Исследования показывают, что 98% компьютерных программ содержат в себе open source, или открытое (свободное1) программное обеспечение. При этом программы в среднем на 75% состоят из open source компонентов. Открытое программное обеспечение распространяется с исходным кодом, то есть с текстом программы, написанном на языке программирования и доступном для восприятия человеком. Задумано это для того, чтобы пользователи open source могли свободно использовать, изучать, модифицировать и распространять программу. Гарантом свобод выступают открытые лицензии, под которыми распространяются open source программы. Лицензии также накладывают ограничения, которые защищают пользователей open source, в чем выражается их отличие от инструментов классического авторского права, нацеленного на защиту интересов авторов. Для этого сторонники open source используют термин copyleft (дословно – «авторское лево»).
Повсеместность использования open source влечет технические риски уязвимости и устаревания ПО и юридические риски, которые выражаются в растущем числе судебных споров, выявлении множества нарушений в ходе предынвестиционных проверок и аудитов для регистрации продукта в реестре российского ПО (Методические рекомендации по подготовке заявок на включение ПО в Единый реестр). Несмотря на это многие организации до сих пор предпочитают игнорировать вопросы, связанные с открытым ПО. Непонимание существа отношений по использованию open source иногда демонстрируют и государственные органы и суды. Поэтому теоретико-практическое осмысление правовой природы свободного программного обеспечения и открытых лицензий остается актуальным.
Открытые лицензии традиционно разделяют на три вида: пермиссивные, слабые копилефтные и сильные копилефтные лицензии. Пермиссивные лицензии (BTD, Apache 2.0) предоставляют пользователям полную свободу использовать, модифицировать и распространять программы, в том числе и созданные на их основе, на любых условиях. Взамен пользователь обязан лишь уведомить приобретателей об условиях лицензии и авторах open source. Слабые копилефтные лицензии (MIT, LGPL) отличаются от пермиссивных тем, что open source компоненты должны распространяться на оригинальных условиях. И наконец, сильные копилефтные лицензии (семейство GPL) накладывают на пользователей дополнительные обязанности раскрывать исходный код и лицензировать на условиях оригинальной лицензии не только open source компоненты, но и все производные работы, созданные на их основе.
Прежде чем приступить к обсуждению отдельных проблемных аспектов использования open source, следует обосновать применимость к открытым лицензиям норм российского права, так как большинство из них не содержит положений о применимом праве (п. 9 ст. 1211 Гражданского кодекса). Коллизионная норма, которая содержится в п. 8 ст. 1211 ГК РФ, неприменима к open source проектам, поскольку на стороне лицензиара открытого ПО обычно выступает множество лиц. Следовательно, нужно опираться на принцип наиболее тесной связи (п. 9 ст. 1211 ГК РФ). Так, в контексте open source выбор применимого права может обосновываться местом нахождения фонда, поддерживающего open source проект, или территорией страны, в которой происходило использование свободного ПО. Таким образом, российское право будет применяться к открытым лицензиям тогда, когда open source используется на территории или лицом с местом нахождения в РФ. В отношении же интеллектуальных прав на открытое ПО российское право будет применяться всякий раз, когда защита программы испрашивается в РФ (lex loci protectionis) (п. 9 ст. 1211 ГК РФ).
Создание производных произведений на основе open source
Разработка новых программ с использованием open source сопряжена с соблюдением требований открытых лицензий, в первую очередь, это актуально в отношении копилефтных лицензий.
Открытые лицензии или не содержат определение производного произведения, или используют определения, отличные от национального законодательства, поэтому при разрешении спора российский суд будет применять легальное понятие производного произведения, под которым понимается произведение, созданное в результате переработки оригинального произведения (п. 2 ст. 1259 ГК РФ). Частным случаем переработки является модификация программы, то есть внесение в нее любых изменений, в том числе перевод такой программы с одного языка программирования на другой язык (п. 2 ст. 1270 ГК РФ). Законодатель различает модификацию и адаптацию программы, которая означает внесение изменений исключительно в целях функционирования программы на конкретных технических средствах пользователя или под управлением конкретных программ пользователя. Адаптация программы допускается без согласия автора и выплаты вознаграждения.
Законодательное определение модификации программы вызывает определенные нарекания, поскольку критерий модификации не отвечает общему стандарту творчества для предоставления правовой охраны. Кажется очевидным, что минимальные изменения кода не образуют самостоятельного произведения. Вместе с тем судебная практика по данному вопросу противоречива (Постановление Суда по интеллектуальным правам от 6 августа 2019 г. по делу № А60-46975/2016, Постановление Арбитражного суда Московского округа от 20 сентября 2018 г. по делу № А40-233720/17). Эту проблему пытались решить специалисты из Сколково, предложив ввести понятие версии компьютерной программы, которая не является самостоятельным объектом, но данный законопроект не был поддержан.
Неясность в отношении того, является ли любая модификация программы самостоятельным произведением, порождает практические трудности. Предположим, что автор разместил проект на Github, где любое лицо вправе создать на основе форка, то есть копии исходного кода, новую версию программы. Если автор проекта одобряет предлагаемые изменения, они вносятся в оригинальный код. В ситуации, когда любая модификация программы является самостоятельным произведением, она может использоваться в проекте только с согласия разработчика (п. 4 ст. 1260 ГК РФ). При постоянном развитии open source проекта, в которых участвуют сотни разработчиков, права на каждую новую версию, таким образом, должны консолидироваться. При этом использование открытой лицензии не всегда обеспечивает достижение этой цели2. Для решения проблемы разработчики обычно заключают лицензионное соглашение участника (contributor license agreement), по которому они отчуждают права на свои версии руководителю проекта. В отсутствие таких индивидуальных соглашений права на модификации можно консолидировать на основе «входящей=выходящей лицензии» (inbound = outbound license) и «подразумеваемой лицензии» (implied license). Первая конструкция лицензионного договора предполагает, что любая модификация ПО автоматически распространяется под лицензией конечного продукта. Однако, чтобы признать ее существование, нужно доказать, что автор модификации знал или должен был знать об условиях оригинальной лицензии и выразил согласие предоставить такую лицензию любому лицу в будущем. Подразумеваемая лицензия, как следует из названия, выводится из поведения сторон, а для придания ей юридической силы необходимо установить подразумеваемую волю автора, но такая возможность по российскому праву отсутствует3.
Проблема консолидации прав на каждую версию программы может быть решена посредством применения норм о соавторстве. Вместе с тем применение режима соавторства к open source чревато некоторыми неудобствами: невозможностью распорядиться правом без согласия всех соавторов и выделить доли в исключительном праве. Использовать такую программу тем не менее допустимо, так как закон гласит, что соавтор не вправе без достаточных оснований запретить использование произведения, если оно образует неразрывное целое (п. 2 ст. 1258 ГК РФ). Программное обеспечение, хоть оно и не всегда является единым целым, можно считать таковым для целей этой нормы, поскольку последствия запрета на использование отдельного компонента могут привести к невозможности использовать ПО в целом и к необоснованно высоким убыткам других соавторов и пользователей. Применение режима соавторства также минимизирует негативные последствия «копирайт-троллинга», поскольку по общему правилу доходы от использования произведения делятся между авторами поровну, а следовательно, злоумышленник не сможет претендовать на получение какой-либо выгоды (п. 3 ст. 1229 ГК РФ). Режим соавторства однако нельзя применять в ситуациях, когда при создании проекта используется открытое ПО третьих лиц, поскольку они не вносят творческого вклада в проект и не имеют намерения становиться его соавторами.
Вернемся к исходному вопросу о критериях модификации программы и обратимся к судебной практике. Для определения модификации суды исходят из того, служат ли изменения основанием для появления новых функций в программе, модулей или существенных усовершенствований уже существующих функций (Постановление Девятого арбитражного апелляционного суда от 18 февраля 2016 г. по делу № А40-45539/13). Так, в одном из дел суд при назначении экспертизы разъяснил, что модификация свидетельствует об «изменении функциональности программы, появлении новых свойств и возможностей программы, автоматизации неавтоматизированных ранее ручных операций, иных доработках, выходящих за пределы адаптации программы для ЭВМ» (Решение Арбитражного суда города Москвы от 8 августа 2016 г. по делу № А40-154016/2014).
Стоит, однако, учитывать количественное соотношение заимствуемого и оригинального кода, так как использование библиотеки из 5 строк вряд ли превращает новую программу в производное произведение. Более того, включение кода de minimis иногда необходимо для обеспечения совместимости двух программ – например, включение заголовочного файла в исходный текст для вызова библиотеки в процессе исполнения программы. M. Stotlz отмечает, что в таком случае переработка или воспроизведение программы не осуществляется. При этом соотношение оригинального и заимствуемого кода должно оцениваться в каждом конкретном случае, поскольку введение универсального стандарта заимствований невозможно (Постановление Семнадцатого арбитражного апелляционного суда от 1 сентября 2021 г. по делу № А60-46975/2016).
Признаки модификации, которые описаны выше, применимы в ситуациях, когда изменения вносятся непосредственно в код оригинальной программы или open source продукта. Гораздо чаще на практике open source компоненты интегрируются с другими программными продуктами в составе комбинированного программного обеспечения. Несмотря на то, что текст open source библиотек может не претерпевать изменений, комбинированное ПО при определенных обстоятельствах будет считаться производным произведением от его составляющих, а следовательно, должно распространяться на условиях открытой лицензии.
Open source компоненты могут распространяться вместе с иным программным обеспечением в составе сборника, отдельные элементы которого хоть и могут использоваться совместно, но независимы друг от друга, – например, операционная система с предустановленными программами сторонних разработчиков. Производное произведение в таком случае не возникает, но такой сборник может получить охрану в качестве составного произведения (п. 2 ст. 1261 ГК РФ). Например, в деле № А40-233720/17 арбитражный суд установил, что программный продукт, состоящий из ПО собственной разработки и интегрированной с ним программы третьего лица, является составным произведением, а не модификацией (Постановление Арбитражного суда Московского округа от 20 сентября 2018 г. по делу № А40-233720/17). Еще один пример – дело А. Мамичева, которое касалось определения принадлежности прав на программное обеспечение, созданное Мамичевым во время работы в компании Veeam. В составе ПО разработчик использовал open source библиотеки, которые распространялись под лицензией GNU GPL v2. Апелляционный суд счел, что ПО было составным произведением, а код, созданный Мамичевым, использовался исключительно для связи библиотек. Исходя из представленных в открытом доступе материалов дела, этот вывод вызывает сомнения, поскольку ПО являлось самостоятельным и по сути новым продуктом.
Поскольку каждый элемент составного произведения сохраняет самостоятельность, открытые лицензии, под которыми распространяются open source компоненты, не действуют в отношении составного произведения. Дистрибуция такого ПО может осуществляться под «составной лицензией». Например, «Базальт СПО» распространяет дистрибутивы своих операционных систем, в состав которых входит open source, под проприетарными (то есть собственными) лицензиями, предметом которых является ПО в целом как составное произведение. Важно уточнить, что «составные лицензии» не должны ограничивать действие открытых лицензий на open source компоненты.
Возможна иная ситуация, при которой open source компоненты могут не включаться в исходный код оригинальной программы, а связываться с другими библиотеками и модулями, предназначенными для совместной работы. Связывание подразумевает, что программа «вызывает» другую программу в необходимый момент. Так, программные компоненты могут быть связаны друг с другом статически. Статическое связывание происходит в результате компоновки программы, то есть соединения программных файлов для создания единого исполняемого файла в виде объектного (машиночитаемого) кода. По этой причине статическое связывание свидетельствует в пользу создания производной программы4.
Динамическое связывание отличается от статического тем, что запрашиваемая библиотека вызывается во время выполнения программы, а не компоновки. При этом обе программы являются независимыми, поскольку не образуют единый исполняемый файл. Однозначного ответа на вопрос, влечет ли динамическое связывание создание производной программы, нет5. Фонд свободного программного обеспечения считает, что нужно учитывать механизм взаимодействия и содержание взаимодействия программ33. Например, программа, модули которой имеют общие структуры данных и взаимозависимо вызывают функции друг друга, должна квалифицироваться как производное произведение. При этом сама по себе цель связывания open source модуля с другой программой не должна предопределять вывод о создании производной программы. M. Stotlz в связи с этим пишет, что самостоятельные дополнения и плагины к программе не являются производными работами. К похожему выводу пришел китайский суд в деле Digital Heaven v. YouZi, когда счёл плагин, который был динамически связан с основной программой, отдельной программой, хоть и на основании только того, что он не находился в одной папке и корневом каталоге с основной программой.
Критерий связывания не является бесспорным и нуждается в большей апробации на практике. В правовом пространстве ЕС он, в принципе, является нерелевантным, так как директива Совета Европейского Союза 2009/24/EC от 23 апреля 2009 г. о правовой охране компьютерных программ предусматривает, что использование кода программ для обеспечения их совместимости (interoperability) вне зависимости от способа не является нарушением авторского права, а следовательно, не затрагивает действия копилефтной лицензии.
Для обхода требований открытой лицензии используют «прослойку» между открытым и проприетарным компонентами из библиотеки, распространяемой под LGPL, поскольку в таком случае они оказываются связаны лишь опосредованно – лицензия LPGL используется по той причине, что она является менее строгой по сравнению с GPL. Такое ПО, однако, может быть признано производной программой, если единственное назначение библиотеки – связь проприетарного и открытого кода. Именно к этому выводу пришли специалисты Software Freedom Conservancy (SFC) в споре Hellwig v. VMware.
Производное программное обеспечение должно обеспечивать совместимость открытых лицензий; в противном случае распространение ПО будет нарушать условия лицензий. Вопрос о совместимости конкретных компонентов и лицензий требует технического анализа, но по общему правилу программу, распространяемую под копилефтной лицензией, нельзя включать в ПО, которое распространяется на условиях пермиссивной лицензии, поскольку весь проект в таком случае должен лицензироваться на условиях копилефтной лицензии. Это правило не работает в обратную сторону – компоненты под пермиссивной лицензией можно свободно включать в копилефтные проекты, при условии, что пермиссивная лицензия не содержит дополнительные ограничения, например, лицензия Apache 2.0 несовместима с GPL v2, поскольку содержит ограничения, касающиеся патентных прав.
Помимо статического и динамического связывания open source компоненты можно интегрировать с программами через межпроцессное взаимодействие (IPC) – каналы, сокеты, удаленный вызов процедур (RPC), двоичный интерфейс приложений (ABI) – механизмы операционной системы и командные интерпретаторы6, программный интерфейс приложений (API). Интерфейсы позволяют взаимодействовать независимым программам без интеграции на уровне исходного кода, поэтому их использование не приводит к созданию производного произведения со всеми вытекающими последствиями.
Распространение open source
Создание производной программы само по себе не «активирует» обязательства по открытой лицензии, так как для этого требуется распространение программы. Однако существует неясность в отношении того, что является распространением, так как данный термин имеет разное наполнение в зависимости от юрисдикции.
В соответствии с п. 2 ст. 1270 ГК РФ распространение произведения – это продажа или иное отчуждение его оригинала или экземпляров. Предложение программы к продаже неограниченному кругу лиц (публичная оферта) также является распространением (Постановление ФАС Московского округа от 30 июня 2011 г. по делу № А40-14101/10-12-101).
На практике дистрибуция экземпляров компьютерных программ происходит несколькими путями. Так, программное обеспечение, например, операционная система, может быть предустановлено на оборудование (bundled software). ПО также может распространяться через дистрибутив, то есть пакет программных файлов, необходимый для первичной инициализации на устройстве (Постановление Суда по интеллектуальным правам от 27 декабря 2017 г. по делу № А45-13248/2017).
В определенных случаях передача копий программы не будет являться распространением, например, если копия программы предоставляется работнику организации или дочерней организации для целей исполнения договора4. Российская практика также не признает распространением передачу программы подрядчику для изучения принципов ее работы (Постановление Суда по интеллектуальным правам от 05 декабря 2018 г. по делу № А45-13248/2017). В США аналогичная позиция выражена в доктрине «ограниченной публикации», согласно которой предоставление произведения в конкретных целях ограниченному кругу лиц не влечет его введение в оборот.
Важно помнить, что экземпляры открытого ПО должны распространяться на условиях открытой лицензии даже после правомерного введения в оборот. Это указывает на то, что принцип исчерпания прав фактически не действует в отношении open source, как и большинства компьютерных программ. На уровне закона косвенное подтверждение этому содержится в п. 5 ст. 1286.1 ГК РФ, где указано, что лицензиар по открытой лицензии вправе пользоваться средствами защиты своих прав в отношении любых конечных пользователей (п. 5 ст. 1286.1 ГК РФ).
Благодаря развитию облачных технологий стало возможным предоставлять к программе удаленный доступ (Software as a Service). Программа, реализуемая через «облако», располагается на сервере провайдера без передачи экземпляра пользователю7, поэтому ее предоставление не является распространением. В связи с этим разработчики задумались о пересмотре существующих лицензий, которые создавались в эпоху физических носителей. Так, на базе GPL v2 была создана лицензия AGPL, сфера действия которой распространяется на удаленное взаимодействие по компьютерной сети. Но AGPL была подвергнута критике из-за абстрактных и лаконичных формулировок, а на смену ей стали появляться «облачные лицензии», которые не являются в полной мере открытыми.
На практике понятие распространения иногда ошибочно трактуется судами, показательным примером этого является дело А. Мамичева. Суды установили, что у Мамичева нет прав на созданное им ПО из-за того, что он нарушил права на open source компоненты, распространив программу за плату. Однако распространения в этом случае не произошло, поскольку из материалов дела следует, что Мамичев лишь осуществил перенос программы с личного сервера на сервер работодателя. При этом флеш-накопитель с архивом, который являлся объектом экспертизы, содержал в себе не дистрибутив ПО, а его фрагменты для последующего восстановления на более производительном оборудовании; третьи лица также не имели доступ ни к флеш-носителю, ни к частному серверу. Таким образом, сами по себе перенос программы с одного сервера на другой или смена хостинга не являются случаями распространения, поскольку не сопровождаются отчуждением экземпляра программы в пользу третьего лица.
(Без)возмездность open source
Следует отдельно остановиться на возможности распространения open source программ за плату, так как существует заблуждение, что открытое ПО – бесплатный продукт. Это не так, поскольку право продавать копии – «часть определения свободной программы». Пункт 3 ст. 1286.1 ГК РФ в подтверждение этого содержит лишь презумпцию безвозмездности открытой лицензии. Указанная норма, однако, не учитывает, что установление платы допустимо не за предоставление права использования – в этом контексте все открытые лицензии действительно являются безвозмездными, — а за распространение экземпляров программы.
Также следует понимать, что пользователь коммерческого open source продукта вправе распространять его в дальнейшем на безвозмездной основе, из-за чего разработчики свободного ПО рискуют не вернуть собственные вложения в проект. Этот риск можно преодолеть несколькими способами.
Многие open source продукты распространяются на условиях «двойного лицензирования» под совместимыми лицензиями. Обычно это бесплатная версия под сильной копилефтной лицензией и коммерческая, которая распространяется под пермиссивной лицензией. Двойное лицензирование выгодно для всех сторон – приобретатель бесплатной версии получает ПО с ограничениями, которые установлены копилефтной лицензией, а приобретатель платного продукта вправе использовать open source на более либеральных условиях.
Коммерциализация свободного ПО возможна и через предоставление услуг по сервисному обслуживанию. Вместе с тем платежи за сервисное обслуживание, в том числе тестирование, отладку, хостинг, не являются лицензионными платежами, поскольку осуществляются за оказание определенных услуг, а не передачу прав использования. В деле А. Мамичева суды не учли этого, так как усмотрели нарушение GPL v2 в том, что Мамичев якобы распространил ПО за плату, что противоречит лицензии8. Однако Мамичев предлагал взимать плату не за предоставление права пользования ПО, а за его техническую поддержку, что является вознаграждением за оказание услуг.
Возврат вложений может также достигаться путем установления режима конфиденциальности информации. Так, с пользователем заключается договор на модификацию ПО или его обслуживание, в рамках которого устанавливаются обязательства по неразглашению конфиденциальной информации. Это ограничивает возможность распространения open source на определенный в договоре срок. При этом установление режима конфиденциальности не для целей исполнения договора будет нарушать требования открытой лицензии. Обязанность не распространять ПО можно также установить в соглашении о неконкуренции, например, между хостинг-провайдерами. Такое условие теоретически не будет нарушением лицензии, поскольку между компаниями могут отсутствовать отношения по предоставлению права использования программы. Однако не совсем ясно, как это соотносится с установленным приоритетом требований отдельных лицензий над иными договорными обязательствами.
Личные неимущественные права на open source
Авторы открытого ПО помимо исключительного права обладают личными неимущественными правами – в частности, правом на неприкосновенность произведения (за исключением права на отзыв, которое не распространяется на компьютерные программы в силу прямого указания закона (п. 2 ст. 1269 ГК РФ). Личные неимущественные права неотчуждаемы, что создает риск предъявления автором требований даже в случае выдачи максимально широкой открытой лицензии. Большинство открытых лицензий не касаются личных неимущественных прав, поскольку их содержание определяется преимущественно национальным законодательством, а многие лицензии были разработаны на основе американского права, в котором роль личных неимущественных прав исторически мала. Некоторые открытые лицензии, однако, содержат условия об отказе от личных неимущественных прав, которые будут ничтожны по российскому праву (п. 2 ст. 168 ГК РФ).
Право на неприкосновенность произведения направлено на защиту целостности произведения и замысла автора и запрещает внесение в произведение изменений, сокращений и дополнений, снабжение произведения при его использовании иллюстрациями, предисловием, послесловием, комментариями или какими бы то ни было пояснениями без согласия автора, а также извращение, искажение и иное умаление чести, достоинства или деловой репутации автора (ст. 1266 ГК РФ). Сфера его действия может простираться не только на код и материальный носитель программы, но и на аудиовизуальные отображения, порождаемые ею. Право на неприкосновенность признается лишь в ряде юрисдикций, а в США его действие ограничено визуальными произведениями. При этом нельзя исключать риск того, что разработчики из юрисдикций, признающих право на неприкосновенность, могут предъявить требования в отношении своих компонентов. Однако стоит признать, что такой риск является низким, поскольку это как минимум не соответствует ценностям open source сообщества. Кроме того, российское право допускает согласие на внесение в будущем изменений в произведение, что позволяет минимизировать этот риск в пределах российской юрисдикции (п. 3 ст. 1266 ГК РФ).
В разъяснениях Верховного суда право на неприкосновенность произведения, в отличие от права на переработку, касается таких изменений, которые не связаны с созданием нового произведения (п. 87 Постановления Пленума ВС РФ от 23 апреля 2019 г. № 10). Однако в случае с компьютерными программами разграничить эти права затруднительно, поскольку режим модификации программы распространяется на внесение любых изменений. Относительно этого вопроса существует несколько позиций. Так, А.А. Никифоров считает, что право на неприкосновенность защищает логику работы программы, с чем сложно согласиться, поскольку логика является ни чем иным, как неохраноспособной идеей. Позиция П.Ю. Ямщикова, который утверждает, что право на неприкосновенность защищает программу от использования неподобающих способов лицензирования и установки технических средств защиты, спорна, поскольку указанные действия и так влекут законную ответственность.
В свою очередь А.И. Савельев считает, что право на переработку поглощает право на неприкосновенность. С этим можно не согласиться, поскольку сфера действия права на неприкосновенность распространяется в том числе на репутацию автора, а также на те действия, которые однозначно не приводят к созданию производной программы – например, удаление кода. Другие исследователи вообще предлагают отказаться от права на неприкосновенность компьютерных программ, поскольку это противоречит их сущности, подверженной постоянным изменениям.
Чтобы положить конец этим дебатам, следует уточнить сферу действия права на неприкосновенность, установив, что оно не распространяется на компьютерные программы кроме случаев, когда действия порочат честь или деловую репутацию автора. Такой подход успешно действует в других правопорядках и учитывает специфику компьютерных программ в качестве самостоятельного объекта охраны.
Ответственность за неправомерное использование open source
Несмотря на скептическое отношение сообщества открытого ПО к юрисдикционным способам защиты права, а также сложности в определении надлежащего истца для предъявления иска, количество судебных споров в отношении open source растет.
Ответственность за неправомерное использование open source может наступать в результате нарушения условий открытой лицензии и/или интеллектуальных прав автора или правообладателя. Применение к открытым лицензиям общих норм о договорах открывает возможность для предъявления таких требований как признание лицензии расторгнутой или исполнение обязательства в натуре, чем может выступать раскрытие исходного кода программы. В свою очередь, неправомерное использование open source, например, за пределами условий лицензии или в результате нарушения личных неимущественных прав влечет внедоговорную ответственность, установленную IV частью ГК РФ. Статья 1286.1 ГК РФ, конкретизируя эти виды ответственности, предусматривает два специфических основания ее наступления.
Так, лицензиар вправе отказаться от договора в одностороннем порядке, если лицензиат будет предоставлять право на использование произведения либо на использование производной работы с нарушением условий открытой лицензии (п. 4 ст. 1286.1 ГК РФ). Поскольку большинство открытых лицензий не допускает сублицензирования, а предусматривает, что каждый пользователь приобретает права непосредственно от правообладателя (п. 2 ст. 1268.1 ГК РФ), последствия расторжения договора не касаются последующих добросовестных лицензиатов.
Расторжение открытой лицензии влечет невозможность использования производной программы (п. 3 ст. 1260 ГК РФ), однако сохраняет возможность защищать права на нее против третьих лиц (п. 4 ст. 1260 ГК РФ, Постановление Суда по интеллектуальным правам от 2 июля 2021 г. по делу № А40-311658/2018). Расторжение по условиям многих открытых лицензий происходит автоматически, что создает возможность для «копирайт-троллинга» путем предъявления массовых исков о нарушении открытых лицензий. Для того, чтобы предупредить подобное, в отдельные лицензии включается отлагательное условие о ее восстановлении при прекращении нарушения в определенный срок. Например, GPL v3 предусматривает, что права нарушителя по лицензии могут быть восстановлены, если он исправит нарушение в течение 30 дней или не получит уведомления от правообладателя в течение 60 дней (S. 10). Относительно открытых лицензий, не содержащих подобное положение, российское право не предоставляет льготный срок на прекращение нарушения, поскольку лицензия считается расторгнутой с момента получения нарушителем уведомления (п. 1 ст. 450.1 ГК РФ). Для крупных проектов запрет на использование open source модулей может быть роковым: когда разработчик отозвал свои системообразующие файлы из программного менеджера для JavaScript, проблемы возникли у множества проектов по всему миру.
Автор или иной правообладатель также вправе требовать привлечения лица к ответственности за нарушение исключительного права в результате неправомерных действий по предоставлению или использованию открытой лицензии (п. 5 ст. 1286.1 ГК РФ). Заключение открытых лицензий обычно происходит без непосредственного участия обеих сторон, что создает риск заключения договора неуполномоченным лицом. Вместе с тем, обоснованность выделения этой нормы сомнительна, поскольку распоряжение чужим правом в любом случае не влечет никаких юридических последствий, а нарушитель не получает встречного предоставления. Ценно замечание А.В. Семенова о том, что распространение ответственности за неправомерное использование результатов интеллектуальной деятельности на случаи незаконного распоряжения правом является неверным с теоретической точки зрения «расползанием» санкций ст. 1252 ГК РФ на действия, не подпадающие под ее диспозицию.
Судебная практика по open source в России почти отсутствует и ограничивается лишь признанием действительности открытых лицензий (Постановление Суда по интеллектуальным правам от 5 октября 2020 г. по делу № А03-21181/2018, Апелляционное определение Московского городского суда от 16 июля 2015 г. по делу № 33-25081/2015). Знаковый спор, на основании которого можно делать какие-либо выводы, – дело А. Мамичева. И эти выводы являются скорее неутешительными, о чем ранее уже шла речь. Здесь стоит обратить внимание на еще один аспект. Несмотря на то, что защита исключительных прав может осуществляться только автором или иным правообладателем (п. 2 ст. 1252 ГК РФ), суды самостоятельно констатировали нарушение условий GPL v2 и отказали Мамичеву в защите его прав на ПО. Нельзя исключать, что этот ход возьмут на вооружение другие суды.
Зарубежная практика по open source развивается более стремительно. В деле Jacobson v. Katzer американский суд привлек лицо к ответственности за нарушение авторских прав на open source, возможность чего долгое время оспаривалась в доктрине. В другом известном деле Artifex Software v. Hancom суд определил, что распространение open source без раскрытия исходного кода составляет факт нарушения как договора, так и авторских прав, подтвердив исполнимость открытых лицензий в качестве контракта.
В настоящее время также разворачивается знаковое дело Software Freedom Conservancy (SFC) v. Vizio Inc. Компания Vizio, которая использует в своем проекте open source компоненты, распространяемые под лицензиями семейства GPL, не раскрыла его исходный код в ответ на запросы со стороны SFC, после чего SFC обратилось в суд с требованием исполнить данное обязательство. Этот спор интересен тем, что SFC не является правообладателем open source, а предъявило иск в качестве третьего лица-выгодоприобретателя, а именно конечного потребителя. SFC убеждено, что потребители имеют законный интерес в раскрытии исходного кода продуктов, использующих open source, для их изучения, что содействует развитию инноваций. Если суд удовлетворит иск, дело станет прецедентом, поскольку это позволит конечным пользователям понуждать компании к исполнению открытых лицензий. На момент написания статьи федеральный суд, который компетентен рассматривать споры об интеллектуальных правах и куда требовало перенести спор Vizio, постановил вернуть иск в окружной суд, указав, что спор касается договорных обязательств, что можно считать успехом SFC.
Перспективы подобного иска в России на сегодняшний день ничтожно малы, поскольку третье лицо в данных обстоятельствах не вправе предъявить иск об исполнении договора или привлечении к ответственности за нарушение авторских прав9. Нормы потребительского права также неприменимы, поскольку несмотря на то, что потребители обладают правом на получение необходимой и достоверной информации о товарах, цель получения такой информации («обеспечение возможности правильного выбора»), ее объем и императивные формулировки нормы закона препятствуют такому расширительному толкованию (ст. 10 Закона РФ от 7 февраля 1992 г. № 2300-1 «О защите прав потребителей»). Теоретически возможность привлечения к ответственности третьим лицом за сокрытие исходного кода может быть реализована в рамках антимонопольного законодательства. Статья 14.8 Федерального закона от 26 июля 2006 г. № 135-ФЗ «О защите конкуренции» запрещает любые формы недобросовестной конкуренции, прямо не упомянутые в законе. Однако стандарт доказывания по делам о недобросовестной конкуренции слишком высок (п. 30 Постановления Пленума Верховного Суда РФ от 4 марта 2021 г. № 2), а меры ответственности за нарушение антимонопольного законодательства не отвечают целям и ценностям open source сообщества.
***
Невзирая на возможные риски, преимущества от использования open source не дают отказаться от него. Для того, чтобы митигировать эти риски, компаниям, работающим с открытым ПО, желательно принять локальные нормативные акты, которые регламентируют порядок работы с open source компонентами и указывают на разрешенные и запрещенные модули, включить соответствующие положения в должностные инструкции разработчиков, например, обязанность получать согласие руководителя на использование сторонних open source продуктов, предусмотреть заверения и требования в договоры с подрядчиками. Управление open source также должно включать в себя обучение сотрудников и использование автоматизированных систем проверки наличия open source в коде (Black Duck и др.). Таким образом, только комплексные меры могут минимизировать шанс предъявления возможных претензий и исков, а также создать возможность для эффективного использования открытого программного обеспечения в деятельности организации.
Артем Сафьянников, студент факультета права НИУ ВШЭ
Источник: Журнал Суда по интеллектуальным правам
_____________________________
1Термины «free software» и «open source software» не являются идентичными, поскольку были созданы двумя конкурирующими движениями – FSF и OSI, между которыми существуют идеологические противоречия. Но почти все открытые лицензии, под которыми распространяется ПО, являются и свободными, поэтому в дальнейшем эти термины употребляются как синонимы. См.: Peterson, S.K. What’s the difference between open source software and free software? Режим доступа: https://opensource.com/article/17/11/open-source-or-free-software (дата обращения: 17.01.2022).
2Во-первых, не все вносимые изменения могут быть признаны производной работой в соответствии с лицензией. Во-вторых, открытые лицензии содержат широкие формулировки, что не всегда подходит для оформления отношений с конкретными разработчиками. Одна из лицензий, которая лишена этих недостатков. – Apache 2.0.
3Совершение сделки конклюдентными действиями возможно при отсутствии обязательной установленной письменной формы сделки (п. 2 ст. 159 ГК РФ). Лицензионный договор в то же время должен быть заключен в письменной форме (п. 2 ст. 1235 ГК РФ). Условия лицензии, заключаемой в упрощенном порядке, также должны быть доступны неопределенному кругу лиц (п. 5 ст. 1286 и п. 1 ст. 1286.1 ГК РФ).
4Указанная позиция характерна для сильных копилефтных лицензий. Например, слабая копилефтная лицензия MPL предусматривает, что даже в случае статического связывания open source компонентов с проприетарным ПО единая комбинированная программа не должна распространяться на условиях MPL.
5Отдельные лицензии решают этот вопрос по-разному: условия Apache 2.0. скорее свидетельствуют о самостоятельности двух динамически связанных программ (S.1). Режим доступа: https://www.apache.org/licenses/LICENSE-2.0 (дата обращения: 25.01.2022); GPL v3 предусматривает, что динамическое связывание может создавать новое производное произведение в случае тесного обмена данными между программами (S.1). Режим доступа: https://www.gnu.org/licenses/gpl-3.0.html (дата обращения: 25.01.2022).
6В споре SFC v. Vigorien технический анализ показал, что системные утилиты, подключаемые к ПО для архивации файлов GNU tar через командную строку, являются самостоятельными элементами. Режим доступа: https://copyleft.org/guide/comprehensive-gpl-guidech25.html#x32-17900024.1 (дата обращения: 27.01.2022).
7Передача данных, которые пользовательское устройство получает во время работы с сервисом, не является использованием программы, поскольку «не считается воспроизведением краткосрочная запись произведения, которая носит временный или случайный характер и составляет неотъемлемую и существенную часть технологического процесса, имеющего единственной целью правомерное использование произведения…» (п. 2 ст. 1270 ГК РФ).
8Сам по себе вывод суда о том, что GPL v2 запрещает распространение программы за плату, со всей очевидностью является неправильным.
9Открытая лицензия не является договором в пользу третьего лица (ст. 430 ГК РФ), а доктрина третьего лица-выгодоприобретателя в России не применяется. Пользователь программы также не является лицом, которое может прибегнуть к защите интеллектуальных прав (п. 2 ст. 1250 ГК РФ).