5 ms·

Mario rom hacks are perfectly legal since the only thing that gets distributed is a patch file - the original ROM has to be provided by the user. Sites like SM

Mario rom hacks are perfectly legal since the only thing that gets distributed is a patch file - the original ROM has to be provided by the user. Sites like SMW Central[1] contain thousands of hacks and Nintendo hasn't done anything about it. [1] https://www.smwcentral.net/ https://www.smwcentral.net/

zamadatix 2y ago
Adding on with a wall of text diving into the specific differences in projects that either have or haven't attracted Nintendo's legal attention (tl;dr: it's a lot more than just visibility/popularity). While it's always possible Nintendo will just decide to go after these one day (right or wrong in doing so) that they didn't even attempt to touch this particular type of Mario romhacking scene when Mario Maker came out ~10 years ago makes me think these particular types of projects (patchsets on old games without copyright protection) won't receive much trouble. Doubly so for these types of projects which don't (in and of themselves) make the game playable on unofficial systems. Nintendo seems largely focused on direct redistribution, non-patchset based remakes, "cracking" of modern game DRM/security to allow modification/unauthorized playing, and distribution of gameplay content on media which have stricter takedown requirements than the law strictly requires (e.g. YouTube). This makes some sense as Nintendo has either previously demonstrated these types of cases in court or has previously signalled they believe they could easily do so if challenged. While Nintendo, right or wrong in a specific instance, could definitely get away with a decent amount of "legal bullying" of individuals not interested in fighting a legal battle with a large company over their hobby website they aren't necessarily going to be interested in picking tons of such battles if they aren't relatively sure they'd win should one actually result in a real court battle. Setting precedent in court that something is explicitly okay (like 3rd party games, emulation, personal game backups) can sometimes be worse than just letting it ride as an "underground" thing. Particularly if they are defending their property elsewhere and it'd be hard for someone to argue in court these romhacks existing is counter to that. Anyways, this wall of text is to say: sure, nobody knows what Nintendo is going to do tomorrow, but 20 years of romhacks later they've never hinted at going after this particular type of project, despite going after many nearly identical but slightly differently implemented projects, so the same "get it before Nintendo DMCAs it" comment that one would expect from those threads doesn't necessarily hold the same weight. Not that it's an absolute possibility, anything is possible, but if this type of project were the only one then people wouldn't have the "it'll be DMCA'd by tomorrow" notion. But do back it up anyways... a great deal many more early efforts have been lost to the sands of time than Nintendo's lawyers.
black_puppydog 2y ago
Then I guess we better archive that entire site before someone new in middle management decides to make a name for themselves by killing it.
loeg 2y ago
IP holders (or their representatives) don't always let legality get in the way of issuing DMCA notices for content they don't like.
- drdaeman 2y ago
  In a sane world, it should be as easy as sending them a counter-notice and if they decide to escalate, sending a cardboard cutout of yourself to the court with a printed "no copyrighted materials (except for some screenshots, which is fair use for illustrative purposes) exist on the website" sign to win the case. We are not living in the sane world, of course.
- lbourdages 2y ago
  Nintendo has shut down a bunch of fan games in the past (e.g. Pokemon Uranium) but I have never heard of any DMCA request on Mario rom hacks. I think it speaks for itself here.
Dwedit 2y ago
The patch file will create 95% of a working ROM when applied to a blank file, but not enough to actually create a working ROM. Some important bytes are missing. Some ROM hack patches WILL create a complete working ROM when applied to a blank file. I don't think those can even be called patches anymore.
- wongarsu 2y ago
  Is there an agreed part everyone leaves out, or can you just apply one patch to another patch to get a complete ROM?
  - smegsicle 2y ago
    theseus's copyright infringement
  - derefr 2y ago
    These patch files are supposed to be diffs between the final version of the ROM after your modifications, against the original upstream ROM you started with. Ideally, they're only supposed to contain the code and assets you upserted into the game yourself. And if you don't move anything around, then that's all they will contain. But if you do start moving things around — sliding sections of code or data forward in memory and fixing up references to them so as to make more room for new stuff — then you run into the problem, at release time, that an .IPS file is literal binary bytewise diff. So, by moving a section forward by one byte, the .IPS file will now contain a complete copy of that section, in order to overwrite [SECT_START+1:SECT_START+N+1] with [SECT_START:SECT_START+N]. What is needed, to avoid this, is an alternative patch format, that doesn't just blindly say "overwrite [X:Y] with [binary]" but rather says something like (a binary encoding of) the following "data-unpacking command language" (here as pseudo-Elixir code): expected_output(size: 1000, sha256: <<0x012345...abcdef>>) require_external_data_source(id: :upstream, size: 1000, sha256: <<0x6789ab...beefee>>, description: "Super Mario World (U) v1.0 SFC ROM image") embed_data_source(id: :patch, size: 100, sha256: <<0x777777...cafefe>>) write_at(offset: 0, constant_u8(<<0x00>>, repeat: 100)) write_at(offset: 100, embedded_data_slice(:patch, offset: 0, len: 100)) # some patch data write_at(offset: 200, external_data_slice(:upstream, offset: 0, len: 400)) # then some source data write_at(offset: 204, constant_u32(<<0xaabbccdd>>, repeat: 1)) # fixup one little bit of the copied source data embed_data(:patch, compression: :deflate, data: <<...>>) ...where the patcher tool would ask you for "Super Mario World (U) v1.0 SFC ROM image"; check that the file you provide matches the given SHA; allocate a 1000-byte output buffer; run through the write ops against the output buffer; validate that the output buffer now matches the given SHA; and then write out the output (or pass the pointer to the buffer back to the caller, if being used as a library.) I'm not sure why no patchfile format with these semantics exists. It'd be relatively straightforward to write a library that computed such patch-op sequences from one or more infiles + one outfile, using (essentially) LZ77 to discover shifted partially-overwritten repeats, and gradient-descent optimization over alternative equivalent formulations to find minimal such descriptions. --- Alternately, though, maybe we just shouldn't be making arbitrary low-level byte-delta patches to opaque ROM images in the first place! IMHO we're at a point now with understanding the entire libraries of most of these old systems, that we could very well write a single program for each console that: 1. disassembles a source ROM into sections (individual assets, plus position-independent-code -ified assembly); 2. patches the text sections with git-commit-like textual diff hunks over the PIC ASM (where the tool could very well extract these from a git worktree!); 3. replaces assets wholesale with new per-asset binaries (that can be different sizes, or with different numbers in lists, or with individual assets in different formats — in which cases, the code that loads them will be automatically modified to compensate); 4. and then reassembles the ROM, computing all the fixups in the process. Given the current state of whole-library game preservation (we've had GoodTools for a good 20 years now); and given the experience that game modders now have with building "perfect" build pipelines for game decompilation projects, that build the original ROM image... we should (IMHO) be able to set up these "high-level patchers" in such a way as to guarantee that each tool works on 100% of known titles, to losslessly reproduce the input ROM after a disasm+reasm pass.
Y_Y 2y ago
Are you sure it's not a derivative work? https://www.copyright.gov/circs/circ14.pdf https://www.copyright.gov/circs/circ14.pdf
timbo1642 2y ago
[dead]

zamadatix 2y ago

Adding on with a wall of text diving into the specific differences in projects that either have or haven't attracted Nintendo's legal attention (tl;dr: it's a lot more than just visibility/popularity). While it's always possible Nintendo will just decide to go after these one day (right or wrong in doing so) that they didn't even attempt to touch this particular type of Mario romhacking scene when Mario Maker came out ~10 years ago makes me think these particular types of projects (patchsets on old games without copyright protection) won't receive much trouble. Doubly so for these types of projects which don't (in and of themselves) make the game playable on unofficial systems. Nintendo seems largely focused on direct redistribution, non-patchset based remakes, "cracking" of modern game DRM/security to allow modification/unauthorized playing, and distribution of gameplay content on media which have stricter takedown requirements than the law strictly requires (e.g. YouTube). This makes some sense as Nintendo has either previously demonstrated these types of cases in court or has previously signalled they believe they could easily do so if challenged. While Nintendo, right or wrong in a specific instance, could definitely get away with a decent amount of "legal bullying" of individuals not interested in fighting a legal battle with a large company over their hobby website they aren't necessarily going to be interested in picking tons of such battles if they aren't relatively sure they'd win should one actually result in a real court battle. Setting precedent in court that something is explicitly okay (like 3rd party games, emulation, personal game backups) can sometimes be worse than just letting it ride as an "underground" thing. Particularly if they are defending their property elsewhere and it'd be hard for someone to argue in court these romhacks existing is counter to that. Anyways, this wall of text is to say: sure, nobody knows what Nintendo is going to do tomorrow, but 20 years of romhacks later they've never hinted at going after this particular type of project, despite going after many nearly identical but slightly differently implemented projects, so the same "get it before Nintendo DMCAs it" comment that one would expect from those threads doesn't necessarily hold the same weight. Not that it's an absolute possibility, anything is possible, but if this type of project were the only one then people wouldn't have the "it'll be DMCA'd by tomorrow" notion. But do back it up anyways... a great deal many more early efforts have been lost to the sands of time than Nintendo's lawyers.

black_puppydog 2y ago

Then I guess we better archive that entire site before someone new in middle management decides to make a name for themselves by killing it.

loeg 2y ago

IP holders (or their representatives) don't always let legality get in the way of issuing DMCA notices for content they don't like.

drdaeman 2y ago
In a sane world, it should be as easy as sending them a counter-notice and if they decide to escalate, sending a cardboard cutout of yourself to the court with a printed "no copyrighted materials (except for some screenshots, which is fair use for illustrative purposes) exist on the website" sign to win the case. We are not living in the sane world, of course.
lbourdages 2y ago
Nintendo has shut down a bunch of fan games in the past (e.g. Pokemon Uranium) but I have never heard of any DMCA request on Mario rom hacks. I think it speaks for itself here.

Dwedit 2y ago

The patch file will create 95% of a working ROM when applied to a blank file, but not enough to actually create a working ROM. Some important bytes are missing. Some ROM hack patches WILL create a complete working ROM when applied to a blank file. I don't think those can even be called patches anymore.

wongarsu 2y ago
Is there an agreed part everyone leaves out, or can you just apply one patch to another patch to get a complete ROM?
- smegsicle 2y ago
  theseus's copyright infringement
- derefr 2y ago
  These patch files are supposed to be diffs between the final version of the ROM after your modifications, against the original upstream ROM you started with. Ideally, they're only supposed to contain the code and assets you upserted into the game yourself. And if you don't move anything around, then that's all they will contain. But if you do start moving things around — sliding sections of code or data forward in memory and fixing up references to them so as to make more room for new stuff — then you run into the problem, at release time, that an .IPS file is literal binary bytewise diff. So, by moving a section forward by one byte, the .IPS file will now contain a complete copy of that section, in order to overwrite [SECT_START+1:SECT_START+N+1] with [SECT_START:SECT_START+N]. What is needed, to avoid this, is an alternative patch format, that doesn't just blindly say "overwrite [X:Y] with [binary]" but rather says something like (a binary encoding of) the following "data-unpacking command language" (here as pseudo-Elixir code): expected_output(size: 1000, sha256: <<0x012345...abcdef>>) require_external_data_source(id: :upstream, size: 1000, sha256: <<0x6789ab...beefee>>, description: "Super Mario World (U) v1.0 SFC ROM image") embed_data_source(id: :patch, size: 100, sha256: <<0x777777...cafefe>>) write_at(offset: 0, constant_u8(<<0x00>>, repeat: 100)) write_at(offset: 100, embedded_data_slice(:patch, offset: 0, len: 100)) # some patch data write_at(offset: 200, external_data_slice(:upstream, offset: 0, len: 400)) # then some source data write_at(offset: 204, constant_u32(<<0xaabbccdd>>, repeat: 1)) # fixup one little bit of the copied source data embed_data(:patch, compression: :deflate, data: <<...>>) ...where the patcher tool would ask you for "Super Mario World (U) v1.0 SFC ROM image"; check that the file you provide matches the given SHA; allocate a 1000-byte output buffer; run through the write ops against the output buffer; validate that the output buffer now matches the given SHA; and then write out the output (or pass the pointer to the buffer back to the caller, if being used as a library.) I'm not sure why no patchfile format with these semantics exists. It'd be relatively straightforward to write a library that computed such patch-op sequences from one or more infiles + one outfile, using (essentially) LZ77 to discover shifted partially-overwritten repeats, and gradient-descent optimization over alternative equivalent formulations to find minimal such descriptions. --- Alternately, though, maybe we just shouldn't be making arbitrary low-level byte-delta patches to opaque ROM images in the first place! IMHO we're at a point now with understanding the entire libraries of most of these old systems, that we could very well write a single program for each console that: 1. disassembles a source ROM into sections (individual assets, plus position-independent-code -ified assembly); 2. patches the text sections with git-commit-like textual diff hunks over the PIC ASM (where the tool could very well extract these from a git worktree!); 3. replaces assets wholesale with new per-asset binaries (that can be different sizes, or with different numbers in lists, or with individual assets in different formats — in which cases, the code that loads them will be automatically modified to compensate); 4. and then reassembles the ROM, computing all the fixups in the process. Given the current state of whole-library game preservation (we've had GoodTools for a good 20 years now); and given the experience that game modders now have with building "perfect" build pipelines for game decompilation projects, that build the original ROM image... we should (IMHO) be able to set up these "high-level patchers" in such a way as to guarantee that each tool works on 100% of known titles, to losslessly reproduce the input ROM after a disasm+reasm pass.

Y_Y 2y ago

Are you sure it's not a derivative work? https://www.copyright.gov/circs/circ14.pdf https://www.copyright.gov/circs/circ14.pdf

timbo1642 2y ago

[dead]