Text of the spec is copyrighted by the SCO, they did not put it in public domain. That's what "All rights reserved" was intended to mean even though this phrase has not been meaning anything since 2000.
Has anyone looked at creating a new object format for Linux? A non-open spec seems a minor issue, really, in an era when we put binary blobs in the kernel (hi Nvidia.) But the more decades I work in closed source, the more I value open source, and believe keeping _everything_ open.
(Of course this assumes that doing this is sufficient to make it legally not derived from the original spec as far as copyright law cares about, which is beyond my non-lawyer ability to be that confident in.)
OpenVMS uses ELF too. Rather niche proprietary OS but still maintained and in production use. (Not a new thing with x86-64 port, ELF was adopted during the Alpha to Iranian transition.)
As do many RTOS (both open source and proprietary)
No, because that's overkill for this problem, because the de facto standard is "What do modern free Unicies do", where those are basically Linux/BSD/Illumos. Besides, it's not unheard of in Unix history to have free implementations of proprietary standards, where those implementations became de facto standards anyway.
Even if it was a seriously pressing issue, writing a new specification that covers ELF as it exists today is going to be many, many, many times easier than introducing a new executable format across the ecosystem, they're not even in the same league or sport in terms of effort. If you were going to introduce a whole new object file format it would be much better to do it and justify it on the basis of fundamental technical/architectural changes.
Linux is written in C, whose spec is proprietary. The larger stack has countless ISO standard references etc., all of which refer to proprietary standards you need to buy.
(Personally, that makes me a bit uneasy: for instance, if the copyrighted spec lists the file sections in a certain order, and your implementation happens to output them in the same order even if it doesn't have to, then have you infringed on the owner's copyright of that particular arrangement?)
Meanwhile, they could have gotten a patent on (some parts of) the format, but that doesn't seem to be the case here.
If it is necessary for operation or inter-operation [1] then they can probably not enforce copyright or trademark.
Of course, the defense against this would be to scramble (or normalize) all non-functional choices compared to anything in the spec. But you have to be careful to make sure there's nothing left of the spec's non-functional influence.
At least Oracle v. Google appears to provide some ammunition here in favor of implementers: the court found the transformative use in that case enough to trump even the byte-for-byte copying of the API signatures. So perhaps interoperability could similarly trump such non-functional copying from the spec. But overall, it's still on shakier ground than I'd like.