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