Hi all, 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 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 can dig up a link to the video I'm sure. 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: - Implementations need to be able to quote from the spec, even sometimes in big chunks, in comments and such, but still not be roped in as derivative works - Code snippets like algorithms, regular expression sets, and even variable 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. 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. 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 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 machinery, from compliance to testing to certification, and that was neither required nor doable, so not desirable. -- nathan.p.willis nwil...@glyphography.com <http://identi.ca/n8>
