4 ms·

> How does the ABI end up being “All rights reserved” by SCO? Text of the spec is copyrighted by the SCO, they did not put it in public domain. That's what "Al

> How does the ABI end up being “All rights reserved” by SCO? 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.

LegionMammal978 2y ago
Yeah, it's not like they could copyright the ELF format anyway, only that particular description, or any particular implementation they had. Pretty much everyone seems to agree that file formats themselves aren't copyrightable expression, though I have trouble finding any U.S. case law to that effect. (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.
- Veserv 2y ago
  The rule in general (not just for software) is that patents are for functional elements where as copyrights are for non-functional elements; they are exclusive, a element can only be patentable or copyrightable, not both. If it is necessary for operation or inter-operation [1] then they can probably not enforce copyright or trademark. [1] https://en.wikipedia.org/wiki/Sega_v._Accolade https://en.wikipedia.org/wiki/Sega_v._Accolade
  - LegionMammal978 2y ago
    Sure, but usually in any file format, an encoder has some choice in how to produce its output, with no functional difference either way. For instance, different PNG encoders might include the necessary chunks in a different order in the file. And my concern is that some such choices, if they align with choices described in the copyrighted spec, might be protectable as a creative arrangement or similar. (E.g., a spec might list the chunks in such an order that their names form a creative acronym.) 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.
- MaskRay 2y ago
  I feel that The SCO Group's role in the evolution of the System V ABI seems to have been more of a curator/editor than an innovator, inheriting the System V ABI from previous entities. Given that the Tool Interface Standard (TIS) Committee has essentially released the ELF-related chapters into the public domain, and others have made changes, it's unclear what specific rights The SCO Group (and now Xinuos) could claim to reserve. (That said, their maintenance work needs to be remembered.)
vintagedave 2y ago
It's concerning that a huge open source ecosystem like Linux depends on a closed specification. That is, I read it as that the spec cannot be continued, developed, and evolved or republished without full redefinition and respecification. 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.
- yjftsjthsd-h 2y ago
  I wouldn't think you'd need to create a new format, just write up a spec of what all available FOSS implementations are actually doing and agree that that's the standard going forward. Between Linux/*BSD/illumos you should be able to pretty completely describe all currently-active uses of ELF. (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.)
  - skissane 2y ago
    > Between Linux/*BSD/illumos you should be able to pretty completely describe all currently-active uses of ELF. 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)
    - Iwan-Zotow 2y ago
      To WHAT transition?
      - yjftsjthsd-h 2y ago
        Lol. Although, Itanium does have an entertaining history of having caused a lot of positive changes even though it crashed and burned itself - it's where we got UEFI, and apparently a good time for some OSs to pick up ELF.

LegionMammal978 2y ago

Yeah, it's not like they could copyright the ELF format anyway, only that particular description, or any particular implementation they had. Pretty much everyone seems to agree that file formats themselves aren't copyrightable expression, though I have trouble finding any U.S. case law to that effect. (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.

Veserv 2y ago
The rule in general (not just for software) is that patents are for functional elements where as copyrights are for non-functional elements; they are exclusive, a element can only be patentable or copyrightable, not both. If it is necessary for operation or inter-operation [1] then they can probably not enforce copyright or trademark. [1] https://en.wikipedia.org/wiki/Sega_v._Accolade https://en.wikipedia.org/wiki/Sega_v._Accolade
- LegionMammal978 2y ago
  Sure, but usually in any file format, an encoder has some choice in how to produce its output, with no functional difference either way. For instance, different PNG encoders might include the necessary chunks in a different order in the file. And my concern is that some such choices, if they align with choices described in the copyrighted spec, might be protectable as a creative arrangement or similar. (E.g., a spec might list the chunks in such an order that their names form a creative acronym.) 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.
MaskRay 2y ago
I feel that The SCO Group's role in the evolution of the System V ABI seems to have been more of a curator/editor than an innovator, inheriting the System V ABI from previous entities. Given that the Tool Interface Standard (TIS) Committee has essentially released the ELF-related chapters into the public domain, and others have made changes, it's unclear what specific rights The SCO Group (and now Xinuos) could claim to reserve. (That said, their maintenance work needs to be remembered.)

vintagedave 2y ago

It's concerning that a huge open source ecosystem like Linux depends on a closed specification. That is, I read it as that the spec cannot be continued, developed, and evolved or republished without full redefinition and respecification. 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.

yjftsjthsd-h 2y ago
I wouldn't think you'd need to create a new format, just write up a spec of what all available FOSS implementations are actually doing and agree that that's the standard going forward. Between Linux/*BSD/illumos you should be able to pretty completely describe all currently-active uses of ELF. (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.)
- skissane 2y ago
  > Between Linux/*BSD/illumos you should be able to pretty completely describe all currently-active uses of ELF. 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)
  - Iwan-Zotow 2y ago
    To WHAT transition?
    - yjftsjthsd-h 2y ago
      Lol. Although, Itanium does have an entertaining history of having caused a lot of positive changes even though it crashed and burned itself - it's where we got UEFI, and apparently a good time for some OSs to pick up ELF.