
Лицензии GNU GPL: как пройти проверку Минцифры и заказчика для госзакупок и КИИ
Germanlawyer 1 час назад Лицензии GNU GPL: как пройти проверку Минцифры и заказчика для госзакупок и КИИ 6 мин 3.4K IT-компании Финансы в IT Бизнес-модели * Роадмэп Open source – это не юридическая тонкость, а...
В сфере искусственного интеллекта произошло заметное событие. Germanlawyer 1 час назад Лицензии GNU GPL: как пройти проверку Минцифры и заказчика для госзакупок и КИИ 6 мин 3. 4K IT-компании Финансы в IT Бизнес-модели * Роадмэп Open source – это не юридическая тонкость, а архитектурное ограничение. Сейчас даже среди юристов часто встречаются мнения, что опенсорс лицензии это чистая формальность, на которую не стоит обращать внимание.
В случае с GNU GPL и подобными лицензиями чем дольше вы игнорируете вопрос соблюдения их условий, тем вероятнее он выльется в невозможность:включения ПО в реестр российского ПОсоблюдения требований субъектов КИИ;получения грантов;участия в госзакупках;Все это приведет к срыву контракта с крупным заказчиком, даже если вы обо всем заранее договорились. Чтобы не быть голословным, приведу реальный кейс:Постановление Двадцать первого арбитражного апелляционного суда от 06. 2023 N 21АП-2261/2021 по делу N А84-2787/2020:Компания создала по гос.
Технические детали
руб систему межведомственного взаимодействия для Департамента цифрового развития города Севастополя. Заказчик отказался принимать результат работ из-за несоответствия ПО требованиям технического задания. В ходе экспертизы было установлено, что в ПО неправомерно используется библиотека Wildfly под лицензией GNU LGPL.
Суд встал на сторону Департамента, компания-разработчик не получила деньги и понесла 150 тыс. Чтобы с вами подобного не произошло, давайте на реальных кейсах разберём, как избежать дорогостоящего рефакторинга и юридических проблем на поздних этапах разработки. Каких лицензий можно не бояться, а каких лучше избегать2.
Что такое совместимость лицензий и почему за этим теперь нужно следить3. Как предупредить появление в коде заразных компонентов4. Что делать, если "заразные" элементы уже проникли в разработку5.
Отраслевые последствия
Каких лицензий можно не бояться, а каких лучше избегать? Лицензии, которые содержат условие о необходимости распространять производное ПО по той же лицензии, что и внедренный в код компонент (библиотеки, фреймворки, СУБД и пр. ), называются «заразными».
Они фактически заражают весь код своими условиями. Чаще всего имеются ввиду лицензии GNU GPL, но упомянутое требование может встречаться не только в них. Градацию лицензий GNU GPL по «опасности» для коммерческих продуктов можно представить так:ЛицензияЗаражение кода ПООбъем раскрытия исходного кодаУровень рискаLGPL v2, v3НетТолько часть кода, которая необходима для замены заразного компонентаНизкийGPL v2, v3ДаКод ПО, который вы распространяетеСредне-высокийAGPLДаВесь код ПО, который вы распространяете и к которому даете сетевой доступВысокийЯ всегда рекомендую заменять или удалять компоненты, которые распространяются по условиям лицензий GPL или AGPL, поскольку они довольно «жесткие» и не подходят для закрытых коммерческих проектов.
Об их условиях подробно уже писал тут.
Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.




