Open Source vs. proprietäre Software: eine Entscheidungshilfe

Die Frage wird meist als Glaubensfrage geführt, ist aber eine Beschaffungsfrage. „Open Source“ und „proprietär“ bezeichnen keine Qualitätsstufen, sondern zwei Rechtsverhältnisse: Im einen Fall dürfen Sie den Quellcode lesen, ändern, selbst bauen und weitergeben, im anderen erwerben Sie ein Nutzungsrecht an einem Ergebnis, dessen Herstellung Ihnen verschlossen bleibt. Alles, was in Vergleichen sonst genannt wird – Kosten, Support, Sicherheit, Anpassbarkeit –, folgt aus diesem Unterschied, ist aber nicht durch ihn festgelegt.

Die kurze Antwort: Entscheiden Sie nicht zwischen Kategorien, sondern pro Dimension gegen Ihre tatsächlichen Randbedingungen. Open Source ist im Vorteil, wenn die Software lange läuft, tief in Ihre Systeme greift, an Ihren Betrieb angepasst werden muss oder wenn Sie die Verfügungsgewalt über Daten und Ablauf behalten wollen. Proprietäre Software ist im Vorteil, wenn ein Anbieter etwas beibringt, das Sie nicht selbst herstellen wollen – vertragliche Haftung, eine Zertifizierung, Hardwarebindung, spezialisiertes Domänenwissen – und der Funktionsumfang Ihre Kernanforderung ohne Eigenbau abdeckt. Kippt die Entscheidung, kippt sie fast immer an zwei Zahlen: dem Kostenverlauf über die erwartete Laufzeit und den Kosten des Ausstiegs.

Dieser Artikel liefert den Rahmen dafür: acht Vergleichsdimensionen in einer Tabelle, eine Einordnung der Mischformen Open Core, Source Available, BSL und Dual Licensing, einen ehrlichen Abschnitt darüber, wann proprietär die richtige Wahl ist, und ein Bewertungsverfahren, das Sie in einem Repository dokumentieren und in zwei Jahren nachvollziehen können.

Zwei Rechtsverhältnisse, nicht zwei Qualitätsstufen

Open Source

Software, deren Lizenz Nutzung, Studium, Veränderung und Weitergabe – auch in veränderter Form – ohne Diskriminierung von Personen, Gruppen oder Einsatzfeldern erlaubt. Maßgeblich ist allein die Lizenz, nicht die Sichtbarkeit eines Repositories: öffentlich lesbarer Code ohne entsprechende Lizenzgewährung ist nicht Open Source, sondern lediglich einsehbar.

Innerhalb von Open Source ist die zweite Unterscheidung wichtiger als die erste: permissiv gegen Copyleft. Permissive Lizenzen wie MIT, BSD-3-Clause oder Apache-2.0 verlangen im Wesentlichen Namensnennung und Lizenzweitergabe; Apache-2.0 enthält zusätzlich eine ausdrückliche Patentlizenz und eine Klausel zur Beendigung bei Patentklagen. Copyleft-Lizenzen binden die Weitergabe an dieselben Freiheiten: GPL-3.0 für das gesamte abgeleitete Werk, LGPL-3.0 abgeschwächt für Bibliotheksverwendung, MPL-2.0 auf Dateiebene, AGPL-3.0 zusätzlich für den Fall, dass Nutzer die Software nur über ein Netzwerk erreichen. Für eine Software, die Sie ausschließlich intern betreiben, ist die Unterscheidung meist unkritisch. Für Software, die Sie ausliefern oder als Dienst anbieten, entscheidet sie über die Zulässigkeit Ihres Geschäftsmodells.

Proprietäre Lizenzen kehren die Logik um: Erlaubt ist, was der Vertrag ausdrücklich einräumt. Typische Beschränkungen betreffen die Anzahl der Nutzer, Kerne oder Instanzen, die Umgebung (Test gegen Produktion), die Weitergabe, das Reverse Engineering und Veröffentlichungen über Benchmarks. Ein Quellcode-Escrow-Vertrag mildert das Insolvenzrisiko, ersetzt aber keine Änderungsfähigkeit: Sie erhalten im Auslösefall einen Stand, den niemand in Ihrem Haus baut, testet oder versteht.

