MPL

SEO title: Mozilla Public License — file-level copyleft ліцензія для open source SEO description: Огляд Mozilla Public License 2.0: file-level copyleft, права, обов'язки, сумісність із GPL/LGPL/AGPL, відмінності від GPL, LGPL, MIT, BSD і Apache License 2.0, переваги, недоліки та цікаві факти. SEO 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 Alternative to:

Головна ідея: Mozilla Public License — це open source-ліцензія зі слабким copyleft на рівні файлів: якщо ви змінюєте файл під MPL, зміни цього файлу мають залишатися відкритими під MPL, але інші файли проєкту можуть бути під іншими ліцензіями, навіть proprietary.

Чому це цікаво: MPL займає середину між permissive-ліцензіями на кшталт MIT/Apache і сильним copyleft GPL. Вона захищає відкритість конкретних MPL-файлів, але не “заражає” весь проєкт.

Важливо: MPL не означає “можна робити що завгодно без умов”. Якщо ви поширюєте змінені MPL-файли, потрібно надати їхній source code під MPL, зберегти notices і виконати вимоги ліцензії.

1. Загальний опис

Mozilla Public License або MPL — це ліцензія на вільне та відкрите програмне забезпечення, створена Mozilla.

Найактуальніша й найпоширеніша версія — Mozilla Public License 2.0.

MPL 2.0 є weak copyleft-ліцензією, але її copyleft працює не на рівні всієї програми, а на рівні окремих файлів.

Офіційний FAQ Mozilla описує MPL як simple copyleft license, де file-level copyleft заохочує contributors ділитися змінами до MPL-коду, але дозволяє комбінувати цей код із кодом під іншими ліцензіями, включно з proprietary, з мінімальними обмеженнями. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/FAQ/?utm_source=chatgpt.com))

2. Коротка характеристика

Характеристика	Значення
Повна назва	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 року

SPDX вказує, що MPL 2.0 була випущена в січні 2012 року, а її стандартний SPDX-ідентифікатор — `MPL-2.0`. ([spdx.org](https://spdx.org/licenses/MPL-2.0.html?utm_source=chatgpt.com))

3. MPL простими словами

MPL можна пояснити так:

Є файл під MPL.

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

Але ти можеш додати поруч інші файли
під іншою ліцензією:
MIT, Apache, GPL або навіть proprietary.

Людське пояснення: MPL каже: “Мої файли залиш відкритими, якщо ти їх змінюєш. Але весь твій проєкт я не змушую відкривати”.

4. Чому MPL називають file-level copyleft

File-level copyleft означає, що copyleft-обов'язок прив'язаний до конкретного файлу.

Наприклад:

project/
  engine.c        ← MPL
  ui.c            ← proprietary
  database.c      ← proprietary
  README.md

Якщо змінити `engine.c`, то змінений `engine.c` має залишатися під MPL.

Але `ui.c` і `database.c` можуть залишатися proprietary, якщо це окремі файли й вони не є MPL-covered source code.

Офіційний Revision FAQ Mozilla підкреслює, що file-level copyleft — найважливіша частина MPL і що вона збереглася в MPL 2.0 порівняно з MPL 1.1. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/?utm_source=chatgpt.com))

5. Історія

MPL виникла в контексті Mozilla та Netscape-коду.

Ключові етапи:

Рік	Подія
1998	Netscape відкриває код браузера, що стає основою Mozilla-проєкту.
1998	З'являється Mozilla Public License 1.0.
1999	Виходить MPL 1.1.
2012	Виходить MPL 2.0.
2010-ті	MPL 2.0 стає простішою, сучаснішою і суміснішою з GPL-сімейством.
2020-ті	MPL 2.0 залишається важливою weak copyleft-ліцензією для бібліотек, застосунків і mixed-license проєктів.

6. Цікавий факт: MPL створювалася для реального великого проєкту

MPL не була абстрактною академічною ліцензією.

