Правовые проблемы использования открытого программного обеспечения (open source)

"Журнал Суда по интеллектуальным правам", № 2 (36), июнь 2022 г., с. 33-45

Исследования показывают, что 98% компьютерных программ содержат в себе open source, или открытое (свободное1) программное обеспечение. При этом программы в среднем на 75% состоят из open source компонентов2. Открытое программное обеспечение распространяется с исходным кодом, то есть с текстом программы, написанном на языке программирования и доступном для восприятия человеком. Задумано это для того, чтобы пользователи open source могли свободно использовать, изучать, модифицировать и распространять программу. Гарантом свобод выступают открытые лицензии, под которыми распространяются open source программы. Лицензии также накладывают ограничения, которые защищают пользователей open source, в чем выражается их отличие от инструментов классического авторского права, нацеленного на защиту интересов авторов. Для этого сторонники open source используют термин copyleft (дословно – "авторское лево").

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

Открытые лицензии традиционно разделяют на три вида: пермиссивные, слабые копилефтные и сильные копилефтные лицензии. Пермиссивные лицензии (BTD, Apache 2.0) предоставляют пользователям полную свободу использовать, модифицировать и распространять программы, в том числе и созданные на их основе, на любых условиях. Взамен пользователь обязан лишь уведомить приобретателей об условиях лицензии и авторах open source. Слабые копилефтные лицензии (MIT, LGPL) отличаются от пермиссивных тем, что open source компоненты должны распространяться на оригинальных условиях. И наконец, сильные копилефтные лицензии (семейство GPL) накладывают на пользователей дополнительные обязанности раскрывать исходный код и лицензировать на условиях оригинальной лицензии не только open source компоненты, но и все производные работы, созданные на их основе.

Прежде чем приступить к обсуждению отдельных проблемных аспектов использования open source, следует обосновать применимость к открытым лицензиям норм российского права, так как большинство из них не содержит положений о применимом праве4. Коллизионная норма, которая содержится в п. 8 ст. 1211 ГК РФ, неприменима к open source проектам, поскольку на стороне лицензиара открытого ПО обычно выступает множество лиц. Следовательно, нужно опираться на принцип наиболее тесной связи5. Так, в контексте open source выбор применимого права может обосновываться местом нахождения фонда, поддерживающего open source проект, или территорией страны, в которой происходило использование свободного ПО. Таким образом, российское право будет применяться к открытым лицензиям тогда, когда open source используется на территории или лицом с местом нахождения в РФ. В отношении же интеллектуальных прав на открытое ПО российское право будет применяться всякий раз, когда защита программы испрашивается в РФ (lex loci protectionis)6.

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

Открытые лицензии или не содержат определение производного произведения, или используют определения, отличные от национального законодательства, поэтому при разрешении спора российский суд будет применять легальное понятие производного произведения, под которым понимается произведение, созданное в результате переработки оригинального произведения7. Частным случаем переработки является модификация программы, т.е. внесение в нее любых изменений, в том числе перевод такой программы с одного языка программирования на другой язык8. Законодатель различает модификацию и адаптацию программы, которая означает внесение изменений исключительно в целях функционирования программы на конкретных технических средствах пользователя или под управлением конкретных программ пользователя. Адаптация программы допускается без согласия автора и выплаты вознаграждения.

Законодательное определение модификации программы вызывает определенные нарекания, поскольку критерий модификации не отвечает общему стандарту творчества для предоставления правовой охраны. Кажется очевидным, что минимальные изменения кода не образуют самостоятельного произведения9. Вместе с тем судебная практика по данному вопросу противоречива10. Эту проблему пытались решить специалисты из Сколково, предложив ввести понятие версии компьютерной программы, которая не является самостоятельным объектом, но данный законопроект не был поддержан11.

Неясность в отношении того, является ли любая модификация программы самостоятельным произведением, порождает практические трудности. Предположим, что автор разместил проект на Github, где любое лицо вправе создать на основе форка, т.е. копии исходного кода, новую версию программы. Если автор проекта одобряет предлагаемые изменения, они вносятся в оригинальный код. В ситуации, когда любая модификация программы является самостоятельным произведением, она может использоваться в проекте только с согласия разработчика12. При постоянном развитии open source проекта, в которых участвуют сотни разработчиков, права на каждую новую версию, таким образом, должны консолидироваться. При этом использование открытой лицензии не всегда обеспечивает достижение этой цели13. Для решения проблемы разработчики обычно заключают лицензионное соглашение участника (contributor license agreement), по которому они отчуждают права на свои версии руководителю проекта. В отсутствие таких индивидуальных соглашений права на модификации можно консолидировать на основе «входящей=выходящей лицензии» (inbound = outbound license) и «подразумеваемой лицензии» (implied license)14. Первая конструкция лицензионного договора предполагает, что любая модификация ПО автоматически распространяется под лицензией конечного продукта15. Однако, чтобы признать ее существование, нужно доказать, что автор модификации знал или должен был знать об условиях оригинальной лицензии и выразил согласие предоставить такую лицензию любому лицу в будущем16. Подразумеваемая лицензия, как следует из названия, выводится из поведения сторон, а для придания ей юридической силы необходимо установить подразумеваемую волю автора, но такая возможность по российскому праву отсутствует17.

Проблема консолидации прав на каждую версию программы может быть решена посредством применения норм о соавторстве. Вместе с тем применение режима соавторства к open source чревато некоторыми неудобствами: невозможностью распорядиться правом без согласия всех соавторов и выделить доли в исключительном праве. Использовать такую программу тем не менее допустимо, так как закон гласит, что соавтор не вправе без достаточных оснований запретить использование произведения, если оно образует неразрывное целое18. Программное обеспечение, хоть оно и не всегда является единым целым, можно считать таковым для целей этой нормы, поскольку последствия запрета на использование отдельного компонента могут привести к невозможности использовать ПО в целом и к необоснованно высоким убыткам других соавторов и пользователей. Применение режима соавторства также минимизирует негативные последствия «копирайт-троллинга», поскольку по общему правилу доходы от использования произведения делятся между авторами поровну, а следовательно, злоумышленник не сможет претендовать на получение какой-либо выгоды19. Режим соавторства однако нельзя применять в ситуациях, когда при создании проекта используется открытое ПО третьих лиц, поскольку они не вносят творческого вклада в проект и не имеют намерения становиться его соавторами20.

Вернемся к исходному вопросу о критериях модификации программы и обратимся к судебной практике. Для определения модификации суды исходят из того, служат ли изменения основанием для появления новых функций в программе, модулей или существенных усовершенствований уже существующих функций21. Так, в одном из дел суд при назначении экспертизы разъяснил, что модификация свидетельствует об «изменении функциональности программы, появлении новых свойств и возможностей программы, автоматизации неавтоматизированных ранее ручных операций, иных доработках, выходящих за пределы адаптации программы для ЭВМ»22.

Стоит, однако, учитывать количественное соотношение заимствуемого и оригинального кода, так как использование библиотеки из 5 строк вряд ли превращает новую программу в производное произведение. Более того, включение кода de minimis иногда необходимо для обеспечения совместимости двух программ — например, включение заголовочного файла в исходный текст для вызова библиотеки в процессе исполнения программы. M. Stotlz отмечает, что в таком случае переработка или воспроизведение программы не осуществляется23. При этом соотношение оригинального и заимствуемого кода должно оцениваться в каждом конкретном случае, поскольку введение универсального стандарта заимствований невозможно24.

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

Open source компоненты могут распространяться вместе с иным программным обеспечением в составе сборника, отдельные элементы которого хоть и могут использоваться совместно, но независимы друг от друга, — например, операционная система с предустановленными программами сторонних разработчиков. Производное произведение в таком случае не возникает, но такой сборник может получить охрану в качестве составного произведения25. Например, в деле № А40-233720/17 арбитражный суд установил, что программный продукт, состоящий из ПО собственной разработки и интегрированной с ним программы третьего лица, является составным произведением, а не модификацией26. Еще один пример — дело А. Мамичева, которое касалось определения принадлежности прав на программное обеспечение, созданное Мамичевым во время работы в компании Veeam. В составе ПО разработчик использовал open source библиотеки, которые распространялись под лицензией GNU GPL v2. Апелляционный суд счел, что ПО было составным произведением, а код, созданный Мамичевым, использовался исключительно для связи библиотек27. Исходя из представленных в открытом доступе материалов дела, этот вывод вызывает сомнения, поскольку ПО являлось самостоятельным и по сути новым продуктом.

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

