Inhaltsverzeichnis
Nachrichten
Eine Übersicht über die Blogosphäre im KvFG Netz erhälst Du hier: http://kvfg.net/blogs/blogbersicht/
2021-06-26 T450 Bullseye
Bald nach dem 17.07.2021 wird Debian 11 erscheinen („Bullseye“) und das bisher auf den Corona-Laptops eingesetzte 10er („Buster“) ersetzen.
- Wer sich das Upgrade selbst zutraut soll es selbst machen. Aktuelle Infos hier: https://www.debian.org/ Ein Backup der eigenen Daten im Vorfeld ist zu empfehlen.
- Wer es sich nicht zutraut: Eine Möglichkeit zur geführten Installation von Debian 11 befindet sich in der Vorbereitung und wird dann in der Schule zur Verfügung stehen (Informationen zu Details folgen). Diese Installationsroutine plättet alles (!) auf der Festplatte, so dass auch hier ein Backup der eigenen Daten angeraten erscheint.
- Und wer nichts tut und einfach abwartet? Der kann Glück haben und bleibt bei 10 … oder Glück haben und landet automagisch bei 11 … oder Pech haben und landet irgendwo zwischen den beiden Versionen im Nirvana und guckt dann auf individuell zusammengestellte Fehlermeldungen, so dass dann nix mehr geht - und nix anderes übrig bleibt, als 2. (und evtl. hat Mensch dann ja auch ein Backup).
Behaltet diese Nachrichtensektion im Blick.
2020-08-27 T450 "Corona Laptops"
Im Bereich KvFG-Netz ist eine Seite zu unseren Lenovo T450 erschienen. Hintergrundinformationen hat es hier: https://codeberg.org/dowel/installbox
2019-01-03 Changelog
Die Veränderungen und Neuerungen in der KvFG Cloud aus den vergangenen Wartungsrunden:
- https://home.kvfg.eu bindet das schulische Tausch- und das eigene Homeverzeichnis von ServerG nun automatisch beim Login ein. Damit haben alle SuS und LuL über diesen Server ohne eigene Konfigurationsanstrengungen direkten Zugriff auf die Daten auf dem Schulserver „ServerG“: Daten können von zu Hause ins Schulnetz geladen oder von zu Hause aus dem Schulnetz abgerufen werden;
- das Online-Officepaket in der nextCloud unter https://home.kvfg.eu wurde aktualisiert. Es erlaubt weiterhin (und das schon seit 2015) die gemeinsame und gleichzeitige Arbeit mehrerer Benutzer an Präsentationen, Tabellen und Textdokumenten direkt im Browser, wenn das Dokument geteilt wurde;
- alle unsere Moodles (https://www.kvfg.net https://www.kvfg.org/moodle und https://schulealswelt.de) sind bei Version 3.6 angekommen. Das https://www.kvfg.net Moodle erlaubt die Integration von Dateien, die über https://home.kvfg.eu erreichbar sind, in Moodle. Man muss diese also nicht zuerst herunter- und dann wieder hochladen, sondern kann diese mit dem Filepicker nach einmaliger Anmeldung am Dienst direkt auswählen;
- alle Wordpresse sind auf Version 5 angekommen und alle Plugins sowie Themes wurden aktualisiert. Aktuell kann nur der Classic Editor verwendet werden, was wirklich kein Verlust ist. Details zu den bestehenden Problemen mit dem neuen Blockeditor „Gutenberg“ stehen auf der Startseite unseres Blogsystems unter https://kvfg.net/blogs
- unsere nextCloud Instanzen unter https://home.kvfg.eu (LuL und SuS, Zugriff auf Home und Tausch) und https://cloud.kvfg.de (LuL) wurden - ebenso wie deren Plugins - aktualisiert;
- auch der Webmailer für die SuS unter https://webmail.kvfg.eu ist aktualisiert;
Änderungen am Unterbau unserer Server und VMs:
- die VM für unser Umfragesystem Limesurvey (https://www.karlvonfrischgymnasium.de), die Homepage (https://www.kvfg.de) und die LuL-Cloud (https://cloud.kvfg.eu) wurden aktualisiert. Wir nutzen dort nun PHP 7.2, auf einem Ubuntu 18.04 Server. Hier virtualisieren wir mit LXC;
- die Domains https://www.kvfg.net und https://www.kvfg.org liegen auf einer neuen VM (und diese auf einem komplett frischen Server mit SSDs für die Betriebsystempartitionen aller VMs). Diese VM läuft nun unter Debian 9 und bietet ebenfalls PHP 7.2. Hier virtualisieren wir mit Xen;
Ausstehend:
- der Mailserver mail.lehrerpost.de ist noch nicht auf seine neue Plattform umgezogen. Dies erfolgt aber zeitnah in den kommenden Tagen;
Eine Übersicht über unser komplettes Netz (Cloud und intern) bietet diese Seite hier:
CODE Experiment auf cloud.kvfg.de beendet
Mehr als ein Jahr lang hatte ich für die nectCloud der Kolleg/innen unter https://cloud.kvfg.de ein eigenes Collabora Office (CODE) auf einer weiteren VM gepflegt. In den Logs gab es aber außer meinen eigenen Einträgen nix, was darauf hingedeutet hätte, dass das einer außer mir verwendet. Angesprochen worden bin ich darauf auch nie. Bugreports gab es auch keine.
Also kommt das Ding nun in die Tonne.
Die Seite zu nextCloud habe ich schon angepasst.
Wer ein Online-Office (gelegentlich) braucht: CODE steht weiterhin auf https://home.kvfg.eu zur Verfügung. Wer das nutzen will, kann seine Dateien ja dahin umziehen oder den Speicher auf cloud.kvfg.de dort einbinden. Die VM („Rusty“) für home.kvfg.eu läuft auf dem VM-Host „Kneipe“, steht im Haus und flutscht deswegen nicht ganz so hübsch wie die VMs bei Hetzner, aber für die gelegentlichen Edits wird es reichen (müssen).
Quellen- und Lizenzangaben
Eines der zentralen Missverständnisse von digital natives beim Umgang mit Online-Quellen ist, dass diese meinen, sie hätten beim Zugriff auf „freie“ Bilder ganz besondere Freiheiten. Meist tritt dieses Missverständnis im Zusammenhang mit der Entnahme von Bildern aus der Wikimedia auf und kann sich auch mit anderen Missverständnissen mischen. Im Folgenden deswegen einige Klärungen.
1. Grundlagen
Verantwortlich für eine Seite hier im KvFG-Wiki ist die Person, die die jeweilige Seite erstellt hat bzw. (im Falle von Schüler/innen) die betreuende Lehrkraft, die alle SuS-Werke zu sichten und freizugeben hat.
Im KvFG-Wiki gilt mit gutem Grund und ohne Ausnahme die Regel, dass alle Lizenz- und Quellenangaben immer in der vom Rechteinhaber geforderten Form direkt am eingebundenen Werk zu machen sind.
Damit es bezüglich dieser Regel kein Vertun gibt, sei betont, dass es keinerlei Interpretationsspielraum gibt, was unter „direkt am eingebundenen Werk“ zu verstehen sein könnte. „Direkt“ heißt „direkt“ in der Form, dass es keinen Abstand zwischen Bild und Quellen- sowie Lizenzangaben gibt. Also: keine technischen Spielchen (z.B. Overlays oder Fußnoten etc. pp.) und keine Quellenangaben am Seitenende oder gar getrennte Quellenseiten … oder was Euch sonst noch einfallen könnte.
Das Problem ist dabei weniger, dass man vor einem verständnisvollen Richter nicht für die eigene Interpretation von „direkt“ Zustimmung bekommen würde, sondern dass der Schulträger schlicht das Prozessrisiko scheuen wird. Keine Behörde zieht gerne vor Gericht (das kann nämlich verdammt teuer werden) - und erst Recht nicht, wenn es um die Interpretation von ganz offensichtlich transparent gemachten Regeln geht.
Was ich leider auch noch einmal besonders deutlich machen muss: Aus der Verantwortlichkeit der Autor/innen für die publizierten Inhalte folgt kein Anspruch auf Begleitung durch Dritte. Die Bereitschaft, sich in die Publikationstechnik einzuarbeiten bringt mit sich, dass man gelegentlich das Handbuch zu Dokuwiki konsultieren muss oder sich auch über die Foren von Dokuwiki etc. pp. schlau macht, wenn man komplexere Fragen hat.
Weiter muss man sich als Autor/in in die genutzten Lizenzen und deren Bedingungen einlesen. Creative Commons Lizenzen verlangen z.B. durch die Bank, dass auf deren ausführliche Lizenztexte verlinkt wird.
Zuletzt sei darauf hingewiesen, dass jeder Rechteinhaber einen Anspruch auf Beachtung der von ihm gestellten Bedingungen für die Nutzung seiner Werke hat. Wer dessen Bedingungen ablehnt oder nicht erfüllen kann, muss selbst tätig werden und z.B. die benötigten Bildwerke eigenhändig erstellen.
2. Verzicht
Die offensichtlichste Möglichkeit, mit technischen und / oder rechtlichen Problemen umzugehen, ist der Verzicht auf die Einbindung eines Bildes in das eigene Werk. Wem es also nicht möglich ist, die grundlegenden Anforderungen umzusetzen, muss es bleiben lassen.
Das eigene Werk mag dann etwas „spaßbefreit“ und textlastig wirken. Aber darauf kommt es nicht an, denn erstens sind Wikiseiten immer textlastig und zweitens ist Spaß kein Kriterium, das in der Schule etwas gilt (sondern Freude) - oder vor Gericht.
3. Verlinkung
Alternativ zum Verzicht kann man immer auch einen schlichten Link nutzen. Das sieht dann konkret so aus:
Mein Text ist zu Katzenbildern.
Die technische Umsetzung dieser Lösung ist denkbar einfach:
Mein Text ist zu [[https://commons.wikimedia.org/wiki/File:Hauskatze_in_Abendsonne.jpg|Katzenbildern]].
4. Einbindung
Was die meisten Menschen jedoch haben wollen, ist die direkte Einbindung von Bildwerken ins eigene Werk. Die Wikimedia / -pedia liefert dazu auf den Vorschau- und Beschreibungsseiten von Bildern praktische Tools1) mit, die einem die Arbeit fast vollständig abnehmen - aber eben nur fast.
Üblich und von deutschen Gerichten aktuell2) meist akzeptiert ist die folgende Form der Quellen- und Lizenzangabe, sofern der Rechteinhaber nicht andere Vorgaben macht:
Name des Werkes von Name des Urhebers plus Angaben zum Rechteinhaber plus Lizenz mit Angabe der URL zur Lizenz via Quelle des Werkes mit Angabe der Quellen-URL
Verzichtet auf jeden Fall und ohne Ausnahme auf die Übernahme von Bildwerken aus der Wikipedia / -media ins KvFG-Wiki durch Uploads. Bindet das Bild von Extern ein.
Hintergrund ist hier, dass es einzelne Gerichtsentscheidungen gab, die sich auf die Medienseiten von Wikis bezogen statt auf die Inhaltsseiten. Selbst wenn auf den Inhaltsseiten die Quelle richtig angegeben wird - auf den der Medienseite kann diese dann fehlen! Schreibt außerdem die notwendigen Quellen- und Lizenzinformationen immer auch in den Caption-Teil der eingebundenen Bilder. Das sollte in den meisten Fällen sicher stellen, dass die Medienseiten von Dokuwiki diese Information ebenfalls bereit halten. Die Nebenwirkung ist, dass die Angaben in einem Overlay auftauchen, hält man die Maus über das Bild. Ein Overlay ist aber nie eine Lösung - siehe oben die Definition zu „direkt am eingebundenen Werk“.
Googlet den Rechteinhaber des von Euch genutzten Werkes zusammen mit Begriffen wie „Urheberrecht“, „Abmahnung“ oder „Anwalt“ etc.. Sofern ihr fündig werdet: Finger weg von dessen Werken. Die Wahrscheinlichkeit ist zu hoch, dass es sich um einen der ganz besonderen Menschen handelt, die die Wikipedia für sich als Abmahnfalle nutzen.
Darüber hinaus sei jedem Autor hier im Wiki dringend empfohlen, die Entnahme von Werken Dritter von anderen Seiten zu dokumentieren - z.B. durch Druck der Quellseite in ein PDF-Dokument. Das kann so aussehen wie hier zum im Folgenden verwendeten Katzenbild:
A. In zwei Absätzen
Die einfachste Art und Weise der Einbindung erfolgt über die Nutzung von zwei getrennten Absätzen - einer für die Einbindung des Bildes selbst - und ein zweiter für die Quellen- und Lizenzangabe. Das sieht dann so aus
Hauskatze in Abendsonne von Sebastianjude at the German language Wikipedia GFDL or CC-BY-SA-3.0, via Wikimedia Commons
und im Quelltext dann wie folgt:
{{https://upload.wikimedia.org/wikipedia/commons/0/09/Hauskatze_in_Abendsonne.jpg?300|Sebastianjude at the German language Wikipedia [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons}} Hauskatze in Abendsonne von Sebastianjude at the German language Wikipedia [[http://www.gnu.org/copyleft/fdl.html|GFDL]] or [[http://creativecommons.org/licenses/by-sa/3.0/|CC-BY-SA-3.0]], via [[https://commons.wikimedia.org/wiki/File:Hauskatze_in_Abendsonne.jpg|Wikimedia Commons]]
Der große Vorteil dieser sehr simplen Art der Einbindung ist, dass man sich nicht von Plugins abhängig macht, sondern auf die in Dokuwiki eingebauten Funktionen vertraut. Die werden gepflegt. Bei Plugins ist das nicht immer der Fall.
B. Plugin Caption
Etwas mehr Integration von Bild und notwendigen Angaben erlaubt das Plugin Caption. Das sieht dann so aus:
![Sebastianjude at the German language Wikipedia [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons Sebastianjude at the German language Wikipedia [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons](/wiki/lib/exe/fetch.php?w=300&tok=d4aa8f&media=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F09%2FHauskatze_in_Abendsonne.jpg)
Der Wiki-Quelltext für diese Darstellungsform ist dieser hier:
<figure> {{https://upload.wikimedia.org/wikipedia/commons/0/09/Hauskatze_in_Abendsonne.jpg?300|Sebastianjude at the German language Wikipedia [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], via Wikimedia Commons}} <caption> Hauskatze in Abendsonne von Sebastianjude at the German language Wikipedia [[http://www.gnu.org/copyleft/fdl.html|GFDL]] or [[http://creativecommons.org/licenses/by-sa/3.0/|CC-BY-SA-3.0]], via [[https://commons.wikimedia.org/wiki/File:Hauskatze_in_Abendsonne.jpg|Wikimedia Commons]] </caption> </figure>
5. Schlussbemerkung
Bei der Betrachtung der Lösungen auf dieser Seite ist immer die Hierarchie der Werte im Hinterkopf zu haben. Es kann schon sein, dass keine der angeführten Darstellungsformen die spontane Zustimmung findet, weil man sich selbst für die eigene Seite etwas ganz anderes vorgestellt hat. Aber das Urheberrecht sticht eben Geschmacksfragen.
Außerdem gibt es für Geschmacksfragen ebenfalls Lösungen, über die es nachzudenken gilt. Dabei sollte man aber von Beginn an bedenken, dass die folgenden Lösungen Auswirkungen auf alle Wiki-Seiten haben und vor allem auch auf die Pflege dieser Installation. Die notwendigen Absprachen muss man „einpreisen“.
- Viele Wünsche lassen sich über spezielle Stylesheets regeln. In diesem Fall darf man sich in CSS einarbeiten - und an der einen oder anderen Stelle auch in den PHP-Quelltext von Dokuwiki oder eines anzupassenden Plugins. Dafür kommt man aber - im Vergleich mit allen anderen Lösungen - zügiger an's Ziel.
- Lassen sich die eigenen Wünsche nicht über CSS lösen, dann kann man sich ein fehlendes Plugin für Dokuwiki, das dann genau das tut, was man will, durchaus auch selbst schreiben. Die Schnittstellen sind offengelegt, die meisten Plugins sind Quelloffen und Dokuwiki hat seinen Code ebenfalls publiziert und freigegeben. Also PHP lernen und los.
- Oder man sucht sich jemanden, der das macht. Dabei muss man darauf achten, dass der Schreiber seinen Quellcode unter eine offene Lizenz stellt, will man nicht in die Falle laufen, dass die eigene Lösung in wenigen Jahren (z.B. mit einer neuen Dokuwiki Version) nicht mehr kompatibel ist. Nur durch die Freigabe des Quellcodes unter einer offenen Lizenz ist gewährleistet, dass andere die Arbeit fortsetzen können. Das kann z.B. ein Schüler sein - oder eine bezahlte Kraft. Die Kontaktaufnahme mit den Menschen hinter schon bestehenden Plugins oder auch den Machern von Dokuwiki lohnt sich. Evtl. hat man ja auch Glück und der höflich formulierte Feature-Request auf den Github Seiten des Plugin-Schreibers löst bei dessen nächster Version schon alle Probleme.
- Oder man stellt für sich fest, dass Dokuwiki aktuell nicht die Lösungen bietet, die man sucht, und weicht dann auf etwas anderes aus. Wir haben z.B. Blogs unter Wordpress im KvFG Netz, die andere Darstellungen unterstützen.
In jedem Fall sollte man sich klar machen, dass kein Publikationstool eine Malunterlage ist: Jedes CMS (Dokuwiki, Wordpress, Moodle … Contineo, Typo3) muss den Nutzern Vorgaben machen, wie die Dinge aussehen, sonst läuft die Site komplett auseinander und der Gesamteindruck ist der von Chaos.
Wer aber CMS-Regeln für sich nicht gelten lassen will, muss pures HTML mit integriertem CSS nutzen. Da kann man machen was man will - für jede Seite anders. Das ist dann die Malunterlage für's Web. Das Ergebnis sieht aber aus wie die privaten Internetseiten aus den 90ern.