Fans zijn vrijwel klaar met decompileren binaries Zelda: Ocarina of Time

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. Ze schrijven voor mensen leesbare code, wat de opmaat naar mods, hacks en ports voor de game zal zijn.

Dat meldt Video Games Chronicle op basis van contact met het Zelda Reverse Engineering Team. De laatste pull request staat klaar om opgenomen te worden in de main branch nadat de gemeenschap van ontwikkelaars hun inspectie hebben gedaan. Daarna zal de volledige broncode van de game nagebootst zijn, vrijwel volledig in de programmeertaal C. De versie van de game die ze gebruiken, is de debugversie van OoT Master Quest PAL voor de GameCube, aldus hun website.

Het decompileren van de binaries is een enigszins genuanceerde kwestie. Nintendo is fel tegen fanprojecten zoals ports van hun games naar andere platformen. Dat is dan ook niet wat dit ontwikkelteam doet. Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo. De beschikbaarheid van deze broncode maakt het echter wel zeer goed mogelijk om de game te porten naar bijvoorbeeld Windows.

Datzelfde gebeurde in 2019 al met Super Mario 64, wat leidde tot een pc-port met ondersteuning voor breedbeeldschermen, een hogere kwaliteit model voor Mario en ondersteuning voor zaken als hogere framerates, DX12 en zelfs raytracing. Nintendo probeert de ports van het internet af te laten halen.

Reacties (101)

[Dograver]

Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo

Wordt daarmee dan bedoeld dat ze geen inbreuk maken op de broncode van Nintendo, want deze is geschreven in een andere taal dan de C die ze nu gebruiken?
Daarmee zijn ze nog niet vrij van het gebruik van de naam Zelda, wat natuurlijk ook eigendom is van Nintendo.

Of zeg ik nu hele gekke dingen?


--edit--

Voorheen GCC (GNU C Compiler), dus ook in C.
https://www.reddit.com/r/...and_n64_games_written_in/

[Reactie gewijzigd door Dograver op 22 juli 2024 17:29]

[Blokker_1999]

Wat ze hier lijken te doen is hetzelfde als de recent aangeklaagde modders die bezig waren met GTA III en VC. In essentie ga je de binaire code door een decompiler gooien, die doet zijn best om opnieuw leesbare code in een bepaalde taal te genereren die, wanneer opnieuw gecompileerd, gelijkaardige instructies zou moeten uitvoeren.

Alleen werkt dat niet 100% en zitten er altijd fouten in. Die moet je er opnieuw uithalen. Daarnaast ontbreekt ook elke vorm van commentaar en meestal ook zinvolle naamgeving waardoor je functies en variabelen moet gaan analyseren van wat ze juist doen en waarvoor ze dienen om zeker te zijn dat alles een goede naam heeft en de werking ervan bekend is.

Grootste probleem is dat je uiteindelijk uitkomt op broncode die vrij dicht bij het origineel aanleunt, zeker als je het eenmaal compileert voor hetzelfde platform hoor je gewoon terug hetzelfde eindresultaat te hebben. En daar komt dan weer auteursrecht om de hoek kijken. De broncode op zich is eigendom van Nintendo. Dat die broncode gecompileert is naar, in essentie, machinetaal en je dat nu terug omzet naar leesbare programeertaal maakt dat het in de basis nog altijd de broncode is van Nintendo.

De enige manier waarop je reverse engineering kunt doen slagen vanuit wettelijk oogpunt is door het op de clean room manier te doen. 1 team beschrijft hoe alles zou moeten werken en een ander team implementeert het opnieus. Maar dat vergt enorm veel tijd en werk. Dat doe je niet met een klein team.

[Vampyre]

Grootste probleem is dat je uiteindelijk uitkomt op broncode die vrij dicht bij het origineel aanleunt, zeker als je het eenmaal compileert voor hetzelfde platform hoor je gewoon terug hetzelfde eindresultaat te hebben.

Dit is niet wat hoort en is ook vrijwel onmogelijk.
Het doel van reverse engineering is de functie van een stuk code na te bootsen, niet de daadwerkelijke code.
Daarnaast, een beetje optimizing compiler houd weinig structuur en flow van de originele source code over.
En de originele assembly ga je sowieso al nooit terug krijgen zonder exact de zelfde compiler, toolchain en libraries, ook al heb je de originele source.

[Blokker_1999]

Het doel van reverse engineering is dezelfde functionaliteit bekomen als het origineel. Dat de code er anders uitziet is normaal, maar het idee achter de code, het idee achter hoe iets werkt is uiteindelijk wat we gaan beschermen met auteursrecht. De taal waarin we het implementeren is dus niet belangrijk, de optimalisatie die automatisch wordt toegepast is niet belangrijk, het concept, het idee is wat van tel is.

En ja, wat ik geschreven heb is een immense oversimplificatie, maar vele mensen weten niet eens dat zelfs met exact dezelfde toolchain ga je verschillen bekomen in je uiteindelijke assembly. Reproducible builds zijn zelfs met moderne toolchains moeilijk te maken, laat staan met tools van decennia terug.

[Thralas]

En ja, wat ik geschreven heb is een immense oversimplificatie, maar vele mensen weten niet eens dat zelfs met exact dezelfde toolchain ga je verschillen bekomen in je uiteindelijke assembly. Reproducible builds zijn zelfs met moderne toolchains moeilijk te maken, laat staan met tools van decennia terug.

Maar dit is juist wat ze hier aan het doen zijn: bron

This project is a matching decompilation, which means that it produces a byte-for-byte identical ROM to the supported versions of OoT (which right now is just the MQ debug rom).

Als je in 't GitHub-project kijkt zie je dat ze een IRIX toolchain (waarschijnlijk van een N64 devkit) geëmuleerd met qemu gebruiken om de boel te compileren.

Aangezien de output echt bit-voor-bit identiek is, is dat extra zorgelijk voor eventuele juridische claims.

[Tintel]

is dat extra zorgelijk voor eventuele juridische claims.

idd en ze hebben naast de rechten op de (originele?) brondcode ook nog eens de rechten op de muziek en de figuurtjes in de game... dus dat wordt toch wel een issue vermoed ik.

[bzuidgeest]

volgens mij is dat niet correct. Ik mag prima een rembrand namaken zolang ik niet claim dat het een rembrand is. Als ze zelf code produceren die een resultaat maakt dat gelijk is aan een ander resultaat is dat niet strafbaar. nintendo heeft geen rechten op de C taal of de C compiler. Voor verschillende variaties van input X komt daar altijd resultaat Y uit. Niet omdat de input code gelijk is maar omdat de compiler voor algoritme X altijd op hetzelfde resultaat uitkomt omdat dit nou eenmaal het efficienste is.

Zolang ze een scheiding hebben aangebracht via documentatie tussen het decompilatie team en het implementatie team zijn ze safe. Dit is ook hoe compaq destijds de eerste IBM clone pc maakte. 1 team decompileerde en documenteerde de IBM Bios en een ander team gebruikte die documentatie om vervolgens alles opnieuw te implementeren. IBM kon compaq niets maken.

Dus zolang ze het proces goed inrichten zijn ze juridisch veilig. Tenzij ze ook game content gaan distribueren, maar dat is iets heel anders.

[Tintel]

Meneer Rembrand heeft zijn werk dan ook niet laten vastleggen en wat je noemt is een 'one-off' - elk schilderij is uniek (wel dezelfde stijl van schilderen).

"Mario" is bijv. als figuurtje vastgelegd (qua kleuren en vorm). Dat geldt vast ook voor de figuren van Legend of Zelda. Maar misschien komen ze er mee weg als ze hem dikker maken en ander kleurtje geven of zo.

[bzuidgeest]

Mario en Zelda zijn game content resources. Deze worden bij herimplementatie van een engine niet gekopieerd of gedistribueerd of opnieuw gemaakt. Een engine die uit de originele resources een plaatje afbeeld bevat niet dat plaatje. Jij stel een word document gelijk aan word zelf. Dat is gewoon niet de zaak.

[Tintel]

Maar het model is toch niet alleen een plaatje? Het is een model dat kan interacten met de rest van de game-wereld. En juist dat interacten bepaald in grote mate het 'spel'. En dat wel degelijk onderdeel van de programma.
In de tijden van de Doom (1&2) waren het idd bitmaps die in een bepaalde volgorde werden getoond en afhankelijk van een richting een ander plaatje lieten zien.
Dat zijn deze games toch niet?

Een game-engine is niet gelijk aan Word als programma waarbij daarna een file wordt geladen die wordt afgebeeld. Al lijkt dat conceptueel wel een beetje op elkaar. Maar een word-document intypen is niet programmeren... Zo zitten de meeste games (nog?) niet in elkaar.

[bzuidgeest]

Een model is ook niet de applicatie of de engine. een model is niet anders dan een bitmap. Data die word geïnterpreteerd door een engine. Niet anders dan dat autocad een model kan openen en manipuleren. Veel engines gebruiken gewoon dezelfde format voor hun modellen als wat de 3D design programma's als output hebben en dus ook weer kunnen openen.

Omdat programmeurs een hekel hebben aan dingen twee keer doen is interactie vaak via scripts ook weer in de content resources weggestopt (quake engine, unreal engine etc). De engine bevat alleen een interpreter. Een vroeg voorbeeld hier van zijn de siërra adventures als space quest, kings quest etc... Allemaal hetzelfde programma met andere content. Dat het nu een 3d model is in plaats van een plaatje veranderd daar niets aan.

Gewoon omdat iets complexer is dan een paar jaar geleden maakt het niet fundamenteel anders. Dat jij denkt dat een game-engine niet gelijk is aan word als programma, maakt duidelijk dat je een paar concepten mist. Het punt is dat er een scheiding ligt tussen de content en het de engine die content interpreteert. Word is de engine die word documenten interpreteert. De game zijn engine interpreteert modellen, bitmaps scripts etc etc... en geeft daar leven aan.

Dus ja veel games gebruiken dezelfde engine. De quake, unreal, doom engine. etc etc. zijn allemaal te krijgen in licentie. Het enige dat de studio hoeft te doen is scripts te maken en modellen toe te voegen (simplificatie, bij AAA games is dat een hoop werk)

[Tintel]

Ik mis geen concepten... Jij stelt dat mensen die een Word-document maken hetzelfde doen als mensen die een game-engine gebruiken om een game te maken.

Een model binnen een game (van bijv. de player) is toch echt wel meer dan een bitmap.

Een game engine werkt niet als interpreter. Het 'rendert' geen games. Dat het modellen en werelden rendert betekent niet dat de hele game op die manier wordt uitgevoerd.
Een game-engine is een stapel API's en die worden gebruikt door een weer andere programeer-taal (zoals vaak C++). Een Word-document is dat zeker niet.
Jij noemt scripts in 1 adem met game engines maar zo werkt dat niet volgens mij - dat noemen we geen scripts maar routines en die worden vrijwel altijd gecompileerd en niet geinterpreteerd.

Dat een game content heeft dat betwist ik niet. Ik stel dat het moeilijk zal zijn een game te maken die gebaseerd is op de bron-code van Zelda waarbij je niet ook minstens een deel van die content nodig hebt en daar wringt de schoen wat betreft de juristen van Nintendo.
Maar goed; misschien worden totaal nieuwe resources eraan toegevoegd, dat weet ik natuurlijk niet.

[bzuidgeest]

Ik mis geen concepten... Jij stelt dat mensen die een Word-document maken hetzelfde doen als mensen die een game-engine gebruiken om een game te maken.

Dat doen ze ook. Ze maken content met gebruikmaking van een platform. Game of document dat maakt niet uit.

Een game engine werkt niet als interpreter.

Zie zork, de sierra game line. Zo ongeveer elke 3d engine van dit moment. Unity 5 en c# scripting etc etc.

Een game-engine is een stapel API's en die worden gebruikt door een weer andere programeer-taal (zoals vaak C++). Een Word-document is dat zeker niet.

Een word document kan macros bevatten. Word zelf kan worden ge-embed in code of de libraries kunnen worden geintegreerd in ander applicaties. Zelfs word heeft een API.

Jij noemt scripts in 1 adem met game engines maar zo werkt dat niet volgens mij - dat noemen we geen scripts maar routines en die worden vrijwel altijd gecompileerd en niet geinterpreteerd.

En wanneer gebeurd dat? en waar gaat het resultaat heen? Het word geen onderdeel van de engine. bij precompilatie komt het al een "plugin" een extra dll of zo. Het word geen onderdeel van de engine. Zelfde bij JIT compilers in de engine. Dan is het script totdat de engine zijn compiler het omzet. Het word nooit onderdeel van de aangeleverde engine. Wat jij het noemt is niet echt interessant. Mensen in IT slachten tegenwoordig continue concepten en benamingen. Door alle tussen lagen weet een grote groep nauwelijks meer wat ze werkelijk doen en waar de grenslijnen liggen. Concepten en overview worden bedolven onder marketing hype termen om te kunnen doen alsof er iets werkelijk nieuws is. Newsflashs: Er is in programmeer land de laatste jaren niets fundamenteels nieuws meer uitgevonden. Op zijn hoogst incrementele verbeteringen. Syntax sugar.

die gebaseerd is op de bron-code van Zelda waarbij je niet ook minstens een deel van die content nodig hebt en daar wringt de schoen wat betreft de juristen van Nintendo.

De content heb je al als je de game legaal hebt aangeschaft. Het staat jou vrij die te combineren met een nieuwe executable. Dat is niet strafbaar. Die nieuwe executable kan voordelen hebben die de oude niet had. De nieuwe bevat geen content. Dus is vrij te distribueren.
De juristen van Nintendo hebben alleen een poot om op te staan als het geen cleanroom herimplementatie is. Dat is al duidelijk gemaakt tig jaar geleden in compaq vs IBM over de IBM bios. die jurisprudentie staat nog steeds.

[Tintel]

Een word document kan macros bevatten. Word zelf kan worden ge-embed in code of de libraries kunnen worden geintegreerd in ander applicaties. Zelfs Word heeft een API.

Dat is waar maar toch heb je het over een ander concept dan het gebruik van een game-engine om een game te maken. Het Word-document bevat namelijk geen directe API calls alleen hoogstens wat macro-code. De game is vaak geen los bestand die door een game-engine wordt ingelezen (kan wel natuurlijk maar dan heb je over een ander soort games). Daarnaast gebruikt een game soms meer dan alleen die game-engine en zijn er nog andere onderdelen nodig (zoals bijv. helaas copy-protection). Andere onderdelen zoals specifieke controller support kunnen ook elders worden betrokken.

Het word geen onderdeel van de engine. Zelfde bij JIT compilers in de engine. Dan is het script totdat de engine zijn compiler het omzet.

Nee, natuurlijk geen onderdeel van de engine. Het is andersom; er wordt een programma aangeleverd die de engine gebruikt. En we noemen dat geen 'script' als het door een JIT compiler wordt omgezet maar 'source-code' en als dat C++ of C# is dan noemen we dat ook geen script. Die term is echt wel voorbehouden aan interpreter systemen. We hebben het echt wel over 'C-code' en niet 'C-script'.

In programmeer land wordt wel degelijk nog wel wat nieuws uitgevonden natuurlijk. Al zijn het misschien veranderingen die een andere taal al had of betreft het enkel een systeem wat de compiler in staat stelt om bepaalde programmeer fouten te herkennen. enz. Incrementele verbeteringen zijn toch wel 'nieuw' te noemen? Dat het misschien niet fundamenteelk anders is, tja. Wellicht wel voor quantum computers omdat die fundamenteel verschillen in de basis.

De content heb je al als je de game legaal hebt aangeschaft. Het staat jou vrij die te combineren met een nieuwe executable.

Daar had ik niet bij stil gestaan. Dat is inderdaad een mooie uitweg.

[bzuidgeest]

Incrementele verbeteringen zijn toch wel 'nieuw' te noemen? Dat het misschien niet fundamenteelk anders is, tja. Wellicht wel voor quantum computers omdat die fundamenteel verschillen in de basis.

Alleen voor de marketing afdeling. De rest is technisch niets nieuws. De uitvoering kan makkelijke gemaakt zijn, je kunt wellicht wat meer bereiken met minder code, maar er is niets fundamenteel nieuws. Quantum computers zouden wellicht kwalificeren als nieuw, maar daar hebben we het niet over. Elke taal kan in basis alles, zolang deze turing complete is.
Maar dat nieuw probleem is niet uniek aan computers. Auto's is ook niets fundamenteel nieuws aan. De eerste auto was electrish, maar onpraktisch dus dat is niet nieuw. Verbrandings motoren waren makkelijker, maar ook toen we die eenmaal als concept hadden is daar niets meer principieel aan veranderd. We optimaliseren nog wel en we vinden nog wel eens betere algoritmes. Maar die algoritmes kunnen in iedere taal geimplementeerd worden. Dus je kunt op zijn hoogst zeggen dat wiskunde verbeterd.

alleen die game-engine en zijn er nog andere onderdelen nodig (zoals bijv. helaas copy-protection).

Zowel word als word documenten hebben copy protection functionaliteit dus ook die vlieger gaat al niet eens op.

Ik vermoed dat ik je niet ga overtuigen. Maakt niet uit. Ik ga je alleen nog adviseren om soms eens een stapje verdere achteruit te doen zodat je een bredere blik kan werken. Gewoon omdat iets er zo heel anders uit ziet wil niet zeggen dat het fundamenteel of principieel anders is. Een programmeur die een game engine kan maken kan een editor maken. Beide zijn tools voor genereren en gebruiken van content. Hoe verschillend het doel van die content ook is. Als je alles terug leert brengen tot de basis principes dat is er niets meer dat je tegenhoud om wat dan ook te maken. Hoe zeiden ze dat in de matrix ? "there is no spoon" Labels verbergen de werkelijkheid, maken onderscheid waar geen onderscheid is. maar hebben verbazend weinig betekenis. Ze maken op zijn hoogst communicatie over specialistische toepassingen eenvoudiger. Klinkt wellicht wat filosofisch, maar als je dat eenmaal snapt doe je elke vorm van programmeren in een handomdraai. Zelfde trucje keer op keer op keer ongeacht syntax, taal of platform e.d.

[Reactie gewijzigd door bzuidgeest op 22 juli 2024 17:29]

[Tintel]

Ik vermoed dat ik je niet ga overtuigen.

Ik ben ben bang van niet - want ik begrijp eigenlijk niet goed waarvan je me wilt overtuigen.

maar als je dat eenmaal snapt doe je elke vorm van programmeren in een handomdraai. Zelfde trucje keer op keer op keer ongeacht syntax, taal of platform e.d.

Daar ga ik niet tegenin - is waar. Maar hoe is dat relevant?

Maar om nu het maken van een game gelijk te stellen (dus programmeren met gebruik van een game engine) gelijk te stellen aan het opstellen van een Word-document...
Of bedoel je dat dat Word-document ook syntax gebruik kent en creatieve keuzes?

Het nadeel van het gelijk stellen van het maken van een Word-document en een game is dat dus ook het maken van een beeld hetzelfde is. Je gebruikt gereedschap en creativiteit om een object te 'scheppen'.

Terwijl voor al deze activiteiten het wel degelijk noodzakelijk om een bepaalde expertise te bezitten. En daar komt bij dat ook de gemiddelde tijdsduur om een dergelijke creatie op te zetten enorm verschilt Even ervan uitgaan dat het een Word-document is en geen boek van 1 miljoen pagina's. Natuurlijk kun je ook beelden maken op de schaal van Mount Everest - duurt ook langer.

Als jouw punt is dat games maken niets meer is dan het gebruik van gereedschap en creativiteit dan ben ik het met je eens.

Als we dus weer terug naar de originele topic gaan:

• een game kun je namaken door alles wat er gebeurt op het scherm (n.a.v. user-input) hetzelfde laten uitzien (met dus andere onderliggende code).
• Een Word-document vertelt een verhaal / geeft informatie en dat kan ook in andere bewoordingen worden verteld

Maar de effort voor het namaken van een game ligt veel hoger vanwege het dynamische aspect. Het Word-document kent hoogstens wat dubbelzinnigheden maar is behoorlijk statitisch.

[bzuidgeest]

Het belangrijkste wat ik probeerde te bereiken met mijn uitleg is een duidelijk onderscheid tussen content en functionele code. En dat ook functionele code in principe weer content kan zijn op iets anders (bijvoorbeeld plugins).
Content of dat nou bitmaps zijn of modellen (stappels vertices en vectors) of iets anders maakt helemaal niets uit. De "engine" van nintendo weet hoe hij deze data op het beeld moeten krijgen of er geluid van moet maken of wat dan ook. (er is ook nog kans dat nintende de engine in licentie heeft genomen en dan is het helemaal niet hun ding) Dat doet hij op basis van een specificatie. Je kunt prima zelf een engine maken die hetzelfde doet op basis van de specificatie van die content. Als je dat aanhoud bij reverse engineren ben je "safe". Het feit dat de engine op een specifieke manier op user input reageert en onderdelen van de wereld valt niet onder copyright. Of een bepaalde manier daarvan combineren valt onder een creatieve uiting zou kunnen vallen is denk ik geen ding. In basis is het namelijk 2D of 3D allemaal boundary checking en reacties daarop en dat is hoe elke game werkt. Als dat patenteerbaar was of zoiets dan droegen we allemaal geld af aan de ontwerpers van pong tot het einde der dagen.

Gewoon omdat iets ingewikkelder of mooier of groter is betekend ook vaak niet dat er iets nieuws is. Alleen maar dat iets groter en mooier is geworden. 3D is een goed voorbeeld. De modellen zijn technisch niet veranderd sinds de eerste 3d theepot. Wat wel is veranderd is hoeveel anti-aliassing, polygons, meshes etc etc er zijn in een model. Maar dat maakt de techniek niet nieuw. Dat is gewoon een functie van de hoeveelheid computerkracht die wij tot onze beschikking hebben om dit op het scherm te tonen. Elke jaren 80 3D animator had net zo mooi model kunnen maken als vandaag de dag gebruikelijk is. Echter met de CPU's van toen had hij heel lang op de render van een frame moeten wachten en nu kan elke telefoon zo ongeveer het met gemak.

Om terug te gaan naar het oorspronkelijke onderwerp. Zolang deze project groep het scheiden van de specificatie van het geheel scheiden van het opnieuw schrijven van het geheel kan nintendo ze niets maken.Reageren op user input is niet een creatieve uiting. Als dezelfde jongens reverse engineren als herschrijven dan zijn ze de sjaak. De persoon dier herimplementeerd mag niet her origineel zien in clean room opzetten.

Misschien maakt dit het makkelijker. Emulatie van een console is ook niet illegaal. Maar de emulatie doet het gedrag van een console exact kopiëren. Wat wel illegaal kan zijn is de content benodigd voor een emulator, de roms. De roms zijn relatief aan de emulator de content. Snes9x een nintendo emulator noemen of in de docu het woord nintendo gebruiken is ook niet illegaal. Claimen dat het een nintendo product is dat weer wel.

[Tintel]

Maar het vreemde is dus dat emulators wel mogen maar de ROMs nooit - ook al bezit je de game legaal (op cartridge dus).

Overigens zijn modellen van de jaren 80 vermoedelijk niet alleen op polygoon count verschillend. In de eerste instantie waren de textures afwezig en was het enkel een kleur (eventueel met verloop) per vlak. Vervolgens hebben we nu modellen waar zelfs rek&strek in kan worden opgegeven. Daarnaast krijgen we (of hebben we die al?) de 'opvolger' van een polygoon; curves. Want een polygoon model blijft een benadering. Maar ik dwaal af...

Terug naar het oorspronkelijke onderwerp: ik denk dat we een verschillend type engine in gedachten hebben. Ik refereerde aan de generieke game-engines (zoals Unreal) en niet aan de specifieke game engine voor game X. Dat noemen we - voor zover ik weet - dan ook geen engine maar game-code. En ja, als je die nabootst en daarna andere content of de content die je al bezit daarin laadt dan is het legaal.

Dus we hebben het allebei over hetzelfde; namaken mag mits de programma-code niet 1 op 1 wordt overgezet. Alleen beweer ik dat de effort hiervoor niet gering is.

[Adion]

Dat de code er anders uitziet is normaal, maar het idee achter de code, het idee achter hoe iets werkt is uiteindelijk wat we gaan beschermen met auteursrecht.

Voor zover ik weet is dat althans in Europa niet het geval.
Het auteursrecht beschermd een specifiek werk of uitvoering. Je kan met het auteursrecht geen idee beschermen.
Patenten komen het dichtste in de buurt bij het beschermen van ideeen (uitvindingen eigenlijk), maar ik denk dat het niet gebruikelijk is dat er patenten voor bepaalde werking in games worden aangevraagd, en gezien de leeftijd van het spel zouden deze ondertussen toch al vervallen zijn.

[Blokker_1999]

De belangrijkste vraag is: wat is de definitie van een origineel werk. Het gaat niet zozeer om het idee maar om de originaliteit. Net zoals ik van een boek niet zomaar de plot en personages kan nemen en daarmee een nieuw boek schrijven kan ik ook niet zomaar heel een programma zomaar opnieuw schrijven aan de hand van het bestaande programma.

[bzuidgeest]

Heb je enig idee hoeveel boeken minime variaties zijn van andere boeken? Maar zelf dan is het een probleem die vergelijking. Boeken zijn gedefinieerd door de inhoud. Programma's/code is geen inhoud. Het is meer de lijm en de kaft van een boek. Dat ding dat een boek een boek maakt ipv losse blaadjes.

Zoek maar eens op hoe Compaq de eerste IBM PC bios herimplementeerde voor hun pc clone.

kort samengevat. Zolang de herimplementatie word geschreven van een gedocumenteerd resultaat van een analyse van de originele rom/binairy etc. Ofwel het implementatie team krijg alleen te horen hoe de originele implementatie werkte maar die implementatie zelf niet te zien, dan is de nieuwe code origineel werk. Instructie is een taal om een bepaald algoritmisch resultaat te bereiken. En dat kun je niet claimen als van jou. Anders zou niemand meer 1+1 als programma kunnen schrijven omdat iemand anders daar de rechten op heeft.

[dmantione]

Waar gekeken naar wordt zijn de creatieve keuzen die gemaakt zijn: De namen van de variabelen zijn een vrije keus van de programmeur, tot op zekere hoogte is ook de volgorde waarin je bepaalde zaken doet vrije keus voor de programmeur. Of je iets in een subroutine doet of inline, is ook een vrije keus voor de programmeur.

Een onafhankelijk nieuw werk, maakt andere creatieve keuzen dan het originele werk, ook al heeft het dezelfde functionaliteit. Dus om te bepalen of het een onafhankelijk nieuw werk is, kun je systematisch kijken naar de creatieve keuzen die gemaakt zijn en of die verschillen van de creatieve keuzen in het originele werk.

[Tintel]

Of je iets in een subroutine doet of inline, is ook een vrije keus voor de programmeur.

Gedeeltelijk heb je gelijk - maar als het gedecompileerde code is dan is wellicht meer inline geworden vanwege de optimizing compiler die vast wel gebruikt is.
Dus is gedecompileerde code nooit gelijk aan de originele broncode. Namen van variabelen worden niet meer teruggevonden in gedecompileerde code (even aanname dat het c-code betreft). Maar die zijn sowieso vrij gemakkelijk aan te passen. Is dat dan voldoende om 'anders' te zijn?

Het opnieuw schrijven van een routine zonder te oude broncode te gebruiken geeft vaak nieuwe routines. Als je de gedecompileerde code gebruikt waarschijnlijk niet.

Decompilatie bij talen zoals C# is wel anders - daar is veel meer terug te leiden naar de oorsprong.

[dmantione]

Nee, dat is niet voldoende. Ik kan dan als rechthebbende bijvoorbeeld de volgorde van de velden in records aan wijzen, die ook een vrije keus was, maar in beide werken exact gelijk is. De creatieve keuzen (welke ook) moeten voldoende afwijken dat je eventuele overeenkomsten aan toeval kunt toeschrijven. Dat geldt dan bijvoorbeeld ook voor de volgorde van procedures in het geheugen.

Technische keuzen mogen wel gelijk zijn, want beide programma's mogen dezelfde functionaliteit aanbieden. Het auteursrecht beschermt de creativiteit, niet de techniek. De keuze van een sorteeralgoritme is bijvoorbeeld op zich vrij, maar er zijn technische redenen om bijvoorbeeld voor Quicksort te kiezen, dus twee functioneel gelijke programma's die beiden Quicksort implementeren leidt niet tot auteursrechteninbreuk.

Dit betekent min of meer dat een decompilatie nooit genoeg zal afwijken om een nieuw werk te vormen.

[lilmonkey]

Patenten komen het dichtste in de buurt bij het beschermen van ideeen

Juist niet, patenten gaan over specifieke implementaties van ideeën. Een wezenlijk andere implementatie van hetzelfde idee kan dus gewoon afzonderlijk octrooi krijgen.

[Adion]

Klopt, wat ik bedoelde met het oog op software was dan eerder een specifieke werkwijze of algoritme.
Dat zou eventueel patenteerbaar zijn, en als je in de basis begint met een decompilatie zal die werkwijze vermoedelijk behouden zijn in de broncode die je daar uiteindelijk van maakt, ondanks dat die er volgens het auteursrecht wel voldoende uniek zou kunnen uitzien.

[ffha]

Ik kan een Frans Harry Potter boek pakken, dit zelf naar het Nederlands vertalen en het dan op het internet gooien, maar ik kan je garanderen dat ik de daaropvolgende rechtszaak zou verliezen.

[thedicemaster]

dit is niet te vergelijken met een boek.
om een boek vertaling te verspreiden moet je het beschermde deel van het boek verspreiden, het verhaal.

de code van een spel vertalen en dit verspreiden kan zonder het verhaal, de muziek, de karakters, en locaties te kopiëren.
bij deze projecten moet de eindgebruiker de broncode zelf combineren met de "assets" van het originele spel om een speelbare kopie te krijgen.

dit ligt dichter bij het schrijven van vertaalde ondertiteling voor een film, zonder de film heb je niks.

daarnaast heeft de Amerikaanse copyright wet uitzonderingen specifiek voor reverse engineering en verwijderen van DRM als dit gebruikt wordt voor compatibiliteit, zoals het herschrijven van de code van een console spel dat je bezit zodat dit spel onder Windows draait, het gebruiken van een no-CD crack als je CD een kras heeft, of het verwijderen van online DRM als de DRM servers offline zijn gegaan.

[SuperDre]

Maar die reverse engineering slaat wel op cleanroom RE, en dat betekent dus dat je zonder de originele code het gaat proberen na te maken. En ook dat verwijderen van DRM mag alleen in bepaalde situaties.
En voor jezelf mag je natuurlijk altijd alles doen, het probleem zit em in het publiceren van wat je gedaan hebt.

[thedicemaster]

of het ook "cleanroom" moet ligt dacht ik aan waar het voor gebruikt wordt.
"cleanroom" methode dan valt het volledig buiten de copyright wet en kan je er alles mee doen, anders moet je 1 van de specifieke uitzonderingen te pakken hebben(compatibility/interoperability)

[bzuidgeest]

Dan heb je "content" gedupliceerd, code is geen content. Code is meer vergelijkbaar met kaft en lijm. het mechanische deel van een boek en dat mag iedereen doen. Jij mag nieuwe kaften maken voor een bestaand boek. Hier maken ze een nieuwe engine/code voor bestaande content, de content word niet gedupliceerd.

[Ajunne]

Maar hebben we het nu over decompilen of reverse engineeren? Het verschil is namelijk erg groot, en het eerste is illegaal terwijl het tweede legaal is.

In het geval van decompileren neemt men het uiteindelijke product dat vrij verkrijgbaar is (in dit geval de schijfjes van de game), haalt dat door een disassembler of decompiler waardoor er machine-gegenereerde broncode uitkomt (al dan niet in assembly of een hogere taal als C). Die broncode wordt dan minutieus door mensen bijgewerkt zodat ze correct is, eventueel beter leesbaar en onderhoudbaar, en na het compileren een binair bestand oplevert dat identiek is aan hetgene dat origineel van het schijfje werd geplukt (of op zijn minst identiek dezelfde functies vervult).

In het geval van reverse engineeren (en liefst: clean room reverse engineeren) wordt door één team het uiteindelijke product geanalyseerd tot in het grootste detail mogelijk, en de analyse hiervan wordt in een document opgeschreven. Dit document wordt dan door een ander team gebruik als input voor specificaties en daar wordt een nieuw stuk software geschreven dat volledig aan deze specificaties voldoet. Je krijgt dan een volledig nieuw product, dat verder totaal niet lijkt op het originele product, behalve dat het toevallig exact dezelfde functies vervult. (Fun fact: dit is hoe Compaq destijds de PC BIOS van IBM volledig nagebouwd heeft, en daardoor op zijn eentje de markt van PC-compatibele hardware gestart heeft. Doordat de reverse engineering volledig gedocumenteerd was, had IBM wettelijk geen poot om op te staan om het product van Compaq te verbieden.)

Het eerste is volledig illegaal en een inbreuk op de copyright van Nintendo. Een product wordt namelijk uit elkaar getrokken en gewijzigd, dat mag niet. Het tweede is echter wel toegestaan. Vergelijk het met een ventilator: in het eerste geval koop je een ventilator van een bedrijf en bouwt het toestel volledig na door alle onderdelen één voor één te kopieren en exact na te maken, en dan in elkaar te schroeven en te verkopen. In het tweede geval neem je een bestaande ventilator, schrijft op wat het ding doet (een motor laten draaien die een set wieken laat draaien, en daardoor wind maakt) en dan vervolgens een apparaat bouwt dat hetzelfde doet, maar op een andere manier.

In dit geval is het extra verwarrend, omdat het team dat het doet zichzelf "Zelda Reverse Engineering Team" noemt, maar het product is dan weer "Decompilation of Ocarina of Time". Als je echter even beter kijkt, lijkt het inderdaad om een decompilation te gaan. Dus de componenten van de originele binary, die dan met de hand leesbaar worden aangevuld. Of dat volledig illegaal is, is niet helemaal duidelijk, maar volledig legaal is het zeer zeker niet. Dus ze bevinden zich zeker op glad ijs, en ik denk dat menig rechter Nintendo gelijk zal geven als ze vragen om deze code van het internet af te halen. Of dat zin heeft, nu dat de code publiek is en er heel veel kopies van bestaan, is natuurlijk een totaal andere vraag.

[Vampyre]

Nee, voor de wet is er geen verschil, reverse engineering in de wet wordt decompilatie genoemd (originele Europeese verordening om specifiek te zijn).
Er is legaal absoluut ook geen verschil of je nu assembly leest of dat je decompilatie code leest.
De industrie standaard disassembler IDA heeft ook al jaren een optie om te decompilen naar een pseudo C vorm van code (F5, veel gebruikte toets voor RE's ).

De wet is ook verrassend on-technisch wat betreft dit onderwerp.

[PearlChoco]

En zelfs dan nog, ook al programmeer je het volledig zelf, mag je gewoon een Zelda spel 1 op 1 nabootsen, met dezelfde gfx, gameplay, interface etc?

[Blokker_1999]

Je mag het waarschijnlijk wel compatibel maken met bestaande resources. Die mag je uiteraard nergens meeleveren.

[field33P]

Als je inderdaad mensen vertelt om hun eigen ROM aan te leveren en een tooltje maakt die de resources uit de ROM trekt mag het gewoon wel.

[sampoo]

Dat zal per jurisdictie verschillen. Volgens Amerikaanse wet en regelgeving mag het blijkbaar, al zal het vast ook grijze gebieden kennen.

[Reactie gewijzigd door sampoo op 22 juli 2024 17:29]

[SuperDre]

Nou, nee dus, zeker volgens de amerikaanse wetgeving mag jij niet zomaar het spel 1-op-1 nabootsen en publiceren, want dan kom je sowieso al in IP-recht en dat ga je 100% zeker verliezen. Enige wat zou mogen is zelf, zonder de originele rom te hebben gedecompileerd voor de code, een engine schrijft die overweg kan met de originele gamedata die in de rom zit, maar je mag de originele rom dus niet publiceren, en je zult moeten oppassen met de term nintendo etc te gebruiken want dan kun je ook weer op misbruik van logo's etc kunnen komen.

[bzuidgeest]

Ja het mag wel volgens de Amerikanen. zie de originele namaak IBM bios van compaq zijn eerste IBM clone. Zolang je het team dat documenteert en het team dat van documentatie een nieuwe implementatie schrijft gescheiden houd mag je dat gewoon doen. Het IP zit op de resources en andere content, de naam etc. Maar namen en tekst en graphics zitten als resources in de game niet als code. Dus zolang je die resources niet distribueert moet dit mogen.

[BadRespawn]

In essentie ga je de binaire code door een decompiler gooien
...
De enige manier waarop je reverse engineering kunt doen slagen vanuit wettelijk oogpunt is door het op de clean room manier te doen. 1 team beschrijft hoe alles zou moeten werken en een ander team implementeert het opnieus. Maar dat vergt enorm veel tijd en werk. Dat doe je niet met een klein team.

In dit geval lijken ze toch dat laatste te doen, dus niet door een compiler gooien;

"broncode met de hand nabootsen"
"painstakingly recreated the game from scratch"

En het is een community project, dus wellicht niet een klein team.

Overigens lijkt me "decompileren van broncode" (in het artikel) wat merkwaardig geformuleerd; bij decompileren start je met machinecode om op broncode uit te komen, dat is decompileren van machinecode, niet van broncode.
En als wat er in het artikel staat ook zo is bedoelt dan is het dus 'handmatig decompileren'; oftewel broncode schrijven die na compilatie hetzelfde doet als de oorspronkelijke binary, wat doorgaans niet decompileren wordt genoemd, maar zoals elders in het artikel: "reverse engineering".

[Reactie gewijzigd door BadRespawn op 22 juli 2024 17:29]

[.oisyn]

Ze decompileren dus weldegelijk, aldus de github pagina (h/t @Blokker_1999 ).

Overigens maakt het niet uit of je een decompiler gebruikt of met de hand de functies opnieuw schrijft adhv de assembly, het komt in beide gevallen op hetzelfde neer en je ontwijkt de auteursrechten er niet mee.

[BadRespawn]

Dat zou betekenen dat ze liegen over "painstakingly recreated the game from scratch", en zo dom zijn om hun mond voorbij te praten.
Het enige wat ik op de gitbub pagina zie is dat de term "Decompilation" wordt gebruikt.
Is het onmogelijk dat ze daarmee bedoelen dat ze het met de hand hebben gedecompileerd (hoe merkwaardig het ook is om dat decompileren te noemen), en niet liegen over "painstakingly recreated the game from scratch"?

[Reactie gewijzigd door BadRespawn op 22 juli 2024 17:29]

[Blokker_1999]

community projecten zijn heel vaak zeer kleinte teams van enkele mensen die echt werken aan de code. Vele die er gebruik van willen maken, die hun mening en hun ideeen willen geven maar de echte bijdragen, de mensen die weten hoe ze code moeten schrijven is meestal zeer beperkt.

De makers hebben het continue over decompileren. Dat wil zeggen dat je de assembly neemt en broncode schrijft die een gelijkaardige output gaat genereren. Of je hiervoor nu tools gebruikt die het voor je doen of je doet dat met de hand, het eindresultaat blijft hetzelfde. Je hebt geprobeerd een 1 op 1 vertaling te maken van een assembly naar broncode.

Maar zelfs met een decompiler tool kost het veel tijd omdat de gecompileerde code geen herkenbare benamingen zal hebben voor functies en variabelen. Die moet je er dus alsnog zelf op plaatsen om de code leesbaar te houden. Je moet een analyse maken van elke functie, waarvoor deze gebruikt wordt en waarom iets geschreven is op de manier waarop die geschreven is. Dat kost tijd en moeite. Dus ja, zelfs met decompileren kan het zijn dat je termen als "painstakingly" gaat gebruiken om het proces te omschrijven.

Ongeacht hoe ze het doen, het is geen clean room reverse engineering. En clean room blijft de enige gekende manier om bij dit soort projecten weg te blijven van potentiele copyright claims. Want code analyseren en je analyse opschrijven is gedekt onder fair use. Dat anderen die dan opnieuw kunnen implementeren doet daar geen afbreuk aan.

[bzuidgeest]

Bij een cleanroom her implementatie wel. Zie de zaak rond hoe compaq de eerste IBM bios clone maakte.
Zolang het team dat decompileert gescheiden is van implementerende team mag het gewoon,

[.oisyn]

Bij een cleanroom her implementatie wel

Ook bij een cleamroom implementatie maakt het niet uit of je het met de hand of met een decompiler doet. Dat was de kern van mijn post. Dat je met een clean room implementatie wel auteursrechten kan ontwijken is al meerdere malen in deze thread gezegd, maar het lijkt er niet op dat dat in dit geval gebeurt

[bzuidgeest]

Of het wel of niet gebeurt, weet ik niet zeker. Maar mijn punt is dat de handeling die ze zeggen te doen met de juiste methodiek niet illegaal is.

[Mushroomician]

Een computer is een machine/werktuig.
De instructies aan een paard, koe, olifant of zelfs je hond, zijn evenmin beschermd.

De methode die je gebruikt om de instructies te compileren (je werk) is een uitvinding en zeker verdedigbaar, maar de uitvoer is precies dat: uitvoer wat op andere wijze ook behaald kan worden.

[kaas-schaaf]

Wordt daarmee dan bedoeld dat ze geen inbreuk maken op de broncode van Nintendo, want deze is geschreven in een andere taal dan de C die ze nu gebruiken?

Nee, het decomipleren en daaruit nieuwe leesbare code schrijven is legaal in de VS zonder copyright schending. Een bekend voorbeeld van dit is het decompileren van de originele IBM Bios en het daarna uitbrengen van compatible biossen en dus IBM-Clones in de jaren '80 en '90.

edit: ik was volledig in de veronderstelling dat dit ook met de originele bios gebeurde maar ik heb het blijkbaar verkeerd.

[Reactie gewijzigd door kaas-schaaf op 22 juli 2024 17:29]

[Zer0]

Nee, het decomipleren en daaruit nieuwe leesbare code schrijven is legaal in de VS zonder copyright schending.

Niet direct, het decompileren, beschrijven en vanuit die beschrijving nieuwe code schrijven valt onder fair use. Nieuwe code schrijven direct op basis van de gedecompileerde code niet.

[field33P]

De IBM BIOS was niet gedecompileerd - IBM leverde bij de 5150 gewoon de ROM listings (=broncode) mee met het doel om het ontwikkelaars van uitbreidingen zo makkelijk mogelijk te maken, wetende dat iedereen die zelf de listings kopieerde voor een kloon verpletterd kon worden met een rechtszaak. Waar ze alleen geen rekening mee gehouden hadden was dat Compaq twee gescheiden teams had: één team wat de listings las en omschreef hoe ze werkten, een doorgeefluik waar de omschrijvingen doorheen gingen, en het tweede team wat de omschrijvingen omzette in functioneel identieke code. Daarnaast had Compaq ook nog het hele proces uitgebreid gedocumenteerd wetende dat IBM een heel team aan advocaten naar binnen zou sturen.

[dmantione]

Het vertalen van code van de ene naar de andere taal maakt het niet een nieuw werk: Dat geldt normaliter voor compileren: De door de compiler gegenereerde machinetaal is hetzelfde werk als wat de programmeur heeft geschreven en dus zijn beiden door het auteursrecht beschermt. Het omgekeerde uitvoeren (van machinetaal naar C) betekent dus dan je resulterende code nog steeds het oorspronkelijke werk betreft en beschermd wordt door auteursrecht.

Bij het het IBM PC-BIOS zit het heel wat anders in elkaar. Om te beginnen was daar geen sprake van decompilatie, wel van reverse-engineering: Een team bestudeerde de code en stelde daarop specificaties op (in gewone mensentaal) van waar een BIOS-implementatie moest voldoen. Een onafhankelijk team schreef op basis van die specificaties een nieuw compatibel BIOS.

Die aanpak hield juridisch stand en bij het ontwerp van de Europese Softwarerichtlijn (geïmplementeerd in alle auteurswetten), is als direct gevolg hiervan zelfs expliciet opgenomen dat je het recht hebt om de werking van een programma te bestuderen. Big Blue IBM werd namelijk als een dominante marktmacht gezien waarvan moest voorkomen dat deze het auteursrecht ging gebruiken om zijn macht uit te oefenen.

[.oisyn]

Sowieso hebben ze het over decompileren. Dan kun je het nog wel aanpassen om leesbaar te maken, het uitgangspunt blijft de binary waar Nintendo de rechten op heeft. Taal is hierbij ook compleet ondergeschikt.

Het artikel is dan ook wat tegenstrijdig, want verderop hebben ze het weer over nabootsen. Dat zijn toch echt twee verschillende dingen.

[Reactie gewijzigd door .oisyn op 22 juli 2024 17:29]

[Blokker_1999]

Ben daarom zelf even naar de github pagina gegaan. De makers spreken zelf over decompileren. Het is dus spijtig genoeg geen propere herimplementatie van het spel.

[BadRespawn]

Sowieso hebben ze het over decompileren.

Maar ze hebben het ook over "broncode met de hand nabootsen" en "reverse engineering". Zowel het oorspronkelijke bericht ("painstakingly recreated the game from scratch") als dit tweakers artikel gebruiken tegenstrijdige termen, strikt genomen kan het maar één van de twee zijn.
Het beste wat ik er van kan maken is dat het 'met de hand is gedecompileerd' (wat doorgaans niet decompileren wordt genoemd).

[mjl]

Snel downloaden dan, Nintendo kennende doen ze er alles aan om het te blokkeren.

[Zeror]

De takedown zal vermoedelijk nu al wel onderweg zijn.

[jqv]

In dit geval niet daar dit team niets fout doet.

Pas als mensen het gaan porten kunnen ze aan de slag.

[Blokker_1999]

Nee hoor, zelfs dit is al verkeerd. Dit is gewoon een decompilatie van de game en daar rust auteursrecht op.

Als ik morgen een boek vertaal in een andere taal is dat ook niet voldoende om het auteursrecht niet te schenden gewoon omdat de taal anders is.

[Tinboy]

Zo zwart wit is het niet.

Er nog is fair use voor iets wat onder auteursrecht valt. Daardoor mag jij best een boek vertalen, voor eigen gebruikt. Zo lang je het maar niet verkoopt of de rechthebbende financieel schaad. Volgens mij een keer het voorbeeld gezien van tekst omzetten in braille. Je vertaald de tekst, maar het is de enige manier dat een blinde het kan lezen. Dit wordt gezien als fair use.

Hoe het exact in elkaar steekt weet ik niet. Maar ik vermoed dat dit hier onder valt. Zij vertalen, en doen er verder niks mee. Geen financieel gewin voor hun en het schaad Nintendo niet.

[Blokker_1999]

Voot eigen gebruik. Klopt. Iets op github zetten is niet langer eigen gebruik, dat noemen we publiceren.

Wil je gebruik maken van zogenaamde "fair use" is de eerste belangrijke vraag al direct: in welk land wonen de mensen die aan dit project werken? Verschillende landen hebben verschillende wetgeving. De term "fair use" is bijv. alleen van toepassing in de VS en kent alsnog vele beperkingen.

Maar omdat je het over fair use hebt, laat het ons daar even bij houden. Voor fair use worden er in de basis 4 dingen in rekening gebracht:

• 1. the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
• 2. the nature of the copyrighted work;
• 3. the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
• 4. the effect of the use upon the potential market for or value of the copyrighted work.

Het eerste punt vormt hier al direct een probleem. Niet zozeer het tweede deel van die clausule, want het is uiteindelijk non-profit werk, maar het eerste deel. Voor fair use zie je vaak termen voorbij komen zoals "transformative" of "for review and criticism". Dit werk voldoet aan geen van die eisen. Het is effectief een pure herimplementatie van het origineel, in dit geval met expliciet het doel identiek te zijn aan dat origineel. Zeker in moderne rechtspraak is de nadruk meer en meer komen liggen op het transformeren van het werk in een nieuw werk om te voldoen aan de fair use.

Op het tweede punt kan men heel kort zijn. Het origineel is in binaire vorm verdeeld en Nintendo heeft daar simpel weg de rechten op en mag dus ook bepalen wat er met die werken gebeurd. Die clausule is vooral voorzien om te bepalen of het origineel voldoende verifieerbaar is als een origineel werk en of het wel voldoet aan de eisen om onder auteursrecht te vallen. Bijv. een ongepubliceerd manuscript maar evenzeer een werk waarvan het auteursrecht in het verleden nooit verdedigd is geweest.

Het derde punt gaat over proportionaliteit. Een kleine clip van 30 seconden uit een film of 2 bladzijden uit een book van 300 zal al sneller aanvaard worden als fair use dan het hele werk opnieuw publiceren.

En het vierde punt lijkt mij ook heel eenvoudig. Met deze broncode eenmaal beschikbaar wordt het heel eenvoudig om de game opnieuw te gaan herverdelen, ook op andere platformen waardoor Nintendo mogelijks inkomsten misloopt als zij zelf het spel alsnog naar dat platform zouden brengen. Hoe goed of slecht de ports van Nintendo zijn doet daar zelfs niet ter zake.


En hoe zit het dan specifiek met reverse engineering? Want daar is in het auteursrecht in de VS een uitzondering voor gemaakt, geloof het of niet, waardoor het in de basis wel mogelijk is. MAAR, indien in de TOS, je weet wel, dat stukje tekst dat niemand leest, expliciet is opgenomen dat het niet mag, dan mag het alsnog niet. Staat die bepaling er niet in, dan mag het wel voor persoonlijk gebruik ter bevordering van interoperabiliteit en mag, onder bepaalde voorwaarden, die kennis ook gedeeld worden.


In Europa is het een stuk eenvoudiger. Computerprogramma's genieten dezelfde bescherming als andere werken zoals boeken en muziek. Decompileren is toegestaan om software te laten samenwerken met andere software, maar je hebt niet het recht om dat gedecompileerde werk voor iets anders te gebruiken. Zomaar herpubliceren kan dus niet.

[Tinboy]

Goede uitleg. Kan hem niet geven, maar bij deze +3 .

[Xfade]

Zo zwart wit is het niet, maar dat hield take2 niet tegen om met succes Re3 en ReVC offline te krijgen.

[thedicemaster]

zo "met succes" is dat nog niet.
ze zitten midden in een rechtzaak die moet bepalen of Re3 en ReVC onder fair use vallen, en of take2 niet misbruik heeft gemaakt van DMCA door moedwillig foute claims te maken.

[Xfade]

Oh absoluut. Ik bedoel meer dat je moet spitten om de bestanden te bemachtigen, ze zijn van Github af en worden op het moment niet ge-update.

Ik heb ze ook op m'n playstation vita draaien bijvoorbeeld, maar die githubs daarvan zijn ook weg en ook geen updates meer.
Ze zullen wel terug komen als de rechter bepaalt, uiteraard.

[jqv]

Dat is een aanname van je.
Het artikel geeft wat anders aan.

Ik ga er vanuit dat de auteur weet waar hij over schrijft.

[Blokker_1999]

Die laatste zin van je is een aanname. Wat het artikel aangeeft is leuk, maar je kan ook gewoon doorklikken naar de bronnen in dit artikel. En dan zie je dat de mensen achter het project zelf spreken van decompileren en dat ze een bit voor bit identieke versie van het spel willen krijgen na compilatie.

Dat zijn geen aannames, dat schrijven we gewoon zwart op wit.

[batjes]

Wat ik zo opmaak uit dit artikel is dat ze de code namaken. Niet simpel door een decompiler trekken.

Daar is helemaal niets verboden aan. Zo werken (de meeste) emulators in principe ook. Als Nintendo dit weet te verbieden zeg maar gedag tegen elk modern stukje software en game.

[Xfade]

This project is a matching decompilation, which means that it produces a byte-for-byte identical ROM to the supported versions of OoT (which right now is just the MQ debug rom). The compiler is old and its output is very sensitive to small changes in the source code, which means that there is relatively little freedom to change the source and still end up with a matching ROM.

[SuperDre]

Nou, het is wel verboden om code na te maken met de originele code ernaast. Cleanroom reserver engineering mag dan weer wel, ofwel waarbij je zelf gaat achterhalen hoe het werkt zonder naar de originele code te kijken (en decompileren valt dus onder 'kijken naar de originele code').
Inlezen van de gamedata en daarmee een eigen 'interpreter' schrijven is geen probleem, maar je moet wel rekeninghouden dat je geen van die originele gamedata mee mag leveren met je 'interpreter'.

[Anoniem: 306567]

Nintendo is fel tegen fanprojecten zoals ports van hun games naar andere platformen.

Aan de ene kant snap ik het van Nintendo, maar als ze dan zelf brakke emulatie leveren voor N64 games op de switch.... Hopelijk gaan ze daar nog wat aan doen.

[Eonfge]

Nintendo zou natuurlijk graag zien dat jouw game-bibliotheek langzaam afsterft door entropie; Wat nu nog werkt op officiële hardware, kan over 10 jaar alleen nog werken als je het product opnieuw koopt.

[Wolfos]

Het valt nog te bezien of ze het 'geen backwards compatibility' trucje nog een keer kunnen flikken. Ik denk dat een groot deel van de Switch eigenaren ze keihard laat vallen als ze nog nog een generatie re-releases doen.

[SuperDre]

Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo.

Nee, zo werkt legale reverse engineering niet. De originele code ernaast houden is echt een nono wil je legale reverse engineering doen.
Wil je echt dat nintendo geen kans maakt, dan moet je helemaal aan de slag met cleanroom, en ook dan moet je zorgen dat je geen greintje originele data van Nintendo meelevert. Je gebruikers zullen zelf moeten zorgen dat ze de gamedata zien te krijgen.

[BvdW1978]

De gecompileerde game is toch niet de originele code? Het Samba-team zou er anders ook juridisch behoorlijk opgegaan zijn toen ze een Windows NT Domain Controller nabouwden met alleen de publiek verkrijgbare docs en binaries van Windows NT ernaast. Hadden ze nou de broncode van Windows zonder toestemming van Microsoft verkregen en die ernaast gehouden, dan zou het pas een probleem zijn.

[Anoniem: 1648530]

Wat ik niet snap ze remasteren/ remake elk zelda game behalve zelda oot,

[ShadLink]

Er is een remake van Ocarina of Time. Namelijk op de 3DS

[Anoniem: 1648530]

Maar niet voor de switch

[ShadLink]

OoT is in de N64 app te vinden Enkel The Wind Waker, Twilight Princess en Majora's Mask zijn (nog) niet te spelen op de Switch. (en alle handheld Zelda games muv Link's Awakening)

