1.1 Einfluss der KI auf die OSS-Lizenzen Ich muss gleich am Beginn sagen, dass ich sehr gespannt darauf bin, wie sich die Dinge entwickeln, wenn die Programmierer, die in Github unterwegs sind, nun eine KI zur Erstellung von Source einsetzen. Denn nach dem europäischen Recht unterfällt der Output der KI nicht dem Urheberrecht, es können […]
KI und OSS – Grundlegendes Teil I Weiterlesen »
3.5 Lizenztexte und Urhebervermerke 3.5.1 Lizenztexte Praktisch immer verlangen die OSS- Lizenzen, dass der Text der Lizenz mit der Software gemeinsam übergeben werden muss. Sofern man es als Lieferant richtig machen will, muss man dem Kunden eine BOM (Bill of Material: Eine Liste, aus der sich die unterschiedlichen Softwarekomponenten der Software ergibt) ausliefern, bevor der
Open Source Compliance Teil V Weiterlesen »
3.4.2 Einschränkungen 3.4.2.1 Kompatibilität Gerade im Bereich der Kompatibilität der Lizenzen muss man aufpassen. Jede der Lizenzen erlaubt eine Nutzung der Software nur unter Beachtung der eigenen Regelungen. Deshalb entsteht dann, wenn die Komponenten nicht sauber technisch und vertrieblich getrennt werden können, immer die Frage, ob eine Lizenz die Bestimmungen der anderen Lizenz nicht konterkariert
Open Source Compliance Teil IV Weiterlesen »
3. Inhalt des Systems, Inhaltsverzeichnis von Dateien und Komponenten Man prüfe im Schritt 1, welche Komponenten in einem System verwendet werden und zwar inklusive aller Subroutinen.Der Aufwand, der hier zur treiben ist, hat zu einer Trennung von mir und einer Kundin geführt, die dann doch lieber Inhouse-Juristen beschäftigen wollte. Inzwischen gibt es Tools und Standards,
Open Source Compliance Teil III Weiterlesen »
1.3 Compliance im Hinblick auf das Urheberrecht/ gewerbliche Schutzrechte Dann gibt es die rechtliche Compliance, die das Urheberrecht und den gewerblichen Rechtsschutz (also Patent, Markenrecht etc.) betrifft. Im Laiendeutsch: Die Kontrolle darüber, dass man die Software auch rechtlich, wie gewünscht, nutzen und weitergeben darf. Im Falle der Compliance von Open Source bedeutet das einerseits, dass
Open Source Compliance Teil II Weiterlesen »
1. Einleitung 1.1 Funktion dieser Serie Der Sinn einer Compliance liegt darin, in Übereinstimmung mit den Gesetzen zu arbeiten und Folgen wie z.B. Schadensersatzansprüche zu vermeiden. Die Compliance von Open Source kann in zwei Richtungen erfolgen.Einmal in die Richtung der IT-Sicherheit und einmal im Hinblick auf die rechtliche Compliance. 1.2 IT-Sicherheit Es gibt heute schon
Open Source Compliance Teil I Weiterlesen »
1. NIS-2-RL Bei den Vorgaben der NIS-2-RL handelt es sich um eine Richtlinie der europäischen Union. Diese Vorgaben hätten bis zum 17.10.2024 in nationales Gesetz umgesetzt werden sollen. Dazu kam es nicht, weil zunächst der Bundesrat sein Veto gegen einzelne Zuständigkeitsregelungen einlegte und dann die „Fortschrittskoalition“ zerbrach. Der Regierungsentwurf stammt vom 24.07.2024, inzwischen hat die
Compliance IT Sicherheit – Besonderer Teil NIS-2 Weiterlesen »
3. ISMS- Prozesse 3.1 Grundlagen des Risikomanagements ISMS ist wieder ein Buzzword und steht im Grunde für ein Risikomanagement System für IT- Sicherheit. Pflichten zum Risikomanagement gab es schon lange, und zwar im Gesellschaftsrecht, Banken- und Versicherungsrecht, etc.. Risiko wird verstanden als die Vorsorge vor zukünftigen Gefahren vor negativen Einflüssen. Gefahr wird im öffentlichen Recht
Compliance IT Sicherheit – Allgemeiner Teil III Weiterlesen »
1. Funktion des Begriffs der IT- Sicherheit Einen Blog über das Thema IT- Sicherheit mit der Feststellung zu beginnen, dass es keine gesetzliche Definition für den Begriff IT- Sicherheit gibt, hat sicher einen Geschmack. Kurz und trocken ausgedrückt, soll IT- Sicherheit bewirken, dass die IT- Services, wie beabsichtigt, funktionieren und die mit den Services verarbeiteten
Compliance IT Sicherheit – Allgemeiner Teil II Weiterlesen »
Fortsetzung von Teil I https://www.anwaltskanzlei-online.de/2024/12/27/datenschutzrechtliche-verantwortlichkeit-avv-und-agb-recht-im-spiegel-der-neueren-eugh-rechtsprechung-zur-cyberkriminalitaet-teil-i/ Beweislast Die DSGVO enthält keine Regelungen zur Beweislast für den Schadensersatz. Grundsätzlich muss der Betroffene (also die natürliche Person) nachweisen, dass ein Verstoß gegen die DSGVO zu einem Schaden (materiell oder immateriell) geführt hat. Eine Ausnahme gilt für die TOMs. Hier muss der Verantwortliche nachweisen, die angemessenen Maßnahmen getroffen zu
