Quelloffene Software

Quelloffene Software bezeichnet Software, die es aufgrund bestimmter Lizenzen jedem ermöglicht und erlaubt, Quelltext einzusehen, zu verändern und weiterzugeben. Dies bietet gegenüber proprietärer Software einige Vorteile: Für quelloffene Software fallen keine Lizenzgebühren an, sie kann den persönlichen Bedürfnissen angepasst werden und fördert außerdem eine gewisse Herstellerunabhängigkeit. Diese Vorteile tragen zur Attraktivität quelloffener Software bei, sodass Unternehmen und Organisationen immer häufiger in Betracht ziehen, durch deren Einsatz ihre Kosten zu senken und ihre Produktivität zu steigern.

Im nachfolgenden Dokument befinden sich Bewertungskriterien samt Fragenkatalog für die Gegenüberstellung quelloffener Softwareprodukte.


Bewertungskriterien zur Qualitätseinschätzung


  • Funktionalität
  • Community
  • Support
  • Dokumentation
  • Entwicklungsaktivität
  • Langlebigkeit
  • Integration
  • Sicherheit
  • Lizenzierung

Quelloffene Software bezeichnet Software, die es aufgrund bestimmter Lizenzen jedem ermöglicht und erlaubt, Quelltext einzusehen, zu verändern und weiterzugeben [44], [45]. Dies bietet gegenüber proprietärer Software einige Vorteile: Für quelloffene Software fallen keine Lizenzgebühren an, sie kann den persönlichen Bedürfnissen angepasst werden und fördert außerdem eine gewisse Herstellerunabhängigkeit. Diese Vorteile tragen zur Attraktivität quelloffener Software bei, sodass Unternehmen und Organisationen immer häufiger in Betracht ziehen, durch den deren Einsatz, ihre Kosten zu senken und sowie ihre Produktivität zu steigen.
Die Wahl eines geeignet Produktes für einen bestimmten Anwendungszweck kann sich allerdings als Herausforderung entpuppen. Dies ist bedingt durch die große Anzahl verfügbarer Softwarelösungen und die gleichzeitig fehlenden standardisierten Methoden zur Bewertung dieser. Daher soll die folgende Diskussion unterschiedlicher Bewertungskriterien und Lizenzmodelle eine Qualitätseinschätzung ermöglichen. Neben den hier vorgestellten Hintergrundinformationen der daraus abzuleitenden Strategie wird außerdem ein entsprechender Fragenkatalog zur Verfügung gestellt, um eine Bewertung und Gegenüberstellung von in Frage kommenden Softwareprodukten zu ermöglichen.

Freie vs. Open Source Software

Im Grunde wird zwischen zwei großen Bewegungen unterschieden: zum einen die "Free Software" Bewegung und zum Andren die Open Source"Bewegung. Sowohl Freie Software als auch Open Source Software räumen dabei den entsprechenden Lizenznehmern bestimmte Freiheiten ein, die durch diverse Lizenzen definiert werden.
Die Free Software Bewegung hat ihren Ursprung bereits im Jahr 1983 - ein Jahr bevor das freie Betriebssystem "GNU is not Unix (GNU)"von Richard Stallman ins Leben gerufen wurde. Die dabei kreierte Lizenz "GNU General Public Licence (GPL)"hatte u. a. den Zweck, die Freiheitsrechte der User zu schützen. Da nicht alle User und Entwickler mit diesen Ansichten und Zielen der Free Software Foundation (FSF) übereinstimmten, wurde 1998 eine neue Bewegung ins Leben gerufen, die sogenannte Open Source Initiative (OSI). Diese stellte ethische Fragen in den Hintergrund und fokussierte sich auf praktische Werte, wie z.B. die durch quelloffene Software erleichterte Zusammenarbeit und die daraus resultierenden, überlegeneren Lösungen - als klarer Gegenpol zu proprietärer Software. Beide Bewegungen sind nicht gegensätzlich - im Gegenteil, es gibt teilweise Kooperationen und auch Überlappungen bei der Definition. Der Unterschied zwischen beiden Definitionen lässt sich gut wie folgt erfassen: Öpensource is a development methodology; free software is a social movement." [46]
In der Praxis sind allerdings kaum Unterschiede zwischen Free und Open Source Software erkennbar, weshalb sich die Bezeichnungen Free and Open Source Software (FOSS) bzw. Free/Libre and Open Source Software (FLOSS) durchgesetzt haben, um beide Formen kollektiv anzusprechen. FLOSS verdeutlicht gegenüber FOSS, dass es sich bei "Free Software" um freie Software im Sinne von Freiheit handelt. Zu beachten ist, dass FLOSS-Produkte durchaus kommerziell vertrieben werden können; deshalb ist auch "proprietär" die korrekte Bezeichnung für Nicht-FLOSS-Produkte. Um ein Produkt überhaupt als Free oder Open Source bezeichnen zu können, muss es unter einer Lizenz veröffentlicht werden, die mit der jeweiligen Definition übereinstimmt. Diese werden nachfolgend beschrieben.