Вона виросла з практичної потреби: відкрити великий браузерний код і дозволити співпрацю між open source-спільнотою та компаніями.

Це пояснює її характер:

• не така сувора, як GPL;
• не така вільна, як MIT;
• зручна для великих codebase;
• дозволяє proprietary modules;
• зберігає відкритість змінених MPL-файлів.

MPL — це ліцензія для ситуації, де код живе в змішаному світі.

7. Що дозволяє MPL

Дія	Дозволено?	Пояснення
Використовувати код	Так	Для особистих, навчальних, open source або комерційних задач.
Змінювати код	Так	Зміни MPL-файлів мають поширюватися під MPL.
Поширювати код	Так	У source або binary form.
Використовувати в комерційному продукті	Так	MPL дозволяє commercial use.
Поєднувати з proprietary code	Так	Якщо MPL-файли залишаються під MPL.
Закрити інші файли проєкту	Так	Якщо це окремі non-MPL файли.
Закрити змінений MPL-файл	Ні	Змінений MPL-covered файл має бути доступний під MPL.

8. Основні обов'язки MPL

При використанні й поширенні MPL-коду зазвичай потрібно:

• зберегти текст ліцензії;
• зберегти copyright notices;
• вказати, які файли під MPL;
• надати source code MPL-covered files;
• надати source code змін MPL-covered files;
• не накладати додаткові обмеження на MPL-covered source;
• не видавати чужий код за повністю свій;
• дотримуватися patent-related положень.

Офіційний текст MPL 2.0 вимагає, щоб кожен contributor надавав source form своїх modifications під умовами MPL, а covered software у source form поширювався тільки під MPL. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/?utm_source=chatgpt.com))

9. MPL-covered files

MPL-covered file — це файл, який поширюється під MPL або містить MPL-licensed code.

Приклад:

src/
  parser.rs       ← MPL-covered
  gui.rs          ← proprietary
  storage.rs      ← MIT

Якщо змінити `parser.rs`, то зміни мають залишатися під MPL.

Якщо `gui.rs` не містить MPL-коду і є окремим файлом, його можна залишити під proprietary license.

10. Larger Work

MPL дозволяє включати MPL-covered code у Larger Work.

Larger Work — це більший проєкт, який містить MPL-код разом з іншим кодом.

Приклад:

Larger Work
   |
   +--> MPL files
   +--> proprietary files
   +--> MIT files
   +--> Apache files

Це одна з ключових причин, чому MPL зручна для змішаних codebase.

11. Source code requirement

Якщо ви поширюєте binary, який містить MPL-covered files, потрібно забезпечити доступ до source code цих MPL-covered files.

Але не обов'язково відкривати весь інший код Larger Work.

Простими словами:

Відкрий MPL-файли та їхні зміни.
Інші незалежні файли можуть залишатися закритими.

12. Цікавий факт: MPL працює як “скляна коробка” для окремих файлів

GPL часто сприймають як сильний магніт для всього похідного продукту.

MIT — як майже повну свободу без copyleft.

MPL — інша:

Кожен MPL-файл ніби має прозоре скло.
Його зміни мають бути видимі.
Але сусідні файли не обов'язково відкривати.

Це дуже зручна модель для великих mixed-source проєктів.

13. Patent grant

MPL 2.0 містить patent grant.

Це означає, що contributors надають певну patent license на свої contributions у межах ліцензії.

Офіційний текст MPL 2.0 містить як copyright grant, так і patent grant, але також визначає обмеження scope patent license. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/?utm_source=chatgpt.com))

14. Patent termination

Як і багато сучасних ліцензій, MPL 2.0 містить patent-related захист.

Ідея:

Якщо хтось використовує патенти агресивно проти covered software,
його patent rights за ліцензією можуть бути обмежені або припинені.

Це допомагає зменшити ризик, що contributors дадуть код, а потім використають патенти проти користувачів.

15. MPL і trademarks

MPL не дає автоматичного права використовувати trademarks.

Це означає:

• код можна використовувати;
• MPL-файли можна змінювати;
• можна створити fork;
• але не можна без дозволу використовувати назви, логотипи або бренди так, ніби ваш продукт офіційно підтриманий Mozilla або іншим правовласником.

Це важлива різниця між правами на код і правами на бренд.

16. Disclaimer of warranty

MPL, як і більшість open source-ліцензій, містить відмову від гарантій.

Простими словами:

Код надається “як є”.
Автори не обіцяють, що він без помилок,
підходить для вашої задачі
або не спричинить проблем.

Це стандартний захист для open source contributors.

17. MPL і комерційне використання

MPL дозволяє комерційне використання.

Можна:

• використовувати MPL-код у платному продукті;
• продавати програму;
• використовувати MPL-компоненти в SaaS;
• включати MPL-файли в proprietary проєкт;
• поширювати binary;
• вести комерційну розробку навколо MPL-коду.

Але MPL-covered files і їхні зміни мають залишатися доступними під MPL при поширенні.

18. MPL і proprietary software

MPL дозволяє proprietary software використовувати MPL-код.

Приклад:

proprietary_app/
  main.cpp              ← proprietary
  ui.cpp                ← proprietary
  mozilla_component.cpp ← MPL

У такому випадку:

• `main.cpp` може залишатися закритим;
• `ui.cpp` може залишатися закритим;
• `mozilla_component.cpp` і його зміни мають бути під MPL;
• потрібно надати source code MPL-covered file.

19. MPL і SaaS

MPL не є network copyleft-ліцензією.

Якщо MPL-код використовується лише на сервері як SaaS і не поширюється користувачам у вигляді binary або source distribution, вимога надавати source code може не активуватися так само, як при розповсюдженні.

Цим MPL відрізняється від AGPL, яка спеціально має network copyleft-механізм.

20. MPL і GPL-сумісність

MPL 2.0 за замовчуванням сумісна з GPL-сімейством через механізм Secondary Licenses.

Mozilla FAQ пояснює, що MPL 2.0 сумісна з GPL, LGPL і AGPL, якщо код не позначений як “Incompatible With Secondary Licenses”. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/FAQ/?utm_source=chatgpt.com))

Комбінація	Сумісність	Пояснення
MPL 2.0 + GPLv2 or later	Так, за замовчуванням	Через Secondary Licenses, якщо не заборонено.
MPL 2.0 + GPLv3	Так, за замовчуванням	Можна комбінувати з GPL-проєктами.
MPL 2.0 + LGPL	Так, за замовчуванням	За умови, що немає позначки incompatibility.
MPL 2.0 + AGPL	Так, за замовчуванням	За умови, що не вказано Incompatible With Secondary Licenses.

21. Incompatible With Secondary Licenses

Автор MPL-коду може заборонити GPL-сумісність через позначку:

Incompatible With Secondary Licenses

Якщо така позначка є, код не можна автоматично relicensing-увати під GPL/LGPL/AGPL через Secondary Licenses.

Це важлива деталь для compliance.

22. Цікавий факт: MPL 2.0 стала дружнішою до GPL, ніж MPL 1.1

MPL 1.1 мала складнішу сумісність із GPL.

MPL 2.0 значно спростила це питання.

Саме тому MPL 2.0 часто вважають практичнішою й сучаснішою версією.

Revision FAQ Mozilla згадує compatibility with Apache and GPL як одну з важливих тем змін у MPL 2.0. ([mozilla.org](https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/?utm_source=chatgpt.com))

23. MPL 1.1 і MPL 2.0

Критерій	MPL 1.1	MPL 2.0
Сучасність	Старіша	Актуальніша
GPL-сумісність	Складніша	Значно краща за замовчуванням
Текст	Довший і складніший	Спрощений
Patent language	Менш сучасний	Оновлений
Рекомендованість для нових проєктів	Зазвичай ні	Так

24. MPL і LGPL

Критерій	MPL	LGPL
Тип copyleft	File-level copyleft	Library / linking-oriented weak copyleft
Основна межа	Файл	Бібліотека й linking
Proprietary integration	Дозволена	Дозволена за умовами LGPL
Static linking	Не центральне питання	Важливе compliance-питання
Найкращий сценарій	Mixed-license codebase, окремі файли	Бібліотеки

25. MPL і GPL

Критерій	MPL	GPL
Copyleft	Слабкий, file-level	Сильний
Proprietary files поруч	Можливі	Зазвичай проблемно при derivative work
Відкривати весь продукт	Ні	Часто так при distribution derivative work
Відкривати змінені licensed-файли	Так	Так, і ширше
Філософія	Баланс між відкритістю й інтеграцією	Максимальний захист свободи похідного ПЗ

26. MPL і MIT License

Критерій	MPL	MIT
Тип	Weak copyleft	Permissive
Зміни licensed-коду	Мають залишатися відкритими під MPL	Можуть бути закриті
Proprietary use	Так	Так
Простота	Складніша	Дуже проста
File-level rules	Так	Ні
Найкраще для	Компонентів, де важливо зберегти відкритість файлів	Максимально простого повторного використання

27. MPL і Apache License 2.0

Критерій	MPL	Apache License 2.0
Тип	Weak copyleft	Permissive
Patent grant	Так	Так
Зміни licensed-коду	Мають залишатися відкритими під MPL	Можуть бути закриті
NOTICE	MPL має власні notice-вимоги	Apache має NOTICE-файл, якщо він є
Proprietary use	Так	Так
Основна різниця	MPL захищає MPL-файли	Apache майже не обмежує похідні зміни, але має patent grant

28. MPL і BSD License

Критерій	MPL	BSD
Тип	Weak copyleft	Permissive
Зміни licensed-файлів	Мають залишатися відкритими	Можуть бути закриті
Комерційне використання	Так	Так
Attribution	Так	Так
Складність	Вища	Нижча

29. Коли варто обрати MPL

MPL доцільно обрати, якщо:

• ви хочете weak copyleft;
• хочете захистити відкритість конкретних файлів;
• не хочете змушувати весь проєкт бути open source;
• проєкт може використовуватися в proprietary software;
• потрібен баланс між GPL і MIT;
• ви пишете компонент, який може жити в mixed-license codebase;
• хочете modern license з patent language;
• важлива GPL-сумісність через Secondary Licenses.

30. Коли MPL може бути не найкращим вибором

MPL може бути не найкращим варіантом, якщо:

• ви хочете максимально просту ліцензію — тоді MIT або BSD;
• ви хочете strong copyleft — тоді GPL;
• ви хочете network copyleft — тоді AGPL;
• ви пишете бібліотеку й хочете linking-oriented модель — тоді LGPL;
• ви не хочете, щоб proprietary software використовував ваш код;
• ваша аудиторія не хоче працювати з copyleft навіть на рівні файлів;
• вам потрібна повністю permissive enterprise-ліцензія — тоді Apache 2.0 може бути простішим вибором.

31. Переваги MPL

Перевага	Опис
File-level copyleft	Захищає відкритість конкретних файлів, але не всього проєкту.
Proprietary-friendly	Дозволяє використання поруч із закритим кодом.
Баланс	Посередині між MIT/Apache і GPL.
Patent grant	Містить patent-related положення.
GPL-сумісність	MPL 2.0 за замовчуванням сумісна з GPL-сімейством.
Добра для mixed codebases	Підходить для великих проєктів із різними ліцензіями.
Чітка межа	Copyleft-межа зрозуміла: файл.

32. Недоліки MPL

Недолік	Опис
Складніша за MIT/BSD	Потрібно розуміти file-level obligations.
Не strong copyleft	Proprietary-код поруч може залишатися закритим.
Потрібен compliance	Треба відстежувати MPL-covered files і їхні зміни.
Може бути незвичною	Багато розробників краще знають MIT, Apache або GPL.
Не завжди ідеальна для бібліотек	Для linking-сценаріїв LGPL може бути природнішою.
Secondary Licenses треба перевіряти	Позначка Incompatible With Secondary Licenses змінює сумісність.

