11 marca odbywa się na Wydziale Matematyki i Informatyki Uniwersytetu im. Adama Mickiewicza w Poznaniu, Konferencja „PLD Linux Day”, na której miałem wygłosić prezentację na temat „Legalna dystrybucja GNU/Linux”. Niestety, leżę właśnie w łóżku zmożony chorobą, która uniemożliwia mi prezentację czegokolwiek. Serdecznie pozdrawiam uczestników Konferencji i jako próbę zadośćuczynienia prezentuję poniższy referat pod tytułem: „Legalna dystrybucja GNU/Linux”.
Wprowadzenie
Wolne oprogramowanie to takie, które udostępniane jest użytkownikowi w sposób umożliwiający mu korzystanie z czterech wolności sformułowanych przez Stallmana. Chodzi tu o: (1) wolność korzystania z programu w każdym celu, (2) wolność badania jak program działa i dostosowywania go do swych potrzeb, (3) wolność rozpowszechniania egzemplarzy programu, oraz (4) wolność ulepszania programu i publikowania ulepszeń. Prawne aspekty wolnego oprogramowania rozumianego przez pryzmat tych czterech wolności są przedmiotem mojego doktoratu. Podejmę w nim próbę określenia wpływu jaki na ochronę czterech wolności użytkowników w obowiązującym obecnie systemie normatywnym ma fakt istnienia społeczności wolnego oprogramowania, a także postępujący rozwój eGovernment.
Natomiast przedmiotem niniejszego referatu są zagadnienia prawne związane z tworzeniem dystrybucji GNU/Linux. Zawiera on próbę odpowiedzi na pytanie: „Jak stworzyć legalną dystrybucję GNU/Linux?” Istnieje bliski związek pomiędzy tym tematem, a tematem mojego doktoratu. Po pierwsze, dystrybucje GNU/Linux, jak duża część projektów wolnego oprogramowania tworzone są właśnie w ramach „społeczności”. Po drugie, legalność dystrybucji to także ich zgodność z czterema wolnościami użytkowników o tyle, o ile te wolności można wyrazić w formie praw i obowiązków podmiotów związanych z tworzeniem i korzystaniem z dystrybucji. Chciałbym, aby poniższe wywody, a także ewentualna dyskusja utrzymane zostały w kontekście wpływu tworzenia dystrybucji GNU/Linux w ramach społeczności na wolności użytkowników w ich prawnym rozumieniu. Innymi słowy, chciałbym, aby w tle niniejszego referatu przewijało się pytanie na ile obowiązujący system prawny umożliwia tworzenie dystrybucji GNU/Linux tak, aby użytkownicy mogli korzystać ze czterech wolności Stallmana.
Definicje
Przed rozpoczęciem właściwych rozważań konieczne jest uzgodnienie znaczenia podstawowych pojęć. Pojęcia te to „dystrybucja GNU/Linux”, „tworzenie dystrybucji”, oraz „legalna dystrybucja”.
Zgodnie z Wikipedią, dystrybucja GNU/Linux to system operacyjny składający się z jądra Linuksa oraz wybranego dodatkowego oprogramowania (głównie GNU, ewentualnie także z programów własnościowych), dokumentacji, multimediów (fontów, grafik, ikon, itp.). Elementy te dostępne są w postaci kodów źródłowych lub prekompilowane.
Tworzenie dystrybucji GNU/Linux to niewątpliwie złożone i wymagające zadanie. Dla potrzeb niniejszego referatu rozumienie tego pojęcia zostanie zawężone do trzech aspektów: (1) wykorzystanie lub modyfikacja gotowych elementów pochodzących od osób trzecich (np. poprawienie błędów, import zmian dostępnych w wersjach rozwojowych, dodanie własnych funkcji, kompilacja, stworzenie pakietów, prekonfiguracja), (2) stworzenie własnych elementów (np. system zarządzania pakietami, program instalacyjny), (3) rozpowszechnianie (np. fizyczne CD, repozytoria online, zapewnianie wsparcia i innych usług dodatkowych).
Z kolei „legalność” dystrybucji należy tu rozumieć dwojako. Z jednej strony chodzi tu o dystrybucję, której stworzenie nie narusza praw osób trzecich, a także dokonane zostało w ramach własnych obowiązków. Z drugiej strony, legalność oznacza tu poddanie tworzenia dystrybucji regulacji norm prawnych, w odróżnieniu od innych norm (np. etycznych, zwyczaju).
Powyższe definicje narzucają plan referatu. Otóż odpowiedź na pytanie „Jak stworzyć legalną dystrybucję GNU/Linux”, zależeć będzie od odpowiedzi na następujące trzy pytania pomocnicze: (1) Jak legalnie wykorzystywać cudzą twórczość? (2) Jak legalnie organizować pracę wewnątrz społeczności? (3) Jak legalnie rozpowszechniać gotową dystrybucję? Poszukujemy nie tylko działań zgodnych z prawem, ale także prawnych możliwości regulacji tych działań.
Wykorzystanie cudzej twórczości
Rozważając wykorzystanie cudzej twórczości we własnych projektach należy mieć na uwadze przede wszystkim domyślną ochronę prawa własności intelektualnej (lub jak kto woli, praw na dobrach niematerialnych). Pod tym pojęciem w niniejszym referacie rozumiemy prawo autorskie, a w dalszej kolejności prawo patentowe oraz prawo znaków towarowych. Niemniej jednak, zagadnienia związane z ochroną domyślną nie są specyficzne dla tworzenia dystrybucji GNU/Linux. Specyficzne kwestie prawne mogą być natomiast wynikiem postanowień licencji, na warunkach których udostępniane są elementy wybrane do wykorzystania przy tworzeniu dystrybucji. Dlatego też część referatu dotycząca ochrony domyślnej będzie ograniczona do minimum.
Jak wiadomo, prawo autorskie przyznaje wyłączność twórcy programu na zwielokrotnianie, zmiany oraz rozpowszechnianie programu. Oprócz tych praw majątkowych, które wygasają po określony w ustawie czasie, twórca zachowuje także niezbywalne i nieograniczone w czasie prawa osobiste, do autorstwa programu oraz do oznaczenia programu swym nazwiskiem, pseudonimem, albo do udostępnienia go anonimowo. Istotnym uprawnieniem jest także tak zwane prawo zależne, które pozwala twórcy zakazać rozporządzania i korzystania z opracowań, czyli między innymi modyfikacji programu. Na marginesie warto zaznaczyć, że stosowanie przepisów o opracowaniu w stosunku do programów komputerowych jest sporne, tak jak i samo znaczenie pojęcia „opracowanie programu”. Istotny jest jednak fakt, że bez zgody twórcy nie jest co do zasady możliwe wykonywanie żadnego z powyższych uprawnień. Sprawę komplikuje dodatkowo fakt, że programy są bardzo często utworami złożonymi, powstałymi na skutek współpracy wielu osób. Część z tych osób pisze programy w ramach obowiązków wynikających ze stosunku pracy. Prawo autorskie reguluje uprawnienia wszystkich podmiotów zaangażowanych w te procesy, a zwłaszcza współtwórców, twórców utworów wykorzystanych w utworach zbiorowych, a także pracodawców twórców. Oznacza to, że twórcy dystrybucji GNU/Linux muszą liczyć się z istnieniem złożonych stosunków prawnych pomiędzy podmiotami, których dobra niematerialne wykorzystują przy tworzeniu dystrybucji.
Jak wiadomo, większość z ewentualnych zakazów, do których uprawnia prawo autorskie nie istnieje w świecie wolnego oprogramowania. Ich zniesienie następuje poprzez działanie samych uprawnionych, którzy decydują się udostępnić swoje dobra niematerialne na zasadach jednej z kilkudziesięciu modelowych licencji. Jednak uzyskanie programu na licencji przyznającej wszystkie cztery wolności Stallmana, lub jak kto woli zgodnej z Open Source Definition nie oznacza automatycznie kresu prawniczej dyskusji, czego dowodem jest istnienie kolejnych akapitów niniejszego referatu.
Zanim przejdziemy do omawiania licencji, konieczne jest jeszcze skrótowe omówienie prawa patentowego i prawa znaków towarowych. W niniejszym referacie zakładamy, że kwestia patentów na oprogramowanie nie ma istotnego praktycznego znaczenia, a już na pewno nie jest specyficzna dla tworzenia dystrybucji GNU/Linux. Dość powiedzieć, że przyjmując legalistyczne podejście, twórcy dystrybucji powinni orientować się w kwestiach zdolności patentowej programów komputerowych w krajach, w których zamierzają dokonywać jej rozpowszechniania.
Znacznie ciekawszym z punktu widzenia praktyki jest zagadnienie znaków towarowych. Najogólniej rzecz ujmując, rejestracja znaku towarowego w danym kraju daje wyłączne prawo do oznaczania tym znakiem własnych towarów lub usług. Ograniczymy się tu do omówienia dwóch kazusów wykorzystania znaków towarowych w obrocie wolnym oprogramowaniem. Pierwszy z nich dotyczy „znanego północnoamerykańskiego dystrybutora Linuksa”, który swego czasu wystąpił o zaprzestanie używania jego znaku przez pewną społeczność wolnego oprogramowania. Społeczność ta wykorzystywała cztery wolności przyznane im przez licencje wolnego oprogramowania w celu stworzenia własnej darmowej dystrybucji w oparciu o dystrybucję klasy „Enterprise” tegoż dystrybutora. Istota ochrony znaku przejawiła się w tym, że dystrybutor nie mógł zakazać samego klonowania dystrybucji. Mógł jednak domagać się usunięcia jego znaku z dystrybucji, której nie był twórcą tak, aby nie doszło do pomylenia cudzych produktów z jego własnymi.
Drugim kazusem jest sprawa znaku towarowego „LINUX”. Otóż znak ten został zastrzeżony przez samego Linusa Torvaldsa. Licencje na korzystanie z tego znaku udzielane są przez wyznaczony przez niego podmiot, lecz twórcy niekomercyjnych dystrybucji Linuksa mogą spać spokojnie – ponoszenie opłat licencyjnych uzależnione jest od przekroczenia konkretnego progu przychodów. Co ciekawe, ochrona znaków towarowych opiera się na zasadzie terytorialności, a Torvalds zaniedbał rejestracji znaku „LINUX” w Polsce. Jednak znak ten jest tu zarejestrowany, w klasie „działalność w zakresie oprogramowania” na rzecz pewnego wydawnictwa. Autorowi niniejszego referatu nie jest znane stanowisko tego wydawnictwa w zakresie udzielania zezwoleń na korzystanie z tego znaku.
Przejdźmy jednak do zagadnienia licencji wolnego oprogramowania. Zgodnie z definicją, licencje te przyznają każdemu zainteresowanemu cztery wolności oprogramowania. Zdecydowanie najpopularniejsze są dobrze znane czytelnikom GNU GPL, GNU LGPL oraz BSD. Jednak tworząc dystrybucję GNU/Linux należy liczyć się z faktem wykorzystywania oprogramowania na bardziej egzotycznych licencjach. Analizując je należy wziąć pod uwagę zakres obowiązków, jakie łączą one z faktem wykorzystania objętego nimi oprogramowania we własnej twórczości. Niektóre z nich, z pozoru wolne, ograniczają jednak nawet możliwość samej dystrybucji, a nie tylko możliwość modyfikowania oprogramowania. Najbardziej kuriozalnym przypadkiem, z jakim spotkał się autor niniejszego artykułu było życzenie licencjodawcy, aby informować go o wykorzystaniu programu wysyłając mu pocztówkę.
„Poważną” analizę licencji można przeprowadzić w co najmniej trzech aspektach: (1) zakresu klauzuli „copyleft”, (2) zakresu prawa do rozwidleń („the right to fork”), oraz (3) kompatybilności licencji. Zanim jednak przeznaczy się siły i środki na taką analizę, trzeba zwrócić uwagę, że pomijając przypadki skrajne, większość standardowych licencji wolnego oprogramowania nie ogranicza możliwości prostego włączenia programu jako pakietu do dystrybucji. Nawet jeżeli, to w sytuacji standardowej raczej nie doszłoby do naruszenia licencji, gdyż mało który twórca dystrybucji podejmuje próbę zatajenia kodów źródłowych pakietów lub usunięcia informacji o autorze wykorzystywanego oprogramowania.
Pierwszy aspekt, zakres klauzuli „copyleft” odnosi się do obowiązku udostępnienia oprogramowania pozostającego w określonym związku z licencjonowanym oprogramowaniem na warunkach takiej samej licencji. Kwestii tej poświęcony został odrębny artykuł autora niniejszego referatu.
Drugim aspektem jest zakres prawa do rozwidleń. Prawo to stanowi niejako lustrzane odbicie „copyleft”. O ile bowiem „copyleft” ustanawia prawo twórcy oryginału do nowych wersji programu stworzonych przez kogoś innego, to prawo do rozwidleń pozwala każdemu zainteresowanemu stworzyć nową wersję oprogramowania na zasadach wolnego oprogramowania w sytuacji, gdy sam jego twórca zdecydował się nie udostępniać nowych wersji jako wolnych.
Trzecim aspektem z kolei jest kompatybilność licencji. Według Free Software Foundation, kompatybilne licencje pozwalają na łączenie oprogramowania nimi objętego tak, aby stworzyć w ten sposób jeden większy program. Co istotne, najbardziej popularne licencje wolnego oprogramowania są kompatybilne między sobą.
Podsumowując powyższe należy zauważyć, że duża część działalności polegającej na wykorzystaniu cudzych dóbr niematerialnych w tworzeniu dystrybucji GNU/Linux nie jest obarczona istotnym ryzykiem prawnym. Jest tak zwłaszcza w przypadku, gdy dochodzi do wykorzystania cudzych elementów dostępnych na jednej ze standardowych, najpopularniejszych licencji wolnego oprogramowania, bez dokonywania w nich zmian lub innego własnego wkładu twórczego. Mimo to, zawsze pojawią się kwestie graniczne, prawnie niejednoznaczne. Na przykład, wielu twórców wolnego oprogramowania dodaje dodatkowe zastrzeżenia do skądinąd wolnych licencji. Często są to wskazówki interpretacyjne, dotyczące na przykład zakresu klauzuli „copyleft”. Jednak czasami twórcy oprogramowania potrafią podejmować kroki mające na celu ograniczenie możliwości korzystania z czterech wolności pomimo wyraźnego tekstu licencji. Mogą ku temu służyć nie tylko instytucje prawne, ale też środki techniczne (np. ograniczenie dostępu do repozytoriów kodu). Ograniczenia mogą także pochodzić od osób trzecich, uprawnionych z ważnego patentu (czemu należałoby poświęcić odrębne opracowanie) lub dajmy na to, znaku towarowego.
Organizacja pracy wewnątrz społeczności
Próba wyodrębnienia i określenia znaczenia norm prawnych w organizacji pracy jakiejkolwiek społeczności wolnego oprogramowania jest sporym wyzwaniem. Jest tak dlatego, że podstawowym regulatorem w tych społecznościach są normy moralne oraz zwyczaj, zwłaszcza w społecznościach tworzących oprogramowanie niekomercyjne. Nawet jeżeli dla prawnika istnieją w takiej sytuacji wiążące normy prawne, to mówienie o ich praktycznym zastosowaniu mogłoby niekiedy narazić nawet na śmieszność. Można nawet próbować bronić tezy, że próby zastosowania instytucji prawnych w organizacji tworzenia dystrybucji GNU/Linux przyniosą tylko techniczne pogorszenie oprogramowania.
Podejmijmy jednak karkołomną próbę opisania stosunków pomiędzy członkami społeczności wolnego oprogramowania językiem prawnym. Otóż okazuje się, że stosunki prawne istnieją tam nawet w sytuacji, gdy współpraca jest całkowicie nieformalna. Ich podstawowym źródłem będą postanowienia licencji, które wiążą każdego, kto korzysta z objętych nimi uprawnień, a więc także i twórców dystrybucji GNU/Linux. Zatem, w przypadku gdy jeden z deweloperów stworzy, na przykład menedżera pakietów dystrybucji i udostępni go na jednej z wolnych licencji, a inni deweloperzy podejmą się jego rozwijania, to każdy z nich będzie związany licencją w stosunku do autora oryginału, a także pomiędzy sobą. W efekcie powstanie sytuacja określana przez niektórych jako „plecionka” („patchwork”) praw autorskich. Podkreślmy jednak jeszcze raz, że powyższe należy traktować raczej jako temat do ćwiczeń ze studentami prawa i nie warto się spodziewać, aby miało to praktyczne znaczenie w momencie, gdy większość społeczności polega na normach moralnych i zwyczaju. Co innego, gdyby doszło do sporów z osobą trzecią, niepowiązaną ze społecznością, chcącą wykorzystać dystrybucję w sposób sprzeczny z normami pozaprawnymi.
Kolejnym pomysłem na usystematyzowanie stosunków pomiędzy członkami danej nieformalnej społeczności jest uznanie istnienia spółki cywilnej członków takiej społeczności. Jak wiadomo, w prawie polskim, przez umowę spółki wspólnicy zobowiązują się dążyć do osiągnięcia wspólnego celu gospodarczego przez działanie w sposób oznaczony. Nie sposób nie zauważyć, że stworzenie dystrybucji GNU/Linux jest wspólnym celem gospodarczym (choć niekiedy niekomercyjnym), do którego członkowie społeczności zmierzają przez działanie w sposób oznaczony, zgodnie z przedstawioną wyżej definicją „tworzenia dystrybucji”. Znowu jednak praktyczna doniosłość takiej konstatacji jest nikła. W praktyce prowadzi ona bowiem do przyjęcia zasady jednomyślności wspólników, która to zasada i tak funkcjonuje w każdej nieformalnej społeczności. Ponadto, oznacza ona między innymi solidarną odpowiedzialność wspólników za zobowiązania spółki. Jednak możliwość egzekucji tych zobowiązań w sytuacji, gdy głównym majątkiem spółki jest i tak publicznie dostępny kod źródłowy nie ma praktycznego znaczenia. Mimo to, nie można wykluczyć zastosowania przepisów o spółce cywilnej w sytuacji, gdy dojdzie do sporów wewnątrz społeczności, których nie uda się rozwiązać za pomocą norm moralnych i zwyczaju.
Twórcy niektórych dystrybucji oraz innych projektów wolnego oprogramowania decydują się na daleko idące sformalizowanie współpracy. W warunkach prawa polskiego byłoby to możliwe przez zawiązanie stowarzyszenia, fundacji, lub ewentualnie spółdzielni, a być może nawet dążenie do uzyskania statusu organizacji pożytku publicznego dla takiego bytu prawnego. Z każdą alternatywą wiąże się korzystanie z określonych uprawnień, zwłaszcza możliwości władczego wpływania na działanie innych osób. Jednak po tych prawach następują też obowiązki. Pobieżna analiza przepisów, a także wymiany zdań na listach dyskusyjnych PLD prowadzi autora niniejszego referatu do wniosku, że formalizacja prawna współpracy przy tworzeniu dystrybucji w sytuacji, gdy członkowie społeczności poddani są silnemu działaniu norm pozaprawnych przyniosłaby więcej szkody niż pożytku. Intuicja socjologiczna oraz teoria kosztów transakcyjnych w wydaniu Coase podpowiada, że miałoby to sens w sytuacji, gdy liczba uczestników projektu jest na tyle wysoka, że bezpośrednie relacje pomiędzy nimi są utrudnione lub kosztowne. Ponadto, powołanie bytu prawnego o odrębnej osobowości prawnej w stosunku do członków społeczności przydałoby się głównie w celu reprezentowania tej społeczności na zewnątrz. Na przykład wtedy, gdyby istniała realna szansa wykorzystania uprawnień przyznawanych przez przepisy o organizacjach pożytku publicznego. Na pewno jednak, zależność pomiędzy stopniem formalizacji współpracy a jakością produkowanego oprogramowania jest trudna do udowodnienia.
Warto przy tej okazji omówić jeden z najbardziej sformalizowanych niekomercyjnych projektów wolnego oprogramowania, jakim jest Debian. Podmiotem prawnym stojącym za tą dystrybucją jest niedziałająca dla zysku organizacja „Software in the Public Interest, Inc.”, której praktycznie doniosłą funkcją jest przyjmowanie darowizn różnego rodzaju z przeznaczeniem na rozwój, między innymi, Debiana. Sam „Debian” jest zarejestrowanym znakiem towarowym tej organizacji. Jednak według wiedzy autora tego referatu, członkostwo w SPI lub jakiekolwiek inne z nią powiązanie nie jest konieczne, aby dołączyć się do współpracy nad Debianem. Sam proces inicjacji „hakera” Debiana jest jednak dość sformalizowany i został wyczerpująco opisany przez Coleman. Istnieje także wyczerpujący Statut Debiana („The Constitution of Debian”) ustalający hierarchię, prawa i obowiązki uczestników. Wydaje się, że egzekwowanie jego postanowień nie jest jednak dokonywane za pomocą norm prawnych, stanowi on raczej spisanie pozaprawnych norm narzuconych przez deweloperów samym sobie. Lektura „Umowy Społecznej Debiana”, zawierającej „zobowiązania” społeczności na zewnątrz, oraz zawartej w niej „Debian Free Software Guidelines” prowadzi do wniosku, że celem tej regulacji było zapewnienie wolności tworzonego oprogramowania w długim okresie. Za zagrożenia tej wolności uznano zarówno pewne uregulowane działania deweloperów, jak też i osób trzecich, a zwłaszcza udostępniających oprogramowanie do ewentualnego włączenia do dystrybucji.
Być może to właśnie pytanie o istnienie realnego zagrożenia wolności użytkowników powinni zadać sobie wszyscy zastanawiający się nad formalizacją pracy nad projektem. Jeżeli wolność ta nie jest zagrożona, w szczególności, gdy prawo do rozwidlenia projektu może być faktycznie wykonane w każdym czasie, powoływanie formalnych struktur byłoby zapewne nieporozumieniem. Warto jednak rozważyć zasadność ustanowienia odpowiednika „Debian Policy Manual”, dokumentu o charakterze przede wszystkim technicznym, regulującego głównie zasady współpracy przy tworzeniu pakietów. Kończąc temat Debiana warto podkreślić, że „Free Software Guidelines” to pierwowzór „Open Source Definition”. Służy ona weryfikacji wolności oprogramowania włączanego do Debiana, a interpretacja jej postanowień generuje spory ruch na liście dyskusyjnej debian-legal. Lista ta jest zresztą fenomenem samym w sobie, co jednak można pozostawić na odrębne opracowanie.
Rozpowszechnianie dystrybucji
Gotowa dystrybucja GNU/Linux może być uważana za przedmiot prawa sama w sobie. Będzie ona zapewne utworem zbiorowym, do którego prawa autorskie przysługują producentowi lub wydawcy, z zachowaniem jednak praw twórców części mających samodzielne znaczenie. Wobec tego, warto się zastanowić, kto mógłby być takim producentem w sytuacji gdy tworzenie dystrybucji jest niesformalizowane. O ile jednak współpraca nad dystrybucją jest w wystarczający sposób regulowana normami pozaprawnymi, a jej twórcy nie mają ambicji wchodzenia w złożone stosunki prawne z podmiotami, których działalność musi podlegać sformalizowanym procedurom, rozważania te można w zupełności pominąć. Po prostu nigdy w praktyce nie dojdzie do konieczności zastosowania prawnoautorskiej instytucji utworu zbiorowego lub jej podobnych.
Niekiedy wydaje się, że członków społeczności nie interesuje nawet egzekwowanie naruszeń licencji tworzonego przez nich oprogramowania przez osoby trzecie, gdyż nie dążą oni do komercjalizacji własnej pracy samodzielnie, lub też uważają, że i tak zachowane są ich wolności. Taka sytuacja niesie jednak za sobą konkretne ryzyko prawne. Można sobie bowiem wyobrazić zastosowanie przez osobę trzecią prawnych lub technicznych ograniczeń w celu wykluczenia społeczności, lub konkretnych deweloperów od udziału w tworzeniu dystrybucji, z jednoczesnym utrudnieniem stworzenia rozwidlenia projektu. Ryzyko to należy jednak ocenić jako niskie, gdyż taki „gapowicz” w oczywisty sposób podcinałby gałąź, na której sam siedzi.
Niemniej jednak, rozpowszechnianie dystrybucji wiąże się z wchodzeniem w konkretne stosunki prawne, co daje prawnikowi możliwość ich analizowania nawet, gdy w praktyce nigdy nie dojdzie do sporów w tym zakresie. Można tu wskazać stosunki łączące społeczność na przykład z host-providerem. Znacznie bardziej istotne będą stosunki konkretnych członków społeczności z podmiotami, dla których oferują oni wdrożenie dystrybucji na podstawie indywidualnych umów o dostawę oprogramowania. Oprócz licencji na części składowe, sytuację taką można próbować regulować opracowując licencję na całość dystrybucji. Pojawia się tu pytanie, w jakim stopniu taka licencja mogłaby ograniczać wolności użytkowników, zwłaszcza gdy określone uprawnienia powiązano by ze statusem (jakkolwiek zdefiniowanego) członka społeczności. Prawo dostarcza tu różnych narzędzi do eksperymentowania.
Wnioski i zaproszenie do dyskusji
Powyższa pobieżna analiza pozwala na sformułowanie odpowiedzi na pytanie zadane na początku, które brzmiało: „Jak stworzyć legalną dystrybucję GNU/Linux?”. Odpowiedź brzmi, że istnieje wiele legalnych sposobów ku temu celu. Chodzi tu zarówno o możliwość legalnego wykorzystania cudzej twórczości, jak i poddanie organizacji pracy członków społeczności normom prawnym. Jednocześnie ustaliliśmy, że nie należy przeceniać znaczenia tych norm w regulacji społeczności tworzących dystrybucje. Istnienie PLD wydaje się potwierdzeniem tezy, że możliwe jest stworzenie dystrybucji bez konieczności egzekwowania prawnych praw i obowiązków, a przez oparcie się jedynie na autorytecie norm moralnych i zwyczaju. Wręcz, autor niniejszego referatu chciałby przedstawić obrazoburcze stanowisko, że normą organizującą wiele odnoszących sukcesy projektów wolnego oprogramowania jest „polska norma”, która brzmi: „Musi to na Rusi, a w Polsce jak kto chce!”
Zapraszam do dyskusji, której celem chciałbym uczynić pogłębienie kwestii poruszonych w niniejszym referacie.