Einsatz von Open Source auf Geräten

Im Zuge der zunehmenden Digitalisierung der klassischen Industrie, wie zum Beispiel im Maschinenbau, kommen seit ein paar Jahren nun auch immer mehr Geräte zum Vernetzen der Produktionsanlagen zum Einsatz. Ein wesentlicher Bestandteil der eingesetzten Geräte ist, neben der Fähigkeit über die üblichen Feldbusprotokolle wie Profinet, Modbus TCP oder Ethernet/IP mit übergeordneten Steuerungen kommunizieren zu können, Schnittstellen und Protokolle zu typischen IT-Systemen anzubieten. Gerade bei Neulanlagen sind diese mittlerweile Teil der Grundausstattung und vielfach hardware-technisch so leistungsfähig, um z.B. Szenarien wie die Datenerfassung und Datenvoranalyse zusätzlich mit abzudecken. Deshalb liegt u.a. beim Design solcher Geräte, neben der Auswahl von leistungsfähiger Hardware, der Einsatz von unixoiden Betriebssystemen wie Linux in seinen verschiedenartigen Ausprägungen sehr nahe. Die technischen Vorteile von Linux sind u.a., dass es sehr leistungsfähig und skalierfähig ist. Entstehende Kosten hinsichtlich etwaiger Lizenzen für Linux spielen zumindest im industriellen Umfeld eher keine Rolle, da die Anschaffungspreise von solchen Geräten nicht selten jenseits der 500€-Marke liegen. Zwei weitere Vorteile von Linux sind die Unterstützung von vielen Rechner-Architekturen und der, dass große Firmen, wie Google, IBM, Samsung usw. linux-basierende Betriebssysteme in ihren Produkten einsetzen und die qualitative Entwicklung des Linux-Ökosystems massiv voran getrieben haben.

Mit dem immer größer werdenden Einzug von Linux im industriellen Umfeld steht somit der Einsatz von Open Source für Softwareentwickler also auch auf der Tagesordnung, da es sich bei Linux um ein Open Source Betriebssystem handelt. Allerdings herrscht für viele Entwickler nach wie vor immer noch große Unsicherheit über Rechte und Pflichten beim Einsatz von Open Source Software, welches auch die Motivation für diesen Blog-Artikel war. Da das ganze Thema bei Betrachtung aller technischen, juristischen und organisatorischen Aspekte sehr umfangreich sein kann, liegt der Fokus hier in erster Linie auf ein paar kurze, aber wichtige Informationen und Links beim generellen Umgang mit Open Source Software und zur weiteren Einarbeitung.

Was ist Open Source?

Open Source ist in erster Linie eine Software-Nutzungs-Lizenz. Das bedutet, dass die Software, die unter "Open Source" steht, uneingeschränkt benutzt werden, untersucht und verändert werden kann, welches natürlich den Quelltext voraussetzt. Ein Open Source Programm darf auch weiter gegeben werden, wobei die eventuellen Verpflichtungen eingehalten werden müssen, die daraus entstehen. Bei der Weitergabe müssen also die genannten Rechte des Urhebers vollständig erhalten bleiben. In Langform: "Open Source"-Software ist eine Software, die von Rechteinhabern unter einem bestimmten Typ einer Software-Lizenz gestellt wurde, welcher in den Open Source Definitions (OSD) der Open Source Initiative (OSI) festgelegten Anforderungen erfüllt. Die unterschiedlichen Lizenzen von Open Source-Software unterscheiden sich in erster Linie darin, unter welche Lizenz Bearbeitungen gestellt werden müssen. Als Stichwort sei hier das sogenannte Copyleft genannt. Dieser Umstand ist sehr bedeutsam, denn dass bei erstmaliger Erwähnung einer Lizenz einer Open Source Software diese sich viral über abgeleitete Software-Pakete auswirkt. Eine Lizenz mit Copyleft ist beispielsweise die GPL. Über die Hintergründe zur Entstehung von Open Source und vieles mehr, siehe [1] [2] [5].

Einhaltung der Lizenz-Rechte - nicht so einfach wie gedacht!

