Prawnicy Oracle porównują reimplementację Java API w Androidzie z kopiowaniem zawartości „Harry'ego Pottera”, pdf

Sąd Najwyższy Stanów Zjednoczonych rozpatrzy ważną sprawę na początku tego roku. Oracle kontra Google, które określi status prawny API w świetle prawa własności intelektualnej. Jeśli sąd stanie po stronie Oracle w wielomiliardowym pozwie, może to zdusić konkurencję i umocnić dominację gigantów technologicznych, w tym prawdopodobnie samego Google.

Jednocześnie biznes Oracle początkowo opierał się na wdrażaniu języka programowania SQL opracowanego przez IBM, a nawet teraz firma oferuje usługę w chmurze z API z Amazon S3, i jest to całkowicie normalne. Reimplementacje API są naturalną częścią rozwoju informatyki od początków istnienia branży.

Oracle oskarża Google o nielegalne kopiowanie API Java, w tym listy nazwanych poleceń powiązanych ze strukturami gramatycznymi. System operacyjny Android jest szczególnie kompatybilny z API Java, aby ułatwić programistom Java przeniesienie oprogramowania i wiedzy na nową platformę. Aby to zrobić, Android dokładnie skopiował odpowiednie polecenia Java API i struktury gramatyczne. argument Oracle polega na tym, że taką „ponowną implementację” API Java można porównać do kopiowania dzieła autora, np. powieści literackiej „Harry Potter” (to prawdziwy przykład podany przez prawników Oracle) i Google narusza prawa autorskie Oracle do nazw i struktur poleceń Java API.

Ale interfejsy API Java nie są jedynymi interfejsami API, a Android nie jest jedyną reimplementacją. W dzisiejszej branży IT interfejsy API są wszechobecne, a ich ponowne wprowadzenie ma fundamentalne znaczenie dla utrzymania konkurencji i zapobiegania monopolizacji dużych firm myśli Charles Duane jest dyrektorem ds. technologii i polityki innowacji w R Street Institute.

Duane podaje przykład popularnej platformy pamięci masowej Amazon S3. Aby umożliwić zapisywanie i pobieranie plików z S3, Amazon opracował kompleksowe, szczegółowe API do interakcji z usługą. Na przykład, aby uzyskać listę zapisanych plików (ListaObiektów) wysyłamy komendę GET podając parametry hosta i typu typ kodowania, token kontynuacji и x-amz-data. Aby móc współpracować z Amazon S3, oprogramowanie musi dokładnie używać tych i wielu innych specyficznych nazw parametrów.

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 jest zdecydowanym liderem na rynku usług chmurowych, a jego konkurenci oferują reimplementacje API S3, jednocześnie muszą imitować nazwy poleceń, znaczniki parametrów, przedrostki typów x-amz, struktura gramatyczna i ogólna organizacja API S3. Innymi słowy, wszystko, co twierdzi Oracle, jest chronione prawem autorskim.

Wśród firm oferujących kopię API Amazon S3 znajdują się m.in jest też sama Oracle. Aby zapewnić kompatybilność, interfejs API zgodności Amazon S3 kopiuje wiele elementów interfejsu API Amazon, aż do znaczników x-amz.

Oracle twierdzi, że legalność swoich działań opiera na licencji open source Apache 2.0, która umożliwia swobodne kopiowanie i modyfikowanie kodu. Na przykład, SDK Amazona dla Javy jest również dostarczany z licencją Apache 2.0.

Pytanie jednak brzmi, czy prawo własności intelektualnej w ogóle ma zastosowanie do takich rzeczy jak API. To musi ustalić Sąd Najwyższy.

Kto wynalazł API?

Termin i koncepcja „biblioteki podprogramów” po raz pierwszy pojawiły się w książce Planning and Coding Problems for an Electronic Computing Instrument - Part II, Volume III (Instytut Studiów Zaawansowanych Uniwersytetu Princeton, 1948) autorstwa Hermana Goldsteina i Johna von Neumanna. skopiuj na Archive.org. Spis treści trzeciego tomu:

Jest to pierwszy opis metodologii programowania komputerów przechowujących programy w pamięci (wcześniej taka nie istniała). Został szeroko rozpowszechniony wśród uniwersytetów, które w tamtym czasie próbowały stworzyć własne komputery. A co najważniejsze, książka zawiera kluczową myśl: większość programów będzie używać typowych operacji, a biblioteki z procedurami zmniejszą ilość nowego kodu i błędów. Pomysł ten został udoskonalony przez Maurice'a Wilkesa i zastosowany w praktyce w maszynie EDSAC, za którą w 1967 roku otrzymał nagrodę Turinga.

