Код общий, ответственность индивидуальная
Код общий, ответственность индивидуальная Инфраструктурный вендорский софт последних лет во многом собран из открытого кода: писать собственный менеджер артефактов с нуля никто не готов — ни по деньгам, ни по срокам. Пока исходный проект развивается и стабильно выпускает релизы, схема всех устраивает. Открытая команда делает основу, вендор накладывает доработки, заказчик получает обновления. Вопрос о том, кто в итоге отвечает за фундамент, обычно не задается. Задается он в момент, когда проект меняет лицензию, — как правило, тогда, когда перестраивать продукт уже дороже, чем разбираться с последствиями. Ответ записан в лицензии с самого начала. Просто вендоры внимательно читают ее первую часть — про право использовать, менять и распространять код, — а вторую, где перечислены обязанности распространителя, листают по диагонали. Копилефт требует, чтобы измененный код при распространении оставался под той же лицензией, что и исходный; слабый копилефт распространяет правило только на измененные модули, а не на весь продукт. Но и этого достаточно, чтобы у поставщика появились конкретные обязательства. EPL 1.0 — слабый копилефт, и выглядят эти обязанности так. Все доработки самого Nexus остаются под EPL, и получатель вправе узнать, чем форк отличается от оригинала. Это право следует из лицензии, а не из доброй воли поставщика. Собственный сканер или интерфейс вендора может жить под коммерческой лицензией, он не переработка. Изменение модели прав доступа в самом Nexus — уже переработка. А все обещания заказчику — производительность, поддержка, сроки — обязательства самого вендора: авторы открытого кода гарантий не давали. Показательный случай — менеджеры репозиториев. После ухода JFrog и Sonatype с российского рынка в 2022 году на базе Nexus Repository OSS, открытой редакции под лицензией EPL 1.0, выросло несколько вендорских решений. В феврале 2025 года Sonatype расставила все по местам: с версии 3.77 бесплатная редакция стала Community Edition с отдельным соглашением и лимитами — 100 тыс. компонентов в хранилище и 200 тыс. запросов в сутки. Экземпляр, превысивший любой из порогов, перестает сохранять новые компоненты. Исходный код при этом никуда не делся, nexus-public на GitHub продолжает жить под EPL 1.0, но готовых OSS-сборок больше нет. Но лицензионная часть — лишь половина истории. Хранилище артефактов — критическая система. Если оно недоступно — стоят конвейеры и релизы. Скомпрометировано — зараженные артефакты разойдутся по всем сборкам компании. Sonatype закрывала в Nexus и критические уязвимости, а рабочие примеры эксплуатации появлялись в открытом доступе через несколько дней после бюллетеня. Патчи попадают в релизы исходного проекта, переносить их в форк обязан его владелец, и чем дальше ветка ушла от базы, тем дороже каждый перенос. Наследуются, впрочем, не только патчи, но и ошибки — свежий пример, регрессия в версии 3.83.0 самого Nexus. Отсюда метрика, которую покупатель или регулятор обычно не спрашивает, а стоило бы: срок от раскрытия уязвимости в исходном проекте до патча в сборке вендора. Смена лицензий успешными открытыми проектами стала индустриальной практикой. Сообщество каждый раз отвечало форком — OpenSearch, OpenTofu, Valkey, — но энтузиастам это дает альтернативу, а вендору, который уже продал продукт, — только работу. Поэтому у решения на открытом коде стоит спросить: какая версия исходного проекта в основе, где опубликован код доработок, что заявлено как собственное, есть ли SBOM и за какой срок выпускаются патчи. Ответ «предоставим по запросу» — допустим. Ответ «это наша интеллектуальная собственность» означает, что лицензию поставщик не читал. Разрыв с базовой версией в год и больше — обновления либо переносились вручную, либо не переносились вовсе. Открытый код сам по себе не порок — порок в том, чтобы строить на нем коммерческий продукт и считать, что обязательства заканчиваются там, где заканчивается бесплатность. Они как раз там начинаются. @antiinfosec