Behördensoftware und Gesetzeszwang - warum die ELSTER frei sein muß.

[Bernhard Reiter]

Hallo Christian,

Am 24. Nov 2004 um 14:27:36 schrieb c.gatzemeier at web.de:
> vielleicht habt Ihr auch schon von den neuen Vorschriften gehört, dass 
> Umsatzsteuervoranmeldungs und Lohnsteuer Formulare ab 2005 nur noch 
> elektronisch beim Finanzamt eingereicht werden dürfen. (Artikel[1] auch auf 
> spiegel.de)

ja, davon hörten wir.
Die Situation klingt wirklich nicht schön und 
zeigt mal wieder den Aufklärungsbedarf.

> Die Spezifikation und Libs dazu sind aber nicht öffentlich und werden nur an 
> proprietäre Softwarehersteller herausgegeben.
> 
> Auf die Kommentare zum pro-linux.de Artikel hin hat sich nun anscheinend 
> jemand von elster.de gemeldet, und ich habe mich mal hingesetzt und versucht 
> eine Anfrage zu tippen.

Das ist ja prima!
Genau das müsste noch mehr Leute machen.

> Hier der argumentative Teil, vielleicht sieht jemand noch Schwächen oder weiß 
> noch etwas:

Ich versuche etwas Rückmeldung zu geben:

> -------------------------
> Wie wird verhindert das Datenverarbeitungseinrichtungen in Abhängigkeit 
> einzelner Unterhnehmen, Gruppen etc. kommen, sowie Sicherheit und Transparenz 
  Tippfehler: Unternehmen

> gewähleistet sind?

> Bisher wurde selbst bei dem *nach außen hin wirksamen Teil* des, aus 
> öffentlicher Hand bezahlten, ELSTER Projektes nicht deutlich, dass es sich an 
> die folgenden Grundlagen für eingesetzte Datenverarbeitungs- Anlagen und 
> Programme halten würde. 

Es ist richtig zu erwähnen, dass um die Aussenwirkung geht,
vielleicht ist es ja besser, als wir denken.


>    - Gegebenenfalls neu erstellte (auch im Auftrag) Spezifikationen
>       offengelegt werden.
> 
>    - Die Referenzimplementation von Spezifikationen, z.B. Bibliotheken, 
>       aber auch andere öffentlich finanzierte Programme als
>       freie Software veröffentlicht werden. 

Strategisch gesehen würde ich diese beiden Teile trennen 
und erstmal auf die Spezifikation eingehen.

Ich stimme natürlich bei der Referenzimplementation völlig zu.
(Bei der FSFE schreiben wir mittlerweile übrigens "Freie Software"
mit großem "F", um es als eigenständiges Konzept zu markieren
und keinen Nachteil gegenüber dem "Open Source" zu haben,
was ja als Englischer Begriff immer groß geschriebern wird.)

> a) damit durch öffenliche Gelder nicht Lizenzansprüche für Einzelne aufgebaut 
> oder gefördert werden. 

Teilweise ist jedoch gewünscht, dass mit öffentlichen Geldern geschaffene
Produkte vermarktet werden. Das hat durchaus einen Kern mit Sinn,
weil die Motivation eines Unternehmens ganz anders ist, die Früchte
auch zu ernten und von erfolgreichen Unternehmen leben wir.

Insofern müssten hier mehr Argumente kommen und dass könnte für die
Anfrage zuviel werden.

> b) damit die Erstelllung der Programme keine Subvention für Einzelne 
> darstellt. Eine öffentlich finanzierte Leistung also nicht einfach 
> privatisiert werden kann, ist eine sogenannte "Copyleft Lizenz" nötig. 

Meiner Ansicht nach wäre Freie Software ohne starken Schutz der
Freiheit hier schon ein enormer Fortschritt.
Die USA machen das ürigens bei Bundesmitteln oft so und das läßt
sich gut als Beispiel anführen. Die Public Domain Verfügbarkeit 
hat sicher zur Softwarevorhersschaft der USA geführt.

