-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo zusammen,
mitte nächster Woche würden wir gerne eine Analyse des aktuellen finalen Koalitionsvertrags [1] veröffentlichen.
Wie Ihr ja vielleicht schon aus den Medien oder Diskussionen in unseren Mailinglisten herausgehört habt, handelt es sich um einen recht schwammigen Koalitionsvertrag, wenn es um Freie Software, Offene Standards etc geht.
Das wollen wir natürlich kommentieren und darauf hinweisen, was in der letztendlichen Umsetzung verbessert werden muss, damit Deutschland in den nächsten vier Jahren endlich mal im europäischen Gesamtvergleich wieder aufholt in Sachen Freie Software.
Wir haben intern einige Stellen kommentiert und auf einem Pad [2] zusammengefasst. Ich würde Euch bitten, diese reine Sammlung an Bewertungen aus Sicht Freier Software zu überfliegen und eventuelle Anmerkungen und Verbesserungsvorschläge anzufügen. Diese Bewertung wird für die gesamte kommende Legislaturperiode wichtig sein, da dann dort gelistet ist, *was* die Bundesregierung machen will und *wie* sie das richtig umsetzen sollte.
Danke schonmal im Voraus und viele Grüße Max
[1] http://spd.de/aktuelles/112760/20131127_koalitionsvertrag_uebersicht.html [2] https://public.pad.fsfe.org/p/koav_pr_entwurf
- -- Max Mehl - Free Software Foundation Europe (FSFE) - fsfe.org Schönhauser Allee 6/7, 10119, Berlin | Phone: +49-30-27595290 About me: http://fsfe.org/about/mehl | Blog: blog.max-mehl.com Support us: http://fsfe.org/support | Homepage: max-mehl.com
Max Mehl max.mehl@fsfe.org wrote:
Wir haben intern einige Stellen kommentiert und auf einem Pad [2] zusammengefasst. Ich würde Euch bitten, diese reine Sammlung an Bewertungen aus Sicht Freier Software zu überfliegen und eventuelle Anmerkungen und Verbesserungsvorschläge anzufügen.
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Fabian
# Fabian Keil freebsd-listen@fabiankeil.de [ 06. Dez 2013 @ 12:53 +0100]:
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Als txt angehängt. Bitte deutlich markieren, wenn Du etwas ändern solltest, damit wir das dann einarbeiten können.
Viele Grüße Max
* Fabian Keil freebsd-listen@fabiankeil.de [131206 13:30, mID 4ae036d7.4630c54e@fabiankeil.de]:
Max Mehl max.mehl@fsfe.org wrote:
Wir haben intern einige Stellen kommentiert und auf einem Pad [2] zusammengefasst. Ich würde Euch bitten, diese reine Sammlung an Bewertungen aus Sicht Freier Software zu überfliegen und eventuelle Anmerkungen und Verbesserungsvorschläge anzufügen.
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Das JavaScript, das dort verwendet wird, ist Freie Software. Zusammenarbeit in Echtzeit im Browser wäre ohne JS wohl ein wenig schwierig…
Martin
Martin Gollowitzer gollo@fsfe.org, Fri, 6 Dec 2013 15:16:22 +0100:
- Fabian Keil freebsd-listen@fabiankeil.de [131206 13:30,
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Das JavaScript, das dort verwendet wird, ist Freie Software.
Der Satz kommt aber nicht aus eine Kampagne für Freie Software, sondern aus einer für offene Standards. Und in der Tat wird JavaScript häufig verwendet um den Einsatz tatsächlicher offener Standards zu umgehen - unabhängig davon, dass ECMA offen spezifiziert ist, die darin geschriebenen Programme sind es nicht. Da werden beispielsweise Webseiten via JS skaliert statt über ordentliche CSS rules, was Benutzern die Möglichkeit nimmt, die Darstellung ihren Bedürfnissen anzupassen, etc.
Zusammenarbeit in Echtzeit im Browser wäre ohne JS wohl ein wenig schwierig…
Hier geht es aber in der Tat zunächst um die Darstellung.
http://whiteboard.debian.net/ kriegt es beispielsweise hin einen View des Textes in einfachem HTML raus zu rendern. Dort, wo Echtzeitkolaboration keine Anforderung ist erlauben auch Wikis das gemeinsame Arbeiten an Dokumenten - auf Basis von standardisierten Darstellungs- und Eingabe-Mechanismen. Etherpad benutzt noch nicht mal Serverseitig portable Speicherformate.
Eine Unart die sich bei zeitgenössischen Webapplikationen da breit macht...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
# Paul Hänsch paul@fsfe.org [ 06. Dez 2013 @ 16:13 +0100]:
Martin Gollowitzer gollo@fsfe.org, Fri, 6 Dec 2013 15:16:22 +0100:
- Fabian Keil freebsd-listen@fabiankeil.de [131206 13:30,
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Das JavaScript, das dort verwendet wird, ist Freie Software.
Zusammenarbeit in Echtzeit im Browser wäre ohne JS wohl ein wenig schwierig…
Hier geht es aber in der Tat zunächst um die Darstellung.
http://whiteboard.debian.net/ kriegt es beispielsweise hin einen View des Textes in einfachem HTML raus zu rendern. Dort, wo Echtzeitkolaboration keine Anforderung ist erlauben auch Wikis das gemeinsame Arbeiten an Dokumenten - auf Basis von standardisierten Darstellungs- und Eingabe-Mechanismen. Etherpad benutzt noch nicht mal Serverseitig portable Speicherformate.
Eine Unart die sich bei zeitgenössischen Webapplikationen da breit macht...
Es ist interessant zu erfahren, dass Etherpad anscheinend nicht ganz unseren Ansprüchen von Freier Software und Offenen Standards entspricht. Ich denke, das sollten wir elaborieren und gegebenenfalls eine Alternative anbieten (Paul, wäre das vielleicht was für dich in den kommenden Monaten?).
Bis es so weit ist, könnten wir uns bitte darauf einigen, solange noch Etherpad und/oder Textfiles zu verwenden? Die eigene Infrastruktur ist von enormer Wichtigkeit, aber effiziente Zusammenarbeit ist es umso mehr.
Am Montag fange ich mit dem Schreiben einer Pressemitteilung an. Bis dahin würde ich mich noch sehr über Anmerkungen und konstruktives Feedback freuen. Vielleicht haben wir auch andere interessante Stellen im KoaV übersehen, die wir noch kommentieren sollten.
Danke und viele Grüße Max
- -- Max Mehl - Free Software Foundation Europe (FSFE) - fsfe.org Schönhauser Allee 6/7, 10119, Berlin | Phone: +49-30-27595290 About me: http://fsfe.org/about/mehl | Blog: blog.max-mehl.com Support us: http://fsfe.org/support | Homepage: max-mehl.com
Max Mehl max.mehl@fsfe.org, Fri, 06 Dec 2013 16:42:16 +0100:
Es ist interessant zu erfahren, dass Etherpad anscheinend nicht ganz unseren Ansprüchen von Freier Software und Offenen Standards entspricht. Ich denke, das sollten wir elaborieren und gegebenenfalls eine Alternative anbieten (Paul, wäre das vielleicht was für dich in den kommenden Monaten?).
Der Gedanke da im Laufe des nächsten Jahres was zu machen ging mir auch gerade durch den Kopf. Das erwähnte Whiteboard mit ein Wenig CSS oben dran ist da ein möglicher Ausgangspunkt.
Bis es so weit ist, könnten wir uns bitte darauf einigen, solange noch Etherpad und/oder Textfiles zu verwenden? Die eigene Infrastruktur ist von enormer Wichtigkeit, aber effiziente Zusammenarbeit ist es umso mehr.
Ich denke auch, das Etherpad ist erst mal völlig OK. Wir sollten nur mehr darauf achten, dass wir finale Dokumentenversionen (/signifikante Revisionen) noch irgendwie exportieren (copy/paste) und anderweitig öffentlich verlinkbar vorhalten. Z.B. im Fellowship-Wiki, jeweils mit einem Vermerk im Pad.
Und -wumms- seid ihr weit weg vom Thema und verstrickt in Pro-Contra-Diskussionen um JavaScript und dessen technischen Finessen oder Unnötigkeiten.
Sinnvoll? Ja.
In diesem Thread? Nein.
Mit fröhlichem Gruß
Robert Kehl
* Paul Hänsch paul@fsfe.org [131206 16:13, mID 20131206161312.7219610a@hellme.is-a-geek.org]:
Martin Gollowitzer gollo@fsfe.org, Fri, 6 Dec 2013 15:16:22 +0100:
- Fabian Keil freebsd-listen@fabiankeil.de [131206 13:30,
I cannot read your documents: "Sorry, you have to enable Javascript in order to use this."
Das JavaScript, das dort verwendet wird, ist Freie Software.
Der Satz kommt aber nicht aus eine Kampagne für Freie Software, sondern aus einer für offene Standards. Und in der Tat wird JavaScript häufig verwendet um den Einsatz tatsächlicher offener Standards zu umgehen
- unabhängig davon, dass ECMA offen spezifiziert ist, die darin
geschriebenen Programme sind es nicht. Da werden beispielsweise Webseiten via JS skaliert statt über ordentliche CSS rules, was Benutzern die Möglichkeit nimmt, die Darstellung ihren Bedürfnissen anzupassen, etc.
Das mag alles stimmen, aber was hat das jetzt mit dem Etherpad zu tun? Ich bin absolut kein Freund von JavaScript und bin der Meinung, dass man es auf normalen Webseiten überhaupt nicht einsetzen sollte. Bis heute bin ich einer derjenigen, die auf den FSFE-Webseiten am liebsten nichtmal Piwik hätten.
Zusammenarbeit in Echtzeit im Browser wäre ohne JS wohl ein wenig schwierig…
Hier geht es aber in der Tat zunächst um die Darstellung.
http://whiteboard.debian.net/ kriegt es beispielsweise hin einen View des Textes in einfachem HTML raus zu rendern. Dort, wo Echtzeitkolaboration keine Anforderung ist erlauben auch Wikis das gemeinsame Arbeiten an Dokumenten - auf Basis von standardisierten Darstellungs- und Eingabe-Mechanismen. Etherpad benutzt noch nicht mal Serverseitig portable Speicherformate.
Wenn es Euch nicht passt, hat die FSFE ein Wiki. Das Pad macht uns wesentlich mehr arbeit, aber wir wollten eine Freie Software anbieten, die Kollaboration in Echtzeit erlaubt, weil das einfach oft notwendig ist.
Eine Unart die sich bei zeitgenössischen Webapplikationen da breit macht...
Niemand zwingt hier irgendjemanden, es zu verwenden…
Liebe Grüße, Martin
p.s. Dein MUA ignoriert anscheinend Mail-Followup-To-Header, das nervt deutlich mehr als die Verwendung von JS im Etherpad…
Martin Gollowitzer gollo@fsfe.org, Fri, 6 Dec 2013 22:27:43 +0100:
Das mag alles stimmen, aber was hat das jetzt mit dem Etherpad zu tun?
Ich schreibe dir jetzt mal kein Essay darüber, an welchen präzisen stellen im Code Etherpad JavaScript-Mechanismen einsetzt um Dinge tun, die mit Hilfe offener Standards besser realisiert wären.
Warum die Entwickler ihre jeweilige Vorgehensweise gewählt haben ist auch relativ unumstritten - häufig ist es einfacher Dinge schnell in JS gerade zu hacken, besonders wenn man dadurch bei der gleichen Computersprache bleiben kann, in dem der Bulk des Projektes schon geschrieben ist.
Fabian war nun aber nicht in der Lage die Seite zu *sehen* obwohl die gelieferte Zusatzfunktionalität (das kollaborative Editieren) von Etherpad bis dahin noch gar nicht seinen Anwendungszweck umfasste. Normalerweise sind die Verfahren, über die ein Webbrowser einen Text anzeigt doch recht zugänglich. In diesem Falle offensichtlich nicht. Insofern meine ich, dass Fabians Kritik sehr wohl berechtigt war und das zu unterstreichen war der Kern meiner ursprünglichen Mail. Ich hoffe das reicht um auf deine Nachfrage einzugehen.
Ich bin absolut kein Freund von JavaScript und bin der Meinung, dass man es auf normalen Webseiten überhaupt nicht einsetzen sollte. Bis heute bin ich einer derjenigen, die auf den FSFE-Webseiten am liebsten nichtmal Piwik hätten.
Dann habe ich dir heute ja möglicherweise ein weiteres Argument geliefert, um deinen Standpunkt zu untermauern.
Wenn es Euch nicht passt, hat die FSFE ein Wiki.
Und jetzt haben wir das beide gesagt. Und doch warst du keinen Tick hilfreicher, weil du auch die URL vergessen hast: http://wiki.fsfe.org/ - Anders als das Etherpad ist das glaube ich nur für Fellows editierbar.
Das Pad macht uns wesentlich mehr arbeit, aber wir wollten eine Freie Software anbieten, die Kollaboration in Echtzeit erlaubt, weil das einfach oft notwendig ist.
Gut, und diese Lösung arbeitet eben an Standards vorbei. Du hast begründet, warum wir sie trotzdem haben. Jetzt schreib mal was konstruktives dazu wie wir die Situation weiter verbessern. Darum soll es doch hier gehen.
Eine Unart die sich bei zeitgenössischen Webapplikationen da breit macht...
Niemand zwingt hier irgendjemanden, es zu verwenden…
Eben doch! Das war ja gerade der Punkt. Fabian war nicht in der Lage sich an dem Gespräch auf der ML zu beteiligen, weil er dazu in der Lage hätte sein müssen, das Etherpad zu lesen. Und jetzt sag bloß nicht, niemand zwingt ihn, das zu lesen, oder überhaupt einen Computer zu verwenden. Dass er beides ohne Probleme können soll setzen wir voraus.
Aufgrund der Schnittstellen, dem Dokumentationsumfang und den Datenformaten die Etherpad verwendet kannst nun auch nicht ohne weiteres das Produkt wechseln um die Informationen dann doch irgendwie wahrzunehmen. Das wäre aber der Kerngedanke von offenen Standards und an deren Verbreitung liegt uns.
Auf das Problem sollten wir eingehen, und allein der Hinweis, dass Etherpad ja irgendwie Freie Software ist, und dass man für einen Teil unserer Anforderungen JavaScript braucht wird dem meiner Meinung nach nicht gerecht.
p.s. Dein MUA ignoriert anscheinend Mail-Followup-To-Header
Nein, mein MUA arbeitet korrekt. *Ich* ignoriere Follow-Up-Header weil ich der Konfiguration und dem Verhalten von Mailinglistensoftware grundsätzlich nicht vertraue. Das hat sich häufig genug als begründet erwiesen.
das nervt deutlich mehr als die Verwendung von JS im Etherpad…
Ich bin zuversichtlich, dass dein UA die Mail trotzdem anzeigt.
Hallo,
"Paul Hänsch" paul@fsfe.org schrieb:
Gut, und diese Lösung arbeitet eben an Standards vorbei. Du hast begründet, warum wir sie trotzdem haben. Jetzt schreib mal was konstruktives dazu wie wir die Situation weiter verbessern. Darum soll es doch hier gehen.
Hier geht's um Antworten auf den Koalitionsvertrag. Wer an der Website und der eingesetzten Software mitmachen möchte ist auf web@ gut aufgehoben: http://fsfe.org/contribute/web/web.de.html Siehe auch http://fsfe.org/contribute/contribute.de.html
Viele Grüße Michael
* Paul Hänsch paul@fsfe.org [131207 00:40, mID 20131207003935.18df4d98@hellme.is-a-geek.org]:
Martin Gollowitzer gollo@fsfe.org, Fri, 6 Dec 2013 22:27:43 +0100:
Das mag alles stimmen, aber was hat das jetzt mit dem Etherpad zu tun?
Ich schreibe dir jetzt mal kein Essay darüber, an welchen präzisen stellen im Code Etherpad JavaScript-Mechanismen einsetzt um Dinge tun, die mit Hilfe offener Standards besser realisiert wären.
Danke. Hättest Du es geschrieben, wäre es ohnehin Zeitverschwendung gewesen, da ich kein Etherpadentwickler bin.
Warum die Entwickler ihre jeweilige Vorgehensweise gewählt haben ist auch relativ unumstritten - häufig ist es einfacher Dinge schnell in JS gerade zu hacken, besonders wenn man dadurch bei der gleichen Computersprache bleiben kann, in dem der Bulk des Projektes schon geschrieben ist.
Diese Herangehensweise kann ich durchaus verstehen. Problematisch wird es ja vor allem dann, wenn der Code nicht mehr verständlich ist. Ob das bei Etherpad so ist, kann ich nicht beurteilen.
Fabian war nun aber nicht in der Lage die Seite zu *sehen* obwohl die gelieferte Zusatzfunktionalität (das kollaborative Editieren) von Etherpad bis dahin noch gar nicht seinen Anwendungszweck umfasste. Normalerweise sind die Verfahren, über die ein Webbrowser einen Text anzeigt doch recht zugänglich. In diesem Falle offensichtlich nicht. Insofern meine ich, dass Fabians Kritik sehr wohl berechtigt war und das zu unterstreichen war der Kern meiner ursprünglichen Mail. Ich hoffe das reicht um auf deine Nachfrage einzugehen.
Ich erinnere mich nicht, Fabians Kritik als nicht berechtigt bezeichnet zu haben. Allerdings muss ich gestehen, dass in meinen Augen das Anzeigen des Inhalts nicht die Hauptfunktion ist, sondern das Editieren (was jetzt aber nicht heißen soll, dass es nicht schön wäre, wenn das ohne JS ginge). Wenn die Alternative zu Etherpad ist, dreihundert Versionen des Textes per E-Mail hin- und herzuschicken, sehe ich aber auf jeden Fall einen gewissen Vorteil darin, JS im Browser zu aktivieren.
Ich bin absolut kein Freund von JavaScript und bin der Meinung, dass man es auf normalen Webseiten überhaupt nicht einsetzen sollte. Bis heute bin ich einer derjenigen, die auf den FSFE-Webseiten am liebsten nichtmal Piwik hätten.
Dann habe ich dir heute ja möglicherweise ein weiteres Argument geliefert, um deinen Standpunkt zu untermauern.
:)
Das Pad macht uns wesentlich mehr arbeit, aber wir wollten eine Freie Software anbieten, die Kollaboration in Echtzeit erlaubt, weil das einfach oft notwendig ist.
Gut, und diese Lösung arbeitet eben an Standards vorbei. Du hast begründet, warum wir sie trotzdem haben. Jetzt schreib mal was konstruktives dazu wie wir die Situation weiter verbessern. Darum soll es doch hier gehen.
Ich bin Arzt, kein Betatester [1].
[1] Soll heißen: Ich bin kein Etherpadentwickler, siehe auch http://www.janko.at/Humor/Microsoft/Star%20Trek%202.htm
Liebe Grüße, Martin
* Paul Hänsch paul@fsfe.org [131207 00:40, mID 20131207003935.18df4d98@hellme.is-a-geek.org]:
p.s. Dein MUA ignoriert anscheinend Mail-Followup-To-Header
Nein, mein MUA arbeitet korrekt. *Ich* ignoriere Follow-Up-Header weil ich der Konfiguration und dem Verhalten von Mailinglistensoftware grundsätzlich nicht vertraue. Das hat sich häufig genug als begründet erwiesen.
Im Normalfall wird dieser Header *nicht* von der Mailinglistensoftware gesetzt. Ein korrekt konfigurierter Mailman wird weder MFT- noch Reply-To-Header setzen. Der MFT-Header wird vom Absender (in diesem Fall: Ich) gesetzt, damit er/sie Antworten auf die Nachricht nicht doppelt erhält. Selbst wenn die Mailingliste erkennt, dass der zusätzliche Empfänger schon auf der Liste ist und die Antwort daher nicht nochmal schickt, schlagen die empfängerseitigen Filter nicht zu, da die ML-spezifischen Header fehlen.
das nervt deutlich mehr als die Verwendung von JS im Etherpad…
Ich bin zuversichtlich, dass dein UA die Mail trotzdem anzeigt.
Ja, aber nicht dort, wo ich sie mir erwarten würde und das ist genau der Grund, warum ich MFT-Header setze. Ich würde Dich daher bitten, Deine Einstellung zu überdenken. Und nein, der MFT-Header hat es leider nicht bis zum RFC geschafft. Trotzdem ist er im Prinzip ein offener Standard, und wenn ihn Dein MUA grundsätzlich beachtet, wäre es nett, wenn Du das auch tätest.
Liebe Grüße, Martin
* Paul Hänsch paul@fsfe.org [131207 00:40, mID 20131207003935.18df4d98@hellme.is-a-geek.org]:
Wenn es Euch nicht passt, hat die FSFE ein Wiki.
Und jetzt haben wir das beide gesagt. Und doch warst du keinen Tick hilfreicher, weil du auch die URL vergessen hast: http://wiki.fsfe.org/ - Anders als das Etherpad ist das glaube ich nur für Fellows editierbar.
Das stimmt zwar, aber ich vermute, die meisten auf der Liste kennen den URI und falls nicht, hätten sie ihn u.U. erraten. Für das Wiki gibt es Gast-Accounts [1], mit denen auch Nicht-Fellows Seiten bearbeiten können.
[1] https://wiki.fsfe.org/FSFE%20Fellowship%20Wiki?action=newaccount
Liebe Grüße, Martin
Hallo,
* Max Mehl max.mehl@fsfe.org [2013-12-05T13:18+0100]:
Wir haben intern einige Stellen kommentiert und auf einem Pad [2] zusammengefasst. Ich würde Euch bitten, diese reine Sammlung an Bewertungen aus Sicht Freier Software zu überfliegen und eventuelle Anmerkungen und Verbesserungsvorschläge anzufügen.
ad) Z. 190ff. 'andere EU-Staaten deutlich fortschrittlicher' Ein Mitglied des Edu-Teams aus den Niederlanden (Kevin Kijzer) sieht die Entwicklung in seinem Heimatland etwas anders. Insbesondere im Bildungsbereich ist dort wohl alles ziemlich rückständig (Silverlight u.a.). D.h. die Erwähnung der Niederlande als Positivbeispiel müsste nochmal überprüft werden. Sollte dies einer Überprüfung standhalten, sind wir (edu-team) sehr an den Beispielen zur weiteren Verwendung interessiert.
kind regards
Thomas Jensch edu-team coordinator
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Thomas,
# Thomas Jensch jensch@fsfeurope.org [ 10. Dez 2013 @ 16:21 +0100]:
ad) Z. 190ff. 'andere EU-Staaten deutlich fortschrittlicher' Ein Mitglied des Edu-Teams aus den Niederlanden (Kevin Kijzer) sieht die Entwicklung in seinem Heimatland etwas anders. Insbesondere im Bildungsbereich ist dort wohl alles ziemlich rückständig (Silverlight u.a.). D.h. die Erwähnung der Niederlande als Positivbeispiel müsste nochmal überprüft werden. Sollte dies einer Überprüfung standhalten, sind wir (edu-team) sehr an den Beispielen zur weiteren Verwendung interessiert.
Das ist interessant zu wissen, danke! Momentan sieht dieser Satz folgendermaßen aus:
Dabei könnte Deutschland schon heute von der Erfahrung seiner unmittelbaren EU-Nachbarn lernen. Die Niederlande etwa stehen im E-Government-Index der UN [1] europaweit an oberster Stelle, während Deutschland im EU-Vergleich auf Platz 10 rangiert. Dort können etwa Steuererklärungen auch nativ auf GNU/Linux-Systemen ausgefüllt werden, wogegen sich deutsche Behörden immer noch stemmen.
Dieser E-Government-Index scheint nach dem Überfliegen vor allem Wert auf Bürgerverwaltung zu legen, also das Ausfüllen von Formularen, Kommunikation mit Behörden und so weiter. Einem anderen Paper zufolge sind die Niederland aber bei ihrer "Open-Source-Strategie" (sic) nicht die fortschrittlichsten in der EU, was wohl Kevins Erfahrungen näher kommen würde. Im Zusammenhang mit der Elster-Debatte ist NL allerdings ein Positivbeispiel und das ist aufgrund seiner medialen Brisanz schon wichtig zu erwähnen. Wenn es um generelles geht, sind u.a. Frankreich und Schweden sicherlich auf einem besseren Weg.
Ich hoffe, das hat die Gründe hinter der Erwähnung etwas näher erläutert. Wenn du aber noch ein EU-Land kennst, welches als Vorreiter in Sachen FS im Bildungssektor dienen kann (inkl einer Quelle), dann würde ich das auf jeden Fall auch gerne mit reinnehmen.
Danke und viele Grüße Max
[1] https://www.un.org/en/development/desa/publications/connecting-governments-t...
- -- Max Mehl - Free Software Foundation Europe (FSFE) - fsfe.org Schönhauser Allee 6/7, 10119, Berlin | Phone: +49-30-27595290 About me: http://fsfe.org/about/mehl | Blog: blog.max-mehl.com Support us: http://fsfe.org/support | Homepage: max-mehl.com