Oracle vs Google: API, prawo autorskie i spór o 9 miliardów dolarów

Sąd Najwyższy USA w sprawie Oracle v. Google rozstrzygnął wieloletni spór dotyczący prawnoautorskiej ochrony interfejsów programowania aplikacji (API). Spór, w którym wysokość roszczeń sięgała 9 miliardów dolarów, dotyczył wykorzystania przez Google fragmentów API Java w systemie Android. Wyrok z 5 kwietnia 2021 r. przesądził, że wykorzystanie nawet obszernych fragmentów cudzego kodu może w pewnych okolicznościach stanowić fair use (dozwolony użytek). Rozstrzygnięcie ma fundamentalne znaczenie dla określenia zakresu ochrony prawnoautorskiej w odniesieniu do rozwiązań, które stały się standardami rynkowymi w branży IT.

O co poszło?

W 2005 r. spółka Google przejęła startup Android, Inc. planując wejście na rynek urządzeń mobilnych. Rozpoczęła negocjacje ze spółką Sun Microsystems (później przejętą przez Oracle), mające na celu dostosowanie platformy Java do tego rodzaju urządzeń. Negocjacje te zakończyły się jednak niepowodzeniem. Punktem spornym był wymóg Sun Microsystems, aby implementacja Javy w systemie Android była kompatybilna z platformą Java, co spółka Google uważała za zbędne. W konsekwencji Google zaczął rozwijać własną platformę Java. Tworząc ją, literalnie skopiował około 11 500 linii kodu źródłowego pakietów API Java w części odpowiadającej za deklaracje („nagłówki”). Stanowiło to niewielki procent kodu źródłowego 37 ze 166 pakietów, które w tym okresie składały się na API Javy (ściślej 0,4% z 2 860 000 linii kodu). Pozostała część kodu źródłowego tych pakietów, służąca implementacji poszczególnych metod, została samodzielnie stworzona przez Google.

Google przejął również hierarchię tych pakietów, tj. pogrupowanie poszczególnych metod w klasy, przyporządkowanie klas do poszczególnych pakietów oraz stosowane nazewnictwo („taksonomię”). Celem Google było zapewnienie pewnego stopnia interoperacyjności przy braku pełnej kompatybilności platform. Implementując takie same metody z podstawowych pakietów Javy i porządkując je w taki sam sposób, Google dążył do maksymalnego ułatwienia społeczności programistów, skupionej wokół platformy Java, rozpoczęcia tworzenia programów na platformę Android. Programista nie musiał się uczyć nowych metod i ich właściwości, mógł też w prosty sposób wykorzystać gotowy kod w języku Java.

Google, dążąc do zapewnienia częściowej interoperacyjności, zdecydował się na skopiowanie kodu z plików nagłówkowych oraz przyjęcie analogicznej organizacji pakietów. Technologia Java nie narzuca określonego schematu organizacji pakietów, metod i klas. W konsekwencji Google miał możliwość uzyskania identycznej funkcjonalności środowiska przy zastosowaniu odmiennej architektury API. Jednakże zachowanie tożsamości nazw metod, argumentów oraz zwracanych wartości, koniecznych dla zapewnienia programistom łatwego startu na nowej platformie, wymagało identyczności plików nagłówkowych. Analogiczna zależność dotyczyła struktury organizacyjnej pakietów, określanej mianem „taksonomii”.

Główna linia obrony Google opierała się na dwóch filarach. Po pierwsze Google twierdził, że skopiowane elementy pozostają poza granicami ochrony prawnoautorskiej zgodnie z § 102 (b) Copyright Act. Przepis ten przewiduje, że „w żadnym wypadku ochrona praw autorskich do oryginalnego dzieła autorskiego nie obejmuje jakiejkolwiek idei, procedury, procesu, systemu, metody działania, koncepcji, zasady lub odkrycia, niezależnie od formy, w jakiej zostały one opisane, wyjaśnione, zilustrowane lub zawarte w takim dziele”. Po drugie Google argumentował, że nawet gdyby skopiowane elementy były chronione, jego działania mogły być uznane za fair use zgodnie z § 107 Copyright Act.

Idea, wyrażenie i merger doctrine

Pierwszym rozstrzygnięciem w sprawie był wyrok Sądu Dystryktowego z 2012 roku, który uznał stanowisko Google, że skopiowane elementy nie są objęte ochroną prawnoautorską. W 2014 roku Sąd Apelacyjny Okręgu Federalnego (CAFC) uchylił wyrok sądu pierwszej instancji. CAFC nakazał ponowne rozpoznanie sprawy, wskazując na konieczność zbadania możliwości zastosowania doktryny fair use, którą sąd pierwszej instancji pominął w swojej analizie. Jednocześnie CAFC dokonał merytorycznego rozstrzygnięcia w zakresie ochrony prawnoautorskiej przejętych elementów API Javy, uznając że zarówno kod deklaracji, jak i struktura, sekwencja oraz organizacja pakietów API stanowią przedmiot ochrony prawnoautorskiej.

W swoim rozstrzygnięciu CAFC przyjął, że w sprawie brak możliwości wykluczenia ochrony prawnoautorskiej w oparciu o doktrynę merger. Doktryna ta zakłada, że w sytuacji gdy idea może być wyrażona jedynie w ograniczonej liczbie sposobów, dochodzi do zespolenia idei i jej wyrażenia, co wyklucza objęcie tego wyrażenia ochroną prawnoautorską. CAFC przyjął, że kluczowym kryterium jest zakres swobody twórczej przysługujący pierwotnemu twórcy platformy programistycznej, nie zaś ograniczenia, jakim podlegają późniejsi programiści dążący do zachowania kompatybilności. W konsekwencji sąd uznał, że Oracle (wcześniej Sun Microsystems) podczas tworzenia platformy Java dysponował wystarczającą swobodą twórczą w zakresie konstruowania pakietów, w szczególności w odniesieniu do nazewnictwa metod i argumentów. Jakkolwiek podane przykłady zahaczają miejscami o śmieszność (sąd wskazywał np. że programiści Sun funkcję metody „Math.max”, mogli nazwać w dowolny sposób, w tym „Math.maximum” lub „Arith.larger”), argument ten ma swoją wewnętrzną logikę.

