Как решать проблемы защиты авторских прав в цифровых продуктах, созданных на основе открытого кода

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

Например, автор А создал программу, а автор Б ее украл и выложил под open source. Ваша компания использует ее по open source лицензии автора Б. В такой ситуации автору А ничто не мешает обратиться в суд и потребовать как минимум запрета на использование этой программы и компенсации.

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

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


Дело Антона Мамичева

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

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

В 2019 году Санкт-Петербургский городской суд вынес решение: признать Мамичева автором программы, признать за ним исключительное право на ее использование и взыскать компенсацию за удаление информации об авторстве и использование программы с удаленным знаком охраны авторского права. Однако в 2020 году решение суда первой инстанции о выплате компенсации было отменено. Суд сослался на то, что Мамичев нарушил условия использования программных библиотек по GPL-лицензии. Поэтому суд пришел к выводу, что и права на свою (производную) программу Мамичев не вправе защищать.

Сейчас жалоба Антона Мамичева принята к производству Конституционным судом.

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

Это системная проблема — непонятно, что делать с производными произведениями, внутри которых есть какой-то элемент, который был получен нелегально или права на который были утрачены (например, из-за нарушения лицензии). Была программа А, ее включили в программу Б. Можем ли мы использовать программу Б, если мы нарушаем права на программу А? Можем ли мы защищать права на программу Б? Российская практика по этому вопросу еще не сложилась, а правовое поле недостаточно отрегулировано.


Судебная практика


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

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


Юридические проблемы


1. Проблема установления авторства кода. Когда кто-то выложил исходный код и прикрепил к нему лицензию, сложно доказать, что именно он является автором и настоящим правообладателем. Это касается любого контента и объектов, которые распространяются через сеть. Не могу сказать, что мы с ней часто сталкиваемся — у случайных людей доступ к исходному коду бывает довольно редко. Но мы всегда предупреждаем о таком риске.

Важно учитывать, что сотрудники, которые пишут код, могут оказаться недобросовестными; например, можно взять код с GitHub и проигнорировать открытую лицензию либо позаимствовать код у прошлого работодателя. Поскольку отвечать за нарушение придется работодателю, крупные компании, в том числе связанные с государством, вынуждены создавать системы внутреннего контроля. Это сложная задача, не только юридически, но и организационно, технически. Необходимы комплексные решения.

2. Нарушение условий распространения. Собираясь использовать программу в составе продукта, нужно понять, как условия ее открытой лицензии повлияют на продукт, частью которого она станет. Если продукт предполагается использовать внутри компании, риск невелик. Невелик он и при использовании программы в модели SaaS (Software-as-a-Service), когда доступ к итоговому продукту предоставляется через веб-интерфейс. Многие open source лицензии не ограничивают использование в формате SaaS, в том числе и GPL-лицензия, которая относится к числу «строгих».

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

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

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


Требования к отечественному ПО


Государственная структура с точки зрения юридической ответственности ничем не отличается от остальных. Особенности сектора связаны с условиями приобретения конкретного продукта. В связи с требованиями закупать ПО российского происхождения большое значение приобретает наличие программы в реестре отечественного ПО. В этот реестр могут включаться в том числе и продукты, созданные на базе open source решений. Например, вариации Linux-подобных систем.

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

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

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

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

Рекомендации, связанные с открытыми лицензиями, публикуют Центр компетенций по импортозамещению в сфере ИКТ, Free Software Foundation, Open Source Initiative. Также можно обратить внимание на ресурсы, которые посвящены Mozilla. Многие авторы программ находятся за рубежом, в том числе в западных странах. На них могут действовать все санкционные ограничения. В тексте открытой лицензии эти вопросы напрямую не урегулированы. Неофициальную позицию о том, придерживаются ли экспортных ограничений конкретные объединения в сфере open source, можно посмотреть на сайтах сообществ свободного ПО.


Матрица рисков


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

За последние семь лет увеличилось число юристов, которые специализируются в сфере ИТ, интеллектуальной собственности, так что найти специалиста теперь не такая большая проблема, как раньше. Это особенно важно, если ваша организация претендует на инвестиции или гранты. Чем тщательнее вы проверите юридическую чистоту своего продукта и всех его компонентов, тем выше будет его ценность, в том числе для инвесторов. Никто не будет вкладывать средства в продукт, который завтра могут запретить через суд.

Государство тоже обратило внимание на вопросы свободного ПО. Эти вопросы во многом актуализировались из-за санкций и, например, блокировки российских пользователей на GitHub.

Как я понимаю, Минцифры, во-первых, планирует создать национальный репозиторий. С точки зрения безопасности это, безусловно, разумный подход. Чем он еще может быть интересен участникам рынка? Отчасти это снимет проблему анонимности размещения кода в системе, например, если аккаунт в репозитории будет привязан к ЕСИА («Госуслугам»). Как я уже говорил, это не решает всех проблем. Так, вопрос о том, является ли конкретное ПО служебным (то есть кто им распоряжается: работник или работодатель) невозможно решить одной лишь системой авторизации — это требует юридической экспертизы.

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

Очень важно, чтобы итоговый текст лицензии остался совместимым с другими лицензиями на свободное ПО. Кроме того, «гослицензия» должна быть максимально либеральной, то есть не ограничивать коммерциализацию софта, как это сделано в GPL. Только так можно будет добиться наибольшего экономического эффекта.

Записала Алиса Орлова