📜 Классификация лицензий и как с ними работать

Все лицензии открытого ПО делятся на две основные категории: пермиссивные и копилефтные. Ваш выбор определяет, насколько свободно другие смогут использовать ваш код, в том числе в коммерческих проприетарных продуктах.

Вот сравнение основных лицензий для наглядности:

Тип лицензии	Примеры	Ключевые условия	Что можно делать?	Что нельзя? / Условия
Пермиссивные	MIT, BSD, Apache 2.0	Минимальные ограничения. Сохранить уведомление об авторских правах и текст лицензии.	Использовать в закрытом ПО, изменять, распространять, продавать.	Нарушать условие о сохранении копирайта и лицензии.
Слабый копилефт	LGPL, MPL	Изменения в самом лицензированном файле должны оставаться открытыми.	Связывать библиотеку с проприетарным кодом без "заражения".	Распространять изменения в исходной библиотеке под закрытой лицензией.
Строгий копилефт	GPL	Любая производная работа должна распространяться на тех же условиях (вирусный эффект).	Использовать, изменять, распространять только если весь продукт становится GPL.	Включать код в проприетарное ПО без открытия исходного кода всего продукта.

⚠️ Основные риски использования Open Source зависимостей

1. Лицензионно-юридические риски (Самые критичные)

• Риск "заражения" (Copyleft): Самый опасный риск. Если вы используете код под строгой лицензией (GPL), вы можете быть юридически обязаны открыть исходный код всего вашего проприетарного продукта, в который встроена эта библиотека.
  • Пример: Ваша компания разрабатывает платное ПО для автоматизации бизнеса. Один из разработчиков для удобства добавил в проект библиотеку под лицензией GPL v3. При распространении вашего продукта вы нарушаете лицензию, не открывая свой код. Правообладатель может подать на вас в суд.
• Риск несовместимости лицензий: В проекте могут использоваться библиотеки с лицензиями, которые конфликтуют друг с другом. Вы не можете легально использовать их вместе.
  • Пример: Вы не можете совместить в одном продукте код под лицензией GPL ("вы должны открыть весь код") и код под лицензией Apache 2.0, который запрещает такие условия. Это юридический тупик.
• Риск несоблюдения условий атрибуции (Permissive): Даже у "безопасных" лицензий (MIT, Apache 2.0) есть условия. Обычно это требование включить текст лицензии и уведомление об авторских правах в вашу документацию или интерфейс программы. Несоблюдение — это нарушение лицензии.

2. Риски цепочки поставок (Supply Chain)

• Риск транзитивных зависимостей: Ваша прямая зависимость Библиотека А (с лицензией MIT) сама зависит от Библиотеки Б (с лицензией GPL). Вы можете не знать о Библиотеке Б, но становитесь нарушителем GPL.
  • Пример (из реальной практики): В 2018 году компания Artifex Software подала иск против Hancom (корейский производитель офисного ПО) за использование библиотеки Ghostscript. Hancom утверждал, что не использовал её напрямую, но она была частью цепочки зависимостей. Суд встал на сторону Artifex.
• Риск подмены пакета (Dependency Confusion): Злоумышленник публикует в публичный реестр (например, npm, PyPI) пакет с именем, идентичным вашему приватному внутреннему пакету, но с более высокой версией. Система сборки может автоматически подтянуть вредоносный публичный пакет вместо вашего.

3. Операционные и технические риски

• Риск уязвимостей: Открытый код — мишень для хакеров. Если вы не обновляете зависимости, вы используете код с известными уязвимостями.
  • Пример: Уязвимость Log4Shell в библиотеке Log4j в 2021 году затронула почти все компании мира, потому что эта библиотека использовалась в тысячах продуктов через транзитивные зависимости.
• Риск "заброшенного" ПО (Abandoned Software): Автор перестал поддерживать библиотеку. В ней не фиксятся баги и уязвимости, что создаёт технический долг и угрозу безопасности.

🛠️ Риски доработки Open Source (форки, контрибьюты)

Когда вы решаете не просто использовать, а изменять open source, риски усиливаются.

Способ доработки	Потенциальные риски	Пример
Форк и внутренняя доработка	Обязательство открыть код доработок (для Copyleft). Если вы делаете форк GPL-библиотеки, модифицируете её и используете в своём продукте, вы обязаны опубликовать исходный код своих модификаций.	Ваша компания форкает GPL-библиотеку для работы с графикой, исправляя в ней баги под свои нужды. Теперь вы должны выложить эти исправления в открытый доступ, иначе нарушаете лицензию.
Публикация модифицированной версии	Неправильное лицензирование. Вы публикуете свой форк под неправильной лицензией, которая не совместима с оригиналом. Например, попытка сменить лицензию GPL на MIT. Это запрещено.	Вы не можете взять форк проекта Linux (GPL) и перелицензировать его под проприетарной лицензией. Это прямое нарушение.
Контрибьют в чужой репозиторий	Передача прав. Когда вы отправляете Pull Request, многие крупные проекты требуют подписать CLA (Contributor License Agreement). Это соглашение, по которому вы передаёте права на свой код владельцам проекта. Они смогут использовать его как угодно, в том числе под другой лицензией.	Контрибьютя в Google, Microsoft или Apache Foundation, вы подписываете CLA. Ваш код становится частью их проекта, и вы не можете предъявить на него исключительные права в будущем.