GPL разрешает использовать и изменять программный код, но при распространении продукта накладывает условия на производные работы. Для коммерческой компании в Беларуси главный риск возникает не при внутренней разработке, а при передаче программы клиенту, установке на его сервер или продаже устройства с включённым кодом. В статье разберём, какие компоненты можно объединять, когда нужно раскрывать исходники и как оформить проверку до релиза.
Что именно разрешает GPL?
GPL относится к свободным лицензиям с сильным требованием сохранять свободу производных работ. Обычно она разрешает запускать программу, изучать её код, изменять его и распространять копии. Коммерческое использование само по себе не запрещено: продукт можно продавать, включать поддержку в стоимость и заключать договор с заказчиком.
Ограничения появляются при распространении. Если компания передаёт клиенту программу с компонентом GPL, к этой передаче относятся условия соответствующей версии лицензии. Нужно сохранить уведомления об авторских правах и текст лицензии, а для производного кода предоставить исходный код на предусмотренных условиях.
Здесь важно разделить два сценария. Сотрудники используют библиотеку только внутри компании, и готовый продукт получает внешний клиент. Во втором случае появляется обязанность проверить состав поставки, способ связи компонентов и документы, которые сопровождают релиз.
Какие действия считают распространением?
Внутренний запуск приложения на компьютерах работников обычно отличается от передачи копии сторонней организации. Распространением может стать продажа установочного пакета, передача образа виртуальной машины, поставка оборудования с предустановленной программой или выдача клиенту доступа к копируемому компоненту.
Облачная модель требует отдельной проверки. Если код работает только на сервере поставщика, а клиент получает результат через интерфейс, юридическая оценка зависит от конкретной лицензии, архитектуры и условий договора. Для Affero GPL требования к сетевому доступу к исходному коду могут отличаться от обычной GPL, поэтому название лицензии нужно установить до проектирования интеграции.
Когда коммерческий продукт становится производной работой?
Один факт совместной поставки нескольких программ ещё не даёт готового ответа. Специалист смотрит на способ объединения: изменяли ли код GPL-компонента, включали ли его части в собственный модуль, собираются ли компоненты в единый исполняемый файл и как они взаимодействуют во время работы.
| Ситуация | Что проверить | Практический вывод |
|---|---|---|
| Программа используется внутри компании | Кто получает копию и где хранится код | Зафиксировать компонент в реестре и сохранить текст лицензии |
| Компания изменила GPL-библиотеку | Какие файлы менялись и входят ли они в поставку | Подготовить исходный код изменений и уведомления |
| GPL-компонент поставляется рядом с закрытым модулем | Как модули связаны и образуют ли единое произведение | Получить письменное заключение до релиза |
| Продукт передаётся клиенту вместе с установщиком | Состав архива и документы для пользователя | Добавить лицензии, уведомления и способ получить исходный код |
Самая частая ошибка возникает на границе между «используем библиотеку» и «распространяем готовый продукт». Разработчик видит только импорт пакета, а закупщик и руководитель не знают, что пакет попал в коммерческую поставку. Поэтому юридическую проверку проводят по фактическому артефакту релиза: архиву, контейнеру, установщику или образу устройства.
Как собрать реестр компонентов до выпуска?
Начните с перечня всех внешних пакетов. В таблицу внесите название компонента, версию, ссылку на исходный проект, текст лицензии, способ подключения и место использования. Отдельной строкой отметьте, меняла ли команда код и попадает ли компонент в поставку клиенту.
Одной записи «используется open source» недостаточно. Для GPL нужно указать конкретную версию лицензии: GPLv2 и GPLv3 содержат разные формулировки и не всегда совместимы с другими условиями. Если файл лицензии отсутствует, а сведения взяты только из карточки пакета, сохраните подтверждение из репозитория и передайте вопрос специалисту.
Полезно разделить реестр на три уровня:
- компоненты, которые остаются только в среде разработки;
- компоненты, которые попадают в серверную или клиентскую поставку без изменений;
- компоненты, код которых команда изменила или встроила в собственный модуль.
После этого составьте список файлов, которые нужно передать пользователю. В него могут входить текст GPL, уведомления об авторских правах, перечень компонентов и исходный код изменённых частей. Если полный исходный код не включают в архив, проверьте, какой способ его предоставления допускает применимая версия лицензии.
Для малого бизнеса такую работу удобно оформлять как отдельный аудит, а не оставлять на усмотрение разработчика перед самым запуском. В аудите программных лицензий для малого бизнеса логика проверки строится вокруг инвентаризации, условий лицензий и документов, которые подтверждают право использования.
Как сочетать GPL с закрытым кодом?
Закрытая лицензия на собственный продукт не отменяет условий GPL-компонента. Нельзя написать в договоре с клиентом, что вся поставка принадлежит компании, если часть программы распространяется по свободной лицензии. Документы должны разделять собственный код, сторонние компоненты и права пользователя на каждый из них.
До разработки архитектуры обсудите, как модули будут взаимодействовать. Изолированный процесс, отдельный сервис или самостоятельная программа может иметь другую лицензионную оценку, чем код, который собрали в один бинарный файл. Техническое решение не гарантирует нужный юридический результат, но его описание помогает провести предметную проверку.
Особого внимания требуют плагины и расширения. Если основной продукт закрытый, а плагин использует функции GPL-программы или содержит её код, нельзя автоматически назвать его независимым модулем. Сохраните схему связей и исходные файлы, чтобы юрист мог оценить конкретную конструкцию, а не только название пакета.
Какие ошибки чаще всего допускают при работе с GPL?
- Проверяют лицензию только у прямых зависимостей и пропускают вложенные пакеты.
- Считают, что платная подписка или коммерческий договор отменяют обязанности GPL.
- Передают клиенту изменённую библиотеку без исходного кода изменений и уведомлений.
- Смешивают в одном договоре собственные права компании и права пользователей свободного компонента.
- Заменяют GPL-компонент перед релизом, но не обновляют реестр, установщик и пакет уведомлений.
- Начинают юридическую проверку после публикации продукта, когда архитектуру уже трудно изменить.
3 шага, которые можно сделать на этой неделе:
- Соберите список внешних библиотек и укажите точные версии лицензий.
- Отметьте компоненты, которые изменены или передаются клиенту вместе с продуктом.
- Перед релизом проверьте пакет документов, исходный код и формулировки договора с юристом, который работает с лицензированием ПО.
GPL не запрещает зарабатывать на программном продукте. Она требует заранее определить состав поставки, сохранить уведомления и выполнить условия лицензии для тех компонентов, которые компания распространяет. Такой реестр пригодится и при обновлении продукта, и при проверке прав на ПО, и при выборе коммерческой или облачной альтернативы, если требования GPL не подходят архитектуре.
