Две недели назад популярный JavaScript-инструмент Lerna подвергся драматическим потрясениям. Один из первоначальных основателей и мейнтейнеров проекта Lerna предложил изменить лицензию с обычной MIT на MIT с персональными исключениями в целях предотвращения определенных компаний-разработчиков программного обеспечения, включая Microsoft, Amazon, Apple, LinkedIn, Walmart, Target. , Tesla, Xerox, Dell и другие, от использования Lerna. Другие сопровождающие изначально одобрили это предложение, и изменение было реализовано. Хорошая новость заключается в том, что изменение в конечном итоге было отменено.

Помимо причин, это изменение вызвало серьезную неразбериху среди пользователей Lerna. Некоторые выразили озабоченность; а другие требовали убрать своего работодателя из черного списка; было даже предложено прекратить использовать Лерну. Ряд контрибьюторов даже требовали удалить свои вклады из кода, ну и, конечно же, кто-то вообще разветвил проект. Этот инцидент из реальной жизни — хороший пример такого рода сюрприза, который вы не хотите испытывать, и того, как вы могли бы легко быть предупреждены об этом в режиме реального времени.

Так зачем паниковать?

Можно утверждать, что изменение лицензии будет применяться только с этого момента? Не могут ли Dell или Xerox просто придерживаться текущей версии и не использовать программное обеспечение с опасной лицензией? Разве они не могут заблокировать версию зависимостей? Ну, все сводится к тому, знали ли они, что им нужно это сделать. Это не всегда так. Фиаско с Lerna получило широкую огласку, и разработчики этих компаний, вероятно, узнали об этом и заблокировали зависимости, но что, если бы они этого не сделали?

В то время как вся отрасль уже осознала, что слепое использование последней версии опасно и его следует избегать, большинство разработчиков в мире JavaScript по-прежнему используют гибкую младшую версию и версию исправления. Давайте посмотрим на дескриптор package-lock.json самого проекта Lerna (или почти любого другого программного проекта, использующего npm). Большинство зависимостей объявляются с использованием диапазона курсора для автоматического выбора последней минорной версии и версии патча.

Почему вы должны заботиться?

Теперь вы видите проблему, не так ли? Если какая-либо из компаний из черного списка пропустит новость, они нарушат условия лицензии. Просто недостаточно проверять лицензию при выборе необходимой библиотеки, а затем использовать диапазоны, чтобы оставаться в курсе исправлений ошибок и второстепенных выпусков.

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

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

Как вы можете защитить себя?

Единственный способ быть в курсе исправлений ошибок и дополнительных версий, а также поймать изменения лицензии или новые уязвимости безопасности, появившиеся в этих новых выпусках, — это непрерывно сканировать весь граф зависимостей во время сборки. Такие инструменты, как JFrog Xray, обеспечивают непрерывную безопасность и анализ артефактов и позволяют вам определять политики (например, только известные и принимать перечисленные лицензии. Никакие уязвимости безопасности выше «тривиальных не допускаются в артефактах и ​​во всем дереве переходных зависимостей), а затем применять эти политики для каждого артефакта, загруженного в ваш репозиторий артефактов во время каждой сборки.

Если у вас есть эта система, вы можете спать спокойно. Когда произойдет следующее скрытое изменение лицензии, продвижение конвейера CI не удастся, и вы сможете изучить свои варианты — переключиться на форк, найти альтернативу, подтолкнуть сопровождающих к отмене изменения (как это произошло с Lerna). Вы контролируете ситуацию.