Суд США по делу Oracle v. Google (вопросы правовой охраны компьютерных программ)

О завершении этого дела в 2021 г. смотрите здесь.

Дело Oracle America, Inc. v. Google Inc. (C 10-03561 WHA) рассматривается в американском суде с августа 2010 года. Все это время оно привлекало к себе самое пристальное внимание. И потому, что касалось широко распространенного программного обеспечения (Java и Android), и потому, что весьма далеко идущими были правовые обоснования сторон.

Из-за сложности дела суд проходил в несколько этапов. На первом решался вопрос о том, нарушили ли действия компании Google авторские права истца на один из самых распространенных в мире языков программирования и платформу Java (а именно на 37 приложений Java API). На втором выяснялось — были ли ущемлены патентные права истца. На третьем должен был определяться размер компенсации.

Уже на первом этапе возникли серьезные сложности: привлеченные присяжные, признав действия Google нарушением авторского права, не смогли ответить на вопрос — подпадали ли такие действия под защиту доктрины добросовестного использования (fair use). Второй этап завершился не в пользу истца: присяжные не нашли ущемления патентных прав.

На третьем этапе судья окружного суда Калифорнии William Alsup, оказавшись весьма подкованным специалистом в рассматриваемых вопросах, вынес 31 мая 2012 года детально проработанное решение, обосновавшее добросовестность использования компанией Google элементов приложений API Java. Этот судебный акт любопытен тем, что он подробно разбирает практику добросовестного использования в компьютерной сфере, очерчивает границы правовой охраны программного обеспечения и устанавливает общие принципы, на которые могут ориентироваться новые разработчики, стремящиеся к созданию совместимых программ, при этом не нарушающих права иных разработчиков.

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

Компания Google с 2005 года вела переговоры с компанией Sun о приобретении лицензии и совместной доработке своей платформы на основе Java для мобильных устройств. Соглашения достичь так и не удалось. Тогда Google решила, используя собственный или специально приобретенный исходный код, самостоятельно воспроизвести все необходимые функции приложений Java API, являющиеся ключевыми для мобильных устройств. Google заимствовала описания/заголовки (declaration/header) и функциональность 37 приложений Java API, применив при этом собственный программный код. В ходе судебного разбирательства было установлено, что 97% строк кода, написанных Google, отличались от соответствующего кода Oracle. Совпадение было только в 3% случаев. К ним относятся строки кода описаний (заголовков), определяющие названия, параметры и функциональность методов и классов.

Судом и присяжными было признано, что компания Google свободна в использовании языка Java, в создании собственной виртуальной машины, в заимствовании идентичных неохраняемых программных методов. Авторские права истца такие действия не нарушают. Спор о соблюдении авторских прав возник относительно воспроизводства описаний (заголовков) методов, организации таких описаний и заимствовании функциональности 37 приложений Java API.

Присяжные пришли к мнению, что Google напрямую не копировал приложения API (application programming interface), то есть «интерфейс программирования приложений», позволяющий компьютерной программе взаимодействовать с иными компьютерными программами. Ответчик лишь ориентировался на ту же функциональность программ, достигаемую за счет использования собственного кода для написания  аналогичных приложений API. Компания Oracle уточнила, что обвиняет ответчика не в заимствовании самих программ, а в копировании «структуры, последовательности и организации» (structure, sequence and organization) основного кода 37 приложений API. Жюри признало действия ответчика нарушающими права истца. Кроме того, нарушения авторских прав были обнаружены в прямом заимствовании ответчиком фрагментов кода истца.

Судья, рассматривая данное дело на третьем этапе, рассмотрел в целом вопрос об охраноспособности тех элементов программного обеспечения, о копировании которых заявил истец (описания/заголовки методов приложений, последовательность процессов и функциональность 37 приложений API). Поскольку суд решил, что авторско-правовая охрана ни на один из перечисленных элементов не распространяется, действия ответчика все же не привели к нарушению прав истца.

Судья положил в основу принятого им решения следующие принципы авторского права, касающиеся охраны компьютерных программ в США:

1) Согласно доктрине имен, названия и короткие фразы не являются охраноспособными.

2) Согласно доктрине поглощения (merger doctrine), когда существует единственный (или незначительное количество) способ выражения чего-либо, никто не вправе претендовать на предоставление ему авторских прав на такой способ выражения. Речь в данном случае идет о том, что авторское право не охраняет идеи, но охраняет способ выражения (expression) идей автором.

