Krzysztof Siewicz
Zarys systemu normatywnego społeczności
wolnego oprogramowania
Poprawiona i uzupełniona wersja artykułu ukazała się w: Re: internet – Społeczne aspekty medium. Polskie konteksty i interpretacje, red. Ł. Jonak, P. Mazurek, M. Olcoń, A. Przybylska, A. Tarkowski, J. M. Zając, Wydawnictwa Akademickie i Profesjonalne, Warszawa 2006.
Artykuł jest także dostępny na stronie internetowej autora.
Publikacja za zgodą autora.
1. Streszczenie
Niniejszy artykuł zawiera propozycję systemu normatywnego społeczności wolnego oprogramowania. System składa się z norm regulujących organizację produkcji oprogramowania oraz relacji pomiędzy nimi. Jest on przedstawiony jako odpowiedź na potrzebę zorganizowania procesu naprawiania błędów („bugs”), wprowadzania ulepszeń oraz zapewniania interoperacyjnosci oprogramowania. Potrzeba ta jest wynikiem technicznych oraz ekonomicznych uwarunkowań, w których dochodzi do produkcji oprogramowania.
System obejmuje normy wynikające z trzech źródeł: (1) normy prywatne; (2) normy społeczności i (3) normy publiczne. Do zarysu systemu, będącego przedmiotem artykułu, zostały włączone jedynie najważniejsze normy odnoszące się do projektów rozwijanych w społecznościach o hierarchicznej i dość sformalizowanej strukturze. Rozważania na temat wszystkich społeczności wolnego oprogramowania wykraczają poza zakres niniejszego artykułu i wymagają szerszego opracowania.
Przedstawione wywody prowadzą do wniosku, że opisany system normatywny organizuje produkcję wolnego oprogramowania w ramach społeczności. Społeczność nadzoruje wysiłki jednostek nakierowane na poprawianie błędów, wprowadzanie nowych funkcji oraz zapewnianie interoperacyjności, jednak nie jest uprawniona do narzucania komukolwiek decyzji produkcyjnych. W sensie ekonomicznym, system pozwala na utrzymanie wolnej konkurencji na rynku oprogramowania. Można ponadto stwierdzić, że niniejsze funkcje systemu są efektem relacji pomiędzy normami wywodzącymi się z różnych źródeł. Istotne znaczenie dla istnienia oraz ostatecznego efektu systemu mają normy publiczne.
Artykuł kończy się wskazaniem kierunków dalszych badań, które powinny objąć: (1) identyfikację wszystkich norm regulujących używanie i rozwój wolnego oprogramowania; (2) pełne zrozumienie wzajemnych relacji pomiędzy normami, ze szczególnym uwzględnieniem norm publicznych.
2. Wprowadzenie
Celem niniejszego artykułu jest zaproponowanie systemu normatywnego regulującego społeczność wolnego oprogramowania. W tym celu konieczna jest odpowiedź na dwa pytania: (1) jakie normy regulują używanie oraz rozwój wolnego oprogramowania, oraz (2) jakie są relacje pomiędzy tymi normami? W celu znalezienia odpowiedzi na te pytania, konieczne jest zdefiniowanie „wolnego oprogramowania” oraz jego „społeczności” z normatywnego punktu widzenia. Następnie, przedstawione zostaną techniczne i ekonomiczne uwarunkowania produkcji oprogramowania, które uznano w niniejszym artykule za istotną przyczynę istnienia systemu normatywnego, a także za istotne czynniki wpływające na jego strukturę. Dalej, nastąpi zdefiniowanie systemu oraz wyróżnienie trzech źródeł norm, które się na niego składają. Źródła te zostaną poddane analizie w celu opisania wynikających z nich norm. Następnie podjęta zostanie próba opisania relacji pomiędzy tymi normami oraz określenia ich wyraźnych ról w kształtowaniu regulujących funkcji systemu normatywnego.
2.1. Wolne oprogramowanie
Wolne oprogramowanie to programy, które są publicznie dostępne w formie zrozumiałych dla człowieka kodów źródłowych, na licencji zezwalającej na kopiowanie, modyfikacje oraz rozpowszechnianie zarówno oryginału, jak i modyfikacji. Niniejsza definicja jest zgodna zarówno z Free Software Definition (dalej „FSD”) [1], jak i z Open Source Definition (dalej „OSD”) [2]. Dla potrzeb niniejszego artykułu zakładamy, że nie ma istotnych normatywnych różnic pomiędzy oprogramowaniem określanym jako „Free” a „Open Source” [3].
2.2. Społeczności wolnego oprogramowania
W niniejszym artykule „społeczność” oznacza grupę podmiotów korzystających lub rozwijających projekt wolnego oprogramowania [4]. Istnieje wiele zróżnicowanych projektów [5]. Formułowanie wniosków odnoszących się do nich wszystkich wykracza poza ramy niniejszego artykułu. Dlatego też brane tu będą pod uwagę tylko projekty rozwijane w ramach społeczności o hierarchicznej i dość sformalizowanej strukturze [6]. Jednak należy pamiętać, że istnieją także inne projekty, których analiza oraz wnioski tu prezentowane mogą nie dotyczyć [7].
2.3. Uwarunkowania techniczne
Wszelkie modyfikacje programu wymagają dostępu do zrozumiałych dla człowieka kodów źródłowych, podczas gdy czytelne dla maszyn kody wynikowe wystarczają, aby z oprogramowania korzystać. Powszechnie wiadomo, że każde oprogramowanie zawiera błędy („bugs”) i jednocześnie nie dysponuje wszystkimi oczekiwanymi funkcjami. Ponadto, oprogramowanie zwykle musi współpracować z innymi elementami w danym systemie informatycznym. Oznacza to, że w zasadzie każde oprogramowanie podlega ciągłej modyfikacji w celu naprawiania błędów, wprowadzania nowych funkcji oraz zapewniania interoperacyjności. W celu kontroli jakości tego procesu konieczny jest odpowiedni podział praw dostępu do kodów źródłowych pomiędzy rozmaite podmioty korzystające oraz rozwijające oprogramowanie.
2.4. Uwarunkowania ekonomiczne
W sensie ekonomicznym, powyższe uwarunkowania techniczne tworzą rynek usług usuwania błędów, wprowadzania nowych funkcji oraz zapewniania interoperacyjności oprogramowania. Rynek ten jest areną zażartej walki konkurencyjnej, ale też jest podatny na zawłaszczenie („proprietary lock-in”) i monopolizację [8]. Struktura oraz konkurencyjność tego rynku zależy od podziału praw dostępu do kodów źródłowych oraz wynikowych oprogramowania. Oznacza to, że produkcja oprogramowania jest organizowana nie tylko z myślą o uwarunkowaniach technicznych, lecz mają na nią wpływ także strategie marketingowe rozmaitych podmiotów aktywnych na tym rynku.
Uznanie istnienia wyżej opisanego rynku pozwala wytłumaczyć istnienie formalnych i hierarchicznych społeczności wolnego oprogramowania za pomocą teorii kosztów transakcyjnych. Chodzi tu zwłaszcza o ujęcie tej teorii zaproponowane przez Coase, który tłumaczy pojawianie się hierarchicznych struktur organizowanych za pomocą władczego oddziaływania istnieniem kosztów transakcyjnych, które w określonych przypadkach czynią nieopłacalnym organizację współpracy na zasadzie równorzędności partnerów [9].
2.5. System normatywny społeczności wolnego oprogramowania
System normatywny społeczności wolnego oprogramowania składa się z norm regulujących organizację produkcji wolnego oprogramowania oraz relacji pomiędzy tymi normami [10]. Celem systemu jest zorganizowanie procesu naprawiania błędów, wprowadzania nowych funkcji oraz zapewniania interoperacyjności oprogramowania. Zawiera on normy określające kto może używać oraz rozwijać oprogramowanie. Normy te mają trzy źródła: (1) normy prywatne, (2) normy społeczności oraz (3) normy publiczne. Normy prywatne to nakazy i zakazy powstałe na skutek korzystania przez jednostki z wolności w dysponowaniu własnymi prawami oraz swobodzie umów. Normy społeczności to przede wszystkim normy pozaprawne, wywodzące się ze zwyczaju lub etyki, powstałe ewolucyjnie w trakcie współpracy nad rozwojem wolnego oprogramowania. Normy publiczne są nakładane na jednostki i społeczności z zewnątrz, w szczególności przez prawo, lecz także przez inne środki regulacji [11].
3. Normy prywatne
Poniżej przedstawiona została analiza licencji wolnego oprogramowania oraz innych instytucji prawnych funkcjonujących pomiędzy poszczególnymi jednostkami, w celu wyodrębnienia norm prywatnych.
3.1. Status prawny licencji i ich znaczenie społeczno-ekonomiczne
Licencje wolnego oprogramowania są podstawą systemu normatywnego i same w sobie stanowią fenomen społeczny. Są to „licencje modelowe”, gdyż poszczególne projekty rzadko udostępniane są na licencji innej niż jedna z już istniejących i zaaprobowanych licencji wolnego oprogramowania. Zatem, nie są to tylko prywatne dokumenty prawne [12], lecz mogą być porównywane z instytucjami o szerszym społecznym oddziaływaniu, jak statuty, wzorce umowne, umowy lub ustawy modelowe, czy nawet konwencje międzynarodowe.
Ich praktyczne znaczenie przejawia się w tym, że ponieważ GNU General Public License („GPL”) lub inne popularne licencje obejmują dużą liczbę projektów, wszelkie spory w ramach jednego z nich mogą wpłynąć na prawa i obowiązki podmiotów zewnętrznych związanych taką samą licencją [13]. Taki wpływ to nie tylko efekt orzecznictwa sądowego [14], lecz znacznie częściej przyjmowania przez podmioty zewnętrzne określonej praktyki i interpretacji wypracowanej w ramach danego projektu w chwili wyboru takiej samej licencji [15].
Każda licencja wolnego oprogramowania przyznaje użytkownikowi cztery wolności wskazane w FSD: (1) do uruchamiania programu, (2) do studiowania i przystosowywania go, (3) do rozpowszechniania kopii i (4) do ulepszania oraz publikowania ulepszeń. Ściśle rzecz ujmując, uprawnienia tworzone inter partes nie mogą być nazwane „wolnościami”, ponieważ są nimi tylko określone normy wynikające z prawa powszechnego i skuteczne erga omnes. Jednakże, z uwagi na „paragraf 22” licencji na oprogramowanie, w praktyce wywołują one skutki podobne do praw erga omnes. Mianowicie, podejmowanie wszelkich działań objętych licencją bez zgody licencjodawcy jest wyraźnie zabronione przez prawo. Zgoda ta jest udzielana właśnie w niepodlegającej negocjacji licencji, której zaakceptowanie jest w zasadzie tak nieuchronne, jak przestrzegania prawa powszechnego. Ten paradoks pozwala na skuteczną zmianę domyślnego stanu prawnego przez czynności normalnie skuteczne jedynie inter partes i sprawienie, że działają one tak jak normy erga omnes.
Przyznanie czterech wolności ma poważne konsekwencje dla relacji pomiędzy członkami społeczności oraz rozwoju oprogramowania. Prawa licencjobiorców zostają co do zasady zrównane z prawami deweloperów, co pozwala im aktywnie uczestniczyć w produkcji oprogramowania, a nie tylko pasywnie konsumować końcowy produkt. Może to być rozumiane jako zwiększenie uczestnictwa widowni w tworzeniu przedmiotów kultury lub, w sensie ekonomicznym, jako niskie bariery wejścia na rynek.
3.2. Copyleft
GPL i niektóre inne licencje [16] zawierają mechanizm prawny zaprojektowany w celu ochrony przyznanych praw i zapobieżenia następczej prywatyzacji oprogramowania pierwotnie udostępnionego jako wolne („copyleft”). Mechanizm ten wymaga od licencjodawcy przestrzegania czterech wolności innych użytkowników i przyczynia się do rozpowszechniania ideologii wolnego oprogramowania. Czyni to te licencje narzędziem „indoktrynacji”, w odróżnieniu od licencji pozbawionych klauzuli „copyleft” (typu BSD) [17], które przyznają użytkownikom wolności bez ambicji wpływania na ich dalsze zachowanie.
Zdaniem Stallmana, gwarancja „copyleft” dla wolności przyznanych licencją czyni je prawami niezbywalnymi [18]. To zabezpieczenie przez zawłaszczeniem i wykorzystaniem ich pracy przez „gapowiczów”, stanowi dla niektórych argument przeciwko licencjom typu BSD, które takiego zabezpieczenia nie zawierają. Jednakże faktyczne konsekwencje „copyleft” nie są do końca jasne, gdyż istnieją odnoszące sukcesy projekty rozpowszechniane na licencji „non-copyleft”. Wobec tego, nie ma bezpośredniego związku pomiędzy „copyleft” a tworzeniem zachęt do uczestniczenia w projekcie [19].
3.3. Kompatybilność licencji oraz podwójne licencjonowanie
Licencje są kompatybilne ze sobą, jeżeli zezwalają na łączenie objętego nimi oprogramowania [20]. Ponieważ niekompatybilność licencji ogranicza liczbę elementów, z których można korzystać przy pisaniu oprogramowania, niektórzy deweloperzy decydują się na podwójne licencjonowanie, czyli określenie kilku modelowych licencji, spośród których użytkownik może wybrać. Ma to oczywisty wpływ na gęstość relacji pomiędzy projektami i deweloperami. Niektóre formy podwójnego licencjonowania pozwalają na łatwiejsze łączenie z oprogramowaniem własnościowym, co może być rozumiane jako poświęcenie części ideałów i wolności, na rzecz efektywności i biznesu.
3.4. Immunitet hakerski
Poza szerokim zakresem udzielanych uprawnień, licencje zawierają zwykle wyłączenia rękojmi oraz ograniczenia odpowiedzialności. Ich celem jest uchronienie deweloperów przed negatywnymi konsekwencjami uczestniczenia w społeczności wolnego oprogramowania, co mogłoby stanowić poważny demotywator dla ochotników. Zazwyczaj, klauzule te są uzasadniane techniczną niemożliwością stworzenia bezbłędnego oprogramowania, wobec czego deweloperzy zmuszeni są do „ubezpieczenia” się przeciwko odpowiedzialności. W przypadku wolnego oprogramowania dodatkowym uzasadnieniem takiego „immunitetu” jest fakt społecznych korzyści pracy hakerów [21]. Pozwala to na ostrożne porównanie ich z jednostkami piastującymi urzędy w interesie publicznym i rozważenie, czy taka społeczna funkcja nie uzasadnia korzystania z określonych przywilejów.
3.5. Inne prywatne instytucje prawne
Pozostałe prywatne normy są zwykle tworzone przez aktywne na rynku wolnego oprogramowania podmioty komercyjne. Przedsiębiorcy wykorzystują instytucje takie jak prawa autorskie, patenty, znaki towarowe lub swobodę umów w celu ograniczenia praw licencjobiorców. Dla przykładu, zastrzeżony znak towarowy w skądinąd wolnym programie może stanowić utrudnienie dla jego rozpowszechniania. Poza tym, dodatkowe usługi związane z oprogramowaniem mogą być oferowane pod warunkiem korzystania z określonej wersji programu. Wobec działań tego typu konieczne jest przemyślenie wyżej sformułowanego wniosku o zrównaniu użytkowników z deweloperami.
3.6. Istota norm prywatnych
Jak wynika z powyższego, do norm prywatnych zalicza się udzielenie praw do kontroli oprogramowania użytkownikom w szerokim zakresie. Tym prawom, określanym przez cztery wolności, odpowiadają obowiązki nieprzeszkadzania w ich wykonywaniu, które mogą być wzmocnione przez klauzule „copyleft”. Ponadto, istnieje norma, zgodnie z którą tworzenie i rozpowszechnianie wolnego oprogramowania nie stanowi podstawy odpowiedzialności prawnej.
Istnieją jednakże ograniczenia zakresu wolności, wynikające choćby z niekompatybilności licencji lub innych działań skutkujących rozdysponowaniem praw przez użytkowników. Rzucają one nowe światło na ustalenia dotyczące publicznej dostępności wolnego oprogramowania oraz równości użytkowników i deweloperów.
Innymi słowy, zgodnie z normami prywatnymi, każdy ma prawo do swobodnego dysponowania oprogramowaniem dopóki, dopóty nie wpływa to na wolność innych lub on sam nie zobowiąże się do powstrzymania od korzystania ze swych wolności.
4. Normy społeczności
Poniżej dokonana została analiza kultury hakerskiej, własności projektu oraz merytokracji, a także instytucji rozwidlania („forking”) w celu przedstawienia wynikających z nich norm społeczności.
4.1. Kultura hakerska
Istnieje dość popularny, choć dyskutowany pogląd, że hakerzy [22] organizują swoje działania zgodnie z „kulturą prezentu” („gift culture”), czyli gospodarki definiującej bogactwo jako ilość dóbr, które dana jednostka jest w stanie rozdać. Według Raymonda, status społeczny jednostek zależy od wartości wkładu wniesionego w rozwój wolnego oprogramowania [23].
Levy sugeruje istnienie etyki hakerskiej, składającej się z takich norm jak „informacja powinna być wolna” [24]. Wobec tego, status społeczny w społecznościach wolnego oprogramowania zależy także od poziomu etycznego poszczególnych jednostek [25].
4.2. Własność projektu
Uznawanie statusu oraz wynikająca z tego struktura społeczna oznacza zwykle, że tylko niektórzy są uprawnieni do podejmowania decyzji w sprawie rozwoju projektu. Tacy „właściciele projektu” tworzą czasem nieformalną grupę, taką jak „wewnętrzne koło” społeczności jądra Linuksa, lecz w niektórych projektach (np. Apache), ustanowiono dość sformalizowane reguły uznawania statusu [26]. Zatem wokół prawie każdego zaawansowanego projektu wolnego oprogramowania można zaobserwować „cebulową” strukturę, z głównymi deweloperami otoczonymi przez liczniejszych, lecz mniej uprzywilejowanych uczestników.
Jednak jak wskazano wyżej, licencje nadają równe prawa wszystkim, a ich literalne brzmienie sugeruje istnienie bardziej anarchistycznej struktury. Niezależnie od tego, koncepcja władzy centralnej to co najmniej ograniczenie wolności do modyfikacji oprogramowania. Nie jest więc zaskoczeniem, że społeczności wypracowały procedury w celu rozwiązywania tego typu konfliktów, których działanie można zaobserwować np. w społeczności Debiana [27]. Analiza tych instytucji prowadzi do wniosku, że własność projektu ma charakter powierniczy (fiducjarny) i jest wykonywana w imieniu wszystkich uczestników, a co za tym idzie jest poddana publicznemu nadzorowi.
4.3. Merytokracja
Proces przyznawania władzy autorom najlepszego kodu określany jest jako merytokracja. W sytuacjach wyjątkowych, niedoświadczeni uczestnicy mogą zostać technicznie odseparowani od projektu w celu utrzymania jakości kodu i umożliwienia zespołowi efektywnej pracy [28]. Jednakże w normalnym toku spraw, merytokracja nie jest narzucana, lecz uzgodniona w sposób dorozumiany lub nawet wyraźnie zapisana w „konstytucji projektu” (np. Debian) [29]. W takich projektach, społeczność wybiera swych reprezentantów (właścicieli modułów, przywódców projektu), którzy wchodzą w skład swego rodzaju zarządu. Lecz nawet wtedy są oni oceniani na podstawie ich zasług, choć niewątpliwie ich zdolności polityczne także powinny być brane pod uwagę.
Analiza „dyktatury” Linusa Torvaldsa dokonana przez Kuwabarę [30] pozwala wnioskować, że choć jego decyzje są często wyrażane autorytarnie, bez możliwości odwołania, to rzadko pozbawione są technicznego uzasadnienia. Ponadto, okazuje się, że te decyzje są po prostu właściwe i nie narażają użyteczności projektu. Ponieważ hakerzy są przede wszystkim zainteresowani wydajnością kodu, może być to wyjaśnieniem dlaczego decydują się podporządkować takim przywódcom, zamiast wykonywać wszystkie swoje wolności na każdym etapie.
4.4. Prawo do rozwidlenia
Rozwidlenie („forking”) to rozpoczęcie konkurencyjnego projektu we własnym zakresie, przez nowych głównych deweloperów i zazwyczaj w ramach nowej społeczności. Jest to zdecydowanie zgodne z licencjami i zaszło w przypadku wielu projektów. Należy podkreślić, że zwykle inicjatorzy forkingu wyczerpująco tłumaczą swe postępowanie, dostarczając przede wszystkim argumentów technicznych [31]. Niekiedy, argumentują oni, że nowy projekt nie jest rozwidleniem, ale czymś innym [32].
Rozwidlenie jest środkiem obrony przed próbami zawłaszczenia projektu lub skierowania go na techniczne manowce. Jednakże jest ono postrzegane jako środek ostateczny, gdy konflikty lub odmienne wizje techniczne wewnątrz społeczności są nie do pogodzenia. Praktyka wskazuje na istnienie procedur koncyliacyjnych, poszanowanie własności projektu oraz okazjonalne mediacje przeprowadzane przez uznane postacie ruchu wolnego oprogramowania [33]. Niezależnie od opisanej wyżej merytokracji, rozwidlanie wiąże się z decyzjami politycznymi, a nie tylko technicznymi [34].
W nieco słabszej formie, prawo do rozwidlania umożliwia każdemu poprawianie błędów lub przygotowanie wyspecjalizowanej wersji programu. Wydaje się, że jak długo taka swoboda jest możliwa, tak długo hakerzy będą tolerować władzę właścicieli projektu.
4.5. Istota norm społeczności
Z powyższych rozważań wynika, że podstawowymi normami społeczności jest norma nakazująca dzielenie się kodem ze społecznością połączona z zakazem zatajania informacji o autorstwie wkładów. Należy przyznać, że “kultura prezentu” jest trafnym, choć nie jedynym uzasadnieniem istnienia tych norm. Obie te normy umożliwiają uznawanie statusu oraz wykształcanie się struktur społecznych wokół projektów.
Własność projektu, merytokracja oraz nakaz podporządkowania się głównym deweloperom kontrastują z prawem do rozwidlania. Wydaje się, że główni deweloperzy działają w imieniu społeczności, podczas gdy każdy uczestnik zachowuje prawo do odwołania swego pełnomocnictwa i rozwidlenia projektu. Nie ulega jednak wątpliwości, że normy społeczne zmieniają stan całkowitej wolności wynikający z norm prywatnych.
5. Normy publiczne
Poniżej przedstawione zostały przykłady norm regulujących całe społeczeństwo, które powinny być wzięte pod uwagę przy tworzeniu systemu normatywnego. Podjęta została także próba wykazania, jak normy te wpływają na normy prywatne i normy społeczności.
5.1. Przykłady istotnych norm publicznych
Istotne dla systemu normy publiczne to takie, które odnoszą się do kontroli używania, modyfikacji i rozpowszechniania oprogramowania. Takie normy zawiera prawo własności intelektualnej, które nadaje wyłączne uprawnienia do używania i rozwijania danego oprogramowania tylko niektórym jednostkom. To samo prawo pozwala na dysponowanie tymi uprawnieniami na wiele sposobów.
Inne normy wchodzące w skład systemu wynikają z wolności słowa, stowarzyszania się, własności prywatnej, swobody gospodarczej oraz zasad odpowiedzialności. Istotne jest, że w określonych sytuacjach normy te mogą mieć nierozłączne zakresy, lecz w każdym przypadku wpływają one na zakres dostępnej dla jednostek kontroli nad używaniem i rozwijaniem oprogramowania.
Prawo nie jest jedynym źródłem norm publicznych. Zgodnie z przyjętym tu rozumieniem „regulacji” (patrz przyp. 11), należy zaliczyć do systemu normatywnego także normy regulujące używanie i rozwój wolnego oprogramowania wynikające z działań w zakresie zamówień publicznych, podatków, pomocy publicznej, polityki konkurencji i innych. Są to jedynie przykłady działań, w wyniku których społeczeństwo może wpływać nie tylko na prawo, ale także na architekturę, rynek i zasady społeczności wolnego oprogramowania.
5.2. Istota norm publicznych
Normy publiczne ustanawiają prawo do używania i rozwijania oprogramowania, które nie jest powszechne, lecz wyłączne. Tylko uprawnieni z tych praw mogą decydować w jaki sposób zorganizowana zostanie produkcja oprogramowania. Poszczególne normy publiczne i ich relacje wpływają na zakres ochrony przyznawanej takim jednostkom oraz swobodę z jaką mogą one korzystać z tych praw wyłącznych.
5.3. Wpływ norm publicznych na normy prywatne
Licencjonowanie wolnego oprogramowania jest możliwe dzięki ochronie prawa autorskiego, choć niekiedy podnosi się, że taki sam efekt wywołałoby całkowite zniesienie ochrony prawnej. W każdym przypadku, zakres ochrony bezpośrednio wpływa na możliwość kontrolowania licencjobiorców i na ich role społeczne. Zatem społeczeństwo może wpływać na (1) działania propagatorów wolnego oprogramowania zmierzające ku zrównaniu użytkowników z deweloperami, jak i na (2) przeciwne tendencje do podporządkowania użytkowników jako konsumentów. Można tego dokonać nie tylko przez prawo autorskie, ale także przez dostosowanie zasad odpowiedzialności lub swobody umów, np. prawo ochrony konkurencji i konsumentów.
Ponadto, społeczeństwo może chcieć wpływać na popularyzację wolnego oprogramowania przez realizację spójnej polityki w zakresie zamówień publicznych, podatków i innych regulatorów rynku. Podobne efekty mogą być uzyskane przez politykę dotyczącą otwartych standardów, które także wpływają na podział kontroli nad technologią pomiędzy jednostki.
Należy zdać sobie sprawę, że relacje pomiędzy normami prywatnymi i publicznymi są wzajemne, zwłaszcza wobec quasi erga omnes oddziaływania tych pierwszych. Wobec tego, w pewnym zakresie możliwe jest wykorzystanie norm prywatnych do dostosowania domyślnego reżimu praw wyłącznych ustanowionego normami publicznymi.
5.4. Wpływ norm publicznych na normy społeczności
Struktury społeczności wolnego oprogramowania powstają dzięki wolności słowa i stowarzyszeń, a niewątpliwie istotnym katalizatorem jest tu tani dostęp do Internetu. Uczestniczenie w projektach uwarunkowane jest ponadto poziomem wiedzy technicznej jednostek oraz znajomością języka angielskiego. Wszystkie te czynniki podlegają społecznej regulacji.
Stosując różne środki regulacji można wspomagać uczestnictwo w społecznościach lub wpływać na ich struktury. Może być to dokonywane bezpośrednio w przypadku projektów tworzonych na potrzeby administracji publicznej [35]. Społeczeństwo może także wpływać na równowagę, która powstała pomiędzy władzą głównych deweloperów, a wolnością jednostek, zwłaszcza w projektach nadzorowanych przez państwo.
Podobnie jak normy prywatne, normy społeczności mogą także wchodzić we wzajemne relacje z normami publicznymi, a nie pozostawać jedynie przedmiotem regulacji. Upraszczając, normy społeczności dostosowują domyślny reżim norm publicznych dla potrzeb merytokracji i „kultury prezentu”.
6. Wnioski
Poniżej udzielone zostały odpowiedzi na dwa pytania badawcze, a także sformułowany został zarys systemu normatywnego społeczności wolnego oprogramowania. Poza tymi wnioskami, wskazano także kierunki dalszych badań.
6.1. Odpowiedź na pierwsze pytanie
Pytanie pierwsze brzmiało: jakie normy regulują używanie oraz rozwój wolnego oprogramowania? Analiza trzech źródeł tych norm pozwala odpowiedzieć następująco. Normy prywatne pozwalają użytkownikowi swobodnie dysponować oprogramowaniem, dopóki nie dojdzie do naruszenia swobód innych użytkowników lub też sam użytkownik nie zobowiąże się do niewykonywania części uprawnień. Normy społeczności przekazują wolności użytkowników w ręce zaufanych głównych deweloperów. Jednakże, ograniczenie wolności przez społeczność nie jest nadmierne, gdyż prawo do rozwidlenia gwarantuje, że wolności ostatecznie pozostają przy jednostkach, nawet gdy zostaną wykorzystane komercyjnie. Na pozostały zespół norm składają się normy publiczne, które przyznają wyłączne, zbywalne i podlegające obrotowi prawa do używania i rozwijania oprogramowania tylko niektórym jednostkom. Inne normy publiczne określają dokładny zakres tej ochrony. Wobec tego, wszystkie te normy powinny zostać zaliczone do systemu.
6.2. Odpowiedź na drugie pytanie
Pytanie drugie brzmiało: jakie są relacje pomiędzy normami, które regulują używanie i rozwój wolnego oprogramowania? Powyższa analiza prowadzi do wniosku, że relacje pomiędzy normami prywatnymi, społeczności oraz publicznymi są liczne i złożone. Normy prywatne są często wykorzystywane w celu ukształtowania pasywnej roli użytkowników. Jednakże, mogą być one także wykorzystywane przez jednostki (w tym przedsiębiorców), którzy cenią przeciwny stan rzeczy i wolą mieć do czynienia z równymi sobie partnerami. W ten sposób wspierane jest powstawanie społeczności wokół projektów wolnego oprogramowania, jak i podtrzymywana zostaje wolna konkurencja. Wykorzystując swobody w dostępie do oprogramowania wynikające z norm prywatnych, jak też i różne prawa zabezpieczone normami publicznymi, jednostki tworzą społeczności wolnego oprogramowania. Ostatecznie wolność jednostki wydaje się być jedynie wspomagana, a nie wchłaniana przez instytucje społeczności, takie jak kolektywne podejmowanie decyzji lub struktury hierarchiczne. Wszystkie te działania podejmowane są w ramach ustalonych przez normy publiczne, które wpływają na relacje pomiędzy wolnością jednostki, kontrolą społeczności oraz komercyjnym wykorzystaniem uprawnień.
6.3. Propozycja systemu normatywnego
W wyniku relacji opisanych powyżej, normy prywatne, normy społeczności i normy publiczne tworzą jeden system normatywny, którego celem jest podział praw i obowiązków związanych z dostępem do kodów źródłowych. Z technicznego punktu widzenia, system ten organizuje produkcję oprogramowania w ramach społeczności, która jest uprawniona do nadzorowania wysiłków jednostek skierowanych ku naprawianiu błędów, wprowadzaniu nowych funkcji oraz zapewnianiu interoperacyjności, lecz nie ma prawa do narzucania decyzji produkcyjnych komukolwiek. W sensie ekonomicznym, system jest środkiem do utrzymania konkurencji na rynku oprogramowania. Jednakże, należy pamiętać, że działanie norm prywatnych i społeczności jest istotnie uzależnione od norm publicznych.
6.4. Kierunki dalszych badań
Powyższa propozycja jest trafna, lecz stanowi jedynie pierwszy krok w kierunku kompletnego systemu normatywnego. Na propozycję składają się bowiem jedynie najważniejsze normy i relacje, wobec czego jest ona tylko podstawą, zarysem systemu normatywnego społeczności wolnego oprogramowania. Istnieje potrzeba dalszych badań, skierowanych na: (1) zidentyfikowanie wszystkich norm regulujących używanie i rozwój wolnego oprogramowania; (2) pełne zrozumienie relacji pomiędzy tymi normami, ze szczególnym uwzględnieniem norm publicznych. Kompletny system jest niezbędny dla efektywnej regulacji i będzie przydatny zarówno dla jednostek prywatnych, konkretnych społeczności, jak i całego społeczeństwa, niezależnie od ich celów.
PRZYPISY
[1]
Free Software Foundation, Free Software Definition, pod: http://www.gnu.org/philosophy/free-sw.html.
[2]
Open Source Initiative, Open Source Definition, pod: http://opensource.org/docs/definition.php.
[3]
Założenie to jest uzasadnione chociażby dlatego, że większość najpopularniejszych licencji modelowych wolnego oprogramowania jest zgodna zarówno z FSD jak i OSD. Por.: http://www.gnu.org/licenses/license-list.html z: http://opensource.org/licenses/.
[4]
Taka definicja jest wystarczająca dla prowadzonej w niniejszym artykule analizy normatywnej. Pogłębiona analiza socjologiczna tematu zawarta jest np. w: Margaret S. Elliot, Walt Scacchi, Free Software Development: Cooperation and Conflict in A Virtual Organizational Culture, w: „Free/Open Source Software Development”, red. S. Koch, Idea Publishing, 2004. Rozdział książki dostępny jest pod adresem
http://www.ics.uci.edu/~wscacchi/Papers/New/Elliott-Scacchi-BookChapter.pdf. Tam “community of practice” definiowane jest jako „grupa osób o podobnych celach, interesach, przekonaniach i systemach wartości połączona w ramach wspólnej powtarzającej się działalności” („a group of people who share similar goals, interests, beliefs, and value systems in a common domain of recurring activity or work”).
[5]
W październiku 2005 roku istniało ok. 68,000 projektów na licencji zgodnej z OSD, zarejestrowanych w popularnym repozytorium SourceForge.net. Istnieją także projekty poza SourceForge.net.
[6]
Koncepcja Raymonda wyraźnie odróżniająca model „cathedral” i „bazaar” jest zbytnim uproszczeniem. Por.: Eric S. Raymond, The Cathedral and the Bazaar, pod: http://www.catb.org/~esr/writings/cathedral-bazaar/ z: Nikolai Bezroukov, A Second Look at the Cathedral and the Bazaar, „Firstmonday”, pod: http://www.firstmonday.org/issues/issue4_12/bezroukov/index.html. Poza różnorodnością w ramach wolnego oprogramowania, występują także poważne różnice pomiędzy producentami programów własnościowych. Por.: Charles S. Mann, Why Software Is So Bad, „MIT Technology Review”, pod: http://www.technologyreview.com/articles/02/07/mann0702.1.asp, z: Lev Grossman, How Apple Does It, „Time”, pod: http://www.time.com/time/magazine/article/0,9171,1118384,00.html.
[7]
Kevin Crowston, James Howison, The social structure of free and open source software development, „Firstmonday”, pod: http://www.firstmonday.org/issues/issue10_2/crowston/index.html; Sandeep Krishnamurthy, Cave or Community? An Empirical Examination of 100 Mature Open Source Projects, „Firstmonday”, pod: http://www.firstmonday.org/issues/issue7_6/krishnamurthy/index.html.
[8]
Jest tak zwłaszcza wobec tzw. efektów sieciowych, rozumianych zwykle jako zwiększenie wartości dobra w oczach jego konsumentów w odpowiedzi na zwiększenie liczby konsumentów. Szczegółowa analiza ekonomiczna jest poza zakresem niniejszego artykułu, jednak należy zwrócić uwagę, że efekty sieciowe mogą spowodować przyjęcie na całym rynku standaryzowanego produktu jednego rodzaju.
[9]
Ronald Coase, The Nature of the Firm, „Economica”, Vol. 4, No. 16, Listopad 1937, s. 386-405. Artykuł dostępny on-line pod adresem: http://www.cerna.ensmp.fr/Enseignement/CoursEcoIndus/SupportsdeCours/COASE.pdf.
[10]
W niniejszym artykule, “norma” jest rozumiana zgodnie z teorią prawoznawstwa, jako “[w]ypowiedź, która formułuje skierowane do danej osoby lub osób żądanie albo upoważnienie do określonego zachowania się”, cyt. za: Tomasz Stawecki, Piotr Winczorek, Wstęp do prawoznawstwa, Warszawa 1998, s. 43. Jednak do systemu należy zaliczyć nie tylko normy prawne, lecz także takie, które wynikają z etyki lub zwyczaju.
[11]
“Regulację” należy rozumieć szeroko. Zob. artykuł Lessinga wskazujący cztery środki regulacji: (1) prawo, (2) architektura, (3) zasady postępowania i (4) rynek. Regulacja jest możliwa przez bezpośrednie zastosowanie tych środków, lecz także pośrednio, poprzez ich wzajemne oddziaływanie. Lawrence Lessig, The New Chicago School, „The Journal of Legal Studies”, Vol. 27, 1998, s. 661–691.
[12]
Toczy się dyskusja, czy licencje wolnego oprogramowania są umowami, czy jednostronnymi oświadczeniami woli. Nie jest to jednak kwestia szczególnie istotna w niniejszych rozważaniach.
[13]
W październiku 2005 roku ok. 70% wolnego oprogramowania było objęte GPL. Pozostałe popularne licencje modelowe to: GNU Lesser General Public License („LGPL”), BSD License, Artistic License, MIT License, Apache Software License (v. 1.1 i v. 2.0) oraz Mozilla Public License (SourceForge.net).
[14]
Planetary Motion, Inc. v. Techsplosion, Inc. 261 F.3d 1188 (11th Circ. (Fla.), 2001); Progress Software Corp. v. MySQL AB 195 F. Supp. 2d 328 (D. Mass. 2002); SCO Group, Inc., The v. International Business Machines, No. 2:03cv0294 (Plaintiff’s Amended Complaint) (D. Utah, filed June 16, 2003); Unix System Laboratories v. Berkeley Software Design, Inc. 1993 Copr.L.Dec. P 27,075, (27 U.S.P.Q.2d 1721); 1993 Copr.L.Dec. P 27,166, (86 Ed. Law Rep. 738, 29 U.S.P.Q.2d 1561); Landgericht Muenchen 19.5.2004 (21 O 6123/04).
[15]
Zakres i inne prawne aspekty licencji modelowych są często dyskutowane publicznie w Internecie. Zob.: GNU, GPL, FAQ, pod: http://www.fsf.org/licensing/licenses/gpl-faq.html.
[16]
Zob.: Mozilla Public License, pod: http://www.mozilla.org/MPL/MPL-1.1.html.
[17]
BSD to skrót od „Berkeley Software Distribution”, prostej nierestrykcyjnej licencji pozbawionej klauzuli „copyleft”, pod: http://xfree86.org/3.3.6/COPYRIGHT2.html. Licencje typu BSD stosowane są w wielu istotnych projektach wolnego oprogramowania, np.: FreeBSD, NetBSD i OpenBSD.
[18]
Richard M. Stallman, The GNU Project, w: Eadem, „Free Software, Free Society: Selected Essays of Richard M. Stallman”, GNU Press, Boston 2002, s. 17-33. Książka w całości dostępna do pobrania w eBibliotece.
[19]
Niektórzy dopatrują się takich zachęt w ograniczeniu zakresu „copyleft” – zob.: Greg R. Vetter, „Infectious” Open Source Software: Spreading Incentives or Promoting Resistance?, „Rutgers Law Journal”, Vol. 36, 2004, s. 53-163; Kernel Torvaldsa, przywołujący Note to the Linux, pod: http://www.linux.de/linux/gnu.html; jak również licencję LGPL, pod: http://www.fsf.org/licensing/licenses/lgpl.txt. Według Lakhani et. al., przestrzeganie postanowień licencji jest najrzadziej wskazywaną przez deweloperów przyczyną uczestniczenia w projektach – K.R. Lakhani, B.Wolf, J. Bates i C. DiBona, The Boston Consulting Group Hacker Survey, pod: http://www.bcg.com/opensource/BCGHackerSurveyOSCON24July02v073.pdf. Jednakże Kuwabara uważa, że „copyleft” i norma społeczności nakazująca dzielenie się, stanowią istotne gwarancje, że wkłady nie zostaną zawłaszczone przez „gapowiczów” i przyczyniają się do wzrostu ogólnego poczucia stabilności – Ko Kuwabara, pod: Linux: A Bazaar at the Edge of Chaos, „Firstmonday”, pod: http://www.firstmonday.org/issues/issue5_3/kuwabara/index.html.
[20]
Free Software Foundation, Various Licenses and Comments about Them, pod: http://www.gnu.org/licenses/license-list.html.
[21]
„Hacker” oznacza tu wysoce wykwalifikowanego informatyka, a nie przestępcę włamującego się do systemów informatycznych.
[22]
Zob.: Eric S. Raymond, A Brief History of Hackerdom, pod: http://catb.org/~esr/writings/cathedral-bazaar/hacker-history/; Eadem, How to Become a Hacker, pod: http://catb.org/~esr/faqs/hacker-howto.html.
[23]
Eric S. Raymond, Homesteading the Noosphere, pod: http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/.
[24]
Steven Levy, Hackers: Heroes of the Computer Revolution, New York-Dell, 1985.
[25]
E. Gabriella Coleman, The Social Construction of Freedom in Free and Open Source Software: Hackers, Ethics, and the Liberal Tradition – doktorat, University of Chicago, 2005, pod: http://www.healthhacker.org/biella/freesoftware.html (opis procesu przyjmowania nowego członka społeczności deweloperów Debiana, składający się z weryfikacji umiejętności technicznych, etyki oraz wiedzy prawniczej kandydata).
[26]
How the ASF works, pod: http://www.apache.org/foundation/how-it-works.html.
[27]
E. Gabriella Coleman, FN 4 (opisujący procedurę „peer-review” stosowaną dla weryfikacji decyzji menedżerów); Elliot & Scacchi, FN 4 (opisujący dyskusje na temat celowości wykorzystania nie-wolnych narzędzi dla rozwijania wolnego oprogramowania).
[28]
Alan Cox, Cathedrals, Bazaars and the Town Council, pod: http://slashdot.org/features/98/10/13/1423253.shtml. Według słów samego autora jest to „a guide to how to completely screw up a free software project”; ponieważ decyzja o ignorowaniu „mas” nie pozwoliła w pełni wykorzystać potencjału modelu „bazaar”.
[29]
Debian Project, Debian Constitution, pod: http://www.debian.org/devel/constitution.
[30]
Kuwabara, FN 8.
[31]
Zach Welch, FORK: The Time is Now, pod: http://article.gmane.org/gmane.linux.gentoo.devel/9598.
[32]
Mark Shuttleworth, MarkShuttleworth, Wiki.ubuntu.com, pod: https://wiki.ubuntu.com/MarkShuttleworth.
[33]
Charles M. Schweik, Andrei Semenov, The Institutional Design of Open Source Programming: Implications for Addressing Complex Public Policy and Management Problems, „Firstmonday”, pod: http://www.firstmonday.org/issues/issue8_1/schweik/index.html.
[34]
Monica Divirini, Letizia Jaccheri, Eric Monteneiro, Hallvard Traettenberg, Open source process: no place for politics?, w: „Proceedings from 3rd Workshop on Open Source Software Engineering”, Portland-Oregon 2003.
[35]
Rishab Aiyer Ghosh, Ruediger Glott, Gregorio Robles, Patrice-Emmanuel Schmitz, Guideline for Public Administrations on Partnering with Free Software Developers, European Commission, Enterprise DG, IDA/GPOSS, 2004, pod: http://europa.eu.int/idabc/servlets/Doc?id=19295.
——————————————————————————————–
Materiał udostępniany na zasadach licencji
Creative Commons 2.5
Uznanie autorstwa
——————————————————————————————–