Analiza mikroekonomiczna oprogramowania o otwartym źródle rola przedsiębiorstw w jego rozwoju

Transkrypt

1 Szkoła Główna Handlowa w Warszawie Studium Dyplomowe Praca magisterska na kierunku EKONOMIA Grzegorz Andruszkiewicz Nr albumu: Analiza mikroekonomiczna oprogramowania o otwartym źródle rola przedsiębiorstw w jego rozwoju Praca wykonana pod kierunkiem prof. Aleksandera Sulejewicza katedra Ekonomii II Warszawa 2004

2 Pracę przedkładam do oceny Data Podpis autora pracy: Praca jest gotowa do oceny przez recenzenta Data Podpis kierującego pracą:

3 Spis treści Wstęp Oprogramowanie o otwartym źródle Licencje Tworzenie oprogramowania o otwartym źródle Motywacja programistów Motywacja firm Proces powstawania Niezawodność Rola przedsiębiorstw i rządu w tworzeniu wolnego oprogramowania Model Funkcja produkcji firm komercyjnych Funkcja produkcji ruchu wolnego oprogramowania Funkcja użyteczności użytkownika oprogramownia Producent oprogramowania Powstawanie oprogramowania o otwartym źródle Porównanie oprogramowania komercyjnego z oprogramowaniem o otwartym źródle Wnioski z modelu Wnioski Bibliografia

4

5 Wstęp W ostatnich latach na rynku oprogramowania komputerowego zauważamy nową tendencję pojawiło się tzw. oprogramowanie o otwartym źródle (ang. open source software, skr. OSS), czyli oprogramowanie, którego każdy ma prawo używać bez konieczności zakupu licencji 1 i które każdy ma prawo poprawiać, ponieważ kod źródłowy 2 jest publicznie dostępny. Fenomenem ostatnich kilku lat jest fakt, że oprogramowanie to jest coraz lepsze i coraz bardziej rozpowszechnione. Najlepszym przykładem jest serwer WWW 3 Apache, który można ściągnąć za darmo ze strony a jednocześnie ma (luty 2004) ponad 69% udziału w rynku 4. Poza Apache m istnieje wiele innych bardzo zaawansowanych technicznie projektów, konkurencyjnych do rozwiązań komercyjnych, 5 jak chociażby system operacyjny GNU/Linux 6, prze- 1 Licencja jest rodzajem ograniczonego prawa do korzystania z dobra intelektualnego. Oprogramowanie o otwartym źródle także jest objęte licencjami, ale licencje te istotnie różnią się od licencji komercyjnych, gdyż starają się zagwarantować każdemu prawo do korzystania z oprogramowania, a nie je ograniczyć. Problemy licencji zostaną dokładniej omówione w rozdziale Kodem źródłowym nazywamy tekst programu bezpośrednio tworzony przez programistów. Programy, które uruchamiamy na komputerze są w postaci tzw. kodu wykonywalnego, który istotnie różni się od kodu źródłowego jest praktycznie nieczytelny dla człowieka. Posiadając kod źródłowy możemy łatwo otrzymać kod wykonywalny poprzez kompilację (proces zautomatyzowany). Proces ten jest jednakże praktycznie nieodwracalny istnieją tzw. dekompilatory, lecz nie potrafią one wiernie odtworzyć kodu źródłowego, w szczególności nie da się odzyskać komentarzy programistów, często niezbędnych do zrozumienia sposobu działania programu. Można więc przyjąć, że posiadając tylko kod wykonywalny programu, nie da się w programie nic poprawić. 3 Serwer WWW to program umożliwiający udostępnienie innym użytkownikom sieci naszej strony internetowej. 4 Netcraft, Web Server Survey. 5 Analizą poziomu zaawansowania i konkurencyjnością oprogramowania o otwartym źródle zajmę się w rozdziale

6 glądarka internetowa Mozilla 7, pakiet biurowy Open Office 8, kompilator gcc 9, debugger gdb 10, system zarządzania bazą danych MySQL 11, itd. Narzucającym się pytaniem jest jak to się dzieje, że takie oprogramowanie powstaje? Stworzenie tak zaawansowanych programów wymaga niesłychanie dużego nakładu pracy wysoko wykwalifikowanych programistów, którzy rozdają swoje produkty za darmo. Poza tym obserwujemy czynny udział firm w rozwijaniu oprogramowania o otwartym źródle. Na pierwszy rzut oka wydaje się, że ten fenomen przeczy zasadom ekonomii klasycznej, gdyż dlaczego ludzie i firmy mieliby rozdawać owoce swojej pracy, zamiast czerpać zyski z ich sprzedaży? W niniejszej pracy chciałbym przedstawić analizę tego paradoksu. Najpierw, w rozdziale 1 zdefiniuję dokładnie oprogramowanie o otwartym źródle i dokonam przeglądu licencji, na których to oprogramowanie jest wypuszczane. Licencje zostaną przeanalizowane pod kątem możliwości wykorzystania objętego nimi oprogramowania do celów komercyjnych. Następnie postaram się wytłumaczyć fenomen, że wielu programistów tworzy, a następnie dobrowolnie i nieodpłatnie udostępnia innym swoje poprawki do istniejących programów, czy wypuszcza nowe programy na licencjach oprogramowania o otwartym źródle. Pokażę różne motywacje programistów: począwszy od rozwijania oprogramowania dla własnej korzyści, poprzez zagadnienia dotyczące ekonomii kariery, a na aspektach kulturowo-psychologicznych skończywszy. Na koniec przedstawię także analizę porównawczą oprogramowania o otwartym źródle i oprogramowania komercyjnego pod względem użyteczności dla użytkowników (pokażę że oprogramowanie o otwartym źródle często zawiera mniej błędów, nowo-zgłoszone błędy są poprawiane szybciej, a oprogramowanie to lepiej pasuje do potrzeb niektórych użytkowników) oraz samego procesu powstawania (tworzenia) oprogramowania (przeanalizuję efektywność obu procesów, stopień dostosowania produktu do potrzeb użytkowników i możliwość kontrolowania tworzenia oprogramowania pokażę między innymi, że nie każda forma wspierania oprogramowania o otwartym źródle przyspiesza jego rozwój). W rozdziale 2 przedstawię model powstawania oprogramowania o otwartym źródle na rynku, przeanalizuję proces powstawania wolnego oprogramowania oraz jego konkurencyjności z produktem firmy komercyjnej. Zauważamy ostatnio, że w rozwój oprogramowania o otwartym źródle angażuje się coraz więcej komercyjnych firm, zarówno nowo powstałych, zajmujących

