Szabo: regulering of financiering open source communities niet opportuun
Het reguleren of financieren van open source communities is niet opportuun, zo stelt staatssecretaris Szabo voor Digitalisering. Twee jaar geleden hadden de ChristenUnie en VVD gevraagd of er een soort ondergrens kan worden gedefinieerd voor open source community's. "Want er is nergens gedefinieerd wat dan een goede community is of wat een goed functionerende community is, noch in omvang noch in kwaliteit", aldus Caspar van den Berg, die destijds senator namens de VVD was. Van den Berg reageerde tijdens een behandeling van de Wet digitale overheid in de Eerste Kamer. Daar werd gesproken over het toepassen van open source voor de ontwikkeling van overheidsinlogmiddelen.
"De vraag is al een paar keer gesteld en ook ik hecht eraan dat we voor onszelf definiëren wat een open source community op z'n minst zou moeten kunnen realiseren", reageerde toenmalig staatssecretaris Van Huffelen voor Digitalisering. Ze voegde toe dat het mogelijk is om een bijdrage aan deze gemeenschappen te leveren, maar de onafhankelijkheid ingewikkelder wordt als er van tevoren dingen worden geregeld.
"Als we geld geven, wil je misschien ook nog anderszins dingen geregeld hebben. Onze ervaringen tot nu toe zijn dat dat voldoende is. Maar goed, als wij zien dat er niemand meer meekijkt naar die broncodes, is er altijd nog de mogelijkheid dat je dat op de een of andere manier anderszins gaat stimuleren. Dan lijken dingen als bug bounty's interessanter dan daadwerkelijk zeggen: doe een analyse op dit of dat", ging Van Huffelen verder. Ze liet de Eerste Kamer weten de mogelijkheden tot regulering en financiering van open source communities te zullen onderzoeken.
"Niet opportuun"
"Ik ben tot de conclusie gekomen dat regulering of financiering van open source communities niet opportuun is", laat Szabo vandaag in een brief aan de Eerste Kamer weten (pdf). "Het belang van een open source community is dat een breed publiek kan meekijken op de broncode van software die openbaar is gemaakt. Dat biedt vertrouwen omdat onafhankelijke personen, dat wil zeggen personen die geen belang hebben bij de werking van de software, van buitenaf kunnen zien hoe software werkt."De open source communities waar de ChristenUnie en VVD het over hebben zijn volgens de staatssecretaris vrijwillig en niet strikt georganiseerd. "Zij zijn geen verantwoording schuldig aan wie dan ook, niet alleen juridisch maar ook niet financieel. Dat maakt hen breed toegankelijk en biedt hen onafhankelijkheid in hun functioneren. Te veel regelen en sturen in de wens naar zekerheid gaat ten koste van deze brede toegankelijkheid en de onafhankelijkheid, en schiet daarmee het doel voorbij."
Neem een voorbeeld aan het Duitse Sovereign Tech Fund https://www.sovereign.tech/. Daarmee worden juist in het algemeen belang open source projecten aangezet om dingen als accessibility etc te verbeteren. Op aanvraag van het project zelf dus geen enkel probleem met onafhankelijkheid.
Hetzelfde geldt overigens voor bedrijven die met alle liefde FOSS gebruiken maar er niets voor terugdoen in development capaciteit of geld.
Dat is natuurlijk een beetje kort door de bocht. Als er projecten telkens subsidie aanvragen voor verbeteringen gaan ze op een gegeven moment drijven op de subsidie. Dat zorgt er op zijn minst voor dat heel duidelijk in het achterhoofd zit dat je die organisatie (en dus de overheid) niet voor het hoofd moet stoten.
Belangrijke signalen die je daarin kunt zien zijn dingen als censuur/moderatie tools die een hogere prioriteit krijgen. Dat is veelal niet op basis van input van de community maar van de politiek. Al dan niet (zeer) indirect.
Om maar niet te spreken op welke partijen wel/geen subsidie krijgen: je kunt op die manier een mooie scheefgroei krijgen aan wel door de overheid gewenste stromingen en minder gewenste. Ik zou daar niet te licht over denken.
Dat is natuurlijk een beetje kort door de bocht. Als er projecten telkens subsidie aanvragen voor verbeteringen gaan ze op een gegeven moment drijven op de subsidie. Dat zorgt er op zijn minst voor dat heel duidelijk in het achterhoofd zit dat je die organisatie (en dus de overheid) niet voor het hoofd moet stoten.
Belangrijke signalen die je daarin kunt zien zijn dingen als censuur/moderatie tools die een hogere prioriteit krijgen. Dat is veelal niet op basis van input van de community maar van de politiek. Al dan niet (zeer) indirect.
Om maar niet te spreken op welke partijen wel/geen subsidie krijgen: je kunt op die manier een mooie scheefgroei krijgen aan wel door de overheid gewenste stromingen en minder gewenste. Ik zou daar niet te licht over denken.
Je krijgt dan ook snel van die Code of conduct onzin waar van die community managers meer te zeggen krijgen dan de techneuten die het hele project gebouwd hebben.
Neem een voorbeeld aan het Duitse Sovereign Tech Fund https://www.sovereign.tech/. Daarmee worden juist in het algemeen belang open source projecten aangezet om dingen als accessibility etc te verbeteren. Op aanvraag van het project zelf dus geen enkel probleem met onafhankelijkheid.
Hetzelfde geldt overigens voor bedrijven die met alle liefde FOSS gebruiken maar er niets voor terugdoen in development capaciteit of geld.
Op zich ben ik het met Szabo eens dat je niet moet financieren of reguleren. Maar wat een overheid wel heel goed zou kunnen doen, is actief bijdragen aan community's die zich bezighouden met producten die je als overheid gebruikt. Gebruik je bijvoorbeeld Apache, zorg dan dat je een paar ontwikkelaars hebt die een aantal uren in de week tijd krijgen om aan de Apache community bij te dragen.
Het mes snijdt dan aan twee kanten, de community heeft baat bij de inbreng en als overheid bouw je kennis in eigen huis op. Als er dan een keer een kritische kwetsbaarheid is of een complexe storing, heb je mensen in huis die dicht op de bal zitten.
Neem een voorbeeld aan het Duitse Sovereign Tech Fund https://www.sovereign.tech/. Daarmee worden juist in het algemeen belang open source projecten aangezet om dingen als accessibility etc te verbeteren. Op aanvraag van het project zelf dus geen enkel probleem met onafhankelijkheid.
Hetzelfde geldt overigens voor bedrijven die met alle liefde FOSS gebruiken maar er niets voor terugdoen in development capaciteit of geld.
Op zich ben ik het met Szabo eens dat je niet moet financieren of reguleren. Maar wat een overheid wel heel goed zou kunnen doen, is actief bijdragen aan community's die zich bezighouden met producten die je als overheid gebruikt. Gebruik je bijvoorbeeld Apache, zorg dan dat je een paar ontwikkelaars hebt die een aantal uren in de week tijd krijgen om aan de Apache community bij te dragen.
Het mes snijdt dan aan twee kanten, de community heeft baat bij de inbreng en als overheid bouw je kennis in eigen huis op. Als er dan een keer een kritische kwetsbaarheid is of een complexe storing, heb je mensen in huis die dicht op de bal zitten.
Dat inderdaad.
Het lastige voor overheid is dat ze "beleid" en "regels" willen/maken/nodig hebben voor wanneer ze dingen doen .
Want wie hebben er "recht" op die ondersteuning ?
De natte vinger van een ambtenaar - waarom ontaard dat niet in een gratis geld loket voor vriendjes van die ambtenaar ?
Een jan lul project (non binary diverse smart home AI 0.1 ? ) van een python klutser krijgt een tonnetje ?
En als ze Rust steunen, waarom niet ook Swift . En Ada . En Julia .
Ik zie ook het meest in het faciliteren dat eigen/interne ontwikkelingen/bugfixes rondom open source gedeeld (mogen) worden.
Laat dat belastinggeld gewoon maar bij zitten, dan verdeel ik het zelf wel over open source dingen die IK wil steunen.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?