Hallo Liste,
um mal auf freie Software zurückzukommen - ich hoffe, Ihr seid alle informiert über das was in ca. 15 Monaten auf (fast) alle Entwickler freier Software zukommt: das CE-Zeichen für Software - und noch einiges anderes.
Sehr schön zusammengefasst hier: https://blog.documentfoundation.org/blog/2023/01/24/tdf-position-on-eus-prop... und, etwas älter, hier: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13...
Was dort nicht erwähnt wird (weil es nicht FOSS-spezifisch ist), ist der richtige Klopper in Art. 11 CRA:
(1) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, jede aktiv ausgenutzte Schwachstelle, die in dem Produkt mit digitalen Elementen enthalten ist. ...
(2) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, jeden Vorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt. ...
(3) Die ENISA übermittelt dem Europäischen Netzwerk der Verbindungsorganisationen für Cyberkrisen (EU-CyCLONe), ... die gemäß den Absätzen 1 und 2 gemeldeten Informationen, ...
Quelle: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A52022PC0454
Hinter verschlossenen Türen wird gesagt, dass die Meldekette von ENISA an die für "legal interception" zuständigen nationalen Behörden gehen wird. Das ist das Ende von responsible disclosure.
Viele Grüße Ilu
Hallo Ilu,
Am 11.10.23 um 19:45 schrieb Ilu:
Was dort nicht erwähnt wird (weil es nicht FOSS-spezifisch ist), ist der richtige Klopper in Art. 11 CRA:
AFAIK lassen sich menschliche/technische Lücken zunehmend automatisiert ausnutzen. Das sind die Risiken der Hyperkonnektivität.
Deshalb MUSS die Verantwortliche den Nachweis erbringen, dass und wie sie personenbezogene Daten per DSGVO, betriebliche Prozesse per NIS-2 und softwarehaltige Produkte per CRA schützt. Das heißt: Die Verantwortliche MUSS Sicherheit 4.0 garantieren können, wenn sich ihre Verantwortung beispielsweise auf vernetzte Implantate, Autos oder Solaranlagen beziehen sollte.
Die Bundesregierung hat im Deutschen Umsetzungsgesetz darauf geachtet, dass das Abwälzen der Verantwortung auf eine D/O-Versicherung ausgeschlossen ist -- die Verantwortliche ist und bleibt persönlich für Pflichtverletzungen, delegieren lassen sich lediglich Aufgaben:
"Eine Pflichtverletzung liegt jedoch schon dann vor, wenn durch unzureichende Organisation, Anleitung bzw. Kontrolle Mitarbeitern der Gesellschaft Straftaten oder sonstige Fehlhandlungen ermöglicht oder auch nur erleichtert werden. Diesbezüglichen Verdachtsmomenten muss der Geschäftsführer unverzüglich nachgehen; weiterhin muss der Geschäftsführer geeignete organisatorische Vorkehrungen treffen, um Pflichtverletzungen von Unternehmensangehörigen hintanzuhalten" [1]
Pflichten werden verletzt, wenn das Schutzniveau aus §1 ProdHaftG "Stand von Wissenschaft und Technik" nicht eingehalten wird:
"Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn [...] der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte."
Das sind die Rechtsfolgen aus den Risiken.
Wollen wir ein niedrigeres Schutzniveau für vernetzte Implantate, Autos oder Solaranlagen? Ich hoffe nicht! Es läge auch nicht im Interesse der Herstellerin, wenn sich Schädlinge in den Produkten herumtreiben würden, denn dann würden die Kundinnen dem Laden wohl die Freundschaft kündigen?!
Diese Regelkonformität der Datenverarbeitung lässt sich nach Ansicht des BfDI besonders gut mit "Open Source" erfüllen.
Das bestätigt sogar ErwG 52 NIS-2:
"Open-Source-Cybersicherheitswerkzeuge und -Anwendungen können zu einem höheren Maß an Offenheit beitragen und sich positiv auf die Effizienz industrieller Innovationen auswirken."
(2) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, jeden Vorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt. ...
Mit dieser Pflicht werden insb. Unternehmen kollidieren, die nicht in den Quellcode ihrer Lieferkette gucken können.
Die Frage ist: Wie sollte sich die Sicherheit von Daten, Prozessen und Produkten sichern lassen, wenn nicht durch eine umfassende Rechenschaftspflicht der Verantwortlichen für eigenes Handeln sowie das Handeln derer, die im Auftrag dieser Verantwortlichen an der Planung, Entwicklung, Einrichtung, Verwaltung oder Nutzung von SW zur Verarbeitung/Durchführung von Daten/Produkten und Prozessen beteiligt sind?
Tatsächlich kritikwürdig empfinde ich es, dass die Gesetzgeberin einerseits für umfassende Rechenschaftspflichten eintritt -- und gleichzeitig andererseits Vorratsdaten sammeln, Chats kontrollieren und wer weiß Gott noch alles treiben will -- womit sie am Ende in Karlsruhe/Luxemburg aufm Bauch landen wird.
Leider habe ich keine öffentliche Stimme zu dieser Kritik oder den Schlußfolgerungen gehört, die sich aus der Hyperkonnekvitität ergeben.
Moment -- Stimmt nicht ganz:
"Nachhaltige Digitalisierung geht nur sicher. Oder überhaupt nicht!" [2]
Ich fänds gut, wenn die FSFE diesen Ball aufgreifen würde.
Gruß Joachim
[1] https://openjur.de/u/2395749.html [2] https://www.nbs.de/die-nbs/aktuelles/news/details/news/nachhaltige-digitalis...
Hallo Joachim,
Deine Antwort geht an der Sache vorbei: Was Du zu DSGVO und NIS-2 schreibst, ist völlig richtig, hat aber nichts mit CRA zu tun. Um Datenschutz und Sicherheit beim IT-Betrieb muss sich jedes Unternehmen kümmern und ist insofern auch für die dafür ausgewählte Software verantwortlich. CRA befasst sich aber nicht mit dem Betrieb, sondern mit der Erstellung von Software(-produkten).
Es ist bereits jetzt klar, dass - wenn CRA so Gesetz wird - viele kleine FOSS-Projekte in Europa eingestellt werden, weil sie CRA schlicht nicht umsetzen können. Hunderte von internationalen FOSS-Projekten werden Europa geo-blocken ("machen wir mit Nordkorea auch") und den Einsatz ihrer Software in Europa verbieten. Ob das lizenzkonform ist, sei dahingestellt, aber die Absicht besteht. Zum Beispiel die Linux Foundation: "Expect to see open source “not approved for the EU” if the EU CRA goes forward." Die EU sägt sich hier den Ast ab, auf dem sie eigentlich mit ihren Open-Source-Initiativen sitzen will.
Wer Freie Software erstellt, verschenkt etwas an die Gesellschaft. Die EU wird mit ihrer nächsten Gesetzesinitiative PLD den Schenkern vorschreiben, dass sie für die Qualität ihres Geschenks doch bitte in vollem Umfang haften sollen. Und zwar bei Freier Software jedem gegenüber, der diese Software nutzt (Ersteller proprietärer Software haften nur gegenüber ihren Kunden). Da ist es nur folgerichtig, dass Redhat ihre Repositories dichtgemacht haben.
Aber zurück zu Art. 11 CRA: Da geht es nicht um irgendwelche Pflichtverletzungen, sondern darum, dass Sicherheitslücken an eine Unzahl von staatlichen Behörden gemeldet werden sollen, bevor ein Patch bereitsteht. Das vermindert die Sicherheit anstatt sie zu erhöhen, so die einhellige Meinung aller Menschen, die sich mit IT-Sicherheit befassen. Gründe dafür kannst Du zB hier https://www.centerforcybersecuritypolicy.org/insights-and-research/joint-let... nachlesen. "Responsible disclosure" trägt nicht umsonst "verantwortungsbewußt" im Namen.
Ilu
PS: CRA wird nicht für solche Projekte gelten, die rein ehrenamtlich von Leuten betrieben werden, die auch in ihrem Hauptberuf nicht mit IT Geld verdienen - das merke ich nur der Vollständigkeit halber an, denn in der Realität kommt das so gut wie nicht vor.
Am 12.10.23 um 15:43 schrieb Joachim Jakobs:
Hallo Ilu,
Am 11.10.23 um 19:45 schrieb Ilu:
Was dort nicht erwähnt wird (weil es nicht FOSS-spezifisch ist), ist der richtige Klopper in Art. 11 CRA:
AFAIK lassen sich menschliche/technische Lücken zunehmend automatisiert ausnutzen. Das sind die Risiken der Hyperkonnektivität.
Deshalb MUSS die Verantwortliche den Nachweis erbringen, dass und wie sie personenbezogene Daten per DSGVO, betriebliche Prozesse per NIS-2 und softwarehaltige Produkte per CRA schützt. Das heißt: Die Verantwortliche MUSS Sicherheit 4.0 garantieren können, wenn sich ihre Verantwortung beispielsweise auf vernetzte Implantate, Autos oder Solaranlagen beziehen sollte.
Die Bundesregierung hat im Deutschen Umsetzungsgesetz darauf geachtet, dass das Abwälzen der Verantwortung auf eine D/O-Versicherung ausgeschlossen ist -- die Verantwortliche ist und bleibt persönlich für Pflichtverletzungen, delegieren lassen sich lediglich Aufgaben:
"Eine Pflichtverletzung liegt jedoch schon dann vor, wenn durch unzureichende Organisation, Anleitung bzw. Kontrolle Mitarbeitern der Gesellschaft Straftaten oder sonstige Fehlhandlungen ermöglicht oder auch nur erleichtert werden. Diesbezüglichen Verdachtsmomenten muss der Geschäftsführer unverzüglich nachgehen; weiterhin muss der Geschäftsführer geeignete organisatorische Vorkehrungen treffen, um Pflichtverletzungen von Unternehmensangehörigen hintanzuhalten" [1]
Pflichten werden verletzt, wenn das Schutzniveau aus §1 ProdHaftG "Stand von Wissenschaft und Technik" nicht eingehalten wird:
"Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn [...] der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte."
Das sind die Rechtsfolgen aus den Risiken.
Wollen wir ein niedrigeres Schutzniveau für vernetzte Implantate, Autos oder Solaranlagen? Ich hoffe nicht! Es läge auch nicht im Interesse der Herstellerin, wenn sich Schädlinge in den Produkten herumtreiben würden, denn dann würden die Kundinnen dem Laden wohl die Freundschaft kündigen?!
Diese Regelkonformität der Datenverarbeitung lässt sich nach Ansicht des BfDI besonders gut mit "Open Source" erfüllen.
Das bestätigt sogar ErwG 52 NIS-2:
"Open-Source-Cybersicherheitswerkzeuge und -Anwendungen können zu einem höheren Maß an Offenheit beitragen und sich positiv auf die Effizienz industrieller Innovationen auswirken."
(2) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, jeden Vorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt. ...
Mit dieser Pflicht werden insb. Unternehmen kollidieren, die nicht in den Quellcode ihrer Lieferkette gucken können.
Die Frage ist: Wie sollte sich die Sicherheit von Daten, Prozessen und Produkten sichern lassen, wenn nicht durch eine umfassende Rechenschaftspflicht der Verantwortlichen für eigenes Handeln sowie das Handeln derer, die im Auftrag dieser Verantwortlichen an der Planung, Entwicklung, Einrichtung, Verwaltung oder Nutzung von SW zur Verarbeitung/Durchführung von Daten/Produkten und Prozessen beteiligt sind?
Tatsächlich kritikwürdig empfinde ich es, dass die Gesetzgeberin einerseits für umfassende Rechenschaftspflichten eintritt -- und gleichzeitig andererseits Vorratsdaten sammeln, Chats kontrollieren und wer weiß Gott noch alles treiben will -- womit sie am Ende in Karlsruhe/Luxemburg aufm Bauch landen wird.
Leider habe ich keine öffentliche Stimme zu dieser Kritik oder den Schlußfolgerungen gehört, die sich aus der Hyperkonnekvitität ergeben.
Moment -- Stimmt nicht ganz:
"Nachhaltige Digitalisierung geht nur sicher. Oder überhaupt nicht!" [2]
Ich fänds gut, wenn die FSFE diesen Ball aufgreifen würde.
Gruß Joachim
[1] https://openjur.de/u/2395749.html [2] https://www.nbs.de/die-nbs/aktuelles/news/details/news/nachhaltige-digitalis...
FSFE-de mailing list FSFE-de@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
Hallo Ilu
Am 12.10.23 um 21:03 schrieb Ilu:
Hallo Joachim,
Deine Antwort geht an der Sache vorbei: Was Du zu DSGVO und NIS-2 schreibst, ist völlig richtig, hat aber nichts mit CRA zu tun.
Das sehe ich anders: Wenn durch Konstruktionsfehler Sicherheitslücken entstehen [1] oder gar Menschen an Leib und Leben verletzt werden, könnte das das Interesse der Staatsanwältin wecken -- egal ob es nun um vernetzte Autos/Implantate/Solaranlagen oder Aufzüge geht.
Um
Datenschutz und Sicherheit beim IT-Betrieb muss sich jedes Unternehmen kümmern und ist insofern auch für die dafür ausgewählte Software verantwortlich. CRA befasst sich aber nicht mit dem Betrieb, sondern mit der Erstellung von Software(-produkten).
Es wäre ja auch unsinnig, zwei unterschiedliche Richtlinien mit gleichem Inhalt und Adressatinnen zu erlassen -- aber die Herstellerinnen von dem ganzen IoT-Kram müssen eben nicht nur CRA sondern auch noch NIS-2 einhalten. Genauso wie in der Kreditwirtschaft nicht nur DORA sondern eben auch noch zusätzlich NIS-2 gilt (Der Bankenverband glaubt nämlich auch, dass für seine Mitglieder nur DORA gelte:-))
Es ist bereits jetzt klar, dass - wenn CRA so Gesetz wird - viele kleine FOSS-Projekte in Europa eingestellt werden, weil sie CRA schlicht nicht umsetzen können.
Klar ist: Wer durch mangelhafte Leistungen Menschen in Gefahr bringt, fliegt raus. Und das ist auch gut so.
Hunderte von internationalen FOSS-Projekten werden Europa geo-blocken ("machen wir mit Nordkorea auch") und den Einsatz ihrer Software in Europa verbieten. Ob das lizenzkonform ist, sei dahingestellt, aber die Absicht besteht. Zum Beispiel die Linux Foundation: "Expect to see open source “not approved for the EU” if the EU CRA goes forward." Die EU sägt sich hier den Ast ab, auf dem sie eigentlich mit ihren Open-Source-Initiativen sitzen will.
Für quelloffene Software lässt sich in jedem Fall leichter eine Stückliste derselben erstellen/eine Zertifzierung erhalten als mit proprietärer.
Sollte es dabei Schwierigkeiten mit der Finanzierung geben, wäre eben an der Stelle was zu tun.
Wer Freie Software erstellt, verschenkt etwas an die Gesellschaft. Die EU wird mit ihrer nächsten Gesetzesinitiative PLD den Schenkern vorschreiben, dass sie für die Qualität ihres Geschenks doch bitte in vollem Umfang haften sollen.
Wenn es anders wäre, könnten wir auch Kindern Waffen oder Handgranaten zum Spielen schenken.
Und zwar bei Freier Software jedem
gegenüber, der diese Software nutzt (Ersteller proprietärer Software haften nur gegenüber ihren Kunden). Da ist es nur folgerichtig, dass Redhat ihre Repositories dichtgemacht haben.
Aber zurück zu Art. 11 CRA: Da geht es nicht um irgendwelche Pflichtverletzungen, sondern darum, dass Sicherheitslücken an eine Unzahl von staatlichen Behörden gemeldet werden sollen, bevor ein Patch bereitsteht.
Ich wollte keineswegs behaupten, dass die Richtlinie kein VErbesserungspotential enthält.
Viele Grüße
Joachim
[1] https://www.automobil-industrie.vogel.de/autonomes-fahren-cybersicherheit-ha...
Am 12.10.23 um 15:43 schrieb Joachim Jakobs:
Hallo Ilu,
Am 11.10.23 um 19:45 schrieb Ilu:
Was dort nicht erwähnt wird (weil es nicht FOSS-spezifisch ist), ist der richtige Klopper in Art. 11 CRA:
AFAIK lassen sich menschliche/technische Lücken zunehmend automatisiert ausnutzen. Das sind die Risiken der Hyperkonnektivität.
Deshalb MUSS die Verantwortliche den Nachweis erbringen, dass und wie sie personenbezogene Daten per DSGVO, betriebliche Prozesse per NIS-2 und softwarehaltige Produkte per CRA schützt. Das heißt: Die Verantwortliche MUSS Sicherheit 4.0 garantieren können, wenn sich ihre Verantwortung beispielsweise auf vernetzte Implantate, Autos oder Solaranlagen beziehen sollte.
Die Bundesregierung hat im Deutschen Umsetzungsgesetz darauf geachtet, dass das Abwälzen der Verantwortung auf eine D/O-Versicherung ausgeschlossen ist -- die Verantwortliche ist und bleibt persönlich für Pflichtverletzungen, delegieren lassen sich lediglich Aufgaben:
"Eine Pflichtverletzung liegt jedoch schon dann vor, wenn durch unzureichende Organisation, Anleitung bzw. Kontrolle Mitarbeitern der Gesellschaft Straftaten oder sonstige Fehlhandlungen ermöglicht oder auch nur erleichtert werden. Diesbezüglichen Verdachtsmomenten muss der Geschäftsführer unverzüglich nachgehen; weiterhin muss der Geschäftsführer geeignete organisatorische Vorkehrungen treffen, um Pflichtverletzungen von Unternehmensangehörigen hintanzuhalten" [1]
Pflichten werden verletzt, wenn das Schutzniveau aus §1 ProdHaftG "Stand von Wissenschaft und Technik" nicht eingehalten wird:
"Die Ersatzpflicht des Herstellers ist ausgeschlossen, wenn [...] der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte."
Das sind die Rechtsfolgen aus den Risiken.
Wollen wir ein niedrigeres Schutzniveau für vernetzte Implantate, Autos oder Solaranlagen? Ich hoffe nicht! Es läge auch nicht im Interesse der Herstellerin, wenn sich Schädlinge in den Produkten herumtreiben würden, denn dann würden die Kundinnen dem Laden wohl die Freundschaft kündigen?!
Diese Regelkonformität der Datenverarbeitung lässt sich nach Ansicht des BfDI besonders gut mit "Open Source" erfüllen.
Das bestätigt sogar ErwG 52 NIS-2:
"Open-Source-Cybersicherheitswerkzeuge und -Anwendungen können zu einem höheren Maß an Offenheit beitragen und sich positiv auf die Effizienz industrieller Innovationen auswirken."
(2) Der Hersteller meldet der ENISA unverzüglich, jedenfalls aber innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, jeden Vorfall, der sich auf die Sicherheit des Produkts mit digitalen Elementen auswirkt. ...
Mit dieser Pflicht werden insb. Unternehmen kollidieren, die nicht in den Quellcode ihrer Lieferkette gucken können.
Die Frage ist: Wie sollte sich die Sicherheit von Daten, Prozessen und Produkten sichern lassen, wenn nicht durch eine umfassende Rechenschaftspflicht der Verantwortlichen für eigenes Handeln sowie das Handeln derer, die im Auftrag dieser Verantwortlichen an der Planung, Entwicklung, Einrichtung, Verwaltung oder Nutzung von SW zur Verarbeitung/Durchführung von Daten/Produkten und Prozessen beteiligt sind?
Tatsächlich kritikwürdig empfinde ich es, dass die Gesetzgeberin einerseits für umfassende Rechenschaftspflichten eintritt -- und gleichzeitig andererseits Vorratsdaten sammeln, Chats kontrollieren und wer weiß Gott noch alles treiben will -- womit sie am Ende in Karlsruhe/Luxemburg aufm Bauch landen wird.
Leider habe ich keine öffentliche Stimme zu dieser Kritik oder den Schlußfolgerungen gehört, die sich aus der Hyperkonnekvitität ergeben.
Moment -- Stimmt nicht ganz:
"Nachhaltige Digitalisierung geht nur sicher. Oder überhaupt nicht!" [2]
Ich fänds gut, wenn die FSFE diesen Ball aufgreifen würde.
Gruß Joachim
[1] https://openjur.de/u/2395749.html [2] https://www.nbs.de/die-nbs/aktuelles/news/details/news/nachhaltige-digitalis...
FSFE-de mailing list FSFE-de@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
FSFE-de mailing list FSFE-de@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
Hallo,
die grundsätzliche Frage scheint mir zu sein: Wer soll haften, die Person, die Software herstellt, oder die, die Software einsetzt?
Ein einfaches Beispiel: Der Hersteller eines Datenbankmanagementsystems, das als Freie Software verbreitet wird, Kann nicht alle Zwecke kennen, für die es eingesetzt wird.
Wird es nur für die Verwaltung einer Briefmarkensammlung eingesetzt, ist ein möglicher Schaden durch ein "Leck" eher irrelevant. Wird es für die Verwaltung von Millionen Kreditkartendaten oder von einem Kranken- oder Sozialversicherer eingesetzt, ist dies evidentermaßen anders.
Wird das Programm nur auf einen "unvernetzten" Rechner eingesetzt, wäre ein solcher Fehler ebenfalls irrelevant, solange der unbefugte physische Zugang zum Rechner verhindert wird.
Daher ist es IMO die verwendende Person, die die Risiken der Nutzung einer solcher Software tragen sollte, denn sie hat erstens den Nutzen vom Einsatz der Software und zweitens ist sie am Besten in der Lage, die Risiken zu beherrschen und zu minimieren (von der Firewall bis zum Türschloss).
Bei Freier Software kommt noch hinzu, dass das Recht und die Möglichkeit zum Studium derselben eingeräumt wird, Warum sollen sich aus diesen erhöhten Rechten der verwendenden Person nicht auch erhöhte (Prüfungs-)Obliegenheiten derselben ergeben?
Ein weiteres Argument ist die Versicherbarkeit der Risiken. Das Risiko ist für das Projekt, welches ein freies DBMS herstellt, kaum kalkulierbar. Es ist aber viel besser kalkulierbar für die konkrete Verwendung desselben.
Oder um zum "Handgranatengeschenk" zu kommen: Software an sich ist ungefährlich. Erst ihr konkreter Einsatz kann riskant sein.
Aus guten Grund ist nach deutschem Recht auch der Haftungsmaßstab bei einer Schenkung ein anderer, als bei einem Verkauf.
Gruß Michael
Hallo Michael,
danke für die schöne Zusammenfassung der risikoorientierten Gesetzgebung!
Am 15.10.23 um 17:41 schrieb Dr. Michael Stehmann:
Hallo,
die grundsätzliche Frage scheint mir zu sein: Wer soll haften, die Person, die Software herstellt, oder die, die Software einsetzt?
beide haften IMHO: Die Autorin für die Sicherheit der Software (per CRA), die Anwenderin für den sicheren Einsatz (Einrichtung, Verwaltung, Nutzung per DSGVO/NIS-2).
(Insb.) für vernetzte Produkte gilt (in Deutschland) der "Stand von Wissenschaft und Technik". Ich vermute, dass sich dieses Schutzniveau auch in Europa durchsetzen wird, sobald es zu Körperverletzungen kommt.
Oder um zum "Handgranatengeschenk" zu kommen: Software an sich ist ungefährlich. Erst ihr konkreter Einsatz kann riskant sein.
:)
Aus guten Grund ist nach deutschem Recht auch der Haftungsmaßstab bei einer Schenkung ein anderer, als bei einem Verkauf.
Klar: Wer (um es zu überspitzen) aus Habgier an der Sicherheit/Pentests/Zertifizierung spart, wird strenger behandelt, als Eine, die Geschenke macht.
Gruß Joachim
Hallo,
Am 15.10.23 um 21:11 schrieb Joachim Jakobs:
beide haften IMHO: Die Autorin für die Sicherheit der Software (per CRA), die Anwenderin für den sicheren Einsatz (Einrichtung, Verwaltung, Nutzung per DSGVO/NIS-2).
Die Sache ist nur, dass IMO die "Sicherheit der Software" (für die die Autorin haften soll) vom konkreten Einsatz abhängt und dieser ist bei Freier Software nicht von vornherein festgelegt oder auch nur absehbar ("use for any purpose").
Gruß Michael
Am 15.10.23 um 21:28 schrieb Dr. Michael Stehmann:
Die Sache ist nur, dass IMO die "Sicherheit der Software" (für die die Autorin haften soll) vom konkreten Einsatz abhängt und dieser ist bei Freier Software nicht von vornherein festgelegt oder auch nur absehbar ("use for any purpose").
Also ich bin kein Entwickler und schon garnicht Experte für die Steuerung von Autos/Implantaten -- oder auch nur Software zum Briefmarkensortieren.
Aber ich vermute: Die Software zum Sortieren wird sich nicht zum Steuern verwenden lassen?
Wobei es natürlich sein, dass Software zum Sortieren und zum Steuern gleichermaßen auf einen Baustein wie Log4j zugreifen. Die Sortiersoftware kann wohl samt Quelltext bedenkenlos veröffentlicht werden. Für die Steuerungssoftware wäre eine Stückliste, ein Pentest und ein Zertifikat wichtig. Dann wäre wohl die Entwicklerin aus dem Schneider.
Gruß Joachim
Hallo,
zum Thema Supply Chain und Freie Software eine gut lesbare Dissertation:
https://bonndoc.ulb.uni-bonn.de/xmlui/bitstream/handle/20.500.11811/9325/638...
Das Thema wird in letzter Zeit diskutiert auch in Bezug auf sinnvolles Verhalten für (Weiter-)Verwendende von Freier Software.
https://www.linux-magazin.de/ausgaben/2022/12/communities/?mc-cid=8526f6bf4e...
"Softwareentwickler bedienen sich gern am riesigen Fundus quelloffener Bibliotheken und Werkzeuge. Komplett aus dem Blick geraten dabei allerdings häufig die Communities hinter diesen Komponenten."
Da gibt es sicherlich auch viel Anekdotik.
Gruß Michael
Die EU hat sich über den nicht festgelegten Einsatzzweck auch schon Gedanken gemacht: Haftungsgegenstand soll sein "was der Nutzer vernünftigerweise erwarten konnte". (PLD)
Welche/r Programmierer/in wird es sich unter diesen Umständen noch leisten können, Software der Allgemeinheit zu jedem beliebigen Zweck frei zur Verfügung zu stellen? Und damit ein völlig unbegrenztes (und unbegrenzbares) Haftungsrisiko gegenüber der ganzen Weltbevölkerung einzugehen?
Joachim: Es geht hier nicht um Firmen, die IOT verkaufen oder irgendwas in Autos einbauen. Die nutzen nämlich freie Software nur, aber erstellen sie nicht. Und ihren Kunden gegenüber haften sie ohnehin. Das ist alles schon längst geregelt.
Ich nehme als Beispiel mal curl, dessen Programmierer (sofern der beruflich sein Geld mit Software verdient, was ich vermute) in Zukunft keinen bug mehr leisten, weil seine großzügig freigegebene Software praktisch überall eingebaut wird und er für all das haften soll. Dass seine Software eine Schenkung ist, wird nach EU-Recht (und damit auch in D) keinen Unterschied mehr machen. Ein bug kann sein Leben ruinieren.
Joachim, Du findest es ernsthaft angemessen, dass etwa der Programmierer von curl haften soll, wenn in einem Auto oder einem IOT-Gerät (wegen einem bug) das Update fehlschlägt und deshalb was schiefgeht?
Am 15.10.23 um 17:41 schrieb Dr. Michael Stehmann:
Hallo,
die grundsätzliche Frage scheint mir zu sein: Wer soll haften, die Person, die Software herstellt, oder die, die Software einsetzt?
Ein einfaches Beispiel: Der Hersteller eines Datenbankmanagementsystems, das als Freie Software verbreitet wird, Kann nicht alle Zwecke kennen, für die es eingesetzt wird.
Wird es nur für die Verwaltung einer Briefmarkensammlung eingesetzt, ist ein möglicher Schaden durch ein "Leck" eher irrelevant. Wird es für die Verwaltung von Millionen Kreditkartendaten oder von einem Kranken- oder Sozialversicherer eingesetzt, ist dies evidentermaßen anders.
Wird das Programm nur auf einen "unvernetzten" Rechner eingesetzt, wäre ein solcher Fehler ebenfalls irrelevant, solange der unbefugte physische Zugang zum Rechner verhindert wird.
Daher ist es IMO die verwendende Person, die die Risiken der Nutzung einer solcher Software tragen sollte, denn sie hat erstens den Nutzen vom Einsatz der Software und zweitens ist sie am Besten in der Lage, die Risiken zu beherrschen und zu minimieren (von der Firewall bis zum Türschloss).
Bei Freier Software kommt noch hinzu, dass das Recht und die Möglichkeit zum Studium derselben eingeräumt wird, Warum sollen sich aus diesen erhöhten Rechten der verwendenden Person nicht auch erhöhte (Prüfungs-)Obliegenheiten derselben ergeben?
Ein weiteres Argument ist die Versicherbarkeit der Risiken. Das Risiko ist für das Projekt, welches ein freies DBMS herstellt, kaum kalkulierbar. Es ist aber viel besser kalkulierbar für die konkrete Verwendung desselben.
Oder um zum "Handgranatengeschenk" zu kommen: Software an sich ist ungefährlich. Erst ihr konkreter Einsatz kann riskant sein.
Aus guten Grund ist nach deutschem Recht auch der Haftungsmaßstab bei einer Schenkung ein anderer, als bei einem Verkauf.
Gruß Michael
FSFE-de mailing list FSFE-de@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
Am 16.10.23 um 08:26 schrieb Ilu:
Joachim: Es geht hier nicht um Firmen, die IOT verkaufen oder irgendwas in Autos einbauen. Die nutzen nämlich freie Software nur, aber erstellen sie nicht. Und ihren Kunden gegenüber haften sie ohnehin. Das ist alles schon längst geregelt.
Das verstehe ich nicht: Wer entwickelt denn die Steuerungen von vernetztem Zeugs? AFAIK hat VW eine extra Tochter dafür. Und machen die alles selber? Oder gibts auf sourceforge ein klein wenig Quellcode (wie log4j), das Alle nutzen, aber keiner die Entwicklerin von dem Fetzen Quellcode bezahlt? Oder gibts ausgerechnet bei den Steuerungen nur hochbezahlte Entwicklerinnen, die ausschließlich proprietären Code schreiben?
Joachim, Du findest es ernsthaft angemessen, dass etwa der Programmierer von curl haften soll, wenn in einem Auto oder einem IOT-Gerät (wegen einem bug) das Update fehlschlägt und deshalb was schiefgeht?
Wer sollte denn sonst haften, wenn nicht die Entwicklerin, wenn durch ihren (fahrlässig) verursachten Fehler bei einem (Verkehrs-/Kraftwerks)Unfall Menschen verletzt werden?
Um im Beispiel zu bleiben: Bei VW hätte sicher auch die Tochter und der Konzern als Herstellerin zu haften -- das ändert aber an der Haftung für den kleinen Fetzen nix.
Und ja: Da könnte es Entwicklerinnen geben, die sich das nicht mehr leisten können. Dann wird die Industrie irgendwann feststellen: "Hoppla, die Geschenke bleiben aus!" Was werden die Verantwortlichen also tun??
Ich bin überzeugt, dass hier ganz fix neue Geschäftsmodelle entstehen werden -- einschließlich menschenwürdiger Bezahlung!
Am 15.10.23 um 17:41 schrieb Dr. Michael Stehmann:
Hallo,
die grundsätzliche Frage scheint mir zu sein: Wer soll haften, die Person, die Software herstellt, oder die, die Software einsetzt?
Ein einfaches Beispiel: Der Hersteller eines Datenbankmanagementsystems, das als Freie Software verbreitet wird, Kann nicht alle Zwecke kennen, für die es eingesetzt wird.
Wird es nur für die Verwaltung einer Briefmarkensammlung eingesetzt, ist ein möglicher Schaden durch ein "Leck" eher irrelevant. Wird es für die Verwaltung von Millionen Kreditkartendaten oder von einem Kranken- oder Sozialversicherer eingesetzt, ist dies evidentermaßen anders.
Wird das Programm nur auf einen "unvernetzten" Rechner eingesetzt, wäre ein solcher Fehler ebenfalls irrelevant, solange der unbefugte physische Zugang zum Rechner verhindert wird.
Daher ist es IMO die verwendende Person, die die Risiken der Nutzung einer solcher Software tragen sollte, denn sie hat erstens den Nutzen vom Einsatz der Software und zweitens ist sie am Besten in der Lage, die Risiken zu beherrschen und zu minimieren (von der Firewall bis zum Türschloss).
Bei Freier Software kommt noch hinzu, dass das Recht und die Möglichkeit zum Studium derselben eingeräumt wird, Warum sollen sich aus diesen erhöhten Rechten der verwendenden Person nicht auch erhöhte (Prüfungs-)Obliegenheiten derselben ergeben?
Ein weiteres Argument ist die Versicherbarkeit der Risiken. Das Risiko ist für das Projekt, welches ein freies DBMS herstellt, kaum kalkulierbar. Es ist aber viel besser kalkulierbar für die konkrete Verwendung desselben.
Oder um zum "Handgranatengeschenk" zu kommen: Software an sich ist ungefährlich. Erst ihr konkreter Einsatz kann riskant sein.
Aus guten Grund ist nach deutschem Recht auch der Haftungsmaßstab bei einer Schenkung ein anderer, als bei einem Verkauf.
Gruß Michael
FSFE-de mailing list FSFE-de@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
FSFE-de mailing list FSFE-de@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
Hallo,
Am 16.10.23 um 10:36 schrieb Joachim Jakobs:
Das verstehe ich nicht: Wer entwickelt denn die Steuerungen von vernetztem Zeugs? AFAIK hat VW eine extra Tochter dafür. Und machen die alles selber? Oder gibts auf sourceforge ein klein wenig Quellcode (wie log4j), das Alle nutzen, aber keiner die Entwicklerin von dem Fetzen Quellcode bezahlt? Oder gibts ausgerechnet bei den Steuerungen nur hochbezahlte Entwicklerinnen, die ausschließlich proprietären Code schreiben?
Joachim, Du findest es ernsthaft angemessen, dass etwa der Programmierer von curl haften soll, wenn in einem Auto oder einem IOT-Gerät (wegen einem bug) das Update fehlschlägt und deshalb was schiefgeht?
Wer sollte denn sonst haften, wenn nicht die Entwicklerin, wenn durch ihren (fahrlässig) verursachten Fehler bei einem (Verkehrs-/Kraftwerks)Unfall Menschen verletzt werden?
Zu haften hat IMO die Person, die die Software zu einem bestimmten Zweck einsetzt. Dies gilt jedenfalls dann, wenn die Software nicht gezielt für einen bestimmten Einsatz entwickelt wurde.
Bei log4j war es ja, soweit ich dies verstanden habe, so, dass die Software so arbeitete, wie von den Entwicklern beabsichtigt ("works as designed"). Sie wurde jedoch so eingesetzt, dass die Features zu Sicherheitsproblemen führten. Nicht die Software war also fehlerhaft, sondern ihr konkreter Einsatz.
Warum soll hierfür die entwickelnde Person haften?
Freie Software wäre definitiv tot, wenn man aus ihrer Entwicklung und Distribution eine "gefahrgeneigte Tätigkeit" mit unkalkulierbaren Haftungsrisiken machen würde. (Nur ausnahmsweise kann man mathematisch beweisen, dass Software immer entsprechend ihrer Spezifikation und nur entsprechend ihrer Spezifikation arbeitet. Und das Problem des nicht spezifikationsgerechten Einsatzes bleibt dann.)
(Exkurs: Ich stelle mir gerade einen Beipackzettel vor: "Wichtiger Hinweis! Zu Risiken und Nebenwirkungen eines konkreten Einsatzes dieser Software fragen Sie bitte Ihre InformatikerInnen oder Ihre IT-SicherheitsexpertInnen.")
Der Tod Freier Software wäre sicherlich im Interesse mancher Unternehmen (anderer eher nicht). Aber wäre dies auch im Interesse der Gesellschaft (oder auch der Menschheit)?
Also Apologet Freier Software meine ich: Nein!
Gruß Michael
Am 16.10.23 um 12:00 schrieb Dr. Michael Stehmann:
Warum soll hierfür die entwickelnde Person haften?
Das würde in der Konsequenz bedeuten, dass Microsoft (mit seiner historisch bedingten Anfälligkeit) oder der Autozulieferer Continental nicht zur Rechenschaft zu ziehen wäre, sondern die jeweils Verantwortliche Nutzerin (Ärztin/Autofahrerin), die Implantate verbaut oder Auto fährt?
Grade bei Continental wäre das fatal: Dort soll sich eine Mitarbeiterin einen Browser aus dem Netz gezogen und installiert haben -- am Ende waren Terabytes von Daten/Quellcode weg. Bei einem neuerlichen Angriff muss jetzt mit dem Versuch gerechnet werden, Schadsoftware in die automobile Lieferkette und am Ende in die Autos einzuschleusen.
Wäre Continental nicht verantwortlich für die Integrität seiner Anwendungen, hätten sie keinerlei Anreiz, sich darum zu kümmern -- sie sind ja immerhin schon TISAX-zertifiziert! TISAX!!
Und die Fehlerdichte könnte zunehmen:
"Factors affecting Defect Density Complexity
As the complexity of code increases, the defect rate could increase significantly." [1]
Nochmal: Freie Software ermöglicht Transparenz, verringert die Haftungsrisiken. Dafür muss die Entwicklerin bezahlt werden. Das wird die Industrie lernen (müssen) wenn sie mit der zu erwartenden Angriffsqualität in Zukunft klarkommen will.
Ein juristisches Gutachten (__Rechtswissenschaftlerinnen_:-) der Uni Göttingen meint im Auftrag des BSI, dass Stand von Wissenschaft und Technik für die Entwicklerinnen von Autos -- ich meine auch von Implantaten -- bereits heute gelte und §1 ProdHG anzuwenden sei.
Freie Software wäre definitiv tot, wenn man aus ihrer Entwicklung und Distribution eine "gefahrgeneigte Tätigkeit" mit unkalkulierbaren Haftungsrisiken machen würde. (Nur ausnahmsweise kann man mathematisch beweisen, dass Software immer entsprechend ihrer Spezifikation und nur entsprechend ihrer Spezifikation arbeitet. Und das Problem des nicht spezifikationsgerechten Einsatzes bleibt dann.)
Ack -- perfekte Software wirds nie geben! Es lässt sich aber alles Menschenmögliche tun. Und allzu oft geht den Kundinnen Geschwindigkeit über Qualität. Und sie setzen Termine, die nicht einzuhalten sind, wenn Qualität gebracht werden soll. Das wird sich ändern, wenn Qualität ein Leistungsmerkmal ist, mit dem sich Geld verdienen lässt. Oder wenn Keine mehr bereit ist, Geschenke zu machen.
Hallo,
Am 16.10.23 um 13:03 schrieb Joachim Jakobs:
Am 16.10.23 um 12:00 schrieb Dr. Michael Stehmann:
Warum soll hierfür die entwickelnde Person haften?
Das würde in der Konsequenz bedeuten, dass Microsoft (mit seiner historisch bedingten Anfälligkeit) oder der Autozulieferer Continental nicht zur Rechenschaft zu ziehen wäre, sondern die jeweils Verantwortliche Nutzerin (Ärztin/Autofahrerin), die Implantate verbaut oder Auto fährt?
Der Hersteller des Produktes (Auto, Reifen u.ä.), der Software zu einem bestimmten Zweck implementiert, soll in erster Linie haften. Genauso wie der Führer eines Fahrzeuges haftet, wenn er beispielsweise zu schnell damit fährt und nicht der Hersteller, der ein Fahren mit einer Geschwindigkeit über 6 km/h zugelassen hat. Denk' auch 'mal über den Sinn der Gefährdungshaftung nach.
Grade bei Continental wäre das fatal: Dort soll sich eine Mitarbeiterin einen Browser aus dem Netz gezogen und installiert haben -- am Ende waren Terabytes von Daten/Quellcode weg. Bei einem neuerlichen Angriff muss jetzt mit dem Versuch gerechnet werden, Schadsoftware in die automobile Lieferkette und am Ende in die Autos einzuschleusen. > Wäre Continental nicht verantwortlich für die Integrität seiner Anwendungen, hätten sie keinerlei Anreiz, sich darum zu kümmern -- sie sind ja immerhin schon TISAX-zertifiziert! TISAX!!
Also ist der Fall an sich doch klar: Continental haftet und nicht der Hersteller der Software, welche einen Download ermöglicht hat.
Continental hätte den Download durch technische oder organisatorische Maßnahmen verhindern müssen.
Man kann doch nicht dem Hersteller der Downloadsoftware aufgeben, diese prüfen im Einzelnen zu lassen, was heruntergeladen werden soll - abgesehen davon kann eine solche Sperre bei Freier Software recht einfach entfernt werden.
Und die Fehlerdichte könnte zunehmen:
"Factors affecting Defect Density Complexity
As the complexity of code increases, the defect rate could increase significantly." [1]
Nochmal: Freie Software ermöglicht Transparenz, verringert die Haftungsrisiken. Dafür muss die Entwicklerin bezahlt werden. Das wird die Industrie lernen (müssen) wenn sie mit der zu erwartenden Angriffsqualität in Zukunft klarkommen will.
Richtig, aber nicht, indem die entwickelnde Person, die die Software lizenzgebührenfrei der Allgemeinheit zur Verfügung stellt, in Haftung genommen wird.
Ein juristisches Gutachten (__Rechtswissenschaftlerinnen_:-) der Uni Göttingen meint im Auftrag des BSI, dass Stand von Wissenschaft und Technik für die Entwicklerinnen von Autos -- ich meine auch von Implantaten -- bereits heute gelte und §1 ProdHG anzuwenden sei.
Auch richtig, aber das kann doch nicht für die Entwicklerin einer Freien Bibliothek gelten, derer sich der Automobilhersteller zur Steuerung seines Fahrzeuges oder zwecks Unterhaltung seiner Insassen bedient.
Freie Software wäre definitiv tot, wenn man aus ihrer Entwicklung und Distribution eine "gefahrgeneigte Tätigkeit" mit unkalkulierbaren Haftungsrisiken machen würde. (Nur ausnahmsweise kann man mathematisch beweisen, dass Software immer entsprechend ihrer Spezifikation und nur entsprechend ihrer Spezifikation arbeitet. Und das Problem des nicht spezifikationsgerechten Einsatzes bleibt dann.)
Ack -- perfekte Software wirds nie geben! Es lässt sich aber alles Menschenmögliche tun. Und allzu oft geht den Kundinnen Geschwindigkeit über Qualität. Und sie setzen Termine, die nicht einzuhalten sind, wenn Qualität gebracht werden soll. Das wird sich ändern, wenn Qualität ein Leistungsmerkmal ist, mit dem sich Geld verdienen lässt. Oder wenn Keine mehr bereit ist, Geschenke zu machen.
Wenn niemand mehr bereit ist, Geschenke zu machen, ist Freie Software tot. Es gehört zum Wesen Freier Software, dass die Lizenz unentgeltlich eingeräumt wird.
Im Übrigen: "Look at the community!"
https://www.linux-magazin.de/ausgaben/2022/12/communities/?mc-cid=8526f6bf4e...
Beispielsweise: Bevorzugt man ein Projekt mit festen Releasezyklen oder eins, welches veröffentlicht, wenn es fertig ist?
Gruß Michael
Am 16.10.23 um 14:19 schrieb Dr. Michael Stehmann:
Der Hersteller des Produktes (Auto, Reifen u.ä.), der Software zu einem bestimmten Zweck implementiert, soll in erster Linie haften.
Herstellung und Implementierung sind zwei Paar Schuhe?
Der Hersteller stellt Implantate her, die dann von der Ärztin verbaut werden. Der Hersteller haftet für das Implantat (per CRA), die Ärztin fürs ordnungsgemäße Verbauen (per NIS-2 bzw Patientendatenschutzgesetz/Cybersicherheitsrichtlinie)
Genauso wie der Führer eines Fahrzeuges haftet, wenn er beispielsweise zu schnell damit fährt und nicht der Hersteller, der ein Fahren mit einer Geschwindigkeit über 6 km/h zugelassen hat. Denk' auch 'mal über den Sinn der Gefährdungshaftung nach.
Die Nutzerin eines Fahrzeugs ist nicht am Herstellungsprozess der Komponenten bzw deren Zusammenfügen beteiligt.
Grade bei Continental wäre das fatal: Dort soll sich eine Mitarbeiterin einen Browser aus dem Netz gezogen und installiert haben -- am Ende waren Terabytes von Daten/Quellcode weg. Bei einem neuerlichen Angriff muss jetzt mit dem Versuch gerechnet werden, Schadsoftware in die automobile Lieferkette und am Ende in die Autos einzuschleusen. > Wäre Continental nicht verantwortlich für die Integrität seiner Anwendungen, hätten sie keinerlei Anreiz, sich darum zu kümmern -- sie sind ja immerhin schon TISAX-zertifiziert! TISAX!!
Also ist der Fall an sich doch klar: Continental haftet und nicht der Hersteller der Software, welche einen Download ermöglicht hat.
Womöglich war meine Darstellung zuvor unpräzise: Die Anwendung scheint die Tarnung gewesen zu sein. Es war einfach nur ein Schädling, der sich hinter dieser Anwendung versteckte und darauf gewartet hat, dass er implementiert wurde.
Haftung seines der ENtwicklerin ist nicht zu erwarten.
Continental hätte den Download durch technische oder organisatorische Maßnahmen verhindern müssen.
Da sind wir uns ausnahmsweise einig:-)
Richtig, aber nicht, indem die entwickelnde Person, die die Software lizenzgebührenfrei der Allgemeinheit zur Verfügung stellt, in Haftung genommen wird.
Wer soll denn dann beispielsweise für Debian GNU/Linux haften?
Ein juristisches Gutachten (__Rechtswissenschaftlerinnen_:-) der Uni Göttingen meint im Auftrag des BSI, dass Stand von Wissenschaft und Technik für die Entwicklerinnen von Autos -- ich meine auch von Implantaten -- bereits heute gelte und §1 ProdHG anzuwenden sei.
Auch richtig, aber das kann doch nicht für die Entwicklerin einer Freien Bibliothek gelten, derer sich der Automobilhersteller zur Steuerung seines Fahrzeuges oder zwecks Unterhaltung seiner Insassen bedient.
s.o: Die Herstellerin wird irgendwann feststellen, dass die Geschenke ausbleiben und ihr kriminelles Geschäftsmodell ändern. Das ist natürlich schwierig, da die Mafia aus Wolfsburg, München und Stuttgart aktuell mit Geldbußen, Schadensersatz und den Fehlern der Produktpolitik vergangener Jahrzehnte eigentlich genug zu kämpfen hat.
Freie Software wäre definitiv tot, wenn man aus ihrer Entwicklung und Distribution eine "gefahrgeneigte Tätigkeit" mit unkalkulierbaren Haftungsrisiken machen würde. (Nur ausnahmsweise kann man mathematisch beweisen, dass Software immer entsprechend ihrer Spezifikation und nur entsprechend ihrer Spezifikation arbeitet. Und das Problem des nicht spezifikationsgerechten Einsatzes bleibt dann.)
Ack -- perfekte Software wirds nie geben! Es lässt sich aber alles Menschenmögliche tun. Und allzu oft geht den Kundinnen Geschwindigkeit über Qualität. Und sie setzen Termine, die nicht einzuhalten sind, wenn Qualität gebracht werden soll. Das wird sich ändern, wenn Qualität ein Leistungsmerkmal ist, mit dem sich Geld verdienen lässt. Oder wenn Keine mehr bereit ist, Geschenke zu machen.
Wenn niemand mehr bereit ist, Geschenke zu machen, ist Freie Software tot. Es gehört zum Wesen Freier Software, dass die Lizenz unentgeltlich eingeräumt wird.
Sind die bezahlten FS-Entwicklerinnen alle ausgestorben?
Hallo Joachim,
Du verstehst überhaupt nicht, wie Freie Software funktioniert. Damit bist Du in guter Gesellschaft, die gesamte EU-Bürokratie und die Abgeordneten verstehen es auch nicht. Gleiches gilt für die nationale Ebene.
Das verstehe ich nicht: Wer entwickelt denn die Steuerungen von vernetztem Zeugs? AFAIK hat VW eine extra Tochter dafür.
Die entwickeln natürlich auch selbst, aber daraus wird fast nie Freie Software. Der Code bleibt geheim.
Und machen die alles selber? Oder gibts auf sourceforge ein klein wenig Quellcode (wie log4j), das Alle nutzen, aber keiner die Entwicklerin von dem Fetzen Quellcode bezahlt?
GENAU SO IST ES. Genau das ist das Prinzip Freier Software.
Oder gibts ausgerechnet bei den Steuerungen nur hochbezahlte Entwicklerinnen, die ausschließlich proprietären Code schreiben?
So ist es. Vielleicht nicht ausschließlich, auch da gibt es Leute, die - häufig privat in ihrer Freizeit! - zu Freier Software beitragen.
Das würde in der Konsequenz bedeuten, dass Microsoft (mit seiner historisch bedingten Anfälligkeit) oder der Autozulieferer Continental nicht zur Rechenschaft zu ziehen wäre, sondern die jeweils Verantwortliche Nutzerin (Ärztin/Autofahrerin), die Implantate verbaut oder Auto fährt?
Microsoft und Continental und IOT und Implantathersteller haben Vertragsbeziehungen zu Kunden und werden bezahlt. Natürlich haften die ihren Kunden gegenüber. Das hat mit CRA absolut nichts zu tun. [Sie versuchen häufig, die Haftung vertraglich auszuschließen. Das zu verbieten ist sicher angebracht, ist aber ein anderes Thema.]
... bereits heute gelte und §1 ProdHG anzuwenden sei.
Natürlich ist das jetzt schon so. Der Produkt-/Code-VERKÄUFER haftet. und das ist auch richtig so. Aber doch nicht der Code-Ersteller, der den Code verschenkt!
Nochmal: Freie Software ermöglicht Transparenz, verringert die Haftungsrisiken. Dafür muss die Entwicklerin bezahlt werden. Das wird die Industrie lernen (müssen) wenn sie mit der zu erwartenden Angriffsqualität in Zukunft klarkommen will.
Die Industrie entwickelt nur einen winzig kleinen Teil Freier Software, der größte Teil sind private Initiativen. Und das einzige, was die Industrie aus CRA lernen wird, ist dass man besser keine Freie Software entwickelt, denn die Freigabe erhöht das Haftungsrisiko völlig unkontrollierbar. CRA und PLD werden dazu führen, dass es sich niemand in Europa mehr leisten kann, Freie Software zu entwickeln. Weder beruflich noch privat.
Am 16.10.23 um 12:00 schrieb Dr. Michael Stehmann:
Freie Software wäre definitiv tot, wenn man aus ihrer Entwicklung und Distribution eine "gefahrgeneigte Tätigkeit" mit unkalkulierbaren Haftungsrisiken machen würde.
Und genau das passiert gerade.
Viele Grüße Ilu
Hallo,
On 16/10/2023 8:03 pm, Ilu wrote:
Damit bist Du in guter Gesellschaft, die gesamte EU-Bürokratie und die Abgeordneten verstehen es auch nicht. Gleiches gilt für die nationale Ebene.
derartige Aussagen sind despektierlich, polemisch, populistisch und kontraproduktiv. Ohne kompetente Entscheidungsträger hätten es sicher nicht sowas wie FOSSA/FOSSA2 gegeben, die Ausnahmen im CRA vom IMCO und vom Rat sind durchaus passabel, die EP Position für den AI Act und PLD ebenso. Insbesondere die zugrundeliegende Änderungsanträge zeichnen ein völlig anderes Bild als das was du malst.
Beste Grüße
Alex
Hallo Alex,
ja, das war polemisch. Es gibt auch in der EU einzelne Leute, die die Sachlage verstehen.
Am 17.10.23 um 10:51 schrieb Alexander Sander:
Hallo,
On 16/10/2023 8:03 pm, Ilu wrote:
Damit bist Du in guter Gesellschaft, die gesamte EU-Bürokratie und die Abgeordneten verstehen es auch nicht. Gleiches gilt für die nationale Ebene.
derartige Aussagen sind despektierlich, polemisch, populistisch und kontraproduktiv. Ohne kompetente Entscheidungsträger hätten es sicher nicht sowas wie FOSSA/FOSSA2 gegeben, die Ausnahmen im CRA vom IMCO und vom Rat sind durchaus passabel, die EP Position für den AI Act und PLD ebenso. Insbesondere die zugrundeliegende Änderungsanträge zeichnen ein völlig anderes Bild als das was du malst.
Beste Grüße
Alex
Hallo,
On 16/10/2023 8:03 pm, Ilu wrote:
Und das einzige, was die Industrie aus CRA lernen wird, ist dass man besser keine Freie Software entwickelt, denn die Freigabe erhöht das Haftungsrisiko völlig unkontrollierbar. CRA und PLD werden dazu führen, dass es sich niemand in Europa mehr leisten kann, Freie Software zu entwickeln. Weder beruflich noch privat.
kurz zur Klarstellung:
Es wird sehr sehr wahrscheinlich eine Ausnahme im CRA als auch der PLD geben, die private Entwicklung ausnimmt. Das stand nie zur Debatte. Umstritten ist, ob Kleinst- und Kleinunternehmen ausgenommen werden sollen und wie mit non profit Projekten die Umsatz generieren und Stiftungen umgegangen wird.
Liebe Grüße
Alex
Am Dienstag 17 Oktober 2023 11:03:48 schrieb Alexander Sander:
Es wird sehr sehr wahrscheinlich eine Ausnahme im CRA als auch der PLD geben, die private Entwicklung ausnimmt. Das stand nie zur Debatte.
Da Problem ist, dass die Freie Software-Produkte, welche von einem Mensch in einer privaten Rolle entwickelt werden, von jedem professionell eingesetzt werden können. Ich bin skeptisch, ob die Regeln das hinbekommt sowohl "in privater Rolle" vernünftig zu definieren, wie das abzugrenzen.
2004 schätze ich, dass "40% der eingesetzten Freien Software im Hauptberuf entwickelt wird." [Reiter 2004]. Meine Vermutung ist, dass sich das noch deutlich erhöht hat.
Auch die Zuschreibung "Geschenk" finde ich unzutreffend, da eine Initiative, elche Freie Software herausgibt, von ihrer Gemeinschaft deutlich profitieren kann. Wenn, dann ist es ein Geben und nehmen.
Umstritten ist, ob Kleinst- und Kleinunternehmen ausgenommen werden sollen und wie mit non profit Projekten die Umsatz generieren und Stiftungen umgegangen wird.
Auch die Haftung der Großunternehmen wird Freie Software stark schaden, weil sie diese auf ihre Zulieferer pauschal abwälzen wird. Große Unternehmen ignorieren die Haftung dann einfach (wie es z.B. Microsoft jetzt schon tut) und kleinere sind dran.
Und ein Problem ist prinzipiell, Michael hat mehrmals darauf hingewiesen: Der Einsatzzweck einer Software (gerade einer Freien Software) kann nicht durch den Entwickelnden bestimmt oder auch nur vorhergesehen werden. Obwohl ich Joachims Gedanken verstehe, dass doch jemand haften müsse, und es sehr wünschenswert wäre, wenn da bessere Finanzierungsmodelle wären... bin ich eher bei Ilu: das ist viel zu wenig Verständnis für (Freie)-Software in der EU und anderen Verwaltungen. Genau das versuchen wir mit der FSFE schon seit Jahren zu verbessern.
Gruß Bernhard
[Reiter 2004] Wandel der IT: Mehr als 20 Jahre Freie Software; in HMD, Heft 238, August 2004, Seiten 83-91 https://intevation.de/~bernhard/publications/200408-hmd/200408-wandel_der_it...
Hi
Mal 'ne "blöde" Frage:
Am 17.11.23 um 11:50 schrieb Bernhard E. Reiter:
Und ein Problem ist prinzipiell, Michael hat mehrmals darauf hingewiesen: Der Einsatzzweck einer Software (gerade einer Freien Software) kann nicht durch den Entwickelnden bestimmt oder auch nur vorhergesehen werden.
Es gibt durchaus Lizenzen, die den Einsatzzweck einschränken (creative commons "NC" z.B.) - wenngleich dann wohl nicht mehr von "freier Software" in engerem Sinne geredet werden kann.
Aber was hält den Entwickler freier Software davon ab, in der Lizenz sinngemäß festzulegen, dass innerhalb der EU der kommerzielle Einsatz der Software nur gestattet ist, wenn der Einsetzende in die Haftungsrisiken, die sich daraus ergeben, vollumfänglich eintritt?
Nur mal so - als Plan B vielleicht ;-)
Hi,
Aber was hält den Entwickler freier Software davon ab, in der Lizenz sinngemäß festzulegen, dass innerhalb der EU der kommerzielle Einsatz der Software nur gestattet ist, wenn der Einsetzende in die Haftungsrisiken, die sich daraus ergeben, vollumfänglich eintritt?
Nichts – das steht da ja auch schon drin – "to the extent permitted by applicable law".
Nur verschiebt CRA halt den "extent permitted by applicable law".
-nik
Hi Dominik
Am 17.11.23 um 13:51 schrieb Dominik George:
Nichts – das steht da ja auch schon drin – "to the extent permitted by applicable law".
Nur verschiebt CRA halt den "extent permitted by applicable law".
Nun ja - "to the extent permitted by applicable law" ist dann auch nach wie vor auch der kommerzielle Einsatz; der ist ja nicht gesetzlich verboten. Nur ginge damit halt der Entwickler ungewollt in die Haftung - aber auch das ist ja nicht gesetzlich verboten, sondern ganz im Gegenteil explizit herbeigeführt.
Also: Nein, das steht nicht schon 'drin.
Hi,
Nun ja - "to the extent permitted by applicable law" ist dann auch nach wie vor auch der kommerzielle Einsatz; der ist ja nicht gesetzlich verboten [...]
Es geht ja nicht um die Nutzung, sondern um die Haftung.
CRA verbietet nicht die Nutzung, sondern den Haftungsausschluss.
Damit ist "without warranty, to the extent permitted by applicable law" vollkommen korrekt und anwendbar: Bei kommerzieller Nutzung darf die Haftung nicht ausgeschlossen werden.
Worauf du hinauswillst ist, glaube ich, dass dann eben in der Lizenz zusätzlich geregelt sein sollte, dass eine kommerzielle Nutzung ohne Wartungsvertrag ausgeschlossen ist.
Das sehe ich nicht so – es ist nicht Aufgabe des Urhebers, und auch nicht des Urheber*rechts*, sich mit anderen Rechtsbereichen auseinanderzusetzen oder zu überlegen, wer wo die Software einsetzen darf.
Stattdessen sollte das CRA die Verantwortung zum Nutzer verschieben: Wenn ich Software kommerziell nutzen will, brauche ich eben nicht nur eine Lizenz, sondern auch einen Wartungsvertrag oder muss erklären, die Haftung selber zu übernehmen.
M.M.n. spielt bei nichts davon der Urheber oder die Lizenz eine Rolle. Nur, wenn ich eben will, dass mein Code in der EU kommerziell genutzt werden darf, dann muss ich eben zusätzlich zur Lizenz auch einen Wartungsvertrag anbieten. Muss ich aber nicht. So würde ich mir das wünschen.
-nik
CRA verbietet nicht die Nutzung, sondern den Haftungsausschluss.
PLD wird den Haftungsausschluss verbieten. CRA regelt erstmal die (einen Teil der) Sorgfaltsanforderungen.
Das spezielle Problem bei Freier Software ist, dass die Berechtigten der Haftung in keiner Weise eingeschränkt sind. Jeder, der die Software runterlädt und im Rahmen der Lizenz benutzt, kann im Fall des Falles Haftung verlangen. Insofern ist da schon ein Zusammenhang mit Lizenzrecht.
Und da die freien Lizenzen auch sachlich uferlos sind (keine Einschränkung auf bestimmte Verwendungszwecke) ist die daraus resultierende uferlose Haftung ein massives Problem.
Proprietäre Software hat dieses Problem nicht, da wird nur gegenüber den eigenen Kunden gehaftet. Und der Verwendungszweck wird vertraglich geklärt.
Am 18.11.23 um 18:24 schrieb Dominik George:
Hi,
Nun ja - "to the extent permitted by applicable law" ist dann auch nach wie vor auch der kommerzielle Einsatz; der ist ja nicht gesetzlich verboten [...]
Es geht ja nicht um die Nutzung, sondern um die Haftung.
CRA verbietet nicht die Nutzung, sondern den Haftungsausschluss.
Damit ist "without warranty, to the extent permitted by applicable law" vollkommen korrekt und anwendbar: Bei kommerzieller Nutzung darf die Haftung nicht ausgeschlossen werden.
Worauf du hinauswillst ist, glaube ich, dass dann eben in der Lizenz zusätzlich geregelt sein sollte, dass eine kommerzielle Nutzung ohne Wartungsvertrag ausgeschlossen ist.
Das sehe ich nicht so – es ist nicht Aufgabe des Urhebers, und auch nicht des Urheber*rechts*, sich mit anderen Rechtsbereichen auseinanderzusetzen oder zu überlegen, wer wo die Software einsetzen darf.
Stattdessen sollte das CRA die Verantwortung zum Nutzer verschieben: Wenn ich Software kommerziell nutzen will, brauche ich eben nicht nur eine Lizenz, sondern auch einen Wartungsvertrag oder muss erklären, die Haftung selber zu übernehmen.
M.M.n. spielt bei nichts davon der Urheber oder die Lizenz eine Rolle. Nur, wenn ich eben will, dass mein Code in der EU kommerziell genutzt werden darf, dann muss ich eben zusätzlich zur Lizenz auch einen Wartungsvertrag anbieten. Muss ich aber nicht. So würde ich mir das wünschen.
-nik
Nichts – das steht da ja auch schon drin – "to the extent permitted
by applicable law".
Nur verschiebt CRA halt den "extent permitted by applicable law".
So ist es. Sobald die Tätigkeit als kommerziell eingestuft wird, kann die Haftung halt zukünftig (nach PLD) nicht mehr ausgeschlossen werden. Nicht vertraglich und auch nicht generell via Lizenz. Und, wie Bernhard schon schrieb, auch nicht hinsichtlich des Zwecks, zu dem die Software verwendet wird.
Wenn ein Kleinunternehmen eine Freie Software produziert, die die ESA dann für die nächste explodierte Raumfähre verwendet, kann das für das Kleinunternehmen ziemlich schwierig werden. Ein realitätsnäheres Beispiel sind Autohersteller. Und ein realistisches Beispiel für eine solche Software wäre z.B. curl oder der Linux kernel.
Viele Grüße Ilu
Am 17.11.23 um 13:51 schrieb Dominik George:
Hi,
Aber was hält den Entwickler freier Software davon ab, in der Lizenz sinngemäß festzulegen, dass innerhalb der EU der kommerzielle Einsatz der Software nur gestattet ist, wenn der Einsetzende in die Haftungsrisiken, die sich daraus ergeben, vollumfänglich eintritt?
Nichts – das steht da ja auch schon drin – "to the extent permitted by applicable law".
Nur verschiebt CRA halt den "extent permitted by applicable law".
-nik
Hallo,
Am Mon, Oct 16, 2023 at 12:00:09PM +0200 schrieb Dr. Michael Stehmann:
Der Tod Freier Software wäre sicherlich im Interesse mancher Unternehmen (anderer eher nicht). Aber wäre dies auch im Interesse der Gesellschaft (oder auch der Menschheit)?
Ich würde eher sagen: im Interesse einiger sehr sehr weniger Unternehmen!
Selbst Firmen, die früher _alles_ in house gemacht haben, sind längst dazu übergegangen FOSS in ihren Produkten zu verwenden. Alles andere ist schlicht zu teuer. Für kleine Firmen ist es finanziell schlicht unmöglich alles selbst zu entwickeln. Wenn ich mir jetzt vorstelle, dass jede Firma selbst einen json- oder XML-Parser, einen Bootloader, einen Betriebssystemkern für embedded Devices usw. entwickeln muss, anstatt ausgereifte und gut geteste FOSS Komponenten zu diesem Zweck zu benutzen, wie sicher werden die entstehenden Produkte dann noch sein? Also wenn sie dann überhaupt noch entstehen?
Grüße Alex
Hallo Alex,
Am 16.10.23 um 13:47 schrieb Alexander Dahl:
Selbst Firmen, die früher _alles_ in house gemacht haben, sind längst dazu übergegangen FOSS in ihren Produkten zu verwenden. Alles andere ist schlicht zu teuer. Für kleine Firmen ist es finanziell schlicht unmöglich alles selbst zu entwickeln. Wenn ich mir jetzt vorstelle, dass jede Firma selbst einen json- oder XML-Parser, einen Bootloader, einen Betriebssystemkern für embedded Devices usw. entwickeln muss, anstatt ausgereifte und gut geteste FOSS
Nach dem Testen muss dann noch die Zertifizierung folgen. Wie sollte die Herstellerin sonst mit der Fülle dieser beliebigen Anzahl von Komponenten klarkommen? Sie muss sich darauf verlassen, dass die Zuliefererin die vereinbarte Qualität liefert. Genauso wie sich die Herstellerin eines Autos darauf verlassen können muss, dass der Stahl über die vereinbarten Eigenschaften verfügt.
Über kurz oder lang wird jeder Furz Software zertifiziert sein müssen -- die Bedeutung solcher Zertifizierung wird parallel zur Komplexität und Länge der Lieferkette zunehmen.
Viele Grüße
Joachim
Am 18.10.23 um 09:35 schrieb Joachim Jakobs:
Über kurz oder lang wird jeder Furz Software zertifiziert sein müssen -- die Bedeutung solcher Zertifizierung wird parallel zur Komplexität und Länge der Lieferkette zunehmen.
Damit wäre dann nämlich auch die Haftung geklärt: Wie groß ist die Wahrscheinlichkeit, dass in Freier Software samt Stückliste, Pentest, Zertifikat fahrlässig verursachte Fehler zu finden sind?
Ansonsten brauchen wir einen Aufkleber: "Gebrauch auf eigene Gefahr und Risiko"
Ich glaube nicht, dass die Automafia ihre Kundinnen mit solchen Aufklebern fahren lassen will.
Wenn wir schon dabei sind: Wie prüft denn eigentlich der TÜV die (Nicht-TISAX-)Software im Fahrzeug heute? Oder wird die womöglich garnicht geprüft? Verbreiten die Menschen ihren Quark mit einer ungeprüften Facebook-Implementierung?