Виклик програмного забезпечення GPL від програмного забезпечення, яке не є GPL


30

Чи можу я (юридично) використовувати програму, що випускається під GPL з іншої програми, про яку я пишу, і не повинна поважати GPL (для програми, яку я пишу)?

Наприклад, у мене є графічний інтерфейс, який використовує програму (яка знаходиться під GPL), чи можу я заховати код у графічному інтерфейсі і навіть продати його?

Відповіді:


30

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

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

Деякі відповідні біти FAQ GPL :

Де знаходиться лінія між двома окремими програмами та однією програмою з двома частинами? Це юридичне питання, яке в кінцевому підсумку вирішить судді. Ми вважаємо, що належний критерій залежить як від механізму комунікації (exec, pipe, rpc, виклики функцій у спільному адресному просторі тощо), так і семантики комунікації (які види інформації взаємозамінні).

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

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


Чи можу я випустити невільну програму, розроблену для завантаження плагіна, охопленого GPL?

Це залежить від того, як програма викликає свої плагіни. Наприклад, якщо програма використовує лише прості форк та exec для виклику та спілкування із плагінами, то плагіни - це окремі програми, тому ліцензія плагіна не пред'являє жодних вимог щодо основної програми.

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

Якщо програма динамічно пов'язує плагіни, але зв'язок між ними обмежується викликом "основної" функції плагіна з деякими параметрами та очікування повернення, це є прикордонним випадком.

Зауважте, що GPL повністю застосовується до базової програми командного рядка в будь-якому випадку - якщо ви поширюєте її (на відміну від того, щоб користувачі отримували її з іншого джерела), ви несете відповідальність за надання копії GPL користувачам, виготовлення її зрозуміло їм, що програма командного рядка знаходиться під GPL (навіть якщо GUI-обгортка відсутня), і надає вихідний код програми командного рядка для них на запит. З питань FAQ GPL знову:

Якби люди розповсюджували програмне забезпечення, охоплене GPL, називаючи його "частиною" системи, яку користувачі знають, частково є власницею, користувачі можуть бути невідомими щодо своїх прав щодо програмного забезпечення, охопленого GPL. Але якщо вони знають, що те, що вони отримали, - це безкоштовна програма плюс інша програма, поруч, їх права будуть зрозумілі.

Стандартне відмови від відповідальності: я не юрист, і навіть якби я був юристом, я не ваш юрист. Якщо вам потрібна остаточна відповідь, проконсультуйтеся з відповідним юристом, який має ліцензію на практику у вашій юрисдикції.


1
Слід зазначити, що позиція ФСФ щодо зв'язування є позицією меншості. (І IMO, це не має сенсу. Автоматизований процес не може створити нову роботу.)
David Schwartz

1
Однак FSF написав GPL. Це робить їх думку набагато актуальнішою. "Коли ми кажемо X, ми маємо на увазі {...}" загальновизнаним у суді. "Коли ви сказали X, ви мали на увазі {...}", не так.
MSalters

Що означає "використовує лише просту вилку та exec для виклику" - хтось може це уточнити?
Крунал

Тож GPL можна легко обійти, просто записавши трубну обгортку, щоб запустити код GPLed в окремий процес? Це, мабуть, зробить GPL невідповідним та неможливим впроваджувати. Що робити, якщо я напишу власну бібліотеку і посилаюся на неї разом із бібліотекою GPLed. Чи стає моя окрема окрема бібліотека також GPLED? Що робити, якщо я посилаюся на чужу бібліотеку під час використання GPLed-коду? Чи стає їхня бібліотека GPLed? Якщо ви не відповідете на жодне з цих запитань, це відкриє масивну лазівку, щоб легко обійти GPL. Якщо ви відповідаєте "так", ви порушуєте закон про авторські права.
Серін

@Cerin - GPL дійсно застосовується лише до коду, який ви поширюєте. Таким чином, хоча ви можете написати програму, яка посилається як на GPLed, так і на несумісні з GPL ліцензії, ви не можете потім поширювати цю програму третім сторонам, оскільки вона би запускала код GPLed і не GPL, сумісний у тому самому процесі. ("Використання без перерозподілу" багато хто розглядає як лазівку в GPL, оскільки це означає, що веб-сервіси тощо можуть повністю пройти через GPL, оскільки вони самі запускають програмне забезпечення, а не дають його користувачам для запуску. GNU AGPL - це спроба вирішити це питання.)
Дейв Шерохман

0

Залежить, що ви маєте на увазі під його вживанням?

  • складіть його у свій код
  • використовувати спільну бібліотеку
  • запустити виконуваний файл

Також точно залежить, під якою версією / варіантом GPL знаходиться інший код.

  • GPL
  • LGPL
  • AGPL
  • Напевно, інші

Юридична відмова: Я не юрист.


-2

Це залежить від того, як саме ваша програма "використовує" програму GPL. Поширені запитання щодо GPL мають досить тривале пояснення , але воно все ще залишає багато відкритого для тлумачення:

