Profesorowie J. Barta i R. Markiewicz opublikowali w Rzeczpospolitej (14 XII 2006, C4) artykuł pod tytułem: “Od ‘wolnego’ oprogramowania do ‘wolnych utworów’”. Artykuł zawiera bardzo ciekawe postulaty de lege ferenda w odniesieniu do Creative Commons, private levies i organizacji zbiorowego zarządzania. Poniżej chciałbym jednak zreferować i odnieść się do tej części artykułu, który poświęcony jest wolnemu oprogramowaniu.

Autorzy pokrótce definiują prawną istotę wolnego oprogramowania, a następnie zwracają uwagę na ustalone przez nich zastrzeżenia prawne wobec licencji wolnego oprogramowania. Co istotne, jako cechę definiującą wolne oprogramowanie uznają oni zapewnienie użytkownikom “czterech swobód”, a nie nieodpłatność licencji, jak to się często mylnie przyjmuje. Na marginesie, uważny czytelnik zauważy drobne różnice pomiędzy “czterema swobodami” określonymi w artykule, a “czterema wolnościami” zdefiniowanymi przez Stallmana. Otóż jako jedną z wolności autorzy wskazują “dostęp do kodu źródłowego“, który według Stallmana jest jedynie warunkiem istnienia wolności nr 1 i 3. Powyższa omyłka nie jest jednak szczególnie istotna dla poprawności wnioskowania przedstawionego w dalszej części artykułu.

Pewną dodatkową nieścisłością jest stwierdzenie, że “użytkownik … zobowiązany jest do dalszego udostępniania własnych modyfikacji [wolnego] programu“. Warto wyjaśnić i podkreślić, że zobowiązanie to nie dotyczy wszystkich użytkowników wolnego oprogramowania. Istnieje bowiem pokaźny jego zasób dostępny na licencjach typu BSD, które nie wymagają udostępniania własnych modyfikacji. Jeżeli natomiast istotnie licencja ustanawia takie zobowiązanie, to nie jest ono bezwarunkowe. Na przykład, GPLv2 wymaga takiego udostępniania jedynie w przypadku rozpowszechniania programu (”[whenever you] distribute or publish“). Innymi słowy, modyfikacje dokonywane dla własnych potrzeb (np. wewnątrz przedsiębiorstwa) użytkownika nie muszą być nikomu udostępniane, nawet gdy oryginał objęty jest GPL.

Mając powyższe na uwadze, można przejść do analizy istoty wywodów Profesorów Barty i Markiewicza w odniesieniu do wolnego oprogramowania. Autorzy zwracają uwagę na postanowienia modelowych licencji wolnego oprogramowania, które ich zdaniem budzą zastrzeżenia prawne. Są to:

1. nieodwołalne poddanie programu reżimowi open source (sic!)
2. obowiązek dystrybuowania w ramach tego systemu także programów adaptowanych przez użytkownika
3. pełne wyłączenie odpowiedzialności udostępniającego program za jego wady

Odnosząc się do pierwszego zastrzeżenia warto zwrócić uwagę, że wolne oprogramowanie pozostaje wolne (zamiast “reżim open source” proponuję konsekwentne stosowanie jednolitej terminologii) dzięki dwóm instytucjom mającym umocowanie w postanowieniach licencji. Są to: (1) “right to fork” i (2) “copyleft” (ta druga nie występuje we wszystkich występuje w tylko niektórych wolnych licencjach). Oczywiście obie z nich istnieją tylko wtedy, gdy licencja jest wiążąca. Ponieważ jednak licencje wolnego oprogramowania są udzielane na czas nieokreślony, możliwe jest ich wypowiedzenie, a tym samym pozbawienie użytkowników praw wynikających z tych instytucji. Z praktycznego punktu widzenia nie stanowi to jednak istotnego zagrożenia.

Jest tak przede wszystkim dlatego, że według mojej wiedzy żaden z licencjodawców wolnego oprogramowania nie wypowiedział jeszcze raz udzielonej licencji. Jeżeli nawet licencjodawca wypowiedziałby licencję, to byłby zmuszony do wykonania syzyfowej pracy ścigania wszystkich dotychczasowych licencjobiorców poprzednich wersji programu w celu doręczenia im wypowiedzenia (dyskusyjne jest, czy wystarczyłaby ogólna deklaracja umieszczona na dotychczasowej stronie projektu). Znacznie prościej jest wobec tego nie wypowiadać licencji, a jedynie zamknąć kolejną - nowszą i ulepszoną - wersję programu. Ma to o wiele większy sens z ekonomicznego punktu widzenia, gdyż popyt na nowszy i lepszy program wyprze istotną część popytu na program starszy. Poza taką “ucieczką przez atak”, zdarza się niekiedy, że licencjodawca po prostu porzuca zapoczątkowany przez siebie wolny projekt. Teoretycznie, to również oznacza koniec wolności programu. Jednak w obu przypadkach społeczność skupiona wokół danego projektu zwykle kontynuuje jego rozwój, korzystając z przywołanego wyżej prawa do rozwidlania. Innymi słowy, pierwsze zastrzeżenie Profesorów Barty i Markiewicza abstrahuje od całości uwarunkowań produkcji wolnego oprogramowania, które ja określam jako “System normatywny społeczności wolnego oprogramowania.”

Na marginesie, zamknięcie dotychczas wolnego projektu nie jest wcale łatwym zadaniem. W tym celu trzeba bowiem wyczyścić jego kod z wkładów dotychczasowych członków społeczności tak, aby samemu nie naruszyć wolnych licencji do opracowań własnego programu (zjawisko “plecionki praw autorskich” (”patchwork of copyrights”)). Z tego punktu widzenia o wiele bardziej skutecznym sposobem na “zniewolenie” programu jest powiązanie go z jakąś własnościową usługą lub sprzętem. Taką strategię, według Stallmana, realizują z powodzeniem producenci urządzeń typu TiVo.

Drugie zastrzeżenie Profesorów Barty i Markiewicza jest częściowo związane z pierwszym. Mowa tu bowiem o ważności klauzul “copyleft”, które autorzy określają jako “obowiązek dystrybuowania w ramach [systemu wolnego oprogramowania] także programów adaptowanych przez użytkownika“. Warto jeszcze raz podkreślić, że obowiązek wynikający z tych klauzul występuje tylko w przypadku dokonania rozpowszechnienia “programów adaptowanych“. Ponadto, zakres tego obowiązku jest ograniczony przedmiotowo. Ogólnie rzecz biorąc dotyczy to “opracowań” (”utworów zależnych”) wolnych programów. Wobec tego, wszelkie zastrzeżenia co do tego obowiązku są w istocie zastrzeżeniami do instytucji praw zależnych. Na gruncie polskiego prawa autorskiego sprawa jest nieco bardziej skomplikowana, gdyż nie jest jasne, czy do programów stosuje się przepisy o opracowaniu. Znane są natomiast próby kwestionowania “copyleft”, ale z pozycji prawa antymonopolowego, czego przykładem są sprawa Wallace v. FSF lub ostatnie orzeczenie wydane na rzecz Welte (PDF). Próby te jednak nie spotkały się z uznaniem sądów, które odrzucały tego typu roszczenia. Z analizy powyższego wynika w największym skrócie, że drugie zastrzeżenie Profesorów Barty i Markiewicza w praktyce sprowadza się nie do ważności, ale raczej do zakresu “copyleft”. Zakres ten starałem się swego czasu określić w “Zakresie klauzuli ‘copyleft’ w prawie polskim“.

Ostatnie, trzecie zastrzeżenie dotyczy pełnego wyłączenia odpowiedzialności licencjodawcy za wady programu, zwane przeze mnie “immunitetem hakerskim“. Trudno jednak uznać, że zastrzeżenie to dotyczy w jakiś szczególny sposób wolnego oprogramowania. Klauzule usiłujące całkowicie lub istotnie wyłączyć odpowiedzialność licencjodawcy znajdują się bowiem we wszystkich umowach licencyjnych, nie tylko wolnych, a też i być może przede wszystkim w licencjach oprogramowania własnościowego. Z praktycznego punktu widzenia, w przypadku poniesienia szkody, sytuacja użytkownika tego ostatniego oprogramowania jest gorsza niż sytuacja użytkownika cieszącego się czterema wolnościami. Jest tak dlatego, że nie ma on dostępu ani praw do kodów źródłowych oprogramowania, przez co jest on zdany na łaskę i niełaskę licencjodawcy w zakresie ewentualnych prób mitygowania szkody (np. poprzez zidentyfikowanie błędu i odtworzenie danych). Ponadto, powszechna dostępność wolnego oprogramowania powoduje, że jego dostawcy zmuszeni są konkurować między sobą, a przejawia się to między innymi w poszerzaniu oferty o usługi serwisowe i gwarancyjne. Możliwość takiej konkurencji na rynku usług dotyczących danego programu własnościowego jest natomiast wyłącznie kontrolowana przez jego producenta. Innymi słowy, w praktyce, użytkownicy wolnego oprogramowania chronieni są przed szkodami nie przez prawo, a przez faktyczne uwarunkowania produkcji i obrotu tym oprogramowaniem.

Niemniej jednak, na gruncie teoretycznym można sobie wyobrazić skuteczne pozwanie dewelopera wolnego oprogramowania o odszkodowanie. Zwykle jednak użytkownik nie uzyskuje programu bezpośrednio od dewelopera, a raczej w formie binarnego pakietu dostarczonego przez konkretnego dostawcę. Pozwala to poddać w wątpliwość bierną legitymację dewelopera w takim procesie. Ponadto, zakładając odpowiedzialność dewelopera np. na zasadzie regresu od dostawcy trzeba też wziąć pod uwagę ewentualne przyczynienie się poszkodowanego dostawcy - przez dokonanie takiego, a nie innego wdrożenia wolnego programu. Z kolei użytkownikowi trudno byłoby powoływać się na rękojmię o ile nie dołożył on należytej staranności poprzez audyt kodu źródłowego. Dostęp do tego kodu pozwala zakładać, że użytkownik powinien wiedzieć o wadach w chwili zawierania umowy, co zwykle wyłącza odpowiedzialność drugiej strony. Oczywiście mowa tu o stosunkach profesjonalnych. Ustawodawstwo konsumenckie może modyfikować tę zasadę w konkretnych jurysdykcjach.

Podsumowując, zastrzeżenia Profesorów Barty i Markiewicza bazują na teoretycznej i formalnej analizie postanowień niektórych licencji wolnego oprogramowania. Z takiego właśnie - teoretycznego i formalnego - punktu widzenia są one zasadne. Innymi słowy, w konkretnej sprawie może dojść do sytuacji, w której uprzednio wolny program zostanie na powrót “zniewolony”. (Jako podstawę wskazałbym jednak nie tyle prawo, co “kod” oraz “tivoizację”). Ponadto, poza sytuacją ewidentnego opracowania lub modyfikacji programu na licencji “copyleft” istnieje “szara strefa” zgodności z takimi licencjami (np. binarne moduły jądra). Wreszcie, w sytuacji gdy dochodzi do obrotu wolnym oprogramowaniem w sposób podobny do dystrybucji oprogramowania własnościowego (tzn. w relacji producent-konsument) zasadne jest rozważanie kwestii odpowiedzialności licencjodawcy i niemożliwości jej wyłączenia.