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

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 …

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

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

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:

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:

1. 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.
2. 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.
3. 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).
4. 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:

1. In einem LilyPond Snippets Repository werden bereits wiederverwendbare Snippets gehostet. Laut LSR fallen all diese Snippets in die ‘Public Domain’ [⇒ 5]
2. 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 …

… 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] http://LilyPond.org/gpl.html
• [2] http://LilyPond.org/introduction.html
• [3] http://LilyPond.org/text-input.html
• [4] https://github.com/LilyPond/LilyPond
• [5] http://lsr.di.unimi.it/LSR/html/whatsthis.html
• [6] https://github.com/openlilylib/
• [7] https://openlilylib.org/
• [8] https://github.com/openlilylib/oll-core
• [9] https://github.com/openlilylib/oll-core/blob/master/package.ily
• [A] https://opensource.org/licenses/GPL‑3.0
• [B] https://opensource.org/licenses/LGPL‑3.0
• [C] https://opensource.org/licenses/Apache‑2.0
• [D] https://creativecommons.org/share-your-work/licensing-types-examples/
• [E] https://opensource.org/licenses/MIT
• [F] https://creativecommons.org/publicdomain/zero/1.0/

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

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 …

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

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 …

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

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 …

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

The post Die FOSSCon 2013 appeared first on Freigiebigkeit.

Oder: ein bisschen innerfamiliäre Open Source Diversity. Auf den Chemnitzer Linuxtagen 2013 sprach der Free Software Verfechter Reinhard Müller zum Thema “Mach dich Frei: Wie man die Welt rettet. Eine Kurzanleitung in 5 einfachen Schritten”. Unfreie Software durch freie zu ersetzen, das war das Ziel. Gestern Abend ging es dann bei mir zu Hause zur Sache, beim Abendessen, mit meiner Frau. Genau dieses Vortrages wegen:

Zugegeben, Reinhard hatte da einen Hardcore-Standpunkt vertreten. In freien demokratischen Gesellschaften müssten essentielle Infrastrukturen der Gemeinschaft gehören. Es könne nicht sein, dass sie in die Hohheit einzelner Firmen übergeben würden, die die Nutzer dann zu einem ihren Interessen gemäßen Verhalten zwingen. Und die IT sei exakt so eine essentielle Infrastruktur.

An diesem Punkt lag – unausgesprochen — eine Analogie in der Luft: Wir, der demokratische Souverän, hielten es doch gewiss für absurd, übergäbe man das deutsche Straßennetz der STRABAG und ließe diese z.B. festlegen, dass man auf deren Straßen nur noch Opel fahren dürfte – was uns nicht des Opels wegen absurd vorkäme. Aber ärgerlicherweise nähmen wir, das Volk, analoge Versuche im IT Bereich völlig klaglos hin. Im Gegenteil, es gäbe den akzeptierten Hang zum „glücklichen Sklaven“.

Und was wäre – laut Reinhard Müller — der Ausweg aus dieser ‚selbstverschuldeten Unmündigkeit‘: Nun, man könne doch – erst mal jeder für sich — Schritt für Schritt sich seine je eigene wirklich freie IT-Infrastruktur ausformen. Das entscheidende Kriterium sei die Existenz von Alternativen. Und nach dem Simplify-Prinzip könnte sogar ganze Migrationsprojekte vorgehen, ohne zu scheitern, nämlich schlicht nach der Regel ‚vom Einfachen zum Komplexen‘:

1. Nutze nur freie Kommunikationswege. Verzichte auf Medien, die an spezifische Firmen gebunden sind (kein Skype, kein Whatsapp, [lieber echtes Telefon und Join ])
2. Nutze nur freie Datenformate. Verzichte auf Formate, die in ihrer Struktur unbekannt und an spezifische Firma gebunden sind (kein Kindle ‚[lieber Tolino]),
3. Nutze nur freie Anwendungen, um diese Daten zu lesen und/oder zu modifizieren (kein Acrobat, lieber evince).
4. Nutze nur freie Betriebssysteme zum Betrieb dieser freien Anwendungen [kein Apple, lieber GNU-Linux]
5. Sei ein freier selbstbestimmter (IT-)Mensch.

