MPL
Його зміни мають бути видимі. project/
main.cpp ← proprietary
10. Вказати ліцензію в package metadata.Weak copyleft
Це важлива різниця між правами на код і правами на бренд. під іншою ліцензією: |- | Використовувати код | Так | Для особистих, навчальних, open source або комерційних задач. Можна:
Software license Людське пояснення: MPL каже: “Мої файли залиш відкритими, якщо ти їх змінюєш. Як правильно думати У великому продукті можуть бути: Але MPL-covered files і їхні зміни мають залишатися доступними під MPL при поширенні. Чому виникає
!== 26. MPL і MIT License ==
Для документації часто використовують інші ліцензії:
- їхній внесок у MPL-covered file буде під MPL;
- інші можуть використовувати цей файл у larger works;
- зміни цього файлу мають залишатися відкритими;
- проєкт здатна бути поєднаний із proprietary code;
- patent grant здатна застосовуватися до contribution.== 48. Джерела ==
main.cpp ← proprietary
</pre>
MPL — інша:
{| class="wikitable"
== 15. MPL і trademarks ==
</pre>
Простими словами:
== 10. Larger Work ==
<pre>
{
* використовувати MPL-код у платному продукті;
* продавати програму;
* використовувати MPL-компоненти в SaaS;
* включати MPL-файли в proprietary проєкт;
* поширювати binary;
* вести комерційну розробку навколо MPL-коду. Apache License 2.0
[[SPDX]]
MPL дає можливість включати MPL-covered code у Larger Work. |- | Змінювати код | Так | Зміни MPL-файлів мають поширюватися під MPL. |- | Тип | Weak copyleft | Permissive |- | Зміни licensed-файлів | Мають залишатися відкритими | Можуть бути закриті |- | Комерційне використання | Так | Так |- | Attribution | Так | Так |- | Складність | Вища | Нижча |}
new_feature.cpp
! 8. MPL-covered file — це файл, який поширюється під MPL або містить MPL-licensed code.== 2. Коротка характеристика ==
MPL 1. 23.1 і MPL 2.0
Найактуальніша й найпоширеніша реліз системи — Mozilla Public License 2.0. Інші файли — можуть мати інший режим. Комбінація
payments.cpp ← proprietary
45. Цікаві факти
|- | File-level copyleft | Захищає відкритість конкретних файлів, але не всього проєкту. |- | здатна бути незвичною | Багато розробників краще знають MIT, Apache або GPL. | Зазвичай відкриваються MPL-covered files, не весь Larger Work. |- | Не завжди ідеальна для бібліотек | Для linking-сценаріїв LGPL здатна бути природнішою. |- | MPL 2.0 + AGPL | Так, за замовчуванням | За умови, що не вказано Incompatible With Secondary Licenses. Це пояснює її характер:
Відкрий MPL-файли та їхні зміни. 1. ! ! Якщо змінити `parser.rs`, то зміни мають залишатися під MPL.== 43. Юридичне застереження ==
34. Приклад використання MPL у proprietary продукті
|- | Повна назва | Mozilla Public License |- | Скорочення | MPL |- | Актуальна реліз системи | MPL 2.0 |- | Автор / організація | Mozilla |- | Тип | Weak copyleft / file-level copyleft |- | Основна ідея | Зміни MPL-файлів залишаються відкритими, але інші файли можуть мати іншу ліцензію |- | Комерційне використання | Дозволено |- | Використання в proprietary software | Дозволено за умовами MPL |- | Copyleft-рівень | Рівень файлу |- | GPL-сумісність | MPL 2.0 сумісна з GPL-сімейством за замовчуванням, якщо не вказано Incompatible With Secondary Licenses |- | SPDX identifier | MPL-2.0 |- | Дата MPL 2.0 | Січень 2012 року |}
Інші незалежні файли можуть залишатися закритими. Дія
Приклад у source-файлі: LGPL Це важлива деталь для compliance. Пояснення Але навколо них можна будувати різні системи —
8. Основні обов'язки MPL
|- | Тип copyleft | File-level copyleft | Library / linking-oriented weak copyleft |- | Основна межа | Файл | Бібліотека й linking |- | Proprietary integration | Дозволена | Дозволена за умовами LGPL |- | Static linking | Не центральне питання | Важливе compliance-питання |- | Найкращий сценарій | Mixed-license codebase, окремі файли | Бібліотеки |}
Larger Work — це більший проєкт, який містить MPL-код разом з іншим кодом. MPL 1.1 офіційний FAQ Mozilla описує MPL як simple copyleft license, де file-level copyleft заохочує contributors ділитися змінами до MPL-коду, але дає можливість комбінувати цей код із кодом під іншими ліцензіями, включно з proprietary, з мінімальними обмеженнями. MPL
Це означає:
38. Compliance checklist
42. MPL і документація
|- | Тип | Weak copyleft | Permissive |- | Patent grant | Так | Так |- | Зміни licensed-коду | Мають залишатися відкритими під MPL | Можуть бути закриті |- | NOTICE | MPL має власні notice-вимоги | Apache має NOTICE-файл, якщо він виступає як |- | Proprietary use | Так | Так |- | Основна різниця | MPL захищає MPL-файли | Apache майже не обмежує похідні зміни, але має patent grant |}
Mozilla Public License — це weak copyleft open source-ліцензія, найвідоміша своєю file-level copyleft-моделлю. офіційний текст MPL 2.0 вимагає, щоб кожен contributor надавав source form своїх modifications під умовами MPL, а covered software у source form поширювався тільки під MPL. Вона каже:
MPL дає можливість створювати forks. Чи коректно описані third-party components? +--> proprietary files- Mozilla: Mozilla Public License 2.0
- Mozilla: MPL 2.0 FAQ
- Mozilla: MPL 2.0 Revision FAQ
- SPDX License List: MPL-2.0
- Open Source Initiative: Mozilla Public License 2.0
- Free Software Foundation licensing materials
- Open source compliance documentation
- Mozilla licensing documentation
| - | MPL 2.0 + GPLv2 or later | Так, за замовчуванням | Через Secondary Licenses, якщо не заборонено.MIT — як майже повну свободу без copyleft. Автор MPL-коду здатна заборонити GPL-сумісність через позначку:
{{SEO
|title=Mozilla Public License — file-level copyleft ліцензія для open source
|description=Огляд Mozilla Public License 2.0: file-level copyleft, права, обов'язки, сумісність із GPL/LGPL/AGPL, відмінності від GPL, LGPL, MIT, BSD і Apache License 2.0, переваги, недоліки та цікаві факти.
|keywords=Mozilla Public License, MPL, MPL 2.0, MPL-2.0, file-level copyleft, weak copyleft, Mozilla Foundation, open source license, GPL compatibility, software license
}}
renderer.cpp ← MPL
<pre>
і source code цього файлу має бути доступним. Якщо ти його змінюєш і поширюєш,
+--> Apache files
gui.rs ← proprietary
|-
| Сучасність
| Старіша
| Актуальніша
|-
| GPL-сумісність
| Складніша
| Значно краща за замовчуванням
|-
| Текст
| Довший і складніший
| Спрощений
|-
| Patent language
| Менш сучасний
| Оновлений
|-
| Рекомендованість для нових проєктів
| Зазвичай ні
| Так
|}
== 19. MPL і SaaS ==
<div style="border-left: 6px solid #f57c00; background: #fff3e0; padding: 12px 16px; margin: 16px 0;">
! Дозволено? MPL
його patent rights за ліцензією можуть бути обмежені або припинені. {| class="wikitable"
<syntaxhighlight lang="json">
* `main.cpp` здатна залишатися proprietary;
* `payments.cpp` здатна залишатися proprietary;
* `renderer.cpp` має бути доступний під MPL;
* `renderer.h`, якщо він MPL-covered і змінений, теж має виконувати MPL-вимоги;
* потрібно зберегти notices і текст ліцензії.<pre>
MPL-2.0
MPL не виступає як network copyleft-ліцензією. |}
== 6. Цікавий факт: MPL створювалася для реального великого проєкту ==
Якщо ви поширюєте binary, який містить MPL-covered files, потрібно забезпечити доступ до source code цих MPL-covered files. Але:
MPL здатна бути не найкращим варіантом, якщо:
офіційний Revision FAQ Mozilla підкреслює, що file-level copyleft — найважливіша частина MPL і що вона збереглася в MPL 2.0 порівняно з MPL 1.1. Можна:
[[Open source]]
! !== 44. Людське пояснення: чим виступає як MPL ==
Але технічно деякі проєкти можуть використовувати MPL для source-like documentation або прикладів коду. MPL
як приклад:
MPL можна пояснити так:
! ! |-
| Чітка межа
| Copyleft-межа зрозуміла: файл. |-
| Закрити змінений MPL-файл
| Ні
| Змінений MPL-covered файл має бути доступний під MPL. engine.c ← MPL
Ідея:
<pre>
== 27. MPL і Apache License 2.0 ==
“Відкрий увесь похідний ERP-продукт”. ui.c ← proprietary
== 36. MPL у package metadata ==
Кожен MPL-файл ніби має прозоре скло.== 17. MPL і комерційне використання ==
== 24. MPL і LGPL ==
Цим MPL відрізняється від AGPL, яка спеціально має network copyleft-механізм. Чи поширюється binary? Характеристика
5. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/?utm_source=chatgpt.com))
* код можна використовувати;
* MPL-файли можна змінювати;
* можна створити fork;
* але не можна без дозволу використовувати назви, логотипи або бренди так, ніби ваш ERP-продукт офіційно підтриманий Mozilla або іншим правовласником.== 14. Patent termination ==
* складніша за permissive-ліцензії;
* потребує відстеження MPL-covered files;
* змінені MPL-файли треба відкривати;
* не strong copyleft;
* Secondary Licenses треба перевіряти;
* не така універсально знайома, як MIT або GPL. |-
| 2010-ті
| MPL 2.0 стає простішою, сучаснішою і суміснішою з GPL-сімейством. Критерій
</div>
* захищає відкритість MPL-файлів;
* не змушує відкривати весь ERP-продукт;
* дає можливість proprietary integration;
* підходить для mixed-license codebase;
* має patent grant;
* MPL 2.0 сумісна з GPL-сімейством за замовчуванням;
* виступає як хорошим компромісом між MIT/Apache і GPL. MPL
<pre>
MPL 2.0 виступає як weak copyleft-ліцензією, але її copyleft функціонує не на рівні всієї програми, а на рівні окремих файлів. Якщо змінити `engine.c`, то змінений `engine.c` має залишатися під MPL. 2. Перед використанням критично:
{| class="wikitable"
<pre>
Як і багато сучасних ліцензій, MPL 2.0 містить patent-related захист. |}
Це стандартний захист для open source contributors. |-
| Потрібен compliance
| Треба відстежувати MPL-covered files і їхні зміни. |-
| Поєднувати з proprietary code
| Так
| Якщо MPL-файли залишаються під MPL.== Цікавий факт: MPL 2. 22.0 стала дружнішою до GPL, ніж MPL 1.1 ==
Тобто важлива не лише назва файлу, а й те, чи містить він MPL-covered code. критично: MPL не означає “можна робити що завгодно без умов”. LGPL |
- | MPL — середина між MIT і GPL | Вона не на 100% permissive, але й не strong copyleft. ([spdx.org](https://spdx.org/licenses/MPL-2.0.html?utm_source=chatgpt.com))
ліцензійний пакет не гарантує безпеку коду. Перевага |
У великих проєктах додатково можуть бути:
Це одна з ключових причин, чому MPL зручна для змішаних codebase. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/FAQ/?utm_source=chatgpt.com)) Для contributors MPL означає: 29. Коли варто обрати MPL9. '''Чому це цікаво:''' MPL займає середину між permissive-ліцензіями на кшталт MIT/Apache і сильним copyleft GPL.<div style="border-left: 6px solid #2e7d32; background: #e8f5e9; padding: 12px 16px; margin: 16px 0;"> Але сусідні файли не обов'язково відкривати. !== Див. 49. так само == <pre> [[Open source compliance]] 1. ! Вказати ліцензію в README. ! Пояснення
|
|---|