discuss: Re: [staff] Re: Remote-Serial-Console-HOWTO
Subject:
Re: [staff] Re: Remote-Serial-Console-HOWTO
From:
David Lawyer ####@####.####
Date:
6 Dec 2001 17:55:52 -0000
Message-Id: <20011206095531.A191@lafn.org>
On Wed, Dec 05, 2001 at 11:01:20PM -0500, David Merrill wrote:
> On Wed, Dec 05, 2001 at 01:24:06AM -0800, David Lawyer wrote:
> > > Which brings up a question I have about the plethora of unmaintained
> > > documents under this version of the LDPL. My reading of it says the
> > > HOWTO coordinator has been granted the right to relicense the work. It
> > > says, "you may not produce a derivative work from a HOWTO and impose
> > > additional restrictions on its distribution. Exceptions to these rules
> > > may be granted under certain conditions; please contact the HOWTO
> > > coordinator". First, moving to GFDL is not imposing additional
> > > restrictions, and second the HOWTO coordinator can make exceptions.
> >
> > What about the GFDL requirement to keep "invariant sections" in the doc?
> > This is sort of a "restriction". LDPL is a lot shorter and I don't
> > think that the GFDL is much of an improvement. I think that the new
> > author should make the proposal and then the HOWTO coordinator can
> > approve or disapprove. There is also the short boilerplate license in
> > the Manifesto that some have used. An advantage of keeping it LDPL is
> > that one can "escape" from LDPL at a later date. Once it's GFDL there's
> > no escape if the author isn't around.
>
> It seems the restriction of invariant sections is irrelevant if you
> don't *apply* any invariant sections, right?
But adding invariant sections is always possible by the maintainer or by
anyone modifying the document. I could have gone on about the
"restrictions" of the GFDL. If you want to modify a GFDL document there
are 14 conditions (numbered A thru N) that one must follow. All of them
might be considered "restrictions". The LDPL was shortsighted when
someone put the word "restrictions" in it. There are "good"
restrictions and there are "bad" restrictions. We want only "good"
restrictions where "good" means in the public interest to the benefit
of the user of the documentation. The interpretation of this is of
course subjective. But I think that a number of these 14 conditions
imposed by GFDL are "bad" ones. I'll elaborate this in another post on
the subject of GFDL.
>
> And the manifesto is not the binding document, the LDPL is the legal
> document under which they are licensed. If they have the boilerplate
> text, that doesn't grant Ferg the right to relicense, so I'm not
> suggesting we do something not granted by the verbiage.
Agreed. I only mentioned the boilerplate as a possible license people
might want to use. It's also not a very good license, except that it's
very short and easy to understand.
>
> I don't think the GFDL is an improvement on the LDPL either. It says
> very much the same thing. But it *is* a much more widely accepted
> license and that counts for a lot in practical terms.
It says a lot more than LDPL. I would like to see LDP have a much
better license than GFDL and encourage LDP authors to switch to that
license. But once someone takes over a GFDL doc, they must stay with
GFDL.
>
> > > Do Ferg and Dave read it that way also? If so, I would like to use
> > > that authority to relicense all the unmaintained LDPL documents
> > > under GFDL or OPL to keep them in Debian. I don't really have a
> > > preference, since they are substantially the same, but I'd rather
> > > stick with GFDL. It allows merging documents, for instance, which
> > > we've done several times, without license conflicts. Let's try to
> > > stick to it, but any author who objects can of course do as they
> > > will. I'm not mandating anything.
>
David Lawyer
