<div dir="ltr">Hi Nate,<div><br></div><div>Unfortunately you have a fatal assumption here: that your standard can be copyrighted. In reality, <i>the copyright you can assert on a standard is extremely limited and</i><b style="font-style:italic"> probably could not be enforced against software implementations of the standard at all. </b>You can enforce that people don't copy your standard text into another document, but that is probably not what you want.</div><div><br></div><div>This is also true for schematics, which is why the so-called Open Source Hardware licensing mostly can't be enforced.</div><div><br></div><div>This comes from the second paragraph of US copyright law, which is generally duplicated in other nations (because the US imposes its IP law on other countries through treaties).</div><div><br></div><div>17 USC 102(b)</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>(b)In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.</div><div><br></div></blockquote>That is because all of those things are the domain of patent rather than copyright. You may patent unique elements of your standard that haven't been invented before, if there are any, but this is somewhat unlikely.<div><br></div><div>In particular, you can't copyright function call signatures, variable names, return values, data structures, pretty much anything a software standard would cover.</div><div><br></div><div>Open Source, of course, implements many APIs, standards, protocols, and formats simply because they can't be copyrighted.</div><div><br></div><div>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).</div><div><br></div><div>I'm a little surprised that the lawyers on the channel didn't jump to this issue right away.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 15, 2024 at 4:21 AM Nathan Willis via License-discuss <<a href="mailto:license-discuss@lists.opensource.org">license-discuss@lists.opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Richard; thanks for the comments,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2024 at 2:57 AM Richard Fontana <<a href="mailto:rfontana@redhat.com" target="_blank">rfontana@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This is the key problem with your license in my opinion. It replicates<br>
a traditional assumption in the standards community that copyright<br>
should be used to prevent people from modifying specifications. I<br>
think this was rooted in a bygone era not around interoperability<br>
objectives but rather business models in which certain prominent<br>
standards organizations used the sale of  copies of standards<br>
documents as a revenue stream (perhaps some of them still attempt to<br>
do this).<br></blockquote><div><br></div><div>Yeah, it's a blunt statement currently, but — ironically — that's because I was primarily interested in hearing any analysis others had of the custom clauses discussing translations, quotations, and code, etc. To that end, it was simpler to lay down a broad baseline and then work on the carve-outs, so to speak. I found it a little tricky to dial back the baseline permissions without getting extremely lengthy or having bits like the "quotations" bullet point go incoherent. Of course, I haven't really heard any reactions to the specific carve-out clauses, so maybe they aren't unclear but, if anyone was fixating on the baseline without scrutinizing the carve-outs, I would like to clarify that takes on those are of interest, because there were not a lot of prior examples to compare.<br></div><div><br></div><div>Regarding the mechanism used to dissuade the creation of competing forks, that mostly boils down to the fact that this is a project without resources.The thing that I found unhelpful in existing examples is that open-standards orgs that do _not_ make a copyright-based attempt to deter forks (almost?) all seem to do it through either compliance programs or certifications, which I guess both seem like what I'd call trademark-based approaches (feel free to say that's not the appropriate term, of course), even if they don't explicitly put trademark statements on things like including the org's name in the title. Or else there's some sort of pay-to-participate model.<div><br></div><div>Saying people have to be "members" to participate is very obviously a non-starter. Certifications means ongoing effort on the part of the project (which in this case, can't happen); and as for simple trademark policies ... well, I don't see a lot of examples of that in small FOSS projects to crib from. I'd like to see some. I spent a long time probing that specifically for fonts (where I consider it a better approach than the RFN option in the OFL). The docs live (currently) under my username on GitHub, but *I* do not want or intend to defend a trademark for the specification. If it were to get adopted by a standards body, that problem would go away and open up some of those options. The company that underwrote the writing of the docs was hoping that a standards body would see their usefulness and agree to adopt them, but that hasn't happened. And I have to believe that the "small FOSS project with no funding or staff" case is still an important one to many others.<br></div></div><div><br></div><div>So the language in the draft license (rather than the non-identical 
phrasing in my first email) talks about forks and changeset-suggesting, as 
ways to piggyback on the GitHub infrastructure and mechanics rather than
 define processes for participation, which a large standards body might have. The way GitHub back-links forks to 
their originating repository is helpful in that regard.</div><div><br></div><div>As far as where the baseline modification-permission goes, I did think about phrasing that stuff in terms of the intent of the forker (forkist?) but that feels sketchy to me (like the "for use as a technical specification"  already creeps close to, which elicited no comments).<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I have never seen a convincing justification for why standards<br>
licenses should prohibit modification; it seems more like a cargo cult<br>
thing. If the goal is to promote interoperability, I would think<br>
reasonable restrictions on naming of derivative works, whether rooted<br>
in trademark or otherwise, would be good enough.<br>
</blockquote></div><div><br></div><div>Part of the concern originally was the pre-existing interoperability problems. Multiple, incompatible forks is not a hypothetical concern in this case, it's the longstanding status quo and the primary source of trouble for everyone. The vendors currently implementing shaping are overwhelmingly proprietary, if you go by the number of seats, and in commercial competition with each other. They can and do implement behavioral changes, and still claim to be following the OpenType (or OFF) specification and The Unicode Standard.</div><div><br></div><div>So there would be uphill work required to bring currently-incompatible implementations into full interoperability, and perhaps even some resistance. But more importantly, new implementors only have those (1) ever-changing and (2) divergent vendor implementations to compare against. So a frozen document improves on (1) at least, and not having multiple modified forks of the document out there simultaneously improves on (2).<br></div><div><br></div><div>I did also think about a renaming clause (with a shudder from RFN encounters), but in practical terms I couldn't really see a way to implement that that was different from the trademark-based approach. If the relevant community embraces & adopts the specification (or a standards body takes it on), then they could decide on a name to defend, but I can't take that on personally.</div><div><br></div><div>So, yeah, defining the baseline modification permission differently is a point well taken, but I was more interested in all the other bits.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For example, the Fedora project classifies standards documents as<br>
"content" conveniently to allow packages to bundle standards documents<br>
under licenses that would violate project legal norms around licensing<br>
of software or documentation.</blockquote><div><br></div><div>There are also some standards docs that Debian packages in nonfree, such as W3C ones. To be honest, I feel like making web standards locally-installable software packages borders on frivolity. Folks care, which is great, but I think I would consider packaging standards documents into an OS distribution package a "nice-to-have" but not compelling as a requirement. I suppose there are people stuck on desert islands with Debian DVDs who disagree.</div><div><br></div><div>Nate <br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="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>
_______________________________________________<br>
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 <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> email address.<br>
<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div>Bruce Perens K6BP</div></div></div></div>