Licencje oprogramowania typu open source w świetle prawa holenderskiego i unijnego

Prawie każdy komercyjny produkt programowy zawiera komponenty open source, zazwyczaj setki, wybierane przez programistów, a nie prawników. Staje się to problemem, gdy nikt nie jest w stanie określić, które licencje mają zastosowanie, czego wymagają i czy produkt jest zgodny z przepisami. W tym artykule wyjaśniono, jak działają licencje open source w świetle prawa holenderskiego i unijnego, gdzie tkwi ryzyko i co należy wdrożyć.

Czym jest licencja open source w ujęciu prawnym

Licencja open source to licencja praw autorskich udzielana pod pewnymi warunkami. Nie stanowi zrzeczenia się praw, nie jest oddaniem domeny publicznej ani zrzeczeniem się praw i w tym zakresie działa jak każda inna licencja oprogramowania w prawie holenderskim . Autor zachowuje prawa autorskie na mocy art. 1 Aw i art. 10 Aw, które chronią programy komputerowe jako utwory, a licencja zezwala na działania, które w przeciwnym razie naruszałyby prawa wyłączne na mocy art. 12 Aw i art. 13 Aw.

Konsekwencje są ważniejsze niż definicja. Jeśli zastosujesz się do nich, kopiowanie i rozpowszechnianie będzie zgodne z prawem. Jeśli ich nie zastosujesz, pozwolenie nie będzie obejmować tego, co zrobiłeś: Twoje użycie jest naruszeniem praw autorskich, a nie naruszeniem umowy. Większość licencji copyleft wzmacnia tę zasadę, automatycznie wygasając w przypadku naruszenia – GPLv2 bez okresu naprawczego, podczas gdy GPLv3 i AGPLv3 przywracają prawa, jeśli naruszenie zostanie naprawione w określonym czasie po powiadomieniu.

Sądy holenderskie stosują tę argumentację. W sprawie Rb. Amsterdam 22 września 2020 r., ECLI:NL:RBAMS:2020:4717, dystrybutor, który usunął tekst licencji i informację o prawach autorskich z rozwidlonej bazy kodu, został uznany za osobę, która utraciła pozwolenie i dopuściła się naruszenia. Dodanie dużej ilości nowego kodu nie spowodowało powstania niezależnego dzieła: oryginał pozostał rozpoznawalnie obecny, więc obowiązki zostały przeniesione wraz z nim.

Dwie rodziny: permisywna i copyleft

Licencje zezwalające — MIT, licencje BSD, Apache 2.0 — zezwalają na użytkowanie, modyfikację i redystrybucję, także w produktach o zamkniętym kodzie źródłowym, pod warunkiem zachowania informacji o prawach autorskich i tekstu licencji.

Licencje copyleft wymagają, aby rozpowszechniając oprogramowanie lub coś na jego podstawie, robić to na tej samej licencji i udostępniać odpowiednie źródło. Różnią się one zakresem.

Wyzwalacz copyleft i pytanie o linkowanie

Obowiązek copyleft dotyczy dystrybucji, a nie użytkowania. Firma, która wewnętrznie korzysta z oprogramowania na licencji GPL, niezależnie od stopnia jego modyfikacji, nie rozpowszechnia niczego i nie jest do niczego zobowiązana. „Czy dystrybuowaliśmy?” to zawsze pierwsze pytanie i dlatego kontenery, urządzenia, oprogramowanie sprzętowe i zestawy SDK są ważniejsze niż narzędzia wewnętrzne.

Drugie pytanie jest trudniejsze. GPL mówi o „utworze opartym na Programie”, zapożyczając amerykańską koncepcję utworu zależnego. Prawo holenderskie nie posiada takiego terminu: analiza obejmuje prawa do reprodukcji i adaptacji, pytając, czy chroniony wyraz oryginału został zreprodukowany.

