Nyílt forráskódú szoftverlicencek a holland és az uniós jog szerint

Szinte minden kereskedelmi szoftvertermék tartalmaz nyílt forráskódú komponenseket, általában több százat, amelyeket a fejlesztők választanak ki, nem pedig a jogászok. Ez problémává válik, amikor senki sem tudja megmondani, hogy mely licencek vonatkoznak rájuk, mit követelnek meg, és hogy a termék megfelel-e az előírásoknak. Ez a cikk elmagyarázza, hogyan működnek a nyílt forráskódú licencek a holland és az uniós jog szerint, hol rejlik a kockázat, és mit kell betartani.

Mi a nyílt forráskódú licenc jogi szempontból?

A nyílt forráskódú licenc egy feltételekhez kötött szerzői jogi licenc. Nem jelent lemondást, nem a közkincshez való ragaszkodást, nem a jogokról való lemondást, és ebben a tekintetben a holland törvények értelmében bármely más szoftverlicenchez hasonlóan működik . A szerző az 1. Aw. és a 10. Aw. cikk értelmében megtartja a szerzői jogot, amelyek a számítógépi programokat művekként védik, és a licenc olyan cselekményeket tesz lehetővé, amelyek egyébként sértenék a 12. Aw. és a 13. Aw. cikk szerinti kizárólagos jogokat.

A következmény fontosabb, mint maga a definíció. Ha betartod a feltételeket, a másolás és terjesztés jogszerű. Ha nem tartod be a feltételeket, az engedély nem terjed ki arra, amit tettél: a felhasználásod szerzői jogsértés, nem szerződésszegés. A legtöbb copyleft licenc ezt azzal erősíti meg, hogy a jogsértés esetén automatikusan megszűnik – a GPLv2 orvoslási időszak nélkül, míg a GPLv3 és az AGPLv3 visszaállítja a jogokat, ha a jogsértést az értesítést követő meghatározott időn belül orvosolják.

A holland bíróságok ezt az érvelést alkalmazzák. Az Rb. ügyben... Amsterdam A 2020. szeptember 22-i ECLI:NL:RBAMS:2020:4717 számú ítéletben egy forgalmazót, aki eltávolította a licencszöveget és a szerzői jogi közleményt egy elágazott kódbázisból, úgy ítéltek meg, hogy elvesztette az engedélyét, és jogsértő. Nagy mennyiségű új kód hozzáadása nem hozott létre önálló művet: az eredeti felismerhetően jelen maradt, így a kötelezettségek azzal együtt jártak.

A két család: a megengedő és a copyleft

Az engedékeny licencek – MIT, BSD licencek, Apache 2.0 – lehetővé teszik a felhasználást, módosítást és terjesztést, beleértve a zárt forráskódú termékeken belüli felhasználást is, feltéve, hogy megőrzi a szerzői jogi közleményeket és a licencszöveget.

A copyleft licencek előírják, hogy a szoftver vagy az arra épülő valami terjesztésekor ugyanazon licenc alatt kell történnie, és a megfelelő forráskódot kell elérhetővé tennie. Ezek hatókörükben különböznek.

A copyleft-es kiváltó ok és a linkelés kérdése

A szerzői jogi kötelezettségek a terjesztésre, nem pedig a használatra vonatkoznak. Egy GPL-lel védett szoftvert belsőleg futtató vállalat, bármilyen erősen is módosították azt, semmit sem terjeszt, és semmivel sem tartozik. A „Terjesztettük már?” mindig ez az első kérdés, és ezért fontosabbak a konténerek, készülékek, firmware-ek és SDK-k, mint a belső eszközök.

A második kérdés nehezebb. A GPL „a Programon alapuló műről” beszél, átvéve az amerikai származékos mű fogalmát. A holland jogban nincs ilyen kifejezés: az elemzés a sokszorosítási és adaptációs jogokon keresztül vezet végig, azt kérdezve, hogy az eredeti mű védett kifejezési formáját reprodukálták-e.

A gyakorlati eset a linkelés. Azt, hogy egy saját fejlesztésű modul GPL könyvtárhoz való linkelése egyetlen, a szerzői jogvédelem alá eső művet hoz-e létre, még soha nem döntötte el holland bíróság, és nincs erre kötelező érvényű uniós hatóság sem. A Free Software Foundation nézete, miszerint a linkelés kombinált művet hoz létre, a licencgondnok értelmezése, nem pedig a törvény, és az ellentétes nézet ugyanilyen kipróbálatlan. Az internet kedvenc válasza – a dinamikus linkelés biztonságos, a statikus linkelés nem – nem rendelkezik a holland szerzői jogi törvényben való alappal, amely nem kérdezi meg, hogyan viselkedik egy fordítóprogram. Egy védhetőbb elemzés azt kérdezi, hogy a komponensek mennyire szorosan vannak összekapcsolva: megosztanak-e címtartományt és adatszerkezeteket, a kombináció egyetlen termékként kerül-e forgalomba, működhet-e önállóan, a saját fejlesztésű oldal reprodukálja-e a fejléceket, makrókat vagy beágyazott kódot a szerzői jogvédelem alatt álló oldalról? Ezek a kérdések általában megoldják a kockázatot. Ahol nem, ott elkülönítik a komponenst egy folyamathatár mögé, lecserélik, vagy kereskedelmi licencet vesznek fel.

AGPL és hálózathasználat

Az AGPL azért létezik, mert a copyleft a terjesztés által aktiválódik, a SaaS-szolgáltatók pedig nem terjesztik. A hálózati záradéka előírja, hogy ha módosítod a szoftvert, és elérhetővé teszed azt a távolról interakcióba lépő felhasználók számára, akkor fel kell ajánlanod számukra a módosított verzió megfelelő forrását.

Három pontot gyakran figyelmen kívül hagynak. A kötelezettség a szolgáltatás felhasználóira vonatkozik, ami egy nyílt regisztrációs termékben kevés vigaszt nyújt. A kötelezettséget a módosítás váltja ki, így egy módosítatlan komponens nem használja, de egy javított build igen. És ugyanazt a kombinált munka kérdést veti fel, mint a GPL a verem többi részére vonatkozóan – ezért tiltja sok vállalat az AGPL használatát az éles kódban.

Licenc kompatibilitás

A kompatibilitás az olyan komponensek kombinálásának problémája, amelyek licencei olyan kötelezettségeket rónak, amelyek nem teljesíthetők egyetlen disztribúcióban: a megengedő licencek szinte mindennel kompatibilisek, a copyleft licencek csak azzal, amit a saját feltételeik megengednek. A standard eset az Apache 2.0 és a GPLv2. Az Apache Software Foundation és a Free Software Foundation egyetért abban, hogy a kombináció nem megengedett, mivel az Apache 2.0 szabadalmi felmondási és kártalanítási rendelkezései további korlátozások, amelyeket a GPLv2 nem engedélyez. A GPLv3-at úgy tervezték, hogy elfogadja ezeket. A kompatibilitás irányított is: az Apache kód beolvasztható egy GPLv3 projektbe, de fordítva nem. Egyetlen rossz helyen lévő GPL komponens választásra kényszerítheti az újralicencelést, az újratervezést vagy az eltávolítást – sokkal olcsóbb a kiadás előtt, mint utána.

Tulajdonítási és értesítési kötelezettségek

A leggyakrabban megszegett kötelezettségek a legkevésbé drámaiak: a szerzői jogi közlemények, licencszövegek, felelősségkizárások és – Apache 2.0 alatt – a disztribúcióhoz tartozó anyagokban található NOTE tartalmak reprodukálása. Minden család előírja ezeket, beleértve az MIT-t és a BSD-t is. Azért sértik meg őket, mert senki sem birtokolja őket, és a legkönnyebben javíthatók – általában egy, a termékkel együtt szállított generált attribúciós fájllal. A fenti holland eset pontosan ezt a hibát váltotta ki.

Szabadalmak megadása és szabadalmi megtorlás

Az MIT és a BSD semmit sem mond a szabadalmakról, és az sem egyértelmű, hogy lehet-e hallgatólagos szabadalmi licencet biztosítani. Az Apache 2.0 minden közreműködőtől kifejezett, jogdíjmentes szabadalmi licencet adott hozzá, egy megtorlási záradékkal párosítva: szabadalmi pert indíthat, ha a munka jogsértő, és a szabadalmi licence megszűnik. A GPLv3 hasonló engedélyezési és saját szabadalmi rendelkezéseket tartalmaz.

Két következmény van a szabadalmi portfólióval rendelkező vállalatok számára. Ha a mérnökeid Apache vagy GPLv3 licenccel rendelkező projektekhez járulnak hozzá, akkor a saját szabadalmaid alapján adsz licenceket. És ha valaha is szabadalmi igényt érvényesítesz egy olyan vállalattal szemben, amely ugyanazokra az Apache licenccel rendelkező komponensekre támaszkodik, amelyeket te is használsz, a megtorlás miatt elveszítheted a licencedet, amelyre támaszkodsz.

Az EUPL és a holland közszféra

Az Európai Bizottság által 2017 májusában végrehajtási határozattal jóváhagyott Európai Uniós Nyilvános Licenc 1.2-es verziója egy OSI által jóváhagyott copyleft licenc, három megkülönböztető jegygel.

• Nyelv. Az EU hivatalos nyelvein létezik, minden jóváhagyott változat azonos értékű, így egy holland hatóság hollandul is köthet szerződéseket.
• Kompatibilitás. Egy függelék felsorolja a kompatibilis licenceket – többek között a GPLv2 és v3, az AGPLv3, az LGPL, az MPL 2, az EPL 1.0, az OSL és a CeCILL –, és lehetővé teszi, hogy egy EUPL kódot egy listán szereplő licenc hatálya alá tartozó kóddal kombináló származékos művet az adott licenc alapján terjesszenek.
• Elérni. A terjesztés definíciója magában foglalja a mű online vagy offline elérhetővé tételét vagy hozzáférést biztosít annak alapvető funkcióihoz, és az EUPL 5. cikkelye a szerzői jogi kötelezettséget a távoli interakcióra is kiterjeszti, amelyben ugyanazt a funkcionalitást kínálják. Így a szolgáltatásként nyújtott szoftverekre is kiterjed, ahogyan a GPL nem.

Egy holland közszférabeli ügyfélnek inkább szakpolitikai, mint törvényi előírásként kell megkövetelnie az EUPL licencet. Az Interoperable Europe törvény, az (EU) 2024/903 rendelet, előírja a közszférabeli szervek számára, hogy előnyben részesítsék a korlátozó licencfeltételek nélküli interoperabilitási megoldásokat, például a nyílt forráskódot, ahol azzal egyenértékű; országos szinten a nyílt forráskód elve, a tenzij, a kabinet döntésein és szakpolitikai irányvonalakon alapul, nem pedig törvényen: a Wet digitale overheid elősegíti a digitális identitás infrastruktúráját, de nem ír elő végrehajtható kötelezettséget az összes forráskód közzétételére. Olvassa el a pályázati dokumentációt: az EUPL követelménye köti a teljesítendő terméket, és inkompatibilis lehet az újrafelhasználni kívánt zárt kóddal.

Végrehajtás a gyakorlatban

Ki perelhet? A jogtulajdonos – egyéni közreműködők, vagy az átruházott szerzői jogokkal rendelkező alapítvány vagy vállalat. A töredezett szerzőség a gyakorlati fék: a felperesnek bizonyítania kell a vitatott kód tulajdonjogát. Ez meghiúsította a legismertebb európai GPL-ügyet, ahol egy kernelfejlesztő virtualizációs szolgáltatóval szembeni keresete a szerzőség igazolásának hiányában meghiúsult (LG Hamburg, 2016. július 8., 310 O 89/15; helybenhagyta az OLG Hamburg, 2019. február 28., 5 U 146/16).

