Licence za softver otvorenog koda prema nizozemskom i europskom pravu

Gotovo svaki komercijalni softverski proizvod sadrži komponente otvorenog koda, obično stotine, koje biraju programeri, a ne pravnici. To postaje problem kada nitko ne može reći koje se licence primjenjuju, što zahtijevaju i je li proizvod u skladu s propisima. Ovaj članak objašnjava kako licence otvorenog koda funkcioniraju prema nizozemskom i zakonodavstvu EU, gdje leži rizik i što treba imati na snazi.

Što je licenca otvorenog koda, u pravnom smislu

Licenca otvorenog koda je licenca za autorska prava dodijeljena pod određenim uvjetima. To nije odricanje, nije posveta javnoj domeni, nije odricanje od prava i u tom smislu funkcionira kao i svaka druga softverska licenca prema nizozemskom zakonu . Autor zadržava autorska prava prema čl. 1 Aw i čl. 10 Aw, koji štite računalne programe kao djela, a licenca dopušta radnje koje bi inače kršile isključiva prava prema čl. 12 Aw i čl. 13 Aw.

Posljedica je važnija od definicije. Pridržavajte se pravila i vaše kopiranje i distribucija bit će zakoniti. Ne pridržavajte se pravila i dopuštenje ne pokriva ono što ste učinili: vaša upotreba je kršenje autorskih prava, a ne kršenje ugovora. Većina copyleft licenci to pojačava automatskim prekidom u slučaju kršenja - GPLv2 bez ikakvog razdoblja ispravljanja, dok GPLv3 i AGPLv3 vraćaju prava ako se kršenje ispravi unutar definiranog vremenskog okvira nakon obavijesti.

Nizozemski sudovi primjenjuju ovo obrazloženje. U predmetu Rb. Amsterdam 22. rujna 2020., ECLI:NL:RBAMS:2020:4717, distributer koji je uklonio tekst licence i obavijest o autorskim pravima iz razdvojene baze koda proglašen je gubitkom dopuštenja i kršenjem autorskih prava. Dodavanje velike količine novog koda nije stvorilo neovisno djelo: izvornik je ostao prepoznatljivo prisutan, pa su s njim išle i obveze.

Dvije obitelji: permisivna i copyleft

Dozvolne licence — MIT, BSD licence, Apache 2.0 — dopuštaju korištenje, izmjenu i redistribuciju, uključujući i unutar proizvoda zatvorenog koda, pod uvjetom da sačuvate obavijesti o autorskim pravima i tekst licence.

Copyleft licence zahtijevaju da prilikom distribucije softvera ili nečega izgrađenog na njemu, to činite pod istom licencom i da odgovarajući izvorni kod učinite dostupnim. Razlikuju se po dosegu.

Okidač copylefta i pitanje povezivanja

Obveze autorskog prava odnose se na distribuciju, a ne na korištenje. Tvrtka koja interno koristi GPL softver, ma koliko jako modificiran, ne distribuira ništa i ne duguje ništa. "Jesmo li distribuirali?" uvijek je prvo pitanje i zato su kontejneri, uređaji, firmver i SDK-ovi važniji od internih alata.

Drugo pitanje je teže. GPL govori o „djelu temeljenom na Programu“, posuđujući američki koncept izvedenog djela. Nizozemski zakon nema takav pojam: analiza prolazi kroz prava reprodukcije i prilagodbe, pitajući je li reproduciran zaštićeni izraz iz originala.

Praktični slučaj je povezivanje. Stvara li povezivanje vlasničkog modula s GPL bibliotekom jedno djelo podložno copyleftu nikada nije odlučio nizozemski sud, a ne postoji obvezujuća autoriteta EU. Stav Zaklade za slobodni softver da povezivanje stvara kombinirano djelo je tumačenje upravitelja licence, a ne zakon, a suprotno stajalište je jednako neprovjereno. Omiljeni odgovor interneta - dinamičko povezivanje je sigurno, statičko povezivanje nije - nema osnovu u nizozemskom zakonu o autorskim pravima, koji ne pita kako se kompajler ponaša. Obranjivija analiza pita koliko su komponente intimno kombinirane: dijele li adresni prostor i strukture podataka, isporučuje li se kombinacija kao jedan proizvod, može li funkcionirati samostalno, reproducira li vlasnička strana zaglavlja, makroe ili inline kod s copyleft strane? Ta pitanja obično rješavaju rizik. Ako to ne čine, izolirajte komponentu iza granice procesa, zamijenite je ili uzmite komercijalnu licencu.