So weit, so gut oder schlecht. Ich wollte von Reinhard Müller dann wissen, wie ich so etwas meiner Frau nahebringen solle. Er müsse bei seinem Ratschlag allerdings berücksichtigen, dass meine Frau ihre eigenen schönen Kopf habe. Für sie müsse die Technik ohne Aufwand smooth funktionieren. Und schick müsse sie sein, die Technik — weshalb sie, meine Frau, bis jetzt im Apple-Biotop lebe. Und mit Moral brauche man ihr schon mal gar nicht zu kommen. Was also – so wollte ich wissen — solle ich da tun?

Na, – so Reinhard — meine Frau gehöre dann halt eben zu den „glücklichen Sklaven“. Er habe gar nix gegen glückliche Sklaven (auch wenn diese für die gefährlichsten Gegner der Freiheit halte). Er wolle nur seinerseits nicht gezwungen werden, solch unfreie Sachen nutzen zu müssen. Vielleicht sei ja so ein Toleranzmodell auch bei mir innerfamiliär denkbar.

Tja, abends hab ich dann meiner Frau davon zu erzählt. Da ging’s aber ab:

Zum ersten hat sie mir um die Ohren gehauen, dass sie sehr wohl aus moralischen Gründen auf eine bessere Ästhetik verzichte. Ich bräuchte doch nur mal an den Austausch der Kaffeemaschine zu denken, weg von den umweltbelastenden Nespresso-Alu-Kapseln, hinzu normalen Bohnen in einer weniger schicken und umständlicheren Maschine. Wer etwas von ihr wolle, müsse ihr das eben einfach und nachvollziehbar erklären. Und genau das täten diese ganzen Open Source Gurus ja gerade nicht. Da sei immer alles so kompliziert, dramatisch und vielschichtig – und mühselig zu verstehen. Also wenn diese Open Source Community sie — meine Frau — gewinnen wolle, dann müsse sie — diese Community — sich schon etwas um sie — meine Frau — bemühen. Dann klappe das auch mit der Nachbarin.

Und dann immer wieder dieses abstoßende Gut-Und-Böse-Gehabe. Hier die guten Open Sourceler, da die „glücklichen Sklaven“, die entweder zu dumm seien, die Technik und die Konsequenzen zu begreifen, oder schlicht zu faul oder zu ignorant. Sie sei glücklich, aber keine Sklavin. Es sei ihr Recht, die Dinge einfach haben zu wollen. Sie dürfe die IT nutzen wollen, ohne zum Experten werden zu müssen. Ihr Leben habe einen anderen Sinn. Und sie sei nicht abhängig. Oder wenn, dann allenfalls in dem Sinne, wie sie von mir abhängig sei, ihrem Mann. Und daran wolle ich doch wohl hoffentlich nichts ändern.

Da hab ich dann – sehr, sehr vorsichtig — angemerkt, dass Amazon doch aber schon bestimme, welche Bücher sie zu lesen bekäme, wenn Amazon unter der Hand Versionen auch von schon gekauften Büchern austausche. Undschließlich gäbe da schon einen großen Unterschied zwischen Amazon und mir: Mich könne sie ersetzen, sie könne die Schlösser austauschen, ins Hotel ziehen oder meine Sachen vor die Tür stellen – und uneingeschränkt glücklich weiterleben. Amazon könne sie nicht vor die Tür setzen, ohne ihre ganzen Bücher zu verlieren. Und Apple auch nicht, ohne keine Musik mehr zu haben.

Das möge ja sein – meine Frau hielt weiterhin vehement dagegen -, nur bleibe es dann immer noch eine Frechheit, sie als „glückliche Sklavin“ zu deklassieren. Sie dürfe sich doch ihr Leben wohl so organisieren, wie sie es wolle — und zwar ohne dass selbsternannte Gutmenschen den Stab über sie brächen. Und wenn diese Open Source Weltverbesserer schon die Welt verbessern wollen, dann sei sie ja wohl ein Teil dieser Welt. Und durch Beschimpfungen und Herabwürdigungen anstelle von [energischer Unterton:] einfachen [sehr energischer Ton:] handlichen [sehr energischer Oberton:] Begründungen sei noch niemand vom Besseren überzeugt worden.

Wie eigentlich immer hatte ich auch gestern wieder den Eindruck, dass meine Frau die Sache auch richtig sähe und dass ich an meinem Standpunkt noch überabreiten müsse. Vielleicht sollte ich Reinhard das mal schreiben…

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.

The post Unfreie Software durch freie ersetzen: ein Weg zur FreiFrau appeared first on Freigiebigkeit.