Forschung zur Compliance-Richtlinie und Kontrollstrategie für die Exportkontrolle von Open-Source-Software

Inhalt

I. Überblick

2. Exportkontrollrichtlinien der Länder für Open-Source-Software

(1) US-Exportkontrollbestimmungen zur Kontrolle von Open-Source-Software

(2) Kontrolle von Open-Source-Software durch Exportkontrollbestimmungen von China, der Europäischen Union und Japan

3. Exportkontrollstrategien wichtiger Open-Source-Communities

(1) Exportkontrollrichtlinie für internationale Open-Source-Organisationsprojekte

    1. Open-Source-Stiftung

    2. Open-Source-Lizenz

    3. Code-Hosting-Plattform

(2) Der Einfluss von Community-Statements auf die Nutzung von Open-Source-Software

4. Praxis der Compliance-Kontrolle bei der Exportkontrolle von Open-Source-Software

(1) Verwaltung und Kontrolle von Open-Source-Softwareanwendungen

    1. Identifizierung von Open-Source-Software, die der EAR unterliegt

    2. Einreichung von Open-Source-Software unter der Gerichtsbarkeit von EAR

(2) Kontrolle externer Open-Source-Beiträge

    1. Eigenentwickelter Codebeitrag

    2. Open-Source-Projektaufbau

V. Management und Kontrolle von Open-Source-Software, Verbesserungsmaßnahmen und Risikoanalyse

(1) Management von Open-Source-Software und Kontrolle von Lücken und Verbesserungen

(2) Potenzielle Risikoanalyse von Open-Source-Software

6. Referenzen

I. Überblick

Open-Source-Software ist Computersoftware, deren Quellcode frei verfügbar ist. Mit Zugriff auf den Quellcode kann jeder den Code nach eigenem Ermessen anzeigen, ändern und verteilen. Open Source stellt eine der Produktionsmethoden der Informationsgesellschaft dar. Sie ist gekennzeichnet durch groß angelegte Kollaboration und Netzwerkdienstleistung Der weltweite Open Source Code ist ein Merkmal von Open Source Software. Die Open-Source-Softwaretechnologie meines Landes ist in wichtigen Bereichen wie Betriebssystemen, Cloud-Native, künstlicher Intelligenz und Big Data vollständig angekommen.Beispielsweise gibt es in der Container-Technologie, Microservice-Technologie und DevOps-Technologie Open-Source-Beiträge aus China. Open-Source-Software ist in allen Lebensbereichen weit verbreitet. Als Open-Source-Software, die in einer Open-Source-Community gehostet wird, muss sie den Verwaltungsbeschränkungen der jeweiligen Open-Source-Community unterliegen. Aufgrund der unterschiedlichen Gesetze und Vorschriften in verschiedenen Ländern, basierend auf der Tatsache, dass die Community von verschiedenen Ländern initiiert wird, die Hosting-Plattform in verschiedenen Ländern existiert und die Versionszuordnung dieser Open-Source-Software unterschiedlich ist, sind diese Open-Source-Projekte unterliegen auch verschiedenen „anderen externen Gesetzen und Vorschriften“, wie z. B. „Exportkontrollanforderungen“. Die Vereinigten Staaten haben einst ein chinesisches Unternehmen und seine Tochtergesellschaften auf die „Entity List“ für die Exportkontrolle gesetzt, und dann kündigte das US-amerikanische Google an, dass es die Bereitstellung von technischem Support und Dienstleistungen für das Android-System, das seit jeher ein weltbekanntes ist, einstellen würde Open-Source-Projekt. .

Softwareprodukte stellen heute eine der wichtigsten Produktformen für die meisten High-Tech-Unternehmen dar, und eine große Anzahl von Open-Source-Software war beteiligt.Es ist besonders wichtig, Forschung zu Open-Source-Software-bezogenen Compliance-Richtlinien und Compliance zu betreiben. Dieses Papier untersucht hauptsächlich die Vorschriften und Richtlinien in Bezug auf Open-Source-Software und ihre Auswirkungen aus der Perspektive der Exportkontrolle.Anhand der aktuellen Compliance-Management- und -Kontrollpraktiken von Unternehmen analysiert es den aktuellen Status und die Lücken des Managements und der Kontrolle von Open-Source-Software, schlägt vor Verbesserungsmaßnahmen und erläutert die zukünftige Entwicklung von Open-Source-Software Risiken, denen Sie bei der Nutzung ausgesetzt sein können.

2. Exportkontrollrichtlinien der Länder für Open-Source-Software

Für die Erfordernisse der Politik, Wirtschaft, Militär- und Außenpolitik formuliert der Staat Gesetze und Vorschriften, die den Export von Produkten einschränken, um die Kontrolle über Exportaktivitäten auszuüben. Während unserer Recherche zu Open-Source-Software haben wir vier der größten Volkswirtschaften der Welt gescannt, um ihre Anforderungen an die Regulierung von Open-Source-Software zusammenzufassen. Die vier großen Volkswirtschaften sind die Vereinigten Staaten, Japan, die Europäische Union und China. Die wichtigsten Exportkontrollvorschriften für diese vier Volkswirtschaften lauten wie folgt:

Tabelle 1 Namen der Exportkontrollgesetze und -vorschriften in den vier großen Volkswirtschaften

(1) US-Exportkontrollbestimmungen zur Kontrolle von Open-Source-Software

