Atvirojo kodo programinės įrangos licencijos pagal Nyderlandų ir ES įstatymus

Beveik kiekviename komerciniame programinės įrangos produkte yra atvirojo kodo komponentų, dažniausiai šimtų, kuriuos pasirenka kūrėjai, o ne teisininkai. Tai tampa problema, kai niekas negali pasakyti, kurios licencijos taikomos, ko jos reikalauja ir ar produktas atitinka reikalavimus. Šiame straipsnyje paaiškinama, kaip atvirojo kodo licencijos veikia pagal Nyderlandų ir ES teisę, kur slypi rizika ir ką reikia turėti.

Kas yra atvirojo kodo licencija teisiniu požiūriu

Atvirojo kodo licencija yra autorių teisių licencija, suteikiama su tam tikromis sąlygomis. Tai nėra atsisakymas, ne įsipareigojimas viešajai erdvei, ne teisių atsisakymas ir šiuo atžvilgiu ji veikia kaip bet kuri kita programinės įrangos licencija pagal Nyderlandų įstatymus . Autorius išlaiko autorių teises pagal 1 Aw ir 10 Aw straipsnius, kurie saugo kompiuterių programas kaip kūrinius, o licencija leidžia veiksmus, kurie kitaip pažeistų išimtines teises pagal 12 Aw ir 13 Aw straipsnius.

Pasekmė yra svarbesnė nei apibrėžimas. Jei laikysitės reikalavimų, kopijavimas ir platinimas bus teisėti. Jei nesilaikysite reikalavimų, leidimas neapims jūsų veiksmų: jūsų naudojimas yra autorių teisių, o ne sutarties pažeidimas. Dauguma autorių teisių licencijų tai sustiprina automatiškai nutraukdamos pažeidimo atveju – GPLv2 be jokio ištaisymo laikotarpio, o GPLv3 ir AGPLv3 atkuria teises, jei pažeidimas ištaisomas per nustatytą laikotarpį po pranešimo.

Nyderlandų teismai taiko šį samprotavimą. Byloje Rb. Amsterdam 2020 m. rugsėjo 22 d., ECLI:NL:RBAMS:2020:4717, byloje platintojas, pašalinęs licencijos tekstą ir autorių teisių pranešimą iš atskirtos kodų bazės, buvo pripažintas praradusiu leidimą ir pažeidusiu autorių teises. Pridėjus didelį kiekį naujo kodo, savarankiškas kūrinys nebuvo sukurtas: originalas išliko atpažįstamas, todėl kartu su juo atsirado ir įsipareigojimai.

Dvi šeimos: permisyvi ir autorių teisių pažeidimo

Leidžiančiosios licencijos – MIT, BSD licencijos, „Apache 2.0“ – leidžia naudoti, modifikuoti ir platinti, įskaitant uždarojo kodo produktus, jei išsaugomi autorių teisių pranešimai ir licencijos tekstas.

Autorių teisių licencijos reikalauja, kad platindami programinę įrangą arba jos pagrindu sukurtą produktą, tai darytumėte pagal tą pačią licenciją ir pateiktumėte atitinkamą šaltinio kodą. Jos skiriasi savo apimtimi.

„Copyleft“ trigeris ir susiejimo klausimas

Autorių teisių įstatymą (Copyleft) reglamentuojantys įsipareigojimai yra susiję su platinimu, o ne su naudojimu. Įmonė, kuri viduje naudoja GPL programinę įrangą, kad ir kaip smarkiai ji būtų modifikuota, nieko neplatina ir nieko neskolinga. „Ar mes platinome?“ visada yra pirmas klausimas, ir todėl konteineriai, įrenginiai, programinė įranga ir SDK yra svarbesni nei vidiniai įrankiai.

Antrasis klausimas yra sunkesnis. GPL licencija kalba apie „kūrinį, pagrįstą programa“, pasiskolinant amerikietišką išvestinio kūrinio sąvoką. Nyderlandų teisėje tokio termino nėra: analizė apima atgaminimo ir adaptavimo teises, klausiant, ar buvo atgaminta saugoma originalo išraiška.

Praktinis atvejis yra susiejimas. Ar nuosavybės teise saugomo modulio susiejimas su GPL biblioteka sukuria vieną kūrinį, kuriam taikomos autorių teisių nuostatos, niekada nebuvo nusprendęs Nyderlandų teismas, ir nėra jokios privalomos ES institucijos. Laisvosios programinės įrangos fondo požiūris, kad susiejimas sukuria sujungtą kūrinį, yra licencijos tvarkytojo aiškinimas, o ne įstatymas, o priešingas požiūris taip pat nėra patikrintas. Mėgstamiausias interneto atsakymas – dinaminis susiejimas saugus, statinis susiejimas ne – neturi pagrindo Nyderlandų autorių teisių įstatyme, kuriame neklausiama, kaip elgiasi kompiliatorius. Labiau pagrįsta analizė klausia, kaip glaudžiai komponentai yra sujungti: ar jie dalijasi adresų erdve ir duomenų struktūromis, ar derinys pateikiamas kaip vienas produktas, ar jis galėtų veikti atskirai, ar nuosavybės teise saugoma pusė atkuria antraštes, makrokomandas ar vidinį kodą iš autorių teisių saugomos pusės? Šie klausimai paprastai išsprendžia riziką. Jei jie to nepadaro, komponentą izoliuokite už proceso ribos, pakeiskite jį arba gaukite komercinę licenciją.

AGPL ir tinklo naudojimas

AGPL licencija egzistuoja todėl, kad „copyleft“ licenciją suaktyvina platinimas, o SaaS teikėjai neplatina. Jos tinklo sąlyga reikalauja, kad jei modifikuojate programinę įrangą ir pateikiate ją vartotojams, kurie su ja sąveikauja nuotoliniu būdu, jūs jiems pasiūlytumėte atitinkamą modifikuotos versijos šaltinį.

Dažnai praleidžiami trys punktai. Įsipareigojimas taikomas paslaugos vartotojams, o tai atviros registracijos produkte nėra labai patogu. Įsipareigojimą sukelia modifikacija, todėl nemodifikuotas komponentas jo neįtraukia, tačiau pataisytas kompiliavimas gali. Be to, tai kelia tą patį kombinuoto darbo klausimą, kaip ir GPL licencija likusiai jūsų programų paketo daliai – todėl daugelis įmonių draudžia AGPL gamybiniame kode.

Licencijų suderinamumas

Suderinamumas – tai problema, kylanti dėl komponentų, kurių licencijos nustato įsipareigojimus, kurių negalima įvykdyti viename platinime: leidžiančiosios licencijos suderinamos su beveik viskuo, o autorių teisių saugomos licencijos – tik su tuo, ką leidžia jų pačių sąlygos. Standartinis atvejis yra „Apache 2.0“ ir „GPLv2“. „Apache Software Foundation“ ir „Free Software Foundation“ sutinka, kad derinys neleidžiamas, nes „Apache 2.0“ patento nutraukimo ir žalos atlyginimo nuostatos yra papildomi apribojimai, kurių GPLv2 neleidžia. GPLv3 buvo parengta taip, kad jas priimtų. Suderinamumas taip pat yra kryptingas: „Apache“ kodą galima integruoti į GPLv3 projektą, bet ne atvirkščiai. Vienas GPL komponentas netinkamoje vietoje gali priversti rinktis tarp pakartotinės licencijos, perprojektavimo ar pašalinimo – daug pigiau prieš išleidimą nei po jo.

Priskyrimo ir pranešimo įsipareigojimai

Dažniausiai pažeidžiami įsipareigojimai yra mažiausiai dramatiški: autorių teisių pranešimų, licencijų tekstų, atsakomybės ribojimų ir, naudojant „Apache 2.0“, PRANEŠIMŲ turinio atkūrimas platinimo medžiagoje. Kiekviena šeima, įskaitant MIT ir BSD, juos taiko. Jie pažeidžiami, nes niekam nepriklauso jų nuosavybė, ir juos lengviausia ištaisyti – paprastai naudojant sugeneruotą priskyrimo failą, pateikiamą kartu su produktu. Minėtas olandų atvejis lėmė būtent šį gedimą.

Patentų suteikimas ir atsakomosios priemonės dėl patentų

MIT ir BSD nieko nesako apie patentus, ir neaišku, ar patento licencija gali būti numanoma. „Apache 2.0“ pridėjo aiškią, neatlygintiną patento licenciją iš kiekvieno bendradarbio ir atsakomųjų veiksmų sąlygą: jei iškelsite patentų bylą, teigdami, kad darbas pažeidžia autorių teises, jūsų patento licencija bus nutraukta. GPLv3 apima panašią suteikimo ir savo patentų nuostatas.

Dvi pasekmės įmonėms, turinčioms patentų portfelius. Jei jūsų inžinieriai prisideda prie „Apache“ arba GPLv3 licencijuotų projektų, jūs suteikiate licencijas pagal savo patentus. Ir jei kada nors pareikšite patentus prieš įmonę, kuri priklauso nuo tų pačių „Apache“ licencijuotų komponentų, kuriuos naudojate jūs, atsakomosios priemonės gali kainuoti jums licenciją, kuria pasitikite.

EUPL ir Nyderlandų viešasis sektorius

Europos Sąjungos viešosios licencijos 1.2 versija, kurią Europos Komisija patvirtino įgyvendinimo sprendimu 2017 m. gegužės mėn., yra OSI patvirtinta autorių teisių saugoma licencija, turinti tris skiriamuosius bruožus.

• Kalba. Jis egzistuoja oficialiomis ES kalbomis, visos patvirtintos versijos yra vienodai galiojančios, todėl Nyderlandų institucija gali sudaryti sutartis olandų kalba.
• Suderinamumas. Priede išvardytos suderinamos licencijos – GPLv2 ir v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ir CeCILL – ir leidžiama platinti išvestinį kūrinį, kuriame EUPL kodas derinamas su kodu pagal išvardytą licenciją, pagal tą licenciją.
• Pasiekite. Platinimo apibrėžimas apima kūrinio pateikimą į internetą arba neprisijungus. arba suteikiant prieigą prie esminių jo funkcijų, o EUPL 5 straipsnyje autorių teisių įpareigojimas taikomas ir nuotolinei sąveikai, kurios metu siūloma ta pati funkcija. Todėl jis taikomas programinei įrangai, teikiamai kaip paslauga, kitaip nei GPL.

Nyderlandų viešojo sektoriaus klientas gali reikalauti EUPL kaip politikos, o ne įstatymo reikalo. Sąveikaujančios Europos įstatymas, Reglamentas (ES) 2024/903, nurodo viešojo sektoriaus įstaigoms teikti pirmenybę sąveikumo sprendimams be ribojančių licencijavimo sąlygų, pavyzdžiui, atvirojo kodo sprendimams, jei jie lygiaverčiai; nacionaliniu mastu atvirojo kodo principas (tenzij) grindžiamas ministrų kabineto sprendimais ir politikos linijomis, o ne įstatymu: „Wet digitale overheid“ palengvina skaitmeninės tapatybės infrastruktūros kūrimą, tačiau nenustato vykdytinos prievolės skelbti visą šaltinio kodą. Perskaitykite konkurso dokumentus: EUPL reikalavimas saisto jūsų rezultatą ir gali būti nesuderinamas su nuosavybės teise priklausančiu kodu, kurį ketinote pakartotinai naudoti.

Praktinis vykdymas

Kas gali paduoti į teismą. Teisių turėtojas – individualūs bendradarbiai arba fondas ar įmonė, turinti priskirtas autorių teises. Fragmentuota autorystė yra praktinis stabdys: ieškovas turi įrodyti ginčijamo kodo nuosavybę. Tai padėjo įveikti geriausiai žinomą Europos GPL bylą, kurioje branduolio kūrėjo ieškinys prieš virtualizacijos tiekėją buvo atmestas dėl autorystės įrodymų trūkumo (LG Hamburg 2016 m. liepos 8 d., 310 O 89/15; patvirtintas OLG Hamburg 2019 m. vasario 28 d., 5 U 146/16).

