Технологический продукт может иметь юридические обязательства, о которых отдел продаж компании не знает. Такие обязательства могут возникнуть из-за простого решения, принятого в процессе разработки программного обеспечения: разработчик добавляет в проект бесплатную библиотеку, чтобы сэкономить неделю работы. Библиотека распространяется под лицензией, например, GNU General Public License, версия 2 (GPL-2.0). Продукт выпускается на рынок. Спустя годы, в ходе технической экспертизы, спора с клиентом или письма от правообладателя, компания обнаруживает, что преимущества этого решения были получены с нарушением условий лицензии, существовавших с момента первого выпуска продукта.
В данной статье рассматривается содержание этих условий, причины, по которым дела Cisco и Linksys остаются самым известным поучительным примером по этому вопросу, оценка этих лицензий судами в современной практике, а также действия, требуемые от компании, которая создает или приобретает программный продукт.
Что такое открытый исходный код:
Программа состоит из двух частей: исходного кода (того, что пишет разработчик) и готовой программы (того, что использует пользователь). В случае открытого исходного кода автор делится исходным кодом со всеми и разрешает им использовать, изменять и распространять его. Это разрешение прописано в лицензии и всегда сопровождается условиями .
Три распространенные ошибки:
«Открытый исходный код = каждый может делать все, что хочет». Нет. Программа защищена авторским правом, и разрешение также утрачивает силу в случае нарушения условий лицензии.
«Это бесплатно, то есть безусловно». Платить за это не нужно, но существуют определенные условия использования.
«Все продукты с открытым исходным кодом одинаковы». Нет. Лицензии сильно различаются, и именно это различие определяет степень риска, связанного с тем или иным компонентом.
2. «Бесплатно» не означает «безусловно».
Программное обеспечение с открытым исходным кодом обычно бесплатно, хотя его использование требует соблюдения правовых условий. Такая программа по-прежнему защищена авторским правом, и лицензия является единственным основанием, предоставляющим третьей стороне право копировать, изменять или распространять ее. Если условия лицензии не соблюдаются, разрешение больше не существует, и использование программы становится нарушением авторских прав. Грузинское законодательство основано на том же подходе: согласно подпункту «а» пункта 1 статьи 6 Закона Грузии «Об авторском праве и смежных правах», компьютерная программа считается литературным произведением, и согласно статье 19, автор имеет исключительное право давать разрешение или запрещать ее воспроизведение и адаптацию. В законе нет положения, согласно которому программа теряла бы защиту исключительно потому, что автор опубликовал ее в открытом доступе.
Лицензия GPL — это лицензия типа «копилефт». Её основное правило изложено в разделе 2(b) GPL-2.0: любое распространяемое произведение, содержащее программу полностью или частично или являющееся её производным, должно распространяться третьим лицам в полном объёме, бесплатно и на условиях той же лицензии. Раздел 3 устанавливает дополнительное практическое обязательство: при распространении программы в исполняемой форме она должна сопровождаться полным соответствующим исходным кодом или письменным предложением о его предоставлении, действительным не менее трёх лет.
Проще говоря, если продукт компании включает код, распространяемый по лицензии GPL, и компания распространяет этот продукт, она может быть обязана предоставлять пользователям не только используемый компонент, но и исходный код своего собственного продукта.
Часто неправильно понимаются два момента. Во-первых: обязательство возникает при распространении, а не при использовании. В тексте лицензии прямо указано, что запуск программы не ограничен. Во-вторых: наказание суровое. Согласно разделу 4, любая попытка скопировать, модифицировать, сублицензировать или распространять программу за пределами, разрешенных лицензией, является недействительной и автоматически прекращает права, предоставленные в соответствии с лицензией. Таким образом, компания-нарушитель не только нарушает условия соглашения, но и распространяет программу, на распространение которой у нее больше нет лицензии.
3. Дело Cisco и Linksys
В марте 2003 года Cisco согласилась приобрести Linksys, лидера рынка оборудования для домашних сетей, за 500 миллионов долларов в акциях. Самый продаваемый маршрутизатор Linksys, WRT54G, работал под управлением программного обеспечения на базе Linux. Через несколько месяцев в списке рассылки разработчиков ядра Linux появилось сообщение о том, что Linksys не предоставляет исходный код, требуемый лицензией GPL. В дело вмешался и Фонд свободного программного обеспечения (FSF). Linksys опубликовала исходный код программного обеспечения летом 2003 года. Этот инцидент теперь рассматривается как пример того, почему проверка благонадежности должна включать в себя и сам код: недостаток был обнаружен после завершения сделки.
Было бы неправильно списывать это дело на простую халатность. Ведущий эксперт по законодательству об открытом исходном коде, Хизер Микер, отметила тогда, что Cisco «должна была провести надлежащую проверку на трех уровнях интеграции продукта»: Linksys приобрела чипсеты у Broadcom, а Broadcom передала разработку программного обеспечения на аутсорсинг иностранному разработчику. Проблема возникла в цепочке поставок, поэтому ее трудно обнаружить.
Дело не закончилось в 2003 году. В декабре 2008 года Фонд свободного программного обеспечения (FSF) подал в суд на Cisco из-за продуктов Linksys, содержащих программное обеспечение, принадлежащее FSF, и в мае 2009 года спор был урегулирован. В соответствии с условиями соглашения, Cisco назначила в Linksys директора по свободному программному обеспечению для контроля за соблюдением условий лицензии. Компания также согласилась информировать предыдущих получателей продукта о правах, предоставляемых лицензией GPL, предоставить исходный код и выплатить FSF неопределенную сумму денег. Для юристов важно отметить, что соглашение касалось в первую очередь восстановления нарушенного состояния и репутации, а не единовременной крупной компенсации за ущерб. Кроме того, соглашение предусматривало бессрочные обязательства и обязывало приобретателя внедрить последовательную программу для соблюдения условий лицензии.
При заключении соглашения с разработчиком или аутсорсинговой компанией правила использования открытого исходного кода должны быть четко определены заранее, поскольку проблема обычно возникает на этапе разработки: разработчик выбирает библиотеку, а юрист компании часто узнает об этом выборе только после выпуска продукта. Важно точно сформулировать вопрос: использование открытого исходного кода само по себе не делает код общедоступным. Обязательства по лицензии GPL возникают при распространении программы, а не при ее использовании.
Либеральные лицензии, такие как MIT, вообще не требуют открытого доступа к исходному коду. Однако при распространении продукта, включающего компонент лицензии типа copyleft, компания может быть обязана передать исходный код своего продукта получателю, и получатель имеет право на дальнейшее распространение этого кода. Поэтому соглашение должно применяться не к «открытому исходному коду» в целом, а конкретно к тем лицензиям, которые представляют угрозу для вашей модели распространения продукта.
На практике соглашение должно включать три основных условия. Во-первых, разработчику должно быть запрещено использовать код, распространяемый под лицензиями GPL, LGPL, AGPL или аналогичными лицензиями copyleft, без письменного согласия заказчика. Требование предварительного согласия должно также распространяться на использование кода, распространяемого под любыми неизвестными или нестандартными лицензиями.
Во-вторых, разработчик должен предоставить заказчику полный список всех используемых компонентов с открытым исходным кодом, указав версию и лицензию каждого из них. Этот список должен быть частью документа о приемке продукта. Это требование особенно важно, поскольку компоненты с открытым исходным кодом, которые разработчик добавляет автоматически или из-за зависимостей от других компонентов, часто остаются незамеченными при традиционной проверке. Согласно отчету Black Duck за 2026 год, 17% компонентов с открытым исходным кодом попадают в кодовую базу без использования стандартных менеджеров пакетов, в том числе в виде скопированных фрагментов и кода, сгенерированного искусственным интеллектом.
В-третьих, в договоре также должен быть определен правовой режим кода, созданного с использованием искусственного интеллекта: разработчик должен раскрыть использование таких инструментов и подтвердить полученные результаты аналогичным образом, поскольку информация о происхождении кода и соответствующей лицензии может отсутствовать.
Для обеспечения соблюдения этих условий также необходимы соответствующие договорные механизмы. Разработчик должен подтвердить и гарантировать, что поставляемый продукт не содержит скрытых компонентов с открытым исходным кодом и не нарушает права третьих лиц. В случае нарушения он обязан возместить заказчику ущерб. Заказчик также должен иметь право на проверку и сканирование исходного кода как при получении продукта, так и в течение определенного периода после его поставки.
Такой подход напрямую вытекает из опыта Linksys: проблемы могут возникать и на третьем, и на четвертом звеньях цепочки поставок. Поэтому договорные условия и гарантии не должны ограничиваться прямым подрядчиком и должны распространяться также на субподрядчиков, нанятых застройщиком. Без такой защиты последствия нарушения лицензионного соглашения ложатся на заказчика, даже если нарушение происходит без его согласия.
