Historia oprogramowania open source i jego licencji

Czym jest oprogramowanie open source i skąd się wywodzi

Historia oprogramowania open source to w dużej mierze historia jego licencji, ponieważ to licencja decyduje o tym, co można zrobić z kodem napisanym przez kogoś innego. Kod udostępniano otwarcie na długo przed spisaniem tych licencji. Przestano go udostępniać, gdy stał się produktem, a licencje stworzono po to, aby zapewnić możliwość dochodzenia praw do współdzielenia kodu przed sądem.

To wersja skrócona. Wersja pełna jest istotna, ponieważ oprogramowanie uruchamiane dzisiaj na serwerze nadal nosi ślady tamtych decyzji. Niektóre z nich zapadły w 1983 roku. Inne podjęto w zeszłym roku i to właśnie one są powodem, dla którego niektóre aplikacje w naszych przewodnikach dotyczących self-hostingu występują obecnie w dwóch wersjach o różnych nazwach.

Oprogramowanie było udostępniane przed rozpoczęciem jego sprzedaży

W latach 50. i 60. XX wieku oprogramowanie było dostarczane wraz z maszyną. IBM dołączał kod źródłowy do swoich systemów, a grupy użytkowników, takie jak SHARE założona w 1955 roku, wymieniały się programami na taśmach. Dwa czynniki zakończyły ten stan rzeczy. W 1969 roku IBM ogłosił, że wyceni oprogramowanie oddzielnie od sprzętu, co stworzyło samodzielny rynek oprogramowania. Następnie prawo dostosowało się do nowej sytuacji. Ustawa Computer Software Copyright Act z 1980 roku potwierdziła, że programy są utworami podlegającymi prawu autorskiemu w Stanach Zjednoczonych. Po 1980 roku kod, którego użytkownik nie napisał samodzielnie, stał się domyślnie zamknięty, więc jego udostępnianie wymagało pisemnej zgody autora.

Homebrew Computer Club i list otwarty do hobbystów

Pierwsze spotkanie Homebrew Computer Club odbyło się w marcu 1975 roku w garażu w Menlo Park w Kalifornii. Członkowie przynosili sprzęt oraz taśmy papierowe, a kopiowanie było częścią spotkania. Altair BASIC, napisany przez Billa Gatesa i Paula Allena, krążył po sali na kopiowanych taśmach. W lutym 1976 roku Gates odpowiedział w biuletynie klubu „Listem otwartym do hobbystów” (An Open Letter to Hobbyists).

Jak większość hobbystów zapewne wie, większość z was kradnie oprogramowanie.

Napisał, że mniej niż jeden na dziesięciu właścicieli Altair zapłacił za BASIC, a czas pracy komputera poświęcony na jego napisanie był wart ponad 40 000 dolarów. Cała współczesna argumentacja zawarta jest już w tym liście. Kopiowanie oprogramowania nic nie kosztuje i pomaga każdemu, kto je kopiuje. Napisanie go wciąż kosztowało kogoś rok życia. Każda licencja opisana poniżej jest próbą odpowiedzi na oba te fakty jednocześnie.

System GNU w 1983 roku oraz licencja GPL jako innowacja prawna

Richard Stallman ogłosił powstanie projektu GNU we wrześniu 1983 roku w Usenet, sieci grup dyskusyjnych używanej przed erą WWW. Nazwa GNU to rekurencyjny akronim od "GNU's Not Unix". Plan zakładał stworzenie kompletnego systemu kompatybilnego z Unixem, który każdy mógłby kopiować i modyfikować.