Free Software Definition
Die Free Software Definition beinhaltet vier Prinzipien bzw. Freiheitsrechte, die mit Gründung des GNU-Projekts bzw. der FSF festgelegt wurden, um die Freiheit der User gegenüber der Nutzung von Free Software zu wahren. Jegliche Software, die diesen Prinzipien nicht entspricht, wird von der FSF als nicht-frei und unethisch angesehen. Frei ist immer im Sinne von freiheitsgewährend zu verstehen, nicht im Sinne von kostenlos/gratis (vgl. "free speech, not free beer").
Freedom 0: The Freedom to Run - "The freedom to run the program as you wish, for any purpose (freedom 0)."[44]
Freedom 0 besagt, dass BenutzerInnen Freier Software das uneingeschränkte Recht haben, diese auszuführen und dass entsprechende Lizenzen alle denkbaren Verwendungsmöglichkeiten erlauben müssen. Essenziell ist hierbei der Freiheitsbezug auf die BenutzerInnen und nicht auf die EntwicklerInnen.
Freedom 1: The Freedom to Change or Modify - "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this."[44]
Freedom 1 räumt das Recht ein, die Software zu modifizieren und an eigene Bedürfnisse anzupassen, ohne dass diese überhaupt erwähnt werden müssten.
Freedom 2: The Freedom to Copy and Share - "The freedom to redistribute copies so you can help your neighbor (freedom 2)." [44]
Freedom 3: The Freedom to Share Improvements - "The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this." [44]
Kopien des Werkes - samt eventueller Modifikationen - zu verbreiten ist ausdrücklich erlaubt, ohne dies jemandem bekanntgeben, jemanden fragen oder dafür zahlen zu müssen. Der Vertrieb kann dabei sowohl kostenlos als auch kommerziell erfolgen. Modifizierte Versionen können daher, müssen aber nicht zwingend, erneut als Freie Software vertrieben werden.
Die Free Software Definition sieht zudem vor, dass die Dokumentation Freier Software denselben oben genannten Kriterien unterliegt, da diese als Teil der Software anzusehen ist [44].

Open Source Definition
Folgende drei Prinzipien bilden die Grundlage aller Open Source Lizenzen:

  • Das lizenzierte Werk darf beliebig oft kopiert, verbreitet und genutzt werden.
  • Der Quelltext des lizenzierten Werks muss offengelegt werden.
  • Das lizenzierte Werk darf verändert und in veränderter Form weitergegeben werden.

