25.04.2016 – Wenn Software-Hersteller Richtlinien für den Umgang mit Open Source Software definieren, kommt früher oder später die Idee auf, Listen mit zugelassenen und unzulässigen Open Source Lizenzen aufzustellen. Das macht auch im ersten Augenblick Sinn. Die Juristen in der Rechtsabteilung haben bei den Einzelprüfungen gemerkt, dass es unproblematische Lizenzen wie Apache und BSD gibt, die man auch pauschal genehmigen kann. Würde man dann einfach die strengen Lizenzen, wie etwa GPL und LGPL untersagen, müsste man nicht mehr jeden Fall einzeln prüfen.
Das typische Merkmal für die Abgrenzung ist meistens der Copyleft-Effekt. Eine Open Source Lizenz, die es nötig macht, eigenen Source Code bereitzustellen, sollte man nicht einsetzen. Damit finden sich LGPL, GPL, CPL, EPL, CDDL und andere schnell auf dem Index. Die Aufgabe ist mit ein bisschen Fleißarbeit schnell erledigt und tatsächlich gab es einige Unternehmen, die jahrelang auf Grundlage solcher Whitelists gearbeitet haben, indem sie am besten die Einhaltung der Regeln nie näher untersucht haben. In der Praxis erweisen sich diese Listen häufig als unbrauchbar. Mit einem pauschalen Verbot von Copyleft-Lizenzen wird auf einmal ein Großteil des verfügbaren Softwarebestandes für unzulässig erklärt. Gerade im Bereich eingebetteter Software mit eigenen Bootloadern und Betriebssystemen kommt man ohne GPL-basierte Betriebssysteme und Libraries nicht weit. Nur wenige Betriebssysteme wie beispielsweise QNX sind fast frei von Copyleftbasierten Lizenzen, während Linux und Android im Kernel auf GPL 2.0 basieren.
Bei Herstellern von Desktop-Software kommt es hingegen manchmal vor, dass eine Beschränkung auf Open Source Lizenzen mit schwachen oder gar keinem Copyleft umsetzbar ist. Bei solchen Produkten geht es dann nur noch darum, die formalen Kriterien für die Open Source Nutzung einzuhalten.
Dort wo sich Open Source Komponenten mit Copyleft-Effekt nicht vermeiden lassen, wird man die Anwendungsfälle auch individuell überprüfen müssen. Für die Zulässigkeit kommt es dann darauf an, wie die Open Source Komponente eingebunden wird, ob sie beispielsweise statisch, dynamisch oder über einen Systemcall eingebunden wird und ob die Open Source Komponente verändert wird. Auch hier lassen sich standardisierte Schemata anwenden und die Prüfung automatisieren.