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

[Bruce Perens]

Hi Nate,

Unfortunately you have a fatal assumption here: that your standard can be
copyrighted. In reality, *the copyright you can assert on a standard is
extremely limited and** probably could not be enforced against software
implementations of the standard at all. *You can enforce that people don't
copy your standard text into another document, but that is probably not
what you want.

This is also true for schematics, which is why the so-called Open Source
Hardware licensing mostly can't be enforced.

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

17 USC 102(b)

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

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.

In particular, you can't copyright function call signatures, variable
names, return values, data structures, pretty much anything a software
standard would cover.

Open Source, of course, implements many APIs, standards, protocols, and
formats simply because they can't be copyrighted.

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

I'm a little surprised that the lawyers on the channel didn't jump to this
issue right away.

    Thanks

    Bruce



On Mon, Jul 15, 2024 at 4:21 AM Nathan Willis via License-discuss <
license-discuss at lists.opensource.org> wrote:

> 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>
> _______________________________________________
> 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 at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>


-- 
Bruce Perens K6BP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20240715/f41ae329/attachment.htm>