Diese Prinzipien werden in der Open Source Definition auf zehn Kriterien abgebildet [45]. Diese werden nachfolgend aufgegriffen und wie folgt interpretiert:

  1. Free Redistribution - "The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale."[45]
  2. Source Code - "The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."
    Der kompilierten Software sowie allen Derivaten davon muss der zugrundeliegende Source Code unverfremdet beigelegt oder dieser auf einfache Weise zugänglich gemacht werden, wie z.B. als gratis Download.
  3. Derived Works - "The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software." [45]
    Solche Derivate dürfen aber müssen nicht zwingend unter derselben Lizenz wie das ursprüngliche Werk vertrieben werden. Dies inkludiert die Möglichkeit, ein Derivat unter eine restriktivere Lizenz zu stellen, die beispielsweise eine Veröffentlichung des Souce Codes nicht vorsieht. werden könnte, die die Offenlegung des Quelltextes nicht vorsieht.
  4. Integrity of The Author’s Source Code - "The license may restrict source-code from being distributed in modified form only if the license allows the distribution of ‘patch files’ with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software." [45]
    Benutzer/Benutzerinnen sollen in der Lage sein, den ursprünglichen Autor der Software verifizieren zu können. Dafür wird hiermit das Recht eingeräumt, den veränderten Quelltext so anzubieten, dass der ursprüngliche Quelltext in Kombination mit sämtlichen Veränderungen in Form von Patches enthalten sind. Weiters muss die Lizenz die Verbreitung von Software, die aus verändertem Quelltext entstanden ist, explizit erlauben. Außerdem kann verlangen werden, dass die abgewandelte Version einen eigenen Namen bzw. eine eigene Versionsnummer tragen muss.
  5. No Discrimination Against Persons or Groups - "The license must not discriminate against any person or group of persons." [45]
    Dieses Kriterium stellt sicher, dass bestimmte Personen bzw. Gruppen durch eine Open-Source-Lizenz nicht ausgeschlossen werden. So kann z.B. auf gesetzliche Bestimmungen bzw. Einschränkungen in einer entsprechenden Open-Source-Lizenz zwar hingewiesen werden, jedoch darf die Lizenz selbst niemals solche Einschränkungen definieren.
  6. No Discrimination Against Fields of Endeavor - "The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."[45]
    Open-Source-konforme Lizenzen dürfen keinerlei Klauseln beinhalten, die den Einsatz der Software in irgendeiner Weise einschränken, wie z.B. die Verwendung im kommerziellen Umfeld oder in ethisch umstrittenen Praktiken.
  7. Distribution of License - "The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties."[45]
    Die mit der Lizenz einhergehenden Rechte gelten für alle AnwenderInnen der betroffenen Software. Diese dürfen durch keinerlei zusätzliche Verpflichtungen beschränkt werden.
  8. License Must Not Be Specific to a Product - "The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution."[45]
    Die in der Lizenz eingeräumten Rechte sind unabhängig davon, ob ein als Open Source lizenziertes Programm alleine oder als Teil einer Softwaredistribution vertrieben wird.
  9. License Must Not Restrict Other Software - "The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software."[45]
    Wird ein Open-Source-konformes Programm gemeinsam mit anderer Software vertrieben, darf die Lizenz diese in keinster Weise beschränken. So darf z.B. nicht verlangt werden, dass die zusätzlich vertriebene Software ebenfalls open source sein muss.
  10. License Must Be Technology-Neutral - "No provision of the license may be predicated on any individual technology or style of interface."[45]
    Die Möglichkeit der Zustimmung zur Lizenz muss technologie-neutral sein und darf daher nicht durch eventuelle technologische Hürden eingeschränkt werden. Solche Einschränkungen sind z.B. die Voraussetzung einer grafischen Oberfläche oder die Zustimmung per Button-Click (vgl. "click-wrapping").

Bewertungskriterien zur Qualitätseinschätzung


Um die Qualität und Brauchbarkeit von FLOSS-Projekten für die eigenen Anforderungen bewerten zu können, gibt es verschieden Kriterien. Die relevantesten Merkmale wurden aus [20] K. van den Berg, “Finding open options,” Master’s thesis, Tilburg University, 2005, [Accessed July 29, 2015]. [Online]. Available: http://www.karinvandenberg.nl/Thesis.pdf N. Ahmad and P. A. Laplante, “A systematic approach to evaluating open source software,” Strategic Adoption of Technological Innovations, pp. 50–69, 2013. extrahiert und nachfolgend beschrieben:

  • Funktionalität
  • Community
  • Support
  • Dokumentation
  • Entwicklungsaktivität
  • Langlebigkeit
  • Integration
  • Sicherheit
  • Lizenzierung

Funktionalität
Als elementares Kriterium zur Auswahl einer Software gilt sicher deren gebotener Funktionsumfang, welcher mit den geforderten bzw. gewünschten Funktionalitäten übereinstimmen muss. Die Websites von FLOSS-Projekten bieten daher üblicherweise eine Funktionsübersicht und/oder Frequently Asked Questions (FAQs), wodurch man sich einen ersten Eindruck verschaffen kann. Der große Vorteil liegt hier darin, dass kostenlose Software die Möglichkeit bietet, diese selbst anzutesten, um dabei festzustellen, ob sie den Anforderungen auch tatsächlich entspricht bzw. zu welchem Grad. Deshalb sollte man vorab definieren, welche Funktionen absolut unerlässlich sind. Falls kein Zeitdruck besteht, kann man üblicherweise auch "Feature Requestsän die Entwickler stellen. Diese bieten gleichzeitig ein Feedback für die EntwicklerInnen, welche Features noch benötigt werden.
Die Reaktion auf solche Requests kann zusätzlich auch gleich dabei helfen, die Seriosität, Aktivität und Qualität der Entwickler-Community einzuschätzen. Die barrierefreie Interaktion mit dem Entwicklerteam ist hier als weiterer Vorteil von FLOSS gegenüber proprietärer Software zu werten, die es üblicherweise nicht ermöglicht, direkt mit Entwicklern in Kontakt zu treten. Neben Feature Requests ist es dadurch etwa möglich, Informationen über aktuelle Aktivitäten und zukünftig geplante Features einzuholen.
Auch die User Community kann helfen, die Funktionalitäten der Software besser einschätzen zu können. Außerdem listen manche Websites Organisationen, in denen das Produkt zum Einsatz kommt, die ebenso um Erfahrungen mit der SW gebeten werden kann. Zusätzlich können Mailing-Listen und Foren nach Informationen durchsucht werden.
Ist ein FLOSS-Projekt und/oder dessen Dokumentation in verschieden Sprachen verfügbar, ist dies ein weiteres positives Anzeichen für ein aktives Projekt mit einer breiten Nutzerbasis.

Community
Die sog. "Community" eines FLOSS-Projektes besteht einerseits aus den EntwicklerInnen und andererseits aus den BenutzerInnen. Im Gegensatz zu propriäterer Software herrscht bei FLOSS üblicherweise rege Interaktion zwischen beiden Gruppen. Die gängigsten Mittel zur Kommunikation sind hierbei Mailing-Lists und Online-Foren.
Der User Community kommen bei FLOSS-Projekten die unterschiedlichsten Rollen zu. Diese reichen von Fehlerberichten, allgemeinem Feedback bis zu Feature Requests. Die Spanne der Fehlerberichte kann sich hier von simplen Rechtschreibfehlern bis hin zu gravierenden Funktionsstörungen ziehen. Oft bieten auch sehr erfahrene Key User Supporttätigkeiten an.
Sowohl Größe als auch Aktiviät der Community lassen auf den Reifegrad der Software schließen. Eine große User Community deutet z.B. auf eine breite Akzeptanz der Software hin, während eine großer Developer Community das Risiko gering hält, dass ein Projekt eingestellt wird.
Zum Austausch zwischen beiden Gruppen stehen üblicherweise Mailing-Listen und Foren zur Verfügung, die aber auch innerhalb dieser Gruppen zur Kommunikation verwendet werden können. Davon lässt sich außerdem die Aktivität der Community feststellen, z.B. können hierfür die Anzahl und das Datum der zuletzt getätigten Posts herangezogen werden. Auch die Reaktionszeit und Anzahl der Antworten auf etwaige Fragen geben darüber Auskunft. Dabei sollte auch auf die Qualität der Antworten geachtet werden. Eine transparente Aufstellung der Community ist ein weiteres positives Merkmal in diesem Zusammenhang.

