Tłumaczenia tej strony
Autor: Richard Stallman
(wersja z 24 kwietnia 1992)
Fakt istnienia programów komputerowych w nieunikniony sposób otwiera kwestię sposobu podejmowania decyzji co do ich użytkowania. Wyobraźmy sobie na przykład, że ktoś posiadający kopię programu spotyka kogoś, kto takową kopię chciałby mieć. Mają oni przy tym możliwość jej zrobienia. Kto powinien decydować o tym, czy będzie ona rzeczywiście wykonana? Zainteresowane osoby? A może ktoś inny, nazywany „właścicielem”?
Twórcy programów zwykle rozważają te pytania zakładając, że odpowiednie kryterium dla ich rozstrzygnięcia to maksymalizowanie ich zysków. Polityczne wpływy biznesu doprowadziły do tego, że rząd przyjął zarówno to kryterium, jak również rozstrzygnięcie wysunięte przez twórców, które mówi, że program ma właściciela, zazwyczaj korporację zaangażowaną w jego rozwój.
Chciałbym rozważyć te same pytania używając innego kryterium: dobrobytu i wolności całego społeczeństwa.
O rozstrzygnięciu tych kwestii nie może decydować dzisiejsze prawo, jako że prawo powinno dostosowywać się do zasad etycznych, a nie na odwrót. Nie rozstrzygają ich także obecne praktyki, chociaż mogą one zasugerować możliwe rozwiązania. Jedynym sposobem na rozstrzygnięcie jest stwierdzenie kto zyskuje, a kto traci na uznawaniu praw właścicieli oprogramowania, a także dlaczego i w jakim stopniu. Innymi słowy, powinniśmy przeprowadzić analizę zysków i strat w imieniu całego społeczeństwa, uwzględniając w niej wolność jednostek oraz produkcję dóbr materialnych.
Zamierzam w tym eseju opisać rezultaty, jakie niesie za sobą uznawanie właścicieli i pokazać, że są one szkodliwe. Udowodnię, że programiści powinni zachęcać innych do redystrybucji i dzielenia się pisanymi przez nas programami, do ich studiowania i ulepszania. Innymi słowy, powinni pisać „wolne” oprogramowanie.[1]
Ludzie korzystający na obecnym systemie, w którym programy są własnością, przedstawiają dwa argumenty na poparcie swoich roszczeń: emocjonalny i ekonomiczny.
Argument emocjonalny brzmi tak: „Przelałem w ten program swój pot, serce i duszę. Ja go stworzyłem, jest mój!”
Ten argument nie jest trudny do odparcia. Uczucie przywiązania programiści mogą w sobie pielęgnować gdy jest im to na rękę, nie jest czymś nieodłącznym. Zwróćmy na przykład uwagę, z jaką chęcią ci sami programiści zrzekają się zazwyczaj wszystkich swoich praw na rzecz jakiejś dużej korporacji, gdy im się za to zapłaci – przywiązanie emocjonalne znika jak za dotknięciem czarodziejskiej różdżki. Spójrzmy dla odmiany na wielkich artystów i rzemieślników średniowiecza, którzy nawet nie podpisywali swoich prac. Dla nich nazwisko twórcy nie miało znaczenia. Ważne było dzieło oraz fakt, że jest gotowe, a także funkcja, którą pełniło. Taki pogląd panował przez setki lat.
Argument ekonomiczny brzmi następująco: „Chcę być bogaty (zazwyczaj nieprecyzyjnie mówią „chcę mieć się z czego utrzymać”), a jeśli nie dacie mi się wzbogacić na programowaniu, to nie będę tego robił. Wszyscy myślą jak ja, więc nikt nie będzie programował. A wtedy zostaniecie bez żadnych programów!” Ta pogróżka występuje zwykle pod przykrywką przyjacielskiej rady od mądrzejszego.
Wyjaśnię później, dlaczego ta pogróżka to blef. Najpierw chcę się zająć pewnym domyślnym założeniem, które jest bardziej widoczne w innym sformułowaniu tego argumentu.
Sformułowanie to zaczyna się od porównania stopnia społecznej użyteczności programów objętych restrykcyjną licencją i braku programów. Następnie dochodzi się w nim do wniosku, że tworzenie oprogramowania objętego taką licencją jest w sumie korzystne i powinno się je popierać. Błąd tkwi tutaj w porównywaniu tylko dwóch rozwiązań – oprogramowanie objęte licencją albo brak oprogramowania – i zakładaniu, że inne możliwości nie istnieją.
Jeśli istnieje system praw autorskich obejmujący oprogramowanie, to pisanie programów związane jest zazwyczaj z istnieniem właściciela kontrolującego sposób, w jaki programy są używane. Tak długo, jak istnieje ten związek, musimy często wybierać pomiędzy oprogramowaniem objętym restrykcyjną licencją a brakiem oprogramowania. Ten związek nie jest jednak nieodłączny ani nieunikniony, jest konsekwencją konkretnej decyzji społecznej lub prawnej, którą poddajemy tutaj w wątpliwość: decyzji o uznawaniu właścicieli. Formułowanie całej kwestii jako wyboru pomiędzy oprogramowaniem objętym licencją a brakiem oprogramowania to przyjmowanie za prawdziwe czegoś, co nie zostało udowodnione.
Bieżąca kwestia brzmi: Czy rozwój oprogramowania powinien być powiązany z istnieniem właścicieli, którzy ograniczają jego użytkowanie?
Aby ją rozstrzygnąć, musimy osobno ocenić społeczne efekty obu tych rzeczy: tworzenia oprogramowania (niezależnie od warunków jego dystrybucji) oraz ograniczania jego użytkowania (zakładając, że zostało ono stworzone). Jeśli jedna z nich daje użyteczne rezultaty, a druga jest szkodliwa, to korzystniejsze dla nas byłoby przerwanie związku między nimi i kontynuowanie tylko tej pierwszej.
Innymi słowy, jeśli ograniczanie użytkowania istniejącego programu jest szkodliwe dla całego społeczeństwa, to postępujący etycznie programista nie będzie tego robił.
Żeby ustalić skutki, które niesie za sobą ograniczanie dzielenia się programami, musimy porównać wartość, jaką przedstawia dla społeczeństwa program ograniczony (tzn. objęty restrykcyjną licencją) z wartością tego samego programu, tyle że wolnego. Oznacza to porównanie dwóch alternatywnych światów.
Ta analiza dotyka również pojawiającego się czasami prostego kontrargumentu, który mówi, że „korzyść, jaką odnoszą znajomi z tytułu dzielenia się z nimi programami jest równoważona przez szkodę, którą ponosi przez to właściciel”. Kontrargument ten zakłada, że korzyść i szkoda są równe w swej wielkości. Niniejsza analiza zawiera ich porównanie i wykazuje, że korzyść jest dużo większa.
Żeby rozjaśnić całe rozumowanie, przyłóżmy je do innej dziedziny: budowy dróg.
Można by finansować budowę wszystkich dróg poprzez pobieranie opłat za przejazd. Pociągałoby to za sobą konieczność umieszczenia na każdym rogu budek pobierających opłaty. Taki system przynosiłby duże środki na ulepszanie dróg. Miałby jeszcze jedna zaletę: zmuszałby użytkowników każdej drogi do płacenia za przejazd. Budki są jednak sztuczną przeszkodą i zakłócają płynną jazdę. Sztuczną, bo nie ma żadnego związku między nimi a sposobem w jaki działają drogi i samochody.
Gdy porównujemy bezpłatne i płatne drogi pod kątem użyteczności okazuje się, że chociaż oba rodzaje są takie same pod każdym innym względem, to te pierwsze są tańsze do zbudowania, tańsze w utrzymaniu i bardziej efektywne w użyciu.[2] W ubogim kraju opłaty za drogi uczyniłyby je niedostępnymi dla wielu obywateli. Drogi bezpłatne oferują zatem społeczeństwu więcej korzyści po mniejszej cenie, są więc z jego punktu widzenia bardziej pożądane. Dlatego też społeczeństwo powinno znaleźć sposób na finansowanie dróg inny niż budki pobierające opłaty. Używanie dróg, gdy są już zbudowane, powinno być darmowe.
Gdy zwolennicy budek pobierających opłaty przedstawiają je jako zaledwie pewien sposób zdobywania funduszy, zaciemniają obraz innych dostępnych możliwości. Budki rzeczywiście przynoszą fundusze, ale robią też coś jeszcze: w rezultacie obniżają wartość drogi. Droga płatna nie jest tak dobra jak darmowa. Budowanie większej ilości dróg, lub technicznie lepszych dróg, wcale nie musi być krokiem do przodu, jeśli oznacza zastąpienie dróg darmowych płatnymi.
Za budowę darmowej drogi trzeba oczywiście zapłacić i koszty te społeczeństwo musi w jakiś sposób ponieść. Jednak nie skazuje to nas na budki pobierające opłaty. Skoro i tak musimy płacić, to dostaniemy za te same pieniądze więcej, jeśli kupimy drogę darmową.
Nie twierdzę, że droga płatna jest gorsza od braku dróg. Byłoby to prawdą, gdyby opłaty były tak duże, że prawie nikt by z dróg nie korzystał, ale takie postępowanie instytucji zbierających opłaty nie jest zbyt prawdopodobne. Dopóki jednak budki pobierające opłaty powodują znaczne marnotrawstwo i niewygodę, lepiej jest zbierać fundusze w sposób sprawiający mniej trudności.
Żeby zastosować to samo rozumowanie do programów komputerowych, pokażę teraz, że istnienie „budek pobierających opłaty” dla użytecznego oprogramowania kosztuje społeczeństwo bardzo wiele: powoduje, że rozwój i dystrybucja programów są bardziej kosztowne, a ich użytkowanie jest mniej satysfakcjonujące i efektywne. Wynikiem będzie stwierdzenie, że tworzenie programów powinno być motywowane w inny sposób. Następnie zaprezentuję inne metody motywowania i finansowania (w rzeczywiście potrzebnym zakresie) rozwoju oprogramowania.
Wyobraźmy sobie, że został napisany jakiś program i poniesione zostały wszelkie związane z tym procesem koszty. Teraz społeczeństwo musi zadecydować, czy uczynić go prawnie zastrzeżonym, czy też pozwolić na jego swobodną dystrybucję i użytkowanie. Przyjmijmy, że istnienie tego programu oraz jego dostępność są pożądane.[3]
Ograniczenia nałożone na dystrybucję i modyfikacje tego programu nie mogą ułatwiać jego użytkowania, a jedynie w nim przeszkadzać. Tak więc rezultat może być wyłącznie negatywny. Ale w jakim stopniu? I w jaki sposób?
Z utrudnień takiego rodzaju wynikają trzy poziomy materialnych szkód:
Każdy z poziomów szkód materialnych ma towarzyszącą formę szkód psychospołecznych. Mowa jest tutaj o skutkach, jakie podejmowane przez ludzi decyzje mają na ich późniejsze uczucia, postawy i skłonności. Te zmiany w ludzkim sposobie myślenia będą potem miały dalszy wpływ na ich relacje ze współobywatelami i mogą pociągnąć za sobą materialne konsekwencje.
Trzy poziomy szkód materialnych marnują część wartości, jaką mógłby wnieść do społeczeństwa program, ale nie mogą zredukować jej do zera. Jeśli marnują niemal całą wartość programu, to jego napisanie szkodzi społeczeństwu co najwyżej przez wysiłek, jaki został w to włożony. Jest kwestią sporną, czy program, który opłaca się sprzedawać musi dawać jakieś bezpośrednie materialne korzyści.
Biorąc jednak pod uwagę idące w parze szkody psychospołeczne, nie ma żadnej granicy dla szkód, jakie może przynieść rozwój objętego restrykcyjnymi licencjami oprogramowania.
Pierwszy poziom szkód utrudnia najzwyklejsze użytkowanie programu. Wykonanie kopii programu to prawie żaden koszt (szczególnie, że można to zrobić samemu), więc na wolnym rynku cena kopii byłaby bliska zeru. Opłata licencyjna to czynnik znacząco zniechęcający do używania danego programu. Jeśli jakiś użyteczny dla szerokich rzesz ludzi program jest objęty restrykcyjną licencją, to będzie go używać o wiele mniej osób niż by chciało.
Łatwo wykazać, że całkowity wkład programu na rzecz społeczeństwa jest zmniejszany przez przydzielenie mu właściciela. Każdy potencjalny użytkownik tego programu, który zetknie się z koniecznością płacenia za jego używanie, może zdecydować się zapłacić lub zrezygnować z korzystania z niego. Jeśli zdecyduje się zapłacić, to saldo operacji wynosi zero: materialnie korzysta właściciel, a użytkownik zyskuje prawo do korzystania z programu. Tymczasem za każdym razem, gdy ktoś decyduje się zrezygnować z używania jakiegoś programu, to dzieje się mu krzywda, a korzyści nie odnosi nikt. Suma liczb ujemnych i zer zawsze jest ujemna.
Ale to nie zmniejsza ilości pracy, którą trzeba włożyć w rozwój programu. W rezultacie zredukowana jest efektywność całego procesu mierzona w dostarczonej użytkownikowi satysfakcji na godzinę pracy.
To odzwierciedla bardzo ważną różnicę pomiędzy kopiami programów a kopiami samochodów, krzeseł lub kanapek. Poza science fiction nie istnieje kopiarka obiektów materialnych. Programy dają się jednak łatwo kopiować, każdy może niewielkim wysiłkiem wyprodukować tyle kopii, ile jest mu potrzebnych. Nie jest tak w przypadku obiektów materialnych, bo obowiązuje prawo zachowania masy: każdą kopię trzeba zbudować z surowców w taki sam sposób, w jaki zbudowano oryginał.
W przypadku obiektów materialnych zniechęcanie do ich używania ma sens, ponieważ mniejsza ilość kupionych przedmiotów oznacza mniejszą ilość surowców i pracy potrzebnych do ich zrobienia. Prawdą jest, że zazwyczaj również istnieje koszt początkowy, koszt rozwoju, który rozkłada się na cały proces produkcji. Ale tak długo, jak koszty produkcji jednej jednostki są znaczne, dodawanie części kosztów rozwoju nie robi jakościowej różnicy. I nie wymaga ograniczania wolności zwykłych użytkowników.
Jednak nakładanie ceny na coś, co w innym przypadku byłoby darmowe, to zmiana jakościowa. Centralnie nałożona na dystrybucję oprogramowania cena ma potężne działanie zniechęcające.
Co więcej, praktykowana obecnie scentralizowana produkcja jest nieefektywna nawet w kwestii dostarczania kopii oprogramowania. Na taki system składa się umieszczanie fizycznych dyskietek lub taśm w nikomu niepotrzebnych opakowaniach, rozsyłanie ich po całym świecie i magazynowanie w celu sprzedaży. Ten koszt przedstawiany jest jako nieodłączne wydatki związane z robieniem interesów, a tak naprawdę jest częścią marnotrawstwa powodowanego przez istnienie właścicieli.
Załóżmy, że dla ciebie i twojego znajomego użyteczny byłby pewien program. W etycznej trosce o znajomego powinieneś uważać, że prawidłowe rozwiązanie tej sytuacji pozwoli wam obu go używać. Pomysł, żeby pozwolić tylko jednemu z was na używanie tego programu i zabronić tego samego drugiemu, tworzy podziały. Ani ty, ani twój znajomy nie powinniście tego akceptować.
Podpisanie typowej umowy licencyjnej oznacza zdradzenie znajomego: „Obiecuję pozbawić mojego znajomego dostępu do tego programu, żebym mógł mieć kopię tylko dla siebie”. Ludzie, którzy podejmują takie decyzje, czują wewnętrzną psychologiczną presję, by je usprawiedliwić poprzez bagatelizowanie znaczenia pomagania swoim znajomym, więc duch społeczny na tym traci. Jest to psychospołeczna szkoda powiązana z materialną szkodą wynikającą ze zniechęcania do używania programu.
Wielu użytkowników podświadomie zdaje sobie sprawę, że odmawianie dzielenia się jest niewłaściwe, więc decydują się ignorować licencje oraz prawa i dzielić się programami pomimo ich istnienia. Mają jednak często poczucie winy. Wiedzą, że musza łamać prawo, żeby być dobrymi znajomymi, ale uznają zwierzchność prawa i dochodzą do wniosku, że bycie dobrym znajomym (a takimi są) jest nieprzyzwoite lub hańbiące. To także jest jeden z rodzajów szkód psychospołecznych, ale można ich uniknąć poprzez powiedzenie sobie, że te licencje i prawa nie mają żadnej mocy moralnej.
Programiści także odnoszą szkody psychospołeczne wiedząc, że wielu użytkowników nie będzie miało szansy skorzystać z owoców ich pracy. To prowadzi do cynicznych postaw lub zaprzeczania prawdzie. Programista może entuzjastycznie opisywać pracę, która jest dla niego fascynująca pod względem technicznym. Potem, kiedy spytamy go „Czy będę mógł tego używać?”, rzednie mu mina i przyznaje, że odpowiedź jest negatywna. Aby nie czuć się zniechęcony, albo przez większość czasu ignoruje ten fakt, albo przyjmuje cyniczną postawę, żeby zbagatelizować znaczenie całej sprawy.
Od czasów Reagana w USA najbardziej brakuje nie innowacji technologicznych, ale raczej skłonności do wspólnej pracy na rzecz społeczeństwa. Nie ma sensu sprzyjać pierwszemu kosztem tego drugiego.
Drugim poziomem szkód materialnych jest niemożność dostosowywania programów do własnych potrzeb. Łatwość modyfikacji oprogramowania jest jego wielką przewagą nad starszymi technologiami. Tymczasem w większości komercyjnie dostępnego oprogramowania nie można wprowadzać przeróbek, nawet gdy się je kupi. Możecie je brać albo nie, jak czarną skrzynkę, której wnętrze pozostaje tajemnicą – i tyle.
Program, który można uruchomić składa się z ciągów liczb, których znaczenie jest nieznane. Nikt, nawet dobry programista, nie może łatwo pozmieniać tych numerów tak, żeby program robił coś innego.
Programiści standardowo pracują z „kodem źródłowym” programów, który zapisany jest w jednym z języków programowania jak Fortran lub C. Używa się w nim nazw do wskazywania używanych danych oraz części programu, a operacje takie jak dodawanie i odejmowanie reprezentowane są przez symbole typu '+' i '-'. Wszystko to jest zaprojektowane po to, by ułatwić programistom czytanie i modyfikowanie programów. Poniżej znajduje się przykład, program do obliczania odległości pomiędzy dwoma punktami na płaszczyźnie:
float distance (p0, p1) struct point p0, p1; { float xdist = p1.x - p0.x; float ydist = p1.y - p0.y; return sqrt (xdist * xdist + ydist * ydist); }
A tutaj jest ten sam program w formie wykonywalnej z komputera, którego na co dzień używam:
1314258944 -232267772 -231844864 1634862 1411907592 -231844736 2159150 1420296208 -234880989 -234879837 -234879966 -232295424 1644167167 -3214848 1090581031 1962942495 572518958 -803143692 1314803317
Kod źródłowy jest przydatny (przynajmniej potencjalnie) dla każdego użytkownika programu. Jednak większości użytkowników odmawia się do niego dostępu. Zazwyczaj kod źródłowy objętego restrykcyjną licencją programu jest trzymany w ukryciu przez właściciela, żeby tylko ktoś się z niego czegoś nie nauczył. Użytkownicy dostają tylko pliki zawierające niezrozumiałe numery, które wykonuje komputer. Oznacza to, że tylko właściciel programu może go modyfikować.
Kiedyś znajoma opowiadała mi, jak przez pół roku pracowała jako programistka w banku, pisząc program podobny do czegoś, co było komercyjnie dostępne. Twierdziła, że jeśli mogłaby wtedy dostać kod źródłowy tamtego komercyjnego programu, to bez trudu mogłaby go zaadaptować dla swoich potrzeb. Bank gotów był za to zapłacić, ale nie wyrażono na to zgody – kod źródłowy był tajemnicą. Tak więc musiała spędzić pół roku na bezsensownej pracy, która wlicza się do PKB pomimo tego, że tak naprawdę jest marnotrawstwem.
Laboratorium Sztucznej Inteligencji MIT dostało około 1977 roku w prezencie od Xeroksa graficzną drukarkę. Była ona obsługiwana przez wolne oprogramowanie, do którego dodaliśmy wiele przydatnych funkcji. Na przykład powiadamiało ono użytkownika o zakończeniu wydruku. Jeśli z drukarką było coś nie tak, zaciął się lub skończył papier, to oprogramowanie natychmiast powiadamiało o tym wszystkich użytkowników, których dokumenty czekały w kolejce na wydruk. Dzięki tym funkcjom praca była płynna.
Potem Xerox podarował Laboratorium nowszą, szybszą drukarkę, jedną z pierwszych drukarek laserowych. Była ona obsługiwana przez objęte restrykcyjną licencją oprogramowanie, które działało na specjalnie do tego przeznaczonym, osobnym komputerze, więc nie mogliśmy dodać żadnej z naszych ulubionych funkcji. Mogliśmy napisać program, który powiadamiał o wysłaniu wydruku do tego specjalnego komputera, ale nie mogliśmy wysyłać powiadomień po rzeczywistym zakończeniu wydruku (tymczasem czas między jednym a drugim był zazwyczaj dość długi). Nie było żadnej możliwości sprawdzenia, czy wydruk się rzeczywiście zakończył, można było tylko zgadywać. Poza tym nikt nie był powiadamiany, gdy zaciął się papier, więc często drukarka stała godzinę w oczekiwaniu na usunięcie usterki.
Programiści systemowi w Laboratorium mogli naprawić takie problemy prawdopodobnie tak samo dobrze jak pierwotni autorzy programu. Xeroksa to nie interesowało i nie pozwolili nam tego zrobić, więc musieliśmy się z problemami pogodzić. Nigdy się z nimi nie uporano.
Większość dobrych programistów zna to uczucie frustracji. Bank było stać na rozwiązanie problemu przez napisanie programu od nowa, ale typowy użytkownik, bez względu na swoje umiejętności, może się tylko poddać.
Poddawanie się wyrządza szkody psychospołeczne duchowi samodzielności. Życie w domu, którego nie możesz przebudować i dostosować do swoich potrzeb jest demoralizujące. Prowadzi do rezygnacji i zniechęcenia, co może się przenieść na inne aspekty życia. Ludzie, którzy się tak czują, są nieszczęśliwi i nie pracują dobrze.
Wyobraźcie sobie, co by się działo, gdyby przepisy kulinarne były strzeżone tak jak oprogramowanie. Moglibyście się spytać „Jak zmienić ten przepis, by pozbyć się soli?”, a wspaniały kucharz powiedziałby „Jak śmiesz obrażać mój przepis, dziecię mego umysłu i podniebienia, próbując przy nim majstrować? Nie masz pojęcia, jak zmienić mój przepis bez zepsucia go!”.
„Ale mój lekarz mówi, że nie powinienem jeść soli! Co mam zrobić? Czy zmienisz dla mnie ten przepis tak, żeby nie było w nim soli?”
„Z chęcią to zrobię, opłata wynosi jedynie 50 tys. dolarów”. Opłata zazwyczaj jest duża, bo właściciel ma monopol na zmiany. „Jednak obecnie nie mam czasu. Jestem zajęty zleceniem opracowania nowego przepisu na suchary dla Departamentu Marynarki. Mogę się zająć twoją sprawą za jakieś dwa lata”.
Trzeci poziom szkód materialnych dotyka rozwoju oprogramowania. Był on kiedyś procesem ewolucyjnym, w czasie którego programista brał istniejący już program i przepisywał jego części w celu dodania jednej nowej funkcji, a potem ktoś inny przepisywał inne części żeby dodać kolejne funkcje. W niektórych przypadkach ciągnęło się to przez dwadzieścia lat. W tym samym czasie na podstawie innych części tego programu tworzono podwaliny nowych projektów.
Istnienie właścicieli uniemożliwia taką ewolucję i powoduje, że pisząc program trzeba zaczynać od zera. Odbiera także nowym programistom szansę studiowania istniejących programów w celu nauczenia się użytecznych technik oraz sposobów konstruowania dużych programów.
Właściciele są też przeszkodą na drodze edukacji. Zdarzało mi się spotkać obiecujących studentów informatyki, którzy w życiu nie widzieli kodu źródłowego dużego programu. Mogą być dobrzy w pisaniu małych programów, ale nie są w stanie zacząć uczyć się odmiennych umiejętności pisania dużych, jeśli nie mogą zobaczyć, jak zrobili to inni.
Na każdym polu pracy intelektualnej można osiągnąć więcej stojąc na ramionach gigantów. Jednak nie ma już na to ogólnego przyzwolenia przy pisaniu programów – możecie stać tylko na ramionach ludzi ze swojej firmy.
Związane z tym szkody psychospołeczne dotykają ducha naukowej kooperacji, który kiedyś był tak silny, że naukowcy współpracowali ze sobą nawet kiedy ich państwa były w stanie wojny. To w tym duchu japońscy oceanografowie, opuszczający swoje laboratorium na wysepce na Pacyfiku, starannie zachowali wyniki swojej pracy dla atakujących amerykańskich marines i zostawili im notatkę z prośbą, żeby dobrze się tym wszystkim zaopiekowali.
Wojna o zyski zniszczyła to, co wojna światowa oszczędziła. W dzisiejszych czasach naukowcy wielu dziedzin nie zawierają w swoich artykułach wystarczająco informacji, żeby inni mogli powtórzyć ich eksperymenty. Publikują tylko tyle, żeby inni mogli podziwiać, jak wiele udało im się zrobić. To z pewnością ma miejsce w informatyce, gdzie kod źródłowy opisywanych programów jest zazwyczaj tajemnicą.
Mówiłem tutaj o skutkach, jakie przynosi zabranianie ludziom kopiowania i modyfikowania programów, oraz budowania oprogramowania na bazie innych projektów. Nie sprecyzowałem, w jaki sposób takie utrudnianie może być przeprowadzone, bo nie ma to wpływu na wnioski. Nieważne, czy robi się to przez zabezpieczenia przed kopiowaniem, prawa autorskie, licencje, szyfrowanie, karty ROM, czy sprzętowe numery seryjne – jeśli skutecznie przeszkadza to w użytkowaniu, jest to szkodliwe.
Użytkownicy uważają niektóre z tych metod za bardziej nieznośne od innych. Wydaje mi się, że najbardziej znienawidzone metody to te, które są skuteczne.
Pokazałem, jak własność programu, czyli możliwość ograniczania jego kopiowania i modyfikacji, stwarza utrudnienia. Ich negatywne efekty są szerokie i znaczące. Wynika z tego, że w społeczeństwie nie powinni istnieć właściciele programów.
Innym sposobem na zrozumienie tego wszystkiego może być to, że społeczeństwo potrzebuje swobodnego oprogramowania, a programy objęte restrykcyjnymi licencjami są jego marnymi substytutami. Popieranie substytutów nie jest racjonalną drogą do osiągnięcia naszych celów.
Vaclav Havel powiedział, że powinniśmy „pracować na rzecz jakiejś sprawy, bo jest ona dobra, a nie tylko dlatego, że ma szansę powodzenia”. Firma wytwarzająca objęte licencją oprogramowanie ma szansę powodzenia w wąskim tego słowa znaczeniu, ale nie jest to coś dobrego dla społeczeństwa.
Jeśli wyeliminujemy prawo autorskie jako zachętę do rozwijania oprogramowania, to na początku będzie się tworzyć mniej programów, ale będą one bardziej użyteczne. Nie jest jasne, czy ogólna dostarczona użytkownikowi satysfakcja będzie mniejsza; ale jeśli taka będzie, lub jeśli chcemy ją i tak powiększyć, to są inne metody zachęcania do pisania programów, tak samo jak oprócz budek pobierających opłaty są inne metody zbierania pieniędzy na drogi. Zanim powiem jak można to zrobić, chcę zbadać, jak duża zewnętrzna zachęta jest rzeczywiście potrzebna.
Są takie prace, których mało kto się podejmie w zamian za coś innego niż pieniądze, np. roboty drogowe. Są też inne dziedziny nauki i sztuki, w których są małe szanse wzbogacenia się, a w które ludzie wchodzą z powodu swoich fascynacji lub dlatego, że postrzegają je jako wartościowe dla społeczeństwa. Mam tu na myśli np. logikę matematyczną, muzykę klasyczną i archeologię, a także tworzenie organizacji politycznych wśród ludzi pracy. Ludzie konkurują ze sobą, bardziej smutno niż zaciekle, o parę opłacanych etatów, z których żaden nie jest opłacany zbyt dobrze. Czasami ludzie nawet płacą za szansę pracowania w takiej dziedzinie, jeśli ich na to stać.
Taka dziedzina może się błyskawicznie zmienić jeśli zacznie stwarzać możliwości zarobienia dużych pieniędzy. Kiedy jeden pracownik staje się bogaty, inni domagają się takiej samej możliwości. Wkrótce wszyscy mogą zacząć domagać się dużych sum pieniędzy za coś, co niegdyś robili dla przyjemności. Po paru latach później wszyscy powiązani z tą dziedziną będą wyśmiewać się z pomysłu, że można było w niej pracować bez dużych zysków finansowych. Będą doradzać planistom, żeby zapewnili te zyski poprzez rekomendowanie specjalnych przywilejów, praw i monopoli do tego potrzebnych.
Taka zmiana nastąpiła w dziedzinie programowania komputerowego w ciągu ostatniej dekady. Piętnaście lat temu ukazywały się artykuły o „komputerowym uzależnieniu”: użytkownicy przyklejali się do komputerów i wydawali na swój nałóg po sto dolarów tygodniowo. Panowało ogólne przekonanie, że ludzie kochają programowanie tak bardzo, że poświęciliby dlań swoje małżeństwo. Dzisiaj panuje ogólne przekonanie, że nikt nie będzie programował, chyba że za duże pieniądze. Ludzie zapomnieli, w co wierzyli piętnaście lat temu.
Jeśli w danym okresie prawdą jest, że w pewnej dziedzinie ludzie będą pracować tylko za duże pieniądze, to nie musi to na zawsze pozostać prawdą. Pęd zmian może biec w odwrotnym kierunku, jeśli impuls do tego da społeczeństwo. Jeśli odbierzemy możliwość zbicia fortuny, to po pewnym czasie ludzie zmodyfikują swoje postawy i znów będą chętni pracować w tej dziedzinie w zamian za radość zawodowego spełnienia.
Pytanie „Jak możemy zapłacić programistom?” stanie się łatwiejsze, gdy zdamy sobie sprawę, że nie chodzi tutaj o płacenie im fortuny. Pieniądze na zwykłą pensję łatwiej jest zdobyć.
Instytucje płacące programistom nie muszą być firmami programistycznymi. Istnieje już wiele innych instytucji, które mogą to robić.
Producenci sprzętu uważają wspieranie rozwoju oprogramowania za bardzo ważne, nawet jeśli nie mogą kontrolować jego użycia. W 1970 większość ich oprogramowania była swobodna, bo nawet nie myśleli o ograniczaniu jego użycia. Dzisiaj ich wzrastająca chęć do przyłączania się do konsorcjów pokazuje, że zdali sobie sprawę z tego, iż posiadanie oprogramowania nie jest tym, co jest dla nich rzeczywiście ważne.
Wiele przedsięwzięć programistycznych prowadzą uniwersytety. Dzisiaj często sprzedają ich rezultaty, chociaż nie robiły tego w latach 70. Czy nie jest oczywiste, że uniwersytety rozwijałyby wolne oprogramowanie, jeśli nie miałyby pozwolenia na sprzedaż programów? Projekty te mogłyby być wspierane przez te same kontrakty i granty rządowe, które teraz wspierają rozwój oprogramowania objętego restrykcyjnymi licencjami.
W dzisiejszych czasach powszechne są sytuacje, w których uniwersytetom przyznaje się granty na rozwój jakiegoś systemu, a one rozwijają go prawie do końca i mówią, że jest „gotowy”. Następnie zakładają firmy, które rzeczywiście go kończą i czynią zdatnym do użytkowania. Czasami deklarują oni, że wersja niedokończona jest „wolna”. Jeśli są źli do szpiku kości, to zamiast tego zdobywają od uniwersytetu wyłączną licencję. Nie jest to tajemnicą. Zainteresowani tym faktem otwarcie to przyznają. Jednak gdyby naukowcy nie byli kuszeni przez możliwość robienia takich rzeczy, to i tak nadal kontynuowaliby badania naukowe.
Programiści tworzący wolne oprogramowanie mogą zarabiać na życie sprzedając usługi związane ze swoimi programami. Zatrudniono mnie, bym napisał wersję GNU C Compiler dla nowej platformy sprzętowej i żebym stworzył rozszerzenia interfejsu użytkownika dla GNU Emacsa. (Oddaję te ulepszenia w ręce społeczeństwa jak tylko są gotowe). Poza tym zarabiam na prowadzeniu zajęć uniwersyteckich.
Nie tylko ja pracuję w ten sposób. Sukces odnosi teraz i rośnie w siłę korporacja, która nie wykonuje żadnych innych prac. Kilka innych firm także dostarcza komercyjne usługi związane z wolnym oprogramowaniem systemu GNU. To początek niezależnej branży wsparcia programistycznego, która może stać się dość duża, jeśli wolne oprogramowanie stanie się popularniejsze. Daje ona użytkownikom wybór normalnie niedostępny w przypadku oprogramowania objętego restrykcyjnymi licencjami, nie licząc bardzo bogatych.
Nowe instytucje, takie jak Fundacja Wolnego Oprogramowania, także mogą finansować programistów. Większość funduszy Fundacji pochodzi od użytkowników, którzy kupują wysyłkowo taśmy. Oprogramowanie zawarte na taśmach jest wolne, więc każdy użytkownik ma prawo je kopiować i modyfikować, ale wielu z nich i tak płaci za swoje kopie. (Przypominam, że „free software” to oprogramowanie wolne, a nie darmowe). Niektórzy użytkownicy, którzy mają już kopie, zamawiają taśmy żeby nas wesprzeć, bo uważają, że na to zasługujemy. Fundacja otrzymuje także pokaźne darowizny od producentów sprzętu.
Fundacja Wolnego Oprogramowania jest organizacją charytatywną, a jej dochody przeznaczane są na zatrudnienie tak wielu programistów, jak tylko się da. Jeśli byłaby zwykłą firmą rozprowadzającą wśród społeczeństwa to samo wolne oprogramowanie za tą samą opłatą, to zapewniałaby teraz swojemu założycielowi bardzo dobre utrzymanie.
Ponieważ Fundacja jest organizacją charytatywną, programiści często pracują dla nas za połowę pieniędzy, które mogliby dostać gdzieś indziej. Robią to, bo nie ma u nas biurokracji, a także dlatego, że czują satysfakcję wiedząc, że ich praca nie będzie niedostępna użytkownikom. Głównym powodem, dla którego to robią jest fakt, że programowanie sprawia przyjemność. Co więcej, wiele przydatnych programów napisali dla nas ochotnicy. (Nawet twórcy dokumentacji technicznej zaczęli zgłaszać się na ochotnika).
To potwierdza, że programowanie to jedna z najbardziej fascynujących dziedzin, obok muzyki i sztuki. Nie musimy się obawiać, że nikt nie będzie chciał programować.
Istnieje dobry powód, dla którego użytkownicy programów czują moralne zobowiązanie ich wspierania. Ludzie rozwijający wolne oprogramowanie wnoszą wkład w działania użytkowników, dlatego finansowe wspieranie dalszego rozwoju jest nie tylko fair, ale także w dłuższej perspektywie w interesie użytkowników.
Jednak nie odnosi się to do twórców oprogramowania objętego restrykcyjnymi licencjami, bo utrudnianie zasługuje na karę, a nie nagrodę.
Mamy tu więc paradoks: twórcy użytecznego oprogramowania należy się wsparcie użytkowników, ale każda próba zamiany tego moralnego zobowiązania w żądanie niszczy jego podstawę. Twórca może zasługiwać na nagrodę lub się jej domagać, ale nie obie te rzeczy na raz.
Uważam, że postępujący etycznie programista, który zetknie się z tym paradoksem, musi zachowywać się tak, żeby zasłużyć na nagrodę, ale powinien także prosić użytkowników o dobrowolne datki. W końcu użytkownicy nauczą się wspierać programistów bez przymusu, tak samo jak nauczyli się wspierać publiczne radio i telewizję.
Jeśli oprogramowanie byłoby wolne, to programiści istnieliby nadal, tyle że być może byłoby ich mniej. Czy byłoby to złe dla społeczeństwa?
Niekoniecznie. W dzisiejszych czasach rozwinięte państwa mają mniej rolników niż w roku 1900, ale nie uważamy tego za złe dla społeczeństwa, bo mała ilość rolników dostarcza konsumentom więcej jedzenia niż kiedyś dostarczało wielu. Nazywamy to zwiększoną produktywnością. Wolne oprogramowanie potrzebowałoby dużo mniej programistów do zaspokojenia popytu, bo na wszystkich poziomach zwiększyłaby się produktywność:
Ludzie, którzy sprzeciwiają się współpracy twierdząc, że doprowadziłoby to do zatrudnienia mniejszej ilości programistów, tak naprawdę sprzeciwiają się zwiększonej produktywności. Tymczasem ci sami ludzie zazwyczaj akceptują szeroko przyjęty pogląd, że przemysł programistyczny potrzebuje zwiększonej produktywności. Więc o co w końcu chodzi?
„Produktywność programistyczna” może znaczyć dwie różne rzeczy: ogólną produktywność całej produkcji oprogramowania lub produktywność poszczególnych projektów. Ogólna produktywność jest tym, co społeczeństwo chciałoby podnieść, a najprostszym sposobem, żeby to zrobić, jest zniesienie sztucznych barier, które stoją na drodze współpracy i ją zmniejszają. Jednak naukowcy badający „produktywność programistyczną” skupiają się tylko na drugim, ograniczonym znaczeniu tego pojęcia, w przypadku którego polepszenie sytuacji wymaga trudnych postępów technologicznych.
Czy nieuniknione jest, że ludzie będą próbować ze sobą konkurować, żeby być lepszymi od swoich rywali? Być może tak. Ale konkurencja sama w sobie nie jest szkodliwa, rzeczą szkodliwą jest walka.
Konkurować ze sobą można na wiele sposobów. Konkurencja może mieć na celu próbę ciągłego osiągania więcej, prześcigania tego, co zrobili inni. Na przykład dawno temu istniało współzawodnictwo pomiędzy programistycznymi geniuszami o to, kto potrafi zmusić komputer do zrobienia najbardziej zadziwiającej rzeczy lub napisać najkrótszy bądź najszybszy program wykonujący jakieś zadanie. Taka konkurencja może być pożyteczna dla wszystkich, dopóki utrzymany jest duch pozytywnego współzawodnictwa.
Konstruktywna konkurencja wystarcza by zmotywować ludzi do wielkich wysiłków. Kilkoro ludzi konkuruje ze sobą o tytuł pierwszej osoby, która odwiedzi wszystkie kraje świata, niektórzy wydają na to całe fortuny. Jednak nie przekupują kapitanów statków, by wysadzili ich rywali na bezludnych wyspach. Chętnie przystają na to, by wygrał najlepszy.
Konkurencja przekształca się w walkę, gdy konkurenci zaczynają próbować przeszkadzać sobie nawzajem zamiast samemu iść do przodu, kiedy „Niech wygra najlepszy” ustępuje miejsca „Dajcie mi wygrać, nawet jeśli nie jestem najlepszy”. Objęte restrykcyjną licencją oprogramowanie jest szkodliwe nie dlatego, że jest formą konkurencji, ale dlatego, że jest formą walki pomiędzy obywatelami naszego społeczeństwa.
Konkurencja w biznesie niekoniecznie musi być walką. Na przykład, gdy konkurują ze sobą dwa warzywniaki, to ich energia idzie na ulepszanie własnej oferty, a nie sabotowanie rywala. Ale to nie jest przejawem specjalnego przywiązania do biznesowej etyki. W tej dziedzinie jest po prostu mało możliwości walki, pomijając przemoc fizyczną. Niektóre branże biznesu mają więcej takich możliwości. Zatrzymywanie dla siebie informacji, które mogłyby pomóc wszystkim w rozwoju jest formą walki.
Ideologia biznesu nie przygotowuje ludzi na powstrzymywanie się przed pokusą walki z konkurentami. Niektóre formy walki zostały zakazane przez ustawy antymonopolowe, ustawy o prawdzie w reklamie, itd., ale zamiast uogólnić to do powszechnego zakazu walki, dyrektorzy wymyślają inne jej formy, które nie są bezpośrednio zabronione. Społeczne zasoby są roztrwaniane przez ekonomiczny odpowiednik frakcyjnej wojny domowej.
W Stanach Zjednoczonych każdy zwolennik czegoś innego niż najbardziej ekstremalne formy wolnorynkowego egoizmu często spotyka się z tym oskarżeniem. Jest ono np. wymierzone w zwolenników narodowego systemu ochrony zdrowia, takiego jakie działają we wszystkich uprzemysłowionych krajach wolnego świata. Jest wymierzone w zwolenników publicznego wsparcia dla sztuki, które jest także powszechne w rozwiniętych krajach. Pomysł, że obywatele mają jakieś zobowiązania wobec dobra publicznego jest w Ameryce identyfikowany z komunizmem. Ale na ile podobne do siebie są te dwie idee w rzeczywistości?
Komunizm praktykowany w Związku Radzieckim był systemem scentralizowanej kontroli, w którym każda działalność była poddana reżimowi, rzekomo dla wspólnego dobra, ale tak naprawdę dla dobra członków partii komunistycznej. Urządzenia do kopiowania były tam ściśle pilnowane, aby zapobiec nielegalnemu wykonywaniu kopii.
Amerykański system praw autorskich dotyczących oprogramowania ustanawia scentralizowaną kontrolę nad dystrybucją programów i stoi na straży urządzeń do kopiowania, używających różnych zabezpieczeń, by zapobiec wykonywaniu nielegalnych kopii.
W przeciwieństwie do tego, ja pracuję na rzecz systemu, w którym ludzie mają wolną rękę i mogą decydować o swoich poczynaniach. W szczególności mają możliwość pomagania swoim znajomym oraz modyfikowania i ulepszania narzędzi, których codziennie używają. Systemu opartego na ochotniczej współpracy i decentralizacji.
Tak więc jeśli chcemy oceniać poglądy według ich podobieństwa do radzieckiego komunizmu, to komunistami są właściciele oprogramowania.
Zakładam w tym artykule, że użytkownik oprogramowania nie jest mniej ważny niż jego twórca, a nawet pracodawca twórcy. Innymi słowy ich interesy i potrzeby mają jednakową wagę podczas decydowania, która droga jest najlepsza.
Ta przesłanka nie jest ogólnie przyjmowana. Wielu twierdzi, że pracodawca twórcy jest z natury ważniejszy niż ktokolwiek inny. Mówią oni na przykład, że powodem dla istnienia właścicieli oprogramowania jest zapewnienie szefowi twórcy korzyści, na które zasługuje, niezależnie od tego, jak może to wpłynąć na społeczeństwo.
Próby udowodnienia lub obalenia tych przesłanek nie mają sensu. Dowód wymaga wspólnych przesłanek. Tak więc większość z tego, co mówię jest adresowana do tych, którzy uznają moje przesłanki lub przynajmniej są zainteresowani, jakie są ich konsekwencje. Dla tych, którzy uważają, że właściciel jest ważniejszy niż wszyscy inni, artykuł ten jest po prostu bez znaczenia.
Tylko dlaczego duży odsetek Amerykanów akceptuje przesłankę, która wynosi pewnych ludzi ponad wszystkich innych? Częściowo przez przekonanie, że taka przesłanka jest częścią amerykańskiej tradycji prawnej. Niektórzy myślą, że poddawanie jej w wątpliwość to podważanie podstaw społeczeństwa.
Ważne jest, żeby ci ludzie zdali sobie sprawę, że ta przesłanka nie jest częścią naszej tradycji prawnej i nigdy nią nie była.
Konstytucja mówi, że celem prawa autorskiego jest „promocja postępu nauki i sztuk użytecznych”. Więcej na ten temat powiedział Sąd Najwyższy, stwierdzając w sprawie Fox Film przeciwko Doyal, że „Wyłączny przedmiot zainteresowania Stanów Zjednoczonych i podstawowy cel nadawania monopolu [praw autorskich] leży w ogólnych korzyściach, jakie społeczeństwo wynosi z pracy autorów”.
Nie musimy się zgadzać z Konstytucją lub Sądem Najwyższym. (W pewnym okresie obie te instytucje aprobowały niewolnictwo). Tak więc ich stanowiska nie obalają przesłanki o wyższości właścicieli. Mam jednak nadzieję, że jej siła zostanie zmniejszona przez świadomość, że jest to radykalne prawicowe założenie, a nie założenie tradycyjnie przyjmowane.
Lubimy myśleć, że nasze społeczeństwo popiera pomaganie bliźnim. Jednak za każdym razem, kiedy nagradzamy kogoś za utrudnianie lub podziwiamy go za bogactwo, które w ten sposób zdobył, dajemy dowód czegoś innego.
Nieudostępnianie oprogramowania jest jedną z form naszej powszechnej gotowości do stawiania osobistych korzyści ponad dobro społeczne. Możemy to prześledzić od Ronalda Reagana do Jamesa Bakkera, od Ivana Boesky'ego do Exxonu, od upadających banków do upadających szkół. Możemy to zmierzyć wielkością populacji bezdomnych i więźniów. Duch antyspołeczny sam się napędza, ponieważ im więcej widzimy, że inni nam nie pomagają, tym bardziej wydaje nam się bez sensu pomaganie innym. W ten sposób społeczeństwo zamienia się w dżunglę.
Jeśli nie chcemy żyć w dżungli, musimy zmienić nasze postawy. Musimy zacząć dawać do zrozumienia, że dobry obywatel to taki, który współpracuje kiedy należy, a nie taki, który odnosi sukcesy w zabieraniu innym. Mam nadzieję, że pomoże w tym ruch wolnego oprogramowania: przynajmniej w jednej dziedzinie zastąpimy dżunglę bardziej efektywnym systemem, który zachęca do ochotniczej współpracy i dzięki niej funkcjonuje.
[1] Słowo „free” [wolny, darmowy] w „free software” odnosi się do wolności, a nie do ceny. Cena za kopię wolnego programu może być zerowa, mała lub (rzadko) dość duża.
[2] Sprawa zanieczyszczenia środowiska i korków nie wpływa na tę konkluzję. Jeśli chcemy uczynić jazdę samochodem droższą, aby zniechęcić do jazdy samochodem w ogóle, to nie jest dobrze robić to instalując budki pobierające opłaty, które powiększają zanieczyszczenie i korki. Znacznie lepszy jest podatek na benzynę. Tak samo nie ma z nią związku chęć zwiększenia bezpieczeństwa przez ograniczanie prędkości maksymalnej – wolnodostępna droga poprawia płynność ruchu, przez co wzrasta bezpieczeństwo, niezależnie od limitu prędkości.
[3] Ktoś może uważać jakiś program za szkodliwą rzecz, która w ogóle nie powinna być dostępna, jak Lotus Marketplace, baza danych informacji osobistych, którą wycofano ze sprzedaży z powodu presji społeczeństwa. Większość z tego, co mówię, nie odnosi się do tego przypadku, ale nie ma specjalnie sensu w upieraniu się za właścicielami na podstawie stwierdzenia, że właściciel uczyni oprogramowanie mniej dostępnym. Właściciel nie uczyni go całkowicie niedostępnym, jak chcielibyśmy, żeby było w przypadku programu, którego użytkowanie jest destrukcyjne.
Ten tekst został zamieszczony w książce Free Software, Free Society (Wolne oprogramowanie, wolne społeczeństwo. Wybrane eseje Richarda M. Stallmana).
Tłumaczenia tej strony:
[
简体中文
| 繁體中文
| Česky
| Deutsch
| English
| Español
| Français
| עברית
| Bahasa Indonesia
| Polski
| Português
| Русский
| Српски
| Suomi
]
Powrót do strony głównej Projektu GNU.
Pytania dotyczące GNU i FSF prosimy kierować na adres
[email protected].
Istnieją także
inne sposoby skontaktowania się
z FSF.
Informacje o niedziałających odnośnikach oraz inne poprawki
(lub propozycje) prosimy wysyłać na adres
[email protected].
Copyright (C) 1998, 2001, 2005, 2006 Free Software Foundation, Inc.,
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
Verbatim copying and distribution of this entire article is
permitted in any medium without royalty provided this notice is
preserved.
Zezwala się na wykonywanie i dystrybucję wiernych kopii tego tekstu,
bez tantiem i niezależnie od nośnika, pod warunkiem zachowania niniejszego zezwolenia.
Tłumaczenie:
Grupa tłumaczy witryny Projektu GNU
([email protected]).
Aktualizowane: $Date: 2006/06/27 16:05:54 $ $Author: wkotwica $