Чи існує лазівка ​​в GPL, яка дозволяє зв’язати власницьке програмне забезпечення з бібліотеками GPL?


15

Розберемо гіпотетичний сценарій:

Компанія X пише власну програму (A), яка динамічно пов'язується із власною бібліотекою (B). Компанія Y хоче використовувати бібліотеку заміни (C), ліцензовану відповідно до GPL, і таким чином записує бібліотеку обгортки (D), яка динамічно посилається на A і C і переводить виклики API, використовувані A, на виклики API, використовувані C.

Оскільки D призначений для використання з C та використовує API викликів C, він є похідною роботою C і тому повинен бути розповсюджений за умовами GPL *. Як результат, комбінована робота A і D також повинна поширюватися за умовами GPL, що неможливо, враховуючи, що компанія Y не має вихідного коду для А. Це сказано, якщо компанія Y поширює D сама по собі , немає жодних проблем. Однак, незалежно від дій компанії Y, компанія X не порушує GPL, поширюючи A, навіть без B. Просте існування D не означає, що A раптом є похідною роботою C (через D), яка повинна бути ліцензована відповідно до GPL також.

Тепер ця лазівка: ніщо не заважає Компанії X писати власну версію D, поширювати її окремо від A та казати кінцевим користувачам використовувати D замість B під час запуску A. Схоже, що компанія здатна розробка власницької програми для використання бібліотеки GPL без порушення GPL, доки модуль обгортки використовується для ізоляції патентованої програми від бібліотеки GPL, і цей модуль поширюється окремо.

Чи правильно я міркую? Це справжня лазівка ​​в GPL?

* D також є похідною роботою A, але для цілей цього сценарію компанія X явно дозволила створити D і дозволила ліцензувати його відповідно до GPL.


1
Коротка відповідь: ні.
whatsisname

2
Я все, крім юриста, але, наскільки я розумію, що динамічне посилання на бібліотеку не робить ваш код похідною роботою. В іншому випадку неможливо буде поширювати що-небудь під, скажімо, ліцензією BSD, яка динамічно пов'язується з тим, що може бути під ліцензією GPL. Статичне посилання - це вже інша історія, і, звичайно, ви не можете перерозподілити динамічно пов'язану бібліотеку під будь-яким іншим, крім GPL.
tdammers

4
@tdammers: динамічне посилання AFAIK робить код похідною роботою, і ви правильно, можливо, неможливо поширювати програмне забезпечення за ліцензією BSD, коли він використовує GPL-лібри. Ось чому багато авторів бібліотек з відкритим кодом пропонують свої бібліотеки під LGPL замість GPL.
Док Браун

2
@tdammers: Для цього сценарію я використовую підхід Сталмана до зв'язків: і динамічне, і статичне з'єднання порушує GPL.
Майкл Курлас

3
@mouviciel Існували рішення суду, які вказували на те, що тиражування API для цілей взаємодії є законним. Я вважаю, що це було встановлено незалежними судами високого рівня як у США, так і в ЄС, тому правовий статус є досить солідним (якщо хтось активно не змінює закон).
Стипендіати Доналу

Відповіді:


10

IANAL, але ось моя думка про те, що дозволено в межах GPL:

  • розповсюджуйте загальнодоступну роботу "А - Б" на публіці: штрафом, це можна зробити за будь-якою власною ліцензією

  • створіть кришку D для C для Y за допомогою Y: добре, це не означає, що A потрібно поставити під GPL

  • використовуйте комбінований продукт "A - D - C" внутрішньо Y: також добре, GPL не вимагає відкривати вихідний код A до тих пір, поки комбінація не поширюється для всіх

  • розповсюджуйте комбіновану роботу "A - D - C" на публіці: для цього потрібно буде A з відкритими джерелами та його розміщення під GPL (і не важливо, чи X або Y поширили цю комбінацію; додатково, якщо Y хоче зробити це, що, звичайно, вони вимагатимуть ліцензії на розповсюдження для A від X)

Цікаве питання зараз: чи може D&C поширюватися окремо як відкритий код під GPL, A&B (або просто A без B) поширюватися за власною ліцензією, а кінцевий користувач замінює B на D&C сам?