Ką nustato teismų praktika. Vokietijos teismai ne kartą pripažino, kad atvirojo kodo licencijos yra galiojančios ir kad pažeidimas platinimą daro neteisėtą, pradedant pirmuoju GPL draudimu (LG München I 2004 m. gegužės 19 d., 21 O 6123/04). JAV federalinis apygardos teismas priėjo prie tokios pačios išvados byloje Jacobsen prieš Katzer , 535 F.3d 1373 (Fed. Cir. 2008): licencijos sąlygos yra suteikimo apimties sąlygos, o ne vien sutartys, todėl pažeidimas yra pagrindas ieškiniui dėl autorių teisių ir teismo įsakymui. JAV bylinėjimasis nagrinėjamas, ar tolesnis gavėjas gali ginti GPL kaip trečiosios šalies naudos gavėjas. Tai yra pagrindinis klausimas byloje „Software Freedom Conservancy prieš Vizio“, nagrinėjamoje Kalifornijos Aukščiausiajame teisme: ar vartotojai, kaip trečiosios šalies naudos gavėjai, gali reikalauti išlaisvinti šaltinio kodą pagal GPLv2. 2025 m. gruodžio 23 d. teismas priėmė sprendimą dėl vieno klausimo, pritardamas sutrumpintam sprendimui, nusprendęs, kad GPLv2 ir LGPLv2.1 reikalauja šaltinio, kurį galima gauti ir perdaryti naudoti kitur, o ne šaltinio, kurį galima iš naujo įdiegti įrenginyje išlaikant jo funkcionalumą. Pats trečiosios šalies naudos gavėjo klausimas buvo paliktas spręsti iki teismo posėdžio, kuris buvo atidėtas ne kartą. Bet kuriuo atveju tai yra Kalifornijos sutarčių teisės klausimas, todėl jis niekuo neįpareigoja Nyderlanduose; tai pakeistų tik skundą galinčių pateikti žmonių skaičių.

Kaip į tai žiūrėtų Nyderlandų teismas. Autorių teisių pažeidimas pagal „Auteurswet“: ieškovas įrodo nuosavybės teisę ir atgaminimą ar viešą paskelbimą; atsakovas remiasi licencija; ieškovas atsako, kad jos sąlygos nebuvo įvykdytos, todėl gynyba atmeta argumentus. Sutartinės teisių gynimo priemonės pagal BW 6:265 straipsnį taikomos lygiagrečiai, tačiau autorių teisės yra stipresnis kelias.

Teisių gynimo priemonės. Teismo draudimas pagal 3:296 BW straipsnį, paprastai su bauda ir prieinamas supaprastinto proceso tvarka; žalos atlyginimas pagal 27 Aw straipsnį ir pelno ataskaita pagal 27a Aw straipsnį; atšaukimas, perdavimas ar sunaikinimas pagal 28 Aw straipsnį; ir visiškas pagrįstų ir proporcingų teisinių išlaidų atlyginimas pagal 1019h Rv straipsnį. Kai programinė įranga buvo platinama nemokamai, nuostolius sunku įvertinti, todėl Vokietijos apeliacinis teismas atsisakė priteisti žalos atlyginimą, tačiau paliko galioti teismo draudimą (OLG Hamm, 2017 m. birželio 13 d., 4 U 72/16). Žala retai kada yra skaudi: tai teismo draudimas, atšaukimas, išlaidų priteisimas ir būtinybė publikuoti šaltinį, kurio niekada neketinote publikuoti.

Kai aptinkate atitikties problemą

Paprastai informacija apie pažeidimą atskleidžiama iš kliento saugumo klausimyno, nuskaitymo atliekant deramo patikrinimo procedūrą arba teisių turėtojo laiško. Tuomet taisomosios priemonės atliekamos taip: jei rizika yra didelė, sustabdykite paveiktos versijos platinimą; nustatykite, kuris komponentas, kuri versija, kuri licencija, kurie produktai ir leidimai, per kokį laikotarpį; išsiaiškinkite, ko iš tikrųjų reikalauja licencija – dažnai tai yra priskyrimo failas, o ne šaltinio leidimo versija; parengkite artefaktus: pranešimus, licencijos tekstus, visą atitinkamą šaltinį, įskaitant kūrimo scenarijus, ir rašytinį pasiūlymą, jei jis buvo naudojamas; išsiųskite reikalavimus atitinkantį leidimą, tada pasakykite teisių turėtojui, ką padarėte, užuot ginčęsi, ar reikėjo tai padaryti.

Pagal GPLv3 ir AGPLv3 licencijas ištaisymo laikotarpis suteikia teisinę galią greičiui; pagal GPLv2 licencijas ištaisymo teisės nėra, todėl dauguma vykdymo užtikrinimo priemonių baigiasi derybomis dėl atitikties įsipareigojimo. Taip pat atkreipkite dėmesį, kad privilegija taikoma jūsų advokato konsultacijai, o ne vidinei inžinerinei ataskaitai.

Atvirojo kodo įmonės susijungimų ir įsigijimų bei išsamaus patikrinimo srityje

Programinės įrangos įsigijimo atveju atvirojo kodo programos yra standartinis kruopštumo darbo srautas, o neatskleistas autorių teisių saugomas pagrindinio produkto komponentas yra vienas iš nedaugelio faktų, kurie iš tikrųjų lemia sandorį: jei produkto negalima platinti neatskleidus jo šaltinio kodo, pirkėjas įsigyja kitą turtą nei tas, kuris buvo įkainotas.

Tikėkitės kodo bazės nuskaitymo, komponentų su licencijomis inventoriaus ir klausimų apie susitarimus su bendradarbiu ir rangovu. Tipiniai rezultatai yra konkreti žalos atlyginimo garantija, išlaikymas, kol bus imtasi ištaisymų, išankstinė sąlyga, reikalaujanti pašalinti, arba individuali atvirojo kodo garantija. Pardavėjai pirmiausia turėtų nuskaityti: jūsų atskleisti duomenys yra derybų rezultatas, o pirkėjo patarėjo pateikti duomenys – svertas. Pirkėjai turėtų siekti ne „įmonės intelektinės nuosavybės“, o patvirtinimo, kad joks produktas neapima atvirojo kodo, reikalaujančio atskleisti nuosavybės teise pagrįstą šaltinio kodą.

Medžiagų sąrašas, skenavimas ir Kibernetinio atsparumo įstatymas

Programinės įrangos medžiagų sąrašas yra produkto komponentų su versijomis ir licencijomis sąrašas. Iki šiol tai buvo grynai sutartinis reikalavimas, o dabar tai yra ir norminis dokumentas.

Kibernetinio atsparumo įstatymas, Reglamentas (ES) 2024/2847, įsigaliojo 2024 m. gruodžio 10 d. ir yra taikomas palaipsniui. Jis taikomas kartu su Nyderlandų kibernetinio saugumo įstatymu , kuris skirtas organizacijai, o ne produktui. Pranešimo apie aktyviai išnaudotas pažeidžiamumus ir sunkius incidentus, numatytus CRA 14 straipsnyje, įpareigojimai taikyti nuo 2026 m. rugsėjo 11 d.; nuostatos dėl atitikties vertinimo įstaigų pranešimo – nuo ​​2026 m. birželio 11 d.; visas reglamentas – nuo ​​2027 m. gruodžio 11 d. (CRA 71 straipsnis). CRA I priede reikalaujama, kad gamintojai identifikuotų ir dokumentuotų gaminio komponentus, be kita ko, parengdami programinės įrangos medžiagų sąrašą įprastai naudojamu ir kompiuterio skaitomu formatu, kuriame būtų nurodytos bent aukščiausio lygio priklausomybės. Jo skelbti nereikia; rinkos priežiūros institucijos gali jo paprašyti.

