Решение Верховного суда вносит ясность в отношении добросовестного использования API, которое поможет разработчикам программного обеспечения.

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

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

Это судебное дело связано с использованием Google при создании Android определенной части API из Java SE, принадлежащей Oracle. Это дело длилось более 10 лет в затяжных судебных разбирательствах в нижестоящих судах. Апелляционный суд Федерального округа США (CAFC) ранее постановил, что (1) авторские права Oracle на часть кода API Java SE, скопированного Google, защищены авторским правом, и (2) использование Google не было определено как добросовестное использование (fair use) в соответствии с законом. Это означало, что Google понесет ответственность за нарушение авторского права за ту часть API, относимую к Java SE, которая используется в Android. Если бы это постановление осталось в силе, это было бы потерей не только для Google, но и для сообщества разработчиков программного обеспечения, в том числе с открытым исходным кодом.

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

К сожалению, индустрия программного обеспечения переживала эти потрясения более десятилетия. Однако, решение Верховного суда США дает новое объяснение и основу для анализа использования программных интерфейсов, и это в значительной степени хорошая новость. Короче говоря, хотя суд не отменил решение о защите авторских прав (что было бы лучшей новостью с точки зрения разработчиков программного обеспечения), он вынес решительное решение в пользу Google относительно того, было ли использование Google добросовестным с точки зрения закона.

Что такое API? Это зависит от того, кого вы спрашиваете

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

(источник: Google LLC против Oracle America, Inc., № 18-956, США, 5 апреля 2021 г.; стр. 38)

В определении суда понятие API включает в себя как "декларируемый код", так и "реализующий код" — термины, принятые судом, хотя они не используются разработчиками ПО на Java или других языках программирования. Декларируемый код (то, что разработчики на Java называют объявлением метода) объявляет имя метода и его входные и выходные данные. В вышеприведенном примере декларируемый код объявляет имя метода "max" и далее объявляет, что он получает два целых числа "x" и "y" и возвращает целое число результата.

Реализующий код (то, что разработчики Java называют телом метода) состоит из инструкций, реализующих функции метода. Таким образом, в вышеприведенном примере реализующий код будет использовать компьютерные инструкции и логику, чтобы определить, является ли “x” или “y” большим числом, и вернуть большее число.

В данном случае речь шла только о декларируемом коде. Google был обвинен в копировании частей декларируемого кода Java SE для использования в Android, а также "структуры, последовательности и организации" этого декларируемого кода. На завершающих стадиях этого дела в отношении Google уже не было претензий в копировании какого-либо реализующего кода. Стороны судебного процесса признали, что Google написал собственный реализующий код для Android.

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

Я буду называть декларируемый код "программным интерфейсом", поскольку в данном случае это то, что беспокоит индустрию. Программные интерфейсы, подпадающие под это определение, исключают любой реализующий код.

Теперь, когда с этим покончено....

Вот более подробное объяснение того, что конкретно означает решение Верховного суда.

Google был обвинен в копировании определенного декларируемого кода Java SE для использования в Android: он не только скопировал имена многих методов, но при этом скопировал структуру, последовательность и организацию этого декларируемого кода (например, как код был организован в пакеты, классы и тому подобное). Структура, последовательность и организация (SSO, от англ. "structure, sequence, and organization" - прим. пер.) могут быть защищены законом США об авторском праве. Это дело много лет ходило по судам, и его история увлекательна для ученых-юристов. Однако для наших целей я просто перейду к делу.

Если произведение не защищено авторским правом, то оно, как правило, может использоваться без ограничений. Google настойчиво утверждал, что декларируемый код, который он скопировал, был именно таким — не защищенным авторским правом. Аргументы в пользу отсутствия его охраны авторским правом включают то, что это незащищенный метод или система работы, которые четко прописаны в законах США об авторском праве как выходящие за рамки правовой охраны. Фактически, это аргумент, который Red Hat и IBM выдвинули в своем amicus brief, поданном в Верховный суд в январе 2020 года. Если бы суд постановил, что декларируемый код, скопированный Google, не защищен авторским правом, это было бы концом истории и абсолютной лучшей ситуацией для сообщества разработчиков.

К сожалению, мы не получили этого от суда, но мы получили следующий лучший вывод.

Как следствие моих слов, вы можете подвергнуть себя юридической опасности, скопировав или изменив чужое произведение, защищенное авторским правом, такое как книга, картинка или даже программное обеспечение, без разрешения правообладателя. Это связано с тем, что правообладатель защищенного авторским правом произведения имеет исключительное право копировать и вносить изменения (результаты чего известны как производные произведения). Поэтому, если у вас нет лицензии (которая может быть лицензией для ПО с открытым исходным кодом или иной, специализированной лицензией) или ваш случай не является добросовестным использованием, вы не можете копировать или изменять чужое произведение, защищенное авторским правом. Добросовестное использование – это правовая защита при использовании чьего-либо произведения, защищенного авторским правом, о чем я расскажу далее.

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

Вместо этого Верховный суд предположил в качестве аргумента, что у Oracle были действительные авторские права на декларируемый код (т.е., программный интерфейс), и на этом основании он спросил, подпадает ли использование Google под добросовестное использование. Результатом стало громкое "да"!

Когда применимо добросовестное использование?

