Avoimen lähdekoodin ohjelmistolisenssit Alankomaiden ja EU:n lainsäädännön mukaisesti

Lähes jokainen kaupallinen ohjelmistotuote sisältää avoimen lähdekoodin komponentteja, yleensä satoja, jotka kehittäjät valitsevat lakimiesten sijaan. Tästä tulee ongelma, kun kukaan ei voi sanoa, mitkä lisenssit soveltuvat, mitä ne edellyttävät ja onko tuote vaatimusten mukainen. Tässä artikkelissa selitetään, miten avoimen lähdekoodin lisenssit toimivat Alankomaiden ja EU:n lainsäädännön nojalla, missä riskit piilevät ja mitä toimenpiteitä on otettava huomioon.

Mitä avoimen lähdekoodin lisenssi on lainopillisesti?

Avoimen lähdekoodin lisenssi on tekijänoikeuslisenssi, joka myönnetään tietyin ehdoin. Se ei ole luopuminen oikeuksista, ei sitoutuminen julkiseen omaisuuteen eikä oikeuksista luopuminen. Tekijä säilyttää tekijänoikeudet 1 Aw ja 10 Aw artiklojen nojalla, jotka suojaavat tietokoneohjelmia teoksina, ja lisenssi sallii teot, jotka muutoin loukkaisivat 12 Aw ja 13 Aw artiklojen mukaisia ​​yksinoikeuksia.

Seuraus on tärkeämpi kuin määritelmä. Noudata ehtoja, niin kopiointi ja levittäminen ovat laillisia. Jos et noudata ehtoja, lupa ei kata tekoasi: käyttösi on tekijänoikeusrikkomus, ei sopimusrikkomus. Useimmat copyleft-lisenssit vahvistavat tätä päättymällä automaattisesti rikkomuksen sattuessa – GPLv2:ssa ei ole korjausaikaa, kun taas GPLv3 ja AGPLv3 palauttavat oikeudet, jos rikkomus korjataan määritellyn ajan kuluessa ilmoituksesta.

Alankomaiden tuomioistuimet soveltavat tätä päättelyä. Asiassa Rb. Amsterdam 22. syyskuuta 2020, ECLI:NL:RBAMS:2020:4717, jakelijan, joka poisti lisenssitekstin ja tekijänoikeusilmoituksen haarautuneesta koodikannasta, katsottiin menettäneen lupansa ja rikkovan tekijänoikeuksia. Suuren määrän uutta koodia lisääminen ei luonut itsenäistä teosta: alkuperäinen jäi tunnistettavasti läsnä, joten velvollisuudet kulkivat sen mukana.

Kaksi perhettä: salliva ja copyleft

Sallivat lisenssit – MIT, BSD-lisenssit, Apache 2.0 – sallivat käytön, muokkaamisen ja edelleenjakelun, myös suljetun lähdekoodin tuotteiden sisällä, edellyttäen, että säilytät tekijänoikeusilmoitukset ja lisenssitekstin.

Tekijänoikeuslisenssit edellyttävät, että ohjelmiston tai sen pohjalta tehdyn sovelluksen levittäminen tapahtuu samalla lisenssillä ja vastaava lähdekoodi on saatavilla. Ne eroavat toisistaan ​​laajuuden suhteen.

Copyleft-liipaisin ja linkityskysymys

Tekijänoikeusvelvoitteet kohdistuvat jakeluun, eivät käyttöön. Yritys, joka käyttää GPL-ohjelmistoa sisäisesti, olipa ohjelmisto kuinka paljon tahansa muokattu, ei jaa mitään eikä ole velkaa mitään. "Olemmeko jakaneet?" on aina ensimmäinen kysymys, ja siksi säilöt, laitteet, laiteohjelmistot ja SDK:t ovat tärkeämpiä kuin sisäiset työkalut.

Toinen kysymys on vaikeampi. GPL puhuu "ohjelmaan perustuvasta teoksesta" lainaten amerikkalaista johdannaisteoksen käsitettä. Alankomaiden laissa ei ole tällaista termiä: analyysi käy läpi kopiointi- ja sovitusoikeudet ja kysyy, onko alkuperäisteoksesta suojattua ilmaisua kopioitu.

Käytännön tapaus on linkittäminen. Hollantilainen tuomioistuin ei ole koskaan päättänyt, luoko GPL-kirjastoon linkitetty omistusoikeudellinen moduuli yhden copyleft-suojatun teoksen, eikä EU:lla ole sitovaa toimivaltaa. Free Software Foundationin näkemys, jonka mukaan linkittäminen luo yhdistetyn teoksen, on lisenssinvalvojan tulkinta, ei laki, ja vastakkainen näkemys on yhtä lailla testaamaton. Internetin suosikkivastauksella – dynaaminen linkitys turvallista, staattinen linkitys ei – ei ole pohjaa Alankomaiden tekijänoikeuslaissa, jossa ei kysytä, miten kääntäjä käyttäytyy. Puolustautuneempi analyysi kysyy, kuinka tiiviisti komponentit on yhdistetty: jakavatko ne osoiteavaruuden ja tietorakenteet, toimitetaanko yhdistelmä yhtenä tuotteena, voisiko se toimia yksinään, kopioiko omistusoikeus otsikoita, makroja tai inline-koodia copyleft-puolelta? Nämä kysymykset yleensä ratkaisevat riskin. Jos näin ei ole, eristä komponentti prosessirajan taakse, korvaa se tai ota kaupallinen lisenssi.

AGPL ja verkon käyttö

AGPL-lisenssi on olemassa, koska copyleft aktivoituu jakelun kautta, eivätkä SaaS-palveluntarjoajat jaa. Sen verkkolauseke edellyttää, että jos muokkaat ohjelmistoa ja asetat sen saataville käyttäjille, jotka ovat vuorovaikutuksessa sen kanssa etänä, tarjoat heille muokatun version vastaavan lähdekoodin.

Kolme asiaa jää usein huomiotta. Velvollisuus koskee palvelun käyttäjiä, mikä avoimen rekisteröitymisen tuotteessa ei ole kovin mukavaa. Se laukeaa muokkaamisesta, joten muokkaamaton komponentti ei käytä sitä, mutta päivitetty versio voi. Ja se herättää saman yhdistetyn työn kysymyksen kuin GPL-lisenssi muulle koodipinolle – minkä vuoksi monet yritykset kieltävät AGPL:n tuotantokoodissa.

Lisenssien yhteensopivuus

Yhteensopivuusongelma on sellaisten komponenttien yhdistäminen, joiden lisensseihin liittyvät velvoitteet eivät molempia voida täyttää samassa jakelussa: sallivat lisenssit ovat yhteensopivia lähes kaiken kanssa, copyleft-lisenssit vain sen kanssa, minkä niiden omat ehdot sallivat. Tyypillinen tapaus on Apache 2.0 ja GPLv2. Apache Software Foundation ja Free Software Foundation ovat yhtä mieltä siitä, että yhdistäminen ei ole sallittua, koska Apache 2.0:n patentin irtisanomis- ja korvausmääräykset ovat lisärajoituksia, joita GPLv2 ei salli. GPLv3 laadittiin hyväksymään ne. Yhteensopivuus on myös suuntaa antavaa: Apache-koodia voidaan sisällyttää GPLv3-projektiin, mutta ei päinvastoin. Yksi väärässä paikassa oleva GPL-komponentti voi pakottaa valitsemaan uudelleenlisensoinnin, uudelleensuunnittelun tai poistamisen välillä – paljon halvempaa ennen julkaisua kuin sen jälkeen.

Määräämis- ja ilmoitusvelvollisuudet

Yleisimmin rikotut velvoitteet ovat vähiten dramaattisia: tekijänoikeusilmoitusten, lisenssitekstien, vastuuvapauslausekkeiden ja Apache 2.0:ssa myös NOTICE-sisällön jäljentäminen jakelun mukana tulevissa materiaaleissa. Jokainen perhe, myös MIT ja BSD, asettaa niitä. Niitä rikotaan, koska kukaan ei omista niitä, ja ne on helpoin korjata – yleensä tuotteen mukana toimitetulla luodulla attribuutiotiedostolla. Yllä oleva hollantilainen tapaus johti juuri tähän virheeseen.

Patenttien myöntäminen ja patenttien vastatoimet

MIT ja BSD eivät sano mitään patenteista, ja on epäselvää, voidaanko patenttilisenssiä pitää implisiittisenä. Apache 2.0 lisäsi jokaiselta osallistujalta nimenomaisen, rojaltivapaan patenttilisenssin, johon liittyi kostotoimenpidelauseke: jos nostat patenttioikeudenkäynnin väittäen, että työ loukkaa tekijänoikeuksia, patenttilisenssisi päättyy. GPLv3 sisältää vastaavan myöntämisoikeuden ja omat patenttimääräykset.

Kaksi seurausta patenttisalkkuja omistaville yrityksille. Jos insinöörisi osallistuvat Apache- tai GPLv3-lisensoituihin projekteihin, myönnät lisenssejä omien patenttiesi nojalla. Ja jos joskus vaadit patentteja yritystä vastaan, joka on riippuvainen samoista Apache-lisensoiduista komponenteista, joita käytät, kostotoimet voivat maksaa sinulle lisenssin, johon olet riippuvainen.

EUPL ja Alankomaiden julkinen sektori

Euroopan komission toukokuussa 2017 täytäntöönpanopäätöksellä hyväksymä Euroopan unionin julkinen lisenssi (EU Public Licence) versio 1.2 on OSI:n hyväksymä copyleft-lisenssi, jolla on kolme erottavaa ominaisuutta.

• Kieli. Se on olemassa EU:n virallisilla kielillä, ja kaikilla hyväksytyillä versioilla on sama arvo, joten hollantilainen viranomainen voi tehdä sopimuksia hollanniksi.
• Yhteensopivuus. Liitteessä luetellaan yhteensopivat lisenssit – mukaan lukien GPLv2 ja v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL ja CeCILL – ja sallitaan johdannaisteosten, joissa EUPL-koodia yhdistetään luettelossa mainitun lisenssin alaiseen koodiin, levittäminen kyseisen lisenssin nojalla.
• Saavuttaa. Sen levittämisen määritelmä kattaa teoksen saataville asettamisen verkossa tai sen ulkopuolella tai tarjoamalla pääsyn sen olennaisiin toimintoihin, ja EUPL:n 5 artikla siirtää tekijänoikeusvelvoitteen myös etävuorovaikutukseen, jossa samaa toiminnallisuutta tarjotaan. Se koskee siis palveluna toimitettavaa ohjelmistoa, toisin kuin GPL.

Alankomaalainen julkisen sektorin asiakas saattaa vaatia EUPL-lisenssiä pikemminkin käytäntönä kuin lakiin perustuen. Yhteentoimivuus Eurooppaa koskeva asetus (EU) 2024/903 ohjaa julkisen sektorin elimiä priorisoimaan yhteentoimivuusratkaisuja ilman rajoittavia lisenssiehtoja, kuten avointa lähdekoodia, jos se on vastaava. Kansallisesti avoimen lähdekoodin periaate , tenzij , perustuu hallituksen päätöksiin ja poliittisiin linjauksiin, ei lakiin: Wet digitale overheid helpottaa digitaalisen identiteetin infrastruktuuria, mutta ei aseta täytäntöönpanokelpoista velvoitetta julkaista kaikkea lähdekoodia. Lue tarjousasiakirjat: EUPL-vaatimus sitoo toimitettavaasi ja voi olla yhteensopimaton uudelleenkäytettävän omistusoikeuskoodin kanssa.

Käytännön täytäntöönpano

Kuka voi haastaa oikeuteen. Oikeudenhaltija – yksittäiset avustajat vai säätiö tai yritys, jolle tekijänoikeudet on siirretty. Hajanaisen tekijyyden käsite on käytännön jarru: kantajan on todistettava omistavansa kyseessä olevan koodin. Tämä esti tunnetuimman eurooppalaisen GPL-tapauksen, jossa ytimen kehittäjän kanne virtualisointitoimittajaa vastaan ​​hylättiin, koska tekijyyttä ei todistettu (LG Hamburg 8. heinäkuuta 2016, 310 O 89/15; vahvisti OLG Hamburg 28. helmikuuta 2019, 5 U 146/16).

Mitä oikeuskäytäntö osoittaa. Saksalaiset tuomioistuimet ovat toistuvasti hyväksyneet, että avoimen lähdekoodin lisenssit ovat päteviä ja että rikkomus tekee levittämisestä laitonta, alkaen ensimmäisestä GPL-kieltomääräyksestä (LG München I 19. toukokuuta 2004, 21 O 6123/04). Yhdysvaltain liittovaltion tuomioistuin päätyi samaan johtopäätökseen Jacobsen v. Katzer -tapauksessa , 535 F.3d 1373 (Fed. Cir. 2008): lisenssiehdot ovat ehtoja lisenssin laajuudelle, eivät pelkkiä sitoumuksia, joten rikkomus tukee tekijänoikeusvaatimusta ja kieltomääräystä. Yhdysvaltain oikeudenkäynneissä selvitetään, voiko jatkokäyttäjä kolmannen osapuolen edunsaajana panna GPL-lisenssin täytäntöön. Tämä on keskeinen kysymys Software Freedom Conservancy v. Vizio -tapauksessa Kalifornian ylemmässä oikeudessa: voivatko kuluttajat kolmannen osapuolen edunsaajina vaatia lähdekoodin julkaisemista GPLv2-lisenssin nojalla. Asiaa koskevaa lopullista päätöstä odotetaan vasta valamiehistön oikeudenkäynnin jälkeen vuonna 2026, joten asia ei ole vielä ratkaistu.

Miten hollantilainen tuomioistuin lähestyisi asiaa. Tekijänoikeusrikkomuksena Auteurswetin nojalla: kantaja todistaa omistajuuden ja kopioinnin tai välittämisen; vastaaja vetoaa lisenssiin; kantaja vastaa, että sen ehtoja ei ole täytetty, joten puolustus epäonnistuu. BW:n artiklan 6:265 mukaiset sopimusperusteiset oikeussuojakeinot toimivat rinnakkain, mutta tekijänoikeus on vahvempi tie.

Oikeussuojakeinot. BW-artiklan 3:296 mukainen kieltomääräys, johon tyypillisesti liittyy uhkasakko ja joka on saatavilla yhteenvetona; vahingonkorvaukset 27 Aw -artiklan mukaisesti ja voitonselvitys 27a Aw -artiklan mukaisesti; takaisinveto, luovutus tai tuhoaminen 28 Aw -artiklan mukaisesti; ja kohtuullisten ja oikeasuhtaisten oikeudenkäyntikulujen täysimääräinen korvaaminen 1019h Rv -artiklan mukaisesti. Kun ohjelmisto jaettiin ilmaiseksi, tappiota on vaikea määrittää, ja saksalainen muutoksenhakutuomioistuin kieltäytyi myöntämästä vahingonkorvauksia, mutta vahvisti kieltomääräyksen (OLG Hamm 13. kesäkuuta 2017, 4 U 72/16). Vahingonkorvaukset ovat harvoin ratkaisevia: ne ovat kieltomääräys, takaisinveto, kustannusmääräys ja sellaisen lähteen julkaiseminen, jota ei koskaan ollut tarkoitus julkaista.

Kun huomaat vaatimustenmukaisuusongelman

Löytö tulee yleensä asiakkaan tietoturvakyselystä, due diligence -tarkastuksen aikana tehdystä skannauksesta tai oikeudenhaltijan kirjeestä. Korjaavat toimenpiteet toimivat sitten seuraavasti: Pysäytä kyseisen koontiversion jakelu, jos altistuminen on vakava. Selvitä mikä komponentti, mikä versio, mikä lisenssi, mitkä tuotteet ja julkaisut ja millä ajanjaksolla. Selvitä, mitä lisenssi todella vaatii – usein attribuutiotiedosto lähdekoodin julkaisun sijaan. Valmistele tarvittavat osat: ilmoitukset, lisenssitekstit, täydellinen vastaava lähdekoodi, mukaan lukien koontikomentosarjat, ja kirjallinen tarjous, jos niitä käytetään. Lähetä yhteensopiva julkaisu ja kerro sitten oikeudenhaltijalle, mitä olet tehnyt, sen sijaan, että väitelisit siitä, oliko sinun pakko tehdä niin.

