Vorgestern hatte ich die Chemnitzer Linuxtage mit ihren vielen anregenden Vorträgen besucht – u.a. auch den des echten Free Software Apologeten, Reinhard Müller: “Mach dich Frei: Wie man die Welt rettet. Eine Kurzanleitung in 5 einfachen Schritten“. 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, hielte 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 – so die Botschaft der Ausgangspunkt in dem Vortrag – 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‘:
- Nutze nur freie Kommunikationswege. Verzichte auf Medien, die an spezifische Firmen gebunden sind (kein Skype, kein Whatsapp, [lieber echtes Telefon und Join
])
- Nutze nur freie Datenformate. Verzichte auf Formate, die in ihrer Struktur unbekannt und an spezifische Firma gebunden sind (kein Kindle ,[lieber Tolino]),
- Nutze nur freie Anwendungen, um diese Daten zu lesen und/oder zu modifizieren (kein Acrobat, lieber evince).
- Nutze nur freie Betriebssysteme zum Betrieb dieser freien Anwendungen [kein Apple, lieber GNU-Linux]
- 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…
- 18. März 2013
- kreincke
- Free Software, FSFE
Seit einigen Wochen wird auf der OSI license discuss mailing list die Frage diskutiert, ob PHP Programme gewissermaßen automatisch Open Source sind. Das ist bei näher Betrachtung eines kleinen Kommentares wert.
Initial bezog sich Engel Nyst auf die Frage: “Is <SOME PROGRAM> Open Source simply because it’s written in <SOME > OPEN SOURCE LICENSED LANGUAGE>”, um dann kritisch der Verneinung in der OSI FAQ nachzugehen. Diese besagt schlicht, dass die Implementierung der Sprache das eine sei, der Code der Sprache das andere. Und Nyst erstaunt nun, dass die “[.] FAQ page assumes that the confusion around PHP applications being ‘Open Source’ has anything to do with the license of the language implementation”. Vielmehr gehe es doch darum: “Is this PHP program Open Source simply because the source of a PHP program is *available*, therefore ‘open’ source?”
Nun, die Diskussion schwenkte schnell auf mögliche sprachliche Verbesserungen in der FAQ um. Was aber wäre der Hintergrund für eine Reformulierung. Wir sehen das so:
Der Interpreter einer Skriptsprache (php, perl, python) ist natürlich seinerseits ein Computerprogram, das in welcher Sprache auch immer implentiert wird. Seine Entwicklung kann unter eine Open Source Lizenz gestellt sein, muss es aber nicht. Auf jeden Fall nimmt jeder Interpreter einen Text (den php-, perl- oder python-Quelltext) und übersetzt ihn in eine andere Form (in die ausgelieferten HTML-Seiten, in Output Daten oder ein Computerverhalten). So gesehen, wäre es bei den Interpretern wie bei Word (ähäm): das nimmt auch einen Text (z.B. mein Artikeltemplate), führt darauf Operationen aus (Übersetzung meiner Zweifingerstakserei in Buchstaben) und sichert das Ganze in einer neuen Form (meines Blog-Beitrags). Nur kommt man gemeinhin nicht auf die Idee, zu sagen, dass mein Blogtext deshalb automatisch unter die EULA von Microsoft fiele. Generell gesagt: In der Regel unterliegt weder Input, noch der Output eines Programms nicht der Lizenz des Programms selbst.
Und so ist das eben auch bei Interpretersprachen: Selbst wenn Programme als offene Softwarequellen vorliegen, sind sie damit nicht automatisch offene Quellsoftware – sie müssen, wollen sie Open Source Software werden, selbst noch unter eine Open Source Lizenz gestellt werden. Umgekehrt dürfen wie offen vorliegende Softwarequellen nicht automatisch als Open Source Software ‘weiterverarbeiten’, nur weil sie eh schon offen vorliegen.
- 26. Januar 2013
- kreincke
- open source, OSI, php
Vor einigen Tagen gab es eine gediegene Diskussion unter uns Open Source Adepten: Unterläuft Open Source Software in der Cloud wirklich das Prinzip von ‘Open Source Software’? … anders gefragt: Klaut Open Source Software in der Cloud die Open Source Software?
Nun, ein Ausgangspunkt der Diskussion war der Artikel von William Judd. Im Kern geht es da um die Frage, ob die in der Cloud eingesetzte Open Source Software die Anwendung der Open Source Regeln nun auslöst oder nicht: muss man den Quellcode einer verbesserte Open Source Software aus seiner Cloud offenlegen oder nicht? Früher, als man, um Software zu nutzen, immer auch die Binaries haben musste, konnten die Open Source Gurus noch simpel festlegen, dass bei Open Source Software neben dem Kompilat auch der Quellcode zugänglich sein müsse. Heute – in Zeiten der Cloud – sei das nicht mehr so: nun habe der Nutzer u.U. nur noch Zugriff auf den Output, nicht aber auf die Binaries selbst.
Hitzig war die Diskussion schon – obwohl die Sache vielleicht doch nicht so dramatisch ist:
Zum einen gibt es die sogenannten permissiven Lizenzen (BSD, MIT, Apache, etc.). Die fordern an keiner Stelle, dass man den Code weitergeben müsse (auch wenn man es gerne tun dürfe ) – egal, wie man die Programme verwendet. Ergo unterläuft man ihre Idee auch nicht, wenn man sie in der Cloud anwendet, ohne Verbesserungen offenzulegen.
Dann gibt es die Lizenzen mit schwachem Copyleft (LGPL) und starkem Copyleft (GPL und AGPL). Ihnen gemeinsam ist, dass man ihren Vorgaben nach eben dem, dem man ein Compilat gibt, (auf Anfrage) auch den Quellcode geben müsse. Heißt: So lange ich zu Hause auf meinem Rechner ein so lizenziertes Programm verbessere und laufen lasse, bleibt’s meine Sache. Gebe ich es jedoch an einen dritten weiter, muss ich diesem dritten auch den Quellcode zugänglich machen – aber eben nur ihm, nicht der ganzen Welt.
Und jetzt kommt’s: Worin unterscheidet sich denn jetzt die private Nutzung auf einem privaten Rechner von der auf einem gemieteten Rechner aus der Cloud? Und was ist der Unterschied, wenn ich selbst etwas in der Cloud installiere und laufen lasse und wenn ich einen dritten damit beauftrage?
Diese Fälle unterscheiden sich gar nicht – sagen die einen. Ergo dürfe zumindest GPL und LGPL lizenzierte Software (selbst in modifizierter Form oder als Komponente eines eigenen Werkes) in der Cloud genutzt werden, ohne dass man deswegen seine Verbesserungen offenlegen müsse. Schließlich gäbe man sein Programm rechtlich ja gar nicht weiter (selbst wenn man es dazu realiter doch an seinen Administrator zur Installation auf seinem Cloud teil weiterreiche). Mithin unterlaufe man die GPL-Idee auch nicht, wenn man GPL-Software in der Cloud anwendet, ohne Verbesserungen offenzulegen
Die anderen – und dazu gehöre ich – sagen, dass sich diese Fälle eben genau da unterscheiden: Wenn ich selbst per sftp etwas hochlade und per ssh auf meinem Cloudteil starte, gleiche das der rein privaten Nutzung auf privatem Rechner. Aber wenn ich diese Software dem Administrator meiner Wahl zur Installation übergäbe, dann gäbe ich sie ihm ja. Punktum. Ergo habe er das Recht, auf Wunsch auch den Quellcode zu bekommen.
Ärgerlicherweise ist die Welt nicht so schön (klar), wie wir anderen es gerne hätten:
Zum einen kann ich ja meinem Nachbarn ja auch eine Flasche Milch in doppeltem Sinne ‘übergeben’. Ich kann ihm erlauben, sie zu nutzen, also zu trinken oder an seine Frau zwecks gemeinsamen Genusses weiterzureichen. Oder ich kann meinen Nachbarn bitten, die Flasche [gibt's so was überhaupt noch?] (gegen Einwurf kleiner Münzen) in seinen Kühlschrank zu stellen. Dann wäre ich doch wohl etwas pikiert, wenn er sie mir halb leer zurückgäbe. Irgendwie ist Weitergabe nicht gleich Weitergabe.
Zum anderen hat die GPL Community diese Lücke doch offensichtlich selbst entdeckt. Ihretwegen existiert die AGPL. Sie legt explizit fest, dass man den verbesserten Code selbst dann an alle freigeben muss, die per Netz mit der AGPL Cloud Software interagieren, wenn man ihnen gerade kein Kompilat überlassen hat.
Was also ist richtig? Unterläuft Open Source Software in der Cloud nun den Gedanken von Open Source oder nicht?
In den meisten aller Fälle sicher nicht. Und bei dem Rest brauchen wir vom Open Source License Compendium das glücklicherweise nicht zu entscheiden. Wir wollen nicht die Grenzen von Open Source austesten. Wenn nötig, wäre das der Job von gestandenen Juristen. Wir wollen nur eine sichere Art der lizenz-adäquaten Nutzung pro Lizenz und Usecase beschreiben. Und danach wäre es – so meine ich persönlich – schon sinnvoll, auch bei Nutzung von GPL und LGPL Software in der Cloud, den Distributionsfall anzunehmen. Sicherheitshalber. Bei AGPL Software müssen wir es ja eh tun.
Und mal ganz ehrlich: Wenn wir eine Open Source Software in der Cloud laufen lassen und uns dafür vom Endkunden bezahlen lassen, wäre es nicht ein Zeichen des Respektes, wenn wir unsere Verbesserungen daran an die Community zurückgäben – selbst wenn wir bei gewiefter Auslegung der Open Source Lizenzen im letzten Sinne nicht dazu verpflichtet wären?
- 23. Juli 2012
- kreincke
- OSLiC
Jetzt ist es also wirklich da – das Open Source License Compendium – in einer ersten Durchstichsversion 0.4. Wie auf dem Open Source Forum der BitKom Ende Juni in Berlin versprochen und in einer OSLiC Präsentation skizziert, ist das OSLiC Anfang Juli in einer Version veröffentlicht worden, anhand derer man – über das konkrete Beispiel ‘BSD-Lizenz’ – erkennen kann, wie es später einmal für viele Lizenzen verwendet werden soll: Kapitel 6 definiert die Kategorien, über die die Open Source Use Cases spezifziert werden. Kapitel 7 bietet den dazu passenden Fragebogen und eine Taxonomie, um über die Antworten den je relevanten Open Source Use Case zu finden. Und Kapitel 8.2 bietet für die Use Cases die BSD spezifischen TO-DO-Listen, die man nur abarbeiten muss, um sicher zu sein, dass man sich lizenzkonform verhält.
Nun gut, es ist erst die Version 0.4. Und die BSD-Lizenz gehört auch nicht unbedingt zu den kompliziertesten Lizenzen. Insofern wird noch viel an Inhalt zu ergänzen sein. Aber so ist das eben, wenn man der OS Regel folgt – veröffentliche früh, veröffentliche viel: Dann fehlt in einem frühen Stadium eben noch viel. Und vieles ist vielleicht noch vorläufig. Aber dafür kann eben jeder mitdenken und mitarbeiten.
Und die Resonanz nach einer Woche ist ganz erstaunlich. Hier mal ein paar Links
- 15. Juli 2012
- kreincke
- OSLiC
Das hatte wahrlich nicht lange gedauert! Nur wenige Stunden, nachdem ich ihn auf seine die merkwürdigen Meldungen beim Aufruf seiner Site aufmerksam gemacht hatte, schrieb Larry Rosen mir zurück, dass er leider schon darauf aufmerksam geworden sein:
I’m aware of the problem and am waiting for a DNS switch to fix it. The problem arose at my AT&T web hosting service and they have been less than helpful to fix it. So I’ve moved my website to another host and the change is taking place even now [...] Please check back again soon.
Und das habe ich am Wochen Ende getan. Mit Erfolg! Wer heute
- … in Google nach dem ‘oslbook’ sucht, wird nicht mehr gewarnt
- … den Link aus der deutschen Googletrefferliste heraus aufruft, wird direkt zum Ergebnis weitergeleitet
- .. den Link www.rosenlaw.com/oslbook.htm direkt aufruft, kommt direkt dahin
und zwar auf allen Browsern! Also eine absolut stimmige Angelegenheit…
- 26. März 2012
- kreincke
- OSI
Lawrence Rosen – auch genannt: Larry Rosen – ist einer der wirklich prominenten juristischen Experten in Sachen ‘Open Source Lizenzierung’. Viele seiner Artikel schwirren durchs Netz, fundiert und eingängig geschrieben.
Doch gibt es Merkwürdiges zu entdecken: Er hat nämlich auch ein Open Source Buch geschrieben und frei ins Netz gestellt, das “Open Source Licensing Book”. Allerdings werden wir, die wir es lesen wollen, momentan (2012-03-15 – 2012-03-17) mit bösen “Malware Warnings” geflutet, wenn wir den Link dahin aufrufen [...]
- 17. März 2012
- kreincke
- OSI
Nun also ist es da: ein Forum, um das Open Source License Compendium zu diskutieren.
Zentrale Informationsquelle ist natürlich zunächst einmal die englisch- und deutschsprachige OSLiC Homepage, gehostet unter GitHub. Zusammen mit den Quelldateien für das Kompendium im öffentlichen OSLiC GitHub Repository bildet die Homepageseiten die Basis für unsere collaborative Entwicklung: hier wird erläutert, was man dort herunterladen kann [...]
- 13. März 2012
- kreincke
- OSLiC