Unterliegt Open-Source-Software Exportkontrollen in den Vereinigten Staaten? Eine weit verbreitete Ansicht ist, dass der Quellcode von Software nicht reguliert wird, weil er durch die Meinungsfreiheit geschützt ist. Laut Bernstein gegen Justizministerium (Bernstein gegen Justizministerium) aus dem Jahr 1995 fällt Software-Quellcode unter die Kategorie der Meinungsfreiheit und kann nicht von Regierungsbehörden reguliert werden. Aber es wurde selten erwähnt, dass das Urteil in dem Fall nicht wirksam war. Daher ist der Fall Bernstein kein gültiger Präzedenzfall, und man kann nicht einfach schlussfolgern, dass der Quellcode von Software nicht reguliert werden kann, weil er durch die Meinungsfreiheit geschützt ist. Im Gegenteil, solange der Quellcode der Software nicht „öffentlich verfügbar“ ist, unterliegt er immer noch der Rechtsprechung der US Export Administration Regulations (im Folgenden als „EAR“ bezeichnet).

Die US-Gerichtsbarkeit für Open-Source-Software basiert auf dem Konzept „Veröffentlicht“ oder „Öffentlich verfügbar“. Offengelegte Informationen können beliebig kopiert und verbreitet werden, und es ist unmöglich, die offengelegten Informationen zu kontrollieren.Daher hat der Gesetzgeber die offengelegten Informationen aus dem Zuständigkeitsbereich der EAR ausgenommen, d " Informationen und Software unterliegen nicht der EAR. Open-Source-Software kann beliebig heruntergeladen und verbreitet werden, da ihr Quellcode auf Websites oder Online-Communities im Internet öffentlich gemacht wurde, weshalb Open-Source-Software aufgrund ihrer öffentlichen Eigenschaft grundsätzlich nicht der EAR unterliegt.

Gleichzeitig messen die US-amerikanischen Exportkontrollgesetze der Verschlüsselungstechnologie einen hohen Stellenwert bei: Der US-Gesetzgeber geht davon aus, dass Verschlüsselungstechnologie zur Gefährdung der nationalen Sicherheit der Vereinigten Staaten eingesetzt werden kann, und behandelt daher Open-Source-Software mit Verschlüsselungsfunktionen besonders. Wenn die Software mit Verschlüsselungsfunktion zu dem in den Vereinigten Staaten entwickelten Code gehört oder aus der Open-Source-Community unter der Gerichtsbarkeit der Vereinigten Staaten stammt und gemäß der funktionalen Leistung als 5D002 klassifiziert ist, dann selbst wenn der Quellcode der Software im Internet veröffentlicht wurde, unterliegt die Software noch Einschränkungen, die von der EAR geregelt werden. Wenn Personen außerhalb der Vereinigten Staaten diese Software herunterladen und verwenden möchten, muss eine Ausfuhrgenehmigung eingeholt werden. Das Bureau of Industry and Security (BIS) des US-Handelsministeriums bietet jedoch eine Möglichkeit, solche Open-Source-Software von der EAR auszunehmen. Der Software-Autor oder -Benutzer kann den Quellcode der Software an die spezifischen Mailboxen der BIS und der National Security Agency (im Folgenden als „NSA“ bezeichnet) zur Aufzeichnung senden, sodass die Software nicht mehr der Gerichtsbarkeit des BIS unterliegt OHR. Wenn sich der Quellcode der Software häufig ändert, kann der Softwareautor oder -benutzer auch die Website zum Herunterladen des Quellcodes der Software und den Namen der Software zur Aufzeichnung an die spezifischen Mailboxen von BIS und NSA senden, und es besteht keine Notwendigkeit um den sich ständig ändernden Software-Quellcode wiederholt zu senden Spezifische Mailboxen für BIS und NSA. Darüber hinaus muss für Objektcode mit Verschlüsselungsfunktion (d. h. der Quellcode wird zu Maschinencode kompiliert) aus den Vereinigten Staaten der entsprechende Open-Source-Code eingereicht werden, bevor der Objektcode von der EAR ausgenommen wird Zuständigkeit.

(2) Kontrolle von Open-Source-Software durch Exportkontrollbestimmungen von China, der Europäischen Union und Japan

Aus der Analyse der Exportkontrollvorschriften der vier großen Volkswirtschaften hat nur die EAR der Vereinigten Staaten das Konzept der Open-Source-Software erwähnt und detaillierte Regeln für die Kontrolle von Open-Source-Software vorgeschlagen. In Japans Kontrollliste wird Software nicht einmal erwähnt; obwohl chinesische und EU-Vorschriften Software erwähnen, erwähnen sie nicht das Konzept von Open-Source-Software, und es gibt kein Kontrollsystem speziell für Open-Source-Software. Das Folgende veranschaulicht, wie sich die Kontrolle von Software durch Chinas Exportkontrollgesetze auf Open-Source-Software auswirken wird:

Die Kontrolle von Software nach dem chinesischen Exportkontrollgesetz konzentriert sich nach wie vor auf die Funktionen und die Leistung der Software. Der Open-Source-Charakter von Open-Source-Software befreit sie nicht von der Zuständigkeit des chinesischen Exportkontrollgesetzes. Solange die Software selbst auf der Liste des chinesischen Exportkontrollgesetzes steht, wie z. B. der Liste der Güter mit doppeltem Verwendungszweck, kann für die Software eine Ausfuhrgenehmigung erforderlich sein, selbst wenn es sich um Open-Source-Software handelt. Insbesondere ist nach den Bestimmungen des Artikels 2 des „Ausfuhrkontrollgesetzes der Volksrepublik China“ die Verbringung von kontrollierten Gütern aus dem Hoheitsgebiet der Volksrepublik China ins Ausland „Ausfuhr“; Bürger, juristische Personen und nicht rechtsfähige Organisationen der Volksrepublik China an ausländische Organisationen und Einzelpersonen Die Lieferung von kontrollierten Artikeln ist ebenfalls ein „Export“ (auch bekannt als „deemed export“).

Daher wird der Umfang des „Exports“ oder „angenommenen Exports“ von Open-Source-Software, der durch das chinesische Exportkontrollgesetz definiert wird, sehr breit sein, und sowohl Unternehmen als auch Einzelpersonen, die in China tätig sind, müssen dem besondere Aufmerksamkeit schenken. Im Folgenden finden Sie Beispiele für Szenarien, die den Export oder Nicht-Export von Open-Source-Software betreffen.

Szenarien, die als Exporte von Open-Source-Software identifiziert werden können:

(1) Ein inländisches Unternehmen beschließt, eine von ihm entwickelte Software als Open Source zu veröffentlichen, und verwendet nach Auswahl einer Open Source-Lizenz GitHub als Plattform für das Code-Hosting und die anschließende Zusammenarbeit. Wir wissen, dass Microsoft im Juni 2018 die Übernahme von GitHub für 7,5 Milliarden US-Dollar angekündigt hat. Microsoft ist ein amerikanisches Unternehmen, und die spezielle Betreibergesellschaft von GitHub ist ebenfalls ein amerikanisches Unternehmen mit Sitz in San Francisco, die alle ausländischen Organisationen und GitHubs gehören Code-Speicherplatz befindet sich hauptsächlich in den Vereinigten Staaten. . Tatsächlich erwähnte GitHub.com auch, dass die GitHub-Website, Unternehmensserver und Produkte und Informationen, die von Benutzern hochgeladen wurden, möglicherweise Handelskontrollbestimmungen unterliegen, einschließlich EAR, und gab an, dass Benutzer nur geltende Gesetze einhalten können (einschließlich US-Exportkontrolle und Sanktionsgesetze). ) Verwenden Sie für den Zugriff GitHub.com. Daher wird diese Form von Open-Source-Quellcode, wenn es sich um Softwaretechnologie handelt, deren Export verboten oder beschränkt ist, wahrscheinlich von der zuständigen Behörde als "Export" identifiziert.

(2) Ein inländisches Unternehmen beschließt, sein maschinelles Lernprogramm der Linux Foundation zu spenden. Unter der Annahme, dass das maschinelle Lernprogramm über fortschrittliche Algorithmen verfügt und eine exportverbotene Technologie ist und dass die Linux Foundation eine gemeinnützige Organisation ist, die gemäß 501(c)(3) des US-Bundessteuergesetzes gegründet wurde, handelt es sich um ein ausländisches Gesetz des Spendens von Quellcode und zugehörigem Material wird von den zuständigen Behörden mit hoher Wahrscheinlichkeit ebenfalls als „Export“ identifiziert.

(3) Ein inländisches Unternehmen hat unter der General Public License (im Folgenden als „GPL“ bezeichnet) erhebliche technische Beiträge zum Linux-Kernel geleistet, und diese Innovation ist eine Technologie, deren Export verboten ist. Gemäß der GPL-Open-Source-Lizenz sollte das Unternehmen den Quellcode in der entsprechenden ausländischen Community offenlegen, da es in diesem Fall auch sehr wahrscheinlich ist, dass die zuständige Behörde ihn als „Export“ betrachtet. Der Konflikt und die Lösung nationaler Gesetze und Open-Source-Lizenzen, die hier involviert sind, ist nicht Gegenstand dieses Artikels und wird in diesem Artikel nicht behandelt.

Szenarien, die möglicherweise nicht als Open-Source-Softwareexporte betrachtet werden:

(1) Ein inländisches Unternehmen beschließt, seine Software als Open Source für gitee bereitzustellen, aber die Software ist eine beschränkte Exporttechnologie. Die Gitee-Betriebsgesellschaft ist eine in China registrierte Firma mit Sitz in Shenzhen, und der Speicherplatz des Quellcodes sollte sich auch auf dem Territorium meines Landes befinden. Obwohl das Netzwerk weltweit zugänglich ist, sollte es nicht als "Export" angesehen werden. Es wird darauf hingewiesen, dass, sofern die Software staatliche Geheimhaltungsvorschriften beinhaltet, entsprechende Auflagen einzuhalten sind.

Da das Konzept der Open-Source-Software in den Rechtsvorschriften nicht erwähnt wird, hat auch die EU ähnliche Probleme, und es kann eine übermäßige Rechtsprechung für Open-Source-Software geben. Da Japan Software jedoch nicht separat in seiner Kontrollliste aufführt, ist Japan beim Export und Transfer von Open-Source-Software viel nachsichtiger, und es gibt keine rechtlichen Hindernisse.

Drittens: Exportkontrollstrategien für wichtige Open-Source-Communities

(1) Exportkontrollrichtlinie für internationale Open-Source-Organisationsprojekte 

Ein vollständiges Open-Source-Ökosystem umfasst Open-Source-Stiftungen (Organisationen), Open-Source-Projekte, Open-Source-Lizenzen und Code-Hosting-Plattformen sowie andere Elemente, die alle unterschiedliche Geschäftsbedingungen und rechtliche Einschränkungen haben.

1. Open-Source-Stiftung

Die Open-Source-Stiftung verwaltet Open-Source-Projekte, aber die Managementmethoden der Stiftung sind sehr unterschiedlich, und die Open-Source-Projekte unter der Stiftung können auch andere Managementmethoden wählen. Beispiel:

• Die eigenen Verwaltungsmethoden der Linux Foundation unterliegen nicht den US-Exportkontrollen.Ihre Projekte, einschließlich Linux Kernel, folgen standardmäßig dieser Verwaltungsmethode, aber ihr verteiltes Speicherprojekt Ceph gibt klar an, dass die Gerichtsbarkeit zu Kalifornien, USA, gehört und Benutzer und Exporteure erfordert die Regeln einzuhalten US-Exportkontrolle ist ein Sonderfall in der Linux Foundation;

• Die Managementmethode der Apache Foundation bekennt sich eindeutig zur US-Exportkontrolle: Die meisten ihrer Projekte, wie etwa Hadoop und Spark, unterliegen nach Einreichung (5D002) nicht der EAR-Exportkontrolle;

• Die Mozilla Foundation erklärt ausdrücklich, dass die Gerichtsbarkeit in Kalifornien liegt. Gemäß dem Verhältnis zwischen der oben genannten Gerichtsbarkeit und der Exportkontrolle erklärt die Mozallia Foundation ihre Zuständigkeit, weist jedoch nur darauf hin, dass alle Streitigkeiten dem Urteil des Gerichts in Santa Clara, Kalifornien, unterliegen. Wie bereits erwähnt, bedeutet dies nicht, dass die von ihm verwalteten Open-Source-Projekte standardmäßig Exportkontrollen unterliegen;

• Die RISC-V Foundation ist mit der Linux Foundation verbunden und hat nicht ausdrücklich erklärt, dass sie den US-Exportkontrollen unterliegt, sodass der offene RISC-V-Befehlssatzstandard, der der RISC-V Foundation gehört, nicht den US-Exportkontrollen unterliegt. Es ist erwähnenswert, dass die Mitgliedschaftsbedingungen der RISC-V Foundation auch angeben, dass ihre Gerichtsbarkeit in Delaware, USA, liegt. Gemäß der Beziehung zwischen der oben genannten Gerichtsbarkeit und der Exportkontrolle erklärt die RISC-V-Stiftung ihre Zuständigkeit und erklärt, dass alle Streitigkeiten über Mitgliedschaftsbedingungen von einem bestimmten Gericht entschieden werden, dies bedeutet jedoch nicht, dass die von ihr verwalteten Open-Source-Projekte Gegenstand sind um die Kontrolle standardmäßig zu exportieren.

2. Open-Source-Lizenz

Gängige Open-Source-Lizenzen wie GPL , LGPL, B SD, MIT, Mozilla und Apache enthalten keine Aussagen, die nichts mit staatlicher Exportkontrolle zu tun haben. Darüber hinaus ist es für Open-Source-Projekte einfacher, Lizenzbedingungen einzuhalten und zu ändern, sodass das Risiko einer Exportkontrolle bei Open-Source-Lizenzen relativ gering ist.

3. Code-Hosting-Plattform

Aus der Recherche zu den drei Code-Hosting-Plattformen GitHub, SourceForge und Google Code geht hervor, dass alle drei Plattformen eindeutig angeben, dass sie die US-Exportkontrollbestimmungen einhalten und ihre Gerichtsbarkeit in Kalifornien liegt (d. h. Streitigkeiten müssen gemäß Kalifornien beigelegt werden Gesetz).

Am Beispiel von GitHub stellt GitHub klar, dass sein GitHub Enterprise Server der Exportkontrolle unterliegt und nicht in sanktionierte Länder exportiert werden darf. Was die allgemeinen Funktionen der GitHub-Website betrifft, da das Hoch- und Herunterladen des in den Vereinigten Staaten eingerichteten GitHub-Servers der Exportkontrolle und US-Gesetzen unterliegt, kann seine normale Verwendung reguliert werden. Das heißt, der Open-Source-Projektcode auf GitHub kann die Exportkontroll- und US-Gesetze wie die Informationen auf GitHub einhalten, während er der eigenen Open-Source-Lizenz des Projekts entspricht. Auch der in der Übersicht erwähnte Huawei-Vorfall dürfte durch den GitHub-Faktor in diesem „Entity-List“-Vorfall betroffen sein und dessen Zugriff auf Open-Source-Projekte beeinträchtigt worden sein.

Wie können Open-Source-Projekte Exportkontrollrisiken vermeiden? Es gibt vier Situationen, aber alle erfordern die Unterstützung und Mitarbeit des Sponsors oder Entwicklers des Open-Source-Projekts:

• Für Open-Source-Projekte, die auf GitHub gespeichert wurden, wenn sie auch auf anderen Hosting-Plattformen außerhalb der Vereinigten Staaten gespeichert sind, und die Entwickler eigenständig Updates an GitHub und andere Hosting-Plattformen übermitteln und während des Entwicklungsprozesses keine Informationen von GitHub herunterladen , dann wird die Hosting-Plattform außerhalb der Vereinigten Staaten Plattformzugriff auf Open-Source-Projekte unterliegt nicht den US-Exportkontrollen;