Возможна иная ситуация, при которой open source компоненты могут не включаться в исходный код оригинальной программы, а связываться с другими библиотеками и модулями, предназначенными для совместной работы. Связывание подразумевает, что программа «вызывает» другую программу в необходимый момент. Так, программные компоненты могут быть связаны друг с другом статически. Статическое связывание происходит в результате компоновки программы, т.е. соединения программных файлов для создания единого исполняемого файла в виде объектного (машиночитаемого) кода. По этой причине статическое связывание свидетельствует в пользу создания производной программы31.

Динамическое связывание отличается от статического тем, что запрашиваемая библиотека вызывается во время выполнения программы, а не компоновки. При этом обе программы являются независимыми, поскольку не образуют единый исполняемый файл. Однозначного ответа на вопрос, влечет ли динамическое связывание создание производной программы, нет32. Фонд свободного программного обеспечения считает, что нужно учитывать механизм взаимодействия и содержание взаимодействия программ33. Например, программа, модули которой имеют общие структуры данных и взаимозависимо вызывают функции друг друга, должна квалифицироваться как производное произведение. При этом сама по себе цель связывания open source модуля с другой программой не должна предопределять вывод о создании производной программы. M. Stotlz в связи с этим пишет, что самостоятельные дополнения и плагины к программе не являются производными работами34. К похожему выводу пришел китайский суд в деле Digital Heaven v. YouZi, когда счёл плагин, который был динамически связан с основной программой, отдельной программой, хоть и на основании только того, что он не находился в одной папке и корневом каталоге с основной программой35.

Критерий связывания не является бесспорным и нуждается в большей апробации на практике. В правовом пространстве ЕС он, в принципе, является нерелевантным, так как директива Совета Европейского Союза 2009/24/EC от 23 апреля 2009 г. о правовой охране компьютерных программ предусматривает, что использование кода программ для обеспечения их совместимости (interoperability) вне зависимости от способа не является нарушением авторского права, а следовательно, не затрагивает действия копилефтной лицензии36.

Для обхода требований открытой лицензии используют «прослойку» между открытым и проприетарным компонентами из библиотеки, распространяемой под LGPL, поскольку в таком случае они оказываются связаны лишь опосредованно37. Такое ПО, однако, может быть признано производной программой, если единственное назначение библиотеки — связь проприетарного и открытого кода38.

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

Помимо статического и динамического связывания open source компоненты можно интегрировать с программами через межпроцессное взаимодействие (IPC) – каналы, сокеты, удаленный вызов процедур (RPC), двоичный интерфейс приложений (ABI) – механизмы операционной системы и командные интерпретаторы40, программный интерфейс приложений (API). Интерфейсы позволяют взаимодействовать независимым программам без интеграции на уровне исходного кода, поэтому их использование не приводит к созданию производного произведения со всеми вытекающими последствиями41.

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

В соответствии с п. 2 ст. 1270 ГК РФ распространение произведения — это продажа или иное отчуждение его оригинала или экземпляров. Предложение программы к продаже неограниченному кругу лиц (публичная оферта) также является распространением42.

На практике дистрибуция экземпляров компьютерных программ происходит несколькими путями. Так, программное обеспечение, например, операционная система, может быть предустановлено на оборудование (bundled software). ПО также может распространяться через дистрибутив, т.е. пакет программных файлов, необходимый для первичной инициализации на устройстве43.

В определенных случаях передача копий программы не будет являться распространением, например, если копия программы предоставляется работнику организации или дочерней организации для целей исполнения договора44. Российская практика также не признает распространением передачу программы подрядчику для изучения принципов ее работы45. В США аналогичная позиция выражена в доктрине «ограниченной публикации», согласно которой предоставление произведения в конкретных целях ограниченному кругу лиц не влечет его введение в оборот46.