Решение Верховного суда гласило, что использование Google частей декларирующего кода Java SE является добросовестным использованием. Добросовестное использование - это защита от нарушения авторского права, поскольку, если вы технически нарушаете чьи-либо авторские права, ваше использование может быть оправдано в соответствии с принципом добросовестного использования. Академическая наука является одним из примеров (среди многих), когда добросовестное использование может обеспечить надежную защиту во многих случаях.

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

Добросовестное использование – это факторный тест. В законодательстве США об авторском праве описаны четыре фактора, которые используются для определения того, применимо ли добросовестное использование (хотя суд также может рассмотреть иные факторы). Для более полного описания добросовестного использования см. эту норму закона на сайте Управления по авторскому праву США (US Copyright Office). Сложность добросовестного использования заключается в том, что не все факторы должны быть в наличии, и один фактор может иметь не такой вес, как другой. Некоторые факторы могут даже быть взаимосвязаны и сталкиваться друг с другом, в зависимости от фактов по делу. Удачным результатом решения Верховного суда является то, что оно было принято в пользу Google в отношении добросовестного использования по всем четырем установленным законом факторам и в решении 6-2. Это не та ситуация, которая была прямо на грани, далеко не так.

Последствия для разработчиков программного обеспечения

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

Прежде чем я перейду к этому, необходимо кратко обсудить варианты использования.
Существует два основных варианта использования программного интерфейса. В случае с Google это было переосмысление частей программного интерфейса Java SE для Android. Это означает, что Google сохранил тот же декларируемый код и переписал весь реализующий код для каждого объявления метода. Я называю это "повторной реализацией", и это похоже на правую сторону приведенной выше диаграммы, использованной в решении Верховного суда. Это очень распространено в опенсорсном сообществе: модуль имеет программный интерфейс, который могут использовать многие другие программные системы и модули, и креативный разработчик улучшает этот модуль, создавая новые и улучшенные реализации в виде нового реализующего кода. Используя один и тот же декларируемый код для каждого улучшенного метода, существующие программные системы и модули могут использовать улучшенный модуль без переписывания какого-либо кода или, возможно, с минимальным переписыванием. Это огромное преимущество, которое усиливает экосистему разработки с открытым исходным кодом.

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

4 совета для соответствия добросовестному использованию

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

1. В обоих случаях использования, описанных выше, используйте программный интерфейс в объеме не большем, чем требуется для обеспечения взаимодействия с другим программным модулем. Кроме того, имейте в виду, какой объём чужого произведения вы копируете. Чем меньше вы копируете произведение целиком, тем больше вес этого фактора добросовестного использования склоняется в вашу пользу.
2. Напишите свой собственный реализующий код при повторной реализации и улучшении существующего модуля.
3. Избегайте использования любого реализующего кода другого модуля, за исключением любого декларируемого кода, который мог быть полностью или частично воспроизведен в реализующем коде другого модуля. Такое иногда случается, и часто это неизбежно.
4. Сделайте свою реализацию настолько преобразующей, насколько это возможно. Это означает добавление чего-то нового с дополнительной целью или другим характером. В ситуации с Google компания изменила части Java SE, чтобы их можно было лучше использовать в мобильной среде. В данном деле это рассматривалось как фактор.

Может ли API быть защищен авторским правом?

Что насчет защиты API авторским правом и этой странной ситуации, когда Верховный суд не вынес решения по этому вопросу? Означает ли это, что API на самом деле защищены авторским правом? В противном случае, зачем нам проводить анализ добросовестного использования? Отличные вопросы!

Ответ: да, может быть защищен, но, на мой взгляд, это маловероятно в большинстве юрисдикций. По странной причуде, решение суда первой инстанции было обжаловано в CAFC, а не в 9-й окружной апелляционный суд США, что было бы традиционным способом обжалования дел, рассматриваемых в суде первой инстанции Сан-Франциско. CAFC обычно не рассматривает дела об авторском праве, каким является Oracle против Google.2 В то время как CAFC применил закон 9-го округа при рассмотрении дела, 9-й округ не должен быть связан этим решением.

В Соединенных Штатах 13 федеральных апелляционных судов. Таким образом, хотя CAFC (но не Верховный суд США) постановил, что программные интерфейсы защищены авторским правом, его решение не является обязательным для других апелляционных судов или даже для CAFC, за исключением редких случаев, когда CAFC применяет закон 9-го округа. Решение, однако, может быть "убедительным" в других случаях, рассматривающих возможность защиты авторских прав в 9-м округе. Существует лишь очень небольшой набор случаев и ситуаций, когда решение CAFC о защите авторских прав было бы обязательным в апелляционной судебной системе США.

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

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

1. “По нашему мнению, ... декларируемый код, если он вообще защищен авторским правом, отдалён от ядра авторского права больше, чем большинство компьютерных программ (таких как реализующий код).” (Источник: Google LLC против Oracle America, Inc., № 18-956, США, 5 апреля 2021 г.; стр. 38)

2. CAFC рассмотрел дело только потому, что оно изначально было связано с патентной претензией, которая в конечном итоге прекратила рассмотрение дела. Если бы не патентная претензия, это дело было бы рассмотрено 9-м окружным апелляционным судом США.

Прим. пер.:

• amicus brief – экспертное заключение
• Джеффри Р. Кауфман – старший коммерческий юрист корпорации Red Hat, Inc.