Acht Dimensionen, an denen die Entscheidung wirklich hängt

Dimension	Open Source	Proprietär	Entscheidungsfrage
Quellcodezugang	Vollständig lesbar und selbst baubar; Verhalten am Code prüfbar	Kein Zugang; allenfalls Einsicht unter NDA oder Escrow im Auslösefall	Müssen Sie Fehler selbst lokalisieren oder Verhalten auditieren können?
Lizenzkosten und Kostenverlauf	Keine Lizenzgebühr; Kosten in Betrieb, Integration, Personal und optionalem Supportvertrag	Subscription nach Metrik (Nutzer, Kern, Node, Datenvolumen); Preisanpassung und Audit-Nachforderung möglich	Wie skaliert der Preis mit Ihrer Nutzung, und wer kontrolliert die Preisformel?
Support und Haftung	Community ohne Zusage; verbindliche Reaktionszeiten über Distributor, Hersteller oder Dienstleister zukaufbar	Vertraglicher Support mit definierten Zeiten und benannter Haftung	Brauchen Sie einen Vertragspartner, der im Störfall einsteht?
Roadmap-Einfluss	Patch, Upstream-Beitrag, im Extremfall Fork; die Governance bestimmt die Reichweite	Feature-Request ohne Anspruch; Priorisierung nach Umsatzrelevanz	Ist eine für Sie kritische Funktion notfalls erzwingbar?
Exit-Kosten	Datenmodell und Formate einsehbar; Weiterbetrieb der letzten Version rechtlich möglich	Nutzungsrecht endet mit dem Vertrag; Export nur im angebotenen Umfang	Was kostet der Wechsel in Personentagen und Parallelbetrieb?
Sicherheitsprozess und Transparenz	CVE- und OSV-Einträge, Commits und Security-Tracker öffentlich; Fix selbst backportbar	Offenlegung nach Ermessen des Anbieters; Korrektur ausschließlich durch ihn	Wie schnell erfahren Sie von einer Lücke, und können Sie unabhängig reagieren?
Anpassbarkeit	Konfiguration, Plugin, Patch, Fork – unter Beachtung der Lizenzpflichten	API, Konfiguration und offizielle Erweiterungspunkte; kein Eingriff in den Kern	Liegt ein Unterschied, der für Sie zählt, im Verhalten dieser Software?
Betriebsmodell	Self-Hosting, eigene Region, Betrieb ohne Internetzugang möglich; Betriebslast liegt bei Ihnen	Häufig SaaS-Bindung oder Appliance; Betrieb beim Anbieter	Wo dürfen die Daten liegen, und wer soll den Betrieb tragen?

Die Tabelle beschreibt Tendenzen, keine Automatismen. Ein Open-Source-Projekt mit einem einzigen Maintainer bietet weniger Verlässlichkeit als ein etablierter Anbieter mit Wartungsvertrag, und ein proprietäres Produkt mit dokumentiertem Datenmodell und offenem Exportformat ist leichter zu verlassen als eine offene Anwendung, deren Schema seit Jahren undokumentiert wächst. Die Dimensionen sind Messpunkte, nicht Vorurteile.

Kostenverlauf statt Listenpreis

Der häufigste Fehler beider Lager ist die Verwechslung von Lizenzkosten mit Gesamtkosten. Open Source verschiebt Kosten aus der Lizenzzeile in Betrieb, Integration und Personal; sie verschwinden nicht. Proprietäre Modelle machen die erste Rechnung sichtbar und die zweite verhandelbar – mit dem Unterschied, dass Sie die Verhandlungsposition nicht kontrollieren. Rechnen Sie deshalb über die erwartete Laufzeit, üblicherweise fünf bis zehn Jahre, und tragen Sie beide Seiten vollständig ein: Subscription oder Betriebspersonal, Integrationsaufwand, Schulung, Supportvertrag, Aufwand für Lizenz-Audits, Migrationskosten am Ende und – der oft übersehene Posten – erzwungene Upgrades, wenn eine Version das Ende ihres Wartungszeitraums erreicht.

