Open Source Software zu nutzen, ist bei deutschen Unternehmen schon lange gang und gäbe, denn sie bringt ihnen viele Vorteile. Warum Unternehmen dabei auf kommerzielle Open-Source-Produkte setzten sollten, lesen Sie im Folgenden.

Illustration: Absmeier, Pixabay

Bei Open Source Software (OSS) denken die meisten Anwender an kostenlose Software. Tatsächlich kann OSS gratis sein – muss sie aber nicht. In erster Linie bedeutet Open Source, dass der Quellcode offen und frei verfügbar ist. Jeder kann ihn einsehen, kopieren, weiterverteilen, dauerhaft nutzen und sogar verändern. Mehr als zwei Drittel der deutschen Unternehmen setzen bereits Open Source Software bewusst ein. Bei den größeren Betrieben ab 2.000 Mitarbeitern sind es sogar 86 Prozent, so eine Studie des Branchenverbandes Bitkom. OSS hat neben Kosteneinsparungen noch viele weitere Vorzüge. Zu den wichtigsten zählen Transparenz, Verfügbarkeit und Nachhaltigkeit. Bei OSS liegt der Quellcode offen. Jeder, der sich dafür interessiert, kann ihn einsehen. Unternehmen können OSS zudem so lange und in der Form nutzen, wie es ihnen gefällt. Darüber hinaus sind Investitionen in OSS sicher: Dadurch, dass sie immer weitergegeben wird, existiert sie unabhängig von einem einzelnen Hersteller. Viele Basistechnologien werden zudem durch lizenzkostenfreie Bereitstellung einfach verfügbar. Das beginnt bei freier Anwendersoftware und geht über viele Serversysteme wie Datenbanken, Webserver oder Kommunikationssysteme bis hin zu Softwarebibliotheken, die für die Erstellung von IT-Produkten frei genutzt werden können.

Ist Open Source Software sicher?

Jede Software ist potenziell unsicher, dies gilt für proprietäre Software wie für Open Source. Die Intuition macht uns erst einmal skeptisch: Wenn die Quellen offen liegen, gefährdet das nicht die Sicherheit? Tatsächlich ist es jedoch gerade die Transparenz, die OSS sogar sicherer macht als proprietäre Software. Da der Quellcode offen liegt, kann er von jedem geprüft werden. Viele Augen sehen viel und Open-Source-Lösungen können nichts verbergen. So können Anwender sicher sein, dass zum Beispiel auch keine Hintertüren eingebaut sind. Da Anbieter von proprietärer Software keinen Einblick in ihren Quellcode gewähren, müssen die Anwender versuchen, ein ähnliches Sicherheitsniveau durch andere Maßnahmen zu erreichen, wie die Prüfung auf Schwachstellen oder die systematische Beobachtung des Verhaltens der Software. Dies kann eine freie Verfügbarkeit des Quellcodes nicht ersetzen, ist aber bei Lösungen, für die es keine Open-Source-Alternative gibt, ein gangbarer Weg. Zudem erhöht die meist höhere Frequenz von Updates und Patches die Sicherheit und zählt laut der Bitkom-Studie zu den wichtigsten Vorteilen von Open Source Software. Fehlerfrei ist jedoch auch Open Source Software nicht, und sie muss genauso sorgsam betrieben werden wie proprietäre Alternativen. Aber sie ist sicherlich – wo einsatzfähig verfügbar – die bessere Wahl.

Welche Vorteile birgt der Einsatz von kommerzieller OSS?

Open Source Software gibt es häufig sowohl als kostenlose als auch kommerzielle Version. Bevor sich Unternehmen für eine Variante entscheiden, sollten sie sich aber der möglichen Vorteile der kommerziellen Lösung bewusst sein, die besonders beim professionellen Einsatz entscheidend sein können. Open-Source-Anbieter stellen Support und Gewährleistung ausschließlich für ihre kommerziellen Produktlinien bereit, da dies der Kern ihres Geschäftsmodells ist. Nur dann gibt es auch SLAs, die festgelegte Leistungen garantieren. Technisch lassen sich auch die freien Varianten betreiben, aber dann muss das Anwenderunternehmen selber Wissen aufbauen und die Verantwortung für die Sicherheit und Funktionalität der Anwendung übernehmen. Dazu gehört auch, die Aktivitäten in der Community genau im Auge behalten, wichtige Updates und Patches herunterladen, testen und zeitnah einspielen. Alle diese Aufgaben erfordern den Erwerb und Erhalt von Expertenwissen, und erzeugen damit hohen Aufwand in den meist ohnehin schon stark belasteten IT-Abteilungen. Open-Source-Hersteller können sich dagegen auf ihr Produkt fokussieren und lernen von den vielen einsetzenden Kunden. Da Software im Unternehmensumfeld sicher und stabil laufen muss, ist es daher meist ratsam, auf kommerzielle Open-Source-Varianten zu setzen – sonst kann die vermeintliche Kostenersparnis schnell ins Gegenteil umschlagen oder die erhoffte Verbesserung der Sicherheit nicht erzielt werden.

Fazit

Kommerzielle Open Source Software ist für den Einsatz im professionellen Umfeld optimiert. Sie lässt sich einfach installieren, läuft stabil und punktet mit vereinfachtem Management, Gewährleistung und Support. Außerdem bietet sie häufig zusätzliche Services, die einen wertvollen Mehrwert bringen. Zu den wichtigsten Vorteilen für einsetzende Unternehmen gehört – vergleichbar wie bei proprietären Produkten – einen Ansprechpartner zu haben, der beratend und unterstützend zur Seite steht und das Produkt auch im Sinne der Unternehmen weiterentwickelt. So ist der Kunde dank offenem Source Code in vielerlei Hinsicht sicherer aufgestellt als mit Produkten proprietärer Anbieter.

Wer die kommerzielle Variante von OSS nutzt, kann so von den Vorteilen profitieren, ohne sich von den Risiken ausbremsen zu lassen.

Elmar Geese, COO bei Greenbone

Open-Source-Lizenzen: Keine Lizenz, große Probleme?

13. Oktober 2020

Illustration: Absmeier, Progressor

In der modernen Softwareentwicklung werden die dazu nötigen Komponenten wie Puzzleteile aus verschiedenen Quellen zusammengestellt. Open-Source-Komponenten haben daran einen ständig wachsenden Anteil. Der 2020 Open Source Security and Risk Analysis (OSSRA) Bericht hat gezeigt, dass 99 % der überprüften Codebasen Open Source und 100 % der Codebasen aus neun der 17 berücksichtigten Branchen mindestens eine Open-Source-Komponente enthalten [1]. Unternehmen entscheiden sich im Wesentlichen aus zwei Gründen für Open Source: Sie wollen bei der Softwareentwicklung schneller vorankommen und sie wollen Kosten senken. Dabei gerät leicht in Vergessenheit, dass Open Source zwar bei der Anschaffung keine Kosten verursacht, aber sehr wohl für das Management der Komponenten, und es bestehen Risiken, wenn diese Komponenten Teil einer kommerziellen Codebasis werden.

Eine bereits im letzten Jahr durchgeführte Untersuchung hat ergeben, dass es im Bereich Open Source 2.700 Lizenzpermutationen gibt [2]. Was aber passiert, wenn eine Komponente gar keine Lizenz hat? In der besagten Untersuchung war das bei rund einem Drittel der untersuchten Codebasen der Fall: 33 % wiesen keine der üblichen Lizenzen auf. Es gibt einige typische Szenarien wie unlizenzierte Open Source in eine Codebasis einfließen kann. Werden solche Komponenten in kommerzielle Apps eingebunden, hat das weitereichende Auswirkungen.

Gewährung von Rechten

Bevor wir uns aber mit diesen Implikationen beschäftigen, sollte man wissen, was genau eine Softwarelizenz bewirkt. Eine Lizenz gewährt Rechte. Wer eine Software verwenden will, egal ob es sich um Open Source oder kommerzielle Software handelt, braucht dazu ein gewisses Maß an Rechten, das ihm über die betreffende Lizenz gewährt wird. In vielen Ländern ist kreative Arbeit (zu der auch die Entwicklung einer Software gehört) standardmäßig durch das Urheberrecht geschützt. Das heißt, niemand kann und darf diese Software ohne ausdrückliche Genehmigung des Urhebers/Autors legal verwenden, kopieren, verteilen oder verändern. Diese Genehmigung erfolgt in Form einer Lizenz, die die entsprechenden Rechte gewährt. Ohne diese Lizenz geht man davon aus, dass es jemandem nicht erlaubt ist, die betreffende Software zu verwenden.

Das Einbinden einer Open-Source-Komponente ohne Lizenz in eine kommerzielle Anwendung, ist für ein Unternehmen fraglos problematisch. Unternehmen, die nicht lizenzierten Code verwenden, sind einem höheren Risiko ausgesetzt, gegen das Urheberrecht zu verstoßen, als Unternehmen, die eindeutig lizenzierte Komponenten verwenden. Ohne Lizenzgewährung ist es für einen Benutzer deutlich schwieriger auszumachen, welche Rechte er hat, ja sogar, ob er überhaupt welche hat.