Support
Beim Support kann man grundsätzlich zwischen der Art des angebotenen Service (Servicetypen) und der Art der Abwicklung (Supportmodelle) unterscheiden.

Servicetypen
Grundsätzlich lassen sich bei FLOSS zwei Arten von Support unterscheiden:

  • Usage Support: Beantworten von Fragen zum Umgang mit der Software
  • Failure Support: Lösen von Problemen im Umgang mit der Software

Der Failure Support wird dabei zumeist über einen Bug-Tracker abgewickelt, über den Probleme gemeldet werden können und ein Problem-Management erfolgt. Ein so gemeldetes Problem wird dabei einem Entwickler zugeteilt, und der Status des Fehlers kann so von der gesamten Community transparent verfolgt werden. Daher ist ein wesentliches Qualitätsmerkmal in diesem Zusammenhang, ob ein Bug-Tracker zur Verfügung steht und wie aktiv dieser genutzt wird.

Supportmodelle
Nicht nur die Arten des Supports sondern auch die Abwicklung dessen unterscheiden sich von proprietärer Software. Bei FLOSS existieren folgende drei unterschiedlich Modelle:

  • Paid Support: Der Support erfolgt entgeltlich, z.B. durch ein externes Unternehmen
  • Community Support: Die FLOSS-Community übernimmt den Support
  • Self Support: Eine Person oder ein Team der eigenen Organisation mit dem entsprechenden Know-How wird mit dem Support betraut

Die Variante des Paid Supports wird üblicherweise von größeren Unternehmen in Anspruch genommen und auch als Third-Party Support bezeichnet. Dabei fällt eine Gebühr an. Der Support wird entweder über einen Service Vertrag mit sogenannten Service Level Agreements (SLAs) abgewickelt oder aber die Abrechnung erfolgt pro Support-Anfrage. Die Möglichkeit, überhaupt SLAs für ein FLOSS-Produkt vereinbaren zu können, deutet auf einen hohen Reifegrad des Produkts hin.
Die am weitest verbreitetste Art der Supportmodelle ist der Community Support, da dieser am kostengünstigsten angeboten werden kann und ist daher für KMUs und kleinere Organisationen besonders interessant. Als erste Anlaufstellen kommen hier die Dokumentation sowie die FAQs des Projekts in Frage. Wird man hier nicht fündig, gibt es als nächsten Schritt besonders für Usage-Supportanfragen die Möglichkeit, Supportanfragen anhand von Postings in den jeweiligen Foren und Mailing-Listen abzusetzen. Die Kriterien zur Bewertung der Qualität des Community Supports sind dabei vielfältig. Ein grundsätzlicher Ansatz ist die Überprüfung, ob derartige Mittel beim in Frage kommenden FLOSS-Produkt überhaupt existieren. Danach ist es wesentlich, wie Groß die Community ist, d.h. wie viele Mitglieder sich aktiv am Projekt beteiligen. Eine hohe Anzahl an Community-Mitgliedern erhöht die Chance aus zahlreichere und qualitativ hochwertiger Antworten. Weitere wichtige Punkte sind Qualität und Reaktionszeit der Antworten, und auch ob die Anfrage zur Zufriedenheit des Benutzers beantwortet wurde, Hierbei gilt es auch die Qualität der Anfragen miteinzubeziehen; nur wohlformulierte und ausreichend detailliere Postings sollten für die Bewertung herangezogen werden.
Der Self Support erfolgt in-house, indem erfahrene MitarbeiterInnen den Support übernehmen. Dies setzt einerseits voraus, dass das FLOSS-Produkt schon über einen längeren Zeitraum in der Organisation eingesetzt wird; andererseits ist es auch möglich, dass solche Mitarbeiter eigens für diese Aufgabe eingesetzt werden. Im ersten Fall muss jedenfalls sichergestellt und berücksichtigt werden, dass auch die notwendigen Ressourcen zur Verfügung gestellt werden. Ein beträchtliches Risiko ist allerdings damit verbunden, dass solch erfahrene Mitarbeiter aus der Organisation ausscheiden. Daher sollte auch regelmäßiger Knowledge-Transfer vorgesehen und geplant werden.

