Oracle-advokater sammenligner re-implementeringen af ​​Java API i Android med kopiering af indholdet af "Harry Potter", pdf

Den amerikanske højesteret vil behandle en vigtig sag i begyndelsen af ​​året. Oracle vs Google, som vil bestemme API'ets juridiske status i henhold til intellektuel ejendomsret. Hvis retten slutter sig til Oracle i dens multimilliard-dollar-retssag, kan det kvæle konkurrencen og cementere dominansen af ​​tech-giganter, måske også Google selv.

Samtidig var Oracles forretning oprindeligt bygget på implementeringen af ​​SQL-programmeringssproget udviklet af IBM, og allerede nu tilbyder virksomheden en cloud-tjeneste med en API fra Amazon S3, og det er helt normalt. API-genimplementering har været en naturlig del af udviklingen af ​​datalogi lige siden begyndelsen af ​​branchen.

Oracle anklager Google for ulovligt at kopiere Java API, herunder en liste over navngivne kommandoer knyttet til grammatiske strukturer. Android-operativsystemet er specifikt kompatibelt med Java API for at gøre det nemmere for Java-programmører at overføre software og viden til den nye platform. For at gøre dette kopierede Android nøjagtigt de tilsvarende Java API-kommandoer og grammatiske strukturer. argument Oracle er, at en sådan "genimplementering" af Java API kan sammenlignes med at kopiere en forfatters værk, såsom den litterære roman "Harry Potter" (denne et rigtigt eksempel givet af Oracle-advokater), og Google overtræder Oracles ophavsret til Java API-kommandonavne og -strukturer.

Men Java API'er er ikke de eneste API'er, og Android er ikke den eneste genimplementering. I dagens IT-industri er API'er allestedsnærværende, og genindførelse er grundlæggende for at opretholde konkurrencen for at forhindre store virksomheder i at monopolisere tænker Charles Duane er direktør for teknologi og innovationspolitik ved R Street Institute.

Duane giver eksemplet med den populære Amazon S3-lagringsplatform. For at gøre det muligt at skrive og hente filer fra S3 har Amazon udviklet omfattende, detaljeret API at interagere med tjenesten. For eksempel for at få en liste over gemte filer (Listeobjekter) sender vi en GET-kommando, der angiver værts- og typeparametrene kodningstype, fortsættelse-token и x-amz-dato. For at arbejde med Amazon S3 skal softwaren bruge disse og mange andre specifikke parameternavne nøjagtigt.

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 klart førende på markedet for cloudtjenester, og dets konkurrenter tilbyder re-implementeringer af S3 API, mens de skal efterligne kommandonavne, parametertags, typepræfikser x-amz, grammatisk struktur og generel organisation af S3 API. Med andre ord, alt hvad Oracle hævder er ophavsretligt beskyttet.

Blandt de virksomheder, der tilbyder en kopi af Amazon S3 API er der er også selve Oracle. For kompatibilitet kopierer Amazon S3 Compatibility API adskillige elementer af Amazon API, ned til x-amz tags.

Oracle hævder, at lovligheden af ​​dets handlinger er baseret på open source Apache 2.0-licensen, som tillader gratis kopiering og ændring af kode. For eksempel, Amazon SDK til Java leveres også med en Apache 2.0-licens.

Men spørgsmålet er, om intellektuel ejendomsret overhovedet gælder for ting som API'er. Det skal Højesteret fastslå.

Hvem opfandt API'en?

Udtrykket og konceptet for et "subrutinebibliotek" dukkede først op i bogen Planning and Coding Problems for an Electronic Computing Instrument - Part II, Volume III (Princeton University Institute of Advanced Study, 1948) af Herman Goldstein og John von Neumann. kopi på archive.org. Indhold i tredje bind:

Dette er den første beskrivelse af en programmeringsmetodologi til computere, der gemmer programmer i hukommelsen (tidligere eksisterede dette ikke). Det blev bredt distribueret til universiteter, som på det tidspunkt forsøgte at skabe deres egne computere. Og vigtigst af alt, bogen indeholder en central idé: de fleste programmer vil bruge almindelige operationer, og biblioteker med rutiner vil reducere mængden af ​​ny kode og fejl. Denne idé blev yderligere forfinet af Maurice Wilkes og ført ud i livet i EDSAC-maskinen, som han modtog 1967 Turing Award for.

EDSAC-underrutinebiblioteket er til venstre

Det næste skridt var at skabe funktioner af højere orden og fuldgyldige softwaregrænseflader, som Maurice Wilkes og David Wheeler gjorde i Forberedelse af programmer til den elektroniske digitale computer (1951).

Selve udtrykket Applikationsprogramgrænseflade (API) dukkede op et sted i slutningen af ​​60'erne.

Forfatter til præsentationen "En kort subjektiv historie om API" Joshua Block giver flere eksempler på programmeringsgrænseflader, instruktionssæt og subrutinebiblioteker: hvordan de blev oprettet og efterfølgende brugt. Tanken er, at genbrug er pointen med en API. Det er, hvad de blev skabt til i første omgang. Og udviklere har altid haft mulighed for at kopiere og lave andres API'er:

API
Skaberen
År
Genimplementering
Å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-systemopkald
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 kommandosæt
Hayes Micro
1982
Ankerautomatisering
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
microsoft
1992
Samba projekt
1993

Win32
microsoft
1993
Vin projekt
1996

Java 2 klasse biblioteker
Sol
1998
Google/Android
2008

Web API Delicious
Lækker
2003
opslagstavle
2009

Kilde: "En kort subjektiv historie om API"

Kopiering og genbrug af API'er (biblioteker, instruktionssæt) er ikke kun korrekt, men denne programmeringsmetode anbefales direkte i datalogiens kanoner. Selv før de kopierede S3-programmeringsgrænseflader, gjorde Oracle selv dette mange gange. Desuden var Oracles forretning oprindeligt bygget på implementeringen af ​​SQL-programmeringssproget udviklet af IBM. Oracles første flagskibsprodukt var et DBMS, stort set kopieret fra IBM System R. I dette tilfælde taler vi om re-implementering af SQL som en "standard API" for en DBMS.

At pålægge intellektuelle ejendomsrettigheder på API'er kan skabe et juridisk minefelt, der påvirker alle. API'er implementerer og andre cloud-tjenester. Mange tekniske standarder, såsom Wi-Fi og internetprotokoller, inkluderer API'er. Programmeringsgrænseflader genimplementeres nødvendigvis i en eller anden form på enhver computer og server på internettet. Oracles ophavsretsteori kan gøre næsten alt, hvad du gør med din computer, ulovligt.

For at undgå disse vidtrækkende konsekvenser har Oracle og appeldomstolen, der stadfæstede deres argumenter, forsøgt at begrænse ophavsretskrænkelse til visse API-genimplementeringer, der er "inkompatible" med originalen. Men også delvise re-implementeringer er almindelige. Selv i sin kopi af S3 API bemærker Oracle adskillige "forskelle" og inkompatibiliteter med de originale Amazon API'er.

Den største fare ved Oracles retssag er, at det kan forhindre mindre teknologivirksomheder i at skabe versioner af systemer, der er kompatible med dominerende platforme som S3. Uden en sådan kompatibilitet vil programmører effektivt blive låst ude af denne virksomheds tilbud.

Brancherepræsentanter og udviklere kan kun håbe, at fornuften vil sejre her, og dommere kender det grundlæggende i programmering.

Kilde: www.habr.com