[licens]

vraag me af of de VR community er wat mee kan doen

[ErwinPeters]

Onaangepast leent de gameplay zich niet goed voor vr. Dan bedoel ik vooral de dungeons waarin de puzzles vanuit first person niet goed zichtbaar zijn en de textures erg low-res om vanuit ooghoogte te bekijken.

Hier kun wat aan doen, natuurlijk maar dat is meer werk voor iets dat al speelbaar is.

[walterg]

One of the most iconic video games of all time is now fully playable in VR thanks to a new mod by BrianMp16. This isn’t some 20-minute tech demo; you can play through the entirety of the legendary campaign from start to finish, all from an immersive first-person perspective.

https://vrscout.com/news/...now-fully-playable-in-vr/

[Reactie gewijzigd door walterg op 22 juli 2024 17:29]

[ErwinPeters]

Oh, kijk nou. Ik ben blij verrast en ga hem proberen. Misschien zit ik er wel helemaal naast.

[Aardedraadje]

Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo.

Volgens mij heb je dan nog wel te maken met het verschil tussen "clean-room reverse engineering" en "ik heb de assembly bekeken en de functie nagebouwd in C". Dat laatste heeft m.i. een veel lagere kans om overeid te blijven als Nintendo komt aankloppen, dan dat eerste.