Wie nicht lizenzierte Open Source ihren Weg in nicht lizenzierte Komponenten findet

Eine nicht lizenzierte Komponente kann auf unterschiedlichen Wegen in eine Codebasis gelangen. Der direkte Weg ist, wenn der Urheber (und Copyright-Inhaber) bei der Erstellung der Open-Source-Komponente keine Lizenz ausgewählt oder zugewiesen hat. Man könnte davon ausgehen, dass eine fehlende Lizenz bedeutet, dass man die betreffende Komponente frei nutzen darf. Aufgrund des Urheberrechtsgesetzes existiert aber keine Rechtegewährung ohne ausdrückliche Genehmigung des Urhebers/Autors. Diesen Komponenten fehlt also die Genehmigung, sie zu verwenden, zu verändern oder zu verteilen. In solchen Situationen muss ein Unternehmen entscheiden, wie risikofreudig es sein will. Verwendet eine Firma trotz fehlender Rechtegewährung eine solche Komponente, kann das zu einem kostspieligen und zeitaufwändigen Rechtsstreit wegen Verstoß gegen das Recht an geistigem Eigentum führen. Das klingt auf den ersten Blick wie ein Sonderfall, aber genau dieses Szenario betrifft allein in der eingangs zitierten Untersuchung rund ein Drittel der untersuchten Codebasen.

Modifizierte Komponenten

In einem anderen, nicht untypischen Szenario modifizieren Entwickler eine Open-Source-Komponente, damit diese eine bestimmte, benötigte Funktion erfüllt. Bei diesen Modifikationen werden beispielsweise die Header-Datei oder die Benutzer-/Lizenzinformationen geändert oder entfernt. Die Sache hat natürlich einen Haken. Bindet man eine Komponente ein, ohne die zugehörige Lizenz zu verstehen, wie soll man dann sicherstellen, dass man die entsprechenden Rechte hat, den Code so zu verwenden, wie man ihn verwenden will. Deshalb sollte man zumindest eine forensische Untersuchung durchführen, was die Herkunft der Komponente anbelangt. Nur dann kann der Entwickler vorab gewährleisten, alle mit der Lizenz verbundenen Verpflichtungen einzuhalten. Wer das erst spät im Entwicklungszyklus oder mitten in einer M&A-Due-Diligence-Prüfung tut, der verschwendet unnötig Zeit und Ressourcen [3].

Open Source Snippets

Das letzte der drei typischen Szenarien ist nicht ganz so simpel. Entwickler nutzen beim Schreiben von Code nicht selten Open Source-Code-Snippets aus populärem Quellen wie etwa Stack Overflow. Snippets sind sehr kleine Bestandteile einer Komponente, die eine bestimmte Funktion erfüllen. Snippets, die aus Bezugsquellen wie Stack Overflow stammen, haben allerdings so gut wie nie anwendbare Lizenzbedingungen. Mancher fragt sich vielleicht, ob ein Snippet an und für sich überhaupt urheberrechtlich geschützt ist. Mit anderen Worten: Steckt in einem Snippet (ausreichende) Kreativität? Oder handelt es sich hierbei um rein funktionalen Code, der von vorneherein nicht urheberrechtsfähig und daher auch nicht lizenzpflichtig ist? Schlussendlich läuft auch diese Debatte darauf hinaus, wie risikofreudig ein Unternehmen ist. Die Schwelle ist niedriger als in den anderen Fällen, angesichts der Diskussion, ob ein Stück Code kreativ genug ist, damit der Urheberrechtsschutz greift. Im schlimmsten Fall wird allerdings ein Gericht entscheiden, und das Unternehmen muss den Code aus der Anwendung entfernen. Das kostet Zeit, Geld, und man ist gezwungen einen nicht ganz unerheblichen juristischen Aufwand zu betreiben.

Open Source und doppelte Lizenzierung

Ein Bereich, der juristisch besonders relevant ist, ist das Durchsetzen von Lizenzen. Die Betrachtungsweise bei der Durchsetzung von Lizenzen beziehungsweise Compliance-Aktivitäten hat sich in den letzten Jahren gewandelt. Sie ist inzwischen weit weniger ideologisch als rein kommerziell getrieben. Wenn Unternehmen sich gegen Unternehmen wenden, wirft das für Open-Source-Benutzer eine Reihe von Bedenken auf. Denn dann geht es nicht mehr primär darum »das Richtige zu tun«, sondern darum, Umsatzverluste zu vermeiden und Wettbewerbsvorteile zu sichern.