Nemokama ir atvirojo kodo programinė įranga, teikiama ne komercinės veiklos tikslais, nepatenka į KRA taikymo sritį. Reglamente įvedamas atvirojo kodo programinės įrangos valdytojas – juridinis asmuo, teikiantis nuolatinę paramą komercinei veiklai skirtos atvirojo kodo programinės įrangos kūrimui, – su lengvesniais KRA 24 straipsnyje numatytais įpareigojimais: dokumentuota kibernetinio saugumo politika, bendradarbiavimas su rinkos priežiūros institucijomis ir ataskaitų teikimas. Jei komercializuojate atvirojo kodo programinę įrangą arba finansuojate projektą, kurį komercializuoja kiti, nustatykite, kokį vaidmenį atliekate. Komisija priėmė pirmąsias gaires 2026 m. liepos 27 d.: Komisijos gaires dėl Kibernetinio atsparumo akto (KRA) taikymo, pridėtas prie komunikato C(2026) 5252, kuriose, be kita ko, aptariama, kada nemokama ir atvirojo kodo programinė įranga patenka į taikymo sritį. Nebuvo priimtas įgyvendinimo aktas, kuriame būtų nustatytas programinės įrangos medžiagų sąrašo formatas, todėl kol kas lieka priemone paties reglamento standartas – įprastai naudojamas, kompiuterio skaitomas formatas.

CI sistemoje atliekama programinės įrangos sudėties analizė sukuria inventorių, kuris vienu metu padeda užtikrinti atitiktį, licencijų peržiūrą ir patikrinimą. Tokios priemonės praleidžia tiekėjo kodą, klaidingai identifikuoja dvigubos licencijos projektus ir negali perskaityti licencijos sąlygų: rezultatas traktuojamas kaip peržiūros pradžia, o ne pati apžvalga.

Jei publikuojate savo kodą: CLA ir DCO

Įmonė, kuri leidžia kodą ir priima išorės įnašus, turi žinoti, kad turi teises į tai, ką sujungia. Bendradarbio licencijos sutartis yra sutartis tarp projekto ir bendraautorio, paprastai suteikianti plačią autorių teisių licenciją ir aiškią patentų licenciją su originalumo ir autoriteto garantijomis. Tai leidžia įmonei vėliau perlicencijuoti savo projektą arba pasiūlyti komercines licencijas kartu su atvirojo kodo licencija. Jos kaina yra trintis.

„Linux“ branduolio ir daugelio kitų projektų naudojamas kūrėjo kilmės sertifikatas nėra licencijos suteikimas, o supaprastintas patvirtinimas, pridedamas kaip pasirašymo eilutė prie kiekvieno įvykdymo, kad bendradarbis gali pateikti kodą pagal projekto licenciją. Mažiau sudėtinga ir mažiau apsaugo: nėra patento licencijos, nėra pakartotinės licencijos.

Jei įmanomas dvigubas licencijavimas arba būsima pakartotinė licencija, naudokite CLA; jei projektas yra tikrasis bendrosios nuosavybės objektas, paprastai pakanka DCO. Bet kuriuo atveju įsitikinkite, kad jūsų darbo ir rangovo sutartyse yra numatytos autorių teisės į jūsų žmonių rašomą kodą.

Praktinis politikos kontrolinis sąrašas

• Sugeneruokite komponentų atsargas kiekvienam produktui ir išleiskite jas kūrimo procese, o ne rankiniu būdu.
• Paskelbti vidinę politiką: leidžiamų veiksmų sąrašą, draudžiamų veiksmų sąrašą ir visų kitų veiksmų patvirtinimo procesą.
• Raštu apibrėžkite, kas laikoma platinimu – diegimas vietoje, įrenginiai, konteineriai, SDK, mobiliosios programėlės, programinė-aparatinė įranga.
• Kartu su kiekvienu produktu pridėkite sugeneruotą atribucijos failą.
• Licencijų pasirinkimus tvirtinkite projektavimo metu, kai komponentas yra pasirenkamas, o ne išleidimo metu.
• Nuspręskite, ar įnašams į išorinius projektus reikalingas patvirtinimas, atsižvelgiant į susijusių patentų suteikimą, ir prieš pirmąjį išorinį įnašą pasirinkite CLA arba DCO.
• Suderinkite intelektinės nuosavybės garantijas, žalos atlyginimo įsipareigojimus ir sąlyginio deponavimo sąlygas su produkte esančia atvirojo kodo programine įranga.
• Atlikite peržiūrą prieš lėšų rinkimo ar pardavimo procesą, o ne jo metu.

Law & More konsultuoja programinės įrangos įmones ir jų investuotojus Eindhoven bei Amsterdam dėl atvirojo kodo atitikties, licencijų peržiūros, susitarimų su bendradarbiais ir atvirojo kodo darbo srauto sandoryje.