Oracle proti Googlu se že desetletje vijuga po sodiščih. Verjetno ste že slišali, da bi odmevni pravni primer lahko spremenil programsko inženirstvo, kot ga poznamo - toda ker se zdi, da se nikoli nič ne zgodi, je odpustljivo, če ste si navadili uglasiti novice.
Morda je čas, da se spet vključite. Zadnjo ponovitev primera bo ameriško vrhovno sodišče zaslišalo v sezoni 2020–2021, ki se je začela ta teden (potem ko je bila zaradi pomislekov zaradi koronavirusa zavrnjena). Odločitve najvišjega sodišča v deželi ni mogoče razveljaviti in verjetno ne bo razveljavljena, zato bi se v nasprotju s prejšnjimi odločitvami na okrožnem in okrožnem sodišču držala za vedno. Medtem ko o zadevi govorijo v ZDA, bi odločitev vplivala na celotno svetovno tehnološko industrijo.
[Tudi o: Ali bi morali biti API-ji zaščiteni z avtorskimi pravicami? 7 razlogov za in 7 proti]
Če niste prebrali nobenega od 10-letnih člankov, je tu osvežitev. Oracle v svoji tožbi trdi, da Googlova uporaba API-jev Java v svojem operacijskem sistemu Android pomeni kršitev avtorskih pravic, ker Google nikoli ni prejel licence za Java. Kot tak, Oracle proti Googlu se ukvarja z vprašanjem, ali so API-ji zaščiteni z avtorskimi pravicami, in če je tako, ali njihova uporaba v programskih aplikacijah po zakonu pomeni "pošteno uporabo".
To je ključno vprašanje za razvijalce programske opreme in celotno industrijo programske opreme. Ponovna implementacija API-jev je kruh in maslo programskega inženirstva, in če Oracle zmaga, bo to drastično spremenilo način razvijalcev. Toda kako natančno bi bila videti ta sprememba - in kaj bi pomenila za vaše delo v industriji programske opreme? Tu je kratek predogled možnega vpliva.
Kaj bi pomenili API-ji za pisanje besedil
Večina najboljših praks sodobnega razvoja programske opreme temelji na ponovni implementaciji API-jev. V svetu, kjer SCOTUS vlada v korist Oracle, bi morali razvijalci spremeniti način izdelave nove programske opreme. A spremembe se pri tem ne bi ustavile. Vpliv odločitve pro-Oracle bi se razširil navzven po celotni industriji programske opreme.
Več podjetij bo poskušalo monetizirati svoje API-je
Eden od takojšnjih učinkov odločitve v korist Oracla bi bil omogočiti podjetjem, da monetizirajo svoje API-je. Verjetno bi to storili z zaračunavanjem licenčnin za API-je, kot to že počnejo številna podjetja za programsko opremo SaaS.
Na prvi pogled se zdi, da je licenciranje privlačen tok prihodkov, zlasti za podjetja z izjemno priljubljenimi API-ji (npr. Amazonovi API-ji S3). Vendar je malo verjetno, da bi veliko podjetij plačalo licence za API. Medtem ko API pomaga združljivosti, je resnično pomembna koda, ki jo uporabljate za dejansko izvedbo stvari. To je "skrivna omaka" vašega podjetja in način, kako se razlikuje od konkurentov. V tej luči plačevanje API-jev ne bo dodalo konkurenčne prednosti in se dolgoročno verjetno ne bo splačalo.
Namesto tega bo večina podjetij verjetno prilagodila svojo kodo ravno toliko, da bodo njihovi API-ji "drugačni" po zakonu o avtorskih pravicah - čeprav bo ta koda v bistvu storila enako kot prej. S tem bi sicer lahko prihranili denar podjetjem s programsko opremo, dolgoročno pa bi povzročili preglavice zaradi združljivosti.
Možno je tudi, da bi se nekatera podjetja s priljubljenimi API-ji odločila, da bodo odprtokodna. Prednost, da je vaš lastniški protokol industrijski standard, ima veliko prednosti, tudi če s tem ne zaslužite neposredno. Vendar pa so podjetja, ki jih skrbijo sodni spori ali prihodnje pristojbine za licenciranje, previdna pri uporabi katerega koli API-ja brez sprememb.
Programska oprema bo manj navzkrižno združljiva
Težje je, če različni deli programske opreme delujejo skupaj, če vsi delujejo na edinstveni lastniški kodi namesto na enem univerzalnem standardu. Isto načelo velja tudi zunaj programske opreme - zato je v stene vseh nameščena običajna električna vtičnica, namesto drugačne vtičnice, odvisno od vašega podjetja.
V svetu, kjer so API-ji zaščiteni z avtorskimi pravicami, se aplikacije ne bi igrale skoraj tako dobro. Prehod z enega ponudnika SaaS na drugega bi pomenil prilagoditev vaše kode tako, da se bo ujemala z njenimi edinstvenimi API-ji - dolgočasen, delovno intenziven postopek. Ta premik bi tudi vaše spretnosti razvijalca naredil manj prenosne. Namesto da bi uporabili svoje obstoječe znanje o industrijskih standardih, bi se morali vsakič, ko zamenjate delovno mesto, naučiti novega nabora API-jev.
Tekmovanje z uveljavljenimi podjetji za programsko opremo bo težje
Z avtorskimi pravicami API-ji bi podjetja, ki jih naredijo, spremenili v vratarje, ki se sami odločijo, kdo bo uporabil njihove najbolj dragocene API-je. Tehnološka industrija je zelo konkurenčna in nekatera podjetja lahko drugim onemogočijo dostop samo zato, da jim otežijo življenje. Podjetja bi lahko API-ju zavrnila dostop do vsakogar, s katerim se politično ali drugače ne strinjajo, in tako odprla nov sklop vprašanj.
Poleg tega bi pomanjkanje odprtokodnih API-jev precej otežilo odstranitev obstoječih operaterjev. Če podjetje zdaj za svojim API-jem ne ponuja odličnih storitev, lahko nadgrajenec z lahkoto vstopi na trg z boljšo storitvijo in z istim API-jem omogoči združljivost te storitve z obstoječo programsko opremo, kar zagotavlja preprosto uporabo. Z avtorskimi pravicami API to gre skozi okno. Podjetja bi morala sprejeti velike infrastrukturne spremembe, da bi sprejela novo rešitev.
Namig prihodnosti
Večina nas v tehnološkem svetu navija za Googlovo zmago, ki bi ohranila status quo razvoja programske opreme. Na srečo stvari izgledajo dokaj upajoče. Maja je SCOTUS od družbe Oracle in Googla naročil dodatna poročila, v katerih so podrobno opisani standardi pregleda, ki se uporabljajo za določitev poštene uporabe v prvotnem postopku porote okrožnega sodišča. (Okrožno sodišče je odločilo v korist Googla, vendar je bilo kasneje pritožba na zveznem okrožnem sodišču razveljavljeno.)
Zahteva sodnikov je lahko znak, da SCOTUS preučuje stališče, ki ga je med drugim predstavil pravni center Software Freedom Center (SFLC), ki trdi, da je pritožbeno sodišče, ki je razveljavilo sodbo porote o pošteni uporabi, protiustavno po sedmem Predlog spremembe. Sledenje tej argumentaciji bi SCOTUS-u omogočilo, da primer reši na podlagi razmeroma preprostega postopkovnega vprašanja. Sodišče bi se izognilo poglabljanju v tehnične zapletenosti razvoja programske opreme - in ne bi ustvarilo nobenega precedensa, kako bi bilo treba API-je razlagati glede na zakonodajo o avtorskih pravicah.
Kljub tem namigom pa izida ne bomo zares vedeli, dokler SCOTUS o primeru ne bo odločil prihodnje leto. Pametno bi bilo, da se vsa podjetja, ki se ukvarjajo s programsko opremo, pripravijo na možnost, da bo Oracle zmagal in da bodo API-ji zaščiteni z avtorskimi pravicami. To ne pomeni, da morate zdaj začeti prepisovati obstoječe API-je svojih aplikacij - vendar bi bilo smiselno pripraviti načrt za to hitro in učinkovito, če bo to potrebno. V tem času lahko le čakamo.
Hannu Valtonen je soustanovitelj in glavni produktni direktor podjetja Aiven, ponudnika oblačnih podatkovnih platform, ki upravlja upravljane odprtokodne baze podatkov, pretakanje dogodkov, predpomnilnik, iskanje in grafične rešitve za stranke po vsem svetu.
—
Forum New Tech ponuja prizorišče za raziskovanje in razpravo o nastajajoči podjetniški tehnologiji v globini in širini brez primere. Izbor je subjektiven in temelji na našem izboru tehnologij, za katere menimo, da so pomembne in najbolj zanimajo bralce. ne sprejema tržnih zavarovanj za objavo in si pridržuje pravico do urejanja celotne prispevane vsebine. Vsa vprašanja pošljite na [email protected].
