Avocații Oracle compară reimplementarea API-ului Java în Android cu copierea conținutului din „Harry Potter”, pdf

Curtea Supremă a SUA va audia un caz important la începutul acestui an. Oracle vs Google, care va determina statutul juridic al API-ului conform legislației privind proprietatea intelectuală. Dacă instanța este de partea Oracle în procesul său de miliarde de dolari, ar putea înăbuși concurența și ar putea consolida dominația giganților din tehnologie, inclusiv Google însuși.

Totodată, afacerea Oracle a fost construită inițial pe implementarea limbajului de programare SQL dezvoltat de IBM, iar chiar și acum compania oferă un serviciu cloud cu un API de la Amazon S3, iar acest lucru este complet normal. Reimplementarea API a fost o parte naturală a dezvoltării informaticii încă de la începuturile industriei.

Oracle acuză Google de copierea ilegală a API-ului Java, inclusiv o listă de comenzi denumite legate de structuri gramaticale. Sistemul de operare Android este compatibil în mod specific cu API-ul Java pentru a facilita transferul de software și cunoștințe către noua platformă de către programatorii Java. Pentru a realiza acest lucru, Android a copiat cu precizie comenzile API Java și structurile gramaticale relevante. Argument Oracle este că o astfel de „reimplementare” a API-ului Java poate fi comparată cu copierea operei unui autor, cum ar fi romanul literar „Harry Potter” (acest un exemplu real dat de avocații Oracle) și Google încalcă drepturile de autor ale Oracle asupra numelor și structurilor comenzilor API Java.

Însă API-urile Java nu sunt singurele API-uri, ci Android — nu este singura reimplementare. În industria IT modernă, API-urile sunt omniprezente, iar reimplementarea este fundamentală pentru menținerea concurenței și prevenirea monopolurilor din partea firmelor mari. consideră Charles Duane este director de tehnologie și politică de inovare la Institutul R Street.

Duane dă exemplul popularei platforme de stocare Amazon S3. Pentru a permite scrierea și preluarea fișierelor din S3, Amazon a dezvoltat cuprinzătoare, API detaliat pentru a interacționa cu serviciul. De exemplu, pentru a obține o listă de fișiere salvate (ListObjects) trimitem o comandă GET specificând parametrii gazdă și tip tip de codificare, continuare-token и x-amz-date. Pentru a lucra cu Amazon S3, software-ul trebuie să utilizeze exact acestea și multe alte nume de parametri specifici.

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 este liderul clar pe piața serviciilor cloud, iar concurenții săi oferă reimplementari ale API-ului S3, în timp ce trebuie să imite numele comenzilor, etichetele parametrilor, prefixele de tip. x-amz, structura gramaticală și organizarea generală a API-ului S3. Cu alte cuvinte, tot ceea ce pretinde Oracle este protejat prin drepturi de autor.

Printre companiile care oferă o copie a Amazon S3 API se numără există și Oracle însuși. Pentru compatibilitate, Amazon S3 Compatibility API copiază numeroase elemente ale Amazon API, până la etichetele x-amz.

Oracle susține că legalitatea acțiunilor sale se bazează pe licența open source Apache 2.0, care permite copierea și modificarea gratuită a codului. De exemplu, Amazon SDK pentru Java vine și cu o licență Apache 2.0.

Dar întrebarea este dacă legea proprietății intelectuale se aplică chiar și la lucruri precum API-urile. Asta trebuie să stabilească Curtea Supremă.

Cine a inventat API-ul?

Termenul și conceptul de „bibliotecă de subrutine” au apărut pentru prima dată în cartea Planning and Coding Problems for an Electronic Computing Instrument - Part II, Volume III (Princeton University Institute of Advanced Study, 1948) de Herman Goldstein și John von Neumann. copiați pe archive.org. Conținutul celui de-al treilea volum:

Aceasta este prima descriere a unei metodologii de programare pentru calculatoare care stochează programe în memorie (anterior aceasta nu exista). A fost distribuit pe scară largă universităților, care la vremea aceea încercau să-și creeze propriile computere. Și cel mai important, cartea conține o idee cheie: majoritatea programelor vor folosi operațiuni comune, iar bibliotecile cu rutine vor reduce cantitatea de cod nou și erori. Această idee a fost rafinată în continuare de Maurice Wilkes și pusă în practică în mașina EDSAC, pentru care a primit premiul Turing în 1967.

Biblioteca de subrutine EDSAC este în stânga

Următorul pas a fost crearea de funcții de ordin superior și interfețe software cu drepturi depline, așa cum au făcut Maurice Wilkes și David Wheeler în Preparing Programs for the Electronic Digital Computer (1951).

Termenul în sine Interfața programului de aplicație (API) a apărut undeva la sfârșitul anilor 60.

Autorul prezentării „O scurtă istorie subiectivă a API” Joshua Block oferă câteva exemple de interfețe de programare, seturi de instrucțiuni și biblioteci de subrutine: cum au fost create și utilizate ulterior. Ideea este că reutilizarea este scopul unui API. Pentru asta au fost create în primul rând. Și dezvoltatorii au avut întotdeauna ocazia să copieze și să refacă API-urile altor persoane:

API
Creator
An
Reimplementare
An

biblioteca FORTRAN
IBM
1958
Univac
1961

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Biblioteca standard C
AT&T/Bell Labs
1976
Mark Williams Co.
1980

Apeluri de sistem Unix
AT&T/Bell Labs
1976
Mark Williams Co.
1980

VT100 Esc Seqs
Decembrie
1978
Heathkit
1980

BIOS PC IBM
IBM
1981
Tehnologii Phoenix
1984

CLI MS-DOS
Microsoft
1981
Proiectul FreeDOS
1998

Set de comandă Hayes AT
Hayes Micro
1982
Anchor Automation
1985

PostScript
chirpici
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Proiectul Samba
1993

Win32
Microsoft
1993
Proiectul Vinului
1996

Biblioteci de clasă Java 2
soare
1998
Google/Android
2008

Web API Delicious
Delicios
2003
Pinboard
2009

Sursa: „O scurtă istorie subiectivă a API”

Copierea și reutilizarea API-urilor (biblioteci, seturi de instrucțiuni) nu este doar corectă, dar această metodologie de programare este direct recomandată în canoanele informaticii. Chiar și înainte de a copia interfețele de programare S3, Oracle însuși a făcut acest lucru de multe ori. Mai mult, afacerea Oracle a fost construită inițial pe implementarea limbajului de programare SQL dezvoltat de IBM. Primul produs emblematic al Oracle a fost un DBMS, copiat în mare parte din IBM System R. În acest caz, vorbim despre reimplementarea SQL ca „API standard” pentru un DBMS.

Impunerea drepturilor de proprietate intelectuală asupra API-urilor poate crea un câmp minat legal care îi afectează pe toată lumea. Interfețele API implementează și alte servicii cloud. Multe standarde tehnice, cum ar fi protocoalele Wi-Fi și Internet, includ API-uri. Interfețele de programare sunt neapărat reimplementate într-o anumită formă pe fiecare computer și server de pe Internet. Teoria dreptului de autor a Oracle poate face ilegal aproape orice faci cu computerul tău.

Pentru a evita aceste consecințe de amploare, Oracle și instanța de apel care și-a susținut argumentele au încercat să limiteze încălcarea drepturilor de autor la anumite reimplementari API care sunt „incompatibile” cu originalul. Dar și reimplementari parțiale sunt banale. Chiar și în copia sa a API-ului S3, Oracle observă numeroase „diferențe” și incompatibilități cu API-urile Amazon originale.

Principalul pericol al procesului Oracle este că ar putea împiedica companiile de tehnologie mai mici să creeze versiuni de sisteme care sunt compatibile cu platformele dominante precum S3. Fără o astfel de compatibilitate, programatorii vor fi blocați efectiv din ofertele acestei companii.

Reprezentanții industriei și dezvoltatorii pot doar spera că rațiunea va prevala aici și judecătorii cunosc elementele de bază ale programării.

Sursa: www.habr.com