3) Согласно статье 102(b) Закона об авторском праве США авторско-правовая охрана не распространяется на любую идею, процедуру, процесс, систему, способ эксплуатации или концепцию независимо от их формы. Функциональные элементы, существенно важные для совместимости программы с иным программным обеспечением, также не охраняются.

4) Согласно делу Feist (Feist Publications, Inc. v. Rural Telephone Services, 1991), надлежит не поддаваться искушению предоставлять авторско-правовую охрану в целях простого вознаграждения усилий, вложенных в объект интеллектуальной собственности (в данном деле Верховный суд отказался признать охраняемым алфавитный телефонный справочник).

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

1) Согласно разъяснению Бюро регистрации авторских прав США:

«Авторское право не охраняет имена, названия, короткие фразы или выражения. Охрана не предоставляется, даже если имя, заголовок, короткая фраза являются оригинальными или имеют различительную способность, или представляют собой игру слов. Бюро регистрации авторских прав не может регистрировать заявления о предоставлении авторских прав на короткие сочетания слов, такие как:

– названия продуктов или услуг;

– названия коммерческих организаций или групп (включая групп исполнителей);

– псевдонимы (в том числе авторские и сценические);

– названия произведений;

– ключевые слова, популярные выражения, девизы, слоганы, или короткие рекламные выражения;

– списки ингредиентов в рецептах, на ярлыках или в формулах. Когда рецепт или способ приготовления (формула) сопровождаются объяснениями или инструкциями, текстовые инструкции могут охраняться авторским правом, но сам рецепт или способ приготовления по-прежнему остаются не охраноспособными».

Эти разъяснения были поддержаны судом, рассматривавшим дело Sega Enters., Ltd. v. Accolade, Inc. (9th Cir. 1992). Они же, по мнению судьи W.Alsup, всецело применимы и в данном деле.

2) Нельзя забывать, что описания (заголовки) методов представляют собой не просто названия. Одновременно они являются и командной структурой. Каждый метод и класс методов в составе приложений предназначены для выполнения изначально заданных функций, поэтому использование идентичного описания (заголовка) свидетельствует об идентичности характеристик приложений, выражающихся в идентичности выполняемых функций. Поскольку, согласно принципам Java, существует только один способ обозначения функциональности используемого метода (путем указания его описания, являющегося одновременно командой), то любой, кто добивается той же функциональности, обязан прописывать те же строки кода для получения того же описания (заголовка). Исходя из этого, понятна крайняя необходимость и неизбежность прямого заимствования описаний (заголовков) методов разными разработчиками для достижения совместимости их программ. Это дало возможность получить программный продукт, функциональность и заголовки которого схожи с соответствующими элементами широко распространенной платформы Java. Благодаря этому сходству независимые разработчики мобильного программного обеспечения на основе Java могли создавать собственные программы, легко совместимые с системой Android. Поэтому требования истца подлежат отклонению в связи с не предоставлением охраны описаниям (заголовкам) методов. Во-первых, исходя из доктрины поглощения, нельзя устанавливать монополию на единственно возможный способ выражения. Во-вторых, согласно требованиям законодательства, не предусматривающего охрану названий и коротких фраз.

Судья указал: «До тех пор пока для реализации определенного метода используется отличающийся машинный код, каждый свободен в соответствии с Законом об авторском праве написать свой собственный код для методов, имеющих те же самые функции или те же характеристики, что и методы, использованные в приложении Java API». При этом не важно, если описание или заголовок метода будут идентичными. Согласно принципам Java, они должны быть идентичными, чтобы обозначать метод, имеющий такую же функциональность, даже если реализация его будет отличаться.

«Когда существует только один способ выразить идею или функцию, каждый свободен сделать это, и никто не вправе монополизировать такой способ выражения идеи или функции». Платформа Android достигает той же функциональности без прямого копирования структуры команд, используемой в Java. В частности, путем иного сочетания тех же самых методов в разных классах и пакетах приложений. Но использование тех же описаний (заголовков) методов не привело к нарушению авторского права.

3) Хотя общий комплекс описаний (заголовков) методов и содержит творческое начало, тем не менее все они, сами по себе, являются прикладным и функциональным набором символов, осуществляющим предустановленные функции. Такая командная структура (также как и 9 строчек кода, фактически скопированных разработчиками Google), согласно Статье 102(b) Закона об авторском праве США, является системой или способом деятельности, в связи с чем не подлежит охране авторским правом.

