Юрысты Oracle параўноўваюць рэімплементацыю Java API у Android з капіяваннем зместу "Гары Потэра", PDF

У пачатку гэтага года Вярхоўны суд ЗША разгледзіць важную справу Oracle супраць Google, якое вызначыць прававы статус API у адпаведнасці з законам аб інтэлектуальнай уласнасці. Калі суд устане на бок Oracle у яе шматмільярдным пазове, гэта можа задушыць канкурэнцыю і замацаваць дамінаванне тэхналагічных гігантаў, магчыма, у тым ліку саму Google.

У той жа час бізнес Oracle першапачаткова пабудаваны на імплементацыі мовы праграмавання SQL, распрацаванага IBM, ды і зараз кампанія прапануе хмарны сэрвіс з API з Amazon S3, і гэта зусім нармальна. Рэімплементацыя API была натуральнай часткай развіцця інфарматыкі з самага зараджэння галіны.

Oracle абвінавачвае Google у незаконным капіяванні Java API, у тым ліку спісу найменных каманд, прывязаных да граматычных структур. Аперацыйная сістэма Android спецыяльна сумяшчальная з Java API, каб Java-праграмістам было прасцей перанесці праграмнае забеспячэнне і веды на новую платформу. Для гэтага Android сапраўды скапіявала адпаведныя каманды Java API і граматычныя структуры. аргумент Oracle заключаецца ў тым, што такую ​​"рэімплементацыю" Java API можна параўнаць з капіраваннем аўтарскага твора, такога як літаратурны раман "Гары Потэр" (гэта рэальны прыклад, які прывялі юрысты Oracle), А Google парушае капірайт Oracle на імёны каманд і структуры Java API.

Але Java API – не адзіныя API, а Android – не адзіная рэімплементацыя. У сучаснай IT-індустрыі API сустракаюцца паўсюдна, а паўторнае ўкараненне фундаментальна важна для захавання канкурэнцыі, каб прадухіліць манаполію буйных фірм, лічыць Чарльз Дзюан, дырэктар па тэхнічнай і інавацыйнай палітыцы ў R Street Institute.

Дзюан прыводзіць прыклад папулярнай платформы захоўвання дадзеных Amazon S3. Каб дазволіць запіс і выманне файлаў з S3, Amazon распрацавала ўсебаковы, падрабязны API для ўзаемадзеяння з сэрвісам. Напрыклад, для атрымання спісу захаваных файлаў (ListObjects) мы адпраўляем каманду GET з указаннем хаста і параметраў тыпу encoding-type, continuation-token и x-amz-date. Для працы з Amazon S3 праграмнае забеспячэнне павінна ў дакладнасці выкарыстоўваць гэтыя і многія іншыя спецыфічныя назвы параметраў.

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 з'яўляецца відавочным лідэрам на рынку хмарных сэрвісаў, а яе канкурэнты прапануюць рэімплементацыю API S3, пры гэтым ім даводзіцца імітаваць назвы каманд, тэгі параметраў, прэфіксы тыпу x-amz, граматычную структуру і агульную арганізацыю API S3. Іншымі словамі, усё тое, што, па сцвярджэнні Oracle, абаронена аўтарскім правам.

Сярод кампаній, якія прапануюць копію API Amazon S3, ёсць і сама Oracle. Для сумяшчальнасці Amazon S3 Compatibility API капіюе шматлікія элементы API Amazon, аж да тэгаў x-amz.

Oracle запэўнівае, што законнасць яе дзеянняў заснавана на апенсорснай ліцэнзіі Apache 2.0, якая дазваляе вольнае капіяванне і змена кода. Напрыклад, Amazon SDK для Java таксама пастаўляецца з ліцэнзіяй Apache 2.0.

Але пытанне ў тым, ці дастасавальна наогул заканадаўства аб інтэлектуальнай уласнасці да такіх аб'ектаў, як API. Менавіта гэта павінен устанавіць Вярхоўны суд.

Хто вынайшаў API?

Тэрмін і паняцце «бібліятэкі падпраграм» (subroutine library) упершыню з'явілася ў кнізе Хермана Голдстайна і Джона фон Нэймана «Планаванне і кадаваньне праблем для электроннай вылічальнай прылады» — частка II, том III (Інстытут прасунутых даследаванняў Прынстанскага ўніверсітэта, 1948), копія на archive.org. Змест трэцяга тома:

Гэта першае апісанне метадалогіі праграмавання для кампутараў з захаваннем праграм у памяці (раней такой не існавала). Яна шырока разышлася па ўніверсітэтах, якія ў той час спрабавалі стварыць уласныя вылічальныя машыны. І галоўнае, кніга змяшчае ключавую ідэю: большасць праграм будзе выкарыстоўваць агульныя аперацыі, а бібліятэкі з падпраграмамі паменшаць колькасць новага кода і памылак. Гэтую ідэю дапрацаваў Морыс Уілкс і ўжыў на практыцы ў машыне EDSAC, завошта атрымаў прэмію Цьюрынга 1967 гады.

