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 nwil...@glyphography.com <http://identi.ca/n8>
_______________________________________________ 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