AGPL i korištenje mreže

AGPL postoji jer se copyleft aktivira distribucijom, a SaaS pružatelji usluga ne distribuiraju. Njegova mrežna klauzula zahtijeva da ako modificirate softver i učinite ga dostupnim korisnicima koji s njim komuniciraju na daljinu, ponudite im odgovarajući izvorni kod vaše modificirane verzije.

Tri se točke često previđaju. Obveza se odnosi na korisnike usluge, što u proizvodu s otvorenom registracijom nije velika utjeha. Pokreće je modifikacija, tako da je nemodificirana komponenta ne aktivira, ali zakrpana verzija može. I postavlja isto pitanje kombiniranog rada kao i GPL za ostatak vašeg stoga - zbog čega mnoge tvrtke zabranjuju AGPL u produkcijskom kodu.

Kompatibilnost licenci

Kompatibilnost je problem kombiniranja komponenti čije licence nameću obveze koje se ne mogu ispuniti u jednoj distribuciji: permisivne licence kompatibilne su sa gotovo svime, copyleft licence samo s onim što dopuštaju njihovi vlastiti uvjeti. Standardni slučaj je Apache 2.0 i GPLv2. Apache Software Foundation i Free Software Foundation slažu se da kombinacija nije dopuštena jer su odredbe o raskidu patenta i obeštećenju Apachea 2.0 dodatna ograničenja koja GPLv2 ne dopušta. GPLv3 je izrađen kako bi ih prihvatio. Kompatibilnost je također usmjerena: Apache kod može se apsorbirati u GPLv3 projekt, ali ne i obrnuto. Jedna GPL komponenta na pogrešnom mjestu može nametnuti izbor između ponovnog licenciranja, reinženjeringa ili uklanjanja - daleko jeftinije prije objavljivanja nego nakon.

Obveze navođenja i obavještavanja

Najčešće kršene obveze su najmanje dramatične: reprodukcija obavijesti o autorskim pravima, tekstova licenci, odricanja od odgovornosti i, pod Apacheom 2.0, sadržaja NOTICE u materijalima koji prate distribuciju. Svaka obitelj ih nameće, uključujući MIT i BSD. Krše se jer ih nitko ne posjeduje i najlakše ih je popraviti - obično generirana datoteka atribucije koja se isporučuje s proizvodom. Gore navedeni nizozemski slučaj pokazao se upravo na taj neuspjeh.

Dodjela patenata i odmazda za patente

MIT i BSD ne govore ništa o patentima, a pitanje može li se podrazumijevati patentna licenca nije riješeno. Apache 2.0 dodao je izričitu, patentnu licencu bez tantijema od svakog suradnika, uparenu s klauzulom o odmazdi: pokrenite patentni spor u kojem se tvrdi da djelo krši patent i vaša patentna licenca prestaje. GPLv3 sadrži usporedivu dodjelu i vlastite patentne odredbe.

Dvije implikacije za tvrtke s patentnim portfeljima. Ako vaši inženjeri doprinose projektima s Apache ili GPLv3 licencom, dodjeljujete licence pod vlastitim patentima. A ako ikada zatražite patente od tvrtke koja ovisi o istim Apache licenciranim komponentama koje koristite, odmazda vas može koštati licence na koju se oslanjate.

EUPL i nizozemski javni sektor

Javna licenca Europske unije verzija 1.2, koju je Europska komisija odobrila provedbenom odlukom u svibnju 2017., je licenca s autorskim pravom koju je odobrio OSI s tri različite značajke.