Achten Sie besonders auf die Preismetrik. Eine Lizenz pro CPU-Kern verhält sich in einer Kubernetes-Umgebung mit horizontaler Skalierung völlig anders als in einem statischen Serverpark. Eine Metrik pro Nutzer bestraft Erfolg, eine Metrik pro verarbeitetem Datensatz bestraft Wachstum. Diese Kurven, nicht der Einstiegspreis, entscheiden nach drei Jahren über das Budget.

Sicherheitsprozess und die Transparenz von Schwachstellen

Offener Quellcode wird nicht dadurch sicher, dass er offen ist. Der Unterschied liegt im Prozess: Bei Open Source sind Schwachstellenmeldung, Fix-Commit, CVE-Zuordnung und Distributionspatch nachvollziehbar. Sie können den Zeitraum zwischen Meldung und Korrektur messen, den Patch lesen, ihn auf eine ältere Version backporten und die Betroffenheit Ihres Systems anhand von OSV-Daten und einer eigenen Stückliste bestimmen. Bei proprietärer Software erfahren Sie, was der Anbieter mitteilt, und Sie warten auf einen Fix, den nur er liefern kann. Beides ist ein Prozess mit Vor- und Nachteilen: Der offene Weg verlangt eigene Kapazität, der geschlossene verlangt Vertrauen.

Beide Modelle brauchen dieselbe Grundlage: eine belastbare Inventur dessen, was tatsächlich läuft. Erzeugen Sie diese aus dem Build, nicht aus Herstellerangaben.

# Stückliste aus dem gebauten Artefakt erzeugen, nicht aus der Anbieterdokumentation
syft dir:. -o cyclonedx-json=sbom.cdx.json

# Lizenzverteilung sichtbar machen; Ausreißer und Unbekannte zuerst prüfen
jq -r '.components[] | ((.licenses[0].license.id // .licenses[0].expression) // "UNBEKANNT")' \
  sbom.cdx.json | sort | uniq -c | sort -rn

# Bekannte Schwachstellen gegen dieselbe Stückliste prüfen
grype sbom:sbom.cdx.json --fail-on high
osv-scanner scan source --sbom=sbom.cdx.json

Wie sich dieser Schritt in einen laufenden Prozess überführen lässt, beschreibt der Artikel zur Absicherung der Software Supply Chain. Für proprietäre Komponenten ersetzt die vertragliche Zusage über Meldefristen die technische Prüfbarkeit – lassen Sie sie sich schriftlich geben, denn die europäische Regulierung verlangt zunehmend genau diese Nachweisbarkeit: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) staffelt Melde- und Dokumentationspflichten für Produkte mit digitalen Elementen bis Dezember 2027 ein und betrifft offene wie geschlossene Software in der Rolle des Herstellers.

Exit-Kosten als gemessene Zahl

Exit-Kosten sind die einzige Dimension, die Sie vor der Entscheidung experimentell bestimmen können und fast niemand bestimmt. Führen Sie den Ausstieg im Pilotbetrieb einmal durch: vollständige Kopie der eigenen Daten ohne Mitwirkung des Anbieters, dokumentierte Formate, geprüfte Vollständigkeit.

# Exit-Test im Pilotbetrieb: alle eigenen Daten ohne Anbieterunterstützung sichern
pg_dump --format=directory --jobs=4 --file=/srv/exit/db "$DATABASE_URL"
mc mirror --preserve objectstore/dokumente /srv/exit/blobs
curl -sS -H "Authorization: Bearer $TOKEN" \
  'https://api.example.internal/v1/export?scope=all' -o /srv/exit/api.json

