10.3 Закупки, открытый исходный код и лицензирование

Обзор и мотивация

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

Для больших команд ставки одновременно юридические, операционные и стратегические. Юридически лицензии открытого исходного кода это исполнимые контракты с реальными обязательствами. Ошибка с копилефтом (лицензированием, способным требовать делиться производными работами на тех же условиях) может в худшем случае обязать раскрыть проприетарный исходный код или вызвать судебное разбирательство. Нарушения лицензий могут даже заблокировать поглощение или публичное размещение во время должной осмотрительности. Операционно неуправляемые зависимости гниют: компоненты остаются без сопровождения, накапливают уязвимости и достигают конца срока службы, всё ещё зарытые глубоко в производстве. Стратегически открытый исходный код больше, чем вход для экономии. Это способ избежать привязки, привлечь таланты и формировать экосистемы, от которых вы зависите, преимущества, которые вы получаете, только если вовлекаетесь намеренно.

У государства есть дополнительное измерение. Во многих юрисдикциях теперь есть явные политики, отдающие предпочтение открытому исходному коду, открытым стандартам и обмену кодом между ведомствами. Они нередко выражены как «общественные деньги, общественный код»: принцип, что программное обеспечение, финансируемое налогоплательщиками, должно по умолчанию быть доступно обществу. Так что инженерам государственного сектора приходится ориентироваться и в соответствии лицензиям, и в активных мандатах предпочитать, публиковать и повторно использовать открытый исходный код. Эта глава призвана сделать всё это управляемым в масштабе.

Ключевые принципы

Открытый исходный код это цепочка поставок, а не бесплатное добро. Воспринимайте потребляемые компоненты с той же строгостью, что и любого критичного поставщика.
Лицензии это обязательства, а не разрешение игнорировать. Каждая зависимость несёт условия; знайте их до отгрузки.
Копилефт это проектное ограничение, а не табу. Лицензии с копилефтом пригодны и ценны; они лишь требуют понимать, как вы сочетаете и распространяете программное обеспечение.
Потребляйте намеренно, вносите вклад стратегически. Решайте, что приносить, и, где это вам служит, вкладывайтесь в передачу изменений вверх по течению, а не в форки.
Описывайте всё. Нельзя соответствовать, защищать или обновлять то, чего не видишь; SBOM (перечень компонентов программного обеспечения, полная опись компонентов в вашем ПО) обязательный минимум.
Планируйте конец срока службы с самого начала. Каждая зависимость однажды останется без сопровождения; знайте свой выход, прежде чем вас вынудят к нему.
В государственном секторе по умолчанию открытое. Предпочитайте открытые стандарты и открытый исходный код и публикуйте код на общественные деньги, если нет конкретной причины не делать этого.

Компромиссы: плюсы и минусы

Выбор	Плюсы	Минусы
Свободное потребление открытого исходного кода	Быстрая поставка; огромный рычаг; нет лицензионных платежей	Обязательства по лицензиям, безопасности и сопровождению теперь ваши
Строгий список разрешённых лицензий	Низкий юридический риск; предсказуемо	Замедляет команды; может исключать действительно полезные компоненты
Только разрешительные лицензии	Минимум обязательств; легко сочетать	Отказ от ценных проектов с копилефтом; меньше взаимности
Принятие копилефта, где подходит	Доступ к сильным экосистемам; выгоды взаимности	Требует осторожности при сочетании и распространении
Вклад вверх по течению	Меньше бремя частных патчей; влияние; добрая воля	Постоянные усилия; накладные расходы ИС и процесса
Построение проприетарного вместо	Полный контроль; нет внешних обязательств	Высокая цена; изобретение товара заново; вы сопровождаете его вечно
Публикация по умолчанию в государственном секторе	Прозрачность; повторное использование; избегает привязки	Усилия публикации; рецензия безопасности; постоянное стюардство

Центральное напряжение между скоростью разработчиков и контролем. Заприте всё за тяжёлой рецензией, и разработчики обойдут политику. Это создаст неуправляемые теневые зависимости, хуже подхода разрешительного, но видимого. Оставьте всё совершенно бесконтрольным, и вы невидимо накопите юридический долг и долг безопасности. Разрешение автоматизация и кураторство: сделайте соответствующий путь самым быстрым через предварительно проверенные компоненты, сканирование в конвейере и ясные умолчания, получая контроль без трения. Для копилефта компромисс не «рискованно против безопасно», а «понято против не понято». Копилефт полностью пригоден, как только вы знаете, как сочетаете и распространяете.

Вопросы для обсуждения с командой