Das klassische Beispiel für die kommerziell motivierte Lizenzdurchsetzung ist die sogenannte doppelte Lizenzierung [4]. Dabei können Unternehmen, die das Urheberrecht innehaben, sich entscheiden, denselben Code unter 2 separaten Lizenzen zu lizenzieren. Sie lizenzieren ihren Code dann unter einer traditionellen OEM-ähnlichen Lizenz für jeden, der diesen Code wiederverwenden oder in ein kommerzielles Produkt einbetten möchte– und der das ohne Bedenken wegen eines General Public Licence (GPL) Copyleft tun will. Unterliegt eine Software einem Copyleft, muss der Nutzer diese Rechte bei Weitergabe (mit oder ohne Softwareänderung, Erweiterung oder der Wiederverwendung von Softwarebestandteilen) beibehalten. Bei der GPL ist beides der Fall. Derselbe Lizenzgeber kann gleichzeitig denselben oder einen im Wesentlichen identischen Code unter der GPL für diejenigen lizenzieren, die diesen Code intern verwenden wollen oder die keinerlei Bedenken hinsichtlich der möglichen Auswirkungen eines GPL-Copyleft haben, aus welchem Grund auch immer.

Es gibt eine Reihe von Gründen, warum Unternehmen einen unter GPL lizenzierten Code in kommerziellen Anwendungen verwenden, wo sie eine OEM-Lizenz hätten zahlen und verwenden sollen, die der beabsichtigten oder tatsächlichen Nutzung entspricht. Entweder fehlt ein gutes Open-Source-Management oder das Unternehmen handelt fahrlässig, wenn nicht sogar vorsätzlich. In solchen Szenarien ist es mehr als wahrscheinlich, dass der Lizenznehmer auch gegen andere Lizenzanforderungen verstößt. Das wiederum ist eine direkte Urheberrechtsverletzung. Die GPLv2, unter der zahlreiche solcher Fälle auftreten, hat keine Klausel zur Behebung. Jeder Verstoß gegen die GPLv2 führt zum sofortigen Entzug der aus der Lizenz gewährten Rechte. Damit ist jede weitere Nutzung der Software nicht mehr lizenziert.

Im Falle einer Doppel-Lizenzierung lässt sich der Schadensersatz ausnahmsweise relativ einfach berechnen. Der Lizenzgeber muss dazu nur einen Blick auf sein OEM-Business werfen und die Lizenzgebühren für den Fall der legitimen Nutzung von Anfang an berechnen. Double Licensing ist nicht der einzige Fall dieser Art, aber er ist anschaulich und er kommt häufig vor.

Fazit

Open Source ist ein unverzichtbares und kritisches Element der modernen Softwareentwicklung. Das Tempo der Softwareentwicklung nimmt weiter zu, Code wird immer komplexer. Damit steigt auch der Bedarf, Open-Source-Komponenten in Echtzeit zu verwalten.

Unternehmen und juristische Berater sollten deshalb von sich aus aktiv werden. Sie sollten vor allem darüber nachdenken, wie ihr Unternehmen Open-Source-Code einsetzt und wie die betreffenden Produkte verbreitet werden, und, ob diese Prozesse den Geschäfts-, Sicherheits- und Compliance-Zielen entsprechen. Die Herausforderungen sind zugegebenermaßen vielschichtig. Der erste Schritt ist immer eine Analyse dessen, wie gut ein Unternehmen über die Verwendung von Code in seinen Produkten Bescheid weiß. Juristische Berater sollten unbedingt die nötige Expertise im Bereich Open Source mitbringen, um ihre Mandaten angemessen zu beraten.

Matthew Jacobs, Director, Legal Counsel, Synopsys

[1] https://www.synopsys.com/software-integrity/resources/analyst-reports/2020-open-source-security-risk-analysis.html

[2] https://www.synopsys.com/blogs/software-security/top-open-source-licenses/

[3] https://www.synopsys.com/software-integrity/solutions/mergers-and-acquisitions.html

[4] https://www.synopsys.com/blogs/software-security/software-licensing-decisions-consider-dual-licensing/

Google-Initiative soll Open-Source-Projekte schützen

11. Juli 2020

Illustration: Absmeier, Michael Shannon

Google hat jetzt seine Marktmacht in den Dienst einer Initiative zum Schutz der Integrität von Open-Source-Projekten gestellt. Die Entscheidung, die eingetragenen Warenzeichen von Open-Source-Projekten besser zu schützen, steht vor dem Hintergrund, dass eine Reihe von äußerst erfolgreichen Projekten stark dadurch beeinträchtigt wurden, dass Public Cloud Provider die Angebote mit eigenen Managed-Services-Angeboten unterboten hatten.