Praktycznym przypadkiem jest linkowanie. To, czy linkowanie modułu własnościowego z biblioteką GPL tworzy jeden utwór podlegający copyleft, nigdy nie zostało rozstrzygnięte przez sąd holenderski i nie ma wiążącego orzeczenia UE w tej sprawie. Pogląd Fundacji Wolnego Oprogramowania, że ​​linkowanie tworzy utwór łączony, jest interpretacją administratora licencji, a nie prawem, a przeciwny pogląd jest równie niesprawdzony. Ulubiona odpowiedź internetu – linkowanie dynamiczne jest bezpieczne, linkowanie statyczne nie – nie ma podstaw w holenderskim prawie autorskim, które nie pyta o zachowanie kompilatora. Bardziej uzasadniona analiza pyta, jak ściśle komponenty są połączone: czy współdzielą przestrzeń adresową i struktury danych, czy kombinacja jest dostarczana jako jeden produkt, czy może działać samodzielnie, czy strona własnościowa odtwarza nagłówki, makra lub kod inline z części copyleft? Te pytania zazwyczaj rozwiązują ryzyko. Jeśli tak się nie dzieje, należy odizolować komponent za granicą procesu, zastąpić go lub wykupić licencję komercyjną.

AGPL i korzystanie z sieci

Licencja AGPL istnieje, ponieważ licencja typu copyleft jest aktywowana przez dystrybucję, a dostawcy oprogramowania jako usługi (SaaS) nie dystrybuują. Klauzula sieciowa AGPL wymaga, aby w przypadku modyfikacji oprogramowania i udostępnienia go użytkownikom korzystającym z niego zdalnie, podać im odpowiednie źródło zmodyfikowanej wersji.

Trzy punkty są często pomijane. Obowiązek ten spoczywa na użytkownikach usługi, co w przypadku produktu z otwartą rejestracją nie jest zbyt komfortowe. Zobowiązanie jest aktywowane przez modyfikację, więc niezmodyfikowany komponent nie uruchamia go, ale poprawiona kompilacja może. Rodzi to te same pytania dotyczące łączonej pracy, co GPL dla reszty stosu — dlatego wiele firm zabrania stosowania AGPL w kodzie produkcyjnym.

Zgodność licencji

Zgodność to problem łączenia komponentów, których licencje nakładają obowiązki, których nie da się spełnić w ramach jednej dystrybucji: licencje permisywne są kompatybilne z niemal wszystkim, licencje copyleft tylko z tym, na co pozwalają ich własne warunki. Standardowym przypadkiem są Apache 2.0 i GPLv2. Fundacja Oprogramowania Apache i Fundacja Wolnego Oprogramowania zgadzają się, że takie połączenie jest niedozwolone, ponieważ postanowienia Apache 2.0 dotyczące wygaśnięcia patentu i odszkodowania stanowią dodatkowe ograniczenia, na które GPLv2 nie zezwala. GPLv3 została opracowana z myślą o ich akceptacji. Zgodność ma również charakter kierunkowy: kod Apache można wchłonąć do projektu GPLv3, ale nie odwrotnie. Jeden komponent GPL w niewłaściwym miejscu może wymusić wybór między zmianą licencji, przeprojektowaniem a usunięciem – znacznie tańsze przed wydaniem niż po.

Obowiązki dotyczące atrybucji i powiadamiania

Najczęściej naruszane obowiązki są najmniej drastyczne: powielanie informacji o prawach autorskich, tekstów licencji, zastrzeżeń, a w przypadku Apache 2.0 również treści NOTICE w materiałach dołączonych do dystrybucji. Obowiązują one w każdej rodzinie, w tym w MIT i BSD. Są one łamane, ponieważ nikt nie jest ich właścicielem, a ich naprawa jest najłatwiejsza — zazwyczaj za pomocą wygenerowanego pliku z informacją o autorstwie dołączonego do produktu. Opisany powyżej przypadek holenderski był właśnie wynikiem tego błędu.

Udzielanie patentów i odwet patentowy

