Я хотів би випустити бібліотеку програмного забезпечення, написану на основі класу, об'єктно-орієнтованою мовою програмування (Java) на веб-сервісі хостингу вихідного коду , що дозволяє об'єднати вилки проекту в основний проект (GitHub через pull запити). Я досліджував в Інтернеті і багато думав, як ліцензувати програмне забезпечення. Чи я правильний у наступних припущеннях (з точки зору IANAL )?

• І LGPL, і MPL сприяють спільному використанню модифікацій ліцензійного програмного забезпечення LGPL / MPL, яке використовується в інших програмних проектах. Замість того, щоб вимагати від користувачів модифікованої бібліотеки розміщення окремої вилки бібліотеки, я можу просувати внесок у вихідну бібліотеку (наприклад, через запити на витяг).

• Основна відмінність полягає в тому, як ліцензійний код MPL / LGPL повинен бути пов'язаний з проектом. Файли вихідного коду MPL можна безпосередньо скопіювати у (можливо) власницький програмний проект ( статичне посилання ), тоді як ліцензійний код LGPL повинен бути динамічно пов'язаний (нещільно пов'язаний з можливим проектом програмного забезпечення, щоб кінцеві користувачі могли вимкнути ліцензійне програмне забезпечення бібліотека для іншої версії ліцензованої бібліотеки програмного забезпечення).

• Динамічне посилання та, таким чином, LGPL накладає додаткові перешкоди для упаковки фірмового програмного продукту, не сприяючи більшому внеску в бібліотеку програмного забезпечення з відкритим кодом, ніж завдяки статичному зв’язку (і, таким чином, MPL). Існує модифікований LGPL, який дозволяє статичне з'єднання.

• Там немає ніяких інших значущих відмінностей (від IANAL точки зору).

• У старіших версіях ліцензії не задовольняють мої потреби так добре , як новітні з них.

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

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

Рішення: За допомогою обговорення у прийнятій відповіді я обираю дотримуватися MPL через популярність , свободу зв’язків та тому, що це офіційна, немодифікована ліцензія .

Я вважаю, ви точно вказали різницю між публічною ліцензією Mozilla та меншою загальнодоступною ліцензією GNU , і це може відповідати вашим потребам просто чудово, але ви пропускаєте найважливішу різницю між двома ліцензіями:

Хто може робити нові версії?

І MPL (розділ 10), і LGPL (розділ 14) включають у свою ліцензію право замінювати поточну версію останньою версією, і фактичних обмежень щодо того, що може входити в ці ліцензії, немає. Хоча це дуже малоймовірно, що або Фонд Mozilla, або Фонд вільного програмного забезпечення зроблять щось настільки божевільне, як, скажімо, запровадити застереження, яке говорить про те, що "всі внески в це програмне забезпечення стають нашою власністю", це не виходить за межі можливості, що один із організації випустять нову ліцензійну версію, яка вам не подобається.

Що означає ще один момент щодо використання "Модифікованого LGPL".

Змінена ліцензія - це не та сама ліцензія!

Хоча ви маєте досить дивовижну здатність вказувати власні умови ліцензування, і по суті, це може сказати "ви можете поширити це відповідно до GPL, але вам потрібно вписати моє ім'я у ваші кредити та сплатити мені 1% будь-якого отриманого вами доходу" , в будь-який час ви створюєте нову ліцензію на основі чужої роботи. Це означає, що ви НЕ використовуєте MPL або LGPL, ви використовуєте нову "ліцензію mucaho".

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

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

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

Відповідь DougM та AER робить справедливим. MPLv2 та LGPLv3, за винятком статики, однакові щодо подій, які спричинили копілефт. Однак я думаю, що нам не вистачає ще однієї дуже важливої ​​різниці між LGPL та MPL. Коли спрацьовує копілефт, копілефт застосовується до:

• для MPL: до тих самих файлів вашої оригінальної бібліотеки
• для LGPL: до "роботи, заснованої на бібліотеці", на відміну від "роботи, яка використовує бібліотеку". Таким чином, LGPL може потенційно поширити копілефт на нові файли.

Кордон: Використання MPL дозволяє користувачам не ділитися своїми вдосконаленнями

MPL - це ліцензія на файл-рівень copyleft. Це означає, що якщо хтось вбудує його у більший проект (статично чи динамічно) та внесе зміни у ваш файл, він повинен лише випустити зміни, внесені до цього конкретного файлу.

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

Наприклад, хтось може взяти один з головних файлів вашого проекту, додати "імпорт my_private_new_file" та змінити ваш основний метод, наприклад, додавши "my_private_new_file.newAwesomeFeature.run ()" .

І таким чином він міг додати нові функції до вашого проекту, лише випустивши модифікований основний файл і зберігаючи фактичну логіку нового закритого джерела в "my_private_new_file" .

Повернення основного файлу до спільноти просто дасть вам інформацію про те, що "Ей ви додали нову функцію", але це не дозволяє вам використовувати цю нову функцію відкрито ... Це може дратувати, якщо нова функція буде тісно - пов'язана з проблемою, яку намагається вирішити ваша бібліотека.

Очевидно, що це крайній випадок, і навряд чи хтось захоче цього зробити, але це ризик, про який ви повинні знати, користуючись MPLv2.

LGPL написано для заборони такої поведінки. Побачити:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• Чи дозволяє LGPL мені це зробити?

Я цитую оригінальну ліцензію LGPL:

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

Копілефт стосується лише "роботи на основі бібліотеки". Тепер що таке "робота на основі бібліотеки" на практиці? Це залишає простір для інтерпретації. Що не тільки приємна річ, оскільки це означає, що дотримання ліцензії стає складнішим і, отже, страшним. Це може призвести до того, що деякі люди просто не користуються вашою бібліотекою.

У цьому сенсі LGPL є більш обмежуючим, ніж MPL, але також захищає цілісність проекту.

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

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

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

Як результат, MPL значно простіше використовувати власників-постачальників використовувати І надсилати виправлення у вашу бібліотеку, ніж LGPL.

У той же час, у більшості випадків власники постачальників не мають ані ресурсів, ані часу, щоб зануритися у вашу складну бібліотеку, і, швидше за все, не вирішили б її самі. Вони скоріше відкриють проблему у вашому репортажі GitHub або надішлють електронний лист у списку розсилки та чекають вашого виправлення.

У зв'язку з цим LGPL більше застосовує подібну поведінку. Але чи потрібне виконання справді?

Висновок

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

LGPL був створений Фондом вільного програмного забезпечення, щоб забезпечити широке використання бібліотек вільного програмного забезпечення у світі, але завжди маючи на увазі ідею просування вільного програмного забезпечення та боротьби з власником програмного забезпечення. Це все є частиною стратегії щодо їх ідеології. Дивіться: https://www.gnu.org/licenses/why-not-lgpl.html

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

За своєю суттю MPLv2 багатьма розглядається як дозвільна ліцензія, тоді як LGPLv3, у тому числі зі статичним винятком, рідко називається таким чином.

EDIT

Я забув згадати щось важливе. LGPLv3 (зі статичним винятком або без нього) забороняє сприймання . Ви можете подумати, що це "деталь", але насправді це не так, залежно від вашої мети. Чи дбаєте ви про свободу користувачів? Тоді це не деталь. Чи хвилює вас, що вашу бібліотеку можна використовувати на пристрої Apple? VLC більше піклується про використання, тому вони вирішили використовувати LGPLv2, який не містить такого обмеження. Так само, це одна з причин, чому Linux продовжує використовувати GPLv2 . MPLv2 також не має обмежень щодо тивіонізації, очевидно, оскільки це ліцензія, створена з урахуванням "практичної" філософії з відкритим кодом, а не ідеології FSF.

Можуть бути й інші "незначні" речі, подібні цій, яку я пропустив.