• Wenn der Sponsor für Open-Source-Projekte, die auf GitHub hinterlegt wurden, über eine lokale Kopie verfügt und keine Updates von GitHub heruntergeladen hat, kann der Sponsor ein Open-Source-Projekt auf einer anderen Hosting-Plattform außerhalb der Vereinigten Staaten erstellen und die Kopie auf diese Hosting-Plattform hochladen . Danach übermitteln Entwickler eigenständig Updates an GitHub und Hosting-Plattformen außerhalb der Vereinigten Staaten und laden während des Entwicklungsprozesses keine Informationen von GitHub herunter, sodass der Erwerb von Open-Source-Projekten von Hosting-Plattformen außerhalb der Vereinigten Staaten nicht dem US-Export unterliegt Kontrollen;

• Bei neu gestarteten Open-Source-Projekten kann der Initiator das Projekt gleichzeitig auf der Hosting-Plattform und GitHub außerhalb der Vereinigten Staaten erstellen, und der Entwickler übermittelt unabhängig Updates an die Hosting-Plattform und GitHub außerhalb der Vereinigten Staaten und lädt keine herunter Informationen von GitHub während des Entwicklungsprozesses Der Erwerb von Open-Source-Projekten von Hosting-Plattformen außerhalb der USA unterliegt nicht den US-Exportkontrollen;

• Bei neu gestarteten Open-Source-Projekten kann der Initiator direkt ein Projekt auf einer Hosting-Plattform außerhalb der Vereinigten Staaten erstellen und der Entwickler aktualisiert dann auf die Hosting-Plattform, dann unterliegt das von der Hosting-Plattform bezogene Open-Source-Projekt nicht der US-Exportkontrolle .

Aus der obigen Analyse ist ersichtlich, dass, obwohl nicht alle von Open-Source-Stiftungen und Open-Source-Communities verwalteten Quellcodes den US-Exportkontrollen unterliegen, fast alle internationalen Open-Source-Organisationen oder Projekte mit Sitz in den Vereinigten Staaten die US-Exportkontrollen ohne erfüllen Ausnahme. Politik.

(2) Der Einfluss von Community-Statements auf die Nutzung von Open-Source-Software

Bei der tatsächlichen Verwendung von Open-Source-Software müssen wir, um unsere Fähigkeit zur Kontrolle der Open-Source-Software zu verbessern, bei der Auswahl eines Open-Source-Softwareprojekts die Möglichkeit berücksichtigen, jederzeit auf die Version und Technologie in ihrem gesamten Lebenszyklus Bezug zu nehmen Zeit ohne Einschränkung, um die Anforderungen der Referenzierung von Open-Source-Software zu erfüllen.Das vollständige Lebenszyklusmanagement von Softwareprodukten erfordert:

• Wenn Sie sich für Open-Source-Software entscheiden, müssen Sie die drei Erklärungen der Open-Source-Community/Open-Source-Stiftung, zu der sie gehört, die Erklärung des Projekts selbst und die Erklärung der verwendeten Open-Source-Lizenz sorgfältig lesen, um die Exportkontrollgerichtsbarkeit zu verstehen und Beschränkungen verschiedener Länder. Die obige Erklärung in Bezug auf die verwendete Open-Source-Software muss während des gesamten Lebenszyklus verfolgt werden, und wenn ihre Bedingungen geändert werden, muss sie schnell reagieren und ihre Auswirkungen auf die Exportkontrolle analysieren;

• Unter den gleichen Bedingungen wird Open-Source-Software im Rahmen der heimischen Open-Source-Stiftung und Open-Source-Community bevorzugt;

• Open-Source-Hosting-Plattformen unterliegen sowohl den EAR-Exportkontrollen als auch den US-Gerichten und sind das größte Risiko für Open Source. Unter den gleichen Bedingungen wird Open-Source-Software innerhalb der heimischen Open-Source-Community bevorzugt;

• Gleichzeitig, nach der Unterwerfung unter die Exportkontrolle, ob es andere Gegenmaßnahmen gibt, wie z. B. den Ersatz von Open-Source-Software, die Möglichkeit, Open-Source-Software zu schützen usw.;

• Erstellen Sie eine Open-Source-Benchmark-Bibliothek für die von Ihnen verwendete Open-Source-Software, vorzugsweise eine Vollversionsbibliothek der von Ihnen verwendeten Open-Source-Komponenten.

Vollständige Lebenszykluskontrolle ausgewählter Open-Source-Softwarelizenzen, um die Einhaltung von Lizenzänderungen oder sogar die Einführung neuer, von der Exportkontrolle betroffener Lizenzen zu verhindern.

Viertens: Compliance-Kontrollpraxis für die Exportkontrolle von Open-Source-Software

(1) Verwaltung und Kontrolle von Open-Source-Softwareanwendungen

