3. Inhalt des Systems, Inhaltsverzeichnis von Dateien und Komponenten
Man prüfe im Schritt 1, welche Komponenten in einem System verwendet werden und zwar inklusive aller Subroutinen.
Der Aufwand, der hier zur treiben ist, hat zu einer Trennung von mir und einer Kundin geführt, die dann doch lieber Inhouse Juristen beschäftigen wollte. Inzwischen gibt es Tools und Standards, die die Vorarbeiten für den Anwalt leisten. Das erleichtert meine und Ihre Arbeit.
3.1 Prüfschema
Jede Datei, die Software beinhaltet muss nach dem Prüfschema geprüft werden:
- Wer ist der Autor?
- Unter welcher Lizenz soll die konkrete Software genutzt werden?
- Unter Ansehung des Verwendungszwecks: Kann die Software genutzt werden?
- Unter Ansehung der technischen Verwendung: Besteht ein CopyLeft Effekt oder ähnliches?
- Sind die einzelnen Komponenten eines Systems so wie sie eingesetzt werden, kompatibel?
3.2 Tiefe der Compliance
Das kann in Stichproben geschehen oder insgesamt. Offengestanden gibt kaum eine Compliance, bei der man von Beginn an weiß, welche Lizenzen eigentlich wirklich anwendbar sind und ob alle erforderlichen Materialien auch zur Verfügung stehen. Hinzukommt, dass oft Lizenzen in Komponenten von Version zu Version geändert werden und man weiß nicht, mit welcher Version gerade gearbeitet werden soll. Oder es werden in einer Komponente OSS Komponenten verschiedener Lizenzbestimmungen kombiniert und man weiß nicht – weil es einfach keine klaren Aussagen gibt – ob die konkrete Form der Kombination rechtlich zulässig ist oder nicht.
Also muss schon bei der Eingangsprüfung von OSS einiges an Risikobewusstsein vorhanden sein.
3.3 Typische Fehler bei der Compliance
Für diejenigen, die schon Scans durchführen gleich am Anfang eine Warnung: Trocken gesagt reicht es nicht, wenn die Scan Tools die Lizenzbestimmungen ohne konkrete Versionsnummer angeben. Das ist ein Fehler. Die einzelnen Dateien der Komponenten müssen einer konkreten Lizenz zugeordnet werden. Und das tun die Tools manchmal nicht. Scans können natürlich keine Aussagen darüber treffen, wie eine Software eingesetzt wird und das bestimmte Einsatzzwecke (Kommerziell, Lizenz im Wege des SaaS, Verbot von DRM) durch die Lizenz ausgeschlossen werden.
3.4 Was darf man mit der OSS Software tun?
Das Erste, was ich im Rahmen von Seminaren über OSS immer klarstelle:
Jedem, der ein urheberrechtlich geschütztes Werk erschafft (so wie ich jetzt diesen Text), dem stellt das Recht Verbietungsrechte zur Verfügung, die es mir erlauben, von jedem anderen zu verlangen, es zu unterlassen, z.B. diesen Text ohne meine Zustimmung weiterzugeben, zu vervielfältigen, etc..
Das geschieht in den Schranken, die der Gesetzgeber und die Gerichte vorsehen.
Durch die Lizenzbestimmungen des OS verzichtet der Urheber der Software (oder des Unternehmens, welches die Nutzungs- und Verwertungsrechte innehat) auf diese Verbietungsrechte.
Das Dogma ist:
Sofern Du meine Software weitergibst (an Deinen Kunden) und/ oder ggf. weiter bearbeitest, musst Du Dich an die Inhalte der Bestimmungen dieser Lizenztexte halten. Sofern Du das nicht tust, entfallen die Dir übertragenen Nutzungsrechte an der Software und ich verbiete Dir, diese Software zu installieren, zu bearbeiten, weiterzugeben, etc.
Eine Verbreitung liegt vor, wenn die Software kopiert und an eine andere juristische oder natürliche Person weitergegeben wird. Das ist wichtig zu wissen, denn die meisten Pflichten die aus OSS Lizenzbestimmungen folgen, sind erst dann anwendbar wenn die Software verbreitet wird.
Genau deshalb unterfällt Software der public Domain nicht diesen Regelungen.
Schauen Sie sich einmal die Lizenzbestimmungen der Lizenz WTF, an.
Ich stelle nachfolgend einige Bedingungen aus den Lizenzbestimmungen vor, die immer wieder häufig verwendet werden. Welche konkret zu beachten sind, ergibt sich nur aus den jeweiligen Lizenztexten.
3.4.1 Permissive Lizenzen (Universitäts OSS)
Diese Regelungen sind gut einzuhalten.
Man darf die Software aus dem Internet installieren, in den Arbeitsspeicher laden und bearbeiten, man darf die bearbeitete Software unter einige andere (auch proprietäre) Lizenz stellen (umstritten z.B. für Apache und bestimmte Copyleft Lizenzen). Sofern man die Software verbreitet (also an den Kunden weitergibt oder zum Vertrieb verwendet), muss man bestimmte Informationen weitergeben.