Richard Stallman und freie Software: Ideen, die Code veränderten

Warum Richard Stallman immer noch wichtig ist

Software ist nicht nur ein technisches Produkt — sie ist auch eine Reihe von Erlaubnissen. Wer darf sie ausführen, kopieren, mit einem Freund teilen, einen Fehler beheben oder etwas Neues darauf aufbauen? Diese Fragen werden weniger durch Code als durch Lizenzen beantwortet. Als Software zentral für Arbeit, Kommunikation und Forschung wurde, begannen die Regeln darüber, „was erlaubt ist“, die Innovation ebenso zu formen wie die Features.

Richard Stallman (häufig „RMS“ genannt) ist wichtig, weil er diese Regeln unabweisbar machte. Anfang der 1980er Jahre beobachtete er einen Wandel: Mehr Programme wurden ohne Quellcode verteilt, und Nutzer wurde zunehmend gesagt, sie dürften Software nur zu den Bedingungen anderer verwenden. Stallman stellte dies nicht als kleines Ärgernis dar, sondern als Verlust von Nutzer‑ und Entwicklerfreiheit — und er antwortete, indem er klare Prinzipien und rechtliche Werkzeuge vorschlug, um diese Freiheiten zu schützen.

Worum es in diesem Beitrag geht (und worum nicht)

Dieser Artikel konzentriert sich auf Stallmans Ideen und ihre praktischen Konsequenzen: die Definition freier Software, das GNU‑Projekt, Copyleft und die GNU General Public License (GPL) — und darauf, wie diese das moderne Open‑Source‑Ökosystem und die Normen der Softwarelizenzierung geprägt haben.

Es ist keine Biographie und kein technischer Deep‑Dive ins Kernel‑Kompilieren oder Repository‑Management. Du brauchst keinen Programmierhintergrund, um zu folgen.

Eine ausgewogene, zugängliche Sicht

Stallman ist einflussreich und zugleich umstritten. Das Ziel hier ist, faktisch und lesbar zu bleiben: was er argumentierte, welche rechtlichen Mechanismen entstanden, wie Unternehmen und Entwickler reagierten und wo Debatten heute weitergehen — damit du erkennst, warum seine Arbeit alltägliche Softwareentscheidungen noch beeinflusst.

Was „freie Software“ wirklich bedeutet

„Freie Software“ wird leicht missverstanden, weil frei wie ein Preisetikett klingt. Richard Stallman verwendete frei im Sinne von Freiheit — die Fähigkeit der Nutzer, die Software zu kontrollieren, auf die sie angewiesen sind.

Wenn ein Programm 0 € kostet, du es aber nicht inspizieren, ändern oder teilen darfst, kann es „free as in beer“ sein und gleichzeitig in Stallmans Sinn unfrei.

Die vier essentiellen Freiheiten

Freie Software ist durch vier grundlegende Rechte definiert:

• Freiheit 0: Das Programm für jeden Zweck ausführen.
• Freiheit 1: Studieren, wie das Programm funktioniert, und es so ändern, dass es deinen Wünschen entspricht.
• Freiheit 2: Kopien weiterverbreiten, damit du anderen helfen kannst.
• Freiheit 3: Deine veränderten Versionen verbreiten, damit die Gemeinschaft davon profitiert.

Diese Freiheiten betreffen Handlungsmacht: Du bist nicht nur Konsument von Werkzeugen — du kannst Teilnehmer werden, der überprüft, anpasst und verbessert.

Warum Zugang zum Quellcode nicht verhandelbar ist

Freiheiten 1 und 3 sind ohne Zugriff auf den Quellcode — die menschenlesbaren Instruktionen — unmöglich. Ohne ihn ist Software eher ein versiegeltes Gerät: Du kannst es benutzen, aber nicht verstehen, reparieren oder an neue Bedürfnisse anpassen.

Quellcodezugang ist auch wichtig für Vertrauen. Er ermöglicht unabhängige Überprüfungen (für Datenschutz, Sicherheit und Fairness) und macht es möglich, Software auch dann zu pflegen, wenn der ursprüngliche Entwickler nicht mehr unterstützt.

Eine einfache Analogie: Rezepte vs. versiegeltes Essen

Stell dir ein Restaurantessen vor.

• Proprietäre Software ist wie ein versiegeltes, fertig zubereitetes Gericht: Du kannst es essen, kennst aber die Zutaten nicht, kannst das Rezept nicht anpassen und darfst keine Kopien weitergeben.
• Freie Software ist wie das Rezept: Du kannst es zuhause nachkochen, lernen, wie es gemacht wird, es an Allergien anpassen und deine verbesserte Version mit Freund:innen teilen.

Das ist die Kernidee: Freie Software geht um die Freiheiten, die Nutzer brauchen, um die Kontrolle über ihr Rechnen zu behalten.

Das Problem, auf das Stallman reagierte

Bevor „Softwarelizenzierung“ breit diskutiert wurde, beruhte viel Programmierkultur — besonders an Universitäten und in Forschungslabors — auf der Annahme: Wer ein Werkzeug verbessern kann, teilt die Verbesserung. Quellcode reiste mit der Software, Leute lernten durch das Lesen der Arbeit anderer, und Fixes verbreiteten sich informell.

Von Teilungsnormen zu zugesperrter Software

Diese Kultur begann sich zu ändern, als Software zum Produkt wurde. Unternehmen (und einige Institutionen) betrachteten Quellcode als Wettbewerbsvorteil. Verteilungen kamen mit „kein Teilen“-Bedingungen, Code wurde nicht mehr mit Programmen ausgeliefert, und Geheimhaltungsvereinbarungen wurden normal. Für Entwickler, die gewohnt waren, Probleme kollektiv zu lösen, fühlte sich dieser Wandel nicht nur unbequem an — er war eine Regeländerung, die gemeinschaftliches Problemlösen juristisch riskant machte.

Die Druckergeschichte (als Beispiel, nicht als Mythos)

Eine oft erzählte Ursprungsgeschichte handelt von einem Drucker im MIT AI Lab. Stallman beschrieb, wie ein neuer Drucker mit nur in Binärform verteilter Software ankam — ohne Quellcode. Das praktische Problem war banal: Das Labor wollte das Programm anpassen, um etwa Benutzer über Papierstaus zu informieren oder Druckaufträge intelligenter zu routen. Unter den älteren „Hacker“-Normen hätte jemand den Code gepatcht und die Änderung geteilt. Hier konnten sie das nicht — weil sie den Quellcode nicht sehen oder ändern durften.

Wichtig ist die richtige Einordnung: Es war nicht so, dass genau dieser eine Drucker eine globale Bewegung auslöste. Es war ein klares, nachvollziehbares Beispiel für einen breiteren Trend — Werkzeuge, auf die Menschen angewiesen waren, wurden für ihre Nutzer unwartbar.

Warum das zu neuen Lizenzideen führte

Für Stallman ging es nicht nur um technischen Zugang; es ging um den Verlust der Freiheit zur Kooperation. Wenn du nicht studieren kannst, wie ein Programm funktioniert, kannst du es nicht wirklich kontrollieren. Wenn du Verbesserungen nicht teilen kannst, zerfällt die Gemeinschaft, und alle erfinden Fixes privat neu.

Diese Motivation formte die lizenzrechtlichen Innovationen, die folgten. Anstatt sich auf Wohlwollen oder informelle Normen zu verlassen, wollte Stallman Regeln, die die Möglichkeit zu nutzen, zu studieren, zu ändern und zu teilen bewahrten — damit Zusammenarbeit nicht verlorengeht, sobald ein Programm kommerziellen Wert erhält.

Das GNU‑Projekt: Aufbau eines freien Betriebssystems

Stallmans großer Schritt war nicht nur ein Manifest — es war ein praktisches Ingenieursprojekt. 1983 kündigte er das GNU‑Projekt an, mit dem ambitionierten Ziel: ein vollständiges Betriebssystem zu bauen, das jede:r nutzen, studieren, ändern und teilen kann, und dabei Unix‑kompatibel zu bleiben, sodass vertraute Programme und Arbeitsabläufe laufen.

Ein komplettes System, nicht ein einzelnes Werkzeug

Ein Betriebssystem ist kein einzelnes Programm — es ist ein ganzer Stapel. GNU setzte sich zum Ziel, alle alltäglichen Bausteine bereitzustellen, die ein Computer brauchbar machen, darunter:

• Compiler (am bekanntesten GCC), damit Entwickler Code in ausführbare Programme übersetzen können
• Kern‑Kommandozeilen‑Utilities (Basiswerkzeuge zum Kopieren von Dateien, Durchsuchen von Texten, Verwalten von Prozessen)
• Bibliotheken und Entwicklerwerkzeuge zur Unterstützung des Bauens weiterer Software
• Shells und Editoren, um tatsächlich am System zu arbeiten

Einfach gesagt: GNU baute die Rohrleitungen, Verkabelung und Schalter — nicht nur ein einzelnes Gerät.

GNU + Linux: wie die meisten Menschen es kennenlern(t)en

Anfang der 1990er hatte GNU einen großen Teil dieses „Userlands“ produziert, doch ein kritisches Stück fehlte: der Kernel (der Teil, der Hardware und Systemressourcen verwaltet). Als Linux 1991 erschien, schloss es diese Lücke.

Deshalb kombinieren viele heute populäre Systeme GNU‑Komponenten mit dem Linux‑Kernel — oft als „GNU/Linux“ bezeichnet.

Infrastruktur war genauso wichtig wie Ideale

GNU machte die Idee der freien Software real, indem es eine funktionierende Basis schuf, auf der andere aufbauen konnten. Philosophie erklärte, warum Freiheit wichtig ist; GNU lieferte die Werkzeuge, die Freiheit praktisch, wiederholbar und skalierbar machten.

Copyleft in klaren Worten

Copyleft ist eine Lizenzstrategie, die Software frei halten soll (im Sinne von Freiheit) — nicht nur in der ersten Veröffentlichung, sondern auch in zukünftigen Versionen. Wenn du copyleft‑geschützten Code erhältst, darfst du ihn nutzen, studieren, verändern und teilen — aber wenn du deine veränderte Version verteilst, musst du die gleichen Freiheiten an andere weitergeben.

Ein rechtliches Werkzeug auf Basis des Urheberrechts

Copyleft klingt wie „Anti‑Urheberrecht“, baut aber tatsächlich auf dem Urheberrecht auf. Der Autor nutzt sein Urheberrecht, um erlaubende Regeln in einer Lizenz festzulegen: „Du darfst dies kopieren und verändern, aber wenn du es weiterverbreitest, musst du es unter derselben Lizenz halten.“ Ohne Urheberrecht gäbe es keinen rechtlichen Mechanismus, diese Bedingungen durchzusetzen.

Die Idee „share alike“ (mit einfachen Beispielen)

Denk daran als Regel, die dem Code folgt:

• Forks: Du forkt ein copyleft‑Projekt, fügst Funktionen hinzu und veröffentlichst deinen Fork. Du musst den Quellcode veröffentlichen und dieselbe Lizenz beibehalten, sodass andere auch deinen Fork forken können.
• Weiterverteilungen: Du bündelst das Programm in ein Produkt, das du Kunden lieferst. Du darfst Geld verlangen, musst aber Quellcode und dieselben Rechte an die Empfänger weitergeben.

Ziel ist, ein Muster zu verhindern, das Stallman befürchtete: Jemand nimmt gemeinschaftliche Arbeit, verbessert sie und sperrt die Verbesserungen weg.

Copyleft vs. permissive Lizenzen

Permissive Lizenzen (wie MIT oder BSD) erlauben in der Regel fast alles mit dem Code, einschließlich der Weitergabe veränderter Versionen unter einer proprietären Lizenz. Copyleft‑Lizenzen (wie die GNU GPL) erlauben weiterhin umfassende Nutzung und Modifikation, verlangen aber, dass abgeleitete Werke unter denselben Copyleft‑Bedingungen weitergereicht werden — so bleibt die Freiheit stromabwärts erhalten.

Wie die GNU GPL die Lizenzlandschaft veränderte

Die GNU General Public License (GPL) veränderte Softwarelizenzierung, indem sie „Teilen“ in eine durchsetzbare Regel verwandelte, nicht nur in eine nette Geste. Vor der GPL konnte man Quellcode erhalten, ihn verbessern und dann geschlossen weitergeben, sodass Nutzer ihn nicht studieren oder modifizieren konnten. Die GPL kehrte diese Dynamik um: Sie schützt die Freiheiten der Nutzer, indem sie Bedingungen an die Weitergabe knüpft.

Was die GPL gibt — und was sie im Gegenzug verlangt

Praktisch gewährt die GPL den Nutzern das Recht, das Programm für jeden Zweck auszuführen, den Quellcode zu lesen und zu ändern und Original‑ oder veränderte Versionen zu teilen.

Wenn du GPL‑Software weiterverbreitest (insbesondere in einem Produkt), musst du diese Freiheiten weitergeben. Das bedeutet typischerweise:

• Bereitstellung des Quellcodes (oder einer gültigen Bezugsmöglichkeit) für Empfänger
• Beifügen des Lizenztexts und Erhalt von Copyright‑Hinweisen
• Lizenzierung deiner Änderungen unter der GPL, damit nachgelagerte Nutzer nicht „ausgeschlossen“ werden

Pflichten zur Quellcodeverteilung (wann sie gelten)

Die GPL‑Pflichten greifen hauptsächlich, wenn du die Software an andere weitergibst — Binärauslieferungen, Verkauf von Geräten mit der Software oder das Übergeben von Kopien an Kunden. Wenn du GPL‑Code nur intern modifizierst und nicht verteilst, musst du normalerweise den Quellcode nicht veröffentlichen.

„Abgeleitetes Werk“ in einfachen Worten

Du brauchst keine juristische Theorie, um das Wesentliche zu verstehen: Wenn dein Programm GPL‑Code in einer Weise aufnimmt, die ein kombiniertes Werk schafft (z. B. durch Verlinken in deine Anwendung), wird das Ergebnis meist als abgeleitetes Werk behandelt und muss unter der GPL verteilt werden. Ein Programm lediglich auszuführen oder über Standard‑Schnittstellen mit ihm zu kommunizieren, ist oft anders zu bewerten.

GPL‑Varianten: v2, v3 und LGPL

GPLv2 ist die klassische, weit verbreitete Version. GPLv3 ergänzt Schutz gegen Patentvereinbarungen und gegen „Tivoisierung“ (Hardware, die veränderte Software blockiert). Die LGPL ist für Bibliotheken gedacht: Sie erlaubt unter bestimmten Bedingungen das Verlinken aus proprietären Programmen, während die Bibliothek selbst frei bleibt.

Entwicklerrechte — und Pflichten — unter freien Lizenzen

Freie Lizenzen (insbesondere die GNU GPL) erlauben nicht nur das Teilen — sie schützen das Recht, Software zu studieren, zu verändern und weiterzugeben, auf eine Weise, die schwer rückgängig zu machen ist. Für Entwickler bedeutet das: Deine Verbesserungen können für andere verfügbar bleiben unter denselben Bedingungen, statt in ein geschlossenes Produkt zu fließen, ohne dass die Gemeinschaft davon profitiert.

Welche Rechte du gewinnst

Unter der GPL kannst du:

• sorglos tüfteln: den Quellcode lesen, ändern und deine veränderte Version ausführen
• deine Arbeit teilen: Original‑ oder veränderte Programme verteilen
• auf den Verbesserungen anderer aufbauen: weil Empfänger dieselben Freiheiten erhalten

Deshalb wird die GPL oft als „durchsetzbare Reziprozität“ beschrieben. Wenn jemand ein GPL‑gedecktes Programm (oder ein abgeleitetes Werk) verteilt, kann er keine zusätzlichen Einschränkungen auferlegen, die nachgelagerte Nutzer von denselben Änderungen ausschließen.

Welche Pflichten du übernimmst

Diese Rechte kommen mit Pflichten beim Vertrieb von Software:

• Copyright‑ und Lizenzhinweise bewahren
• entsprechenden Quellcode bereitstellen (oder ein Angebot dazu), wenn die GPL es verlangt
• die Lizenz intakt halten, damit Empfänger ihre Rechte erkennen

Diese Pflichten sind keine „Fallstricke“ — sie sind der Mechanismus, der verhindert, dass Zusammenarbeit zu einseitiger Ausbeutung wird.

Ein praktischer Hinweis zur Einhaltung

Teams sollten Lizenzkonformität wie Release‑Hygiene behandeln. Verfolge:

• welche Open‑Source‑Komponenten du auslieferst,
• ihre Versionen und Lizenzen,
• wo du Quellcode (oder schriftliche Angebote) bereitstellst,
• und welche Änderungen du vorgenommen hast.

Eine einfache Software Bill of Materials (SBOM) und eine wiederholbare Checkliste für Releases verhindern die meisten Probleme lange bevor Anwälte eingreifen.

Freie Software vs. Open Source: eine Werteaufspaltung

Auf Code‑Ebene beschreiben „freie Software“ und „Open Source“ oft viele derselben Projekte. Die Trennung betrifft hauptsächlich das Warum des Teilens.

Unterschiedliche Prioritäten: Freiheit vs. Adoption