GPLv3- ja AGPLv3-lisensseissä oikeussuojakeino antaa nopeudelle oikeudellisen arvon; GPLv2-lisensseissä ei ole oikeussuojakeinoa, minkä vuoksi useimmat täytäntöönpanotoimet päättyvät neuvoteltuun vaatimustenmukaisuussitoumukseen. Huomaa myös, että asianajajan neuvoihin liittyy etuoikeus, ei sisäiseen suunnitteluraporttiin.

Avoin lähdekoodi yrityskaupoissa ja due diligence -prosessissa

Ohjelmistokaupassa avoin lähdekoodi on vakiotarkastusprosessi, ja ydintuotteen salassa pidettävä tekijänoikeuskomponentti on yksi harvoista löydöksistä, jotka todella vaikuttavat kauppaan: jos tuotetta ei voida levittää julkaisematta lähdekoodia, ostaja hankkii eri omaisuuserän kuin hinnoiteltu.

Odota koodikannan skannausta, komponenttiluetteloa lisensseineen sekä kysymyksiä avustajan ja urakoitsijan sopimuksista. Tyypillisiä tuloksia ovat erityinen korvaus, korjausta odottava pidätys, poistamista vaativa ennakkoehto tai räätälöity avoimen lähdekoodin takuu. Myyjien tulisi skannata ensin: paljastamasi löydökset ovat neuvottelutulosta, ostajan neuvojan tekemät löydökset ovat vipuvaikutusta. Ostajien ei tulisi pyrkiä siihen, että "yritys omistaa immateriaalioikeutensa", vaan vakuutukseen siitä, että mikään tuote ei sisällä avoimen lähdekoodin ohjelmistoja, mikä edellyttäisi omistusoikeuden alaisen lähdekoodin paljastamista.

Materiaaliluettelo, skannaus ja kyberturvallisuuslaki

Ohjelmiston osaluettelo on luettelo tuotteen komponenteista versioineen ja lisensseineen. Vielä äskettäin puhtaasti sopimukseen perustuva luettelo on nykyään myös sääntelyyn perustuva.

Kyberturvallisuuslaki, asetus (EU) 2024/2847, tuli voimaan 10. joulukuuta 2024 ja se tulee voimaan vaiheittain. Artiklan 14 mukaiset CRA:n mukaiset aktiivisesti hyödynnettyjä haavoittuvuuksia ja vakavia poikkeamia koskevat raportointivelvollisuudet tulevat voimaan 11. syyskuuta 2026; vaatimustenmukaisuuden arviointilaitosten ilmoittamista koskevat säännökset 11. kesäkuuta 2026; ja asetus kokonaisuudessaan 11. joulukuuta 2027 (CRA:n 71 artikla). CRA:n liitteen I mukaan valmistajien on yksilöitävä ja dokumentoitava tuotteen komponentit, mukaan lukien laatimalla ohjelmiston materiaaliluettelo yleisesti käytetyssä ja koneellisesti luettavassa muodossa, joka kattaa ainakin ylimmän tason riippuvuudet. Luetteloa ei tarvitse julkaista; markkinavalvontaviranomaiset voivat pyytää sitä.

