2024-11-24 - 02:18

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 1 - Installation eigener Software-Versionen (Installing own software versions)

Ein Maschinenbauer liefert in seinen Maschinen die folgenden Softwarekomponenten, die unter einer Open Source-Lizenz stehen, in binärer Form aus:

  1. Das U-Boot GPL-2.0
  2. Linuxkernel GPL-2.0
  3. GNU C Library LGPL-2.1
  4. Busybox GPL-2.0

Über eine serielle Schnittstelle, die auch in der Maschine des Kunden vorhanden ist, kann der Bootloader “Das U-Boot” mit Z-Modem Protokoll in die entsprechende Partition des Flash-Speichers kopiert werden (Varianten a bis f). Ein Kunde möchte nun eine eigene Version des Bootloaders „Das U-Boot“ installieren.

Varianten

Variante a)

Für das Aufspielen der Software ist ein spezieller Login vorgesehen, aber der Maschinenbauer weigert sich, dem Kunden die erforderliche Username/Passwort-Kombination auszuhändigen. Darf der Hersteller sich weigern?

Antwort a)
(Hinweis: Diese und die folgenden Antworten sind nur sichtbar, wenn Sie als OSADL-Mitglied eingeloggt sind.)

Variante b)

Auch in dieser Variante ist für das Aufspielen der Software ein Passwortschutz vorgesehen. Aber der Maschinenbauer hat sich am SIL2LinuxMP-Projekt der OSADL eG beteiligt und vom TÜV Rheinland eine SIL2-Zertifizierung für die Maschine erhalten. Nun weigert er sich, dem Kunden die erforderliche Username/Passwort-Kombination auszuhändigen, mit dem Argument, der TÜV habe das verboten. Stimmt das?

Antwort b)

Variante c)

Für die Herstellung des Bootloaders „Das U-Boot“ wurde ausschließlich Quellcode verwendet, der optional unter die GPL-3.0 gestellt werden kann. Daher hat der Software-Dienstleister des Maschinenbauers, der „Das U-Boot“ geliefert hat, eine Lizenzierung unter der GPL-3.0 vorgenommen. Auch jetzt ist das Aufspielen der Software durch Passwort geschützt, und der Maschinenbauer weigert sich, dem Kunden die erforderliche Username/Passwort-Kombination auszuhändigen. Darf der Hersteller sich jetzt weigern? Wenn er sich bei Variante a) und c) jeweils nicht weigern darf, gibt es dennoch einen Unterschied?

Antwort c)

Variante d)

Die beiden mittleren
Stifte sind durch den
roten Jumper verbunden

In dieser Variante ist kein Login mit Username/Passwort erforderlich, sondern die Software-Installation erfordert das Einsetzen einer Kurzschlussbrücke (Jumper) auf der Platine; dieser Jumper wurde aber vom Hersteller vor der Auslieferung entfernt und nicht dokumentiert. Der Kunde nimmt aber an, dass es einen solchen Jumper geben muss (denn irgendwie muss der Maschinenbauer die Software bei der Herstellung der Maschine installiert haben) und findet auch mehrere passende Stiftpaare für einen Jumper auf der Platine. Der Maschinenbauer verschweigt aber diese Tatsache auch nach entsprechender Anfrage und macht die erbetene Dokumentation weiterhin nicht verfügbar. Der Kunde droht mit Klage. Wie könnte diese ausgehen?

Antwort d)

Variante e)

Lötbrücke, die gerade aufgelötet wird
Lötbrücke, die gerade
aufgelötet wird

Das erneute Beschreiben der entsprechenden Partition des Flash-Speichers ist nicht wegen einer fehlenden Jumper-Dokumentation. sondern wegen einer fehlenden nicht dokumentierten Lötbrücke nicht möglich. Der Kunde weiß dies aber nicht, und der Maschinenbauer teilt dem Kunden dies – auch nach mehrfacher Anfrage – nicht mit. Eine kurzfristige Antwort wäre aber erforderlich gewesen, um ein aktuelles Produktionsproblem zu lösen. Zufälligerweise erhält der Kunde zu einem späteren Zeitpunkt eine Kopie des Schaltplans und stellt fest, dass es mit dem Auflöten einer kleinen Lötbrücke schnell und einfach möglich gewesen wäre, die eigene Version der Bootloaders „Das U-Boot“ auf die Maschine zu kopieren. Da der Kunde dies nicht gewusst hat, ist ihm ein nennenswerter Schaden entstanden. Hat er berechtigte Hoffnung, dass der Maschinenbauer für diesen Schaden aufkommt?

Antwort e)

Variante f)

Das erneute Beschreiben der entsprechenden Partition des Flash-Speichers ist nicht möglich, da am Ende des Herstellungsprozesses der serielle Controller mechanisch unbrauchbar gemacht wurde, so dass auch der Hersteller nicht mehr in der Lage ist, die Boot-Partition des Flash-Speichers zu beschreiben. Auch in diesem Fall erfährt der Kunde davon und fordert den Hersteller auf, ihm eine ursprüngliche Version der Platine auszuhändigen, damit er seine eigene Version des Bootloaders „Das U-Boot“ auf die Maschine kopieren kann. Muss der Maschinenbauer diese Platine aushändigen? Wenn ja, darf er Geld dafür verlangen?

Antwort f)

Variante g)

Schaltbild eines maskenprogrammierbaren ROM (MX23X1024)
Schaltbild eines
maskenprogrammierbaren
ROMs (MX23X1024)
Außenansicht des maskenprogrammierbaren ROMs
Außenansicht des
maskenprogrammier-
baren ROMs

Im Gegensatz zur obigen Beschreibung dieses Falls ist in dieser Variante der Bootloader „Das U-Boot“ in einem maskenprogrammierten ROM gespeichert, das sich nicht auslöten oder sonstwie ersetzen lässt. Der Kunde möchte aber unbedingt seine eigene Version des Bootloaders „Das U-Boot“ auf die Maschine kopieren. Muss er diesen Wunsch aufgeben? Oder kann er den Maschinenbauer zwingen, bei der nächsten Maskenversion des ROMs seine Änderungen aufzunehmen, so dass diese dann – eventuell optional – verfügbar wären?

Antwort g)

Fall 1   Fall 2    Fall 3    Fall 4    Fall 5    

Best practices I        Best practices II