On Mon, Dec 10, 2001 at 02:03:18AM -0500, Branden Robinson wrote: > > Do you think emacs20 should be considered non-free? > I'm undecided on that point.
It seems like it's a good one to consider then.
Let's assume at the outset that it's not going to be declared non-free for
woody, so that arguments like "But it's too near the freeze! Arrggh!" can
be avoided.
Since we're looking at clarifying/changing the DFSG, we'll also ignore
arguments about the precise wording of the DFSG. This probably won't
actually work, but hey, I'll say it anyway.
We'll also assume the only issue is the non-modifiability of some of the
docs. There might be other issues with emacs20 which'll come to light if
people actually take a long hard look at it, but we/I don't care.
So, presumably the reason we like modifiability for programs is so that:
* people can change the code to work in other situations
* people can reuse the code in their own projects
* when the author dies or gets bored or becomes obnoxious,
other people can ensure it keeps working
Are there other reasons?
For docs, this means things like:
* if we change the program we shouldn't have to rewrite the docs
from scratch
* if we want to use the docs elsewhere (like in online help) we
should be able to
* if we use bits of the code in another project, we ought to be
able to use the relevant bits of the docs in that project too
Hrm. Actually, I can't see any invariant sections in the emacs21 manual,
apart from the GPL and the GFDL themselves. Am I blind? Well, apparently
I just don't know how to use info, the invariant sections are listed in
the info file, but I can't get emacs to show them to me. Weird.
So anyway. The only time I can imagine them being a problem is if you
convert the manual to online help on a system that's very pressed for
space. Obviously, this means you drop lots of technical content as well,
but it doesn't seem entirely implausible.
Now, in this case, obviously we don't mind licenses that require the
full license text to be made available to end users, or the source code
for that matter. For a really-pressed-for-space system, you might decide
to print out the licenses and bind them and distribute them that way,
though, or you might decide to include them all on a separate "source"
CD if you're that way inclined. It seems like that'd work for licenses
in general, so would work for the usual sorts of things we have in main
pretty easily.
Possibly the same thing could be done for things like the GNU manifesto.
It certainly doesn't need to be in the online help, but including it
along with the GPL, GFDL and whatever other licenses you have to pass
along doesn't seem like a particular challenge.
Hrm.
Would splitting things in this way (having the interesting text be
available in one media, and the boring text be available in another)
meet the GFDL's requirements, as long as they were always distributed
togethere?
Would it be a reasonable thing to expect people wanting to reuse
documentation to do if they can't include all the invariant sections
as is?
If it is okay, we could do something like limit them to being essay
type pieces (opinions, historical stuff, manifestos, stuff like that),
that aren't obscenely long, and insist that they're only there to augment
the package, not to be the primary purpose of it.
We could go a step further, and get maintainers to put a copy of them
in /usr/share/doc/<foo>/invariant/<title>.<fmt>, so that they can be
reviewed by ftpmaster along with the license, and easily collated by
anyone who might want to collate them.
Or not, I dunno. I would like to see the GNU Manifesto be somewhere
obvious under /usr/doc though...
> I think it's conceivable that I might
> consider some of its documentation non-free.
Well, what problems do you see in us having unmodifiable text in
/usr/share/emacs/20.7/etc/GNU?
> > If we're trying for minimal changes, then deciding emacs20 as packaged
> > right now is non-free is out of scope (since the minimal changes would be
> > to let FDL stuff be considered free, and not make anything we currently
> > consider DFSG-free non-free).
> Minimal changes to our interpretive guidelines (which to date have been
> largely undocumented) or minimal changes to the current contents of
> main? These are distinct goals.
Well, the current contents of main are the way our current guidelines are
interpreted. I'm not inclined to look at those as the same goal expressed
differently, personally: removing the word "not" from point "9" would
be a fairly small change if you're just looking at the number of bytes
changed, but I don't think anyone'd call it a particularly minimal change.
Likewise, if making a small change to wording (like adding a very specific
exception) causes a huge change in interpretation (like assuming there
aren't any other possible exceptions), then I don't see it as a minor
change.
Looking at your list of documents though seems to indicate pretty clearly
there's some stuff which probably oughtn't be considered "free" in main,
though.
> > > The DFSG should be blind as
> > > to the identity of the works whose licenses it measures.
> > Weren't you just exhorting the benefits of relating the proposal to existing
> > packages a minute ago?
> Here's what I mean by ex nihilo reasoning.
Actually, I think "non sequitur" might be the more appropriate Latin. I'm
sure I had a point when I wrote that, but it's not at all obvious to
me that it had any relationship to the comment it was apparently in
response to.
I was trying to point out that while the DFSG should be blind to the
identities, we shouldn't. I've no idea why I thought you'd disagree with
that either. I may just need more sleep.
> > > Granting exceptions to DFSG 3 and 4 for copyright notices and
> > > license texts seems uncontroversial. The problem is that we need more
> > > exceptions than that if some of the present contents of main are not to
> > > come under review.
> > See?
> > Adding exceptions for some things encourages people to think we
> > should review main for any other subtle exceptions.
> And that's a bad thing why, exactly?
Because the DFSG wasn't written to be read pedantically, so if people
do decide to read it pedantically there'll be problems.
> > These things are *guidelines*, they're not pedantically correct rules:
> > adding some explicit exceptions *weakens* their utility, it doesn't
> > improve it.
> I disagree. I think we need to apply the DFSG fairly and consistently,
We're talking at cross-purposes. To be more precise: having some parts
of the DFSG be imprecise and require good judgement and experience when
interpreting (like the discrimination sections, imo), and other parts
specify exact byte limits and algorithmic processes to follow makes the
guidelines as a whole more confusing and less valuable (since people
will be confused as to when they can read the guidelines literally,
and when they can go with the spirit of the thing).
It the difference between saying "We're not worried about whether the
license can be modified" and "The legally binding portions of the
text distributed in /usr/share/doc/<pkg>/copyright may be declared
unmodifiable, along with amounts of non-binding text totalling not more
than 4523 bytes when converted to lowercase and compressed with the
optimal Huffman encoding for the text", not the difference between saying
anything and nothing at all.
> > (which is, again, aiui, just to clarify our stance on licenses, and
> > allow FDL-licensed stuff to enter main in the usual case).
> I'm not sure what the "usual case" for FDL-licensed stuff is.
In that case setting a byte limit now seems even worse. :-/
Not sure why I'm still harping on about that, the byte limit's gone now
isn't it?
> If you're interested in some quick empirical data...
Always. Well. Often.
> *** Packages below this point make no reference to the GNU FDL is made in
> *** packages' debian/copyright files. I consider this a bug.
Filed yet?
> emacs21 [Distro info, GNU Manifesto, GPL, GFDL]
> gawk [GPL]
> gdb ["GDB is free software...", A Sample GDB Session]
> [stabs.info: Stabs Types, Stabs Sections]
Hrm, isn't "A Sample GDB Session" exactly the sort of thing that
*shouldn't* be invariant? If gdb's changed so it doesn't work that way,
it should be modified, and if bits of gdb are reused in a different app
and bits of the docs still apply, then it shouldn't be needed...
> [I have to wonder if the technical information contained in "Stabs
> Types" and "Stabs Section" complies with the intent of the Invariant
> Sections clause of the GNU FDL.]
Likewise.
> glibc [Free documentation!, LGPL]
> wget [GPL, GFDL]
Which seems to make the invariant sections (as far as the FSF uses them)
generally be for licenses and the ocassional politically screed.
Having a general policy of invariant text being allowed for that general
sort of thing, as long as it's both relatively brief and auxiliary to the
point of the package, being okay as long as [a copy of] it is somewhere
standard in /usr/share/doc/<foo> could work pretty well IMO, both for things
like the current emacs20 and stuff licensed under the GNU FDL.
Do we need to start worrying that people other than the FSF will take
it up though? Will we find ourselves distributing everyone and their
dog's take on why free software rulz or why RMS is an idiot or how to
make money fast if we decide this is okay?
I'd be a lot happier if we were allowed to drop the essays, without
being able to modify them. :-/
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
pgpENcxzAZslQ.pgp
Description: PGP signature
