Projekt GNU

Richard Stallman

Pierwsza społeczność dzieląca się oprogramowaniem

Kiedy w 1971 roku rozpocząłem pracę w Laboratorium Sztucznej Inteligencji MIT stałem się częścią społeczności wymieniającej się oprogramowaniem, która działała już od wielu lat. Dzielenie się programami nie ograniczało się wyłącznie do naszej społeczności. Jest tak stare, jak komputery, podobnie jak wymienianie się przepisami jest tak stare, jak samo gotowanie. Ale nasza społeczność robiła to w większym stopniu, niż inne.

Laboratorium Sztucznej Inteligencji korzystało z systemu operacyjnego współdzielącego czas o nazwie ITS (Incompatible Timesharing System), który był zaprojektowany i napisany w języku assembler przez hackerów z Laboratorium na komputer Digital PDP-10, jeden z wielkich komputerów tamtych czasów [1]. Moja praca, jako członka społeczności i pracownika Laboratorium, polegała na ulepszaniu tego systemu.

Nie nazywaliśmy naszego oprogramowania „wolnym oprogramowaniem”, bo taki termin wówczas nie istniał. Ale właśnie takie ono było. Kiedy pracownicy innego uniwersytetu albo firmy chcieli przenieść jakiś program na swój system i korzystać z niego, to z chęcią się zgadzaliśmy. Kiedy widziało się kogoś korzystającego z nieznanego, interesującego programu, to zawsze można było poprosić o jego kod źródłowy – żeby go przeczytać, zmienić lub użyć jego fragmentów do stworzenia nowego programu.

Upadek społeczności

Sytuacja zmieniła się drastycznie we wczesnych latach 80., kiedy Digital zakończył produkcję PDP-10. Ich architektura, elegancka i potężna w latach 60., nie dała się w sposób naturalny rozbudować tak, żeby wykorzystać większe przestrzenie adresowe, jakie stały się osiągalne w latach 80. To oznaczało, że niemal wszystkie programy składające się na ITS stały się przestarzałe.

Społeczność hackerów z Laboratorium Sztucznej Inteligencji rozpadła się niewiele wcześniej. W roku 1981 rozwijająca się firma Symbolics zatrudniła niemal wszystkich hackerów z Laboratorium, a wyludniona społeczność nie mogła już samodzielnie dać sobie rady. (Wydarzenia te opisuje książka Steve'a Levy'ego Hackers, nakreślono w niej także klarowny opis samej społeczności w czasach rozkwitu). Kiedy w 1982 Laboratorium kupiło nowy komputer PDP-10, jego administratorzy w miejsce ITS zdecydowali się korzystać z wyprodukowanego przez firmę Digital zastrzeżonego systemu operacyjnego z podziałem czasu.

Nowoczesne w tamtych czasach komputery, takie jak VAX czy 68020, miały swoje własne systemy operacyjne, ale żaden z nich nie był wolnym oprogramowaniem. Trzeba było podpisać umowę o nieujawnianiu nawet po to tylko, by dostać program w postaci pliku wykonywalnego.

To oznaczało, że pierwszym działaniem przy korzystaniu z komputerów była obietnica odmowy pomocy innym. Społeczność oparta na współpracy była zakazana. Zasadą wprowadzoną przez właścicieli zastrzeżonego prawnie oprogramowania było „jeśli dzielisz się z bliźnim, to jesteś piratem, a jeśli potrzebujesz zmian, to błagaj, żebyśmy je wprowadzili”.

Dla niektórych czytelników może być zaskoczeniem koncepcja, że system społeczny ukryty za oprogramowaniem prawnie zastrzeżonym – system, który mówi, że nie wolno ci dzielić się programami ani ich zmieniać – jest antyspołeczny, nieetyczny, że jest po prostu zły. Ale co innego moglibyśmy powiedzieć o systemie opartym na wprowadzaniu podziałów między ludzi i pozostawianiu użytkowników bez pomocy? Czytelnicy, którym ta myśl wydaje się zaskakująca, prawdopodobnie uważają system społeczny oprogramowania prawnie zastrzeżonego za naturalny, albo osądzają go według kryteriów podsuwanych przez przemysł oprogramowania prawnie zastrzeżonego. Producenci oprogramowania ciężko i długo pracowali nad przekonaniem ludzi, że to jedyny sposób, w jaki można patrzeć na sprawę.

Kiedy producenci oprogramowania mówią o „egzekwowaniu” swoich „praw” albo „powstrzymaniu piractwa”, to, co w danej chwili mówią, jest w istocie drugorzędne. Faktyczną treścią ich wypowiedzi są niewypowiadane wprost, ukryte założenia traktowane przez nich jak rzecz bezdyskusyjna. Słuchacze mają rzecz przyjmować bezkrytycznie. Przetestujmy zatem te założenia.

Pierwszym jest, że producenci oprogramowania mają niekwestionowane, naturalne prawo do posiadania programów, a przez to do wywierania wpływu na wszystkich ich użytkowników. (Gdyby było to prawo naturalne, to wtedy bez względu na to, jak wiele szkody przynosi społeczności, nie moglibyśmy się mu sprzeciwić). Interesujące, że konstytucja Stanów Zjednoczonych i tradycja prawna odrzucają ten pogląd. Prawo autorskie nie jest prawem naturalnym, tylko sztucznym, utrzymywanym przez rząd monopolem, który ogranicza naturalne prawo użytkowników do kopiowania.

Kolejnym niejawnym założeniem jest, że jedyną istotną rzeczą w programach komputerowych jest praca, którą pozwalają wykonać – że my, użytkownicy komputerów, nie powinniśmy dbać o to, jaki rodzaj społeczności mamy prawo tworzyć.

Trzecim założeniem jest, że nie mielibyśmy żadnego zdatnego do użytku oprogramowania (albo nie mielibyśmy programu do wykonania takiej czy innej konkretnej pracy), gdybyśmy nie dali firmie komputerowej władzy nad jego użytkownikami. To założenie mogło wydawać się całkiem sensowne zanim ruch wolnego oprogramowania nie pokazał, że możemy stworzyć mnóstwo użytecznego oprogramowania bez zakładania na niego kajdan.

Jeśli odrzucimy te założenia, a rzecz osądzimy bazując na zwykłej, zdroworozsądkowej moralności kierując się przy ocenie przede wszystkim dobrem użytkownika, dojdziemy do krańcowo odmiennych wniosków. Użytkownicy komputerów powinni mieć wolność w zakresie modyfikowania programów do swoich potrzeb, i wolność do dzielenia się oprogramowaniem, ponieważ pomaganie innym jest podstawą funkcjonowania społeczeństwa.

Nie ma tu miejsca na przedstawienie wyczerpującego uzasadnienia tego twierdzenia, dlatego pozwolę sobie skierować czytelnika do stron „Dlaczego oprogramowanie nie powinno mieć właścicieli” oraz „Wolne oprogramowanie jest jeszcze ważniejsze teraz.”

Wybór czysto moralny

Moja społeczność przestała istnieć, nie można już było działać jakby nic się nie zmieniło. Stanąłem w obliczu czysto moralnego wyboru.

Najłatwiejszym rozwiązaniem było wejście w świat oprogramowania prawnie zastrzeżonego – podpisywanie umów o nieujawnianiu i zgoda na nieudzielanie pomocy moim kolegom hackerom. Zapewne ja także pracowałbym nad rozwojem oprogramowania wydawanego na warunkach umów o nieujawnianiu, tym samym wzmagając presję na innych, aby także oni zdradzili swoich przyjaciół.

Mógłbym w ten sposób zarabiać pieniądze, być może mógłbym znaleźć radość w pisaniu kodu. Ale wiedziałem, że na końcu swojej kariery obejrzałbym się na lata, które spędziłem budując mury między ludźmi, i poczułbym, że życie minęło mi na czynieniu świata gorszym miejscem.