• Jezik. Postoji na službenim jezicima EU-a, sve odobrene verzije imaju istu vrijednost, tako da nizozemsko tijelo može sklapati ugovore na nizozemskom jeziku.
• Kompatibilnost. Dodatak navodi kompatibilne licence - među njima GPLv2 i v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL i CeCILL - i dopušta da se izvedeno djelo koje kombinira EUPL kod s kodom pod navedenom licencom distribuira pod tom licencom.
• Doseg. Njegova definicija distribucije obuhvaća dostupnost djela online ili offline ili omogućavanje pristupa njegovim bitnim funkcionalnostima, a članak 5 EUPL-a prenosi obvezu autorskog prava na udaljenu interakciju u kojoj se nudi ista funkcionalnost. Stoga se odnosi na softver isporučen kao usluga, na način na koji to GPL ne čini.

Nizozemski kupac iz javnog sektora može zahtijevati EUPL kao pitanje politike, a ne zakona. Zakon o interoperabilnoj Europi, Uredba (EU) 2024/903, nalaže tijelima javnog sektora da daju prioritet rješenjima interoperabilnosti bez restriktivnih uvjeta licenciranja, kao što je otvoreni kod, gdje je ekvivalentno; na nacionalnoj razini, načelo otvorenog koda, tenzij, počiva na odlukama kabineta i političkim smjernicama, a ne na zakonu: Wet digitale overheid olakšava infrastrukturu digitalnog identiteta, ali ne nameće nikakvu provedivu obvezu objavljivanja cjelokupnog izvornog koda. Pročitajte dokumente za nadmetanje: zahtjev EUPL-a obvezuje vašu isporuku i može biti nekompatibilan s vlasničkim kodom koji ste namjeravali ponovno upotrijebiti.

Provedba u praksi

Tko može tužiti. Nositelj prava - pojedinačni suradnici ili zaklada ili tvrtka koja je vlasnik dodijeljenih autorskih prava. Fragmentirano autorstvo je praktična kočnica: podnositelj zahtjeva mora dokazati vlasništvo nad spornim kodom. Time je pobijen najpoznatiji europski GPL slučaj, gdje je tužba programera kernela protiv dobavljača virtualizacije odbijena zbog nedostatka dokaza o autorstvu (LG Hamburg 8. srpnja 2016., 310 O 89/15; potvrđeno OLG Hamburg 28. veljače 2019., 5 U 146/16).

Što utvrđuje sudska praksa. Njemački sudovi su više puta prihvatili da su licence otvorenog koda valjane i da kršenje čini distribuciju nezakonitom, počevši od prve GPL zabrane (LG München I 19. svibnja 2004., 21 O 6123/04). Američki savezni okružni sud došao je do istog zaključka u predmetu Jacobsen protiv Katzera , 535 F.3d 1373 (Fed. Cir. 2008): uvjeti licence su uvjeti o opsegu dodjele, a ne samo ugovori, pa kršenje podupire zahtjev za autorska prava i zabranu. Američki parnični postupak istražuje može li nizvodni primatelj provoditi GPL kao korisnik treće strane. To je središnje pitanje u predmetu Software Freedom Conservancy protiv Vizia pred Višim sudom Kalifornije: mogu li potrošači, kao korisnici treće strane, zahtijevati objavu izvornog koda pod GPLv2. Dana 23. prosinca 2025. sud je odlučio o jednoj točki sažetog postupka, utvrdivši da GPLv2 i LGPLv2.1 zahtijevaju izvorni kod koji se može nabaviti i preraditi za upotrebu negdje drugdje, a ne izvorni kod koji se može ponovno instalirati na uređaj s netaknutom funkcionalnošću. Samo pitanje korisnika treće strane ostavljeno je za suđenje pred sudom, koje je više puta odgođeno. U svakom slučaju, to je pitanje kalifornijskog ugovornog prava, tako da ne obvezuje na Nizozemsku; ono što bi promijenilo jest broj ljudi koji se mogu žaliti.

Kako bi nizozemski sud pristupio tome. Kao kršenje autorskih prava prema Auteurswetu: tužitelj dokazuje vlasništvo i reprodukciju ili priopćavanje; tuženik se poziva na licencu; tužitelj odgovara da njegovi uvjeti nisu bili ispunjeni, pa obrana ne uspijeva. Ugovorni pravni lijekovi prema čl. 6:265 BW teku paralelno, ali autorsko pravo je jači put.

