<div dir="ltr"><div>Hello,</div><div><br></div><div>I am interested in hearing some genuine feedback on a new license that I was in a position to need and have therefore drafted.<div><br></div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- 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</div><div>-
 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<br></div><div>- Translations 
should be permitted but must be designated as unofficial (due to the 
fact that translating human language is always ambiguous)</div><div><br></div><div>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).<br></div><div><br></div><div>All that preamble now out of the way, the actual draft license in question is accessible here:<br></div><div><a href="https://github.com/n8willis/opentype-shaping-documents/blob/license/LICENSE.md" target="_blank">https://github.com/n8willis/opentype-shaping-documents/blob/license/LICENSE.md</a></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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....).</div><div><br></div><div>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).</div><div><br></div><div>Thanks,</div><div>Nate</div><div><br></div><div>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.<br><br>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.</div></div><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">nathan.p.willis<br><a href="mailto:nwillis@glyphography.com" target="_blank">nwillis@glyphography.com</a><a href="http://identi.ca/n8" target="_blank"></a></div></div></div></div>