Biblioteka podprogramów EDSAC znajduje się po lewej stronie

Następnym krokiem było stworzenie funkcji wyższego rzędu i pełnoprawnych interfejsów oprogramowania, jak zrobili to Maurice Wilkes i David Wheeler w książce Preparing Programs for the Electronic Digital Computer (1951).

Sam termin Interfejs programu aplikacji (API) pojawiło się gdzieś pod koniec lat 60-tych.

Autor prezentacji „Krótka subiektywna historia API” Joshua Block podaje kilka przykładów interfejsów programistycznych, zestawów instrukcji i bibliotek podprogramów: jak zostały utworzone, a następnie wykorzystane. Pomysł jest taki, że celem API jest ponowne użycie. Po to przede wszystkim zostały stworzone. Programiści zawsze mieli możliwość kopiowania i przerabiania interfejsów API innych osób:

API
Twórca
Rok
Ponowne wdrożenie
Rok

biblioteka FORTRAN
IBM
1958
Univac
1961

IBM S/360 ISA
IBM
1964
Firma Amdahl.
1970

Standardowa biblioteka C
Laboratoria AT&T/Bell
1976
Marka Williamsa Co.
1980

Wywołania systemowe Uniksa
Laboratoria AT&T/Bell
1976
Marka Williamsa Co.
1980

VT100 Esc Sekw
Grudzień
1978
Zestaw Heath
1980

BIOS komputera IBM
IBM
1981
Phoenix Technologies
1984

Interfejs wiersza polecenia MS-DOS
Microsoft
1981
Projekt FreeDOS
1998

Zestaw poleceń Hayes AT
Hayes Mikro
1982
Automatyka kotwiczna
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Projekt Samby
1993

Win32
Microsoft
1993
Projekt wina
1996

Biblioteki klas Java 2
Niedz
1998
Google/Androida
2008

Internetowe API Pyszne
Pyszne
2003
Tablica korkowa
2009

Źródło: „Krótka subiektywna historia API”

Kopiowanie i ponowne wykorzystywanie API (biblioteki, zestawy instrukcji) jest nie tylko poprawne, ale taka metodologia programowania jest bezpośrednio zalecana w kanonach informatyki. Jeszcze przed skopiowaniem interfejsów programistycznych S3 sama Oracle robiła to wielokrotnie. Co więcej, działalność Oracle początkowo opierała się na wdrażaniu języka programowania SQL opracowanego przez IBM. Pierwszym flagowym produktem Oracle był system DBMS, w dużej mierze skopiowany z IBM System R. W tym przypadku mówimy o ponownej implementacji języka SQL jako „standardowego interfejsu API” dla systemu DBMS.

Narzucanie praw własności intelektualnej do interfejsów API może stworzyć prawne pole minowe, które będzie miało wpływ na wszystkich. Interfejsy API implementują i inne usługi w chmurze. Wiele standardów technicznych, takich jak protokoły Wi-Fi i internetowe, zawiera interfejsy API. Interfejsy programistyczne muszą być w jakiejś formie ponownie zaimplementowane na każdym komputerze i serwerze w Internecie. Teoria praw autorskich Oracle może sprawić, że prawie wszystko, co zrobisz na komputerze, stanie się nielegalne.

Aby uniknąć tych daleko idących konsekwencji, Oracle i sąd apelacyjny, który podtrzymał jej argumenty, próbowały ograniczyć naruszenia praw autorskich do niektórych reimplementacji API, które są „niekompatybilne” z oryginałem. Ale także częściowe reimplementacje są powszechne. Nawet w swojej kopii API S3 Oracle zauważa liczne „różnice” i niezgodności z oryginalnymi API Amazon.

Głównym niebezpieczeństwem pozwu Oracle jest to, że może on uniemożliwić mniejszym firmom technologicznym tworzenie wersji systemów kompatybilnych z dominującymi platformami, takimi jak S3. Bez takiej kompatybilności programiści zostaną skutecznie odcięci od oferty tej firmy.

Przedstawiciele branży i deweloperzy mogą mieć tylko nadzieję, że rozsądek zwycięży i ​​tutaj sędziowie znają podstawy programowania.

Źródło: www.habr.com