7 się tylko tym oprogramowaniem, jak i wielkich światowych gigantów. Na przykład firma Red Hat Software 12, powstała w 1995 roku, zajmuje się dostarczaniem firmom rozwiązań softwarowych opartych na Linuksie i oprogarmowaniu o otwartym źródle. Dystrybucja Linuksa Red Hat 13 jest jedną z najbardziej znanych i rozpowszechnionych. Red Hat zajmuje się sprzedażą pudełkowych wersji swojej dystrybucji, można ją jednak ściągnąć za darmo ze strony internetowej, często nawet wcześniej niż dotrze do sklepów. Firma zarabia głównie na wsparciu technicznym, konsultingu, indywidualne usługi informatyczne czy szkolenie techników (wprowadzono kursy na stopnie: Red Hat Certified Engineer i Red Hat Certified Technician) i inne. Red Hat jest notowana na NASDAQ (RHAT) dnia miała wartość $ 3,158,185,200. Red Hat aktywnie inwestuje w rozwój wolnego oprogramowania, chociaż konkurenci mogą korzystać z jej pracy bez żadnych ograniczeń. Z drugiej strony IBM, tradycyjny gigant na rynku, także poświęca ogromne środki na rozwój oprogramowania o otwartym źródle, w tym np. na dostosowanie Linuksa do własnych platform sprzętowych. Firmy te ponoszą koszty na wspieranie projektów OSS, udostępniają publicznie owoce swojej pracy, a nie mają możliwości czerpania z tego żadnych bezpośrednich zysków (z powodu licencji). Sytuacja z przedsiębiorstwami jest o tyle ciekawsza od motywacji programistów, że przedsiębiorstwa są nastawione tylko na zysk (zgodnie z ekonomią klasyczną), nie występują tutaj aspekty kulturowe, psychologiczne, etc. Co więcej, często sie zdarza, że różne przedsiębiorstwa rozwijające to samo oprogramowanie o otwartym źródle są bezpośrednimi konkurentami, co raczej nie zachodziło w przypadku programistów. Analizując model postaram się wyciągnąć kilka wniosków o możliwości wpływu tych firm na sam proces rozwoju oprogramowania o otwartym źródle Dystrybucja jest to jądro Linuksa razem ze zbiorem narzędzi i programów użytkowych. Dystrybucje posiadają własny instalator, czyli program uruchamiający (przegrywający na dysk, tworzący odp. strukturę katalogów, zakładający pliki konfiguracyjne, etc) wszystkie programy na komputerze użytkownika. 7

8

9 Rozdział 1 Oprogramowanie o otwartym źródle Na początku istnienia komputerów oprogramowanie powstawało głównie albo w ośrodkach akademickich (jak Berkeley czy MIT), albo w centralnych korporacyjnych laboratoriach badawczych, gdzie naukowcy także mieli dużą autonomię (np. Bell Labs i centrum badawcze firmy Xerox w Palo Alto). Nikt nie starał się zarobić na samym oprogramowaniu, w związku z czym źródła były otwarte, a ludzie wymieniali się nowymi wersjami i ew. swoimi poprawkami. W latach 70-tych korporacje włożyły wiele wysiłku w próbę stworzenia systemu operacyjnego, który mógłby działać na wielu platformach sprzętowych. Najbardziej udane wynalazki tego okresu to język C i system UNIX, stworzone początkowo w laboratoriach AT&T Bell Labs. Oprogramowanie to było jednak przekazywane (za darmo lub za minimalną opłatą) innym instytucjom, które wprowadzały kolejne poprawki i innowacje, czym dzieliły się z pozostałymi użytkownikami. Proces dzielenia się kodem był ułatwiony, gdy w 1979 powstała sieć Usenet, łącząca społeczność programistów uniksowych. Wraz z rozwojem tej sieci, możliwości wymiany technologii przez poszczególne uniwersytety i laboratoria gwałtownie rosły. 1 Jednak w latach 80-tych firma AT&T zaczęła rościć sobie prawa własności intelektualnej do Unixa (opisany powyżej proces był nieformalny i formalne prawa własnościowe nie były ustalone) 2, inne instytucje zaczęły postępować podobnie. Między innymi MIT sprzedała firmie komercyjnej licencję na oprogramowanie wytworzone w laboratoriach. Firma ta natychmiast ograniczyła dostęp do kodu źródłowego tego oprogramowania, przez co osoby niezatrudnione, w tym twórcy oprogramowania (naukowcy z MIT), przestali mieć możliwość korzystania, nauczania i dalszego rozwijania projektów. W odpowiedzi Richard Stallman z MIT Artificial Intelligence 1 Lerner i Tirole, The Simple Economics of Open Source. 2 Ibid. 9

10 Laboratory założył w 1985 roku organizację Free Software Foundation 3, która za cel postawiła sobie stworzenie i rozprowadzenie szerokiego wachlarza darmowego oprogramowania z ogólnie dostępnym źródłem w pełni funkcjonalnego systemu operacyjnego złożonego tylko z darmowego (wolnego) oprogramowania. Projekt ten nazywa się GNU 4. Bardziej dziś znane aplikacje to kompilator gcc, debugger gdb, edytor Emacs, graficzny interfejs użytkownika GNOME i wiele innych. Stallman był osobiście dotknięty zdarzeniem w MIT, uważał także, że nowa światowa tendencja do produkcji i sprzedaży oprogramowania w postaci kodu wykonywalnego, którego nie można było modyfikować ani uczyć się na jego podstawie, jest moralnie zła. 5 Stworzył ideę i definicję wolnego oprogramowania (ang. Free Software) jest to oprogramowanie, które daje użytkownikowi cztery wolności : (1) Wolność do używania programu do jakiegokolwiek zastosowania, (2) Wolność do analizowania działania programu i dostosowania go do swoich potrzeb, (3) Wolność do rozprowadzania programu, (4) Wolność do poprawiania, modyfikowania i wypuszczania swoich wersji. Stallman podkreśla, że aby oprogramowanie było wolne w jego rozumieniu, kod źródłowy musi być ogólnie dostępny. Jest to niezbędny warunek do spełnienia punktów (2) i (4). Stallman (w ramach działalności Free Software Foundation), żeby zapobiec ewentualnym sporom o prawa autorskie wolnego oprogramowania (projektu GNU), postanowił umiejscowić to oprogramowanie w istniejących standardach prawnych. Została stworzona specjalna licencja GNU GPL (General Public License), która gwarantowała, że objęte nią oprogramowanie pozostanie wolnym oprogramowaniem (w sensie zdefiniowanym powyżej). Stallman stworzył termin Copyleft (pozostawienie do kopiowania), jako przeciwieństwo copyright (prawa autorskie, dokł. prawo do kopiowania). 6 Normalnie każdy autor dobra intelektualnego ma właśnie copyright, co oznacza że tylko on ma prawo do kopiowania i rozprowadzania swojego dzieła, zaś pozostali ludzie są tego prawa pozbawieni. Wolne oprogramowanie objęte jest copyleft, czyli jest pozostawione do kopiowania, każdy ma prawo dowolnie rozprowadzać te programy. Analogicznie jak copyright, dobra pochodne 7 także objęte są copyleft. Tą cechę licencji GPL będziemy nazywać żywotnościa. Żywotność nie jest niezbędną cechą licencji wolnego oprogramowania. 8 Dokładniej analizą różnych żywotnych i nieżywotnych licencji wolnego Od GNU s Not Unix. 5 von Hippel i von Krogh, Open Source Software and the Private-Collective Innovation Model Stallman, The Free Software Definition. 7 Dobrem (programem) pochodnym innego dobra (programu) pierwotnego będziemy nazywać coś, co powstało na bazie dobra (programu) pierwotnego jako jego modyfikacja, rozbudowa, lub nawet gdy wykorzystano tylko elementy dobra (programu) pierwotnego. 8 Stallman, Categories of Free and Non-Free Software. 10