Amit a joggyakorlat megállapít. A német bíróságok ismételten elfogadták, hogy a nyílt forráskódú licencek érvényesek, és hogy a jogsértés jogellenessé teszi a terjesztést, kezdve az első GPL-tiltó határozattal (LG München I 2004. május 19., 21 O 6123/04). Az Egyesült Államok Szövetségi Körzeti Fellebbviteli Bírósága ugyanerre a következtetésre jutott a Jacobsen kontra Katzer , 535 F.3d 1373 (Fed. Cir. 2008) ügyben: a licencfeltételek a licencadás terjedelmére vonatkozó feltételek, nem puszta kötelezettségvállalások, így a jogsértés alátámasztja a szerzői jogi igényt és a tiltó intézkedést. Az Egyesült Államokbeli peres eljárások azt vizsgálják, hogy egy továbbfelhasználó érvényesítheti-e a GPL-t harmadik fél kedvezményezettjeként. Ez a központi kérdés a Software Freedom Conservancy kontra Vizio ügyben a Kaliforniai Legfelsőbb Bíróság előtt: vajon a fogyasztók, mint harmadik fél kedvezményezettek, követelhetik-e a forráskód kiadását a GPLv2 alapján. 2025. december 23-án a bíróság egy pontban összefoglaló ítéletet hozott, kimondva, hogy a GPLv2 és az LGPLv2.1 olyan forrást igényel, amely beszerezhető és átdolgozható máshol történő felhasználásra, ahelyett, hogy olyan forrást igényelne, amely funkcionalitásának megőrzésével újratelepíthető az eszközön. Magát a harmadik fél kedvezményezettjének kérdését a tárgyalóasztalra hagyták, amelyet többször is elhalasztottak. Ez mindenesetre egy kaliforniai szerződési jogi kérdés, így Hollandiában semmire sem kötelező; amit megváltoztatna, az a panasztevők száma.

Hogyan közelítené meg egy holland bíróság? Szerzői jogsértésként az Auteurswet értelmében: a felperes bizonyítja a tulajdonjogot és a sokszorosítást vagy közvetítést; az alperes a licencre hivatkozik; a felperes azt válaszolja, hogy annak feltételei nem teljesültek, így a védekezés kudarcot vall. A BW 6:265. cikke szerinti szerződéses jogorvoslatok párhuzamosan futnak, de a szerzői jog az erősebb út.

Jogorvoslatok. A BW 3:296 cikke szerinti ideiglenes intézkedés, jellemzően büntetéssel, amely összefoglaló eljárásban vehető igénybe; kártérítés a 27. cikk alapján, valamint nyereségkimutatás a 27a. cikk alapján; visszahívás, átadás vagy megsemmisítés a 28. cikk alapján; és az ésszerű és arányos perköltségek teljes megtérítése a 1019h Rv. cikk alapján. Amennyiben a szoftvert ingyenesen terjesztették, a veszteséget nehéz számszerűsíteni, és egy német fellebbviteli bíróság elutasította a kártérítés megítélését, miközben helybenhagyta az ideiglenes intézkedést (OLG Hamm 2017. június 13., 4 U 72/16). Ami ritkán fáj, az a kár: az az ideiglenes intézkedés, a visszahívás, a költségekre vonatkozó rendelkezés, és egy olyan forrás közzétételének kötelezettsége, amelyet soha nem akart közzétenni.

Amikor megfelelési problémát fedez fel

A felfedezés általában egy ügyfél biztonsági kérdőívéből, egy átvilágítás során végzett vizsgálatból vagy egy jogtulajdonostól kapott levélből származik. A korrekció ezután a következőképpen történik. Állapítsd meg az érintett build terjesztését, ha a kockázat súlyos. Határozd meg, hogy melyik komponens, melyik verzió, melyik licenc, mely termékek és kiadások, milyen időszak alatt vannak. Dolgozd ki, hogy mit ír elő valójában a licenc – gyakran egy attribúciós fájlt a forráskiadás helyett. Készítsd el a szükséges elemeket: értesítéseket, licencszövegeket, a teljes megfelelő forráskódot, beleértve a build szkripteket, és egy írásos ajánlatot, ahol használtál. Küldj egy megfelelő kiadást, majd mondd el a jogtulajdonosnak, mit tettél, ahelyett, hogy azon vitatkoznál, hogy kellett-e.

A GPLv3 és az AGPLv3 licencek értelmében a jogorvoslati időszak gyorsaságot biztosít; a GPLv2 licencek értelmében nincs jogorvoslatra, ezért a legtöbb végrehajtási intézkedés tárgyalásos megfelelési kötelezettségvállalással zárul. Azt is vegye figyelembe, hogy a kiváltság az ügyvéd tanácsához kapcsolódik, nem pedig a belső mérnöki jelentéshez.

Nyílt forráskód az M&A-ban és az átvilágításban

Egy szoftverfelvásárlás során a nyílt forráskódú szoftverek használata egy standard átvilágítási folyamat, és a fő termékben található, nem nyilvános, szerzői jogvédelem alatt álló összetevő egyike azon kevés megállapításnak, amelyek valóban befolyásolják az üzletet: ha a termék nem terjeszthető a forráskód kiadása nélkül, a vevő egy másik eszközt szerez be, mint amelyiket az árban feltüntették.

Számítson rá egy kódbázis-szkennelésre, egy licencekkel ellátott komponensleltárra, valamint a közreműködő és a vállalkozó közötti megállapodásokkal kapcsolatos kérdésekre. Tipikus kimenetelek lehetnek egy konkrét kártérítés, egy visszatartás a korrekcióig, egy eltávolítást előíró előzetes feltétel vagy egy egyedi nyílt forráskódú garancia. Az eladóknak először szkennelniük kell: az Ön által közzétett megállapítások tárgyalás eredménye, a vevő tanácsadója által tett megállapítások pedig előnyt jelentenek. A vevőknek nem azt kell kérniük, hogy „a vállalat birtokolja a szellemi tulajdonát”, hanem azt a kijelentést, hogy egyetlen termék sem tartalmaz nyílt forráskódú szoftvert, amely megköveteli a saját forráskód közzétételét.

Az anyagjegyzék, a szkennelés és a kiberbiztonsági törvény

A szoftver anyagjegyzéke a termék összetevőinek leltárát tartalmazza, verziókkal és licencekkel együtt. A közelmúltig tisztán szerződéses jellegű volt, ma már szabályozási jellegű is.

A kiberbiztonsági ellenálló képességről szóló törvény, az (EU) 2024/2847 rendelet, 2024. december 10-én lépett hatályba, és fokozatosan kerül bevezetésre. A holland kiberbiztonsági törvénnyel párhuzamosan helyezkedik el , amely inkább a szervezetre, mint a termékre vonatkozik. A CRA 14. cikkében foglalt, aktívan kihasznált sebezhetőségekre és súlyos incidensekre vonatkozó jelentéstételi kötelezettségek 2026. szeptember 11-től alkalmazandók; a megfelelőségértékelő szervezetek bejelentésére vonatkozó rendelkezések 2026. június 11-től; a rendelet teljes egészében 2027. december 11-től (CRA 71. cikk). A CRA I. melléklete előírja a gyártók számára, hogy azonosítsák és dokumentálják a termékben található alkatrészeket, többek között egy általánosan használt és géppel olvasható formátumban elkészített szoftveres anyagjegyzék elkészítésével, amely legalább a legfelsőbb szintű függőségeket tartalmazza. Nem kell közzétenni; a piacfelügyeleti hatóságok kérhetik.

A kereskedelmi tevékenységen kívül szállított ingyenes és nyílt forráskódú szoftverek kívül esnek a CRA hatálya alá. A rendelet bevezeti a nyílt forráskódú szoftverek felügyelőjét – egy olyan jogi személyt, amely tartós támogatást nyújt a kereskedelmi tevékenységekre szánt nyílt forráskódú szoftverek fejlesztéséhez –, a CRA 24. cikkében enyhébb kötelezettségekkel: dokumentált kiberbiztonsági politika, együttműködés a piacfelügyeleti hatóságokkal és jelentéstétel. Ha Ön nyílt forráskódú szoftvert értékesít, vagy finanszíroz egy olyan projektet, amelyet mások értékesítenek, határozza meg, hogy milyen szerepet tölt be. A Bizottság 2026. július 27-én fogadta el első iránymutatását: a C(2026) 5252 közleményhez csatolt, a Kiberbiztonsági Törvény (CRA) alkalmazásáról szóló bizottsági iránymutatást, amely többek között azt tárgyalja, hogy mikor tartoznak a szabad és nyílt forráskódú szoftverek a hatály alá. Nem fogadtak el olyan végrehajtási jogi aktust, amely előírná a szoftverek anyagjegyzékének formátumát, így egyelőre a rendelet saját szabványa – egy általánosan használt, géppel olvasható formátum – marad az intézkedés.

