Прийняття проекту з відкритим кодом до закритого джерела


19

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


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

Чому б просто не взяти його, зробити його новим проектом і піти звідти?
Грак

@Blrfl Це викликає цікаве запитання. Кожен, хто буде використовувати частини або цілий проект GPL'ed, порушить ліцензію закритого джерела, оскільки база коду була б ідентичною.
Карлсон

8
@Karlson: Не дуже, вони просто ніколи не підписувались на ліцензію закритого джерела. Вони залишаються за ліцензією GPL.
DeepSpace101

Відповіді:


10

Тут є дві речі:

  • відкликання відкритої ліцензії, яку було надано. Це, мабуть, залежатиме від тексту ліцензії. Якщо ліцензія не передбачає, я не впевнений, що це можливо, якщо ліцензіат не порушив її. І деякі ліцензії на зразок GPL версії 3 явні в цьому:

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

  • повторне ліцензування на інших умовах. Це можливо, якщо ви отримаєте згоду всіх власників авторських прав. Якщо ви мали передбачення отримати його до того, як приймати внески (деякі проекти GNU, такі як GCC, просять вас, наприклад, призначити авторські права на FSF), це легко. Якщо ви цього не зробили, це буде важко (якийсь проект зробити це добровільно, щоб змінити ліцензію на практиці неможливо. Отримавши згоду всіх або відстежуючи та видаляючи внески тих, хто не був недоцільним).

(Обов’язкова згадка: я не юрист, бачте свого, і якийсь аспект може бути локалізованим і залежати від вашої юрисдикції).


4

Ви не можете позбавити права користувача користуватися заданим програмним забезпеченням v1.5 , як тільки він отримав це через ліцензування GPL / OSS.

АЛЕ

Ви можете зв'язатися з автором по Given-програмного забезпечення v1.5 і

  1. придбати комерційну ліцензію з правом модифікації та перерозподілом із закритим джерелом
  2. купуйте у нього свої права на програмне забезпечення

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

    Ах, оскільки ви вже там, можливо, вам також буде цікаво придбати права на найменування товару.

Тоді ви можете випустити інші версії (скажімо, програмне забезпечення 2.0 ) під комерційною ліцензією і залишити безкоштовно лише попередню версію. (як у вільній мові)

Деякі проекти OSS продовжують продавати нові версії та випускати попередню як відкритий код при кожному великому оновленнях версії.

(Я думаю, що тут Ghostscript , але також відомо, що Android робив щось подібне, попередньо випускаючи речі зацікавленим партнерам, за здорові ціни)

Що може піти не так

  1. Конкуренція. Основна вилка OSS + перейменування може просто вбити новий комерційний продукт, (це вільний ринок)

  2. Обслуговувач може не мати усіх прав, необхідних йому для повторної ліцензії даного програмного забезпечення 1.5

    • Оригінальний автор не міг бути доступним: поточний сервіс може бути другим, третім чи четвертим обслуговуючим персоналом після оригіналу.
    • Проект міг отримати занадто багато зовнішніх виправлень помилок або доповнень до функцій , і технічний супровід ніколи не намагався просити про відмову, тому програмне забезпечення зараз справді належить обслуговуючому персоналу та всім, хто коли-небудь вносив будь-який код . За невизначених термінів.

      Справжній нерозривний безлад, який лише чекає, коли адвокат з деяким часом спалить, і корпорація, яку варто доїти за гроші. (насправді навіть проект GNU завжди просить відмовитись, які передають усі авторські права до фонду GNU)

    • Відмови можна було підписати, але умови на них могли точно вказати ліцензію на код ніколи не можна змінювати .

У цих останніх двох ситуаціях єдиний вихід з ОСС - це важке, величезне, горе і сумне переписування всього внесеного коду. І навіть якщо все зроблено правильно і добре, вона все ще може бути заперечної, (від цього адвоката, так) , так що ... це на самому справі не варто.

Відмова від відповідальності: IANAL.


І так, тому важко зробити неможливим внесок у основну кодову базу Android. Вони просто не можуть приймати виправлення та розмахувати прапором OSS лише за значенням його слова . (так, це відстійно)
ZJR

2
IANAL. Співробітники Android повинні підписати "Ліцензійну угоду для корпоративного вкладника", яка фактично дає "лідерам проектів" ліцензію на авторське право робити з вашим кодом все, що завгодно.
Джейді

3

IANAL, але:

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

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


0

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

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

Наприклад, Open Office був відкритим кодом (і досі є). Але оскільки Oracle придбав Sun, люди відчули, що OO може бути занадто жорстким, тому вони можуть почати змінювати цей код самостійно під назвою Libre Office, і Oracle не може відкликати це право.

Однак завжди можна зробити дві речі:

  1. Додайте ліцензію за певних умов. Наприклад, ви можете мати комерційну ліцензію, відмінну від Open Source, яка є лише в тому випадку, якщо ви є самим проектом з відкритим кодом (або НУО / Академія).

  2. Для всієї нової версії ви все одно можете скасувати стару ліцензію та надати нову. Наприклад, REDHAT 7 (або 8) був усі з відкритим кодом. Після цього вони створили RHEL, який отримав комерційну ліцензію. Так народилася Федора.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.