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

Richard Fontana rfontana at redhat.com
Fri Jul 12 01:56:39 UTC 2024


On Tue, Jul 9, 2024 at 8:29 AM Nathan Willis via License-discuss
<license-discuss at lists.opensource.org> wrote:

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

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

Of course, prohibiting modification is in direct conflict with norms
around free software/open source licensing and free/open/libre
documentation. The two approaches can coexist but it is often awkward.
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. Fedora struggles to be as much of a
_libre_ distribution as possible and I would say some of the biggest
obstacles to this stem from licensing of artifacts of standards
organizations that invariably get bundled in software packages.

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.

Personally, I would rather see specifications licensed under an open
source license.

Richard




More information about the License-discuss mailing list