Abkommen über Handel mit Dienstleistungen: Geleakte Verhandlungsdokumente beinhalten Open-Source-Verbot

Demonstration gegen TiSA, Paradeplatz Zürich. CC BY-NC-ND 2.0 via Christian Natiez

Das umstrittene Abkommen über den Handel mit Dienstleistungen (TiSA) wird derzeit von über 50 Staaten verhandelt. Die Electronic Frontier Foundation (EFF) hat einen Blick auf jüngst durchgesickerte Verhandlungsdokumente zum E-Commerce-Kapitel geworfen.

Danach soll es Staaten künftig untersagt sein, den Transfer und Zugang zu Softwarequellen als Bedingung für Software-Dienstleistungen festzusetzen, wenn der Entwickler aus einem anderen Vertragsstaat stammt. Damit kann die Durchsetzung von sogenannten Copyleft-Lizenzen wie der European Union Public License (EUPL) oder der GNU General Public License (GPL) unter der Rechtsordnung der an dem Dienstleistungsabkommen beteiligten Staaten unmöglich werden. Die Bestimmung richtet sich vor allem gegen die Option einer verpflichtenden Hinterlegung von Softwarequellen im öffentlichen Beschaffungsbereich, die zur Abwehr von Spionage immer wieder in der Diskussion steht. So forderte der Schmid-Bericht (2002) über die Existenz des Abhörsystems Echolon beispielsweise

die Kommission und die Mitgliedstaaten [der EU] auf, Softwareprojekte zu fördern, deren
Quelltext offengelegt wird, da nur so garantiert werden kann, dass keine „Backdoors“
eingebaut sind…

In Vorbeugung einer gesetzlich verpflichtenden Offenlegung haben viele Unternehmen wie Microsoft durch freiwillige Offenlegung von Softwarequellen gegenüber nationalen Sicherheitsbehörden guten Willen gezeigt. Jene Option auf Gesetzgebung, Beschaffungsbestimmungen oder Fördermaßnahmen zur verpflichtenden Quellcodehinterlegung bzw. quelloffenen Software-Lizenzierung würden die Vertragsstaaten ausdrücklich aufgeben. Ausgenommen von den vorgesehenen TiSA-Bestimmungen soll Software für „kritische Infrastrukturen“ sein. Anwendung sollen sie dagegen ausdrücklich auf „Massenmarkt-Software“ finden. Diese unausgegorenen Abgrenzungen des Anwendungsbereiches mögen sich zwar technisch nachbessern lassen, aber der Souveränitätsverzicht bliebe nicht minder marktfern und interessenwidrig. Wieder einmal zeigen die durchgesickerten Verhandlungsdokumente wie problematisch die mangelnde Transparenz der TiSA-Verhandlungen ist. Die EFF warnt vor handelspolitisch motivierter Zementierung („Lock-In“) von Regeln für das Internet, die Vertragsstaaten bald nach Abschluss bedauern dürften.

Deine Spende für digitale Freiheitsrechte

Wir berichten über aktuelle netzpolitische Entwicklungen, decken Skandale auf und stoßen Debatten an. Dabei sind wir vollkommen unabhängig. Denn unser Kampf für digitale Freiheitsrechte finanziert sich zu fast 100 Prozent aus den Spenden unserer Leser:innen.

20 Ergänzungen

  1. Danke für den Hinweis!

    Wie absurd ist das denn? Denn mal ganz abgesehen davon, dass der ganze Bereich Krypto damit kaputt ginge: Auch damit der Software-Markt „erwachsen“ wird und der Kunde normale Regress-Ansprüche stellen kann, ist es langfristig doch zwingend notwendig, dass der Hersteller die Fehlerfreiheit seines Produktes durch den Quellcode garantiert. Wer nicht offen legt, muss sich auf Dauer dem Risiko aussetzen, mit höheren Regress-Kosten konfrontiert zu sein, damit mehr Kundennutzen eintreten kann.

    Wie kann man denn bitte einen so anti-marktwirtschaftlichen Passus in ein Abkommen einbauen und damit versuchen, die Software-Monopole um weitere Jahrzehnte fort zu schreiben – wer führt uns da bitte hinter die Fichte?!

  2. Das ist eine Ente. Im Entwurfstext (https://goo.gl/1wRsu2) steht lediglich drin, dass kein Vertragsstaat den Zugriff auf Quellcode erzwingen darf. Kritische Infrastruktur und Auftragsentwicklungen sind zudem ausgenommen. Von einem Open-Source-Verbot ist das meilenweit entfernt, allenfalls ein möglicher Open-Source-Zwang würde dadurch eingeschränkt.

    1. Genau darum geht es. Handelsabkommen wirken immer nicht nur auf gesetzgeberische, sondern auch um administrative Entscheidungen, wie etwa die Lizenzierung von Quellcode. Wenn der Staat Software unter der EUPL oder der GPL lizenziert, dann „erzwingt“ er unter den Bedingungen dieser gewählten Lizenzen Quellcodeoffenlegung. Ich habe es vorsichtig formuliert, aber sehe, dass auch die GPL-Durchsetzung vor Gericht gefährdet wäre.

      1. In diesem Fall folgt die Quellcode-Offenlegung aber aufgrund von Urheberrechten am Code des Lizenznehmers, die der Staat in diesem Fall selbst innehat. Selbst bei maximal verschwörungstheoretischer Betrachtungsweise kann ich da nicht erkennen, inwieweit der Entwurfstext da anwendbar sein sollte.

      2. Weshalb sollte der Staat als Auftraggeber einer Softwareentwicklung anschließend Urheberrechte an dieser Entwicklung innehaben? Ich sehe das exakt wie André, dass die Formulierung des Vertragstext benutzt werden könnte, eine Anforderung nach GPL für die entwickelte Auftragssoftware von staatlicher Seite stellen zu dürfen, als Handelshemnis unterbinden zu können.

  3. Decompilierung ist nach deutschem Recht erlaubt, um die Interoperabilität von Programmen zu gewährleisten. Möge dieser Paragraph des Urheberrechtsgesetzes erhalten bleiben!

      1. Ok, eigentlich ist es doch erlaubt, auch zur Prüfung der Sicherheit! Wer sich aber hinstellt und sagt, er habe ein Protokoll anhand von Dissassembling des Treibers anstatt durch Mitschneiden von erzeugter Kommunikation implementiert, der hat ein erheblich größeres Klagerisiko.

  4. Aber mit open source hat der Artikel nichts zu tun. Es geht um das Recht staatlicher Stellen, in den Quellcode kommerzieller Programme Einblick nehmen zu dürfen. Z.B. was es mit dem NSA- key im Windows NT auf sich hatte.
    Im Gegenteil, diese Bestimmung könnte dazu führen, dass anstelle fremder kommerzieller Software mit möglichen undokumentierten Hintertüren künftig mehr open source verwendet wird.
    Eure Überschrift ist irreführend.

  5. Seh da auf Anhieb einen Haufen latent kritikwürdiger (aber eigentlich kompromisslos schwammiger) Stellen wie das „subject to reasonable network management“, „provided that such devices do not harm the network“, „lawful network traffic“ …

    Zu dem closed-source-Passus, ich bin ja persönlich der Ansicht, dass neben kritischen Infrastrukturen insbesondere Massenmarktprodukte (wenn sie hinreichend general-purpose sind, oder sonstwie kritisch für das tägliche Leben sein können) immer komplett offengelegt zu sein haben, da sie qua ihrer Verbreitung so etwas wie Infrastruktur darstellen. Schluss mit proprietären Systemen in unseren Taschen … eine mysteriöse Infrastruktur ist ein Sicherheitsrisiko, das eine Gesellschaft sich nicht antun dürfte. Den gegenwärtigen Zustand (Intellectual-Property-Feudalismus) zu akzeptieren und als Modell für die Zukunft zu nehmen, ist IMHO dumm und unverantwortlich. Verantwortlich würde ich es finden, wenn die Entscheider einfach mal Cory Doctorows Argumentation hinsichtlich Prothesen etc. folgten …

    1. Wollt ich auch gerade schreiben. Besonders was network managment angeht, movement of information (da lacht sich Fratzenbuch einen ab – Milliardenklagen werden bestimmt schon vorbereitet) und diverse schwammige sprich technikfremde Definitionen.

      Hier braut sich mal wieder typisch gewinnorientierter BWL Kokolores zusammen der auf den Standards des letzten Jahrhunderts beruht. Freifahrtschein für ISDS Klagewellen.

  6. Wie absurd ist das denn? Dann … verschicken wir wieder Fax und Briefe oder was ? :D

  7. Ich lese das wieder mal mit gemischten Gefühlen. Wie Bernd schon ausführte, es geht hier mitnichten um ein Verbot von Open Source als mehr um das Verbot, die Offenlegung der Quellen als Anforderung bei Softwarebeschaffungen festzuschreiben. Das ist etwas ganz anderes als ein Verbot von Open Source. Hat es Netzpolitik nötig, so billige Propaganda zu machen?

    1. „No Party may require the transfer of, or access to, source code of software owned by a
      person of another Party, as a condition of providing services related to such software in its
      territory.
      For purposes of this Article, software subject to paragraph 1 is limited to mass-market
      software, and does not include software used for critical infrastructure.“

      Ich kann jetzt nicht erkennen, dass neue Auftragsentwicklungen davon betroffen sein sollen bzw. OpenSource nicht als Bedingung gestellt werden kann. Vielmehr geht es doch um bestehende Software, die an viele andere Kunden verkauft wird.
      Natürlich ist auch das nicht optimal: Ein Smartphone-OS, ein Officepacket oder die Firmware von der neuen Stasi-Barbie gehören wohl nicht zur kritischen Infrastruktur.

  8. Ich lese netzpolitik.org gern und oft, aber mit DIESER Überschrift habt Ihr Euch wirklich keinen Gefallen getan. Ein „Open-Source-Verbot“ gibt der Text definitv nicht her, und Eure berechtigte Kritik an der politischen Stoßrichtung des Vertragstextes wird dadurch entwertet. Lieber die Bälle etwas flacher halten, das soll hier ja keine Boulevard-Veranstaltung werden.

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.