Как учитывать open-source компоненты в составе своего ПО

Учет open-source компонентов помогает компании понять, какой код вошел в продукт, на каких условиях его можно использовать и какие действия потребует лицензия при выпуске обновления или передаче программы заказчику. Для малого бизнеса достаточно начать с реестра компонентов, проверить тексты лицензий и закрепить простой порядок согласования новых библиотек. В статье разберем, какие сведения собирать, чем отличаются распространенные лицензии и как подготовить документы к внутренней или внешней проверке.

Зачем вести реестр открытого кода

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

Реестр открытого кода связывает компонент с конкретным продуктом и версией продукта. В нем видно, кто добавил библиотеку, где лежит исходный код, какая лицензия указана автором и есть ли у команды обязательства при распространении. Такой список полезен и для учета коммерческих лицензий: управление ИТ-активами опирается на разные лицензионные метрики, а условия зависят от модели лицензирования и поставщика (ITAM2.RU, «Основные виды лицензионных метрик»).

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

Поле в реестре	Что записать	Зачем это нужно
Название компонента	Библиотека, модуль, шаблон или фрагмент кода	Чтобы отличить его от похожих пакетов
Версия	Точная версия, которая вошла в сборку	Лицензия и состав зависимостей могут меняться
Источник	Репозиторий, сайт автора или внутренняя копия	Чтобы найти исходный текст лицензии и уведомления
Лицензия	Название лицензии и ссылка на ее текст в архиве проекта	Чтобы проверить условия распространения
Где используется	Продукт, модуль и релиз	Чтобы оценить последствия замены или обновления
Ответственный	Разработчик или руководитель проекта	Чтобы уточнить происхождение компонента

Чем MIT, Apache и GPL отличаются для коммерческого продукта

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

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

Если в продукте есть компонент GPL, не стоит ограничиваться отметкой «open source» в реестре. Разработчик фиксирует, как библиотека связана с программой, что получает клиент и какие файлы входят в дистрибутив. Отдельно разобрать этот сценарий поможет материал как использовать GPL в коммерческом продукте.

Как собрать сведения о компонентах без долгой инвентаризации

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

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

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

Какие документы подготовить к проверке продукта

Проверка лицензий не сводится к сопоставлению количества установок. В лицензионном аудите также смотрят на корректность версий и редакций программных продуктов, удаление неиспользуемых инсталляций, распределение лицензий и выбор схемы лицензирования (Iterbi, «Лицензионный аудит программных продуктов»). Для собственного ПО с открытыми компонентами логика похожая: нужно показать состав продукта и основания для использования каждого элемента.

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

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

Типичные ошибки при работе с open-source лицензиями

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

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