5 kwietnia 2021 r. Sąd Najwyższy USA wydał wyrok w sprawie Oracle v Google na korzyść tej drugiej firmy. Zakończył tym samym ciągnący się od ponad 10 lat spór, w którym pojawiają się takie hasła jak API, Java, Android, merger doctrine, fair use. W grze było także odszkodowanie w wysokości – bagatela – 9 mld USD. Warto więc przypomnieć o co tak naprawdę chodziło i jakie znaczenie ma to rozstrzygnięcie. Kto wygrał, kto co mógł rozegrać lepiej, i czy polscy programiści mogą czerpać z tego dorobku.
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 Google uważ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 lini 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.
Skopiowanie kodu z plików nagłówkowych i organizacji pakietów było związane z zamiarem zapewnienia tej pożądanej przez Google częściowej interoperacyjności. Powinniśmy pamiętać, że Java nie wymusza sposobu organizacji pakietów, metod i klas. Google mógł więc zapewnić taką samą funkcjonalność środowiska przyjmując odmienną organizację API – co ma znaczenie z punktu widzenia prawa autorskiego (swoboda twórcza vs konieczny do zastosowania i jedyny standard). Ale jeżeli dana metoda miała być wywoływana za pomocą tej samej nazwy, tych samych argumentów i zwracać taki sam wynik, pliki nagłówkowe musiały być identyczne. To samo dotyczyło „taksonomii”, czyli sposobu organizacji pakietów.
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” (w Europie mamy bardzo podobnie, o czym później). 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 (a tego akurat nie mamy).
Idea, wyrażenie i merger doctrine
Pierwszy wyrok zapadł w 2012 r. Sąd dystryktowy orzekł na korzyść Google uznając, że skopiowane elementy nie podlegają ochronie prawnoautorskiej. Dwa lata później Sąd Apelacyjny Okręgu Federalnego (CAFC) uchylił wyrok sądu pierwszej instancji i rozstrzygnął merytorycznie kwestię prawnoautorskiej ochrony przejętych elementów API Javy uznając, że kod deklaracji, a także struktura, sekwencja i organizacja pakietów API mogą podlegać ochronie prawnoautorskiej. Nakazał natomiast sądowi pierwszej instancji dokładniej przyjrzeć się kwestii fair use. Zmieniliśmy więc płaszczyznę sporu – z kwestii „czy prawo autorskiego w ogóle ma zastosowanie” na „czy łapiemy się na wyjątek”.
W wyroku CAFC jedną z kluczowych kwestii merytorycznych była kwestia zastosowania tzw. merger doctrine. Podstawowym założeniem prawa autorskiego jest ochrona wyrażenia (ekspresji), a nie idei. Doktryna merger sprowadza się z grubsza do założenia, że pewne idee, te nie chronione przez prawo autorskie, mogą być wyrażone tylko na ograniczoną liczbę sposobów. To cecha i przekleństwo programów nakierowanych na czystą efektywność czy poprawność – w teorii można kodować np. nowe reguły akcyzy na wiele sposobów, ale realnie, w konkretnym systemie, wybór jest niewielki. W takim przypadku dochodzi do „stopienia się” wyrażenia i idei w taki sposób, że stają się one nierozróżnialne. Nie można więc przyznać ochrony wyrażeniu, bo rozciągałaby się ona na idee. Dla CAFC kluczowe było, że decyduje swoboda twórcza, jaką ma pierwotny twórca platformy programistycznej, a nie późniejsi programiści, zmuszeni do dostosowania się do przyjętych przez niego założeń w celu zachowania kompatybilności.
Patrzymy więc na pierwszego twórcę, a nie rzeszę następców, którzy – realnie, chcąc zachować kompatybilność – muszą dostosować się na opracowanego standardu. W tej sprawie Oracle (a poprzednio Sun Microsystems), tworząc platformę Java, miała wystarczający zakres swobody twórczej, mogąc wytworzyć pakiety w całkowicie dowolny sposób, przede wszystkim w zakresie nazw metod i argumentów. Nie doszło więc do „stopienia się” idei i wyrażenia, i w konsekwencji uznano, że sporne elementy mogły podlegać ochronie. Jakkolwiek podane przykłady momentami są dość zabawne (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ę.
Mimo prób podejmowanych przez Google Sąd Najwyższy USA nie przyjął sprawy do rozpoznania (niestety, niestety, to naprawdę ciekawy temat). Spór wrócił wiec do sądu dystryktowego i zgodnie z wyrokiem CAFC toczył się dalej już tylko w zakresie fair use.
Czym jest fair use?
Fair use – § 107 Copyright Act – jest swoistym bezpiecznikiem, pozwalającym na eksploatację utworu w takim zakresie, w którym monopol autorski byłby moralnie czy społecznie nieusprawiedliwiony. Prawo autorskie, o czym się zapomina, to nie tylko prawa twórcy (Janka Muzykanta), jego producenta czy wydawcy, ale także prawa użytkowników czy szerzej – społeczeństwa. Fai use jest charakterystyczny dla prawa autorskiego USA ograniczeniem praw autorskich. Wyróżnia go elastyczność. Pozwala bowiem uznać za dozwolone pewne sposoby korzystania z utworu, nawet jeżeli ustawa o nich nie wspomina, jeżeli tylko są „fair”. Kryteria tej oceny określa wspomniany §107. Nakazuje on brać pod uwagę takie czynniki jak cel i charakter korzystania (w tym, czy ma charakter komercyjny), charakter dzieła chronionego prawem autorskim, wielkość i istotność wykorzystanej części w stosunku do całości utworu chronionego prawem autorskim oraz wpływ wykorzystania na potencjalny rynek lub wartość dzieła chronionego prawem autorskim.
I znów w ocenie sądów pojawiły się różnice. W 2016 r. sąd dystryktowy orzekł na korzyść Google uznając, że działania spółki mieściły się w granicach fair use. CAFC w 2018 r. uznał, że granice fair use zostały przekroczone. Dla stanowiska CAFC kluczowe było, że wykorzystanie przejętych elementów przez Google nie miało charakteru „transformacyjnego”. Google po prostu przeniósł bez większych zmian fragmenty środowiska programistycznego z jednej platformy na inną.
Rozstrzygnięcie przed Sądem Najwyższym USA
Tym razem Sąd Najwyższy sprawę wziął do rozstrzygnięcia. Skarga Google dotyczyła obu głównych elementów sporu, ale zdaniem sądu w szybko zmieniających się warunkach technologicznych i biznesowych odpowiedź powinna ogranicza się tylko do tego, co jest niezbędne do rozstrzygnięcia sporu. A za niezbędną sąd uznał tylko kwestię fair use. Zdaniem sądu:
“Charakter spornego utworu przemawia za fair use. Skopiowane linie kodu są częścią ‘interfejsu użytkownika’, który zapewnia programistom dostęp do wcześniej napisanego kodu komputerowego poprzez użycie prostych komend. Jako część interfejsu, skopiowane linie kodu są nieodłącznie związane z ideami nieobjętymi prawami autorskimi (ogólna organizacja API) i tworzeniem nowej ekspresji twórczej (kod napisany przez Google).
Komercyjny cel i charakter wykorzystania elementów zaczerpniętych z API Javy może być usprawiedliwiony transformacyjnym charakterem użycia (a jednak). Google skopiował tylko to, co było potrzebne, aby umożliwić programistom pracę w innym środowisku obliczeniowym i wykorzystanie już znanego języka programowania. Celem Google było stworzenie innego systemu dla innego środowiska komputerowego (smartfonów) oraz stworzenie platformy (Androida) która pomogłaby osiągnąć i spopularyzować ten cel.
Skopiowana została jedynie niewielka część utworu. Co więcej Google skopiował te linie „nie ze względu na ich kreatywność czy piękno, ale dlatego, żeby umożliwić programistom wykorzystanie ich umiejętności w nowym środowisku smartfonów”.
Jeżeli chodzi o skutki rynkowe Sąd Najwyższy wskazał, że nowa platforma Google dla smartfonów nie jest rynkowym substytutem dla Java SE. Ponadto uznanie, że doszło tu do naruszenia prawa autorskiego stanowiłoby barierę kreatywności ze szkodą dla społeczeństwa. Zestawienie tych dwóch czynników doprowadziło sąd do wniosku, że również w zakresie skutków rynkowych spełnione są wymogi § 107 Copyright Act.
Sąd Najwyższy USA powiedział wiec mniej więcej tyle, że producent oprogramowania, które stanie się rynkowym standardem, w istocie kreuje rzeczywistość, do której inni producenci muszą się dostosować. W takich przypadkach zachowanie interoperacyjności wymaga w niektórych przypadkach przejęcia fragmentu cudzego programu. Tworzenie w oparciu o prawo autorskie barier dla takich praktyk nie służy interesom społecznym.
Co z wyroku w sprawie Oracle vs Google dla nas wynika?
Możemy tylko pofilozofować, skoro po pierwsze w sprawie orzekały sądy amerykańskie, a po drugie pomiędzy prawem amerykańskim a polskim (czy szerzej – europejskim) jest trochę różnic.
Co mogłoby wyglądać podobnie? W prawie europejskim podobnie można by oceniać możliwość ochrony nazw funkcji metod (owego „match.max”) i ich organizacji (taksonomii pakietów Javy). Takie wnioski wynikają z wyroku Trybunału Sprawiedliwości UE w sprawie C-406/10 SAS Institute. TSUE oceniał w nim możliwość prawnoautorskiej ochrony języka programowania i formatów plików środowiska SAS. I wprawdzie uznał, że język programowania i format plików nie podlega ochronie jako program komputerowy (innymi słowy, odróżnił specyfikację języka czy formatu plików od ich implementacji), ale jednocześnie wskazał, że jeżeli tylko są oryginalne mogą one być chronione na podstawie dyrektywy 2001/29/WE o prawie autorskim w społeczeństwie informacyjnym. Czyli choć nie są programem, mogą podlegać ochronie prawnoautorskiej (na szczęście mamy jeszcze inne utwory niż tylko programy).
TS UE ocenił więc język programowania jako zbiór słów kluczowych i ich wzajemnych powiązań za pomocą reguł składniowych. Pojedyncze słowa nie podlegają ochronie, ale jeżeli dobór słów i dobór reguł składniowych stanowi oryginalny wyraz twórczej inwencji, ochrona jest możliwa. Wyroki TS UE są wiążące dla sądów krajowych państw członkowskich. Jeżeli więc polski sąd miałby oceniać, czy API jest chronione, powinien – tak jak CAFC – zastanawiać się nad tym, czy cały zbiór nazw funkcji metod odznacza się oryginalnością i czy oryginalnością taką oznacza się sposób ich pogrupowania w pakiety. Oceny tej – tak jak CAFC – powinien dokonywać z punktu widzenia programistów Sun (Oracle), a nie innych podmiotów, które muszą dostosować się do przyjętej przez twórców środowiska struktury. Istnieje duże prawdopodobieństwo, że doszedłby do podobnych wniosków jak CAFC i uznał API Javy za coś chronionego.
Natomiast nie mamy ani w Polsce, ani w Europie bezpośredniego odpowiednika fair use. Mamy dozwolony użytek, ale akurat przy programach komputerowych ma on marginalne znaczenie. Mamy przeciekawą konstrukcję legalnego użytkownika w art. 75 ust. 1 naszej ustawy i katalog czynności „dozwolonych” w 75 ust. 2 (m.in. obserwowanie, badanie i testowanie programu oraz dozwolona dekompilacja), ale one też, przy omawianym sporze, nie na wiele się zdadzą. Brakuje nam fair use, a jeżeli nie fair use, to przynajmniej „dedykowanego” ograniczenia prawa autorskiego (wyjątku) który pozwalałby tworzyć interoperacyjne programy w tych przypadkach, w których zachowanie interoperacyjności wymaga przejęcie z cudzego programu elementów chronionych.
Z jednej strony – wyrok – ciekawostka, o sporym znaczeniu głównie dla systemu prawnego USA. Z drugiej strony pokazuje, że nasze (polskie i europejskie) prawo autorskie jest miejscami zbyt „sztywne”, zbyt mało elastyczne, aby dostosować się do zmieniających potrzeb technologicznych i biznesowych. Jeżeli nie chcemy przegrywać w globalnym wyścigu technologicznym, musimy się nauczyć czynić go bardziej sprawnym, elastycznym. A przyziemnie – nasz rodzimy biznes programistyczny rośnie w siłę, i wielu z nas stanie przed podobnymi dylematami: co mogę wziąć z innego utworu, cały czas działając legalnie.
Na sam koniec (dzięki, Bohdan Widła za podrzucenie) – komunikat Oracle po publikacji wyroku: “The Google platform just got bigger and market power greater—the barriers to entry higher and the ability to compete lower. They stole Java and spent a decade litigating as only a monopolist can. This behavior is exactly why regulatory authorities around the world and in the United States are examining Google’s business practices“—Dorian Daley, Executive Vice President and General Counsel, Oracle.
dr Zbigniew Okoń, Partner w kancelarii Maruta Wachta sp.j.; Marcin Maruta, Partner i Wspólnik w kancelarii Maruta Wachta sp.j.