Ви не можете включити програмне забезпечення, охоплене GPL, у власну систему. (...) Однак у багатьох випадках ви можете поширювати програмне забезпечення, охоплене GPL, поряд із власною власною системою. Щоб зробити це дійсно, ви повинні переконатися, що вільні та невільні програми спілкуються на відстані озброєнь, щоб вони не поєднувались таким чином, щоб зробити їх ефективно єдиною програмою. (...) якщо дві програми поєднані так, що вони фактично стають двома частинами однієї програми, то ви не можете розцінювати їх як дві окремі програми. Тож GPL має покрити всю справу.Якщо дві програми залишаються добре відокремленими, як компілятор і ядро, або як редактор і оболонка, то ви можете ставитися до них як до двох окремих програм, але це потрібно робити правильно. Питання - це лише одна із форм: як ви описуєте, що робите. Чому нас це хвилює? Оскільки ми хочемо переконатися, що користувачі чітко розуміють безкоштовний статус програмного забезпечення, охопленого GPL, у колекції.

Я думаю, що у вашому прикладі графічного інтерфейсу, який існує в основному для виклику програми GPL командного рядка, ці два чітко утворюють єдину програму, тому вам доведеться випустити свій код під GPL.


Ні, вони не "чітко формують єдину програму". Поки основна програма командного рядка залишається здатною функціонувати за відсутності накладання графічного інтерфейсу, вони поєднуються «простим агрегуванням» і не є «ефективною єдиною програмою». Зверніть увагу на приклади в тексті, який ви цитували - компілятор сидить поверх ядра і не буде працювати без нього, але ядро ​​буде щасливо запускатися за відсутності компілятора.
Дейв Шерохман

1
@Dave: чи може програма, що лежить в основі командного рядка, здатна функціонувати за відсутності накладання GUI, може бути актуальною, якщо про стан ліцензії програми командного рядка виникли сумніви - але питання стосується графічного інтерфейсу, який безрезультатно без програма командного рядка, і тому правда поза тінню сумнівів, що вони утворюють єдину програму.
Майкл Боргвардт

Давайте підставимо один із прикладів із цитованого розділу та подивимося, як це відбувається. "... але питання стосується компілятора, який без ядра абсолютно марний, і тому це правда поза тінню сумнівів, що вони утворюють єдину програму." За винятком того, що в цитованому вами тексті прямо зазначено, що "ви можете ставитися до них як до двох окремих програм". Якщо це просто питання залежності, то ви ніколи не можете запускати закрите програмне забезпечення в Linux, оскільки це програмне забезпечення було б "абсолютно марним" без ядра (GPLed).
Дейв Шерохман

@Dave: За винятком випадків, що компілятори та всі види закритого програмного забезпечення НЕ марні без ядра Linux, оскільки вони можуть працювати і працювати на будь-якому, що реалізує стандарти бібліотеки POSIX та / або C, і забезпечують власну функціональну функціональність. . Зовсім інша матерія, ніж обгортка GUI, яка існує виключно для керування однією конкретною програмою командного рядка.
Майкл Боргвардт

3
Ти не прав у частині графічного інтерфейсу. Цей самий графічний інтерфейс GUI буде працювати з іншими програмами CLI, зокрема з пізнішими версіями оригіналу. Це актуально в цьому контексті, оскільки це означає, що оригінальні права GPL на базовій програмі все ж можуть бути здійснені. Якщо я перекомпілюю його на 10% швидше, CLI мені не заважає.
MSalters

-3

Ні.

GPL-код може використовуватися лише іншим кодом GPL.

Посилаючись на перший рядок статті GPL у Вікіпедії :

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

З іншого боку, GPL має кілька сторінок і існує в декількох версіях.


Попередження, особистий гнів уперед!

Мені особисто дуже не подобається ліцензія GPL через її дуже обмежувальний та вірусоподібний характер. Вони називають це "безкоштовно", але насправді навпаки, GPL-код не може бути використаний нічим, крім іншого GPL-коду. Таким чином, примушуючи інші проекти в GPL або змушені переписувати цілі бібліотеки, незалежно від того, чи є ваш поточний проект відкритим кодом чи ні. Були величезні проекти з відкритим кодом, наприклад, freeBSD, які змушені були переписати сотні тисяч рядків коду Linux, оскільки їх ліцензія була несумісною, вона була занадто "вільною" у сенсі "роби все, що хочеш", що, очевидно, не сумісний з GPL.

Якщо ви хочете по-справжньому "безкоштовну" ліцензію в сенсі "робіть все, що завгодно", я рекомендую ліцензію на BSD або MIT ... насправді більшість інших ліцензій у порядку. Це лише GPL - це справді проблематично, тому що наскільки він обмежує і як він змушує інших до нього. Нарешті, це надмірно складно.

Ага, так, це також квиток в один бік. GPL може використовувати код / ​​бібліотеки, що мають більшість ліцензій, але ці бібліотеки / код не можуть використовувати код GPL по черзі.


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

@WTP: безумовно, так - вся суть LGPL полягає в тому, щоб мати іншу ліцензію, яка це дозволяє.
Майкл Боргвардт

3
Оболонка графічного інтерфейсу, обмотана навколо програми командного рядка, не є "похідним твором", як визначено для цілей авторського права.
Дейв Шерохман

1
@Dave Sherohman - це не здається зрозумілим. Прийнята відповідь на це запитання говорить: "ІМХО, за духом, чиста обгортка, яка лише розкриває функціональність програми GPL, повинна бути GPL". Це не лише технічний аспект того, як вони спілкуються, це наміри. Наприклад, переклад книги створює похідний твір. Перетворення його у формат Kindle було б похідною роботою. Я міг бачити суддю, який постановляє, що додавання GUI - це похідна робота. Остерігайся.
Скотт Вітлок
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.