Юристы Oracle сравнивают реимплементацию Java API в Android с копированием содержания «Гарри Поттера», pdf

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

В то же время бизнес Oracle изначально построен на имплементации языка программирования SQL, разработанного IBM, да и сейчас компания предлагает облачный сервис с API из Amazon S3, и это совершенно нормально. Реимплементация API была естественной частью развития информатики с самого зарождения отрасли.

Oracle обвиняет Google в незаконном копировании Java API, в том числе списка именованных команд, привязанных к грамматическим структурам. Операционная система Android специально совместима с Java API, чтобы Java-программистам было проще перенести программное обеспечение и знания на новую платформу. Для этого Android точно скопировала соответствующие команды Java API и грамматические структуры. Аргумент Oracle заключается в том, что такую «реимплементацию» Java API можно сравнить с копированием авторского произведения, такого как литературный роман «Гарри Поттер» (это реальный пример, который привели юристы Oracle), а Google нарушает копирайт Oracle на имена команд и структуры Java API.

Но Java API — не единственные API, а Android — не единственная реимплементация. В современной IT-индустрии API встречаются повсеместно, а повторное внедрение фундаментально важно для сохранения конкуренции, чтобы предотвратить монополию крупных фирм, считает Чарльз Дюан, директор по технической и инновационной политике в R Street Institute.

Дюан приводит пример популярной платформы хранения данных Amazon S3. Чтобы позволить запись и извлечение файлов с S3, Amazon разработала всесторонний, подробный API для взаимодействия с сервисом. Например, для получения списка сохранённых файлов (ListObjects) мы отправляем команду GET с указанием хоста и параметров типа encoding-type, continuation-token и x-amz-date. Для работы с Amazon S3 программное обеспечение должно в точности использовать эти и многие другие специфические названия параметров.

GET /?Delimiter=Delimiter&EncodingType=EncodingType&Marker=Marker&MaxKeys=MaxKeys&Prefix=Prefix HTTP/1.1
Host: Bucket.s3.amazonaws.com
x-amz-request-payer: RequestPayer

Amazon является явным лидером на рынке облачных сервисов, а её конкуренты предлагают реимплементацию API S3, при этом им приходится имитировать названия команд, теги параметров, префиксы типа x-amz, грамматическую структуру и общую организацию API S3. Другими словами, всё то, что, по утверждению Oracle, защищено авторским правом.

Среди компаний, предлагающих копию API Amazon S3, есть и сама Oracle. Для совместимости Amazon S3 Compatibility API копирует многочисленные элементы API Amazon, вплоть до тегов x-amz.

Oracle уверяет, что законность её действий основана на опенсорсной лицензии Apache 2.0, которая позволяет свободное копирование и изменение кода. Например, Amazon SDK для Java тоже поставляется с лицензией Apache 2.0.

Но вопрос в том, применимо ли вообще законодательство об интеллектуальной собственности к таким объектам, как API. Именно это должен установить Верховный суд.

Кто изобрёл API?

Термин и понятие «библиотеки подпрограмм» (subroutine library) впервые появилось в книге Хермана Голдстайна и Джона фон Неймана «Планирование и кодирование проблем для электронного вычислительного инструмента» — часть II, том III (Институт продвинутых исследований Принстонского университета, 1948), копия на archive.org. Содержание третьего тома:

Это первое описание методологии программирования для компьютеров с сохранением программ в памяти (ранее таковой не существовало). Она широко разошлась по университетам, которые в то время пытались создать собственные вычислительные машины. И главное, книга содержит ключевую идею: большинство программ будет использовать общие операции, а библиотеки с подпрограммами уменьшат количество нового кода и ошибок. Эту идею доработал Морис Уилкс и применил на практике в машине EDSAC, за что получил премию Тьюринга 1967 года.

Библиотека подпрограмм EDSAC стоит слева

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

Сам термин Application Program Interface (API) появился где-то в конце 60-х.

Автор презентации «Краткая Субъективная история API» Джошуа Блок приводит несколько примеров программных интерфейсов, наборов инструкций и библиотек подпрограмм: как они создавались и использовались впоследствии. Идея в том, что повторное использование — и есть смысл API. Именно для этого они создавались в первую очередь. И у разработчиков всегда была возможность копировать и переделывать чужие API:

API
Создатель
Год
Повторная реализация
Год

Библиотека FORTRAN
IBM
1958
Univac
1961

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Стандартная библиотека С
AT&T / Bell Labs
1976
Mark Williams Co.
1980

Системные вызовы Unix
AT&T / Bell Labs
1976
Mark Williams Co.
1980

VT100 Esc Seqs
DEC
1978
Heathkit
1980

IBM PC BIOS
IBM
1981
Phoenix Technologies
1984

MS-DOS CLI
Microsoft
1981
FreeDOS Project
1998

Набор команд Hayes AT
Hayes Micro
1982
Anchor Automation
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Samba Project
1993

Win32
Microsoft
1993
Wine Project
1996

Библиотеки классов Java 2
Sun
1998
Google/Android
2008

Веб-API Delicious
Delicious
2003
Pinboard
2009

Источник: «Краткая Субъективная история API»

Копировать и повторно использовать API (библиотеки, наборы инструкций) — это не только правильно, но такая методология программирования прямо рекомендуется в канонах информатики. Ещё до копирования программных интерфейсов S3 сама компания Oracle неоднократно делала это. Более того, бизнес Oracle изначально построен на имплементации языка программирования SQL, разработанного IBM. Первым флагманским продуктом Oracle стала СУБД, во многом скопированная с IBM System R. В данном случае речь идёт о реимплементации SQL как «стандартного API» для СУБД.

Наложение интеллектуальных прав на интерфейсы API может создать юридическое минное поле, от которого пострадают все. Интерфейсы API реализуют и другие облачные сервисы. Многие технические стандарты, такие как Wi-Fi и протоколы интернета — включают API. Программные интерфейсы обязательно повторно реализованы в каком-то виде на каждом компьютере и сервере в интернете. Теория копирайта Oracle может превратить почти всё, что вы делаете с компьютером, в незаконное деяние.

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

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

Представителям индустрии и разработчикам остаётся надеяться, что разум здесь восторжествует, а судьи знают основы программирования.

Источник: habr.com