Журнал "Information Security/ Информационная безопасность" #4, 2026

Наша команда разрабатывает плат- форму безопасной разработки Code- Scoring, в задачи которой входит авто- матическая проверка критериев лицен- зионной чистоты анализируемого ПО на основании экспертной базы знаний. Рассмотрим ситуацию, когда продукт, построенный на открытом решении, складывается из работы двух команд: первая развивает исходный проект, а вторая берет его за основу, добавляет свою функциональность и сопровождает заказчика. Пока релизы открытого про- екта выходят регулярно, это разделение обычно всех устраивает. Вендор пере- носит исправления, заказчик получает обновления, и вопрос о том, кто на самом деле отвечает за основу проекта, задается нечасто. Между тем ответ на этот вопрос суще- ствует, и записан он в лицензии исход- ного проекта. Вендора в ней обычно интересует первая часть, где сказано, что код можно использовать, менять и распространять. Однако у лицензий с копилефтом 1 есть и вторая часть, где перечислены обязанности того, кто рас- пространяет код дальше. Она опреде- ляет, что вендор обязан раскрыть, на каких условиях он может распространять собственные модули и кто отвечает перед заказчиком за продукт, если к нему предъявят претензии, притом что сам исходный проект от гарантий и ответственности отказывается. Именно эта часть и превращает сопровождение чужого кода в ответственность вендора. Помнят о ней не все и не всегда, потому что повод появляется обычно тогда, когда исходник меняет лицензию. Такие перемены для успешных откры- тых проектов сегодня не редкость. Одни меняют лицензионные соглашения, а другие вводят ограничения на объемы использования. Разберем пример, где случилось и то и другое. После ухода с российского рынка раз- работчиков менеджеров артефактов – компаний JFrog и Sonatype – появились решения, построенные на Nexus Repos- itory OSS – открытой редакции продукта Sonatype, распространяющейся под EPL 1.0. В феврале 2025 г. Sonatype ввела для бесплатной редакции отдельное соглашение и лимиты, а выпуск откры- тых сборок прекратила. Введение политики ограничений в открытом решении До февраля 2025 г. у Nexus Repository было две поставки: платная Pro и бес- платная OSS, исходные коды которой Sonatype публиковала на GitHub под EPL 1.0. Часть модулей уже тогда постав- лялась только в скомпилированном виде, на что обращали внимание те, кто про- бовал собирать ее из исходников. Тем не менее готовые сборки OSS выходили регулярно, и вендор, строивший на них продукт, получал новую версию от Sonatype, накладывал свои изменения и отдавал результат заказчику. 4 февраля 2025 г. Sonatype объявила 2 , что с версии 3.77 бесплатная поставка называется Community Edition. Она уста- навливается по отдельному пользова- тельскому соглашению и имеет лимиты на 100 тыс. компонентов в хранилище и 200 тыс. запросов в сутки. После льгот- ного периода экземпляр, превысивший любой из порогов, отказывается сохра- нять новые компоненты. Для компании с заметным объемом разработки это болезненные цифры. По грубой оценке, одна сборка среднего Java- или JavaScript-проекта запрашивает у про- кси-репозитория сотни артефактов, а с холодным кешем – тысячи, поэтому лимит в 200 тыс. запросов в сутки легко может быть выбран командой из несколь- ких десятков разработчиков с обычным конвейером разработки. Лимит хранения в 100 тыс. компонентов прокси Maven Central или npm может быть исчерпан за несколько месяцев, потому что каждая версия каждого пакета считается отдель- ным компонентом. Исходные коды при этом никуда не исчезли. Репозиторий nexus-public на GitHub 3 продолжает лицензироваться под EPL 1.0, на начало сентября 2026 г. там опубликован тег 3.96.0, а исправления в него попадают регулярно. Но готовых OSS-сборок боль- ше нет, с версии 3.77 все бинарные пакеты являются Community Edition. Тот, кому нужна именно открытая редакция, должен собирать ее из исходников сам, и это требует ручных шагов. Для продукта, построенного на базе Nexus OSS, это означает смену процесса работы. Раньше можно было опираться на бинарные релизы Sonatype и накла- дывать свои изменения поверх. Теперь сборка своя, и перенос изменений тоже ложится на плечи разработчика. 72 • ТЕХНОЛОГИИ Чужой код, своя ответственность: лицензионная чистота, которую важно блюсти статье разберем показательный случай, когда вендорское решение построено на известном открытом проекте, который распространяется по копилефт-лицензии. Рассмотрим набор правил для самопроверки, позволяющий увереннее контроли- ровать юридические риски и риски безопасности в цепочке поставок ПО. В Артем Максимов, продуктовый аналитик CodeScoring Фото: CodeScoring 1 Копилефт – это условие открытой лицензии, по которому измененный код при распространении должен оставаться под той же лицензией, что и исходный. Слабый копилефт распространяет это требование только на измененные файлы или модули, а не на весь продукт целиком. Важно отметить, что у каждой лицензии имеются свои особенности использования, поэтому следует ознакомиться с полным текстом каждого такого документа. 2 https://www.sonatype.com/blog/sonatype-nexus-repository-community-edition 3 https://github.com/sonatype/nexus-public