MIT i BSD nie wspominają o patentach, a kwestia, czy licencja patentowa może być dorozumiana, pozostaje nierozstrzygnięta. Apache 2.0 wprowadził wyraźną, wolną od opłat licencyjnych licencję patentową dla każdego współautora, wraz z klauzulą ​​odwetową: wniesienie pozwu patentowego w przypadku stwierdzenia naruszenia praw autorskich przez dzieło i wygaśnięcia licencji patentowej. GPLv3 zawiera porównywalną licencję i własne postanowienia patentowe.

Dwie implikacje dla firm z portfelami patentowymi. Jeśli Twoi inżynierowie uczestniczą w projektach objętych licencją Apache lub GPLv3, udzielasz licencji na podstawie własnych patentów. A jeśli kiedykolwiek będziesz dochodzić roszczeń patentowych od firmy, która korzysta z tych samych komponentów z licencją Apache, z których korzystasz, odwet może Cię kosztować utratę licencji, na której polegasz.

EUPL i holenderski sektor publiczny

Licencja Publiczna Unii Europejskiej w wersji 1.2, zatwierdzona przez Komisję Europejską decyzją wykonawczą w maju 2017 r., jest zatwierdzoną przez OSI licencją typu copyleft z trzema wyróżniającymi cechami.

• Język. Dokument jest dostępny w oficjalnych językach UE, a wszystkie zatwierdzone wersje mają identyczną wartość, co oznacza, że ​​holenderski urząd może zawierać umowy w języku niderlandzkim.
• Zgodność. W załączniku wymieniono zgodne licencje — m.in. GPLv2 i v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL i CeCILL — i zezwolono na dystrybucję dzieła pochodnego łączącego kod EUPL z kodem objętym wymienioną licencją na podstawie tej licencji.
• Dosięgnąć. Definicja dystrybucji obejmuje udostępnianie dzieła w trybie online lub offline lub zapewnienie dostępu do jego podstawowych funkcjonalności, a art. 5 EUPL przenosi obowiązek copyleft na zdalną interakcję, w której oferowana jest ta sama funkcjonalność. Obejmuje zatem oprogramowanie dostarczane jako usługa, w sposób nieosiągalny dla GPL.

Holenderski klient z sektora publicznego może wymagać licencji EUPL na mocy polityki, a nie ustawy. Ustawa o Interoperacyjności w Europie, Rozporządzenie (UE) 2024/903, nakazuje organom sektora publicznego priorytetowe traktowanie rozwiązań interoperacyjnych bez restrykcyjnych warunków licencyjnych, takich jak oprogramowanie typu open source, tam gdzie jest ono równoważne; na szczeblu krajowym zasada otwartego oprogramowania (tenzij) opiera się na decyzjach rządu i liniach politycznych, a nie na ustawie: ustawa Wet digitale overheid ułatwia infrastrukturę tożsamości cyfrowej, ale nie nakłada egzekwowalnego obowiązku publikacji całego kodu źródłowego. Przeczytaj dokumentację przetargową: wymóg EUPL wiąże Twój produkt i może być niezgodny z zastrzeżonym kodem, który zamierzasz ponownie wykorzystać.

Egzekwowanie w praktyce

Kto może pozwać? Podmiot praw autorskich — indywidualni współautorzy lub fundacja bądź firma posiadająca przeniesione prawa autorskie. Fragmentaryczne autorstwo stanowi praktyczny hamulec: strona wnosząca roszczenie musi udowodnić własność spornego kodu. To położyło kres najsłynniejszej europejskiej sprawie GPL, w której roszczenie dewelopera jądra przeciwko dostawcy oprogramowania do wirtualizacji zostało oddalone z powodu braku dowodu autorstwa (LG Hamburg, 8 lipca 2016 r., 310 O 89/15; utrzymane w mocy przez OLG Hamburg, 28 lutego 2019 r., 5 U 146/16).

