Open source – это не юридическая тонкость, а архитектурное ограничение. Сейчас даже среди юристов часто встречаются мнения, что  опенсорс лицензии это чистая формальность, на которую не стоит обращать внимание. 

В случае с GNU GPL и подобными лицензиями чем дольше вы игнорируете вопрос соблюдения их условий, тем вероятнее он выльется в невозможность:

• включения ПО в реестр российского ПО

• соблюдения требований субъектов КИИ;

• получения грантов;

• участия в госзакупках;

Все это приведет к срыву контракта с крупным заказчиком, даже если вы обо всем заранее договорились.

Чтобы не быть голословным, приведу реальный кейс:

Постановление Двадцать первого арбитражного апелляционного суда от 06.06.2023 N 21АП-2261/2021 по делу N А84-2787/2020:

1. Компания создала по гос. контракту на 12.1 млн. руб систему межведомственного взаимодействия для Департамента цифрового развития города Севастополя.

2. Заказчик отказался принимать результат работ из-за несоответствия ПО требованиям технического задания.

3. В ходе экспертизы было установлено, что в ПО неправомерно используется библиотека Wildfly под лицензией GNU LGPL.

4. Суд встал на сторону Департамента, компания-разработчик не получила деньги и понесла 150 тыс. руб. судебных расходов.

Чтобы с вами подобного не произошло, давайте на реальных кейсах разберём, как избежать дорогостоящего рефакторинга и юридических проблем на поздних этапах разработки.

Содержание

1. Каких лицензий можно не бояться, а каких лучше избегать

2. Что такое совместимость лицензий и почему за этим теперь нужно следить

3. Как предупредить появление в коде заразных компонентов

4. Что делать, если "заразные" элементы уже проникли в разработку

5. Итог

1. Каких лицензий можно не бояться, а каких лучше избегать?

Лицензии, которые содержат условие о необходимости распространять производное ПО по той же лицензии, что и внедренный в код компонент (библиотеки, фреймворки, СУБД и пр.), называются «заразными». Они фактически заражают весь код своими условиями. 

Чаще всего имеются ввиду лицензии GNU GPL, но упомянутое требование может встречаться не только в них.

Градацию лицензий GNU GPL по «опасности» для коммерческих продуктов можно представить так:

Я всегда рекомендую заменять или удалять компоненты, которые распространяются по условиям лицензий GPL или AGPL, поскольку они довольно «жесткие» и не подходят для закрытых коммерческих проектов. Об их условиях подробно уже писал тут.

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

2. Что такое совместимость лицензий и почему за этим теперь нужно следить?

Совместимость лицензий – это юридическая возможность объединять код или другие материалы, которые распространяются  под разными лицензиями, в один проект, не нарушая при этом условия ни одной из них

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

Чтобы было понятнее, покажем, как это выглядит на кейсах:

Кейс 1: Наш клиент потратил на разработку больше 100 миллионов рублей, осуществлялась она разными командами в течение 6 лет. Так как время нынче непростое, он поставил цель войти в реестр российского ПО, чтобы начать получать IT-льготы в 2026.

Когда мы провели аудит разработки, то выяснили, что технологический стек (далее – тех. стек) состоит из несовместимых друг с другом критических библиотек  (GPL v2, GPL v3).  Каждая из лицензий обязывает распространять производное ПО на своих условиях, что невозможно реализовать. Это является грубым нарушением лицензионных условий, из-за которого регистрация в реестре Минцифры невозможна  в исходном виде.

Что сделали? В результате нам удалось совместно с разработчиками клиента провести точечный рефакторинг и добиться достаточной изоляции компонентов друг от друга за счет специфической архитектуры ПО. Помогло создание отдельной директории, в реестр мы вошли.

Вывод: следите за версиями лицензий GNU GPL.

Следующий кейс описывает более экзотический случай, однако в связи с массовым внедрением ИИ проблема будет встречаться все чаще ввиду распространенности компонента. 

Кейс 2: Клиент разработал платформу для поиска в файлах вирусов и иных вредоносных элементов с помощью LLM-моделей. Главная цель – начать сотрудничество с крупным заказчиком, который требует факт регистрации в реестре Минцифры.

В процессе проверки тех. стека нами было выявлено, что в ПО содержатся библиотеки под заразной лицензией GNU GPL v2 и License Agreement for NVIDIA Software Development Kits, запрещающей раскрытие кода.

Такое сочетание привело к нелегальному использованию компонентов и, как следствие, долгому рефакторингу. В конечном счете нам удалось преодолеть препятствие с помощью замены компонентов и войти в реестр.

Вывод: вчитывайтесь в каждую лицензию и учитывайте соотношение ограничений.

Совместимость лицензий GNU можно отразить так:

3. Как предупредить появление в коде заразных компонентов?

3.1. Примите регламент со списком допустимых лицензий

Большинство компонентов распространяются по типовым лицензиям, что позволяет создать список «хороших» и «плохих»:

• MIT, Apache и BSD можно использовать без опаски. Главное выполнять базовые требования по типу упоминания авторов.

• В качестве среднерисковых выделим GNU LGPL и MPL, требующих оставлять код компонентов открытым, включая измененные версии.

• Среди высокорисковых следует выделить лицензии GNU GPL и AGPL. Они заражают весь код, поэтому их лучше просто не использовать.

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

3.2. Начните проводить регулярные аудиты тех. стека

Проводить аудит следует потому, что разработчик может что-то пропустить или не учесть. Делать это можно, например, ежеквартально тем же образом, как мы проверяем ПО клиентов перед регистрацией в реестре Минцифры.

Разработчики формируют список всех включенных опенсорс компонентов, которые они только что внедрили. Юрист проходится по лицензиям каждого и формирует мини-отчет, выделяя недопустимые. Если разработчику попадается нетипичная лицензия (ее нет в списке регламента), он направляет ее вне очереди на проверку юристу. Это позволит в зачатке купировать большинство рисков, связанных с лицензиями программных компонентов.

С учетом внедрения приведенных мер процесс разработки может выглядеть так:

4. Что делать, если копилефт все же проник в программу?

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

Итог

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

Я рекомендую: 

• минимизировать использование компонентов под GNU GPL И AGPL;

• принять регламент со списком запрещенных лицензий и провести обучение;

• внедрить в процесс разработки регулярный аудит лицензий компонентов.

Такие меры позволят быстро масштабировать продукты на рынке и привлекать крупных заказчиков с большими бюджетами.

Если статья вам пригодилась – подписывайтесь мой блог на Хабре или в телеграме. Там разбираю реальные кейсы из практики: что в Реестре проверяют, на чём заворачивают, какие льготы можно получить ИТ-компаниям и сколько это в реальных деньгах.

Вопросы по теме статьи – задавайте в комментариях, разберу каждый. Если ситуация специфическая и хочется обсудить отдельно – пишите в личку, отвечаю всем.