Poznaj filozofię Richarda Stallmana dotyczącą wolnego oprogramowania, Projekt GNU i GPL — oraz jak zmieniły one licencjonowanie, prawa deweloperów i podejście do open source.
Oprogramowanie to nie tylko produkt techniczny — to też zestaw uprawnień. Kto może je uruchamiać, kopiować, udostępniać znajomemu, naprawiać błąd lub budować coś nowego na jego podstawie? Na te pytania odpowiadają mniej kod, a bardziej licencje. W miarę jak oprogramowanie stało się centrum pracy, komunikacji i badań, zasady mówiące „co wolno robić” zaczęły kształtować innowacje równie mocno co funkcje.
Richard Stallman (często nazywany „RMS”) ma znaczenie, bo uczynił te zasady niemożliwymi do zignorowania. Na początku lat 80. zauważył zmianę: coraz więcej programów było dystrybuowanych bez kodu źródłowego, a użytkownikom coraz częściej mówiono, że mogą korzystać z oprogramowania tylko na czyichś warunkach. Stallman przedstawił to nie jako drobną niedogodność, lecz jako utratę wolności użytkowników i deweloperów — i odpowiedział, proponując jasny zestaw zasad i narzędzi prawnych do ochrony tych wolności.
Artykuł koncentruje się na ideach Stallmana i ich praktycznych konsekwencjach: definicji wolnego oprogramowania, Projekcie GNU, copyleft i GNU General Public License (GPL) — oraz jak wpłynęły one na współczesny ekosystem open source i normy licencjonowania.
To nie jest biografia ani techniczne głębokie zanurzenie w kompilację jąder czy zarządzanie repozytoriami. Nie potrzebujesz wykształcenia programistycznego, żeby zrozumieć tekst.
Stallman jest wpływowy, ale też kontrowersyjny. Celem tutaj jest pozostać rzeczowym i czytelnym: co postulował, jakie mechanizmy prawne powstały, jak firmy i deweloperzy się dostosowali i gdzie dziś toczy się debata — tak, żebyś zobaczył, dlaczego jego praca wciąż wpływa na codzienne wybory dotyczące oprogramowania.
„Wolne oprogramowanie” łatwo źle zrozumieć, bo słowo wolne brzmi jak informacja o cenie. Richard Stallman używał wolne w sensie wolności — zdolności użytkownika do kontrolowania oprogramowania, na którym polega.
Jeśli program kosztuje 0 zł, ale nie wolno ci go przejrzeć, zmienić ani udostępnić, może być „darmowy jak piwo”, a jednocześnie niewolny w rozumieniu, które Stallman uważał za istotne.
Wolne oprogramowanie definiują cztery podstawowe uprawnienia:
Te wolności dotyczą samodzielności: nie jesteś tylko konsumentem narzędzi — możesz stać się uczestnikiem, który może weryfikować, dostosowywać i ulepszać oprogramowanie.
Wolności 1 i 3 są niemożliwe bez dostępu do kodu źródłowego — instrukcji czytelnych dla człowieka. Bez niego oprogramowanie jest bardziej jak zapieczętowane urządzenie: możesz go używać, ale nie rozumiesz, co robi, nie możesz naprawić go, gdy się zepsuje, ani dostosować do nowych potrzeb.
Dostęp do kodu źródłowego ma też znaczenie dla zaufania. Umożliwia niezależne przeglądy (pod kątem prywatności, bezpieczeństwa i uczciwości) i sprawia, że utrzymanie oprogramowania jest możliwe, nawet jeśli pierwotny autor przestanie je wspierać.
Pomyśl o posiłku w restauracji.
To sedno: wolne oprogramowanie dotyczy wolności, które pozwalają użytkownikom zachować kontrolę nad ich obliczaniem.
Zanim „licencjonowanie oprogramowania” stało się powszechnym tematem sporów, wiele środowisk programistycznych — zwłaszcza uniwersytety i laboratoria badawcze — opierało się na założeniu: jeśli możesz ulepszyć narzędzie, dzielisz się poprawką. Kod źródłowy zwykle szedł wraz z oprogramowaniem, ludzie uczyli się, czytając kod innych, a poprawki rozchodziły się przez nieformalne współprace.
Ta kultura zaczęła się zmieniać, gdy oprogramowanie stało się produktem. Firmy (a nawet niektóre instytucje) zaczęły traktować kod źródłowy jako przewagę konkurencyjną. Dystrybucja wiązała się z zakazami udostępniania, kod przestał być dołączany do programów, a umowy o zachowaniu poufności stały się normalne. Dla deweloperów przyzwyczajonych do wspólnego rozwiązywania problemów ta zmiana była nie tylko niewygodą — wyglądała jak zmiana reguł, która uczyniła rozwiązywanie problemów przez społeczność prawnie ryzykownym.
Jedna z często powtarzanych historii dotyczy drukarki w AI Lab na MIT. Stallman opisywał, jak nowa drukarka przyszła z oprogramowaniem dostarczanym tylko w postaci binarnej, bez kodu źródłowego. Problem praktyczny był trywialny: laboratorium chciało zmodyfikować program, by np. powiadamiać użytkowników o zacięciach lub inteligentnie kierować zadania druku. W dawnych „hakerskich” normach ktoś by załatał kod i udostępnił poprawkę. Tutaj nie mogli — bo nie mieli prawa zobaczyć ani zmienić źródła.
Warto zachować proporcje: to nie jedna drukarka stworzyła globalny ruch. Był to czytelny, relatywny przykład szerszego trendu — narzędzia, od których ludzie zależeli, stawały się nie do naprawienia przez ich użytkowników.
Dla Stallmana kluczowy problem nie był jedynie technicznym dostępem; chodziło o utratę wolności do współpracy. Jeśli nie możesz badać, jak program działa, nie kontrolujesz go naprawdę. Jeśli nie możesz udostępniać ulepszeń, społeczności się rozpadają, a wszyscy zaczynają prywatnie wynajdywać poprawki na nowo.
To założenie ukształtowało innowacje licencyjne, które nastąpiły. Zamiast polegać na dobrej woli czy nieformalnych normach, Stallman chciał reguł, które zachowają możliwość używania, badania, modyfikowania i dzielenia się oprogramowaniem — tak aby współpraca nie mogła być cofnięta w momencie, gdy program stanie się wartościowy komercyjnie.
Duży krok Stallmana to nie tylko manifest — to praktyczne przedsięwzięcie inżynieryjne. W 1983 roku ogłosił Projekt GNU, z ambitnym celem: zbudować kompletny system operacyjny, którego każdy może używać, badać, zmieniać i udostępniać, pozostając jednocześnie kompatybilnym z Unixem, aby ludzie mogli uruchamiać znane programy i zachować swoje workflowy.
System operacyjny to nie pojedynczy program — to całe stosy komponentów. GNU postawiło sobie za cel stworzyć wszystkie codzienne elementy potrzebne do użytecznego komputera, w tym:
Mówiąc prościej: GNU budowało instalację, okablowanie i przełączniki — nie tylko jedno urządzenie.
Na początku lat 90. GNU dostarczyło ogromną część tego „userlandu”, ale brakowało jednego krytycznego elementu: jądra (części zarządzającej sprzętem i zasobami systemu). Kiedy w 1991 roku pojawił się Linux, wypełnił tę lukę.
Dlatego wiele popularnych dziś systemów łączy komponenty GNU z jądrem Linux — często określane jako „GNU/Linux”.
GNU uczyniło ideę wolnego oprogramowania realną, tworząc działającą bazę, na której inni mogli budować. Filozofia wyjaśniała dlaczego wolność jest ważna; GNU dostarczyło narzędzi, które uczyniły tę wolność praktyczną, powtarzalną i skalowalną.
Copyleft to strategia licencyjna mająca na celu utrzymanie oprogramowania jako wolnego nie tylko w pierwszym wydaniu, lecz także w przyszłych wersjach. Jeśli otrzymasz kod objęty copyleftem, możesz go używać, badać, modyfikować i udostępniać — ale kiedy rozpowszechniasz zmodyfikowaną wersję, musisz przekazać te same wolności innym.
Copyleft brzmi jak „anty‑copyright”, ale w rzeczywistości opiera się na prawie autorskim. Autor używa praw autorskich, by ustalić zasady w licencji: „Możesz kopiować i modyfikować to, ale jeśli rozpowszechniasz, musisz zachować tę samą licencję.” Bez prawa autorskiego nie byłoby prawnego mechanizmu do egzekwowania tych warunków.
Pomyśl o tym jako regule towarzyszącej kodowi:
Celem jest zapobieganie wzorcowi, który martwił Stallmana: ktoś bierze pracę społeczności, ulepsza ją, a potem zamyka ulepszenia.
Licencje permisywne (jak MIT czy BSD) zwykle pozwalają robić niemal wszystko z kodem, łącznie z redystrybucją zmodyfikowanych wersji na zamkniętych, własnościowych warunkach. Licencje copyleftowe (jak GNU GPL) nadal pozwalają szeroko używać i modyfikować kod, ale wymagają, aby redystrybuowane pochodne pozostały na tych samych copyleftowych warunkach — tak, by wolność była zachowana w dół łańcucha.
GNU General Public License (GPL) zmieniła licencjonowanie oprogramowania, czyniąc „dzielenie się” regułą wykonalną prawnie, a nie tylko uprzejmym gestem. Wcześniej można było otrzymać kod źródłowy, ulepszyć go, a potem wypuścić zamkniętą wersję, której użytkownicy nie mogli badać ani modyfikować. GPL odwróciła tę dynamikę: chroni prawa użytkowników przez dołączenie warunków do dystrybucji.
Praktycznie GPL daje prawa do uruchamiania programu w dowolnym celu, czytania i modyfikowania źródła oraz udostępniania oryginału lub zmodyfikowanych wersji.
Jeśli rozpowszechniasz oprogramowanie objęte GPL (zwłaszcza w produkcie), musisz przekazać te same wolności. To zazwyczaj oznacza:
Obowiązki GPL uruchamiają się głównie wtedy, gdy dystrybuujesz oprogramowanie innym — wysyłasz binaria, sprzedajesz urządzenia z oprogramowaniem lub przekazujesz kopie klientom. Jeśli modyfikujesz kod GPL do użytku prywatnego i nie dystrybuujesz go, zwykle nie musisz publikować źródła.
Nie trzeba studiów prawniczych, aby zrozumieć sedno: jeśli twój program włącza kod GPL w sposób tworzący dzieło połączone (np. przez linkowanie do niego), rezultat zwykle traktuje się jako dzieło zależne i trzeba je dystrybuować na GPL. Samo uruchamianie programu GPL lub komunikacja z nim jako oddzielnym procesem przez standardowe interfejsy często jest inaczej traktowane.
GPLv2 to klasyczna, szeroko stosowana wersja. GPLv3 dodaje ochrony związane z patentami i „tivoizacją” (blokowanie zmodyfikowanego oprogramowania w urządzeniach). LGPL jest zaprojektowana dla bibliotek: pozwala na linkowanie z programami własnościowymi w pewnych warunkach, zachowując jednocześnie wolność samej biblioteki.
Wolne licencje (szczególnie GNU GPL) nie tylko „pozwalają” na dzielenie się — chronią prawo do badania, modyfikowania i redystrybucji w sposób trudny do cofnięcia. Dla deweloperów oznacza to, że twoje ulepszenia mogą pozostać dostępne innym na tych samych warunkach, zamiast zostać wchłonięte przez zamknięty produkt bez korzyści dla społeczności.
Na mocy GPL możesz:
Dlatego GPL często nazywa się „egzekwowalną wzajemnością”. Jeśli ktoś rozpowszechnia program objęty GPL (lub dzieło zależne), nie może dodać ograniczeń blokujących downstream użytkowników przed dokonywaniem podobnych modyfikacji i dzielenia się.
Te prawa wiążą się z obowiązkami przy dystrybucji oprogramowania:
Te obowiązki nie są „pułapkami” — są mechanizmem, który chroni współpracę przed jednostronnym wydobyciem wartości.
Zespoły powinny traktować zgodność licencji jak higienę wydania. Śledź:
Prosty SBOM i powtarzalna lista kontrolna przy wydaniach mogą zapobiec większości problemów zanim prawnicy będą musieli interweniować.
Na poziomie kodu „wolne oprogramowanie” i „open source” często opisują te same projekty. Rozróżnienie polega głównie na dlaczego dzielenie się jest ważne.
Ruch Free Software (związany z Richardem Stallmanem i Free Software Foundation) traktuje wolność oprogramowania jako kwestię etyczną: użytkownicy powinni mieć prawo uruchamiać, badać, modyfikować i udostępniać oprogramowanie. Chodzi nie tylko o lepsze inżynierstwo — lecz o ochronę autonomii użytkownika.
Podejście Open Source podkreśla praktyczne rezultaty: lepszą współpracę, szybszą iterację, mniej błędów i poprawę bezpieczeństwa dzięki przejrzystości. Pozwala promować otwartość jako lepszy model rozwoju, bez konieczności przyjmowania stanowiska etycznego.
W 1998 r. Open Source Initiative spopularyzowała termin „open source”, by uczynić ideę bardziej akceptowalną biznesowo. „Free software” często było błędnie rozumiane jako „bezpłatne”, a niektóre firmy obawiały się komunikatu opartego na prawach i etyce. „Open source” dało organizacjom możliwość powiedzenia „pracujemy w ten sposób” bez ideologicznego zabarwienia.
Wiele projektów nazywanych open source używa GNU GPL lub innych licencji copyleft, podczas gdy inne wybierają licencje permisywne jak MIT czy Apache. Tekst prawny może być identyczny; zmienia się opowieść skierowana do współtwórców, użytkowników i klientów. Jedna narracja mówi „to chroni twoje wolności”, druga — „to zmniejsza tarcie i poprawia jakość”.
Jeśli priorytetem twojego zespołu jest zapewnienie, że użytkownicy downstream zachowają te same wolności, postaw na framing free software i rozważ copyleft.
Jeśli priorytetem jest maksymalna adopcja (w tym przez firmy, które nie chcą zobowiązań wzajemnych), framing open source i licencja permisywna mogą być lepsze.
Jeśli chcesz szerokiej współpracy, ale też chcesz, aby ulepszenia wracały, użyj języka open source dla przystępności, a wybierz copyleft jako efektowną gwarancję wyników.
Wolne oprogramowanie nie znaczy „nikt nie zarabia”. Oznacza to, że użytkownicy mają swobodę uruchamiania, badania, modyfikowania i dzielenia się kodem. Wiele firm buduje przychody na tej wolności — często pobierając opłaty za to, z czym organizacje mają realne problemy: niezawodność, odpowiedzialność i czas.
Kilka powszechnych, sprawdzonych modeli:
Współczesnym twistem modelu „managed offering” jest pojawienie się platform generujących i uruchamiających aplikacje szybko. Na przykład Koder.ai to platforma vibe-coding, która pomaga zespołom budować aplikacje webowe, backend i mobilne przez czat — jednocześnie wspierając eksport kodu źródłowego. To połączenie (szybka iteracja plus własność kodu) naturalnie pasuje do wartości stojących za wolnością oprogramowania: zdolności do przeglądu, zmiany i przenoszenia oprogramowania, gdy jest to potrzebne.
Wybór licencji może kształtować, kto przechwytuje wartość:
„Komercyjne” opisuje sposób sprzedaży; „wolne oprogramowanie” opisuje prawa użytkownika. Firma może sprzedawać wolne oprogramowanie, pobierać opłaty za wsparcie i jednocześnie szanować wolność oprogramowania.
Zanim zaangażujesz się w projekt FOSS lub postawisz na nim produkt, zapytaj:
GPL i „FOSS” są często omawiane, ale kilka powtarzających się mitów zaciemnia obraz — zwłaszcza dla zespołów, które chcą szybko wypuścić produkt bez przypadkowego naruszenia licencji.
Nie jest. Domena publiczna oznacza brak właściciela praw autorskich i brak obowiązków — każdy może używać dzieła bez ograniczeń.
GNU GPL to przeciwieństwo „bez ograniczeń”. Autor zachowuje prawa autorskie i udziela szerokiego pozwolenia na użycie, modyfikację i udostępnianie — ale tylko jeśli przestrzegasz warunków GPL (najbardziej znane: udostępnienie źródła przy dystrybucji binariów).
Udostępnienie kodu może pomóc w bezpieczeństwie, ale nie daje gwarancji. Projekt open source może być nadal:
Bezpieczeństwo wymaga aktywnego utrzymania, audytów, odpowiedzialnego ujawniania błędów i dobrych praktyk operacyjnych — nie naklejki licencyjnej.
Ludzie często nazywają GPL „wirusową”, sugerując, że rozprzestrzenia się niekontrolowanie. To nacechowana metafora.
Zwykle chodzi o copyleft: jeśli rozpowszechniasz dzieło zależne od kodu GPL, musisz podać odpowiadające źródło na GPL. To wymóg celowy: chroni wolności użytkowników downstream. To nie „zarażenie” — to warunek, który możesz zaakceptować albo uniknąć, używając innego kodu.
Zasada orientacyjna: obowiązki uruchamiają się głównie przy dystrybucji.
Gdy to ma znaczenie, potrzebna jest dokładna analiza, jak kod jest łączony i dystrybuowany — nie polegaj na uproszczonych założeniach.
Richard Stallman jest postacią kontrowersyjną. Można to przyznać i jednocześnie rzeczowo mówić o trwałym wpływie idei i licencji z nim związanych.
Warto oddzielić dwie rozmowy: (1) dyskusje o Stallmanie jako osobie i członku społeczności oraz (2) mierzalny wpływ zasad wolnego oprogramowania, Projektu GNU i GPL na licencjonowanie oprogramowania i prawa deweloperów. Drugą rozmowę można prowadzić w oparciu o źródła pierwotne (teksty licencji, historie projektów, wzorce adopcji) nawet jeśli opinie o pierwszej są skrajnie różne.
Jedna z powtarzających się krytyk dotyczy nie licencji, lecz zarządzania: jak projekty podejmują decyzje, kto ma władzę i co się dzieje, gdy założyciele, maintainerzy i użytkownicy chcą różnych rzeczy. Społeczności wolnego oprogramowania zmagają się z pytaniami:
Te kwestie są ważne, bo licencje tworzą warunki prawne, ale same nie zapewniają zdrowego procesu decyzyjnego.
Inny ciągły spór dotyczy inkluzywności i norm: jak projekty ustalają oczekiwania dotyczące zachowania, jak rozwiązują konflikty i jak gościnne są dla nowych osób. Niektóre społeczności stawiają na formalne kodeksy postępowania; inne wolą minimalne reguły i nieformalne moderowanie. Żadne podejście nie jest automatycznie „słuszne”, ale istnieją realne kompromisy, o których warto dyskutować bez personalnych ataków.
Oceniając spuściznę Stallmana warto trzymać się weryfikowalnych twierdzeń: co wymaga GPL, jak copyleft zmienił praktyki zgodności i jak te idee wpłynęły na późniejsze licencje i instytucje. Możesz być krytyczny, wspierający lub niezdecydowany — ważne, by być precyzyjnym, uprzejmym i jasnym co do tego, co jest krytykowane.
Największym praktycznym darem Stallmana dla zespołów jest jasne pytanie: jakie wolności chcesz zagwarantować downstream? Odpowiedź zamienia „wybór licencji” z nastroju w przemyślaną decyzję.
Jeśli nie jesteś pewien, zdecyduj na podstawie celu: adopcja (permisywne) kontra wzajemność (copyleft) kontra przyjazność dla bibliotek (słaby copyleft).
LICENSE w katalogu głównym repozytorium (skopiuj pełny tekst licencji).Jeśli tworzysz produkty z pomocą rozwiązań wspomaganych AI (w tym platform czatowych jak Koder.ai), ta lista jest jeszcze ważniejsza: wciąż wysyłasz rzeczywiste zależności, rzeczywiste artefakty i realne obowiązki licencyjne. Szybkość nie zwalnia z odpowiedzialności — wręcz przeciwnie, czyni powtarzalne procedury zgodności cenniejszymi.
Uczyń to nudnym i powtarzalnym:
Dla głębszych porównań, zobacz: /blog/choosing-an-open-source-license i /blog/gpl-vs-mit-vs-apache.
„Wolne oprogramowanie” oznacza wolność, nie cenę.
Program może kosztować 0 zł i wciąż być niewolny, jeśli nie możesz go przejrzeć, zmienić ani udostępnić. Wolne oprogramowanie skupia się na prawach do uruchamiania, badania, modyfikowania i rozpowszechniania oprogramowania, od którego zależysz.
Definicja opiera się na czterech uprawnieniach:
Jeśli którekolwiek z nich brakuje, użytkownicy tracą kontrolę, a współpraca staje się trudniejsza.
Bo bez tego nie da się realistycznie badać ani modyfikować oprogramowania.
Dostęp do kodu źródłowego umożliwia:
Copyleft wykorzystuje prawo autorskie, aby wymagać „dzielenia się na tych samych warunkach” przy dystrybucji.
Możesz używać, modyfikować i nawet sprzedawać oprogramowanie, ale jeśli rozpowszechniasz zmodyfikowaną wersję, musisz zapewnić odbiorcom te same wolności (zwykle poprzez udostępnienie odpowiadającego źródła na tej samej licencji).
GPL daje szerokie prawa (użyć, badać, modyfikować, udostępniać) i żąda wzajemności przy dystrybucji.
Jeśli rozpowszechniasz binaria objęte GPL, zazwyczaj musisz:
Często — nie.
Obowiązki GPL zwykle uruchamiają się przy dystrybucji. Jeśli modyfikujesz kod GPL do użytku wewnętrznego i nie przekazujesz kopii poza organizację, zazwyczaj nie musisz publikować zmian.
(Są wyjątki — traktuj to jako zasadę orientacyjną, nie poradę prawną.)
To zależy od sposobu łączenia kodu.
W praktyce:
Gdy to ma znaczenie, odwzoruj dokładny sposób integracji przed wydaniem.
Różnią się pod kątem problemów, które rozwiązują:
Wybierz według tego, czy chcesz silnej wzajemności (GPL) czy bardziej przyjaznego podejścia dla bibliotek (LGPL).
Zwykle nie na mocy samej GPL.
Jeśli uruchamiasz oprogramowanie GPL na swoich serwerach, a użytkownicy wchodzą w interakcję tylko przez sieć, zwykle nie „rozpowszechniasz” kopii — więc obowiązek udostępnienia kodu się nie pojawia.
Jeśli chcesz, by użycie przez sieć zmuszało do udostępnienia źródła, rozważ AGPL i oceń ją pod kątem modelu wdrożenia.
Tak—wiele firm zarabia na wolnym oprogramowaniu, nie ograniczając praw użytkowników.
Popularne modele to:
Wybór licencji wpływa na strategię: licencje permisywne mogą zwiększać adopcję; copyleft może zniechęcać do zamkniętych forków i wspierać modele usługowe.