Kategorien
Allgemein

Der Einstieg in Open Source 2: Projektarten und Lizenzen

Die große Vielfalt

One of the nice things about […] open source in general is, there are a lot of different things and everybody has something he can give to the project.

TORVALDS, 2016, Youtube 0:55

So lud Linus Torvalds die zögernden Entwickler in einem Teaser der Linux Foundation ein, ihre Zeit und Fähigkeiten in den Open-Source-Bereich zu investieren. Laut der von GitHub hauseigenen Statistik vom Oktober 2018 existieren auf ihrer Plattform über 96 Millionen Repositories mit über 200 Millionen Pull Requests in den letzten 12 Monaten (GITHUB, 2018).

Welche Arten von Open Source-Projekten gibt es?

Open Source-Projekte lassen sich aufgrund ihrer großen Vielfalt also nicht eindeutig kategorisieren. Eine der vielen Möglichkeiten, stellt die Definition idealtypischer Varianten von Schrape dar. Schrape kategorisiert OSS-Projekte nach deren Unternehmenseinfluss und hierarchischen Organisationsstruktur (vgl. Schrape, 2015, S. 33).

Idealtypische Varianten quelloffener Softwareprojekte (SCHRAPE, 2015, S. 33)

Peer Production Communities

Die größten Freiheiten lassen sich in Peer Production Communities erwarten, welche nach Richard Stallmans Idee für FOSS eine egalitäre Organisationsstruktur aufweisen und ohne Unternehmenseinfluss sich gesellschaftsethischen Maximen verpflichten (vgl. SCHRAPE, 2015, S. 33).

Pan definiert die Eigenschaften von OSS als ein „Information product, reliant on the internet, a userdeveloper innovation process, […] the product of a highly modular design“ (PAN, 2016, S. 481). Diese Eigenschaften bilden die notwendigen Bedingungen für das Entstehen von OSS.

Conditions of peer production (PAN, 2016, S. 481)

Dass ein OSS-Projekt zur Peer Production Community wird, hängt von weiteren Eigenschaften des Projekts und der Beteiligten ab. Eine ausgeglichene intrinsische und extrinsische Motivationen der Beteiligten löst das soziale Dilemma beim Angebot öffentlicher Güter, das Projekt nicht durch das Verfolgen eigener Ziele zu behindern. Eine gepflegte Hackerkultur trägt dazu bei, die intrinsischen Motivationen der Mitwirkenden zu stärken. Zur Überwindung des Problems, dass Beteiligte nicht das Gefühls bekommen, ausgenutzt zu werden, tragen strikte Regeln zur Kooperation, wie bspw. Copyleft-Lizenzen bei (vgl. PAN, 2016, S. 481).

Elitezentrierte Projektgemeinschaften

Mit ähnlich schwachen Unternehmenseinfluss, jedoch mit einem eng definierten Führungszirkel, stehen Elitezentrierte Projektgemeinschaften. Oftmals stehen ihre Gründer an dessen Spitze (vgl. SCHRAPE, 2015, S. 40). Nach Raymond entwickeln sich Gruppen, die aus Entwicklern und Eigentümer bestehen, zu Organisationen mit einem „wohlwollenden Diktator“.

Dieser muss stets das Allgemeinwohl seines Projekts und seiner Gemeinschaft und im Blick haben, um Forks des Projekts zu verhindern. Selbst wenn der Eigentümer Diktator bleibt, führt er eine Ebene möglicher Diskussionen darüber ein, wer für welche Teile des Projekts die Autorschaft gutgeschrieben wird. Somit soll der Eigentümer sein Projekt nicht absolut besitzen, auch wenn er das Recht behält, verbindliche Entscheidungen zu treffen (vgl. RAYMOND, 2000).

Heterarchisch angelegte Infrastrukturvorhaben

Heterarchisch angelegte Infrastrukturvorhaben unterscheiden sich von unabhängigen FOSS-Projekten durch die Betreuung und Steuerung ihrer Projekte. Obwohl es erhebliche Unterschiede zwischen der Leitung dieser Projekte gibt, behalten sie die Eigenschaft, dass jeder als Mitglied der Community an jedem Projekt teilnehmen kann.

Die meisten dieser Stiftungen haben eine eigene Lizenz für die Nutzung und Verteilung der mit ihren Projekten verbundenen Software geschaffen. Diese Stiftungen erhalten Mittel von Unternehmen und anderen Geldgebern, um die Kosten für die Projektinfrastruktur und das Management der Stiftung zu decken. Diese Finanzierung, kombiniert mit dem Screening der verschiedenen Projekte, zieht eine größere Commnunity von Entwicklern an (vgl. WASSERMAN, 2013, S. 3–4).

„In solchen heterarchisch angelegten Infrastrukturvorhaben geht es weniger um benennbare Produkte als um die Entwicklung übergreifend eingesetzter Werkzeuge“, so Schrape (SCHRAPE, 2015, S. 37). Als Beispiele benennt er hierbei Entwicklungsumgebungen oder Content Management Systeme (vgl. SCHRAPE, 2015, S. 37).

Korporativ geführte Kollaborationsprojekte

Korporativ geführte Kollaborationsprojekte stehen unter einem starken oder völligem Unternehmenseinfluss und werden oftmals in einer strengen korporativ-geführten Hierarchie geführt (vgl. SCHRAPE, 2015, S. 37).

„If a software firm can encourage voluntary external work, its development costs decrease, because in these situations the firm does not have to pay for the external contributions. Many firms increasingly initiate their own OSS projects rather than building on existing ones.“ (Schaarschmidt et al., 2015, S. 100) Jedoch, steht „angesichts der Dominanz von angestellten Entwicklern […] vielmehr die projektbezogene Kollaboration mit anderen industriellen Stakeholdern“ (SCHRAPE, 2015, S. 34) mittlerweile im Vordergrund.

