Kleines FOSS-ABC

Veröffentlicht von Rene Schwarzinger am

Begriffsdefinition:

Während Freie Software eine politische bzw. ideologische Bedeutung impliziert (unfreie Software = gesellschaftliches Problem) stellt Open Source den praktischen Nutzen in den Vordergrund (bessere Programme durch offenen Quellcode).
Für den 0815-Anwender können beide Begriffe synonym betrachtet werden. Daher rührt auch der Begriff FOSS (= Free and Open Source Software).

Freie Open Source Software definiert sich durch 4 Freiheiten:

  • Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck.
  • Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen.
  • Die Freiheit, das Programm zu verteilen und damit seinen Mitmenschen zu helfen.
  • Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert.

Freiheit statt Freibier:

Freie Open Source Programme sind zumeist kostenlos nutzbar. Dies ist jedoch keine Bedingung von FOSS, sodass Richard Stallmann (Urgestein der Free Software Foundation) den Ausspruch „Free as in freedom, not as in free beer“ geprägt hat.
Dieser feine Unterschied hat zum Begriff FLOSS (Free and Libre Open Source Software) geführt, da dem lateinischstämmigen „libre“ nicht die Konnotation „kostenlos“ anhaftet.

Wie man mit FOSS trotzdem Geld verdienen kann:

Neben spendenbasierten Finanzierungsmodellen (z.B. Wikipedia) sind in der Regel kostenpflichtige Zusatzleistungen zu kostenloser Basis-Software ein Geschäftsmodell. Das können einerseits Add-ons oder Support sein, andererseits neue Produkte, die auf bestehender Freier Open Source Software aufbauen.
Gerade bei Unternehmen besteht oft eine erhöhte Zahlungsbereitschaft, gegenüber Leistungen wie Schulung, Support, Unterstützung bei der Migration und Integration sowie Service-Level-Agreements.
Es kann somit vorkommen, dass eine Software von 99 % der Nutzer kostenlos verwendet wird, jenes 1 % aber ausreichend Ertrag für die Entwickler einspielt.
Gut sichtbar wird dies z.B. an der freien Office Software LibreOffice. Firmen verdienen an großen Kunden mit bestimmten Bedürfnissen, indem gezielt Bugs beseitigt oder neue Features entwickelt werden. Im Gegensatz zu proprietärer Software wandern diese Verbesserung aber wieder in die Community zurück.

Gemeinschaftssinn:

Der Umstand, dass jeder interessierte Entwickler Verbesserungen am Code vornehmen kann, fördert den Aufbau so genannter Communitys.
Copyleft Lizenzen tragen dazu bei, dass Freie Open Source Programme auch in Zukunft frei bleiben. Dies gibt der Community die Sicherheit, dass ihre Arbeit nicht irgendwann gänzlich nutzlos bzw. einseitig verwertet wird.

Lizenzen:

Ganz grob lassen sich freie Lizenzen danach unterteilen ob sie „permissive“ sind oder „Copyleft“ forcieren.

Copyleft Lizenzen bauen auf dem Urheberrecht auf, kehren jedoch den Zweck des Copyrights um. Lizenzen mit Copyleft erzwingen, dass der Programmcode eines (freien) Projekts, das modifiziert wurde oder in das freier Quellcode eingeflossen ist, selbst wieder unter der selben Lizenz stehen muss – einmal frei, immer frei. Dies bedingt weiters, dass der Quellcode einer Software zumindest dem Empfänger der Software zugänglich gemacht werden muss.

Innerhalb des Copylefts gibt es wieder Unterteilungen in mildere (LGPL, MPL) und strengere Ausprägungen (GPL, AGPL).

Die freizügigere Form der freien Lizenzen erzwingt kein Copyleft. Abwandlungen und Kombinationen von Programmen können ohne Freigabe des Quellcodes unter eine beliebige, andere (auch proprietäre) Lizenz gestellt werden. Bekannte Vertreter sind etwa die BSD- und Apache-Lizenzen sowie in extremer Ausprägung das Public Domain.

Die Vielzahl an Lizenzvarianten hat in der Vergangenheit zu Inkompatibilitäten geführt (z.B. sind reine GPLv2 und reine GPLv3 Projekte nicht kombinierbar). Einerseits versuchen neuere Lizenz-Versionen diesem Problem entgegenzutreten (z.B. ist GPLv3 mit mehr anderen Lizenzen kompatibel) und andererseits gibt es Mehrfachlizenzierungen (z.B. GPLv3 or later).

Auch wenn die rechtliche Situation unübersichtlich wirkt, ist eine Zusammenarbeit wesentlich einfacher als im Closed-Source-Umfeld möglich!

Quelle: c’t magazin für computer technik, Ausgabe 1, 21.12.2019, S: 63-71, 74-75


0 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.