path: root/talermerchantdemos/blog/articles/pl/shouldbefree.html

<!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->

<!--#include virtual="/server/header.pl.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Dlaczego oprogramowanie powinno być wolne - Projekt GNU - Fundacja Wolnego
Oprogramowania (FSF)</title>

<!--#include virtual="/philosophy/po/shouldbefree.translist" -->
<!--#include virtual="/server/banner.pl.html" -->
<h2>Dlaczego oprogramowanie powinno być wolne </h2>

<p>
<a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
<h3 id="introduction">Wprowadzenie</h3>
<p>
Fakt istnienia programów komputerowych w&nbsp;nieunikniony sposób otwiera
kwestię sposobu podejmowania decyzji co do&nbsp;ich użytkowania. Wyobraźmy
sobie na&nbsp;przykład, że&nbsp;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&nbsp;będzie ona rzeczywiście
wykonana? Zainteresowane osoby? A&nbsp;może ktoś inny, nazywany
&bdquo;właścicielem&rdquo;? </p>
<p>
   Twórcy programów zwykle rozważają te pytania zakładając, że&nbsp;odpowiednie
kryterium dla ich rozstrzygnięcia to maksymalizowanie ich zysków. Polityczne
wpływy biznesu doprowadziły do&nbsp;tego, że&nbsp;rząd przyjął zarówno to
kryterium, jak również rozwiązanie wysunięte przez twórców, które mówi,
że&nbsp;program ma właściciela, zazwyczaj korporację zaangażowaną
w&nbsp;jego rozwój.</p>
<p>
   Chciałbym rozważyć to samo pytanie używając innego kryterium: dobrobytu
i&nbsp;wolności całego społeczeństwa. </p>
<p>
   O rozstrzygnięciu tych kwestii nie może decydować dzisiejsze prawo, jako
że&nbsp;prawo powinno dostosowywać się do&nbsp;zasad etycznych, a&nbsp;nie
na&nbsp;odwrót. Nie rozstrzygają ich także obecne praktyki, chociaż mogą one
zasugerować możliwe rozwiązania. Jedynym sposobem na&nbsp;rozstrzygnięcie
jest stwierdzenie kto zyskuje, a&nbsp;kto traci na&nbsp;uznawaniu praw
właścicieli oprogramowania, a&nbsp;także dlaczego i&nbsp;w jakim
stopniu. Innymi słowy, powinniśmy przeprowadzić analizę zysków i&nbsp;strat
w&nbsp;imieniu całego społeczeństwa, uwzględniając w&nbsp;niej wolność
jednostek oraz&nbsp;produkcję dóbr materialnych. </p>
<p>
   Zamierzam w&nbsp;tym eseju opisać rezultaty, jakie niesie za&nbsp;sobą
uznawanie właścicieli i&nbsp;pokazać, że&nbsp;są one szkodliwe. Udowodnię,
że&nbsp;programiści powinni zachęcać innych do&nbsp;redystrybucji
i&nbsp;dzielenia się pisanymi przez nas programami, do&nbsp;ich studiowania
i&nbsp;ulepszania. Innymi słowy, powinni pisać <a
href="/philosophy/free-sw.html">&bdquo;wolne&rdquo; oprogramowanie</a>.<a
href="#f1">(1)</a></p>

<h3 id="owner-justification">Jak właściciele usprawiedliwiają swoją władzę</h3>
<p>
   Ludzie korzystający na&nbsp;obecnym systemie, w&nbsp;którym programy są
własnością, przedstawiają dwa argumenty na&nbsp;poparcie swoich roszczeń:
emocjonalny i&nbsp;ekonomiczny. </p>
<p>
   Argument emocjonalny brzmi tak: &bdquo;Przelałem w&nbsp;ten program swój
pot, serce i&nbsp;duszę. <em>Ja</em> go stworzyłem, jest
<em>mój</em>!&rdquo;</p>
<p>
   Ten argument nie jest trudny do&nbsp;odparcia. Uczucie przywiązania
programiści mogą w&nbsp;sobie pielęgnować gdy jest im to na&nbsp;rękę, nie
jest czymś nieodłącznym. Zwróćmy na&nbsp;przykład uwagę, z&nbsp;jaką chęcią
ci sami programiści zrzekają się zazwyczaj wszystkich swoich praw
na&nbsp;rzecz jakiejś dużej korporacji, gdy im się za&nbsp;to zapłaci&nbsp;–
przywiązanie emocjonalne znika jak za&nbsp;dotknięciem czarodziejskiej
różdżki. Spójrzmy dla odmiany na&nbsp;wielkich artystów i&nbsp;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&nbsp;fakt, że&nbsp;jest
gotowe, a&nbsp;także funkcja, którą pełniło. Taki pogląd panował przez setki
lat.</p>
<p>
   Argument ekonomiczny brzmi następująco: &bdquo;Chcę być bogaty (zazwyczaj
nieprecyzyjnie mówią &bdquo;chcę mieć się z&nbsp;czego utrzymać&rdquo;),
a&nbsp;jeśli nie dacie mi się wzbogacić na&nbsp;programowaniu, to nie będę
tego robił. Wszyscy myślą jak ja, więc&nbsp;nikt nie będzie nigdy
programował. A&nbsp;wtedy zostaniecie bez&nbsp;żadnych programów!&rdquo; Ta
pogróżka występuje zwykle pod&nbsp;przykrywką przyjacielskiej rady
od&nbsp;mądrzejszego. </p>
<p>
   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&nbsp;innym
sformułowaniu tego argumentu.</p>
<p>
   Sformułowanie to zaczyna się od&nbsp;porównania stopnia społecznej
użyteczności programów objętych restrykcyjną licencją i&nbsp;braku
programów. Następnie dochodzi się w&nbsp;nim do&nbsp;wniosku,
że&nbsp;tworzenie oprogramowania objętego taką licencją jest w&nbsp;sumie
korzystne i&nbsp;powinno się je popierać. Błąd tkwi tutaj
w&nbsp;porównywaniu tylko dwóch rozwiązań&nbsp;– oprogramowanie własnościowe
albo&nbsp;brak oprogramowania&nbsp;– i&nbsp;zakładaniu, że&nbsp;inne
możliwości nie istnieją.</p>
<p>
   Jeśli istnieje system praw autorskich obejmujący oprogramowanie, to pisanie
programów związane jest zazwyczaj z&nbsp;istnieniem właściciela
kontrolującego sposób, w&nbsp;jaki program jest używany. Tak długo, jak
istnieje ten związek, musimy często wybierać pomiędzy oprogramowaniem
objętym restrykcyjną licencją a&nbsp;brakiem oprogramowania. Ten związek nie
jest jednak&nbsp;nieodłączny ani&nbsp;nieunikniony, jest konsekwencją
konkretnej decyzji społecznej lub&nbsp;prawnej, którą poddajemy tutaj
w&nbsp;wątpliwość: decyzji o uznawaniu właścicieli. Formułowanie całej
kwestii jako wyboru pomiędzy oprogramowaniem objętym licencją a&nbsp;brakiem
oprogramowania to przyjmowanie za&nbsp;prawdziwe czegoś, co nie zostało
udowodnione.</p>

<h3 id="against-having-owners">Przeciwko istnieniu właścicieli</h3>
<p>
   Bieżąca kwestia brzmi: Czy&nbsp;rozwój oprogramowania powinien być powiązany
z&nbsp;istnieniem właścicieli, którzy ograniczają jego użytkowanie?</p>
<p>
   Aby&nbsp;ją rozstrzygnąć, musimy osobno ocenić społeczne efekty obu tych
rzeczy: tworzenia oprogramowania (niezależnie od&nbsp;warunków jego
dystrybucji) oraz&nbsp;ograniczania jego użytkowania (zakładając,
że&nbsp;zostało ono stworzone). Jeśli jedna z&nbsp;nich daje użyteczne
rezultaty, a&nbsp;druga jest szkodliwa, to korzystniejsze dla nas byłoby
przerwanie związku między nimi i&nbsp;kontynuowanie tylko tej pierwszej.</p>
<p>
   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ł.</p>
<p>
   Żeby ustalić skutki, które niesie za&nbsp;sobą ograniczanie dzielenia się
programami, musimy porównać wartość, jaką przedstawia dla społeczeństwa
program ograniczony (tzn. objęty restrykcyjną licencją) z&nbsp;wartością
tego samego programu, tyle że&nbsp;wolnego. Oznacza to porównanie dwóch
alternatywnych światów. </p>
<p>
   Ta analiza dotyka również pojawiającego się czasami prostego kontrargumentu,
