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

[Nathan Willis]

Hi Richard; thanks for the comments,

On Fri, Jul 12, 2024 at 2:57 AM Richard Fontana <rfontana at redhat.com> wrote:

>
> This is the key problem with your license in my opinion. It replicates
> a traditional assumption in the standards community that copyright
> should be used to prevent people from modifying specifications. I
> think this was rooted in a bygone era not around interoperability
> objectives but rather business models in which certain prominent
> standards organizations used the sale of  copies of standards
> documents as a revenue stream (perhaps some of them still attempt to
> do this).
>

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.

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.

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.

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.

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).

I have never seen a convincing justification for why standards
> licenses should prohibit modification; it seems more like a cargo cult
> thing. If the goal is to promote interoperability, I would think
> reasonable restrictions on naming of derivative works, whether rooted
> in trademark or otherwise, would be good enough.
>

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.

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).

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.

So, yeah, defining the baseline modification permission differently is a
point well taken, but I was more interested in all the other bits.

For example, the Fedora project classifies standards documents as
> "content" conveniently to allow packages to bundle standards documents
> under licenses that would violate project legal norms around licensing
> of software or documentation.


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.

Nate
-- 
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/20240714/871167e7/attachment.htm>