Lizenzkategorien

Die Lizenz von Open Source-Projekten stellt auch einen wichtigen Unterschied dar. Sie bestimmt im Grunde genommen, wie man mit seinen Entwicklern „umgeht“.

Software jeder Art unterliegen Lizenzen, die bestimmen wie diese genutzt, weiterentwickelt und verteilt werden darf. Die einzige Ausnahme davon stellt Public Domain-Software dar, also Software ohne Urheber, jedoch ist diese Form von „lizenzfreier“ Software nach europäischem Urheberrecht schwer umzusetzen (vgl. ANGELOPOULOS, 2012, S. 17–18).

Innerhalb der Open Source existiert eine Vielzahl von Lizenzen, daher empfiehlt sich laut FSF eine Kategorisierung solcher:

Kategorisierung von Freier Software (CHAO-KUEI & BJÖRN SCHIESSLE, 2012)

Die GNU General Public License (GPLv3) ist eine starke Copyleft-Lizenz, die nicht nur sicherstellt, dass Benutzer alle Rechte haben, die sie benötigen, um Ihr Werk zu teilen und zu ändern, sondern ebenfalls die Benutzer, welche diese veränderte Software nutzen. Die GNU Affero General Public License (AGPLv3) stellt sicher, dass Benutzer, die über ein Netzwerk mit freier Software mit geänderten Codes interagieren, den Quellcode zu erhalten können (vgl. Robertson, 2015). Es werden auch andere Mittel blockiert, um Software proprietär zu machen, wie z.B. über Tivoisierung (vgl. Stallman, 2014).

Die GNU Lesser General Public License (LGPLv3) ist eine schwache Copyleft Lizenz. Sie erlaubt einer Software die Kombination mit unfreien Modulen (vgl. Free Software Foundation, 2019).

X11 oder ähnliche gewähren eine Weitergabe ohne Quelltext und die Software kann als Basis proprietäre Software verwendet werden (vgl. Robertson, 2015).

Wie geht es für mich weiter?

Im nächsten Artikel wird beleuchtet, was Entwickler antreibt oftmals freiwillig an einem Open Source-Projekt mitzuarbeiten. Hier lernst du auch die typischen Hürden beim Einstieg, die du dann umgehen kannst. Der Artikel wird hier verlinkt, sobald Teil Drei der Reihe veröffentlich ist.

Falls du Anregungen, Verbesserungsvorschläge und Fragen hast, kannst du die unixAG Zweibrücken über das Kontaktformular erreichen oder mir auf GitHub folgen. Die unixAG trifft sich ebenfalls jeden Mittwoch in der Hochschule Kaiserslautern am Standort Zweibrücken. Die Treffen sind für alle offen und jeder ist herzlich eingeladen sich dazuzugesellen. Mehr dazu findest du auf unserer Webseite.

Quellen

The Linux Foundation: Linus Torvalds: Why Choose a Career in Linux and Open Source. Online verfügbar unter https://www.youtube.com/watch?v=s8EKVNcD1ko.

GitHub (2018): The State of the Octoverse. Online verfügbar unter https://octoverse.github.com/, zuletzt aktualisiert am 17.11.2018, zuletzt geprüft am 14.02.2019.

Schrape, Jan-Felix (2015): Open Source Softwareprojekte zwischen Passion und Kalkül (SOI Discussion Paper) (02). Online verfügbar unter http://www.uni-stuttgart.de/soz/oi/publikationen/soi_2015_2_Schrape_Open_Source_Softwareprojekte_zwischen_Passion_und_Kalkuel.pdf.

Pan, Xiangdong (2016): A New Method of Production: Peer Production. In: Menggang Li, Qiusheng Zhang, Juliang Zhang und Yisong Li (Hg.): Proceedings of 2015 2nd International Conference on Industrial Economics System and Industrial Security Engineering, Bd. 327. Singapore: Springer Singapore, S. 477–484.

Raymond, Eric S. (2001): The cathedral and the bazaar. Musings on Linux and Open Source by an accidental revolutionary. Rev. ed. Beijing, Cambridge Mass.: O’Reilly.

Wasserman, Anthony I. (2013): Community and Commercial Strategies in Open Source Software. In: it – Information Technology 55 (5). DOI: 10.1515/itit.2013.1003.

Schaarschmidt, Mario; Walsh, Gianfranco; Kortzfleisch, Harald F.O. von (2015): How do firms influence open source software communities? A framework and empirical analysis of different governance modes. In: Information and Organization 25 (2), S. 99–114. DOI: 10.1016/j.infoandorg.2015.03.001.

Angelopoulos, Christina (2012): The Myth of European Term Harmonisation: 27 Public Domains for the 27 Member States. In: SSRN Journal. DOI: 10.2139/ssrn.2145862.

Richard Stallman (2014): Why Upgrade to GPLv3. Hg. v. Free Software Foundation. Online verfügbar unter https://www.gnu.org/licenses/rms-why-gplv3.html, zuletzt geprüft am 14.02.2019.

Free Software Foundation (2019): Verschiedene Lizenzen und Kommentare. Online verfügbar unter https://www.gnu.org/licenses/license-list.html, zuletzt geprüft am 14.02.2019.

Donald Robertson (2015): Demystifying copyleft — Free Software Foundation — working together for free software. Hg. v. Free Software Foundation. Online verfügbar unter https://www.fsf.org/bulletin/2015/spring/demystifying-copyleft-1, zuletzt geprüft am 14.02.2019.