Привет, Хабр!

Использование OSS‑компонентов — стандарт современной разработки. Под OSS‑компонентами мы понимаем ПО с открытым исходным кодом. Это могут быть приложения, библиотеки, набор файлов, или даже просто фрагмент кода.

Но при использовании OSS есть нюанс — лицензии. Одни библиотеки можно брать без оглядки, другие требуют платежей, а третьи — строгого соблюдения условий. И если в бэкенде зачастую все относительно статично (версии меняются редко, компонентов немного), то веб — отдельная история. Тут компоненты множатся с космической скоростью, версии обновляются каждую неделю, и следить за всем этим вручную просто нереально.

В этой статье расскажем о том, как мы формируем реестр OSS‑компонентов и какие инструменты помогают нам быстрее проверять лицензии и формировать единый список компонентов.

Проблематика

Нарушение лицензий open source (OSS) может привести к таким же серьезным последствиям, как и несоблюдение условий использования коммерческих сторонних компонентов. Ключевая разница заключается в том, что нарушения OSS‑лицензий чаще всего возникают из‑за недостаточной культуры работы с открытым кодом и отсутствия четких процедур контроля его использования. 

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

Политика регистрации сторонних компонентов

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

Исключение составляют только случаи, когда код компонента не связан с кодом компании — например, при использовании Far, Eclipse, Linux и других open source продуктов в процессе разработки (их регистрировать не нужно).

Cхема формирования дерева зависимостей OSS

После заполнения Excel-файла разработчиком продуктовые менеджеры совместно с юристами организует проверку этих данных. Процесс выглядит так:

• Проверенные и согласованные юристами  компоненты вносятся во вкладку «Общий список компонентов» (OSS-реестр).

• В отдельном листе фиксируются версии компонентов — это помогает отслеживать их состав для каждой версии продукта.

• Запускается процесс согласования EULA по внутренней политике компании, после чего юрист формирует файл «Технологии третьих лиц».

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

Фрагмент шаблонного Excel-файла для разработчиков

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

Автоматизация проверки OSS-компонентов 

Изначально мы вели учет сторонних компонентов вручную, просто собирая их список с версиями в Excel. Это работало, пока количество OSS оставалось небольшим. Все изменилось после крупного рефакторинга кода в одном из флагманских продуктов: количество компонентов увеличилось более чем вдвое. Юристы, увидев такой объем, сразу сказали: «Вручную это проверить невозможно». 

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

Что под «капотом» нашей системы автоматизации. Это гибридное решение, где мы соединили готовые инструменты с собственными разработками: набором скриптов на Node.js. Мы сознательно выбрали JavaScript в качестве базового языка, поскольку он позволял одинаково эффективно работать как с бэкенд-логикой, так и с фронтенд-компонентами.

Самописные скрипты мы интегрировали с несколькими open source и сервисными решениями:

• Webpack стал нашим верным помощником в анализе бандлов. Он точно определяет, какие пакеты попадают в конечный продукт, а какие нужны только на этапе сборки. 

• Axios надежно обрабатывает запросы к GitHub и другим API.

• Библиотека Excel.js превращает собранные данные в удобные Excel-файлы, привычные для юристов и разработчиков. 

Как работает процесс проверки компонентов. Сначала скрипт формирует итоговый список отфильтрованных компонентов с их версиями. Затем производится автоматический поиск каждого компонента на GitHub или npmjs.com.

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

После завершения всех проверок скрипт формирует два отдельных отчета. Первый посвящен фронтенд‑компонентам (JavaScript), второй — бэкенд‑решениям (C#). Такой раздельный подход позволяет каждому отделу работать именно с теми данными, которые им действительно нужны.

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

Особое внимание уделяем совершенствованию механизма проверки лицензий. Сейчас скрипт работает по принципу сравнения с эталонами: находит лицензию в репозитории, вырезает соответствующий фрагмент и заменяет его эталонным текстом. Однако этот подход имеет ограничения, особенно когда речь идет о сложных случаях вроде комбинированных лицензий «mid AND bsd» или «mid OR bsd».

Именно для таких ситуаций мы планируем внедрить LLM. Основная сложность заключается в том, что текущая система плохо справляется с вариативностью оформления текстов — кавычками в виде звездочек, разными стилями списков и другими нюансами форматирования. LLM должна помочь анализировать текст целиком, оценивая смысловое соответствие, а не только точное совпадение символов.

Мы осознаем риски, связанные с возможными «галлюцинациями» языковых моделей. Поэтому планируем реализовать механизм перекрестной проверки — результаты работы LLM будут отображаться в отдельной колонке отчета, что позволит сопоставлять их с данными, полученными традиционным способом. При этом все выводы ИИ в обязательном порядке будут проверяться юристом, так как последствия ошибок могут быть существенными, и полная автоматизация процесса пока выглядит рискованной. Такой подход позволит оптимизировать работу, сохранив при этом возможность ручного контроля в спорных случаях.