In den aktuellen Hightech-F&E-Unternehmen ist Open-Source-Software an fast jedem Softwareforschungsprojekt beteiligt. In den letzten Jahren haben Unternehmen in der Branche damit begonnen, Open-Source-Compliance-Governance durchzuführen. Durch kontinuierliche Verbesserung haben einige Unternehmen nun eine Reihe von Open-Source-Software-Managementsystemen gebildet. Das Managementsystem umfasst hauptsächlich drei Teile: Open-Source-Sicherheit, Lizenzen und Ausfuhrkontrolle. In diesem Abschnitt werden hauptsächlich Compliance-Kontrollpraktiken im Hinblick auf die Exportkontrolle behandelt. Obwohl, wie oben erwähnt, die Exportkontrollen von Japan, der Europäischen Union und China unter den vier großen Volkswirtschaften Software entweder nicht erwähnen oder das Konzept von Open-Source-Software nicht haben.Zum Beispiel basiert Chinas Exportkontrollpolitik hauptsächlich auf der funktionale Leistung des Endprodukts Bestätigung der Bedenken, aber im Wesentlichen gibt es „unsichtbare“ Exportkontrollen bei der Verwendung von Open-Source-Software. Hier erörtert der Autor die Einhaltung des US EAR Act, der explizitere und strengere Anforderungen an die Kontrolle von Open-Source-Software stellt, basierend auf der Compliance-Management- und Kontrollpraxis von Open-Source-Software durch ein inländisches Unternehmen.

Gemäß den Bestimmungen der EAR (734.3(b)(3), 734.7(b) und 742.15(b)) unterliegt verschlüsselte Open-Source-Software mit ECCN 5D002 weiterhin der EAR, es sei denn, ihr Objektcode und ihr Quellcode werden eingereicht BIS und ENC nach Bedarf. Der Encryption Request Coordinator hat eine Benachrichtigung vorgenommen. Obwohl die Einreichung keine zwingende Anforderung der EAR ist, haben sich Unternehmen entschieden, verschlüsselte Open-Source-Software, deren ECCN 5D002 ist, einzureichen und zu verwalten, um das Risiko der Einhaltung der Exportkontrolle zu verringern, und haben Kontrollmaßnahmen für die Open-Source-Software gemäß der EAR ergriffen Zuständigkeitsbereich der EAR, die im Forschungs- und Entwicklungsprozess verwendet werden.

1. Identifizierung von Open-Source-Software, die der EAR unterliegt

Die korrekte Identifizierung aller Open-Source-Software, die in F&E-Aktivitäten verwendet wird, ist die Grundlage für die Identifizierung von Open-Source-Software im Zuständigkeitsbereich der EAR, aber es gibt derzeit keine ausgereifte und zuverlässige Lösung für eine 100% korrekte Identifizierung in der Branche.Es verbessert die Erkennungseffizienz und -genauigkeit von Open-Source-Software, vermeidet das Problem rein manueller Erkennungsfehler und löst auch das Problem der unvollständigen Erkennung, das aufgrund der vorzeitigen Aktualisierung der Scantool-Datenbank auftreten kann.

Nach der Identifizierung von Open-Source-Software ist es notwendig, diese Open-Source-Software daraufhin zu analysieren, ob sie der EAR unterliegt. Zu diesem Zweck wird eine wissenschaftliche und praktikable Methode zur Identifizierung zusammengefasst, die wir die Vier-Elemente-Methode zur Identifizierung von Open-Source-Software im Zuständigkeitsbereich der EAR nennen, wie in der folgenden Abbildung dargestellt:

 

Einfach ausgedrückt, wenn eine Open-Source-Software die oben genannten vier Bedingungen gleichzeitig erfüllt, betrachten wir die Open-Source-Software als Open-Source-Software, die der EAR unterliegt.

2. Einreichung von Open-Source-Software unter der Gerichtsbarkeit von EAR

Diese Praxis erfordert, dass Open-Source-Software, die als der EAR unterliegend identifiziert wurde, die Einreichung beim BIS abschließen muss, bevor die Softwareversion für die Öffentlichkeit freigegeben wird, und durch die Einreichung wird die Open-Source-Software unter der Gerichtsbarkeit der EAR in eine Nicht-Software umgewandelt -jurisdiktionale Open-Source-Software, wodurch das Risiko der Einhaltung der Exportkontrolle verringert wird. Die spezifische Methode besteht darin, den BIS- und ENC-Koordinator für Verschlüsselungsanfragen per E-Mail zu benachrichtigen und die URL oder Netzwerkadresse mitzuteilen, wo sich der verschlüsselte Quellcode befindet. Jedes Mal, wenn sich die URL ändert, muss der BIS- und ENC-Koordinator für Verschlüsselungsanfragen erneut benachrichtigt werden. aber die Quellcode-Aktualisierung oder -Änderung erfordert keine erneute Benachrichtigung.

Unternehmen verwalten die Einreichung von Open-Source-Software zentral aus Sicht des Unternehmens, um einerseits die Zuverlässigkeit und Glaubwürdigkeit der Quelle sicherzustellen, andererseits eine Ressourcenteilung zu realisieren und unterschiedliche F&E-Einheiten zu vermeiden Ressourcenverbrauch und verbessert die Effizienz.

(2) Kontrolle externer Open-Source-Beiträge

Als Anwender von Open-Source-Software, aber auch als Mitwirkende von Open-Source-Software. Es gibt zwei gängige Wege, um externe Beiträge zu Open Source zu leisten: Zum einen, um selbst entwickelten Code direkt in die Open-Source-Community einzubringen, und zum anderen, um Bauprojekte in der Open-Source-Community zu leiten.

1. Eigenentwickelter Codebeitrag

