Er zit een misvatting in de Kamerbrief “Open, tenzij”. De beleidsbrief veronderstelt dat open source software zou verplichten tot openbare publicatie en dus niet samen kan gaan met een vertrouwelijke werkwijze – zoals bij opsporing en toezicht. Dat klopt natuurlijk niet. Hoe zit het wel? Over het “tenzij” in “Open, tenzij”.
Open source licenties komen grosso modo in twee smaken | Beeld: Shutterstock
Er zijn vele redenen voor de overheid om open source software te gebruiken. Een aantal van die redenen hangt samen met de open werkwijze die open source licenties mogelijk maken. Van de praktijk waarbij organisaties openbaar code delen op platformen als Github of Gitlab zullen velen ten minste hebben gehoord. Dat maakt dat we open source software associëren met transparantie, publieke beschikbaarheid en vertrouwen. Ook de drempelloze samenwerking over organisatiegrenzen heen, dat de gestandaardiseerde open source licenties mogelijk maken, kennen we inmiddels uit de praktijk. En ook dat associëren we met toegankelijkheid voor iedereen. Dit zijn zonder meer praktijken die open source licenties mogelijk maken en waarmee in een publieke context ook belangrijke publieke waarden gerealiseerd kunnen worden.
De veronderstelling dat openbare publicatie verplicht is, is onjuist. Dit moet nooit.
De Kamerbrief echter veronderstelt dat dit moet en spreekt over “de benodigde vertrouwelijke werkwijze van de overheid, denk aan opsporing en toezicht” als mogelijke grond om geen open source software te gebruiken. Maar de veronderstelling dat openbare publicatie verplicht is, is onjuist. Dit moet nooit.
Hieronder een beknopt overzicht met een wat scherper onderscheid tussen wat open source licenties mogelijk maken, wat ze vereisen en wat vertrouwelijk kan met eigen personeel, ingehuurd personeel en externe partijen. Met een paar verrassende conclusies op het eind.
Licenties in twee smaken
Alle open source licenties geven een viertal rechten; het recht om de software te gebruiken, te begrijpen, te wijzigen en te verspreiden. Toch komen open source licenties grosso modo in twee smaken. De ene groep licenties biedt gebruikers de mogelijkheid om zonder nadere eisen de software te gebruiken of aan te passen. Dit is wat bijvoorbeeld Apple doet met haar besturingssystemen iOS en MacOS: hierin zit open source onder de zogeheten BSD licentie, die toestaat om met uitsluitend een verzoek tot naamsvermelding de software opnieuw uit te brengen, zelfs onder een gesloten licentie. Daarom noemen we deze groep licenties ook wel ‘toegeeflijke licenties’. Daarnaast is er een groep licenties die vereist dat als je de software aan een ander geeft, deze dezelfde rechten krijgt. Als je de software verspreidt moet de ontvanger toegang krijgen tot de broncode, zodat hij of zij ook weer wijzigingen kan aanbrengen en de software mag verspreiden. Deze licenties noemen we ook wel ‘beschermende’ licenties, omdat de software open moet blijven. Geen enkele licentie echter verplicht tot openbare publicatie.
Tussen geen plicht tot openbaarheid en de eis van vertrouwelijkheid
Uiteraard kan er een hele wereld zitten tussen geen verplichting hebben om iets openbaar te maken en de zekerheid van vertrouwelijkheid. Daarom is het goed om even naar de details te kijken. Toegeeflijke licenties zijn evident geen belemmering voor een vertrouwelijke werkwijze. Als je daaraan een stuk code toevoegt dat vertrouwelijk moet blijven, mag je die zelfs delen met andere overheden onder een andere licentie – open of gesloten – of met een geheimhoudingsovereenkomst ernaast.
Wanneer openbaarheid niet in het belang is van deze organisaties, staat niets vertrouwelijkheid in de weg.
Bij beschermende licenties is dit iets subtieler. Ook daar is er geen belemmering voor overheden, zeg de Belastingdienst, om een stuk open source software aan te passen en dit vertrouwelijk te houden. Er is namelijk niets dat je verplicht om aangepaste software te distribueren. Dus wanneer dit niet in je belang is als overheid, is er niets dat je daartoe verplicht. Mocht je de software overdragen aan een derde buiten de eigen organisatie, dan krijgt diegene dezelfde rechten op de software en dus ook het recht om de software openbaar te publiceren. De ontvangende organisatie is dat echter niet verplicht. Dus wanneer openbaarheid niet in het belang is van deze organisaties, staat niets vertrouwelijkheid in de weg. Maar geen belang hebben is wellicht nog iets anders dan vertrouwelijkheid afspreken.
Eigen werknemers en externe bedrijven
Als organisaties alleen met eigen of gedetacheerde medewerkers wijzigingen aanbrengen in software onder een beschermende licentie, kunnen zij vertrouwelijkheid vereisen. Dat komt omdat werknemers in een gezagsverhouding staan. En dus kan een organisatie vereisen dat ze in het algemeen geen zaken naar buiten mogen brengen zonder toestemming. De licentieovereenkomst die de organisatie aangaat en de arbeidsovereenkomst met de werknemer staan los van elkaar. Dat wordt anders wanneer een organisatie de code aan een externe ontwikkelaar geeft. Zij krijgen daarmee het recht om die code te verspreiden. Een geheimhoudingsovereenkomst naast een beschermende open source licentie is niet toegestaan, want met het aangaan de softwarelicentie ben je juist akkoord gegaan om ieder aan wie je de software overdraagt dezelfde rechten te geven als je zelf hebt ontvangen. Dus ook als de organisatie de code alleen intern wil inzetten, is het geen optie om daaraan met externe bedrijven te werken. Daarmee gaan dus tevens andere gemakken van open source software verloren, zoals samenwerken zonder drempels.
Samenwerkingen van overheden
Wanneer het gaat om fraudebestrijding, werken overheden veelal in samenwerkingsverbanden aan software en doorgaans met betrokkenheid van private partijen. Zo’n samenwerkingsverband mag niet onderling afspreken – op welke wijze dan ook – software vertrouwelijk te houden wanneer zij gemodificeerde open source software delen onder een beschermende licentie. Al kan andersom uiteraard alleen de wetgever deze organisaties verplichten om de software publiek te maken.
Verantwoording
Bij vertrouwelijkheid hoort in publieke organisaties altijd verantwoording. Dat het hier om software gaat, maakt dat niet anders. En al is transparantie ook een waarde in zichzelf, transparantie is geen noodzakelijke en ook geen voldoende voorwaarde voor verantwoording. Open source software kan hoogstens allerlei systemen van verantwoording mogelijk maken en makkelijk maken. Als een organisatie software vertrouwelijk wil houden, zoals in het kader van opsporing en toezicht, dan hoort daar altijd de vraag bij hoe daarover dan verantwoording wordt afgelegd. Want dat vertrouwelijke software onafhankelijke controle behoeft, misschien wel juist in opsporing en toezicht, is de afgelopen jaren wel zeer duidelijk geworden.
Dit alles leidt tot een paar interessante conclusies. Enerzijds dat er voor individuele organisaties geen enkele belemmering is om code vertrouwelijk te houden, wanneer zij “sourcen” of met eigen mensen werken. Maar anderzijds ook dat als zij met externe partijen werken aan code die vertrouwelijk moet blijven of samenwerken met andere overheden, zij geen geheimhoudingsovereenkomst mogen sluiten, ofwel geen open source software mogen gebruiken onder een beschermende licentie. Dat laatste zou wel eens lastiger kunnen zijn dan lijkt. En tenslotte dat een “tenzij”, in “Open, tenzij”, altijd gepaard moet gaan met een duidelijk antwoord op de vraag naar verantwoording. Het is een extra motief om vertrouwelijkheid te beperken tot alleen wat echt vertrouwelijk moet blijven.
Arjan Widlak is directeur van Stichting Kafkabrigade en publiceert op het snijvlak van technologie en publieke waarden.
Arnoud Engelfriet is ICT-jurist en publiceert al decennia over open source software en recht.
Nog afgezien van de, in dit artikel, uitstekend benoemde argumenten zie ik nog een ander probleem. Wanneer kamerleden en veel anderen spreken over Open Source dan gebeurt dit altijd in terminologie van “gebruiken”. Nergens hoor ik de essentie van de Open Source gedachte, namelijk die van “bijdragen”.
OS Software wordt gemaakt en verbeterd door contributors, mensen van vlees en bloed met kinderen, een hypotheek en hobbies die hun ziel en zalgheid (en heel veel tijd) stoppen in de ontwikkeling van software waar de rest van de wereld iets aan heeft. Maar ook mensen die van hun werkgevers de tijd krijgen om een bijdrage te leveren aan OS projecten. De voordelen zijn evident, je wordt gezien als volwaardig lid van een “community”, je hoort als eerste van zero-day exploits en je kunt “meesturen” met de ontwikkeling.
OS wordt door de overheid nog te vaak gezien als “free beer”, iets wat je simpelweg kunt gebruiken zonder iets terug te hoeven doen. Een echte Open Source strategie houdt in dat ook de overheid tijd en geld vrijmaakt om een bijdrage te leveren aan zo iets moois als Open Source. Dan geef je ook nog eens invulling aan die “transparatie” waar zo vaak over gesproken wordt, want ook daarvan vindt 99,999% van de OS gebruikers dat “iemand anders” die code wel zal controleren op eventuele rare back-doors oid.
Met interesse dit artikel gelezen.
De kamerbrief gaat m.i. echter niet over het gebruik van open source binnen de overheid. Daarvoor is immers al bestaand NOiV beleid (gebruik van open source bij gelijke geschiktheid). Deze brief gaat uitsluitend over het hergebruik en publiceren van broncode waarvan de overheid zelf al de auteursrechthebbende is. Broncode die tot nu toe gesloten was, moet volgens de brief wel degelijk zo veel mogelijk actief openbaar worden gemaakt, en dus gepubliceerd. Tenzij er inderdaad redenen zijn om dat laatste niet te doen. Bijvoorbeeld omdat de gesloten software gebruikt wordt bij opsporing en toezicht, en je niet wilt dat de buitenwereld achter de beslisregels van de software komt. Terecht verwijst de brief ook voor dit soort uitzonderingen naar de WOB. Diezelfde Wob kan overigens ook verplichten tot openbaarmaken!
Ik deel de conclusie in het stuk dat je altijd goed moet nadenken over wat te doen indien je software besloten wilt doorontwikkelen terwijl er al open source licenties op de software van toepassing zijn. Daarbij is natuurlijk ook relevant of jij als enige de auteursrechthebbende (nog) bent. Als ik als overheid mijn eigen software wil gaan (door)ontwikkelen in een besloten samenwerkingsverband (en daar zijn natuurlijk tal van voorbeelden van) dan zal ik die beschikbaarstelling aan de deelnemers vanwege de beoogde vertrouwelijkheid niet gaan doen onder een open source licentie, maar juist onder een samenwerkingsovereenkomst inclusief geheimhoudingsbeding. Uiteraard kan ik daarbij ook afspraken maken over een toekomstige licentiekeuze, over het inschakelen van externe partijen voor de doorontwikkeling, of over wat te doen indien een van de deelnemers een stuk software met een beschermende licentie wil inbrengen waarop derden al de auteursrechten hebben.
Ik mis bovenstaande nuance in het artikel.