Da Informatiker in der Regel juristische Laien sind und nicht in jedem Unternehmen ein Hausjurist zur Verfügung steht, der sich auch noch mit diesen speziellen Themen auseinandersetzt, geschweige denn auf Experten-Niveau auskennt, fangen also die Probleme bei dessen Einhaltung an. Seit ein paar Jahren gibt es nämlich zudem (ehemalige) Autoren von Open Source Software, die Unternehemn z.B. wegen Verletzung der GPLv2-Lizenz abmahnen. Als ein bekannter Vertreter sei hier Patrick McHardy genannt. Zahlreiche Unternehmen, darunter auch große, mussten schon Beträge im mittleren Fünfstelligen Bereich zahlen und teilweise auch Unterlassungserklärungen abgeben. Neben den juristischen Problemen bei Nichteinhaltung der Pflichten, besteht zudem die Gefahr von z.B. hohen Umbaukosten von bereits produzierten Geräten. Auch wenn Open Source Software zwar so gesehen nichts kostet, werden aber in aller Regel Bedingungen zu dessen Einsatz gestellt. Als Nicht-Jurist könnte man nun zu der Meinung gelangen, dass Lizenzen etwa Entwickler in ihrer Arbeit behindern - das Gegenteil ist der Fall! Lizenzen sind an sich immer etwas Gutes, denn sie erlauben etwas, was normalerweise nicht gestattet wird. Wenn also keine Lizenz bei einer Software bzw. in dessen Quelltext vorhanden ist, tritt immer das Urheberrecht ein, dass die Nutzung der Software verbietet. Siehe [1] [3].

Für die Industrie ist 2006 die OSADL gegründet worden. Es handelt sich hierbei um eine Genossenschaft, die sich zum Ziel gesetzt hat, die Entwicklung von Open Source-Software für den Maschinen- und Anlagenbau und für die industrielle Automation zu fördern und zu koordinieren [4]. Speziell beim Know-How-Aufbau rund um das Thema Open Source mit Linux kann die Genossenschaft Unternehmen hier helfen und bietet ihren Mitgliedern, gegen Münzeinwurf in Form eines jährlichen Mitgliedsbeitrags, zusätzlich diverse Vorteile und juristische Hilfestellung durch ein Expertennetzwerk. Des Weiteren wird die koordinierte Weiterentwicklung von dringend benötigten Embedded-Linux-Features für die Industrie bzw. deren Genossenschaftsmitgliedern hier voran getrieben. Ein Besuch lohnt sich hier allemal, da auch die Website für Nicht-Mitglieder viele Interessante Informationen liefert.

Technische Analyse

Aus technischer Sicht muss zunächst einmal identifiziert werden, in welchen eigens hergestellten Programmen/Komponenten Open Source zum Einsatz kommt. Das kann mitunter sehr aufwändig sein bis zu dem Punkt, an dem es manuell gar nicht mehr zu leisten ist, z.B. im Cloud-Umfeld, wenn bestimmte Services als Docker-Container mit eigener Linux-Distribution zum Einsatz kommen und diese ganz nebenbei noch noch als On-Premise-Variante beim Kunden laufen kann. Im gewählten Beispiel tritt man dann sogar als Vertreiber einer Linux-Distribution auf, die in der Regel allerdings nur unverändert weiter gegeben darf. Abgesehen von solchen Schwierigkeiten existiert im gewähltem Beispiel in der Regel ein ganzer Zoo von Open Source-Lizenzen, wobei sich einige dieser Lizenzen in ihrer Nutzung sogar ausschließen können, also juristisch betrachtet schlichtweg inkompatibel sind! Als Beispiel sei nur die Verwendung von Komponenten erwähnt, die einmal unter der Apache 2.0 vs. GPLv2-Lizenz stehen, wobei hier auf die Erklärungen zum Copy-Left verwiesen wird [1].

Typische Forderungen von Open Source Software-Komponenten sind zum Beispiel:

  • Lizenztexte mitliefern- viele Lizenzen fordern, dass dem Endkunden der vollständige Lizenztext über alle verwendenten Open Source Komponenten zur Verfügung gestellt wird
  • Quelltext anbieten - die GPL und auch LGPL fordern beispielsweise, dass der Quelltext der darunter fallenden Komponenten mitgeliefert werden muss, oder mindestens für mehrere Jahre auf Anforderung beim Hersteller auslieferbar bleibt.
  • Copyright-Nenneung - je nach ausgeliefertem Produkt, wo Open Source Komponenten vorhanden sind, muss vom Hersteller entweder ausgedruckte Lizenzen beigefügt werden, oder aber z.B. in einer GUI zur Anzeige gebracht werden
  • Keine direkte Verbindung mit unfreien (Closed-Source) Programmen - Open Source-Komponenten, die beispielsweise unter die GPL fallen (aber nicht nur die!) dürfen nicht mit Code, der nicht frei ist, zu einem Programm zusammengeführt bzw. gelinkt werden. Ein reines Beilegen ist jedoch fast immer erlaubt.