Um die gemeinsame Konstruktion der Open-Source-Community und die gemeinsame Nutzung von Technologie und Code zu realisieren, muss das F&E-Projekt in einigen Fällen den Quellcode mit der Open-Source-Community teilen, während das Open-Source-Projekt von der Open-Source bezogen wird Gemeinschaft. Zur Einhaltung der Exportkontrollrichtlinien darf Software, die von EAR kontrollierte Technologie oder Software enthält, der Open-Source-Community nicht als Open-Source-Software offengelegt werden. In dieser Praxis sind die Kontrollanforderungen für den externen Beitrag von Open-Source-Code: Bevor der Quellcode an die Open-Source-Community übermittelt wird, muss das Projektteam feststellen, ob er kontrollierte Software enthält und die kontrollierte Software nicht als Open-Source-Software veröffentlicht werden kann; die Software von kontrollierten Projekten mit kontrollierten Technologien Quellcode darf nicht an die Außenwelt weitergegeben werden.

2. Open-Source-Projektaufbau

Gegenwärtig haben viele Unternehmen in meinem Land ihre eigenen Open-Source-Softwareentwicklungsprojekte, der Code wird von der Linux Foundation gehostet, und gleichzeitig werden Spiegel auf der chinesischen Open-Source-Community aufgebaut. Open Source China ist derzeit die größte Open-Source-Technologie-Community. Obwohl Open-Source-Projekte Autonomie bei der Wahl der Hosting-Plattformen haben, entscheiden sich die meisten chinesischen Projektteams dafür, Spiegelbilder in China zu erstellen, wenn sie Code auf großen internationalen Plattformen hosten.Nicht nur chinesische Projekte, sondern auch Open-Source-China ist vielen großen internationalen Plattformen ähnlich. Der Abschluss entsprechender Vereinbarungen kann einerseits die Open-Source-Community kontinuierlich weiterentwickeln und ist gleichzeitig auch ein langfristiger Garant für die Sicherheit der Nutzung von heimischem Open-Source-Code.

Fünf: Open-Source-Software-Control-Verbesserungsmaßnahmen und Risikoanalyse

(1) Management von Open-Source-Software und Kontrolle von Lücken und Verbesserungen

In der oben genannten Kontrollpraxis für Open-Source-Software haben Unternehmen relativ umfassende Kontrollmaßnahmen für Open-Source-Software formuliert, und das Risiko der Einhaltung der Exportkontrolle wurde vollständig kontrolliert. Allerdings gibt es noch einen gewissen Unterschied zwischen der Umsetzung und den bestehenden Richtlinienanforderungen, der sich in den aktuellen EAR-Vorschriften widerspiegelt, die nur Open-Source-Software mit nicht standardmäßigen Verschlüsselungsalgorithmen kontrollieren, d.h. nur Open-Source-Software mit nicht-standardisierten Verschlüsselungsalgorithmen Standard-Verschlüsselungsalgorithmen sind die Angelegenheit der US-Exportkontrolle. Der Gegenstand des Unternehmens, andere fallen nicht in seine Gerichtsbarkeit, und es besteht keine Notwendigkeit, bei ihm einzureichen. Diese Richtlinie wird im März 2021 geändert. Wenn die Einreichung jedoch derzeit noch gemäß den ursprünglichen Anforderungen durchgeführt wird, wird die gesamte verschlüsselte Open-Source-Software eingereicht, und der Kontrollstandard wird höher sein. Diese Lücke stellt zwar kein Compliance-Risiko dar, erhöht jedoch den Arbeitsaufwand für die Einreichung.

Um diese Lücke zu schließen, diskutieren Corporate Compliance und Business Units laufend Verbesserungsmaßnahmen und Vorschläge mit dem Ziel, die EAR-Anforderungen vollständig zu erfüllen und nur noch Open-Source-Software mit nicht standardisierten Verschlüsselungsalgorithmen beim BIS anzumelden. In diesem Schema ist der kritischste Punkt, wie zu bestimmen ist, ob der Verschlüsselungsalgorithmus ein Standardalgorithmus ist. Die Empfehlungen für die Umsetzung des Implementierungsplans lauten wie folgt:

• Bestimmen Sie zunächst gemäß der Beschreibung der Standardverschlüsselungsalgorithmen im Gesetz die Liste der derzeit verwendeten Standardverschlüsselungsalgorithmen, aber diese Liste deckt nicht alle Standardverschlüsselungsalgorithmen ab und dient nur als Referenz für Benutzer;

• Der Benutzer ist verantwortlich für die Beurteilung des Standards und Nicht-Standards des Verschlüsselungsalgorithmus der Open-Source-Verschlüsselungssoftware. Die Beurteilungsmethode bezieht sich auf die Liste der Standard-Verschlüsselungsalgorithmen. Wenn der von der Verschlüsselungssoftware verwendete Verschlüsselungsalgorithmus in dieser Liste enthalten ist, ist er es gilt als Standard-Verschlüsselungsalgorithmus;

• Wenn der von der Verschlüsselungssoftware verwendete Algorithmus nicht in dieser Liste enthalten ist, muss er gemäß der Definition des Nicht-Standard-Verschlüsselungsalgorithmus beurteilt werden, und die Beurteilung, ob es sich um einen Nicht-Standard-Verschlüsselungsalgorithmus handelt, erfolgt und die Beurteilung Basis: in welcher internationalen Norm der Algorithmus öffentlich freigegeben ist;

• Beurteilungsgrundlage für Manager zur Überprüfung von Standardverschlüsselungsalgorithmen, die nicht in der Liste der Standardverschlüsselungsalgorithmen enthalten sind. Wenn die Beurteilungsgrundlage zuverlässig ist, wird der modifizierte Algorithmus in die Liste der Standardverschlüsselungsalgorithmen aufgenommen, andernfalls wird Open-Source-Software mit nicht standardmäßigen Verschlüsselungsalgorithmen beim BIS eingereicht.

