FOSS Archives - Freigiebigkeit

Das eigene Farbkonzept mit bootScore

Karsten Reincke — Thu, 21 Mar 2024 12:47:28 +0000

Als “leistungsstarkes, kostenloses Bootstrap-Starter-Theme für WordPress” verwendet bootScore das Farbdesign von Bootstrap und zeichnet seine Elemente entsprechend aus. Zur Verfeinerung dieser allseits gleichen Ergebnisse liefert es aber Techniken mit. So muss die Webdesignerin erst das eigene Farbkonzept entwickeln und es dann in und mit bootScore umsetzen, wenn sie ein persönliches Outfit ihrer Site möchte:

[ de | en ]

Lösung

Konzipiere das Erscheinungsbild Deiner Site.
Wähle die entsprechenden Bootstrap-Farbcluster.
Schreibe die Funktionsfarben entsprechend um.
Definiere die eigenen CSS-Klassen gemäß Deines Konzeptes.
Weise die Klassen den intendierten Elementen Deiner Website zu.

Hintergrund

Bootstrap hat den RGB-Farbraum in 10 Farbcluster unterteilt: Blau (blue), Indigo (indigo), Violett (purple), Rosa (pink), Rot (red), Orange (orange), Gelb (yellow), Grün (green), Petrol (teal), Cyan (cyan), Grau (gray). Jeder Cluster beginnt mit einer entsprechend hellen Farbe und geht 9 Schritten bis zu einer entsprechend fast schwarzen Farbe. Definiert sind die Farben als SASS-Variablen, für jeden Cluster nach demselben Muster. Zugreifen können wir so etwa auf ein $green-100, $green-200, $green-300, $green-400, $green-500, $green-600, $green-700, $green-800, $green-900, wobei $green der Farbe $green-500 entspricht.

Wollen wir diese Farben in einem unserer Element verwenden, definieren wir in unserer Child-Themedatei scss/bscore_custom.scss eine CSS-Klasse .cdg600 { color: $green-600; } und weisen die dem intendierten HTML-Element zu, wie z.B. hier $green-600. Diese Technik verengt den RGB-Farbraum zwar, sie erleichtert es uns aber, farblich differenzierte und trotzdem einheitliche Themes zu erstellen.

Neben der rein technischen Farbbehandlung geht Bootstrap auch konzeptionell neue Wege: Es gäbe — so der Gedanke — Site-übergreifende kommunikative Aufgaben, die von verschiedenen Elementen einer Site ausgeführt werden (können). Bootstrap erlaubt es, diesen Funktionselementen typische “Funktionsfarben” zuzuordnen. Welche Elemente einer Site welche Funktion übernehmen, entscheidet die Web-Designerin — und ordnet diesen die entsprechend “Funktionsfarbe” zu.

Konkret geht Bootstrap davon aus, dass es in Sites typischerweise (mehrere) Elemente gibt, die Erfolg signalisieren, die abschrecken, warnen oder informieren. Oder, dass es primäre Elemente gibt, sekundäre oder teriäre¹, dunkle oder helle Elemente. Für diese seitenübergreifenden kommunikativen Funktionen definiert Bootstrap ‘funktionale Farben’. Das entsprechende Bootstrap-color-Howto zeigt die Vorbelegung dieser ‘Funktionsfarben’.

Ein Bootstrap-basiertes Theme muss also nur noch seine Elemente entsprechend der vorgesehenen Funktionen mit den zugehörigen CSS-Klassen auszeichnen, um ein minimal konsistentes Farbkonzept zu realisieren. Das hat bootScore vorbereitet. Allerdings verwendet es die Standard-Funktionsfarben von Bootstrap. So entsteht ein recht “buntes” Farbkonzept. Wir können die Farbwahl jedoch ‘entschärfen’, indem wir die CSS-Definitionen der ‘Funktionsklassen’ überschreiben und so die konzeptionell passende Farbe auf alle entsprechend markierten Elemente übertragen. bootscore demonstriert diesen Ansatz, indem es die Primärfarbe von Blau auf Rot umsetzt — mithilfe der Zeile $primary:#FF0000; in der Datei bscore_variables.scss.

Dabei müssen wir den Wert der gewünschten Farbe jedoch explizit zuweisen, anstatt eine der Variablen aus den von Bootstrap definierten Farbclustern zu verwenden. Das ist nicht das, was wir eigentlich wollen. Intuitiv würden wir $primary:$red; schreiben. Leider ist das nicht möglich, weil die bootScore-Datei bscore_variables.scss vor der entsprechenden Bootstrap-Datei geladen wird.². Um also die von Bootstrap definierten und von bootScore verwendeten Funktionsfarben anzupassen, müssen wir die bestehenden Definitionen überschreiben, in denen wir explizit die Werte der beabsichtigten Clusterfarben verwenden. Dazu nutzen wir unserer Datei bscore_variables.scss.