Die Free‑Software‑Bewegung (mit Richard Stallman und der Free Software Foundation assoziiert) betrachtet Softwarefreiheit als ethische Frage: Nutzer sollten das Recht haben, Software auszuführen, zu studieren, zu ändern und zu teilen. Es geht nicht nur um bessere Technik — es geht um Schutz der Autonomie der Nutzer.

Der Open‑Source‑Ansatz betont praktische Ergebnisse: bessere Zusammenarbeit, schnelleres Iterieren, weniger Bugs und verbesserte Sicherheit durch Transparenz. Er wirbt gerne damit, Offenheit sei ein überlegener Entwicklungsansatz, ohne notwendigerweise eine moralische Position zu fordern.

Warum „Open Source“ durchsetzte

1998 popularisierte die Open Source Initiative (OSI) den Begriff „Open Source“, um die Idee für Unternehmen zugänglicher zu machen. „Free software“ wurde oft missverstanden als „kostenlos“, und manche Firmen scheuten eine Botschaft, die auf Rechten und Ethik beruhte. „Open Source“ bot Organisationen eine Möglichkeit zu sagen „wir arbeiten so“, ohne ideologisch zu klingen.

Gleiche Lizenzen, unterschiedliche Rahmung

Viele Projekte, die sich als Open Source bezeichnen, nutzen die GNU GPL oder andere Copyleft‑Lizenzen; andere wählen permissive Lizenzen wie MIT oder Apache. Der juristische Text kann identisch sein; die Erzählung gegenüber Beitragenden, Nutzer:innen und Kund:innen ändert sich. Die eine Botschaft lautet „das schützt eure Freiheiten“, die andere „das reduziert Reibung und verbessert Qualität“.

Ein einfacher Entscheidungsleitfaden

Wenn euer Team als Priorität hat, sicherzustellen, dass nachgelagerte Nutzer dieselben Freiheiten behalten, setzt auf die freie Software‑Rahmung und erwägt Copyleft.

Wenn eure Priorität maximale Verbreitung ist (auch bei Firmen, die keine reziproken Pflichten wollen), passt die Open Source‑Rahmung — und oft eine permissive Lizenz — besser.

Wenn ihr breite Zusammenarbeit wollt, aber auch Verbesserungen zurückfließen sollen, nutzt Open‑Source‑Sprache zur Zugänglichkeit und wählt trotzdem eine Copyleft‑Lizenz für das Ergebnis.

Geschäftsmodelle und reale Anreize

Freie Software heißt nicht „niemand wird bezahlt“. Es bedeutet, dass Nutzer die Freiheit haben, Software auszuführen, zu studieren, zu verändern und weiterzugeben. Viele Firmen bauen erfolgreiche Einnahmen um diese Freiheit herum — oft, indem sie für Dinge bezahlen, mit denen Organisationen wirklich kämpfen: Zuverlässigkeit, Verantwortung und Zeit.

Wie Unternehmen mit FOSS Geld verdienen

Einige bewährte Modelle:

• Support und Dienstleistungen: bezahlte Helpdesks, SLAs, Schulungen, Audits, kundenspezifische Features und Migrationsarbeit
• Hosting und Managed‑Angebote: Verkauf einer gehosteten Version, bei der Kunden für Komfort, Skalierung, Backups und Compliance zahlen
• Dual Licensing: dasselbe Produkt unter einer freien Lizenz (oft Copyleft) und zusätzlich unter einer kostenpflichtigen kommerziellen Lizenz anbieten
• Open Core (mit Vorsicht): eine wirklich freie Basis behalten und proprietäre Add‑ons verkaufen. Das kann funktionieren, kann aber das Vertrauen der Community belasten, wenn der „freie“ Teil absichtlich begrenzt wirkt

Eine moderne Variante des „Managed“‑Modells sind Plattformen, die schnell Anwendungen erzeugen und betreiben. Zum Beispiel ist Koder.ai eine Vibe‑Coding‑Plattform, die Teams beim Bau von Web‑, Backend‑ und Mobile‑Apps via Chat hilft — und gleichzeitig den Export des Quellcodes unterstützt. Diese Kombination (schnelles Iterieren plus Code‑Eigentum) passt natürlich zu den Werten der Softwarefreiheit: die Fähigkeit, deinen Code zu inspizieren, zu ändern und zu verschieben, wenn du es brauchst.

Warum permissive vs. copyleft Strategie beeinflusst