Суд пояснил: начиная с решения по делу Baker v. Seldon, 101 U.S. 99 (1879), признано, что различия между патентным и авторским правом как раз и призваны исключить ситуацию, когда методы, идеи или факты, описанные в авторском произведении, защищаются правом от их использования иными лицами. Разработчик таких методов или идей должен прибегнуть к помощи патентной процедуры, чтобы зафиксировать свои законные интересы, но не полагаться на авторское право. Последнее ни в коем случае не предназначено для закрепления монополии на подобные объекты. Иное привело бы к серьезному ущемлению интересов всего общества.

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

«Существуют вопросы о распространении авторско-правовой охраны компьютерных программ на методологию и процедуры, примененные разработчиком программы, нежели только на сам текст, выражающий его идеи. Статья 102(b), помимо прочего, разъясняет, что именно способ выражения, использованный разработчиком, является охраняемым элементом компьютерной программы, и что фактические процедуры и методы, воплощенные в программе, не входят в сферу действия авторского права». В 1980 году в Закон об авторском праве США было добавлено и определение компьютерной программы. Компьютерной программой, по законодательству США, признается «совокупность предписаний или инструкций, предназначенных для прямого или косвенного исполнения компьютером в целях получения определенного результата».

В силу закона охраняется не идея, а лишь способ ее выражения (expression). Таким образом, законодатель не признает нарушением авторских прав заимствование положенных в основу программы методов, процессов и иных подобных элементов. Судебная практика исходит из тех же посылок.

Не будет нарушений в действиях ответчика, выразившихся в заимствовании иерархической структуры описаний (заголовков) методов, образующих таксономию. Хотя истец проявил творчество и креативность в разработке таксономии, тем не менее она остается не более чем командной структурой, то есть неохраняемым, в соответствии со статьей 102(b), способом эксплуатации (method of operation). Если охрана и возможна, то только в рамках патентного права.

Не выявил суд нарушений и в заимствовании ответчиком функциональности 37 приложений API. Как указал судья, копирование, обусловленное необходимостью обеспечить совместимость программ, не ведет к нарушению авторских прав, поскольку не охраняются авторским правом элементы программы, принципиально важные для обеспечения такой совместимости с программами сторонних разработчиков. Как будет показано далее, распространение охраны на такие элементы программы вело бы к установлению монополии на функции и методы, что не допускается принципами авторского права и соображениями защиты законных интересов третьих лиц. Поэтому действия компании Google признаются добросовестным использованием (fair use) программ Java.

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

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

________________________________________________

Нарушением авторских прав на программный продукт может быть признано построчное копирование чужого кода (или его более-менее значительной части), то есть способа выражения (expression) идей создателя продукта. Но даже в тех случаях, когда построчное копирование отсутствует, разработчики программного обеспечения пытаются доказать нарушение авторских прав в виде присвоения «структуры, последовательности и организации» (structure, sequence and organization) их программ. Аналогичных судебных дел еще не рассматривалось, поэтому судья произвел обзор схожих процессов, в которых изучалась правомерность не дословного копирования программ.

Так, в одном из первых подобных дел, Whelan Associates, Inc. v. Jaslow Dental Laboratory, Inc., 797 F.2d 1222 (3d Cir. 1986), суд пришел к выводу о распространении авторско-правовой охраны на структуру программ. Опирался он на следующие рассуждения: «Граница между идей и способом ее выражения может быть проведена со ссылкой на цель, для достижения которой создана программа. Другими словами, цель или функция прикладной программы признаются идеей такой программы, а все, что не является обязательным для такой цели или функции, относится к способу выражения идеи». Поскольку цель может быть достигнута при различных структурах программы, сама структура не является обязательным элементом и, следовательно, охраняется авторским правом. Данное судебное решение в дальнейшем неоднократно критиковалось.

Другой суд (Computer Associates International, Inc. v. Altai, 1992) отказался от столь узкого понимания «идеи» программы, и предложил взамен тест «извлечение – фильтрация – сравнение» (the abstract-filtration-comparison test). В соответствии с ним на первом этапе суду надлежит разделить сомнительную программу на ее составные части, проверить наличие в каждой из них своей идеи, предопределенного такой идеей способа ее выражения, а также общедоступного программного обеспечения, что позволит выявить неохраняемые элементы программы.

