[mindslight]

The distinction is that the binary is a derivative work with no added creativity. I'm not saying this is how things are today, but rather I'm saying this is how things should be. In order to qualify for copyright protection, one should have to put the created work in escrow so it can actually enter the public domain when the copyright expires. If one wishes to control access to their work with other mechanisms that prevent fulfillment of even the very lopsided bargain that was struck with copyright, then one shouldn't get the privilege of copyright.

Also if the best of your "great number of reasons" is fallacious legal reasoning of the type software engineers tend to be drawn to, then I don't think that's much of an argument.

[cornholio]

Again, how do you prove my binary that I put in your copyright escrow facility is a derivative work and not a handcrafted assembly program? Sorry, but you are just uttering nonsense.

[mindslight]

Do you think the idea of binary analysis does not exist? Or that courts don't have a long history of deciding questions of judgement? The problem is also fundamentally quite similar to proving that a published binary is/isn't a derivative work of someone else's work.

Also handcrafted assembly isn't sufficient for your argument, but rather one would have to directly write a binary with a hex editor. Show me any binary larger than say 1 MB that was written with a hex editor. So really the burden of proof would be on anyone claiming that a large binary is direct creation.

[cornholio]

> the burden of proof would be on anyone claiming that a large binary is direct creation

That's not how any of this works. Once I've submitted my binary to the escrow, then it's an original work worthy of copyright until challenged. If someone breaks my copyright, I simply assert my originality and get an injunction against it by default. If the adversary claims my work is a derivative, then the legal burden is on them to prove it - because they are the ones rising it as defense against infringement. So I've already quashed 90% of adversaries by this point just by legal intimidation.

Also, you are attacking a strawman version of this problem. In practice, what will be submitted to the repository are binary object files for the core proprietary sections that are unlikely to be changed, for example the file format definitions to preclude interoperability. Anything else can be source, the final linker step is automated etc. The market will also offer tools for binary randomization and compiler signature obfuscation.

So you are left with a technological arms race that needs to be settled in court, on a case by case basis, using expert testimony where the burden of proof belongs to the infringer. It's just absurd to think anything like this could ever work in practice to promote source availability, or there would be public benefits to put such a highly litigious system in place.

[mindslight]

> That's not how any of this works. Once I've submitted my binary to the escrow, then it's an original work worthy of copyright until challenged

Are you referring to some existing system? Because otherwise we're discussing in the abstract how this could work. And it would be straightforward for the copyright office to have a rule prima facie rejecting machine-executable binaries being claimed as original works, unless compelling proof were submitted that it had been directly created. Because as I said, show me any substantial executable that has been directly created with a hex editor.

The idea of a company choosing a few critical parts that they then (honestly or dishonestly) claim as original binary works is interesting. But note that this still would go a long way towards making the overall work part of the public domain when it expired - such blobs are highly unlikely to contain references to libraries with API churn and whatnot. And even if they somehow do, since they are small enough to be directly worked on, they can be directly fixed.