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

USA:s högsta domstol kommer att behandla ett stort mål i början av året Oracle vs. Google, som kommer att avgöra API:ets rättsliga status i enlighet med immateriella rättigheter. Om domstolen dömer i Oracles rättegång på flera miljarder dollar kan det strypa konkurrensen och cementera dominansen av teknikjättar, eventuellt inklusive Google själv.

Samtidigt byggdes Oracles verksamhet ursprungligen på implementeringen av programmeringsspråket SQL 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 datavetenskaplig utveckling sedan fältets start.

Oracle anklagar Google för att olagligt kopiera Java API:et, inklusive en lista med namngivna kommandon kopplade till grammatiska strukturer. Operativsystemet Android är specifikt kompatibel med Java API för att göra det enklare för Java-programmerare att överföra programvara och kunskap till den nya plattformen. För att göra detta, Android kopierade korrekt de relevanta Java API-kommandona och grammatikstrukturerna. argument Poängen med Oracle är att en sådan "omimplementering" av Java API kan jämföras med att kopiera en författares verk, till exempel den litterära romanen "Harry Potter" (detta är 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, Android — är inte den enda återimplementeringen. I den moderna IT-branschen är API:er allestädes närvarande, och återimplementering är grundläggande för att upprätthålla konkurrens och förhindra monopol från stora företag. tänker Charles Duane, chef för teknik och innovationspolitik vid R Street Institute.

Duane ger exemplet med den populära datalagringsplattformen Amazon S3. För att göra det möjligt att skriva och hämta filer från S3 har Amazon utvecklat en 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 med värd- och typparametrarna kodningstyp, fortsättningssymbol и 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 omimplementering av S3 API, men de måste imitera kommandonamn, parametertaggar, typprefix x-amz, den grammatiska strukturen och den allmänna organisationen 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, ända 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 koden. Till exempel, Amazon SDK för Java kommer också med en Apache 2.0-licens.

Men frågan är om immaterialrätt överhuvudtaget 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 Herman Goldstine och John von Neumanns bok, Planning and Coding Problems for Electronic Computing Instruments, Del II, Volym III (Princeton University Institute for Advanced Study, 1948), kopiera på archive.org. Innehållet i tredje volymen:

Detta är den första beskrivningen av en programmeringsmetodik för datorer med program lagrade i minnet (tidigare existerade inte en sådan metod). Den var allmänt distribuerad bland universitet, som vid den tiden försökte skapa sina egna datorer. Och viktigast av allt, boken innehåller huvudidén: de flesta program kommer att använda vanliga operationer, och bibliotek med rutiner kommer att minska mängden ny kod och fel. Denna idé utvecklades vidare av Maurice Wilkes och omsattes i praktiken i EDSAC-maskinen, för vilken han fick Turing Award 1967.

EDSAC-subrutinbiblioteket finns till vänster

Nästa steg var att skapa funktioner av högre ordning och fullfjädrade programmeringsgränssnitt, vilket gjordes av Maurice Wilkes och David Wheeler i deras bok, 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 av API:er" 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 hela poängen med ett API. Det är precis därför de skapades i första hand. Och utvecklare har alltid haft möjlighet att kopiera och omarbeta 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-systemsamtal
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 klassbibliotek
sol
1998
Google/Android
2008

Utsökt webb-API
Utsökt
2003
Anslagstavla
2009

Källa: "En kort subjektiv historia av API:er"

Att kopiera och återanvända API:er (bibliotek, instruktionsuppsättningar) är inte bara det rätta att göra, utan det är en programmeringsmetodik som direkt rekommenderas i datavetenskapens kanoner. Redan innan de kopierade S3:s API:er hade Oracle själv gjort detta vid ett flertal tillfällen. Dessutom byggdes Oracles verksamhet ursprungligen på implementeringen av SQL-programmeringsspråket som utvecklats av IBM. Oracles första flaggskeppsprodukt var ett DBMS som till stor del kopierades från IBM System R. I det här fallet pratar vi om att implementera SQL som ett "standard API" för DBMS.

Att lägga immateriella rättigheter på API:er kan skapa ett lagligt minfält som skadar alla. API:er implementerar och andra molntjänster. Många tekniska standarder, som Wi-Fi och Internetprotokoll, inkluderar API:er. API:er 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 försökte Oracle och appellationsdomstolen som biföll sina argument att begränsa upphovsrättsintrång till endast 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 Amazons ursprungliga API:er.

Den största faran med Oracles stämningsansökan är att den kan hindra mindre teknikföretag från att bygga versioner av sina 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 sunt förnuft råder här, och domare kan grunderna i programmering.

Källa: will.com