Subject:
Re: LDP Licence at http://tldp.org/COPYRIGHT.html, and changing in-place
From:
Rick Moen ####@####.####
Date:
26 Jan 2004 04:01:37 -0000
Message-Id: <20040126040136.GF29859@linuxmafia.com>
Quoting Guylhem Aznar ####@####.####
> On Sun, 18 Jan 2004 23:11:24 -0800
> Rick Moen ####@####.#### wrote:
> > > Whabout about creating a separate "history" page in the copyright section?
> >
> > I'm not sure I understand this question. Sorry.
>
> COPYRIGHT.html would contain our default/agreed/basic/whatever
> license, with a link at the beginning to the past versions and a
> proeminent warning "Previous versions for historic purposes only"
Ah, thank you for elucidating! (I really wasn't trying to be difficult,
honest. I honestly didn't understand your suggestion.)
That would certainly be an improvement on the present situation.
However, it would _continue_ the current implication that the
default/agreed/basic/whatever licence applies to various LDP documents
citing its URL, when that very likely is not the case.
I keep seeing a desire on LDP volunteers' part to make the issue go
away. That's perfectly understandable. However, at the risk of
repetition, the reasoning behind my earlier suggestion was that it was
the best way I could find to remedy the situation resulting from the
(very bad, in my opinion) decision to change the licence in place --
rather than papering it over. The phrase "for historic purposes only"
is at least _thinner_ paper, which is (I guess) an improvement.
I get the recurring impression that LDP volunteers seriously think that
changing the document at that URL has the legal effect of changing
covered documents' terms of usage. That is most unfortunate, in my
view. I would think that LDP would want to remedy the problem it
(inadvertanly) caused. Oh well: At least my own LDP documents are no
longer affected.
> > Huh? I'm afraid that, once more, I do not follow.
>
> Keeping too many licenses impers interoperability - if only because of
> the number of licenses to choose from
Let's please back up a moment, and consider what interoperability means
for software licensing (and then for software documentation licensing,
as an extension of that). The question arises for software when it
becomes desirable to create a derivative work from two codebases of
differing licensing.
An example would be when my friend Marc Merlin added TLS/SSL support to
the Exim MTA by linking it against OpenSSL. This created a problem
because Eric A. Young's code withing OpenSSL is under the old BSD
licence, and Exim is GNU GPL (with which the old BSD licence's
advertising clause clashes). The result was that, although Marc's TLS
variant of Exim was lawful to use, it wasn't lawful to distribute --
until Marc secured a licence exception from Exim copyright owner Philip
Hazel (which fortunately was easy in Philip's case).
The same variety of problem _could_ theoretically arise with software
documentation -- except that it's very rare to need to create such a
combination of disparate documents. If you do, and there's a conflict,
then either getting a licence exception or writing a substitute for one
of the components to skirt its copyright encumbrance is generally easier
than for software. Thus, I expect that clashes of documentation
licensing will be both rare and seldom a significant problem.
> Take some old interesting document with an uncommon license, banning
> the document from Debian for ex. - this is a problem since it can't be
> updated and removing it won't be easy if most people like it.
Is this likely?
I was, back around 2001, denied by psychologist Stanley Milgram's widow
the right to publish on my Web site one of Dr. Milgram's long
out-of-print articles. I'm dealing with that obstacle by paraphrasing
it -- something much easier to do with writings (of low to moderate
length) than with software.
To use your example, Debian does not presently even bar documentation
under the proprietary GFDL licence, although it might do so in the
future. I doubt that LDP currently has any documents whose licences
prohibt inclusion in Debian GNU/Linux, and suspect it's unlikely to
accept any.
LDP may wish to either encourage or require in the future use of a
forkable licence, but even that needn't reflect a concern with "too many
licences", only with licence acceptability in other places.
> It's a causing more problems to TLDP because unlike software the BSD
> and GPL are not the most common licenses : much more restrictive
> licenses are preferred.
So, are you saying you want fewer licences, or are you saying you want
forkable ones? Those are different issues, and you seem to be
suggesting they're identical.
Now, having "fewer licences" would no doubt be less messy and easier to
think about. Good luck convincing authors. ;->
> > It is likewise unclear to me why you would wish to "agree on a
> > common licence", and unclear to me what would be achieved by doing
> > so.
>
> We would in one step fix license-boud problems such as :
> - new authors updating old documents
> - merging old documents (ex: the lilo linux/nt/os2/fat/etc serie)
> - having our documents included in distributions where licensing
> issues matter.
1. New authors updating old documents doesn't require a "common
licence". It requires either the copyright holder's permission or a
forkable licence.
2. It is unclear to me that "merging old documents" occurs more than
once in a blue moon and isn't fairly easily dealt with (in such rare
cases) as detailed previously.
3. Having LDP documents included in distributions where licensing
issues matter might (in some cases) require forkable licences, but it's
illogical to suggest that it necessarily requires fewer licences.
> I'm sorry that you don't see these problems and how they affect TLDP.
I'm sorry, too, since I'd like to be of assistance. But I'm getting the
impression that you seek simplicity at the expense of much else, and
that does not seem to bode well.
> > you are aware that "relicensing" is something possible only to
> > copyright holders, in any event.)
>
> I do - I think the author could possibly agree to a contract which
> would cause his document to be relicensed on some event (ex: can't be
> reached for 6 months) and passed to a new authors following some
> criterias (ex: new title, old author name indicated in a table of
> former authors).
I strongly suggest you consult an experienced copyright attorney, if you
are seriously contemplating this. (I'm not an attorney of any stripe,
but I greatly doubt that such a contract can confer copyright title --
leaving aside whether authors are likely to agree to it.)
[document licence incompatibilities:]
> The only reason why it's rare is exactly the license problems. And
> even in you consider it's just a minor factor, why don't you want to
> fix it?
Well, by doing what, exactly? If I could wave my magic wand and induce
all documentation writers to prefer and use the same (forkable) licence,
I might do so. But my magic wand's in the shop for repairs, so I'm left
to consider what's a cost-effective expenditure of time, effort, and
persuasive powers. So:
1. If LDP adopts some "standard" licence, is it prepared to refuse
admission to otherwise attractive contributions that have a slightly
different forkable licence?
2. If LDP author foo wishes to incorporate 200 lines from incompatibly
licensed document bar, is his need to either get (or grant) a licence
exception or rewrite 200 lines an earth-shaking problem?
Make up your own mind, of course. I'm not here to argue -- but I
suspect that that policy change would limit LDP's appeal to authors for
very little gain in return.
> For ex, 2 of my documents where created upon an existing basis (Mail &
> UUCP HOWTO) which was then split (Mail Administrator / Mail User
> HOWTO) etc. What if in the future we want to integrate different
> documents in a printed book?
Does the licensing stand in the way of _aggregation_? That would indeed
be a problem -- but I doubt that LDP has works with such obstacles. Are
you saying such hideous licensing problems _do_ exist, or was this just
a farfetched hypothetical with no connection to present reality.
Please note that aggregation of such multiple documents into a printed
book doesn't require that the constituent documents' licences be either
forkable or compatible (where "compatibility" relates to creation of
derivative works).
> Or simply in one big online guide covering everything from email to
> system security ?
That sounds like aggregation, to me. Is there some issue I'm missing?
> What if some chapters on new email subsystems are to be added and my
> document can't be included in Debian because of my past license choice
> GFDL?
I'm having a difficult time parsing that question. Are you talking
about the question of Debian's accepting a (hyopthetical) "big online
guide" containing a GFDLed chapter by you? If so:
1. Debian does not at present reject GFDLed works. It might do so in
the future.
2. In that event, Debian would have the option of asking you to
dual-licence. Remember, a licence applies to an _instance_ of a
creative work. The copyright holder is always free to issue additional
instances under different terms. (Authors who could not be contacted,
or who would decline such a request, would indeed be an obstacle.
Debian would then be obliged by its theoretical future standards to
either omit that portion or find a substitute.)
But indeed, aside from that, that would be a perfect instance of what
I've been talking about all along, of the usefulness of forkable
licences for long-term document viability.
3. But this should not be confused with a problem of "too many
licences".
--
Cheers, "A raccoon tangled with a 23,000 volt line, today. The results
Rick Moen blacked out 1400 homes and, of course, one raccoon."
####@####.#### -- Steel City News
