Почему решение судебного дела Oracle vs Google предвещает неприятности для облачных компаний

Google
Oracle vs Google

Судебное решение, принятое 9 мая федеральным судом США в деле, Oracle vs Google, которое касалось иска Oracle по поводу якобы незаконного использования Google компонентов языка программирования Java в популярнейшей мобильной ОС Android, приняло неожиданный новый оборот. Последствия этого решения, если оно будет утверждено, окажутся весьма далеко идущими для всех.

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

Что же именно оспаривалось, и на каких основаниях суд пришел к принятому решению? Судебный иск, который являлся продолжением более старого иска Oracle (который Google выиграл, но Oracle подал аппеляцию), оспаривает право Google свободно пользоваться API Java. Проще говоря, решение объявляет API программного продукта/сервиса таким же объектом копирайтного права, как и сама программа/сервис. Это решение имеет огромные последствия так как в мире ИТ, API, который связывает программы и сервисы вместе, считается одним из базовых строительных блоков интеграции, к которому неприменимо право копирайта.

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

Это решение идет вразрез с традиционной парадигмой «идея/воплощение», в рамках которой копирайту подлежит воплощение какой-либо идеи или концепции, но не сама концепция. Например, понятие и концепция сонета не подлежит копирайту, но конкретная поэма – подлежит. В случае с API Java, суд дал Oracle право на то, что, по всей видимости, является функциональным концептом.

Судья мотивировала решение сравнением заголовков «java.lang.ref» и «java.lang.reflect», обозначений API в Oracle с литературными произведениями. Аналогично, вступление к литературному произведению, скажем, «Истории двух городов» Диккенса, является всего лишь текстом, который можно разбить на короткие фразы. И тем не менее, никто не будет спорить, что литература не может защищаться правом копирайта только потому, что текст можно разбить на более короткие составляющие компоненты.

Понятно, что это «объяснение» не придало оптимизма ИТ-братии и экспертам, специализирующимся в вопросах интеллектуальной собственности. Реакция на решение варьировалась от возмущения до удивления, но общим было одно – все считали, что решение сильно осложнит и без того непростые взаимоотношения в области интеллектуального права.

Google, скорее всего, подаст апелляцию в вышестоящую инстанцию, но даже если это случится, решение может прийти не скоро – в конце концов, первая апелляция заняла два года, вторая может занять еще больше времени, а на это время основным прецедентом будет считаться текущее решение, которое создает массу новых проблем, корень которых лежит в том, что широкое (и бесплатное) использование API сделало многие веб-сервисы очень популярными, а некоторые так и прямо-таки незаменимыми. Именно опасения такого рода удерживали многих облачных провайдеров от интеграции API, например, инструментов Amazon Web Services в свои услуги. Использование API AWS имел смысл, так как он стал де-факто стандартом для публичных облачных платформ и очень много разработчиков использовало его. Но никто не подозревал, что использование чужого API станет проблемой.

А теперь это проблема. Так как за последние годы использование API стало широкой практикой для связи устройств, сервисов и платформ в единые продукты, которые используют данные и услуги из многих источников, то злоупотребление даже одной из компаний новообретенными «правами» может повлечь массу проблем. Что можно сделать, чтобы максимально их избежать?

Правило №1: спрашивайте разрешение


Вернемся к ситуации с Amazon. Когда два года назад Eucalyptus добавил поддержку API AWS в свое решение, многие были удивлены. Другие конкуренты избегали связываться со сторонними API – из-за опасения возникновения именно такой ситуации. Так как же собирается Eucalyptus действовать в сложившейся ситуации?

Как оказывается, никак. Представители Eucalyptus сообщили, что имплементация API AWS, которая используется в сервисе, не может быть опротестована Amazon, но тем не менее Eucalyptus получил лицензию Amazon на использование его API – на всякий случай. И именно такой способ действий и является наиболее правильным и разумным.

Здравый смысл предполагает, что если компания Б хочет использовать API, который принадлежит компании А, то начинать надо с переговоров с компанией А. Использование сторонних API в своих коммерческих сервисах всегда было серой зоной, но в связи с недавними событиями, использовать API без разрешения уже просто опасно. В случае с Eucalyptus, скорее всего Amazon не будет иметь претензий к первому, потому что модель работы Eucalyptus не представляет конкуренции для Amazon, а наоборот, усиливает его позиции, делая взаимодействие публичных и частных облачных инфраструктур более простым.

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

API как контент


В некотором смысле рассмотрение API как защищаемого контента имеет смысл. Так, крупные компании вкладывают в его разработку много средств и времени. Например, API AWS отлажен по всем параметрам, что позволяет другим пользоваться им, не озадачиваясь вопросами его безопасности, производительности и так далее.

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

Как это случилось и на этот раз.

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn