Avatud lähtekoodiga tarkvara litsentsid Hollandi ja ELi õiguse alusel

Peaaegu iga kommertstarkvaratoode sisaldab avatud lähtekoodiga komponente, tavaliselt sadu, mille valivad pigem arendajad kui juristid. Sellest saab probleem, kui keegi ei oska öelda, millised litsentsid kehtivad, mida need nõuavad ja kas toode vastab nõuetele. See artikkel selgitab, kuidas avatud lähtekoodiga litsentsid toimivad Hollandi ja ELi õiguse alusel, kus peitub risk ja mida peaks olema.

Mis on avatud lähtekoodiga litsents juriidilises mõttes

Avatud lähtekoodiga litsents on autoriõiguse litsents, mis antakse teatud tingimustel. See ei ole loobumine, avalikku omandisse pühendumine ega õigustest loobumine ning selles osas toimib see nagu iga teine ​​Hollandi seaduste kohaselt tarkvaralitsents . Autorile jäävad autoriõigused vastavalt artiklitele 1 Aw ja 10 Aw, mis kaitsevad arvutiprogramme teostena, ning litsents lubab toiminguid, mis muidu rikuks artiklite 12 Aw ja 13 Aw kohaseid ainuõigusi.

Tagajärg on olulisem kui definitsioon. Nõuete täitmisel on teie kopeerimine ja levitamine seaduslik. Nõuete mittetäitmisel ei kata luba teie tegu: teie kasutus on autoriõiguste rikkumine, mitte lepingu rikkumine. Enamik autoriõiguse litsentse tugevdab seda, lõppedes rikkumise korral automaatselt – GPLv2 ilma parandusperioodita, samas kui GPLv3 ja AGPLv3 taastavad õigused, kui rikkumine kõrvaldatakse kindlaksmääratud aja jooksul pärast etteteatamist.

Hollandi kohtud kohaldavad seda arutluskäiku. Kohtuasjas Rb. Amsterdam 22. septembril 2020 (ECLI:NL:RBAMS:2020:4717) loeti levitaja, kes eemaldas litsentsiteksti ja autoriõiguse märkuse kaheharulisest koodibaasist, oma loa kaotanuks ja rikkus õigusi. Suure hulga uue koodi lisamine ei loonud iseseisvat teost: originaal jäi äratuntavalt alles, seega kaasnesid sellega kohustused.

Kaks perekonda: lubav ja autoriõigusevaba

Lubavad litsentsid – MIT, BSD litsentsid, Apache 2.0 – lubavad kasutamist, muutmist ja levitamist, sealhulgas suletud lähtekoodiga toodetes, tingimusel et säilitate autoriõiguse märkused ja litsentsiteksti.

Autoriõiguse litsentsid nõuavad, et tarkvara või selle põhjal loodud sisu levitamisel teeksite seda sama litsentsi alusel ja teeksite kättesaadavaks vastava lähtekoodi. Need erinevad ulatuse poolest.

Copylefti päästik ja linkimise küsimus

Autoriõiguse kohustused piiravad levitamist, mitte kasutamist. Ettevõte, mis käitab GPL-tarkvara sisemiselt, olenemata selle suurest modifitseerimismahust, ei levita midagi ega ole võlgu. Esimene küsimus on alati „Kas oleme levitanud?“ ja seetõttu on konteinerid, seadmed, püsivara ja SDK-d olulisemad kui sisemised tööriistad.

Teine küsimus on keerulisem. GPL räägib „programmil põhinevast teosest“, laenates Ameerika tuletatud teose kontseptsiooni. Hollandi õiguses sellist terminit ei ole: analüüs hõlmab reprodutseerimis- ja kohandamisõigusi, küsides, kas originaali kaitstud väljendust on reprodutseeritud.

Praktiline juhtum on linkimine. Seda, kas omandiõigusega kaitstud mooduli linkimine GPL-teegiga loob ühe autoriõigusega kaitstud teose, pole Hollandi kohus kunagi otsustanud ja puudub ka siduv ELi pädevus. Vaba Tarkvara Fondi seisukoht, et linkimine loob kombineeritud teose, on litsentsihalduri tõlgendus, mitte seadus, ja vastupidine seisukoht on samamoodi kontrollimata. Interneti lemmikvastus – dünaamiline linkimine on turvaline, staatiline linkimine mitte – ei oma Hollandi autoriõiguse seaduses alust, mis ei küsi, kuidas kompilaator käitub. Kaitstavam analüüs küsib, kui tihedalt on komponendid ühendatud: kas neil on ühine aadressiruum ja andmestruktuurid, kas kombinatsioon tarnitakse ühe tootena, kas see võiks toimida kas eraldi, kas omandiõigusega kaitstud pool reprodutseerib autoriõigusega kaitstud poolelt päiseid, makrosid või tekstisisest koodi? Need küsimused lahendavad tavaliselt riski. Kui see nii ei ole, isoleeri komponent protsessipiiri taha, asenda see või võta ärilitsents.

AGPL ja võrgu kasutamine

AGPL eksisteerib seetõttu, et copyleft käivitub levitamise teel ja SaaS-pakkujad ei levita. Selle võrguklausel nõuab, et kui muudate tarkvara ja teete selle kättesaadavaks kasutajatele, kes sellega kaugjuurdepääsu kaudu suhtlevad, pakute neile oma muudetud versiooni vastavat allikat.

Kolm punkti jäetakse sageli tähelepanuta. Kohustus lasub teenuse kasutajatel, mis avatud registreerimisega tootes pole kuigi lohutav. Selle käivitab modifitseerimine, seega modifitseerimata komponent seda ei kasuta, kuid parandatud versioon võib. Ja see tekitab sama kombineeritud töö küsimuse nagu GPL ülejäänud teie pinu jaoks – mistõttu paljud ettevõtted keelavad AGPL-i tootmiskoodis.

Litsentsi ühilduvus

Ühilduvus seisneb selliste komponentide kombineerimise probleemis, mille litsentsid kehtestavad kohustusi, mida ei saa ühes ja samas distributsioonis täita: lubavad litsentsid ühilduvad peaaegu kõigega, copyleft-litsentsid aga ainult sellega, mida nende endi tingimused lubavad. Standardjuhtum on Apache 2.0 ja GPLv2. Apache Software Foundation ja Free Software Foundation on ühel meelel, et kombinatsioon ei ole lubatud, kuna Apache 2.0 patendi lõpetamise ja hüvitamise sätted on täiendavad piirangud, mida GPLv2 ei luba. GPLv3 koostati neid aktsepteerima. Ühilduvus on ka suunatud: Apache koodi saab GPLv3 projekti integreerida, kuid mitte vastupidi. Üks vales kohas olev GPL-komponent võib sundida valima uuesti litsentsimise, ümberprojekteerimise või eemaldamise vahel – see on enne avaldamist palju odavam kui pärast.

Omistamis- ja teatamiskohustused

Kõige sagedamini rikutud kohustused on kõige vähem dramaatilised: autoriõiguse märkuste, litsentsitekstide, lahtiütluste ja Apache 2.0 all ka NOTICE sisu reprodutseerimine levitamisega kaasnevates materjalides. Iga perekond kehtestab neid, sealhulgas MIT ja BSD. Neid rikutakse, kuna need ei kuulu kellelegi, ja neid on kõige lihtsam parandada – tavaliselt tootega kaasas oleva genereeritud atribuutimisfaili abil. Ülaltoodud Hollandi juhtum oli just selle vea põhjuseks.

Patendi väljaandmine ja patendikaitse

MIT ja BSD ei ütle patentide kohta midagi ning see, kas patendilitsentsi saab kaudselt anda, on lahtine. Apache 2.0 lisas igalt kaastööliselt selgesõnalise ja tasuta patendilitsentsi koos kättemaksuklausliga: kui algatate patendivaidluse, väites, et teos rikub autoriõigusi, siis teie patendilitsents lõpeb. GPLv3 sisaldab võrreldavat patendikaitset ja oma patendisätteid.

Kaks tagajärge patendiportfelliga ettevõtetele. Kui teie insenerid panustavad Apache'i või GPLv3-litsentsiga projektidesse, annate litsentse oma patentide alusel. Ja kui te kunagi esitate patente ettevõtte vastu, mis sõltub samadest Apache'i litsentsiga komponentidest, mida teie kasutate, võib kättemaks teile maksta litsentsi, millele te toetud.

EUPL ja Hollandi avalik sektor

Euroopa Liidu avalik litsents versioon 1.2, mille Euroopa Komisjon kiitis heaks rakendusotsusega 2017. aasta mais, on OSI poolt heaks kiidetud autoriõiguse litsents, millel on kolm eristavat omadust.

• Keel. See on olemas ELi ametlikes keeltes ja kõigil heakskiidetud versioonidel on identne väärtus, seega saab Hollandi ametiasutus sõlmida lepinguid hollandi keeles.
• Ühilduvus. Lisas on loetletud ühilduvad litsentsid – nende hulgas GPLv2 ja v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ja CeCILL – ning lubatakse EUPL-koodi ja loetletud litsentsi alla kuuluvat koodi kombineerivat tuletatud teost levitada hoopis selle litsentsi alusel.
• Ulatus. Selle levitamise definitsioon hõlmab teose kättesaadavaks tegemist nii võrgus kui ka võrguväliselt. või pakkudes juurdepääsu selle olulistele funktsioonideleja EUPL artikkel 5 hõlmab autoriõiguse kohustust ka kaugsuhtluses, mille käigus sama funktsionaalsust pakutakse. Seega jõuab see teenusena pakutava tarkvarani viisil, mida GPL ei võimalda.

Hollandi avaliku sektori klient võib EUPL-i nõuda pigem poliitika kui seaduse alusel. Euroopa koostalitlusvõime seadus, määrus (EL) 2024/903, suunab avaliku sektori asutusi eelistama koostalitlusvõime lahendusi ilma piiravate litsentsitingimusteta, näiteks avatud lähtekoodi, kui see on samaväärne; riiklikul tasandil põhineb avatud lähtekoodi põhimõte tenzij kabineti otsustel ja poliitikasuundadel, mitte seadusel: Wet digitale overheid hõlbustab digitaalse identiteedi infrastruktuuri, kuid ei kehtesta täitmisele pööratavat kohustust avaldada kogu lähtekoodi. Lugege hankedokumente: EUPL-i nõue on teie tulemusega seotud ja võib olla vastuolus omandiõigusega kaitstud koodiga, mida kavatsesite taaskasutada.

Praktikas rakendamine

Kes saab kohtusse kaevata? Õiguste omaja – üksikud kaastöölised või sihtasutus või ettevõte, kellele autoriõigused on määratud. Fragmenteeritud autorlus on praktiline pidur: hageja peab tõendama vaidlusaluse koodi omandiõigust. See lükkas ümber tuntuima Euroopa GPL-i kohtuasja, kus kerneli arendaja hagi virtualiseerimisteenuse pakkuja vastu ebaõnnestus autorluse tõendamise puudumise tõttu (LG Hamburg 8. juuli 2016, 310 O 89/15; OLG Hamburg kinnitas otsuse 28. veebruaril 2019, 5 U 146/16).

Mida kohtupraktika kehtestab. Saksa kohtud on korduvalt tunnistanud, et avatud lähtekoodiga litsentsid on kehtivad ja et rikkumine muudab levitamise ebaseaduslikuks, alates esimesest GPL-i ettekirjutusest (LG München I 19. mai 2004, 21 O 6123/04). USA föderaalringkonnakohus jõudis samale järeldusele kohtuasjas Jacobsen vs. Katzer , 535 F.3d 1373 (Fed. Cir. 2008): litsentsitingimused on litsentsi ulatuse tingimused, mitte pelgalt lepingud, seega toetab rikkumine autoriõiguse nõuet ja ettekirjutust. USA kohtuvaidlustes uuritakse, kas allkasutaja saab GPL-i kolmanda osapoole soodustatud isikuna jõustada. See on keskne küsimus California ülemkohtu kohtuasjas Software Freedom Conservancy vs. Vizio : kas tarbijad saavad kolmanda osapoole soodustatud isikutena nõuda lähtekoodi avaldamist GPLv2 alusel. 23. detsembril 2025 otsustas kohus ühe punkti kokkuvõtliku otsuse alusel, leides, et GPLv2 ja LGPLv2.1 nõuavad allikat, mida saab mujal kasutamiseks hankida ja ümber töötada, mitte allikat, mida saab seadmesse uuesti installida, säilitades selle funktsionaalsuse. Kolmanda osapoole soodustatud isiku küsimus ise jäeti kohtuistungi otsustada, mida on mitu korda edasi lükatud. See on igal juhul California lepinguõiguse küsimus, seega ei ole see Hollandis kuidagi siduv; see muudaks aga kaebusi esitavate inimeste arvu.

Kuidas Hollandi kohus sellele läheneks. Autoriõiguse rikkumisena Auteursweti alusel: hageja tõendab omandiõigust ja reprodutseerimist või edastamist; kostja viitab litsentsile; hageja vastab, et selle tingimused ei olnud täidetud, seega kaitse ebaõnnestub. BW artikli 6:265 kohased lepingulised õiguskaitsevahendid toimivad paralleelselt, kuid autoriõigus on tugevam tee.

Õiguskaitsevahendid. Ettekirjutus vastavalt artiklile 3:296 BW, tavaliselt koos trahviga ja kättesaadav kokkuvõtliku menetluse teel; kahjutasu vastavalt artiklile 27 Aw ja kasumiaruanne vastavalt artiklile 27a Aw; tagasikutsumine, loovutamine või hävitamine vastavalt artiklile 28 Aw; ja mõistlike ja proportsionaalsete kohtukulude täielik hüvitamine vastavalt artiklile 1019h Rv. Juhtudel, kui tarkvara levitati tasuta, on kahju raske kvantifitseerida ja Saksamaa apellatsioonikohus keeldus kahjutasu määramast, kinnitades samal ajal ettekirjutuse (OLG Hamm 13. juuni 2017, 4 U 72/16). Kahjutasu on harva oluline: see on ettekirjutus, tagasikutsumine, kulude määramine ja allika avaldamise kohus, mida te ei kavatsenudki avaldada.

Kui avastate vastavusprobleemi

Tavaliselt saadakse teada kliendi turvaküsimustikust, hoolsuskohustuse käigus tehtud skannimisest või õiguste omaniku kirjast. Seejärel toimub parandus järgmiselt. Peatage kahjustatud järgu levitamine, kui oht on tõsine. Tehke kindlaks, milline komponent, milline versioon, milline litsents, millised tooted ja versioonid ning millise perioodi jooksul. Selgitage välja, mida litsents tegelikult nõuab – sageli on vaja pigem atribuutimisfaili kui lähtekoodi väljalaset. Valmistage ette artefaktid: teated, litsentsitekstid, täielik vastav lähtekood, sealhulgas ehitusskriptid, ja kirjalik pakkumine, kui seda kasutati. Saatke nõuetele vastav väljalase ja seejärel öelge õiguste omanikule, mida olete teinud, selle asemel, et vaidleda selle üle, kas te pidite seda tegema.

GPLv3 ja AGPLv3 litsentside puhul annab parandusaken kiirusele õigusliku väärtuse; GPLv2 litsentside puhul parandusõigust ei ole, mistõttu enamik jõustamisi lõpeb läbirääkimiste teel saavutatud vastavuskohustusega. Pange tähele, et advokaadi nõuanded kuuluvad advokaadile, mitte ettevõttesisesele inseneriaruandele.

Avatud lähtekoodiga ettevõtted ühinemistes ja omandamistes ning hoolsuskohustuse täitmisel

Tarkvara omandamisel on avatud lähtekood standardne hoolsuskohustuse töövoog ja avalikustamata autoriõiguse komponent põhitootes on üks väheseid leide, mis tehingut tegelikult muudab: kui toodet ei saa levitada ilma lähtekoodi avaldamata, omandab ostja hinnas olevast erineva vara.

Oodake koodibaasi skannimist, litsentsidega komponentide inventuuri ning küsimusi kaastöötajate ja töövõtjate kokkulepete kohta. Tüüpilised tulemused on konkreetne hüvitis, parandusmeetmete võtmise ootel säilitamine, eemaldamist nõudev eeltingimus või kohandatud avatud lähtekoodi garantii. Müüjad peaksid kõigepealt skannima: teie avaldatud leiud on läbirääkimiste tulemus, ostja nõustaja tehtud leiud aga mõjuvõimu. Ostjad ei tohiks otsida seisukohta, et „ettevõte omab oma intellektuaalomandit”, vaid kinnitust, et ükski toode ei sisalda avatud lähtekoodi, mis nõuaks omandiõigusega kaitstud lähtekoodi avalikustamist.

Materjalide loetelu, skaneerimine ja kübervastupidavusvõime seadus

Tarkvara materjalide loend on toote komponentide inventuur koos versioonide ja litsentsidega. Kui see oli veel hiljuti puhtalt lepinguline, siis nüüd on see ka regulatiivne.

Kübervastupidavusvõime seadus, määrus (EL) 2024/2847, jõustus 10. detsembril 2024 ja seda rakendatakse järk-järgult. See toimib paralleelselt Hollandi küberturvalisuse seadusega , mis käsitleb pigem organisatsiooni kui toodet. CRA artiklis 14 sätestatud aktiivselt ärakasutatud haavatavuste ja tõsiste intsidentide aruandluskohustused kehtivad alates 11. septembrist 2026; vastavushindamisasutuste teavitamise sätted alates 11. juunist 2026; määrus tervikuna alates 11. detsembrist 2027 (CRA artikkel 71). CRA I lisa nõuab tootjatelt toote komponentide identifitseerimist ja dokumenteerimist, sealhulgas koostades tarkvara materjalide loetelu üldkasutatavas ja masinloetavas vormingus, mis hõlmab vähemalt tipptasemel sõltuvusi. Seda ei pea avaldama; turujärelevalveasutused võivad seda nõuda.

Väljaspool äritegevust pakutav tasuta ja avatud lähtekoodiga tarkvara jääb CRA reguleerimisalast välja. Määrusega kehtestatakse avatud lähtekoodiga tarkvara haldur – juriidiline isik, kes toetab pidevalt äritegevuseks mõeldud avatud lähtekoodiga tarkvara arendamist –, kellel on CRA artiklis 24 leebemad kohustused: dokumenteeritud küberturvalisuse poliitika, koostöö turujärelevalveasutustega ja aruandlus. Kui turustate avatud lähtekoodiga tarkvara või rahastate projekti, mida teised turustavad, määrake kindlaks oma roll. Komisjon võttis oma esimesed juhised vastu 27. juulil 2026: komisjoni juhised kübervastupidavusvõime seaduse (CRA) kohaldamise kohta, mis on lisatud teatisele C(2026) 5252 ja milles käsitletakse muu hulgas seda, millal kuulub tasuta ja avatud lähtekoodiga tarkvara reguleerimisalasse. Rakendusakti, mis näeks ette tarkvara materjalide loendi vormingu, ei ole vastu võetud, seega jääb esialgu meetmeks määruse enda standard – üldkasutatav masinloetav vorming.

Tarkvara koostise analüüs, mida teostatakse CI-s, genereerib inventuuri, mis teenindab korraga vastavust, litsentsi läbivaatamist ja hoolsust. Sellised tööriistad ei leia tarnija koodi, tuvastavad valesti topeltlitsentsiga projekte ega suuda lugeda litsentsi tingimusi: käsitlege väljundit ülevaatuse algusena, mitte ülevaatusena.

Kui avaldate oma koodi: CLA-d ja DCO

Ettevõte, mis avaldab koodi ja võtab vastu väliseid panuseid, peab teadma, et tal on õigused sellele, mida ta ühendab. Kaastöölise litsentsileping on projekti ja kaastöölise vaheline leping, mis tavaliselt annab laiaulatusliku autoriõiguse litsentsi ja selgesõnalise patendilitsentsi koos originaalsuse ja autoriteedi garantiidega. See võimaldab ettevõttel oma projekti hiljem ümber litsentsida või pakkuda avatud lähtekoodiga projekti kõrval kommertslitsentse. Selle maksumus on hõõrdumine.

Linuxi kerneli ja paljude teiste projektide poolt kasutatav arendaja päritolusertifikaat ei ole litsentsi andmine, vaid igale commit'ile lisatud kinnitus, et kaastööline võib koodi projekti litsentsi alusel esitada. Vähem koormav ja vähem kaitsev: pole patendilitsentsi ega edasilitsentsimist.

Kui topeltlitsentsimine või tulevane edasilitsentsimine on teostatav, kasutage CLA-d; kui projekt on ehtne ühisvara, piisab tavaliselt DCO-st. Mõlemal juhul veenduge, et teie töö- ja töövõtjalepingud määravad autoriõigused teie inimeste kirjutatud koodile.

Praktiline poliitikakontrollnimekiri

• Looge toote kohta komponentide inventuur ja avaldage see ehitustorustikus, mitte käsitsi.
• Avalda sise-eeskirjad: lubatud nimekiri, keelatud loend ja kõige muu kinnitamise kord.
• Määratle kirjalikult, mis loetakse levitamiseks – kohapealsed installid, seadmed, konteinerid, SDK-d, mobiilirakendused, püsivara.
• Saatke iga tootega kaasa genereeritud atribuutimisfail.
• Litsentsivalikud tuleb kinnitada juba komponendi valimise ajal, mitte väljalaske ajal.
• Otsusta, kas välisprojektidesse panustamine vajab heakskiitu, arvestades kaasatud patentide väljastamist, ning vali enne esimest välist panust CLA või DCO.
• Viige intellektuaalomandi garantiid, hüvitamistingimused ja tagatisraha tingimused vastavusse tootes tegelikult sisalduva avatud lähtekoodiga.
• Tehke ülevaade enne raha kogumise või müügiprotsessi, mitte selle ajal.

Law & More nõustab tarkvarafirmasid ja nende investoreid Eindhoven ja Amsterdam avatud lähtekoodiga tarkvara vastavuse, litsentside läbivaatamise, kaastööliste kokkulepete ja tehingu avatud lähtekoodiga tarkvara töövoo kohta.