Wstęp

Dzisiejszy wpis to efekt lektury artykułu Pani Mec. Marty Pasztaleniec na stronie IP Procesowo. Kluczowe dla dzisiejszego wpisu jego fragmenty to:

Programy komputerowe w świetle krajowego prawa autorskiego korzystają ze szczególnej ochrony. Z uwagi na ich specyfikę wyłączono stosowanie niektórych regulacji z ogólnej części prawa autorskiego, w szczególności przepisów dotyczących dozwolonego użytku, który umożliwia w ściśle określonych okolicznościach korzystanie z utworów bez zgody twórcy, a nawet wbrew takiej zgodzie. Co do zasady zatem jakiekolwiek zwielokrotnienie programu komputerowego wymaga zgody twórcy. […]
Spór ma swą genezę w 2005 r. kiedy to Google nabył startup Android Inc i rozpoczął starania by wejść na rynek smartfonów, tworząc platformę do budowy systemów dla urządzeń mobilnych. Platforma w swym założeniu miała być nieodpłatna po to by popularyzować środowisko Google. Jako że język programistyczny Java był wówczas jednym z najbardziej popularnych i powszechnych wśród programistów, Google podjął rozmowy z Sun Microsystems ? twórcą Java ? na temat licencjonowania całej platformy Java. Ostatecznie zdecydował się jednak na budowę własnej platformy. Aby jednak zapewnić jej powszechność i łatwość stosowania wśród programistów zastosowano w nim nazwy funkcji i formatów danych charakterystyczne dla języka Javy. Google de facto opracował własne odpowiedniki funkcji Javy i nadał im nazwy takie same jak w Javie. Oracle, po przejęciu spółki Sun Microsystems, pozwał w 2010 r. Google o naruszenie przysługujących Oracle praw autorskich i patentów. Zarzucono Google skopiowanie blisko 11 500 linii deklaracji API programu Java (co stanowiło 0,4 % deklaracji). […]
Sąd uznał, że działanie Google było ?zgodne z kreatywnym ?postępem?, który jest podstawowym konstytucyjnym celem samego prawa autorskiego?. Według sądu dozwolony użytek pełni więc istotną rolę w rozwoju oprogramowania, a prawo autorskie nie powinno hamować tego rozwoju. (żr.: Dozwolony użytek programów komputerowych ? jak Google pokonał Oracle w USA).

Powyższy tekst wskazuje na dwa ciekawe aspekty oprogramowania, o których dzisiaj napiszę. Pierwszy to tak zwany dozwolony użytek, bardzo często przywoływany w sporach o bezpłatne użycie oprogramowania i zakres tego użycia. Najczęściej dotyczy gier komputerowych ale nie tylko. Drugi to charakter oprogramowania, jakim jest kod źródłowy będący tekstem, oraz efekt ostateczny, jakim jest “komputer realizujący określony mechanizm”, gdzie komputer definiujemy jako “procesor, pamięć i program” . Warto tu zwrócić uwagę na pewien “drobiazg”: autorka (jak wielu innych prawników) traktuje treść programu jako “tekst” i nie raz stosuje analogię do typowych utworów pisanych takich jak proza czy poezja, co jest poważnym błędem. Fragmenty tekstów (esej, praca doktorska, powieść, itp.) bardzo często mają wartość, czego o nie można powiedzieć o oprogramowaniu (nie działa w kawałkach). Owszem, można potraktować fragmenty kodu “literaturowo”, jako przykłady jego struktry i składni (np. literatura na temat wzorców projektowych w inżynierii oprogramowania), jednak nie można mówić o fragmencie kodu, że to “oprogramowanie”, gdyż to z zasady “musi działać”, a jest to możliwe tylko wtedy gdy do komputera załadujemy kompletny program a nie “cytowany fragment”.

Prawo autorskie i dozwolony użytek

Bardzo rzetelny opis dozwolonego użytku podano na stronie Legalna Kultura:

Dozwolony użytek jest formą ograniczenia autorskich praw majątkowych i daje nam możliwość korzystania z chronionego takimi prawami utworu bez konieczności uzyskiwania zgody podmiotu uprawnionego tj. autora czy też np. wydawcy/producenta, który nabył autorskie prawa majątkowe. (źr.: Dozwolony użytek).

Tu autorzy, podobnie jak większość dogmatyków prawników, skupiają się głównie na utworze rozumianym jako “coś co można przeczytać, posłuchać, lub obejrzeć” (a także skopiować czy rozpowszechniać: pola eksploatacji). Kod programu, napisany w dowolnym, określonym języku programowania, niewątpliwie jest tekstem, który jako treść można wykorzystać np. do celów informacyjnych czy edukacyjnych. Problem pojawia się, gdy weźmiemy pod uwagę fakt, że program jako taki jest integralną częścią komputera (patrz wyżej definicja pojęcia komputer), oraz to że właśnie w takim celu – użycie go w komputerze – co do zasady jest tworzony (pisany).

Moim zdaniem, pisanie w umowach, że program komputerowy ma jakieś inne, niż użycie go w komputerze, pola eksploatacji jest wyrazem niezrozumienia istoty tego czym jest oprogramowanie: na pewno nie jest ono czymś “do poczytania”. To, że można go utrwalić jest prawdą, ale samo jego utrwalanie nie jest jego użyciem. Nawet jego powielanie jako treści kodu, nie jest “szkodą” dla autora programu, szkodą będzie dopiero jego użycie w komputerze, bo dopiero wtedy realizuje on określone funkcje.

Szkodliwość samego powielania kodu programu jest taka sama jak szkodliwość powielania projektu architektonicznego domu: problemem jest nie posiadanie kopii projektu, a postawienie kolejnego domu na jego podstawie bez zgody architekta (autora projektu).

Fundamentem Ustawy Prawo autorskie, jest ochrona utworu czyli treści (jest nią tekst, ale także każdy obraz czy zestaw dźwięków). Oprogramowanie, jako kod, zostało tu (Ustawa) także uwzględnione:

Jednak znajdujemy w Ustawie także:

Art. 23. Dozwolony użytek osobisty
1. Bez zezwolenia twórcy wolno nieodpłatnie korzystać z już rozpowszechnionego utworu w zakresie własnego użytku osobistego. Przepis ten nie upoważnia do budowania według cudzego utworu architektonicznego i architektoniczno-urbanistycznego oraz do korzystania z elektronicznych baz danych spełniających cechy utworu, chyba że dotyczy to własnego użytku naukowego niezwiązanego z celem zarobkowym.
2. Zakres własnego użytku osobistego obejmuje korzystanie z pojedynczych egzemplarzy utworów przez krąg osób pozostających w związku osobistym, w szczególności pokrewieństwa, powinowactwa lub stosunku towarzyskiego.
Art. 30(1). Do baz danych spełniających cechy utworu nie stosuje się art. 271 i art. 28.
Art. 35. Dozwolony użytek nie może naruszać normalnego korzystania z utworu lub godzić w słuszne interesy twórcy.
.

Art.23. już nie zawiera wprost pojęcia “program”, ustawodawca “nieśmiało” uznał, że “baza danych” jednak nie jest już zwykłym utworem. Ważnym zapisem jest jednak Art,35.: “nie może godzić w słuszne interesy twórcy”. Pozostaje tylko pokazać co i kiedy “godzi w ten słuszny interes”. Słusznym interesem twórcy są przychody z jego pracy i oznaczenie go jako autora. Pozostaje więc każdorazowo wykazać, że określone działanie (cytowanie, kopiowanie itp.) umniejsza mu, co może nie być proste, a nie raz jest niemożliwe. Co ciekawe cytowanie czy powielanie utworu, z zachowaniem autorskich praw osobistych, może nawet działać na korzyść twórcy np. pokazując jego zdolności. Wystarczy, że osoba powielająca nie czerpie z tego żadnych korzyści a udostępniony utwór nie przynosi korzyści tym, którzy go pozyskali (wielu ludzi nie stać na książki czy gry, więc albo nie przeczytają ich nigdy albo przeczytają za darmo, więc nie jest prawdą, że powodują straty przychodu autora, tak działają np. biblioteki).

Generalnie na świecie toczy się debata na temat pojęcia tantiem jako biernych przychodów i krytyki dochodów bez świadczenia pracy. Jednym z ciekawszych moim zdaniem głosów jest uznanie, że człowiek powinien być wynagradzany za wykonywaną pracę a nie za monopolizowanie jej efektów. Ta idea właśnie przyświeca idei oprogramowania open source: wynagrodzenie dostajemy za godziny spędzone nad jego wdrażaniem i rozwijaniem u jego użytkowników (czyli za świadczoną pracę), a nie za udzieloną licencję, bo ta jest tu bezpłatna.

Komputer jako mechanizm

