Subject:
Re: RFC: review of unpublished source documents
From:
Rick Moen ####@####.####
Date:
24 Feb 2016 22:28:50 +0000
Message-Id: <20160224222953.GF24965@linuxmafia.com>
Quoting Martin A. Brown ####@####.####
> Intro-Linux
> -----------
> I suggest publishing (contingent on author and license question).
>
> (guide/docbook/Intro-Linux)
>
> This was written by Machtelt Garrels (Tille), a formerly active TLDP
> volunteer and contributor. The license says:
>
> https://github.com/tLDP/LDP/blob/master/LDP/guide/docbook/Intro-Linux/abook.xml#L362
> http://tille.garrels.be/training/tldp/pr01s07.html
>
> This is not one of the known-acceptable licenses in the license
> list. Is that license acceptable to LDP?
The licence text at http://tille.garrels.be/training/tldp/pr01s07.html
is the 3-clause BSD License, except that he's fooled around slightly
with the wording of clause #3 to change 'copyright holder' to 'author, ,
Machtelt Garrels'. That appears to be the only difference. Compare:
https://opensource.org/licenses/BSD-3-Clause
I wish people wouldn't do this sort of tinkering, as it can produce
slightly weird, unintended legal effects. In this case, the unintended
effect is to permanently tie the work to Machtelt, making any
replacement maintainer not the 'author', just a 'contributor', and
making the licence text itself gratuitously specific to Machtelt.
Is this a problem? Not really. It's just a minor wobble. The
important thing is that the licence conveys all necessary rights and is
a 'forkable' licence.
But please, folks. Please resist the urge to tinker with a standard
licence text. (Maybe if we ask Machtelt politely, he'll consent to
changing to fully standard 3-clause BSD terms. He need not issue a
new instance of the work. It's enough that he say 'Yes, you may change
that for me.')
I'm one of the volunteer evaluators of licences submitted to Open Source
Initiative (on the license-review and license-discuss mailing lists),
and can say that OSI has for the past decade-plus received an ongoing
barrage of _permissive_ licences with minor differences (of the
'tinkering' variety), chewing up the time of licence evaluators on
usually pointless and somewhat silly variations -- sometimes making the
licences totally (yet unintentionally) dysfunctional. Oddly enough, I
would have expected this problem to involve silly, sometimes broken
_copyleft_ ('reciprocal') licences, but no: It's pretty much always
silly, sometimes broken permissive licences, instead.
But at least the above is clearly open source (spitting cousin of
3-clause BSD with, in effect, a minor branding difference), rather than
something _really_ weird and screwball, like:
o 'WTFPL v. 2': Permissive licence so badly written that it grants
rights only to the _licence_ itself, and not to any ostensibly
covered work.
o 'Unlicence': Paragraph (and sentence) #1 professes to put the
covered work into the public domain. Paragraph 2 professes to be
a grant of rights normally reserved by default to a copyright owner,
which makes no sense given that the preceding sentence professed to
eradicate the work's quality of being ownable. _However_ (upon
reflection), in itself that would be harmless if redundant and
pointless: One can interpret paragraph 2 as an elaboration of
the consequences of the first paragraph.
Paragraph 3 is mostly further explanation of the concept of public
domain, and therefore harmless if not useful. Its middle sentence
elaborates that the erstwhile author aims to bind heirs and
successors, too (which is a logical inclusion, irrespective of
whether it works).
Paragraph 4, though, is the one that would be amusing if it weren't
tragically broken: It's the warranty disclaimer. People accepting
the covered work are obliged to accept the condition of no warranty,
otherwise there is no licence. Except, oh, wait: Paragraph 1
professed to put the work in the public domain, so the erstwhile
owner has sawed off and evaporated in paragraph 1 all power to
require the condition in paragraph 4.
o 'Public domain': The effect of declaring one's work public domain
by personal fiat is legally non-deterministic, as it may have the
intended effect in some jurisdictions but fail in others where
it is known to not work (such as the UK), resulting in a silent
failure to grant permission at all. Or judge might rule it to have
some other effect. The work's user has to roll the legal dice to
find out, which is exactly what you as a creator do _not_ want to
achieve with licensing.
Software people should as a general rule not attempt to do the work of
attorneys (and, if they're lucky, attorneys won't write their software).
In both cass, unintentional comedy is the likely result, at best.