Каково ваше явное правило для сильного и сетевого копилефта во внутреннем, распространяемом и обслуживаемом по сети контекстах? Копилефт проектное ограничение, а не табу, и обязательства зависят от двух вещей: распространяете ли вы программное обеспечение и насколько тесно сочетаете компоненты. GPL во внутреннем инструменте ведёт себя совсем иначе, чем GPL, скомпонованный в продукт, который вы отгружаете, а AGPL распространяет обязанности раскрытия на программное обеспечение, которое вы лишь предлагаете по сети, что меняет ваш расчёт «строить или принять» для всего, что вы ведёте как сервис. Запишите правило для каждого контекста, чтобы разработчик знал, не звоня юристу, что (например) разрешительные лицензии предварительно одобрены везде, сильный копилефт годится внутри, но заблокирован для отгружаемого продукта, а AGPL требует рецензии до того, как коснётся сетевого сервиса. Принесите свидетельства: просканируйте ваше нынешнее дерево зависимостей и найдите, где компоненты с копилефтом уже стоят относительно вашей границы распространения. Затем ограничьте сборку этой политикой, потому что правило, которое не принуждает ни один сканер, правило, которое разработчики нарушат случайно.
Нужен ли вам Офис программы открытого исходного кода и кто сегодня владеет политикой лицензий, сканированием и решениями о вкладе? Если честный ответ «никто» или «каждая команда решает», вы ведёте свободную игру, невидимо накапливающую юридический долг и долг безопасности. OSPO, даже один человек плюс межфункциональная рабочая группа, обуздывает этот хаос и захватывает стратегическую ценность: в какие проекты вверх по течению вкладываться, когда вносить вклад и как хорошо выпускать собственные проекты. Принесите на совещание свидетельства: может ли кто-нибудь представить текущий список одобренных лицензий, SBOM и имя человека, который отвечал бы на вопрос о копилефте во время должной осмотрительности при поглощении? Ответ должен назначить ясное владение и сделать соответствующий путь самым быстрым через предварительно проверенные компоненты и сканирование в конвейере, так что разработчики получают контроль без трения. Политика медленнее копирования кода будет просто проигнорирована.
Какие зависимости больнее всего ударили бы, будучи заброшены завтра, и каков ваш заранее решённый ответ для каждой? Каждая зависимость рано или поздно достигает конца срока службы, и дорогая версия этого события обнаружение того, что основной компонент потерял поддержку месяцы назад, только когда уязвимость вынуждает обратить внимание. Для ваших критичных компонентов под угрозой заброшенности решите заранее, будете ли вы финансировать сопровождающего, вносить сопровождение сами, форкать или заменять. Принесите свидетельства: из вашего SBOM перечислите компоненты, чей отказ остановил бы приносящий выручку или критичный для миссии сервис, и отметьте состояние сопровождения и окно поддержки безопасности каждого. Ответ должен превратить конец срока службы из сюрприза в отслеживаемый операционный риск с запланированной миграцией, на том же стандарте, что и любой другой риск. Поддержание зависимостей актуальными малыми частыми шагами гораздо дешевле редкого гигантского вынужденного скачка.
Можете ли вы произвести полный текущий SBOM, доходящий до самого низа вашего дерева транзитивных зависимостей, и как быстро? Когда громкая уязвимость приземляется в широко используемой библиотеке, первый вопрос руководства «подвержены ли мы и где?» Команда, не способная ответить за часы, уже отстаёт, потому что настоящий риск обычно прячется на несколько слоёв глубже в зависимостях, которые никто не выбирал намеренно. Конкурирующее соображение цена и шум: полная транзитивная опись по многим сервисам порождает большой, меняющийся список, а избыточное оповещение приучает людей его игнорировать, поэтому нужно решить, какая глубина и какая серьёзность действительно запускают действие. Принесите на обсуждение свидетельства: попробуйте сгенерировать свежий SBOM для одного производственного сервиса прямо сейчас, посчитайте, сколько компонентов прямых против транзитивных, и засеките, сколько это заняло. Для корпоративного или государственного органа привяжите это к конкретной цели реагирования на инциденты и к любой регуляторной обязанности раскрывать затронутые компоненты, потому что мандат сообщать об экспозиции, которую вы не можете перечислить, мандат, который вы нарушите.
Когда критичную зависимость стоит финансировать, вносить в неё вклад или быть её стюардом, а не воспринимать как бесплатную? Большинство организаций потребляют открытый исходный код как коммунальную услугу, затем потрясены, когда компонент, на котором держится приносящий выручку сервис, оказывается одним неоплачиваемым добровольцем. Намеренное решение финансировать сопровождающего, передавать исправления вверх по течению или выпускать и опекать собственный проект превращает хрупкий бесплатный вход в долговечный, на который вы влияете, и не даёт вашим инженерам нести частные патчи через каждое обновление. Напряжение в том, что вклад и стюардство стоят реального постоянного инженерного времени и несут накладные расходы интеллектуальной собственности и процесса, поэтому нельзя делать это для всего. Принесите свидетельства: из вашего SBOM отметьте горстку компонентов, чей отказ остановил бы критичный для миссии сервис, и отметьте число сопровождающих, финансирование и сколько частных патчей вы уже несёте против каждого. Для большой или государственной организации взвесьте репутационную цену заброшенного выпуска открытого исходного кода, опубликованного с помпой, а в государственном секторе воспринимайте постоянное стюардство опубликованного кода на общественные деньги как часть поставки, а не необязательное дополнение.
Действительно ли ваши закупки поставляют открытый, повторно используемый, хорошо документированный код с нужными вам правами или проприетарные чёрные ящики, которые вы не можете сопровождать или покинуть? Контракты, написанные без экспертизы в открытом исходном коде, регулярно отдают поставщику контроль, о котором вы пожалеете: закрытые форматы, нет права публиковать или изменять и зависимости, которые ведомство не может исправить, когда поставщик уходит. Сделать это правильно рано гораздо дешевле, чем обнаружить при продлении, что вы не можете уйти. Конкурирующие соображения скорость и выбор поставщика: требование открытых поставок и переносимости может сузить поле и замедлить заказ, а некоторые действительно полезные поставщики сопротивляются. Принесите свидетельства: возьмите два недавних контракта и проверьте, указывают ли они условия лицензий, поставку исходного кода, стандарты документации, предоставление SBOM и права, сохраняемые организацией. Для корпоративных закупок свяжите это с привязкой и анализом совокупной стоимости; для государственных с открытостью по умолчанию и мандатами «общественные деньги, общественный код» и с процессом документированных исключений, позволяющим закрыть только чувствительные к безопасности части, а не всю систему.