На втором этапе суд устанавливает неохраняемые структуры, примененные в программе. Отсутствие охраны обусловлено тем, что структура часто задается такими практическими соображениями, как технические возможности устройств, требования скорости и производительности работы программы, легкость ее использования пользователями. В связи с этим суд называет неохраняемыми три вида структуры программ: (а) обусловленные требованием производительности (если примененный в программе набор модулей предопределяет структуру приложения, обеспечивающую наивысшую производительность; это, кстати, приводит к парадоксальным последствиям в виде охраны авторским правом непроизводительных структур, тогда как производительные остаются неохраняемыми); (б) зависящие от внешних факторов, так называемая доктрина «scenes a faire» (подразумевающая, например, факторы в виде технических характеристик устройства, на котором будет работать программа, совместимости с иным программным обеспечением, требований компьютерной индустрии или сферы производства, где планируется использовать программу); (в) являющиеся общедоступными элементами программного обеспечения (например, распространяемые на условиях свободной лицензии).

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

В другом деле (Gates Rubber Co. v. Bando Chemical Industries, Ltd., 1993) суд дал определение структуры компьютерной программы: «Архитектура или структура программы – это описание того, как работает программа на основе ее разнообразных функций, исполняемых отдельными модулями, и как каждый из этих модулей взаимодействует друг с другом». В отношении охраноспособности структуры программы судья выразил ту же позицию, что и в предыдущем деле: необходимо применять тест для отсечения не охраняемых видов структуры и иных элементов.

В деле Lotus Development Corp. v. Borland International, Inc. (1995) суд признал неохраняемыми такие элементы программы, как названия пунктов меню и иерархическую структуру меню. Хотя создание этих элементов может сопровождаться творческой активностью, тем не менее, по мысли суда, эти части программы должны заимствоваться разработчиками альтернативных программных продуктов для обеспечения совместимости программ и облегчения работы пользователей. Такие части программы суд отнес к методам эксплуатации (method of operation), которые, согласно статье 102(b), не охраняются авторским правом.

Промежуточную позицию по вопросу охраноспособности структуры программ занял суд в решении по делу Johnson Controls, Inc. v. Phoenix Control Sys., Inc. (1989). Он посчитал, что структура, последовательность и организация программы могут охраняться, если они представляют собой не идею, а способ ее выражения.

Возможность охраны авторским правом последовательности операций и организации программы подтверждена, например, решением по делу Atari Games Corp. v. Nintendo of America Inc. (1992). Суд исходил из того, что указанные составляющие программы не являлись ее основной идей и не были предопределены такой идеей. Действительно, истец заявлял о нарушении прав на систему блокировки его игровых консолей от подключения чужих картриджей. Такая система, с точки зрения основных функций оборудования, является второстепенной и потому вполне может быть результатом творческой деятельности ее разработчика, и, значит, охраняться авторским правом.

Вопросу об авторско-правовой охране процедур взаимодействия приложений (interface procedures) преимущественно посвящено решение по делу Sega Enterprises Ltd. v. Accolade, Inc. (1992). Суд признал такой элемент программы не охраняемым по следующим соображениям. Действия ответчика, выразившиеся в копировании объектного кода программы истца и в разработке на основе собственного кода аналога процедур взаимодействия, используемых истцом, являются добросовестным использованием (fair use), поскольку необходимы для обеспечения совместимости программ. Создание совместимого программного обеспечения возможно лишь при условии изучения принципов функционирования сторонних программ. Этого невозможно достичь без копирования объектного кода процедур взаимодействия и его обратного ассемблирования. Соответственно, предоставление авторско-правовой охраны такому элементы программы, как процедуры взаимодействия приложений, привело бы к невозможности изучения объектного кода и разработки совместимых программ, что фактически означало бы предоставление монополии на функции и процедуры. А это уже прямо противоречило бы основным принципам авторского права. Кроме того, процедуры взаимодействия приложений относятся к функциональным элементам программы, что также исключает их охрану.

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

Судья отмечает, что сегодня вопрос охраны программного обеспечения авторским правом уже не столь актуален, в силу перетягивания в последние десятилетия этого объекта в сферу патентного права. Патенты на компьютерные программы, коих насчитывается уже сотни тысяч, позволяют обходить те сложности охраны, которые обусловлены природой авторского права. Если что и останавливает подобных разработчиков от обращения за получением патента, то только существенно меньший срок легальной монополии на их изобретение. Так и в данном деле судья признал существенную долю творчества в работе компании Oracle. Изобретение нового метода получения нового результата вполне может быть креативным, даже инновационным. Но такие открытия, на концептуальном и функциональном уровне, должны охраняться именно нормами патентного права, а не авторского.

Количество просмотров: 4 184

Оставьте комментарий