Oracle-jurister jämför omimplementeringen av Java API i Android med att kopiera innehållet i "Harry Potter", pdf

USA:s högsta domstol kommer att behandla ett viktigt mål i början av året. Oracle vs Google, som kommer att avgöra API:ets juridiska status enligt immateriella rättigheter. Om domstolen ställer sig på Oracles sida i dess process för mångmiljarddollar kan det strypa konkurrensen och cementera dominansen av teknikjättar, eventuellt inklusive Google själv.

Samtidigt byggdes Oracles verksamhet från början på implementeringen av SQL-programmeringsspråket utvecklat av IBM, och redan nu erbjuder företaget en molntjänst med ett API från Amazon S3, och detta är helt normalt. API-återimplementering har varit en naturlig del av utvecklingen av datavetenskap ända sedan branschens början.

Oracle anklagar Google för att illegalt kopiera Java API, inklusive en lista över namngivna kommandon kopplade till grammatiska strukturer. Operativsystemet Android är specifikt kompatibelt med Java API för att göra det lättare för Java-programmerare att överföra programvara och kunskap till den nya plattformen. För att göra detta kopierade Android exakt motsvarande Java API-kommandon och grammatiska strukturer. argument Oracle menar att en sådan "omimplementering" av Java API kan jämföras med att kopiera en författares verk, som den litterära romanen "Harry Potter" (denna ett verkligt exempel från Oracles advokater) och Google bryter mot Oracles upphovsrätt på Java API-kommandonamn och strukturer.

Men Java API:er är inte de enda API:erna, och Android är inte den enda omimplementeringen. I dagens IT-industri finns API:er allestädes närvarande, och återinförandet är grundläggande för att upprätthålla konkurrensen för att förhindra att stora företag monopoliserar tänker Charles Duane är chef för teknik och innovationspolitik vid R Street Institute.

Duane ger exemplet med den populära Amazon S3-lagringsplattformen. För att göra det möjligt att skriva och hämta filer från S3 har Amazon utvecklat omfattande, detaljerat API att interagera med tjänsten. Till exempel, för att få en lista över sparade filer (Listobjekt) skickar vi ett GET-kommando som anger värd- och typparametrarna kodningstyp, fortsättning-token и x-amz-date. För att arbeta med Amazon S3 måste programvaran använda dessa och många andra specifika parameternamn exakt.

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 är den tydliga ledaren på molntjänstmarknaden, och dess konkurrenter erbjuder omimplementeringar av S3 API, samtidigt som de måste imitera kommandonamn, parametertaggar, typprefix x-amz, grammatisk struktur och allmän organisation av S3 API. Med andra ord, allt som Oracle hävdar är upphovsrättsskyddat.

Bland företagen som erbjuder en kopia av Amazon S3 API är det finns också Oracle själv. För kompatibilitet kopierar Amazon S3 Compatibility API många delar av Amazon API, ner till x-amz-taggarna.

Oracle hävdar att lagligheten av dess handlingar baseras på Apache 2.0-licensen med öppen källkod, som tillåter fri kopiering och modifiering av kod. Till exempel, Amazon SDK för Java kommer även med en Apache 2.0-licens.

Men frågan är om immaterialrätt ens gäller saker som API:er. Det är vad Högsta domstolen ska fastställa.

Vem uppfann API?

Termen och konceptet för ett "subrutinbibliotek" dök först upp 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 och John von Neumann. kopiera på archive.org. Innehållet i tredje volymen:

Detta är den första beskrivningen av en programmeringsmetodik för datorer som lagrar program i minnet (tidigare fanns inte detta). Den distribuerades brett till universiteten, som vid den tiden försökte skapa sina egna datorer. Och viktigast av allt, boken innehåller en nyckelidé: de flesta program kommer att använda vanliga operationer, och bibliotek med rutiner kommer att minska mängden ny kod och fel. Denna idé förfinades ytterligare av Maurice Wilkes och sattes i praktiken i EDSAC-maskinen, för vilken han fick 1967 års Turing Award.

EDSAC-subrutinbiblioteket finns till vänster

Nästa steg var att skapa funktioner av högre ordning och fullfjädrade mjukvarugränssnitt, som Maurice Wilkes och David Wheeler gjorde i Preparing Programs for the Electronic Digital Computer (1951).

Själva termen Applikationsprogramgränssnitt (API) dök upp någonstans i slutet av 60-talet.

Författare till presentationen "En kort subjektiv historia om API" Joshua Block ger flera exempel på programmeringsgränssnitt, instruktionsuppsättningar och subrutinbibliotek: hur de skapades och sedan användes. Tanken är att återanvändning är poängen med ett API. Det är vad de skapades för i första hand. Och utvecklare har alltid haft möjlighet att kopiera och göra om andras API:er:

API
skaparen
År
Återimplementering
Å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
December
1978
Heathkit
1980

IBM PC BIOS
IBM
1981
Phoenix Technologies
1984

MS-DOS CLI
Microsoft
1981
FreeDOS-projekt
1998

Hayes AT kommandouppsättning
Hayes Micro
1982
Ankare automation
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Samba projekt
1993

Win32
Microsoft
1993
Vinprojekt
1996

Java 2 klass bibliotek
sol
1998
Google/Android
2008

Web API Delicious
Utsökt
2003
Anslagstavla
2009

Källa: "En kort subjektiv historia om API"

Att kopiera och återanvända API:er (bibliotek, instruktionsuppsättningar) är inte bara det rätta att göra, utan det är en programmeringsmetod som uttryckligen rekommenderas inom datavetenskapens kanoner. Redan innan de kopierade S3-programmeringsgränssnitten gjorde Oracle själv detta många gånger. Dessutom byggdes Oracles verksamhet från början på implementeringen av SQL-programmeringsspråket som utvecklats av IBM. Oracles första flaggskeppsprodukt var ett DBMS, till stor del kopierat från IBM System R. I det här fallet talar vi om omimplementering av SQL som ett "standard API" för ett DBMS.

Att införa immateriella rättigheter på API:er kan skapa ett lagligt minfält som påverkar alla. API:er implementerar och andra molntjänster. Många tekniska standarder, som Wi-Fi och Internetprotokoll, inkluderar API:er. Programmeringsgränssnitt implementeras med nödvändighet i någon form på varje dator och server på Internet. Oracles upphovsrättsteori kan göra nästan allt du gör med din dator olagligt.

För att undvika dessa långtgående konsekvenser har Oracle och appellationsdomstolen som biföll dess argument försökt begränsa upphovsrättsintrång till vissa API-omimplementeringar som är "inkompatibla" med originalet. Men även partiella omimplementeringar är vanliga. Även i sin kopia av S3 API noterar Oracle många "skillnader" och inkompatibiliteter med de ursprungliga Amazon API:erna.

Den största faran med Oracles rättegång är att den kan hindra mindre teknikföretag från att skapa versioner av system som är kompatibla med dominerande plattformar som S3. Utan sådan kompatibilitet kommer programmerare att effektivt stängas ute från detta företags erbjudanden.

Branschrepresentanter och utvecklare kan bara hoppas att förnuftet ska segra här, och domare kan grunderna i programmering.

Källa: will.com