Elster (war Re: Gitbt es ein FLOSS Gründerpaket)

[Julius Bünger]

Das BSI schreibt hier, dass das "Re-Engineering" nach EU-Recht explizit
erlaubt ist, falls Firmen Schnittstellen nicht offen legen.

Unter https://www.bsi.bund.de/DE/Themen/DigitaleGesellschaft/FreieSoftware/freiesoftware_node.html
findet man:

> Daher müssen Standards frei zugänglich dokumentiert und einsetzbar
> sein. Dies wird durch Artikel 6 der Richtlinie des Europäischen
> Parlaments und des Rates vom 23. April 2009 über den Rechtsschutz von
> Computerprogrammen gestützt. Diese erlaubt das Re-Engineering in den
> Fällen, in denen Firmen ihre Standards zur Wahrung der
> Interoperabilität nicht offen legen. Ein Beispiel dafür sind
> Office-Formate. Durch die Verwendung offener Standards ist die
> Schaffung von Interoperabilität bei Freier Software gewährleistet.

Ich fand das recht bemerkenswert.


On Sun, Mar 10, 2019 at 10:13:47 +0100, Moritz Bartl wrote:
> Das selbe gilt für die Datev-Schnittstellen(dokumentation).
> 
> In all solchen Fällen ist jedoch mein Rechtsverständnis, das ein
> "Reverse Engineering" und eine alternative kompatible Implementation
> (ohne Kenntnis der Schnittstellen-Dokumentation) rechtlich nicht zu
> verhindern wäre. Im Zweifel veröffentlicht man das in den USA.
> 
> https://techcrunch.com/2016/05/26/jury-finds-googles-implementation-of-java-in-android-was-fair-use/
> 
> 
> On 06.03.19 13:24, Ilu wrote:
> > Gerüchteweise ist bei Elster der Hintergrund der, daß man Schnittstelle
> > und Parameter nicht sauber getrennt hat - d.h. der Zugang zur
> > Schnittstelle legt Parameter offen, die man nicht veröffentlichen will.
> > Insofern ist das mit der Scham schon der richtige Ansatz.
> > 
> > Am 06.03.2019 um 13:07 schrieb Dr. Michael Stehmann:
> >>
> >>
> >> Am 06.03.19 um 12:57 schrieb Ilu:
> >>> Das Finanzamt verlangt für den Zugriff auf die Elster-Schnittstelle die
> >>> Unterzeichnung eines NDA. Freie Software also absichtlich
> >>> ausgeschlossen. Federführend ist leider die Finanzverwaltung in Bayern.
> >>>
> >>> Gruß
> >>> Ilu
> >>>
> >> Dies ist leider eine übliche Vorgehensweise. Die BRak verlangt das
> >> gleiche für die beA-Schnittstelle und die Rechtsschutzversicherer für
> >> die drebis-Schnittstelle.
> >>
> >> Die kassenärztlichen Abrechnungssysteme (in D) müssen sogar zertifiziert
> >> sein.
> >>
> >> Es gibt ein tiefes (wenn auch unbegründetes) Misstrauen gegen die
> >> Sicherheit Freier Software in Deutschland. Möglicherweise schämt man
> >> sich aber bloß über die Spezifikation der Schnittstellen ;-) .
> >>
> >> Gruß
> >> Michael
> >>
> >>
> _______________________________________________
> FSFE-de mailing list
> FSFE-de at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/fsfe-de
> 
> Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
> Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
> behandeln: https://fsfe.org/about/codeofconduct

-- 

------------------------------------------------------------------------
           I prefer to communicate via GPG-encrypted email.
           Key: D4E5F972B413F3B3     Keyserver: pgp.mit.edu
------------------------------------------------------------------------

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-keys
Dateigröße  : 22748 bytes
Beschreibung: PGP Key 0xF97F2DA52C3A6F0EAE471A71D4E5F972B413F3B3.
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20190310/537000ac/attachment.key>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20190310/537000ac/attachment.sig>