Die Lizenzwahl kann bestimmen, wer Wert abschöpft:

• Permissive Lizenzen (MIT/Apache) erleichtern es Dritten — auch großen Anbietern — euren Code in proprietären Produkten wiederzuverwenden. Das kann Adoption steigern, aber eure Möglichkeiten zur Monetarisierung von Exklusivität verringern.
• Copyleft‑Lizenzen (GPL) verlangen, dass Weiterverteiler Modifikationen unter denselben Bedingungen teilen. Das kann geschlossene Forks entmutigen und Geschäftsmodelle unterstützen, die auf Services, zertifizierten Distributionen oder Dual‑Licensing beruhen.

„Kommerziell“ und „freie Software“ sind keine Gegensätze

„Kommerziell“ beschreibt wie etwas verkauft wird; „freie Software“ beschreibt die Rechte der Nutzer. Ein Unternehmen kann freie Software verkaufen, für Support Gebühren verlangen und dennoch Softwarefreiheit respektieren.

Nachhaltigkeits‑Checkliste

Bevor ihr ein Produkt auf einem FOSS‑Projekt aufbaut, fragt:

• Gibt es eine aktive Community (Issues, Releases, Reviews)?
• Ist Governance klar (wer entscheidet, wie werden Konflikte gelöst)?
• Ist Finanzierung sichtbar (Sponsoren, Firmenunterstützung, Stiftung)?
• Ist die Belastung der Maintainer tragbar (Bus‑Faktor, Burnout‑Signale)?
• Sind Sicherheitspraktiken dokumentiert (Patch‑Rhythmus, Advisories)?

Häufige Missverständnisse über die GPL und FOSS

Über die GPL und „FOSS“ wird viel geredet, und einige Mythen verunsichern Teams, die einfach nur ein Produkt ausliefern wollen, ohne aus Versehen Lizenzauflagen zu verletzen.

„GPL heißt Public Domain"

Tut sie nicht. Public Domain bedeutet, dass es keinen Urheberrechtsinhaber gibt, der Bedingungen durchsetzt — jede:r kann das Werk ohne Verpflichtungen nutzen.

Die GNU GPL ist das Gegenteil von „ohne Bedingungen“. Der Autor behält das Urheberrecht und gewährt weitreichende Erlaubnisse — aber nur, wenn du die Bedingungen der GPL erfüllst (insbesondere Quellcodefreigabe bei Distribution von Binärdateien).

„Open Source ist immer sicher"

Offenlegung kann Sicherheit helfen, garantiert sie aber nicht. Ein Projekt kann offen sein und dennoch:

• ungewartet,
• schlecht überprüft,
• jahrelang verwundbar bleiben, bevor jemand es bemerkt.

Sicherheit entsteht durch aktive Wartung, Audits, verantwortliche Offenlegung und gute operative Praktiken — nicht durch ein Lizenzetikett.

Der Vorwurf der „Virus‑Lizenz"

Man nennt die GPL oft „viral“, um zu suggerieren, sie verbreite sich unkontrolliert. Das ist eine zugespitzte Metapher.

Meist meint man damit Copyleft: Wenn du ein abgeleitetes Werk von GPL‑Code verteilst, musst du den entsprechenden Quellcode unter der GPL bereitstellen. Diese Regel ist bewusst: Sie erhält die Freiheiten stromabwärts. Es ist keine „Infektion“, sondern eine Bedingung, die du akzeptieren kannst — oder du vermeidest sie, indem du anderen Code verwendest.

„Kann ich GPL‑Code in meiner App oder meinem Service verwenden?“ (auf hohem Niveau)

Faustregel: Pflichten greifen hauptsächlich bei Distribution.

• Interne Nutzung: Die Nutzung von GPL‑Software innerhalb einer Firma verlangt meist nicht, Änderungen zu veröffentlichen.
• Auslieferung einer App/eines Geräts: Wenn du ein GPL‑lizenzierbares Programm verteilst (oder ein abgeleitetes Werk), musst du in der Regel Quellcode und Lizenzhinweise bereitstellen.
• SaaS / Webdienste: Den Server betreibst du, aber du verbreitest meist keine Kopien — die GPL zwingt daher normalerweise nicht zur Veröffentlichung. (Die AGPL wurde geschaffen, um diese Lücke zu schließen.)

Wenn es relevant wird, lass die konkrete Kombination und Verteilung prüfen — nicht nur Vermutungen.