Geheime open source software


Er zit een misvatting in de Kamerbrief over ‘Open, tenzij’, stellen Arjan Widlak en Arnoud Engelfriet. 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’.  

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 Kamerbrief veronderstelt echter 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.

‘Geen enkele licentie verplicht tot openbare publicatie’

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.

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.

‘Er is niets dat je verplicht om aangepaste software te distribueren’

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 van 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 op 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.

Vond je dit artikel interessant? Lees alle artikelen van: Arjan Widlak Arnoud Engelfriet
Deel dit artikel

Er zijn nog geen reacties op dit artikel

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

*