upvote
In a sane world, if brought before a court, the binary itself wouldn't have any protection unless hand authored. The actual creative work/human expression was the source code. The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.

Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.

reply
> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.

I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.

> You can compile a decomp into the same binary, but that's only to prove functional equivalence.

This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.

reply
A huge portion of the actual thing I write when writing a program does not exist at all in the compiled binary. Names, types, type parameters, etc. being big ones, but many types are also aliases for the empty struct, so their value doesn't exist at runtime either. Conversely, I can write _.map(_.map(_.map(f))) and have that turn into all sorts of looping and branching logic that I didn't write, and the meaning of which is basically "do whatever must be done to make the types work".

Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.

reply
> it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.

Absolutely false. There are an infinite number of programs that will compile to the same machine code. Especially when an optimizer is involved. Discovering one of those is a creative process, transformative, and protected.

Using an LLM to do it for you? I wouldn’t touch that with a 10 foot pole. Seems too close to mechanical transformation to me.

reply