11 oprogramowania zajmiemy się w rozdziale 1.1. W latach 90-tych nastąpił dynamiczny rozwój różnych projektów będących wolnym oprogramowaniem. W 1991 roku Linus Torvalds stworzył Linuksa 9, czyli jądro wolnego uniksowego systemu operacyjnego. Razem z narzędziami i aplikacjami GNU powstał darmowy system operacyjny GNU/Linux, bardzo popularny w kręgach akademickich i zdobywający coraz większy udział w rynku serwerowych systemów operacyjnych. Zaczęło powstawać wiele nowych projektów, ich rozwój był ułatwiony dynamicznym rozwojem Internetu - rosła pula potencjalnych programistów, chcących wziąć udział w rozwoju oprogramowania o otwartym źródle. Poza tym drastycznie zmniejszyły sie koszty komunikacji. Zaczęły powstawać inne niż GPL licencje nadal spełniające definicję wolnego oprogramowania 10. Żeby to uporządkować, w 1995 roku Debian 11 stworzył Debian Free Software Guideliness 12 zasady opisujące kiedy dana licencja jest licencją wolnego oprogramowania (dokument ten był zupełnie niezależny od Free Software Foundation, aczkolwiek GPL spełniała te zasady). Pomimo popularności wolnego oprogramowania wśród programistów, było ono rzadko wykorzystywane przez firmy i pozostałych użytkowników komputerów. W 1997 Bruce Perens (szef Debiana) i Eric Raymond (publicysta i programista OSS) doszli do wniosku, że przyczyną tego jest nieszczęsna dwuznaczność terminu free software - ludziom kojarzyło sie ono pejoratywnie z darmowym oprogramowaniem niskiej jakości. Stworzyli oni nowy termin Open Source Software (po polsku oprogramowanie o otwartym źródle) 13. Założono organizację Open Source Initiative 14, która z kolei opublikowała Open Source Definition 15 (definicję oprogramowania o otwartym źródle) niewiele zmieniony dokument Debian Free Software Guideliness. Open Source Definition składa się z 10 punktów: 1. Wolna redystrybucja licencja musi umożliwiać każdemu użytkownikowi programu jego dalszą dystrybucję, w tym pobieranie za to opłaty. 2. Kod Źródłowy licencja musi zezwalać na dystrybucję kodu źródłowego objętego nią 9 Oparł się na szkoleniowym systemie operacyjnym stworzonym przez Andrew Tanenbaum a w MIT na potrzeby prowadzenia zajęć ze studentami. 10 von Hippel i von Krogh, Open Source Software and the Private-Collective Innovation Model Debian jest stowarzyszeniem zajmującym się tworzeniem wolnego systemu operacyjnego opartego na GNU/Linux konkretniej ma własną dystrybucję Debian GNU/Linux. Zobacz: 12 Debian, Debian Free Software Guideliness. 13 von Hippel i von Krogh, Open Source Software and the Private-Collective Innovation Model Perens, Open Source Definition. 11

12 oprogramowania. Gdy oprogramowanie jest dystrybuowane bez kodu źródłowego, musi być on dostępny za darmo lub za opłatą równą kosztowi reprodukcji. 3. Prace Pochodne licencja musi umożliwiać tworzenie programów pochodnych i dystrybuowanie ich na tych samych zasadach, co licencja pierwotna. 4. Integralność kodu źródłowego autora licencja może ograniczać dystrybucję zmodyfikowanego kodu źródłowego tylko gdy pozwala na dystrybucję łatek Brak dyskryminacji żadnej osoby czy grupy osób. 6. Brak dyskryminacji żadnego pola zastosowania programu (w tym zastosowania w biznesie lub do badań z dziedziny inżynierii genetycznej) 7. Dystrybucja Licencji Licencja na której jest rozprowadzany program musi, bez konieczności dokonania dodatkowych czynności, dotyczyć także wszystkich, którzy ten program posiądą. 8. Licencja nie może być specyficzna dla konkretnego produktu nie może zależeć od tego, czy program jest częścią jakieś większej dystrybucji. 9. Licencja nie może wykluczać innego oprogramowania rozprowadzanego na tym samym nośniku danych. 10. Licencja musi być niezależna od technologii nie może zależeć od sposobu rozprowadzania programu (w sensie technicznym). Definicje Open Source Definition 17 i definicja wolnego oprogramowania opublikowana przez Free Software Foundation 18 różnią się. Obie te instytucje publikują listę licencji, które uznają za wolne/o otwartym źródle 19. Dodatkowo Free Software Foundation podaje także listę 16 Łatka (ang. patch) zawiera różnice pomiędzy pierwotnym kodem a kodem zmodyfikowanym. Korzystając ze specjalnych narzędzi, po nałożeniu łatki na pierwotny kod, otrzymujemy kod zmodyfikowany. Taki sposób dystrybucji programów pozwala odseparować program pierwotny od później dokonanych zmian. Stosuje się go głównie wtedy, gdy autorzy pierwotnego programu nie są w stanie stwierdzić jakiej jakości są poprawki, a nie chcą ryzykować utraty zaufania do jakości własnego oprogramowania. Użytkownik wtedy wie, że nakłada łatkę na własne ryzyko. 17 Perens, Open Source Definition. 18 Stallman, The Free Software Definition. 19 Odpowiednio i license-list.html 12