# Nachweis führen statt hoffen: Mengen und Summen gegen das laufende System vergleichen
psql "$DATABASE_URL" -c 'select count(*) from documents;'
find /srv/exit/blobs -type f | wc -l
sha256sum /srv/exit/api.json | tee /srv/exit/api.json.sha256

Was der Test kostet, ist die Zahl, die in die Entscheidung gehört: Personentage für Export, Transformation, Neuimplementierung der Schnittstellen, Parallelbetrieb und Schulung. Welche Architekturentscheidungen diese Zahl dauerhaft klein halten – Abstraktion an genau einer Stelle, offene Formate an den Grenzen, keine Geschäftslogik in herstellerspezifischen Erweiterungen –, behandelt der Beitrag zur Vermeidung von Vendor Lock-in; die Umsetzung im Systementwurf gehört in die Softwarearchitektur.

Mischformen: Open Core, Source Available, BSL und Dual Licensing

Die meisten Produkte, über die heute entschieden wird, sind keine der beiden Reinformen. Die Bezeichnung im Marketingmaterial trägt dabei wenig – maßgeblich ist die SPDX-Kennung der Lizenz, unter der die Version läuft, die Sie einsetzen wollen.

Open Core

Ein Produktmodell, bei dem ein funktionsfähiger Kern unter einer OSI-konformen Lizenz steht, während Funktionen für den Unternehmenseinsatz – typischerweise Single Sign-on, feingranulare Rechteverwaltung, Audit-Protokolle, Hochverfügbarkeit, Mandantenfähigkeit – nur in einer kommerziellen Edition enthalten sind.

Modell	Was die Lizenz zulässt	Wo das Risiko liegt
Open Core	Kern frei nutzbar, änderbar, weitergebbar; Zusatzmodule nur nach Vertrag	Die Grenze zwischen Kern und Edition verschiebt sich über Releases; genau die Funktionen, die Compliance verlangt, liegen häufig außerhalb
Source Available	Code lesbar, Nutzung eingeschränkt – etwa das Verbot, die Software als konkurrierenden Managed Service anzubieten (Elastic License 2.0, SSPL)	Kein Open Source im Sinne der OSD; Weitergabe und Fork rechtlich beschränkt, Ökosystem an Distributionen bricht weg
BSL 1.1	Nutzung innerhalb des Additional Use Grant frei; darüber hinaus erst nach der Change Date, dann unter einer GPL-kompatiblen Change License	Produktionsnutzung kann heute lizenzpflichtig sein; die Version, die frei wird, liegt bis zu vier Jahre zurück
Dual Licensing	Dieselbe Codebasis unter Copyleft (GPL, AGPL) oder gegen Entgelt unter kommerzieller Lizenz (etwa Qt, MySQL)	Wer nicht copyleft-konform ausliefern kann, zahlt; das Modell setzt Rechtebündelung beim Hersteller über einen CLA voraus

Diese Modelle sind nicht illegitim – sie finanzieren Entwicklung, die sonst nicht stattfindet. Sie verändern aber die Risikolage, und zwar dynamisch: Lizenzwechsel sind in beide Richtungen dokumentiert. Terraform wechselte 2023 zur BSL, worauf die Community OpenTofu abspaltete; Redis wechselte 2024 zu einer quelloffenen, aber nicht OSD-konformen Lizenz, worauf Valkey entstand, und ergänzte 2025 wieder AGPLv3 als Option. Was daraus für die Praxis folgt, ist unspektakulär und wichtig: Prüfen Sie, ob das Projekt unter einer Stiftung mit verteilten Rechten steht oder unter einem Unternehmen mit CLA, das die Lizenz einseitig ändern kann. Diese Frage gehört in jede Open-Source-Strategie, lange bevor sie akut wird.

Wann proprietär die richtige Wahl ist

Es gibt Fälle, in denen die offene Alternative der schlechtere Entwurf ist, und sie zu benennen gehört zu einer belastbaren Empfehlung.