Im vergangenen Jahr berichtete die New York Times darüber, dass Amazon Web Services (AWS) Open Source Software von Elastic kopiert und in seine eigenen Elasticsearch-Dienste integriert hatte. Computer Weekly hatte kurz zuvor berichtet, dass sowohl MongoDB als auch Redis ihre Produktangebote dahingehend verändert hatten und zukünftig zwischen einer komplett freien und einer lizenbasierten Version des Produktes unterscheiden wollten. Letztere richtet sich ausdrücklich an Organisationen, die das Produkt im Rahmen von Managed Services vermarkten wollen.

Laut Google ist es für die langfristige Zukunftsfähigkeit solcher Projekte entscheidend, die betreffenden Trademarks und ihren Geltungsbereich zu verstehen und zu verwalten. Das gilt umso mehr angesichts der stetig wachsenden Zahl von Unternehmen, die Open-Source-Software in ihren Produkten verwenden. Die Initiative unter dem Namen Open Usage Commons hat es sich zum Ziel gesetzt, die Philosophie und Definition von Trademarks in Open-Source-Projekten auszudehnen.

Weitere Informationen finden Sie im Beitrag von https://www.computerweekly.com/news/252485848/Google-commits-to-protecting-open-source-projects .

Dazu ein Kommentar von Tim Mackey, Senior Security Strategist bei Synopsys:

»Die Gründung der Open Usage Commons Initiative unterstreicht zwei Dinge. Zum einen, dass Open Source inzwischen Mainstream geworden ist, und zum anderen, dass damit auch die üblichen Probleme des Mainstreams verbunden sind. Das wiederum sind nicht unbedingt die Probleme, mit denen Entwickler sich typischerweise befassen. In diesem Fall geht es konkret um Trademarks. In und außerhalb der Open Source Community sind Linux und das Logo, Tux, der Pinguin, weithin als Marke bekannt. Die Logos und eingetragenen Warenzeichen vieler anderer populärer Projekte sind demgegenüber sehr viel weniger bekannt. Teil des Problems ist, dass die Open Source Community einen ausgesprochen guten Job gemacht hat, als es darum ging das Copyright des Quellcodes in Form von Open-Source-Lizenzen zu schützen. Dieselbe Community hat allerdings vergleichsweise geringe Anstrengungen unternommen, um das Erscheinungsbild der eigenen Marke und die damit verbundenen Markenzeichen wirksam zu schützen.

Oder lassen Sie es mich anders formulieren. Wenn man nicht selbst aktiv in ein bestimmtes Projekt involviert war, wie will man dann wissen, dass es sich tatsächlich um die »offizielle« Projektversion handelt? Es gibt keine Open-Source-Software-Firmen oder Anbieter – das heißt, oftmals gibt es keine der typischen Erkennungszeichen einer Marke, um den Status des Projekts auch anhand dessen zu überprüfen.

In der Welt der physischen Waren genauso wie in der der kommerziellen Software, investieren Hersteller und Anbieter Unsummen in klare, eindeutige Trademarks als Teil ihrer Go-to-Market-Strategie. Wenn ein Projekt zu einem wesentlichen Teil unter Beteiligung der betreffenden Unternehmen zustande kommt, wie das etwa bei Xen, Redis oder MongoDB der Fall ist, dann ist es sehr wahrscheinlich, dass in diesem Zusammenhang Trademarks erstellt werden, um auch das Open-Source-Investment zu monetarisieren.

Ziel der Open Usage Commons Initiative ist es, Möglichkeiten zu finden, diese Praxis auszudehnen. Das schützt beide, die Nutzer und die Produzenten/Urheber von Open-Source-Software. Zudem verspricht dieser Ansatz mehr Klarheit zu schaffen, was Eigentumsrechte und Urheberschaft von Open-Source-Projekten im Markt anbelangt.«

629 Artikel zu „open source“

NEWS | IT-SECURITY | AUSGABE 3-4-2020 | SECURITY SPEZIAL 3-4-2020

Augen auf beim Einsatz von Third-Party-Komponenten – Risikofaktor Open Source

3. Mai 2020

Im Zuge der Digitalisierung entwickelt sich Open-Source-Software auch in Deutschland, Österreich und der Schweiz zu einem wichtigen Baustein agiler Entwicklungsumgebungen. Der quelloffene Code ermöglicht es Unternehmen, wirtschaftlicher zu agieren und ihre Anwendungen schneller zur Marktreife zu führen – doch er birgt auch Risiken. Mittelständler, Konzerne und Regierungseinrichtungen sind daher gut beraten, passgenaue Strategien für eine sichere Open-Source-Nutzung zu entwickeln.