MIT, GPL, Apache — co znaczą dla użytkownika
Trzy licencje, trzy filozofie — i jak wybrać jedną do własnego projektu.
Na tej stronie jest tekst o wybieraniu licencji dla kodu, który sam napisałeś. To jest druga strona tego samego pytania i akurat ta, która dotyczy większej liczby osób: co te trzy słowa znaczą dla Ciebie, kiedy po prostu używasz oprogramowania, prowadzisz firmę i nie zamierzasz napisać ani linijki czegokolwiek.
Krótka odpowiedź, którą resztę tekstu spędzę na doprecyzowywaniu: przy zwykłym użyciu wszystkie trzy dają Ci to samo, a różnice pojawiają się w trzech konkretnych momentach. Wiedza, w których trzech, chroni Cię zarówno przed ludźmi mówiącymi, że licencje nie mają znaczenia, jak i przed tymi, którzy twierdzą, że jedna z nich jest niebezpieczna.
Co gwarantują Ci wszystkie trzy
Uruchamianie oprogramowania w dowolnym celu, także komercyjnym, bez płacenia, bez pytania, bez liczenia użytkowników. Instalowanie go na dowolnej liczbie maszyn. Żadnych negocjacji odnowienia, żadnego audytu zgodności licencyjnej, żadnego odkrycia, że cena się zmieniła.
Ten zestaw jest identyczny w MIT, GPL i Apache, a dla przytłaczającej większości ludzi stanowi całą praktyczną treść licencji. Gabinet dentystyczny używający otwartego edytora dokumentów i otwartego serwera plików ma te same prawa pod każdą z trzech i nigdy nie napotka między nimi różnicy.
Warto się zatrzymać nad tym, jak nietypowe jest to w porównaniu z alternatywą. Licencje komercyjne liczą rzeczy — użytkowników, rdzenie, urządzenia, sesje równoległe — a ktoś ma prawo to sprawdzić. Każda mała firma, z którą pracowałem, ma gdzieś szufladę z licencyjnym niepokojem. Wszystkie trzy te licencje po prostu usuwają tę kategorię problemu i to jest nagłówek, a nie przypisy poniżej.
Moment pierwszy: przekazujesz oprogramowanie komuś innemu
Tu pojawia się różnica i jest to jedyna, która dotyczy sensownej liczby firm.
Pod MIT i Apache możesz włożyć oprogramowanie do produktu, zmienić je, zamknąć i sprzedać. Pod GPL, jeśli rozpowszechniasz produkt zbudowany na kodzie GPL, musisz udostępnić źródło tego dzieła na tych samych warunkach — a obowiązek obejmuje całość powstałego dzieła, nie tylko linijki, które wziąłeś.
Zwróć uwagę, co to uruchamia: rozpowszechnianie. Nie użycie. Firma uruchamiająca zmodyfikowane oprogramowanie na GPL wewnętrznie, na własnych serwerach, dla własnych pracowników, nie jest winna nikomu nic i może zachować każdą zmianę dla siebie. To jest najczęstsze nieporozumienie w tym obszarze i sprawia, że firmy unikają oprogramowania, z którego mogłyby swobodnie korzystać.
Czyli: czy wysyłasz klientom produkt z tym kodem w środku? Jeśli nie — a dla większości firm odpowiedź brzmi nie — to rozróżnienie do Ciebie nie dociera. Jeśli tak, jest to realne pytanie warte godziny z kimś kompetentnym.
Moment drugi: coś idzie nie tak
Wszystkie trzy całkowicie wyłączają gwarancję i robią to wielkimi literami. Żadnej obietnicy, że działa, żadnej odpowiedzialności za szkody, żadnego zapewnienia przydatności do czegokolwiek.
Ludzie reagują na to jak na skandal. To nie jest istotna różnica wobec oprogramowania komercyjnego, gdzie odpowiedzialność jest zwykle ograniczona do tego, co zapłaciłeś — ale znaczy, że jeśli potrzebujesz kogoś kontraktowo odpowiedzialnego, licencja nigdy Ci tego nie da. Kupujesz to osobno, u dostawcy wsparcia, a to, że kod jest darmowy, jest tym, co czyni ten rynek możliwym.
Apache różni się tu jednym praktycznym szczegółem: wprost przyznaje Ci prawa patentowe od współtwórców. MIT nie mówi o patentach nic. W branży regulowanej albo gęstej patentowo warto o tej luce wiedzieć; w zakładzie stolarskim nie.
Moment trzeci: projekt zmienia zdanie
To jest ten, który obchodzi mnie najbardziej jako kogoś wybierającego oprogramowanie dla innych ludzi, i prawie nigdy się o nim nie mówi.
Projekt może zmienić licencję dla przyszłych wersji. Zdarzało się to wielokrotnie znanemu oprogramowaniu: lata otwartego rozwoju, duża baza użytkowników, a potem nowe warunki, które nie są już otwarte. Chroni Cię to, że wersja wydana na starej licencji zostaje na starej licencji, na stałe. Nikt nie może tego odebrać wstecz.
W praktyce znaczy to, że społeczność może niezależnie kontynuować ostatnią otwartą wersję i kilka razy tak zrobiła — a kontynuacja stawała się wersją, z której korzysta większość. Ta możliwość jest faktyczną gwarancją, jaką daje Ci otwarta licencja. Nie to, że projekt zawsze będzie zachowywał się porządnie, tylko to, że jeśli przestanie, nie zostajesz na lodzie.
Co faktycznie sprawdzam, zanim postawię coś na maszynie klienta
Trzy rzeczy, w jakieś pięć minut, i żadna z nich nie dotyczy tego, której z trzech licencji używa.
Czy to faktycznie otwarta licencja, czy jeden z nowszych zestawów warunków ograniczających użycie komercyjne przy jednoczesnym używaniu słowa „otwarty" w marketingu? To rozróżnienie znaczy znacznie więcej niż MIT kontra GPL i to ono zmieniło się najbardziej w ostatnich latach.
Kto nim zarządza — fundacja z wieloma członkami czy pojedyncza spółka z inwestorami? Ta druga może zmienić warunki; pierwszej jest to strukturalnie trudno.
I gdzie mieszkają dane, w jakim formacie i co je czyta. Bo ostatecznie to jest ta rzecz, której licencja naprawdę broni: Twojej możliwości odejścia. Idealna licencja nad oprogramowaniem zamykającym Twoje pliki w formacie, którego nic innego nie czyta, dała Ci wolność, z której nie możesz skorzystać.
Zobacz open source w praktyce.
Na naszym demo działa n8n — ten sam kod, który możesz pobrać i zaudytować — oraz oftionn ai, nasza własna usługa zbudowana na otwartych modelach. Reszta stacku: Nextcloud, Immich, Jellyfin, Stirling PDF i Home Assistant, to ten sam otwarty kod, preinstalowany na sprzęcie, który dostarczamy.