Licencje open source dzielą się na trzy rodziny: silne copyleft, słabe copyleft i permisywne. Wybór konkretnej licencji w stosie Twojego produktu decyduje o tym, czy będziesz musiał udostępnić cudzemu odbiorcy kod całej swojej aplikacji. Najpoważniejsze wyzwnia dla software house to skażenie GPL i tzw. luka SaaS, którą zamyka licencja AGPL.

Zasadniczo występują trzy rodziny licencji Open Source (OSS): copyleft (GPL, AGPL), słabe copyleft (LGPL, MPL, EPL), permisywne (MIT, BSD, Apache 2.0).
Skażenie GPL: jeśli „wszyjesz” bibliotekę GPL bezpośrednio w aplikację, musisz udostępnić kod całej aplikacji każdemu, komu ją przekażesz.
Pułapka AGPL: nawet w modelu SaaS, gdy formalnie nie dystrybuujesz programu, masz obowiązek opublikować kod, wystarczy że użytkownik korzysta z funkcjonalności przez sieć.
Licencje permisywne, najbezpieczniejsze, (MIT, BSD, Apache 2.0): wymagają jedynie wskazania autora w dystrybucji produktu.

Scenariusz, który nie jest hipotetyczny

Wyobraź sobie taką sytuację: trzy lata temu Twój zespół dodał do projektu bibliotekę do generowania PDF. Działała, więc nikt nie sprawdzał, na jakiej licencji jest udostępniona. Dziś klient sprzedaje spółkę inwestorowi i ten przed zakupem zleca audyt techniczny oraz audyt prawny umów IT. Audyt znajduje bibliotekę na licencji AGPL „wszytą” w Twoją aplikację. Wycena spada lub kupujący żąda wpierw usunięcia ryzykownych licencji przed nabyciem spółki.

Ten scenariusz nie jest hipotetyczny. Open source compliance to obszar, który w software house najczęściej zawodzi nie z braku wiedzy, ale z braku procesu. Poniżej trzy rodziny licencji OSS, mechanizm skażenia GPL i pułapka AGPL przy modelu SaaS.

Licencja open source – co to jest i czym różni się od freeware

Licencja open source, zgodnie z definicją Open Source Initiative (OSI), to udzielenie odbiorcy prawa dostępu do kodu źródłowego, modyfikacji i redystrybucji oprogramowania. Licencja OSS musi spełniać dziesięć kryteriów obejmujących m.in. swobodną dystrybucję, dostępność kodu źródłowego i brak dyskryminacji odbiorców. To formalna definicja różniąca OSS od innych rozwiązań.

Tytułem przykładu licencja typu Freeware jest darmowa, ale nie pozwala użytkownikowi na dostęp do kodu źródłowego oraz nie daje prawa do modyfikacji. Licencja taka jak Shareware umożliwia korzystanie z programu komputerowego, ale w ograniczonym zakresie, głównie w celu jego przetestowania. Wreszcie, licencja Source-available (np. Business Source License) udostępnia użytkownikowi kod źródłowy, ale wprowadza ograniczenie co do jej komercyjnego wykorzystania.

Jak w takim razie odróżnić OSS od innych rozwiązań? Identyfikacja licencji następuje przez standard SPDX (Software Package Data Exchange), jest to jeden ze sposobów jednoznacznego oznaczenia komponentu. Identyfikator SPDX (np. „MIT”, „GPL-3.0-or-later”, „AGPL-3.0-only”) jest standardem oznaczania licencji w plikach SBOM. Wskazany standard licencyjny znajdziesz na spdx.org/licenses, a oficjalną listę OSI-Approved Licenses na opensource.org/licenses.

W polskim porządku prawnym licencja OSS jest dopuszczalna jako licencja niewyłączna, którą reguluje art. 65 ust. 1 ustawy o prawie autorskim i prawach pokrewnych. Umowy licencyjne OSS, tak samo jak standardowa licencja niewyłączna w prawie polskim, nie wymagają formy pisemnej. Kliknięcie przycisku „I accept” w narzędziu lub samo pobranie biblioteki wystarczy do zawarcia umowy. To, że biblioteka jest dostępna za darmo w menedżerze pakietów, nie oznacza, że jest „bez warunków” – każda licencja OSS nakłada konkretne obowiązki.

Trzy rodziny licencji OSS – copyleft, słabe copyleft, licencje permisywne

Wszystkie licencje OSS dzielą się na trzy rodziny: silne copyleft (GPL, AGPL), słabe copyleft (LGPL, MPL, EPL) i permisywne (MIT, BSD, Apache 2.0). Różnica między nimi sprowadza się do tego, czy i kiedy obowiązek udostępnienia kodu źródłowego „przenosi się” na pozostałe komponenty Twojego produktu, do którego stworzenia wykorzystałeś produkt udostępniony na warunkach licencji OSS.

