Historia sporu: znajomy interfejs w nowym środowisku
Budując Androida, Google napisało własny kod wykonujący zadania, a zarazem wykorzystało około 11 500 wierszy kodu deklarującego interfejsu Java SE. Chodziło o umożliwienie programistom korzystania z poznanych wcześniej poleceń w środowisku mobilnym. Oracle, jako uprawniony do Java SE, zakwestionowało takie wykorzystanie. Spór dotyczył więc konkretnej warstwy programu, a nie prostego przejęcia całego systemu. [2]
Historia postępowania pokazuje znaczenie kolejności pytań: po rozstrzygnięciu o ochronie interfejsu nadal pozostawała obrona oparta na fair use. Wyniki kolejnych etapów przed ławą przysięgłych i sądem apelacyjnym różniły się. Sama kwalifikacja materiału jako chronionego nie kończyła zatem analizy sposobu jego wykorzystania. [2]
Pytanie prawne i właściwy test
Amerykański § 107 Copyright Act wymaga oceny celu i charakteru wykorzystania, natury utworu, rozmiaru oraz istotności wykorzystanej części i wpływu na rynek lub wartość utworu. Nie ustanawia jednej dozwolonej liczby wierszy ani bezpiecznego procentu kopiowania. Kryteria stanowią strukturę oceny konkretnego użycia; znaczenie części trzeba rozpatrywać w odniesieniu do całości i okoliczności. [3]
Wniosek redakcyjny: przed badaniem podobieństwa warto sformułować dwie osobne hipotezy. Pierwsza dotyczy tego, czy materiał w ogóle podlega ochronie. Druga dotyczy tego, czy określone użycie może być dopuszczalne mimo ochrony. Zlewanie ich prowadzi do opinii, której konkluzji nie da się odtworzyć.
Metoda analizy: kod, funkcja i rynek
Sąd Najwyższy odróżnił deklaracje pozwalające wywoływać funkcje od implementacji, która te funkcje wykonuje. Rozstrzygnięcie z 5 kwietnia 2021 r. oparł na fair use, przyjmując wyłącznie na potrzeby rozumowania możliwość ochrony spornego kodu. Nie przesądził ostatecznie, że wszystkie API są chronione, ani że pozostają poza ochroną. [1]
Propozycja metodyczna: audyt podobnego projektu powinien zawierać tabelę pochodzenia plików, mapę przejętych elementów, opis samodzielnie napisanej implementacji i uzasadnienie technicznej potrzeby zgodności. Osobnego materiału wymaga rynek: kto używa rozwiązania, do jakiego zadania i jakie produkty rzeczywiście może ono zastąpić. Taka dokumentacja pozwala skontrolować argumenty; nie gwarantuje wyniku sprawy.
Rozstrzygnięcie i jego uzasadnienie
W tych okolicznościach większość Sądu uznała wykorzystanie za fair use. Znaczenie miały funkcjonalny charakter interfejsu, nowy kontekst platformy i związek rozmiaru kopiowania z przyjętym celem. Sąd oceniał też skutki dla rynku oraz możliwość wykorzystania przez programistów wcześniejszych umiejętności. Wynik nie był zezwoleniem na dowolne kopiowanie programów. [1]
Wniosek redakcyjny: najbardziej użyteczna lekcja tej sprawy dotyczy opisu przedmiotu sporu. Ogólne słowo „kod” ukrywa odmienne role techniczne. Analiza powinna wyjaśnić, jakie elementy tworzą sposób komunikacji z programem, a jakie stanowią konkretną realizację zadania. Dopiero wtedy argument o kompatybilności można skonfrontować z rzeczywistym zakresem przejęcia.
Co wynika z tego dla projektów informatycznych w Polsce
Wniosek redakcyjny: Google kontra Oracle warto czytać jako studium argumentacji porównawczej, a nie gotową instrukcję dla polskiego projektu. Najpierw trzeba wskazać właściwy system prawny, rodzaj prawa, warunki licencji i czynności użytkownika. Później można porównać sposób dokumentowania funkcji, konieczności przejęcia oraz skutków gospodarczych.
W hipotetycznym audycie biblioteki programistycznej wynik powinien przyjąć postać kilku oddzielnych ustaleń: skąd pochodzi materiał, jak go wykorzystano, jakie warunki umowne sprawdzono i które zagadnienia wymagają dalszej oceny. Sama nazwa głośnego precedensu nie zastępuje tych ustaleń. To propozycja pracy nad materiałem, a nie opis czynności wykonywanych przez strony historycznego sporu.
Dodatkowa propozycja dokumentacyjna: zachowuj numery wersji, sumy kontrolne i daty pobrania ocenianych plików. Dzięki temu późniejsza osoba sprawdzająca raport będzie mogła odtworzyć dokładnie ten sam materiał. Porównanie innego wydania biblioteki może prowadzić do innych ustaleń technicznych, nawet jeżeli nazwa produktu pozostaje identyczna.
Co wynika z analizy
- Rozdziel pytanie o ochronę od pytania o dopuszczalność konkretnego wykorzystania.
- Oceniaj funkcję przejętych elementów, ich pochodzenie i kontekst rynku.
- Nie przenoś amerykańskiego fair use automatycznie do polskiej analizy.
Granice interpretacji
Opracowanie dotyczy amerykańskiego prawa autorskiego i konkretnych ustaleń sprawy. Nie rozstrzyga patentowalności oprogramowania ani legalności dowolnego kopiowania API. Wnioski metodyczne są komentarzem redakcyjnym.
Źródła i dalsza lektura
- 1Google LLC v. Oracle America, Inc. — opinia Sądu Najwyższego USA ↗
18-956; 593 U.S. 1 (2021), 5.04.2021
Źródło pierwotne; w szczególności s. 11–15 i 21–36 opinii większości. Syllabus jest odrębnym streszczeniem redakcyjnym.
- 2U.S. Copyright Office — Fair Use Index: Google v. Oracle ↗
Fair Use Index, Google LLC v. Oracle Am., Inc., 2021
Urzędowe opracowanie faktów i przebiegu postępowania; odrębne od samego wyroku.
- 3Copyright Act — ustawowe kryteria fair use ↗
17 U.S.C. § 107
Tekst prawa opublikowany przez U.S. Copyright Office; cztery czynniki oceny.