Юристи 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).

сам термін Інтерфейс програми програми (API) з'явився десь наприкінці 60-х.

Автор презентації Коротка Суб'єктивна історія API Джошуа Блок наводить кілька прикладів програмних інтерфейсів, наборів інструкцій та бібліотек підпрограм: як вони створювалися та використовувалися згодом. Ідея в тому, що повторне використання є сенс API. Саме для цього вони створювалися насамперед. І у розробників завжди була можливість копіювати та переробляти чужі API:

API
Творець
рік
Повторна реалізація
рік

Бібліотека FORTRAN
IBM
1958
Юнівак
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
Грудень
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
саман
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Samba Project
1993

Win32
Microsoft
1993
Проект вина
1996

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

Веб-API Delicious
дуже смачний
2003
Шпилька
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