Wolny Unix! Począwszy od Święta Dziękczynienia, zamierzam napisać kompletny system oprogramowania kompatybilny z Unixem o nazwie GNU (od GNU's Not Unix) i udostępnić go za darmo każdemu, kto może z niego skorzystać.

Fundacja Free Software Foundation (FSF) powstała w 1985 roku. Jej definicja wolnego oprogramowania wymienia cztery wolności, numerowane od zera: uruchamianie programu w dowolnym celu, badanie i modyfikowanie go, redystrybucję kopii oraz rozpowszechnianie zmodyfikowanych wersji. Wolność 1 wymaga dostępu do kodu źródłowego, ponieważ badanie pliku binarnego w praktyce jest niemożliwe. Słowo "wolny" (ang. free) odnosi się tutaj do wolności, a nie do ceny. FSF używa sformułowania "free as in free speech, not free beer" (wolność jak w wolności słowa, a nie jak w darmowym piwie).

Manifest nie był najważniejszym osiągnięciem. Była nim licencja. GNU General Public License (GPL) wykorzystuje prawo autorskie do wymuszania współdzielenia kodu, zamiast ograniczania tego procesu. Użytkownik otrzymuje cztery wolności pod jednym warunkiem: każdy, komu przekazuje oprogramowanie, również musi je otrzymać wraz z kodem źródłowym. Stallman nazwał to copyleft. Licencja została po raz pierwszy wydana wraz z GNU Emacs w 1985 roku, stała się GPL w wersji 1 w 1989 roku, a w wersji 2 w czerwcu 1991 roku.

GPL działa, ponieważ opiera się na prawie autorskim, a nie z nim walczy. Bez licencji użytkownik nie ma prawa do rozpowszechniania cudzego kodu. GPL przyznaje to prawo i nakłada na nie warunki. Producent, który dostarcza zmodyfikowany kod na licencji GPL wewnątrz routera i odmawia udostępnienia kodu źródłowego, nie łamie obietnicy. Narusza prawo autorskie, co właściciel praw autorskich może skierować na drogę sądową. Dlatego egzekwowanie licencji jest możliwe – od spraw prowadzonych przez Harald Welte w ramach gpl-violations.org w latach 2000., po pozew Software Freedom Conservancy przeciwko Vizio złożony w 2021 roku, w którym argumentuje się, że osoba kupująca telewizor ma prawo żądać wydania kodu źródłowego.

Linux kończy system

Do 1991 roku projekt GNU posiadał kompilator, bibliotekę C, powłokę oraz większość narzędzi. Brakowało działającego jądra, ponieważ prace nad własnym jądrem GNU, czyli Hurd, trwały znacznie dłużej niż planowano. W sierpniu 1991 roku student z Helsinek opublikował wiadomość w grupie dyskusyjnej comp.os.minix:

Tworzę (darmowy) system operacyjny (tylko hobbystycznie, nie będzie duży ani profesjonalny jak gnu) dla klonów 386(486) AT.

Linux 0.01 pojawił się we wrześniu 1991 roku na licencji napisanej przez samego Linusa Torvaldsa, która zabraniała jego sprzedaży. Na początku 1992 roku zastąpił ją licencją GPLv2, co później określił jako jedną ze swoich najlepszych decyzji. Licencja ta zapewniła bezpieczeństwo wkładu korporacyjnego: firma mogła oddelegować inżynierów do pracy nad jądrem, mając pewność, że konkurencja nie przejmie tych ulepszeń na własność.

Darmowy Unix istniał już w Berkeley. Powodem, dla którego to Linux, a nie BSD (Berkeley Software Distribution), stał się domyślnym darmowym Unixem, jest częściowo proces sądowy. Unix System Laboratories pozwało Berkeley Software Design w 1992 roku, a sprawa toczyła się do początku 1994 roku. Przez te dwa lata systemy BSD wiązały się z ryzykiem prawnym, podczas gdy Linux nie, co przyciągnęło użytkowników. FSF prosi o nazywanie połączonego systemu GNU/Linux, ponieważ Linux jest jądrem, a większość otaczających go narzędzi pochodzi z projektu GNU. Większość osób używa nazwy Linux. Obie nazwy odnoszą się do tego samego zestawu oprogramowania.

1998: rebranding open source i podział, który nigdy się nie zagoił

W styczniu 1998 roku firma Netscape ogłosiła publikację kodu źródłowego swojej przeglądarki. Było to największe przedsiębiorstwo, które zdecydowało się na taki krok, co ujawniło praktyczny problem. Fraza "free software" w języku angielskim jest interpretowana jako "oprogramowanie, które nic nie kosztuje", co zostało dosłownie odebrane przez kadrę zarządzającą. W lutym 1998 roku w Palo Alto zebrała się grupa osób w celu znalezienia lepszego określenia, a Christine Peterson zaproponowała termin "open source". W ciągu kilku tygodni Eric Raymond i Bruce Perens założyli Open Source Initiative (OSI). Organizacja przyjęła Open Source Definition, zaadaptowaną z Debian Free Software Guidelines, które Perens napisał w 1997 roku.

Open Source Definition zawiera dziesięć kryteriów. Dwa z nich rozstrzygają większość współczesnych sporów: kod źródłowy musi być dostępny, a licencja nie może ograniczać tego, kto może korzystać z programu ani do jakich celów może go używać. Licencja zawierająca zapis "nie wolno oferować tego jako usługi komercyjnej" nie przechodzi tego testu, niezależnie od tego, na co pozwala w innych kwestiach. Należy zapamiętać to zdanie. Jest to granica, którą przekraczają dzisiejsze licencje typu source-available.

Podział, który pojawił się w 1998 roku, dotyczy powodów, a nie tego, które licencje są akceptowalne. Stanowisko FSF jest etyczne: użytkownik, który nie może zmienić programu, nie kontroluje własnego komputera. Stanowisko OSI, przedstawione biznesowi w eseju Raymonda "The Cathedral and the Bazaar", jest praktyczne: otwarta współpraca tworzy lepsze oprogramowanie, a firma może na tym skorzystać. Odpowiedź Stallmana, "Why Open Source Misses the Point of Free Software", jest nadal publikowana na gnu.org, a on sam nigdy nie zaakceptował nowszego terminu. Perens, który współtworzył ten ruch, zrezygnował z członkostwa w zarządzie OSI w 1999 roku, twierdząc, że ruch oddalił się od idei wolnego oprogramowania.

Warto precyzyjnie określić, jak niewielka jest praktyczna różnica między tymi podejściami. Lista wolnych licencji FSF oraz lista zatwierdzonych licencji OSI są niemal identyczne i obejmują między innymi GPL, MIT, Apache 2.0 oraz BSD. Autorzy, którzy muszą odwołać się do obu znaczeń jednocześnie, używają skrótów FOSS (free and open source software) lub FLOSS (free/libre and open source software).

Jak firmy nauczyły się dostarczać kod

Debiut giełdowy Red Hat w 1999 roku pokazał, że zyski płyną ze wsparcia i pakowania oprogramowania, a nie ze sprzedaży kopii. W 2001 roku IBM zainwestował miliard dolarów w Linux. W tym samym roku dyrektor generalny Microsoft nazwał Linux „rakiem”, by w 2016 roku firma ta dołączyła do Linux Foundation jako platynowy członek, a w 2018 roku przejęła GitHub za 7,5 miliarda dolarów w akcjach. IBM kupił Red Hat w 2019 roku za 34 miliardy dolarów. Żadne z tych wydarzeń nie wynikało ze zmiany podejścia do licencji. Była to zmiana miejsca, w którym generowane są zyski. Gdy system operacyjny jest kosztem wspólnym, utrzymywanie własnego rozwiązania staje się kosztowne, a każdy dostawca woli konkurować na warstwie znajdującej się powyżej.

Własność korporacyjna działa również w drugą stronę. Gdy Oracle kupił Sun w 2010 roku, przejął MySQL oraz OpenOffice.org, co doprowadziło do odejścia obu społeczności. MariaDB wyrosła z MySQL, a LibreOffice powstał jako fork OpenOffice.org we wrześniu 2010 roku. Fork jest jedynym realnym narzędziem głosowania, jakie posiada społeczność użytkowników, a licencja jest tym, co czyni takie głosowanie możliwym.

Dlaczego niektóre samodzielnie hostowane aplikacje mają teraz forki

Od 2018 roku grupa firm zmieniła warunki licencjonowania oprogramowania, które zostało już wcześniej wydane. Sytuacja za każdym razem wyglądała podobnie. Jedna firma zatrudniała niemal wszystkich programistów, znacznie większy dostawca chmurowy sprzedawał to samo oprogramowanie jako usługę zarządzaną, a mniejsza firma uznała, że powodem braku konkurencyjności jest licencja.

• MongoDB przyjęło licencję Server Side Public License (SSPL) w październiku 2018 roku. SSPL stanowi, że w przypadku oferowania oprogramowania innym jako usługi, należy opublikować kod źródłowy wszystkiego, co jest używane do świadczenia tej usługi. Organizacja OSI nie uznała jej za licencję open source, a MongoDB wycofało ją z procesu weryfikacji w 2019 roku.
• Redis dodał ograniczenia użytkowania do niektórych modułów w latach 2018 i 2019, a następnie w marcu 2024 roku, wraz z wersją 7.4, przeniósł główny serwer na podwójne warunki typu source-available. Kilka dni później pojawił się fork ostatniego wydania na licencji BSD o nazwie Valkey, działający pod egidą Linux Foundation i wspierany między innymi przez Amazon, Google oraz Oracle. W maju 2025 roku Redis dodał licencję Affero General Public License version 3 (AGPLv3), która jest zatwierdzona przez OSI, jako trzecią opcję dla Redis 8.
• Firma Elastic przeniosła Elasticsearch i Kibana z licencji Apache 2.0 w styczniu 2021 roku na podwójne warunki SSPL oraz Elastic License. Amazon stworzył fork o nazwie OpenSearch. Elastic dodało AGPLv3 jako trzecią opcję w sierpniu 2024 roku, a we wrześniu 2024 roku OpenSearch został przeniesiony do Linux Foundation jako OpenSearch Software Foundation.
• HashiCorp przeniósł Terraform oraz inne swoje narzędzia na licencję Business Source License (BUSL) w sierpniu 2023 roku. BUSL nie jest licencją open source w okresie jej obowiązywania, ponieważ zabrania konkurencyjnego wykorzystania komercyjnego. Każde wydanie po upływie określonego czasu, w przypadku Terraform po czterech latach, zmienia licencję na otwartą. W ciągu kilku tygodni powstał fork OpenTofu, który obecnie również znajduje się pod opieką Linux Foundation.

Obie strony mają uzasadnione argumenty i żadna z nich nie działa w złej wierze. Firma opłacająca pięćdziesięciu pracowników, podczas gdy znacznie większy podmiot odsprzedaje jej pracę, ma problem, którego nie rozwiąże dobra wola. Użytkownik, który oparł swoje rozwiązania na warunkach Apache 2.0 i obudził się w obliczu nowych zasad, również ma problem, a nikt nie zapytał go o zdanie. Warto zwrócić uwagę na to, co wydarzyło się później w dwóch z tych przypadków. Po tym, jak forki zyskały na znaczeniu, zarówno Elastic, jak i Redis przywróciły silne licencje typu copyleft. Copyleft odpowiedziało na pierwotne zastrzeżenia, ponieważ AGPLv3 wymaga od dostawcy usługi publikacji zmian, które wprowadził w uruchamianym oprogramowaniu. Według stanu na sierpień 2026 roku oba projekty oraz oba forki pozostają aktywne, co jest rezultatem, do którego dopuszczenia zostały zaprojektowane te licencje.

Kto może zmienić licencję

Projekt może zostać objęty nową licencją tylko wtedy, gdy jedna strona posiada prawa autorskie do całości kodu. Firmy uzyskują taką kontrolę na jeden z dwóch sposobów. Przeniesienie praw autorskich (copyright assignment) przekazuje własność każdego wkładu na rzecz firmy. Umowa licencyjna dla współtwórców (CLA) pozostawia własność po stronie autora, ale przyznaje firmie prawa wystarczająco szerokie, aby mogła ona zmienić licencję na jego pracę. Obie formy są zazwyczaj zatwierdzane poprzez kliknięcie linku zamieszczonego przez bota w pierwszym pull request.

Linux nie posiada CLA. Wkłady są przekazywane na warunkach GPLv2 wraz z Developer Certificate of Origin, a prawa autorskie są rozproszone między tysiące osób i firm. Nikt nie może zmienić licencji Linuxa, ponieważ zebranie wszystkich wymaganych podpisów jest niemożliwe. Ta sama ochrona dotyczy każdego projektu z wieloma niezależnymi właścicielami praw autorskich i jest ona skuteczniejsza niż jakakolwiek obietnica, ponieważ wynika bezpośrednio ze stanu własności.

Zatem kluczowym pytaniem dotyczącym oprogramowania, na którym planujesz polegać, nie jest to, czy jest ono obecnie open source. Pytanie brzmi, kto mógłby to zmienić i czy mógłby zrobić to samodzielnie.

Co faktycznie zapewnia fundacja

Fundacja przechowuje zasoby i ustala zasady podejmowania decyzji. Apache Software Foundation, Linux Foundation, działająca w jej ramach Cloud Native Computing Foundation oraz Software Freedom Conservancy realizują to zadanie w różnych wariantach. Fundacja nie jest neutralna z natury. Członkowie opłacają swoje miejsca, a większość osób pracujących w pełnym wymiarze godzin nad dużymi projektami fundacyjnymi jest opłacana przez firmy członkowskie. Uzyskana korzyść jest węższa, ale nadal bardzo wartościowa: znak towarowy i proces wydawniczy (release process) nie należą do jednego dostawcy, więc żadna pojedyncza firma nie może przejąć projektu na własność.

Znak towarowy jest elementem, który często umyka uwadze. Kod jest licencjonowany. Nazwa jest znakiem towarowym, a znak towarowy nie jest objęty licencją na kod. Zawsze można dokonać forka kodu. Zazwyczaj nie można jednak zachować nazwy. Dlatego właśnie forki w tej historii nazywają się Valkey, OpenSearch, OpenTofu oraz Forgejo.

Problem opiekunów projektu

Współczesna infrastruktura opiera się na projektach utrzymywanych przez jedną lub dwie osoby nieotrzymujące za to wynagrodzenia, a awarie uwidaczniają ten stan rzeczy. Błąd Heartbleed w OpenSSL z 2014 roku dotknął bibliotekę obsługującą znaczną część szyfrowanego ruchu w sieci, utrzymywaną przez garstkę osób przy niemal zerowym budżecie. Luka Log4Shell z grudnia 2021 roku zmusiła zespoły reagowania na incydenty na całym świecie do współpracy z niewielką grupą wolontariuszy z projektu Apache Log4j.

Backdoor w XZ Utils wykryty w marcu 2024 roku jest najbardziej wyrazistym przykładem, ponieważ atak wymierzony był w opiekuna, a nie w sam kod. Konto użytkownika przez około dwa lata wnosiło wartościowy wkład do biblioteki kompresji używanej w dystrybucjach Linux. Inne konta wywierały presję na wyczerpanego, jedynego opiekuna, aby przyjął pomoc. Nowy współopiekun umieścił następnie backdoor w archiwach wydania, celując w systemy, w których demon SSH (secure shell) korzysta z biblioteki liblzma. Programista odkrył to podczas analizy przyczyn, dla których logowanie trwało o około pół sekundy dłużej niż oczekiwano. Był to przypadek, co publicznie przyznały wszystkie zaangażowane strony.

Pieniądze zaczęły napływać: GitHub Sponsors od 2019 roku, Open Collective, niemiecki Sovereign Tech Fund od 2022 roku oraz projekt Alpha-Omega w ramach OpenSSF. Środki te trafiają jednak nierównomiernie i zazwyczaj do projektów, które już zyskały rozgłos. Nadchodzą również regulacje. Akt o cyberodporności (Cyber Resilience Act) Unii Europejskiej wszedł w życie w grudniu 2024 roku, a większość jego obowiązków zacznie obowiązywać od grudnia 2027 roku. Wczesne projekty zakładały nałożenie odpowiedzialności producenta na nieopłacanych wolontariuszy, dlatego ostateczny tekst, po długim lobbingu fundacji i dystrybucji, wprowadza łagodniejszą kategorię określaną jako "zarządca oprogramowania open source" (open source software steward).

Co historia oprogramowania open source oznacza dla systemów na Twoim VPS

Każda aplikacja w naszych poradnikach dotyczących self-hostingu jest wynikiem tych decyzji. Nextcloud istnieje dzięki forkowi: w 2016 roku założyciel ownCloud wraz z większością zespołu opuścił projekt i uruchomił go ponownie na licencji AGPLv3; od tego czasu oba produkty rozwijają się równolegle. Ta historia stanowi tło dla alternatyw dla Nextcloud wartych rozważenia oraz alternatyw dla Dropbox do samodzielnego hostowania, które konkurują z oboma tymi rozwiązaniami.

Ten sam schemat dotyczy hostingu Git. Gitea powstała w 2016 roku jako fork Gogs. Pod koniec 2022 roku znaki towarowe i domeny projektu zostały przeniesione na firmę, w grudniu tego samego roku Codeberg stworzył fork Forgejo, a wraz z wersją 9 w 2024 roku Forgejo przeszło z licencji MIT na GPLv3. Oba rozwiązania opisano w opcjach serwerów Git do samodzielnego hostowania, a różnice licencyjne w dużej mierze tłumaczą, dlaczego projekty te wciąż się rozbiegają. Jednocześnie większość wolnego oprogramowania jest rozwijana na GitHubie, zamkniętej platformie należącej do Microsoftu, co stanowi stary spór z istotnymi argumentami po obu stronach: zobacz czym w rzeczywistości jest GitHub.

Zanim powierzysz serwer danemu projektowi, poświęć dziesięć minut na cztery sprawdzenia.

• Przeczytaj plik LICENSE w repozytorium, a nie stronę marketingową. Strony często używają określenia "open source" długo po tym, jak treść pliku przestała to potwierdzać.
• Sprawdź, czy istnieje CLA lub przeniesienie praw autorskich. Jeśli tak, jeden właściciel może zmienić warunki przyszłych wydań.
• Dowiedz się, kto posiada prawa autorskie: jedna firma, wielu współtwórców czy fundacja.
• Policz aktywnych opiekunów projektu. Projekt z jednym opiekunem stanowi ryzyko zarówno dla tej osoby, jak i dla Ciebie.

Nie oznacza to, że należy unikać oprogramowania od jednego dostawcy. Wiele z nich jest doskonałych, a fakt, że są finansowane, często jest powodem, dla którego w ogóle są utrzymywane. Chodzi o świadomość ryzyka. Decydując co warto hostować samodzielnie, uwzględnij licencję w porównaniu obok wymagań dotyczących pamięci RAM.

Część tej historii możesz odczytać na maszynie, z której korzystasz. Każdy pakiet w systemie Debian lub Ubuntu dostarcza własne warunki:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

Pierwsza liczba oznacza, ile zainstalowanych pakietów posiada plik praw autorskich (zazwyczaj kilkaset na małym VPS). Drugie polecenie wyświetla początek pliku dla bash, który wskazuje na GNU General Public License w wersji 3. Brak pliku oznacza, że pakiet nie został zbudowany zgodnie z polityką Debian, co zdarza się rzadko i wymaga dokładniejszego sprawdzenia, zanim obdarzysz go zaufaniem.

FAQ

Jaka jest różnica między wolnym oprogramowaniem a open source?

Obejmują one niemal ten sam zestaw licencji, różniąc się jedynie argumentacją dotyczącą ich znaczenia. "Wolne oprogramowanie" (free software) to starszy termin, wprowadzony przez Free Software Foundation w 1985 roku, którego argumentacja ma podłoże etyczne: użytkownik, który nie może zmienić programu, nie kontroluje swojego komputera. Termin "open source" powstał w lutym 1998 roku, aby ułatwić wyjaśnianie tych samych licencji firmom, a jego argumentacja jest praktyczna. Licencje GPL, MIT, BSD oraz Apache 2.0 znajdują się na obu oficjalnych listach. Autorzy, którzy chcą odnieść się do obu pojęć jednocześnie, używają skrótów FOSS lub FLOSS.

Czy oprogramowanie source-available to to samo co open source?

Nie. Source-available oznacza jedynie możliwość wglądu w kod źródłowy. Open source, zgodnie z definicją Open Source Definition, oznacza również, że licencja nie może ograniczać tego, kto korzysta z oprogramowania ani do jakich celów jest ono wykorzystywane. Licencje SSPL oraz Business Source License ograniczają komercyjne wykorzystanie przez konkurencję, więc żadna z nich nie jest open source w myśl tej definicji, mimo że obie udostępniają kod źródłowy. Jeśli oprogramowanie jest hostowane wyłącznie na własne potrzeby, ograniczenia te mogą nigdy nie mieć zastosowania. W przypadku budowania produktu w oparciu o takie oprogramowanie, należy najpierw dokładnie zapoznać się z treścią licencji.

Czy firma może wycofać licencję open source, której już udzieliła?

Nie w odniesieniu do kodu, który został już wydany. Ta wersja pozostaje na licencji, z którą została udostępniona, co jest powodem, dla którego forki takie jak Valkey czy OpenTofu mogły powstać na bazie ostatniego commita z licencją permisywną. Firma może natomiast wydać przyszłe wersje na nowych warunkach, o ile posiada pełnię praw autorskich do całego projektu poprzez przeniesienie praw lub umowę z kontrybutorami (contributor licence agreement). Projekty z wieloma niezależnymi właścicielami praw autorskich, w tym Linux, nie mogą zostać jednostronnie przelicencjonowane przez nikogo.

Jakiej licencji szukać w oprogramowaniu self-hosted?

W przypadku oprogramowania uruchamianego samodzielnie, którego nie zamierzasz odsprzedawać, każda licencja zatwierdzona przez OSI, taka jak GPL, AGPL, MIT czy Apache 2.0, zapewnia wszystkie niezbędne uprawnienia. Bardziej istotną kwestią jest to, kto posiada prawa autorskie, ponieważ to decyduje o tym, czy warunki mogą w przyszłości ulec zmianie. Projekt zarządzany przez fundację lub wielu niezależnych kontrybutorów nie może zostać przelicencjonowany wbrew woli użytkowników. Projekt jednego dostawcy z umową typu contributor licence agreement może zostać przelicencjonowany. Oba rodzaje mogą być dobrym oprogramowaniem. Tylko jeden z nich może jednak samodzielnie zmienić zasady gry.