Важно помнить, что экземпляры открытого ПО должны распространяться на условиях открытой лицензии даже после правомерного введения в оборот47. Это указывает на то, что принцип исчерпания прав фактически не действует в отношении open source, как и большинства компьютерных программ48. На уровне закона косвенное подтверждение этому содержится в п. 5 ст. 1286.1 ГК РФ, где указано, что лицензиар по открытой лицензии вправе пользоваться средствами защиты своих прав в отношении любых конечных пользователей49.

Благодаря развитию облачных технологий стало возможным предоставлять к программе удаленный доступ (Software as a Service). Программа, реализуемая через «облако», располагается на сервере провайдера без передачи экземпляра пользователю50, поэтому ее предоставление не является распространением. В связи с этим разработчики задумались о пересмотре существующих лицензий, которые создавались в эпоху физических носителей. Так, на базе GPL v2 была создана лицензия AGPL, сфера действия которой распространяется на удаленное взаимодействие по компьютерной сети51. Но AGPL была подвергнута критике из-за абстрактных и лаконичных формулировок52, а на смену ей стали появляться «облачные лицензии», которые не являются в полной мере открытыми53.

На практике понятие распространения иногда ошибочно трактуется судами, показательным примером этого является дело А. Мамичева. Суды установили, что у Мамичева нет прав на созданное им ПО из-за того, что он нарушил права на open source компоненты, распространив программу за плату54. Однако распространения в этом случае не произошло, поскольку из материалов дела следует, что Мамичев лишь осуществил перенос программы с личного сервера на сервер работодателя. При этом флеш-накопитель с архивом, который являлся объектом экспертизы, содержал в себе не дистрибутив ПО, а его фрагменты для последующего восстановления на более производительном оборудовании; третьи лица также не имели доступ ни к флеш-носителю, ни к частному серверу. Таким образом, сами по себе перенос программы с одного сервера на другой или смена хостинга не являются случаями распространения, поскольку не сопровождаются отчуждением экземпляра программы в пользу третьего лица.

Следует отдельно остановиться на возможности распространения open source программ за плату, так как существует заблуждение, что открытое ПО — бесплатный продукт. Это не так, поскольку право продавать копии — «часть определения свободной программы»55. Пункт 3 ст. 1286.1 ГК РФ в подтверждение этого содержит лишь презумпцию безвозмездности открытой лицензии. Указанная норма, однако, не учитывает, что установление платы допустимо не за предоставление права использования — в этом контексте все открытые лицензии действительно являются безвозмездными, - а за распространение экземпляров программы.

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

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

Коммерциализация свободного ПО возможна и через предоставление услуг по сервисному обслуживанию. Вместе с тем платежи за сервисное обслуживание, в том числе тестирование, отладку, хостинг, не являются лицензионными платежами, поскольку осуществляются за оказание определенных услуг, а не передачу прав использования. В деле А. Мамичева суды не учли этого, так как усмотрели нарушение GPL v2 в том, что Мамичев якобы распространил ПО за плату, что противоречит лицензии56. Однако Мамичев предлагал взимать плату не за предоставление права пользования ПО, а за его техническую поддержку, что является вознаграждением за оказание услуг.

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

Авторы открытого ПО помимо исключительного права обладают личными неимущественными правами — в частности, правом на неприкосновенность произведения59. Личные неимущественные права неотчуждаемы, что создает риск предъявления автором требований даже в случае выдачи максимально широкой открытой лицензии. Большинство открытых лицензий не касаются личных неимущественных прав, поскольку их содержание определяется преимущественно национальным законодательством, а многие лицензии были разработаны на основе американского права, в котором роль личных неимущественных прав исторически мала. Некоторые открытые лицензии, однако, содержат условия об отказе от личных неимущественных прав60, которые будут ничтожны по российскому праву61.