Kaupallisen toiminnan ulkopuolella toimitettavat ilmaiset ja avoimen lähdekoodin ohjelmistot eivät kuulu CRA:n piiriin. Asetuksessa otetaan käyttöön avoimen lähdekoodin ohjelmistojen vastuuhenkilö – oikeushenkilö, joka antaa jatkuvaa tukea kaupalliseen toimintaan tarkoitetun avoimen lähdekoodin ohjelmiston kehittämiselle – ja siinä asetetaan CRA:n 24 artiklassa kevyemmät velvoitteet: dokumentoitu kyberturvallisuuspolitiikka, yhteistyö markkinavalvontaviranomaisten kanssa ja raportointi. Jos kaupallistat avoimen lähdekoodin ohjelmistoja tai rahoitat muiden kaupallistamaa hanketta, määritä, mikä rooli sinulla on. Komissio antoi ensimmäiset ohjeensa 27. heinäkuuta 2026: komission ohjeet kyberturvallisuuslain (CRA) soveltamisesta, jotka on liitetty tiedonantoon C(2026) 5252. Ohjeissa käsitellään muun muassa sitä, milloin ilmaiset ja avoimen lähdekoodin ohjelmistot kuuluvat soveltamisalaan. Ohjelmistojen osaluettelon muotoa koskevaa täytäntöönpanosäädöstä ei ole annettu, joten asetuksen oma standardi – yleisesti käytetty, koneellisesti luettava muoto – on edelleen voimassa toistaiseksi.

Ohjelmistokoostumusanalyysi, joka suoritetaan CI:ssä, luo luettelon, joka palvelee vaatimustenmukaisuutta, lisenssitarkastusta ja huolellisuutta samanaikaisesti. Tällaiset työkalut ohittavat toimittajan koodin, tunnistavat väärin kaksoislisenssiprojekteja eivätkä pysty lukemaan lisenssiehtoja: käsittele tulosta tarkistuksen alkuna, älä itse tarkistuksena.

Jos julkaiset omaa koodiasi: CLA:t ja DCO

Yrityksen, joka julkaisee koodia ja vastaanottaa ulkopuolisia lisäyksiä, on tiedettävä, että sillä on oikeudet siihen, mitä se yhdistää. Avustajalisenssisopimus on projektin ja avustajan välinen sopimus, joka tyypillisesti myöntää laajan tekijänoikeuslisenssin ja nimenomaisen patenttilisenssin, takuita alkuperäisyydestä ja auktoriteetista. Se antaa yritykselle mahdollisuuden uudelleenlisensoida projektinsa myöhemmin tai tarjota kaupallisia lisenssejä avoimen lähdekoodin projektin rinnalla. Sen kustannus on kitka.

Linux-ytimen ja monien muiden projektien käyttämä kehittäjän alkuperätodistus ei ole lisenssin myöntäminen, vaan kevyt vakuutus, joka lisätään jokaiseen commit-tiedostoon kuittausriviksi, jotta osallistuja voi lähettää koodin projektin lisenssin alaisena. Vähemmän työlästä ja suojaavaa: ei patenttilisenssiä, ei uudelleenlisensointia.

Jos kaksoislisensointi tai tuleva jatkolisensointi on mahdollista, käytä CLA:ta; jos projekti on aito yhteisomistus, DCO yleensä riittää. Joka tapauksessa varmista, että työ- ja urakoitsijasopimuksissasi on määritelty tekijänoikeudet kirjoittamaasi koodiin.

Käytännön tarkistuslista käytännöistä

• Luo komponenttivarasto tuotteelle ja julkaise se rakennusputkessa, älä manuaalisesti.
• Julkaise sisäinen käytäntö: sallittujen luettelo, kiellettyjen luettelo ja hyväksymisreitti kaikelle muulle.
• Määrittele kirjallisesti, mikä lasketaan jakeluksi – paikalliset asennukset, laitteet, säilöt, SDK:t, mobiilisovellukset, laiteohjelmistot.
• Lähetä jokaisen tuotteen mukana luotu attribuutiotiedosto.
• Hyväksy lisenssivalinnat suunnitteluvaiheessa, komponentin valinnan yhteydessä, ei julkaisun yhteydessä.
• Päätä, tarvitsevatko ulkoisiin projekteihin tehdyt panokset hyväksynnän, ottaen huomioon myönnettyjen patenttien määrän, ja valitse CLA tai DCO ennen ensimmäistä ulkopuolista panosta.
• Yhdenmukaista immateriaalioikeuksien takuut, korvausvastuut ja escrow-ehdot tuotteen tosiasiallisen avoimen lähdekoodin kanssa.
• Tee arviointi ennen varainhankinta- tai myyntiprosessia, älä sen aikana.