Чужой код, своя ответственность: лицензионная чистота, которую важно блюсти
Наша команда разрабатывает платформу безопасной разработки CodeScoring, в задачи которой входит автоматическая проверка критериев лицензионной чистоты анализируемого ПО на основании экспертной базы знаний. В статье рассматривается частный, но показательный случай: когда вендорское решение основано на известном открытом проекте, распространяющемся на условиях копилефт-лицензий. Материал сопровождается примером и набором правил для самопроверки, которые позволят увереннее контролировать юридические риски и риски безопасности в цепочке поставок ПО.Рассмотрим ситуацию, когда продукт, построенный на открытом решении, складывается из работы двух команд. Первая развивает исходный проект, вторая берёт его за основу, добавляет свою функциональность и сопровождает заказчика. Пока релизы открытого проекта выходят регулярно, это разделение обычно всех устраивает. Вендор переносит исправления, заказчик получает обновления, и вопрос о том, кто на самом деле отвечает за основу проекта, задается нечасто.Между тем ответ на этот вопрос существует, и записан он в лицензии исходного проекта. Вендора в ней обычно интересует первая часть, где сказано, что код можно использовать, менять и распространять. Однако у лицензий с копилефтом есть и вторая часть, где перечислены обязанности того, кто распространяет код дальше. Она определяет, что вендор обязан раскрыть, на каких условиях он может распространять собственные модули и кто отвечает перед заказчиком за продукт, если к нему предъявят претензии, притом что сам исходный проект от гарантий и ответственности отказывается. Именно эта часть и превращает сопровождение чужого кода в ответственность вендора. Помнят о ней не все и не всегда, потому что повод появляется обычно тогда, когда исходный проект меняет лицензию. Читать далее