Make "publiccode" required and always show the field.

[floort]

In line with the position paper from the College voor de Rechten van de Mens: Make is visible when transparency about the detailed logic behind the algorithm isn't available. And because intellectual property may not be an obstacle to this transparency I suggest making this field required as well. Under exceptional circumstances this linkt could also link to a resource that's (partially) redacted.

[jaspervanderheide]

Ha,

Een volledig inhoudelijk laat even op zich wachten tot we aan volgende versie van standaard werken. Ik zou wel willen voorstellen om de uitleg in een apart veld te stoppen. Misschien een algemeen veld "transparantiebeperkingen"? Dan geldt dat veld meer in algemeenheid voor redenen. Dit hebben we ook gedaan bij impacttoetsen. Daardoor kan op het veld publiccode een controle plaatsvinden dat het een url is, wat hopelijk de kwaliteit ten goede komt.

Of het veld uiteindelijk verplicht moet worden, kom ik op terug, maar ben benieuwd naar verschillende zienswijzen. Ik zou wel willen voorstellen om het voorlopig in te stellen als altijd zichtbaar, in plaats van verplicht. Omdat er nu geen wettelijke verplichting geldt, vormt dat wellicht een belemmering voor het invullen. Het technisch verplichten is - voor mij - vooral van toepassing op velden die ofwel de functionaliteit van de website beperken als ze ontbreken of die behoren tot het minimaalste (dus zonder die velden had je net zo goed niet kunnen registreren). We willen natuurlijk de kwaliteit van de registraties zoveel mogelijk verhogen, maar tegelijkertijd ook gewoon zorgen dat organisaties beginnen met aanleveren, ook al is het niet altijd compleet (dat is natuurlijk niet het einddoel).

[floort]

Misschien interpreteren we het anders, maar betekent een verplicht veld dat er broncode transparant moet zijn of dat er verplicht aangegeven moet worden of er transparante broncode is? Ik ging uit van het laatste. Ik wil dat je bij registraties die het niet hebben veilig kan concluderen dat ze het niet hebben en dat niet invullen niet ambigu is.

[jaspervanderheide]

Verplicht in die context betekent dat je niet kan aanleveren zonder dat het veld is ingevuld. Dus geen van beide.

Uiteindelijk is het uitgangspunt wel dat als daar geen url ingevuld is, dat er dan ook geen url beschikbaar is. Maar dat lijkt me niet op een wijze afdwingbaar?

[floort]

Een alternatieve suggestie: een boolean "Publieke broncode beschikbaar" en een tekstveld met "URL waar de broncode beschik is, of uitleg van de gronden waarom deze niet beschikbaar gesteld kan worden". Of vergelijkbaar, maar dan uitgesplitst in 3 velden. Zo is het niet beschikbaar zijn en niet volledig invullen niet meer ambigu én kunnen bestuursorganen die broncode niet beschikbaar stellen zonder een reden te geven makkelijk aangesproken worden.

Zoals ik het nu lees wordt het huidige veld al onjuist gebruikt om uitleg te geven dat de broncode niet beschikbaar is. Dat was waarom ik er niet vanuit ging dat niet invullen bij het niet beschikbaar zijn van broncode onmogelijk zou zijn.

[jaspervanderheide]

Er wordt nog gewerkt aan het afdwingen van een url, daar heb je gelijk in.

Ik snap je redenering, maar ik zou bij niet invullen uitgaan van het niet bestaan. En dus daar om vragen. Dat lijkt me efficienter dan de tussenstap van het derde veld. Uiteindelijk wil je immers dat de standaard zo volledig mogslijk ingevuld wordt.

[floort]

Het kan mogelijk Woo-verzoeken schelen als er proactief wordt aangegeven wat de weigeringsgronden zullen zijn. Als ik de position paper van het College voor de Rechten van de Mens goed begrijp zou niet beschikbaar stellen bijna een uitzonderlijke situatie mogen zijn. De meeste algoritmes zouden een dergelijke uitleg dus niet nodig moeten hebben. En degenen die weigeren zouden al goed nagedacht moeten hebben over de redenen om dat niet te doen en de compenserende waarborgen waardoor het ook relatief makkelijk zou moeten zijn om het in te vullen. En niet openbaar maken zonder uitleg mag best opvallen in het register denk ik.

[floort]

Ik heb broncode opgevraagd bij de KVK; Die link werkt niet, wordt aan gewerkt. Maar ook bij Omgevingsdienst Midden-Holland; Datamask is een closed source tool en de link naar de productpagina zal worden verwijderd. Van de 201 registraties blijft zo misschien alleen de KVK over. Dat is minder dan 0.5% van de registraties met beschikbare broncode.

Ik denk dat het waardevol is dat het register de omvang van dit probleem duidelijk maakt, maar misschien is het ook goed om te kijken of in de presentatie van de registraties wat context wordt meegegeven. Is er ruimte in het register om betrokkenen standaard uitleg te geven bij velden zoals hier bij de broncode verwijzen naar het advies van het College en advies over wat ze kunnen doen om alsnog de risico's en rechtmatigheid te beoordelen?

[jaspervanderheide]

Die ruimte is wat mij betreft een goed idee. Het ging mij meer om de vorm. Ik neem dit voorstel mee naar de discussie voor een volgende wijziging, maar weet nog niet wanneer deze zal zijn.

Misschien nog een kleine kanttekening, niet alle algoritmes leiden uiteindelijk tot een besluit. Dus daar is het position paper niet direct op van toepassing. En er is volgens mij nog wel wat discussie over hoe ver het motiveringsbeginsel in Awb gaat, maar dat is niet mijn kennisgebied. Een veld over de mate van transparantie zou natuurlijk hoe dan ook kunnen.

[floort]

Voor algoritmes die geen significante onderdelen van besluiten nemen heb je een goede uitleg voor het geven van minder transparantie. Maar ik denk niet dat dat een goede reden is om bij alle algoritmes minder duidelijk te zijn over de transparantie. Ik begrijp dat het register wel primair is bedoeld voor algoritmes die besluiten nemen en dat met enige goede wil, als de KVK de link repareert, er net wat minder dan 0.5% publieke broncode heeft. Ik denk dat het voor transparantie over dat contrast niet productief is om de uitzonderingen van het register als uitgangspunt in het ontwerp mee te nemen.

Is er ruimte om terugkoppeling te geven over de overwegingen om dit punt wel of niet mee te wegen? Of misschien om de discussie hier of op pleio te voeren zodat inzichtelijk is waarom bepaalde keuzes worden gemaakt.