Бібліятэка падпраграм EDSAC стаіць злева

Наступным крокам было стварэнне функцый больш высокага парадку і паўнавартасных праграмных інтэрфейсаў, што зрабілі Морыс Уілкс і Дэвід Уілер у кнізе "Падрыхтоўка праграм для электроннага лічбавага кампутара" (1951).

Сам тэрмін Інтэрфейс прыкладной праграмы (API) з'явіўся недзе ў канцы 60-х.

Аўтар прэзентацыі «Кароткая Суб'ектыўная гісторыя API» Джошуа Блок прыводзіць некалькі прыкладаў праграмных інтэрфейсаў, набораў інструкцый і бібліятэк падпраграм: як яны ствараліся і выкарыстоўваліся пасля. Ідэя ў тым, што паўторнае выкарыстанне - і ёсць сэнс API. Менавіта для гэтага яны ствараліся найперш. І ў распрацоўнікаў заўсёды была магчымасць капіяваць і перарабляць чужыя API:

API
Стваральнік
Год
Паўторная рэалізацыя
Год

Бібліятэка FORTRAN
IBM
1958
Унівак
1961

IBM S/360 ISA
IBM
1964
Amdahl Corp.
1970

Стандартная бібліятэка З
AT&T / Bell Labs
1976
Mark Williams Co.
1980

Сістэмныя выклікі Unix
AT&T / Bell Labs
1976
Mark Williams Co.
1980

VT100 Esc Seqs
Сьнежня
1978
Хіткіт
1980

IBM PC BIOS
IBM
1981
Phoenix Technologies
1984

MS-DOS CLI
Microsoft
1981
FreeDOS Project
1998

Набор каманд Hayes AT
Hayes Micro
1982
Anchor Automation
1985

PostScript
Adobe
1985
GNU/GhostScript
1988

SMB
Microsoft
1992
Samba Project
1993

Win32
Microsoft
1993
Wine Project
1996

Бібліятэкі класаў Java 2
Сонца
1998
Google/Android
2008

Вэб-API Delicious
вельмі смачны
2003
Pinboard
2009

Крыніца: «Кароткая Суб'ектыўная гісторыя API»

Капіяваць і паўторна выкарыстоўваць API (бібліятэкі, наборы інструкцый) - гэта не толькі правільна, але такая метадалогія праграмавання прама рэкамендуецца ў канонах інфарматыкі. Яшчэ да капіявання праграмных інтэрфейсаў S3 сама кампанія Oracle неаднаразова рабіла гэта. Больш за тое, бізнес Oracle першапачаткова пабудаваны на імплементацыі мовы праграмавання SQL, распрацаванага IBM. Першым флагманскім прадуктам Oracle стала СКБД, шмат у чым скапіяваная з IBM System R. У дадзеным выпадку гаворка ідзе аб рэімплементацыі SQL як "стандартнага API" для СКБД.

Накладанне інтэлектуальных правоў на інтэрфейсы API можа стварыць юрыдычнае міннае поле, ад якога пацерпяць усе. Інтэрфейсы API рэалізуюць і іншыя хмарныя сэрвісы. Многія тэхнічныя стандарты, такія як Wi-Fi і пратаколы інтэрнэту – уключаюць API. Праграмныя інтэрфейсы абавязкова паўторна рэалізаваны ў нейкім выглядзе на кожным кампутары і серверы ў інтэрнэце. Тэорыя капірайту Oracle можа ператварыць амаль усё, што вы робіце з кампутарам, у незаконнае дзеянне.

Каб пазбегнуць гэтых далёка ідучых наступстваў, Oracle і апеляцыйны суд, які падтрымаў яе аргументы, паспрабавалі абмежаваць парушэнне капірайту вось некаторымі рэімплементацыямі API, якія "несумяшчальныя" з арыгіналам. Але частковыя рэімплементацыі таксама з'яўляюцца звычайнай справай. Нават у сваёй копіі API S3 кампаніі Oracle адзначае шматлікія "адрозненні" і несумяшчальнасці з арыгінальнымі API Amazon.

Галоўная небяспека пазову Oracle складаецца ў тым, што ён можа перашкодзіць невялікім тэхналагічным кампаніям ствараць версіі сістэм, сумяшчальныя з дамінантнымі платформамі, такімі як S3. Без такой сумяшчальнасці праграмісты будуць фактычна заблакаваны ў прапановах гэтай фірмы.

Прадстаўнікам індустрыі і распрацоўшчыкам застаецца спадзявацца, што розум тут пераможа, а суддзі ведаюць асновы праграмавання.

Крыніца: habr.com