Mag je Legend of Zelda decompileren en een bitwise identieke versie maken?

aerozol / Pixabay

Het Zelda Reverse Engineering Team meldt dat ze vrijwel klaar zijn met het decompileren van de binaries van The Legend of Zelda: Ocarina of Time voor de Nintendo 64. Dat las ik bij Tweakers vorige week. Nintendo is fel tegen fanprojecten zoals ports van hun games naar andere platformen, zo voegt men daaraan toe. Toch meent dit project legaal te opereren binnen het auteursrecht, wat natuurlijk de vraag oproept hoe dat dan zit met decompileren, namaken en porten van software.

Legend of Zelda is een klassieke serie voor Nintendo-gamers, en Ocarina of Time (1998) de bekendste uit de reeks. Het spel was echter nooit beschikbaar voor moderne computers, totdat dus deze groep enthousiaste programmeurs haar decompilatie voltooide. De binaries (de machine-leesbare code van het programma) zijn via decompilatie terugvertaald naar broncode, die door mensen, althans programmeurs, gelezen en aangepast kan worden.

Punt is alleen dat dat aanpassen (en het produceren van nieuwe binaries) inbreuk op auteursrecht is. Maar het RET doet dan ook iets anders: ze vogelen uit wat de N64 binaries doen, en schrijven dan zelf broncode die na compilatie datzelfde doet. Dat is géén inbreuk op auteursrechten, want achterhalen wat iets doet is legaal, en in je eigen woorden dat navertellen is dat ook.

Deze nieuwe code is dus een soort van spirituele kloon: hij doet hetzelfde, maar op een eigen manier en zonder code van Nintendo over te nemen. Maar daarmee is men er nog niet:

But even though the game’s code has been fully decompiled, there’s still a lot of remaining work for the ZRET team including creating documentation, re-naming and re-organisation of code and definitions, and support for asset-handling so viewing or modifying on modern computers is easier.
Zodra je natuurlijk originele beelden van personages (of achtergronden of andere assets) uit het spel gaat overnemen, trap je alsnog in de auteursrechtinbreuk. Ik ben benieuwd hoe ze dat gaan oplossen.

Ook heel benieuwd ben ik naar hun reden om te gaan voor een bit-for-bit identieke binary als uitkomst, in plaats van enkel een functioneel identiek spel. Want hun streven is dus echt om hun eigen code zo te maken dat deze na compilatie en linken (haha) exact uitkomt op dezelfde nullen en enen als het origineel van Nintendo. Dat voelt voor mij als een moeilijke manier om een kopie van die nullen en enen te maken, en dat is inbreuk. Maar het zal wel een hoger artistiek doel dienen?

Arnoud

8 reacties

  1. Ocarina of Time is ook erg populair bij speedrunners. Een van de grootste trucjes (glitches) die zij kunnen doen is SRM. Hierbij is de volgorde van alle objecten in het geheugen erg belangrijk omdat men rechtstreeks waardes in het geheugen zit aan te passen. Als je deze en andere trucjes hetzelfde wilt laten werken als in de N64, dan zal je definitie van “functioneel identiek” een heel stuk strenger moeten zijn. Bit-for-bit klinkt dan niet meer zo onredelijk, je weet dan zeker dat alle trucjes even moeilijk zijn, dat alle trucjes het nog steeds doen en dat er geen nieuwe geïntroduceerd zijn. Beide versies kunnen dan in dezelfde leaderboard staan.

    Voor mensen die meer van over SRM (en ACE, een vergelijkbare maar nog groter trucje) willen weten, verwijs ik door naar deze uitleg: https://www.youtube.com/watch?v=wdRJWDKb5Bo

  2. Zodra je natuurlijk originele beelden van personages (of achtergronden of andere assets) uit het spel gaat overnemen, trap je alsnog in de auteursrechtinbreuk. Ik ben benieuwd hoe ze dat gaan oplossen.

    Er zijn in het verleden meer spellen op dezelfde manier opnieuw uitgebracht door hobbyisten. Bijvoorbeeld Transport Tycoon. Hier hebben de hobbyisten opnieuw alle code geschreven om het spel zo goed mogelijk na te maken. De diverse assets leverden ze echter niet mee, maar de nieuwe versie bevatte de mogelijkheid om de assets van een originele installlatie-bron te kopieren en te gebruiken. Zo was het voor mensen die het origineel hadden dus mogelijk om de nieuwe versie te spelen. Later zijn er ook open source equivalenten van de assets gemaakt, waardoor het spel ook speelbaar werd voor mensen die het origineel niet hadden.

    Een dergelijke oplossing is voor OoT wellicht lastiger, omdat het origineel op een ander platform werkt dan de nieuwe versie. Maar het zou best kunnen dat men kijkt naar het produceren van een versie waarbij de assets simpelweg nog moeten worden ingevuld.

    1. Maar in het geval van OpenTTD bijvoorbeeld ging het niet om een bit-voor-bit identieke binary. Daar hebben ze bewust de game engine opnieuw gemaakt zodat die op SDL draait, en er uiteindelijk veel meer functionaliteit aan toegevoegd.

      Dat zie ik hier niet gebeuren. Als het een bit-voor-bit gelijke binary zou zijn, dan gaat het argument van ‘porten voor moderne platformen’ het raam uit. Een PC met Windows is nog altijd geen N64 met een MIPS processor. En je zou na decompilen van de binary die je net met heel veel pijn en moeite gemaakt hebt, nog altijd uitkomen op dezefde decompiled broncode als je uit een originele OoT binary haalt. Het argument ‘auteursrecht’ vervalt echt niet spontaan als je in je decompilatie ‘__int_x8f4d9’ vervangt door ‘CurrentLevelEnemyCount’.

      Een loophole om auteursrechtclaims te kunnen omzeilen is dit dus zeker niet. Hooguit dat je zoiets doet ‘omdat het kan’ en om de programmeerprincipes van Nintendo te doorgronden (vooral in Ocarina of Time zit bizar veel optimalisatie) maar aan de uiteindelijke binary heb je dan vrij weinig. Dat is een gegeven wat je (als het goed is) namelijk al hebt.

    1. De vraag is of het verhaal onderdeel is van de code!

      Dat is namelijk verre van normaal, zelfs in het C64/Amiga tijdperk had je al Scripting Utility for Maniac Mansion (SCUMM).

      Een herimplementatie van de scripting engine die dezelfde scripts kan lezen en uitvoeren is al jaren verkrijgbaar en volkomen legaal: ScummVM. Noch assets, noch verhaal is onderdeel van de enigine. Je kan zelfs je eigen adventure maken met een custom ‘javascript’ en ScummC compileert dat naar de bytecode die SCUMM/ScummVM uit kan voeren.

      Wat mij meer verbaasd is dat een eerder artikel dat ik las het had over decompileren en de gedecompileerde code aanpassen (herordenene, variabelen zinnige namen geven) om het leesbaar te maken. Dat is geen herimplementatie, dat is een direct afgeleid werk. OOk al gebruik je geen enkele game asset.

        1. Dat is klassieke clean room reverse engineering. Helemaal eens dat daar geen auteursrechten issues uit komen.

          Ik heb nu dus twee verhalen die elkaar tegenspreken, moet ik zelf maar even op onderzoek uit hoe ze het precies gedaan hebben.

        2. Dat gaat dus echt alleen als je alléén de functionele aspecten van een programma of game meeneemt. Je krijgt dan een ‘generieke’ Ocarina of Time-engine die hetzelfde spel oplevert als je er de originele assets in duwt. En dat is een vrij veel voorkomende manier om bekende spellen (Transport Tycoon, Command & Conquer, Half-Life, Quake 3 Arena) te porten naar moderne platformen.

          Als je als doelstelling hebt om een identieke binaire executable te krijgen als het origineel, dan is die executable dus zélf de specificatie. En dan is je decompiled broncode niets anders dan een andere representatie van hetzelfde werk.

          “Het verhaal”, dus het plot van het spel, reken ik in dit geval onder de assets. En of het abstracte verhaal van “The Legend of Zelda” op zich beschermd is door auteursrecht is maar de vraag, dat is meer een kwestie van merkenrecht.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.