33. Типові помилки новачків

Помилка	Чому виникає	Як правильно думати
“MPL = GPL”	Обидві copyleft.	MPL слабша й працює на рівні файлів.
“MPL = MIT”	Обидві дозволяють комерційне використання.	MPL вимагає відкривати змінені MPL-файли.
“Треба відкривати весь продукт”	Плутають із strong copyleft.	Зазвичай відкриваються MPL-covered files, не весь Larger Work.
“Можна закрити змінений MPL-файл”	Неправильне розуміння copyleft.	Змінений MPL-файл має залишатися під MPL.
“GPL-сумісність завжди автоматична”	Є нюанс Secondary Licenses.	Перевіряти, чи немає Incompatible With Secondary Licenses.
“MPL не має patent clauses”	Плутають із короткими permissive-ліцензіями.	MPL 2.0 має patent grant і patent-related rules.

34. Приклад використання MPL у proprietary продукті

Уявімо продукт:

app/
  main.cpp          ← proprietary
  payments.cpp      ← proprietary
  renderer.cpp      ← MPL
  renderer.h        ← MPL

Компанія змінює `renderer.cpp`.

Тоді:

• `main.cpp` може залишатися proprietary;
• `payments.cpp` може залишатися proprietary;
• `renderer.cpp` має бути доступний під MPL;
• `renderer.h`, якщо він MPL-covered і змінений, теж має виконувати MPL-вимоги;
• потрібно зберегти notices і текст ліцензії.

35. Приклад із окремими файлами

Якщо до MPL-проєкту додати новий файл:

new_feature.cpp

і цей файл не містить MPL-коду, його можна ліцензувати інакше.

Але якщо скопіювати значні частини MPL-коду в `new_feature.cpp`, файл може стати MPL-covered.

Тобто важлива не лише назва файлу, а й те, чи містить він MPL-covered code.

36. MPL у package metadata

SPDX identifier:

MPL-2.0

Приклад у package metadata:

{
  "license": "MPL-2.0"
}

Приклад у source-файлі:

SPDX-License-Identifier: MPL-2.0

37. Як додати MPL 2.0 до проєкту

Типовий процес:

1. Додати файл LICENSE з повним текстом MPL 2.0.
2. Додати license header або SPDX identifier до MPL-covered файлів.
3. Вказати ліцензію в README.
4. Вказати ліцензію в package metadata.
5. Якщо потрібно — позначити Incompatible With Secondary Licenses.
6. Документувати third-party dependencies.
7. Вести облік файлів, які є MPL-covered.

38. Compliance checklist

Для MPL compliance варто перевірити:

1. Які файли під MPL?
2. Чи змінювалися MPL-covered files?
3. Чи поширюється binary?
4. Чи доступний source code MPL-covered files?
5. Чи збережені copyright notices?
6. Чи включено текст MPL?
7. Чи є Incompatible With Secondary Licenses?
8. Чи поєднується код із GPL/LGPL/AGPL?
9. Чи немає додаткових обмежень на MPL-covered source?
10. Чи коректно описані third-party components?

39. Цікавий факт: MPL зручна для великих проєктів із різними частинами

У великому продукті можуть бути:

• open source core;
• proprietary UI;
• third-party modules;
• plugins;
• commercial extensions;
• experimental files;
• GPL-compatible components;
• Apache/MIT dependencies.

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

Вона каже:

MPL-файли — під MPL.
Інші файли — можуть мати інший режим.

40. MPL і forks

MPL дозволяє створювати forks.

Можна:

• копіювати MPL-код;
• змінювати MPL-файли;
• поширювати modified versions;
• включати MPL-файли в більші проєкти;
• створювати commercial products.

Але:

• змінені MPL-файли мають залишатися під MPL;
• source code цих файлів має бути доступний;
• notices мають зберігатися;
• trademarks не можна використовувати без окремого права.