Взгляд по секторам

Стартап. Вы собираете почти всё из открытого исходного кода и не имеете юриста, поэтому держите правило на одной странице: разрешительные лицензии вроде MIT и Apache 2.0 предварительно одобрены, сильный копилефт годится для внутренних инструментов, но заблокирован для отгружаемого продукта, а всё странное получает быструю рецензию основателя. Добавьте сканирование лицензий и уязвимостей в конвейер и ведите SBOM с первого дня, потому что самый дешёвый момент сделать это правильно до того, как должная осмотрительность покупателя прочешет ваше дерево зависимостей. Не запрещайте копилефт из страха; поймите его и идите дальше.

Малый бизнес. Без специалиста по открытому исходному коду и при ограниченном бюджете опирайтесь на инструменты, а не штат: сканер в сборке и короткий список одобренных лицензий делают большую часть работы человека. Формулируйте потребление как «покупать против строить» честно, поскольку изобретение заново хорошо сопровождаемого открытого компонента обычно дорогой выбор, но так же дорого зависеть от компонента, который вы никогда не описывали. Ведите простую запись того, что используете и по какой лицензии, чтобы анкета безопасности клиента или оповещение об уязвимости не превратились в суету.

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

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

Примеры

Стартап. Стартап из четырёх человек, строящий мобильное приложение, собирает почти всё из открытого исходного кода и не имеет юриста в штате. Вместо запрета копилефта из страха основатели пишут политику на одной странице: разрешительные лицензии вроде MIT и Apache 2.0 предварительно одобрены, сильный копилефт вроде GPL годится для внутренних инструментов, но заблокирован для отгружаемого приложения, чтобы избежать обязанностей раскрытия, а всё необычное получает быструю рецензию основателя. Они добавляют сканирование лицензий и уязвимостей в конвейер, чтобы запрещённая лицензия не могла проскользнуть в выпуск, ведут SBOM с первого дня и передают небольшое исправление вверх по течению в критичную библиотеку, чтобы перестать нести частный патч через каждое обновление. Правильное решение рано также избавляет их от болезненного сюрприза, когда должная осмотрительность покупателя в итоге прочешет дерево зависимостей.

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