13 licencji uznanych za niespełniające kryteriów wolności. Po dokonaniu analizy okazało sie, że organizacje te nie zgadzają się tylko w przypadku jednej licencji: Artistic Licence. Free Software Foundation nie uznało tej licencji jako wolnej, a dla Open Source Initiative jest ona open source. 20 W uzasadnieniu jest napisane, że Nie możemy stwierdzić, że jest licencją wolnego oprogramowania, ponieważ jest zbyt nieprecyzyjna pewne ustępy są zbyt niejasne., i dalej Kłopoty dotyczą sformułowań, nie samego sensu. 21 Tak więc jedyny przypadek sprzecznej klasyfikacji licencji opiera się tylko na nieścisłości sformułowań. Co więcej, Istnieje skorygowana wersja Licencji Twórczej (ochrzczona Licencją Twórczą 2.0 ), która jest licencją wolnego oprogramowania, a nawet jest zgodna z GPL. czyli problematyczna wersja Artistic License została już poprawiona. Podsumowując, obie organizacje są prawie zgodne co do ram opisywanego przeze mnie ruchu. W związku z tym pojęć wolne oprogramowanie i oprogramowanie o otwartym źródle będę używał wymiennie. Organizacje te różnią się natomiast podejściem filozoficznym. Richard Stallman napisał Fundamentalna różnica między tymi dwoma ruchami leży w uznawanych przez nie wartościach, sposobach patrzenia na świat. Dla Open Source kwestia, czy oprogramowanie powinno mieć dostępne otwarte źródła to problem praktyczny, nie etyczny. Jak to ktoś ujął: Open source to metodyka konstruowania, wolne oprogramowanie to ruch społeczny. Dla ruchu Open Source oprogramowanie, które nie jest wolne to rozwiązanie gorsze niż optymalne. Dla ruchu Wolnego Oprogramowania programy, które nie są wolne to problem społeczny, którego rozwiązaniem jest wolne oprogramowanie Licencje Oprogramowanie komputerowe jest dobrem intelektualnym, charakteryzującym się prawie zerowym kosztem krańcowym utworzenia kolejnej kopii. Dobra intelektualne objęte są specyficznymi dla tej kategorii prawami własności. Istnieją trzy podstawowe rodzaje praw własności intelektualnej 23 : Prawa Autorskie (ang. Copyright) Gdy powstaje nowe dobro intelektualne (np. program kom- 20 Niestety Open Source Initiative nie publikuje listy licencji, które nie są open source. W związku z tym jedyne badanie jakie mogłem przeprowadzić, to znalezienie wszystkich licencji uznanych za open source przez Open Source Initiative a jednocześnie odrzuconych przez Free Software Foundation Stallman, Dlaczego termin Free Software jest lepszy niż Open Source. 23 Koek, Free Software Licensing. 13

14 puterowy), autor automatycznie dostaje prawo własności tego dobra 24, co w uproszczeniu oznacza że ma on wyłączne prawo do kopiowania tego dobra. Prawo to jest automatyczne i uniwersalne (obowiązuje wszędzie). Gdy autor sprzedaje kopię jakiemuś innemu podmiotowi, prawo autorskie nie przechodzi na kupującego tylko prawo do normalnego użytkowania konkretnej kopii. Warto także zauważyć, że prawo autorskie (w szczególności w przypadku programów) odnosi się tylko do konkretnego kodu, a nie pomysłu, funkcjonalności, etc. Mając dany program, można stworzyć niezależnie nowy program o identycznych możliwościach jak ten poprzedni nie będzie on już objęty prawami własności autora pierwszego programu. W przypadku dóbr pochodnych, autor dobra pierwotnego zachowuje prawa autorskie do części napisanej przez siebie, zaś osoba wprowadzająca modyfikacje uzyskuje prawo autorskie do tych modyfikacji. 25 Prawo autorskie wygasa, zwykle po 70 latach. Patenty Patent jest dokumentem wydanym przez odp. urząd państwowy, który daje posiadaczowi wyłączne prawo do wykorzystywania pewnego konkretnego wynalazku (invention) czyli samego pomysłu, idei, a nie konkretnej implementacji. Żeby wynalazek dało sie opatentować, musi być on (1) nowy (nieopublikowany, nie używany publicznie), (2) nie może być oczywisty (tzn. nie może być tak, że specjalista w danej dziedzinie z łatwością stworzyłby dany wynalazek), (3) musi należeć do dziedziny techniki 26 i (4) musi sie nadawać do przemysłowego wykorzystania. Częstym argumentem przeciwko stosowaniu patentów jest fakt, że to organizacja rządowa jest odpowiedzialna za stwierdzenie, czy dany wynalazek spełnia warunki (1) i (2). Ostatnio technika posunęła się na tyle do przodu, że błędne decyzje zdarzają się coraz częściej, szczególnie jeżeli chodzi o patenty na oprogramowanie. Patenty ulegają przedawnieniu po minimum 20 latach. 27 Są prawem terytorialnym i nieautomatycznym. O patent trzeba się ubiegać w biurze patentowym, które może 24 O ile stworzone przez niego dobro nie jest identyczne lub bardzo podobne do już istniejącego (np. algorytmu z podręcznika). 25 Jest to czasem wykorzystywane np. przez wydawców gdy wydają jakieś stare dzieło, w przypadku którego prawa autorskie już wygasły, dodają komentarze/interpretację, które są niezależnie objęte prawem autorskim. Dzięki temu dobra jako całości (książki z komentarzami) nie można kopiować i rozprowadzać. 26 Kwestia czy oprogramowanie jest patentowalne jest różnie rozstrzygalne w różnych krajach. W Stanach Zjednoczonych i Japonii wydaje się patenty na oprogramowanie, w Unii Europejskiej sprawa jest dyskutowana. 27 Taki minimalny czas trwania patentów został przyjęty w TRIPS (Trade Related aspects of Intellectual Property Rights) międzynarodowej umowie dotyczącej ochrony intelektualnej, ratyfikowanej przez większość rozwiniętych gospodarczo państw. 14

15 przyznać patent lub go odrzucić. Patenty obowiązują tylko na terytorium państwa, które je wydało. 28 Znaki handlowe Znak handlowy to znak umożliwiający rozpoznanie towarów lub dóbr danej organizacji. Znakiem handlowym jest np. Open Source i OSI Certified, należą one do Open Source Initiative 29. Znaki handlowe nie wiążą się bezpośrednio z prawami własności intelektualnej programów komputerowych, więc nie będziemy się nimi więcej zajmować. Tajemnica firmowa Jest to nieformalny sposób ochrony własności intelektualnej, bardzo istotny jednak w odniesieniu do oprogramowania komputerowego. Ponieważ programy komputerowe sprzedaje się w postaci kodu binarnego, na bazie którego bardzo trudno jest (czyli kosztownie) odkryć rzeczywiste mechanizmy działania programu ukryte pod interfejsem użytkownika, firma nie musi obawiać się ujawnienia tajemnicy służbowej dystrybuując program. Jest to jedyna forma ochrony wynalazków używana w małych i średnich przedsiębiorstwach, ponieważ firm tych nie stać na aplikowanie o patenty. Właściciele dóbr intelektualnych mogą dać(sprzedać) innym prawo do korzystania ze swojej kopii. To zezwolenie będziemy nazywać licencja. Licencja może ograniczać użytkownika dobra intelektualnego i zabraniać mu dokonywania niektórych czynności (jak kopiowanie, rozpowszechnianie, modyfikację). Autorzy wolnego oprogramowania wykorzystują istniejące mechanizmy ochrony praw autorskich do zapewnienia wolności swojemu oprogramowaniu. Posiadając prawa autorskie, rozdają program na pożądanej przez siebie licencji. 30 Przeglad licencji oprogramowania o otwartym źródle The General Public License (GPL) kiedyś GNU Public License jest to pierwsza licencja wolnego oprogramowania, stworzona przez Free Software Foundation, nazywana także copyleft. Najważniejsze cechy to: użycie oprogramowania jest nieograniczone. 28 Ostatnio wprowadzono pojecie patentu europejskiego, który będzie obowiązywał w całej Unii Europejskiej. 29 Zobacz 30 Ibid. 15

