Lizenzkonformität Archives - Freigiebigkeit

Ein sauberes Cookie-Management — mit bootScore

Karsten Reincke — Tue, 26 Sep 2023 08:41:00 +0000

Einen adäquaten Cookie-Dialog einzublenden ist das eine. Ihm eine echte Bedeutung zu geben, das andere. Denn die Abfrage allein reicht nicht. Wir müssen die Antworten unserer Leserinnen auch auswerten. Wir dürfen ausschließlich solche Cookies auf deren Rechnern ablegen, die zu schreiben sie oder das Gesetz uns erlaubt haben. Ein JavaScript-Funktion, die das gewährleistet, implementiert die Semantik des Cookie-Dialogs und etabliert ein sauberes Cookie-Management.

Das Plugin bs-Cookie-Settings selbst liefert nur die Cookie-Abfrage. Wie man die aktiviert, hatte ich bereits beschrieben. Die entsprechende Semantik zu implementieren, sieht bootScore als Aufgabe der jeweiligen Web-Designerin. Hier eine Variante, die gern allgemein wiederverwendet werden darf:

[ de | en ]

Lösung

Lade die JS-Cookie-Bibliothek von z.B. cdnpkg.com herunter und lege sie (entpackt) unter dem Namen js/js.cookie.min.js in Deinem Child-Theme-Ordner ab.
Erweitere in Deiner Datei functions.php die Funktion bootscore_child_enqueue_styles() um den Eintrag

wp_enqueue_script('js-cookie',get_stylesheet_directory_uri().'/js/js-cookie-min.js',false, '', true););

Erweitere die Datei js/custom.js Deines Child-Themes so:

jQuery(function ($) {

  $(document).ready(function(){
    const bsCookieSettings='bs_cookie_settings';
    const analytics = 'analytics';
    const advertising = 'advertising';
    const analyticDemoCookie='bsAnalyticCookie';
    const advertisingDemoCookie='bsAdvertisingCookie';
    const necessaryDemoCookie='bsNecessaryCookie';
    const demoCookieValue='demo-cookie';

    // alert("adding cookie writing algorithm");
    const bsv=Cookies.get(bsCookieSettings);
    if (bsv) {
      const allowedCookies=JSON.parse(bsv);
      // alert(allowedCookies.level);

      if (allowedCookies.level.includes(analytics)) {
        // alert("writing analytic cookies");
        if (!(Cookies.get(analyticDemoCookie))) { 
          Cookies.set(analyticDemoCookie, demoCookieValue, { expires: 100, path: '/' });
        };
      };
      if (allowedCookies.level.includes(advertising)) { 
        // alert("writing advertising cookies"); 
        if (!(Cookies.get(advertisingDemoCookie))) { 
          Cookies.set(advertisingDemoCookie, demoCookieValue, { expires: 10, path: '/' });
        };
      };
      // alert("writing necessary cookies"); 
      if (!(Cookies.get(necessaryDemoCookie))) { 
        Cookies.set(necessaryDemoCookie, demoCookieValue, { expires: 14, path: '/' });
      };
    };
  });

  // Do your other stuff here

}); // jQuery End

Hintergrund

Cookies könnten wir mit nativem Javascript setzen und evaluieren. Mit fertigen Bibliotheken geht es einfacher. WordPress bringt jQuery bereits mit. Und bootScore hat dies schon aktiviert und uns eine Möglichkeit geschaffen, eigene JavaScript-/JQuery-Funktionen in unser bootScore-Childtheme einzubauen.

Früher gab es für das Cookie-Management ein echtes jQuery-cookie Plugin. Das ist mittlerweile archiviert und in eine von jQuery unabhängige Javascript-Bibliothek js-cookie überführt worden. Um die zu nutzen, laden wir Datei js-cookie-min.js herunter und legen sie im JavaScript-Ordner unseres Child-Themes ab. Außerdem erweitern wir die Funktion bootscore_child_enqueue_styles() in unser Datei functions.php so, dass die Bibliothek js/js.cookie.min.js auch geladen wird.

Den Algorithmus zur Evaluation der Cookie-Settings implementieren wir danach in der Datei js/custom.js. Er wirkt so:

Zuerst versuchen wir den vom bs-Cookie-Plugin unter dem Namen bs_cookie_settings abgelegten Cookie zu lesen.
Wenn es ihn noch nicht gibt, hat unsere Leserin der Nutzung von Cookies noch nicht zugestimmt. Also dürfen wir noch keine schreiben.((Übrigens auch die technisch notwendigen nicht. Die dürfen wir zwar von gesetzeswegen ablegen, wir müssen unsere Leserin aber zuvor informieren, dass wir das tun. Und dass wir das getan haben, können wir wiederum anhand des Cookies bs_cookie_settings ‘belegen’. ))
Sobald unsere Leserin den Cookie-Dialog in welchem Umfang auch immer ‘bestätigt’ hat, legt das bs-Cookie-Plugin den Cookie bs_cookie_settings ab. Sein Wert enthält ein JSON-Objekt:

{  "level": 
    [   "necessary",
        "analytics",
        "advertising"
    ],
    "revision":0,
    "data":null,
    "rfc_cookie":false
}

Das müssen wir also erst parsen lassen, bevor wir — auf JavaScript-Ebene — auf die Liste der erlaubten Cookie-Gruppen via allowedCookies.level zugreifen und über die Methode includes eines Listenobjektes abfragen können, welche der Cookie-Gruppen necessary, analytics und /oder advertising uns unsere Leserin zu schreiben erlaubt hat.
Und zu jeder zugelassen Gruppen schreiben wir dann die entsprechenden Cookies.((wobei wir uns bei den technisch notwendigen Cookies auf die gesetzliche Erlaubnis berufen.))

Und ein letzter Tipp noch: JavaScript erzeugt Seiten dynamisch. Gecacht werden die Ergebnisse. Deshalb müssen wir gelengtlich den Cache löschen, um die Ergebnisse unserer Veränderungen sehen zu können.

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, zuletzt muss die Web-Designerin im Rahmen ihrer Anpassungen auch rechtliche Vorgaben beachten, seien es die der DSGVO, die für eine Cookie-Zustimmung und deren Beachtung oder die zur Erstellungen einer Datenschutzerklärung. In diesen Kontext gehören dann auch die Fragen nach dem Zweck eines Bildverzeichnisses, nach einem adäquaten Impressum oder nach einer hinreichenden Open-Source-Lizenzerfüllung. Dies ins rechte Licht zu rücken, will auch dieser Post unterstützen.

Im Übrigen: Männer sind mitgemeint.

The post Ein sauberes Cookie-Management — mit bootScore appeared first on Freigiebigkeit.

Ein sauberer Cookie-Dialog — mit bootScore

Karsten Reincke — Fri, 15 Sep 2023 11:44:35 +0000

Wir dürfen Cookies nicht einfach so auf die Festplatte einer Leserin schreiben (lassen). Denn die gehört ihr, nicht uns. Für die Cookies, die technisch notwendig sind, hat sie mit dem Abruf unserer Seite zwar konkludent ihr Einverständnis gegeben. Denn sie wollte unseren Blogbeitrag ja lesen. Die anderen Cookies dürfen wir jedoch nur dann auf ihrem Rechner speichern, wenn unsere Leserin es uns explizit erlaubt hat. Und bevor sie das tut, muss sie abfragen können, was die Cookies tun. Dazu dient uns ein sauberer Cookie-Dialog.

[ de | en ]

Den brauchen wirt nicht selbst zu entwickeln . Denn bootScore liefert uns mit seinem Plugin bsCookie einen konfigurierbaren Dialog auf der Höhe der Zeit:

Lösung

Lade bsCookie herunter.
Installiere die Zip-Datei über das Plugin-Management Deines WordPress-Backends.
Ermittle die Cookies, die Du auf dem Rechner Deiner Leserin installieren willst.((Wir müssen dabei bedenken, dass auch unsere Plugins Cookies ablegen lassen können. Es reicht also nicht, nur nach den entsprechenden JavaScript-Befehlen in unseren eigenen Posts und Pages zu suchen.))
Ordne jeden dieser Cookies der Gruppe ’necessary’((Cookies, die wir dieser Gruppe zuordnen, werden zuletzt auch ohne explizite Zustimmung auf der Festplatte unserer Leserin abgelegt, eben weil sie technisch notwendig sind. So müssen wir notfalls auch beweisen können, dass diese Cookies tatsächlich technisch notwendig sind.)), ‘advertising’ oder ‘analytics’ zu.
Ziehe im Dialog ‘Appearance/Widgets’ ein Widget ‘Customer HTML’ in die Widget-Gruppe Footer‑4
Trage dort die Scriptzeilen ein, wie sie die bsCookie-Dokumentation offeriert.
Erzeuge für jedes Deiner Plugins in der entsprechenden Sektion einen Eintrag.
Verlinke Deine Datenschutzseite in den Dialog, indem Du #yourprivacypolicy entsprechend ersetzt.
Übersetze die Texte in die Sprache Deiner Site (bzw. erzeuge einen zusätzlichen Eintrag gemäß Deiner Mehrsprachigkeitsstrategie)

Hintergrund

Das Schreiben der Cookies über einen Dialog erlauben zu lassen, ist nur die eine Seite der Medaille. Denn Cookies können auch (personen-bezogene) (Wiedererkennungs-) Daten speichern, die auf Serverseite akkumuliert und an externe Stellen weitergereicht werden. Deshalb müssen wir solche Cookies außerdem in unserem Datenschutzkonzept erwähnen. Damit unsere Leserin dies auch direkt aus dem Cookie-Zustimmugsdialog heraus ausrufen kann, bietet der bsCookie-Dialogtext einen Link, dessen Wert #yourprivacypolice wir entsprechend (um)setzen dürfen.

Es ist mittlerweile gute Tradition, Cookies funktionsbezogen zu gruppieren und für die Gruppen als solche zu fragen, ob die ihr zugeordneten Cookies lokal abgelegt werden dürfen. Rechtlich notwendig ist so ein Clustern nicht. Wir könnten unsere Leserin die Nutzung von Cookies auch ganz generell erlauben oder ablehnen lassen.((Eine stärkere Granularität liegt aber in unserem Interesse. Denn möchte eine Leserin das eine nicht — z.B. Advertising -, könnte sie das andere — z.B. Analytics — immer noch erlauben. Damit würden wir wenigstens noch einen Teil dessen erfahren, was wir insgesamt zu erfahren hofften.)) Oder wir könnten jeden einzelnen Cookie an- oder abwählbar machen — und den Dialog damit überfrachten.

Wie dem auch sei: Erstmal müssen wir natürlich wissen, welche Cookies unsere Site schreibt und was diese tatsächlich tun. Welche es sind, können wir uns über die Browser anzeigen lassen. Etwa mittels seines ‘Privacy and Security’-Dialoges. Oder mit Hilfe eines Browser-Plugins((z.B. mit dem Cookie Editor)), das direkt für jede aufgerufene Site/Seite anzeigt, welche Cookies von ihr geschrieben worden sind. Was unsere Cookies tun, müssen wir dagegen gesondert ermitteln.

Haben wir diese Cookies dann funktional sortiert, brauchen wir im bsCookie-Dialog nur noch die entsprechenden Gruppen als Sektionen anzulegen und in diese für jedes zugehörige Cookie einen Eintrag zu erzeugen. Für die drei gängigen Gruppen ’necessary’, ‘advertising’ und ‘analytics’ bringt bsCookie die nötigen Codegruppen immer schon mit. Hier reicht es mithin, die Cookies in und mit den Einzeleinträgen zu beschreiben. Gesetzt, wir wollten die drei Cookies bsNecessaryCookie, bsAdvertisingCookie, und bsAnalizingBCookie gesetzeskonform ablegen lassen, müsste der Code für den bsCookie-Dialog so aussehen:

Die Informationen in den Cookie-Zustimmungsdialogs einzubauen, ist das eine. Seinen Code zu aktivieren, das andere. Den angepassten bs-cookie-settings-JavaScript-Code tragen wir dazu in ein Custom-HTML-Element ein, das wir dem Widget Footer 4 hinzugefügt haben. Prinzipiell könnten wir das Custom-HTML-Element auch in andere Widgets einbetten. bsCookie schlägt Footer 4 vor, weil der JavaScript-Code so eher am Ende einer Seite eingebettet und damit direkt ausgeführt wird. Wie auch immer, der Cookie-Zustimmungsdialog wird dann beim Aufruf all der Seiten angezeigt, deren Templates den Footer 4 verwenden. Das Problem der ‘Deep-Links’((Es reicht nicht aus, nur unsere Einstiegsseite den Zustimmungsdialog anzeigen zu lassen. Denn gelegentlich reichen unsere Leserinnen auch Links auf tiefer eingebettete Seiten herum. Unsere Site muss auch in deisen Fällen erst um Erlaubnis bitten, bevor sie die Cookies ablegt.)) ist also gelöst, wenn jede Seite ein Template verwendet, das den entsprechenden JavaScript-Code enthält.

Blieben uns noch drei letzte Aufgaben:

Zum ersten werden wir unseren Zustimmungsdialog oft auch sprachlich anpassen wollen. Auch das geht über die ‘Umprogrammierung’ des erwähnten JavaScript-Codes.

Über das funktionalen Farbkonzept von Bootscore/bootStrap ist der Cookie-Dialog auf ‘Warning’ eingestellt. Wer ihn dennoch anders gestalten will, kann das in ihrer Datei _bscore_custom.scss so tun:

// design the bsCookie-Dialog
#c-inr {
  border-color: darkblue;
  border-width: 2px;
  border-style: solid;
  background-color: #eef;
  color: blue($color: #000000);
  padding: 5px;
}

#c-p-bn {
  border-color: darkblue;
}

#c-s-bn {
  border-color: darkblue;
}

Zum dritten müssen wir die Semantik des Cookie-Zustimmungsdialoges implementieren. Wenn wir mehr als nur reden wollen, müssen wir unseren ‘Schreibe-Cookie-JavaScript-Code’ so anlegen, dass er ohne Zustimmung nur die technischen notwendigen Cookies schreibt und dass er ansonsten nur die Cookies aus den Gruppen ablegt, für die eine Zustimmung vorliegt.

Diesen letzten Punkt werde ich in einem gesonderten Post aufgreifen …

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

The post Ein sauberer Cookie-Dialog — mit bootScore appeared first on Freigiebigkeit.

Lizenzkonformes Javascript

Karsten Reincke — Wed, 17 May 2023 07:27:52 +0000

Um die Übertragung im Netz zu beschleunigen, betten Web-Sites JavaScript-Bibliotheken üblicherweise ‘minified’ ein, in komprimierter Form also. Leerzeichen, Zeilenvorschübe und Kommentare sind daraus entfernt worden. Daher enthalten die Bibliotheken nur noch rudimentäre Lizenzinformationen — jedenfalls nicht den Lizenztext selbst. Aber alle FOSS-Lizenzen verlangen von uns, dass wir einige Compliance-Artefakte mit dem Code zusammen ausliefern — insbesondere den Lizenztext. Lizenzkonformes Javascript ist mithin eine Herausforderung für Sites — in und mit bootScore, WordPress und anderswo.

[ de | en ]

Lösung

Verwende die JavaScript-Bibliothek Bootstrap so, wie sie von bootScore bereitgestellt wird
Verwende die JavaScript-Bibliotheken so, wie sie von WordPress geliefert werden
Erstelle eine Tabelle mit den Informationen zur JavaScript-Konformität
Erstelle für jede von bootScore oder WordPress gelieferte JavaScript-Bibliothek eine entsprechende Zeile in der JS-Tabelle.
Binde diese Tabelle in Deine Open Source Compliance Page ein.
Mache die Open Source Compliance Page über den ‘Footer’ Deiner Seiten zugänglich

Hintergrund