(2) Potenzielle Risikoanalyse von Open-Source-Software

Obwohl die Verwendung von Open-Source-Software den US-Exportkontrollen vollständig entsprochen hat, bedeutet dies in dieser Praxis nicht, dass kein Risiko besteht. Wie aus den oben skizzierten Fällen ersichtlich ist, kann es zu einer Extremsituation kommen: Sobald das EAR in den Vereinigten Staaten modifiziert wird, wird der Steuerung einige grundlegende Basissoftware wie Hochleistungssoftware und EDA-Software hinzugefügt (dies ist nicht der Fall unmöglich, im November 2018 hat die US BIS öffentliche Meinungen darüber eingeholt, ob neue Technologien wie KI und maschinelles Lernen in die Kontrollliste aufgenommen werden sollten) und die aktuelle „Einreichung ist nicht reguliert“ geändert (die fast alle ASF Open Source umfasst Projekte) auf „Einreichung und muss reguliert werden“ “, was bedeutet, dass eine große Anzahl von Kern-Open-Source-Projekten Exportkontrollen unterliegen werden.

Mit anderen Worten, wenn der Großteil der von uns verwendeten Open-Source-Software von diesen einflussreichen externen Gemeinschaften stammt und diese Gemeinschaften den nationalen Exportkontrollrichtlinien unterliegen, dann wird diese Open-Source-Software immer von Änderungen der Exportkontrollrichtlinien betroffen sein . Wir haben klar erkannt, dass das Wesen der Exportkontrolle darin besteht, dass Länder nicht wollen, dass die Dinge (Gegenstände), die ihnen wichtig sind, an Länder/Personen (Embargoländer/eingeschränkte Subjekte) transferiert werden, die sie nicht mögen.Die aktuelle internationale Situation ist unvorhersehbar . . . , wenn sich die Form verändert, wird Open-Source-Software als zweischneidiges Schwert, das alle Lebensbereiche ernsthaft betrifft, sehr wahrscheinlich als Waffe gegen ein Land oder ein Unternehmen eingesetzt.

Langfristig muss China also seine eigene einflussreiche Hosting-Plattform für Open-Source-Projekte aufbauen, seine eigene Open-Source-Power entwickeln und Open-Source-Enthusiasten auf der ganzen Welt auf offenere Weise anziehen. China begann 2008 mit dem Aufbau einer chinesischen Open-Source-Community, die sich inzwischen zur größten Open-Source-Technologie-Community in China entwickelt hat. Im vierzehnten Fünfjahresplan des Landes wurde „Open Source“ in den Plan aufgenommen. Mit Blick auf chinesische Unternehmen hat auch Huawei als Vertreter herausragender Risikomanagement-Unternehmen seine Risiken in Open-Source-Software früh erkannt: Huawei hat in China ein komplettes Open-Source-Ökosystem für Basissoftware wie Betriebssysteme, Datenbanken und KI Deep aufgebaut Learning Frameworks Werden Sie zu einer wichtigen Kraft in Chinas Open Source.

Auch für Unternehmen, die weitreichend von Open-Source-Software und Exportkontrollen betroffen sind, ist es notwendig, sich auf Gefahren vorzubereiten und mehr Beiträge zu leisten.

Sechs: Referenzen

[1] China: „Exportkontrollgesetz der Volksrepublik China“

[2] China: „Güterkatalog mit doppeltem Verwendungszweck“

[3] Japan: << Security Trade Management >>;

[4] Japan: „Japan Export Trade Control Order“;

[5] Vereinigte Staaten: „Teil 734 – Geltungsbereich der Export Administration Regulations“;

[6] Vereinigte Staaten: „Teil 742 – Kontrollrichtlinie – CCL-basierte Kontrollen“;

[七]《Amtsblatt der Europäischen Union》（欧盟公报））：《Verordnung-EG-Nr.428-2009-des-EU-Rates vom 5. Mai 2009 zur Einrichtung einer Gemeinschaftsregelung -die-kontrolle-der-exporte-transfervermittlung-und-transit-von-gütern mit doppeltem verwendungszweck》

[8] Die Linux Foundation veröffentlichte ein Whitepaper: „Understanding Open Source Technology and U.S. Export Control“;

[9] The Linux Foundation: „The Linux Foundation veröffentlicht ein White Paper, das erklärt, wie man auf US-Exportkontrollen bei Open-Source-Projekten reagiert“ 2020.7

[10] China Open Command Ecology (RISC-V) Alliance: „Risikoanalyse und Vorschläge für Gegenmaßnahmen für Open-Source-Projekte“.

Autoren dieses Artikels: Z.YQ, F.YP, Zh.X, X.ShM

 

Haftungsausschluss

Die für das Verfassen dieses Artikels erforderlichen Informationen werden aus legalen und öffentlichen Kanälen gesammelt, und wir können keinerlei Garantie für die Authentizität, Vollständigkeit und Genauigkeit der Informationen geben;

Dieser Artikel dient nur dem Zweck des Teilens, der Kommunikation und des Lernens, und niemand sollte den Inhalt dieses Artikels ganz oder teilweise als Grundlage für die Entscheidungsfindung nehmen, und die Konsequenzen liegen in der Verantwortung des Akteurs.

 

Quelle: Compliance Xiaoke

 

{{o.name}}

{{m.name}}