Projekt S-Bahn Berlin Map

Discord Einladung
Trete unserem Discord-Server bei (klicke hier zum Beitreten).

  • Beitrag von bandit25 ()

    Dieser Beitrag wurde von Steve aus folgendem Grund gelöscht: Off-Topic ().
    • Neu

    Danke und habe es mal durchgeführt, umbenannt. Mal sehen, ob es dann besser wird. Aber erstmal vielen Dank für deine Mühe.

    • Neu
    Zitat von BR-218

    Der Fehler ist auch im allgemeinen gehalten. Deshalb schrieb ich ja das entweder der Speicher voll läuft oder aber der TS mit irgendwas nicht klar kommt. Dann spuckt er genau den selben Fehler aus.


    Dann musst du dich da einarbeiten. Musste jeder der mit dem TS auch was anfangen will.

    Das S Bahn Tool scheint aber Fehler zu haben. Da vertraue lieber TS Tools.

    Hallöchen BR-218 und @all.

    Ich versuche es ja, mit dem TS-Tool.

    Jetzt habe ich es, leider falsch hier, mit der Stadtbahn-Berlin versucht.

    Wollte es aber jetzt, wo ich das bemerkt haben, nicht nochmals versuchen, das mit der S-Bahn Berlin durchmachen, um euch das jetzt in Screens zu zeigen, was ich meine und um eure Hilfe Bitte.

    Ist ja in der Anwendung dasselbe.

    Deshalb Sorry, für die falsche Map/App.

    Habe das TS-Tool geöffnet und dann die bedien xml-Dateien extrahiert.

    Wie es in der Anleitung am Anfang eingeblendet wird.

    Habe dann in den Einstellungen gefunden, das man das Tool auf Deutsch einstellen kann, was ich tat.

    Nur sehr seltsam, das einige "Button" weiterhin in Englisch sind, wie einige Meldungen, was in den Screens zu sehen ist.

    Warum auch nimmer, aber soll die aktuelle Version von TS-Tool sein.

    So, dann fangen wir mal an.

    Bild 1 zeigt den Anfang, wenn ich das TS-Tool gestartet habe, nach dem ich auf: "Werkzeuge Strecken erstellen", dann das Menü, was aufgeklappt wird: "Strecken (Routes) oder Aufgaben (Szenarios) prüfen" anklickte.

    Dann wählte ich eben "Stadtbahn.." aus. Dann auf: "gewaehlte Strecke pruefen" aus. Screen: TS-Tool-1.

    Wie zu sehen, wird ja geprüft.

    Dann kommt das Screen: TS-Tools-2.

    Dachte dann, sieht ja okay aus.

    Dann aber dann Screen: TS-Tool-3.

    Rote zahlen, was hellblaues (habe von Farbennamen keine Ahnung, für mich Hellblau).

    Danach dann Screen: TS-Tools-4.

    Nun die Roten zahlen auf "Null".

    Dann diese Fehlermeldung in Englisch in Screenshoot: TS-Tolls-5-fehlermeldun viele".

    Das mehrmals, aber änderte sich nur die Nummer hinter der: "#".

    Dann folgte die nächste Meldung: TS-Tool-5-fKeine Ahnung".

    So, nun weiß ich nicht viel mehr, als vorher.

    Wer Kann helfen?

    Danke.

    • Neu
    Zitat von PlanZ

    Technische Anpassungen zur Fehlerbehebung oder Wiederherstellung der Funktionsfähigkeit können unter den Voraussetzungen des § 69d Abs. 1 UrhG zulässig sein.


    Der Einwand mit § 69d Abs. 1 UrhG klingt im ersten Moment für juristische Laien plausibel, hält aber einer echten urheberrechtlichen Prüfung in diesem konkreten Fall nicht stand. Hier liegt eine klassische Fehlinterpretation der Norm vor, da die strengen Tatbestandsmerkmale, die der Gesetzgeber für eine eigenmächtige "Fehlerbehebung" vorschreibt, überhaupt nicht erfüllt sind.


    Damit ein Nutzer eine Software eigenmächtig verändern darf, muss zwingend ein Fehler (Mangel) in der gekauften Software vorliegen. Ein Softwarefehler im Sinne des Urheberrechts liegt dann vor, wenn das Programm nicht das tut, was es laut Herstellerbeschreibung tun soll (Abweichung Ist-Beschaffenheit von Soll-Beschaffenheit). Das Add-on Berlin JWD von virtualTracks funktioniert auch nach dem letzten Update jedoch fehlerfrei. Man kann die Strecke laden, Züge fahren und alle sonstigen ordnungsgemäßen Funktionen nutzen. Das Addon selbst hat also keinen Defekt. Dass die S-Bahn Berlin Map nach dem Update die Daten des Addons nicht mehr auslesen kann (bzw. die angesprochene Datei vmtl. zu Fehlern führt), stellt keineswegs einen Mangel des Berlin JWD Addons dar – dies anzunehmen, ist der eigentliche Trugschluss an der Sache. Eine Inkompatibilität mit Drittsoftware ist urheberrechtlich kein Mangel des Addons.


    Das Tatbestandsmerkmal der bestimmungsgemäßen Benutzung nach § 69d Abs. 1 UrhG erlaubt Modifikationen an der Software (hier: an dem Addon Berlin JWD) ausdrücklich nur dann, wenn sie "für eine bestimmungsgemäße Benutzung des Computerprogramms [...] notwendig sind". Die bestimmungsgemäße Benutzung des Berlin JWD Addons ist das Befahren der von Jan entwickelten Strecke mit den zur Verfügung stehenden Rollmaterialien. Die Zweckentfremdung durch das Löschen oder Manipulieren der Datei "TTB_FM_GeoReader_JWD.out" geschieht hier jedoch nicht, um das Berlin JWD Addon bestimmungsgemäß spielen zu können, sondern geschieht ausschließlich zu dem Zweck, die Inhalte des Payware-Addons für ein anderes Projekt (hier: die Freeware S-Bahn Berlin Map) freizuschalten. Das Auslesen von Daten für Fremdprojekte gehört aber nicht zur rechtlich geschützten bestimmungsgemäßen Benutzung des Produkts. Selbst wenn man hypothetisch einen Fehler konstruieren würde: Wenn es sich bei dem integrierten GeoReader (wie aus dem Kontext zu vermuten) um eine funktionale Validierungsschranke handelt, die den unberechtigten Datenzugriff steuert, greift § 69d Abs. 1 UrhG erst recht nicht. Der Gesetzgeber erlaubt über die Fehlerberichtigung das Flicken von Abstürzen oder Bugs. Er erlaubt damit aber niemals das gezielte Deaktivieren, Überschreiben oder Entfernen von herstellereigenen Sicherheits-, Kopierschutz- oder Validierungsdateien. Das Aushebeln solcher Mechanismen - wie in der Anleitung beschrieben - fällt unter das strikte Umarbeitungsverbot des § 69c Nr. 2 UrhG.


    Die Argumentation mit § 69d Abs. 1 UrhG ist in diesem Fall also juristisches Wunschdenken. Die Norm schützt den ehrlichen Käufer vor kaputter Software - sie ist keine Freikarte, Systemdateien eines Payware-Entwicklers zu "manipulieren", nur weil ein dadurch inkompatibles Freeware-Projekt sonst streikt. Das Risiko für diese Inkompatibilität liegt allein beim Team des Freeware-Projekts der "S-Bahn Berlin Map", das eine unfertige Version / Vorgängerversion als starre Basis genutzt hat. Als Urheber steht Jan das exklusive Recht zu, seine Software jederzeit zu patchen, zu verändern oder Sicherheitsmechanismen einzubauen (§ 69c UrhG). Er hat keinerlei rechtliche Pflicht zur Abwärtskompatibilität für Drittprojekte. Wer ein eigenes Freeware-Projekt auf der Basis eines bekanntlich unfertigen, fremden Payware-Addons aufbaut, trägt das volle technische Risiko für zukünftige Updates des Hauptprogramms. Das Freeware-Team hätte das Projekt auf die finale Version anpassen müssen, anstatt eine Kompatibilität der Payware einzufordern oder das Publizieren einer solchen Anleitung zu rechtfertigen.


    Ergänzung zur aktuellen Stellungnahme von virtualTracks: Jan hat mittlerweile angekündigt, die technische Validierungsschranke mit Version 1.21 zur Deeskalation zu entfernen. An der urheberrechtlichen Bewertung der Freeware-Map ändert dieser Schritt rein rechtlich jedoch nichts: 1. Bestätigung der Fehlerfreiheit: Die Erklärung zeigt, dass die Schranke absichtlich als Schutzmaßnahme integriert war. Es lag somit zu keinem Zeitpunkt ein „Softwarefehler“ vor, womit die Argumentation über § 69d UrhG auch rückwirkend endgültig hinfällig ist. 2. Fehlende Rechteeinräumung: Der Urheber hat unmissverständlich klargestellt, dass für die S-Bahn-Map keine Freigabe zur Nutzung der Assets erteilt wurde. Da die Modelle zudem auf zweckgebundenen Fotogenehmigungen der Deutschen Bahn basieren, bleibt die Verwendung der 3D-Objekte in einem Fremdprojekt ohne explizite Lizenzierung urheberrechtlich unzulässig. Die bloße Entfernung des technischen Schutzes legalisiert die Nutzung der urheberrechtlich geschützten Inhalte also nicht.
    • Neu

    Danke für ein Einwand. Ich sehe das aber anders.


    vT bezeichnet den Mechanismus selbst als "Copyrightschutz", eine Bezeichnung die urheberrechtlich jedoch nicht trägt. Das Urheberrecht an Computerprogrammen schützt nach § 69a Abs. 2 Satz 1 UrhG ausdrücklich nur die Ausdrucksformen eines Computerprogramms. Ideen und Grundsätze die einem Element eines Computerprogramms zugrunde liegen sind nach § 69a Abs. 2 Satz 2 UrhG nicht geschützt. Der Bundesgerichtshof hat in I ZR 157/21 (Rn. 20) unter Verweis auf EuGH C-159/23 vom 17. Oktober 2024 festgestellt, dass zu den urheberrechtlich geschützten Ausdrucksformen eines Computerprogramms der Quellcode und der Objektcode fallen, da sie die Vervielfältigung oder spätere Entstehung dieses Programms ermöglichen. Dagegen werden andere Elemente des Programms, wie insbesondere seine Funktionalität, nicht durch die Richtlinie 2009/24/EG geschützt.



    Der fragliche Geofencing-Mechanismus – eine Lua-Bytecode-Datei die per DLL prüft ob der Nutzer auf virtualTracks-eigenen Strecken fährt und nach 60 Sekunden einen künstlichen Absturz auslöst schützt keine urheberrechtlich geschützten Inhalte vor unbefugtem Zugriff oder Vervielfältigung. Er steuert ausschließlich den Programmablauf abhängig vom geografischen Kontext. Das ist nach BGH I ZR 157/21 und EuGH C-159/23 reine Funktionalität und Funktionalität wird von der Richtlinie 2009/24/EG ausdrücklich nicht geschützt.



    Das Löschen der Datei verändert zudem keinen Quell- oder Objektcode des Addons selbst. Es handelt sich damit auch nicht um eine Umarbeitung im Sinne des § 69c Nr. 2 UrhG. Was urheberrechtlich nicht geschützt ist und dessen Entfernung keine Umarbeitung darstellt, kann auch nicht im Sinne des Urheberrechts "umgangen" werden. Die Bezeichnung "Copyrightschutz" ist daher irreführend. Es handelt sich um eine Anti-Interoperabilitätsmaßnahme die vom Urheberrecht nicht geschützt wird.

    Die Ergänzung bestätigt im Kern was urheberrechtlich von Anfang an galt: Das Rechtsproblem besteht zwischen virtualTracks und dem Freeware-Kartenersteller, nicht zwischen virtualTracks und dem Endnutzer. Der Endnutzer der eine Datei auf seinem eigenen System löscht hat weder Assets vervielfältigt noch verbreitet noch in Quell- oder Objektcode eingegriffen. Er hat lediglich eine Funktionalitätsdatei entfernt die nach BGH I ZR 157/21 (Rn. 20, gestützt auf EuGH C-159/23) keinen urheberrechtlichen Schutz genießt. Die fehlende Rechteeinräumung gegenüber dem Freeware-Kartenersteller ist ein berechtigter Einwand, aber er richtet sich an die falsche Adresse wenn er gegen den Endnutzer ins Feld geführt wird. Die urheberrechtliche Verantwortung für die Asset-Nutzung liegt ausschließlich beim Kartenersteller, nicht beim Käufer des Addons der sein legitim erworbenes Produkt auf seinem eigenen System nutzen möchte.

    Einmal editiert, zuletzt von PlanZ () aus folgendem Grund: Ein Beitrag von PlanZ mit diesem Beitrag zusammengefügt.

    Gefällt mir 1
    • Neu

    PlanZ Dein Einwand wirkt durch die präzise Zitierung des EuGH (C-159/23 „Sony/Datel“) und des BGH (I ZR 157/21) auf den ersten Blick juristisch hochkarätig. Er leidet jedoch an einem fundamentalen Kategorien- und Übertragungsfehler: Du vermischst hier die abstrakte Idee einer Funktion mit dem konkreten Code, der diese ausführt.


    Deine Argumentation lässt sich daher mit drei klaren Punkten entkräften:

    1. Fehlinterpretation des EuGH-Urteils (Idee vs. konkreter Objektcode): Du ziehst das Sony/Datel-Urteil heran, um zu belegen, dass es sich beim Geofencing um eine bloße "Funktionalität" handele, die nicht geschützt sei. Dabei verkennst du den dort verhandelten Sachverhalt grundlegend. Der Fall beim EuGH: Das Unternehmen Datel veränderte temporär Variablen im Arbeitsspeicher (RAM) einer Konsole während des laufenden Betriebs. Die originalen Programmdateien blieben völlig unangetastet. Der EuGH entschied folgerichtig, dass der flüchtige RAM-Inhalt kein geschützter Code ist. Der Fall hier: Die Anleitung "fordert den Nutzer dazu auf", eine physisch auf der Festplatte existierende Datei ("TTB_FM_GeoReader_JWD.out") dauerhaft zu löschen oder zu verändern. Kompilierter Lua-Bytecode ist rechtlich unbestritten Objektcode i.S.d. § 69a Abs. 2 UrhG und genießt - ausdrücklich auch nach dem von dir zitierten EuGH-Urteil - den höchsten urheberrechtlichen Schutz als Ausdrucksform. Die Richtlinie 2009/24/EG besagt lediglich, dass die Idee einer Funktion (z.B. die Logik eines Geofencings) nicht geschützt ist - jeder darf sie selbst neu programmieren. Der konkrete, fertig kompilierte Code auf der Festplatte ist jedoch als solcher geschützt. Würde man deiner Logik folgen, wäre überhaupt keine Software geschützt, da jedes Programm letztlich "nur den Programmablauf steuert und Funktionen ausführt". Das dauerhafte Entfernen von geschütztem Objektcode hat mit dem dynamischen Verändern von RAM-Variablen im Sony-Urteil nichts zu tun.
    2. Das Löschen von Dateien als Umarbeitung (§ 69c Nr. 2 UrhG): Die Behauptung, das Löschen einer Datei greife nicht in den Code ein, ist IT-rechtlich falsch. Ein modernes Computerprogramm definiert sich urheberrechtlich als funktionale Einheit (Gesamtwerk), bestehend aus einem Gefüge interagierender Module, DLLs und Skriptdaten. Wer gezielt eine funktionale Objektcode-Datei aus diesem Gesamtgefüge entfernt, um die vom Entwickler programmierte Logik zu manipulieren (hier: die Validierungsabfrage zu kappen), nimmt eine strukturelle Änderung an der Softwarearchitektur vor. Das ist eine klassische, zustimmungsbedürftige Umarbeitung des Gesamtprogramms nach § 69c Nr. 2 UrhG.
    3. Der Schutz der Assets (§ 2 Nr. 7 i.V.m. § 95a UrhG): Selbst wenn man deiner Argumentation hypothetisch folgen würde, dass der GeoReader nur eine schutzlose "Funktion" sei, übersiehst du die eigentliche Schutzrichtung: Die out.Datei schützt nicht sich selbst, sondern sie kontrolliert den Zugriff auf die 3D-Modelle, Texturen und Geodaten des Addons. Diese grafischen Assets fallen überhaupt nicht unter das Software-Urheberrecht nach §§ 69a ff. UrhG, sondern sind Werke nach § 2 Nr. 7 UrhG. Für diese klassischen Werke gilt der strikte Schutz technischer Maßnahmen nach § 95a UrhG. Da der GeoReader den Zugang zu diesen geschützten Werken beschränkt, stellt er eine wirksame technische Maßnahme dar. Das gezielte Löschen der Kontrolldatei, um diese geschützten Assets in einer nicht autorisierten Fremdmap darzustellen, stellt somit eine unzulässige Umgehung im Sinne des § 95a UrhG dar.

    Wie schon erwähnt, hat Jan mittlerweile angekündigt, die technische Validierungsschranke mit Version 1.21 zur Deeskalation zu entfernen. An der urheberrechtlichen Bewertung der Freeware-Map und der Anleitung ändert dieser Schritt rein rechtlich jedoch nichts. Die Erklärung zeigt, dass die Schranke absichtlich als Schutzmaßnahme integriert war. Es lag somit zu keinem Zeitpunkt ein "Softwarefehler" vor, womit die Argumentation über § 69d UrhG auch rückwirkend endgültig hinfällig ist. Zudem hat Jan (als Urheber) unmissverständlich klargestellt, dass für die S-Bahn-Map keine Freigabe zur Nutzung der Assets aus dem Berlin JWD Addon erteilt wurde. Da die Modelle zudem auf zweckgebundenen Fotogenehmigungen der Deutschen Bahn basieren, bleibt die Verwendung der 3D-Objekte in einem Fremdprojekt ohne explizite Lizenzierung urheberrechtlich unzulässig. Die bloße Entfernung des technischen Schutzes durch den Entwickler legalisiert die Nutzung der urheberrechtlich geschützten Inhalte im Fremdprojekt also nicht.


    Letztendlich kann ohnehin nur der Urheber selbst entscheiden, ob und wie er seine Rechte geltend macht. Da diese juristische Diskussion zwar extrem spannend ist, für den Mainstream-Nutzer hier im Thread aber vermutlich etwas zu trocken und schwer nachvollziehbar wird, können wir das Ganze bei Interesse gerne per PN vertiefen, um das Thema hier nicht zu sprengen. Wie heißt es am Ende so oft: Zwei Juristen, drei Meinungen ;)

    • Neu

    Danke für die detaillierte Antwort. Ich gehe die drei Punkte mal durch.


    Zu Punkt 1: Objektcode-Argument und BGH-Urteil: Der technische Unterschied zwischen flüchtigen RAM-Variablen und einer physischen Datei auf der Festplatte ist korrekt und wird nicht bestritten. Aber das ist nicht der Punkt für den BGH I ZR 157/21 hier herangezogen wird. Das relevante Prinzip aus diesem Urteil ist nicht "RAM-Variablen sind kein geschützter Code", sondern "Eingriffe in den Programmablauf ohne Veränderung von Quell- oder Objektcode des Hauptprogramms stellen keine Umarbeitung im Sinne des § 69c Nr. 2 UrhG dar." Die entscheidende Frage ist nicht ob die gelöschte Datei selbst Objektcode enthält, sondern ob ihr Entfernen eine Umarbeitung des Addons darstellt. Das tut es nicht, weil der verbleibende Code des Addons vollständig unangetastet bleibt. § 69c Nr. 2 erfordert aktive Gestaltungshandlungen: Übersetzung, Bearbeitung, Arrangement. Das Löschen einer Datei ist das genaue Gegenteil davon.


    Zu Punkt 2: Gesamtwerk und Umarbeitung: § 69c Nr. 2 definiert Umarbeitung konkret als Übersetzung, Bearbeitung, Arrangement und andere Umarbeitungen, allesamt aktive Gestaltungshandlungen die eine Veränderung des vorhandenen Codes voraussetzen. Das Löschen einer Datei ist das genaue Gegenteil: kein Code wird verändert, kein neuer Code entsteht. Der Begriff "strukturelle Änderung der Softwarearchitektur" findet sich weder in § 69c noch in der Richtlinie 2009/24/EG noch in der BGH-Rechtsprechung. Er ist eine selbst konstruierte Kategorie ohne gesetzliche Grundlage. Der BGH hat in I ZR 157/21 exakt dieses Gesamtwerk-Argument bereits abgelehnt, Sony hatte dasselbe vorgebracht und ist damit gescheitert. Zudem beweist das Argument zu viel: Wenn das Entfernen einer Datei bereits eine Umarbeitung wäre, wäre auch das Deinstallieren eines Plugins oder das Löschen einer Konfigurationsdatei eine zustimmungsbedürftige Umarbeitung. Das kann nicht der Sinn des § 69c Nr. 2 sein.


    Zu Punkt 3: § 95a für Assets: Die Trennung zwischen GeoReader als Software und Assets als eigenständige Werke ist strukturell nicht falsch. Aber das Argument scheitert auf mehreren Ebenen.


    Erstens scheitert es am Wirksamkeitskriterium des § 95a Abs. 2 Satz 2 UrhG. Das System ist technisch durchdacht: Ein kryptografischer Hash basierend auf internen TS-Objekt-IDs wird kombiniert mit GPS-Verifikation. Beide Bedingungen müssen erfüllt sein damit ein gültiger Stempel geschrieben wird. Das wird nicht bestritten. Entscheidend ist aber was dieses System tatsächlich schützt. Es prüft ob bestimmte Signalobjekte auf der Strecke vorhanden sind und ob der Nutzer sich geografisch in Berlin befindet. Es kontrolliert damit den Nutzungskontext, nicht den Zugang zu den Assets. Die Asset-Dateien selbst liegen unverschlüsselt auf der Festplatte und werden vollständig geladen und gerendert. Sie sind für den Nutzer sichtbar bevor der Absturz ausgelöst wird. § 95a Abs. 2 Satz 2 erfordert ausdrücklich eine Zugangskontrolle, einen Schutzmechanismus wie Verschlüsselung, Verzerrung oder sonstige Umwandlung, oder einen Mechanismus zur Kontrolle der Vervielfältigung. Keines dieser drei Kriterien ist erfüllt.



    Zweitens gilt § 95a für Computerprogramme grundsätzlich nicht. Das ergibt sich aus Artikel 1 Abs. 2 der InfoSoc-Richtlinie 2001/29/EG sowie Erwägungsgrund 50 derselben. Für Software gilt das Sonderregime der §§ 69a ff. UrhG sowie Artikel 7 der Richtlinie 2009/24/EG. Artikel 7 schützt jedoch ausschließlich gegen kommerzielles Inverkehrbringen von Umgehungsmitteln deren einziger Zweck die Umgehung ist, nicht gegen das private Löschen einer Datei durch einen lizenzierten Endnutzer.



    Drittens ist die Einordnung der Assets unter § 2 Nr. 7 UrhG als "Darstellungen wissenschaftlicher oder technischer Art" falsch. Der Gesetzestext nennt als Beispiele ausdrücklich Zeichnungen, Pläne, Karten, Skizzen, Tabellen und plastische Darstellungen, also zweckgebundene wissenschaftlich-technische Dokumentation. Kreative 3D-Bahnhofsmodelle für einen Spielsimulator fallen nicht darunter, sondern allenfalls unter § 2 Nr. 4 UrhG als Werke der angewandten Kunst, mit der zusätzlichen Voraussetzung einer persönlichen geistigen Schöpfung nach § 2 Abs. 2 UrhG.



    Ein Punkt blieb in deiner Antwort vollständig unbeantwortet: Wer ist hier eigentlich der Adressat der urheberrechtlichen Vorwürfe? Die Anleitung richtet sich an Endnutzer mit gültiger Lizenz die eine Datei auf ihrem eigenen System löschen. Diese Endnutzer haben weder Assets vervielfältigt noch verbreitet noch Quell- oder Objektcode verändert. Sie haben auch keinen kryptografischen Hash manipuliert oder Signalobjekte auf einer Strecke platziert. Sie haben lediglich eine Datei aus einem Verzeichnis entfernt. Selbst wenn man allen drei deiner Argumente hypothetisch folgen würde, träfen sie den Freeware-Kartenersteller der Assets ohne Erlaubnis verwendet und keine GeoSignal-Objekte auf seiner Karte platziert hat, nicht den Endnutzer der schlicht sein legitim erworbenes Produkt auf seinem eigenen System nutzen möchte. Das Rechtsproblem besteht zwischen virtualTracks und dem Kartenersteller. Der Endnutzer ist in dieser Auseinandersetzung der unbeteiligte Dritte der die Konsequenzen eines Konflikts trägt den er nicht verursacht hat.

    • Neu

    PlanZ vielen Dank für die Replik. Schöner Argumentationsgang, aber du ziehst hier falsche Schlüsse aus den zitierten Urteilen, um eine scheinbare Entlastung zu konstruieren. Mein Standpunkt bleibt rechtlich eindeutig und wird durch deine Argumentation nicht entkräftet:

    1. Das Missverständnis zum Sony-Urteil und der Umarbeitung: Der BGH und der EuGH haben im Sony-Fall nur deshalb keine Umarbeitung gesehen, weil der Code auf dem Datenträger zu 100 % unangetastet blieb und nur RAM-Variablen flüchtig verändert wurden. Wer eine essenzielle Binärdatei (.out) dauerhaft von der Festplatte löscht, greift direkt in den herstellereigenen Objektcode ein. § 69c Nr. 2 UrhG nennt neben der Bearbeitung ausdrücklich "andere Umarbeitungen". Das gezielte Entfernen einer logischen Kontrolldatei, um das Ablaufverhalten des verbleibenden Programms grundlegend zu verändern, ist eine solche unzulässige Umarbeitung. Der Vergleich mit Plugins hinkt: Plugins nutzen vom Entwickler vorgesehene Schnittstellen, das Entfernen einer Schutzdatei hebelt diese aus.
    2. Der Schutz der Assets durch die "Nintendo-Rechtsprechung" (EuGH C-355/12): Dein Einwand, § 95a UrhG gelte für Software nicht, greift zu kurz. Nach der wegweisenden "Nintendo-Rechtsprechung" des EuGH (Rechtssache C-355/12) fallen technische Schutzmaßnahmen in einer Software unter das strengere Regime des allgemeinen Urheberrechts (§ 95a UrhG), wenn sie dazu dienen, den unautorisierten Zugriff auf andere geschützte Werke - wie hier die grafischen 3D-Modelle und Texturen - zu verhindern. Der EuGH betont in diesem Urteil zwar die Verhältnismäßigkeit, aber genau die ist hier gegeben: Die Sperre schützt die Assets vor einer konkreten Urheberrechtsverletzung (der unlizenzierten Nutzung in einem Fremdprojekt). Eine technische Maßnahme ist gesetzlich wirksam, wenn sie im normalen Betriebsablauf die unberechtigte Nutzung unterbindet. Ein automatisierter Programmabsturz verhindert die Nutzung der Assets auf der unlizenzierten Map effektiv. Ob man die aufwendigen Bahnhöfe nun als Werke der angewandten Kunst nach § 2 Nr. 4 UrhG oder anders einordnet, ändert nichts daran: Sie sind urheberrechtlich geschützt und unlizenziert nicht frei nutzbar.
    3. Die Adressaten-Frage: Natürlich liegt die primäre Urheberrechtsverletzung beim Kartenersteller, der die Assets ohne Freigabe verbaut hat. Aber darum geht es bei der Warnung vor Haftungsrisiken nicht. Die Anleitung im Thread fordert den Endnutzer aktiv dazu auf, eine wirksame technische Schutzmaßnahme auf seinem System zu umgehen, um diese unlizenzierten Inhalte überhaupt erst lauffähig zu machen.
    Wir sehen an unserem Austausch sehr gut, das IT-Urheberrecht ist ein absolutes Minenfeld, bei dem sich selbst absolute Experten streiten. Bitte lass uns aber den Thread hier nicht weiter behelligen, da diese Diskussion für den "Mainstream-Nutzer" nun vermutlich endgültig zu trocken und theoretisch wird (und virtualTracks den Schutz mit Version 1.21 ohnehin entfernt). Weitere juristischen Details können ja gerne per PN weiter ausgefochten werden.
    • Neu

    Ich finde, man sollte mal ein gesondertes Thema dazu eröffnen! Zum einen, weil es komplex ist, und gerade auch interessant was es alles zu beachten gibt wenn es um Urheberrecht geht, bei Repaint und Streckenupgrade. Aus dem Grund meine ich, das für so etwas ein gesondertes Thema eingerichtet wird, wo sich auch Leute die sich da juristisch auskennen, austauschen. Was für die Mehrheit auch informatiev ist, um was es da geht und auch sensibilisiert.

    • Neu
    Zitat von DennyW

    Ich finde, man sollte mal ein gesondertes Thema dazu eröffnen! Zum einen, weil es komplex ist, und gerade auch interessant was es alles zu beachten gibt wenn es um Urheberrecht geht, bei Repaint und Streckenupgrade. Aus dem Grund meine ich, das für so etwas ein gesondertes Thema eingerichtet wird, wo sich auch Leute die sich da juristisch auskennen, austauschen. Was für die Mehrheit auch informatiev ist, um was es da geht und auch sensibilisiert.

    Eigentlich eine gute Idee.

    komax

    Punkt 1: "Umarbeitung und Sony-Urteil"


    Das Löschen einer Datei ist kein Eingriff in Objektcode sondern das Entfernen von Objektcode. Das sind rechtlich zwei völlig verschiedene Handlungen, und genau diese Unterscheidung ist entscheidend. Der verbleibende Code des Addons bleibt nach dem Löschen vollständig und unverändert auf der Festplatte. Kein Byte wird modifiziert, überschrieben oder ergänzt. BGH I ZR 157/21 ist zwar kein direkter Präzedenzfall für das Löschen einer Datei, dort ging es um RAM-Variablen, aber das Urteil gibt das maßgebliche Prinzip vor: Geschützt sind nur Elemente die die Vervielfältigung oder spätere Entstehung des Programms ermöglichen. Der GeoReader ermöglicht weder das eine noch das andere. Und § 69c Nr. 2 UrhG erfordert bei "anderen Umarbeitungen" nach dem Auslegungsgrundsatz ejusdem generis dieselbe Qualität wie Übersetzung, Bearbeitung und Arrangement - allesamt aktive Gestaltungshandlungen die ein Ergebnis produzieren das vervielfältigt werden kann. Das Löschen produziert kein solches Ergebnis. Anzumerken ist außerdem dass die Anleitung alternativ auch das bloße Umbenennen der Datei beschreibt. Damit bleibt die Datei vollständig erhalten. Kein Code wird verändert, kein Code wird entfernt. Der § 69c Nr. 2-Vorwurf einer Umarbeitung ist damit in dieser Variante noch weniger haltbar.


    Punkt 2: "Nintendo-Rechtsprechung und § 95a"


    Das Nintendo-Urteil wird hier grundlegend falsch interpretiert. Der EuGH hat in Rn. 23 des Urteils C-355/12 erklärt dass Directive 2009/24 als lex specialis den Schutz auf Computerprogramme beschränkt. Nintendo-Videospiele fielen dennoch unter Directive 2001/29 und damit § 95a weil sie keine reinen Computerprogramme sind sondern zusätzlich "grafische und klangliche Bestandteile umfassen, die, auch wenn sie in einer Computersprache kodiert sind, eigenen schöpferischen Wert besitzen, der nicht auf diese Kodierung beschränkt ist." Genau dieser eigene schöpferische Wert der grafischen und klanglichen Bestandteile war der tragende Grund für die Anwendbarkeit von § 95a.


    TTB_FM_GeoReader_JWD.out enthält ausschließlich Lua-Bytecode zur Geofencing-Logik. Es gibt keine grafischen oder klanglichen Bestandteile die einen eigenen schöpferischen Wert besitzen der über die Kodierung hinausgeht. Es ist ein reines Computerprogramm. Nach der präzisen Logik von Rn. 23 des Nintendo-Urteils gilt damit ausschließlich Directive 2009/24 und § 95a ist nicht anwendbar.


    Unabhängig davon enthält die Antwort eine falsche Rechtsdefinition. Dort steht: "Eine technische Maßnahme ist gesetzlich wirksam, wenn sie im normalen Betriebsablauf die unberechtigte Nutzung unterbindet." Das ist nicht was § 95a Abs. 2 Satz 2 UrhG sagt. Der Gesetzestext definiert Wirksamkeit abschließend durch drei konkrete Kriterien: eine Zugangskontrolle, einen Schutzmechanismus wie Verschlüsselung, Verzerrung oder sonstige Umwandlung, oder einen Mechanismus zur Kontrolle der Vervielfältigung. Ein Absturztimer der nach 60 Sekunden auslöst wenn der GPS-Sensor eine fremde Strecke erkennt erfüllt keines dieser drei Kriterien. Die Assets werden vollständig geladen und gerendert. Es gibt keine Zugangskontrolle. Es findet keine Verschlüsselung oder Umwandlung statt. Es wird keine Vervielfältigung kontrolliert. Eine eigene Definition die schlicht "unberechtigte Nutzung unterbinden" lautet genügt dem Gesetzestext nicht.


    Schließlich kommt das Verhältnismäßigkeitsprinzip das der EuGH in Nintendo Rn. 31 selbst aufstellt: Technische Maßnahmen dürfen nicht über das zur Zielerreichung Erforderliche hinausgehen. Der GeoReader prüft nicht ob eine Urheberrechtsverletzung vorliegt. Er prüft ausschließlich ob bestimmte Signalobjekte auf der Strecke vorhanden sind und ob der GPS-Check positiv ausfällt. Damit trifft er unterschiedslos jeden lizenzierten Käufer der die Assets auf einer anderen Karte verwendet, sei es eine öffentliche Freeware-Karte, eine private Eigenkreation oder ein kommerzielles Projekt. Ob dabei eine Urheberrechtsverletzung vorliegt ist für den Mechanismus vollständig irrelevant. Das geht weit über das zur Zielerreichung Erforderliche hinaus.


    Punkt 3:

    Dieses Argument setzt voraus dass der GeoReader eine wirksame technische Schutzmaßnahme im Sinne des § 95a ist. Genau das wurde jedoch widerlegt: Der GeoReader erfüllt keines der drei abschließenden Wirksamkeitskriterien des § 95a Abs. 2 Satz 2 UrhG, und nach Rn. 23 des Nintendo-Urteils gilt § 95a für reine Computerprogramme ohnehin nicht. Wer eine nicht wirksame und nicht anwendbare Schutzmaßnahme entfernt begeht keine Urheberrechtsverletzung - die Prämisse des Haftungsarguments entfällt damit vollständig.


    Selbst wenn man § 95a hypothetisch anwenden würde, steht dem Abs. 1 das fehlende subjektive Element entgegen. Der typische Endnutzer der diese Anleitung liest, sieht einen Crash nach 60 Sekunden und eine Lösung die diesen behebt. Er hat keine Kenntnis von Geofencing, GPS-Validierung oder einem als Schutzmaßnahme konzipierten Mechanismus. § 95a Abs. 1 setzt jedoch voraus dass dem Handelnden bekannt ist oder bekannt sein muss dass er eine Schutzmaßnahme umgeht um Zugang zu einem geschützten Werk zu ermöglichen. Das ist bei einem Endnutzer der schlicht einen technischen Fehler behebt nicht der Fall.


    Der eigentliche Kern des Arguments lautet: Die Anleitung ermöglicht die Nutzung einer Freeware-Karte auf der der Kartenersteller Berlin JWD-Assets ohne Erlaubnis verbaut und veröffentlicht hat. Die urheberrechtlich relevante Handlung des Verbreitens und öffentlichen Zugänglichmachens liegt ausschließlich beim Kartenersteller. Der Endnutzer der die Karte spielt verbreitet keine Assets und macht sie nicht öffentlich zugänglich. Eine allgemeine Pflicht zur Prüfung der Lizenzlage aller in einem Fremdprojekt verwendeten Assets legt das Urheberrecht dem Endnutzer nicht auf. Relevant wäre allenfalls positive Kenntnis des Nutzers von einer konkreten Rechtsverletzung - die bloße Möglichkeit, dass Assets möglicherweise unlizenziert sind begründet keine Haftung.


    Selbst wenn man alle Prämissen des Arguments hypothetisch akzeptieren würde, bleibt das entscheidende Problem: Eine Anleitung zur Urheberrechtsverletzung setzt voraus dass die beschriebene Handlung eine Urheberrechtsverletzung ist. Das ist sie nicht.

    Naja, jetzt hat es sich sowieso erledigt. War dennoch eine interessante Diskussion :)

    Einmal editiert, zuletzt von PlanZ () aus folgendem Grund: Ein Beitrag von PlanZ mit diesem Beitrag zusammengefügt.

  • _EinfachEric_

    Hat das Label von in Entwicklung auf eingestellt geändert.
    • Neu

    Da merkt man leider, das die Menschheit nicht lesen kann, schreiben fällt ihr schon die ganze Zeit schwer... Schrecklich, wenn Leute es nicht verstehen und nicht mal abwarten können, was beide Parteien sagen.


    Jetzt hat _EinfachEric_ das Projekt eingestellt und man kann sich nur bedanken, bei allen hier.. Ich finde alle beide Hersteller machen eine sehr tolle Arbeit. Ich hoffe inständig, das es doch irgendwann komplett wird.


    Sage aber erstmal einen großen Dank an bahnjan und _EinfachEric_ , Danke das es euch gibt und ihr Die Geduld habt, solche Werke zu schaffen. Danke :verneigen:



    *lok*