Tools zur Identifikation von Open Source Komponenten

In diesem Zusammenhang sind über die Jahre verschiedene Werkzeuge entstanden, mit der die Identifikation von eingesetzten Open Source Komponentne erleichtert werden soll. Der Markt ist hier derzeit stark in Bewegung. Je nach Umfang der eingesetzten Open Source Software-Komponenten - und natürlich auch nach Geldbeutel - empfiehlt sich das eine oder das andere Tool. Eine pauschale Aussage dazu kann hier nicht gegeben werden.

Unter den kostenfreien Werkzeugen sei FOSSology in Verbindung mit ScanCode genannt. Die beiden Werkzeuge (GUI und CLI-Tool) arbeiten auf Grundlage von Dateien bzw. Codezeilen. Dieser Ansatz kennt jedoch keine Software-Komponente als Ganzes, dass allerdings mehr oder weniger hohen zusätzlichen manuellen Aufwand beim Bündeln der Dateien zu Komponenten mit sich bringt. Gibt es eine neue Version von z.B. BusyBox, dann müssen bei jedem Update die Dateien wieder zusammen analysiert und gebündelt werden. Aus professioneller Sicht ist das nur ein probates Mittel, wenn wenige Open Source Komponenten verwendet werden.

Neben den freien Werkzeugen giibt es noch eine Reihe von kommerziellen Anbietern, wobei ich hier nur drei nennen möchte: Black Duck, WhiteSource und Fossa.

Alle drei Werkzeuge können mit Open Source Komponenten dahingehend gut umgehen, dass sie den Code gut analysieren können. Bei Fossa gibt es allerdings derzeit keine Möglichkeit Docker-Container o.ä. zu analysieren, welches den Einsatz gerade für verteilte Systeme erschwert. Die Analyse-Qualität auf Code-Ebene und Metadaten der OSS-Komponenten ist gerade bei den beiden zu erst genannten Produkten hervorragend und es kann schnell ein Überblick über dort verwendeten Komponenten erzeugt werden. Auch die Versionierung der eingesetzten Open Source Komponenten wird unterstützt, zumindest bei Black Duck. Auch in Punkto .NET-Ökosystem konnte z.B. Black Duck und WhiteSource beim Umgang mit nuget-Paketen punkten, als auch im Umgang mit npm-Paketen bei node.js. Bei der Unterscheidung zwischem dynamischen vs. statischem Linken (z.B. für die GPL-Lizenz wichtig) ist bislang nur Black Duck in der Lage. Bei WhiteSource gelingt dies derzeit nur mit gewissen Work-Arounds. Alle Tools verfügen über eine schicke Web-Oberfläche, die nach einer gewissen Einarbeitung jedoch intuitiv bedienbar ist und wo der Entwickler seinen "Open Source-Zoo" im Überblick hat.

Wer gute Ergebnisse haben will, muss allerdings auch dafür bezahlen. Die Preise liegen gerade bei den zuerst genannten Produkten momentan zwischen 5000€ und 15000€ pro Lizenz und pro Jahr. Es ist also eine klassische Make-or-Buy Entscheidung, die man hier treffen muss, ob es das Geld gegenüber dem Aufwand wert ist, den man ggf. investieren muss, um mit dem Thema Open Source möglichst korrekt umzugehen. Fairerweise muss man hier noch hinzufügen, dass zumindest Black Duck und WhiteSource noch weitere Funktionen anbieten, wie die Untersuchung auf potentielle Sicherheitslücken in jeder verwendeten Komponente und z.B. die Meldung von Policy-Verletzungen, wenn beispielsweise keine AGPL- oder Sleepycat-Lizenz verwendet werden darf. Dies hilt dem Entwickler, sich an gültige Unternehmensrichtlinien zu halten.

Organisatorische Themen

