Иски за нарушение лицензий open source: почему растет их число

Это означает, что в каждом втором корпоративном проекте, использующем open source, существует как минимум одна строка кода, чьи условия распространения формально нарушены — не раскрыт исходник, не сохранена атрибуция, не выполнено требование копилефта (обязывающего производные работы наследовать ту же открытую лицензию). На фоне этой цифры судебные иски последних лет перестают выглядеть как случайные инциденты — они становятся закономерным следствием того, как устроена современная разработка.

Рост числа исков — это не попытка «задушить» свободное ПО и не ужесточение законодательства. Законы остались прежними. Меняется инфраструктура: открытый код окончательно перестал быть нишевым инструментом энтузиастов и превратился в фундамент коммерческого софта. Чем глубже он врастает в продукты, тем чувствительнее становятся конфликты вокруг его условий — и тем чаще эти конфликты доходят до суда.

От деклараций к обязательствам: эволюция судебной практики

Долгое время, примерно до середины 2000-х, открытые лицензии воспринимались сообществом скорее как декларация о намерениях, чем как полноценный юридический договор. Вопрос «а что будет, если условия нарушат?» обсуждался в основном теоретически. Эта неопределённость закончилась в 2008 году, когда Апелляционный суд США по делу Jacobsen v. Katzer впервые прямо сформулировал: условия открытых лицензий — это юридически обязательные условия использования объекта авторского права, а не декаративные пожелания автора.

Суть этого решения, если посмотреть на его архитектуру, важна для всей последующей практики. Суд разделил два понятия, которые до этого смешивались: нарушение условий лицензии (breach of contract) и нарушение авторского права (copyright infringement). До Jacobsen v. Katzer использование GPL-кода без соблюдения условий можно было трактовать как «пользуемся бесплатно, и ладно». После решения стало ясно: условия лицензии — это встречное предоставление, без которого само право использования не возникает. Если вы их не выполняете, вы используете код без правового основания — точно так же, как если бы вы использовали проприетарный (закрытый, частный) софт без лицензии.

Прецедент Jacobsen v. Katzer превратил открытую лицензию из манифеста в контракт: пока условия выполнены, код свободен; стоит их нарушить — использование становится нелегальным.

Параллельно аналогичная логика закреплялась в Европе. В Германии первый судебный запрет за нарушение открытой лицензии был вынесен ещё в 2004 году, и с тех пор немецкие суды стабильно квалифицируют такие нарушения как ущемление авторских прав. Сегодня этот подход стал общеевропейским стандартом: берлинское решение по делу Steck v. AVM в июне 2024 года опирается именно на эту двадцатилетнюю традицию.

Экономика конфликтов: кто и за что судится

Картина «кто подаёт иски» за последние пятнадцать лет изменилась радикально. Если в 2000-х истцами выступали почти исключительно организации-правозащитники открытого ПО — фонд Software Freedom Conservancy, Free Software Foundation, проект GNOME — то сегодня в суд идут самые разные игроки, и мотивация у каждого своя.

Структура современных исков выглядит так:

Кейс SFC v. Vizio, поданный в октябре 2021 года в суд Калифорнии, — поворотная точка. До него истец всегда был связан с кодом лично: автор, правопреемник или организация-хранитель проекта. В иске против Vizio Software Freedom Conservancy впервые выступил от имени конечных пользователей — покупателей SmartCast TV, которые по условиям LGPL являются бенефициарами лицензии. Однако важно понимать: статус третьестороннего бенефициара и возникающее на его основе право на иск не появляются автоматически у каждого покупателя устройства с закрытой прошивкой, содержащей GPL- или LGPL-код. Такой статус зависит от конкретных условий лицензии, правопорядка и того, как суд квалифицирует интерес конечного пользователя. Прецедент Vizio открыл дверь, но не сделал процесс автоматическим.

Иск CoKinetic Systems против Panasonic Avionics показывает другую грань. Здесь истец — прямой коммерческий конкурент, требующий возмещения ущерба на сумму свыше $100 млн. Мотивация — не идеология свободного кода, а конкурентное преимущество: соблюдение лицензии обязывает раскрыть исходники, а это, в свою очередь, позволяет конкуренту детально изучить архитектуру продукта. Так экономика открытого ПО напрямую переплетается с конкурентной разведкой.