W literaturze z obszaru filozofii informatyki można często znaleźć opisy określające komputer jako “uniwersalny mechanizm” . Innymi słowy, skoro komputer może realizować rozmaite funkcje, w tym analogiczne do funkcji urządzeń mechanicznych czy elekro-mechanicznych (np. zegar), a integralną częścią komputera, odpowiedzialną za to, jest ‘program’, to mamy prawo uznać, że program (tu) to także element konstrukcji tego urządzenia. A to już czyni program czymś więcej niż tylko “tekstem”.

Nieco ponad rok temu pisałem o mechatronice (Inteligentna pralka czyli czym jest mechatronika). Opisałem wtedy metodę modelowania urządzeń elektromechanicznych wskazując przykłady, gdzie komputer zastąpił element (komponent) elektromechaniczny, jakim jest np. programator pralki. Nowoczesne urządzenia mogą zawierać elementy “sztucznej inteligencji” pozwalające się nawet komunikować urządzeniom między sobą (IoT: ang. Internet of Things czyli Internet Rzeczy), a nie raz są to po prostu elementy realizujące funkcje autonomicznych zachowań (np. włączenie okresowego obrotu bębna, jeżeli pralka nie zostanie otwarta i opróżniona w ciągu godziny od zakończenia cyklu prania, co zapobiega trwałemu wygnieceniu się garderoby).

Poniżej schemat blokowy takiej hipotetycznej pralki.

Kolorem pomarańczowym oznaczono elementy będące komputerem, który komunikuje się z pozostałymi elementami pralki na ogólnych zasadach, czyli z pomocą sygnałów elektrycznych, identycznie jak każde inne elektro-mechaniczne urządzenie. Taki komputer może komunikować się z innymi urządzeniami (sterować nimi) także mechanicznie: wystarczy, że wyposażymy go dodatkowo w sterowane elektrycznie cięgna, zapadki, koła czy popychacze (tak działa zamek sterowanego komputerem zamka i domofonu).

Innymi słowy, z perspektywy całego urządzenia, jakim jest np. pralka, odróżnienie programatora będącego komputerem od programatora będącego mechanicznym układem zegarowym, jest niemożliwe. Co zresztą można zaobserwować w niektórych modelach pralek (i nie tylko): stary mechaniczny programator można zastąpić nowym (komputer), bez potrzeby zmiany konstrukcji reszty, bo wymiary i metody połączenia z resztą pralki zostały zachowane: standard połączenia i współpracy komponentów urządzenia. To połączenie nazywamy ‘interfejsem’. Pod pojęciem ‘interfejs’ należy rozumieć zarówno rozstaw otworów montażowych, jak i sygnały sterujące i komunikaty przesyłane między komponentami.

Interfejs i jego realizacja

Interfejs to bardzo ważne pojęcie nie tylko w inżynierii oprogramowania. Są to generalnie wszelkie “styki” między komponentami urządzeń i urządzeniami. Interfejsem jest ustalona średnica rurki łączącej i mocującej do roweru siodełko. Interfejsem jest wałek z wielowypustem łączący silnik ze sprzęgłem. Interfejsem jest (obecnie uniwersalne) złącze ładowarki smartfona. Interfejsem jest API (Application Programming Interface) czyli udostępniona możliwość korzystania z funkcji innego oprogramowania.

Czym konkretnie jest interfejs? Interfejs jest specyfikacją czyli formą umowy, np. ustalenie wymiarów wałka łączącego silnik i skrzynie biegów. Dzięki temu (umowa) oba te elementy (silnik i sprzęgło) mogą powstać u różnych producentów, a mimo to będą poprawnie współpracowały. Bardzo często interfejsy są powszechnie uznaną umową czyli standardem.

Schematycznie interfejsy pokazujemy jak poniżej (notacja UML to także standard):

Jak czytać ten diagram? Interfejs_B to specyfikacja, czyli opis współpracy (umowa). Komponent A korzysta z możliwości Komponentu B (lub “zmusza” go to jakieś pracy) a robi to za pomocą Interfejsu_B. Interfejs_B to np. ustalone wymiary ww. wałka lub ustalony zestaw poleceń wymienianych między dwoma aplikacjami. Dlatego schemat blokowy wskazujący na to, że chodzi o oprogramowanie, poza użytymi nazwami, nie różni się tego “ogólniejszego” powyżej. Powyższy schemat czytamy:
– Komponent A (może on być czymkolwiek) korzysta z usług opisanych jako Interface_B (opis ten zawiera także oczekiwany efekt),
– Komponent_B to mechanizm, który realizuje usługi opisane (zadeklarowane) jako Interfejs_B (ten komponent to określone urządzenie elektromechaniczne lub oprogramowanie komputera).