Aus organisatorischer Sicht sind hier ebenfalls einige Dinge zu tun, insbesondere dass sich nicht nur der Kreis der Entwickler mit dem Thema auseinander setzt, sondern auch Personen aus den Führungsetagen - als Stichwort sei hier die Unternehmens-Compliance erwähnt, denn der klassische Angestellte kann beispielsweise bei Verstößen gegen das Urheberrecht nicht dafür haftbar gemacht werden, wenn es keinerlei Regeln im Unternehmen dazu gibt. Im Wesentlichen geht es hier um die Einhaltung gesetzlicher Vorschriften und Verordnungen, der Einhaltung von genrellen Standards und die Erfüllung von Code of Cunducts. Erfahrungsgemäß fällt das berühmte Kind allerdings erst in den Brunnen, bevor Prozesse und Standards "von oben" etabliert werden. Falls das Thema im Unternehmen also noch relativ neu ist, gilt es das also rechtzeitig an die Verantwortlichen zu adressieren, damit Dokumente und Prozesse etabliert werden können, Mitarbeiter geschult und ggf. externe Audits durchgeführt werden. Folgende Maßnahmen könnten hier getroffen werden:

  • Erarbeitung einer Checkliste beim Check-In von Quellcode durch interne und ggf. externe Mitarbeiter (Freelancer) [3]
  • Aufsetzen einer unternehmensweit gültigen Open Source Policy, die jeder betroffene Entwickler unterzeichnen sollte
  • Schaffung der Position des "Open Source Officers", der Schulungen organisiert, Prozesse mit derenTool-Chains weiterentwickelt und deren Umsetzung regelmäßig prüft (jedoch nur sinnvoll in größeren Unternehmen)
  • Last but not least: Etablierung einer modernen "Open Source"-Unternehmenskultur, d.h. insbesondere Softwareentwicklern erlauben, während der Arbeitszeit an Open Source Projekten mitarbeiten zu lassen
  • Durchführung von rechtlichen Prüfungen, was benutzt und/oder veröffentlicht werden darf

Veröffentlichung von Software mit Open Source

Wenn der Entwicklungsprozess abgeschlossen ist und das Gerät serienreif ist, geht's an die Auslieferung. Bei der Auslieferung von Geräten mit vorinstallierter Firmware/Software, die Open Source-Komponenten enthält, sollte in jedem Fall folgendes beachtet werden:

Auslieferung der Lizenztexte

Die Lizenztexte können entweder z.B. auf dem Webserver des Gerätes zur Anzeige gebracht werden, falls dieser vorhanden ist. Alternativ muss ein Datenträger mit den Lizenztexten beim Gerät beigelegt oder oder diese in gedruckter Form ausgeliefert werden.

Auslieferung des Quelltexts

Im optimalen Fall geschieht die Auslieferung des Quelltexts auf dem Gerät selbst, oder dieser muss auf einem Datenträger bereitgestellt werden. Ein sogenanntes "Written Offer" sollte aber in jedem Fall in gedruckter Form beigelegt werden oder auf dem Webserver eingesehen werden können. Wichtig bei der Auslieferung der Quellen ist es, dass diese von einer externen Person vollständig kompiliert werden können. [5]

Hinweis auf verwendete Open Source Komponenten

Es sollte ein Hinweis hinterlegt werden wo Informationen zu den Open Source Komponenten zu finden sind. Wenn es eine Art Beipackzettel mit den Informationen gibt, ist es damit schon erledigt. Ansonsten sollte ein Aufdruck auf den Gehäuse des Gerätes (bevorzugt) oder auf den Beipackzettel ein Link zu der Webseite des Gerätes aufgedruckt sein.

Fazit

Wenn während eines Software-Projekts, optimalerweise am Anfang, klar wird, dass Open Source-Softwarekomponenten in wie auch immer gearteter Form zum Einsatz kommen, sind genügend Zeit bzw. Resourcen einzuplanen, um die genannten Themen im ausreichendem Maße zu behandeln. Zudem sollte man bereits am Anfang möglichst hohe Transparenz und Dokumentation über verwendete Open Source Komponenten in Form von Tools und Dokumentation schaffen, weil typischerweise der Aufwand hinterher dafür unverhältnismäßig hoch wird und dann vielleicht doch noch Lizenzen auftauchen, die man sich ungewollt eingehandelt hat und die die Veröffentlichung des Produkts schwierig gestalten. Da das Thema Open Source, beziehungsweise die Einhaltung von Lizenzen, vor allem ein juristisches Thema ist, sollte man sich zumindest einmalig entsprechend professionelle Hilfe vor Veröffentlichung des Produkts einholen.

Links

[1] Leitfaden zu Open Source Software (Bitkom)

[2] The Open Source Definition (Open Source Initiative)

[3] Open Source und Compliance (Embedded-Software Engineer)

[4] Open Source Automation Development Lab (OSADL)

[5] Open Source Software - nicht Freibier aber auch nicht unbegrenzte Freiheit (Informatik Aktuell)

Wir benutzen Cookies
Diese Seite enthält Cookies. Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren und die Zugriffe auf unsere Website zu analysieren.