Czym jest „skażenie” licencją GPL?

To sytuacja, w której dodanie do Twojego projektu jednego komponentu na licencji GPL zmusza Cię do otwarcia kodu całej reszty aplikacji. Według Free Software Foundation – twórców GPL – Twoja aplikacja staje się wtedy tzw. „utworem pochodnym”. W efekcie musisz udostępnić cały swój kod źródłowy każdemu, kto otrzyma Twój program. Wynika to z warunków licencji GPLv3.

Kiedy NIE dochodzi do skażenia?

Twoja aplikacja pozostanie bezpieczna i zamknięta, jeśli łączy się z programem na licencji GPL wyłącznie na odległość. Tytułem przykładu:

Bezpieczne rozwiązanie – Jeśli używasz bazy danych na licencji GPL (np. jako wewnętrznego narzędzia do analityki) i łączysz się z nią przez sieć, wówczas nie tworzysz utworu pochodnego.
Rozwiązanie, które powoduje efekt „wirusa” – jeśli tę samą bazę danych „wszyjesz” bezpośrednio w strukturę swojej aplikacji (jako bibliotekę statyczną), wówczas Twój program zostanie skażony i musisz udostępnić jego kod.

Licencja AGPL a model SaaS, o co w tym chodzi?

Dla firm tworzących oprogramowanie (software house’ów), licencja AGPL v3 bywa nazywana „pułapką”. Aby zrozumieć dlaczego, warto najpierw wyjaśnić, czym jest tzw. luka SaaS (SaaS loophole) w zwykłych licencjach open source.

Na czym polega „luka SaaS” w zwykłej licencji GPL?

Tradycyjna licencja GPL mówi tak: „Jeśli weźmiesz nasz kod, zmienisz go i dasz go komuś innemu (czyli dokonasz dystrybucji), to musisz pokazać i udostępnić kod swoich poprawek”.

Gdzie pojawia się haczyk? W modelu SaaS (czyli gdy aplikacja działa w chmurze, na Twoim serwerze). Użytkownik nie pobiera programu na swój komputer, klika jedynie w przeglądarce lub łączy się przez API. Z punktu widzenia prawa, w modelu SaaS nie dochodzi do zwielokrotniania programu, więc formalnie go nie udostępniasz. Dzięki tej luce prawnej firmy mogły brać darmowy kod GPL, ulepszać go, zarabiać na nim i nikomu nie pokazywać swoich poprawek.

Jak licencja AGPL zamyka tę lukę?

Twórcy licencji AGPL postanowili to naprawić. Dodali zapis, który mówi: „Obowiązek pokazania kodu aktywuje się również wtedy, gdy użytkownik korzysta z programu przez sieć”.

Dla software house’u oznacza to ogromne ryzyko: jeśli w swojej aplikacji działającej w chmurze (SaaS) użyjesz choćby jednej biblioteki na licencji AGPL, masz prawny obowiązek upublicznić kod źródłowy całej swojej aplikacji.

Co zrobić, jeśli Twój produkt komercyjny (SaaS) używa kodu AGPL?

Masz do wyboru trzy rozwiązania:

Pokazać światu cały swój kod – udostępniasz wszystko za darmo na licencji AGPL, co dla większości firm jest nie do zaakceptowania.
Wykupić licencję komercyjną – jeśli właściciel biblioteki daje taką możliwość, płacisz mu za licencję biznesową i wtedy nie musisz otwierać swojego kodu.
Przepisać kod – usuwasz z aplikacji komponent AGPL i zastępujesz go innym, darmowym rozwiązaniem, które ma łagodniejszą licencję (np. MIT lub Apache 2.0), która nie zmusza do ujawniania kodu źródłowego.

Licencje permisywne – MIT, BSD i Apache 2.0 w praktyce

MIT, BSD-3-Clause i Apache 2.0 to trzy najpowszechniejsze licencje permisywne. Pozwalają one na dowolne komercyjne wykorzystanie programu komputerowego, w tym łączenie go z własnym kodem źródłowym. Jedynym warunkiem legalnego wykorzystania jest zachowanie noty autorskiej i pliku licencji w dystrybucji produktu.

Różnice praktyczne między trzema licencjami:

MIT – najprostsza, wymaga jedynie zachowania noty „Copyright (c)”.
BSD-3-Clause – możesz swobodnie korzystać z kodu, ale musisz wskazać oryginalnego autora. Dodatkowo obowiązuje Cię zakaz reklamy: nie możesz używać nazwiska autora ani nazwy jego firmy do promowania swojego produktu bez jego zgody.
Apache 2.0 – możesz swobodnie korzystać z kodu i zawartych w nim patentów, ale musisz wskazać oryginalnego autora.