Co ustala orzecznictwo. Niemieckie sądy wielokrotnie uznawały, że licencje open source są ważne, a naruszenie ich powoduje bezprawność dystrybucji, począwszy od pierwszego nakazu sądowego GPL (LG München I 19 maja 2004 r., 21 O 6123/04). Federalny Sąd Apelacyjny USA doszedł do tego samego wniosku w sprawie Jacobsen v Katzer , 535 F.3d 1373 (Fed. Cir. 2008): warunki licencji są warunkami zakresu udzielenia, a nie jedynie zobowiązaniami, więc naruszenie ich uzasadnia roszczenie z tytułu praw autorskich i nakaz sądowy. Postępowanie sądowe w USA bada, czy dalszy odbiorca może egzekwować GPL jako beneficjent zewnętrzny. To jest centralne pytanie w sprawie Software Freedom Conservancy v Vizio przed Sądem Najwyższym Kalifornii: czy konsumenci, jako beneficjenci zewnętrzni, mogą żądać wydania kodu źródłowego na mocy GPL v2. 23 grudnia 2025 r. sąd rozstrzygnął jedną kwestię w postępowaniu uproszczonym, orzekając, że licencje GPLv2 i LGPLv2.1 wymagają kodu źródłowego, który można uzyskać i przerobić do wykorzystania gdzie indziej, a nie kodu źródłowego, który można ponownie zainstalować na urządzeniu z zachowaniem jego funkcjonalności. Kwestia beneficjenta zewnętrznego została pozostawiona do rozstrzygnięcia przez sąd, który był już wielokrotnie odraczany. Jest to w każdym razie kwestia kalifornijskiego prawa umów, więc nie jest wiążąca w Holandii; zmieniłaby ona jedynie liczbę osób uprawnionych do wniesienia skargi.

Jak podszedłby do tego sąd holenderski? W przypadku naruszenia praw autorskich na mocy ustawy o autorach: powód udowadnia prawo własności i prawo do reprodukcji lub rozpowszechniania; pozwany podnosi kwestię licencji; powód odpowiada, że ​​jej warunki nie zostały spełnione, więc obrona jest nieskuteczna. Środki ochrony prawnej na mocy art. 6:265 BW działają równolegle, ale prawo autorskie jest silniejszą drogą.

Środki zaradcze. Nakaz sądowy na podstawie art. 3:296 BW, zazwyczaj z karą pieniężną i dostępny w postępowaniu uproszczonym; odszkodowanie na podstawie art. 27 Aw oraz rozliczenie zysków na podstawie art. 27a Aw; zwrot, wydanie lub zniszczenie na podstawie art. 28 Aw; oraz pełne pokrycie uzasadnionych i proporcjonalnych kosztów sądowych na podstawie art. 1019h Rv. W przypadku bezpłatnej dystrybucji oprogramowania, strata jest trudna do oszacowania, a niemiecki sąd apelacyjny odmówił przyznania odszkodowania, podtrzymując jednocześnie nakaz sądowy (OLG Hamm, 13 czerwca 2017 r., 4 U 72/16). Rzadko dochodzi się odszkodowania: to nakaz sądowy, zwrot, nakaz zapłaty kosztów i konieczność opublikowania źródła, którego nigdy nie zamierzano opublikować.

Kiedy odkryjesz problem ze zgodnością

Odkrycie zazwyczaj następuje w kwestionariuszu bezpieczeństwa klienta, skanowaniu podczas badania due diligence lub w liście od posiadacza praw. Następnie działania naprawcze przebiegają następująco: Wstrzymaj dystrybucję kompilacji, jeśli ryzyko jest poważne. Ustal, który komponent, która wersja, która licencja, które produkty i wydania oraz na jaki okres. Określ, czego faktycznie wymaga licencja — często pliku z informacją o autorstwie, a nie wydania źródła. Przygotuj artefakty: powiadomienia, teksty licencji, kompletne odpowiednie źródła, w tym skrypty kompilacji, oraz pisemną ofertę w przypadku ich wykorzystania. Prześlij zgodne wydanie, a następnie poinformuj posiadacza praw o swoich działaniach, zamiast kłócić się, czy musiałeś je wykonać.

