Dates and Events:
|
OSADL Articles:
2023-11-12 12:00
Open Source License Obligations Checklists even better nowImport the checklists to other tools, create context diffs and merged lists
2022-07-11 12:00
Call for participation in phase #4 of Open Source OPC UA open62541 support projectLetter of Intent fulfills wish list from recent survey
2022-01-13 12:00
Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completedAnother important milestone on the way to interoperable Open Source real-time Ethernet has been reached
2021-02-09 12:00
Open Source OPC UA PubSub over TSN project phase #3 launchedLetter of Intent with call for participation is now available |
Fall 4 - Eigenes Release von FOSS Safety-Software (Own release of FOSS safety software)
Ein Hersteller von industriellen Steuerungen hat sich am SIL2LinuxMP-Projekt des OSADL beteiligt und im Rahmen der damit verbundenen Entwicklungstätigkeit eine Erweiterung des Linuxkernels in Form eines Patches bereitgestellt. Diese Erweiterung beinhaltet ein Safety-Framework, das eine Reihe von Komponenten zusammenfasst, die für den Betrieb eines Linukernels erforderlich sind, der für funktionale Sicherheit zertifiziert werden soll. Viele Funktionen dieses Frameworks sind weitgehend unabhängig von der jeweiligen Version des Linuxkernels und können sogar nach nur leichter Anpassung mit Delta-Zertifizierung auch im Zusammenhang mit einem anderen Betriebssystem genutzt werden. Bei der Programmierung wurde streng nach den Vorgaben einer Standard-konformen Entwicklung vorgegangen und eine getrennte Zertifizierung angestrebt. Diese wurde auch erreicht, und das Framework erhielt eine SIL2-Zertifizierung. Als Lizenz wurde die GPL-2.0 gewählt.
Da eine Aufnahme des entwickelten und zertifizierten Safety-Frameworks in den Mainlinekernel in absehbarer Zukunft nicht zu erwarten ist, beschließt der Hersteller, den Patch auf seiner Webseite zur Verfügung zu stellen. Den Auflagen der Zertifizierungsstelle folgend bietet er Interessenten an, beim Download der Software einen Kommunikationskanal einzurichten, auf dem später gefundene Programmierfehler mitgeteilt werden. Ebenfalls den Auflagen der Zertifizierungsstelle folgend können Nutzer der Software die angegebenen Kommunikationsdaten selbständig anpassen, damit sichergestellt ist, dass die Fehlerreports in jedem Fall den Anwender erreichen, wenn dies vom Anwender gewünscht wird.
Nach einiger Zeit erreicht den Hersteller die folgende Anfrage:
„Sehr geehrte Damen und Herren
Wir nutzen das von Ihnen bereitgestellte Safety-Framework und möchten dies nun unsererseits weitergeben. Wir kennen die von der Standardisierungsstelle vorgegebene Auflage, einen Kommunikationskanal für die Mitteilung von später aufgefundenen Programmierfehlern bereitzustellen. Aber wir sind uns über die gegenseitigen Verpflichtungen von SIL2-Zertifizierung und GPL-2.0 nicht im Klaren. Müssen wir diesen Kommunikationskanal unsererseits einrichten? Wenn ja, stellt dies wohl eine Verletzung von Artikel 6 der GPL-2.0 („You may not impose any further restriction“) dar. Wenn nein, wird die Vorgabe der Zertifizierungsstelle nicht erfüllt – verliert das Framework dadurch seine Zertifizierung, wenn wir es ohne den Kommunikationskanal weitergeben? Dürfen wir den von Ihnen eingerichteten Kommunikationskanal verwenden? Wenn ja, können wir uns darauf verlassen? Bitte geben Sie uns Bescheid.“
Was soll der Hersteller antworten?
Antwort
(Hinweis: Diese Antwort ist nur sichtbar, wenn Sie als OSADL-Mitglied eingeloggt sind.)