Современное программное обеспечение (ПО) почти никогда не пишется с нуля. В проект попадают библиотеки, фреймворки, готовые модули, фрагменты кода из публичных репозиториев и код, предложенный ИИ-ассистентами. Это экономит месяцы разработки, но добавляет новую задачу: понять, на каких условиях все эти компоненты вообще разрешено использовать.

По данным отчета Black Duck OSSRA 2026, проблемы с лицензией обнаружили в 68% исследованных коммерческих кодовых базах, переданных компании для аудита. Годом ранее таких было 56%. При этом только 54% организаций проверяют сгенерированный ИИ-код на риски, связанные с интеллектуальными правами и лицензиями.

Софт с открытым исходным кодом сам по себе не означает «берите и делайте что угодно». У открытого кода есть правообладатель, а право использовать его дает лицензия. Если ее условия не выполнить, бесплатный модуль может неожиданно превратиться в претензию, необходимость переделывать продукт или менять условия его распространения.

Разбираемся, чем отличаются открытые лицензии, где разработчика чаще всего поджидают ошибки и как проверить сторонний код до релиза.

Что такое открытый программный код

Софтом с открытым исходным кодом называют программное обеспечение, исходный код которого доступен для изучения, использования и изменения на условиях соответствующей лицензии.

Главное здесь именно последнее: открытый доступ к исходнику не отменяет авторских прав. В России программы для электронно-вычислительных машин (ЭВМ) охраняются авторским правом, а статья 1286.1 Гражданского кодекса Российской Федерации (далее ГК РФ) прямо предусматривает возможность предоставления произведений по открытой лицензии. Это лицензионный договор, условия которого заранее доступны неопределенному кругу пользователей.

Поэтому репозиторий на GitHub без лицензии и проект под лицензией MIT (разрешительная лицензия с минимальными ограничениями) юридически не одно и то же. Возможность увидеть или скачать код еще не означает разрешение встроить его в коммерческий продукт.

Открытые лицензии тоже отличаются друг от друга. Условно их можно расположить от более свободных к более требовательным.

MIT и BSD обычно позволяют использовать, изменять и распространять код в коммерческих продуктах, но требуют сохранить сведения об авторских правах и текст лицензии. Лицензия Apache 2.0 также предусматривает свои условия, в том числе связанные с уведомлениями и патентными правами.

GPL относится к лицензиям с более строгими условиями использования: при распространении на основе такого кода продукта могут возникнуть обязанности предоставить соответствующий исходный код и лицензировать производное ПО на совместимых условиях.

Поэтому при выборе библиотеки разработчику или ИТ-компании, которая его привлекает к разработке ПО, важно учитывать не только техническую совместимость кода, но и условия лицензии: разрешают ли они использовать и распространять его в рамках выбранной модели коммерциализации продукта.

Безопасно ли использовать чужой код с точки зрения авторского права

Если правообладатель разрешил использование в конкретном объеме и соблюдаются условия лицензии, то проблем скорее всего не будет. Опасная формула выглядит иначе: «код лежал в интернете, поэтому мы его взяли». Программы для ЭВМ в России охраняются авторским правом независимо от государственной регистрации, а воспроизведение и переработка программы относятся к способам ее использования.

Особенно легко потерять происхождение небольших фрагментов. Разработчик копирует решение из форума, берет несколько функций из чужого репозитория или использует код, сгенерированный ИИ-ассистентом, который также требует проверки на возможные совпадения со сторонним кодом и лицензионные ограничения. Через полгода этот код уже воспринимается командой как собственная часть проекта, а установить его источник и первоначальные условия использования сложно.

При этом размер фрагмента сам по себе не дает автоматического разрешения на использование. Если заимствованная часть охраняется авторским правом, аргумент «там всего двадцать строк» проблему не решает.

Еще одна ошибка — считать любую лицензию для софта с открытым кодом одинаково безопасной для закрытого коммерческого ПО. Например, наличие компонента, распространяемого по лицензии GPL, требует отдельного анализа того, как он связан с остальной программой и какие обязанности возникают при ее распространении.

Российское законодательство это тоже учитывает: правообладатель, предоставивший открытую лицензию, сохраняет авторские права и при нарушении условий ее использования может требовать применения предусмотренных законом способов защиты.

Как защититься от претензии за использование стороннего кода

Лучшее заранее выяснять происхождение библиотеки. Перед использованием стороннего компонента стоит установить его источник, правообладателя и конкретную версию лицензии. Если лицензия отсутствует или происхождение кода непонятно, для коммерческого проекта безопаснее не считать такой материал «свободным по умолчанию».

Отдельного внимания требуют зависимости. Один пакет может иметь десятки прямых и транзитивных зависимостей, каждая из которых может распространяться на условиях собственной лицензии. Именно поэтому современный контроль софта с открытым исходным кодом несколько усложняется.

Полезно вести перечень сторонних компонентов и их версий, сохранять тексты лицензий и сведения об авторах, а перед релизом проверять совместимость лицензий между собой и с моделью распространения собственного продукта.

Также важно контролировать и то, что происходит внутри команды. Если подрядчик приносит готовый модуль, договор с ним не превращает автоматически чужой открытый исходный код в собственность заказчика. Если сотрудник использовал библиотеку с несовместимыми условиями, проблема также переходит вместе с кодом в продукт компании.

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

Это особенно важно перед крупной сделкой, привлечением инвестиций или продажей ПО. Непонятное происхождение части кодовой базы может поставить под угрозу весь бизнес.

Юридический консалтинг n’RIS

Проверить лицензию одной библиотеки относительно просто. Сложнее, когда продукт собирался несколько лет, над ним работали сотрудники и подрядчики, а внутри уже находятся десятки или сотни сторонних компонентов.

В рамках юридического консалтинга n’RIS специалисты могут провести аудит прав на программный продукт, проверить используемые лицензии и цепочку перехода исключительных прав, оценить риски использования компонентов софта с открытым кодом и подготовить необходимые договоры и документы.

Такая проверка полезна не только после получения претензии. До релиза она помогает понять, можно ли распространять продукт на запланированных условиях и не возникнет ли обязанности раскрыть часть исходного кода или выполнить другие лицензионные требования.

Если претензия уже поступила, специалисты помогут оценить ее обоснованность, проверить происхождение спорного компонента, подготовить ответ и документы для досудебного урегулирования или судебного разбирательства.

Юридически чистая кодовая база важна и для дальнейшей работы с самим активом. Права на программное обеспечение можно оформить и учитывать как интеллектуальную собственность компании, а соответствующий установленным требованиям российский программный продукт включить в Реестр российского ПО и использовать доступные меры поддержки. Сейчас в реестре числится более 32 тыс. программ почти 12 тыс. правообладателей.

Софт с открытым исходным кодом и чужой код: как не получить претензию правообладателя

Что такое открытый программный код

Безопасно ли использовать чужой код с точки зрения авторского права

Как защититься от претензии за использование стороннего кода

Юридический консалтинг n’RIS