Begriff

Open Source

Development Licensing S1

2 Quellen 0 Lernpfade 1 Backlink enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Bei proprietärer Software (Windows, Photoshop) bekommst du nur das fertige Programm (den Kuchen). Das Rezept (den Quellcode) hält der Hersteller streng geheim. Bei Open Source (Linux, Firefox, VLC) bekommst du den Kuchen und das Rezept. Jeder darf:

Den Code lesen ("Was macht das Programm wirklich?").
Den Code ändern ("Ich bau mir eine Version mit lila Buttons").
Den Code weitergeben.

Es ist eine Bewegung für freies Wissen und Zusammenarbeit.

Merksatz: Software, deren Quellcode öffentlich zugänglich ist und von jedermann genutzt, geändert und verbreitet werden darf.

1. Dual-Licensing Models (SaaS-Druck)

Die Cloud bedroht klassisches Open Source. MongoDB und Elasticsearch waren komplett frei. Aber Giganten wie Amazon AWS nahmen sich den offenen Code, hosteten ihn (ohne eine Zeile beizutragen) und verkauften es als "AWS DocumentDB" für Milliarden. Kleine Firmen starben am Open-Source Ausnutzungsproblem. Die Lösung war ein Lizenzwechsel (z.B. AGPL oder SSPL - Server Side Public License). Hier ist der Kniff: Der Code ist weiterhin offen. Aber wer den Code nutzt, um ihn als "Service" (SaaS) gegen Geld an Dritte feilzubieten (AWS), muss zwingend sein gesamtes Cloud-Billing/Hosting System ebenfalls dem Copyleft unterwerfen, was Amazon rechtlich verbietet. Wer die Datenbank nur intern braucht, nutzt sie weiter kostenlos. Startups wie Redis oder HashiCorp überleben nur durch diese Lizenz-Hybriden (Business Source Licenses).

2. CLA (Contributor License Agreement)

Du findest einen Bug in einem fremden Open Source Projekt und programmierst gratis den Fix. Bevor dein Code (Pull Request) gemerged wird, zwingt dich der Eigentümer, ein CLA (Contributor License Agreement) zu unterschreiben. Warum? Weil du rechtlich der Urheber deiner 5 Zeilen Code bist. Möchte die Mutterfirma das Projekt später von Open Source auf "Paid Proprietary" umstellen, bräuchte sie theoretisch die schriftliche Erlaubnis von 10.000 zufälligen Community-Hobbyisten, die jemals einen PR gesendet haben. Das CLA überträgt (assignt) all deine Urheber-Verwertungsrechte pauschal auf die Main-Firma, damit diese den Code kommerziell weiterverkaufen kann.

3. Dependency Confusion Attack

Das Herz von Open Source (NPM, PyPI) ist blindes Vertrauen. Startups haben inhouse Pakete (z.B. @internal/payment-lib) gebaut, die nur in privaten Firmen-Repositories liegen. Das Paket hat die Versionsnummer 1.0.0. Ein Hacker findet den Namen des internen Pakets heraus und lädt ein extrem bösartiges Paket mit exakt dem gleichen Namen – aber Version 99.0.0 auf den öffentlichen Open Source NPM Registry hoch. Der npm install im Firmen-Server fragt lokal an, merkt aber: "Hey, auf dem globalen (öffentlichen) Server liegt eine viel höhere Version (99)!". Durch Design-Schwächen laden die Server dann ungeprüft den bösartigen Open-Source-Trojaner ins interne Rechenzentrum.

Quick-Check

Heißt Open Source immer kostenlos?
Meistens ja ("Free as in Beer"), aber nicht zwingend ("Free as in Speech"). Man darf Open Source Software verkaufen (z. B. Red Hat Linux Enterprise), aber man bezahlt da eher für den Support und Updates.
Ist Open Source unsicher, weil Hacker den Code kennen?
Im Gegenteil ("Security through Obscurity" funktioniert nicht). Bei Open Source werden Lücken schneller gefunden und gefixt als bei Windows, wo nur Microsoft-Mitarbeiter den Code sehen dürfen.
Kann man damit Geld verdienen?
Ja. Geschäftsmodell: Software gratis, aber Hosting, Support, Training oder "Pro-Features" kosten Geld (Open Core Modell).