Wolne oprogramowanie powstaje jako efekt współpracy wielu różnych osób. Tworzą one swoiste społeczności wokół produktów swojej pracy, często z bogatą strukturą wewnętrzną i rozbudowanymi instytucjami. Funkcją tych społeczności jest organizacja produkcji. Nie polega ona jednak na odgórnym przydzielaniu zadań do wykonania, lecz raczej na ocenie przydatności kodu, który członkowie zdecydowali się wnieść do projektu (por. “Coase’s Penguin…” Benklera). Jak to już dawno zauważył Raymond “właściciele projektu” mają społecznie uznane prawo do decydowania czy i jak zintegrować kod nadsyłany przez rozmaitych członków społeczności z “wersją oficjalną”.
Na poziomie pojedynczego programu, decyzje te dotyczą zwykle fragmentów kodu usuwających błąd lub dodających nową funkcjonalność. Natomiast “właściciele” dużych projektów, takich jak dystrybucje GNU/Linux decydują o włączeniu do nich tysięcy gotowych pakietów. Co istotne, ewentualna odpowiedzialność za wykorzystanie cudzego kodu z naruszeniem prawa dotyka między innymi końcowego użytkownika. Jest to istotnym zagrożeniem swobodnego korzystania z czterech wolności tym bardziej, że ewentualny regres użytkownika do dostawcy oprogramowania ogranicza “immunitet hakerski“, czyli postanowienia wyłączające odpowiedzialność licencjodawcy. Użytkownicy są zatem żywotnie zainteresowani odpowiedzią na pytanie, czy społeczności wolnego oprogramowania są w stanie tworzyć oprogramowanie nie tylko sprawne technicznie, ale również pozbawione wad prawnych.
Dla ułatwienia podzielmy możliwe wady prawne na (1) naruszenia praw autorskich licencjodawców, od których pochodzi integrowany kod oraz (2) naruszenia innych praw, w tym praw osób trzecich, które w jakiś sposób są z takim kodem związane.
Ryzyko wystąpienia wad pierwszego rodzaju można względnie prosto minimalizować. Polega to na integrowaniu tylko kodu dostępnego na uznanych przez FSF i certyfikowanych przez OSI licencjach wolnego oprogramowania. Co prawda, wolne licencje zawierają zwykle postanowienie o ich automatycznym wygaśnięciu w przypadku naruszenia, ale stwierdzają jednocześnie, że końcowy użytkownik uzyskuje licencję bezpośrednio od twórcy oryginału. Wobec tego, korzystanie z wolności przez użytkownika nie jest zagrożone nawet w sytuacji, gdy “właściciel projektu” włączy do swego projektu cudzy kod na wolnej licencji w sposób nie do końca zgodny z jej postanowieniami. Swoją drogą, o taką niezgodność trzeba się zwykle bardzo postarać, bo wymagania stawiane przez wolne licencje nie są wygórowane (chodzi głównie o przekazanie określonych informacji, a czasem dodatkowo o udostępnienie kodu źródłowego na określonej licencji).
Bardziej złożony problem prawny pojawia się przy włączaniu do projektu kodu na licencji niezgodnej z FSD lub OSD. Z uwagi na brak standaryzacji niewolnych licencji, trudno wysuwać jakiś ogólny wniosek na temat związanych z nimi ryzyk prawnych. Może się na przykład okazać, że rozpowszechnianie takiego kodu podlega ograniczeniom, a gdy jest dozwolone to użytkownik może go wykorzystywać jedynie w celu niekomercyjnym. W skrajnym wypadku odpowiedzialność może ponieść zarówno “właściciel projektu”, jak i użytkownik. Na marginesie, jest to tylko dodatkowy argument na rzecz purytańskiego podejścia w tworzeniu wolnego oprogramowania opisanego w poprzednim akapicie.
W praktyce doszło do wykształcenia dość rozbudowanych reguł audytu pakietów, takich jak DFSG lub Fedora Packaging Guidelines. Trzeba przyznać, że nawet niebędący prawnikami hakerzy są wyczuleni na punkcie wolności i niezwykle poważnie traktują te dokumenty (por. np. artykuł na LWN o audycie Fedora Extras, wpis na Ubuntu Daily o własnościowych sterownikach, aktywność list dyskusyjnych takich jak debian-legal). Zgodnie z takimi wytycznymi “niewolne” pakiety są szybko odrzucane lub przynajmniej wyraźnie oznaczane a użytkownik jest informowany o konieczności zapoznania się ze specyficzną licencją. Niekiedy tworzone jest całkowicie odrębne od oficjalnego projektu repozytorium, takie jak np. Livna.
Sposoby minimalizacji zagrożeń opisane powyżej są skuteczne jedynie w sytuacji, gdy integrowany kod pochodzi od osoby uprawnionej. Przechodząc zatem do drugiej grupy zagrożeń trzeba zauważyć, że kod wniesiony do wolnego projektu może naruszać cudze prawa autorskie. W takiej sytuacji, nawet najszersza licencja uzyskana od nieuprawnionego nie jest w stanie uchronić od odpowiedzialności. Autorowi niniejszego felietonu nie jest jednak znany ani jeden przypadek takiego naruszenia. Warto zauważyć, że społeczność hakerska, w której reputacja budowana poprzez jakość własnej pracy odgrywa kluczową rolę ma silnie rozwiniętą normę moralną zakazującą przywłaszczania kodu.
Poza ochroną prawa autorskiego programy mogą podlegać innym prawom bezwzględnym. Na przykład, “właściciel projektu” może dokonać rozpowszechnienia z naruszeniem cudzego znaku towarowego (por. np. artykuł na Linux.com o sposobie wykorzystania logo Firefoksa w Debianie). Z punktu widzenia użytkownika o wiele dalej idące konsekwencje może mieć korzystanie z wolnego programu stanowiącego produkt lub proces opatentowany przez osobę trzecią (por. Groklaw o sprawie Jacobsen v. Katzer oraz informacje na stronie projektu JMRI). Co istotne, ryzyka tego nie jest w stanie zminimalizować rozszerzanie zakresu licencji wolnego oprogramowania na prawa z patentów (por. FSFE o GPLv3), bo postanowienia te nie wiążą osób trzecich.
Na zakończenie warto podkreślić, że regułą w ramach ruchu wolnego oprogramowania jest publikowanie decyzji integracyjnych wraz z uzasadnieniem. Publicznie dostępny jest również kod źródłowy. Oznacza to, że większość informacji potrzebnych do oceny ryzyka prawnego jest łatwo dostępna. Co więcej, informacje te oceniane są nie tylko przez konkretnego użytkownika, ale przez wszystkich Internautów (żywych i nieożywionych). Jak dowodzi niedawna skuteczność polskiej “blogosfery” w tropieniu plagiatów, taki “rozproszony audytor” jest niezwykle efektywny. Oczywiście wszystko zależy od stopnia zorganizowania społeczności danego wolnego projektu oraz nacisku, jaki kładzie się w niej na kwestie prawne. Można zatem postawić tezę, że dobrze zorganizowane i transparentne społeczności wolnego oprogramowania złożone z jednostek o rozwiniętej świadomości prawnej stanowią istotny czynnik minimalizujący wady prawne tego oprogramowania. Producenci oprogramowania własnościowego z definicji nie korzystają z dobrodziejstw takich społeczności. Ceteris paribus oznacza to, że użytkownicy oprogramowania własnościowego ponoszą znacznie większe ryzyko odpowiedzialności prawnej.