bootSCore enthält einige JS-Komponenten. Zum Beispiel seine eigenen entfalteten JavaScript-Bibliotheken((vgl. ./bootscore/js/theme.js)) — implizit lizenziert unter der MIT, aber ohne explizites Lizenzierungsstatement — und die minifizierte Bootstrap JavaScript-Bibliothek((vgl. ./bootscore/js/lib/bootstrap.bundle.min.js)) — durch ein entsprechendes Lizenzierungsstatement explizit unter der MIT-Lizenz gestellt. Aber keine davon enthält den Lizenztext selbst. Auch WordPress bringt einige eigene und einige minimierte JavaScript-Bibliotheken von Drittanbietern mit((vgl. https://codex.wordpress.org/Javascript_Reference bzw. ./wp-includes/js)), wie z.B. die jQuery-Bibliothek¹, die ebenfalls unter der MIT lizenziert ist und ein entsprechendes Lizenzstatement enthält, aber nicht den Lizenztext. Unabhängig davon, von wem die Website-Besitzerin diese Bibliotheken erhalten hat — von bootScore oder WordPress -, ist sie es letztendlich, die die Lizenzanforderungen erfüllen muss. Denn es ist ja ihr System ist, das die JavaScript-Bibliotheken an ihre Leser weitergibt.

Aber worin besteht denn nun eigentlich die Herausforderung?

Wie die JavaScript-Bibliotheken von Bootstrap und jQuery auch, sind die meisten JS-Bibliotheken MIT lizenziert. Diese FOSS-Lizenz verlangt, dass beides — die Copyright-Zeile und der Lizenztext — zusammen mit dem Open-Source-Programm verteilt wird. “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”((cf. MIT License))

Für (L|A)GPL-lizenzierte JavaScript-Bibliotheken gilt fast dasselbe: Diese Lizenzen erlauben die Weitergabe des Quellcodes, “[…] provided that one conspicuously and appropriately publishes on each copy an appropriate copyright notice and disclaimer of warranty […] and gives any other recipients of the Program a copy of this License along with the Program”.((pars pro toto vgl. GPL‑2.0. Zusätzlich verlangt die (A)GPL, dass jeder Code, der die (A)GPL-lizenzierte Bibliothek usw. verwendet, ebenfalls unter der (A)GPL lizenziert ist (Copyleft-Effekt). Aber darum geht es in diesem Zusammenhang nicht.))

Wir haben hier also einen Widerspruch: Auf der einen Seite lädt ein Browser nicht nur den Seitentext (HTML) herunter, sondern auch die JavaScript-Bibliothek. Dieser Download verbreitet den Code und löst damit die Notwendigkeit aus, die Anforderungen der Open-Source-Lizenz zu erfüllen. Auf der anderen Seite enthalten die komprimierten Bibliotheken — selbst wenn sie als Paket von den Autorinnen angeboten werden — in der Regel nicht mehr die notwendigen Lizenzinformationen. Denn je kleiner die Bibliotheken sind, desto schneller erscheinen die Seiten auf den Rechnern der Leser angezeigt.

Der Website-Betreiberin bieten sich zwei Möglichkeiten, mit dieser Herausforderung umzugehen: Entweder sie heilt die implizit von WordPress und bootScore übernommenen Pakete nachträglich (und (halb)manuell). Oder sie verwendet sie so, wie sie sie bekommen hat. Es ist klar: Heilen würde bedeuten, dass wir diese Aufgabe jedes Mal wiederholen müssten, wenn wir WordPress oder bootScore aktualisieren. Also wäre der andere Weg weniger aufwendig. Also besser — sofern es eine Option gäbe, die Idee und die Anforderungen freier Softwarelizenzen dabei (doch) nicht zu verletzen.

Die Lösung ist dies:

Geben Entwickler ihre JavaScript-Bibliotheken als ‘minified’ Versionen weiter, gehen sie davon aus, dass ihre JS-Bibliothek auch in dieser Version verwendet wird. Daraus schließen wir, dass die Copyright-Owner diese Art der Nutzung implizit (konkludent) zulassen. Auch, wenn die Bibliotheken dabei gegen die von den Entwicklern selbst gewählte Lizenz verstößt. Trotzdem sollten wir unseren Benutzern eine andere Möglichkeit anbieten, diese Informationen zu erhalten. Wir zeigen damit, dass wir die FOSS-Idee verstanden haben und respektieren. Außerdem müssen wir darauf achten, nur die minifizierten JavaScript-Bibliotheken in unsere Site einzubinden. Also nur die Form, die die Entwicklerin selbst zur Verfügung gestellt hat. Sonst unterliefen wir ja unsere Argumentation. Im Falle der Bootstrap-JS-Lib in bootScore und der jQuery-JS-Lib etc. in WordPress dürfen wir davon ausgehen, dass sie dies getan haben.

Wir haben so im Falle eines Rechtsstreits um die Lizenzerfüllung bei JS-Bibliotheken((Ich habe noch nie von solch einem Disput gehört!)) ein starkes Argument für die Legalität unseres Vorgehens. Und wir befinden uns in sehr guter Gesellschaft: Die Sekundärliteratur diskutiert es in diesem Sinne((vgl. https://www.iusmentis.com/computerprograms/opensourcesoftware/license-notices-web-applications/)) und sogar die FSF schlägt vor, so vorzugehen.((vgl. https://www.gnu.org/licenses/javascript-labels.en.html und https://www.gnu.org/licenses/javascript-labels-rationale.html)) Und die hat nun wirklich nicht den Ruf, die Einhaltung von Lizenzen auf die leichte Schulter zu nehmen.

Und in welchem Zusammenhang …

… steht das mit einer systematischen Erfüllung von FOSS-Lizenzen? Nun, dazu müssen wir halt auch politische Konnotationen bedenken, konzeptionelle und kontextuelle Aspekte analysieren — einzeln oder gemeinsam auf Konferenzen. Wir müssen konkrete Fälle und allgemeine Nebenwirkungen durchdenken, für Software, Bilder oder Dokumente. Wir müssen Trends benennen und Leitfäden erstellen. Vornehmlich aber müssen wir die Automatisierung der Lizenzerfüllung vorantreiben, unser Lizenzwissen frei zur Verfügung stellen, es in kleinere Tools gießen und in größere Systeme einbringen: Denn FOSS lebt von der Freiheit durch Lizenzerfüllung, im Großen und im Kleinen.

Im Übrigen: Männer sind mitgemeint.

vgl. wp-includes/js/jquery/

The post Lizenzkonformes Javascript appeared first on Freigiebigkeit.

Datenschutz, DSGVO und Cookies

Karsten Reincke — Fri, 21 Apr 2023 09:17:38 +0000

Datenschutz sei komplex und müsse von Expertinnen organisiert werden, wird der WEB-Site-Betreiberin gerne bedeutet. Was aber, wenn sie das Geld dafür nicht hat? Wenn es irgendwie unsinnig erscheint, mit der Kanone eines bezahlten Expertinnenteams auf einen Spatzenblog zu schießen? Dann wird sie sich vielleicht via Google irgendein gerne genutztes WordPress-Plugin für Datenschutz und/oder Cookies organisieren — und hoffen, dass alles gut geht. Oder sie wird dem genauer nachgehen. Und sich am Ende vielleicht auch Daumenregeln für das Thema ‘Datenschutz und DSGVO’ zusammenstellen, aus und mit denen sich wenigstens ein gut gangbarer Weg ergibt. Hier meine 3.7 Faustregeln:

[ de | en ]

Lösung

I. Verwende nur die personenbezogenen Daten, die Du für das Funktionieren Deines Systems wirklich benötigst.
II. Wenn Du personenbezogene Daten erhebst, dann sage den Besitzerinnen,
- dass Du das tust,
- zu welchem Zweck Du die Daten verwendest,
- welche Rechtsgrundlage Dich dazu berechtigt,
- an wen Du die Daten weitergibst,
- wie lange Du sie bei Dir speicherst,
- wie sie bei der erfragen können, welche Daten Du über die Zeit gespeichert hast
- wie sie die Daten wieder löschen lassen können.
III. Wenn Du Daten auf dem Rechner Deiner Nutzerinnen speicherst, die sie nicht direkt oder indirekt angefordert haben (könnten), frage sie vorher um Erlaubnis.

Hintergrund

Gehe ich danach vor — so mache ich immer wieder glauben — werde ich meine Sites so gestalten, dass ich die gröbsten Fallen¹ und Fehler² vermeide. Denn eines habe ich immer im Kopf: mit einem bloßen Cookie-Banner ist es nicht getan:

Als Erstes überlege ich mir, wo mein Blog als System personenbezogene Daten erhebt. Die, die ich in und mit Formularen explizit abfrage, fallen mir am leichtesten auf und ein. Bei denen weiß ich — ‘qua Amt’ -, wofür ich sie nutze und an wen ich sie weitergebe etc.
Außerdem ist mir klar, dass auch IP-Adressen als personenbezogenen Daten gelten — obwohl das Internet ohne sie gar nicht funktionieren würde.
Zudem können WordPress, die von mir aktivierten Plugins, Javascript-Bibliotheken, Google-Fonts u.Ä.m. Daten erheben, notieren und an Dritte versenden.
Schließlich werden meine Kommentatorinnen üblicherweise über das gängige Gravatar-System wiedererkennbar gemacht.

Dieses Gemenge muss ich ordnen:

Regel (I) sagt mir, dass Weniger im Mehr ist: Je weniger Daten ich erfrage, je weniger Plugins ich verwende, desto schlanker wird mein Datenschutzkonzept. Also miste ich hier aus, z.B., in dem ich Produktiv- und Developsytsem unterschiedlich behandele.
Regel (II) sagt mir, dass ich die verbleibenden Datensets aber auch tatsächlich im Datenschutzkonzept beschreiben muss. Also ermittle ich nach bestem Wissen und Gewissen, welche Daten meine Plugins, Font-Requests und andere technische Komponenten erheben, wie sie sie speichern und wohin sie sie weitergeben.
Regel (III) sagt mir, dass ich es ich es mir erlauben lassen muss, Dateien, will sagen: Cookies auf den Rechner meiner Nutzerin schreiben zu dürfen, sei es — wie bei technisch notwendigen Cookies — gesetzlich, sei es — wie bei den anderen — per Zustimmung durch meiner Nutzerin. Und um die gewährt zu bekommen, ist es hilfreich, Zweck und Auswirkung anzugeben.

Weitere Posts beschreiben, wie ich das konkret umgesetzt habe.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

The post Datenschutz, DSGVO und Cookies appeared first on Freigiebigkeit.

Der Bitkom Open Source Leitfaden 3.0

Karsten Reincke — Mon, 11 Jul 2022 13:57:29 +0000

Über 6 Jahre war der Bitkom Open Source Leitfaden 2.0 eine Quelle für die rechtskonforme Nutzung von Open-Source-Software, ein Benchmark. Doch der ist gealtert. Gut, dass der Bitkom und sein Arbeitskreis ‘Open Source’ nun seit Juni 2022 offiziell einen thematisch erweiterten und verfeinerten Bitkom Open Source Leitfaden 3.0 herausgeben — wiederum als Richtschnur, als Benchmark und als Handbuch.

[ de | en ]

Schon erstaunlich, dass der Bitkom mit diesem Leitfaden zum ersten Mal eine ‘Handreichung’ unter einer Open-Source-Lizenz veröffentlicht hat. Die Wahl fiel auf die Creative Commons Lizenz (CC BY-ND 3.0 DE). Offensichtlich rückt die Idee einer ‘Allmende’ und der Gedanke eines frei zugänglichen Services auch beim Bitkom in den Vordergrund. Das verleiht seiner Stimme noch mehr Gewicht. Dass er eine Bearbeitung durch Dritte dabei nicht zulässt (ND = Non Derivation), ist verständlich. Immerhin soll die Qualität und Verlässlichkeit bewahrt bleiben. Aber jede andere Art der Verwendung durch Dritte ist ausdrücklich erlaubt, ja erwünscht, auch die kommerzielle. So wird sich der Bitkom zukünftig gewiss dazu durchringen, auch die Quellen allgemein zugänglich zu machen. Anstatt ’nur’ in einer ‘geschlossenen’ GitHub-Organisation.

Außerdem hat der Bitkom hat seinen Autoren dabei gestattet, sich über und mit GitHub zu organisieren. Jeder konnte mitmachen. Jeder konnte Mitglied der Organisation werden und damit auf das GitHub-Repository mit den (Teil)Ergebnissen zugreifen. So hat der Bitkom — wiederum erstmals und erfolgreich — ein Buch mit den Mitteln der Open-Source-Softwareentwicklung erarbeitet. Die Kapitel des Bitkom-Open-Source-Leitfadens wurden in Markdown geschrieben, als Snippets ins Repository eingecheckt und mit Incidents und Pullrequests zu einem Ganzen geformt. Und das, obwohl mitnichten alle Autoren von Anfang an mit GitHub vertraut waren. Auch das weist über sich hinaus: Git, GitHub oder GitLab können die (firmenübergreifende) Kooperation und Kollaboration deutlich vereinfachen.

Und das dritte Erstaunliche ist die Wandlung des Inhalts. War der Leitfaden 2.0 noch auf die nutzungsrechtlichen Aspekte fokussiert, ist der neue Bitkom Open Source Leitfaden 3.0 deutlich breiter und ausgewogener aufgestellt: Er behandelt den Nutzen von FOSS ebenso, wie deren Programmierung. Er beleuchtet gleichermaßen die Einbindung in Geschäftsmodelle und Firmenstrategien, die Open-Source-Compliance und die FOSS-Geschichte — auf jeweils nahezu gleich vielen Seiten. Hier ist das FOSS-Umfeld nicht mehr nur Anhängsel zur Compliance, sondern es werden die Bedingungen zur erfolgreichen Nutzung von Open-Source-Software ausgeglichen in den Blick genommen, ohne dass der Abschnitt zur Lizenzkonformität verliert. Und jeder Abschnitt hat mit seinen 10–20 Seiten einen Umfang, der es erlaubt, sich auch auf die Schnelle zu orientieren.

Damit ist der Bitkom-Opensource-Leitaden‑3.0 zu einer Informationsquelle geworden, die man auch firmenintern gut einfach mal so als erste Orientierung weitergeben kann.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

The post Der Bitkom Open Source Leitfaden 3.0 appeared first on Freigiebigkeit.

CC-BY Bildertrolle

Karsten Reincke — Sat, 26 Feb 2022 14:31:53 +0000

Präsentationen ohne Bilder nerven. Darum bedienen wir uns so gern aus dem Internet mit seinen vielen schönen Fotos. Nur ist es eben nicht einfach, fremde Bilder legal in die eigene Präsentation einzufügen. Und auf die Verletzung solcher Pflichten bei freien Bildern zielt ein neuer Typ von Troll, der Bildertroll.

[ de | en ]

Wenn wir Bilder aus dem Internet nutzen, müssen wir die Urheberrechte der Malerinnen und Fotografinnen beachten. Genau, wie wir sonst Lizenzgebühren an die Patentinhaberinnen zahlen müssen, deren Erfindungen wir nutzen. Oder wie wir die in den Lizenzen genannten Bedingungen tatsächlich umsetzen müssen, wenn wir Open-Source-Software nutzen. Nun ist — nach den Patent- und Open-Source-Trollen — jüngst einer neuer Typ entstanden, der ‘copyleft-’ oder ‘Bildertroll’.[1] Es ist gut zu wissen, wie solche Trolls arbeiten und wie wir uns vor ihnen schützen können.

Oft werden freie Bilder unter einer Creative-Commons-Lizenz veröffentlicht. Diese ähneln den Open-Source-Lizenzen: Beide folgen dem Prinzip ‘Paying by Doing’. Anstatt Geld dafür zu bezahlen, die Nutzungsrechte zu bekommen, muss frau hier bestimmte Dinge tun. Welche Rechte sie bekommt und was genau sie dafür tun muss, hängt von der jeweiligen Lizenz ab. Im Creative Commons Bereich gibt es ein recht komplexes System verschiedener Lizenzen[2]. Aber nahezu jede davon hat eine ‘BY’-Klausel, die festlegt, dass die Nutzerin den Namen der Malerin oder Fotografin und die Lizenz angeben und einen Downloadlink zum Photo und zum Lizenztext mitliefern muss.[3]

Diese BY-Bedingungen seien — wie der Entdecker der Bildertrolle sagt — ein “set of administrative requirements that are easy to get wrong”.[4] Und genau das ist die erste Zutat, die ein gewinnbringender Troll benötigt: je leichter es ist, solche Bedingungen zu verfehlen, desto größer die Zahl potentieller Opfer.

Die zweite Zutat besteht darin, dass frühere Versionen der CC-Lizenzgebühren — wie etwa die CC-BY 2.0- oder die CC-BY 3.0-Lizenz — eine “Termination”-Klausel enthalten: “This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License.”[5] Das besagt, dass Du in dem Moment die Nutzungsrechte verlierst, wo Du eine der gestellten Bedingungen unzureichend erfüllst.

Man kann die Brisanz dieser Klausel schon daran erkennen, dass die CC-BY 4.0-Lizenz zwar auch eine solche “Termination”-Klausel enthält, dass sie aber zusätzlich die Möglichkeit eröffnet, Lizenzverletzungen innerhalb eines bestimmten Zeitraums auszubessern: Diese Lizenz sagt nämlich, dass die abgesprochenen Rechte “[…] reinstates automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation […]”.[6]

Als dritte Zutat für sein legales, aber unangenehmes Geschäft benötigt der ‘Bildertroll’ eine Methode, im großen Stil die Nutzerinnen seiner Bilder zu finden und deren missglückte Kennzeichnungen zu analysieren. Die automatisierte Bildersuche im Internet ist eine solche mittlerweile gut etablierte Technik.

Und als vierte Zutat benötigt der Bildertroll einen Rechtsraum, der ihm große Ausgleichszahlungen für die Verletzung von Nutzungsrechten garantiert — was wenigstens in den USA gang und gäbe ist.

Wie also nutzt ein Bildertroll diese Zutaten? Er muss eigentlich nur hübsche Bilder fotografieren und sie in einer gern genutzten Bilddatenbank unter einer CC-Lizenz mit ‘Termination’-Klausel veröffentlichen. Damit ist der “honeypot” angerichtet. Denn nun braucht der Bildertroll nur noch im Netz nach seinen eigenen Bildern zu crawlen und dort, wo er sie findet, zu analysieren, ob die Nutzerinnen die Nutzungsbedingung richtig erfüllt haben. Wenn nicht, kann er ein juristisches Verfahren gegen sie eröffnen. Und zumindest in den USA sprechen wir hier von einem gesetzlichen Schadenersatz (“statutory damages”) bis zu $150.000,–.[7]

Was können wir also tun, um uns vor Angriffen schützen, die zwar legal sind, aber irgendwie auch dem Geist freier Kultur und freier Software entgegenstehen?

Der beste Weg zum gelungenen Selbstschutz ist zu wissen, unter welcher Lizenz ein Bild veröffentlicht ist, was sie als Gegenleistung erwartet, und diese Bedingungen dann gewissenhaft zu erfüllen.
Eine gute Strategie ist auch, sich auf CC0 lizenzierte Bilder[8] zu fokussieren, wie sie etwa unter pxhere.com[9] angeboten werden. Denn eine Lizenz, die expressis verbis nichts fordert, kann auch nicht dazu missbraucht werden, Dich juristisch zu bedrängen.
Eine etwas schwächere Absicherung bietet der Weg, vorrangig CC-BY-xyz 4.0 lizenzierte Bilder weiter zu verwerten.[A] Zwar muss frau die Bedingungen auch hier gründlich und vollständig erfüllen, aber sie hat doch wenigstens die Möglichkeit, nachzubessern, bevor sie in einen Rechtsstreit verwickelt wird.
Und wenn frau doch CC-BY-xyz 3.0 oder früher lizenzierte Bilder verwerten will — und es gibt viele gute so veröffentlichte Bilder -, dann muss sie die Forderungen der Lizenz selbst lesen und erfüllen, nicht nur die kondensierte Zusammenfassung, die die Creative Commons Organisation anbietet.

Bildurheberrechte jedoch komplett zu ignorieren und etwas aus dem Internet einfach so zu abzugreifen, ist der sicherste Weg, in einen Rechtsstreit verwickelt zu werden — genauso wie die Verwendung von Open-Source-Software ohne Erfüllung der Lizenzanforderungen oder die Verwendung patentierter Techniken ohne Zahlung der Lizenzgebühren.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

[1], [4], [7]: cf. https://doctorow.medium.com/a‑bug-in-early-creative-commons-licenses-has-enabled-a-new-breed-of-superpredator-5f6360713299. This article reports on aspects that Cory Doctorow has outlined first. He talks about ‘copyleft trolls’ probably for indicating, that other than pictures can be used to establish such an attack. But I think that using pictures inadequately is the most danger.
[2]: cf. https://creativecommons.org/about/cclicenses/
[3]: cf. https://creativecommons.org/licenses/by/4.0/legalcode, Section 3 Attribution. It is worth to know the CC organization provide summaries that condense these conditions to the one sentence ‘Credit must be given to the creator’ (cf. https://creativecommons.org/licenses/by/3.0/). Hence, you are not free to acknowledge the author just as you want.
[5]: cf. https://creativecommons.org/licenses/by/2.0/legalcode or https://creativecommons.org/licenses/by/3.0/legalcode
[6]: cf. https://creativecommons.org/licenses/by/4.0/legalcode
[8]: cf. https://creativecommons.org/publicdomain/zero/1.0/
[9]: cf. https://pxhere.com/en/license
[A]: cf. https://creativecommons.org/licenses/by/4.0

The post CC-BY Bildertrolle appeared first on Freigiebigkeit.

TDOSCA & OSCake: FOSS Compliance automatisieren

Karsten Reincke — Sat, 28 Nov 2020 10:14:48 +0000

Mit dem Open Source License Compendium und dem Open Source Compliance Advisor hat die Deutsche Telekom das Thema ‘Open-Source-Compliance’ bereits vorangebracht. Am BOSL‑3.0 durfte ich in ihrem Namen mitschreiben. Allerdings bietet die DT mittlerweile so viele komplexe Produkte mit Open-Source-Anteil an, dass es zu teuer wird, die notwendigen Compliance-Artefakte manuell zu erzeugen. Notwendig ist eine praktisch nutzbare automatisierte ‘Toolchain’. Dieser Artikel disuktiert eine neue Methodik (TDOSCA) und einen neues Tool (OSCake), die die DT unter dem Dach des Open Chain Projekts öffentlich umsetzt.

[ de | en ]

3 einfache Fragen an Open Source Compliance Tools

Es gibt ohne Zweifel bereits eine Reihe von Open-Source-Compliance tools. Die Open-Chain-Reference-Tooling-Work-Group hat eine entsprechende Liste zusammengestellt. Die kann noch weiter gruppiert werden:

Einige der Tools werden von Organisationen wie die Apache-Foundation, SPDX, Eclipse der der About-Code-Initiative angeboten.
Andere stehen insofern etwas abseits, als sie einen speziellen Fokus haben oder gar keine richtige Tools sind.
Und wieder andere bilden eine Gruppe, weil sie eher Services sind, als Tools.

Die Deutsche Telekom hat dabei einen recht einfachen Blickwinkel. Wann immer ihr ein FOSS-Compliance-Tool begegnet, fragt sie deren Entwicklerinnen und Vertreterinnen:

Liefert dieses Tool der Firma die FOSS-Compliance-Artefakte, die sie wirklich benötigt? Und wenn nicht,
- Welchen Teil davon könnte es ihr liefern?
- Wieviel Handarbeit fällt dann noch auf Seiten der Telekom an?

Die Deutsche Telekom hat viel Erfahrung darin, angebotene FOSS-Compliance-Tools zu sichten. Ihren Mitarbeiterinnen sind exzellente Tools und brilliante Expertinnen begegnet, die oft völlig davon überzeugt waren, dass sie der Firma umfassend helfen könnten. Am Ende der Gespräche fühlte es sich aber oft so an, dass die Anbieterinnen nicht wirklich verstanden hatten, was die DT benötigte (und noch immer benötigt). Um den Punkt zu verdeutlichen: Wer lange Listen gefundener FOSS-Komponenten anbietet und dann sagt, dass die Firma nun jeden Eintrag mit ihren Juristinnen durchgehen müsse, hilft ihr nicht wirklich.

Und dennoch, auch die Deutsche Telekom AG muss mit solchen langen Listen umgehen. Die Open Source Compliance ist keine Frage der Lust oder Unlust: Entweder wir nutzen die Open-Source-Komponenten und erfüllen die Lizenzbedingungen, oder wir nutzen die Komponenten nicht. Deshalb kann Telekom auch nicht länger warten. Die Komplexität ihrer Produkte zwingt sie, die Automation von Open-Source-Compliance selbst voranzutreiben. Allerdings wird sie dazu nicht den nächsten Greenfield-Ansatz verfolgen, sondern sich im Geiste von Open-Source-Entwicklungen in bestehende Projekte einbringen.

Eine Test-Driven Entwicklung von Tools zur Erzeugung von Open Source Compliance Artefakten

DTs erster Schritt zielte auf die Verbesserung ihrer eigenen Kommunikation. Sie wollte — ausgehend vom Standpunkt einer großen Firma mit vielen komplexen Softwarestacks — einfacher klarstellen, was sie wirklich benötigt und von Tools erwartet. Zu diesem Zweck hat die Telekom den Ansatz einer ‘Test Driven Software Entwicklung’ auf die Programmierung der Compliance-Tools übertragen:

Einerseits sollen die Testcases wirklich nutzbare Software enthalten, und zwar zusammen mit den Angaben über Lizensierungen und Abhängigkeiten und eingebettet in Paketmanager, wie sie auch in ‘richtigen’ Open-Source-Projekten verwendet werden.
Andererseits sollen diese Testcases als Refeenzdaten auch schon alle Compliance-Artefakte enthalten, die es — wären sie dem Softwarepaket beigelegt — erlauben würden, die paketierte Software lizenzkonform zu verteilen.

Außerdem meint die DT,

dass existierende Open-Source-Projekte in der Regel zu komplex seien, um um sie zu Testcases zu machen.
dass ‘künstlich’ erzeugte Software sich besser auf einzelnen Compliance-Aspekte fokussieren lasse.
dass die Referenz-Software auf der einen Seite funktional einfache Hello- World Programme sein sollten,
die auf der anderen Seite auch solche ausgefeilten Compliance-Fallen enthalten müsse, wie frau sie in richtigen Open-Source-Projekten findet..

Anhand solcher Test-Cases sollten die Community, die Tools und beteiligte Firmen verifizieren und kommunizieren können,

welche Compliance-Fallen ein Tool schon erfolgreich bewältigt,
welche Artefakte ein Tool schon liefert (und welche nicht),
wo es noch offenen Herausforderungen gibt
und wo abweichend Ergebnisse nur eine Frage der Interpretation sind.

Die ‘Hello World’ Open-Source-Compliance-Testcases

Alle TDOSCA-Testcases werden unter dem Dach der GitHub-Organization Open-Source-Compliance gehostet und anhand des Prefixes tdosca gruppiert. Die README-Datei des Hauptrepositories tdosca beschreibt die allgemeine Systematik: Frau darf erwarten, dass jeder Testcase dieselbe Struktur mitbringt. Die kann gut anhand des Testcases tdosca-tc06-plainhw erläutert werden:

Auf der obersten Ebene beschreibt eine spezifische README-Datei die Intentionen des Testcases.
Im Ordner input-sources befindet sich die Software
- samt der Lizenz und Lizensierungsinformation, die analog zu ‘echten’ Projekten arrangiert sind
- in einer Form, dass sie mit den Standardtechniken kompiliert und installiert werden könnte (hier also mit java + maven).
Auf der obersten Ebene beschreibt außerdem eine ‘Compliance-Trap Datei’ die Herausforderungen, die in und mit diesem Testcases implementiert worden sind und mit denen ein Tool umgehen sollte.
In dem Ordner reference-compliance-artifacts befinden sich dann die Compliance-Artifakte, die ein Tool idealerweise liefern sollte:
- eine BOM-Datei, die die enthaltenen Komponenten auflistet
- eine Liste der Pakete, die auf dem Zielsystem vorinstalliert sein müssen
- die eine Open-Source-Compliance-Datei, die — sofern frau sie dem Paket als Ganzes hinzufügt — daraus ein lizenzkonform distribuierbares Softwarepaket macht.

Die einzelnen Testcases sind in den speziellen Repositories tdosca-tc01 … tdosca-tc0n abgelegt.

Zentrales Element der Referenzartefakte ist die Datei Open Source Compliance File: Zu ihrem Format hat sich die Deutsche Telekom von einer Datei inspieren lassen, die Cisco OSCF dem Jabber-Client beilegt: https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/ docs/CiscoJabberforWindows-128–1578365187.pdf. Diese Datei ist nicht perfekt. Aber zeigt gut, wie frau mit dem Thema umgehen könnte. Im Rahmen von TDOSCA bietet die OSCF-Datei des 6. Testcases einen guten Einblick.

Ein Zwischenfazit und ein Zusatz:

Im allgemeinen nutzen die TDOSCA-Testcases also die folgende Struktur:

Die TDOSCA-Intiative — gehosted unter dem Schutz des Open-Chain-Projektes der Linux-Foundation und betreut unter dem Dach der OpenChain Reference Tooling Work Group — sollte der Community eine gute Möglichkeit bieten, ihre Arbeit systematisch zu evaluieren.

Trotzdem bliebe eine ‘Geschmäckle’, wenn die Deutsche Telekom nur diesem Ansatz folgte. Sie würde leicht in die Rolle einer Polizistin oder Richterin rutschen. Das ist nicht das, was die Telekom sein möchte. Sie möchte Community auch praktisch voranbringen. Darum hat sie bereits existierende Tools anhand von TDOSCA-Testcases evaluiert, hat Erfahrungen gemacht und Konsequenzen gezogen:

TDOSCA und ORT …

Als erstes hat sich die DT dem Open Source Review Toolkit zugewendet, um eine Durchstichsversion zu erzeugen, die den Testcase-Input nimmt und automatisiert die Compliance-Dateien erzeugt:

Hier die

die 5 Komponenten, die ORT in seinem README als seine Bestandteile erähnt,
die Art der Datenj, die sie generieren und
die Weise, wie sie den Inhalt ihrer Vorgänger weiterverarbeiten.

Ausgehend von dieser Skizze kann frau nun erläutern, …

… welche Erfahrung mit ORT

aufgelaufen sind:

Zunächst musste die DT akzeptieren, dass der ORT den ersten und einfachsten Test-Case nicht hat verwerten können, weil der ‘Paketmanager’ GNU autotools noch nicht in das ORT integriert war.
Dann musste die DT lernen, dass ORT bei der Auswertung der Daten des Paketmanagers gradle, ORT — momentan- noch nicht entscheiden kann, welches die Default-Lizenz ist.
Und schließlich musste die DT konstatieren, das die im ORT-Reader eingebauten Standard-Templates dem Prinzip der Übererfüllung der Lizenzbedingungen folgen.

Was heißt das? Gibt frau ein komplett unter der MIT lizenzisiertes Paket weiter, muss sie nur diesen einen Lizenztext einschließlich des einen mit ihr verbundenen Copyrightstatements beilegen, um es lizenzkonform zu distribuieren. Tools, die dem Prinzip der Überfüllung folgen, fügen dem aber z.B. auch noch die Copyrightlines hinzu, die sie mit der GPL orientierten Suchtechnik in den Quellen gefunden haben.

Das ist ein vielfach verwendeter Ansatz. Dem Prinzip der Lizenz-Überfüllung zu folgen, ist jedoch eine problematische Strategie:

Zum einen werden Fehler, die in den beigelegten Compliance-Artefakten gemacht werden, den Distributoren auch dann zugerechnet, wenn diese Teile gar nicht hätten mitgeliefert werden müssen.
Zum anderen können die zusätzlich mitgelieferten Compliance-Artefakte diejenigen überschreiben oder aushebeln, die der Lizenz nach mitgeliefert werden müssen.

Glücklicherweise ist ORT modular aufgebaut und macht ihre Bestandteile konfigurierbar, was der DT erlaubt, das Tool entsprechend anzupassen:

Konsequenz 1: das ORT erweitern

Die Deutsche Telekom plant eine Evaluierung der GNU autotools zu implementieren und an das ORT Team zurückzugeben.
Außerdem wird sie eine Heuristik entwickeln und upstream geben, die immer die Defaultlizenz ausweist.

Konsequenz 2: die Testcases komplettieren

Die DT wird ferner zusätzliche Testcase implementieren, sodass der multi-dimensionale Raum aus Complexity x Programmiersprache x Paketmanager besser abgedeckt wird..

Konsequenz 3: eine intelligente Open Source Compliance artifact knowledge engine entwickeln

Die Deutsche Telekom AG wird schließlich eine intelligente Komponente entwickeln, in die das Wissen um Open Source Lizenzbedingungen deklarativ eingebettet ist, so dass sie es automatisiert anwenden kann. Dazu wird sie
- ihren eigenen ‘Writer’ ins ORT einbetten
- mittels Eclipse und XText eine Domainen-spezischen Sprache in Sachen Open-Source-Lizenzen entwickeln
- und mittels Eclipse und XTend eine entsprechenden Artifact-Composer implementieren

Diese neue Komponente, die auch für anderen Open Source Compliance Chains nutzbar sein soll, wird OSCake genannt und unter der Eclipse Public License 2.0 entwickelt. Die Abkürzung steht für Open Source Compliance artifact knowledge engine.

OSCake soll die Lücke schließend, die Open Source Scanner haben, die nach dem Prinzip der Lizenzüberfüllung arbeiten. Es wird Open-Source-Compliance-Collections nehmen und Open-Source-Compliance-Files liefern, die die Forderungen der Lizenzen genau erfüllen. OSCake wird eine agnostische Wissensmaschine werden, und nicht von einem spezifischen Scanning-Tool abhängen, sondern nur von einem fehlertoleranten Inputformat. Um das zu erreichen, wird OSCake mit einer bipolaren inneren Struktur arbeiten:

Fazit

TDOSCA und OSCake sind interessante Arbeitsziele, für die Deutsche Telekom AG selbst, für die Community und für andere kommerzielle Ansätze:

DT will in der Tat eine praktisch verwendbare FOSS-Compliance-Tool-Chain aufsetzen, die automatisiert passende Compliance-Artefakte ableitet.
DT will den manuellen Aufwand so weit als möglich reduzieren.
Und DT wird seine Komponenten unter der Kontrolle TDOSCA verwirklichen: der Initiative zur Entwicklung von Test Driven Open Source Compliance Artifact Gatherers und Compilers

Und es ist ein besonders guter Aspekt dieser Arbeit, dass sie öffentlich passiert, unter dem Dach von Open-Chain und dessen Open Chain ReferenceTooling Workgroup.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

OSLiC sources: https://github.com/telekom/oslic
OSLiC homepage: http://telekom.github.io/oslic/
OSLiC version 1.0.2: https://telekom.github.io/oslic/releases/oslic.pdf
OSCAd sources: https://github.com/telekom/oscad
OSCAd homepage: https://telekom.github.io/oscad/
OSCAd instance: http://oscad.fodina.de/
OpenChain homepage: https://www.openchainproject.org/
Respective Linux Foundation project page: https://www.linuxfoundation.org/projects/security-compliance/
Introduction into the Open Chain Reference Tooling Work Group: https://www.openchainproject.org/news/2020/03/15/openchain-reference-tooling-work-group-in-2020
Open Chain Reference Tooling Work Group homepage: http://oss-compliance-tooling.org/
Existing Open Source license compliance tools: http://oss-compliance-tooling.org/Tooling-Landscape/OSS-Based-License-Compliance-Tools/
Open-source Review Toolkit: https://github.com/oss-review-toolkit/ort
Test Driven Open Source Compliance Initiative: https://github.com/Open-Source-Compliance/tdosca
Open Source Compliance artifact knowledge engine: https://github.com/Open-Source-Compliance/OSCake
Open Compliance Summit 2020: https://events.linuxfoundation.org/open-compliance-summit/program/schedule/

The post TDOSCA & OSCake: FOSS Compliance automatisieren appeared first on Freigiebigkeit.

GPL lizenzierte LilyPond-Snippets — und ihre Nebenwirkungen

Karsten Reincke — Tue, 29 Oct 2019 19:32:43 +0000

Dieser Artikel geht ungewollten Seiteneffekten nach: Er beschreibt, warum es suboptimal ist, GPL lizenzierte LilyPond-Snippets zu distribuieren, selbst wenn man — wie ich es tue — gerne Freie- und Open-Source-Software erstellt, verteilt und verwendet. Der Seiteneffekt ist überraschenderweise der Copyleft-Effekt der GPL:

[ de | en ]

Beginnen wir mit einigen hoffentlich unbestrittenen Punkten: Das Programm ‘LilyPond’ ist unter der GPLv3 lizenziert [⇒ 1]. Es will “schöne Noten erstellen” [⇒ 2]. Zu diesem Zweck nimmt es eine Datei, die die darzustellenden Noten beschreibt, und zwar in einer LilyPond spezifischen Beschreibungssprache. Und es erzeugt daraus den eigentlichen Notentext — als PDF, PNG etc:

LilyPond is a compiled system: it is run on a text file describing the music. The resulting output is viewed on-screen or printed. In some ways, LilyPond is more similar to a programming language than graphical score editing software. [⇒ 3]

Die LilyPond-Beschreibungssprache ist also eine Programmiersprache (ausgeführt und interpretiert vom Programm LilyPond). Das Schreiben von Musik für LilyPond ist Programmierung. LilyPond ist ein Programmiersystem wie PHP‑, PYTHON- oder BASH: Der Interpreter (die PHP‑, Python‑, Bash- oder eben die LilyPond-Engine) nimmt ihren Eingabecode und erzeugt daraus eine neue Ausgabe. Solche (Open Source-basierten) Engines werden häufig unter anderen Lizenzen freigegeben als der Programmiercode, den sie ausführen. Beispielsweise ist PHP unter der PHP-Lizenz lizenziert, es gibt jedoch viele PHP-Programme, die unter der MIT‑, der BSD- oder sogar der LGPL-Lizenz lizenziert sind.

Dass dem auch bei LilyPond so ist, zeigt das LilyPond-Repository [⇒ 4]:

Es enthält die Datei COPYING, die eine Kopie der GPLv3 ist.
Es enthält eine Datei mit dem Namen LICENSE, die besagt, dass LilyPond unter der GPLv3 lizenziert sei.
Es enthält eine Datei mit dem Namen LICENSE.Documentation, aus der hervorgeht, dass alle Dokumenteingaben unter die GNU Free Documentation License fallen, allerdings mit Ausnahme der Dateien im Verzeichnis ’snippets’, diese seien ‘Public Domain’.

Daraus können wir Folgendes ableiten:

LilyPond selbst ist unter den Bedingungen der GPL lizenziert: Sie dürfen es ausführen, untersuchen, modifizieren und weitergeben. Wenn Sie jedoch eine (geänderte) Instanz weitergeben, müssen Sie ihrem ‘Paket’ den Lizenztext, eine Liste der Urheberrechtsinhaber, den Quellcode und einige andere Compliance Artefakte hinzufügen.
Die GPLv2/v3 sagt nirgendwo, dass die Eingabedateien (in unserem Fall: die LilyPond encodierten Noten) oder die Ausgabedateien (in unserem Fall: pdf, png, …) ebenfalls unter den Bedingungen der GPLv3 verteilt werden müssen.
Außerdem verlangen die LilyPond-Urheberrechtsinhaber an keiner Stelle, dass die Eingabe- und Ausgabedateien auch unter der GPL freizugeben sind (was sie — dem Vorbild einiger Codegeneratoren folgend — hätten tun könnten).
Darüber hinaus wissen und akzeptieren die Urheberrechtsinhaber von LilyPond nachweisbar, dass die LilyPond-Eingabedateien nicht automatisch durch den “Starken Copyleft Effekt” der GPL erfasst werden. Andernfalls hätten sie keine Snippets in ihr Repository einbetten und zugleich sagen sagen können, dass diese Public Domain seien.

So können wir allgemein folgern, dass die LilyPond-Eingabe- und Ausgabedateien aus der Sicht von LilyPond und seinen Entwicklern anders lizensiert werden dürfen, als LilyPond selbst.

Welche Lizenz sollte man also für seine LilyPond-Schnipsel wählen? Es gibt zwei Vorbilder:

In einem LilyPond Snippets Repository werden bereits wiederverwendbare Snippets gehostet. Laut LSR fallen all diese Snippets in die ‘Public Domain’ [⇒ 5]
Angeboten wird ferner eine ‘Open LilyPond Library’. [⇒ 6] Deren Homepage ist größtenteils ein Website-Skelett. Es heißt dort nur, “openLilyLib” sei eine Erweiterungsbibliothek für die Musiknotationssoftware GNU LilyPond. [⇒ 7] Unter der Github Organisation “openlilylib” findet man dann das zentrale Repository “oll-core”, das sich als “the heart of openLilyLib” vorstellt und allgemeine Funktionen anbietet, die jedes “openLilyLib”-Paket verwenden müsse. [⇒ 8]

Obwohl dieses openLilyLib Repository keine Datei mit dem Namen COPYING (mit dem Text der GPL als Inhalt) und auch keine Datei LICENSE oder LICENSING enthält, sagt der Header der zentralen Quellcodedatei package.ily klar, dass “openLilyLib’ freie Software sei und unter den Bedingungen der GNU General Public License weitergegeben und / oder modifiziert werden könne [⇒ 9]. Dies drückt den Willen der Entwickler und der Copyright Owner aus, der von allen Benutzern der openLilyLib respektiert werden muss.

Leider hat das Model, GPLv3 lizensierte LilyPond-Schnipsel anzubieten, hat einige sehr unattraktive und schmerzhafte Folgen:

Wir wissen bereits, dass der LilyPond-Code selbst Software ist. Solche Schnipsel werden mit dem Befehl include "ABC.ly" in den Hauptcode eingebunden. Oder sie werden in den eigenen LilyPond-Musikcode hineinkopiert. Beides triggert den Starken Copyleft-Effekt der GPL [⇒ A, §5]: Wenn ich einen Teil des GPL-lizenzierten Codes mittels eines Funktionsaufrufes von meinem Code aus verwende (anstatt diesen Code selbst zu schreiben) oder wenn meine Datei den Fremdcode gar selbst enthält, dann hängt meine Arbeit von dieser GPL-lizenzierten Vorarbeit ab und ich muss meinen Code auch unter den Bedingungen der GPL verbreiten, unabhängig davon, ob ich meine Arbeit als Quellcode [⇒ A, §5] oder in Form von kompilierten Ergebnissen [⇒ A, §6] verbreite.

Jetzt kann man die unangenehmen Konsequenzen geradezu riechen. Wenn ich meine Musiknoten mit der LilyPond-Sprache beschreibe und dabei ein GPL-lizenziertes Snippet verwende, muss ich meine Musiknoten auch unter den Bedingungen der GPL verbreiten, und zwar unabhängig davon, ob ich sie als Bilder / PDFs oder LilyPond-Code weitergebe. Durch die Verteilung unter der GPL gewähre ich dann konsequenterweise jedem, der meine Ergebnisse bekommt, das Recht, sie zu verwenden, zu studieren, zu modifizieren und neu zu verteilen. Und was bedeutet es, Musiknoten zu verwenden? Natürlich! Es bedeutet insbesondere auch, die Musik zu spielen.

Wenn Sie also ein GPL-lizenziertes LilyPond-Snippet zum Erstellen Ihrer eigenen LilyPond-Musikdatei verwenden — sei es als ‘inkludierte’ Datei, sei per Copy&Past -, haben all diejenigen, die Ihre Noten erhalten — egal, in welcher Form -, das Recht, Ihre Musik zu spielen (oder sonst wie zu verwenden) — ohne weitere Nachfrage und zu jedem Zweck.

Um es klar zusagen: Natürlich hat jeder Autor das Recht, seine Arbeit unter eine beliebige Lizenz zu stellen. Und die Benutzer seiner Arbeit müssen die Anforderungen der gewählten Lizenz erfüllen. Das ist unstrittig und der Kern der ganzen Free Software World. Kein Zweifel.

Die Frage ist allerdings, was dann diejenigen tun können, die ihre Nutzer nicht solch radikale Konsequenzen aufbürden wollen?

Sie könnten ihre Snippets / Libs zum ersten unter den Bedingungen der LGPL verbreiten. [⇒ B] Aufgrund des Schwachen Copyleft-Effekts der LGPL [⇒ B, §2/§4] dürfen die Benutzer dann ihren eigenen Code / ihre eigene Musik unter den ihnen gemäßen Bedingungen verbreiten.

Das hat aber auch einen — wahrscheinlich unerwünschten — Nebeneffekt: Wenn ich ein Musikstück auf Basis eines LGPL-lizenzierten Snippets geschrieben habe, muss ich — auch wenn ich meinen Notentext nur als Bild oder PDF verteile- zusätzlich auch den Code, den Lizenztext selbst, eine Liste der Urheberrechtsinhaber [⇒ B, §4] und einige andere Compliance-Artefakte verteilen — und zwar zusammen mit meinem Notentext . Eine einfache Verteilung meiner Arbeit ohne diese Compliance-Artefakte wäre schlicht ein Lizenzverstoß. Egal wie sinnig oder unsinnig man den Mehraufwand einschätzte!

Alternativ könnten Sie in dem Dokument, mit dem Sie Ihr Snippet lizensieren, ausdrücklich darauf hinweisen, dass die Verbreitung der Musik in Form von Bildern / PDFs NICHT die Anforderungen der LGPL entsprechen müsse (also den Copyleft-Effekt nicht triggere).

Die Lizenz durch Exzeptions ‘aufzuweichen’, ist mittlerweile üblich. Es ist jedoch immer besser, eine sprachlich passende Lizenz zu verwenden, als hinzuzufügen, dass der Lizenztext in gewisser Hinsicht nicht meine, wie er besage.

Ferner könnten Sie den LilyPond-Code unter jeder anderen zulässigen Open Source-Lizenz verteilen.

Aber auch diese Lizenzen zwingen uns, Compliance-Artefakte zusammen mit unserer Musik zu verbreiten (im Falle der Apache‑2.0‑Lizenz zum Beispiel wäre das z.B. der Lizenztext selbst und die NOTICE-Datei des Pakets [⇒ C §4].

Schließlich könnten Sie die Snippets unter den Bedingungen einer der Creative Commons-Lizenzen verbreiten. [⇒ D]

Je nach Wahl der Attribute würden Sie selbst festlegen, wie die Nutzer Ihnen Respekt zollen sollten (BY), welche Rechte er übernehmen muss (SA) oder ob er womöglich gar nichts tun muss (CC0).

Schließlich könnten Sie Ihre Snippets zu ‘Public Domain Software erklären’.

Dann gäben Sie aber Ihre Urheberrechte vollständig auf. Ihre Arbeit dürfte formal nicht einmal mehr auf Sie als Copyrightowner bzw. Autor verweisen. Diesen Weg wählt der LSR [⇒ 5]. Leider taugt dieses Verfahren nur im anglo-amerikanischen Rechtsraum, im europäischen gibt es keine “public domain”.

Was also sollen wir als Autoren tun, die wir mit unseren Snippets anderen die Arbeit mit LilyPond erleichtern wollen? Es gibt drei Wege:

Ich denke, der beste Weg besteht darin, diese Snippets unter den Bedingungen der MIT-Lizenz zu verbreiten. Diese permissive Lizenz ist so klein, dass sie zusammen mit der Copyright-Zeile buchstäblich in den Quellcode integriert werden kann, sodass er literal bereits alle Compliance-Artefakte enthält: “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” [⇒ E]
Die zweite fast gleichwertige Methode bestünde darin, die Snippets unter einer Creative Commons Lizenz zu verteilen. Allerdings bürdet nur die CC0 dem Nutzer keine ‘lästigen’ Pflichten auf [⇒ F].
Der dritte Weg ist der, den ich bei harmonyli.ly verwendet habe: die Duallizenzierung

Allerdings: wenn wir so vorgehen, können wir nicht mehr erzwingen, dass unsere Nutzer ihre Verbesserungen mit der Community teilen. Aber seien wir ehrlich: Sind unsere Snippets so wichtig, dass wir sie besonders schützen müssen? Ich denke, dass es manchmal besser ist, einfach so zu geben, ohne etwas zurückzufordern. Denn das kommt dann meist so, ganz von allein und freiwillig.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

The post GPL lizenzierte LilyPond-Snippets — und ihre Nebenwirkungen appeared first on Freigiebigkeit.

YOCTO, IOT und die GPLv3

Karsten Reincke — Sun, 30 Jun 2019 16:24:24 +0000

IOT-Geräte bieten meist nur eingeschränkte Möglichkeiten, die darin verwendete Software zu untersuchen oder gar zu verändern. YOCTO möchte Software ganz spezifisch für IOT-Geräte zusammenstellen. Die GPLv3 erfordert aber, dass man so lizenzierte Software ersetzen können muss. Wie also stehen sie wirklich zueinander, YOCTO, IOT und die GPLv3?

[ de | en ]

Das “open source collaboration project” YOCTO bewirbt sich mit dem Slogan “it’s not an embedded Linux Distribution, it creates a custom one for you” (→ [7]): Man sammelt und kompiliert genau die Software, die man benötigt. So kann auch die ausführende IOT-Hardware einfach gehalten werden. Das ist der YOCTO-Ansatz. Allerdings: die technische Struktur der Geräte beeinflusst auch die Erfüllbarkeit der Lizenzen. Und da kann haarig werden!

Grundsätzlich weiß YOCTO um die Komplexität der FOSS Compliance und unterstützt die Produzenten schon während des Kompilationsprozesses. Es listet z.B. alle Pakete und alle in das Image eingeflossene Lizenzen auf (→ [8] 3.5). Außerdem erlaubt es, automatisiert auch die Lizenztexte in den Build zu integrieren (→ [8] 5.20.2). Und es bietet die Option, auch den korrespondierenden Quellcode als Paket zusammenzustellen (→ [8] 5.20.1). Das sind wichtige Vorarbeiten. [Nur der Vollständigkeit halber: diese Vorarbeiten sind notwendig, aber nicht hinreichend. Allerdings ist das jetzt nicht unser Thema.]

Nun fordert jede (A|L)GPLv lizenzierte Software mehr als nur die Mitgabe der Lizenz. Oder die Nennung der Copyright-Owner und die Mitgabe des Disclaimers und (auf Anfrage) die Übersendung des Codes. Zusätzlich muss dem Empfänger die Möglichkeit gegeben werden, selbst eine verbesserte oder verschlechterte Version auf der Hardware installieren zu können. (→ [1,2,3] §3) Wenn das IOT-Gerät den Zugriff auf die interne Platte erlaubt — sei es über ein USB-Interface oder sonst wie — ist das kein Problem: der Nutzer speichert seine Version der zu ersetzenden Software darauf ab und legt den Link um. Bingo. Was aber, wenn das Gerät kein solches Interface hat? Oder wenn der Hersteller nicht möchte, dass seine Kunden dieses Recht ausüben, sei es, um gesetzliche Sicherheitsstandards nicht zu unterlaufen, sei es um seinen Betreuungsaufwand gering zu halten?

Dann — so die einfache Antwort — darf der Hersteller keine GPLv3, keine LGPLv3 und keine AGPLv3 lizenzierte Software in seinem Softwarestack verwenden. Denn über die Lizenz verspricht er, die Benutzung oder Modifikation der genutzten Software nicht zu beschränken (→ [1] §3): Entweder man erfüllt die Lizenzen oder man verwendet die Software nicht. So einfach und binär ist das ganz generell mit der FOSS Compliance.

Glücklicherweise unterstützt YOCTO den Produktmanager auch bei der Einhaltung dieser Maxime. Man kann im “recipe” zur Erzeugung des Images die Variable INCOMPATIBLE_LICENSE mit Lizenzidentifikatoren belegen kann. (→ [9] Chapter 10) Der Kompilationsvorgang bricht dann ab, wenn Entwickler trotzdem so lizensierte Software einbauen. Allerdings hat das funktionelle Nebeneffekte: YOCTO warnt sogar mehrfach, dass mit dieser Option nur sehr rudimentäre Images erzeugt werden können, (→ [9] pars pro toto: Chapter 10), eben weil so viele gute Software mittlerweile unter der GNU Lizenzen V3 veröffentlicht werden. Aber immerhin, es geht in Grenzen.

So weit, so gut. Leider stößt man damit auf ein Kernproblem, das sich viel stärker auswirkt:

Einige Standardbibliotheken — wie eben die libstdc++ — stehen in akzeptabler Reife nur noch unter den Bedingungen der GPLv3 zur Verfügung. Wenn überhaupt ist es nur sehr schwer möglich, sie zu ersetzen. Und so integriert YOCTO die libstdc++ — fast, als wolle das Projekt dies unterstreichen — in sein Image, auch wenn die Belegung der Variable INCOMPATIBLE_LICENSE dies eigentlich verhindern müsste. Es scheint also, als würde YOCTO nicht-Lizenz-konforme Images erzeugen. Betrachtet man die Lage genauer, erkennt man, dass YOCTO dennoch auf dem richtigen Weg ist:

Standardbibliotheken haben eine besondere Stellung. Sie stellen die Basisfunktionen bereit, über die ein Programm mit dem ausführenden Kernel kommuniziert und über die es erst ausführbar gemacht wird. Sie sind unumgehbar. Wird eine Standardbibliothek unter einer Lizenz mit starkem Copyleft (AGPL|GPL) veröffentlicht, ergibt sich so unmittelbar, dass jede ‘höher liegende’ Bibliothek und jedes Programm unter derselben Lizenz veröffentlich werden müsste. Die “GNU Standard C++ Library v3” — kurz libstdc++ — ist eine solche Bibliothek: Sie sieht sich als ein “ongoing project to implement the ISO 14882” (→ [5] 1.1), sie versteht sich als Teil der “GNU compiler collection” (→ [5] 1.2) [4] und ist unter der GPLv3 lizensiert (→ [4]).

Trotzdem verneint die Libstdc++-FAQ die Frage ganz klar, ob jedes Programm, das die libstdc++ nutze, unter die GPL falle: “No. The special exception permits use of the library in proprietary applications. ” (→ [5] 2.2) Wie ist das möglich?

Die libstdc++ ist nicht nur unter der GPLv3 allein lizenziert: “The source code is distributed under the GNU General Public License version 3, with the addition under section 7 of an exception described in the ‘GCC Runtime Library Exception, version 3.1’ as follows” (→ [4]). Und diese GCC-Runtime Library Exception sagt unter §1:

You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. (→ [4] §1)

Das klingt erst einmal kryptisch. Aber das Erratische löst sich auf, wenn man auch die unter §0 hinzugefügten Definitionen berücksichtigt:

Der “Target Code” bezeichnet jeden “[…] Output from any compiler for a real or virtual target processor architecture, in executable form or suitable for input to an assembler, loader, linker and/or execution phase”. Die “Runtime Library” meint eben die Bibliothek, für die Ausnahme gilt, hier also die libstdc++. Und “Independent Modules” sind die Dateien, zu deren Ausführung in kompilierter Form die Runtime Library notwendig ist. (→ [4] §0) Oder anders gesagt: Es sind die Dateien, die Funktionsaufrufe in die libstdc++ enthalten, die deren Objekt und Methoden nutzen oder deren Inline-Funktionen über libstdc++ aufgelöst werden.

Also erlaubt uns der Erste der oben zitierten Sätze, sein kompiliertes Programm auch unter Bedingungen zu verteilen, die die GPLv3 verletzten. Vorausgesetzt wird nur, man hat sein ganzes Produkt über einen Eligible Compilation Process generiert.

Ein Compilation Process wiederum ist jedes Verfahren, dass menschlich lesbaren Softwarecode oder JAVA-Byte-Code in den Target Code überführt. Und Eligble ist ein solcher Compilation Process dann und nur dann, “[…] if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC.” (→ [4]) Entweder ganz GCC oder gar nicht — aber kein Mischmasch. Darum geht es.

Der erste Satz von §1 besagt also, dass man seine gegen die libstdc++ kompilierten eigenen Programme auch dann verteilen darf, wenn man durch die Art der Verteilung die GPLv3 verletzen würde, vorausgesetzt, man hat alle Teile komplett mit dem GCC kompiliert (oder keines). Der erste Satz hebt also den starken Copyleft-Effekt unter bestimmten Bedingungen auf.

In unserem Kontext von IoT-Geräten ohne Interface zum Ersetzen der Software ist das aber nicht genug! Die Frage bleibt ja, ob man die libstdc++ selbst unter Verletzung der GPLv3 vertreiben dürfte. Um diese Frage zu beantworten, benötigen wir den 2. Satz von §1. Er besagt,

You may then [= unter den zuvor genannten Bedingungen] convey [= propagate = distribute] such a combination under terms of your choice, consistent with the licensing of the Independent Modules. (→ [4] §1)

Die genannte Kombination kann dann nichts anderes sein als die libstdc++ plus die gegen sie kompilierten unabhängigen Module und Programme. Wir dürfen das ganze Konglomerat unter den Bedingungen vertreiben, die zu den Bedingungen der unabhängigen Module passen, also auch unter Verletzung der GPLv3 — eben mit Rückgriff auf die Runtime Exception selbst. Und das gilt mithin auch für die libstdc++.

Bingo! Wirklich? Leider noch nicht ganz.

Im Urheberrecht kommt es nicht nur darauf an, die wörtliche Bedeutung eines Vertragstextes, einer Lizenz zu ermitteln. Stattdessen muss man auch berücksichtigen, was die Urheber gemeint haben. Glücklicherweise kann man das in diesem Fall recht einfach ermitteln:

Der Copyright-Owner der GNU Compiler Collection ist die FSF. Und die hat in einer libstdc++-FAQ erläutert, wie sie die GCC Runtime Exception im Kontext der libstdc++ verstanden haben möchte (→ [5]) :

Einerseits fragt die FSF ob “[…] any program which uses libstdc++ falls under the GPL?”. Und antwortet kurz und knapp: “No. The special exception permits use of the library in proprietary applications.” (→ [5] 2.1) Auf der anderen Seite erläutert des FSF in dieser FAQ, dass die libstdc++ ganz generell nicht so einfach ersetzt werden könne, wie es bei anderen Bibliotheken möglich sei, weil “much of the library consists of inline functions and templates, which are expanded inside the code that uses the library” and replacing the library would also require to recompiling the using program. (→ [5] 2.3)

Also dürfen wir auch aus der FAQ schließen, dass die FSF nicht nur den starken Copylefteffekt unter den genannten Bedingungen aufgehoben sehen will, sondern auch die Bedingung der Ersetzbarkeit.

Unglücklicherweise gibt es ein drittes Dokument, was diesem Schluss zu widersprechen scheint. Die libstdc++ ist nicht die einzige Bibliothek, die unter der Runtime Library Exception veröffentlicht ist. Deshalb hat die FSF unter dem Titel “GCC Runtime Library Exception Rationale and FAQ” auch eine generelle Einführung veröffentlich. (→ [6]) Dieses Dokument erklärt zuerst, warum man diese Technik der Ausnahmeregelungen ab der Version 3 generell einführt. Im 2. Abschnitt erläutert es, wie die Technik funktioniert. Und endet hier in dem jetzt bereits bekannten Satz “As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it ‘under terms of your choice.’” (→ [6])

Die Frage, ob auch die libstdc++ unter den Ausnahmebedingungen der Runtime Library Exception vertrieben werden darf, stellt der Text jedoch nicht. Im Kontext einer Frage nach der Nutzung einer komplett proprietären Kompilerkette wird allerdings herausgehoben, dass man auch dann die Vorteile der Runtime Exception nutzen kann, allerdings müsse man die libstdc++ selbst unter den Bedingungen der GPLv3 weitergeben.

Diesen Zusatz könnte man generell sehen wollen. Allerdings gibt es zwei starke Gründe, die das verbieten. Zum ersten ist er im spezifischen Kontext dieser Frage eingefügt worden, also nicht generalisiert worden. Und zum zweiten würde eine generelle Geltung die Runtime Exception im durch die FSF dargestellten Sinne unterlaufen. Wenn auf der einen Seite der starke Copylefteffekt der GPLv3 für die eigenen Programme über die GCC Runtime Exception aufgehoben werden soll und wenn andererseits die Art der Bibliothek trotzdem die Offenlegung des nutzenden Codes erzwingen würde, damit man die Bedingung der Ersetzbarkeit überhaupt erfüllen kann, dann hätte die FSF etwas Selbst-widersprüchliches im Sinn gehabt. Und davon ist nicht auszugehen.

So liegt die Sache nunmehr klar auf dem Tisch:

YOCTO darf die libstdc++ Bibliothek auch dann in seine Images integrieren, wenn die Nutzung von GPLv3 Software eigentlich ausgeschlossen sein soll. Es entsteht auch damit ein lizenzkonformes Image. Denn der starke Copylefteffekt ist durch die Runtime Exception ebenso aufgehoben, wie die Forderung nach der Ersetzbarkeit der libstdc++.

Allerdings gilt dies nur für die libstdc++. Auf andere Libraries können wir es nicht so einfach übertragen. Die Möglichkeit, die libstdc++ auch — wie es in der GCC Runtime Library Exception heißt — unter Verletzung der GPLv3 zu vertreiben, hängt von der Lizenzierung der libstdcc unter der GPLv3 mit GCC Runtime Library Exception ebenso ab, wie von ihrer immanenten Natur als c++-Bibliothek.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

[1] GPLv3 :- https://opensource.org/licenses/GPL‑3.0
[2] AGPLv3 :- https://opensource.org/licenses/AGPL‑3.0
[3] LGPLv3 :- https://opensource.org/licenses/LGPL‑3.0
[4] libstdc++ licensing document containing the libstdc++ GCC RUNTIME LIBRARY EXCEPTION :- https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
[5] libstdc++ FAQ :- https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.license.any_program
[6] General GCC Runtime Library Exception Rationale and FAQ :- https://www.gnu.org/licenses/gcc-exception‑3.1‑faq.en.html
[7] YOCTO project page :- https://www.yoctoproject.org/
[8] YOCTO project development manual :- https://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html
[9] YOCTO project reference manual :- https://www.yoctoproject.org/docs/1.9/ref-manual/ref-manual.html
[A] YOCTO Howto :- https://wiki.yoctoproject.org/wiki/How_do_I

The post YOCTO, IOT und die GPLv3 appeared first on Freigiebigkeit.