który mówi, że&nbsp;&bdquo;korzyść, jaką odnoszą osoby z&nbsp;tytułu
dzielenia się programami z&nbsp;innymi jest równoważona przez szkodę, którą
ponosi przez to właściciel&rdquo;. Kontrargument ten zakłada,
że&nbsp;korzyść i&nbsp;szkoda są równe w&nbsp;swej wielkości. Niniejsza
analiza zawiera ich porównanie i&nbsp;wykazuje, że&nbsp;korzyść jest dużo
większa.</p>
<p>
   Żeby rozjaśnić całe rozumowanie, przyłóżmy je do&nbsp;innej dziedziny:
budowy dróg.</p>
<p>
   Można by finansować budowę wszystkich dróg poprzez&nbsp;pobieranie opłat
za&nbsp;przejazd. Pociągałoby to za&nbsp;sobą konieczność umieszczenia
na&nbsp;każdym rogu budek pobierających opłaty. Taki system przynosiłby duże
środki na&nbsp;ulepszanie dróg. Miałby jeszcze jedna zaletę: zmuszałby
użytkowników każdej drogi do&nbsp;płacenia za&nbsp;przejazd. Budki są
jednak&nbsp;sztuczną przeszkodą i&nbsp;zakłócają płynną jazdę. Sztuczną,
bo&nbsp;nie ma żadnego związku między nimi a&nbsp;sposobem w&nbsp;jaki
działają drogi i&nbsp;samochody.</p>
<p>
   Gdy porównujemy bezpłatne i&nbsp;płatne drogi pod&nbsp;kątem użyteczności
okazuje się, że&nbsp;chociaż oba rodzaje są takie same pod&nbsp;każdym innym
względem, to te pierwsze są tańsze do&nbsp;zbudowania, tańsze
w&nbsp;utrzymaniu i&nbsp;bardziej efektywne w&nbsp;użyciu.<a
href="#f2">(2)</a> W&nbsp;ubogim kraju opłaty za&nbsp;drogi uczyniłyby je
niedostępnymi dla wielu obywateli. Drogi bezpłatne oferują
zatem&nbsp;społeczeństwu więcej korzyści po&nbsp;mniejszej cenie, są
więc&nbsp;z&nbsp;jego punktu widzenia bardziej pożądane. Dlatego&nbsp;też
społeczeństwo powinno znaleźć sposób na&nbsp;finansowanie dróg inny niż
budki pobierające opłaty. Używanie dróg, gdy są już zbudowane, powinno być
darmowe.</p>
<p>
   Gdy zwolennicy budek pobierających opłaty przedstawiają je jako
<em>zaledwie</em> sposób zdobywania funduszy, zaciemniają obraz innych
dostępnych możliwości. Budki rzeczywiście przynoszą fundusze, ale&nbsp;robią
też coś jeszcze: w&nbsp;rezultacie obniżają wartość drogi. Droga płatna nie
jest tak dobra jak darmowa. Budowanie większej ilości dróg,
lub&nbsp;technicznie lepszych dróg, wcale nie musi być krokiem
do&nbsp;przodu, jeśli oznacza zastąpienie dróg darmowych płatnymi.</p>
<p>
   Za&nbsp;budowę darmowej drogi trzeba oczywiście zapłacić i&nbsp;koszty te
społeczeństwo musi w&nbsp;jakiś sposób ponieść. Jednak&nbsp;nie skazuje to
nas na&nbsp;budki pobierające opłaty. Skoro i&nbsp;tak musimy płacić, to
dostaniemy za&nbsp;te same pieniądze więcej, jeśli kupimy drogę darmową. </p>
<p>
   Nie twierdzę, że&nbsp;droga płatna jest gorsza od&nbsp;braku dróg. Byłoby to
prawdą, gdyby opłaty były tak duże, że&nbsp;prawie nikt by z&nbsp;dróg nie
korzystał, ale&nbsp;takie postępowanie instytucji zbierających opłaty nie
jest zbyt prawdopodobne. Ponieważ&nbsp;jednak budki pobierające opłaty
powodują znaczne marnotrawstwo i&nbsp;niewygodę, lepiej jest zbierać
fundusze w&nbsp;sposób sprawiający mniej trudności. </p>
<p>
   Stosująć to samo rozumowanie do&nbsp;programów komputerowych, pokażę teraz,
że&nbsp;istnienie &bdquo;budek pobierających opłaty&rdquo; dla użytecznego
oprogramowania kosztuje społeczeństwo bardzo wiele: powoduje, że&nbsp;rozwój
i&nbsp;dystrybucja programów są bardziej kosztowne, a&nbsp;ich użytkowanie
jest mniej satysfakcjonujące i&nbsp;efektywne. Wynikiem będzie stwierdzenie,
że&nbsp;tworzenie programów powinno być motywowane w&nbsp;inny
sposób. Następnie zaprezentuję inne metody motywowania i&nbsp;finansowania
(w&nbsp;zakresie rzeczywiście potrzebnym) rozwoju oprogramowania.</p>

<h4 id="harm-done">Szkody powodowane utrudnianiem dostępu do&nbsp;programów</h4>
<p>
   Wyobraźmy sobie, że&nbsp;został napisany jakiś program i&nbsp;poniesione
zostały wszelkie związane z&nbsp;tym procesem koszty. Teraz społeczeństwo
musi zadecydować, czy&nbsp;uczynić go prawnie zastrzeżonym, czy&nbsp;też
pozwolić na&nbsp;jego swobodną dystrybucję i&nbsp;użytkowanie. Przyjmijmy,
że&nbsp;istnienie tego programu oraz&nbsp;jego dostępność są pożądane.<a
href="#f3">(3)</a></p>
<p>
   Ograniczenia nałożone na&nbsp;dystrybucję i&nbsp;modyfikacje tego programu
nie mogą ułatwiać jego użytkowania, a&nbsp;jedynie w&nbsp;nim
przeszkadzać. Tak więc&nbsp;rezultat może być wyłącznie
negatywny. Ale&nbsp;w&nbsp;jakim stopniu? I&nbsp;w&nbsp;jaki sposób?</p>
<p>
   Z&nbsp;utrudnień takiego rodzaju wynikają trzy poziomy materialnych szkód:</p>

<ul>
<li>Mniej osób korzysta z&nbsp;programu.</li>

<li>Nikt z&nbsp;użytkowników nie może programu naprawić lub&nbsp;dostosować
do&nbsp;swoich potrzeb.</li>

<li>Inni programiści nie mogą się niczego z&nbsp;takiego programu nauczyć,
ani&nbsp;oprzeć na&nbsp;nim nowego projektu.</li>
</ul>

<p>
   Każdy z&nbsp;poziomów szkód materialnych ma towarzyszącą formę szkód
psychospołecznych. Mowa jest tutaj o&nbsp;skutkach, jakie podejmowane przez
ludzi decyzje mają na&nbsp;ich późniejsze uczucia, postawy
i&nbsp;skłonności. Te zmiany w&nbsp;ludzkim sposobie myślenia będą potem
miały dalszy wpływ na&nbsp;ich relacje ze współobywatelami i&nbsp;mogą
pociągnąć za&nbsp;sobą materialne konsekwencje.</p>
<p>
   Te trzy poziomy szkód materialnych marnują część wartości, jaką mógłby
wnieść do&nbsp;społeczeństwa program, ale&nbsp;nie mogą zredukować jej
do&nbsp;zera. Jeśli marnują niemal całą wartość programu, to jego napisanie
szkodzi społeczeństwu co najwyżej przez wysiłek, jaki został włożony
w&nbsp;napisanie go. Zwykle program, który opłaca się sprzedawać musi dawać
jakieś bezpośrednie materialne korzyści.</p>
<p>
   Biorąc jednak&nbsp;pod uwagę idące w&nbsp;parze szkody psychospołeczne, nie
ma żadnej granicy dla szkód, jakie może przynieść rozwój objętego
restrykcyjnymi licencjami oprogramowania.</p>

<h4 id="obstructing-use">Utrudnianie użytkowania programów</h4>
<p>
   Pierwszy poziom szkód utrudnia najzwyklejsze użytkowanie programu. Wykonanie
kopii programu to prawie żaden koszt (szczególnie, że&nbsp;można to zrobić
samemu), więc&nbsp;na wolnym rynku cena kopii byłaby bliska zeru. Opłata
licencyjna to czynnik znacząco zniechęcający do&nbsp;używania danego
programu. Jeśli jakiś powszechnie używany program jest objęty restrykcyjną
licencją, to będzie go używać o wiele mniej osób niż by chciało.</p>
<p>
   Łatwo wykazać, że&nbsp;całkowity wkład programu na&nbsp;rzecz społeczeństwa
jest zmniejszany przez przydzielenie mu właściciela. Każdy potencjalny
użytkownik tego programu, który zetknie się z&nbsp;koniecznością płacenia
za&nbsp;jego używanie, może zdecydować się zapłacić lub&nbsp;zrezygnować
z&nbsp;korzystania z&nbsp;niego. Jeśli zdecyduje się zapłacić, to saldo
operacji wynosi zero. Tymczasem za&nbsp;każdym razem, gdy ktoś decyduje się
zrezygnować z&nbsp;używania jakiegoś programu, to dzieje się mu krzywda,
a&nbsp;korzyści nie odnosi nikt. Suma liczb ujemnych i&nbsp;zer zawsze jest
ujemna.</p>
<p>
   Ale&nbsp;to nie zmniejsza ilości pracy, którą trzeba włożyć w&nbsp;rozwój
programu. W&nbsp;rezultacie zredukowana jest efektywność całego procesu
mierzona w&nbsp;dostarczonej użytkownikowi satysfakcji na&nbsp;godzinę
pracy.</p>
<p>
   To odzwierciedla bardzo ważną różnicę pomiędzy kopiami programów
a&nbsp;kopiami samochodów, krzeseł lub&nbsp;kanapek. Poza science fiction
nie istnieje kopiarka obiektów materialnych. Programy dają się
jednak&nbsp;łatwo kopiować&nbsp;- każdy może niewielkim wysiłkiem
wyprodukować tyle kopii, ile jest mu potrzebnych. Nie jest tak
w&nbsp;przypadku obiektów materialnych, bo&nbsp;obowiązuje prawo zachowania
masy: każdą kopię trzeba zbudować z&nbsp;surowców w&nbsp;taki sam sposób,
w&nbsp;jaki zbudowano oryginał. </p>
<p>
   W&nbsp;przypadku obiektów materialnych zniechęcanie do&nbsp;ich używania ma
sens, ponieważ&nbsp;mniejsza ilość kupionych przedmiotów oznacza mniejszą
ilość surowców i&nbsp;pracy potrzebnych do&nbsp;ich zrobienia. Prawdą jest,
że&nbsp;zazwyczaj również istnieje koszt początkowy, koszt rozwoju, który
rozkłada się na&nbsp;cały proces produkcji. Ale&nbsp;tak długo, jak koszty
produkcji jednej jednostki są znaczne, dodawanie części kosztów rozwoju nie
robi jakościowej różnicy. I&nbsp;nie wymaga ograniczania wolności zwykłych
użytkowników.</p>
<p>
   Jednak&nbsp;nakładanie ceny na&nbsp;coś, co w&nbsp;innym przypadku byłoby
darmowe, to zmiana jakościowa. Centralnie nałożona na&nbsp;dystrybucję
oprogramowania cena ma potężne działanie zniechęcające.</p>
<p>
   Co więcej, praktykowana obecnie scentralizowana produkcja jest nieefektywna
nawet w&nbsp;kwestii dostarczania kopii oprogramowania. Na&nbsp;taki system
składa się umieszczanie fizycznych dyskietek lub&nbsp;taśm w&nbsp;nikomu
niepotrzebnych opakowaniach, rozsyłanie ich po&nbsp;całym świecie
i&nbsp;magazynowanie w&nbsp;celu sprzedaży. Ten koszt przedstawiany jest
jako nieodłączne wydatki związane z&nbsp;robieniem interesów, a&nbsp;tak
naprawdę jest częścią marnotrawstwa powodowanego przez istnienie
właścicieli.</p>

<h4 id="damaging-social-cohesion">Naruszanie spójności społeczeństwa</h4>
<p>
   Załóżmy, że&nbsp;dla Ciebie i&nbsp;Twojego znajomego użyteczny byłby pewien
program. W&nbsp;etycznej trosce o znajomego powinieneś uważać,
że&nbsp;prawidłowe rozwiązanie tej sytuacji pozwoli Wam obu go
używać. Pomysł, żeby pozwolić tylko jednemu z&nbsp;Was na&nbsp;używanie tego
programu i&nbsp;zabronić tego samego drugiemu, tworzy podziały. Ani&nbsp;Ty,
ani&nbsp;Twój znajomy nie powinniście tego akceptować.</p>
<p>
   Podpisanie typowej umowy licencyjnej oznacza zdradzenie bliźniego:
&bdquo;Obiecuję pozbawić mojego bliźniego dostępu do&nbsp;tego programu,
żebym mógł mieć kopię tylko dla siebie&rdquo;. Ludzie, którzy podejmują
takie decyzje, czują wewnętrzną psychologiczną presję, by je usprawiedliwić
poprzez&nbsp;bagatelizowanie znaczenia pomagania swoim bliźnim,
więc&nbsp;duch społeczny na&nbsp;tym traci. Jest to psychospołeczna szkoda
powiązana z&nbsp;materialną szkodą wynikającą ze zniechęcania
do&nbsp;używania programu.</p>
<p>
   Wielu użytkowników podświadomie zdaje sobie sprawę, że&nbsp;odmawianie
dzielenia się jest niewłaściwe, więc&nbsp;decydują się ignorować licencje
oraz&nbsp;prawa i&nbsp;dzielić się programami pomimo ich istnienia. Mają
jednak&nbsp;często poczucie winy. Wiedzą, że&nbsp;musza łamać prawo, żeby
być dobrymi, ale&nbsp;uznają zwierzchność prawa i&nbsp;dochodzą
do&nbsp;wniosku, że&nbsp;bycie dobrym (a&nbsp;takimi są) jest nieprzyzwoite
lub&nbsp;hańbiące. To także jest jeden z&nbsp;rodzajów szkód
psychospołecznych, ale&nbsp;można ich uniknąć poprzez&nbsp;powiedzenie
sobie, że&nbsp;te licencje i&nbsp;prawa nie mają żadnej mocy moralnej.</p>
<p>
   Programiści także odnoszą szkody psychospołeczne wiedząc, że&nbsp;wielu
użytkowników nie będzie miało szansy skorzystać z&nbsp;owoców ich pracy. To
prowadzi do&nbsp;cynicznych postaw lub&nbsp;zaprzeczania
prawdzie. Programista może entuzjastycznie opisywać pracę, która jest dla
niego fascynująca pod&nbsp;względem technicznym. Potem, kiedy spytamy go
&bdquo;Czy będę mógł tego używać?&rdquo;, rzednie mu mina i&nbsp;przyznaje,
że&nbsp;odpowiedź jest negatywna. Aby&nbsp;nie czuć się zniechęcony,
albo&nbsp;przez większość czasu ignoruje ten fakt, albo&nbsp;przyjmuje
cyniczną postawę, żeby zbagatelizować znaczenie całej sprawy.</p>
<p>
   Od&nbsp;czasów Reagana w&nbsp;USA najbardziej brakuje nie innowacji
technologicznych, ale&nbsp;raczej skłonności do&nbsp;wspólnej pracy
na&nbsp;rzecz społeczeństwa. Nie ma sensu sprzyjać pierwszemu kosztem tego
drugiego.</p>

<h4 id="custom-adaptation">Utrudnianie dostosowywania programów do&nbsp;swoich potrzeb</h4>
<p>
   Drugim poziomem szkód materialnych jest niemożność dostosowywania programów
do&nbsp;własnych potrzeb. Łatwość modyfikacji oprogramowania jest jego
wielką przewagą nad&nbsp;starszymi technologiami. Tymczasem
we&nbsp;większości komercyjnie dostępnego oprogramowania nie można
wprowadzać zmian, nawet gdy się je kupi. Możecie je brać albo&nbsp;nie, jak
czarną skrzynkę, której wnętrze pozostaje tajemnicą&nbsp;– i&nbsp;tyle.</p>
<p>
   Program, który można uruchomić składa się z&nbsp;ciągów liczb, których
znaczenie jest ukryte. Nikt, nawet dobry programista, nie może łatwo zmienić
ten ciąg tak, żeby program robił coś innego.</p>
<p>
   Programiści zwykle pracują z&nbsp;&bdquo;kodem źródłowym&rdquo; programów,
który zapisany jest w&nbsp;jednym z&nbsp;języków programowania jak Fortran
lub&nbsp;C. Używa się w&nbsp;nim nazw do&nbsp;wskazywania używanych danych
oraz&nbsp;części programu, a&nbsp;operacje takie jak dodawanie
i&nbsp;odejmowanie reprezentowane są przez symbole typu '+'
i&nbsp;'-'. Wszystko to jest zaprojektowane po&nbsp;to, by ułatwić
programistom czytanie i&nbsp;modyfikowanie programów. Poniżej znajduje się
przykład, program do&nbsp;obliczania odległości pomiędzy dwoma punktami
na&nbsp;płaszczyźnie: </p>

<pre>
     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);
     }
</pre>
<p>
   Najważniejszą rzeczą nie jest co kod źródłowy oznacza; kluczem tutaj jest
jego wygląd przypominający algebrę a&nbsp;ludzie, którzy znają te języki
programowania uznają go jako kod znaczący i&nbsp;napisany
estetycznie. Z&nbsp;drugiej strony, mamy tutaj ten sam program w&nbsp;formie
wykonalnej na&nbsp;komputerze, którego normalnie używam by napisać to:
</p>

<pre>
     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317
</pre>

<p>
   Kod źródłowy jest przydatny (przynajmniej potencjalnie) dla każdego
użytkownika programu. Jednak&nbsp;większości użytkowników odmawia się
do&nbsp;niego dostępu. Zazwyczaj kod źródłowy objętego restrykcyjną licencją
programu jest trzymany w&nbsp;ukryciu przez właściciela, żeby tylko ktoś się
z&nbsp;niego czegoś nie nauczył. Użytkownicy dostają tylko pliki zawierające
niezrozumiałe ciągi liczb, które wykonuje komputer. Oznacza to,
że&nbsp;tylko właściciel programu może go modyfikować.</p>
<p>
   Kiedyś znajoma opowiadała mi, jak przez pół roku pracowała jako programistka
w&nbsp;banku, pisząc program podobny do&nbsp;czegoś, co było komercyjnie
dostępne. Twierdziła, że&nbsp;jeśli mogłaby wtedy dostać kod źródłowy
tamtego komercyjnego programu, to bez&nbsp;trudu mogłaby go zaadaptować dla
swoich potrzeb. Bank gotów był za&nbsp;to zapłacić, ale&nbsp;nie wyrażono
na&nbsp;to zgody&nbsp;– kod źródłowy był tajemnicą. Tak więc&nbsp;musiała
spędzić pół roku na&nbsp;bezsensownej pracy, która wlicza się do&nbsp;PKB
pomimo tego, że&nbsp;tak naprawdę jest marnotrawstwem.</p>
<p>
   Laboratorium Sztucznej Inteligencji <abbr title="Massachusetts Institute of
Technology">MIT</abbr> dostało około 1977 roku w&nbsp;prezencie
od&nbsp;Xeroksa graficzną drukarkę. Była ona obsługiwana przez wolne
oprogramowanie, do&nbsp;którego dodaliśmy wiele przydatnych
funkcji. Na&nbsp;przykład powiadamiało ono użytkownika o&nbsp;zakończeniu
wydruku. Jeśli z&nbsp;drukarką było coś nie tak, zaciął się
lub&nbsp;skończył papier, to oprogramowanie natychmiast powiadamiało
o&nbsp;tym wszystkich użytkowników, których dokumenty czekały w&nbsp;kolejce
na&nbsp;wydruk. Dzięki tym funkcjom praca była płynna.</p>
<p>
   Potem Xerox podarował Laboratorium nowszą, szybszą drukarkę, jedną
z&nbsp;pierwszych drukarek laserowych. Była ona obsługiwana przez objęte
restrykcyjną licencją oprogramowanie, które działało na&nbsp;specjalnie
do&nbsp;tego przeznaczonym, osobnym komputerze, więc&nbsp;nie mogliśmy dodać
żadnej z&nbsp;naszych ulubionych funkcji. Mogliśmy napisać program, który
powiadamiał o&nbsp;wysłaniu wydruku do&nbsp;tego specjalnego komputera,
ale&nbsp;nie mogliśmy wysyłać powiadomień po&nbsp;rzeczywistym zakończeniu
wydruku (tymczasem czas między jednym a&nbsp;drugim był zazwyczaj dość
długi). Nie było żadnej możliwości sprawdzenia, czy&nbsp;wydruk się
rzeczywiście zakończył, można było tylko zgadywać. Poza tym nikt nie był
powiadamiany, gdy zaciął się papier, więc&nbsp;często drukarka stała godzinę
w&nbsp;oczekiwaniu na&nbsp;usunięcie usterki.</p>
<p>
   Programiści systemowi w&nbsp;Laboratorium mogli naprawić takie problemy
prawdopodobnie tak samo dobrze jak pierwotni autorzy programu. Xeroksa to
nie interesowało i&nbsp;nie pozwolili nam tego zrobić, więc&nbsp;musieliśmy
się z&nbsp;problemami pogodzić. Nigdy się z&nbsp;nimi nie uporano.</p>
<p>
   Większość dobrych programistów zna to uczucie frustracji. Bank było stać
na&nbsp;rozwiązanie problemu przez napisanie programu od&nbsp;nowa,
ale&nbsp;typowy użytkownik, bez&nbsp;względu na&nbsp;swoje umiejętności,
może się tylko poddać.</p>
<p>
   Poddawanie się wyrządza szkody psychospołeczne duchowi samodzielności. Życie
w&nbsp;domu, którego nie możesz przebudować i&nbsp;dostosować do&nbsp;swoich
potrzeb jest demoralizujące. Prowadzi do&nbsp;rezygnacji
i&nbsp;zniechęcenia, co może się przenieść na&nbsp;inne aspekty
życia. Ludzie, którzy się tak czują, są nieszczęśliwi i&nbsp;nie pracują
dobrze.</p>
<p>
   Wyobraźcie sobie, co by się działo, gdyby przepisy kulinarne były strzeżone
tak jak oprogramowanie. Moglibyście się spytać &bdquo;Jak zmienić ten
przepis, by pozbyć się soli?&rdquo;, a&nbsp;wspaniały kucharz powiedziałby
&bdquo;Jak śmiesz obrażać mój przepis, dziecię mego umysłu
i&nbsp;podniebienia, próbując przy nim majstrować? Nie masz pojęcia, jak
zmienić mój przepis bez&nbsp;zepsucia go!&rdquo;.</p>
<p>
   &bdquo;Ale mój lekarz mówi, że&nbsp;nie powinienem jeść soli! Co mam zrobić?
Czy&nbsp;zmienisz dla mnie ten przepis tak, żeby nie było w&nbsp;nim
soli?&rdquo;</p>
<p>
   &bdquo;Z&nbsp;chęcią to zrobię, opłata wynosi jedynie 50
tys. dolarów&rdquo;. Opłata zazwyczaj jest duża, bo&nbsp;właściciel ma
monopol na&nbsp;zmiany. &bdquo;Jednak obecnie nie mam czasu. Jestem zajęty
zleceniem opracowania nowego przepisu na&nbsp;suchary dla Departamentu
Marynarki. Mogę się zająć twoją sprawą za&nbsp;jakieś dwa lata&rdquo;.</p>

<h4 id="software-development">Utrudnianie rozwoju oprogramowania</h4>
<p>
   Trzeci poziom szkód materialnych dotyka rozwoju oprogramowania. Był on
kiedyś procesem ewolucyjnym, w&nbsp;czasie którego programista brał
istniejący już program i&nbsp;przepisywał jego części w&nbsp;celu dodania
jednej nowej funkcji, a&nbsp;potem ktoś inny przepisywał inne części żeby
dodać kolejne funkcje. W&nbsp;niektórych przypadkach ciągnęło się to przez
dwadzieścia lat. W&nbsp;tym samym czasie na&nbsp;podstawie innych części
tego programu tworzono całkiem nowe programy.</p>
<p>
   Istnienie właścicieli uniemożliwia taką ewolucję i&nbsp;powoduje,
że&nbsp;pisząc program trzeba zaczynać od&nbsp;zera. Odbiera także nowym
programistom szansę studiowania istniejących programów w&nbsp;celu nauczenia
się użytecznych technik oraz&nbsp;sposobów konstruowania dużych programów.</p>
<p>
   Właściciele są też przeszkodą na&nbsp;drodze edukacji. Zdarzało mi się
spotkać obiecujących studentów informatyki, którzy w&nbsp;życiu nie widzieli
kodu źródłowego dużego programu. Mogą być dobrzy w&nbsp;pisaniu małych
programów, ale&nbsp;nie są w&nbsp;stanie zacząć uczyć się odmiennych
umiejętności pisania dużych, jeśli nie mogą zobaczyć, jak zrobili to inni.</p>
<p>
   Na&nbsp;każdym polu pracy intelektualnej można osiągnąć więcej stojąc
na&nbsp;ramionach gigantów. Jednak&nbsp;nie ma już na&nbsp;to ogólnego
przyzwolenia przy pisaniu programów&nbsp;– możecie stać tylko
na&nbsp;ramionach ludzi <em>ze swojej firmy</em>.</p>
<p>
   Związane z&nbsp;tym szkody psychospołeczne dotykają ducha naukowej
kooperacji, który kiedyś był tak silny, że&nbsp;naukowcy współpracowali ze
sobą nawet kiedy ich państwa były w&nbsp;stanie wojny. To w&nbsp;tym duchu
japońscy oceanografowie, opuszczający swoje laboratorium na&nbsp;wysepce
na&nbsp;Pacyfiku, starannie zachowali wyniki swojej pracy dla atakujących
amerykańskich marines i&nbsp;zostawili im notatkę z&nbsp;prośbą, żeby dobrze
się tym wszystkim zaopiekowali.</p>
<p>
   Wojna o&nbsp;zyski zniszczyła to, co wojna światowa
oszczędziła. W&nbsp;dzisiejszych czasach naukowcy wielu dziedzin nie
zawierają w&nbsp;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&nbsp;pewnością ma miejsce
w&nbsp;informatyce, gdzie kod źródłowy opisywanych programów jest zazwyczaj
tajemnicą.</p>

<h4 id="does-not-matter-how">Sposób ograniczania dzielenia się nie jest ważny</h4>
<p>
   Mówiłem tutaj o&nbsp;skutkach, jakie przynosi zabranianie ludziom kopiowania
i&nbsp;modyfikowania programów, oraz&nbsp;budowania oprogramowania
na&nbsp;bazie innych projektów. Nie sprecyzowałem, w&nbsp;jaki sposób takie
utrudnianie może być przeprowadzone, bo&nbsp;nie ma to wpływu
na&nbsp;wnioski. Nieważne, czy&nbsp;robi się to przez zabezpieczenia przed
kopiowaniem, prawa autorskie, licencje, szyfrowanie, karty ROM,
czy&nbsp;sprzętowe numery seryjne&nbsp;– jeśli skutecznie przeszkadza to
w&nbsp;użytkowaniu, jest to szkodliwe.</p>
<p>
   Użytkownicy uważają niektóre z&nbsp;tych metod za&nbsp;bardziej nieznośne
od&nbsp;innych. Wydaje mi się, że&nbsp;najbardziej znienawidzone metody to
te, które są skuteczne.</p>

<h4 id="should-be-free">Oprogramowanie powinno być wolne</h4>
<p>
   Pokazałem, jak własność programu, czyli&nbsp;możliwość ograniczania jego
kopiowania i&nbsp;modyfikacji, stwarza utrudnienia. Ich negatywne efekty są
szerokie i&nbsp;znaczące. Wynika z&nbsp;tego, że&nbsp;w&nbsp;społeczeństwie
nie powinni istnieć właściciele programów. </p>
<p>
   Innym sposobem na&nbsp;zrozumienie tego wszystkiego może być to,
że&nbsp;społeczeństwo potrzebuje wolnego oprogramowania, a&nbsp;programy
objęte restrykcyjnymi licencjami są jego marnymi substytutami. Popieranie
substytutów nie jest racjonalną drogą do&nbsp;osiągnięcia naszych celów. </p>
<p>
   Vaclav Havel powiedział, że&nbsp;powinniśmy &bdquo;pracować na&nbsp;rzecz
jakiejś sprawy, bo&nbsp;jest ona dobra, a&nbsp;nie tylko dlatego, że&nbsp;ma
szansę powodzenia&rdquo;. Firma wytwarzająca objęte licencją oprogramowanie
ma szansę powodzenia w&nbsp;wąskim tego słowa znaczeniu, ale&nbsp;nie jest
to coś dobrego dla społeczeństwa. </p>

<h3 id="why-develop">Dlaczego nadal będzie rozwijane oprogramowanie</h3>
<p>
   Jeśli wyeliminujemy prawo autorskie jako zachętę do&nbsp;rozwijania
oprogramowania, to na&nbsp;początku będzie się tworzyć mniej programów,
ale&nbsp;będą one bardziej użyteczne. Nie jest jasne, czy&nbsp;ogólna
dostarczona użytkownikowi satysfakcja będzie mniejsza; ale&nbsp;jeśli taka
będzie, lub&nbsp;jeśli chcemy ją i&nbsp;tak powiększyć, to są inne metody
zachęcania do&nbsp;pisania programów, tak samo jak oprócz budek
pobierających opłaty są inne metody zbierania pieniędzy na&nbsp;drogi. Zanim
powiem jak można to zrobić, chcę zbadać, jak duża zewnętrzna zachęta jest
rzeczywiście potrzebna. </p>

<h4 id="fun">Programowanie sprawia przyjemność</h4>
<p>
   Są takie prace, których mało kto się podejmie w&nbsp;zamian za&nbsp;coś
innego niż pieniądze, np. roboty drogowe. Są też inne dziedziny nauki
i&nbsp;sztuki, w&nbsp;których są małe szanse wzbogacenia się,
a&nbsp;w&nbsp;które ludzie wchodzą z&nbsp;powodu swoich fascynacji
lub&nbsp;dlatego, że&nbsp;postrzegają je jako wartościowe dla
społeczeństwa. Mam tu na&nbsp;myśli np. logikę matematyczną, muzykę
klasyczną i&nbsp;archeologię, a&nbsp;także tworzenie organizacji
politycznych wśród ludzi pracy. Ludzie konkurują ze sobą, bardziej smutno
niż zaciekle, o&nbsp;parę opłacanych etatów, z&nbsp;których żaden nie jest
opłacany zbyt dobrze. Czasami ludzie nawet płacą za&nbsp;szansę pracowania
w&nbsp;takiej dziedzinie, jeśli ich na&nbsp;to stać. </p>
<p>
   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&nbsp;coś, co niegdyś robili dla
przyjemności. Parę lat później wszyscy powiązani z&nbsp;tą dziedziną będą
wyśmiewać się z&nbsp;pomysłu, że&nbsp;można było w&nbsp;niej pracować
bez&nbsp;dużych zysków finansowych. Będą doradzać planistom, żeby zapewnili
te zyski poprzez&nbsp;rekomendowanie specjalnych przywilejów, praw
i&nbsp;monopoli do&nbsp;tego potrzebnych.</p>
<p>
   Taka zmiana nastąpiła w&nbsp;dziedzinie programowania komputerowego
w&nbsp;ciągu ostatniej dekady. W&nbsp;latach siedemdziesiątych XX wieku
ukazywały się artykuły o&nbsp;&bdquo;komputerowym uzależnieniu&rdquo;:
użytkownicy przyklejali się do&nbsp;komputerów i&nbsp;wydawali na&nbsp;swój
nałóg po&nbsp;sto dolarów tygodniowo. Panowało ogólne przekonanie,
że&nbsp;ludzie kochają programowanie tak bardzo, że&nbsp;poświęciliby dlań
swoje małżeństwo. Dzisiaj panuje ogólne przekonanie, że&nbsp;nikt nie będzie
programował, chyba że&nbsp;za duże pieniądze. Ludzie zapomnieli, w&nbsp;co
wierzyli czterdzieści lat temu.</p>
<p>
   Jeśli w&nbsp;danym okresie prawdą jest, że&nbsp;w&nbsp;pewnej dziedzinie
ludzie będą pracować tylko za&nbsp;duże pieniądze, to nie musi to
na&nbsp;zawsze pozostać prawdą. Pęd zmian może biec w&nbsp;odwrotnym
kierunku, jeśli impuls do&nbsp;tego da społeczeństwo. Jeśli odbierzemy
możliwość zbicia fortuny, to po&nbsp;pewnym czasie ludzie zmodyfikują swoje
postawy i&nbsp;znów będą chętni pracować w&nbsp;tej dziedzinie w&nbsp;zamian
za&nbsp;radość zawodowego spełnienia.</p>
<p>
   Pytanie &bdquo;Jak możemy zapłacić programistom?&rdquo; stanie się
łatwiejsze, gdy zdamy sobie sprawę, że&nbsp;nie chodzi tutaj o&nbsp;płacenie
im fortuny. Pieniądze na&nbsp;zwykłą pensję łatwiej jest zdobyć.</p>

<h4 id="funding">Finansowanie wolnego oprogramowania</h4>
<p>
   Instytucje płacące programistom nie muszą być firmami
programistycznymi. Istnieje już wiele innych instytucji, które mogą to
robić.</p>
<p>
   Producenci sprzętu uważają wspieranie rozwoju oprogramowania za&nbsp;bardzo
ważne, nawet jeśli nie mogą kontrolować jego użycia. W&nbsp;1970 większość
ich oprogramowania była swobodna, bo&nbsp;nawet nie myśleli o ograniczaniu
jego użycia. Dzisiaj ich wzrastająca chęć do&nbsp;przyłączania się
do&nbsp;konsorcjów pokazuje, że&nbsp;zdali sobie sprawę z&nbsp;tego, iż
posiadanie oprogramowania nie jest tym, co jest dla nich rzeczywiście ważne.</p>
<p>
   Wiele przedsięwzięć programistycznych prowadzą uniwersytety. Dzisiaj często
sprzedają ich rezultaty, chociaż nie robiły tego w&nbsp;latach
70. Czy&nbsp;nie jest oczywiste, że&nbsp;uniwersytety rozwijałyby wolne
oprogramowanie, jeśli nie miałyby pozwolenia na&nbsp;sprzedaż programów?
Projekty te mogłyby być wspierane przez te same kontrakty i&nbsp;granty
rządowe, które teraz wspierają rozwój oprogramowania objętego restrykcyjnymi
licencjami.</p>
<p>
   W&nbsp;dzisiejszych czasach powszechne są sytuacje, w&nbsp;których
uniwersytetom przyznaje się granty na&nbsp;rozwój jakiegoś systemu,
a&nbsp;one rozwijają go prawie do&nbsp;końca i&nbsp;mówią, że&nbsp;jest
&bdquo;gotowy&rdquo;. Następnie zakładają firmy, które rzeczywiście go
kończą i&nbsp;czynią zdatnym do&nbsp;użytkowania. Czasami deklarują oni,
że&nbsp;wersja niedokończona jest &bdquo;wolna&rdquo;. Jeśli są źli
do&nbsp;szpiku kości, to zamiast tego zdobywają od&nbsp;uniwersytetu
wyłączną licencję. Nie jest to tajemnicą. Zainteresowani tym faktem otwarcie
to przyznają. Jednak&nbsp;gdyby naukowcy nie byli kuszeni przez możliwość
robienia takich rzeczy, to i&nbsp;tak nadal kontynuowaliby badania naukowe.</p>
<p>
   Programiści tworzący wolne oprogramowanie mogą zarabiać na&nbsp;życie
sprzedając usługi związane ze swoimi programami. Zatrudniono mnie, bym
napisał wersję <a href="/software/gcc/">GNU C compiler</a> dla nowej
platformy sprzętowej i&nbsp;żebym stworzył rozszerzenia interfejsu
użytkownika dla <a href="/software/emacs/">GNU Emacsa</a>. (Oddaję te
ulepszenia w&nbsp;ręce społeczeństwa gdy tylko są gotowe). Poza tym zarabiam
na&nbsp;prowadzeniu zajęć uniwersyteckich.</p>
<p>
   Nie tylko ja pracuję w&nbsp;ten sposób. Sukces odnosi teraz i&nbsp;rośnie
w&nbsp;siłę korporacja, która nie wykonuje żadnych innych prac. Kilka innych
firm także dostarcza komercyjne usługi związane z&nbsp;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&nbsp;przypadku oprogramowania objętego restrykcyjnymi licencjami, nie
licząc bardzo bogatych.</p>
<p>
   Nowe instytucje, takie jak <a href="/fsf/fsf.html">Fundacja Wolnego
Oprogramowania</a>, także mogą finansować programistów. Większość funduszy
Fundacji pochodzi od&nbsp;użytkowników, którzy kupują wysyłkowo taśmy
[obecnie na&nbsp;płytach; przyp. tłum.]. Oprogramowanie zawarte
na&nbsp;taśmach jest wolne, więc&nbsp;każdy użytkownik ma prawo je kopiować
i&nbsp;modyfikować, ale&nbsp;wielu z&nbsp;nich i&nbsp;tak płaci
za&nbsp;swoje kopie. (Przypominam, że&nbsp;&bdquo;free software&rdquo; to
oprogramowanie wolne, a&nbsp;nie darmowe.) Niektórzy użytkownicy, którzy
mają już kopie, zamawiają taśmy żeby nas wesprzeć, bo&nbsp;uważają,
że&nbsp;na to zasługujemy. Fundacja otrzymuje także pokaźne darowizny
od&nbsp;producentów sprzętu.</p>
<p>
   Fundacja Wolnego Oprogramowania jest organizacją charytatywną, a&nbsp;jej
dochody przeznaczane są na&nbsp;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&nbsp;tą samą opłatą, to zapewniałaby teraz
swojemu założycielowi bardzo dobre utrzymanie.</p>
<p>
   Ponieważ&nbsp;Fundacja jest organizacją charytatywną, programiści często
pracują dla nas za&nbsp;połowę pieniędzy, które mogliby dostać gdzieś
indziej. Robią to, bo&nbsp;nie ma u&nbsp;nas biurokracji, a&nbsp;także
dlatego, że&nbsp;czują satysfakcję wiedząc, że&nbsp;ich praca nie będzie
niedostępna użytkownikom. Głównym powodem, dla którego to robią jest fakt,
że&nbsp;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&nbsp;ochotnika).</p>
<p>
   To potwierdza, że&nbsp;programowanie to jedna z&nbsp;najbardziej
fascynujących dziedzin, obok muzyki i&nbsp;sztuki. Nie musimy się obawiać,
że&nbsp;nikt nie będzie chciał programować.</p>

<h4 id="owe">Co użytkownicy winni są programistom?</h4>
<p>
   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&nbsp;działania użytkowników, dlatego&nbsp;finansowe wspieranie
dalszego rozwoju jest nie tylko fair, ale&nbsp;także w&nbsp;dłuższej
perspektywie w&nbsp;interesie użytkowników.</p>
<p>
   Jednak&nbsp;nie odnosi się to do&nbsp;twórców oprogramowania objętego
restrykcyjnymi licencjami, bo&nbsp;utrudnianie zasługuje na&nbsp;karę,
a&nbsp;nie nagrodę.</p>
<p>
   Mamy tu więc&nbsp;paradoks: twórcy użytecznego oprogramowania należy się
wsparcie użytkowników, ale&nbsp;każda próba zamiany tego moralnego
zobowiązania w&nbsp;żądanie niszczy jego podstawę. Twórca może zasługiwać
na&nbsp;nagrodę lub&nbsp;się jej domagać, ale&nbsp;nie obie te rzeczy
na&nbsp;raz.</p>
<p>
   Uważam, że&nbsp;postępujący etycznie programista, który zetknie się
z&nbsp;tym paradoksem, musi zachowywać się tak, żeby zasłużyć
na&nbsp;nagrodę, ale&nbsp;powinien także prosić użytkowników
o&nbsp;dobrowolne datki. W&nbsp;końcu użytkownicy nauczą się wspierać
programistów bez&nbsp;przymusu, tak samo jak nauczyli się wspierać publiczne
radio i&nbsp;telewizję.</p>

<h3 id="productivity">Co to jest produktywność programistyczna? </h3>
<p>
   Jeśli oprogramowanie byłoby wolne, to programiści istnieliby nadal, tyle
że&nbsp;być może byłoby ich mniej. Czy&nbsp;byłoby to złe dla społeczeństwa?</p>
<p>
   Niekoniecznie. W&nbsp;dzisiejszych czasach rozwinięte państwa mają mniej
rolników niż w&nbsp;roku 1900, ale&nbsp;nie uważamy tego za&nbsp;złe dla
społeczeństwa, bo&nbsp;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&nbsp;zaspokojenia popytu, bo&nbsp;na wszystkich poziomach zwiększyłaby
się produktywność:</p>

<ul>
<li> Bardziej rozpowszechnione użytkowanie każdego stworzonego programu.</li>
<li> Możliwość modyfikacji istniejącego oprogramowania do&nbsp;własnych potrzeb
zamiast pisania wszystkiego od&nbsp;początku.</li>
<li> Lepsze wykształcenie programistów.</li>
<li> Wyeliminowanie wykonywania po&nbsp;raz kolejny tej samej pracy.</li>
</ul>

<p>
   Ludzie, którzy sprzeciwiają się współpracy twierdząc, że&nbsp;doprowadziłoby
to do&nbsp;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&nbsp;przemysł
programistyczny potrzebuje zwiększonej produktywności. Więc&nbsp;o&nbsp;co
w&nbsp;końcu chodzi?</p>
<p>
   &bdquo;Produktywność programistyczna&rdquo; może znaczyć dwie różne rzeczy:
ogólną produktywność całej produkcji oprogramowania lub&nbsp;produktywność
poszczególnych projektów. Ogólna produktywność jest tym, co społeczeństwo
chciałoby podnieść, a&nbsp;najprostszym sposobem, żeby to zrobić, jest
zniesienie sztucznych barier, które stoją na&nbsp;drodze współpracy
i&nbsp;ją zmniejszają. Jednak&nbsp;naukowcy badający &bdquo;produktywność
programistyczną&rdquo; skupiają się tylko na&nbsp;drugim, ograniczonym
znaczeniu tego pojęcia, w&nbsp;przypadku którego polepszenie sytuacji wymaga
trudnych postępów technologicznych.</p>

<h3 id="competition">Czy&nbsp;konkurencja jest nieunikniona?</h3>
<p>
   Czy&nbsp;nieuniknione jest, że&nbsp;ludzie będą próbować ze sobą konkurować,
żeby być lepszymi od&nbsp;swoich rywali? Być może tak. Ale&nbsp;konkurencja
sama w&nbsp;sobie nie jest szkodliwa, rzeczą szkodliwą jest <em>walka</em>.</p>
<p>
   Konkurować ze sobą można na&nbsp;wiele sposobów. Konkurencja może mieć
na&nbsp;celu próbę ciągłego osiągania więcej, prześcigania tego, co zrobili
inni. Na&nbsp;przykład dawno temu istniało współzawodnictwo pomiędzy
programistycznymi geniuszami o&nbsp;to, kto potrafi zmusić komputer
do&nbsp;zrobienia najbardziej zadziwiającej rzeczy lub&nbsp;napisać
najkrótszy bądź&nbsp;najszybszy program wykonujący jakieś zadanie. Taka
konkurencja może być pożyteczna dla wszystkich, <em>dopóki</em> utrzymany
jest duch pozytywnego współzawodnictwa.</p>
<p>
   Konstruktywna konkurencja wystarcza by zmotywować ludzi do&nbsp;wielkich
wysiłków. Kilkoro ludzi konkuruje ze sobą o&nbsp;tytuł pierwszej osoby,
która odwiedzi wszystkie kraje świata, niektórzy wydają na&nbsp;to całe
fortuny. Jednak&nbsp;nie przekupują kapitanów statków, by wysadzili ich
rywali na&nbsp;bezludnych wyspach. Chętnie przystają na&nbsp;to, by wygrał
najlepszy.</p>
<p>
   Konkurencja przekształca się w&nbsp;walkę, gdy konkurenci zaczynają próbować
przeszkadzać sobie nawzajem zamiast samemu iść do&nbsp;przodu, kiedy
&bdquo;Niech wygra najlepszy&rdquo; ustępuje miejsca &bdquo;Dajcie mi
wygrać, nawet jeśli nie jestem najlepszy&rdquo;. Objęte restrykcyjną
licencją oprogramowanie jest szkodliwe nie dlatego, że&nbsp;jest formą
konkurencji, ale&nbsp;dlatego, że&nbsp;jest formą walki pomiędzy obywatelami
naszego społeczeństwa.</p>
<p>
   Konkurencja w&nbsp;biznesie niekoniecznie musi być walką. Na&nbsp;przykład,
gdy konkurują ze sobą dwa warzywniaki, to ich energia idzie
na&nbsp;ulepszanie własnej oferty, a&nbsp;nie sabotowanie
rywala. Ale&nbsp;to nie jest przejawem specjalnego przywiązania
do&nbsp;biznesowej etyki. W&nbsp;tej dziedzinie jest po&nbsp;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&nbsp;rozwoju jest formą walki.</p>
<p>
   Ideologia biznesu nie przygotowuje ludzi na&nbsp;powstrzymywanie się przed
pokusą walki z&nbsp;konkurentami. Niektóre formy walki zostały zakazane
przez ustawy antymonopolowe, ustawy o&nbsp;prawdzie w&nbsp;reklamie, itd.,
ale&nbsp;zamiast uogólnić to do&nbsp;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.</p>

<h3 id="communism">&bdquo;A może byś się przeniósł do&nbsp;Rosji?&rdquo;</h3>
<p>
   W&nbsp;Stanach Zjednoczonych każdy zwolennik czegoś innego niż najbardziej
ekstremalne formy wolnorynkowego egoizmu często spotyka się z&nbsp;tym
oskarżeniem. Jest ono np. wymierzone w&nbsp;zwolenników narodowego systemu
ochrony zdrowia, takiego jakie działają we wszystkich uprzemysłowionych
krajach wolnego świata. Jest wymierzone w&nbsp;zwolenników publicznego
wsparcia dla sztuki, które jest także powszechne w&nbsp;rozwiniętych
krajach. Pomysł, że&nbsp;obywatele mają jakieś zobowiązania wobec dobra
publicznego jest w&nbsp;Ameryce identyfikowany
z&nbsp;komunizmem. Ale&nbsp;na ile podobne do&nbsp;siebie są te dwie idee
w&nbsp;rzeczywistości?</p>
<p>
   Komunizm praktykowany w&nbsp;Związku Radzieckim był systemem
scentralizowanej kontroli, w&nbsp;którym każda działalność była poddana
reżimowi, rzekomo dla wspólnego dobra, ale&nbsp;tak naprawdę dla dobra
członków partii komunistycznej. Urządzenia do&nbsp;kopiowania były tam
ściśle pilnowane, aby&nbsp;zapobiec nielegalnemu wykonywaniu kopii.</p>
<p>
   Amerykański system praw autorskich dotyczących oprogramowania ustanawia
scentralizowaną kontrolę nad&nbsp;dystrybucją programów i&nbsp;stoi
na&nbsp;straży urządzeń do&nbsp;kopiowania, używających różnych
zabezpieczeń, by zapobiec wykonywaniu nielegalnych kopii.</p>
<p>
   W&nbsp;przeciwieństwie do&nbsp;tego, ja pracuję na&nbsp;rzecz systemu,
w&nbsp;którym ludzie mają wolną rękę i&nbsp;mogą decydować o&nbsp;swoich
poczynaniach. W&nbsp;szczególności mają możliwość pomagania swoim znajomym
oraz&nbsp;modyfikowania i&nbsp;ulepszania narzędzi, których codziennie
używają. Systemu opartego na&nbsp;ochotniczej współpracy
i&nbsp;decentralizacji.</p>
<p>
   Tak więc&nbsp;jeśli chcemy oceniać poglądy według ich podobieństwa
do&nbsp;radzieckiego komunizmu, to komunistami są właściciele
oprogramowania.</p>

<h3 id="premises">Problem przesłanek</h3>
<p>
   Zakładam w&nbsp;tym artykule, że&nbsp;użytkownik oprogramowania nie jest
mniej ważny niż jego twórca, a&nbsp;nawet pracodawca twórcy. Innymi słowy
ich interesy i&nbsp;potrzeby mają jednakową wagę podczas decydowania, która
droga jest najlepsza.</p>
<p>
   Ta przesłanka nie jest ogólnie przyjmowana. Wielu twierdzi,
że&nbsp;pracodawca twórcy jest z&nbsp;natury ważniejszy niż ktokolwiek
inny. Mówią oni na&nbsp;przykład, że&nbsp;powodem dla istnienia właścicieli
oprogramowania jest zapewnienie szefowi twórcy korzyści, na&nbsp;które
zasługuje, niezależnie od&nbsp;tego, jak może to wpłynąć
na&nbsp;społeczeństwo.</p>
<p>
   Próby udowodnienia lub&nbsp;obalenia tych przesłanek nie mają sensu. Dowód
wymaga wspólnych przesłanek. Tak więc&nbsp;większość z&nbsp;tego, co mówię
jest adresowana do&nbsp;tych, którzy uznają moje przesłanki
lub&nbsp;przynajmniej są zainteresowani, jakie są ich konsekwencje. Dla
tych, którzy uważają, że&nbsp;właściciel jest ważniejszy niż wszyscy inni,
artykuł ten jest po&nbsp;prostu bez&nbsp;znaczenia.</p>
<p>
   Tylko dlaczego duży odsetek Amerykanów akceptuje przesłankę, która wynosi
pewnych ludzi ponad wszystkich innych? Częściowo przez przekonanie,
że&nbsp;taka przesłanka jest częścią amerykańskiej tradycji
prawnej. Niektórzy myślą, że&nbsp;poddawanie jej w&nbsp;wątpliwość to
podważanie podstaw społeczeństwa.</p>
<p>
   Ważne jest, żeby ci ludzie zdali sobie sprawę, że&nbsp;ta przesłanka nie
jest częścią naszej tradycji prawnej i&nbsp;nigdy nią nie była.</p>
<p>
   Konstytucja [Stanów Zjednoczonych; przyp. tłum.] mówi, że&nbsp;celem prawa
autorskiego jest &bdquo;promocja postępu nauki i&nbsp;sztuk
użytecznych&rdquo;. Więcej na&nbsp;ten temat powiedział Sąd Najwyższy,
stwierdzając w&nbsp;sprawie Fox Film przeciwko Doyal,
że&nbsp;&bdquo;Wyłączny przedmiot zainteresowania Stanów Zjednoczonych
i&nbsp;podstawowy cel nadawania monopolu [praw autorskich] leży
w&nbsp;ogólnych korzyściach, jakie społeczeństwo wynosi z&nbsp;pracy
autorów&rdquo;.</p>
<p>
   Nie musimy się zgadzać z&nbsp;Konstytucją lub&nbsp;Sądem
Najwyższym. (W&nbsp;pewnym okresie obie te instytucje aprobowały
niewolnictwo.) Tak więc&nbsp;ich stanowiska nie obalają przesłanki
o&nbsp;wyższości właścicieli. Mam jednak&nbsp;nadzieję, że&nbsp;jej siła
zostanie zmniejszona przez świadomość, że&nbsp;jest to radykalne prawicowe
założenie, a&nbsp;nie założenie tradycyjnie przyjmowane.</p>

<h3 id="conclusion">Wnioski</h3>
<p>
   Lubimy myśleć, że&nbsp;nasze społeczeństwo popiera pomaganie
bliźnim. Jednak&nbsp;za każdym razem, kiedy nagradzamy kogoś
za&nbsp;utrudnianie lub&nbsp;podziwiamy go za&nbsp;bogactwo, które
w&nbsp;ten sposób zdobył, dajemy dowód czegoś całkiem odwrotnego.</p>
<p>
   Nieudostępnianie oprogramowania jest jedną z&nbsp;form naszej powszechnej
gotowości do&nbsp;stawiania osobistych korzyści ponad dobro
społeczne. Możemy to prześledzić od&nbsp;Ronalda Reagana do&nbsp;Jamesa
Bakkera, od&nbsp;Ivana Boesky'ego do&nbsp;Exxonu, od&nbsp;upadających banków
do&nbsp;upadających szkół. Możemy to zmierzyć wielkością populacji
bezdomnych i&nbsp;więźniów. Duch antyspołeczny sam się napędza,
ponieważ&nbsp;im więcej widzimy, że&nbsp;inni nam nie pomagają, tym bardziej
wydaje nam się bez&nbsp;sensu pomaganie innym. W&nbsp;ten sposób
społeczeństwo zamienia się w&nbsp;dżunglę.</p>
<p>
   Jeśli nie chcemy żyć w&nbsp;dżungli, musimy zmienić nasze postawy. Musimy
zacząć dawać do&nbsp;zrozumienia, że&nbsp;dobry obywatel to taki, który
współpracuje kiedy należy, a&nbsp;nie taki, który odnosi sukcesy
w&nbsp;zabieraniu innym. Mam nadzieję, że&nbsp;pomoże w&nbsp;tym ruch
wolnego oprogramowania: przynajmniej w&nbsp;jednej dziedzinie zastąpimy
dżunglę bardziej efektywnym systemem, który zachęca do&nbsp;ochotniczej
współpracy i&nbsp;dzięki niej funkcjonuje.</p>


<h3 id="footnotes">Przypisy</h3>

<ol>
<li id="f1">Słowo &bdquo;free&rdquo; [wolny, darmowy] w&nbsp;&bdquo;free software&rdquo;
odnosi się do&nbsp;wolności, a&nbsp;nie do&nbsp;ceny. Cena za&nbsp;kopię
wolnego programu może być zerowa, mała lub&nbsp;(rzadko) dość duża.</li>

<li id="f2">Sprawa zanieczyszczenia środowiska i&nbsp;korków nie wpływa na&nbsp;tę
konkluzję. Jeśli chcemy uczynić jazdę samochodem droższą,
aby&nbsp;zniechęcić do&nbsp;jazdy samochodem w&nbsp;ogóle, to nie jest
dobrze robić to instalując budki pobierające opłaty, które powiększają
zanieczyszczenie i&nbsp;korki. Znacznie lepszy jest podatek
na&nbsp;benzynę. Tak samo nie ma z&nbsp;nią związku chęć zwiększenia
bezpieczeństwa przez ograniczanie prędkości maksymalnej&nbsp;– ogólnie
dostępna droga poprawia płynność ruchu, przez co wzrasta bezpieczeństwo,
niezależnie od&nbsp;limitu prędkości.</li>

<li id="f3">Ktoś może uważać jakiś program za&nbsp;szkodliwą rzecz, która w&nbsp;ogóle
nie powinna być dostępna, jak Lotus Marketplace, baza danych informacji
osobistych, którą wycofano ze sprzedaży z&nbsp;powodu presji
społeczeństwa. Większość z&nbsp;tego, co mówię, nie odnosi się do&nbsp;tego
przypadku, ale&nbsp;nie ma specjalnie sensu w&nbsp;upieraniu się
za&nbsp;właścicielami na&nbsp;podstawie stwierdzenia, że&nbsp;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&nbsp;przypadku programu, którego
użytkowanie jest destrukcyjne.</li>
</ol>

<hr />
<blockquote id="fsfs"><p class="big">Ten esej jest opublikowany w&nbsp;<a
href="http://shop.fsf.org/product/free-software-free-society/"><cite>Free
Software, Free Society: The Selected Essays of Richard
M. Stallman</cite></a>.</p></blockquote>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<b>Przypis tłumacza</b>:
<ol>
<li id="TransNote1">W&nbsp;Polsce, prawa autorskie nie służą dobru
publicznemu. Właściciele oprogramowania przeforsowali w&nbsp;Sejmie dużo
bardziej restrykcyjne prawa autorskie dla oprogramowania niż np. dla filmów,
muzyki czy&nbsp;książek.</li>
</ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.pl.html" -->
<div id="footer">
<div class="unprintable">

<p>Wszelkie pytania dotyczące GNU i&nbsp;FSF prosimy kierować na&nbsp;adres <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Inne metody kontaktu
z&nbsp;FSF można znaleźć na&nbsp;stronie <a
href="/contact/contact.html">kontakt</a> <br /> Informacje o niedziałających
odnośnikach oraz&nbsp;inne poprawki (lub propozycje) prosimy wysyłać
na&nbsp;adres <a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Staramy się, aby&nbsp;tłumaczenia były wierne i&nbsp;wysokiej jakości,
ale&nbsp;nie jesteśmy zwolnieni z&nbsp;niedoskonałości. Komentarze odnośnie
tłumaczenia polskiego oraz&nbsp;zgłoszenia dotyczące chęci współpracy
w&nbsp;tłumaczeniu prosimy kierować na&nbsp;adres <a
href="mailto:www-pl-trans@gnu.org">www-pl-trans@gnu.org</a>. <br /> Więcej
informacji na&nbsp;temat koordynacji oraz&nbsp;zgłaszania propozycji
tłumaczeń artykułów znajdziecie na&nbsp;<a
href="/server/standards/README.translations.html">stronie tłumaczeń</a>.</p>
</div>

<p>Copyright &copy; 1991, 1992, 1998, 2000, 2001, 2006, 2007, 2010, 2017, 2018,
2020 Free Software Foundation, Inc.</p>

<p>Ta strona jest dostępna na&nbsp;<a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.pl">licencji
Creative Commons Uznanie autorstwa&nbsp;&ndash; Bez&nbsp;utworów zależnych
4.0 Międzynarodowe</a>.</p>

<!--#include virtual="/server/bottom-notes.pl.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Tłumaczenie: Radosław Moszczyński 2005, poprawki: Wojciech Kotwica 2005,
2006, Marcin Wolak 2010, Jan Owoc 2010.</div>

<p class="unprintable"><!-- timestamp start -->
Aktualizowane:

$Date: 2020/07/05 14:01:37 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>