Разработчик добавил в коммерческий продукт библиотеку под GPL. Команда обнаружила это перед передачей продукта клиенту. Продавать продукт можно: GPL не запрещает коммерческое использование. Но до поставки нужно выяснить, как библиотека включена в продукт, что именно получит клиент и какие обязанности возникают по лицензии.
Свободное ПО не означает бесхозный код. У программы есть правообладатель, который разрешает определённые действия на своих условиях. Для компании важно понимать, какие условия связаны с копированием, изменением и распространением программы.
Миф: свободное ПО нельзя использовать ради прибыли
Свободные лицензии обычно позволяют использовать программу в бизнесе, дорабатывать её и предлагать клиентам продукты или услуги на её основе. Плату можно брать за разработку, поддержку, размещение сервиса, а в ряде случаев — и за экземпляры программы. «Свободное» здесь описывает права пользователя, а не цену.
Коммерческое использование, однако, не снимает лицензионных обязанностей. При передаче программы клиенту может потребоваться приложить текст лицензии, сохранить сведения об авторстве или предоставить исходный код в предусмотренном объёме. Что именно потребуется, зависит от компонента, версии лицензии и способа использования.
Миф: открытый код можно взять без проверки
Код в публичном репозитории не обязательно разрешено копировать в продукт. Если условия использования не указаны, публикацию нельзя автоматически считать свободной лицензией. Проверьте файл лицензии, сведения в пакетном менеджере, уведомления в исходниках и документацию проекта. Если они противоречат друг другу, выясните происхождение нужных файлов, а не выбирайте наиболее удобную формулировку.
Отдельно проверьте содержимое репозитория. Для примеров, шрифтов, изображений, тестовых данных и фрагментов стороннего кода могут действовать иные условия, чем для самой программы.
Миф: все свободные лицензии требуют открыть свой продукт
Разрешительные лицензии, например MIT и BSD, обычно допускают включение кода в закрытый продукт, если сохранить предусмотренные уведомления и текст лицензии. В Apache License 2.0 тоже есть требования к уведомлениям, а также отдельные положения о патентных правах. То, что клиент не видит обязательную информацию в интерфейсе, не означает, что её можно удалить.
У лицензий с копилефтом другие правила распространения производных работ. В определённых обстоятельствах GPL требует предоставить соответствующий исходный код и распространять охватываемую работу на условиях GPL. У LGPL есть отдельные правила для библиотек: их применение зависит, в частности, от способа связывания и возможности заменить библиотеку. MPL обычно регулирует изменения на уровне охватываемых файлов. AGPL содержит особое условие для случаев, когда доступ к программе предоставляется по сети.
По одному названию лицензии нельзя определить, затронет ли она собственный код компании. Важно установить, скопирован ли компонент или используется без изменений, какие файлы модифицированы, как взаимодействуют модули и что получает клиент. Спорные варианты интеграции нужно оценивать по тексту конкретной лицензии, а не по общему ярлыку «копилефт».
Распространение и работа через сеть — разные ситуации
Если программа работает только на серверах компании, а пользователи обращаются к ней через браузер, это не всегда означает передачу им экземпляра ПО. Но сервисная модель не освобождает от всех условий: AGPL предусматривает специальные обязанности для определённых модифицированных версий, доступных пользователям по сети. При поставке клиенту приложения, устройства или контейнерного образа оценка может быть иной — нужно смотреть на состав передаваемого пакета.
Миф: достаточно проверить только прямые зависимости
Библиотека, которую команда добавила в продукт, может подтягивать десятки других пакетов. При обновлении меняются их версии, а иногда и лицензии. Поэтому проверять нужно фактический состав сборки, а не только список компонентов, добавленных разработчиками вручную.
Перед релизом стоит:
- Составить перечень компонентов и версий. Включить прямые и транзитивные зависимости, а также файлы, которые войдут в поставку.
- Зафиксировать источники условий. Сохранить тексты применимых лицензий и уведомления для используемых версий.
- Описать использование. Отметить, что изменили, что передадите клиенту, а что останется на сервере.
- Подготовить материалы для поставки. Проверить, нужны ли уведомления, тексты лицензий, предложения предоставить исходный код и сам исходный код.
- Повторять проверку после изменений. Новая зависимость или другой способ доставки могут изменить лицензионные обязанности.
Автоматический поиск лицензий помогает найти компоненты, но спорные результаты придётся разбирать вручную. Инструмент может пропустить лицензию отдельного файла или показать несколько вариантов для одного пакета. Лучше заранее назначить того, кто проверит такие случаи до выпуска, а не после запроса клиента.
Миф: свободная лицензия решает все вопросы с правами
Лицензия на код не обязательно разрешает использовать название и логотип проекта так, будто его авторы одобряют ваш продукт. Она также не всегда охватывает документацию, изображения, шрифты и обучающие материалы — для них могут действовать отдельные условия.
Не забудьте о договоре с заказчиком. Он может ограничивать использование отдельных лицензий, требовать перечень сторонних компонентов или определять порядок передачи исходников. Эти обязательства существуют независимо от лицензии открытого проекта. Если заказчик ожидает исключительные права на весь результат, заранее разграничьте собственные разработки и компоненты, на которые у компании есть лишь лицензия.
Открытый код не гарантирует безопасность, постоянную поддержку или пригодность для вашей задачи. Уязвимости и прекращение обновлений стоит оценивать вместе с правовыми рисками. А оговорки об отсутствии гарантий в свободной лицензии не отменяют обязательств, которые компания сама приняла перед клиентом.
Что делать, если компонент обнаружили перед поставкой
Не спешите удалять библиотеку или обещать клиенту открыть весь продукт. Сначала зафиксируйте точную версию компонента, его лицензию, внесённые изменения и способ интеграции. Затем сопоставьте лицензионные требования с составом поставки. В зависимости от обстоятельств можно выполнить условия лицензии, изменить архитектуру, заменить компонент либо договориться с правообладателем об иных правах, если он готов их предоставить. При выборе учитывайте и договор с клиентом.
Сохраните вместе с релизом перечень компонентов, тексты их лицензий и запись о том, какие уведомления и исходные файлы передали клиенту. Это поможет восстановить состав поставки, если позже возникнут вопросы. Материал не заменяет индивидуальную юридическую консультацию: оценка конкретного случая зависит от применимого права, текста лицензии и устройства продукта.