Die Ursache dieses Problems ist jedoch gar nicht FLOSS selbst. Würde ein Softwareentwickler in einem Unternehmen irgendwelche proprietären Werkzeuge für Geld kaufen, so könnte er am Schluss durchaus in derselben Lage sein: Er weiß nicht, ob der Anbieter das Tool überhaupt verkaufen durfte, er weiß nicht, ob Support über die gesamte Nutzungsdauer gewährleistet ist, und er weiß auch nicht, welches Qualitätsniveau geboten wird.
Im Falle von FLOSS kann das fehlende Preisschild dazu verleiten, dass die in einem Unternehmen üblichen und vorgeschriebenen Verfahren von Einkauf und Qualitätskontrolle außer Acht gelassen werden – ganz nach dem Motto: »Einem geschenkten Gaul schaut man nicht ins Maul«. Diese Binsenweisheit, dass etwas, das keinen Preis hat, auch nichts wert sein kann, dreht sich hier um und wendet sich gegen den Erwerber: Was keinen Preis hat, wird oft nicht ausreichend kontrolliert. Das Problem ließe sich also leicht lösen, indem Unternehmen beim Einkauf von Software aus dem FLOSS-Bereich schlicht dieselbe Sorgfalt und dieselben Regeln anwenden wie bei jeder anderen Software auch.
Ein beispielsweise in Compliance-Vorschriften festgelegter Ausschluss von FLOSS wäre daher keine angemessene Reaktion auf ein Problem, das nur auf einem falschen Verständnis des FLOSS-Konzepts beruht. Durch eine restriktive Software-Richtlinie würde man sich von wertvollen Ressourcen abschneiden, etwa bei der Entwicklung von Embedded-Software für Chips, wo die verfügbaren Compiler-Technologien nun mal Open-Source-basiert sind. Zum anderen ist eine pauschale Gegenüberstellung von FLOSS und von proprietärer Software wenig sinnvoll, denn man kann auf beiden Seiten sowohl großartige als auch grauenvolle Software finden, man trifft hier wie da fantastischen Support ebenso wie ganz dürftigen an, und schließlich wird man überall mit passenden und unpassenden Lizenzbedingungen konfrontiert.
Nötig ist stattdessen eine Richtlinie, die dafür sorgt, dass in jedem Fall nur geeignete Software zum Einsatz kommt, egal ob es sich um FLOSS oder proprietäre handelt. Dabei müssen zuerst die Lizenzbedingungen sorgfältig geprüft werden und die Entwickler zu dementsprechend sachgemäßem Umgang angehalten werden. Dass etwas FLOSS ist, bedeutet nicht, dass man es ganz ohne Einschränkungen verwenden kann. Obwohl der Einwand, man könne alle seine IP-Rechte durch den Einsatz von FLOSS verlieren, Unsinn ist, der von großen Anbietern proprietärer Lösungen verbreitet wird, kann man auch bei FLOSS Urheberrechtsverletzungen begehen.
Außerdem müssen Entwickler Werkzeuge oder Bibliotheken, die für eine Nutzung in Betracht gezogen werden, sorgfältig prüfen. Dabei ist die Qualität und Zuverlässigkeit der Software, die Eignung für die konkreten Anforderungen, die Qualität des Supports oder auch die Bereitstellung neuer Funktionen entscheidend. Diese Prüfung ist bei jeder Software schwierig und oft aufwendig, auch bei FLOSS.
Weiterführende Links
[3] Philosophie des GNU-Projekts
[4] International Free and Open Source Solutions Foundation