Open source software (OSS) vormt al lange tijd de ruggengraat van moderne softwareontwikkeling en digitale infrastructuur. Bedrijven, start-ups en overheden bouwen als vanzelfsprekend op frameworks, bibliotheken en systeemcomponenten waarvan de broncode publiek toegankelijk is. Deze technische vrijheid gaat echter gepaard met een juridische verantwoordelijkheid die vaak wordt onderschat. Iedereen die open source gebruikt – voor interne ontwikkeling of in commerciële producten – betreedt een complex gebied van auteursrecht, licentierecht en contractontwerp.
Hieronder geef ik een overzicht van de belangrijkste juridische aspecten van open source software in Duitsland – met als doel om besluitvormers en ontwikkelaars houvast te bieden en typische risico’s te vermijden. Ik schrijf zelf al tientallen jaren over dit onderwerp.
Het wettelijke kader: Auteursrecht als basis
Volgens de Duitse wet – en in de EU – is software auteursrechtelijk beschermd. Dit geldt niet alleen voor “grote” toepassingen, maar ook voor afzonderlijke stukjes code als ze een persoonlijke intellectuele schepping vormen in de zin van artikel 2 UrhG. De bescherming ontstaat automatisch met de creatie – er is geen inschrijving in een register nodig. Iedereen die software schrijft is de auteur en heeft daarom uitgebreide rechten: alleen hij beslist over reproductie, distributie, bewerking en beschikbaarstelling aan het publiek.
In de praktijk is de auteur echter vaak niet één persoon, maar een team, soms jarenlang. In bedrijven speelt ook het arbeidsrecht een rol, aangezien de gebruiksrechten regelmatig toekomen aan de werkgever in overeenstemming met artikel 69b UrhG. Desondanks blijven de morele rechten bij de ontwikkelaar, wat een belangrijke invloed kan hebben op licenties – bijvoorbeeld onder open source voorwaarden.
Wat is “open source” vanuit juridisch oogpunt?
Open source is geen juridisch vacuüm. Ook hier blijft de software beschermd door het auteursrecht – het wordt alleen vrijgegeven voor gebruik onder speciale licentievoorwaarden. Deze licenties verschillen aanzienlijk in rechten en plichten. De doorslaggevende factor is dat open source niet betekent dat alles is toegestaan. Het zijn eerder juridisch bindende contracten die precies regelen wat de gebruiker met de code mag doen.
De bekendste familie zijn de zogenaamde copyleft-licenties, zoals de GNU General Public License (GPL). Deze licenties vereisen dat aangepaste versies beschikbaar worden gesteld als open source. Daartegenover staan permissieve licenties zoals de MIT of BSD licentie, die aanzienlijk meer vrijheid geven, zoals integratie in propriëtaire producten.
In juridische termen zijn open source licenties een speciaal geval van licentieovereenkomsten onder het verbintenissenrecht. De grote uitdaging is dat veel van deze licenties hun oorsprong vinden in de Amerikaanse wetgeving, maar wereldwijd worden gebruikt. In Duitsland bijvoorbeeld botsen bepaalde clausules met dwingende auteurswetgeving – zoals het verbod op volledige afstand van rechten. Desondanks is er een erkende praktijk ontstaan door gerechtelijke en academische ontvangst die de kern van de licenties juridisch uitvoerbaar maakt.
Risico’s verbonden aan gebruik en openbaarmaking
Een vaak onderschat probleem is de naleving van licenties bij het herdistribueren van open source componenten. Iedereen die bijvoorbeeld een bibliotheek met een GPL-licentie integreert in zijn eigen softwareproduct en deze verspreidt, moet zelf ook een licentie onder de GPL afgeven – inclusief het vrijgeven van de broncode. De zogenaamde “copyleft” werkt dus als een virale licentieverplichting.
Bij permissieve licenties is er geen openbaarmakingsverplichting, maar er zijn nog steeds duidelijke vereisten – bijvoorbeeld met betrekking tot het noemen van de auteur. Zelfs schijnbaar onschuldige inbreuken, zoals het verwijderen van auteursrechtmeldingen, kunnen een licentie-inbreuk vormen. In Duitsland kan dit leiden tot een vordering voor een voorlopige voorziening of – in het geval van commercieel gebruik – zelfs schadevergoeding.
Het wordt vooral kritiek als het onduidelijk is wie eigenlijk de auteur van de code is. Er circuleren vaak forks of bibliotheken waarvan de licentiesituatie moeilijk te begrijpen is. Zelfs geautomatiseerde hulpmiddelen voor licentieanalyse (bijv. in CI/CD-pijplijnen) zijn geen vervanging voor een juridische beoordeling, maar dienen op zijn best als een vroegtijdig waarschuwingssysteem.
Speciale vragen in een oogopslag
Bedrijven die open source software ontwikkelen of gebruiken staan voor de taak om duidelijke interne processen op te stellen. Dit omvat bijvoorbeeld het regelen of werknemers toestemming hebben om open source code te publiceren als onderdeel van hun arbeidsrelatie – en zo ja, onder welke voorwaarden. Een vrijgavepraktijk (“open source governance”) helpt om zowel intellectueel eigendom te beschermen als te handelen in overeenstemming met de wet.
Contracten met klanten of leveranciers moeten ook duidelijk regelen of en welke open source componenten worden gebruikt – en welke verplichtingen daaruit voortvloeien. Het vermijden van ongewenste “copyleft contaminatie” wordt zo een zakelijke noodzaak. Open source compliance speelt een steeds belangrijkere rol, vooral in de publieke sector, bij software-as-a-service of bij productcertificering (bijvoorbeeld in de medische of automobielsector). Certificeringsinstanties en klanten letten er goed op of en hoe bedrijven aan hun licentieverplichtingen voldoen.
Juridische valkuilen bij open source software
Open source software biedt vrijheid, maar geen onbeperkte vrijheid. Het praktische gebruik in bedrijven roept herhaaldelijk complexe juridische vragen op, die niet meer alleen te maken hebben met het juiste begrip van licenties, maar met strategische beslissingen binnen het bedrijf. Copyleft-licenties zoals de GPL, de juridische classificatie van bijdragen van derden en de interne processen voor het omgaan met open source vereisen meer dan alleen technische kennis.
Overeenstemming met auteursplicht en open source
Een bijzonder gevoelig gebied is de distributie van software die onderworpen is aan zogenaamde copyleft-licenties – vooral de GNU General Public Licence (GPL) en zijn varianten. Het basismechanisme is welbekend: Iedereen die software gebruikt, wijzigt en opnieuw distribueert, verplicht zich om ook de afgeleide werken toegankelijk te maken onder dezelfde licentie – en dus samen met de broncode.
Deze verplichting geldt niet alleen voor traditionele distributeurs van softwarepakketten, maar ook voor leveranciers van ingebedde systemen die Linux-componenten gebruiken of SaaS-aanbieders, zoals AGPL.
Hoe scherp het zwaard van de auteursplicht kan zijn, blijkt uit de jurisprudentie, bijvoorbeeld uit de zaken die u hebt behandeld over de handhaving van de GPL: als de licentie wordt geschonden, bijvoorbeeld omdat de broncode niet is opgenomen of verwijzingen naar de licentie ontbreken, dreigt niet alleen een waarschuwing, maar kan de licentie ook volledig verloren gaan. De gevolgen zijn ernstig: een onderdeel dat voorheen legaal werd gebruikt, wordt een inbreuk op het auteursrecht – met een kort geding en schadevergoeding.
Voor bedrijven betekent dit dat er betrouwbare interne processen nodig zijn die beginnen bij de selectie van OSS-componenten, de verplichtingen documenteren en consistent worden geïmplementeerd tijdens de levering of terbeschikkingstelling. Naleving van open source is geen juridisch vijgenblad, maar een kwestie van operationele uitmuntendheid – vooral voor klantprojecten, in de toeleveringsketen of als onderdeel van audits.
Redactie, co-auteurschap en vereffening van rechten
Een ander conflictgebied ontstaat wanneer software wordt gewijzigd of verder ontwikkeld. De vraag of een eenvoudige aanpassing een “afgeleid werk” of een onafhankelijke creatie is, is juridisch gezien zeker niet triviaal. De doorslaggevende factor is of een persoonlijke intellectuele creatie van de oorspronkelijke auteur blijft bestaan of wordt overgedrukt – een aspect dat in uw blog beknopt wordt behandeld aan de hand van uitspraken van onder andere het Europees Hof van Justitie en het Landgericht Düsseldorf.
Het wordt vooral lastig wanneer meerdere mensen samenwerken aan een project – bijvoorbeeld als onderdeel van een fork of in interne teams. In dergelijke gevallen kan er sprake zijn van co-auteurschap in de zin van artikel 8 UrhG. Dit leidt tot een hoofdelijke verplichting: geen enkele partij mag het werk vervreemden zonder toestemming van de anderen. Dit kan een blokkade worden voor bedrijven – bijvoorbeeld als een voormalige ontwikkelaar met terugwerkende kracht aanspraken maakt.
Co-auteurschap kan worden ingeperkt door duidelijke contractuele regels. Maar in de open source wereld, waar het werk vaak informeel is of gebaseerd op een gemeenschap, is er vaak een grijs gebied. Wie bijdragen uit de gemeenschap overneemt zonder de auteursrechtelijke status van de bijdrager te verduidelijken, loopt het risico juridisch kwetsbare software te verspreiden. Een Contributor Licence Agreement (CLA) die de overdracht van rechten duidelijk regelt is daarom aan te raden, vooral voor grotere projecten.
Dubbele licentie
Een speciaal juridisch geval is de zogenaamde dubbele licentie – d.w.z. de toewijzing van dezelfde software onder twee verschillende licentiemodellen. Klassiek bekend van MySQL, bijvoorbeeld, staat dit enerzijds vrij gebruik toe onder een open source licentie en anderzijds commerciële licenties onder andere voorwaarden.
Dit is over het algemeen mogelijk onder de Duitse wet, zoals blijkt uit de vakliteratuur en uw blogpost. De auteur blijft de baas over zijn rechten en kan ze op verschillende manieren aan verschillende licentiehouders verlenen. Maar let op: zodra er andere co-auteurs bij betrokken zijn, wordt het ingewikkeld. Elk van hen zou moeten instemmen met de commerciële licentie. Zelfs in het geval van gezamenlijke ontwikkeling door werknemers rijst de vraag of en in welke mate de overeenkomstige rechten zijn toegekend aan de werkgever.
Er bestaat ook een risico op verwarring bij de gebruikers. Als er bijvoorbeeld een open source versie in omloop is en er parallel een betaalde versie met uitgebreide mogelijkheden wordt aangeboden, kan dit bij onduidelijke communicatie tot misverstanden leiden – in het ergste geval zelfs tot ineffectieve licenties. Bedrijven moeten daarom bijzonder duidelijk maken onder welke voorwaarden welke licentie van toepassing is en welke verplichtingen in elk geval ontstaan.
Open source in de arbeidsrelatie
Veel ontwikkelaars zijn niet alleen beroepsmatig betrokken bij open source-projecten, maar ook privé. Hier komen arbeidsrecht en auteursrecht samen.
Als algemene regel geldt dat als software wordt gemaakt als onderdeel van de arbeidsrelatie, de werkgever regelmatig de gebruiksrechten verwerft. De beslissende factor is echter of het werk is gemaakt als onderdeel van de contractuele verplichtingen – of om privéredenen, bijvoorbeeld in het weekend of op eigen initiatief van de werknemer. De grenzen zijn hier vloeiend en zelfs een “privé”-project kan juridische relevantie hebben met betrekking tot mogelijke concurrentiebedingen of loyaliteitsverplichtingen.
Als bijvoorbeeld interne bedrijfscomponenten – bewust of onbewust – worden opgenomen in een open source project, kan dit leiden tot een openbaarmakingsverplichting die in strijd is met de bescherming van bedrijfsgeheimen. Omgekeerd kan een werknemer die open source code onder GPL in het bedrijf brengt, onbedoeld auteursplicht activeren zonder dat het management hiervan op de hoogte is. Een duidelijke catalogus van regels in het arbeidscontract, geflankeerd door intern beleid, creëert hier zekerheid. Dit omvat zowel de relatie tot het eigen OSS-gebruik als de samenwerking op externe projecten. Open source is teamwork – ook juridisch.
Wat vaak een kleine juridische kwestie lijkt, kan enorme juridische en economische gevolgen hebben als er niet zorgvuldig mee wordt omgegaan. Vooral in combinatie met de operationele realiteit – van de werkverdeling in agile ontwikkelteams tot contractuele relaties en de integratie van externe modules – ontstaat een complex veld waarin misverstanden snel een eigen leven kunnen gaan leiden.
Benut kansen, ken de risico’s
Open source software is een integraal onderdeel geworden van moderne softwareontwikkeling – en terecht. De juridische kwesties zijn beheersbaar als je ze serieus neemt. Het is cruciaal om op de hoogte te zijn van de juridische implicaties van licenties, de oorsprong van de code en de verplichtingen bij het doorgeven ervan. Bedrijven die hier proactief mee omgaan en duidelijke processen opstellen, profiteren niet alleen van meer rechtszekerheid, maar ook van het vertrouwen van klanten, partners en de gemeenschap.
Uiteindelijk is het simpel: open source software kan zijn potentieel alleen waarmaken op een juridisch conforme manier als er vanaf het begin rekening wordt gehouden met juridische kwesties. Juist op de raakvlakken tussen technologie, recht en organisatie – zoals copyleft, co-auteurschap of de arbeidsrelatie – liggen valkuilen op de loer die met een gedegen strategie kunnen worden vermeden. Bedrijven die open source serieus nemen moeten compliance niet zien als controle, maar als een voorwaarde om software duurzaam, coöperatief en innovatief te kunnen gebruiken.
Ons kantoor is gespecialiseerd in strafrechtelijke verdediging, witteboordenstrafrecht en IT-recht. Let op ons werk in kunstrecht, digitaal bewijs en softwarerecht.
Let op: Voor bedrijven zijn wij landelijk actief, voor consumenten uitsluitend in NRW voor strafverdediging + OWI's!
- Informeel bankieren onder juridische druk: Hawala-systemen en de complexe juridische beoordeling van strafbaarheid en vermogensontneming in Duitsland - maart 23, 2025
- Open source software in de Duitse wet - maart 23, 2025
- Tabaksaccijns en shisha-tabak in Duitsland: strafrechtelijke risico’s voor winkeliers en bars - maart 8, 2025
