OPEN SOURCE · 01 / 06
Wir entwickeln Software, deren Quelltext offen ist, und arbeiten in bestehenden Open-Source-Projekten mit. Das umfasst neue Komponenten ebenso wie Erweiterungen fremder Codebasen, Upstream-Beiträge anstelle dauerhafter Forks sowie Lizenz-, Release- und Governance-Fragen. Der Maßstab ist einfach: Eine Anpassung muss nach dem nächsten Upstream-Release noch einspielbar sein.
Ausgangslage
Der häufigste Bruch entsteht dort, wo eine Anpassung an fremdem Code als Patch im eigenen Deployment liegt und nie zurückfließt. Nach zwei oder drei Upstream-Releases greift der Patch nicht mehr, das Update wird verschoben, und irgendwann läuft eine Version, für die es keine Sicherheitsaktualisierungen mehr gibt. Der Fork war nie eine Entscheidung – er ist einfach entstanden.
Umgekehrt scheitern Veröffentlichungen an fehlender Vorarbeit. Ein Repository wird öffentlich gemacht, in dessen Historie noch Zugangsdaten liegen, die Lizenzdatei fehlt, Copyright-Header widersprechen sich, und die Herkunft einzelner Dateien ist nicht mehr nachvollziehbar. Nachträglich lässt sich das nur über ein Umschreiben der Historie und eine Rechteklärung reparieren – deutlich teurer als eine geordnete Vorbereitung vor dem ersten öffentlichen Push.
Lizenzkonflikte fallen meist zu spät auf: eine GPL-lizenzierte Bibliothek in einem Produkt, das als geschlossenes Binary ausgeliefert wird, AGPL-Code in einem gehosteten Dienst, oder die Kombination von Apache-2.0 mit GPL-2.0-only, die sich nicht vereinbaren lässt. Wer das erst im Audit eines Kunden klärt, tauscht Komponenten unter Zeitdruck aus oder verhandelt Ausnahmen, die bei früherer Prüfung gar nicht nötig gewesen wären.
Und schließlich der Betrieb des Projekts selbst: Issues ohne Antwort, Pull Requests, die monatelang liegen bleiben, kein Changelog, Tags ohne Bezug zu den ausgelieferten Artefakten, ein Release, das nur eine Person auf ihrem Rechner bauen kann. Das Ergebnis ist ein Projekt, das formal offen ist, an dem aber niemand mitentwickeln kann – und dessen Wissen an einzelnen Köpfen hängt.
Vorgehen
Vor der ersten Zeile klären wir Herkunft und Rechte: Was ist Eigenentwicklung, was stammt von Dritten, welche Lizenzen gelten. Abhängigkeiten inventarisieren wir maschinell als SBOM in CycloneDX oder SPDX und prüfen die Kompatibilität gegen das geplante Auslieferungsmodell. Erst danach fällt die Lizenzentscheidung: MIT für Bibliotheken ohne weitere Auflagen, Apache-2.0 dort, wo eine ausdrückliche Patentlizenz gewünscht ist, GPL oder AGPL, wenn Änderungen offen bleiben sollen.
Anpassungen an bestehender Open-Source-Software gehen upstream. Wir zerlegen sie in einzeln begründete Commit-Serien, richten sie an den Konventionen des Projekts aus – Coding-Style, Tests, DCO- oder CLA-Anforderungen – und begleiten sie durch den Review. Was noch nicht akzeptiert ist, bleibt als benannte Patch-Serie in einer Queue: einzeln rebasebar, dokumentiert, jederzeit entfernbar, statt als undurchsichtiger Diff im Build zu verschwinden.
Releases sind reproduzierbar und automatisiert. Version aus dem Git-Tag, Changelog aus der Commit-Historie, Build im Container mit gepinnten Basis-Images, signierte Artefakte, veröffentlichte Prüfsummen. Paketiert wird für die Zielumgebung: Debian-Paket, OCI-Image, PyPI- oder npm-Paket, bei Go und Rust auch ein statisch gelinktes Binary. Die Pipeline läuft in Forgejo Actions oder einem vergleichbaren CI-System und ist bewusst nicht an eine einzelne Arbeitsumgebung gebunden.
Ein offenes Projekt braucht lesbare Regeln. Dazu gehören ein README mit Build- und Betriebsanleitung, CONTRIBUTING mit den Erwartungen an Beiträge, SECURITY.md mit Meldeweg, CODEOWNERS für Zuständigkeiten und semantische Versionierung mit dokumentierten Deprecation-Fristen. Issue-Triage läuft in fester Kadenz statt nach Tagesform. Das macht Beiträge von außen praktikabel und den Wechsel von Personen im Team unkritisch.
Leistungsumfang
01
02
03
04
05
06
07
Einsatzfälle
Eine angepasste Version einer Open-Source-Anwendung lässt sich nicht mehr aktualisieren. Wir zerlegen die Abweichungen, bringen das Tragfähige upstream und reduzieren den Rest auf eine pflegbare Serie.
Ein intern gewachsenes Werkzeug soll veröffentlicht werden. Vor der Freigabe klären wir Rechte, Historie, Lizenz, Build-Dokumentation und die Frage, wer künftig Beiträge annimmt.
Statt eine zweite Anwendung daneben zu stellen, erweitern wir das eingesetzte Projekt an der vorgesehenen Stelle und geben die Änderung zurück – so bleibt der Update-Pfad offen.
Ein Produkt enthält Open-Source-Komponenten und muss prüfbar ausgeliefert werden. Wir erzeugen SBOM, Lizenzhinweise und den Quelltext-Zugang, den Copyleft-Lizenzen verlangen.
Ergebnis
Ablauf
Fragen
Nein, der reine Einsatz löst keine Veröffentlichungspflicht aus. Entscheidend ist die Weitergabe: Copyleft-Lizenzen wie die GPL verlangen den zugehörigen Quelltext erst dann, wenn Sie das Programm oder ein davon abgeleitetes Werk an Dritte weitergeben. Die AGPL-3.0 fügt in Abschnitt 13 eine eigene, zusätzliche Pflicht hinzu: Wer eine geänderte Version über ein Netzwerk anbietet, muss den darüber interagierenden Nutzern den Quelltext zugänglich machen – auch ohne Auslieferung von Binärpaketen. Permissive Lizenzen wie MIT verlangen im Kern nur die Weitergabe von Lizenztext und Copyright-Hinweis; bei Apache-2.0 kommen ein Hinweis auf geänderte Dateien und die Weitergabe einer vorhandenen NOTICE-Datei hinzu. Welche Pflichten konkret greifen, prüfen wir je Komponente anhand der Art der Einbindung und des Vertriebswegs.
Das hängt vom Ziel ab. Soll die Software breit eingesetzt und auch in geschlossene Produkte eingebaut werden können, ist Apache-2.0 naheliegend, weil sie zusätzlich eine ausdrückliche Patentlizenz enthält. Soll jede Weiterentwicklung offen bleiben, ist GPL-3.0 das Mittel, bei netzbasierten Diensten AGPL-3.0. Wir entscheiden das anhand des Auslieferungsmodells, der Lizenzen Ihrer Abhängigkeiten und der Frage, wer beitragen soll.
Ein Fork verlagert die gesamte Wartung zu Ihnen: Jede Sicherheitskorrektur im Original muss nachgezogen werden, und jede weitere Änderung erhöht den Rebase-Aufwand. Was upstream akzeptiert ist, pflegt das Projekt mit. Ein Fork ist sinnvoll, wenn die Richtung des Projekts dauerhaft nicht zu Ihren Anforderungen passt – dann aber als bewusste Entscheidung mit eigener Release- und Sicherheitsverantwortung.
Das entscheidet das jeweilige Projekt, nicht wir. Kleine, gut begründete Änderungen mit Tests werden häufig innerhalb von Tagen bis Wochen gemergt, Eingriffe in Kernkomponenten können mehrere Review-Runden und Monate brauchen. Deshalb planen wir Ihre Lieferung nie gegen ein Merge-Datum: Die Änderung läuft als saubere Patch-Serie in Ihrem Build und fällt nach dem Merge einfach aus der Queue heraus.
Ja. Offene Lizenzierung schließt kommerzielle Nutzung nicht aus, auch nicht die eigene. Sie behalten das Urheberrecht an Ihrem Code und können ihn zusätzlich unter anderen Bedingungen anbieten, solange keine fremden Copyleft-Anteile enthalten sind. Bei Beiträgen Dritter setzt eine zusätzliche Lizenzierung deren Zustimmung voraus: Eine DCO-Signatur dokumentiert die Herkunft eines Commits, die dafür nötigen Rechte räumt sie nicht ein – das leistet erst eine Contributor-Vereinbarung. Wir halten deshalb von Beginn an fest, auf welcher Grundlage Beiträge angenommen werden.
Verwandte Leistungen
06 / 06
CONSULTING
02 / 06
ENGINEERING
03 / 06
ARCHITECTURE
Fachartikel dazu
Was offene Software wirtschaftlich bringt, welche Kosten sie nur verschiebt statt streicht und wann proprietär die bessere Wahl bleibt.
Eine Open-Source-Strategie regelt verbindlich, welche Fremdkomponenten hereinkommen, was veröffentlicht wird und wer entscheidet. Aufbau, Rollen, Einführung.
Quellcode, Kostenverlauf, Support, Exit-Kosten: ein sachlicher Entscheidungsrahmen für die Wahl zwischen Open Source, proprietärer Software und Mischformen.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.