Право на неприкосновенность произведения направлено на защиту целостности произведения и замысла автора и запрещает внесение в произведение изменений, сокращений и дополнений, снабжение произведения при его использовании иллюстрациями, предисловием, послесловием, комментариями или какими бы то ни было пояснениями без согласия автора, а также извращение, искажение и иное умаление чести, достоинства или деловой репутации автора62. Сфера его действия может простираться не только на код и материальный носитель программы, но и на аудиовизуальные отображения, порождаемые ею63. Право на неприкосновенность признается лишь в ряде юрисдикций, а в США его действие ограничено визуальными произведениями. При этом нельзя исключать риск того, что разработчики из юрисдикций, признающих право на неприкосновенность, могут предъявить требования в отношении своих компонентов. Однако стоит признать, что такой риск является низким, поскольку это как минимум не соответствует ценностям open source сообщества64. Кроме того, российское право допускает согласие на внесение в будущем изменений в произведение, что позволяет минимизировать этот риск в пределах российской юрисдикции65.

В разъяснениях Верховного суда право на неприкосновенность произведения, в отличие от права на переработку, касается таких изменений, которые не связаны с созданием нового произведения66. Однако в случае с компьютерными программами разграничить эти права затруднительно, поскольку режим модификации программы распространяется на внесение любых изменений. Относительно этого вопроса существует несколько позиций. Так, А.А. Никифоров считает, что право на неприкосновенность защищает логику работы программы, с чем сложно согласиться, поскольку логика является ни чем иным, как неохраноспособной идеей67. Позиция П.Ю. Ямщикова, который утверждает, что право на неприкосновенность защищает программу от использования неподобающих способов лицензирования и установки технических средств защиты, спорна, поскольку указанные действия и так влекут законную ответственность68.

В свою очередь А.И. Савельев считает, что право на переработку поглощает право на неприкосновенность69. С этим можно не согласиться, поскольку сфера действия права на неприкосновенность распространяется в том числе на репутацию автора, а также на те действия, которые однозначно не приводят к созданию производной программы — например, удаление кода70. Другие исследователи вообще предлагают отказаться от права на неприкосновенность компьютерных программ, поскольку это противоречит их сущности, подверженной постоянным изменениям71.

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

Несмотря на скептическое отношение сообщества открытого ПО к юрисдикционным способам защиты права, а также сложности в определении надлежащего истца для предъявления иска73, количество судебных споров в отношении open source растет.

Ответственность за неправомерное использование open source может наступать в результате нарушения условий открытой лицензии и/или интеллектуальных прав автора или правообладателя. Применение к открытым лицензиям общих норм о договорах открывает возможность для предъявления таких требований как признание лицензии расторгнутой или исполнение обязательства в натуре, чем может выступать раскрытие исходного кода программы. В свою очередь, неправомерное использование open source, например, за пределами условий лицензии или в результате нарушения личных неимущественных прав влечет внедоговорную ответственность, установленную IV частью ГК РФ. Статья 1286.1 ГК РФ, конкретизируя эти виды ответственности, предусматривает два специфических основания ее наступления.

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

Расторжение открытой лицензии влечет невозможность использования производной программы77, однако сохраняет возможность защищать права на нее против третьих лиц78. Расторжение по условиям многих открытых лицензий происходит автоматически, что создает возможность для «копирайт-троллинга» путем предъявления массовых исков о нарушении открытых лицензий79. Для того, чтобы предупредить подобное, в отдельные лицензии включается отлагательное условие о ее восстановлении при прекращении нарушения в определенный срок80. Относительно открытых лицензий, не содержащих подобное положение, российское право не предоставляет льготный срок на прекращение нарушения, поскольку лицензия считается расторгнутой с момента получения нарушителем уведомления81. Для крупных проектов запрет на использование open source модулей может быть роковым: когда разработчик отозвал свои системообразующие файлы из программного менеджера для JavaScript, проблемы возникли у множества проектов по всему миру82.

Автор или иной правообладатель также вправе требовать привлечения лица к ответственности за нарушение исключительного права в результате неправомерных действий по предоставлению или использованию открытой лицензии83. Заключение открытых лицензий обычно происходит без непосредственного участия обеих сторон, что создает риск заключения договора неуполномоченным лицом. Вместе с тем, обоснованность выделения этой нормы сомнительна, поскольку распоряжение чужим правом в любом случае не влечет никаких юридических последствий, а нарушитель не получает встречного предоставления. Ценно замечание А.В. Семенова о том, что распространение ответственности за неправомерное использование результатов интеллектуальной деятельности на случаи незаконного распоряжения правом является неверным с теоретической точки зрения «расползанием» санкций ст. 1252 ГК РФ на действия, не подпадающие под ее диспозицию84.