41. MPL і contributors

Для contributors MPL означає:

• їхній внесок у MPL-covered file буде під MPL;
• інші можуть використовувати цей файл у larger works;
• зміни цього файлу мають залишатися відкритими;
• проєкт може бути поєднаний із proprietary code;
• patent grant може застосовуватися до contribution.

У великих проєктах додатково можуть бути:

• contribution guidelines;
• Developer Certificate of Origin;
• Contributor License Agreement;
• code review policy;
• license headers.

42. MPL і документація

MPL призначена переважно для software.

Для документації часто використовують інші ліцензії:

• Creative Commons Attribution;
• Creative Commons Attribution-ShareAlike;
• GNU Free Documentation License;
• project-specific documentation license.

Але технічно деякі проєкти можуть використовувати MPL для source-like documentation або прикладів коду.

43. Юридичне застереження

Ця стаття пояснює MPL простими словами, але не є юридичною консультацією.

Для важливих комерційних, patent, compliance, redistribution або mixed-license-рішень краще звернутися до юриста або фахівця з open source compliance.

44. Людське пояснення: чим є MPL

MPL — це ліцензія для людей, які хочуть баланс.

Вона не така сувора, як GPL:

“Відкрий увесь похідний продукт”.

І не така вільна, як MIT:

“Бери й можеш закрити майже все”.

MPL каже:

“Файли, які я відкрила, нехай залишаються відкритими.
Але навколо них можна будувати різні системи —
від open source до commercial”.

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

45. Цікаві факти

Факт	Пояснення
MPL має file-level copyleft	Copyleft працює на рівні файлів, а не всього проєкту.
MPL 2.0 вийшла у 2012 році	Це сучасна версія ліцензії, яка замінила старіші MPL 1.x.
MPL 2.0 за замовчуванням GPL-compatible	Якщо не вказано Incompatible With Secondary Licenses.
MPL дозволяє proprietary files поруч	Інші файли larger work можуть бути закритими.
Змінені MPL-файли треба відкривати	Це головний copyleft-обов'язок MPL.
MPL має patent grant	Це робить її сучаснішою й кориснішою для великих проєктів.
MPL — середина між MIT і GPL	Вона не повністю permissive, але й не strong copyleft.
MPL добре підходить для mixed-license codebases	Особливо там, де є open source core і комерційні компоненти.

46. Безпека і відповідальність

Ліцензія не гарантує безпеку коду.

MPL-код може бути:

• якісним;
• застарілим;
• вразливим;
• погано підтримуваним;
• неправильно інтегрованим;
• несумісним із вашим deployment.

Перед використанням важливо:

• перевірити стан проєкту;
• читати security advisories;
• оновлювати dependencies;
• виконувати license compliance;
• перевіряти patent і license compatibility;
• робити code review;
• тестувати код у своєму середовищі.

47. Висновок

Mozilla Public License — це weak copyleft open source-ліцензія, найвідоміша своєю file-level copyleft-моделлю.

Її головні переваги:

• захищає відкритість MPL-файлів;
• не змушує відкривати весь продукт;
• дозволяє proprietary integration;
• підходить для mixed-license codebase;
• має patent grant;
• MPL 2.0 сумісна з GPL-сімейством за замовчуванням;
• є хорошим компромісом між MIT/Apache і GPL.

Головні обмеження:

• складніша за permissive-ліцензії;
• потребує відстеження MPL-covered files;
• змінені MPL-файли треба відкривати;
• не strong copyleft;
• Secondary Licenses треба перевіряти;
• не така універсально знайома, як MIT або GPL.

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

48. Джерела

• 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

49. Див. також

Mozilla Public License MPL MPL 2.0 Mozilla Mozilla Foundation Open source Free software Copyleft Weak copyleft File-level copyleft GPL LGPL AGPL MIT License BSD License Apache License 2.0 SPDX Patent grant Software license Open source compliance