Адвокатите на 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 не е единственото повторно внедряване. В днешната ИТ индустрия приложните програмни интерфейси (API) са повсеместни и повторното им въвеждане е фундаментално за поддържане на конкуренцията, за да се попречи на големите фирми да монополизират мисли Чарлз Дуейн е директор на политиката за технологии и иновации в R Street Institute.

Дуейн дава пример с популярната платформа за съхранение Amazon S3. За да даде възможност за писане и извличане на файлове от S3, Amazon разработи изчерпателна, подробен API за взаимодействие с услугата. Например, за да получите списък със запазени файлове (ListObjects) изпращаме команда GET, указваща параметрите на хоста и типа тип кодиране, продължение-токен и x-amz-дата. За да работи с 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 е категоричният лидер на пазара на облачни услуги и неговите конкуренти предлагат повторно внедряване на S3 API, докато трябва да имитират имена на команди, тагове на параметри, префикси на типове x-amz, граматическа структура и обща организация на S3 API. С други думи, всичко, което Oracle твърди, е защитено с авторски права.

Сред компаниите, предлагащи копие на API на Amazon S3, са има и самия Oracle. За съвместимост API за съвместимост на Amazon S3 копира множество елементи от API на Amazon, до таговете x-amz.

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

Но въпросът е дали законът за интелектуалната собственост дори се прилага за неща като API. Това трябва да реши Върховният съд.

Кой е изобретил API?

Терминът и концепцията за "библиотека на подпрограми" се появява за първи път в книгата Проблеми на планирането и кодирането за електронен изчислителен инструмент - част II, том III (Институт за напреднали изследвания на Принстънския университет, 1948 г.) от Херман Голдщайн и Джон фон Нойман. копие на archive.org. Съдържание на трети том:

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

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

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

Самият термин Интерфейс на приложната програма (API) се появява някъде в края на 60-те години.

Автор на презентацията „Кратка субективна история на API“ Джошуа Блок дава няколко примера за програмни интерфейси, набори от инструкции и библиотеки с подпрограми: как са били създадени и впоследствие използвани. Идеята е, че повторното използване е смисълът на API. За това са създадени на първо място. И разработчиците винаги са имали възможността да копират и преработват API на други хора:

API
създател
Година
Повторно внедряване
Година

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

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Стандартна C библиотека
AT&T/Bell Labs
1976
Марк Уилямс Ко.
1980

Unix системни повиквания
AT&T/Bell Labs
1976
Марк Уилямс Ко.
1980

VT100 Esc Seqs
Декември
1978
Heathkit
1980

IBM PC BIOS
IBM
1981
Phoenix Technologies
1984

MS-DOS CLI
Microsoft
1981
Проект FreeDOS
1998

Hayes AT набор от команди
Hayes Micro
1982
Автоматизация на котвата
1985

PostScript
Кирпич
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Проект Самба
1993

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

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

Уеб API 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, които са „несъвместими“ с оригинала. Но и частични повторни внедрявания са нещо обичайно. Дори в своето копие на S3 API, Oracle отбелязва множество „разлики“ и несъвместимости с оригиналните API на Amazon.

Основната опасност от делото на Oracle е, че може да попречи на по-малките технологични компании да създават версии на системи, които са съвместими с доминиращи платформи като S3. Без такава съвместимост програмистите ще бъдат ефективно изключени от предложенията на тази компания.

Представителите на индустрията и разработчиците могат само да се надяват, че разумът ще надделее тук и съдиите познават основите на програмирането.

Източник: www.habr.com