Тут остаточна модифікація на "AB", яка робить A залежною від libs D&C, здійснюється кінцевим користувачем - після розповсюдження . Отже, можна стверджувати, що остаточну модифікацію здійснює лише внутрішній кінцевий користувач. І здається, що це дійсно можливо без порушення GPL - і ви отримуєте робочу комбінацію "AC&D", де A є власником ліцензії, а C&D - GPL.

Звичайно, адвокат чи суддя можуть мати іншу думку з цього приводу. Щоб отримати остаточну відповідь, я думаю, ви повинні почекати, коли хтось випробує це, а другий подасть до нього позов.

Я думаю, що для більшості систем буде складно створити таке сузір’я, не спроектувавши "А" спочатку таким чином, щоб воно безперебійно працювало і з B, і з C. І в цьому випадку можна прийти до підозри, що A було якось похідне від C.

РЕДАКТУВАННЯ: деякий час обмірковуючи це, мені спадала на думку подібна ситуація: написання та розповсюдження ліцензій GPL для додатків із закритим кодом. Візьмемо для прикладу Photoshop. Я не думаю, що хтось серйозно намагатиметься змусити Adobe відкрити джерело Photoshop лише тому, що існують деякі плагіни GPL від сторонніх постачальників. Тут не потрібна навіть "обгортка", оскільки існує чітко визначений інтерфейс. Однак чи змінила б ситуацію, якщо Photoshop включив би частину своїх центральних функцій із плагіну сторонніх розробників GPLed? Я думаю, що в такому випадку може бути дуже важко вирішити, де провести лінію, і тоді продукт із закритим кодом - це робота, "заснована" на ліфті GPL.

EDIT2: Доступні ліцензії подвійної ліцензії, з ліцензією GPL на некомерційне використання та власною ліцензією на комерційне використання, як ця, наприклад. Таким чином, ваша «лазівка» означала б розробити продукт на основі такої версії (використовуючи комерційну версію, тому GPL не застосовується до вашого продукту), доставити ваш продукт як закритий джерело без шаблону для широкого загалу та дозволити кінцевому Користувач отримує та встановлює версію GPLed власноруч. У такому випадку я думаю, що у продавця ліб є шанс успішно подати в суд за порушення ліцензії (якщо ви, звичайно, не заплатите за його ліб). Чи варто клопоту? Напевно, ні. Особливо у прикладі, з яким я пов’язаний, вам також доведеться купувати лінзи, оскільки ціноутворення не залежить від того, як часто ви продаєте свій товар, а лише від кількості розробників, які використовують лібу під час розробки.

Нарешті, через ці юридичні ризики, якщо я маю намір використовувати ліцензії з відкритим кодом у продукті із закритим кодом, я б уникав GPL ліфтів, якщо це можливо, і не намагався використовувати цю "лазівку". LGPL або GPL за винятком посилань набагато безпечніші або будь-які ліцензії на невірусну ОС.


2
Моє відчуття кишки говорить про те, що юристи почнуть сильніше кидати, якщо компанія, яка виробляє, Aтакож почне рекламувати A - C&Dкомбо.
Барт ван Іґен Шенау

1
@BartvanIngenSchenau: Я згоден. Але я можу уявити інший сценарій: X поширює AB, а Y поширює (і рекламує) "надбудову" C&D з інсталятором, який замінює B у папці установки AB?
Док Браун

Я також можу уявити цей альтернативний сценарій, і юристам буде набагато важче пробитися, якщо Aі C&Dпоходять від різних юридичних осіб.
Барт ван Інген Шенау

1
@DocBrown: Чи має значення еквівалентна власна бібліотека B? Чи не могла компанія X продати A сама, припускаючи, що кінцевому користувачеві доведеться знайти робочу бібліотеку для її використання, а потім "зручно" надати їм D?
Майкл Курлас

1
@MichaelKourlas: існування lib B зробило б набагато складніше подати позов до X, оскільки X полегшує доказ того, що A не є "похідною роботою" C.
Док Браун

3

Практичним прикладом є власні драйвери графіки для Linux, які кінцевий користувач повинен встановити самостійно. Важливо, що для творця власного драйвера, якщо кінцевий користувач розповсюджує комбіновану роботу, це створює юридичне зобов'язання для кінцевого споживача (яке він не може виконати), але не для творця драйвера.

Інша відповідь стверджує, «оскільки програма залежить від бібліотеки, вона все ще є похідною роботою», але якщо програма насправді не працює, оскільки бібліотека не існує, вона не є похідною.

Зрештою, якщо ви покладаєтесь на «лазівки», то вам слід врахувати, що ваш підхід в першу чергу може бути не правильним.


Незалежно від того, чи повинен кінцевий користувач встановлювати компонент GPL, немає значення. Власні модулі ядра, що містять обгортки GPL, зазвичай розповсюджують компонент GPL лише у формі вихідного коду та вимагають від користувача їх компілювати. DKMS автоматизує це. Для цього використовується інша "лазівка" GPL, яка полягає в тому, що ви можете робити все, що завгодно, з локальною копією програми GPL, доки ви не перерозподілите її у вигляді об'єктного коду. Оскільки кінцеві користувачі зазвичай не розповсюджують ядро ​​Linux разом із власними модулями ядра та компільованими обгортками GPL, вони, як правило, безпечні.
Климент Черлін

1

Зв'язування визначає похідну GPL. Ця конкретна ситуація полягає в тому, з чим розроблено LGPL: де ви хочете випустити бібліотеку як GPL, але визначити посилання як явний ліміт застосованої ліцензії, або по черзі, де ви хочете зв’язатись із деяким кодом GPL, але вимагати, щоб ваш власний робота буде випущена за ліцензією, що не стосується GPL.

У випадку, коли кінцевий користувач збирається здійснити посилання (побудувати свій власний код з джерел, що не належать GPL, які можуть пов'язуватись з бібліотекою GPL), кінцевий користувач фактично не створив версію GPL будь-якого кінцевого продукту, оскільки йому не дозволяється змінювати ліцензію частини, яка не є GPL, тому що він не є її власником. Це, як правило, виключає розповсюдження кінцевим споживачем у будь-якій формі, але не забороняє використання.

Однак, якщо проект вимагає, щоб він був побудований з джерела і поширювався лише таким чином, не має значення, під якою ліцензією знаходиться пов'язана бібліотека, оскільки це повністю не в руках розробника, який не є GPL. Тобто, як ви можете знати, що ваш дистрибутив, призначений лише для джерел, буде побудований на gcc проти glibc VS, побудованого на компіляторі IBM, проти їхнього libc, якщо ви не вкажете це під власними ліцензійними умовами? Це швидко наштовхується на добросовісне використання і забороняє виконувати невиконані правові умови (не те, що фантазія останнім часом не була записана в закон досить часто).


0

Я не юрист, але, наскільки можу вам сказати, ви невірні, оскільки програма залежить від бібліотеки - це все-таки похідна робота. Так само, як послідовність - це похідна робота. Як мінімум, це базується на API, визначеному в бібліотеці.


Не вдалося вирішити проблему з API, включивши модуль обгортки, на який ви маєте авторські права? (див. windyroad.com.au/2006/04/20/… для прикладу того, про що я говорю)
Майкл Курлас

Я оновив питання, щоб додати компонент обгортки.
Майкл Курлас

@ user92103 Чи відповідає цим питанням ваше питання? gnu.org/licenses/gpl-faq.html Або це питання P.SE: programmers.stackexchange.com/questions/50118/…
apsillers

1
@apsillers: Питання P.SE стосується зв'язку клієнт-сервер через мережу. Хоча це, безумовно, можливий спосіб обійти GPL, про це я говорю тут (динамічне посилання). Я подивився на поширені запитання про GPL, і у них виникає питання, що стосується модуля обгортки, але це питання передбачає, що дистриб'ютор поєднує бібліотеку GPL з власною програмою в точці розповсюдження. У цьому випадку кінцевий користувач виконує групування, що різко змінює речі.
Майкл Курлас
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.