> c) weil Transparenz- und Sicherheitsansprüche gebieten, dass die Überprüfung 
> und Einsicht in die Programme stets möglich ist. Sicherheitsprobleme und 
> Fehlfunktionen dürfen nicht verschleiert werden. Die Art und Weise mit der 
> auf Datenstöme zugegriffen wird und wie diese verarbeitet werden muß 
> allgemein überprüfbar bleiben.

Das wird schnell ausgehebelt mit den Argumenten:
	- Wer macht das schon?
	- Wer kann das dann?

In der Tat ist es richtig, dass Freiheit der Software die Chancen
für sichere Software erhöht; es ist aber keine Garantie.
Vielleicht läßt sich hier mit der Pflege und dem Wettbewerb darum
mehr Einsicht erreichen.

> Im Vordergrund steht hier vor allem die Vertrauenswürdigkeit also die 
> Sicherheit und Transparenz bei der Verarbeitung der Datenströme.

Sehe ich hier ähnlich, dass die Sicherheit kein starkes Argument ist;
Kosten und lokale Wirtschaftförderung aber schon.

> Hier liegt es im Interesse sowohl der Behörde wie der Bürger (unabhängig) 
> untersuchen (lassen) zu können wie die Anlagen und Programme arbeiten. Zur 
> Ausübung Ihrer Aufgaben muß die Behörde außerdem die Kontrolle über Ihre 
> Anlage wahren können. Auch dieses ist nur beim Einsatz freier Software 
> gewährleistet.

Gewährleistet nicht, aber leichter möglich.
Dazu sollten sich dei Behörden aber auch Fachleute leisten,
was auch mit Freier Software leicher möglich ist.

> Die zum Datenaustausch mit dem Finanzamt nötigen Bibliotheken werden an 
> Softwarehersteller kostenlos abgegeben aber nicht allgemein veröffentlicht. 
> Die Bibliotheken sind in plattformunabhängiger Quelltext-Form vorhanden. 

Angeblich, oder?
Die Java-Falle ist weit offen...
Vielleicht sollte hier auch mit Wettberb argumentiert werden:
Wenn eine Plattform vorgeschrieben wird, greift das praktisch in den
Wettbewerb der Geschäftsmodelle ein. 

> Laut Erfahrungen von Autoren freier Software wurde Ihnen der
> Zugang sowohl zu den Softwarebibliotheken als auch zu den
> Spezifikationen mit Hinweis auf Lizenzbedingungen jedoch verwehrt.

Was wirklich seltsam ist, weil da doch auch Softwarehersteller drunter sind.

> Und dieses obwohl es scheint als ob die Aufgabe der
> elektronischen, signierten und verschlüsselten Formulareinreichung
> schon von Standardverfahren z.B. für den verschlüsselten e-mail
> Verkehr abgedeckt wird. 

Das wird wahrscheinlich nicht reichen, da ein ja sicher automatisch
übernommern werden soll.

> Plausibilitätsprüfungen 
> auf der Client Seite mögen aus verschiedenen Gründen Sinn machen, und auch 
> gewünscht sein. Hier würde es reichen die Plausibilitätspüfungen in die 
> Spezifikation mit aufzunehmen. Aus Sicherheitsgründen ist eine Prüfung auf 
> der Server Seite allerdings aber nie vermeidbar.

Du bezieht Dich bestimmt auf:
	https://www.elster.de/ssl/elfo/main-anw-form-faq-01-lk-lin.htm
	  Warum keine Entwicklung eines Frontends in JavaScript,
	  PHP, Html etc. ?

	Die Entwicklung von Frontends in XML/HTML etc. mag momentan sehr IN
	sein, für die Erstellung von so komplexen Anwendungen wie ein
	Steuerprogramm mit all seinen Plausibilitätsprüfungen und
	Eingabevarianten ist diese Art der Oberflächenerstellung unseres
	Erachtens nicht geeignet. Zumindest war es zu Beginn der Entwicklung
	von ElsterFormular keine tragbare Alternative.

Das läßt tatsächlich den Verdacht aufkommen, der Klient müßte
wirklich Prüfungen vornehmen, denen später geglaubt würde.
Wäre das so, dann wäre es wirklich ein schlechtes Design.

	Bernhard
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20041126/03cdcaee/attachment.sig>