Po co firmie otwarty kod i dlaczego licencja ma znaczenie
Motywacje biznesowe: korzyści z otwartego kodu w organizacji
Firmy coraz częściej korzystają z otwartego kodu i same go udostępniają, ale motywacje rzadko są idealistyczne. Najczęściej chodzi o bardzo konkretne cele biznesowe. Dobrze dobrana licencja open source pomaga te cele zrealizować, a źle dobrana – potrafi je skutecznie zablokować.
Po pierwsze, otwarty kod to oszczędność czasu i pieniędzy. Zamiast budować wszystko od zera, zespół IT sięga po gotowe biblioteki, frameworki i narzędzia. Jeżeli jednak zignoruje licencje open source, może się okazać, że korzysta z komponentu, który wymaga ujawnienia własnego kodu lub przekazania części praw. To nie jest tylko problem teoretyczny – w praktyce zdarzają się sytuacje, w których klient korporacyjny odmawia wdrożenia, dopóki dostawca nie oczyści sytuacji licencyjnej.
Po drugie, udostępnianie fragmentów kodu jako open source buduje reputację pracodawcy i marki technologicznej. Kandydaci widzą, że firma „gra w otwartej lidze” i że projekt ma realny wpływ na społeczność. Daje to przewagę rekrutacyjną, szczególnie wśród doświadczonych programistów. Konkretny wybór licencji decyduje jednak o tym, czy inni będą mogli swobodnie korzystać z projektu, czy np. powstałe forki będą musiały zachować otwartość.
Po trzecie, otwarty kod pozwala wpływać na standardy branżowe. Gdy firma publikuje komponent, który staje się de facto standardem, zyskuje wpływ na kierunek jego rozwoju. Licencja decyduje, czy inne podmioty będą mogły wziąć rozwiązanie, zamknąć je i zmonopolizować, czy też modyfikacje muszą wracać do społeczności na podobnych zasadach.
„Kod jest na GitHubie” a „kod jest na licencji X” – zasadnicza różnica
Wiele zespołów traktuje GitHuba jak katalog z „kodem, który można wziąć”. Tymczasem sam fakt, że kod jest publicznie dostępny, nie oznacza, że wolno go dowolnie kopiować, modyfikować i wykorzystywać komercyjnie. Bez wyraźnej licencji obowiązuje pełna ochrona prawa autorskiego, a użytkownik ma tylko te uprawnienia, które jasno wyraził autor (albo wynikałyby z przepisów o dozwolonym użytku – w praktyce bardzo ograniczone w kontekście biznesowym).
Dlatego różnica między „kod jest dostępny na GitHubie” a „kod jest na licencji MIT/Apache/GPL” jest kluczowa. W pierwszym scenariuszu tak naprawdę nie wiadomo, co wolno, a czego nie. W drugim – licencja jest swoistą umową, która reguluje uprawnienia i obowiązki. Firma korzystająca z komponentu bez licencji lub wbrew warunkom licencji może naruszać prawa autorskie, co stanowi realne ryzyko prawne.
Co do zasady trzeba przyjąć, że brak licencji oznacza brak zgody na komercyjne wykorzystanie. Zdarza się, że autor deklaruje coś w README, ale bez formalnej licencji to za mało, szczególnie w większych organizacjach. Z perspektywy działu prawnego czy compliance takie repozytorium jest „czerwonym światłem”.
Brak licencji i niejasne zgody – jak rodzi się problem
Brak licencji to nie tylko teoretyczny spór o interpretację prawa autorskiego. W praktyce przekłada się na konkretne sytuacje problematyczne:
klient dużej firmy pyta o listę użytych komponentów open source i licencje – zespół nie potrafi odpowiedzieć, bo nikt tego nie śledził;
inwestor podczas due diligence wykrywa zależność od biblioteki bez licencji i żąda jej usunięcia albo zastąpienia, co opóźnia transakcję;
pracownik wypuszcza prywatnie bibliotekę, ale używa kodu powstałego w godzinach pracy – powstaje spór o to, kto ma prawa i jaką licencję wolno zastosować.
Brak licencji lub jej niejasność mają jeszcze jeden skutek: trudno egzekwować cokolwiek od użytkowników kodu. Jeśli firma chciałaby, aby modyfikacje były odsyłane z powrotem (efekt copyleft), musi to jasno zapisać w licencji. Bez tego inni po prostu wykorzystają kod i nie będą mieli obowiązku dzielenia się poprawkami.
Licencja a bezpieczeństwo i wymagania klientów
Coraz częściej klienci korporacyjni wprowadzają w umowach obowiązek ujawnienia składników open source i potwierdzenia, że dostawca działa zgodnie z ich licencjami. Pojawiają się zapisy o open source compliance, zobowiązania do przekazywania listy komponentów (np. SBOM – Software Bill of Materials) i zapewnienia, że żadne licencje „wirusowe” nie obejmą kodu klienta.
Licencja wpływa też na politykę bezpieczeństwa. Niektóre organizacje mają wewnętrzne ograniczenia, np. zakaz stosowania GPL w oprogramowaniu dystrybuowanym do klientów, bo boją się ryzyka ujawnienia kodu własnościowego. Inne preferują licencje z klauzulą patentową (Apache 2.0), aby zmniejszyć ryzyko sporów patentowych. W efekcie to, jaką licencję wybierze firma dla własnego projektu, zadecyduje, czy projekt będzie akceptowalny dla dużych klientów.
Źródło: Pexels | Autor: www.kaboompics.com
Podstawowe pojęcia: co to w ogóle znaczy „open source”
Open source, darmowe oprogramowanie i freeware – trzy różne światy
W języku potocznym „darmowe” często wrzuca się do jednego worka: „free software”, „open source”, „freeware”. Dla firmy to niebezpieczne uproszczenie. Podstawowe rozróżnienie wygląda następująco:
Open source – kod jest dostępny, a licencja daje określone prawa do używania, modyfikowania i dalszego rozpowszechniania. Warunki są zwykle zdefiniowane przez znane licencje (MIT, Apache, GPL itp.).
Darmowe oprogramowanie (free software) – w sensie ruchu FSF chodzi o wolność, a nie o cenę. To pojęcie ideowe, ale w praktyce często łączy się z licencjami copyleft (np. GPL).
Freeware – oprogramowanie, które można używać bezpłatnie, ale zwykle bez prawa wglądu w kod, modyfikacji czy komercyjnej dystrybucji.
To, że narzędzie jest „za darmo”, nie oznacza, że jest open source. Z perspektywy firmy to zasadnicza różnica: do projektu open source można co do zasady wchodzić głębiej (modyfikować, integrować, forknąć), podczas gdy freeware zwykle pozwala tylko na użycie zgodnie z regulaminem producenta.
Open Source Definition – skrót najważniejszych kryteriów
Open Source Initiative (OSI) stworzyła Open Source Definition – zbiór kryteriów, które musi spełniać licencja, aby można było mówić o open source. W praktyce dla firmy kluczowe są m.in. następujące elementy:
prawo do używania oprogramowania w dowolnym celu (w tym komercyjnie);
prawo do analizy, modyfikacji i tworzenia utworów zależnych (wgląd w kod źródłowy jest konieczny);
prawo do redystrybucji oryginalnego lub zmodyfikowanego oprogramowania, często z pewnymi warunkami (np. zachowanie informacji o autorach, udostępnienie zmian na tej samej licencji).
Nie każda „darmowa licencja” jest zgodna z Open Source Definition. Zdarzają się umowy, które zakazują komercyjnego użycia lub ograniczają grupę użytkowników (np. tylko do celów edukacyjnych). Dla poważnego wykorzystania biznesowego bezpieczniej jest trzymać się licencji powszechnie rozpoznawanych jako open source w sensie OSI.
Licencja jako umowa – co daje, a czego nie daje
Licencja open source pełni funkcję umowy licencyjnej. Autor (lub podmiot praw do kodu) udziela użytkownikowi określonych uprawnień: może np. kopiować, modyfikować i rozpowszechniać program, o ile spełni konkretne warunki. Jeżeli tych warunków nie spełnia, korzysta bezprawnie, jakby licencji nie było.
Typowe uprawnienia w licencjach open source to:
prawo do uruchamiania oprogramowania na dowolnej liczbie maszyn;
prawo do modyfikowania kodu źródłowego;
prawo do redystrybucji takiego samego lub zmodyfikowanego programu, z zachowaniem warunków licencji.
Jednocześnie licencje open source zwykle zawierają szerokie wyłączenia odpowiedzialności („AS IS”, brak gwarancji) oraz klauzule o braku odpowiedzialności za szkody. Z perspektywy firmy korzystającej z open source oznacza to, że trudno jest dochodzić roszczeń za błędy w zewnętrznym kodzie – stąd znaczenie wewnętrznych procedur bezpieczeństwa i testów.
Prawa autorskie, praca pracownicza i znaczenie dla firm
Aby móc rozsądnie zarządzać licencjami open source w firmie, trzeba rozumieć, kto jest właścicielem praw do kodu. Co do zasady, w polskim prawie autorskim rozróżnia się prawa osobiste (niezbywalne, np. prawo do autorstwa) i prawa majątkowe (zbywalne, decydują o komercyjnym wykorzystaniu).
W kontekście firm kluczowa jest zasada, że utwory pracownicze zazwyczaj przechodzą na pracodawcę, jeżeli powstają w ramach obowiązków służbowych. Oznacza to, że to nie programista zatrudniony na etacie decyduje samodzielnie o licencji dla kodu pisanego w pracy. Taką decyzję powinna podjąć firma jako posiadacz majątkowych praw autorskich.
Ta kwestia zaczyna być istotna, gdy:
pracownik chce „wypuścić” bibliotekę powstałą w pracy na GitHubie pod własnym kontem;
firma chce połączyć kod powstały prywatnie u pracownika z kodem firmowym;
kontrybucje pracowników są wysyłane do zewnętrznych projektów open source (czy robią to prywatnie, czy w imieniu pracodawcy).
Bez jasnych zasad wewnętrznych pojawiają się spory: czy wolno było opublikować dany fragment kodu, kto decyduje o licencji, czy przypadkiem nie „wyniesiono” praw firmy do publicznego repozytorium.
Główne typy licencji: permisywne, copyleft, „wirusowe” – o co w tym chodzi
Licencje permisywne: MIT, BSD, Apache 2.0
Licencje permisywne to te, które dają szeroką swobodę wykorzystania kodu, przy minimalnych obowiązkach. Przykładowe licencje z tej grupy to MIT, BSD (2- i 3-klauzulowe) oraz Apache 2.0. Wspólnym mianownikiem jest to, że firma może:
wykorzystać kod w zamkniętym produkcie;
zmodyfikować go i nie ujawniać zmian (chyba że zdecyduje inaczej biznesowo);
sprzedawać rozwiązanie bez udostępniania kodu źródłowego użytkownikom końcowym.
Obowiązki zwykle sprowadzają się do zachowania informacji o autorach (copyright notice), dołączenia tekstu licencji do dystrybucji oraz pozostawienia zastrzeżenia braku odpowiedzialności. W przypadku Apache 2.0 dochodzi jeszcze kwestia licencji patentowej i zrzeczenia się pewnych roszczeń patentowych przez kontrybutorów.
Z perspektywy działu prawnego licencje permisywne są zwykle najmniej kłopotliwe i najchętniej widziane w środowisku korporacyjnym. Łatwo je „wkomponować” w produkt komercyjny bez ryzyka, że pojawi się obowiązek otwierania kodu samego produktu.
Copyleft: „słabe” i „silne” – mechanizm dziedziczenia warunków
Licencje copyleft (np. GNU GPL, LGPL, MPL) opierają się na idei, że modyfikacje i prace zależne powinny pozostać wolne w podobnym stopniu jak oryginał. Osiąga się to przez warunek, że redystrybucja takiego oprogramowania lub utworów zależnych musi odbywać się na tej samej lub kompatybilnej licencji.
W praktyce wyróżnia się zwykle:
„Silne” copyleft – jak GPL, która obejmuje całe pochodne dzieło, jeżeli uznać je za utwór zależny od kodu GPL (to właśnie rodzi obawy „wirusowości”).
„Słabe” copyleft – jak LGPL, które pozwala łączyć bibliotekę z zamkniętym kodem, pod warunkiem że sama biblioteka i jej modyfikacje pozostaną na LGPL.
Copyleft ograniczone do pliku lub modułu – jak MPL 2.0, która obejmuje zmodyfikowane pliki objęte MPL, ale nie rozciąga się automatycznie na cały projekt.
Dla biznesu kluczowe jest zrozumienie, że copyleft nie zabrania komercyjnego użycia. Zabrania natomiast, co do zasady, „zamknięcia” kodu pochodnego przy jego dystrybucji. Można sprzedawać produkt na GPL, ale trzeba zapewnić dostęp do kodu źródłowego i wolności dalej definiowanych w licencji.
„Wirusowe” działanie licencji – skąd się bierze ten termin
Określenie „licencje wirusowe” jest skrótem myślowym, który bywa mylący. Chodzi o sytuacje, gdy wykorzystanie kodu na GPL w większym projekcie prowadzi do tego, że całość lub większość projektu musi być udostępniona na GPL przy dystrybucji. Nie istnieje jednak automat „zarażania”. Zawsze trzeba przeanalizować:
czy doszło do stworzenia utworu zależnego (np. przez statyczne linkowanie, kopiowanie kodu, głęboką integrację);
Granice „zarażania” – kilka typowych scenariuszy technicznych
Aby ocenić, czy warunki licencji copyleft rozciągają się na resztę projektu, trzeba zderzyć język prawny z konkretami technicznymi. Najczęstsze scenariusze w firmach to:
statyczne linkowanie – biblioteka na GPL jest „wkompilowana” do binarki. W wielu interpretacjach prowadzi to do powstania utworu zależnego, a więc „pociąga” GPL na całość dystrybuowanego programu;
dynamiczne linkowanie – kod aplikacji ładuje bibliotekę w czasie uruchomienia (DLL, .so). Tu stanowiska są mniej jednoznaczne; niektóre projekty przyjmują, że to wciąż utwór zależny, inne – że to odrębne dzieła połączone interfejsem;
komunikacja przez API / sieć – aplikacja łączy się z usługą lub serwerem na GPL przez HTTP, gRPC czy inny protokół. Co do zasady postrzegane jest to raczej jako odrębne utwory współdziałające, a nie utwór zależny;
kopiowanie fragmentów kodu – przeniesienie funkcji lub modułu „na żywca” do własnego repozytorium. To zazwyczaj klasyczny utwór zależny i silne copyleft będzie miało pełne zastosowanie.
Dla zarządów i product ownerów istotne jest, że ocena tych scenariuszy bywa sporna. Softwarowy „refactoring” po kilku latach, gdy nagle odkrywa się bibliotekę GPL głęboko w sercu systemu, potrafi kosztować znacznie więcej niż kilka konsultacji prawnych i uporządkowanie polityk na etapie projektu.
Źródło: Pexels | Autor: Oleg Cervi
Jak przełożyć typ licencji na praktykę biznesową
Mapa ryzyka: od „zielonych” do „czerwonych” licencji
Większość firm, które systemowo podchodzą do otwartego kodu, buduje prostą „mapę ryzyka” licencji. Nie chodzi o formalną klasyfikację OSI, tylko o praktyczny podział pod kątem wpływu na model biznesowy:
„Zielona strefa” – licencje permisywne (MIT, BSD, Apache 2.0), niektóre licencje o słabym copyleft (np. MPL 2.0);
„Żółta strefa” – licencje copyleft o ograniczonym zakresie (LGPL, MPL przy określonych typach integracji), licencje mniej znane, ale zbliżone do popularnych wzorców;
„Czerwona strefa” – silne copyleft (GPL, AGPL), licencje nietypowe lub „samodzielnie napisane” przez autora, a także wszelkie klauzule zakazujące komercyjnego użycia.
Taka mapa nie jest „prawem natury”, tylko decyzją biznesową. W jednej firmie GPL może trafić do „czerwonej strefy” (brak zgody na jej stosowanie w produktach), w innej – będzie akceptowana w konkretnych scenariuszach, np. wyłącznie w narzędziach developerskich używanych wewnętrznie.
Licencje a kanały dystrybucji: SaaS, on‑premise, open core
To, czy kod jest dystrybuowany do klienta, czy tylko działa na serwerach dostawcy, ma fundamentalne znaczenie dla licencji copyleft. Kilka schematów powtarza się szczególnie często:
Model SaaS (usługa w chmurze) – użytkownik łączy się przez przeglądarkę lub API, ale nie dostaje kopii programu. W takim modelu klasyczna GPL najczęściej nie generuje obowiązku udostępnienia kodu użytkownikom, bo nie dochodzi do „rozpowszechniania” programu w sensie praw autorskich. Inaczej wygląda to przy AGPL, która rozszerza obowiązek udostępniania kodu również na dostęp przez sieć.
On‑premise / instalacja u klienta – klient otrzymuje binarkę lub nawet kod źródłowy do wdrożenia u siebie. W tym scenariuszu warunki GPL czy LGPL uruchamiają się znacznie częściej, bo mamy klasyczną dystrybucję oprogramowania.
Open core – część produktu jest open source (zwykle na licencji przyjaznej biznesowi, jak Apache 2.0), a część pozostaje zamknięta, jako płatne moduły. W takim modelu wprowadzenie silnego copyleft do „rdzenia” może mocno skomplikować ofertę komercyjnych rozszerzeń.
Zmiana kanału dystrybucji – np. z rozwiązania instalowanego lokalnie na SaaS – potrafi „wyłączyć” część ryzyk związanych z copyleft, ale jednocześnie otwiera inne pola (np. zgodność z RODO, lokalizacją danych). Zespół prawny i produktowy powinny więc omawiać licencje równolegle z modelem dostarczania rozwiązania.
Wewnętrzne użycie vs. produkt komercyjny
Korzystanie z open source „do środka” firmy to zupełnie inna sytuacja niż włączanie go do produktu sprzedawanego klientom. Zwykle rozróżnia się trzy poziomy:
narzędzia developerskie (kompilatory, IDE, testery) – używane wyłącznie wewnętrznie; nawet silne copyleft nie stanowi tu co do zasady problemu, bo nie ma dystrybucji kodu;
komponenty serwerowe (np. baza danych na GPL, framework webowy) – używane na serwerach firmy, bez dystrybucji do klienta; problem pojawia się dopiero przy udostępnianiu binarek lub obrazów, które je zawierają;
elementy wbudowane w produkt – biblioteki i fragmenty kodu, które “jadą” razem z produktem do klienta (SDK, aplikacje desktopowe, rozwiązania embedded). Tu typ licencji i sposób integracji są krytyczne.
Wielu napięć da się uniknąć prostą zasadą: to, co jest tylko wewnętrznym narzędziem, może być bardziej „ryzykowne” licencyjnie (GPL, AGPL), natomiast wszystko, co trafia do klientów, powinno przechodzić ostrzejsze sito i opierać się głównie na licencjach z „zielonej” i „żółtej” strefy.
Polityka „no GPL” – kiedy ma sens, a kiedy szkodzi
Spora część korporacji przyjmuje na poziomie globalnym prosty zakaz: „nie używamy GPL w produktach”. Z punktu widzenia zarządzania ryzykiem to zrozumiałe – łatwo zapanować nad procesem, nie trzeba analizować każdego przypadku. W praktyce takie podejście:
ułatwia compliance – mniej wyjątków, mniej analiz, prostszy audyt;
ogranicza wybór technologii – część dojrzałych i popularnych rozwiązań (np. niektóre systemy zarządzania treścią czy bazy danych) jest od razu poza zasięgiem;
sprzyja „partyzantce” – deweloperzy, którzy potrzebują konkretnego narzędzia na GPL, czasem instalują je mimo zakazu, licząc, że nikt nie zauważy.
Bardziej elastyczny wariant polega na zróżnicowaniu zasad: np. brak GPL w komponentach dystrybuowanych klientom, ale dopuszczalność GPL w narzędziach buildowych, wewnętrznych skryptach czy rozwiązaniach administratorskich. Warunkiem jest jednak dobra widoczność tych komponentów (np. przez skanery SBOM) i przeszkolenie zespołów.
Źródło: Pexels | Autor: www.kaboompics.com
Najważniejsze licencje w praktyce firmowej – przegląd z komentarzem
MIT – minimum obowiązków, maksimum swobody
Licencja MIT jest jednym z najprostszych i najchętniej stosowanych wzorców. W skrócie mówi: „możesz zrobić prawie wszystko, byle zachować informację o autorze i zastrzeżenie braku odpowiedzialności”. Z punktu widzenia firmy:
kod na MIT można wbudować w produkt zamknięty, bez obowiązku publikowania źródeł;
w dystrybucji trzeba dołączyć tekst licencji i informację o autorach, najczęściej w pliku NOTICE, ABOUT, w dokumentacji lub sekcji „O programie”;
brak jest klauzul patentowych – w projektach, gdzie patenty odgrywają istotną rolę, sięga się raczej po Apache 2.0.
MIT dominuje w świecie frontendowym (JavaScript, biblioteki UI), w mniejszych narzędziach linuksowych oraz w wielu bibliotekach pisanych przez indywidualnych programistów. Z perspektywy compliance sprawia najmniej problemów – kluczowe jest tylko, aby informacje o autorach nie „gubiły się” przy budowaniu pakietów instalacyjnych czy kontenerów.
BSD 2- i 3-klauzulowa – podobnie do MIT, z drobnymi różnicami
Licencje BSD (szczególnie w wersji 2- i 3-klauzulowej) są w praktyce zbliżone do MIT: dają szeroką swobodę wykorzystania kodu w rozwiązaniach zamkniętych. Różnica sprowadza się głównie do brzmienia klauzul i ich liczby. Historycznie bywało tak, że licencja BSD wymagała zamieszczania informacji o autorach także w materiałach reklamowych, ale współczesne wersje tego nie przewidują.
Dla działów prawnych ważne jest, aby w dokumentacji projektowej odnotować konkretny wariant licencji (2- czy 3-klauzulowy) oraz sposób spełnienia obowiązku informacyjnego. Zdarza się, że ten typ licencji jest mieszany w jednym projekcie z MIT i Apache 2.0 – wtedy przyda się spójny sposób prezentacji wszystkich informacji o prawach autorskich.
Apache License 2.0 – permisywna, ale z modułem patentowym
Apache 2.0, choć należy do licencji permisywnych, jest bardziej rozbudowana. Oprócz klasycznych uprawnień licencyjnych zawiera:
udzielenie licencji patentowej przez kontrybutorów na rzecz użytkowników oprogramowania;
klauzulę o wygaśnięciu licencji patentowej w razie wytoczenia sporu patentowego przeciwko kontrybutorowi w związku z danym kodem;
wymóg zachowania informacji o modyfikacjach w niektórych przypadkach, np. przy znaczących zmianach plików.
Ten moduł patentowy jest istotny dla firm działających na rynkach silnie nasyconych patentami (USA, niektóre segmenty telekomunikacji, IoT). Użycie komponentu na Apache 2.0 daje co do zasady większe „bezpieczeństwo patentowe” niż sięganie po kod MIT od nieznanego autora. Z tej przyczyny licencja Apache 2.0 bywa preferowana jako domyślna dla większych projektów firmowych.
GPL v2 i v3 – silne copyleft w dwóch odsłonach
GNU GPL występuje najczęściej w dwóch głównych wersjach: v2 i v3. Dla firmy różnice między nimi nie są tylko teoretyczne:
GPL v2 – starsza, wciąż bardzo szeroko stosowana (jądro Linuxa, wiele starszych projektów); nie zawiera rozbudowanych zabezpieczeń przed tzw. „tivoizacją” (blokowaniem modyfikacji na sprzęcie) czy klauzul DMCA;
GPL v3 – rozszerza i doprecyzowuje poprzednią wersję; zawiera m.in. postanowienia dotyczące zabezpieczeń DRM, obejmuje szersze spektrum sytuacji związanych z obejściem technicznych środków ochrony i licencji patentowych.
W codziennej praktyce firmy częściej koncentrują się na samym fakcie „bycia na GPL” niż na różnicach między wersjami. Jednak przy budowaniu ekosystemu wokół produktu (pluginy, rozszerzenia pisane przez klientów) wybór v2 vs v3 może mieć znaczenie, chociażby przy łączeniu z bibliotekami o innych licencjach. Warto przy tym odróżnić oznaczenia „GPL v2 only” od „GPL v2 or later” – w drugim przypadku autor dopuszcza licencjonowanie również na nowszych wersjach GPL.
LGPL – pomost między światem otwartym a zamkniętym
Licencja GNU LGPL (Lesser General Public License) jest zaprojektowana jako kompromis: chroni wolność samej biblioteki, ale dopuszcza łączenie z zamkniętym kodem. Firma może:
korzystać z biblioteki LGPL w produkcie zamkniętym, zwykle przez dynamiczne linkowanie;
utrzymać kod własnego produktu w modelu proprietarnym, pod warunkiem że użytkownik ma możliwość podmiany wersji biblioteki LGPL (np. w systemach desktopowych, oprogramowaniu embedded);
modyfikować bibliotekę – jednak modyfikacje tej biblioteki podlegają LGPL i co do zasady muszą być udostępniane na tych samych warunkach przy dystrybucji.
Najwięcej trudności powoduje w praktyce właśnie wymóg możliwości wymiany biblioteki. Przy oprogramowaniu instalowanym lokalnie da się to spełnić stosunkowo łatwo, natomiast w złożonych systemach embedded albo w produktach, gdzie producent kontroluje cały łańcuch aktualizacji, wdrożenie tego wymogu wymaga dobrej współpracy zespołów technicznych i prawnych.
MPL 2.0 – copyleft „na poziomie pliku”
Mozilla Public License 2.0 stosuje inny mechanizm niż GPL: obowiązek udostępnienia kodu źródłowego dotyczy zasadniczo zmodyfikowanych plików objętych MPL, a nie całego projektu. W praktyce oznacza to, że:
można łączyć pliki na MPL z kodem o innej licencji (w tym zamkniętej), o ile zachowa się odrębność plików i przestrzega wymogów MPL;
jeżeli plik objęty MPL zostanie zmodyfikowany, jego treść trzeba udostępnić w źródle na MPL przy dystrybucji programu;
nowe pliki, które tylko „korzystają” z API kodu na MPL, nie muszą automatycznie być na MPL.
Dla firm, które chcą z jednej strony zachować pewien poziom ochrony „otwartości” własnego kodu, a z drugiej – nie zamykać sobie drogi do komercyjnych integracji, MPL 2.0 bywa atrakcyjną alternatywą. Jest też częściej akceptowana przez konserwatywne działy prawne niż GPL, właśnie ze względu na bardziej przewidywalny zakres obowiązków.
AGPL – kiedy chmura też „liczy się” jako udostępnianie
GNU AGPL (Affero GPL) jest odmianą GPL, która została stworzona z myślą o usługach sieciowych. Klasyczne GPL koncentruje się na sytuacji, gdy oprogramowanie jest dystrybuowane – np. sprzedawane na nośniku lub udostępniane do pobrania. AGPL rozszerza ten model: zakłada, że gdy użytkownicy korzystają z programu przez sieć (np. jako SaaS), również powinni mieć możliwość otrzymania kodu źródłowego.
Praktyczna konsekwencja jest taka, że:
użycie komponentu AGPL „w środku” usługi SaaS może spowodować obowiązek udostępnienia kodu źródłowego całego programu serwerowego (przynajmniej w zakresie dzieła zależnego);
firmy budujące komercyjne platformy chmurowe bardzo ostrożnie podchodzą do AGPL – często przyjmują politykę całkowitego zakazu tej licencji w systemach produkcyjnych;
projekty na AGPL bywają oferowane także w modelu „dual-licensing”: społecznościowo na AGPL, a dla klientów biznesowych – na licencji komercyjnej, bez wymogów copyleft.
Dla zespołów tworzących rozwiązania webowe kluczowe jest, aby AGPL nie „wślizgnęła się” do zależności transytywnych bez świadomej decyzji. Narzędzia do skanowania licencji (w połączeniu z ręczną weryfikacją) pomagają wychwycić takie sytuacje na etapie builda, a nie dopiero przy negocjacji dużej umowy z klientem.
Licencje „source-available” i modele quasi-open source
Coraz częściej pojawiają się licencje, które z zewnątrz wyglądają jak open source (kod jest publicznie dostępny), ale w sensie prawnym nimi nie są. Dotyczy to w szczególności tzw. licencji „source-available” oraz licencji z dodatkowymi ograniczeniami biznesowymi, np. zakazem świadczenia usług konkurencyjnych (SSPL, różne „commercial use restriction”, „business source license” i podobne.
W praktyce takie licencje:
pozwalają na przeglądanie i często modyfikowanie kodu, ale ograniczają komercyjne użycie, szczególnie w chmurze lub w roli „hosted service”;
nie spełniają kryteriów Open Source Definition, więc nie należy ich traktować jak zwykłej licencji open source (np. MIT czy Apache 2.0);
wprowadzają dodatkowe obowiązki umowne, czasami z mechanizmem „przekształcenia” w licencję bardziej otwartą po kilku latach.
Z perspektywy firmy takie rozwiązania mogą być atrakcyjne jako forma ochrony biznesu przed dużymi dostawcami chmurowymi, ale utrudniają budowanie szerokiej społeczności deweloperów. Działy prawne często klasyfikują je osobno i wymagają każdorazowej oceny pod kątem zgodności z modelami dystrybucji produktu.
Jak wybrać licencję dla własnego firmowego projektu open source
Decyzja o licencji to w istocie decyzja o modelu współpracy z otoczeniem: klientami, partnerami, społecznością. Zamiast zaczynać od „która licencja jest najpopularniejsza”, sensowniej zadać kilka konkretnych pytań biznesowych.
Krok 1: sprecyzuj cel publikacji kodu
Najpierw trzeba uczciwie odpowiedzieć sobie, po co firma w ogóle otwiera dany projekt. W zależności od motywacji inny wybór będzie logiczny. Typowe scenariusze to:
baza pod ekosystem – firma buduje platformę, wokół której mają powstać integracje, pluginy, dodatki autorstwa partnerów i klientów;
standard branżowy – publikacja referencyjnej implementacji protokołu lub formatu, aby ułatwić interoperacyjność i zachęcić konkurentów do przyjęcia tego rozwiązania;
narzędzie pomocnicze – biblioteka, skrypt lub framework, który nie jest „sercem” produktu, ale poprawia jego otoczenie lub reputację firmy;
otwarcie komponentu kluczowego – np. silnika produktu, który nadal będzie monetyzowany innymi kanałami (support, wersja enterprise, hosting).
Dla ekosystemu pluginów często wystarczają licencje permisywne (MIT, Apache 2.0), bo zależy nam na jak najszerszym adopcie. Gdy celem jest utrzymanie otwartości samego silnika, a jednocześnie ochrona przed „zamykanie” go w cudzych produktach, rozsądne są licencje copyleft o umiarkowanej sile (MPL 2.0, czasem LGPL).
Krok 2: określ, jaką kontrolę nad kodem chcesz zachować
Drugie pytanie dotyczy apetytu na kontrolę. Można to uprościć do skali:
minimalna kontrola – komuś wolno wziąć kod, zamknąć go, sprzedawać produkt bez obowiązku udostępniania modyfikacji (MIT, BSD, z zastrzeżeniami Apache 2.0);
kontrola umiarkowana – modyfikacje wybranych plików muszą pozostać otwarte, ale reszta projektu może być zamknięta (MPL 2.0);
kontrola silna – każdy, kto dystrybuuje projekt z modyfikacjami, musi udostępnić pełen kod źródłowy (GPL);
kontrola ekstremalna w chmurze – nawet dostarczanie usługi przez sieć wywołuje obowiązek udostępnienia kodu (AGPL).
W firmach nastawionych na sprzedaż oprogramowania on-premise silne copyleft bywa traktowane jako ryzyko, ale przy modelu „open core” może stanowić element strategii: „trzon” jest na GPL/MPL, natomiast dodatki enterprise – na licencji komercyjnej.
Krok 3: decyzja, czy wchodzisz w obszar patentów
W niektórych sektorach (telekomunikacja, multimedia, IoT, fintech) istotną rolę odgrywają patenty. Jeżeli firma ma aktywne portfolio patentowe lub działa na rynku, gdzie spory patentowe są realne, nie warto pomijać modułu patentowego w licencji.
Opcje są stosunkowo klarowne:
MIT / BSD – brak wyraźnej licencji patentowej; korzystający nie otrzymuje od autorów projektu „tarczy” w zakresie patentów;
Apache 2.0 – udzielenie licencji patentowej przez kontrybutorów i mechanizm jej wygaśnięcia w razie sporu;
MPL 2.0 i GPLv3 – zawierają postanowienia dotyczące patentów, choć ich konstrukcja różni się od Apache 2.0.
Jeżeli produkt opiera się na innowacjach technicznych i firma chce uniknąć sytuacji, w której jeden z kontrybutorów użyje patentu przeciwko społeczności, Apache 2.0 albo GPLv3 są zwykle bezpieczniejszym wyborem niż MIT.
Krok 4: dopasowanie licencji do modelu monetyzacji
Sposób zarabiania na projekcie determinuje, gdzie leży „czuły punkt” licencji. Dwie skrajne sytuacje pokazują to najlepiej.
Jeżeli firma zarabia głównie na sprzedaży licencji on-premise, to:
silny copyleft (GPL/AGPL) może utrudnić oferowanie wersji stricte zamkniętej, chyba że projekt jest od początku zaplanowany jako dual-licensed;
permisywne licencje (MIT, BSD, Apache 2.0) ułatwiają wdrażanie modeli OEM, white-label i różnego rodzaju „białych pudełek”;
licencje pośrednie (MPL, LGPL) pozwalają zachować otwartość wybranych komponentów i jednocześnie sprzedawać moduły komercyjne.
Jeżeli źródłem przychodu jest przede wszystkim hosting / SaaS, sytuacja wygląda odwrotnie:
permisywne licencje ułatwiają konkurentom zbudowanie własnej oferty SaaS opartej na tym samym kodzie;
AGPL lub GPL + doprecyzowany model kontrybucji mogą zniechęcić do prostego „klonowania” usługi przez duże chmury publiczne;
część firm wybiera model mieszany: rdzeń na copyleft (czasem AGPL), a biblioteki klienckie i SDK – na MIT/Apache, aby ułatwić integratorom pracę.
W praktyce rzadko da się w pełni zabezpieczyć przed każdą formą konkurencji. Licencja jest tylko jednym z elementów układanki, obok marki, jakości produktu i ekosystemu.
Krok 5: zderzenie wyboru z polityką licencyjną firmy
Wiele większych organizacji ma własną politykę licencyjną, która ogranicza wachlarz możliwych wyborów. Bywa, że odgórnie narzucono np. tylko trzy „dozwolone” licencje dla nowych projektów: MIT, Apache 2.0 i MPL 2.0. Z perspektywy zespołu projektowego oznacza to, że zamiast teoretycznej analizy całego katalogu licencji, pracuje się na dość małym zbiorze.
Jeśli takiej polityki jeszcze nie ma, warto ją zbudować równolegle z pierwszymi projektami open source. Powinna obejmować m.in.:
listę rekomendowanych licencji z krótkim opisem, kiedy którą stosować;
zasady dual-licensing, o ile firma je dopuszcza (np. AGPL + licencja komercyjna);
procedurę konsultacji z działem prawnym, gdy zespół chce odejść od listy standardowych licencji.
Dobrze skonstruowana polityka licencyjna nie zabija elastyczności, ale eliminuje skrajności i minimalizuje liczbę „eksotycznych” licencji, które utrudniają audyty i transakcje M&A.
Krok 6: wybór modelu kontrybucji – CLA, DCO i prawa autorskie
Sama licencja projektu to tylko część układanki. Drugim elementem jest sposób, w jaki firma „przyjmuje” wkład od zewnętrznych deweloperów. W praktyce stosuje się trzy podstawowe modele:
brak formalnego mechanizmu – akceptacja kontrybucji wyłącznie na zasadach wynikających z licencji (np. MIT);
DCO (Developer Certificate of Origin) – kontrybutor potwierdza w commicie, że ma prawo udzielić licencji do kodu (np. formułka „Signed-off-by”);
CLA (Contributor License Agreement) – odrębna umowa z kontrybutorem, często przenosząca majątkowe prawa autorskie na firmę lub udzielająca szerszej licencji.
CLA daje firmie większą kontrolę nad przyszłym sposobem licencjonowania (np. przejście z GPL na model komercyjny), ale obniża próg wejścia dla kontrybutorów – część społeczności jest niechętna podpisywaniu dodatkowych umów. DCO jest kompromisem: zapewnia minimalne potwierdzenie stanu prawnego wkładu bez rozbudowanej „papierologii”.
W projektach, które mają ambicję przyciągnięcia szerokiej społeczności, często zaczyna się od DCO. CLA bywa stosowane tam, gdzie kluczowe jest zachowanie spójnej własności praw (np. w projektach „open core”, które mają być monetyzowane także komercyjnie).
Krok 7: dostosowanie licencji do istniejących zależności
Nawet najlepiej przemyślana licencja nie zadziała, jeśli będzie niekompatybilna z licencjami komponentów, na których opiera się projekt. Klasyczny przykład to próba wydania projektu na Apache 2.0, podczas gdy wewnątrz znajduje się biblioteka na GPLv3 – w wielu konfiguracjach takie połączenie będzie prawnie problematyczne.
Przed ogłoszeniem licencji dla nowego projektu potrzebna jest rzetelna inwentaryzacja zależności (w tym transytywnych) i ich licencji. W praktyce proces obejmuje:
uruchomienie skanera SBOM i weryfikację jego wyników przez inżyniera;
oznaczenie komponentów o „trudnych” licencjach (GPL, AGPL, egzotyczne licencje własne);
sprawdzenie zgodności planowanej licencji z licencjami tych komponentów – czasem konieczna jest zamiana biblioteki na inną lub wydzielenie funkcjonalności do odrębnego modułu.
Na tym etapie często wychodzi na jaw, że mikroserwis czy wewnętrzna biblioteka, którą zespół chciałby upublicznić, korzysta z narzędzi na licencji nieakceptowalnej w projektach klientowskich. Taka informacja na początku procesu pozwala uniknąć późniejszych korekt licencyjnych w panice.
Przykładowe „szablony” wyboru licencji w typowych sytuacjach
Choć każdy przypadek ma swoją specyfikę, w praktyce często wraca kilka powtarzalnych konfiguracji. Dwa uproszczone przykłady pokazują logikę podejścia krok po kroku.
Przykład 1: biblioteka narzędziowa dla deweloperów zewnętrznych
Cel: maksymalna adopcja, brak planu zarabiania bezpośrednio na bibliotece.
Rynek: aplikacje webowe, brak istotnych patentów.
Oczekiwana kontrola: niewielka – dopuszczalne jest użycie także w produktach zamkniętych.
W takiej konfiguracji zazwyczaj wybiera się MIT lub Apache 2.0. Jeśli firma chce mieć choć minimalne zabezpieczenie patentowe – Apache 2.0 będzie rozsądniejsza. DCO wystarczy jako mechanizm regulujący wkład zewnętrzny.
Przykład 2: serwer aplikacyjny, który ma budować przewagę w segmencie SaaS
Cel: rozwój ekosystemu, ale bez łatwego „sklonowania” usługi przez duże chmury.
Oczekiwana kontrola: silna, szczególnie wobec dużych dostawców infrastruktury.
Najczęściej zadawane pytania (FAQ)
Czy samo udostępnienie kodu na GitHubie oznacza, że jest on „open source”?
Nie. Publiczne repozytorium na GitHubie nie jest równoznaczne z udzieleniem licencji open source. Bez wyraźnie wskazanej licencji obowiązuje pełna ochrona prawa autorskiego, a inni mogą co najwyżej przeglądać kod lub korzystać z niego w bardzo ograniczonym zakresie wynikającym z przepisów.
Jeżeli firma korzysta z kodu bez licencji lub wbrew jej warunkom, co do zasady narusza prawa autorskie. Z perspektywy działu prawnego repozytorium bez licencji to sygnał ostrzegawczy – szczególnie przy komercyjnych wdrożeniach czy audytach due diligence.
Jaką licencję open source wybrać dla firmowego projektu?
Dobór licencji zależy od celu biznesowego. Jeżeli priorytetem jest jak najszersze wykorzystanie (w tym w projektach zamkniętych), firmy często sięgają po licencje permissive, takie jak MIT czy Apache 2.0. Dają one dużą swobodę, wymagając zwykle jedynie zachowania informacji o autorach i zastrzeżeń odpowiedzialności.
Jeżeli celem jest „wymuszenie” zwrotu zmian do społeczności i utrzymanie otwartości forków, rozważa się licencje copyleft, np. GPL. Trzeba jednak liczyć się z tym, że część klientów korporacyjnych unika GPL przy oprogramowaniu dystrybuowanym dalej, z obawy przed koniecznością ujawnienia własnego kodu.
Czym różni się open source od freeware w kontekście firmy?
Open source to przede wszystkim dostęp do kodu źródłowego i jasno określone w licencji prawa do używania, modyfikacji oraz redystrybucji. Zwykle można taki kod włączyć do własnych rozwiązań, pod warunkiem spełnienia warunków licencji (np. zachowania informacji o autorach).
Freeware to oprogramowanie bezpłatne, ale najczęściej bez dostępu do kodu i bez prawa modyfikacji czy dalszej sprzedaży. Z punktu widzenia firmy freeware przypomina klasyczny produkt komercyjny z regulaminem użytkowania, tylko bez opłaty licencyjnej. Nie należy go traktować automatycznie jako „open source”.
Jakie ryzyko niesie używanie komponentów bez licencji w produkcie komercyjnym?
Najczęstsze konsekwencje to konieczność nagłej wymiany komponentu (często tuż przed wdrożeniem u klienta), opóźnienia w projektach oraz problemy przy inwestycjach lub sprzedaży spółki. Podczas audytu inwestorzy i duzi klienci wprost pytają o listę zależności open source i ich licencje.
Brak licencji oznacza brak pewnej zgody na komercyjne użycie. W skrajnym przypadku autor może dochodzić roszczeń z tytułu naruszenia praw autorskich. Nawet jeśli do sporu nie dojdzie, sam fakt nieuporządkowanej sytuacji licencyjnej potrafi zablokować kontrakt lub transakcję.
Czy każda „darmowa” licencja spełnia definicję open source (OSI)?
Nie. Aby licencja była uznana za open source w sensie przyjętym przez Open Source Initiative, musi m.in. pozwalać na użycie w dowolnym celu (również komercyjnym), modyfikację kodu i redystrybucję wersji zmodyfikowanych. Licencje ograniczające użycie np. tylko do celów niekomercyjnych lub edukacyjnych zwykle nie spełniają tych kryteriów.
W praktyce, jeżeli firma planuje szerokie, biznesowe wykorzystanie kodu, bezpieczniej jest trzymać się dobrze rozpoznanych licencji zaakceptowanych przez OSI (MIT, Apache 2.0, GPL, BSD itd.), niż opierać się na „autorskich” zapisach lub ogólnych regulaminach.
Dlaczego klienci korporacyjni pytają o licencje open source i SBOM?
Duże organizacje chcą mieć kontrolę nad ryzykiem prawnym i bezpieczeństwem. Z tego powodu w umowach pojawiają się obowiązki ujawniania użytych komponentów open source (np. w formie SBOM – Software Bill of Materials) oraz zapewnienia, że dostawca przestrzega warunków licencji i nie stosuje komponentów nieakceptowanych przez politykę wewnętrzną (np. określonych wersji GPL).
Jeżeli projekt ma trafić do takiego klienta, wybór licencji dla firmowego kodu i sposób zarządzania zależnościami open source bezpośrednio wpływają na to, czy rozwiązanie przejdzie audyt compliance i zostanie w ogóle dopuszczone do wdrożenia.
Czy firma może „wymusić” zwrot zmian do swojego projektu open source?
Tak, ale tylko wtedy, gdy wynika to wyraźnie z licencji. Efekt „zwrotu zmian” zapewniają licencje copyleft, które przewidują, że utwory zależne muszą być udostępniane na tych samych zasadach (np. GPL). Jeżeli firma użyje licencji permissive (MIT, BSD), użytkownicy mogą modyfikować kod i utrzymywać go w całości jako rozwiązanie zamknięte.
Bez jednoznacznego zapisu licencyjnego nie ma skutecznego narzędzia, by domagać się od użytkowników odsyłania poprawek czy publikowania zmian. W takiej sytuacji pozostaje wyłącznie „miękka” presja społeczności lub ustalenia kontraktowe w indywidualnych umowach.
