Google v. Oracle, czyli prawnoautorski spór dekady

W tym miesiącu odbyła się długo wyczekiwana rozprawa przed amerykańskim Sądem Najwyższym pomiędzy dwoma gigantami branży tech – Google i Oracle. Ten prawnoautorski spór dekady, jak często bywa określany przez media, rozpoczął się w 2010 roku, po przejęciu twórców Javy – Sun Microsystems przez Oracle Corporation. Wynik sporu może mieć znaczący wpływ na gałąź software’ową i prawo autorskie.

Czego dotyczy spór?

Sprawa dotyczy wykorzystania API (ang. application programming interface) Javy, czyli interfejsu programowania aplikacji – w najprostszym ujęciu – zbioru reguł opisującego sposoby, poprzez które programy lub ponadprogramy komunikują się ze sobą.  Wiele programów i bibliotek oprogramowania, w szczególności open source, jest opracowywanych przed odtworzenie funkcjonalności API z produktów komercyjnych lub konkurencyjnych, aby pomóc deweloperom w zapewnieniu interoperacyjności między różnymi systemami lub platformami.

Sama Java została opracowana przez Sun i wydana po raz pierwszy w 1996 roku, szybko stając się jednym z najbardziej popularnych języków i platform programowania na świecie. W pierwszych latach ubiegłej dekady Google i Sun rozpoczęli rozmowy na temat współpracy umożliwiającej Google dostosowanie Javy do smartfonów. Mieli oni w planach włączenie bibliotek programistycznych Java Standard Edition (SE) do tworzonego przez nich systemu operacyjnego Android. Sun Microsystems został w międzyczasie przejęty przez firmę Oracle, a dotychczasowe negocjacje zakończyły się fiaskiem. Brak porozumienia nie powstrzymał jednak Google przed wykorzystaniem API Javy. W konsekwencji Oracle wniosła pozew przeciwko Google twierdząc, że skopiowali strukturę, kolejność i organizację kodu oprogramowania dla 37 pakietów, naruszając tym samym prawa autorskie, mimo że,  implementacja API została napisana niezależnie.

Google przeciwstawił się tym twierdzeniom konsekwentnie argumentując, że Java API to metody działania/funkcje, które nie są chronione prawami autorskimi. Żeby zrozumieć sedno problemu, warto, w ślad za sędzią Williamem Alsupem, orzekającym w sprawie w pierwszej instancji przed Sądem Dystryktowym USA dla Północnego Dystryktu Kalifornii, przyrównać API do biblioteki. Każdy z pakietów przypomina półki na książki w tej bibliotece.

Co do wspomnianych już 37 pakietów, o które toczy się spór, biblioteki Java i Android są zorganizowane w ten sam podstawowy sposób. Wszystkie rozdziały w systemie Android zostały napisane z implementacjami innymi niż Java, ale rozwiązując te same problemy i zapewniając te same funkcje.  Każda metoda i klasa jest określona w celu wykonania dokładnych żądanych funkcji, a zatem “deklaracja”, czyli linia kodu stwierdzająca specyfikację musi być identyczna do wykonania danej funkcji. Innym, może jeszcze bardziej przystępnym sposobem wyjaśnienia istoty API może być porównanie go do jadłospisu w restauracji. Zawiera on wykaz oferowanych dań oraz ich opisy. Po wybraniu przez klienta dania w jadłospisie kelner przekazuje zamówienie do kuchni, gdzie danie zostaje przygotowane, a następnie podane klientowi. Klient nie wie jak kucharz przygotowuje zamówione danie, i tak naprawdę nie potrzebuje tego wiedzieć. Porównanie to nie uwzględnia oczywiści wszystkich możliwych zastosowań interfejsu API (zwłaszcza, jeżeli użytkownik jest programistą), ale w zupełności wystarcza, aby  w ogólnym zarysie wyjaśnić jego działanie.

W swoim stanowisku Google twierdzi przede wszystkim, że po pierwsze API Javy nie podlegają prawom autorskim, a po drugie, nawet jeśli przyjmiemy, że jest inaczej, to elementy powielane przez Google podlegają doktrynie fair use. Wiele przedsiębiorstw związanych z branżą tech jak i stowarzyszeń czy przedstawicieli środowisk prawniczych skierowało w tej sprawie pisma jako „przyjaciele sądu” (lac. amici curiae) do Sądu Najwyższego, opowiadając się w większości po stronie Google.

Analiza Sądu Najwyższego

Analiza Sądu Najwyższego, co można było wywnioskować już wcześniej, dotyczyć będzie przede wszystkim dwóch zagadnień amerykańskiego prawa autorskiego, których odpowiedniki możemy znaleźć również na gruncie polskiego porządku, tj. doktryny połączenia (ang. merger doctrine) i możliwości jej zastosowania do API Javy, oraz doktryny fair-use.

Merger doctrine jest powiązana z zasadą rozdzielenia niechronionego pomysłu od chronionego sposobu wyrażenia (ang. idea–expression dichotomy). Przesądza ona o tym, że gdy istnieje tylko jeden lub ograniczona liczba sposobów wyrażenia idei, prawo autorskie nie będzie chroniło tego wyrażenia, ponieważ “połączyło się” ono z ideą. Kiedy idea i wyrażenie są bardzo trudne do oddzielenia, mówi się, że się łączą. Obie wspomniane doktryny zawdzięczają swoje pochodzenie przełomowej sprawie Baker v. Selden, która również toczyła się przed Sądem Najwyższym USA.

Zasadnicze pytanie opiera się przede wszystkim na tym, czy merger doctrine ma zastosowanie do API Javy. Oracle powołuje się na aspekt twórczy wyborów dokonanych przez deweloperów. Google twierdzi natomiast, że API Javy są jedynym i niezbędnym środkiem do wykonania danego zadania – innymi słowy, koncepcja leżąca u podstaw API nie może być wyrażona w więcej niż jeden sposób. API Javy nie są więc chronione, a ich użycie nie stanowi naruszenia praw autorskich. Jeśli Sąd zgodzi się w tym aspekcie z Oracle, przyznając API status utworu, następną konieczną do rozważenia kwestią będzie to czy korzystanie z API przez Google może być dopuszczalne na gruncie fair use. Fair use to doktryna obecna w amerykańskim prawie autorskim, która zezwala na ograniczone użycie materiału chronionego bez konieczności uprzedniego uzyskania zgody od właściciela praw. Z niewielkimi różnicami odpowiada ona znanej na gruncie polskiego prawa instytucji dozwolonego użytku. Artykuł 107 Copyright Act of 1976 określa pewne dopuszczalne rodzaje wykorzystania – takie jak krytyka, komentarz, doniesienia prasowe, nauczanie, stypendium i badania. Dodatkowo określa faktory, które należy mieć na uwadze rozważając taką możliwość w odniesieniu do użycia utworu tj. cel i charakter użycia dzieła, w szczególności kwestia, czy zostało ono użyte w celu komercyjnym, czy niekomercyjnym i edukacyjnym; rodzaj i natura wykorzystywanego dzieła; proporcja objętości i znaczenia fragmentu użytego dzieła w stosunku do całej jego objętości, a także objętości i znaczenia dzieła pochodnego, w którym ten fragment został użyty oraz rezultaty wpływu użycia tego dzieła na jego sprzedaż oraz wartość na rynku.

W trakcie trwającej prawie dwie godziny środowej rozprawy sędziowie i pełnomocnicy stron porównywali API Javy z piosenką, drużyną piłkarską, systemem księgowym, instrukcją znalezienia mieszanki przypraw w sklepie spożywczym oraz układem klawiatury QWERTY. Na podstawie tych porównań i zadanych pytań można mieć wątpliwości czy sędziowie w pełni rozumieją istotę API.

Czy spór ma wpływ na Europę?

Choć sprawa toczy się przed sądem amerykańskim, jej wynik może mieć potencjalnie wpływ na koncepcję ochrony API w Unii Europejskiej. Dotychczasowe stanowisko prezentowane w orzecznictwie, a przede wszystkim na gruncie wyroku Trybunału Sprawiedliwości UE z dnia 2 maja 2012 r. w sprawie SAS Institute Inc. przeciwko World Programming Ltd. – C-406/10, nie przyznaje jednak ochrony interfejsowi programowania aplikacji. W powoływanej sprawie Trybunał orzekł, że zbiór funkcji, język czy format plików danych używanych w ramach programu komputerowego w celu korzystania z pewnych jego funkcji nie stanowią formy wyrażenia tego programu i nie podlegają z tego tytułu ochronie przyznawanej programom komputerowym przez prawo autorskie w rozumieniu dyrektywy Rady 91/250/EWG z dnia 14 maja 1991 r.

Autorka: Karolina Kucharska, prawnik