Już wtedy doświadczyłem, co znaczy być odbiorcą umowy o nieujawnianiu, kiedy ktoś odmówił mi oraz Laboratorium MIT kodu źródłowego do programu kontrolującego drukarkę (brak pewnych możliwości tego programu czynił korzystanie z drukarki zajęciem ogromnie frustrującym.) Tak więc nie mogłem sobie powiedzieć, że umowy o nieujawnianiu są nieszkodliwe. Byłem rozzłoszczony, kiedy odmówiono nam udostępnienia kodu; nie mogłem obrócić się na pięcie i zacząć robić to samo innym.

Kolejnym możliwym wyborem, oczywistym, choć nieprzyjemnym, byłby wybór innego zawodu. W ten sposób moje umiejętności nie byłyby szkodliwie wykorzystywane, ciągle jednak byłyby marnotrawione. Nie byłbym winny dzielenia i ograniczania użytkowników komputerów, ale to i tak miałoby miejsce.

Dlatego szukałem drogi, dzięki której programista mógłby zrobić coś dla wspólnego dobra. Zapytałem siebie, czy jest program, lub programy, które mógłbym napisać, i w ten sposób ponownie umożliwić powstanie społeczności.

Odpowiedź była jasna: pierwszą potrzebną rzeczą jest system operacyjny. To jest podstawowe oprogramowanie, które umożliwia korzystanie z komputera. Mając system operacyjny można robić wiele rzeczy. Bez niego w ogóle nie można uruchomić komputera. Mając wolny system operacyjny ponownie moglibyśmy stworzyć wspólnotę współpracujących ze sobą hackerów, i zaprosić każdego, by do nas dołączył. I każdy mógłby używać komputera bez uczestniczenia w spisku mającym na celu ogołocenie z praw własnych przyjaciół.

Jako specjalista od systemów operacyjnych miałem właściwe umiejętności. I choć nie mogłem być pewny sukcesu całego przedsięwzięcia, to zrozumiałem, że jestem wybrany do tej pracy. Zdecydowałem się zrobić system kompatybilny z Uniksem, tak żeby był łatwy w przenoszeniu na różne komputery, i żeby użytkownicy Uniksa mogli łatwo się na niego przerzucić. Nazwa GNU została wybrana, zgodnie ze starą hackerską tradycją, jako rekursywny akronim „GNU's Not Unix” [„GNU to Nie Unix”]. Wymawia się z jedną sylabą i twardym g.

System operacyjny nie oznacza wyłącznie jądra, ledwo wystarczającego do uruchamiania innych programów. W latach 70. każdy system operacyjny zasługujący na tę nazwę zawierał procesory poleceń, asemblery, kompilatory, interpretery, debuggery, edytory tekstu, programy pocztowe i wiele, wiele więcej innych aplikacji. ITS miał to wszystko, Multics miał, VMS miał i Unix miał. System operacyjny GNU także miał to mieć.

Później usłyszałem słowa, przypisywane Hillelowi [2]:

Jeśli nie jestem dla siebie, kto będzie dla mnie?
Jeśli jestem tylko dla siebie, to czym jestem?
Jeśli nie teraz, to kiedy?

Decyzja o powołaniu do życia Projektu GNU podjęta została w podobnym duchu.

Free as in freedom