• Zertifizierte Werkzeugketten. Wo eine Zulassung nach ISO 26262, IEC 61508 oder einem Medizinprodukterecht am Nachweis der Werkzeugqualifikation hängt, ist die Zertifizierung des Anbieters der eigentliche Kaufgegenstand. Diesen Nachweis selbst zu erbringen kostet mehr als jede Lizenz.
• Hardwarenahe Nischen. EDA-Werkzeuge, Messtechnik-Software, Steuerungssysteme mit Herstellerprotokollen: Wenn die Software die Bedienbarkeit einer konkreten Maschine ist, wird kein offenes Projekt den Ersatz leisten.
• Vertraglich getragenes Risiko. Wenn ein Ausfall messbar teurer ist als die Subscription und Sie die Reaktionsfähigkeit nicht selbst aufbauen wollen, ist der Support-Vertrag ein rational eingekaufter Versicherungsschutz.
• Fehlende Betriebskapazität. Selbstbetrieb, den niemand pflegt, ist teurer und unsicherer als ein zugekaufter Dienst. Diese Ehrlichkeit über die eigene Personallage ist Teil der Entscheidung, nicht ihr Gegner.
• Domänenlogik, die niemand nachbaut. Fachanwendungen mit jahrzehntelang eingearbeiteten Regeln – Tarifwerke, Abrechnungsvorschriften, branchenspezifische Meldewege – sind praktisch nicht reimplementierbar.

Ein Bewertungsverfahren, das reproduzierbar bleibt

Eine Entscheidung, die in zwei Jahren niemand mehr begründen kann, ist keine Entscheidung, sondern eine Erinnerung. Halten Sie die Bewertung deshalb versioniert im Repository fest.

Ein Datensatz pro Kandidat, maschinenlesbar, mit gemessenen statt geschätzten Werten:

# docs/evaluations/dms-candidate-a.yml
candidate: candidate-a
spdx_license: GPL-3.0-only        # Kennung, nicht das Wort "Open Source"
model: community                  # community | open-core | source-available | proprietary
tested_version: ''
governance:
  steward: ''                     # Stiftung, Unternehmen oder Einzelperson
  contributor_agreement: ''       # dco | cla | keins
  unilateral_relicensing_possible: null
maintenance:
  releases_last_12_months: null
  distinct_committers_last_12_months: null
  median_days_to_security_fix: null
operations:
  deployment: self-hosted         # self-hosted | saas | appliance
  air_gapped_possible: null
cost:
  price_metric: ''                # user | core | node | volume | keine
  ten_year_total_eur: null
exit:
  data_export: ''                 # welcher Weg, welches Format
  formats_documented: null
  measured_switch_effort_person_days: null
decision: ''                      # shortlist | pilot | reject
decision_review_date: ''

Dieses Protokoll ist der eigentliche Ertrag des Verfahrens: Es macht die Entscheidung überprüfbar und die Wiederholung günstig. Wenn Sie das Vorgehen für einen konkreten Fall aufsetzen oder eine bestehende Landschaft entlang dieser Dimensionen bewerten wollen, ist das der Gegenstand unserer Open-Source-Beratung.

Fazit

Die Kategorien Open Source und proprietär beantworten keine Auswahlfrage, sie strukturieren sie. Wer die acht Dimensionen einzeln prüft, kommt bei langlebiger, tief integrierter Software regelmäßig zu offenen Technologien, weil Verfügungsgewalt und niedrige Exit-Kosten dort den Ausschlag geben – und bei zertifizierten, hardwarenahen oder fachlich einmaligen Systemen ebenso regelmäßig zu einem Anbieter, der das Risiko vertraglich trägt. Mischformen wie Open Core, Source Available und BSL verlangen dieselbe Prüfung, nur genauer: pro Version, pro Lizenzkennung, pro Governance-Modell. Die beiden Zahlen, die Sie unbedingt messen sollten, sind der Kostenverlauf über die erwartete Laufzeit und der im Pilotbetrieb tatsächlich durchgeführte Exit. Alles andere ist Meinung.