DACH - Deutschsprachige Community für Deutschland, Österreich, Schweiz
Das Sammelbecken auf feddit.org für alle Deutschsprechenden aus Deutschland, Österreich, Schweiz, Liechtenstein, Luxemburg und die zwei Belgier. Außerdem natürlich alle anderen deutschprechenden Länderteile der Welt.
Für länderspezifische Themen könnt ihr euch in folgenden Communities austauschen:
___
Aus gegebenem Anlass werden Posts zum Thema Palästina / Israel hier auf Dach gelöscht. Dasselbe gilt zurzeit für Wahlumfragen al´a Sonntagsumfrage.
___
Einsteigertipps für Neue gibt es hier.
___
Aus gegebenem Anlass: Bitte Titel von Posts nur sinnerweiternd und nicht sinnentstellend verändern. Eigene Meinungen gehören in den Superkommentar oder noch besser in einen eigenen Kommentar darunter.
___
Eine ausführliche Sidebar mit den Serverregeln usw. findet ihr auf der Startseite von feddit.org
___
view the rest of the comments
Nun ja... das Kernproblem aus Konzernsicht ist ja die Softwarelieferkettensicherheit, und das lässt sich nicht ganz abstreiten insbesondere da die bald auch eine rechtliche Frage wird (EU Cyber Reliance Act).
Jetzt einfach zu sagen die Firmem hätten halt ihr eigenes abgesichertes Gemsverzeichnis schaffen müssen greift auch zu kurz, da diese scheinbar die Infrastruktur und auch einige Gehälter bezahlt haben.
Daher abgesehen davon das in diesem speziellen Fall auch noch ansonsten einiges im Argen ist (Rails und DHH etc.), wird es wohl nötig sein solche Abhängigkeitsverwaltungswerkzeuge grundsätzlich anders aufzustellen. Ganz von Konzernen unabhängig wird rein kostenmäßig zumindesten kurzfristig nicht funktionieren, und Open-Source Maintainer sollten für ihre Arbeit auch zumindestens irgendwie entlohnt werden.
Nicht-kommerzielle open-source Projekte sind von CRA ausgenommen. An der Stelle wo zuerst kommerziell verkauft wird fängt CRA an zu greifen. Wenn eine Firma in ein kommerzielles Produkt nicht-kommerzielles open-source einbaut muss sie selbst sicher stellen, dass das Produkt und damit auch seine Komponenten die CRA Anforderungen erfüllen.
Nicht-kommerzielles open-source ist keine Lieferkette. Es wird immer so geredet als gäbe es da einen "Lieferant", das ist nicht der Fall. Das ist einfach nur ein Projekt das herumschwirrt, und wenn ich mich daran bediene um das in ein kommerzielles Produkt verwandeln will um damit Geld zu verdienen, dann muss ich auch selbst dafür sorgen dass es den Regeln des Marktes entspricht.
Eben. Und das hat Ruby Central hier versucht zu machen.
Eh naja, "versucht" ist da harmlos ausgedrückt. Einfach Maintainer aussperren ist weder nett noch förderlich für so ein Projekt. Man hätte auch einen soft fork machen können der upstream trackt und Änderungen nach einer Prüfung übernimmt. Wenn man sich mit upstream gut stellt könnte man auch eine doppel-Lizenz Strategie umsetzen, indem Lizenzen für den CRA-kompatiblen soft-fork an andere kommerzielle Konsumer des Projekts verkauft werden, welche sich dafür das Review plus Risiko sparen können. Daraus wiederum könnte man die Reviews und generelle Projektunterstützung finanzieren.
Wo bitte erfordert der CRA denn die Kontrolle über die Open Source Paketverwaltung? Wenn das so wäre sollte ich dringend schauen, dass meine Firma sowohl PyPi als auch OpenJDK kontrolliert.
Wenn du open-source Projekte in einem kommerziellen Produkt verwendest dann haftest du dafür. Die CRA erfordert strenggenommen natürlich nicht die Kontrolle aber praktisch gesehen ist es durchaus nachvollziehbar das eine Firma nicht für etwas haften will wo sie keinerlei Einfluss auf die Sicherheitsstandards hat.