Pravni lijekovi. Sudska zabrana prema čl. 3:296 BW, obično s plaćanjem novčane kazne i dostupna u skraćenom postupku; odšteta prema čl. 27 Aw i obračun dobiti prema čl. 27a Aw; opoziv, predaja ili uništenje prema čl. 28 Aw; i potpuni povrat razumnih i proporcionalnih sudskih troškova prema čl. 1019h Rv. U slučajevima kada je softver distribuiran besplatno, gubitak je teško kvantificirati, a njemački žalbeni sud odbio je dosuditi odštetu, a potvrdio je sudsku zabranu (OLG Hamm 13. lipnja 2017., 4 U 72/16). Rijetko je šteta ono što grize: to je sudska zabrana, opoziv, nalog o troškovima i objavljivanje izvora koji nikada niste namjeravali objaviti.

Kada otkrijete problem s usklađenošću

Otkriće obično dolazi putem sigurnosnog upitnika kupca, skeniranja tijekom dubinske analize ili pisma nositelja prava. Sanacija se zatim odvija na sljedeći način. Zaustavite distribuciju pogođene verzije ako je izloženost ozbiljna. Utvrdite koja komponenta, koja verzija, koja licenca, koji proizvodi i izdanja, tijekom kojeg razdoblja. Utvrdite što licenca zapravo zahtijeva - često datoteku s atribucijom, a ne izdanje izvornog koda. Pripremite artefakte: obavijesti, tekstove licence, dovršite odgovarajući izvorni kod, uključujući skripte za izradu, i pisanu ponudu gdje je korišten. Pošaljite sukladno izdanje, a zatim obavijestite nositelja prava što ste učinili umjesto da se raspravljate o tome jeste li morali.

Prema GPLv3 i AGPLv3, rok za ispravak daje brzini pravnu vrijednost; prema GPLv2 ne postoji pravo na ispravak, zbog čega većina provedbe završava pregovaranjem o obvezi usklađenosti. Također imajte na umu da se povlastica veže za savjet vašeg odvjetnika, a ne za interno inženjersko izvješće.

Otvoreni kod u spajanjima i preuzimanjima i dubinskoj analizi

Prilikom akvizicije softvera, otvoreni kod je standardni proces analize, a neotkrivena copyleft komponenta u osnovnom proizvodu jedno je od rijetkih otkrića koja doista pokreću posao: ako se proizvod ne može distribuirati bez objavljivanja izvornog koda, kupac stječe drugačiju imovinu od one po kojoj je cijena određena.

Očekujte skeniranje baze koda, popis komponenti s licencama i pitanja o dogovorima između suradnika i izvođača radova. Tipični ishodi su određena odšteta, zadržavanje do sanacije, prethodni uvjet koji zahtijeva uklanjanje ili prilagođeno jamstvo otvorenog koda. Prodavatelji bi prvo trebali skenirati: nalazi koje otkrijete su pregovori, nalazi koje donosi savjetnik kupca su prednost. Kupci ne bi trebali tražiti „tvrtka posjeduje svoje intelektualno vlasništvo“, već izjavu da nijedan proizvod ne uključuje otvoreni kod koji zahtijeva otkrivanje vlasničkog izvornog koda.

Popis materijala, skeniranje i Zakon o kibernetičkoj otpornosti

Popis materijala za softver je popis komponenti proizvoda, s verzijama i licencama. Do nedavno je bio isključivo ugovorni, a sada je i regulatorni.

Zakon o kibernetičkoj otpornosti, Uredba (EU) 2024/2847, stupio je na snagu 10. prosinca 2024. i postupno se uvodi. Nadovezuje se na nizozemski Zakon o kibernetičkoj sigurnosti , koji se odnosi na organizaciju, a ne na proizvod. Obveze izvješćivanja o aktivno iskorištenim ranjivostima i ozbiljnim incidentima u članku 14. Zakona o kibernetičkoj sigurnosti primjenjuju se od 11. rujna 2026.; odredbe o obavještavanju tijela za ocjenjivanje sukladnosti od 11. lipnja 2026.; Uredba u cijelosti od 11. prosinca 2027. (čl. 71. Zakona o kibernetičkoj sigurnosti). Prilog I. Zakona o kibernetičkoj sigurnosti zahtijeva od proizvođača da identificiraju i dokumentiraju komponente u proizvodu, uključujući izradu popisa materijala za softver u uobičajeno korištenom i strojno čitljivom formatu koji pokriva barem najviše ovisnosti. Nije ga potrebno objaviti; tijela za nadzor tržišta mogu ga zatražiti.

Besplatni softver otvorenog koda koji se isporučuje izvan komercijalne aktivnosti ne spada u nadležnost CRA-e. Uredba uvodi upravitelja softvera otvorenog koda - pravnu osobu koja pruža trajnu podršku razvoju softvera otvorenog koda namijenjenog komercijalnim aktivnostima - s lakšim obvezama u članku 24. CRA-e: dokumentirana politika kibernetičke sigurnosti, suradnja s tijelima za nadzor tržišta i izvještavanje. Ako komercijalizirate otvoreni kod ili financirate projekt koji drugi komercijaliziraju, utvrdite koju ulogu imate. Komisija je donijela svoje prve smjernice 27. srpnja 2026.: smjernice Komisije o primjeni Zakona o kibernetičkoj otpornosti (CRA), priložene komunikaciji C(2026) 5252, koje se, između ostalog, bave time kada besplatni softver otvorenog koda spada u područje primjene. Nije donesen provedbeni akt kojim se propisuje format popisa materijala za softver, pa zasad mjera ostaje vlastiti standard Uredbe - uobičajeno korišteni, strojno čitljivi format.

Analiza sastava softvera pokrenuta u CI generira inventar koji istovremeno služi za usklađenost, pregled licence i dubinsku analizu. Takvi alati propuštaju kod dobavljača, pogrešno identificiraju projekte s dvostrukom licencom i ne mogu pročitati uvjete licence: tretiraju izlaz kao početak pregleda, a ne sam pregled.

Ako objavljujete vlastiti kod: CLA-ovi i DCO

Tvrtka koja objavljuje kod i prihvaća vanjske doprinose mora znati da ima prava na ono što spaja. Ugovor o licenci suradnika je ugovor između projekta i suradnika, koji obično daje široku licencu za autorska prava i izričitu patentnu licencu, s jamstvima originalnosti i autoriteta. To je ono što omogućuje tvrtki da kasnije ponovno licencira svoj projekt ili ponudi komercijalne licence uz licence otvorenog koda. Njegov trošak je trenje.

Certifikat o izvornosti razvojnog programera , koji koristi Linux kernel i mnogi drugi projekti, nije licenca, već lagana potvrda, dodana kao potvrda svakom commitu, da suradnik može poslati kod pod licencom projekta. Manje opterećujuće i manje zaštitno: nema patentne licence, nema ponovnog licenciranja.

Ako je dvostruko licenciranje ili buduće korištenje licence moguće, koristite CLA; ako je projekt istinsko zajedničko dobro, DCO je obično dovoljan. U svakom slučaju, provjerite da vaši ugovori o radu i ugovori s izvođačem radova dodjeljuju autorska prava na kod koji vaši ljudi pišu.

Praktična kontrolna lista politika

• Generirajte inventar komponenti po proizvodu i objavite ga u cjevovodu izgradnje, a ne ručno.
• Objavite internu politiku: popis dopuštenih stvari, popis zabranjenih stvari i postupak odobravanja za sve ostalo.
• Pisano definirajte što se smatra distribucijom - lokalne instalacije, uređaji, kontejneri, SDK-ovi, mobilne aplikacije, firmver.
• Uz svaki proizvod pošaljite generiranu datoteku atribucije.
• Odobrite izbore licenci u vrijeme dizajna, kada je komponenta odabrana, a ne prilikom izdavanja.
• Odlučite trebaju li doprinosi vanjskim projektima odobrenje, s obzirom na uključene patentne dodjele, i odaberite CLA ili DCO prije prvog vanjskog doprinosa.
• Uskladite jamstva za intelektualno vlasništvo, odštete i uvjete escrow računa s otvorenim kodom koji se stvarno nalazi u proizvodu.
• Pregledajte prije procesa prikupljanja sredstava ili prodaje, a ne tijekom njega.

Law & More savjetuje softverske tvrtke i njihove investitore od Eindhoven i Amsterdam o usklađenosti s otvorenim kodom, pregledu licenci, dogovorima s suradnicima i toku rada s otvorenim kodom u transakciji.