Dokumentation
Die Dokumentation eines Projekts ist ein wesentliches Qualitätsmerkmal von FLOSS und ein Indikator für die Seriosität und den Reifegrad. Diese wird je nach Zielgruppe und Verwendungszweck in folgende drei Arten unterteilt:

  • Benutzerdokumentation
  • Entwicklerdokumentation
  • Wartungsdokumentation

Die Benutzerdokumentation dient dem/r EndbenutzerIn als Hilfestellung für die Verwendung des Software. Üblicherweise wird innerhalb dieser noch zwischen der Dokumentation für Administratoren und Benutzer unterschieden. Neben der Dokumentation, die vom Entwicklerteam auf der projekteigenen bereit gestellt wird, finden sich auch noch HowTos und Tutorials, die von anderen Benutzer erstellt werden, und üblicherweise einzelne Funktionen und Einsatzszenarien umfassen.
Die Entwicklerdokumentation ist aufgrund der dezentralen Arbeitsaufteilung eines FLOSS-Projekts absolut essentiell. Inhalte dieser sind etwa Regeln für die Bearbeitung des Quelltextes oder die Form der Kommentare im Code. Diese Dokumentation kann zusätzlich von erfahrenen Entwicklern begutachtet werden lassen.
Für komplexe größere oder serverbasierte Applikationen stehen zusätzlich auch Wartungsdokumentationen zur Verfügung, die beschreiben, wie die Installation oder Aktualisierung der Software abläuft. Die Verfügbarkeit von kommerzieller Dokumentation in Form von Sachbüchern deutet außerdem auf ein ausgereiftes Projekt mit hoher Nutzerzahl hin.

Entwicklungsaktivität
Da keine Software je gänzlich frei von Fehlern oder Bugs sein wird, ist eine regelmäßige Weiterentwicklung sowie Aktualisierung wichtig. Auch neue Funktionen und Features tragen zur Dynamik einer Software bei. Daher ist auch die Entwicklungsaktivität ein wichtiges Kriterium zur Bewertung von FLOSS. Ein guter Indikator für ein aktives Projekt ist daher u. a. die Anzahl der Veröffentlichungen und deren Funktionsumfang.
Wichtige Anlaufstellen für Informationen über die Entwicklung von FLOSS-Projekten sind daher:

  • Die projekteigene Website (Versionsnummern, Mailing-Listen, Bug-Tracker)
  • FLOSS-Portale wie SourceForge oder Freecode (div. Statistiken)
  • Changelogs des Projekts (Umfang der Änderungen)

Es ist allerdings anzumerken, dass geringe Aktivitäten auch auf ein stabiles, ausgereiftes Produkt mit wenig Fehlern hinweisen können. In diesem Fall kann man aber über die Benutzeranzahl oder die Bewertung des Projekts Rückschlüsse ziehen.

Langlebigkeit
Die Langlebigkeit bezieht sich darauf, wie lange ein FLOSS-Projekt bereits in Umlauf ist, und gilt als Indikator für die Stabilität eines Projekts bzw. für die (Un-)Wahrscheinlichkeit, dass es zum Stillstand kommt oder gar für immer eingestellt wird. Prinzipiell gilt: Je älter die Software, desto höher der Reifegrad.

Integration
Nicht zuletzt ist die Integrationsfähigkeit eines FLOSS-Projekts ein wesentlicher, wenn auch sehr subjektiver Faktor. Dabei versteht man die Eingliederung in eine bestehende Unternehmensinfrastruktur sowie die Anpassung einer bestehenden Lösung an die eigenen Anforderungen. Im Rahmen der Integration betrachtet man verschiedene Eigenschaften von FLOSS, wie folgt:

Modularität
Unter der Modularität eines Softwareprogramms versteht man den Aufbau aus mehreren Teilen, die jeweils ihre eigene Funktionalität besitzen. Ist dies bei einer FLOSS-Lösung der Fall, kann man bereits von einem hohen Reifegrad dieser ausgehen. Der Vorteil einer modular aufgebauten Software ist vielfältig: Zum einen lässt sich diese einfacher verwalten, da neue Module hinzugefügt, bestehende Module unabhängig voneinander aktualisiert oder sogar eigene Module selbst entwickelt werden können. Zum anderen hat der Benutzer Freiheit in der Funktionsauswahl, indem bestimmte Features aktiviert oder deaktiviert werden können.

Standards
Damit sich FLOSS-Projekte leicht in die vorhandene Organisationsinfrastruktur integrieren lassen, ist es von Vorteil, wenn diese auf etablierte Standards setzen, was z.b. den Datenaustausch zwischen verschiedenen und/oder bereits vorhandenen Produkten betrifft. Ein Beispiel für einen bewährten Standard, der sich hierfür in den letzten Jahren etabliert hat, ist z. B. die Extensible Markup Language (XML).

Anforderungen
Beim Einsatz von FLOSS muss auf etwaige Software-, Hardware- oder Betriebssystemanforderungen geachtet werden. Beispielsweise sind viele FLOSS-Projekte nur für Linux oder UNIX verfügbar. Dies kann Organisationen, die z.B. ein homogenen Windows Netzwerk betreiben, vor Herausforderungen stellen. Bei Serverapplikationen ist dies noch relativ einfach zu bewerkstelligen, da ein spezieller Computer mit dem benötigten Betriebssystem angeschafft werden kann. Clientapplikationen verkomplizieren hier die Problematik; oft bleibt als Lösung nur mehr die problematische Portierung auf eine anderes Betriebssystem oder der Verzicht auf dieses Projekt. Andere Software-Lösungen setzen wiederum sind per se nicht lauffähig, und setzen daher andere Programme, wie z.b. Webserver oder Datenbanken, voraus.

Sicherheit
Bei quelloffener Software werden im Grunde zwei unterschiedliche Standpunkte bzgl. ihrer Sicherheit vertreten. Einerseits herrscht die Meinung vor, dass durch die Offenlegung des Quelltextes Fehler rascher gefunden werden, was sich positiv auf die Sicherheit des Produkts auswirkt ("Given enough eyeballs, all bugs are shallow."). Andererseits gibt es durchaus Verfechter der Ansicht, dass offener Quellcode die Gefahr birgt, dass Schwachstellen von potentiellen Angreifern entdeckt und ausgenutzt werden können. Beide Sichtweisen haben ihre Berechtigung, jedoch liegt der Vorteil zuerst bei den Entwicklern und der Community, die Möglichkeit zu nutzen, ihren Code auf Schwachstellen zu analysieren. Erst wenn diese Möglichkeit nicht genutzt wird, geht sie auf einen Angreifer über. Diesen Vorteil gibt es für die Benutzer proprietärer Software nicht; man ist dem Hersteller diesbezüglich ausgeliefert. Lediglich Security-Reviews auf das kompilierte Endprodukt können hier als proaktive Maßnahme herangezogen werden. Aber selbst bei Entdeckung einer Sicherheitslücke ist man von Updatepolicies und Releasepläne des Herstellers abhängig. Bei FLOSS-Projekten kann wesentlich schneller und flexibler auf gemeldete Schwachstellen reagiert werden.
Diesbezüglich sei auch auf die vorgestellten Kriterien aus Kapitel 8.2.5 "Entwicklungsaktivität"verwiesen. TODO: CVEs siehe bakk-arbeit
Da verschiedene Anwendungsgebiete unterschiedlichste Sicherheitsanforderungen mit sich bringen können, sollten zunächst diese Anforderungen identifiziert werden. Dafür sei auf die Bestimmung der Schutzbedarfsklassifikation !! LINK !! verwiesen, um die spezifischen Anforderungen an das gewünschte Produkt zu ermitteln. TODO: CC siehe bakk-arbeit
Schlussendlich erlaubt eine Analyse der projekteigenen Website und ihrer Community eine Einschätzung darauf, wie seriös das Entwicklungsteam mit dem Thema Sicherheit umgeht. Das Thema Sicherheit sollte in irgendeiner Form auf der Website behandelt werden. Außerdem sollte es eine für die Community transparente Möglichkeit geben, Sicherheitslücken oder potentielle Schwachstellen zu melden. Die Qualität und Zeitspanne der Reaktionen auf derlei Meldungen ist ein weiteres wichtiges Kriterium. Werden zusätzlich zum Download der Software kryptographische Signaturen oder zumindest Checksummen zur Integritätsprüfung bereitgestellt, zeigt dies auf ein sicherheitsgerichtetes Arbeiten und Verständnis des Entwicklerteams auf. (weist hin?)

