Oracle-advokater sammenligner Java API-reimplementering i Android med kopiering av innholdet i «Harry Potter» pdf

USAs høyesterett vil behandle en viktig sak tidlig i år. Oracle vs Google, som vil bestemme den juridiske statusen til API-en under immaterielle rettigheter. Hvis retten slutter seg til Oracle i søksmålet på flere milliarder dollar, kan det kvele konkurransen og sementere dominansen til teknologigigantene, muligens inkludert Google selv.

Samtidig ble Oracles virksomhet opprinnelig bygget på implementeringen av SQL-programmeringsspråket utviklet av IBM, og selv nå tilbyr selskapet en skytjeneste med en API fra Amazon S3, og dette er helt normalt. API-reimplementering har vært en naturlig del av utviklingen av informatikk helt siden starten av bransjen.

Oracle anklager Google for ulovlig å ha kopiert Java API-et, inkludert en liste med navngitte kommandoer knyttet til grammatiske strukturer. Operativsystemet Android er spesielt kompatibel med Java API for å gjøre det enklere for Java-programmerere å overføre programvare og kunnskap til den nye plattformen. For å gjøre dette, Android kopierte de relevante Java API-kommandoene og grammatikkstrukturene nøyaktig. argument Oracle er at en slik "re-implementering" av Java API kan sammenlignes med å kopiere en forfatters verk, for eksempel den litterære romanen "Harry Potter" (denne et ekte eksempel gitt av Oracle-advokater), a Google bryter Oracles opphavsrett på Java API-kommandonavn og -strukturer.

Men Java API-er er ikke de eneste API-ene, Android – er ikke den eneste reimplementeringen. I den moderne IT-bransjen er API-er allestedsnærværende, og reimplementering er grunnleggende for å opprettholde konkurranse og forhindre monopoler fra store bedrifter. tenker Charles Duane er direktør for teknologi og innovasjonspolitikk ved R Street Institute.

Duane gir eksemplet med den populære Amazon S3-lagringsplattformen. For å gjøre det mulig å skrive og hente filer fra S3, har Amazon utviklet omfattende, detaljert API å samhandle med tjenesten. For eksempel, for å få en liste over lagrede filer (ListObjekter) sender vi en GET-kommando som spesifiserer verts- og typeparametere kodingstype, fortsettelse-token и x-amz-date. For å jobbe med Amazon S3, må programvaren bruke disse og mange andre spesifikke parameternavn nøyaktig.

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 er den klare lederen på skytjenestemarkedet, og konkurrentene tilbyr re-implementeringer av S3 API, mens de må imitere kommandonavn, parametertagger, typeprefikser x-amz, grammatisk struktur og generell organisering av S3 API. Med andre ord, alt som Oracle hevder er opphavsrettsbeskyttet.

Blant selskapene som tilbyr en kopi av Amazon S3 API er det er også Oracle selv. For kompatibilitet kopierer Amazon S3 Compatibility API en rekke elementer av Amazon API, ned til x-amz-taggene.

Oracle hevder at lovligheten av handlingene deres er basert på åpen kildekode Apache 2.0-lisensen, som tillater gratis kopiering og modifikasjon av kode. For eksempel, Amazon SDK for Java leveres også med en Apache 2.0-lisens.

Men spørsmålet er om immaterielle rettigheter i det hele tatt gjelder ting som APIer. Dette må Høyesterett fastslå.

Hvem oppfant APIen?

Begrepet og konseptet for et "subrutinebibliotek" dukket først opp i boken Planning and Coding Problems for an Electronic Computing Instrument - Part II, Volume III (Princeton University Institute of Advanced Study, 1948) av Herman Goldstein og John von Neumann. kopi på archive.org. Innhold i tredje bind:

Dette er den første beskrivelsen av en programmeringsmetodikk for datamaskiner som lagrer programmer i minnet (tidligere eksisterte ikke dette). Den ble bredt distribuert til universiteter, som på den tiden prøvde å lage sine egne datamaskiner. Og viktigst av alt, boka inneholder en nøkkelidé: de fleste programmer vil bruke vanlige operasjoner, og biblioteker med rutiner vil redusere mengden ny kode og feil. Denne ideen ble ytterligere foredlet av Maurice Wilkes og satt ut i livet i EDSAC-maskinen, som han mottok Turing-prisen i 1967 for.

EDSAC-underrutinebiblioteket er til venstre

Det neste trinnet var å lage funksjoner av høyere orden og fullverdige programvaregrensesnitt, slik Maurice Wilkes og David Wheeler gjorde i Preparing Programs for the Electronic Digital Computer (1951).

Selve begrepet Grensesnitt for applikasjonsprogram (API) dukket opp et sted på slutten av 60-tallet.

Forfatter av presentasjonen "En kort subjektiv historie om API" Joshua Block gir flere eksempler på programmeringsgrensesnitt, instruksjonssett og subrutinebiblioteker: hvordan de ble opprettet og deretter brukt. Tanken er at gjenbruk er poenget med en API. Det er dette de ble skapt for i utgangspunktet. Og utviklere har alltid hatt muligheten til å kopiere og lage om andres APIer:

API
Creator
År
Reimplementering
År

FORTRAN bibliotek
IBM
1958
Univac
1961

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Standard C-bibliotek
AT&T/Bell Labs
1976
Mark Williams Co.
1980

Unix-systemanrop
AT&T/Bell Labs
1976
Mark Williams Co.
1980

VT100 Esc Seqs
Desember
1978
Heathkit
1980

IBM PC BIOS
IBM
1981
Phoenix Technologies
1984

MS-DOS CLI
Microsoft
1981
FreeDOS-prosjektet
1998

Hayes AT kommandosett
Hayes Micro
1982
Ankerautomatisering
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Samba prosjekt
1993

Win32
Microsoft
1993
Vinprosjekt
1996

Java 2 klasse biblioteker
Sol
1998
Google/Android
2008

Web API Deilig
Nydelig
2003
pinboard
2009

Kilde: "En kort subjektiv historie om API"

Kopiering og gjenbruk av APIer (biblioteker, instruksjonssett) er ikke bare riktig, men denne programmeringsmetodikken anbefales direkte i informatikkkanonene. Selv før de kopierte S3-programmeringsgrensesnitt, gjorde Oracle selv dette mange ganger. Dessuten ble Oracles virksomhet opprinnelig bygget på implementeringen av SQL-programmeringsspråket utviklet av IBM. Oracles første flaggskipprodukt var et DBMS, i stor grad kopiert fra IBM System R. I dette tilfellet snakker vi om re-implementering av SQL som en "standard API" for en DBMS.

Å påtvinge immaterielle rettigheter på APIer kan skape et lovlig minefelt som påvirker alle. APIer implementerer og andre skytjenester. Mange tekniske standarder, for eksempel Wi-Fi og Internett-protokoller, inkluderer APIer. Programmeringsgrensesnitt er nødvendigvis re-implementert i en eller annen form på hver datamaskin og server på Internett. Oracles opphavsrettsteori kan gjøre nesten alt du gjør med datamaskinen ulovlig.

For å unngå disse vidtrekkende konsekvensene har Oracle og ankedomstolen som opprettholdt argumentene deres forsøkt å begrense opphavsrettsbrudd til visse API-reimplementeringer som er "inkompatible" med originalen. Men delvis re-implementering også er vanlig. Selv i sin kopi av S3 API bemerker Oracle en rekke "forskjeller" og inkompatibiliteter med de originale Amazon APIene.

Hovedfaren ved Oracles søksmål er at det kan hindre mindre teknologiselskaper i å lage versjoner av systemer som er kompatible med dominerende plattformer som S3. Uten slik kompatibilitet vil programmerere effektivt bli utestengt fra dette selskapets tilbud.

Bransjerepresentanter og utbyggere får bare håpe at fornuften vil seire her, og dommere kan det grunnleggende om programmering.

Kilde: www.habr.com