[dognotdog]

It seems like using something that's reverse engineering to achieve "interoperability", in this case playing the games on modern hardware, is generally legal in the US/EU, as long as you also own a license to the original, which seems like is a requirement to use the Re* versions, as you need the original game assets.

Decompilation / reverse engineering is very different from "transcribing" a play. Transcribing a play, you would get back an almost exact copy of the source material, whereas decompiling is more akin to taking a car and measuring all the bits of it. You would certainly not get the original drawings or CAD files back out of it. You do not decompile "source code", but machine code, and the source code you get back is not a recreation of the original copyrighted code, but the decompiler's analysis of the machine instructions, stripped of the original design and intent (the creative work part which makes source code copyrightable in the first place).

Measurements (or information) in general is not copyrightable, despite what IP protectionism claims, and in this analogy the machine code is much closer to the mechanical pieces of the car that make it work than the original designs. Either way, the fair use / reverse engineering provisions already create an exemption.

The questions is wether there are enough legal loopholes to squash these generally allowed uses through some other parts of the law or licensing terms, eg. by claiming that some IP (patents, trade secrets) are infringed some other way by publishing the reverse engineered code.

[klodolph]

I think people are hung up here on the question of whether reverse engineering is legal or whether it is considered fair use to reverse engineer something. However, I don't think that's the relevant question.

The question here is whether you are allowed to publish the results of your reverse engineering and decompilation efforts on GitHub. In this case, the answer seems like a very clear and obvious "no".

1. It's a derivative work of the original.

2. It's the entire executable, not just a portion.

3. It's not transformative.

4. The original work is creative.

5. It competes with demand for the original work (remasters).

With so many different factors stacked against it, I just don't see any kind of plausible defense here.

> Transcribing a play, you would get back an almost exact copy of the source material, whereas decompiling is more akin to taking a car and measuring all the bits of it.

Another red herring here... it is irrelevant how superficially close this is to the original source code.

When you compile a program, the result is not a copy of the original source code either. However, the compiled version of a program retains the copyright of the original source code. Likewise, a decompiled program would retain the copyright.

> The questions is wether there are enough legal loopholes to squash these generally allowed uses...

"Legal loopholes" kind of presumes that this sort of effort is permitted by default, but might be illegal through some kind of technicality. These people are distributing the results of IDA Pro / Ghidra decompilation efforts of an entire executable program on GitHub. Seems like very crystal-clear case of copyright infringement.

Again, to clarify things because people are hung up on this point--it is not about whether reverse engineering is legal. It is about whether you are permitted to distribute the results of reverse engineering. Kind of like asking whether it's legal to rip a CD... yes, ripping a CD is legal. Posting a ripped CD online is not.

[dognotdog]

Interesting points! I am not sure which is right, or legal, but there seem to be grey zones, yet.

> Another red herring here... it is irrelevant how superficially close this is to the original source code.

It wasn't until Apple vs. Franklin that object code became copyrightable, prior to that the USPTO held the analogy of "design drawings vs. actual bridge" as the relation of "source vs. object code", and as far as I am aware that case still left some questions open.

There's also the first sale doctrine. So, once I buy a (mechanical, haha) car, I can modify it, take measurements of it, in fact describe and publish every bit of information I can think up of, right, because once it was given to me, I can do with it as I please, unimpeded by the manufacturer. This is, of course, where things get murky.

Now, a binary has elements of literal nature that copyright protects, but a decompilation results in a completely different information stream, so that seems like a non issue. Thus, we are left with the non-literal copyrightable elements of structure, sequence, organization. Copyright protects expression, but not ideas. So, the binary code is an expression of the author's ideas, and thus it seems sensible that the decompiled version is, too, BUT: only creative expression, not things that are necessary and utilitarian to perform a given function, and this is where it get's less well-defined. So if there are decompiled portions, that might not be enough for a copyright claim, provided they are utilitarian in nature. Of course, just decompiling the whole thing and publishing that looks very much like infringemen, indeed.

I do think this nicely embodies the difficulty of dealing with IP vs. actual, tangible things, though. With the car or bridge analogs, copyright would not prevent anyone from replicating them, but it would be patents and trademarks that put restrictions on how and what can be reproduced, instead of the much stronger restrictions of copyright on software.

I'd personally much more comfortably equate binary code with mechanical elements than works of creative authorship (though much of my livelyhood relies on the latter, in lieu of other mechanisms), but this view isn't universally shared, and possibly not even universally applicable.

[klodolph]

> I do think this nicely embodies the difficulty of dealing with IP vs. actual, tangible things, though. With the car or bridge analogs, copyright would not prevent anyone from replicating them, but it would be patents and trademarks that put restrictions on how and what can be reproduced, instead of the much stronger restrictions of copyright on software.

Photographs of artwork such as paintings or statues are routinely seen to be infringements of the original work. So it is not unique to software. There are lots of demarcations and corner cases for this... for example, if you install your statue in public, you no longer have grounds to sue people for photographing it. If the statue is a minor part of a photograph, then it's not infringement.

Same applies to software. This is well-tread ground, by this point. People have been reverse engineering and copying software for a long time.

> Now, a binary has elements of literal nature that copyright protects, but a decompilation results in a completely different information stream, so that seems like a non issue.

Copyright protects original works of authorship. There is nothing in copyright law that talks about something's "literal nature" or different "information streams". For example, if I write a song, I am still the author of the song even when that song is performed--even though that requires a significant amount of interpretation, transformation, and creativity on the part of the musicians. I am still the author.

Likewise, if I write a book about a character named Jean-Luc Picard, who is the bald captain of a captain of a spaceship in my made-up universe, Paramount has grounds to sue for copyright infringement.

Copyright law talks mostly about very ordinary terms like authorship. Authorship survives all sorts of transformations... not infinitely so, but neither decompilation nor refactoring will change who the author of a program is.