Lizenzierung
Bei kommerzieller Software bezahlt man üblicherweise für die Lizenz, ein geschütztes Werk verwenden zu dürfen, wahrend das geistige Eigentum des Produkts dem Hersteller vorbehalten bleibt. Außerdem beinhalten solch Lizenzen eine Reihe von Einschränkungen, wie z. B. das Verbot zur Weitergabe der Software. Dies ist meist mit zusätzlichen (Lizenz-) Kosten verbunden. Lizenzen, die bei FLOSS-Lösungen zum Einsatz kommen, unterscheiden sich dazu hingegen stark. Beispielsweise wird die Verbreitung des Produkts gefördert und eigenhändige Modifikationen sind erlaubt, begünstigt durch den offengelegten Quelltext (vgl. Kapitel 8.1 "Freie vs. Open Source Software").
Um herauszufinden, ob eine bestimmte Lizenz als frei bzw. Open Source gilt, bieten sich die Liste der FSF5 bzw. die der OSI6 an. Dort sind sämtliche der von diesen beiden Organisationen bewilligten Lizenzen aufgelistet.
5 http://www.gnu.org/licenses/license-list.html
6 http://opensource.org/licenses
Diese sogenannten Copyleft-Lizenzen bestimmen, dass sämtliche modifizierten Versionen einer FLOSS ebenso frei bzw. Open Source sein müssen, nämlich so wie das Original. Dadurch wird sichergestellt, dass die modifizierte Software später nicht zu einem proprietären Produkt gemacht werden kann. Die GPL ist eine weitverbreitete Lizenz dieser Art, wenngleich auch die restriktivste. Für Bibliotheken gibt es daher eine weniger eingeschränkte Variante der GPL, die sog. GNU Lesser GPL (LGPL). Wird eine unter der LGPL-Lizenz vertriebene Bibliothek in ein eigenes Produkt eingebunden, muss dies später nicht zwangsläufig frei bzw. Open Source werden.
Dies gilt jedoch nur für den Fall, dass die Bibliothek eingebunden wird; sollte deren Quelltext selbst in das Programm eingefügt werden, greift dennoch der virale Charakter der GPL. Entwickler/Entwicklerinnen müssen außerdem dafür Sorge tragen, dass alle verwendeten Bibliotheken untereinander kompatible Lizenzen verwenden.
Schließlich existieren noch sog. Non-Copyleft-Lizenzen, die erlauben, dass abgeleitete Werke unter eine proprietäre Lizenz gestellt werden dürfen. Ein Beispiel für derartige Lizenzen sind jene der Berkeley Software Distribution (BSD) Familie. Die Lizenzbestimmungen sollten daher sehr genau für einen bestimmten Anwendungsfall bzw. Einsatzzweck evaluiert werden, bevor FLOSS-Produkte modifiziert bzw. eingebunden werden.

[44] Free Software Foundation. (2016) The Free Software Definition. [Online]. Available: https://gnu.org/philosophy/free-sw.html
[45] Open Source Initiative. (2007) The Open Source Definition. [Online]. Available: https://opensource.org/definition
[46] Free Software Foundation. (2016) Why Open Source misses the point of Free Software. [Online]. Available: https://gnu.org/philosophy/open-source-misses-the-point.html

Beschaffungsplattform für sichere IT von Fachhochschule St. Pölten.