Termin „free software” [„wolne oprogramowanie”] czasem jest mylnie rozumiany — to nie ma nic wspólnego z ceną [free w języku angielskim znaczy zarówno wolny, jak i darmowy, patrz też http://www.gnu.org/philosophy/free-sw.html – przyp. tłum.]. Tu chodzi o wolność. Dlatego definicja wolnego oprogramowania jest następująca.

Program jest wolnym oprogramowaniem dla ciebie, jego użytkownika, jeśli:

• Masz prawo do jego uruchamiania w dowolnym celu.
• Masz prawo do modyfikowania programu, tak by zaspokajał twoje potrzeby. (Żeby to prawo mogło być realizowane w praktyce, musisz mieć dostęp do kodu źródłowego, bo wprowadzanie zmian do programu bez posiadania kodu źródłowego jest niewyobrażalnie trudne.)
• Masz prawo do rozprowadzania kopii programu, zarówno za darmo, jak i za opłatą.
• Masz prawo do rozprowadzania zmodyfikowanych wersji programu, tak żeby społeczność mogła skorzystać z twoich ulepszeń.

Słowo „free” odnosi się do wolności, a nie do ceny, więc nie ma sprzeczności między sprzedażą kopii programu, a wolnym oprogramowaniem. W rzeczywistości prawo do sprzedawania kopii jest fundamentalne: zestawy wolnego oprogramowania sprzedawane na CD-ROM-ach są ważne dla społeczności, a sprzedawanie ich jest istotnym sposobem pozyskiwania funduszy na rozwój wolnego oprogramowania. Dlatego program, którego ludzie nie mogą dołączać do takiego zestawu, nie jest wolnym oprogramowaniem.

Z powodu wieloznaczności słowa „free” ludzie długo szukali dla niego alternatyw, ale żadna nie została uznana za lepszą. Język angielski posiada więcej słów i niuansów niż jakikolwiek inny, ale brakuje w nim prostego, niedwuznacznego słowa, które znaczyłoby „wolny” [„free” as in „freedom”]. „Nieskrępowany” [„unfettered”] jest słowem najbliższym mu znaczeniowo. Takie alternatywy jak „oswobodzony” [„liberated”], „wolność” [„freedom”] czy „otwarty” [„open”] mają albo niewłaściwe znaczenie, albo jakieś inne wady.

Oprogramowanie GNU i system GNU

Budowanie całego systemu to bardzo duży projekt. Żeby go osiągnąć, zdecydowałem się wykorzystać i dostosować istniejące fragmenty wolnego oprogramowania gdzie tylko było to możliwe. Na przykład na samym początku zdecydowałem się używać TeX-a jako podstawowego programu do formatowania tekstów, a kilka lat później raczej zaakceptować X Window System, niż pisać inny system okien dla GNU.

Z powodu tych i innych, podobnych, decyzji system GNU nie jest tym samym, co zestaw całego oprogramowania GNU. System GNU zawiera programy, które nie są oprogramowaniem GNU, programy, które dla swoich własnych potrzeb napisali inni ludzie czy firmy. Możemy ich jednak używać, bo są wolnym oprogramowaniem.

Początki projektu

W styczniu 1984 porzuciłem pracę w MIT i rozpocząłem pisanie oprogramowania GNU. Opuszczenie MIT było konieczne, żeby MIT nie mógł ingerować w rozprowadzaniu GNU jako wolnego oprogramowania. Gdybym pozostał pracownikiem MIT, uczelnia mogłaby zgłosić roszczenia do mojej pracy, mogłaby narzucić własne reguły dystrybucji, a nawet zamienić projekt w oprogramowanie prawnie zastrzeżone. Nie miałem ochoty wykonać tak ogromnej pracy, a następnie zobaczyć jak staje się ona bezużyteczna dla zamierzonego celu: stworzenia nowej społeczności dzielącej się oprogramowaniem.

Pomimo to profesor Winston, ówczesny szef Laboratorium Sztucznej Inteligencji MIT, życzliwie umożliwił mi dalsze korzystanie z wyposażenia laboratorium.

Pierwsze kroki

Tuż przed rozpoczęciem prac nad GNU usłyszałem o Free University Compiler Kit, znanym także jako VUCK (holenderskie słowo oznaczające „free” – „wolny” – pisze się przez v). To był kompilator zaprojektowany tak, by obsługiwał różne języki programowania, w tym C i Pascala, a także potrafił wygenerować postaci wynikowe programów przeznaczone dla rozmaitych typów komputerów. Napisałem do autora z pytaniem, czy można go użyć do tworzenia GNU.

Odpowiedział kpiąco, oświadczając, że to uniwersytet jest wolny, a nie kompilator. Wtedy zdecydowałem, że moim pierwszym programem dla GNU będzie wielojęzykowy i wieloplatformowy kompilator.

W nadziei, że uda mi się uniknąć pisania całego kompilatora samodzielnie, zdobyłem kod źródłowy Pastela, który był wieloplatformowym kompilatorem opracowanym w Lawrence Livermore Lab. Obsługiwał on rozszerzoną wersję Pascala, w której też był napisany, zaprojektowana jako język programowania systemów. Dodałem mu napisany w C interfejs użytkownika i rozpocząłem przenoszenie na komputer Motorola 68000. Ale musiałem się poddać, kiedy odkryłem, że kompilator potrzebuje wielu megabajtów pamięci, a istniejący na 68000 system uniksowy zezwalał tylko na 64 kb.

Później zrozumiałem, że kompilator Pastel działał tak, że parsował całość pliku wejściowego do postaci drzewa składniowego, konwertował całe drzewo w ciąg „instrukcji”, a następnie generował cały plik wyjściowy, przy czym na żadnym etapie nie uwalniał zasobów. Wtedy dotarło do mnie, że nowy kompilator muszę napisać od zera. Ten nowy kompilator jest znany obecnie jako GCC. Nie użyłem w nim żadnego fragmentu Pastela, ale udało mi się udało mi się dostosować i wykorzystać napisany wcześniej w C interfejs użytkownika. To było jednak kilka lat później. Najpierw pracowałem nad Emacsem.

GNU Emacs

Prace nad GNU Emacsem rozpocząłem we wrześniu 1984, a na początku 1985 zaczął nadawać się do użytku. To pozwoliło mi na wykorzystanie systemów uniksowych do edycji. Nie mając interesu w uczeniu się vi czy ed, do tej pory edycji dokonywałem na maszynach innego typu.

W tym momencie pojawili się ludzie, którzy chcieli korzystać z GNU Emacsa, co podniosło kwestię jego dystrybucji. Oczywiście umieściłem go na anonimowym serwerze ftp na komputerze MIT, z którego korzystałem. (Komputer ten, prep.ai.mit.edu, stał się w ten sposób podstawowym ośrodkiem dystrybucyjnym GNU; kiedy został zezłomowany kilka lat później, przenieśliśmy jego nazwę na nasz nowy serwer ftp.) Ale w owym czasie wielu zainteresowanych nie miało dostępu do Internetu, i nie mogło uzyskać kopii poprzez ftp. Więc pytanie brzmiało: co miałem im powiedzieć?

Mógłbym powiedzieć „znajdź znajomego z dostępem do Internetu, który zrobi dla ciebie kopię”. Albo mogłem zrobić to, co robiłem z oryginalnym Emacsem na PDP-10, mówiąc „wyślij mi taśmę i zaadresowaną kopertę zwrotną ze znaczkiem, a ja ci ją odeślę z nagranym Emacsem”. Ale nie miałem pracy i szukałem sposobu na zarobienie pieniędzy na wolnym oprogramowaniu. Dlatego ogłosiłem, że wyślę taśmę każdemu, kto tego chce, za opłatą 150$. W ten sposób stworzyłem firmę handlującą wolnym oprogramowaniem, poprzednika dzisiejszych przedsiębiorstw rozpowszechniających całe systemy dystrybucji GNU/Linux.

Czy program jest wolny dla każdego użytkownika?

Jeśli program jest wolny kiedy opuszcza ręce autora, nie oznacza to automatycznie, że będzie wolnym oprogramowaniem dla każdego, kto ma jego kopię. Na przykład oprogramowanie public domain (oprogramowanie, które nie podlega prawu autorskiemu) jest wolne, ale każdy może stworzyć jego zmodyfikowaną, objętą restrykcyjną licencją wersję. Podobnie wiele wolnych programów jest chronionych prawami autorskimi, ale rozpowszechnianych na prostych, mało restrykcyjnych licencjach, które dopuszczają tworzenie zmodyfikowanych, zastrzeżonych wersji.

Wzorcowym przykładem tego problemu jest X Window System. Stworzony na MIT i opublikowany jako wolne oprogramowanie z liberalną licencją, szybko został zaadaptowany przez różne firmy komputerowe. Dodały one X-y – ale tylko w postaci binarnej – do swoich zastrzeżonych systemów uniksowych i objęły je tą samą umową o nieujawnianiu. Te kopie X-ów nie były już bardziej wolne, niż sam Unix.

Twórcy X Window System nie uważali tego za problem – oczekiwali i chcieli, by tak się właśnie stało. Ich celem nie była wolność, ale „sukces” definiowany jako „dotarcie do wielu użytkowników”. Nie dbali o to, czy ci użytkownicy mają wolność, tylko o to, by ich było wielu.

To doprowadziło do paradoksalnej sytuacji, w której dwa różne sposoby mierzenia ilości wolności dawały różne odpowiedzi na pytanie „Czy ten program jest wolny?”. Gdyby sądzić według wolności, którą zapewniają warunki dystrybucji edycji z MIT, można by powiedzieć, że X-y są wolnym oprogramowaniem. Ale gdyby mierzyć wolność przeciętnego użytkownika X-ów okazałoby się, że jest to oprogramowanie zastrzeżone. Większość użytkowników X-ów używała bowiem jego zastrzeżonych wersji dostarczanych z Uniksami, a nie wolnej wersji.

Copyleft i GNU GPL

Celem GNU jest dać użytkownikom wolność, a nie tylko być popularnym. Dlatego potrzebowaliśmy takich warunków dystrybucji, które zapobiegłyby przekształceniu oprogramowania GNU w prawnie zastrzeżone. Metoda, której użyliśmy, nazywa się „copyleft” [3].

Copyleft korzysta z prawa autorskiego, ale wywraca je do góry nogami, żeby służyło innemu niż zazwyczaj celowi: prawo, zamiast być narzędziem służącym do przekształcenia oprogramowania w prywatną własność, staje się narzędziem służącym do zachowania wolności programu.

Centralną koncepcją copyleftu jest to, że dajemy każdemu prawo do uruchamiania programu, kopiowania programu, modyfikowania programu, oraz rozprowadzana zmodyfikowanych wersji – ale nie prawo do dodawania własnych obostrzeń. W ten sposób te podstawowe wolności, które czynią oprogramowanie wolnym, są gwarantowane dla każdego, kto ma jego kopię; stają się prawami niezbywalnymi.

Żeby copyleft był efektywny także zmodyfikowane wersje muszą być wolne. To gwarantuje, że praca oparta na naszej pracy będzie po publikacji dostępna dla naszej społeczności. Kiedy programiści, zarabiający na życie jako programiści, rozwijają oprogramowanie GNU, to właśnie copyleft powstrzymuje ich pracodawców od powiedzenia: „Nie możesz dzielić się tymi poprawkami, bo chcemy ich użyć w naszej, prawnie zastrzeżonej wersji tego programu”.

Wymóg, by także zmiany były wolne, jest niezbędny jeśli chcemy zapewnić wolność każdemu użytkownikowi programu. Firmy, które prywatyzują X Window System zazwyczaj wprowadzają jakieś poprawki, żeby dostosować go swojego sprzętu i systemów. Te poprawki są niewielkie w porównaniu z wielkim rozmiarem X-ów, ale nie są błahe. Gdyby wprowadzanie zmian było pretekstem do odmówienia użytkownikowi wolności, łatwo byłoby każdemu nadużywać tej wymówki.

Z tym związany jest problem łączenia wolnych programów z nie-wolnym kodem. Taka kombinacja byłaby nieuchronnie nie-wolna; wszystkich wolności, których brakuje w nie-wolnej części, brakowałoby także całości. Zgoda na takie połączenia wyrwałaby w kadłubie dziurę wystarczająco dużą, by zatonął cały statek. Dlatego kardynalnym zadaniem copyleftu jest zatkanie takiej dziury: dodawanie czy łączenie z programem copyleftowym musi być dokonane w taki sposób, by całość także była wolna i wydana na zasadach copyleftu.

Charakterystycznym zastosowaniem copyleftu, którego używamy najczęściej dla oprogramowania GNU, jest Powszechna Licencja Publiczna GNU [GNU General Public License], w skrócie GNU GPL. Mamy także inne rodzaje copyleftu, których używamy w wyjątkowych warunkach. Instrukcje obsługi GNU także są copyleftowane, ale do tego celu używamy znacznie prostszego rodzaju copyleftu, ponieważ dla instrukcji obsługi nie jest konieczna cała złożoność GNU GPL [4].

Fundacja Wolnego Oprogramowania (Free Software Foundation)

W miarę jak rosło zainteresowanie Emacsem, w projekt GNU angażowali się coraz to nowi ludzie. W końcu zdecydowaliśmy, że czas ponownie poszukać źródeł finansowania na rozwój systemu operacyjnego GNU. Dlatego w roku 1985 zebraliśmy przyjaciół, którym cel był bliski sercu i stworzyliśmy Fundację wolnego oprogramowania (Free Software Foundation), zwolnioną z podatku instytucję na rzecz rozwoju wolnego oprogramowania. FSF przejęła także dystrybucję taśm z Emacsem; później rozszerzyła tę działalność o rozprowadzanie innego wolnego oprogramowania (zarówno GNU jak i nie-GNU), a także sprzedaż wolnych (czyli szanujących wolność) instrukcji obsługi.

Historycznie większość przychodów FSF pochodziła ze sprzedaży kopii programów i związanych z tym innych usług (CD-ROM-y z kodem źródłowym, CD-ROM-y z programami, ładnie wydrukowane instrukcje, wszystkie z prawem do rozpowszechniania i modyfikacji), a także Dystrybucje Delux (na które składa się cały zestaw programów skompilowanych przez nas na platformę wybraną przez nabywcę). Dziś FSF nadal sprzedaje podręczniki i inne zabawki, ale większość przychodów pochodzi z opłat członkowskich. Możecie przyłączyć się do FSF na stronie fsf.org.

Pracownicy Fundacji wolnego oprogramowania napisali i utrzymywali wiele pakietów oprogramowania GNU. Dwa najbardziej znane to biblioteka C oraz powłoka (shell). Biblioteka C GNU jest czymś, czego używa każdy program uruchomiony pod systemem GNU/Linux do komunikacji z Linuksem. Została stworzona przez członka Fundacji wolnego oprogramowania, Rolanda McGratha. Powłoka używana na większości systemów GNU/Linux to BASH, Bourne Again Shell [5], którą stworzył pracownik FSF Brian Fox.

Sfinansowaliśmy powstanie tych programów, ponieważ projekt GNU nie składa się wyłącznie z narzędzi czy środowiska pracy. Naszym celem był kompletny system operacyjny, a te programy były niezbędne do jego stworzenia.

Wsparcie dla wolnego oprogramowania

Filozofia wolnego oprogramowania odrzuca szeroko stosowane praktyki biznesowe, ale nie jest przeciwko biznesowi. Jeśli biznes respektuje wolność użytkowników, życzymy mu sukcesu.

Sprzedaż kopii Emacsa to przykład jednego ze sposobów działania w biznesie wolnego oprogramowania. Kiedy FSF przejęła tę działalność, potrzebowałem innych sposobów na zarobienie pieniędzy na życie. Sposobem tym okazało się sprzedawanie usług związanych z rozwijanym przeze mnie oprogramowaniem GNU. W tym zawierały się szkolenia z tematów takich jak programowanie na GNU Emacs, czy dostosowanie GCC do konkretnych potrzeb użytkownika, a także rozwój programów, głównie implementacja GCC na nowe platformy.

Dziś każda z tych gałęzi biznesu wolnego oprogramowania jest zajęta przez szereg korporacji. Niektórzy sprzedają zestawy wolnego oprogramowania na CD-ROM-ach, inni sprzedają wsparcie techniczne różnego poziomu, począwszy od odpowiadania na pytania użytkowników, poprzez poprawianie błędów, a skończywszy na dodawaniu nowych, istotnych funkcji. Obserwujemy nawet powstawanie firm informatycznych, które bazują na wypuszczaniu nowych produktów wolnego oprogramowania.

Uważajcie jednak, bo szereg firm, które reklamują się w powiązaniu z terminem „open source” w rzeczywistości opiera swoje interesy na niewolnym oprogramowaniu, które tylko współpracuje z wolnym oprogramowaniem. To nie są firmy wolnego oprogramowania. To są firmy oprogramowania prawnie zastrzeżonego, których produkty odciągają użytkowników od wolności. Oni nazywają je produktami z „wartością dodaną” [„value-added packages”], co odzwierciedla wartości, jakie chcieliby, byśmy przyjęli: udogodnienia ponad wolnością. Jeśli jednak wyżej cenimy sobie wolność, powinniśmy nazwać je raczej produktami z „odebraną wolnością”.

Osiągnięcia techniczne

Najważniejszym zadaniem stojącym przed GNU było po prostu „być wolnym oprogramowaniem”. Nawet jeśli GNU nie miałoby technicznej przewagi nad Uniksem, miałoby przewagę społeczną, gdyż pozwala ono użytkownikom na współpracę, oraz przewagę moralną, poprzez przestrzeganie zasad wolności użytkownika.

Ale było rzeczą naturalną użycie podczas tworzenia GNU znanych i dobrze działających standardów – takich jak dynamiczna alokacja struktur danych, żeby uniknąć arbitralnych stałych rozmiarów danych, czy obsługa wszystkich możliwych 8-bitowych znaków, gdzie tylko miało to sens.

Na dodatek odrzuciliśmy uniksowe podejście skupiające się na minimalnym zużyciu pamięci, decydując, że system nie będzie obsługiwać maszyn 16-bitowych (było jasne, że w momencie, gdy system GNU zostanie ukończony, standardem będą maszyny 32-bitowe), oraz że nie będziemy się starać redukować zużycia pamięci, dopóki nie przekroczy ono wielkości jednego megabajta. Przy programach, dla których obsługiwanie bardzo dużych plików nie było szczególnie istotne, zachęcaliśmy programistów do załadowania pliku do jądra w całości, żeby uzyskać dostęp do jego zawartości bez obaw o ograniczenia wejścia-wyjścia.

Dzięki tym decyzjom wiele programów GNU jest szybsza i stabilniejsza od swoich uniksowych odpowiedników.

Podarowane komputery

Reputacja projektu GNU rosła i w związku z tym znaleźli się ludzie, którzy zaoferowali komputery pracujące pod Unix-em jako dar dla projektu. Były one bardzo użyteczne, bo najłatwiejszym sposobem rozwijania komponentów GNU było robienie tego na systemie Uniksowym, i zastępowanie jego komponentów jeden po drugim. Ale to podniosło problem etyczny: czy posiadanie przez nas kopii Unix-a w ogóle było w porządku?

Unix był (i jest) oprogramowaniem prawnie zastrzeżonym, a filozofia projektu GNU mówi, że nie powinniśmy korzystać z oprogramowania prawnie zastrzeżonego. Tym niemniej, przyjmując to samo rozumowanie, które mówi, że przemoc jest usprawiedliwiona w obronie koniecznej, doszedłem do wniosku, że uzasadnione jest użycie prawnie zastrzeżonego pakietu, jeśli jest to konieczne do stworzenia jego wolnego odpowiednika, który pomógłby ludziom w zaprzestaniu korzystania z zastrzeżonych pakietów.

Nawet jeśli było to zło usprawiedliwione, to ciągle było złem. Dziś nie mamy już żadnych kopii Uniksa, gdyż zastąpiliśmy je wolnymi systemami operacyjnymi. A jeśli nie mogliśmy wymienić systemu operacyjnego maszyny na wolnym system, to wymienialiśmy maszynę.

Lista zadań GNU

Projekt GNU rozwijał się, wzrastała liczba opracowanych lub znalezionych przez nas komponentów, i w końcu okazało się, że dobrze by było zrobić listę brakujących ogniw. Korzystaliśmy z niej przy namawianiu nowych programistów do napisania brakujących elementów. Ta lista stała się znana jako „GNU Task List” (Lista zadań GNU). Oprócz brakujących składników Uniksa na liście znalazły się także inne użyteczne programy oraz dokumentacja projektu, którą – jak sądziliśmy – każdy naprawdę kompletny system powinien posiadać.

Dziś [6] niemal wszystkie komponenty Uniksa zniknęły z Listy zadań GNU. Ta praca już została wykonana, poza kilkoma nieistotnymi. Ale lista jest pełna projektów, które można by nazwać „aplikacjami”. Każdy program, który jest atrakcyjny nie tylko dla wąskiej grupy użytkowników, jest rzeczą na tyle użyteczną, by włączyć go do systemu operacyjnego.

Nawet gry znajdują się na liście zadań – i znajdowały się na niej od początku. Unix zawierał gry, więc także GNU powinien je zawierać. Kompatybilność nie jest problemem w przypadku gier, dlatego nie kopiowaliśmy tych dostępnych w Uniksie. W zamian zamieściliśmy szereg gier różnych rodzajów, które użytkownikom mogłyby się spodobać.

Mniejsze GNU GPL (The GNU Lesser GPL)

Biblioteka GNU C jest opublikowana na specjalnych warunkach copyleft, nazwanego GNU Lesser General Public License (Mniejsza Powszechna Licencja Publiczna GNU) [7], która zezwala na łączenie oprogramowania prawnie zastrzeżonego z tą biblioteką. Czemu służy to odstępstwo od reguły?

To nie jest kwestia zasad, bo nie ma zasady mówiącej, że oprogramowanie prawnie zastrzeżone ma prawo zawierać nasz kod. (Po co pracować na rzecz projektu, który z pewnością odmówi podzielenia się z nami?). Korzystanie z LGPL dla biblioteki C, albo dla każdej innej biblioteki, jest kwestią strategii.

Biblioteka C wykonuje pracę ogólną; każdy prawnie zastrzeżony system operacyjny czy kompilator zawiera bibliotekę C. Dlatego udostępnienie je wyłącznie dla społeczności wolnego oprogramowania nie dałoby wolnemu oprogramowaniu żadnej przewagi – zniechęciłoby tylko innych do korzystania z naszej biblioteki.

Jest jeden wyjątek: na systemie GNU (a to oznacza także GNU/Linux) biblioteka GNU C jest jedyną biblioteką C. Dlatego warunki dystrybucji biblioteki GNU C określają, czy będzie możliwa kompilacja programu prawnie zastrzeżonego na system GNU. Nie ma etycznych powodów, dla których należałoby zezwolić na uruchamianie zastrzeżonego oprogramowania na systemach GNU, ale ze strategicznego punktu widzenia zabranianie tego bardziej zniechęcałoby do używania systemu GNU, niż zachęcałoby do rozwijania wolnych aplikacji. Dlatego stosowanie właśnie Mniejsze GNU GPL dla biblioteki GNU C uważamy za dobrą strategię.

Każdorazowo dla innych bibliotek strategiczna decyzja musi być podjęta. Jeśli biblioteka wykonuje specjalną pracę, pomocną przy pisaniu konkretnego rodzaju programów, wówczas opublikowanie jej na warunkach GPL powoduje, że mogą z niej korzystać wyłącznie wolne programy. W ten sposób wspiera się innych twórców wolnego oprogramowania, zwiększając ich przewagę wobec oprogramowania prawnie zastrzeżonego.

Rozważmy GNU Readline – bibliotekę, która została utworzona, żeby umożliwić edycję wiersza poleceń dla BASH. Readline jest opublikowana na zasadach zwykłej GPL, a nie Mniejszej GPL. To prawdopodobnie powoduje rzadsze używanie Readline, co nie jest dla nas żadną stratą. Jak dotąd co najmniej jedna użyteczna aplikacja została uczyniona wolnym oprogramowaniem tylko po to, by mogła korzystać z Readline, a to jest wymierny zysk dla społeczności.

Twórcy oprogramowania prawnie zastrzeżonego mają przewagę, którą dają im pieniądze; przewagą twórców wolnego oprogramowania jest to, że wspierają się nawzajem. Mam nadzieję, że kiedyś będziemy mieli dużą liczbę bibliotek udostępnionych na warunkach GPL, które nie będą miały odpowiedników dostępnych w oprogramowaniu zastrzeżonym. Będą one użytecznymi modułami służącymi do budowy nowych wolnych programów, dającymi znaczne korzyści w dalszym rozwoju wolnego oprogramowania.

Czuły punkt?

Eric Raymond powiedział, że „tworzenie każdego dobrego programu zaczyna się od poruszenia czułego punktu programisty”. Może i zdarza się to czasami, ale wiele istotnych części GNU zostało utworzonych tylko po to, żeby stworzyć kompletny wolny system operacyjny. Ich źródło leży w wizji i planie pracy, a nie twórczym impulsie.

Na przykład Bibliotekę GNU C stworzyliśmy, bo każdy podobny do Uniksa system potrzebuje biblioteki C. BASH powstał, bo system potrzebuje powłoki, a GNU tar, bo system potrzebuje programu tar. To samo dotyczy moich własnych programów – kompilatora GNU C, GNU Emacsa, GDB i GNU Make.

Niektóre programy GNU powstały, by poradzić sobie ze specyficznymi ograniczeniami naszej wolności. Na przykład gzip powstał, żeby zastąpić program Compress, który przepadł dla społeczności z powodu patentów na kompresję LZW. Znaleźli się ludzie, którzy stworzyli LessTif, a ostatnio także GNOME i Harmony, żeby ominąć kłopoty z pewnymi zastrzeżonymi bibliotekami (zobacz poniżej). Rozwijamy GNU Privacy Guard, która ma zastąpić popularne, nie-wolne oprogramowanie szyfrujące, bo użytkownicy nie powinni być zmuszeni do wyboru pomiędzy wolnością a prywatnością.

Oczywiście, ludzie piszący te programy zaangażowali się w swoją pracę, i wiele funkcji dodali, aby zaspokoić swoje własne potrzeby i interesy. Ale to nie jest powodem, dla którego programy te powstały.

Nieoczekiwany rozwój

Kiedy rozpoczynaliśmy projekt GNU wyobrażałem sobie, że stworzymy cały system GNU, a następnie opublikujemy go jako całość. Tak się jednak nie stało.

Ponieważ każdy komponent GNU był tworzony na systemie uniksowym, to także każdy komponent mógł być pod Uniksem uruchamiany, na długo przed powstaniem kompletnego systemu GNU. Niektóre z tych programów stały się popularne, a użytkownicy rozpoczęli ich przenoszenie na różne, niekompatybilne ze sobą wersje Uniksa, a czasem także na inne systemy.

Dzięki temu programy te stały się o wiele potężniejsze, i przyciągały zarówno sponsorów, jak i kolejnych twórców systemu GNU. Prawdopodobnie jednak równocześnie o szereg lat opóźniło ukończenie minimalnej wersji działającego systemu, jako że swój czas twórcy GNU raczej poświęcali wspieraniu implementacji na różne platformy oraz dodawaniu dodatkowych opcji do istniejących komponentów, zamiast na pisaniu, jednego po drugim, kolejnych brakujących elementów.

GNU Hurd

W roku 1990 system GNU był niemal kompletny. Jedynym większym brakującym składnikiem było jądro. Zdecydowaliśmy się zaimplementować nasze jądro jako zestaw procesów uruchamianych na Machu. Mach to mikrojądro opracowane w Carnegie Mellon University, a później na Uniwersytecie Utah; GNU Hurd jest zbiorem serwerów-demonów (czyli „hordą gnu”), które uruchamiają się na Machu i wykonują zadania jądra uniksowego. Prace nad Hurdem zostały opóźnione, bo czekaliśmy na obiecaną publikację Macha jako wolnego oprogramowania.

Jedną z przyczyn wyboru takiej właśnie architektury była chęć uniknięcia tego, co wydawało się najtrudniejszą częścią pracy: debugowanie jądra przy braku debuggera poziomu źródła. Ta część pracy była już wykonana w Machu. Oczekiwaliśmy, że będziemy mogli debugować serwery Hurda jako programy przestrzeni użytkownika, za pomocą GDB. Ale minęło wiele czasu, zanim stało się to możliwe, a wielowątkowe serwery, które wysyłają wiadomości do siebie nawzajem okazały się bardzo trudne do debugowania. Uczynienie Hurda zdolnym do stabilnej pracy przeciągnęło się o wiele lat.

Alix

Jądro systemu GNU oryginalnie nie miało nazywać się Hurd. Jego pierwszą nazwą było Alix – od imienia kobiety, która była wtedy moją miłością. Była administratorem systemu uniksowego. Kiedyś zwróciła uwagę, że jej imię pasuje do zwyczajowej konwencji nazewniczej systemów uniksowych; w żartach powiedziała przyjaciołom: „Ktoś powinien nazwać moim imieniem jądro systemu”. Nic nie powiedziałem, ale postanowiłem zrobić jej niespodziankę nazywając jądro Alix.

Tak się jednak nie stało. Michael (obecnie Thomas) Bushnell, główny twórca jądra, optował za nazwą Hurd, i przedefiniował nazwę Alix – miała odtąd oznaczać pewną część jądra, część, która miała przechwytywać wywołania systemowe i obsługiwać je, wysyłając komunikaty do serwerów HURD-a.

W końcu Alix i ja rozstaliśmy się, a ona zmieniła imię. Niezależnie od tego projekt Hurda zmienił się tak, że biblioteka C wysyłała komunikaty bezpośrednio do serwerów, a to uczyniło element Alix zbędnym.

Ale zanim się to wszystko wydarzyło, jej znajomy natknął się na imię Alix w kodzie źródłowym Hurda i wspomniał jej o tym. Tak że nazwa ta spełniła swoją rolę.

Linux i GNU/Linux

GNU Hurd nie jest jeszcze gotowy do użytku i nie wiemy czy kiedykolwiek będzie. Ponieważ jest zaprojektowane z celem łatwego dostosowania, są problemy bezpośrednio wynikające z tej elastyczności. Nie wiemy czy istnieją rozwiązania tych problemów.

Na szczęście jest dostępne inne jądro. W roku 1991 Linus Torvalds stworzył jądro kompatybilne z Uniksem i nazwał je Linux. Na początku było oprogramowaniem własnościowym, ale w roku 1992 zmienił na wolne oprogramowanie. Połączenie Linuksa z nie-całkiem-gotowym systemem GNU zaowocowało stworzeniem kompletnego wolnego systemu operacyjnego (połączenie ich było, oczywiście, istotną pracą samą w sobie). To dzięki Linuksowi możemy już teraz korzystać z systemu GNU.

Nazywamy tę wersję systemu GNU/Linux aby wyrazić, że to połączenie systemu GNU z Linuksem jako jądro. Prosimy abyście nie popadali w nazywanie całego systemu „Linux”, ponieważ to przypisywanie naszej pracy komuś innemu. Prosimy traktować nas równo.

Wyzwania w naszej przyszłości

Dowiedliśmy naszej zdolności do stworzenia szerokiego spektrum wolnego oprogramowania. Ale to nie znaczy, że jesteśmy niepokonani i niepowstrzymani. Szereg zagrożeń czyni przyszłość wolnego oprogramowania niepewną; stawienie im czoła wymagać będzie wysiłków i wytrwałości, obliczonych na całe lata. Wymagać będzie tego rodzaju determinacji, którą ludzie okazują gdy cenią swoją wolność i nie pozwolą nikomu jej sobie odebrać.

Następne cztery rozdziały omawiają te zagrożenia.

Tajemnice sprzętu

Producenci sprzętu coraz częściej mają zwyczaj utrzymywania w tajemnicy jego specyfikacji. To utrudnia pisanie wolnych sterowników, dzięki którym Linux i XFree86 mogłyby z nim współpracować. Mamy kompletnie wolne systemy operacyjne dzisiaj, ale nie będziemy ich mieli w przyszłości, jeśli nie będą obsługiwać komputerów jutra.

Są dwa sposoby na rozwiązanie tego problemu. Programiści mogą uprawiać „inżynierię wsteczną”, żeby odkryć, jak działa sprzęt. Reszta z nas może wybierać tylko ten sprzęt, który jest obsługiwany przez wolne oprogramowanie; w miarę jak będzie nas przybywać, utrzymywanie specyfikacji w tajemnicy stanie się polityką samobójczą.

Inżynieria wsteczna jest ciężką pracą; czy znajdą się programiści wystarczająco zdeterminowani, żeby ją udźwignąć? Tak, jeśli tylko zbudujemy silne przekonanie, że wolne oprogramowanie jest kwestią zasad, a nie-wolne sterowniki są nie do zaakceptowania. Czy większość z nas wyda dodatkowe pieniądze lub choćby poświęci więcej czasu, żebyśmy mogli korzystać z wolnych sterowników? Tak, jeśli determinacja, żeby być wolnym będzie powszechna [8].

Nie-wolne biblioteki

Niewolna biblioteka stosowana w wolnym systemie operacyjnym działa jak pułapka na twórców wolnego oprogramowania. Atrakcyjne funkcje biblioteki są przynętą, ale jeśli użyjecie jej, wpadniecie w pułapkę, bo Wasz program nie będzie mógł być użyteczny jako część wolnego systemu operacyjnego. (Dokładnie rzecz biorąc, będziemy mogli dołączyć do systemu Wasz program, ale nie będzie działał bez biblioteki). Co gorsza program, który korzysta z prawnie zastrzeżonej biblioteki, może zwabić w pułapkę innych, niczego nie podejrzewających programistów, jeśli stanie się popularny.

Pierwszym przypadkiem tego problemu był w latach 80. zestaw narzędzi Motif. Choć nie było wtedy jeszcze wolnych systemów operacyjnych, stało się jasne jakie problemy sprawi Motif w przyszłości. Projekt GNU odpowiedział na dwa sposoby: prosząc poszczególne projekty wolnego oprogramowania, żeby obsługiwały, prócz występujących w Motifie, także składniki interfejsu użytkownika pochodzące z wolnego zestawu narzędziowego X-ów oraz wzywając do napisania wolnego programu, który mógłby go zastąpić. Ta praca zajęła wiele lat; LessTif, stworzony przez grupę Hungry Programmers [Głodni Programiści], dopiero w roku 1997 stał się wystarczająco rozbudowany dla większości programów dotychczas korzystających ze składników Motifa.

W latach 1996–98 w ważnym zestawie wolnego oprogramowania, desktopie KDE, używano innego nie-wolnego zestawu narzędzi GUI (Graficznego Interfejsu Użytkownika), biblioteki o nazwie Qt.

Wolne systemy GNU/Linux nie mogły korzystać z KDE, ponieważ nie mogliśmy korzystać z tej biblioteki. Tym niemniej niektóre komercyjne dystrybucje systemu GNU/Linux, które nie były tak zasadnicze w kwestii wolności oprogramowania, dodawały KDE do swoich systemów – dając użytkownikom system z większymi możliwościami, ale mniejszą wolnością. Grupa KDE aktywnie zachęcała innych programistów do używania Qt, a miliony nowych „użytkowników Linuksa” nigdy nie zostały uświadomione, że z tym problem. Sytuacja wydawała się ponura.

Społeczność wolnego oprogramowania odpowiedziała na ten problem na dwa sposoby: tworząc GNOME i Harmony.

GNOME [GNU Network Object Model Environment] jest projektem desktopu GNU. Rozpoczął go w roku 1997 Miguel de Icaza, a rozwijany był z pomocą firmy Red Hat Software. GNOME został stworzony, żeby oferować podobne udogodnienia desktopu, ale przy wykorzystaniu wyłącznie wolnego oprogramowania. Miał także techniczną przewagę: wspierał wiele różnych języków programowania, a nie tylko C++. Ale jego głównym przeznaczeniem była zagwarantowanie wolności: nie zmuszał do korzystania z niewolnego oprogramowania.

Harmony jest kompatybilną biblioteką zastępczą, zaprojektowaną, żeby dało się uruchamiać oprogramowanie KDE bez korzystania z Qt.

W październiku 1998 twórcy Qt ogłosili zmianę licencji, która, kiedy zostanie dokonana, powinna uczynić Qt wolnym oprogramowaniem. Nie ma sposobu, żeby się upewnić, ale myślę, że w dużej mierze było to spowodowane zdecydowaną postawą społeczności wobec problemu, jaki przedstawiała sobą Qt, kiedy nie była wolna. (Nowa licencja jest niedogodna i niesprawiedliwa, dlatego rozsądne jest dalsze unikanie Qt [9].)

W jaki sposób zareagujemy na następna ponętną, ale niewolną bibliotekę? Czy cała społeczność zrozumie potrzebę trzymania się z dala od pułapki? Czy może wielu z nas poświęci wolność dla wygody, tworząc przy okazji poważny problem? Nasza przyszłość zależy od naszej filozofii.

Patenty na oprogramowanie

Największym zagrożeniem, z jakim mamy do czynienia, są patenty na oprogramowanie, które mogą odsunąć algorytm czy funkcjonalność poza zasięg wolnego oprogramowania nawet na 20 lat. Wniosek na patent na algorytm kompresji LZW został złożony w roku 1983, a my ciągle nie możemy opublikować wolnego programu do tworzenia poprawnie skompresowanych GIF-ów [10]. W roku 1998 wolny program do tworzenia skompresowanych plików audio MP3 został wycofany z dystrybucji pod groźbą procesu o naruszenie patentu [11].

Są sposoby na radzenie sobie z patentami: możemy szukać dowodów na to, że patent jest nieważny, możemy też szukać alternatywnych sposobów na wykonanie pracy. Każda z tych metod działa tylko czasami; jeśli i jedno i drugie zawiedzie, patent może spowodować, że pewnych funkcji, potrzebnych użytkownikom, będzie brakować we wszystkich wolnych programach. Po długim czekaniu patenty się przedawnią, ale co zrobimy w międzyczasie?

Ci z nas, którzy cenią sobie wolne oprogramowanie ze względu na wolność, jaką ono daje, tak czy inaczej pozostaną przy wolnym oprogramowaniu. Zdołamy wykonać naszą pracę bez opatentowanych funkcji. Ale ci, którzy cenią wolne oprogramowanie, bo oczekują, że będzie ono technicznie doskonalsze, sytuację taką nazwą defektem. Dlatego, choć jest rzeczą pożyteczną rozmawianie o praktycznej efektywności „modelu bazaru” metody rozwoju oprogramowania oraz solidności i sile niektórych wolnych programów, ale nie możemy się na tym zatrzymać. Musimy rozmawiać o wolności i zasadach.

Wolna dokumentacja

Największa wada naszych wolnych systemów operacyjnych nie leży w oprogramowaniu – jest nią brak dobrych, wolnych podręczników, które moglibyśmy dołączyć do naszych systemów. Dokumentacja jest istotną częścią każdej paczki wolnego oprogramowania; jeśli ważny pakiet wolnego oprogramowania nie zawiera dobrej, wolnej instrukcji obsługi, to jest to poważna luka. Mamy dziś wiele takich luk.

Wolna dokumentacja, podobnie jak wolne oprogramowanie, to kwestia wolności, a nie ceny. Kryteria dla wolnych podręczników są bardzo podobne do tych, jakie stosujemy przy wolnym oprogramowaniu: to kwestia nadania wszystkim użytkownikom pewnych wolności. Redystrybucja (włączając w to sprzedaż dla zysku) musi być dozwolona, zarówno on-line, jak i na papierze, tak żeby każdej kopii programu mógł towarzyszyć podręcznik.

Zezwolenie na modyfikacje także jest bardzo ważne. Zasadniczo nie wierzę, żeby była istotna możliwość nanoszenia przez ludzi zmian do wszelkiego rodzaju tekstów czy książek. Nie sądzę, żebyście Wy czy ja byli zobowiązani do zezwalania na modyfikowanie artykułów takich jak ten, który opisuje nasze działania i nasze poglądy.

Ale jest szczególna przyczyna, dla której wolność do modyfikacji jest krytyczna dla dokumentacji wolnego oprogramowania. Kiedy ludzie egzekwują prawo do modyfikacji programów, do dodawania albo zmiany ich funkcji, to jeśli są konsekwentni zmienią także instrukcje – aby wraz ze zmodyfikowanym programem dostarczyć właściwą i użyteczną dokumentację. Podręcznik, który nie zezwala programiście na bycie konsekwentnym i zakończenie pracy, nie zaspokaja potrzeb naszej społeczności.

Niektóre rodzaje ograniczeń określających sposób nanoszenia zmian nie przedstawiają sobą problemu. Na przykład wymogi zachowania oryginalnej noty praw autorskich autora, warunków rozpowszechniania, czy też listy autorów są w porządku. Nie jest także kłopotem wymóg, by modyfikowana wersja zawierała adnotacje o dokonanych modyfikacjach, ani to, że dokument zawiera całe rozdziały, których nie wolno ani usunąć, ani zmienić, o ile rozdziały te dotyczą tematów nietechnicznych. Tego rodzaju ograniczenia nie są problemem, bo nie powstrzymują one konsekwentnego programisty od adaptacji podręcznika tak, aby pasował do zmodyfikowanego programu. Innymi słowy, nie przeszkadzają one społeczności wolnego oprogramowania w pełnym wykorzystaniu podręcznika.

Konieczne jest jednak, żeby można było modyfikować całą „techniczną” zawartość podręcznika, a następnie rozpowszechniać ją na wszystkie zwykłe sposoby, poprzez wszystkie kanały dystrybucji; jeśli ograniczenia będą blokować społeczność, to podręcznik nie będzie wolny, a my będziemy potrzebować innego.

Czy twórcy wolnego oprogramowania mają świadomość i determinację wystarczającą, żeby stworzyć pełen zakres wolnych podręczników? Raz jeszcze: nasza przyszłość zależy od naszej filozofii.

Musimy mówić o wolności

Szacuje się, że jest dzisiaj dziesięć milionów użytkowników systemów GNU/Linux takich jak Debian GNU/Linux czy Red Hat „Linux”. Wolne oprogramowanie ma tyle praktycznych zalet, że użytkownicy zwracają się ku niemu z powodów czysto praktycznych.

Dobre konsekwencje tego faktu są ewidentne: więcej zainteresowanych rozwijaniem wolnego oprogramowania, więcej klientów na rynku wolnego oprogramowania i więcej możliwości do zachęcania firm, żeby rozwijały komercyjne wolne oprogramowanie zamiast prawnie zastrzeżonych produktów informatycznych.

Ale zainteresowanie oprogramowaniem wzrasta szybciej, niż świadomość filozofii, na której jest ono oparte, a to prowadzi do problemów. Nasza zdolność to radzenia sobie z wyzwaniami i zagrożeniami opisanymi powyżej zależy od woli walki o wolność. Żeby upewnić się, że nasza społeczność rzeczywiście ma tę wolę, musimy propagować idee wśród nowych użytkowników, którzy dołączają do naszej społeczności.

To nam się jednak nie udaje: przyciąganie nowych użytkowników do naszej społeczności daleko przewyższyło wysiłki uczenia ich obywatelskich praw, jakimi się rządzimy. Tymczasem musimy robić i jedno, i drugie. Musimy utrzymywać te wysiłki w równowadze.

„Open Source”

Uczenie nowych użytkowników wolności stało się trudniejsze w roku 1998, kiedy część społeczności zadecydowała o zaprzestaniu używania terminu „wolne oprogramowanie”, w zamian proponując termin „otwarte źródło” [Open source].

Części z tych, którzy faworyzowali ten termin, miała na celu uniknięcie mylenia „wolnego” z „darmowym” – to właściwy cel. Jednak inni chcieli odciąć się od duchowych zasad, jakie stały u podstaw ruchu wolnego oprogramowania i projektu GNU, i w zamian przyciągnąć menedżerów oraz użytkowników biznesowych, z których wielu wyznaje poglądy przedkładające zysk ponad wolność, ponad społeczność i ponad zasady. Dlatego retoryka „open source” skupia się na możliwościach tworzenia wysokiej jakości, potężnego oprogramowania, i omija idee wolności, społeczności i zasad.

Czasopisma „Linuksowe” są czystym tego przykładem – są wypełnione reklamami prawnie zastrzeżonego oprogramowania, które współpracuje z GNU/Linuksem. Kiedy pojawi się następny Motif czy Qt, to czy czasopisma te ostrzegą programistów, by trzymały się od nich z daleka, czy też raczej zamieszczą ich reklamy?

Wsparcie biznesu może wzbogacać społeczność na wiele sposobów. Jeśli wszystko inne pozostanie takie samo, jest to przydatne. Ale uzyskiwanie ich wsparcia poprzez przemilczanie kwestii wolności i zasad może być zgubne w skutkach. Pogarsza wspomniany brak równowagi pomiędzy rozpowszechnieniem a obywatelską edukacją.

Terminy „Wolne oprogramowanie” i „open source” opisują mniej więcej ten sam rodzaj oprogramowania, ale mówią różne rzeczy o tym oprogramowaniu, oraz o wartościach, jakie są z nim związane. Projekt GNU trzyma się terminu „wolne oprogramowanie”, żeby wyrazić ideę, że to wolność, a nie tylko technologia, jest istotna.

Spróbuj!

Filozofia Yody („Nie ma próbowania”) brzmi nieźle, ale jak dla mnie nie działa. Większość mojej pracy wykonałem niepokojąc się, czy dam radę to zrobić, niepewny, czy jeśli mi się uda, to czy to wystarczy. Ale tak czy siak próbowałem, ponieważ nie było nikogo poza mną pomiędzy wrogiem i bramami mojego miasta. Co zaskakujące dla mnie samego, czasem udawało mi się wygrać.

Czasem ponosiłem porażki; niektóre z moich miast poddały się. Wtedy szukałem następnego zagrożonego posterunku i gotowałem się do następnej bitwy. Z czasem nauczyłem się wypatrywać zagrożeń, stawać u bram miasta pod bronią, wzywając pozostałych hackerów, żeby mnie wsparli.

Teraz nie jestem jedynym. To ulga i radość widzieć zastępy hackerów okopujących się, by utrzymać pozycje, i zdaję sobie sprawę, że miasto może przetrwać – przez jakiś czas. Ale zagrożenia są z każdym rokiem większe, a ostatnio Microsoft otwarcie zaatakował naszą społeczność. Nie możemy uznać przyszłości naszej wolności za pewną. Nie uważajmy jej za pewną! Jeśli chcemy zachować naszą wolność, musimy być przygotowani do jej obrony.

Przypisy

1. Użycie słowa „hacker” w znaczeniu „komputerowy włamywacz” jest mylne, wina leży tu po stronie mass mediów. My, hackerzy, nie zgadzamy się z takim jego rozumieniem, i dalej używamy terminu hacker rozumianego jako „ktoś, kto kocha programować i czerpie przyjemność z tego, że jest w tym dobry”. Przeczytajcie mój artykuł „On Hacking” [po angielsku].
   Maszyny PDP były wyjątkowo wygodne w hakowaniu ponieważ były wielofunkcyjne, w pełni interaktywne w przeciwieństwie do dużych mainframe-ów i zezwalały na dzielenie się oprogramowaniem i danymi.
2. Jako ateista nie kieruję się wskazaniami żadnego z przywódców religijnych, ale czasem znajduję godnymi podziwu słowa, jakie któryś z nich wypowiedział.
3. W 1984 lub 1985 roku Don Hopkins (znajomy obdarzony wielką wyobraźnią) wysłał mi list. Na jego kopercie wypisał szereg zabawnych sentencji, między innymi następującą: „Copyleft – all rights reversed” [„Copyleft – wszystkie prawa odwrócone”]. Użyłem słowa „copyleft”, żeby nazwać koncepcję dystrybucyjną, jaką rozwijałem w owym czasie.
4. Obecnie dla dokumentacji stosujemy Licencję GNU Wolnej Dokumentacji [GNU Free Documentation License].
5. „Bourne Again Shell” jest żartem z nazwy „Bourne Shell”, który jest standardową powłoką uniksową. [Nieprzetłumaczalna gra słów – w wymowie „Bourne Again” jest podobne do „born again”, „nowo narodzony”, czyli to jest „powłoka nowo narodzona”.]
6. To było napisane w 1998 roku. Od 2009 już nie utrzymujemy długiej listy zadań. Wolne oprogramowanie jest rozwijane przez społeczność tak szybko, że niemożliwe byłoby wszystko śledzić. W zamian trzymamy listę Projektów o wysokim priorytecie [High Priority Projects]. Jest to krótsza lista projektów, na których nam zależy.
7. Licencja ta początkowo nosiła nazwę GNU Library General Public License [Licencja Publiczna do Bibliotek GNU], ale zmieniliśmy nazwę, żeby nie podsuwała sugestii, że wszystkie biblioteki powinny z niej korzystać. Zobaczcie także tekst „Czemu nie powinniście stosować Mniejszego GPL dla kolejnej biblioteki” aby się dowiedzieć więcej.
8. Notatka z 2008 r.: to dotyczy także BIOSu. Jest wolny BIOS, LibreBoot (dystrybucja coreboot); głównym wyzwaniem jest zdobyciem specyfikacji maszyn, aby LibreBoot mógł je wspierać bez niewolnych „blobów”.
9. We wrześniu 2000 Qt została opublikowana na warunkach GNU GPL, co zasadniczo rozwiązało ten problem.
10. W 2009 roku patenty na GIF wygasły.
11. W 2017 roku patenty na MP3 wygasły. Sami widzicie jak długo musieliśmy czekać.