A CI-ben futtatott szoftverösszetétel-elemzés egyszerre generálja a megfelelőséget, a licencfelülvizsgálatot és az átvilágítást szolgáló leltárt. Az ilyen eszközök nem veszik figyelembe a gyártói kódot, tévesen azonosítják a kettős licenccel rendelkező projekteket, és nem tudják elolvasni a licencfeltételeket: a kimenetet a felülvizsgálat kezdetének, ne pedig magának a felülvizsgálatnak tekintsék.

Ha saját kódot teszel közzé: CLA-k és a DCO

Egy olyan vállalatnak, amely kódot ad ki és külső közreműködéseket fogad el, tudnia kell, hogy rendelkezik a jogokkal ahhoz, amit egyesít. A közreműködői licencszerződés egy szerződés a projekt és a közreműködő között, amely jellemzően széles körű szerzői jogi licencet és kifejezett szabadalmi licencet biztosít, az eredetiségre és a jogosultságra vonatkozó garanciákkal. Ez teszi lehetővé a vállalat számára, hogy később újralicencelje a projektjét, vagy kereskedelmi licenceket kínáljon a nyílt forráskódú projekt mellett. Ennek költsége a súrlódás.

A Linux kernel és sok más projekt által használt fejlesztői származási tanúsítvány nem licencadás, hanem egy könnyű tanúsítvány, amelyet minden egyes commithoz jóváhagyásként adnak hozzá, hogy a közreműködő a projekt licence alatt beküldhesse a kódot. Kevésbé megterhelő és kevésbé védelmet nyújtó: nincs szabadalmi licenc, nincs újralicencelés.

Ha a kettős licencelés vagy a jövőbeni további licencelés lehetséges, használjon CLA-t; ha a projekt valódi közös tulajdon, akkor a DCO általában elegendő. Akárhogy is, győződjön meg arról, hogy a munkaszerződései és a vállalkozói szerződések kiosztják a szerzői jogokat az általad írt kódra.

Gyakorlati irányelv-ellenőrző lista

• Termékenként komponensleltárt kell generálni, és azokat a build folyamatban kell kiadni, ne kézzel.
• Közzétessz egy belső szabályzatot: egy engedélyezett listát, egy tiltott listát és egy jóváhagyási útvonalat minden másra vonatkozóan.
• Írásban határozd meg, hogy mi számít terjesztésnek – helyszíni telepítések, eszközök, konténerek, SDK-k, mobilalkalmazások, firmware.
• Minden termékhez mellékeljen egy generált attribúciós fájlt.
• A licencválasztásokat a tervezési időszakban, a komponens kiválasztásakor hagyd jóvá, ne a kiadáskor.
• Döntse el, hogy a külső projektekhez való hozzájárulásokhoz szükség van-e jóváhagyásra, figyelembe véve a szóban forgó szabadalmi engedélyeket, és válasszon CLA-t vagy DCO-t az első külső hozzájárulás előtt.
• A szellemi tulajdonra vonatkozó garanciákat, kártalanítási és letéti feltételeket hangolja össze a termékben ténylegesen jelen lévő nyílt forráskódú tartalommal.
• A felülvizsgálatot adománygyűjtési vagy értékesítési folyamat előtt végezze el, ne pedig közben.

Law & More szoftvercégeket és befektetőiket tanácsadja Eindhoven és a Amsterdam a nyílt forráskódú szoftverek megfelelőségéről, a licencfelülvizsgálatról, a közreműködői megállapodásokról és a tranzakcióban részt vevő nyílt forráskódú munkafolyamatról.