Eine VPN-Oberfläche, eine GPL-Engine und ein Installer: Was wird ausgeliefert?

Die Frage kommt als Lizenzfrage daher, doch die Antwort beginnt mit einer Bestandsaufnahme. Eine VPN-Oberfläche, die OpenVPN-Engine, die sie ansteuert, eine TLS-Bibliothek und ein Installer können vier verschiedene Bedingungswerke haben, und das Erscheinungsbild des Produkts verrät nichts darüber, welche Datei zu welchem Werk gehört. Arbeiten Sie die Artefakte in der Reihenfolge durch, in der sie ausgeliefert werden, und die rechtliche Frage wird deutlich enger, wenn Sie sie jemandem übergeben, der sie beantworten kann. Jeder Schritt grenzt sie weiter ein: was verteilt wird, was geändert wurde und wie die Teile miteinander kommunizieren.

Beginnen Sie mit dem, was der Installer auf die Platte legt

Nehmen Sie den veröffentlichten Installer oder das Paket, nicht einen Entwicklungs-Checkout, und listen Sie jede Datei auf, die er auf einem sauberen Rechner ablegt. Halten Sie Versionen für die Oberfläche, die Engine und die TLS-Bibliothek fest und notieren Sie, ob die Engine eine eigene ausführbare Datei oder eine in denselben Prozess geladene Bibliothek ist.

Dieser letzte Punkt prägt alles Weitere. Eine eigene ausführbare Datei, die über einen Socket gestartet wird, wirft andere Fragen auf als Code, der in eine einzige Binärdatei kompiliert wurde, und ein Installer, der beides nur nebeneinander ablegt, entscheidet die Sache in keine Richtung. Bündelung ist eine Verpackungsentscheidung, während die Beziehung zwischen den Programmen eine architektonische ist.

Schreiben Sie die Liste mit angehängten Versionen auf, denn die Bedingungen unterscheiden sich zwischen Hauptversionen.

dpkg -L openvpn | head -n 40
openssl version -a

Trennen Sie die Oberfläche von der Engine

Die OpenVPN-Copydatei nennt GPL Version 2 und dokumentiert eine Linking-Ausnahme für OpenSSL, die eine besondere Erlaubnis mit definiertem Umfang ist und keine allgemeine Lizenz zum Mischen von Bedingungen.

Erfassen Sie den Lizenztext, der mit Ihrem Build ausgeliefert wird, nicht den, der heute auf der Projektwebsite steht. Eine Veröffentlichung, die einen älteren Branch festgeschrieben hat, trägt das Dokument dieses Branches mit sich. Screenshots einer Repository-Seite sind kein Ersatz, denn die Datei, die Sie brauchen, ist die im Artefakt. Legen Sie sie neben den Installer, damit das Paket vollständig ist.

Beschreiben Sie dann die Integration ehrlich: Startet die Oberfläche die Engine als Kindprozess und spricht ein Textprotokoll, oder bindet sie eine Bibliothek ein und tauscht interne Strukturen aus? Die zweite Anordnung ist auf eine Weise eng verbunden, wie es die erste nicht ist, und dieser Unterschied ist das, wonach ein Prüfer zuerst fragen wird.

Notieren Sie, welche Dateien Sie geändert haben

Geänderter Quellcode verändert die Analyse stärker als jedes Verpackungsdetail. Wenn Sie die Engine gepatcht haben, ist der Patch selbst abgeleitete Arbeit, und die Pflicht trifft denjenigen, der das Ergebnis verteilt.

Halten Sie jeden Patch, seinen Zweck und ob er upstream geschickt wurde fest, denn ein Patch, der Ihr Repository nie verlassen hat, ist trotzdem Teil dessen, was Sie ausliefern, wenn Sie die Binärdatei ausliefern.

Konfigurationsdateien, Themes und Übersetzungen liegen meist bei der Oberfläche, aber eine Übersetzung, die Quelltextzeichenketten der Engine einbettet, erinnert daran, dass die Grenze pro Datei und nicht pro Verzeichnis verläuft. Halten Sie ein Diff zwischen der Upstream-Veröffentlichung und Ihrem Build bereit, damit die Antwort auf Anfrage vorliegt und nicht später rekonstruiert werden muss. Dieses Diff ist auch das nützlichste Artefakt, wenn ein Auditor fragt, was sich geändert hat.

Prüfen Sie die OpenSSL-Version separat

OpenSSL 3.0 und später werden unter der Apache License 2.0 vertrieben, während ältere Veröffentlichungen die OpenSSL/SSLeay-Bedingungen tragen. Das sind unterschiedliche Dokumente mit unterschiedlichen Pflichten, und eine gebündelte Engine bindet möglicherweise diejenige ein, die Ihr Build-System gefunden hat.

Bestätigen Sie die tatsächlich ausgelieferte Version und nicht die in einem Build-Skript genannte.

Eine OpenVPN-Abhängigkeit macht nicht jede OpenSSL-Änderung zu GPL-Code, und die Linking-Ausnahme beseitigt nicht die anderen Pflichten, die mit der Weitergabe der Bibliothek einhergehen. Behandeln Sie die Ausnahme als eine Klausel in einer größeren Analyse und halten Sie die eigenen Hinweise der TLS-Bibliothek zusammen mit allem anderen fest.

Stellen Sie das Nachweispaket zusammen

Das Paket hat vier Teile: das Dateiinventar mit Versionen, die Beschreibung der Integration, die Liste der Änderungen mit Diffs und die Lizenztexte im Auslieferungszustand. Fügen Sie die Hinweisdatei, die Sie verteilen, und den Ort hinzu, an dem Quellcode angeboten wird, falls Ihre Pflichten ein Angebot verlangen.

Halten Sie das Paket in einer Hand, damit keine Veröffentlichung ohne es erfolgen kann.

Nichts davon entscheidet eine Rechtsfrage, und das ist der Punkt: Es gibt einem qualifizierten Prüfer die Fakten statt einer aus dem Gedächtnis zusammengestellten Zusammenfassung. Die Marketingbeschreibung eines Anbieters ist kein Beleg für dessen Architektur, und Ihre eigene Vermutung darüber ist ebenfalls kein Beleg.