Komponent B, jako określone urządzenie lub oprogramowanie (komputer), może mieć także swój opis (dokumentacja techniczna urządzenia, kod źródłowy programu). Generalnie mówimy, że Komponent B to implementacja Interfejsu_B albo że Komponent B realizuje Interfejs_B.

Jeżeli Komponent A to nasz odkurzacz a Komponent B to elektrownia i sieć energetyczna, to Interfejs_B jest specyfikacją gniazdka w ścianie o ustalonej wartości napięcia i prądu oraz rozstawie i wymiarach otworów. Aby skorzystać z zasilania, musimy np. mieć odkurzacz i “wtyczkę” zgodną ze specyfikacją interfejsu. Identycznie to wygląda gdy chcemy połączyć (zintegrować) nasz system CRM z systemem GUS udostępniającym dane podmiotów gospodarczych np. na podstawie numeru NIP (patrz API REGON).

Co do zasady interfejs to publiczna specyfikacja (rzadkie wyjątki, których intencją jest bezpieczeństwo, są jednak wątpliwą metodą ochrony, patrz Zasada Kerckhoffssa).

Podsumowanie czyli co z tego wynika

Z powyższego można wnioskować, że:

1. każdy komponent systemu ma część jawną: opis jak z niego skorzystać czyli interfejs, oraz część będącą realizacją (implementacją): jej opis może być jawny ale chroniony patentem lub prawem autorskim, albo niejawny, chroniony jako know-how,
2. z perspektywy prawa autorskiego chroniona może może być implementacja interfejsu, ale nie sam interfejs jako specyfikacja (prawo autorskie ani patentowe nie chroni ani idei ani samej listy funkcji czegoś),
3. jednak korzystanie, poprzez API, z usług realizowanych przez określony komponent (implementacja) może wymagać licencji (patrz korzystanie pośrednie),
4. nie jest naruszeniem praw autora komponentu (autora jego projektu) samodzielne opracowanie własnej implementacji opublikowanego interfejsu,
5. interfejs jako “umowa”, to także “dokument” o określonej treści, jednak jego rola i ogólność opisu, pozwalają nie traktować go jak utworu (interfejs to idea, wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94).

Najwięcej emocji budzi ostatni punkt, i moim zdaniem na tym osadzona była istota sporu Google vs. Oracle i wygrana Google. Nie znam detali uzasadnienia tego wyroku, ale z opisu “skutków” można wnioskować, że powyższe wyjaśnia to orzeczenie. Moim zdaniem wplatanie w to wątku o dobrowolnym użytku i jego roli rozwojowej, było tu już przysłowiowym kwiatkiem do kożucha, tym bardziej, że co do zasady specyfikacja interfejsu i jego realizacja to dwa odrębne byty (dokumenty), i stawianie tezy, że wykorzystanie opisu interfejsu jest naruszeniem praw do jego implementacji, jest w świetle powyższego nie do obrony.

Moim zdaniem całość tego sporu i podobnych, pozwala zwrócić uwagą na inny ważny aspekt: prawnicy nie powinni sami oceniać przedmiotu praw autorskich, bo np. nie będąc inżynierami, nie mają wiedzy o przedmiocie sporu ani zrozumienia istoty przedmiotu sporu, którym często jest opisany mechanizm, gdzie jego opis, jako utwór w rozumieniu prawa autorskiego, jest wtórny wobec niego samego. To dlatego dobry prawnik, posługuje się opinią biegłego dotyczącą przedmiotu sporu, skupiając sią na prawie. To, że każda dokumentacja techniczna to tekst i schematy blokowe to fakt, jednak utożsamianie ich wyłącznie z “utworem literackim lub graficznym” jest daleko idącym, i bardzo szkodliwym, uproszczeniem, żeby nie powiedzieć, że wręcz właśnie niezrozumieniem istoty treści tych dokumentów i przedmiotu sporu lub przedmiotu umowy.

Bardzo dobrze to zjawisko opisała Pani Mec. Renata W.Lewicka:

Prawnik powinien być aktywnym uczestnikiem planowanego procesu, a biznes powinien oczekiwać zrozumienia procesu, a nie tylko opisania go w sposób jaki prawnik go rozumie. (źr. TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK).

Źródła