Czy API podlega ochronie praw? Oracle chce tego dowieść przed Sądem Najwyższym
Dowcip o tym, że firma Oracle nie ma żadnych programistów, a jedynie armię prawników wydaje się już zużyty i nudny, ale chyba jeszcze nigdy nie był tak aktualny, jak ostatnio. W tym tygodniu bowiem Oracle zmierzył się w Google w Sądzie Najwyższym Stanów Zjednoczonych, usiłując doprowadzić do konkluzji potyczkę prawną trwającą już od dekady. Chodzi oczywiście o Javę. Jedną z wielu plag, jakie ściągnęła swoim istnieniem na ludzkość jest niekończąca się dyskusja o tym, czy ochrona prawna implementacji rozciąga się na API.
Branży IT nieobce jest podejście embrace-extend-extinguish (3E), polegające na wdrożeniu cudzego standardu, dodaniu rzeczy wykraczających poza ów standard, a następnie wygaszeniu konkurencji stosującej się do dokumentacji. Klienci są w takich sytuacjach niejako zmuszeni wybierać produkt z rzekomą obsługą standardu, w praktyce obsługujący nieudokumentowaną wersję "z plusem". Jeżeli podczas przetwarzania danych, do procesu przemysłowego/informacyjnego dorzuci się jakikolwiek komponent "z plusem", tworzy to kiełkującą konieczność stosowania kompatybilnych rozwiązań. Gdy dzieje się to na wystarczająco dużą skalę, standard przestaje mieć znaczenie.
Brutalne przejęcie standardu
W zabiegu tym przodował niegdyś, rzecz jasna, Microsoft. Głównym przykładem jest Internet Explorer i jego implementacja DHTML oraz "aktywnych skryptów", owocująca stronami wyglądającymi poprawnie tylko w IE, a w przypadku składników ActiveX – działające tylko na Windows. Administratorzy być może pamiętają, że podobny numer próbowano wywinąć z implementacją metody Kerberos w Active Directory.
Rzeczy, o których mowa to udokumentowane "papierowe" standardy, za którymi nie stoi żaden konkretny produkt. Nie ma referencyjnej przeglądarki internetowej, nie istnieją referencyjne, opatentowane implementacje mechanizmów uwierzytelniania. Co jednak, gdy podejście "3E" zastosuje się względem czegoś, co jest produktem i główną implementacją standardu jest po prostu oprogramowanie jakiejś firmy? Tak jest z Javą.
Reimplementacja? Clean-room? API?
Gdy Microsoft próbował zawłaszczyć Javę, dostał po łapach od wymiaru sprawiedliwości, ponieważ uznano, że są to zapędy mające na celu ugruntowanie monopolu na rynku komputerów osobistych. Dziesięć lat później, własną implementację Javy zastosował Google, robiąc to głównie na potrzeby systemu Android. System ten przebojem zaczął zdobywać rynek, a implementacja Google rozszerzała znacząco OpenJDK, odbiegając także w niektórych miejscach od standardu. Google-Java była więc innowacyjna i lepsza od OpenJDK, co wzbudziło niepokój Oracle.
Oracle ma prawa do Javy wskutek kupienia firmy Sun Microsystems. Rości je sobie w dość ortodoksyjny sposób: każda implementacja niebędąca intake'iem lub linkiem do OpenJDK, w szczególności taka dostarczająca składniki nieobecne w OpenJDK, jest naruszeniem praw do Javy. Oracle uważa, że ochronie podlega nie tylko kod maszyny wirtualnej i SDK, ale także referencyjne API opisujące działanie komponentów możliwych do wołania w Javie. Tylko komponenty pobłogosławione przez Oracle i łaskawie dostępne w OpenJDK mogą być używane w oprogramowaniu korzystającym z Javy.
Jest to jakiś sposób na ochronę czystości referencyjnej implementacji, ale prawna obrona takiego podejścia otwiera wrota piekieł. Na tej zasadzie każde API można rozpatrywać w kategorii własności intelektualnej i jeżeli nie istnieje otwarte, referencyjne API tego samego autorstwa, to stworzenie własnego rozwiązania jest niedopuszczalne.
Bez drogi ucieczki
Google usiłuje się bronić. Android 7.0 używa właśnie OpenJDK, a przynajmniej w sporym zakresie. Ale świat nie przeszedł magicznie jednego dnia na Nougata i spory udział światowym obrotów dalej operuje na starszych platformach, które budzą sprzeciw Oracle. Firma ta zresztą zrobiła z Amazon S3 to samo, co Google z ich Javą, ale ponieważ nikt ich nie pozwał, najwyraźniej wszystko jest w porządku.
Afera jest na tyle poważna, że nie tylko trwa z 10 lat, ale także przechodzi do coraz wyższych instancji. Sąd Najwyższy nie jest gronem ekspertów ds. platformowych API, więc decyzje sędziów bywają nietypowe. Ponieważ prace SN dotyczą prawa, a nie faktu, w decyzji dotyczącej API nie zapadnie konkluzja czy Google zrobiło coś złego, a powstanie jasna interpretacja tego, gdzie kończy się ochrona praw. Dopiero w konsekwencji tej decyzji, Google może oberwać. Niestety, na tę decyzje będzie można się powoływać w przyszłości, gdy ktoś następny, po Oracle, zechce zażarcie bronić swojego API.
Mniej oczywiste niż myślimy
Mimo, że sprawa wydaje się oczywista większości fachowców, skład sędziowski obecnego SCOTUS (Supreme Court of the United States) nie musi jednoznacznie poprzeć obecnego konsensusu. Mianowany przez prezydenta Donalda Trumpa sędzia Brett Kavanaugh jest zdania, że API nie stanowi odstępstwa od zasad ochrony praw autorskich do oprogramowania, ponieważ nie jest normą, w stylu systemu miar i wag.
Na werdykt SCOTUS przyjdzie nam nieco poczekać, ale może od niego zależeć kształt przyszłych starań standaryzacyjnych w branży IT.