16 kopiowanie i rozpowszechnianie jest możliwe pod kilkoma warunkami, w szczególności kopia programu objętego GPL jest również objęta GPL. Pobieranie opłaty za kopię jest explicite dopuszczone. modyfikacja jest dozwolona pod warunkiem, że jeżeli zmodyfikowany program będzie rozpowszechniany, modyfikacje będą objęte taką samą licencją jak oryginał (tą cechę nazywamy żywotnościa licencji). Żywotność oznacza, że licencja gwarantuje nie tylko wolność objętego nią oprogramowania, ale także zapewnia, że wszystkie programy pochodne, modyfikacje i udoskonalenia także będą wolnym oprogramowaniem. The Library GPL (obecnie Lesser GPL) gdy biblioteki były objęte GPL, napotkano problem: czy program zlinkowany 31 z biblioteką zawiera kod objęty GPL? W ujęciu prawnym prawdopodobnie (nie było to jeszcze testowane w sądzie) taki program jest uznawany za program pochodny, co nie zawsze było intencją autorów bibliotek. Powstała nowa licencja LGPL różniąca się od GPL tylko zapisem, że programy zlinkowane 32 z biblioteką nie muszą być wolnym oprogramowaniem (natomiast nowa biblioteka oparta na naszej musi być na LGPL). Konieczne jest natomiast udostępnienie pliku obiektowego(czyli skompilowanego, ale nie zlinkowanego z biblioteką), żeby użytkownik mógł samodzielnie zlinkować ten plik z inną (nowszą) wersją biblioteki. typu MIT/X poprzednio omówione licencje były żywotne, czyli wymagały by programy pochodne także były wolnym oprogramowaniem, objętym taką samą licencją. Dla wielu twórców taki zapis jest jednak niewygodny. Licencje typu MIT/X pozwalają na dowolne licencjonowanie programów pochodnych, wprowadzają jednak ograniczenia: wszystkie istniejące informacje o prawach autorskich i warunkach licencji muszą pozostać niezmienione. nazwiska autorów nie mogą być wykorzystywane do promocji programów pochodnych. 31 W uproszczeniu korzystający z biblioteki 32 Licencja zawiera bardzo konkretną definicję bycia zlinkowanym : (fragment 5 plik obiektowy jest plikiem już skompilowanym, ale jeszcze nie zlinkowanym z biblioteką) (... ) Jeżeli taki plik obiektowy korzysta tylko z parametrów liczbowych, schematów struktur danych oraz małych (maksymalnie 10 linii kodu) makr i funkcji wstawianych (ang. inline functions), to użycie takiego pliku obiektowego jest nieograniczone, niezależnie czy formalnie jest to program pochodny. Pełen tekst licencji: 16

17 Na licencjach tego typu istnieje obecnie bardzo dużo oprogramowania, najważniejszym przykładem jest X Window System graficzny interfejs użytkownika używany w większości systemów uniksowych (w tym w Linuksie). Licencje takie niosą ze sobą jednak niebezpieczeństwo, że w pewnym momencie poprawki i rozszerzenia kodu przestaną być wolnym oprogramowaniem. Taka sytuacja miała miejsce z X Window System w kwietniu 1998 roku Open Group (organizacja zajmująca się wtedy systemem) ogłosiła, że implementacja następnej wersji nie będzie już wolnym oprogramowaniem. W tym momencie ludzie zajmujący się dostosowaniem tego systemu do wolnych systemów operacyjnych (Linux i FreeBSD) zadeklarowali, że nie będą oni korzystać z komercyjnej wersji proponowanej przez Open Group, tylko będą niezależnie rozwijać oprogramowanie (wszystkie wersje sprzed kwietnia pozostawały nadal wolnym oprogramowaniem). We wrześniu Open Group ogłosiła, że nową wersję wyda na tych samych zasadach co dotychczas. licencje typu BSD (Berkeley Software Distribution) Uniwersytet Kalifornijski Berkeley był jednym z dwóch ośrodków badawczych, w których powstawał system operacyjny UNIX (drugim były Bell Laboratories z AT&T). Rodzaj licencji, na której uniwersytet wypuszczał swoje oprogramowanie nazywamy licencjami typu BSD. Ponieważ prace te były sponsorowane przez rząd Stanów Zjednoczonych, kod jest licencjonowany bardzo liberalnie. Warunki licencji są podobne do MIT/X z dodanym zastrzeżeniem, że wszystkie reklamy muszą zawierać podziękowanie dla twórców. Zapis ten powoduje, że licencje BSD nie są kompatybilne z GPL 33 to znaczy nie można połączyć oprogramowania na licencji BSD z oprogramowaniem na GPL i wypuścić całości na GPL (licencje typu MIT/X nie mają tej własności, gdyż nie zawierają zapisu sprzecznego z GPL). Przykładami programów na licencji typu BSD są sendmail, Apache czy freebsd. Podwójne licencjonowanie Zdarza się także, że oprogramowanie jest dostępne na dwóch różnych licencjach klient wybiera tą która mu bardziej pasuje. Najbardziej znane przykłady to: Język skryptowy Perl daje użytkownikowi wybór pomiędzy GPL em, a Artistic License (nie jest żywotna modyfikacje mogą nie być oprogramowaniem o otwartym źródle ale wymaga by modyfikacje były rozprowadzane pod inną nazwą). 33 W nowej wersji licencji BSD zrezygnowano tego kłopotliwego zapisu i jest już ona kompatybilna z GPL program utworzony z fragmentów kodu na GPL i BSD będzie ostatecznie na GPL. 17

