|
|
| (Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| ← [[DGB 2. Klasse|Digitale Grundbildung 2. Klasse]] | | ← [[DGB 2. Klasse|Digitale Grundbildung 2. Klasse]] |
|
| |
|
| Die Beschäftigung mit geistigem Eigentum beim Programmieren und Remixen unterstützt die Schülerinnen und Schüler dabei, fremde digitale Beiträge respektvoll zu nutzen, rechtliche Rahmenbedingungen zu beachten und eigene Programme mit korrekten Quellen- und Lizenzangaben verantwortungsvoll zu veröffentlichen.
| | Programme und digitale Projekte bestehen häufig aus vielen Teilen: eigenem Code, übernommenen Bausteinen, Bildern, Figuren, Sounds oder Vorlagen. Beim '''Remixen''' wird Bestehendes verändert oder kombiniert. Dabei müssen Herkunft, Lizenz und eigene Änderungen nachvollziehbar bleiben. |
|
| |
|
| == 13.1 Lernziele == | | == Lehrplanbezug == |
| | |
| | {| class="wikitable" |
| | ! Bereich |
| | ! Zuordnung |
| | |- |
| | | '''Kompetenzbereich''' |
| | | Produktion |
| | |- |
| | | '''Perspektiven''' |
| | | G, I |
| | |- |
| | | '''Schwerpunkt''' |
| | | Geistiges Eigentum und Urheberrechte beim Erstellen oder Remixen von Programmen |
| | |- |
| | | '''Kompetenz''' |
| | | Eigene und fremde Bestandteile digitaler Projekte unterscheiden, Nutzungsrechte prüfen und übernommene bzw. veränderte Bestandteile transparent dokumentieren. |
| | |} |
| | |
| | == Lernziele == |
|
| |
|
| Die Schülerinnen und Schüler können: | | Die Schülerinnen und Schüler können: |
|
| |
|
| * erklären, was mit geistigem Eigentum im Zusammenhang mit Programmen, Quellcode, Grafiken, Sounds und digitalen Medien gemeint ist. | | * geistiges Eigentum im Zusammenhang mit Code und digitalen Medien erklären; |
| * unterscheiden, welche Teile eines Programms selbst erstellt und welche von anderen übernommen wurden. | | * eigene und fremde Bestandteile eines Projekts unterscheiden; |
| * erklären, warum fremder Code, Bilder, Figuren, Sounds oder Bausteine nicht einfach ohne Erlaubnis genutzt werden dürfen. | | * erkennen, dass Quellcode, Grafiken, Sounds und andere konkrete Werke geschützt sein können; |
| * zwischen erlaubter Nutzung, eingeschränkter Nutzung und unerlaubter Übernahme unterscheiden. | | * Remix als Bearbeitung bzw. Kombination vorhandener Materialien beschreiben; |
| * erkennen, dass auch beim Remixen von Programmen Rechte anderer beachtet werden müssen.
| | * erlaubte, eingeschränkte und unklare Nutzungssituationen unterscheiden; |
| * offene und geschlossene Lizenzen im Zusammenhang mit Programmen und digitalen Inhalten unterscheiden. | | * offene und geschlossene Lizenzen bei Programmprojekten vergleichen; |
| * passende Quellen- und Urheberangaben bei übernommenen oder bearbeiteten Bestandteilen eines Programms machen. | | * Quellen-, Urheber- und Lizenzangaben für übernommene Bestandteile erstellen; |
| * erläutern, warum Namensnennung, Lizenzhinweise und Herkunftsangaben wichtig sind. | | * eigene Änderungen an einem übernommenen Projekt dokumentieren; |
| * eigene Programme so dokumentieren, dass fremde und eigene Anteile nachvollziehbar erkennbar sind. | | * bei Gruppenprojekten Beiträge und Herkunft transparent halten; |
| * begründet entscheiden, welche Materialien oder Programmteile für ein Schulprojekt rechtlich und fair genutzt werden dürfen.
| | * begründen, warum Namensnennung und Lizenzhinweise Fairness und Nachvollziehbarkeit fördern; |
| | | * bei fehlender oder unklarer Freigabe auf eigenes oder eindeutig lizenziertes Material ausweichen. |
| == 13.2 Lerninhalte ==
| |
|
| |
|
| Die Auseinandersetzung mit Urheberrechten beim Programmieren und Remixen macht deutlich, dass digitale Produkte meist aus vielen Bestandteilen bestehen und dass für Code, Bilder, Sounds, Figuren und Bausteine klare Regeln zur Nutzung, Bearbeitung und Weitergabe gelten. Geistiges Eigentum bedeutet, dass Ideen in ihrer bloßen Form zwar nicht geschützt sind, wohl aber konkrete Ausarbeitungen wie Quelltexte, Grafiken, Musikstücke, Animationen, Designs, Texte oder Figuren. Beim Programmieren betrifft das nicht nur das gesamte fertige Programm,
| | == Lerninhalte == |
|
| |
|
| sondern oft auch einzelne Bestandteile. Wer ein Spiel entwickelt, arbeitet möglicherweise mit selbst geschriebenem Code, aber auch mit fremden Sprites, Geräuschen, Hintergrundbildern oder Programmbausteinen. Deshalb reicht es nicht, nur das Gesamtprodukt zu betrachten. Entscheidend ist, aus welchen Teilen es besteht und woher diese stammen. Ein wichtiger Lerninhalt ist die Unterscheidung zwischen eigener Leistung und übernommener Arbeit.
| | === Programme sind zusammengesetzte Werke === |
|
| |
|
| Schülerinnen und Schüler sollen erkennen, welche Teile sie selbst entworfen und programmiert haben und welche auf Vorlagen, Bibliotheken, Bildern, Tutorials, Beispielcodes oder bereits vorhandenen Projekten beruhen. Gerade in Entwicklungsumgebungen wie Scratch oder ähnlichen Plattformen ist Remixing ein verbreitetes Vorgehen. Dabei wird ein bestehendes Projekt übernommen und verändert. Das ist didaktisch sinnvoll, aber nur dann verantwortungsvoll, wenn Herkunft und Urheber erkennbar bleiben und vorhandene Nutzungsbedingungen eingehalten werden. Bestandteile Quellcode, Grafik, Sprite, Sound, Text, Animation
| | Ein Spiel kann aus Programmcode, Figuren, Hintergrundbildern, Musik und Texten bestehen. Diese Bestandteile können unterschiedliche Urheberinnen, Urheber und Lizenzen haben. |
|
| |
|
| '''Nutzungsformen'''<br />
| | Darum genügt es nicht zu sagen „Das Projekt ist von mir“, wenn wesentliche Teile übernommen wurden. Eigene und fremde Anteile müssen unterscheidbar sein. |
| erstellen, übernehmen, anpassen, remixen, weitergeben, veröffentlichen
| |
|
| |
|
| Beim Remixen von Programmen geht es darum, vorhandene Projekte, Codes oder Medienbestandteile zu verändern und neu zusammenzustellen. Dieses Vorgehen ist in vielen Lernumgebungen üblich, weil es den Einstieg erleichtert und kreative Weiterentwicklung fördert. Gleichzeitig müssen dabei Rechte beachtet werden. Wenn ein Projekt ausdrücklich zum Remixen freigegeben ist, kann es weiterbearbeitet werden. Dennoch sollen Urheberinnen und Urheber genannt werden, damit sichtbar bleibt, auf welcher Arbeit das neue Produkt aufbaut. Ohne Quellenangabe entsteht der falsche Eindruck, alles sei vollständig selbst erstellt worden.
| | === Idee und konkrete Ausarbeitung === |
|
| |
|
| Auch bei Programmierprojekten gelten für unterschiedliche Bestandteile unterschiedliche Rechte. Selbst wenn ein Codeausschnitt offen nutzbar ist, kann ein eingebettetes Bild geschützt sein. Ein Spielsound kann unter anderen Bedingungen stehen als die verwendete Bibliothek. Ein Hintergrundbild aus dem Internet darf nicht automatisch in ein Spiel eingebaut werden, nur weil es frei auffindbar ist. Diese Unterscheidung ist wichtig, weil digitale Projekte oft mehrere Rechtsbereiche zugleich berühren. Schülerinnen und Schüler sollen deshalb lernen, nicht nur das Programm als Ganzes, sondern jeden übernommenen Teil kritisch zu prüfen.
| | Eine allgemeine Idee wie „ein Quiz über Planeten“ ist etwas anderes als ein konkreter Quelltext, ein gezeichnetes Sprite oder eine komponierte Musikdatei. Für den Unterricht ist wichtig, konkrete fremde Werke nicht einfach als eigene auszugeben. |
|
| |
|
| Projektquellen Tutorial, Beispielcode, Bibliothek, Bildarchiv, Sounddatei, Remixprojekt Prüffragen Wer hat es erstellt, Darf ich es nutzen, Darf ich es ändern, Muss ich es nennen Ein weiterer Schwerpunkt liegt auf offenen und geschlossenen Lizenzen. Manche Materialien und Codebestandteile dürfen unter bestimmten Bedingungen genutzt, verändert und weitergegeben werden. Andere sind nur sehr eingeschränkt oder gar nicht zur Übernahme freigegeben. Offene Lizenzen oder Plattformregeln können Remixing ausdrücklich erlauben, oft mit der Bedingung der Namensnennung.
| | Rechtliche Details können je nach Werk und Nutzung komplex sein; bei Schulprojekten schafft eine saubere Herkunftsdokumentation eine verlässliche Basis. |
|
| |
|
| Bei Open-Source-Software ist der Quellcode einsehbar und unter bestimmten Lizenzbedingungen nutzbar. Bei Creative-Commons- lizenzierten Bildern oder Sounds gelten je nach Lizenz unterschiedliche Regeln. Schülerinnen und Schüler sollen verstehen, dass offen nicht mit grenzenlos gleichzusetzen ist. Für den Unterricht ist besonders wichtig, wie Urheberrechte in Projekten korrekt angegeben werden. Wird ein fremdes Bild, ein Sound, ein Codebaustein oder ein ganzes Ausgangsprojekt
| | === Was bedeutet Remix? === |
|
| |
|
| genutzt, sollen Titel, Urheberin oder Urheber, Quelle und Lizenz möglichst nachvollziehbar genannt werden. In einem Scratch-Projekt kann dies in der Projektbeschreibung, in einem Kommentar oder in einer Quellenliste geschehen. In einem textbasierten Programm können Hinweise im Kommentarbereich des Codes stehen. In einer Präsentation zum Programmprojekt kann zusätzlich erklärt werden, welche Teile selbst erstellt und welche übernommen wurden. Dadurch wird das Projekt transparenter und fairer.
| | Beim Remix wird ein vorhandenes Projekt verändert, erweitert oder mit anderen Elementen kombiniert. Lernplattformen für Programmierung fördern solche Arbeitsformen teilweise ausdrücklich. |
|
| |
|
| Lizenzformen offen, eingeschränkt, proprietär, Open Source, Creative Commons, Plattformregel Pflichtangaben Titel, Urheber, Quelle, Lizenz, Änderungsvermerk, Projektlink Didaktisch hilfreich sind konkrete Beispiele. Ein selbst programmiertes Quiz mit eigenen Fragen und selbst gezeichneten Figuren gehört vollständig den Erstellerinnen und Erstellern. Wird jedoch ein fremdes Hintergrundbild eingebaut, muss dieses gesondert betrachtet werden. Ein Spiel, das aus einem vorhandenen Scratch-Projekt remixt wurde, braucht einen klaren Hinweis auf das Ursprungsprojekt.
| | Ob und unter welchen Bedingungen ein Remix erlaubt ist, hängt von der Lizenz oder Freigabe des Ausgangsmaterials ab. |
|
| |
|
| Ein Programm, das einen Codeausschnitt aus einem Tutorial übernimmt, sollte dies dokumentieren. Ein Musikstück aus dem Internet darf nicht einfach als Spielsound verwendet werden, wenn keine passende Nutzungserlaubnis vorliegt. Solche Fälle zeigen, dass Urheberrecht im Programmieren sehr praktisch und alltagsnah wird. Ebenso wichtig ist die Unterscheidung zwischen Inspiration und Übernahme. Wer die Idee eines Labyrinthspiels aufgreift, verletzt noch kein Urheberrecht. Wer aber die konkrete Grafik, den vollständigen Ablauf oder große Teile des Codes kopiert, übernimmt geschützte Ausarbeitungen.
| | === Offene und geschlossene Lizenzen === |
|
| |
|
| Diese Abgrenzung ist für Lernende oft schwierig, aber zentral. Sie hilft zu verstehen, dass Lernen an Vorbildern erlaubt und sinnvoll ist, während die ungekennzeichnete Übernahme fremder Ausarbeitung problematisch bleibt. Gute Praxis bedeutet daher: sich inspirieren lassen, aber Fremdes kenntlich machen und Nutzungsrechte prüfen. Ein weiterer Lerninhalt ist die Dokumentation eigener Arbeit. Schülerinnen und Schüler sollen in ihren Projekten sichtbar machen, was sie selbst beigetragen haben und an welchen Stellen sie auf vorhandenes Material zurückgegriffen haben.
| | Open-Source- und Creative-Commons-Lizenzen können bestimmte Nutzungen und Bearbeitungen erlauben. Die Bedingungen müssen gelesen und eingehalten werden. Bei proprietären oder ungekennzeichneten Materialien ist die Weiterverwendung häufig stärker eingeschränkt oder unklar. |
|
| |
|
| Das kann über Kommentare im Code, Quellenfelder, Projektbeschreibungen oder begleitende Dokumentationsblätter erfolgen. Diese Gewohnheit ist nicht nur rechtlich sinnvoll, sondern fördert auch sauberes Arbeiten, Nachvollziehbarkeit und Respekt gegenüber anderen Produzierenden. Beispiele Quiz, Spiel, Animation, App, Lernprogramm, Robotikprojekt Dokumentation Kommentar, Quellenliste, Projektbeschreibung, Hinweisfeld, Begleitblatt, Lizenztext Auch Fehler und problematische Praktiken sollen thematisiert werden. Dazu gehört, ein Projekt als vollständig eigen auszugeben, obwohl große Teile remixt wurden.
| | „Im Internet gefunden“ ist keine Lizenz. |
|
| |
|
| Problematisch ist ebenso die Nutzung fremder Bilder ohne Quellenangabe, das Kopieren von Code aus dem Internet ohne Prüfung der Lizenz oder das Übernehmen eines Tutorials Wort für Wort ohne Kennzeichnung. Solche Beispiele helfen dabei, typische Missverständnisse zu klären. Gerade weil digitales Kopieren technisch leicht möglich ist, braucht es eine bewusste Haltung zu Fairness, Transparenz und rechtlich sauberem Arbeiten. Für eine altersgerechte Perspektive ist wichtig, Urheberrecht nicht nur als Verbotssystem darzustellen. Die Rechte am geistigen Eigentum schützen kreative Leistung und machen
| | === Dokumentation von Quellen === |
|
| |
|
| zugleich durch offene Lizenzen geregeltes Teilen möglich. Schülerinnen und Schüler sollen verstehen, dass sie selbst ebenfalls Urheberinnen und Urheber ihrer Programme, Grafiken oder Sounds sein können. Wer eigene Arbeiten veröffentlicht, kann entscheiden, ob andere diese nur ansehen, weiterverwenden oder auch verändern dürfen. Dadurch entsteht ein aktiver Zugang: Rechte anderer achten und eigene Rechte bewusst gestalten.
| | Bei übernommenen Bestandteilen sollten mindestens Titel bzw. Bezeichnung, Urheber oder Projekt, Quelle und Lizenz festgehalten werden. Bei Änderungen sollte zusätzlich erkennbar sein, was verändert wurde. |
|
| |
|
| '''Fehlerquellen'''<br />
| | Solche Angaben können in einer Projektbeschreibung, einem Kommentar im Code, einer Quellenliste oder einem Abspann stehen. |
| fehlende Nennung, falsche Quelle, unerlaubte Kopie, unklarer Remix,
| |
|
| |
|
| Lizenzirrtum, Fremdmaterial
| | === Eigene und fremde Beiträge im Team === |
|
| |
|
| '''Haltungen'''<br />
| | Gruppenprojekte werden transparenter, wenn dokumentiert wird, wer welche Teile erstellt oder eingebracht hat. Das hilft nicht nur beim Urheberrecht, sondern auch bei Zusammenarbeit und Bewertung. |
| Fairness, Respekt, Transparenz, Sorgfalt, Verantwortung, Anerkennung
| |
|
| |
|
| Ein bedeutsamer Zusammenhang besteht zwischen Urheberrecht und Zusammenarbeit. In Gruppenprojekten muss geklärt werden, wer welchen Teil erstellt hat und welche externen Materialien eingebunden wurden. Wenn mehrere Personen an einem Spiel oder Programm arbeiten, sollte die Dokumentation festhalten, wer für Code, Grafik, Sound oder Test zuständig war. So lernen die Schülerinnen und Schüler auch innerhalb der eigenen Gruppe, Leistungen korrekt zuzuordnen und gemeinsame Produkte transparent zu beschreiben. Dies stärkt kooperatives Arbeiten und beugt Konflikten vor.
| | Versionsverläufe und Projektprotokolle können diese Nachvollziehbarkeit unterstützen. |
|
| |
|
| Schließlich sollen die Lernenden erkennen, dass ein rechtlich und ethisch verantwortungsvoller Umgang mit Programmen mehr umfasst als das bloße Vermeiden von Fehlern. Es geht darum, fremde kreative Arbeit wahrzunehmen, korrekt zu kennzeichnen, erlaubte Materialien bewusst auszuwählen und bei eigenen Projekten Offenheit und Schutz sinnvoll abzuwägen. Diese Kompetenz ist für Schule, digitale Kreativität und spätere Projektarbeit gleichermaßen bedeutsam. Gruppenaspekte Zuständigkeit, Mitwirkung, Kennzeichnung, Absprache, Nachvollziehbarkeit, Anerkennung
| | === Faire Remixkultur === |
|
| |
|
| '''Kernideen'''<br />
| | Remixen ist ein wichtiger Teil digitaler Kreativität. Fair wird die Praxis, wenn bestehende Arbeit respektiert, erlaubte Materialien gewählt, Urheber genannt und eigene Veränderungen sichtbar gemacht werden. |
| Rechte achten, Quellen nennen, Remix kennzeichnen, Offenheit prüfen, Eigenes
| |
|
| |
|
| schützen, fair handeln
| | Damit werden kreative Weiterentwicklung und Rechte anderer miteinander verbunden. |
|
| |
|
| === Weiterführende Links === | | == Aufgaben für den Unterricht == |
|
| |
|
| * creativecommons.org
| | === Eigene und fremde Bestandteile unterscheiden === |
| * creativecommons.org/licenses
| |
| * scratch.mit.edu
| |
| * opensource.org
| |
| * oerinfo.de
| |
| * saferinternet.at
| |
|
| |
|
| == 13.3 Aufgaben für den Unterricht ==
| | Ein fiktives Spielprojekt wird in Bestandteile zerlegt. |
|
| |
|
| === 13.3.1 Eigene und fremde Bestandteile unterscheiden ===
| | '''Arbeitsauftrag:''' Kennzeichne Code, Bilder, Sounds, Texte und Vorlagen als selbst erstellt, übernommen oder unklar. Bestimme, was noch geprüft werden muss. |
|
| |
|
| Die bewusste Zerlegung eines Programmprojekts in eigene und übernommene Anteile unterstützt die Schülerinnen und Schüler dabei, geistiges Eigentum konkret wahrzunehmen
| | '''Erwartetes Ergebnis:''' Transparente Komponentenliste. |
|
| |
|
| und die oft unsichtbare Herkunft einzelner Code-, Bild- oder Soundbestandteile systematisch zu klären. Die Lernenden erhalten mehrere kleine Programmprojekte oder Projektbeschreibungen, in denen unterschiedliche Bestandteile vorkommen, etwa selbst geschriebener Code, ein fremdes Hintergrundbild, ein remixtes Scratch-Projekt oder ein Sound aus einer Onlinebibliothek. In Partnerarbeit markieren sie, welche Teile selbst erstellt und welche übernommen wurden. Anschließend besprechen sie, bei welchen Bestandteilen Urheberrechte beachtet und Quellen angegeben werden müssen. | | === Remixe auf Quellen und Rechte prüfen === |
|
| |
|
| Dadurch wird deutlich, dass nicht nur das Gesamtprogramm, sondern auch einzelne Elemente rechtlich relevant sein können. Bestandteile Code, Bild, Sound, Text, Figur, Hintergrund
| | Ein Remix-Projekt wird untersucht. |
|
| |
|
| '''Arbeitsschritte'''<br /> | | '''Arbeitsauftrag:''' Finde Ursprungsprojekt, Lizenz und genannte Änderungen. Beurteile, welche Angaben nachvollziehbar sind und welche fehlen. |
| markieren, zuordnen, prüfen, begründen, besprechen, sichern
| |
|
| |
|
| Ergebnis Analysebogen, Übersicht, Merksatz | | '''Erwartetes Ergebnis:''' Prüfprotokoll. |
|
| |
|
| === 13.3.2 Remixe auf Quellen und Rechte prüfen === | | === Nutzungssituationen rechtlich einordnen === |
|
| |
|
| Die Analyse remixten Programmmaterials fördert ein realistisches Verständnis dafür, dass Weiterentwicklung und kreative Übernahme im Programmierunterricht sinnvoll sein können, aber nur dann verantwortungsvoll sind, wenn Ursprung und Rechte transparent bleiben. Die Schülerinnen und Schüler untersuchen vorhandene Remix-Beispiele, etwa Scratch- Projekte oder vereinfachte Spielentwürfe. Sie prüfen, ob kenntlich gemacht wird, von welchem Ausgangsprojekt der Remix stammt, welche Teile verändert wurden und ob Angaben zu Urheberin oder Urheber vorhanden sind. Danach bewerten sie, ob der Remix fair und nachvollziehbar dokumentiert ist.
| | Mehrere vereinfachte Fälle werden verglichen. |
|
| |
|
| In der gemeinsamen Auswertung wird besprochen, warum fehlende Quellenangaben problematisch sind und wie ein sauber gekennzeichneter Remix aussehen sollte. Prüfkriterien Ursprung, Änderung, Nennung, Lizenz, Nachvollziehbarkeit, Fairness Beispiele Scratchprojekt, Spielidee, Animation, Quiz, App, Lernprojekt Lernprodukte Prüfblatt, Bewertung, Kurzbegründung
| | '''Arbeitsauftrag:''' Ordne die Fälle „klar erlaubt“, „nur unter Bedingungen“, „unklar – zuerst prüfen“ zu und begründe anhand der angegebenen Lizenz. |
|
| |
|
| === 13.3.3 Nutzungssituationen rechtlich einordnen ===
| | '''Erwartetes Ergebnis:''' Vorsichtige, lizenzbezogene Einordnung. |
|
| |
|
| Die Arbeit mit konkreten Fallsituationen hilft den Schülerinnen und Schülern, Urheberrecht nicht nur abstrakt zu benennen, sondern in realistischen Programmiersituationen zu entscheiden, was erlaubt, eingeschränkt oder unzulässig ist. Die Lernenden bearbeiten mehrere kurze Fälle, etwa das Übernehmen eines Codeabschnitts aus einem Tutorial, das Einfügen eines Bildes aus dem Internet in ein Spiel, das Verwenden eines frei lizenzierten Sounds oder das Veröffentlichen eines remixten Projekts ohne Hinweis auf die Vorlage. Zu jedem Fall entscheiden sie, was unproblematisch, fraglich oder unzulässig ist und welche Angaben ergänzt werden müssten.
| | === Quellen und Lizenzen korrekt angeben === |
|
| |
|
| Anschließend vergleichen sie ihre Lösungen und formulieren daraus allgemeine Regeln für eigenes Arbeiten mit fremdem Material.
| | Für ein Projekt werden fremde Bestandteile dokumentiert. |
|
| |
|
| Fallarten Tutorialcode, Internetbild, Sounddatei, Remix, Bibliothek, Vorlage
| | '''Arbeitsauftrag:''' Erstelle eine vollständige Quellenliste mit Titel, Urheber, Quelle, Lizenz und gegebenenfalls Änderungsvermerk. |
|
| |
|
| '''Leitfragen'''<br /> | | '''Erwartetes Ergebnis:''' Nachvollziehbare Dokumentation. |
| Darf ich es, Was fehlt, Was muss genannt werden
| |
|
| |
|
| Ergebnis Fallanalyse, Regelübersicht, Tafelbild
| | === Offene und geschlossene Materialien vergleichen === |
|
| |
|
| === 13.3.4 Quellen und Lizenzen korrekt angeben ===
| | Verschiedene Materialien konkurrieren für dasselbe Projekt. |
|
| |
|
| Die saubere Dokumentation fremder Bestandteile stärkt Sorgfalt und Transparenz und zeigt den Schülerinnen und Schülern, dass korrektes Zitieren und Kennzeichnen auch beim Programmieren ein wesentlicher Teil guter digitaler Arbeit ist. Die Schülerinnen und Schüler erhalten ein kleines Programmprojekt mit übernommenen Bestandteilen und formulieren dafür passende Quellen- und Lizenzangaben. Sie halten fest, welcher Code, welches Bild oder welcher Sound woher stammt, wer ihn erstellt hat und unter welchen Bedingungen er genutzt wurde.
| | '''Arbeitsauftrag:''' Wähle geeignete Bilder, Sounds oder Codebausteine anhand von Nutzungsrechten und Projektzweck. |
|
| |
|
| Dabei üben sie unterschiedliche Formen der Kennzeichnung, etwa in Projektbeschreibungen, im Kommentarbereich eines Programms oder in einem Begleitblatt. Die Ergebnisse werden auf Vollständigkeit und Verständlichkeit geprüft. Pflichtangaben Titel, Urheber, Quelle, Lizenz, Änderungsvermerk, Link Kennzeichnungsorte Kommentar, Beschreibung, Quellenliste, Begleitblatt, Abspann, Infoseite
| | '''Erwartetes Ergebnis:''' Begründete Materialauswahl. |
|
| |
|
| '''Ziele'''<br />
| | === Ein Projekt mit sauberer Dokumentation remixen === |
| Transparenz, Genauigkeit, Nachvollziehbarkeit, Fairness
| |
|
| |
|
| === 13.3.5 Offene und geschlossene Materialien vergleichen ===
| | Ein freigegebenes Lernprojekt wird verändert. |
|
| |
|
| Die gezielte Gegenüberstellung verschiedener Lizenzsituationen unterstützt die Schülerinnen und Schüler dabei, offenes Material, eingeschränkt nutzbare Inhalte und vollständig geschützte Bestandteile voneinander zu unterscheiden und bewusster auszuwählen. Die Klasse vergleicht mehrere Materialien für Programmprojekte, etwa ein selbst gezeichnetes Sprite, ein Creative-Commons-Bild, einen Open-Source-Codebaustein, einen Sound aus einer freien Bibliothek und ein ungekennzeichnetes Internetbild. Die Lernenden prüfen jeweils, welche Nutzungen erlaubt sind, ob Bearbeitungen möglich sind und welche Angaben erforderlich wären.
| | '''Arbeitsauftrag:''' Dokumentiere Ausgangsprojekt und Lizenz, ändere mindestens zwei Aspekte und beschreibe deine eigenen Änderungen. |
|
| |
|
| Danach ordnen sie die Materialien nach ihrer Verwendbarkeit für ein Schulprojekt und begründen ihre Entscheidung. So wird Lizenzwissen in konkrete Auswahlkompetenz übersetzt. Materialarten Sprite, Bild, Sound, Code, Bibliothek, Vorlage
| | '''Erwartetes Ergebnis:''' Fair dokumentierter Remix. |
|
| |
|
| '''Vergleichsaspekte'''<br />
| | === Problematische Beispiele korrigieren === |
| Nutzung, Bearbeitung, Nennung, Offenheit, Sicherheit, Eignung
| |
|
| |
|
| Ergebnis Vergleichstabelle, Rangfolge, Begründung
| | Unvollständige Quellenhinweise werden verbessert. |
|
| |
|
| === 13.3.6 Ein Projekt mit sauberer Dokumentation remixen ===
| | '''Arbeitsauftrag:''' Ergänze fehlende Urheber-, Quellen- oder Lizenzangaben und ersetze Material, dessen Nutzung nicht geklärt werden kann. |
|
| |
|
| Die eigenständige Bearbeitung eines vorhandenen Projekts mit korrekter Kennzeichnung fördert besonders wirksam die Verbindung von kreativem Programmieren, Remixkultur und rechtlich verantwortlichem Handeln. Die Schülerinnen und Schüler wählen ein einfaches freigegebenes Projekt aus und verändern es gezielt, etwa durch neue Figuren, andere Fragen, zusätzliche Level oder veränderte Abläufe. Vor der Bearbeitung prüfen sie die Herkunft des Projekts und dokumentieren die Quelle. Nach
| | '''Erwartetes Ergebnis:''' Korrigierte Projektbeschreibung. |
|
| |
|
| dem Remixen ergänzen sie eine kurze Beschreibung, in der Ursprungsprojekt, eigene Änderungen und übernommene Bestandteile nachvollziehbar dargestellt werden. In der Präsentation erläutern sie, wie sie das Original verändert und welche Angaben sie bewusst ergänzt haben. Arbeitsphasen auswählen, prüfen, remixen, dokumentieren, testen, vorstellen Dokumentationspunkte Ursprung, Änderung, Quelle, Lizenz, Eigenanteil, Hinweis Produkte Remixprojekt, Projektbeschreibung, Kurzvortrag
| | === Eigene Urheberrolle bewusst wahrnehmen === |
|
| |
|
| === 13.3.7 Problematische Beispiele korrigieren ===
| | Die Lernenden betrachten auch ihre eigenen Werke als kreative Leistungen. |
|
| |
|
| Die Analyse fehlerhaft gekennzeichneter Projekte schärft den Blick für typische Versäumnisse und hilft den Schülerinnen und Schülern, unsaubere oder unfaire Veröffentlichungen gezielt zu verbessern. Die Lernenden erhalten Beispielprojekte oder Projektskizzen mit typischen Mängeln, etwa fehlender Quellenangabe, unklarer Herkunft eines Sounds, nicht gekennzeichnetem Remix oder unpassender Nutzung eines Internetbildes. In Gruppen markieren sie die problematischen Stellen und schlagen konkrete Korrekturen vor. Danach erstellen sie eine verbesserte Version der Projektbeschreibung oder Quellenliste.
| | '''Arbeitsauftrag:''' Lege für ein eigenes kleines Projekt fest, wie andere es verwenden dürfen, und begründe deine Entscheidung. |
|
| |
|
| Die gemeinsame Besprechung zeigt, welche Fehler im Schulalltag besonders häufig sind und wie sie vermieden werden können.
| | '''Erwartetes Ergebnis:''' Bewusste Urheber- und Lizenzperspektive. |
|
| |
|
| '''Fehlerarten'''<br />
| | === Gruppenprojekte transparent dokumentieren === |
| fehlende Quelle, unklarer Remix, falsche Lizenz, Fremdbild, Soundnutzung, Kopie
| |
|
| |
|
| Methoden markieren, prüfen, korrigieren, ergänzen, vergleichen, sichern Sicherung Korrekturblatt, Fehlerliste, Checkliste
| | Ein Teamprojekt enthält Beiträge mehrerer Personen und fremde Materialien. |
|
| |
|
| === 13.3.8 Eigene Urheberrolle bewusst wahrnehmen ===
| | '''Arbeitsauftrag:''' Erstellt eine gemeinsame Übersicht über eigene Beiträge, übernommene Bestandteile, Quellen, Lizenzen und Änderungen. |
|
| |
|
| Die Perspektive auf die eigene kreative Leistung fördert das Verständnis dafür, dass Schülerinnen und Schüler nicht nur Nutzende fremder Materialien sind, sondern selbst Urheberinnen und Urheber von Code, Grafiken, Sounds und digitalen Projekten werden können. Die Schülerinnen und Schüler erstellen einen kleinen selbst entwickelten Bestandteil für ein Programm, etwa eine Figur, einen Sound, einen Hintergrund oder einen kurzen Codeabschnitt. Anschließend überlegen sie, wie andere diesen Bestandteil nutzen dürften und welche Angaben sie sich bei einer Übernahme wünschen würden.
| | '''Erwartetes Ergebnis:''' Nachvollziehbares Projektprotokoll. |
|
| |
|
| Danach formulieren sie einfache Freigabebedingungen oder eine kurze Lizenzentscheidung für ihr eigenes Material. Diese Aufgabe stärkt den Perspektivwechsel und macht Urheberrecht als Schutz eigener Arbeit erfahrbar. Eigenleistungen Sprite, Sound, Text, Code, Animation, Hintergrund Entscheidungsfragen Wer darf es, Darf es geändert werden, Muss ich genannt werden Ergebnis Eigenprodukt, Freigabehinweis, Reflexion
| | === Reflexion und Ergebnissicherung === |
|
| |
|
| === 13.3.9 Gruppenprojekte transparent dokumentieren ===
| | Eine Projektregel wird formuliert. |
|
| |
|
| Die bewusste Klärung von Zuständigkeiten und Quellen in kooperativen Projekten unterstützt eine faire Zusammenarbeit und zeigt, dass Urheberangaben nicht nur für externe Materialien, sondern auch innerhalb von Gruppen wichtig sein können. In Kleingruppen planen die Lernenden ein kleines Programmprojekt und halten von Beginn an fest, wer welchen Teil übernimmt, etwa Code, Grafik, Sound, Test oder Dokumentation. Zusätzlich dokumentieren sie, welche externen Materialien eingebunden werden und unter welchen Bedingungen dies geschieht.
| | '''Arbeitsauftrag:''' Erstelle eine Checkliste „Vor dem Remixen prüfen“ mit mindestens sechs Punkten. |
|
| |
|
| Zum Abschluss erstellen sie eine gemeinsame Übersicht, in der Eigenanteile und Fremdanteile klar getrennt sichtbar sind. So lernen die Schülerinnen und Schüler, auch kollaborative Projekte transparent und nachvollziehbar zu beschreiben. Gruppenrollen Code, Grafik, Sound, Test, Dokumentation, Präsentation Dokumentationspunkte Eigenanteil, Fremdanteil, Quelle, Lizenz, Zuständigkeit, Änderung Produkte Projektblatt, Quellenübersicht, Rollenplan
| | '''Erwartetes Ergebnis:''' Praxisorientierte Prüfliste. |
|
| |
|
| === 13.3.10 Reflexion und Ergebnissicherung === | | == Selbstcheck == |
|
| |
|
| Die abschließende Sicherung hilft den Schülerinnen und Schülern, die Verbindung zwischen kreativem Programmieren, Remixing und Urheberrecht als festen Bestandteil verantwortungsvoller digitaler Produktion zu verinnerlichen. Die Schülerinnen und Schüler halten schriftlich oder mündlich fest, worauf sie bei der Nutzung fremder Programmteile künftig achten wollen, welche Angaben bei einem Remix notwendig sind und warum geistiges Eigentum auch im Informatikunterricht bedeutsam ist. Zusätzlich formulieren sie eine eigene Regel für faire Projektarbeit mit fremdem Material.
| | * Ich unterscheide eigene und fremde Bestandteile. |
| | * Ich prüfe die Lizenz vor einem Remix. |
| | * Ich kann Quellen und Lizenzinformationen dokumentieren. |
| | * Ich kennzeichne eigene Änderungen. |
| | * Ich weiß, dass Internetfund und Nutzungsrecht nicht dasselbe sind. |
| | * Ich kann für ein Projekt fairere Materialalternativen auswählen. |
|
| |
|
| Die Ergebnisse werden in einer gemeinsamen Merkhilfe gesammelt und für spätere Programmierprojekte nutzbar gemacht. Reflexionsfragen Was ist mein Anteil, Was ist fremd, Was muss ich nennen, Was darf ich remixen Sicherung Lernjournal, Exit Card, Merkblatt, Wandplakat
| | == Siehe auch == |
|
| |
|
| Grundlage: Digitale Grundbildung II – Lehrband 2. Klasse, Final V2.5.
| | * [[DGB 2: Lizenzmodelle|Creative Commons, OER und Open Source]] |
| | * [[DGB 2: Programmieren Testen Debuggen|Programmieren und Debuggen]] |
| | * [[DGB 2: Visuelle Audiovisuelle Auditive Inhalte|Medien erzeugen und adaptieren]] |
|
| |
|
| [[Kategorie:Digitale Grundbildung 2. Klasse]] | | [[Kategorie:Digitale Grundbildung]] |
| | [[Kategorie:DGB 2]] |
← Digitale Grundbildung 2. Klasse
Programme und digitale Projekte bestehen häufig aus vielen Teilen: eigenem Code, übernommenen Bausteinen, Bildern, Figuren, Sounds oder Vorlagen. Beim Remixen wird Bestehendes verändert oder kombiniert. Dabei müssen Herkunft, Lizenz und eigene Änderungen nachvollziehbar bleiben.
| Bereich
|
Zuordnung
|
| Kompetenzbereich
|
Produktion
|
| Perspektiven
|
G, I
|
| Schwerpunkt
|
Geistiges Eigentum und Urheberrechte beim Erstellen oder Remixen von Programmen
|
| Kompetenz
|
Eigene und fremde Bestandteile digitaler Projekte unterscheiden, Nutzungsrechte prüfen und übernommene bzw. veränderte Bestandteile transparent dokumentieren.
|
Die Schülerinnen und Schüler können:
- geistiges Eigentum im Zusammenhang mit Code und digitalen Medien erklären;
- eigene und fremde Bestandteile eines Projekts unterscheiden;
- erkennen, dass Quellcode, Grafiken, Sounds und andere konkrete Werke geschützt sein können;
- Remix als Bearbeitung bzw. Kombination vorhandener Materialien beschreiben;
- erlaubte, eingeschränkte und unklare Nutzungssituationen unterscheiden;
- offene und geschlossene Lizenzen bei Programmprojekten vergleichen;
- Quellen-, Urheber- und Lizenzangaben für übernommene Bestandteile erstellen;
- eigene Änderungen an einem übernommenen Projekt dokumentieren;
- bei Gruppenprojekten Beiträge und Herkunft transparent halten;
- begründen, warum Namensnennung und Lizenzhinweise Fairness und Nachvollziehbarkeit fördern;
- bei fehlender oder unklarer Freigabe auf eigenes oder eindeutig lizenziertes Material ausweichen.
Ein Spiel kann aus Programmcode, Figuren, Hintergrundbildern, Musik und Texten bestehen. Diese Bestandteile können unterschiedliche Urheberinnen, Urheber und Lizenzen haben.
Darum genügt es nicht zu sagen „Das Projekt ist von mir“, wenn wesentliche Teile übernommen wurden. Eigene und fremde Anteile müssen unterscheidbar sein.
Eine allgemeine Idee wie „ein Quiz über Planeten“ ist etwas anderes als ein konkreter Quelltext, ein gezeichnetes Sprite oder eine komponierte Musikdatei. Für den Unterricht ist wichtig, konkrete fremde Werke nicht einfach als eigene auszugeben.
Rechtliche Details können je nach Werk und Nutzung komplex sein; bei Schulprojekten schafft eine saubere Herkunftsdokumentation eine verlässliche Basis.
Beim Remix wird ein vorhandenes Projekt verändert, erweitert oder mit anderen Elementen kombiniert. Lernplattformen für Programmierung fördern solche Arbeitsformen teilweise ausdrücklich.
Ob und unter welchen Bedingungen ein Remix erlaubt ist, hängt von der Lizenz oder Freigabe des Ausgangsmaterials ab.
Open-Source- und Creative-Commons-Lizenzen können bestimmte Nutzungen und Bearbeitungen erlauben. Die Bedingungen müssen gelesen und eingehalten werden. Bei proprietären oder ungekennzeichneten Materialien ist die Weiterverwendung häufig stärker eingeschränkt oder unklar.
„Im Internet gefunden“ ist keine Lizenz.
Bei übernommenen Bestandteilen sollten mindestens Titel bzw. Bezeichnung, Urheber oder Projekt, Quelle und Lizenz festgehalten werden. Bei Änderungen sollte zusätzlich erkennbar sein, was verändert wurde.
Solche Angaben können in einer Projektbeschreibung, einem Kommentar im Code, einer Quellenliste oder einem Abspann stehen.
Gruppenprojekte werden transparenter, wenn dokumentiert wird, wer welche Teile erstellt oder eingebracht hat. Das hilft nicht nur beim Urheberrecht, sondern auch bei Zusammenarbeit und Bewertung.
Versionsverläufe und Projektprotokolle können diese Nachvollziehbarkeit unterstützen.
Remixen ist ein wichtiger Teil digitaler Kreativität. Fair wird die Praxis, wenn bestehende Arbeit respektiert, erlaubte Materialien gewählt, Urheber genannt und eigene Veränderungen sichtbar gemacht werden.
Damit werden kreative Weiterentwicklung und Rechte anderer miteinander verbunden.
Eigene und fremde Bestandteile unterscheiden
[Bearbeiten]Ein fiktives Spielprojekt wird in Bestandteile zerlegt.
Arbeitsauftrag: Kennzeichne Code, Bilder, Sounds, Texte und Vorlagen als selbst erstellt, übernommen oder unklar. Bestimme, was noch geprüft werden muss.
Erwartetes Ergebnis: Transparente Komponentenliste.
Ein Remix-Projekt wird untersucht.
Arbeitsauftrag: Finde Ursprungsprojekt, Lizenz und genannte Änderungen. Beurteile, welche Angaben nachvollziehbar sind und welche fehlen.
Erwartetes Ergebnis: Prüfprotokoll.
Nutzungssituationen rechtlich einordnen
[Bearbeiten]Mehrere vereinfachte Fälle werden verglichen.
Arbeitsauftrag: Ordne die Fälle „klar erlaubt“, „nur unter Bedingungen“, „unklar – zuerst prüfen“ zu und begründe anhand der angegebenen Lizenz.
Erwartetes Ergebnis: Vorsichtige, lizenzbezogene Einordnung.
Für ein Projekt werden fremde Bestandteile dokumentiert.
Arbeitsauftrag: Erstelle eine vollständige Quellenliste mit Titel, Urheber, Quelle, Lizenz und gegebenenfalls Änderungsvermerk.
Erwartetes Ergebnis: Nachvollziehbare Dokumentation.
Offene und geschlossene Materialien vergleichen
[Bearbeiten]Verschiedene Materialien konkurrieren für dasselbe Projekt.
Arbeitsauftrag: Wähle geeignete Bilder, Sounds oder Codebausteine anhand von Nutzungsrechten und Projektzweck.
Erwartetes Ergebnis: Begründete Materialauswahl.
Ein Projekt mit sauberer Dokumentation remixen
[Bearbeiten]Ein freigegebenes Lernprojekt wird verändert.
Arbeitsauftrag: Dokumentiere Ausgangsprojekt und Lizenz, ändere mindestens zwei Aspekte und beschreibe deine eigenen Änderungen.
Erwartetes Ergebnis: Fair dokumentierter Remix.
Unvollständige Quellenhinweise werden verbessert.
Arbeitsauftrag: Ergänze fehlende Urheber-, Quellen- oder Lizenzangaben und ersetze Material, dessen Nutzung nicht geklärt werden kann.
Erwartetes Ergebnis: Korrigierte Projektbeschreibung.
Eigene Urheberrolle bewusst wahrnehmen
[Bearbeiten]Die Lernenden betrachten auch ihre eigenen Werke als kreative Leistungen.
Arbeitsauftrag: Lege für ein eigenes kleines Projekt fest, wie andere es verwenden dürfen, und begründe deine Entscheidung.
Erwartetes Ergebnis: Bewusste Urheber- und Lizenzperspektive.
Gruppenprojekte transparent dokumentieren
[Bearbeiten]Ein Teamprojekt enthält Beiträge mehrerer Personen und fremde Materialien.
Arbeitsauftrag: Erstellt eine gemeinsame Übersicht über eigene Beiträge, übernommene Bestandteile, Quellen, Lizenzen und Änderungen.
Erwartetes Ergebnis: Nachvollziehbares Projektprotokoll.
Eine Projektregel wird formuliert.
Arbeitsauftrag: Erstelle eine Checkliste „Vor dem Remixen prüfen“ mit mindestens sechs Punkten.
Erwartetes Ergebnis: Praxisorientierte Prüfliste.
- Ich unterscheide eigene und fremde Bestandteile.
- Ich prüfe die Lizenz vor einem Remix.
- Ich kann Quellen und Lizenzinformationen dokumentieren.
- Ich kennzeichne eigene Änderungen.
- Ich weiß, dass Internetfund und Nutzungsrecht nicht dasselbe sind.
- Ich kann für ein Projekt fairere Materialalternativen auswählen.
