Linux Essentials 1.3 Frei wie Freibier? Von Lizenzen, Freiheit und Geschäftsmodellen

Wer von freier Software spricht, meint nicht „kostenlos“, sondern „Freiheit“—wie Richard Stallman es prägnant formuliert: Denke an Redefreiheit, nicht an Freibier. Dieses Freiheitsverständnis ist konkret:

• Freiheit 0 erlaubt die Software für jeden Zweck auszuführen;
• Freiheit 1 garantiert Einsicht in den Quellcode und Anpassung an eigene Bedürfnisse;
• Freiheit 2 gestattet Weitergabe an andere;
• Freiheit 3 erlaubt Verbesserungen zu veröffentlichen—damit die Gemeinschaft profitiert.

Diese vier Freiheiten bilden den Kern „freier Software“. „Open Source“ entstand später als pragmatischerer Ansatz: Offenliegender Quellcode genügt als Kriterium, der gesellschaftlich-politische Anspruch tritt in den Hintergrund. In der Praxis arbeiten beide Welten (FLOSS/FOSS) am selben Ökosystem—die Unterschiede zeigen sich vor allem bei Lizenzen und deren Zielbild.

Lizenzen sind Nutzungsverträge für ein digitales Gut. Sie definieren, was mit Software getan werden darf—Ausführen, Verändern, Kombinieren, Weitergeben—und unter welchen Bedingungen. Hier prallen zwei Philosophien aufeinander. Copyleft-Lizenzen wie die GNU GPL v3 sorgen dafür, dass abgeleitete Werke die gleichen Freiheiten behalten („Vererbung“ der Lizenz). Das schützt die Gemeinschaft, schafft aber Kompatibilitätsfragen: Zwei Komponenten mit unvereinbaren Copyleft-Bedingungen lassen sich oft nicht zusammenführen. Abgemilderte Varianten wie LGPL erlauben das Koppeln freier Bibliotheken mit proprietärer Software; AGPL schließt die SaaS-Lücke, indem auch serverseitige Änderungen offengelegt werden müssen, wenn Nutzer über das Netz mit der Software interagieren. Dokumentation deckt die GFDL ab. Permissive Lizenzen (z. B. BSD 2-Clause/3-Clause, MIT, Apache-2.0) setzen auf maximale Verbreitung: Änderungen dürfen frei genutzt und sogar als Closed Source vertrieben werden—solange Urhebervermerk und Haftungsausschluss erhalten bleiben. Überträgt man das Prinzip auf Inhalte statt Software, landet man bei Creative Commons: von CC BY (nur Namensnennung) über CC BY-SA (Share-Alike, copyleft-ähnlich) bis zu restriktiveren Varianten wie CC BY-NC-ND (nicht-kommerziell, keine Bearbeitung).

Lizenzwahl in der Praxis folgt dem Ziel: Wer sicherstellen will, dass alle Ableitungen frei bleiben, wählt in der Software-Welt typischerweise GPL v3 (Copyleft); wer maximale Adaption erlaubt, nutzt BSD/MIT/Apache-2.0 (permissive). Für Lerninhalte oder Blogposts ist CC BY bzw. CC BY-SA gebräuchlich. Wichtig sind saubere Schritte bei einer GPL-Veröffentlichung: Copyright-Hinweise in jeder Quelldatei, vollständigen Lizenztext (z. B. COPYING) beilegen, klare Projekt-Readme mit Lizenzangabe, ggf. Rechteklärung mit Arbeitgeber/Beitragenden. Proprietäre Komponenten mit GPL-Code zu einer untrennbaren Einheit zu verbinden, verpflichtet in der Regel zur GPL-Veröffentlichung des Gesamtwerks (Copyleft-Effekt). Bleiben Komponenten technisch getrennt („mere aggregation“, klar umgrenzt, z. B. via getrennte Prozesse/Interfaces), ist Koexistenz möglich—die Details entscheiden.

Lizenz-Know-how ist prüfungs- und jobrelevant. Bei Content-Lizenzen steht Wikipedia unter CC BY-SA (Share-Alike-Prinzip). Wichtige Projekte: Apache HTTP Server → Apache-2.0; MySQL Community Server → GPL v2; Mozilla Firefox → MPL 2.0; GIMP → GPL 3. Für Prüfungsfragen rund um „permissive vs. Copyleft“ gilt: BSD-2-Clause ist permissive, GPL v3 Copyleft; bei Creative-Commons ist CC BY permissiv, CC BY-SA die Share-Alike-Variante.

Business-Modelle in Open Source lösen das Spannungsfeld „frei & nachhaltig“. Häufig sind Dual Licensing/Business Edition (z. B. MySQL, Nextcloud, Zammad), Professional Services (Beratung, Support, Wartung, SLA), SaaS/Hosting (Betrieb als Dienst mit nutzungsbasierter Abrechnung), Auftragsentwicklung (kundenspezifische Features), Zertifizierungen/Merchandising und Crowdfunding für Anschubfinanzierung. Gerade für DevOps-/Cloud-Rollen ist Lizenzsicherheit Teil der täglichen Arbeit—Compliance in Pipelines (Lizenz-Scans), Container-Baselines und Third-Party-Risiken gehören dazu.

Creative Commons im Überblick für Inhalte: CC BY erlaubt Bearbeitung & Weitergabe mit Namensnennung; CC BY-SA verlangt Weitergabe unter gleichen Bedingungen (copyleft-ähnlich); CC BY-ND verbietet Bearbeitung; CC BY-NC untersagt kommerzielle Nutzung (kombinierbar mit SA/ND). Der Urheber wählt gezielt Eigenschaften—je mehr gewählt werden, desto restriktiver die Lizenz.

Zusammengeführt mit den Übungsantworten:

• Die vier Freiheiten lauten ausführen, untersuchen/anpassen (Quellcode), weitergeben, verbessern & veröffentlichen.
• FLOSS steht für Free/Libre and Open Source Software.
• Für „alles bleibt frei“ ist GPL v3 die richtige Wahl; BSD-2-Clause ist permissive, GPL v3 Copyleft, CC BY permissiv, CC BY-SA Share-Alike.
• Monetarisierung gelingt etwa über Dual Licensing/Business Edition, Hosting/Service & Support und kundenspezifische Erweiterungen (auch SaaS ist üblich).
• Bei offenen Lizenzbeispielen: Apache → Apache-2.0; MySQL Community → GPL 2; Wikipedia-Artikel → CC BY-SA; Firefox → MPL 2.0; GIMP → GPL 3.
• Für eine GPL-v3-Veröffentlichung sind Lizenztexte/Headers und Rechteklärung essenziell.
• AGPL existiert, um sicherzustellen, dass auch Änderungen an serverseitig bereitgestellter freier Software offengelegt werden (Schließung der „SaaS-Lücke“).
• Beispiele für freie Software mit kostenpflichtiger Edition: MySQL, Nextcloud, Zammad.

Fazit: Lizenzen übersetzen das Freiheitsversprechen von Open Source in belastbare Regeln. Für die Prüfung zählt das klare Einordnen von Copyleft vs. permissiv, das Verständnis von GPL/LGPL/AGPL, die CC-Varianten für Inhalte und typische Lizenzzuordnungen populärer Projekte. Für die Karriere in DevOps/Cloud bedeutet Lizenzkompetenz: sichere Tool-/Bibliothekswahl, saubere Compliance in CI/CD und tragfähige Produktentscheidungen—ein Wettbewerbsvorteil im Remote-Jobmarkt.