[License-discuss] Request for feedback: public specification licensing

[Rob Landley]

On 7/16/24 10:35, Giacomo Catenazzi wrote:
> On 15.07.2024 18:43, Bruce Perens via License-discuss wrote:
> 
>> In particular, you can't copyright function call signatures, variable 
>> names, return values, data structures, pretty much anything a software 
>> standard would cover.
Oracle tried. Went to the supreme court in 2021 and was ruled "copyrightable but
fair use".

https://www.eff.org/deeplinks/2021/04/victory-fair-use-supreme-court-reverses-federal-circuit-oracle-v-google

So still a bit of a minefield, and I wouldn't touch a standard that _tried_ to
impose license terms on users, on the theory its perpetrator is indicating
they're a litigous twerp who will saber rattle and cost me money defending
myself. (Possibly after their "standards body" gets acquired by IP troll du
jour: who is in charge now doesn't mean who inherits later will be sane. I was
working at a company with a build pulling standard headers off https://vhdl.org
when Accelera Inc. had a reorg and took the site down.)

>> Open Source, of course, implements many APIs, standards, protocols, and 
>> formats simply because they can't be copyrighted.

The case law in the above disaster says they CAN be copyrighted, but that "fair
use" is an affirmative defense when you get sued, and it's up to a jury to
decide each instance.

The EFF article extensively quotes Justice Breyer, who retired in 2022.

>> The limitations of copyright and licenses are mostly not understood at 
>> all by programmers. This results in a lot of inapplicable terms and 
>> often sadly humorous ones (like licenses that attempt to stop war).
>> 
>> I'm a little surprised that the lawyers on the channel didn't jump to 
>> this issue right away.
> 
> It is not the point, and for sure Nate know it, else I assume he would 
> not "copy" the interface from Harfbuzz.
> 
> But a standard is much more then just API and structures. As we learned: 
> "nobody can build a network stack just reading RFC, without looking BSD 
> code",

Sure you can, but you need to look at the packets going across the wire to
interoperate with existing stuff. (And then regression test lots against
existing devices.)

> for this reason "reference implementation" is important (and part 
> of the original question),

IETF has always wanted at least two independent interoperating implementations:

  https://datatracker.ietf.org/doc/html/rfc5657

A magic implementation like Excel or Word defining a protocol is problematic,
because every corner case of what it does IS the standard (regardless of what
the man page says).

This one of the reasons Python 3 has been so problematic, especially now that
it's common practice for python programs (such as the qemu build or the kernel's
b4 tool) to check the version number and refuse to run if the runtime's version
is less than about 18 months old. That means there's one magic implementation
with a significant version number, so you can't have alternate implementations
of the language like other languages do, ala https://github.com/symisc/PH7 or
https://github.com/mruby/mruby or the zillions of C compilers (clang/llvm, pcc,
tinycc, https://github.com/libfirm/cparser...)

> but also text and rationale. And who read 
> standard, could really see which one had good writers and which really 
> not (so artistic part is necessary not to have a dry standard). And Nate 
> was a writer of LWN, so I expect more on good writer team.
> 
> We can look at Unicode Standard: the text is much more than just a 
> standard, it has a lot of linguistic and stylistic works. For the rest 
> we just use the Unicode Database (which it is distributed separately). 
> Without such good Unicode Standard text, I doubt Unicode would be so 
> loved (and understood),

UTF-8 is loved. Unicode puts combining characters AFTER the base character so
you never know when you're done with a character until you've read PAST it.
That's just _obviously_ nuts.

The most recent long thread I had with Android's base OS maintainer complaining
about unicode parsing insanity was only a couple months ago:

http://lists.landley.net/pipermail/toybox-landley.net/2024-May/030416.html

Note that bionic (which he maintains) doesn't even TRY to handle unicode
properly when static linked because it wants to pull in a third-party library
that's considered too big for static linking, so it stubs out wcwidth() and
friends and punts a lot of stuff that makes the toybox tests fail. (Which is
annoying trying to test NDK builds on a debian host...)

Rob