Stap 8: Regel intellectueel eigendom
Bij open source samenwerking is helder wie eigenaar is van de code en onder welke voorwaarden deze gebruikt mag worden. Dit voorkomt juridische problemen en stimuleert bijdragen.
Intellectueel eigendom (IE) gaat over drie vragen: wie is eigenaar, wat mag iedereen ermee, en wat gebeurt er met bijdragen van anderen?
1. Eigendom van de code
Vaak wordt bij open source ten onrechte gedacht dat er geen sprake is van Intelectueel Eigendom. Dit is er wel degelijk en het is belangrijk om bij de ontwikkeling van open source software na te denken waar dit ligt. Hieronder zijn twee modellen geschetst wie juridisch eigenaar is van de code:
Model A - Gemeenschappelijk eigendom
Hoe werkt het:
Alle deelnemende gemeenten zijn gezamenlijk eigenaar. Niemand kan individueel over de code beschikken.
Voordelen:
- Gelijkwaardigheid tussen gemeenten
- Continuïteit los van individuele gemeenten
- Niemand kan eenzijdig beslissen
- Past bij samenwerkingsgedachte
Nadelen:
- Juridisch complex bij uittreding gemeente
- Wat als één gemeente bezwaar maakt tegen iets?
Geschikt voor: Kleine groepen (2-8 gemeenten) met hoge mate van vertrouwen
Model B - Eén gemeente als eigenaar
Hoe werkt het:
Eén gemeente (vaak de initiatiefnemer) blijft juridisch eigenaar. Andere gemeenten krijgen gebruiksrecht via de open source licentie.
Voordelen:
- Juridisch eenvoudig
- Duidelijk aanspreekpunt naar buiten
- Eigenaar kan snel beslissen
Nadelen:
- Ongelijkheid tussen gemeenten
- Andere gemeenten afhankelijk van eigenaar
- Eigenaar draagt juridische verantwoordelijkheid
Let op:
Leg in de samenwerkingsovereenkomst vast dat de eigenaar niet eenzijdig de licentie kan wijzigen en dat andere gemeenten invloed hebben op de richting.
Geschikt voor: Lichte coördinatie waarbij één gemeente duidelijk trekker is
Model C - Onafhankelijke partij (bijvoorbeeld stichting)
Hoe werkt het:
Een onafhankelijke rechtspersoon (bijvoorbeeld een stichting) wordt juridisch eigenaar van de code. Deelnemende gemeenten hebben zeggenschap via het bestuur van deze organisatie.
Voordelen:
- Neutrale eigenaar zonder eigen belang
- Continuïteit los van individuele gemeenten
- Professionele governance structuur mogelijk
- Duidelijk extern aanspreekpunt
Nadelen:
- Extra juridische en bestuurlijke lasten (statuten, bestuur, AVG-verantwoordelijkheid)
- Oprichtingskosten en jaarlijkse administratie
- Risico van vervreemding tussen stichting en gemeenten
Let op:
Leg in de statuten vast hoe gemeenten zeggenschap hebben (bijvoorbeeld: elk bestuurslid vertegenwoordigt X gemeenten). Bepaal ook wat er gebeurt bij ontbinding van de stichting met het eigendom van de code. Zorg dat de stichting geen winstoogmerk heeft (ANBI-status kan fiscaal voordelig zijn).
Geschikt voor: Grote groepen gemeenten, strategisch belangrijk product waar lange termijn continuïteit essentieel is, of wanneer meerdere producten onder één gezamenlijke externe constructie worden gebracht.
2. Open source licentie
Ongeacht wie eigenaar is: de code wordt gepubliceerd onder een open source licentie. Die licentie bepaalt wat iedereen (binnen en buiten de samenwerking) met de code mag doen.
De keuze van licentie wordt uitgebreid behandeld in Stap 9. Voor intellectueel eigendom is het belangrijkste:
- De licentie geeft iedereen recht om de code te gebruiken, kopiëren en aanpassen
- Ook als een gemeente uitstapt, mag ze de code blijven gebruiken (via de licentie)
- De licentie is onherroepelijk: je kunt hem niet meer intrekken
3. Bijdragen van gemeenten en leveranciers
Wanneer gemeenten of leveranciers code bijdragen, moet helder zijn dat deze bijdragen onder dezelfde licentie vallen. Dit regelen jullie met een Contributor License Agreement (CLA).
Wat is een CLA?
Een CLA is een korte verklaring waarin de bijdrager bevestigt dat:
- Ze het recht hebben om de code bij te dragen (het is hun eigen werk of ze hebben toestemming)
- De bijdrage onder de gekozen open source licentie valt
- De bijdrage geen inbreuk maakt op rechten van derden
Twee varianten
Developer Certificate of Origin (DCO):
Lichtgewicht variant. Developer tekent digitaal (via ‘Signed-off-by’ in commit message) dat bijdrage aan voorwaarden voldoet. Simpel en gebruikelijk bij open source projecten.
Formele CLA:
Uitgebreider document dat apart getekend wordt. Biedt meer juridische zekerheid maar is bewerkelijker. Vooral relevant bij commerciële partijen of strategische software.
Aanbeveling: Voor gemeentelijke samenwerkingen is DCO meestal voldoende. Gebruik alleen formele CLA als juristen daar sterk op aandringen.
Bijdragen van leveranciers
Wanneer jullie leveranciers inhuren voor doorontwikkeling, neem dan expliciet op in het contract:
- Alle door leverancier ontwikkelde code wordt eigendom van [gemeente/stichting/gemeenschappelijk]
- Code wordt gepubliceerd onder [gekozen open source licentie]
- Leverancier garandeert dat code geen inbreuk maakt op rechten van derden
- Leverancier mag code niet voor commerciële doeleinden hergebruiken (tenzij je dat wél wilt)
Praktische tips
Kies eigendomsmodel passend bij ambitie
Kleine groep, informeel → Één gemeente eigenaar. Gestructureerd, professioneel → Gemeenschappelijk of stichting.
Licentie is belangrijker dan eigendom
Door open source licentie kan iedereen de code gebruiken, ongeacht wie eigenaar is. Focus op goede licentiekeuze.
Leg het vast, maar maak het niet complex
Een paragraaf in de samenwerkingsovereenkomst over IE is voldoende. Verwijs naar de gekozen licentie voor details.
Check contracten met leveranciers
Veel standaardcontracten geven leverancier auteursrecht. Pas dit expliciet aan voor open source ontwikkeling.
Tip: Vraag juridische afdeling niet om het perfecte IE-model te bedenken, maar presenteer één van de drie modellen en vraag hen dat uit te werken. Dat voorkomt eindeloze juridische discussies.