Чи можу я зв’язатись із бібліотекою GPL із додатка із закритим джерелом?

Гаразд, перш ніж всі кричать про повторювані запитання, так, я вже бачив кілька таких питань. Але ніхто не відповідає на питання.

Якщо я посилаюсь на бібліотеку з редакцією GPL, не змінюючи цю бібліотеку, чи потрібно випускати свій вихідний код?

Відповідно до цього питання , відповідь - так!

Але ця відповідь не задовольняє мене. Відповідь в основному говорить, що я не можу використовувати GPL-код жодним чином, не роблячи код відкритим кодом.

Але якщо попереднє вірно, то це вказуватиме на те, що жодна людина чи організація ніколи не може випускати будь-яке власне програмне забезпечення на Linux. Що повинно бути неправильним. Просто тому, що будь-яка програма може робити щось корисне, відкривати файли, писати на консоль, створювати TCP-з'єднання, програма повинна бути пов'язана з libcGPL-ed.

Отже, моє запитання таке: Якщо GPL заявляє, як всі попередні відповіді на сайті говорять, що це робить, програма, яка посилається на іншу програму GPL, повинна бути самою GPL, як можна створити / випустити / продати будь-яку власну програму взагалі що працює на Linux? Оскільки, як я описав вище, ця програма повинна подобатися GPL-коду просто для роботи в Linux.

Більш практичний приклад скаже, що я посилаюсь на спільну бібліотеку, яка GPL-ed у додатку, що не є GPL, чи змусить це не-програма GPL стати GPL-ed? Більш конкретно, якщо я використовую бібліотеку GPL, не змінюючи її, а потім поширюю цю бібліотеку як .soабо .dll, чи вимагатиме, щоб моя програма була відкритим кодом?

gpl linking

— Джон-Чарльз
джерело

Ви продовжуєте задавати те саме запитання, сподіваючись на іншу відповідь. Ви не можете використовувати GPL у програмному забезпеченні, не сумісне з GPL. Мертвий простий.

— Ендрю Т Фіннелл

Він справді? Блідий. Відповідь проста; чому б не зв’язатися з авторами програми GPL і не запитати, чи вони проти? Якщо кажуть, що це добре, це велично! Якщо вони заперечують, то намагання посилити їх юридичними деталями зробить вас дуже непопулярними, незалежно від того, наскільки "правильним" ви відчуваєте себе.

— Джеймс

@James: Якщо вони вибрали GPL, це досить сильна заява вони роблять розум. Люди, які не проти вибрати в першу чергу MIT, BSD або LGPL. Дуже рідко можна побачити бібліотеку під повним GPL. Коли ви це зробите, ви можете бути майже впевнені, що це було навмисно.

— Ян Худек

@Jan Можливо, це залежить від програми та запланованого використання John-Charles. Але я просто думаю, що дивно, як JC підходить до цього. Jc просто намагається отримати відповідь, яку він хоче? На цьому сайті є багато питань, які можна було б вирішити "просто поговорити з ними, бо плакати вголос". :-)

— Джеймс

@JanHudec: Я згоден. Я стверджував, що випустити частину ІС нашої компанії у вигляді бібліотеки GPL'ed, оскільки це було б марно для наших конкурентів і все ще дуже корисне для нашої громади.

— MSalters

Відповіді:

Якщо ви посилаєтесь на ліцензію GPL, тоді ви створили похідну роботу, і ваш код повинен бути GPL - це відрізняється від коду L GPL, який спеціально дозволяє динамічно посилатись на різний ліцензійний код. Все системні бібліотеки, включаючи libc, - це LGPL.

Існує також спеціальне звільнення для заголовків ядра Linux і libgcc (бібліотека, яку явно викликає компілятор).

— Мартін Беккет
джерело

No libc не є LGPL - вам дозволяється посилатися на програми LGPL. Існує також загальне виняток для викликів ядра / системи, тому немає аргументу абобу, що таке виклик системи проти бібліотеки

— Мартін Беккет

LGPL не є новою ліцензією, вона вперше була випущена в 1991 році. Libc завжди був LGPL.

— FigBug