Praktyczna rekomendacja: jeśli wybierasz biblioteki do produktu komercyjnego, Apache 2.0 daje najszerszą ochronę przy minimalnych obowiązkach. MIT i BSD-3-Clause są w porządku, ale na wrażliwych rynkach jak np. fintech lub medtech bezpieczniejszy wydaje się Apache 2.0.

Sprawdź również: Jak negocjować odpowiedzialność i kary umowne w DPA?

Dual licensing, czyli komercyjne użycie kodu objętego GPL

Dual licensing to model, w którym ten sam kod jest dostępny na dwóch równoległych licencjach, open source (zwykle GPL lub AGPL) i komercyjnej. To pozwala używać go w produkcie bez obowiązków copyleft, w zamian za opłatę licencyjną.

Z prawnego punktu widzenia dual licensing oznacza, że pobranie biblioteki bez wykupu wersji komercyjnej automatycznie zobowiązuje do warunków OSS (GPL/AGPL).

Co realnie grozi za naruszenia licencji Open Source

Naruszenie licencji open source skutkuje w polskim porządku prawnym roszczeniami z art. 79 ust. 1 ustawy o prawie autorskim i prawach pokrewnych. Obejmują one:

zaniechanie naruszania,
naprawienie szkody na zasadach ogólnych lub dwukrotność stosownego wynagrodzenia,
wydanie uzyskanych korzyści.

W Polsce orzecznictwa dotyczącego licencji OSS jest niewiele, ale to nie znaczy, że ryzyko nie istnieje. Praktyka rynku M&A pokazuje, że naruszenie licencji OSS odkryte podczas due diligence może obniżyć wycenę spółki.

Podsumowanie – co dalej dla Twojego software house

Open source compliance w software house zaczyna się od jednej decyzji, a to świadomego wyboru licencji każdego komponentu, zanim trafi on do Twojego produktu. Trzy rodziny licencji (copyleft, słabe copyleft, permisywne) wymagają trzech różnych podejść. Największe ryzyko niesienie pułapka AGPL w modelu SaaS, gdyż jest najczęściej przeoczane, bo zespoły zakładają, że SaaS „omija” obowiązki copyleft. To prawda dla zwykłego GPL, ale nie dla AGPL.

Najprostszy pierwszy krok dla Twojego software house: wygeneruj listę wszystkich bibliotek open source używanych w Twoich projektach i sprawdź, czy któraś ma licencję GPL, AGPL lub inną copyleft.

FAQ – open source compliance w software house

Czy mogę używać biblioteki na licencji GPL w komercyjnym SaaS?

W modelu SaaS na zwykłej licencji GPL (v2 lub v3) co do zasady nie masz obowiązku publikacji kodu, ponieważ udostępniasz tylko funkcjonalność przez sieć. Sytuacja jest odwrotna przy AGPL v3, która zamyka tę lukę. Jeśli używasz biblioteki AGPL w SaaS, masz obowiązek udostępnić kod aplikacji każdemu użytkownikowi korzystającemu z funkcjonalności przez sieć.

Czy AGPL działa, gdy używam biblioteki tylko w backendzie?

Tak, AGPL nie rozróżnia, czy biblioteka działa w warstwie frontendowej, backendowej czy w bazie danych. Obowiązek udostępnienia kodu aktywuje się, gdy użytkownik wchodzi w interakcję z funkcjonalnością opartą na komponencie AGPL przez sieć. Pojedyncze wywołanie biblioteki w backendzie SaaS wystarczy do uruchomienia obowiązków licencji AGPL v3.

Czy MIT i Apache 2.0 są bezpieczne dla produktu komercyjnego?

Co do zasady tak, wskazane licencje pozwalają na komercyjne wykorzystanie i łączenie z własnym kodem źródłowym. Wymagają jednak zachowania noty autorskiej w dystrybucji.

Co to jest dual licensing i kiedy się go stosuje?

Dual licensing oznacza, że ten sam kod udostępniany jest na dwóch równoległych licencjach: open source (najczęściej GPL/AGPL) i jednej komercyjnej. Twoja firma wybiera licencję komercyjną, gdy nie chce lub nie może spełnić obowiązków copyleft, czyli nie chce publikować swojego kodu jako open source.

Czy muszę publikować swój kod, jeśli używam biblioteki GPL?

Tak, jeśli dystrybuujesz oprogramowanie i biblioteka GPL jest częścią Twojego produktu. Nie musisz publikować, jeśli używasz GPL wyłącznie wewnętrznie w firmie, obowiązek aktywuje się np. przy sprzedaży produktu.

Źródła

Open Source Initiative – OSI Approved Licenses: opensource.org/licenses
SPDX License List – identyfikatory SPDX licencji: spdx.org/licenses
Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz.U. 1994 nr 24 poz. 83 z późn. zm.) – art. 65, 79.

Licencje open source

W skrócie najważniejsze fakty