18 Autor programu Ghostscript wypuszcza nową wersję programu na licencji AFPL (Aladdin Free Public License). Pozwala ona tylko na redystrybucję niekomercyjną w przeciwnym przypadku trzeba zapłacić. Jednak po pojawieniu się nowej wersji, poprzednie przechodzą automatycznie na GPL. Podejście typu opublikuj albo płać oprogramowanie jest dostępne na jakiejś żywotnej licencji oprogramowania o otwartym źródle (np. GPL) lub na licencji komercyjnej, umożliwiającej sprzedaż oprogramowania pochodnego na dowolnej licencji(np. system zarządzania bazą danych MySQL). Podwójne licencjonowanie niesie jednak ze sobą pewne problemy. Jeżeli zostanie nadesłana poprawka do wersji licencjonowanej na GPL, to czy może być ona uwzględniona w wersji komercyjnej? Trzeba by przekonać autora poprawki, by wypuścił ją na innej licencji. Dlaczego jednak miałby to robić? Komercyjne licencje ostatnio obserwujemy rosnące zaangażowanie wielkich korporacji w rozwój wolnego oprogramowania. Gdy firmy takie wypuszczają swoje oprogramowanie jako oprogramowanie o otwartym źródle, często tworzą nową licencję, która lepiej pasuje do ich potrzeb. Licencje te zawierają często kontrowersyjne zapisy i toczy się burzliwa dyskusja czy pozostają one nadal licencjami oprogramowania o otwartym źródle. Przedstawię dwa najbardziej znane przykłady: The Netscape Public License (NPL) licencja ta jest żywotna tylko w niektórych przypadkach modyfikacje znajdujące się w oddzielnych plikach mogą być rozprowadzane na innej licencji, a modyfikacje istniejących plików nie. Poza tym, Netscape zostawia sobie prawo do wykorzystywania modyfikacji w jakikolwiek sposób powyższe ograniczenia go nie obowiązują (jako jedyny podmiot ma prawo wypuścić komercyjną wersję). Na tej licencji została wypuszczona przeglądarka internetowa Netscape (lecz nie cały kod, gdyż do części Netscape nie miał praw autorskich). Dziś projekt ten nazywa się Mozilla ( zaś licencjonowanie stało się bardzo skomplikowane, szczegóły można znaleźć na Większość licencji jest jednak podobna do NPL. The Apple Public Source License (APSL) Licencja ta obejmuje produkty Apple wypuszczone jako oprogramowanie o otwartym źródle. Licencja ta jest żywotna, 18

19 nakłada na użytkownika kilka specyficznych ograniczeń: Każda modyfikacja albo nawet użycie zmodyfikowanej wersji oprogramowania objętego APSL musi być zgłoszone Apple. Podobnie jak Netscape, firmy Apple żywotność nie obowiązuje jeżeli chodzi o wszelkie modyfikacje. Apple zostawia sobie prawo do unieważnienia licencji gdy ktoś zaskarży firmę o złamanie patentu czy prawa autorskiego. Dla użytkownika oznacz to, że licencja może być w każdym momencie unieważniona, gdyż nie ma zapisu, że to oskarżenie ma być sensowne. W nowszej wersji osłabiono ten zapis: licencja będzie zawieszona na czas procesu. Przez ten zapis pierwsza wersja licencji w ogóle nie była uznawana jako licencja oprogramowania o otwartym źródle. Cechy różnych licencji Z poprzedniego podrozdziału wynika, że choć oprogramowanie o otwartym źródle wydaje się jednym, spójnym fenomenem, tak naprawdę każdy projekt może mieć inną licencję, dalej pozostając oprogramowaniem o otwartym źródle. Przeanalizujmy (na podstawie Lerner i Tirole, The Scope of Open Source Licensing) czym kierują się liderzy projektów wybierając jakąś konkretną licencję, jaki wpływ ma dana licencja na powodzenie projektu oraz jak determinuje możliwości wykorzystania projektu przez firmy komercyjne. W momencie wyboru licencji, licencjodawca musi uwzględnić czynniki jak współpraca z innym oprogramowaniem (nie każde licencje są ze sobą komplementarne), motywacja innych programistów, żeby przyłączyli się do projektu, możliwości rozwidlenia projektu, możliwa współpraca z komercyjnymi dystrybutorami, etc. Zauważmy także, że często motywacje licencjodawcy będą się różniły od motywacji licencjobiorców, szczególnie gdy licencjodawcą jest nastawione na zysk przedsiębiorstwo komercyjne. Można wyróżnić następujące czynniki: 1. Interakcje z innym oprogramowaniem charakterystyczną cechą oprogramowania o otwartym źródle jest to, że bardzo często w jednym projekcie korzysta sie z innych projektów czy łączy się kilka programów razem. Co więcej, jak przeanalizujemy w kolejnym rozdziale, niektóre rodzaje oprogramowania (np. programy rozrywkowe czy branżowe) mają bardzo małą szansę wyjść na licencji oprogramowania o otwartym źródle. Dlatego potencjalna możliwość współpracy z oprogramowaniem komercyjnym także ma znaczenie. 19

20 Łączenie z innym oprogramowaniem ma istotne znaczenie gdy autor oprogramowania chce ustalić jakiś obowiązujący standard (jak na przykład w przypadku projektów ukierunkowanych na komunikację sieciową). Możemy przewidywać, że takie projekty będą na mniej restrykcyjnych licencjach (nieżywotnych), mimo zagrożenia rozwidleniem lub przejęciem projektu. Co ciekawe, wybór licencji może spowodować powstanie efektów sieciowych (ang. network externalities) 34 wśród liderów oprogramowania o otwartym źródle. Wybór nowej licencji dla programu w pewnym polu zastosowania może być zdeterminowany chęcią współpracy z istniejącymi już projektami. Brak dowolności w tym względzie wynika z niekompatybilności licencji. Jeżeli istniejące oprogramowanie jest np. na pierwotnej licencji BSD 35, to wypuszczenie nowego projektu na GPL spowoduje, że zupełnie nie będzie możliwe połączenie obu programów. Z kolei jeżeli istnieje jakiś duży projekt na liberalnej licencji (np. X Window Server), a my wypuścimy oprogramowanie na GPL, to liderzy dużego i uznanego projektu nie będą raczej skorzy do zmiany licencji na GPL, żeby połączyć się z naszym oprogramowaniem, etc. 2. Komercjalizacja projektów zwolennicy żywotnych licencji argumentują, że gdy oprogramowanie jest na liberalnej licencji, jest ono narażone na komercyjne przejęcia. Firma może dopisać trochę własnego, zamkniętego kodu, dodać do oprogramowania o otwartym źródle i wypuścić wszystko jako własne oprogramowanie z zamkniętym źródłem (podobnie jak w 1998 roku próbowano zrobić z X Window Server). Takie oprogramowanie może w końcu zdominować rynek. Samo to jeszcze nie koniecznie musi być gorsze dla społeczeństwa niż istnienie tylko wersji OSS. W kolejnym jednak kroku firma komercyjna może zacząć wykorzystywać swoją pozycję monopolisty, a stara, jeszcze wolna wersja oprogramowania, może być już zupełnie niekompatybilna z nowymi standardami. W każdym wariancie wszyscy (głównie programiści rozwijający to oprogramowanie) stracą możliwości wynikające z wolności oprogramowania i otwartości kodu, jak dostosowanie oprogramowania do swoich potrzeb czy szacunek kolegów wynikający z pracy nad programem. Taka ewentualność może w ogóle odstraszyć potencjalnych programistów zanim jeszcze po- 34 Mówimy, że występują efekty sieciowe, gdy konsument używający pewnego produktu uzyskuje większą użyteczność, gdy inni konsumenci korzystają z tego samego dobra. Dobrym przykładem jest oprogramowanie komunikacyjne konsument ma z niego użyteczność, gdy ma się z kim komunikować za jego pośrednictwem. 35 Istnieje wiele innych licencji niekompatybilnych z GPL, patrz: 20

21 dejmą pracę nad tym projektem. 3. Patenty na oprogramowanie łatwo sobie wyobrazić sytuację, gdy zostanie udowodnione, że oprogramowanie o otwartym źródle narusza jakiś patent na oprogramowanie mogłoby to co najmniej odstraszyć programistów i użytkowników. Najbardziej widoczne jest to w przypadku Apple, gdzie w licencji zapisano, że firma może zawiesić ważność licencji w czasie postępowania. W GPL także w jawny sposób (patrz 7) jest napisane, że korzystanie z programu w ramach licencji (czyli np. użytkowanie czy rozpowszechnianie) jest dozwolone tylko gdy nie narusza to innych przepisów prawa, np. patentowego. 4. Bodźce do produkcji komplementarnego oprogramowania standardowym argumentem na korzyść liberalnych licencji jest umożliwienie firmom komercyjnym tworzenie aplikacji, które współpracują (wykorzystują) istniejący kod. Wydaje się, że szczególnie w przypadku dojrzałych projektów, gdy początkowa energia programistów jest już na wyczerpaniu, zaangażowanie komercyjnych firm w tworzenie kodu może być kluczowym bodźcem dla dalszego rozwoju. 5. Znajomość licencji przez środowisko programistów jeżeli korzystamy ze znanej licencji, potencjalni programiści nie muszą inwestować dodatkowego czasu, żeby zaznajomić sie z warunkami nowej licencji. 6. Rozwidlanie poza powstawaniem konkurencyjnych wersji komercyjnych i koniecznością zmiany nazwy projektu w przypadku niektórych licencji, nie wiadomo na razie jak wybór licencji może wpływać na prawdopodobieństwo rozwidlenia projektu. Lerner i Tirole przeprowadzają analizę empiryczną licencjonowania projektów OSS. Dane pochodzą z SourceForge ( największego internetowego serwisu oferującego utrzymywanie projektów (ang. hosting czyli udostępnienie strony projektu, przestrzeni na dysku na kod źródłowy i wykonywalny, systemu zgłaszania błędów i poprawek, etc.). Badania zostały przeprowadzone w maju 2002 i wtedy SourceForge zawierał ok. 39 tys. projektów. Oczywiście nie wszystkie programy OSS korzystają z SourceForge, jednak serwis ten ma znaczną przewagę liczebną nad konkurencją w 2002 drugim pod względem wielkości takim portalem był Savannah i zawierał tylko 790 projektów. Przy czym nawet gdy jakiś projekt fizycznie znajduje się gdzieś indziej, często na SourceForge u także ma swoją stronę, zawierającą podstawowe dane i odnośnik do właściwej lokalizacji. 21

22 Dane pokazują asymetryczny rozkład licencji: 72% projektów jest na licencji GPL, 10% na LGPL, a tylko 7% na BSD. Wynika to pewnie z faktu, że GPL i LGPL są najbardziej znane wśród programistów i gwarantują, że praca programistów nie zostanie skradziona przez przedsiębiorstwa. Gdy już powstało dużo programów na tych licencjach, kolejne powstawały także z powodów kompatybilności z już istniejącymi 36. Najwięcej jest młodych projektów (poniżej 2 lat) widać wyraźnie że popularność oprogramowania o otwartym źródle najbardziej dynamicznie rosła w ciągu ostatnich kilku lat. W danych można zaobserwować kilka wyraźnych i statystycznie istotnych zależności: Projekt w stadium planowania (dopiero rozpoczynany) ma o 12% większe przewidywane prawdopodobieństwo że będzie miał restrykcyjną licencję niż projekt dojrzały. Może to oznaczać, że kiedyś GPL nie miała aż takich efektów sieciowych, albo że starsze projekty chcą zwiększyć swoje szanse na przetrwanie. 37 Projekty zorientowane na użytkowników końcowych mają o 23% częściej restrykcyjne licencje niż projekty zorientowane na programistów. 38 Projekty działające na komercyjnych systemach operacyjnych (Ms Windows) rzadziej mają restrykcyjne licencje. 39 Może to wynikać z faktu, że Linux i podstawowe narzędzia i biblioteki są na GPL, co tworzy efekty sieciowe. Projekty atrakcyjne dla konsumentów (np. gry) mają licencje bardziej restrykcyjne. 40 Tutaj groźba przejęcia przez firmę komercyjną wydaje się dominującym czynnikiem. Autorzy pracy wyodrębnili z próbki 51 projektów, które były wypuszczone jako oprogramowanie o otwartym źródle przez firmy komercyjne. Okazało się, że licencje restrykcyjne dominują w tej grupie (chociaż zależność ta nie jest istotna statystycznie). Widocznie chęć pozyskania programistów i ich obawa, czy projekt nie będzie z powrotem sprywatyzowany przez firmę, były warunkami kluczowymi. 36 Można powiedzieć, że na rynku ustaliła się równowaga z dominującą pozycją licencji GPL. Istnienie jednej dominującej licencji wynika z efektów sieciowych (network effects) gdy wszyscy (racjonalnie) wierzą że jedna z licencji stanie się dominująca, wypuszczają swoje programy na tej właśnie licencji, żeby zagwarantować sobie korzyści sieciowe łączenie z innymi programami, wykorzystywanie kawałków kodu, łatwe przyciągnięcie programistów znających licencję, itd. 37 Lerner i Tirole, The Scope of Open Source Licensing s Ibid. 39 Ibid. s Ibid. 22

23 1.2. Tworzenie oprogramowania o otwartym źródle Oprogramowanie o otwartym źródle powstaje w sposób inny niż oprogramowanie komercyjne. Programiści nie są związani kontraktem i nie muszą pisać kodu. Nie mają przełożonych w klasycznym rozumieniu tego słowa, którzy koordynowaliby ich pracę, przydzielali do konkretnych zadań, pilnowali zachowania jakości pracy i wyznaczonych terminów. Co więcej, programiści nie dostają wynagrodzenia pieniężnego za swój udział w projekcie więc kwestia ich motywacji do podjęcia pracy nie jest oczywista. W tym rozdziale chciałbym się zastanowić nad procesem powstawania oprogramowania o otwartym źródle, sposobem koordynacji i kontroli pracy programistów, oraz bodźców kierujących ich do podjęcia wysiłku rozwoju wolnego oprogramowania. Następnie przeanalizuję jakość powstałego w ten sposób oprogramowania 41 i możliwością kontroli bądź wpłynięcia na wolne oprogramowanie przez firmy komercyjne. Proces tworzenia wolnego oprogramowania istotnie różni się od tradycyjnej inżynierii oprogramowania używanej w przedsiębiorstwach. Eric Raymond 42 w Raymond, The Cathedral and the Bazaar porównuje styl pracy w firmach informatycznych do budowania katedry, a powstawanie oprogramowania o otwartym źródle do wymiany na chaotycznym i hałaśliwym bazarze. 43 Żeby zbudować katedrę, trzeba na początku przemyśleć i zaprojektować jej wygląd, a następnie po kolei wykonywać plan, w spokoju i izolacji. Katedra nie może być oddana do użytku (testowania) zanim nie będzie w pełni skończona. Bazar, z drugiej strony, rządzi się zupełnie innymi prawami. Tam każdy programista może mieć własną wizję i termin ukończenia swoich kawałków kodu, każdy może w dowolnym momencie przyjść na bazar, popracować nad projektem, a następnie go opuścić. Nowe wersje oprogramowania sklecone z kawałków nadesłanych przez programistów wypuszczane są bardzo często (nawet codziennie) i bardzo szybko (gdy oprogramowanie osiągnie jakąkolwiek użyteczność, w przeciwieństwie do doskonałości katedry). W taki właśnie bazarowy sposób powstał między innymi Linux, coraz bardziej popularny system operacyjny o otwartym kodzie. Postaram się wyjaśnić, jak z tego (pozornego) chaosu może powstać oprogramowanie o tak dużej złożoności jak nowoczesny system operacyjny, i o takiej jakości, że ludzie i firmy decydują się go używać. 41 Jakość rozumiem jako (1) liczba błędów wykrywanych w programach i czas ich poprawienia (2) dopasowanie możliwości programu do potrzeb użytkowników - przeanalizuję jakie grupy użytkowników są odbiorcami oprogramowania o otwartym źródle 42 Lider projektu Fetchmail, publicysta ruchu oprogramowania o otwartym źródle, prezes Open Source Initiative. 43 ibid. s

24 Autorzy (szczególnie Eric Raymond w Raymond, The Cathedral and the Bazaar) podkreślają konieczność samodzielnego napisania przez programistę początkowej wersji programu. Raymond pisze: Każdy dobry program ma swój początek w połechtaniu osobistych ambicji programisty 44.Podkreśla, że w bazarowym stylu można rozwijać tylko już istniejący program, który musi rzeczywiście działać i wykonywać jakąś sensowną pracę, chociaż może zawierać jeszcze błędy, niedociągnięcia i braki pewnych (oczywistych) funkcjonalności. Żeby namówić potencjalnych twórców do stworzenia bazaru, muszą oni widzieć, że oprogramowanie (1) działa (2) może być rozwinięte do czegoś naprawdę wartościowego. 45 O programach nie rozwijanych jeszcze w stylu bazarowym będę mówił, że są w fazie wstępnej. Lerner i Tirole podkreślają, że poza warunkami, że projekt ma być działający i do zrobienia, pierwotny twórca musi zostawić także jakieś ciekawe i nietrywialne problemy do rozwiązania potencjalnym programistom. Linus Torvalds, gdy napisał pierwszą wersję Linuksa, stworzył specjalną stronę internetową, gdzie zachęcał innych programistów do dalszego rozwoju tego programu. W swoich pierwszych publikacjach, mających wzbudzić zainteresowanie Linuksem, podkreślał ilość kreatywnego programowania, jaka jest jeszcze potrzebna by program uzyskał pełną funkcjonalność. 46 Dopiero po utworzeniu produktu przyciągającego innych programistów projekt wchodzi w fazę dojrzała, rozwijającą się już w stylu bazarowym. Co więcej, wypuszczenie ewidentnie działającego i funkcjonalnego oprogramowania niekoniecznie musi zapoczątkować jego rozwój w stylu bazarowym. Przykład przeglądarki Netscape Navigator 47 pokazuje, że programiści nie podejmą się pracy nad programem źle zaprojektowanym, z niechlujnym kodem czy źle zdefiniowanymi celami. 48 Zauważmy, że przez całą fazę wstępną programista (grupa programistów) pracuje sam, czyli posiada pełna prawa autorskie do swojego dzieła. Czemu decydują się oni do wypuszczenia 44 Oryginalnie: Every good work of software starts by scratching a developer s personal itch. 45 Raymond, The Cathedral and the Bazaar s Lerner i Tirole, The Simple Economics of Open Source s. 26, W 1998 firma Netscape wypuściła kod swojej przeglądarki internetowej na licencji oprogramowania o otwartym źródle. Program ten przegrywał wtedy z konkurencyjnym produktem Microsoft Internet Explorer. Ponieważ jednak na początku Navigator (1) nie do końca był funkcjonalny, gdyż Netscape nie mógł opublikować części kodu do którego nie miał wszystkich praw (2) kod był charakterystyczny dla firm, składał się z wielkich fragmentów współzależnych ze sobą, praktycznie niemożliwe było poprawienie małej części. Dopiero po dopisaniu brakujących fragmentów i podzieleniu kodu na mniejsze, funkcjonalne kawałki (wysoka modularność programów jest bardzo charakterystyczna dla oprogramowania o otwartym źródle) projekt zaczął dynamicznie zyskiwać twórców i użytkowników. Dziś nazywa sie Mozilla, 48 Raymond, The Cathedral and the Bazaar s

25 oprogramowania jako oprogramowanie o otwartym źródle, zamiast je sprzedać i czerpać z tego zyski? Przedyskutujemy ten problem w dalszej części pracy. Po analizie licencji wydawałoby się, że projekty OSS charakteryzują się równouprawnieniem wszystkich twórców i użytkowników, dużą liczbą rozwidleń (gdyż każdy, gdy nie zgadza się z pozostałymi, ma prawo stworzyć własną wersję, ew. zobligowany jest do zmiany nazwy czy wypuszczenia swojej wersji na tych samych warunkach co oryginał w zależności od licencji) i ogólnym chaosem. Okazuje się jednak, że w społeczności hakerów (twórców wolnego oprogramowania) istnieją bardzo silne, niepisane normy. W szczególności każdy projekt posiada Lidera, który jest nieformalnym, ale w rzeczywistości bardzo poważanym, przywódcą projektu. Eric Raymond wprowadza nawet termin własności projektów OSS 49. Pokazuje analogię do anglo-amerykańskiego prawa własności ziemi w przypadku słabej władzy centralnej (Johna Locke a). Ziemię można było nabyć na 3 sposoby: zagospodarować leżący odłogiem teren (na granicy cywilizacji), poprzez transfer tego prawa od poprzedniego właściciela bądź przez zajęcie i zagospodarowanie porzuconego obszaru. Podobnie jest z projektami programistycznymi zawsze można znaleźć osobę (lub grupę osób), która zajmuje się projektem, ma uprawnienia do modyfikacji strony i oficjalnego kodu źródłowego, etc. Taka osoba jest właścicielem projektu i najczęściej jego liderem. Rozwidlanie projektu uznawane jest przez społeczność za niemoralne, sprzeczne z zasadami norm kulturowych, gdyż jest to swoista kradzież praw własności do projektu. Ma to także uzasadnienie racjonalne po rozwidleniu grupa programistów związana z tym oprogramowaniem dzieli się na dwa obozy. Przez to następuje spadek tempa rozwoju każdej z tych wersji, a co za tym idzie spadek użyteczności społeczności z nowych funkcjonalności. Praktyka wskazuje, że w długim okresie szansę na przeżycie ma tylko jeden projekt. Obowiązkiem właściciela/lidera jest dbanie o uwzględnienie opinii, poprawek, pomysłów, etc. wszystkich zainteresowanych. Gdy nie wywiązuje się on z tego, projekt uznaje się za porzucony i możliwe jest przejęcie jego praw własności przez innego programistę. Społeczność hakerów mocno preferuje jednak transfer praw od poprzedniego właściciela, który zdając sobie sprawę, że sam nie ma już czasu/chęci to zajmowania się projektem, ogłasza, że przekazuje swoje funkcje konkretnemu następcy. Zupełnie opuszczone projekty zdarzają się stosunkowo rzadko. Zanim całkowicie się przejmie prawa własności takiego projektu, wypada ogłaszać taki zamiar na listach dyskusyjnych związanych z projektem i czekać na ew. sprzeciw Raymond, Homeseading the Noosphere. 50 Ibid. s