Дело Steck v. AVM, завершившееся в Берлине в июне 2024 года, — кейс из другой лиги. Частный разработчик Sebastian Steck обнаружил свой код в проприетарной прошивке роутеров Fritz!Box, подал иск и получил €7,500 возмещения судебных расходов. Сумма скромная, но сам факт принципиален: суд подтвердил, что для подачи иска не нужно быть юридическим лицом или иметь коммерческий интерес. Достаточно того, что ваш код использован с нарушением условий — и вы способны это доказать.

Ловушка транзитивных зависимостей

Почему 53% проверенных кодовых баз содержат лицензионные конфликты? Не из-за злого умысла разработчиков — из-за архитектуры современного процесса сборки.

Суть явления, если объяснить его «под капотом», такова. Когда инженер подключает к проекту одну библиотеку, та тянет за собой две-три зависимости, каждая из которых — ещё по зависимости. Менеджер пакетов (npm, Maven, pip, Cargo) строит граф зависимостей на десятки и сотни узлов. На каждом узле висит файл LICENSE с условиями, которые разработчик обычно не читает. Он доверяет инструменту, а инструмент не проверяет совместимость условий между разными лицензиями в графе.

Возьмём практический сценарий. В корпоративный продукт подключается популярная библиотека под MIT — пермиссивной лицензией, позволяющей свободно использовать, модифицировать и перелицензировать код. Библиотека под MIT вполне совместима с GPLv3: код, распространяемый по MIT, легально включается в GPLv3-проекты. Проблема возникает в обратную сторону — когда внутри этой библиотеки лежит модуль, форкнутый (скопированный из другого репозитория для самостоятельной разработки) из проекта под GPLv3, а весь продукт остаётся проприетарным. GPLv3 обязывает предоставлять исходный код производного произведения при его распространении, и конкретные последствия зависят от того, как компонент включён в проект — через статическую или динамическую линковку, составляет ли он часть единого исполняемого модуля. Разработчик об этом не знает — он просто импортировал пакет. Через полгода код уходит в релиз, через год — в суд. Иск будет обоснованным: формально условия лицензии нарушены, и не имеет значения, что нарушитель не понимал, что нарушает.

OSSRA фиксирует это как системную, а не точечную проблему. Отчёт сканирует кодовые базы автоматическими инструментами и обнаруживает конфликты, которые человек при обычном ревью кода не увидит. Значительная доля из этих 53% приходится именно на транзитивные зависимости — компоненты, которые попали в проект автоматически вместе с явно подключённой библиотекой.

Значительная часть лицензионных конфликтов в коммерческом коде — это не сознательный выбор разработчика, а побочный эффект автоматического графа зависимостей.

Это объясняет, почему традиционные юридические отделы не справляются. Они анализируют прямые лицензии, которые видит разработчик. Проблема прячется на два-три узла глубже в графе, и для её обнаружения нужны инструменты класса SCA (Software Composition Analysis — автоматический анализ состава программного обеспечения), такие как Black Duck или FOSSA. Без них компания узнаёт о конфликте либо из отчёта SCA-сканера, либо из искового заявления.

Почему пермиссивная лицензия — это не индульгенция

Широко распространённое заблуждение звучит примерно так: «если мы берём код под MIT или Apache 2.0, то у нас нет никаких обязательств, кроме упоминания авторства». Это верно лишь отчасти, и именно на этой «отчасти» строятся всё новые судебные иски.

Анализ 47 судебных дел по енфорсменту (принудительному исполнению условий) open source лицензий за 2008–2023 годы, проведённый исследователями лицензионной практики, показал любопытную динамику. Подавляющее большинство исков — 28 из 47 — связаны с GPLv2. Это объясняется прежде всего масштабом её распространения: GPLv2 десятилетиями остаётся основной лицензией для критически важной инфраструктуры — от ядра Linux до утилит GNU. Другие копилефтные лицензии, в том числе AGPL, накладывают дополнительные обязательства, связанные с сетевым взаимодействием, — но исков по ним пока значительно меньше, отчасти потому, что их доля в проверяемых кодовых базах ниже.

При этом число исков по пермиссивным лицензиям (то есть разрешительным — дающим минимальные ограничения) растёт быстрее всего: 4 из 6 дел по MIT были поданы в период с 2018 по 2023 год. Причина этих исков почти всегда не в нераскрытом исходном коде (это требование копилефта, у MIT его нет), а в удалении копирайт-уведомлений и имён авторов из кода перед включением в проприетарный продукт. Юридически условие «сохрани уведомление об авторских правах» — это встречное предоставление по лицензии. Если вы его убираете, вы лишаетесь права использования — так же, как в случае с GPL, только срабатывает механизм через другое условие.

Для бизнеса это означает конкретную операционную задачу. Прежде чем поставлять бинарный дистрибутив (скомпилированную, нечитаемую человеком версию программы), нужно убедиться, что в нём сохранены все оригинальные файлы NOTICE и LICENSE из каждой MIT-библиотеки. Если скрипт сборки их вырезает — формально лицензия нарушена, и при достаточном масштабе использования это повод для иска.

Открытый код в российской правовой системе

В России открытое ПО долгое время существовало в своеобразной серой зоне. С одной стороны, Гражданский кодекс признаёт авторское право на программы для ЭВМ и допускает свободное использование только в случаях, прямо указанных в законе. С другой — специального регулирования именно open source в российском праве не было, и суды часто трактовали открытые лицензии как «обычные лицензионные договоры», применяя к ним общие нормы.

Точку в этом вопросе поставил Конституционный Суд РФ постановлением от 16 июня 2022 года № 25-П по делу Антона Мамичева. Разработчик создал программу с использованием компонентов Open Source и столкнулся с нарушением своих прав со стороны бывшего работодателя, который использовал код без соблюдения условий исходной лицензии.

КС РФ подтвердил несколько принципиальных позиций. Во-первых, открытая лицензия — это разновидность лицензионного договора в смысле ГК РФ, и к ней применимы общие нормы о договорных обязательствах. Во-вторых, нарушение условий открытой лицензии квалифицируется как нарушение исключительного права, а не как «пользовательское» нарушение, к которому применяются мягкие санкции. Это ставит российскую практику в один ряд с американской и европейской: открытый код защищён ровно так же, как проприетарный.

Для разработчиков на территории России это означает следующее. Условия GPL, MIT, Apache и других стандартных открытых лицензий признаются судами как обязательные. Использование открытого кода в коммерческом продукте без раскрытия исходников (для копилефтных лицензий, когда код интегрирован способом, создающим производное произведение) или без сохранения атрибуции (для пермиссивных) даёт правообладателю основание для иска. При этом подсудность конкретного спора зависит от множества факторов — статуса сторон, предмета спора, наличия или отсутствия иностранного элемента. В ряде случаев защита интересов правообладателя возможна и в российском арбитражном суде, но такой результат не гарантирован и определяется конкретными юрисдикционными обстоятельствами.

Что стоит за ростом исков и что с этим делать

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

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

Второй — экономический. Стоимость иска выросла настолько, что судиться стало выгодно. Дело CoKinetic Systems против Panasonic Avionics с претензией более $100 млн превращает лицензионный спор в крупный коммерческий конфликт, в котором есть что делить.

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

Лицензионный риск в open source сместился из категории «юридическая экзотика» в категорию «стандартный операционный риск разработки ПО». Это означает, что с ним нужно работать так же, как с любым другим операционным риском — через процессы, инструменты и политики, а не через разовые юридические консультации.

Для команд, ведущих коммерческую разработку с использованием open source, ситуация требует трёх конкретных изменений.

1. Ввести автоматическое SCA-сканирование на этапе CI/CD (непрерывной интеграции и доставки — пайплайна, через который проходит каждая сборка кода). Это не опциональная мера: при такой плотности конфликтов ручная проверка лицензий физически не успевает за обновлениями зависимостей.

2. Разделить в политике компании риски по типу лицензии. LGPL допускает использование в проприетарном ПО при условии, что библиотека подключена определённым образом (например, через динамическую линковку) и что пользователь может заменить LGPL-компонент. GPL и AGPL требуют раскрытия исходного кода при включении компонента в состав производного произведения — конкретные обязательства зависят от способа интеграции и условий распространения. Пермиссивные лицензии (MIT, Apache, BSD) — это прежде всего обязательство сохранить атрибуцию. Разные риски требуют разных процедур.

3. Зафиксировать в лицензионной политике список запрещённых к подключению лицензий для определённых сценариев. Например, AGPL для SaaS-продуктов обязывает предоставлять пользователям исходный код модифицированной версии при сетевом взаимодействии — это ограничение, которое необходимо учитывать при выборе модели распространения; некоторые компании намеренно идут на эти обязательства, другие исключают AGPL из допустимого списка. Такие решения должны приниматься осознанно на уровне политики, а не обнаруживаться случайно при аудите.

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