Данный текст был подготовлен для журнала Information Security. Оригинальную публикацию можно прочесть на сайте журнала.
Наша команда разрабатывает платформу безопасной разработки CodeScoring, в задачи которой входит автоматическая проверка критериев лицензионной чистоты анализируемого ПО на основании экспертной базы знаний. В статье рассматривается частный, но показательный случай: когда вендорское решение основано на известном открытом проекте, распространяющемся на условиях копилефт-лицензий. Материал сопровождается примером и набором правил для самопроверки, которые позволят увереннее контролировать юридические риски и риски безопасности в цепочке поставок ПО.
Рассмотрим ситуацию, когда продукт, построенный на открытом решении, складывается из работы двух команд. Первая развивает исходный проект, вторая берёт его за основу, добавляет свою функциональность и сопровождает заказчика. Пока релизы открытого проекта выходят регулярно, это разделение обычно всех устраивает. Вендор переносит исправления, заказчик получает обновления, и вопрос о том, кто на самом деле отвечает за основу проекта, задается нечасто.
Между тем ответ на этот вопрос существует, и записан он в лицензии исходного проекта. Вендора в ней обычно интересует первая часть, где сказано, что код можно использовать, менять и распространять. Однако у лицензий с копилефтом есть и вторая часть, где перечислены обязанности того, кто распространяет код дальше. Она определяет, что вендор обязан раскрыть, на каких условиях он может распространять собственные модули и кто отвечает перед заказчиком за продукт, если к нему предъявят претензии, притом что сам исходный проект от гарантий и ответственности отказывается. Именно эта часть и превращает сопровождение чужого кода в ответственность вендора. Помнят о ней не все и не всегда, потому что повод появляется обычно тогда, когда исходный проект меняет лицензию.
Копилефт — это условие открытой лицензии, по которому изменённый код при распространении должен оставаться под той же лицензией, что и исходный. Слабый копилефт распространяет это требование только на изменённые файлы или модули, а не на весь продукт целиком. Важно отметить, что у каждой лицензии имеются свои особенности использования, поэтому следует ознакомиться с полным текстом каждого такого документа.
Такие перемены для успешных открытых проектов сегодня не редкость. Одни меняют лицензионные соглашения, другие вводят ограничения на объёмы использования. Разберём пример, где случилось и то и другое. После ухода с российского рынка разработчиков менеджеров артефактов, компаний JFrog и Sonatype, появились решения, построенные на Nexus Repository OSS, открытой редакции продукта Sonatype, распространяющейся под EPL 1.0. В феврале 2025 года Sonatype ввела для бесплатной редакции отдельное соглашение и лимиты, а открытые сборки прекратили.
Введение политики ограничений в открытом решении
До февраля 2025 года у Nexus Repository было две поставки: платная Pro и бесплатная OSS, исходные коды которой Sonatype публиковала на GitHub под EPL 1.0. Часть модулей уже тогда поставлялась только в скомпилированном виде, на что обращали внимание те, кто пробовал собирать её из исходников. Тем не менее готовые сборки OSS выходили регулярно, и вендор, строивший на них продукт, получал новую версию от Sonatype, накладывал свои изменения и отдавал заказчику.
4 февраля 2025 года Sonatype объявила, что с версии 3.77 бесплатная поставка называется Community Edition. Она устанавливается по отдельному пользовательскому соглашению и имеет лимиты на 100 000 компонентов в хранилище и 200 000 запросов в сутки. После льготного периода экземпляр, превысивший любой из порогов, отказывается сохранять новые компоненты. Для компании с заметным объёмом разработки это болезненные цифры. По грубой оценке, одна сборка среднего Java- или JavaScript-проекта запрашивает у прокси-репозитория сотни артефактов, а с холодным кешем — тысячи, поэтому лимит в 200 000 запросов в сутки легко может быть выбран командой из нескольких десятков разработчиков с обычным конвейером разработки. Лимит хранения в 100 000 компонентов прокси Maven Central или npm набирает за несколько месяцев, потому что каждая версия каждого пакета считается отдельным компонентом.
Исходные коды при этом никуда не исчезли. Репозиторий nexus-public на GitHub продолжает лицензироваться под EPL 1.0, на начало сентября 2026 года там опубликован тег 3.96.0, а исправления в него попадают регулярно. Но готовых OSS-сборок больше нет, с версии 3.77 все бинарные пакеты являются Community Edition. Тот, кому нужна именно открытая редакция, собирает её из исходников сам, и это требует ручных шагов.
Для продукта, построенного на базе Nexus OSS, это означает смену процесса работы. Раньше можно было опираться на бинарные релизы Sonatype и накладывать свои изменения поверх. Теперь сборка своя, и перенос изменений тоже ложится на плечи разработчика.
Что EPL требует от вендора
EPL 1.0, под которой опубликована открытая часть Nexus, относится к лицензиям со слабым копилефтом, и если упростить, то её условия для поставщика умещаются в три следующие задачи:
Контроль изменений исходного проекта. Всё, что разработчик поменял в самом Nexus, остаётся под EPL. Если продукт распространяется в виде бинарных сборок, то текст лицензии требует сообщить получателю, что исходный код доступен, и объяснить, как его получить. Иными словами, у конечного потребителя есть право увидеть, чем именно форк отличается от исходного проекта, и это право следует из лицензии, а не из доброй воли поставщика.
Контроль границы своего и стороннего кода. Готовую бинарную сборку можно распространять по единой коммерческой лицензии, охватывающей и EPL-компоненты, и собственный код. При этом нужно обозначить часть под EPL, соблюдать её условия и сообщить получателю, как получить соответствующие исходники, включая изменения. Собственные модули могут оставаться под другой лицензией, если они поставляются вместе с программой и не являются её переработкой. Собственный интерфейс или сканер могут отвечать этому условию. А вот изменение модели прав доступа в самом Nexus – это уже изменение исходного проекта, которое остаётся под EPL.
Контроль ответственности. Исходный проект поставляется «как есть»: EPL исключает гарантии и ограничивает ответственность его авторов. Если вендор обещает заказчику определённую производительность, поддержку или сроки исправлений, это его собственные обязательства. Переложить их на авторов исходного проекта нельзя. Например, если из-за обещанной вендором производительности претензии предъявят другим участникам проекта, EPL обязывает вендора защищать их и возмещать связанные потери на условиях лицензии. Отдельно лицензия предупреждает, что нарушение существенных условий прекращает права, если его не устранить в разумный срок после обнаружения; тогда получатель обязан прекратить использование и распространение программы.
Ни одна из этих задач не запрещает строить продукт на Nexus и продавать его. Они лишь определяют, что вендор должен раскрыть конечному потребителю, а потребитель вправе запросить.
Почему это еще и вопрос безопасности
Хранилище артефактов относится к критически важным системам, без которых разработка останавливается. Через него проходят все библиотеки, сборки и образы, и если оно недоступно, то останавливаются конвейеры сборки и выпуски релизов. Если хранилище скомпрометировано, то под угрозой оказывается вся цепочка поставки продукта. В таком случае артефакты можно удалить, подменить или заразить, и дальше они разойдутся по всем сборкам компании.
За последние годы Sonatype закрывала в Nexus несколько критических уязвимостей, причём рабочие примеры эксплуатации порой появлялись в открытом доступе через несколько дней после публикации бюллетеня.
Все эти исправления попадают в релизы nexus-public. В форк их должен перенести поставщик форка. Чем дальше его ветка ушла от базовой версии, тем дороже каждый перенос. А регрессия в версии 3.83.0 добавляет еще один риск. Форк наследует не только исправления исходного проекта, но и его ошибки и заметит их с тем же опозданием.
На практике это означает, что у репозитория на базе Nexus есть метрика, которую покупатель обычно не спрашивает, а стоило бы: время между раскрытием уязвимости в исходном проекте и патчем, включённым в конечную сборку вендора. Если такой статистики у поставщика нет, то, скорее всего, нет и регламента переноса в рамках процессов безопасной разработки.
Чек-лист проверки продукта, основанного на открытом решении
Всё сказанное выше про Nexus справедливо для любого продукта, построенного на открытом решении (конечно, с учетом требований конкретных лицензий). Если покупатель хочет защититься от трёх рисков (отстающие исправления безопасности, неясная граница между своим и чужим кодом и унаследованные условия исходного проекта), то ему необходимо задать поставщику несколько базовых вопросов:
какая версия исходного проекта лежит в основе продукта?
где опубликован код доработок исходного проекта, который лицензия обязывает раскрывать?
какие части продукта заявлены как собственные, как они взаимодействуют с исходным проектом?
есть ли SBOM (перечень программных компонентов) самого продукта?
как поставщик узнаёт о новых уязвимостях исходного проекта, за какой срок обязуется выпустить (и выпускает) патч и где это фиксируется?
какие ограничения исходного проекта распространяются на поставку конечному потребителю?
Ответ «предоставим по запросу» на второй вопрос допустим, а ответ «это наша интеллектуальная собственность» противоречит лицензии, под которой поставщик получил код. Разрыв в год и больше в первом вопросе означает, что все обновления за этот год либо перенесены вручную, либо отсутствуют.
Ответы проверяются теми же средствами, которыми компания проверяет любой другой заимствованный код: сравнением с базовой версией, инвентаризацией компонентов и анализом их состава.
При работе с открытым кодом важно помнить
Типизированных открытых лицензий в мире существует более 2500, и все они накладывают свои требования и ограничения на производное ПО.
Копилефт-лицензия описывает не только права вендора, но и его обязанности: раскрывать изменения исходного проекта, отделять собственные модули от переработки и отвечать за коммерческое распространение.
Смена условий работы исходного проекта превращает эти обязанности в конкретную работу вендора: сборку, перенос исправлений и сверку с исходным проектом.
С точки зрения кибербезопасности главной метрикой является срок между раскрытием уязвимости исходного открытого проекта и примененным патчем в конечной сборке.