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 _______________________________________________ The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
