Open source не означает «можно использовать без ограничений»: каждая библиотека, фреймворк или другой компонент имеет лицензию с конкретными условиями. Наибольшие риски для бизнеса связаны с GPL и AGPL, транзитивными зависимостями, изменением лицензий между версиями и кодом из внешних источников. Чтобы избежать претензий, раскрытия собственного кода и проблем во время due diligence, компаниям стоит регулярно проверять зависимости и выстраивать базовый IP-комплаенс.Итак, Open source в бизнесе: как работать с лицензиями без юридических рисков - далее в нашей статье
Среднее современное приложение состоит из собственного кода процентов на десять-двадцать. Остальное — библиотеки, фреймворки, утилиты, подтянутые менеджером пакетов вместе с транзитивными зависимостями. У каждой из них есть лицензия, и ни одна из этих лицензий не означает «делайте что хотите».
Open source — это не отсутствие прав, а специфический способ их реализации. Автор сохраняет авторское право и разрешает использование на определённых условиях. Нарушил условия — остался без разрешения, то есть в положении обычного нарушителя авторского права.
Три группы лицензий
Пермиссивные — MIT, BSD, Apache 2.0. Требуют сохранять уведомление об авторстве и текст лицензии; Apache 2.0 дополнительно содержит патентную оговорку и требование отмечать изменения. Коммерческое использование, в том числе в закрытом продукте, разрешено. Это самая безопасная категория, но даже здесь забытый NOTICE-файл является формальным нарушением.
Копилефт — GPL разных версий. Если вы распространяете продукт, который содержит GPL-компонент и образует с ним производное произведение, весь такой продукт должен распространяться на условиях GPL с раскрытием исходного кода. Для компании, чья ценность — в собственном алгоритме, это фактически требование опубликовать коммерческую тайну. LGPL смягчает правило для динамического линкования, но граница между «использованием» и «производным произведением» — вопрос, который лучше решать до релиза, а не после.
Сетевой копилефт — AGPL. Самая опасная лицензия для SaaS. Классическая GPL привязывает обязательства к распространению копии, поэтому облачный сервис формально ничего не распространял. AGPL закрывает этот пробел: предоставление пользователям доступа через сеть приравнивается к распространению. Многие популярные базы данных и платформы в своё время перешли на AGPL именно по этой причине.
Где компании чаще всего «попадают»
- Транзитивные зависимости. Проверили лицензию библиотеки, но не десяти её зависимостей. Одна из них — GPL.
- Смена лицензии между версиями. Проект, который когда-то был под Apache 2.0, в новой мажорной версии перешёл на BSL или AGPL. Обновление подтянулось автоматически.
- Двойное лицензирование. Компонент доступен под GPL бесплатно или под коммерческой лицензией за деньги. Использование «по умолчанию» означает GPL со всеми последствиями.
- Код с форумов и от AI-ассистентов. Фрагмент, скопированный со StackOverflow или сгенерированный на основе чужого репозитория, попадает в продукт без какой-либо лицензионной истории.
- Шрифты, иконки, стоковые изображения. Формально это не код, но механизм лицензирования тот же — и риск претензий такой же.
Последствия
Нарушение лицензии открывает правообладателю стандартный набор инструментов: требование прекратить использование, взыскание компенсации, а в случае копилефта — давление с целью раскрытия кода. Добавляются и практические последствия: срыв сделки на due diligence, требование инвестора провести полный remediation, блокировка приложения в App Store или Google Play по жалобе правообладателя.
Что выстроить внутри компании
Комплаенс здесь не требует большого бюджета, нужна лишь системность. Минимум: реестр всех зависимостей с лицензиями, автоматизированный scan в CI-пайплайне, внутренний список запрещённых и разрешённых лицензий, правило согласования новых компонентов, генерация NOTICE-файла во время сборки, а также политика в отношении кода из внешних источников и AI-инструментов. Эти процессы и составляют ядро того, что называют IP-комплаенсом для бизнеса.
Проверять всё это стоит регулярно — при изменении состава команды, перед мажорными релизами и перед любой сделкой. Юристы IP EYE проводят такие аудиты вместе с техническими командами, потому что оценка «является ли это производным произведением или нет» одновременно находится и в правовой, и в архитектурной плоскости.
Самый короткий вывод: бесплатный компонент — не то же самое, что компонент без условий. Условия есть всегда, вопрос лишь в том, прочитал ли их кто-то в команде.
Ответы на популярные вопросы
Можно ли безопасно использовать open source в коммерческом продукте?
Да, но только с соблюдением условий конкретной лицензии. Даже бесплатная библиотека может требовать сохранения текста лицензии, указания авторства, публикации изменений или открытия исходного кода.
Какие open source лицензии наименее рискованные для бизнеса?
К наиболее удобным для коммерческих продуктов относятся MIT, BSD и Apache 2.0. Они позволяют использовать компоненты в закрытом программном обеспечении, но установленные ими требования по авторству, лицензионным уведомлениям и другим условиям все равно нужно выполнять.
Почему GPL может создать проблему для закрытого программного продукта?
Если GPL-компонент становится частью производного произведения, при его распространении могут возникнуть обязательства распространять весь соответствующий продукт на условиях GPL и предоставить исходный код. Для компании с собственными закрытыми разработками это может быть критично.
Чем AGPL отличается от обычной GPL?
AGPL распространяет требования копилефта и на программное обеспечение, доступное пользователям через сеть. Поэтому эта лицензия особенно важна для SaaS-проектов, даже если компания не передает пользователям копию программы.
Почему нужно проверять не только основные библиотеки, но и их зависимости?
Одна библиотека может подтягивать десятки других пакетов с собственными лицензиями. Среди транзитивных зависимостей иногда попадаются GPL, AGPL или компоненты с другими условиями, о которых команда даже не подозревает.
Может ли лицензия библиотеки измениться после обновления?
Да. Разработчики могут выпустить новую версию проекта уже под другой лицензией, поэтому автоматическое обновление зависимостей иногда меняет и юридические условия использования компонента.
Что означает двойное лицензирование open source продукта?
Один и тот же компонент может предлагаться, например, бесплатно по GPL и отдельно по платной коммерческой лицензии. Если компании не подходят требования GPL, она может приобрести коммерческую лицензию с другими условиями.
Есть ли риск в коде из StackOverflow или AI-ассистентов?
Да, если команда не знает происхождения фрагмента и условий, на которых его можно использовать. Для такого кода стоит иметь отдельные внутренние правила проверки, особенно если он попадает в коммерческий продукт.
Что может произойти из-за нарушения open source лицензии?
Правообладатель может требовать прекратить использование компонента, устранить нарушение или выплатить компенсацию. Проблемная зависимость также может усложнить инвестиционную сделку, due diligence или размещение приложения в магазинах.
Как организовать контроль open source лицензий в компании?
Полезно вести реестр зависимостей и их лицензий, автоматически проверять пакеты в CI, определить допустимые и запрещенные лицензии и контролировать добавление новых компонентов. NOTICE-файлы и другие необходимые уведомления лучше формировать автоматически во время сборки.
Когда стоит проводить аудит open source компонентов?
Проверку стоит делать регулярно, а особенно перед большими релизами, инвестициями, продажей компании или другими сделками. Чем раньше выявлена проблемная зависимость, тем проще заменить ее или урегулировать лицензионные условия.