Die Umdefinition einer Funktionsfarbe passt dann allerdings auch abgeleitete Farben an: Setzen wir die Primärefarbe auf rot, werden die Links rot eingefärbt, die Hintergrundfarbe der Badgets auf ein helleres Rot und deren Linktext auf ein dunkleres. bootScore reicht dabei ’nur’ die Entscheidungen von Bootstrap durch.³

Als Ausgleich für die Komplikation können wir dann alle vordefinierten Bootstrap-Variablen in unseren eigenen CSS-Definitionen verwenden, die wir in unserer Bootscore-Datei bscore_custom.scss definieren. Mehr noch: wir können auch die von Bootstrap vordefinierten CSS-Klassen (text|bg|…)-(primary|secondary|…|danger|…‘) direkt unseren HTML-Elementen zuordnen, sodass auch diese unseres Konzeptes entsprechend eingefärbt werden. Und noch weiter und feiner: Wir können auch bestehende Klassen — wie etwa die CSS-Klasse card — mit der SASS orienierten Definition .card { backgroundcolor: var(--#{$prefix}dark); in unserer Datei bscore_custom.scss auf einen schwarzen Hintergund umsetzen.⁴ Damit würden alle Karten in unseren Übersichtsdatei ‘verdunkelt’.⁵

Weil wir jedoch oft genug nicht alle Elemente ändern wollen, die mit vordefinierten Klassen ausgezeichnet sind, landen wir zum Schluß doch wieder bei der traditionelle Methode: wir definieren unsere eigenen Klassen, nutzen dabei Farben aus den Bootstrap-Clustern, und weisen unsere Klassen dann in den Templates den von uns intendierten Elemente zu. Und wie finden wir diese? Indem wir den Quellcode unserer bisherigen bootscore-Seiten studieren — und etwas ‘rumprobieren.

Um es zusammenfassen: Für einheitliches und technisch eingebundenes Farbkonzept, müssen wir

unsere Ziele definieren (hier:
- Unsere Site soll blau-weiß-grau erscheinen = in Datei _bscore_variables.scss einfügen:
  - $primary: #0d6efd; // Wert von $blue-500
  - $secondary: #6c757d; // Wert von $gray-600
  - $info: #6ea8fe; // Wert von $blue-300
- Hervorstechende Elemente sollen violett erscheinen = in Datei _bscore_variables.scss einfügen:
  - $danger: #520dc2; // Wert von $indigo-600
  - $warning: #8540f5; // Wert von $indigo-400
- Nebensächlicher Text soll lesbar ausgegraut sein.
- Die weißen Artikelteaser sollen schwach-blau umrandet sein = in Datei _bscore-sustom.scss einfügen: .card { border-color: $blue-600; }
- Die Teaser auf der Landingpage und auf den Übersichtsseiten sollen auf einem leicht blauen Hintergrund abgelegt werden. = in Datei _bscore-sustom.scss einfügen: .page-template-mylap , .hfeed { background-color: $blue-100;}
- Header und Footer sollen weiterhin auf grauem Hintergrund dargestellt werden.
die funktionalen Farben entsprechend umschreiben — in unserer Datei bscore_variables.scss
unsere Siteelemente entsprechend ihrer Funktion mit den Funktionsklassen auszeichnen⁶
unsere eigenen CSS-Klassen entsprechend unserer Ziele definieren — in unserer Datei bscore_custom.scss
unsere Klassen den vorgesehenen Elementen unserer Site zuweisen⁷

CSS-class: bg-primary	CSS-class: text-primary
CSS-class: bg-secondary	CSS-class: text-secondary
CSS-class: bg-success	CSS-class: text-success
CSS-class: bg-info	CSS-class: text-info
CSS-class: bg-warning	CSS-class: text-warning
CSS-class: bg-danger	CSS-class: text-danger
CSS-class: bg-dark	CSS-class: text-dark
CSS-class: bg-light	CSS-class: text-light

Und in welchem Zusammenhang …

… steht das mit unserer Migration zu bootScore? Nun, einmal angefangen mit Verbesserungen der Bildbehandlung, werden der Web-Designerin auch die verwischten ‘primären Beitragsgilder’ auffallen. Sie wird Lösungen ausprobieren und verfeinern. Und sie wird sie u.U. auch mit neuen HTML‑5 Techniken angehen. Denn damit wird eine ausgefallenere Bildstrategie samt integrierter Lizenzerfüllung und das eigene Logo erst richtig sinnvoll. Wie auch immer: Bilder bringen Farbe ins Leseleben. Zuletzt sollte all das also auch in ein eigenes Farbkonzept eingebunden sein. Zu dieser Thematik trägt auch dieser Post etwas bei.

Im Übrigen: Männer sind mitgemeint.

semantisch ist dies wohl eine Abstufung der Wichtigkeit
bootScore sagt, dass es damit der Bootstrap-Richtlinie folgt.
Mehr noch: Gefragt danach, welche HTML-Elemente welcher Funktion zugeordnet sind, empfiehlt bootScore, das einfach auszuprobieren.
oder wie auch immer die Funktionsfarbe ‘dark’ gerade definiert ist
Das ginge zugegebenermaßen auch einfacher, nämlich mit der Anweisung .card { backgroundcolor: $dark}.
wie in u.a. Tabelle demonstriert
wie oben vorgeführt

The post Das eigene Farbkonzept mit bootScore appeared first on 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.

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 …

… 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.

[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.

Die Corona Warn App als Open Source Software

Karsten Reincke — Tue, 16 Jun 2020 11:00:00 +0000

Heute zeigte sich die CWA — die Corona-Warn-App — der Öffentlichkeit. Sie gibt ein positives Bild. Das sagen selbst Spiegel und Welt. Die deutsche Regierung wollte sie als Open-Source-Software veröffentlichen, um die Akzeptanz bei der Bevölkerung zu erhöhen. Trotzdem gibt es noch einige Skepsis. Ich möchte ein paar spezielle Bedenken kommentieren:

[ de | en ]

Gelegentlich höre ich, die Corona-Warn-App sei gar keine echte Open-Source-Software. Denn sie nutze ja die nativen Google-/Android- bzw. Apple-/iOS- Funktionen mit proprietären Anteilen. Das zu behaupten, ist formal und inhaltlich nicht adäquat:
- Open-Source-Software ist, was unter einer Open-Source-Lizenz veröffentlicht ist. Und was eine Open Source Lizenz ist, ist von der Open-Source-Initiative definiert. Die Corona Warn App wird nachweislich unter der Apache-v2 Lizenz veröffentlicht.
- Die ‚Open-Source-Haftigkeit‘ einer Software ist schon seit R. Stallmann völlig unabhängig davon, auf welchem (proprietären) Betriebssystem sie läuft. Zu seiner frühen Zeit ging es noch um die Unix-Derivate. Die kamen mit mehr oder minder geschlossenen Basisbibliotheken daher und führten die Open-Source-Software als Prozess aus. Wer Open-Source wirklich nur das nennen will, was in einem gänzlich freien Stack von Open-Source-Software genutzt wird, scheitert damit in der Regel schon am BIOS.

Zweitens sagen manche, das System sei nicht vertrauenswürdig (weil eben doch Daten zur Regierung kommen). Dem stehen die drei Prinzipien der Offenheit , Freiwilligkeit und der Wahrung der Anonymität entgegen:
- Ich selbst entscheide ja, ob ich die App installiere oder nicht. Wenn ich sie installiere, plottet die darunter liegende iOS-/Android-Funktionen per Bluetooth mit, welche anderen Handies ‚in der Nähe‘ sind. D.h. auf meinem Handy entsteht eine Liste der Identifikatoren der anderen Handys – aber eben nur auf meinem Handy. So, wie meine Handy-ID umgekehrt in den Listen der anderen Handys auftaucht.
- Jeder kann anhand des offen gelegten Codes (Apps, Server, Verification System) alles überprüfen, insbesondere, dass keines der Programme diese Identifikatoren an Dritte z.B. einen Regierungsserver weitergibt. Sie bleiben auf dem entsprechenden Handy.
- Ich selbst entscheide außerdem, ob ich, wenn ich erkranke, meine Erkrankung kundtue. Wenn ich das tue, wird über einen Scancode gewährleistet, dass ich nur als wirklich Getesteter mein Ergebnis in das System eingebe.
- Wenn ich mich oute, steht jedoch nur mein Handyidentifier online zum Abruf bereit, nicht meine Daten.
- Ferner entscheide ich selbst, ob ich mir mehr oder minder regelmäßig vom Server die Handy-Identifikatoren der Erkrankten abhole und LOKAL auf meinem Handy mit den Handy-Identifikatoren meiner ‚Begegnungen‘ vergleichen lasse.
- Es gibt an keiner Stelle eine Verknüpfung meiner Personendaten mit meinem Handy-Identifier. Jeder kann im Code überprüfen, dass das System das NICHT tut. Und die einzigen, die das sonst noch tun könnten, wären Apple und Google. Dazu hätten sie aber böswillig Schadcode in ihre Basisbibliotheken einbauen müssen. Und mit der amerikanischen und/oder deutschen Regierung ein geheimes technisches Austauschsystem aufsetzen müssen. Liebe Verschwörungstheoretiker: Hätten die Firmen das tun wollen, gäbe es auf den Geräten einfachere, effektivere und kostengünstigere Möglichkeiten, so etwas umsetzen.

Und schließlich vermuten einige, die Corona Warn App werde später heimlich und unter der Hand doch noch in ein staatliches Trackingsystem umgebaut.Das wird aber nicht funktionieren:
- Der Quellcode steht öffentlich zur Verfügung. Wollte man also später eine veränderte ‚Version‘ heimlich in Verkehr bringen, müssten die Apps zuletzt doch wieder in die offiziellen Stores eingepflegt werden – und zwar unter Wahrung der offiziellen Releasenummern.
- Das wäre nicht geheim zu halten: Irgendjemand würde bestimmt einmal die Apps aus dem offiziellen Repo kompilieren und – wenigstens von der Größe her – mit den auf dem Handy installierten vergleichen. Gäbe es dort signifikante Abweichungen – und die wird es geben, wenn man in die gute Version heimlich geheimen Schadcode einpflegen würde – gäbe es einen Aufschrei.

Langer Rede kurzer Sinn: Wir dürfen dieser Arbeit vertrauen. Und wir sollten sie benutzen. Das schützt unser Gesundheitssystem vor einer Überlastung (während der 2. Welle).

Und in welchem größere Zusammenhang …

… steht dieser Text? Nun, mein Leben ist eingebettet in freie Software, Natur und Musik. Manchmal finde ich da abseitigere Wege und Tools, die es trotzdem wert sind, geteilt zu werden. Und sei es nur mit meinem vergesslichen zukünftigen ‘ich’. Dem ich gerne immer wieder einmal ein Strato über die Shell ans Herz lege. Oder passend erweiterte Editoren. Oder uralte Vorarbeiten. Manchmal möchte ich dieses ‘ich’ aber auch nur an Haltungen, Standpunkte und Einstellungen erinnern. Damit ich nicht hinter mich zurückfalle. Denn gesagt ist gesagt. Darum geht es auch in hier.

Im Übrigen: Männer sind mitgemeint.

The post Die Corona Warn App als Open Source Software 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.

Wie die eine JNIZ Lizenzierung schiefgeht:

Karsten Reincke — Sun, 17 Feb 2019 11:28:34 +0000

Aktuell sichte ich gerade freie Musiksoftware, darunter auch die jniz und seine spezielle Lizenzierung. Dieses Tool erlaube der Nutzerin “[…] to build and to harmonize several voices according to the rules of classical harmony.” Seine Lizenz aber ist ’strange’. Und am Ende verletzt der Autor damit die GPL — ein Paradebeispiel:

[ de | en ]

Beginnen wir mit der JNIZ Lizenz selbst. Sie besagte einmal¹ u.a.

“Jniz is a free proprietary piece of software. It is forbidden to sell it. You do not have the right to sell, distribute Jniz or use its sources under penalty of law. You will infringes on the Jniz staff property rights.”

Natürlich hat jede Copyrightownerin — hier Bruno Grandjean — erst einmal das Recht, jedes ihre Werke unter genau die Lizenz zu stellen, die ihr gemäß erscheint. Das Recht endet aber dort, wo der (starke) Copylefteffekt der GPL zu wirken beginnt:

Lädt man sich das Package runter und entpackt es, findet frau unter jniz/ressources/LilyPond/usr/bin [Achtung: ‘ressources’ ist Stand heute kein Typo!] einige LilyPond-Dateien, die explizit unter der GPL veröffentlicht sind — so z.B. die Datei ‘lilylib.py’.

Damit ist die Sachlage klar: JNIZ nutzt LilyPond-Funktionalität, es ist funktional vom LilyPond-Code abhängig und also ein ‘derivative work’. Damit muss auch JNIZ unter den Bedingungen der GPL veröffentlicht werden — was es nicht tut. In der gegenwärtigen Form ist die JNIZ-Lizensierung also illegal.

Ich habe heute das Sourceforge-Projekt entsprechend kommentiert und den Autor auch direkt auf seine fragliche JNIZ Lizenzierung angesprochen. Ich vermute, dass ihm das ganze Problem nicht klar ist und dass er sein Werk eigentlich richtig zu Open-Source-Software machen wollte. Daraus ergäben sich gute Lösungsmöglichkeiten. Schau’n wir mal.

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

Früher waren alle Informationen unter ‘http://www.jniz.org‘ abrufbar. Heute existiert nur noch das Source-Forge-Repository.

The post Wie die eine JNIZ Lizenzierung schiefgeht: appeared first on Freigiebigkeit.

Die FOSSCon 2013

Karsten Reincke — Thu, 02 Jan 2014 13:46:07 +0000

Ein Besuch der Extraklasse! Im Dezember 2013 war ich als Speaker auf die FOSSCon 2013 eingeladen. Nach Seoul / Südkorea. Eine außergewöhnliche Ehre … und ein außergewöhnlicher Genuss, selbst wenn ich von Korea wenig, vom Hotel einiges und nur von der Konferenz viel gesehen habe:

Es begann mit einer Keynote von Karsten Gerloff, Präsident der Free Software Foundation Europe, der die politische Arbeit der FSFE erläuterte, insbesondere im Hinblick auf Orderprozesse der öffentlichen Verwaltung. Es wäre komisch gewesen, hätte er nicht über Komplexität gesprochen.

Ähnlich Andrew Wilson: Intel, sein Arbeitgeber, besitze auch ein Open Source Review Board. Allerdings sei es in einer komplexeren Weise in die Produktionswelt der Firma eingebunden, als üblich. Jedes Projekt, das Open-Source-Software einsetze, müsse sich das Approval dieses Boards einholen. Nur geschehe das eben nicht eines Selbstzweckes wegen. Es gehe vielmehr darum, dass das Projekt die Open-Source-Software nicht in einer Weise verwendet, die der Community nicht gefällt. Der Ton sei halt rau da draußen in der Open Source Community. Und so sei es ein echter Vorteil für Intel, wenn ihre Projekte im geschützten Raum eines internen Reviews ’scheitern’ und zur ‘Nachbesserung’ geschickt werden können.

Unser eigenes Thema, der (Telekom) Open Source Compliance Advisor und sein Geschwister, das (Telekom) Open Source License Compendium, fügt sich da nahtlos in diesen Rahmen ein. Es ist schon ein tolles Gefühl, so willkommen geheißen zu werden und mitzukriegen, wie ehrlich das Auditorium verstehen will, wie und warum die Telekom die Tools OSLiC und OSCAd entwickelt hat. Mehr noch: wie und warum wir die beiden selbst als Open-Source-Software freigegeben haben. Klar, dass ich den OSCAd erneut vorgeführt habe. Und ebenso klar, dass dieser Link in Südkorea jetzt herumgeht. Dass es zum OSLiC eine koreanische Übersetzung gibt, ist natürlich ein besonderes Schmankerl.

Ähnlich müssen die Erfahrung im Projekt Genivi sein. Klaus-Peter Wiedemann von Bearing Point stellte es vor. Allerdings arbeiten daran aber viele Firmen mit. Unter anderem auch T‑Systems. Geprägt ist das Projekt von einer komplexen Kooperation. Der Witz ist nur: Es funktioniert. Und zwar umso besser, je weiter der Weg zu einem Open-Source-Projekt zurückgelegt worden ist. Genivi ist ein Projekt, das einen ‘open source software stack’ für ‘Autoindustrie’ entwickelt. Denn — wie soll Dieter Zetsche gesagt haben — heute laufen Autos nicht mehr mit Benzin, sondern mit Software.

Das wiederum passte sehr gut zu dem hellsichtigen Vortrag von Prof. Kern Koh: Firmen transformieren sich in Softwarefirmen und dann in Open Source Softwarefirmen. Sonst scheitern sie. Seine Beispiele — beginnend bei Intel bis hin zu Kodak – waren schon beeindruckend. Für uns Telekom’er gilt das ja auch: selbst als reiner Carrier (der wir nicht sind und nicht sein wollen), wären wir heute trotzdem eine Softwarefirma und nicht mehr eine reine ‚Kabelfirma‘

Besonders komplex für mich waren — Überraschung — alle koreanischen Vorträge. Und die Podiumsdiskussionen am zweiten Tag. Besonders als Teilnehmer. Denn einem koreanischen Beitrag mit koreanischen Folien zu folgen, selbst wenn er simultan übersetzt wird, ist wirklich eine Herausforderung. Aber wie heißt es so schön?

Kein Angst vor Komplexität oder anderen Abgründen!

Und in welchem Zusammenhang …

Im Übrigen: Männer sind mitgemeint.

The post Die FOSSCon 2013 appeared first on Freigiebigkeit.