Pomimo złożenia przez Google wniosku o certiorari, Sąd Najwyższy USA początkowo odmówił rozpoznania sprawy. W konsekwencji postępowanie powróciło do Sądu Dystryktowego. Zgodnie z wcześniejszym wyrokiem Sądu Apelacyjnego Okręgu Federalnego (CAFC), który przesądził kwestię ochrony prawnoautorskiej API, przedmiotem dalszego postępowania pozostała wyłącznie ocena możliwości zastosowania doktryny fair use.

Fair use

Doktrynę fair use kodyfikuje § 107 amerykańskiej ustawy o prawie autorskim (Copyright Act). Zgodnie z tym przepisem, ocena legalności korzystania z utworu bez zgody uprawnionego wymaga analizy czterech kryteriów. Po pierwsze, konieczne jest zbadanie celu i charakteru korzystania, w szczególności jego komercyjnego charakteru. Po drugie, należy uwzględnić charakter utworu chronionego. Po trzecie, ocenie podlega zakres wykorzystania utworu, zarówno pod względem ilościowym, jak i jakościowym. Po czwarte, analizie podlega wpływ takiego korzystania na potencjalny rynek lub wartość utworu chronionego.

Na to nakłada się jeszcze kwestia tzw. transformatywnego użycia. W ten sposób określa się wykorzystanie utworu chronionego w sposób prowadzący do powstania nowego rezultatu o odmiennym charakterze lub celu. Transformacja może polegać na dodaniu nowego wyrazu, znaczenia lub przekazu do oryginalnego utworu. W orzecznictwie amerykańskim uznaje się, że im bardziej transformatywne jest wykorzystanie utworu, tym mniejsze znaczenie mają pozostałe czynniki oceny fair use, w tym komercyjny charakter wykorzystania. Sądy zwykle przychylniej patrzą na przypadki transformatywnego wykorzystania utworu niż na proste przeniesienie jego elementów do nowego kontekstu.

Również w tym aspekcie ujawniły się różnice w podejściu sądów. Sąd Dystryktowy w 2016 roku zakwalifikował działania Google jako mieszczące się w granicach fair use. Sąd Apelacyjny Okręgu Federalnego (CAFC) w wyroku z 2018 roku zajął przeciwne stanowisko. CAFC uznał, że samo przeniesienie komponentów środowiska programistycznego między platformami, bez ich istotnej modyfikacji, nie stanowi użycia transformatywnego, które mogłoby uzasadniać komercyjne wykorzystanie API Java. Dodatkowo CAFC wskazał na negatywny wpływ praktyk Google na model licencyjny platformy Java, co stanowi czynnik przemawiający przeciw możliwości powołania się na doktrynę fair use.

Wyrok Sądu Najwyższego

W ostatecznym rozstrzygnięciu Sąd Najwyższy USA uznał wykorzystanie API Java przez Google za mieszczące się w granicach fair use. Sąd podkreślił, że skopiowane linie kodu stanowią element interfejsu użytkownika, służący programistom do dostępu do wcześniej napisanego kodu poprzez proste komendy. Jako część interfejsu, są one nierozerwalnie związane z ideami niepodlegającymi ochronie prawnoautorskiej, takimi jak ogólna organizacja API, oraz z tworzeniem nowej ekspresji twórczej w postaci kodu napisanego przez Google.

Sąd Najwyższy uznał również, że komercyjny charakter wykorzystania API Java znajduje uzasadnienie w transformatywnym charakterze tego wykorzystania. Google skopiował wyłącznie elementy niezbędne do umożliwienia programistom pracy w środowisku mobilnym przy zachowaniu znajomości języka programowania. Skopiowanie niewielkiej części kodu było podyktowane wyłącznie względami funkcjonalnymi, nie zaś wartością twórczą przejętych elementów.

W zakresie skutków rynkowych Sąd Najwyższy stwierdził, że platforma Android nie stanowi substytutu rynkowego dla Java SE. Jednocześnie uznanie działań Google za naruszenie prawa autorskiego stanowiłoby barierę dla kreatywności, ze szkodą dla interesu społecznego. W konsekwencji Sąd Najwyższy uznał spełnienie wszystkich przesłanek fair use określonych w § 107 Copyright Act.

Co z tego wynika

W swoim wyroku Sąd Najwyższy USA zawarł rozsądną ocenę, że gdy oprogramowanie staje się standardem rynkowym, jego twórca de facto kształtuje warunki techniczne, do których muszą dostosować się inni uczestnicy rynku. W takich przypadkach prawo autorskie nie powinno stanowić bariery dla zachowania interoperacyjności programów komputerowych, nawet jeśli wymaga to przejęcia fragmentów kodu źródłowego. Stworzenie takich barier poprzez nadmierną ochronę prawnoautorską byłoby sprzeczne z interesem społecznym, hamując rozwój technologiczny i innowacje w sektorze.

---

O wyroku SCOTUS w sprawie Oracle v Google piszę także z Marcinem Marutą w tym artykule.

^{obrazek: Pixabay}