@ john-charles - саме тому LGPL був винайдений ще в 1991 році з gplv2. AsLinux (та інші ядра FOSS) стали популярними - і тому його спочатку називали Бібліотека-GPL - існував побоювання, що кожен постачальник компілятора буде мати збиток libc, якщо комерційні програми не зможуть використовувати gcc.

— Мартін Бекетт

@MartinBeckett Це думка FSF (ви не можете посилатися на код GPLd, якщо ви не ліцензуєте свій власний GPL), однак це не є безперечним. Не було жодного серйозного позову (про який я знаю, якщо я помиляюся, будь ласка, виправте мене), щоб підтвердити думку ФФС щодо посилання.

— K.Steff

@ john-charles - так, все загальне законодавство проходить перевірку в судах, але судова практика щодо авторських прав існує досить багато. Якщо я стверджую, що моя немодифікована копія DVD з Бетменом не є виправданою роботою, і тому я можу продати стільки, скільки хочу - MPAA навряд чи погодиться! Копілефт GNU використовує авторські права для забезпечення ліцензійної угоди досить розумним способом - одна з причин, яку вона ніколи не перевіряла в суді, - це те, що всі завжди влаштовувались

— Мартін Бекетт

У загальному випадку ви маєте рацію в тому, що не можете зв’язатися з бібліотекою GPL, поширити свій код і не випустити свій код як GPL.

Однак є виняток із системної бібліотеки, який полягає в тому, як люди пов'язують лібуси Linux і все ще випускають свій продукт під ліцензіями, що не належать GPL.

Ще один виняток - коли дві ліцензії сумісні між собою. Перегляньте сумісну сторінку ліцензії FSF для подальшого читання.

Нарешті, автори GPL’d lib можуть створити конкретні винятки, наприклад, для некомерційних чи любителів.

На жаль, існує надто багато можливостей, щоб мати жорстке і швидке правило. Без більш конкретних питань у вашому запитанні, ваша відповідь "напевно, не може, але, можливо, ви можете".

SLE також відповідає на питання про те, що програма є похідною роботою компілятора, оскільки вона містить парсер, сформований компілятором

— Мартін Бекетт

Ні, SLE дозволяє розробляти GPL-код за допомогою невільної ланцюга інструментів та стандартного режиму виконання, наприклад Visual Studio. Це не дозволяє ніколи не пов'язувати невільний додаток із бібліотекою GPL.

— Ян Худек

Вихід програми GPL не охоплюється GPL. Дивіться gnu.org/licenses/gpl-faq.html#GPLOutput

— Maximus Minimus

-1

Коротка відповідь полягає в тому, що насправді ніхто не знає. (Ця дискусія стосується GPL, а не LGPL.)

У GPL є неясна мова про "Похідні твори", які різні люди трактують по-різному. Здається, що консенсус полягає в тому, що статичне посилання порушує, але виклик через системні переривання (наприклад, до ядра Linux) цього не робить. Останнє базується в основному на тому, що такі компанії, як Oracle відправляються на Linux і не подали до суду - це не ясно в ліцензії.

Динамічне посилання є незрозумілим, ймовірно, 70/30 кажуть, що це порушує. Виклик програми за допомогою труб або віддалених викликів процедур, ймовірно, 30/70 не порушує, навіть якщо це по суті те саме. Дзвінки через COM або використання Java Jar абсолютно незрозумілі.

В основному, якщо є якісь сумніви, і ви не любите юристів, тоді тримайтеся подалі від GPL.

— Tuntable
джерело

GPL насправді не так розпливчасто, і судова практика добре обговорюється навколо питання про те, що є, а що не є похідним твором. Різниця між інтерфейсом syscall Linux та libc полягає в тому, що перше необхідно зробити робочим програмним забезпеченням (яке було підтверджено як виняток із авторських прав), а друге - ні (ви могли реалізувати свій власний). Це не має нічого спільного з тим, як викликаються операції, що не мають юридичної актуальності. Я АНАЛ, це не юридична порада.

— Жуль

"70/30 скажіть, що це порушує" і "30/70 не порушує" - чи навмисно, що співвідношення порушення / не порушує однакове? "навіть якщо це по суті одне і те ж", говорить про те, що він мав бути іншим.

— Mateusz Konieczny