Разработчик использовал open-source библиотеку в платном продукте. Может ли лицензия обязать раскрыть код?

Обязанность раскрывать исходный код определяется не словом open source, а точным текстом лицензии, версией компонента и способом его объединения и распространения. Сильный copyleft может распространять условия на производную работу, а permissive-лицензии обычно требуют сохранения уведомлений и текста лицензии.

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

Для GPL и родственных copyleft-лицензий нужно оценить, является ли продукт производной или объединённой работой, предоставляется ли объект пользователям и выполнены ли требования к исходникам, уведомлениям и той же лицензии. LGPL, AGPL и специальные исключения имеют отдельные условия. MIT, BSD и Apache 2.0 обычно не требуют открывать собственный код, но требуют сохранить уведомления; Apache также содержит патентные положения. SaaS не всегда исключает copyleft-риск: например, сетевое использование значимо для AGPL.

Если лицензия несовместима с моделью продукта, варианты — заменить компонент, изменить архитектуру, получить коммерческую лицензию или раскрыть требуемую часть. Нельзя удалять copyright-файлы или полагаться на вывод разработчика без сохранённой версии лицензии.

Что делать по шагам

1. Собрать software bill of materials

Зафиксируйте все прямые и транзитивные зависимости, версии и источники.

2. Привязать точный текст лицензии

Сохраните LICENSE/NOTICE для использованной версии и проверьте двойное лицензирование.

3. Классифицировать способ использования

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

4. Сопоставить обязательства с релизом

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

5. Устранить несовместимость до выпуска

Замените библиотеку, разделите компонент, получите коммерческую лицензию или выполните раскрытие.

Какие документы и доказательства собрать

Риски, сроки и исключения

Название без версии

Условия проекта могут меняться между релизами.

Транзитивная зависимость

Критичная лицензия может находиться не в прямом компоненте.

SaaS как ложная безопасность

Сетевой copyleft и передача клиентского компонента требуют отдельной проверки.

Удалённые уведомления

Даже permissive-лицензия обычно требует сохранить атрибуцию.

Когда общего ответа недостаточно

Нужен специализированный аудит перед коммерческим релизом, M&A, закрытием исходного кода, поставкой ПО заказчику или получением претензии правообладателя open-source проекта.

Связанные материалы

• Пришла претензия от Copydefend за фотографию. Что делать? — https://oreshkin-urist.ru/vopros-otvet/prishla-pretenziya-copydefend-fotografiyu-delat/

• Сотрудник написал программу в рабочее время. Что оформить, чтобы права принадлежали компании? — https://oreshkin-urist.ru/vopros-otvet/sotrudnik-napisal-programmu-rabochee-vremya-oformit-chtoby/

• Защита интеллектуальных прав — https://oreshkin-urist.ru/uslugi/intellektualnaya-sobstvennost/

О правовой оценке

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