[Anoniem: 1532362]

De Mario 64 reverse engineer project wat de assembly heeft bekenen staat nog steeds op github.

[Twixie]

Volgens mij is er in veel software licenses ook voorzien dat reverse engineering, bvb doormiddel van het decompilen van de binaries, verboden is. Zou me niet verbazen dat dat met games ook zo is, hetzij in de license agreement van het spel, of de license agreement van de console.

[Amanoo]

Het enige wat ze doen is de broncode met de hand nabootsen in C, wat betekent dat ze geen inbreuk maken op het auteursrecht van Nintendo

Dat us geen garantie. Er waren ook modders bezig om GTA3 en Vice City te herimplementeren (ik weet niet zeker of dat voor de nieuwe versie of de oude was), en Take2 heeft ze even vrolijk aangeklaagd voor auteursrechtinbreuk. Er was enkel eigen code, er waren geen models of dialoog uit de originele spellen, en je kon het niet spelen zonder de originele spellen. Daar had Take2 ook geen boodschap aan.

Nintendo zou op eenzelfde manier met advocaten kunnen gooien.

[field33P]

Ze hadden onder andere american.gxt in hun repo gezet waar wel degelijk originele dialoog in zat. Daar was geen enkele praktische noodzaak voor en daar zit gewoon auteursrecht op.

[thedicemaster]

de rechtszaak hiervoor is nog gaande, en de positie van de "modders" is redelijk sterk.

[Amanoo]

Mijn punt is meer dat rechtszaken even goed kunnen komen. In dit geval gaan ze de strijd aan, maar dat is nog een heel risico, zelfs als je gewoon gelijk hebt. Rechtszaken kosten geld, en Take2 heeft een heel leger aan advocaten waar je het tegenop moet nemen. Hetzelfde geldt voor Nintendo. Gelijk hebben is één ding, gelijk krijgen iets anders.

[Knijpoog]

Mijn gedachten bij dit soort projecten is echt: waarom bouw je het niet na in bvb de Unreal engine. Kost het dan echt zoveel meer moeite om het daarin na te bouwen?.. en als je het lukt heb je zo veel geleerd en kun je daarna toch bij vele studios aan de slag.

Ik kan er compleet naast zitten maar waar zit het dan in, dat in het decompileren zoveel tijd en energie word gestoken.

[Tri Force]

Die zijn er wel maar dat kost nogal wat tijd en geld en hoe meer en langer hoe groter de kans dat Nintendo om verwijdering vraagt https://youtu.be/BHs6dl78FSE ook uitleg erbij over het Ocarina of time Unreal Engine project

[SuperDre]

Nouja, zelf compleet nabouwen is leuk als eigen hobbyprojectje, maar je kunt het dan niet publiceren omdat de characters wel copyright op zit. Wat nog wel zou kunnen is als je een converter schrijft voor de originele gamedata en die dan meelevert zodat de gebruiker zelf nog de gamedata moet verstrekken.