-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Person - Datenschutz #43
Comments
Siehe auch #25 (comment) |
Zu personenbezogenen Daten: Ich denke, es sollte sehr wohl reichen, wenn man die Ausgabe von Privatadressen von Gremienmitgliedern optional macht. So wäre es Sache des RIS-Betreibers, ob derartige Daten über die API zu bekommen sind oder nicht. Wir streben mit dem aktuellen Standard-Entwurf die lokale Ebene an. Andere Ebenen müssen wir meiner Meinung nach nicht betrachten. Zum Urheberrecht: Dies betrifft genau genommen nicht den Objekttyp "Drucksache", sondern "Dokument". Wie @akuckartz schreibt, gibt es das Issue #25, um diesbezügliche Fragen zu diskutieren. |
Es wäre sicher möglich, Pflichtfelder als - rechtskonform - und optionale Felder als - rechtlich ungeklärt - zu definieren, dies dürfte von den OParl Anwendern nur nicht in diesem Kontext interpretiert werden. Um das Risiko der Datenschutzrechtsverletzung für Dritte möglichst gering zu halten, auch im Interesse des Vertrauens gegenüber der OParl-Schnittstelle, müsste man die verschiedenen Attribute des Objektes - Person -zusätzlich in: zur ÖFFENTLICHEN oder INTERNEN Verwendung klassifizieren. Probleme entstehen nur bei der öffentlichen Nutzung der Daten durch Dritte. Für eine interne Verwendung können die veröffentlichten RIS-Daten aber auch sehr interessant sein:
Eine interne und externe Verwendung von OParl, würde die Reputation der Schnittstelle zusätzlich eher noch stärken. Ich glaube es könnte vielleicht hilfreich sein, bei den Rechtsfragen noch einmal zu skypen. Vielleicht auch zusammen mit Alexander (OD-Beirat-Bonn), der sich als Datenschutzbeauftrager mit einem Gutachten für BoRIS beschäftigt. |
Die Limitierung des Umfangs der API sollten durch den Datenschutz (betrifft Objekt: Person, Tagesordnung, Drucksache) und das Urheberrecht (betrifft: Objekt: Drucksache) definiert sein.
Das Objekt - Person - könnte folgende datenschutzrechtliche Überlegungen berühren:
Die Veröffentlichung der Adresse und Tel. des Büros eines Landtagsabgeordneten ist nicht gleich zu setzen mit den privaten Adressangaben eines Nicht-Berufspolitikers auf der kommunalen Ebene, auch wenn beide Adressen im PIS bzw. RIS aufgeführt sind.
Für die API sollte man sehr vorsichtig mit dem Thema Datenschutz umgehen, da der API-Erfolg entscheidend von der Zustimmung der Räte abhängt, die definierte Schnittstelle auch mit Daten bedienen zu wollen. Eine öffentliche Diskussion über die mangelnde datenschutzrechtliche Zuverlässigkeit der Schnittstelle dürfte ihren Erfolg sehr in Frage stellen. Eine datenschutzrechtliche Zertifizierung wäre hier sicher hilfreich.
Da die Daten zwar öffentlich über das RIS zur Verfügung stehen, aber eine Verwendung durch Dritte sich daraus nicht automatisch ableiten lässt, würde bei den datenschutzrechtlich und urheberrechtlich relevanten Objekten auch eine Beschreibung, nur zur - internen Verwendung - benötig. Diese könnten für interne Apps-Schnittstellen genutzt werden, für statistische Auswertungen oder auch nach Klärung der Rechtslage freigeschaltet werden.
Abgeordnetenwatch hat bezüglich des datenschutzrechtlichen Rahmens zur Veröffentlichung von personenbezogenen Daten für die Landesebene NRW ein Gutachten erstellen lassen:
http://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument?Id=MMI15/49
Zurzeit befindet sich ein weiteres Gutachten für die kommunale Ebene in Arbeit, das aber wahrscheinlich nicht bis zum 30.6. zur Verfügung stehen wird.
The text was updated successfully, but these errors were encountered: