2024-11-13 - 12:26

Dates and Events:

OSADL Articles:

2024-10-02 12:00

Linux is now an RTOS!

PREEMPT_RT is mainline - What's next?


2023-11-12 12:00

Open Source License Obligations Checklists even better now

Import the checklists to other tools, create context diffs and merged lists


2023-03-01 12:00

Embedded Linux distributions

Results of the online "wish list"


2022-01-13 12:00

Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completed

Another 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 launched

Letter of Intent with call for participation is now available



OSADL Seminar on Software Patents and Open Source Licensing

OSADL Juristisches Seminar 2016 - Aspekte der Lizenzierung von Open Source-Software im Umfeld von Safety- und Security-Zertifizierung

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.)

Fall 1    Fall 2    Fall 3    Fall 4   Fall 5    

Best practices I        Best practices II