Zgodnie z GPLv3 i AGPLv3, okno naprawcze nadaje prędkość prawnie określoną wartość; zgodnie z GPLv2 nie ma prawa do naprawy, dlatego większość egzekwowania prawa kończy się negocjowanym zobowiązaniem do przestrzegania przepisów. Należy również pamiętać, że przywilej dotyczy porady prawnej, a nie wewnętrznego raportu inżynieryjnego.

Oprogramowanie typu open source w fuzjach i przejęciach oraz due diligence

W przypadku zakupu oprogramowania, oprogramowanie typu open source jest standardowym procesem due diligence, a nieujawniony komponent copyleft w głównym produkcie to jedno z niewielu odkryć, które naprawdę może przyczynić się do sfinalizowania transakcji: jeśli produktu nie można rozpowszechniać bez ujawnienia jego kodu źródłowego, kupujący nabywa inny zasób niż ten, na który był wyceniony.

Należy spodziewać się skanowania bazy kodu, inwentaryzacji komponentów z licencjami oraz pytań dotyczących umów z kontrybutorami i wykonawcami. Typowe rezultaty to konkretne odszkodowanie, nakaz retencji do czasu naprawy, warunek zawieszający wymagający usunięcia lub spersonalizowana gwarancja open source. Sprzedawcy powinni najpierw dokonać skanowania: ujawnione przez Ciebie ustalenia stanowią przedmiot negocjacji, a ustalenia doradcy kupującego stanowią formę nacisku. Kupujący powinni dążyć nie do stwierdzenia, że ​​„firma jest właścicielem swojej własności intelektualnej”, ale do zapewnienia, że ​​żaden produkt nie zawiera kodu open source, który wymagałby ujawnienia zastrzeżonego kodu źródłowego.

Wykaz materiałów, skanowanie i ustawa o odporności cybernetycznej

Wykaz materiałów oprogramowania to spis komponentów produktu, wraz z wersjami i licencjami. Do niedawna miał on charakter czysto umowny, obecnie ma również charakter regulacyjny.

Ustawa o odporności cybernetycznej, rozporządzenie (UE) 2024/2847, weszła w życie 10 grudnia 2024 r. i jest wdrażana etapami. Jest ona zgodna z holenderską ustawą o cyberbezpieczeństwie , która dotyczy organizacji, a nie produktu. Obowiązki sprawozdawcze dotyczące aktywnie wykorzystywanych luk w zabezpieczeniach i poważnych incydentów określone w art. 14 CRA obowiązują od 11 września 2026 r.; przepisy dotyczące notyfikacji jednostek oceniających zgodność od 11 czerwca 2026 r.; pełne rozporządzenie od 11 grudnia 2027 r. (art. 71 CRA). Załącznik I CRA wymaga od producentów identyfikacji i udokumentowania komponentów produktu, w tym poprzez sporządzenie listy materiałów oprogramowania w powszechnie używanym i nadającym się do odczytu maszynowego formacie obejmującym co najmniej zależności najwyższego poziomu. Nie musi ona zostać opublikowana; organy nadzoru rynku mogą jej zażądać.

Wolne i otwarte oprogramowanie dostarczane poza działalnością komercyjną nie podlega przepisom CRA. Rozporządzenie wprowadza zarządcę oprogramowania open source — osobę prawną udzielającą stałego wsparcia rozwojowi oprogramowania open source przeznaczonego do działalności komercyjnej — z łagodniejszymi obowiązkami w art. 24 CRA: udokumentowana polityka cyberbezpieczeństwa, współpraca z organami nadzoru rynku oraz sprawozdawczość. Jeśli komercjalizujesz oprogramowanie open source lub finansujesz projekt, który komercjalizują inni, ustal, jaką rolę pełnisz. Komisja przyjęła swoje pierwsze wytyczne 27 lipca 2026 r.: wytyczne Komisji dotyczące stosowania ustawy o odporności cybernetycznej (CRA), załączone do komunikatu C(2026) 5252, które odnoszą się między innymi do sytuacji, w których wolne i otwarte oprogramowanie wchodzi w zakres rozporządzenia. Nie przyjęto żadnego aktu wykonawczego określającego format zestawienia materiałów oprogramowania, dlatego na razie obowiązującą normą pozostaje własny standard rozporządzenia — powszechnie używany format nadający się do odczytu maszynowego.

Analiza składu oprogramowania przeprowadzana w ramach CI generuje inwentarz, który umożliwia jednoczesne sprawdzanie zgodności, przegląd licencji i due diligence. Takie narzędzia pomijają kod dostawcy, błędnie identyfikują projekty z podwójnym licencjonowaniem i nie potrafią odczytać warunków licencji: traktują wynik jako początek przeglądu, a nie sam przegląd.

Jeśli publikujesz własny kod: CLA i DCO

Firma, która publikuje kod i akceptuje wkład z zewnątrz, musi mieć pewność, że posiada prawa do tego, co scala. Umowa licencyjna dla współautorów to umowa między projektem a współautorem, zazwyczaj udzielająca szerokiej licencji praw autorskich i wyraźnej licencji patentowej, z gwarancjami oryginalności i autorytetu. Pozwala ona firmie na późniejsze ponowne licencjonowanie swojego projektu lub oferowanie licencji komercyjnych obok licencji open source. Jej kosztem jest tarcie.

Certyfikat Pochodzenia Dewelopera , używany przez jądro Linuksa i wiele innych projektów, nie jest przyznaniem licencji, lecz lekkim poświadczeniem, dodawanym jako potwierdzenie każdego zatwierdzenia, że ​​współautor może przesłać kod na licencji projektu. Mniej uciążliwy i mniej zabezpieczający: brak licencji patentowej i możliwości ponownego licencjonowania.

Jeśli możliwe jest podwójne licencjonowanie lub przyszłe ponowne udzielenie licencji, skorzystaj z umowy CLA; jeśli projekt jest rzeczywiście wspólny, umowa DCO zazwyczaj wystarcza. W każdym razie upewnij się, że umowy o pracę i umowy z podwykonawcami obejmują przeniesienie praw autorskich do kodu tworzonego przez Twoich pracowników.

Praktyczna lista kontrolna polityki

• Wygeneruj inwentarz komponentów dla każdego produktu i udostępnij go w procesie kompilacji, a nie ręcznie.
• Opublikuj wewnętrzną politykę: listę rzeczy dozwolonych, listę rzeczy zabronionych i ścieżkę zatwierdzania dla wszystkich pozostałych.
• Określ na piśmie, co uznaje się za dystrybucję — instalacje lokalne, urządzenia, kontenery, zestawy SDK, aplikacje mobilne, oprogramowanie sprzętowe.
• Dołącz wygenerowany plik z informacją o autorstwie do każdego produktu.
• Zatwierdzaj wybory licencji w czasie projektowania, gdy wybierany jest komponent, a nie w momencie wydania.
• Zdecyduj, czy wkład w projekty zewnętrzne wymaga zatwierdzenia, biorąc pod uwagę przyznane patenty, i wybierz CLA lub DCO przed pierwszym wkładem zewnętrznym.
• Dopasuj gwarancje dotyczące własności intelektualnej, odszkodowania i warunki depozytu do kodu źródłowego faktycznie zawartego w produkcie.
• Przeprowadź przegląd przed rozpoczęciem zbiórki funduszy lub sprzedaży, a nie w jej trakcie.

Law & More doradza firmom zajmującym się oprogramowaniem i ich inwestorom Eindhoven oraz Amsterdam na temat zgodności z zasadami otwartego oprogramowania, przeglądu licencji, ustaleń dotyczących współpracowników i strumienia prac nad otwartym oprogramowaniem w ramach transakcji.