Судебная практика по open source в России почти отсутствует и ограничивается лишь признанием действительности открытых лицензий85. Знаковый спор, на основании которого можно делать какие-либо выводы, — дело А. Мамичева. И эти выводы являются скорее неутешительными, о чем ранее уже шла речь. Здесь стоит обратить внимание на еще один аспект. Несмотря на то, что защита исключительных прав может осуществляться только автором или иным правообладателем86, суды самостоятельно констатировали нарушение условий GPL v2 и отказали Мамичеву в защите его прав на ПО. Нельзя исключать, что этот ход возьмут на вооружение другие суды.

Зарубежная практика по open source развивается более стремительно. В деле Jacobson v. Katzer американский суд привлек лицо к ответственности за нарушение авторских прав на open source, возможность чего долгое время оспаривалась в доктрине87. В другом известном деле Artifex Software v. Hancom суд определил, что распространение open source без раскрытия исходного кода составляет факт нарушения как договора, так и авторских прав, подтвердив исполнимость открытых лицензий в качестве контракта88.

В настоящее время также разворачивается знаковое дело Software Freedom Conservancy (SFC) v. Vizio Inc. Компания Vizio, которая использует в своем проекте open source компоненты, распространяемые под лицензиями семейства GPL, не раскрыла его исходный код в ответ на запросы со стороны SFC, после чего SFC обратилось в суд с требованием исполнить данное обязательство. Этот спор интересен тем, что SFC не является правообладателем open source, а предъявило иск в качестве третьего лица-выгодоприобретателя, а именно конечного потребителя. SFC убеждено, что потребители имеют законный интерес в раскрытии исходного кода продуктов, использующих open source, для их изучения, что содействует развитию инноваций89. Если суд удовлетворит иск, дело станет прецедентом, поскольку это позволит конечным пользователям понуждать компании к исполнению открытых лицензий. На момент написания статьи федеральный суд, который компетентен рассматривать споры об интеллектуальных правах и куда требовало перенести спор Vizio, постановил вернуть иск в окружной суд, указав, что спор касается договорных обязательств, что можно считать успехом SFC.

Перспективы подобного иска в России на сегодняшний день ничтожно малы, поскольку третье лицо в данных обстоятельствах не вправе предъявить иск об исполнении договора или привлечении к ответственности за нарушение авторских прав90. Нормы потребительского права также неприменимы, поскольку несмотря на то, что потребители обладают правом на получение необходимой и достоверной информации о товарах, цель получения такой информации ("обеспечение возможности правильного выбора"), ее объем и императивные формулировки нормы закона препятствуют такому расширительному толкованию91. Теоретически возможность привлечения к ответственности третьим лицом за сокрытие исходного кода может быть реализована в рамках антимонопольного законодательства. Статья 14.8 Федерального закона «О защите конкуренции» запрещает любые формы недобросовестной конкуренции, прямо не упомянутые в законе. Однако стандарт доказывания по делам о недобросовестной конкуренции слишком высок92, а меры ответственности за нарушение антимонопольного законодательства не отвечают целям и ценностям open source сообщества.

Невзирая на возможные риски, преимущества от использования open source не дают отказаться от него. Для того, чтобы митигировать эти риски, компаниям, работающим с открытым ПО, желательно принять локальные нормативные акты, которые регламентируют порядок работы с open source компонентами и указывают на разрешенные и запрещенные модули, включить соответствующие положения в должностные инструкции разработчиков, например, обязанность получать согласие руководителя на использование сторонних open source продуктов, предусмотреть заверения и требования в договоры с подрядчиками. Управление open source также должно включать в себя обучение сотрудников и использование автоматизированных систем проверки наличия open source в коде (Black Duck и др.). Таким образом, только комплексные меры могут минимизировать шанс предъявления возможных претензий и исков, а также создать возможность для эффективного использования открытого программного обеспечения в деятельности организации.