Open Source Software: Vorteile nutzen und Risiken vermeiden

Anzeige

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?

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

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.

 

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“

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

 

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.

»Size Matters« – jedenfalls bei der Nutzung von Open Source in Unternehmen 

 

»Zuerst die gute Nachricht« heißt es einleitend im Open Source Monitor [1]. Fast 70 % der befragten Unternehmen in Deutschland setzen Open-Source-Lösungen ein. Diese Zahl steigt drastisch an, wenn sich Unternehmen an der Schwelle zum Großunternehmen befinden. Sieben von zehn Unternehmen mit 200 bis 499 Beschäftigten geben an Open-Source-Software einzusetzen. Drei Viertel der Firmen mit…

Open Source: Jedes dritte Unternehmen entwickelt mit

 

Unternehmen wollen durch Open Source Geld sparen – aber auch Mitarbeiter weiterbilden und die Community unterstützen Bitkom veröffentlicht Studienbericht »Open Source Monitor« Open-Source-Software ist längst viel mehr als das abendliche Freizeitprojekt von Computer-Nerds. Rund jedes dritte größere Unternehmen in Deutschland (31 Prozent) beteiligt sich heute bereits an der Entwicklung von Open-Source-Software. Das hat eine Umfrage…

Deutscher Mittelstand hat Nachholbedarf bei Umsetzung und Strategie im Bereich Open Source

 

Der diese Woche veröffentlichte »Bitkom Open Source Monitor 2019« belegt: Die Mehrheit der deutschen Unternehmen steht Open-Source-Software aufgeschlossen gegenüber. Dabei ist es vor allem der Mittelstand – der Motor der deutschen Wirtschaft –, der besonderes Interesse an Open Source zeigt. Das Potenzial von Open-Source-Software wird klar erkannt: Finanzielle Einsparungen durch den Wegfall von Lizenzkosten, hohe…

ERP-Systeme – Open Source vs. Closed Source

 

Der Entscheidungskampf zwischen Open-Source- und Closed-Source-Softwarelösungen wird weiterhin mit vollem Eifer gefochten. Auch im ERP-Bereich kann man keinen generellen Sieger ernennen. Beim Entschluss zu einem Für oder Wider sollten einige wichtige Kriterien, wie Innovationsfähigkeit, Support, Sicherheit, Leistung, Preis oder Unternehmensgröße, bei der Entscheidungsfindung berücksichtigt werden.

In 5 Schritten zum Open Source Software Defined Storage

 

Die Anforderungen für Speichersysteme sind in den letzten Jahren immer weiter gestiegen, Agilität, Flexibilität und die schnelle Bereitstellung von Ressourcen sind in einer bi-modalen IT die großen Herausforderungen. Wir haben heute mit mobilen und IoT-Geräten weitaus mehr Endpunkte, an denen Daten generiert werden, als noch vor einigen Jahren denkbar gewesen wäre. Besonders Videoinhalte verbreiten sich…

Open Source: Kollaboration und Transparenz für eine offene Kultur

 

Die heutige Business-Landschaft ist von schnellen Veränderungen geprägt, nicht zuletzt bedingt durch die Digitale Transformation und neue Technologien. Sie modifizieren die Art, wie Geschäftstätigkeiten ausgeführt oder Services bereitgestellt werden. Digitale Transformation bedeutet aber wesentlich mehr als den Einsatz neuer Tools, es geht dabei auch um die Transformation von Kultur, Werten und Prozessen. Red Hat ist…

IT-Infrastruktur: Cloud und Open Source liegen vorn

 

Die Cloud-Adaption in Deutschland nimmt immer weiter zu. Über 85 Prozent der deutschen Unternehmen beschäftigen sich aktiv mit der Cloud. Mehr als ein Viertel der Unternehmen setzen Cloud-Services bereits als festen Bestandteil im Rahmen ihrer IT-Strategie ein. Deutschland ist ein Open-Source-Land. Für rund 80 Prozent der deutschen Unternehmen haben Open-Source-Technologien eine große Bedeutung und sind ein zentraler Bestandteil…

Open Source als herausragende Architektur und Innovationstreiber

 

Open Source birgt auch weiterhin Herausforderungen in Bezug auf Sicherheit und Management. Die Umfrageergebnisse der zehnten »Future of Open Source Survey« von 2016 zeigen, dass Open Source mittlerweile nicht nur in der Architektur eine wesentliche Rolle spielt, sondern auch die Grundlage für nahezu alle Anwendungen, Betriebssysteme, Cloud-Computing-Lösungen und Big Data ist [1]. »Bei der ersten…

Open Source als Schlüsselelement erfolgreicher DevOps-Strategien

 

Open-Source-Lösungen gehören zu den Toptechnologien, die aktuell oder künftig in DevOps-Umgebungen genutzt werden; dazu zählen das Linux-Betriebssystem, ein Infrastructure-as-a-Service (IaaS) wie OpenStack oder ein Platform-as-a-Service (PaaS) wie OpenShift. So lautet ein zentrales Ergebnis des von Red Hat gesponsorten IDC-InfoBrief »DevOps, Open Source and Business Agility«, der auf der Befragung von 220 US-amerikanischen und europäischen IT-Entscheidern…

Open Source: Sicherheit durch Transparenz

 

Der Vergleich zwischen proprietärer Software und Open-Source-Software ist so alt wie die IT-Industrie selbst. Für so gut wie jede Softwarekategorie gibt es Angebote von Herstellern, die ihren Code entweder alleine entwickeln und vertreiben oder Entwicklergemeinden, die dies an offenem Code tun. Die Ablehnung, offene Software zu nutzen, hat sich vor allem in Unternehmen im letzten…

Würth Phoenix auf der CeBIT: Open Source System Management vom Feinsten

 

Auf der diesjährigen CeBIT, die vom 16. bis 20. März in Hannover stattfindet, dreht sich bei Würth Phoenix alles um Open Source System Management. Im Mittelpunkt steht der neueste Release von NetEye, der zahlreiche Verbesserungen und Innovationen zur Verwaltung komplexer IT-Landschaften mitbringt. Zum jährlichen Branchengipfel in der niedersächsischen Hauptstadt reist Würth Phoenix mit gleich drei…

BOM: Open-Source-Risiken (immer) im Auge behalten

 

Es ist kaum anzunehmen, dass Oberstufenschüler ihrem Berufsberater »Chief Inventory Officer« als ihren persönlichen Traumberuf vorschlagen – falls es diesen Titel überhaupt gibt. Er klingt auf jeden Fall kaum nach Glamour, Prestige oder aufregender Tätigkeit – vielmehr nach eintöniger Arbeit wie in noch nicht komplett vergangenen Tagen: mit dem Klemmbrett im Warenlager.   Dennoch ist…

70 Prozent aller Anwendungen haben Open-Source-Schwachstellen

 

Fehlerhafte Bibliotheken landen auf indirektem Wege im Code. Einsatz von PHP-Bibliotheken führt mit über 50-prozentiger Wahrscheinlichkeit zu fehlerhaftem Code. JavaScript und Ruby haben besonders große Angriffsflächen.   Der neue »State of Software Security (SoSS): Open Source Edition«-Report zum Thema Sicherheit in Open-Source-Software von Veracode zeigt unter anderem auf, dass 70 Prozent aller gescannten Anwendungen mindestens…

Ein Open-Source-Business-Modell gibt es nicht

 

Open-Source-Technologie entfaltet ihre Wirkung dann am besten, wenn sie Bestandteil von Strategien und Taktiken zur Unterstützung eines Kern-Business-Modells ist – und nicht umgekehrt. Open-Source-Business-Modelle sind in aller Munde, da mag der Titel dieses Artikels vielleicht etwas sonderbar anmuten, vor allem, weil der Artikel von jemandem stammt, dessen Job es ist, ein Ökosystem rund um ein…

5 Grundsätze sicherer Open-Source-Software

 

Kaum ein Softwareprojekt beginnt heute noch auf der grünen Wiese. Das können sich Entwickler und Unternehmen in Zeiten immer schnellerer Release-Zyklen nicht leisten. Um Zeit und Kosten zu sparen, entscheiden sie sich deshalb oft für Open-Source-Bibliotheken. Dabei sollte man aber bedenken, dass die Open-Source-Komponenten, die aus Millionen von bestehenden Bibliotheken entnommen werden, auch Schwachpunkte in…

Einstiegstipps: Wie man mit Open-Source-Projekten beginnt

 

Es gibt unzählige Gründe, warum es sich lohnt, an Open-Source-Projekten mitzuwirken, vom beruflichen Aufstieg bis zur Unterstützung einer Community. Man muss kein Experte sein, um ein Open-Source-Projekt zu unterstützen, und nicht einmal Code schreiben können, um einen Beitrag zu leisten. Die Möglichkeiten sind vielfältig und viele Communitys, wie Rubrik Build, akzeptieren Code- und Nicht-Code-Beiträge. Rubrik…

Master Data Management per Open-Source-Plattform: Ein Unternehmen, eine Datenplattform

 

  Auf dem Weg zur Digitalisierung stehen Unternehmen auch vor der Aufgabe, ihre Stammdaten effizienter zu organisieren. Dafür braucht es ein unternehmensübergreifendes Stammdaten-System, in dem alle Daten in hoher Qualität, einschließlich ihrer Relationen untereinander, hinterlegt und abgerufen werden können. Für die technische Umsetzung bieten sich Open-Source-Plattformen als zukunftsfähige und kostengünstige Lösung an.   Daten werden…

Das IT-Jahr 2019 aus Open-Source-Sicht

 

  Kaum hat das Jahr begonnen, schauen wir gespannt auf die IT-Trends die Unternehmen 2019 unbedingt im Blick haben sollten. Open-Source-Experte Michael Jores, verantwortlich für die Geschäfte von SUSE in Zentraleuropa, erwartet für 2019 viele beachtenswerte Entwicklungen: Die Blockchain wird immer mehr auch außerhalb der Finanzwelt eingesetzt werden: Durch Kryptowährungen ist die Blockchain eng mit…

Trotz WannaCry & Co. erhalten Open-Source-Komponenten keine angemessene Aufmerksamkeit

 

Studie zeigt: Weniger als 25 Prozent der Entwickler testen Komponenten bei jeder Veröffentlichung auf Schwachstellen. Laut einer von Studie von CA Veracode aktualisieren nur 52 Prozent der Entwickler ihre kommerziellen oder Open-Source-Komponenten, wenn eine neue Sicherheitslücke veröffentlicht wird. Dies verdeutlicht das mangelnde Sicherheitsbewusstsein vieler Unternehmen und setzt sie dem Risiko von Sicherheitslecks aus. Die Studie,…