Лицензирование копированием и вставкой. Разработчики подтягивают компоненты без проверки лицензии, обнаруживая обязательства только при аудите или поглощении.
Нет описи. Неспособность ответить «что мы используем и по какой лицензии?», когда разражается уязвимость или вопрос о лицензии.
Паника из-за копилефта. Запрет всего копилефта из страха, а не понимания, с отказом от ценных экосистем.
Заброшенный выпуск открытого исходного кода. Публикация проекта с помпой и последующее несопровождение его, вредящее репутации.
Игнорирование транзитивных зависимостей. Проверка прямых зависимостей, пока настоящий риск прячется на несколько слоёв глубже.
Сюрприз конца срока службы. Обнаружение того, что основной компонент потерял поддержку месяцы назад, только когда уязвимость вынуждает обратить внимание.
Политика медленнее копирования. Процесс соответствия настолько тяжёл, что разработчики его обходят, создавая невидимые теневые зависимости.
Государственные чёрные ящики. Закупка проприетарных систем, которые ведомство не может сопровождать, делить или покинуть, вопреки принципам открытости по умолчанию.

Модель зрелости

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

Уровень 2: Развитие. Существуют базовая политика и список одобренных лицензий, и некоторые команды им следуют. Сканирование происходит, но нередко вручную, поздно или только на нескольких проектах. Опись ведётся для основных систем, а транзитивные зависимости не картированы. Вклад и обращение с концом срока службы стихийны и непоследовательны между командами.

Уровень 3: Стандартизация. OSPO или эквивалент владеет стратегией, политикой и инструментами по организации. Сканирование лицензий и уязвимостей автоматизировано в каждом конвейере, файлы авторства и уведомлений генерируются автоматически, а сборка ограничена так, что запрещённая лицензия не может войти. SBOM ведутся вниз по транзитивному дереву, вклад следует документированному процессу, конец срока службы отслеживается с плановыми миграциями, а государственные команды публикуют по умолчанию.

Уровень 4: Управление. Программа измеряется и контролируется относительно базовых значений. Вы отслеживаете покрытие сканированием политики по сервисам, среднее время исправления раскрытой уязвимости зависимости, долю компонентов внутри окна поддержки безопасности, долю ускользнувших нарушений лицензий, отставание актуальности зависимостей и число частных патчей, переданных вверх по течению. Размещение копилефта относительно границы распространения мониторится, а метрики относительно целей двигают каждое решение «пускать или нет», а не мнение.

Уровень 5: Оркестрация. Открытый исходный код непрерывно улучшаемый стратегический актив, интегрированный по организации. Соответствие полностью автоматизировано, а несоответствующие компоненты не могут достичь производства. Вы вкладываетесь намеренно в критичные проекты вверх по течению, рутинно вносите вклад и опекаете собственные хорошо ведомые проекты. Актуальностью зависимостей и концом срока службы управляют адаптивно по мере сдвигов риска и метрик, а открытость становится подлинным конкурентным и гражданским преимуществом.

Идеи для обсуждения

Где правильная линия между быстрым разрешительным умолчанием и контролем, нужным для избегания юридического долга и долга безопасности?
Когда организации следует финансировать или сопровождать критичную зависимость вверх по течению, а не воспринимать её как бесплатную?
Как решить, какие из ваших собственных компонентов стоит выпускать и опекать как открытый исходный код?
Для государственного сектора каков защитимый процесс освобождения компонентов от публикации по умолчанию, не разъедая принцип?
Как глубоко в транзитивные зависимости должна реалистично идти рецензия лицензий и безопасности?
Меняет ли сетевой копилефт (AGPL) ваш расчёт «строить или принять» для программного обеспечения, которое вы предлагаете как сервис?

Главные выводы

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

Источники и дополнительное чтение

Heather Meeker, Open (Source) for Business and Open Source for Business
Van Lindberg, Intellectual Property and Open Source
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
OpenChain (ISO/IEC 5230), Open Source Licence Compliance
Software Package Data Exchange (SPDX, ISO/IEC 5962) specification
CycloneDX SBOM specification
Free Software Foundation, GNU General Public Licence and GPL FAQ
Open Source Initiative, The Open Source Definition and approved licence list
Free Software Foundation Europe, Public Money, Public Code
U.S. Federal Source Code Policy and Code.gov guidance
UK Government, Technology Code of Practice and open-standards principles

10.3 Закупки, открытый исходный код и лицензирование

Обзор и мотивация

Ключевые принципы

Рекомендации

Задайте стратегию открытого исходного кода и политику потребления

Управляйте соответствием лицензиям, обязательствами и риском копилефта

Учредите Офис программы открытого исходного кода (OSPO)

Управляйте вкладом и, где уместно, публикацией

Выполняйте государственные мандаты на открытый исходный код и «общественные деньги, общественный код»

Управляйте зависимостями и программным обеспечением конца срока службы