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

[Nathan Willis]

Hello,

I am interested in hearing some genuine feedback on a new license that I
was in a position to need and have therefore drafted.

It is specifically for a "functional specification", which individual
software implementers might implement separately in their own environments
or software stacks, but which (unlike, say, a network protocol) are not
going to directly interface with other implementations. And to be usable
for free software, naturally (although *not* requiring every implementer to
swear to any particular software licensing ethos).

By way of background, I did a thorough search of other licensing options
before heading down the path of making a bespoke one and, although I see a
lot of commonality in the licenses used on specifications and standards
like IS/IETF or W3C publications, the actual licenses employed there are
specific to those works and to e.g. the W3C itself and, as a result, not
reusable.

Conversely, I think it is evident on even a cursory evaluation that a
boilerplate "document license" like the GFDL or the crop of CC licenses do
not fit several of the specific requirements for a specification license
that software will have to implement. Nor, of course, do software licenses.
I don't want to head into an endless tangent on those points, but if you're
interested in the reasons I enumerated during that survey, please do feel
free to email me privately (or perhaps fork the thread?). I also did a
session in the legal & policy devroom at FOSDEM 2023 about this project; I
would never recommend that anyone spend their precious few remaining hours
watching it, but I can dig up a link to the video I'm sure, in case anyone
is trapped in an elevator or bored waiting for a tow truck.

The point is, though, that, when exploring it, there were a few needs that
stuck out as being peculiar to an "independent functional spec" use case.
The big ones were:

- Software implementations need to be able to quote from the spec, even
sometimes in quite lengthy chunks, in inline code comments, docs sites, and
such, but still not be roped in as derivative works
- Code snippets like algorithms, regular expression sets, and even
variable/token or structure names need to be freely reusable, but not rope
the implementation in as a derivative work
- Translations should be permitted but must be designated as unofficial
(due to the fact that translating human language is always ambiguous)

And those factors would need to interact predictably with a specification
document that is free to read, implement, and share ... but the
specification should not be forked or modified (since that would defeat the
purpose: interoperability).

All that preamble now out of the way, the actual draft license in question
is accessible here:
https://github.com/n8willis/opentype-shaping-documents/blob/license/LICENSE.md

You'll note that it is in a WIP draft and not yet committed. I believe it
is readable at that URL even if you don't use JavaScript etc, but let me
know.

I don't mind going into further details about the preceding project that
has spawned this license scenario, but that could get pretty tangential
pretty immediately. It was work that I was hired to do back in 2018 (and
have updated periodically since then), to do with how font shaping works.
Basically, the gap between the Unicode and Opentype specs, and which
HarfBuzz implements. So most of the writing work was tracing &
understanding HarfBuzz's logic and translating that into documentary form.
The company that hired me to do that then used the doc to develop their own
free-software shaping engine.

I would be most interested in anyone's analysis about the license and how
it would interact with other free-software elements in the ecosystem at
large, as well as whether they think it reads clearly, says what it intends
to, and is reasonable. I have attempted to keep it plain English, so
feedback about the meat & potatoes of the terms (or your preferred menu
substitutes) is more of interest than fine-tuning legalese, at this point
anyway.

It might be a bridge too far to ask whether it sounds like something that
another standards/specification effort could use, but I did try to be
general when writing it, in the hopes of it being useful in the future (and
applying it to another effort as a thought experiment might prove
informative....).

But any reaction or feedback at all would be welcome (although "you
shouldn't write a license / you must have done your research wrong" is not
likely to make it high on the list of comments that warrant a reply.... I,
also, found it surprising that there were not scores of good off-the-shelf
options, but here we are).

Thanks,
Nate

PS - I also know that the functional-spec case is not universal; other
standards might care a LOT about interoperability, but it wasn't in scope
here and adds, potentially, a lot of overhead, from compliance to testing
to certification, and that was neither required nor doable, so not
desirable. That stuff definitely does matter; participation as this project
needed it has been very low-friction via GitHub mechanics, but when I
requested feedback from the Debian list, it was raised as potentially
interacting with the 'translations' lingo, and so far I don't know that I
have a solution that would satisfy the universe, so if you do, I'm all ears
of course.

PPS - I also felt like this was a better fit for the -discuss list than
-review, but that was a judgment call; let me know.

-- 
nathan.p.willis
nwillis at glyphography.com <http://identi.ca/n8>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20240709/124e91f3/attachment.htm>