Re: License of old GNU Emacs manual

[Matthew Garrett <mjg59@srcf.ucam.org>]

I've Cc:ed this to -project - followups should probably go there.

On Tue, 2005-01-04 at 10:24 -0500, Theodore Ts'o wrote:

> Either way, the people who are pushing the strict DFSG above all else
> have to see that the fundamental problem is that there are useful bits
> out there that Debian users will want to use (such as the autoconf
> documentation --- if someone hasn't issued an ITP for it in non-free
> yet, I will, soon, because I need it), that are licensed under
> licenses that do not meet a strict interpretation of the DFSG.

I agree that interpretations of the DFSG that remove large quantities of
material that we've previously thought of as free software are wrong,
and I'm on record as being opposed to various attempts to do so. But
DFSG 4 requires us to be able to modify content. We're willing to bend
that somewhat due to requirements that the GPL and older BSD licenses
have, but I don't believe that objecting to the existence of large and
unmodifiable sections of political content that can't even be removed is
a desperately strict interpretation of the DFSG.

Now, I agree that the autoconf manual doesn't have this issue, and I
agree that the /other/ problems with the GFDL are significantly less
important. However, as written, the license forbids us from doing
certain things that we generally believe should be possible. It's not
really meant to, and it's fairly easily fixable. The fact that we have
so far failed to do so is something of a disaster (yes, I know that it's
not our fault), but I think we're acting in the right way here. We want
to be /sure/ that we can guarantee our users the rights to put GFDLed
documentation on sites requiring http authentication, or on an encrypted
filesystem or whatever because those are freedoms that we tend to think
are important *practical* issues. And free software is fundamentally
about providing as many practical freedoms as possible.

At some point, we have to draw a line and refuse to allow material into
main if it doesn't ensure that certain freedoms are provided. GFDLed
documentation with invariant sections plainly has issues there, and
that's fairly fundamental. GFDLed documentation without them still has
issues, even if they're accidental. 

> It's only a problem if view this as a central role that Debian can and
> should play going forward.  I happen to think an APT plugin might very
> well be the right thing.  We can mark packages in non-free with
> different attributes how they are "non-free".  Are the packages evil
> firmware, or are the packages evil GFDL documentation from the FSF, or
> are the packages evil in some other form?  Let users choose for
> themselves where they are willing to draw the line, instead of forcing
> depriving users of useful software/documentation/bits --- such as the
> autoconf documentation, (which I need, damn it!) --- because we
> presume that we are somehow entitled to choose for our users what
> software they can and should be able to run.

I don't think it's unreasonable for us to expect our users to make
different choices to us as to what levels of freedom are necessary, and
providing tools to allow them to make that choice sounds like an
excellent idea. However, I think it's also important for us to stick to
the aim of producing a useful OS that can be entirely made up of
components that provide all the freedoms of the DFSG. 

> P.S.  Besides, given that the Debian Logo needs to go into non-free,
> since the terms governing its use are also not DFSG compliant, who are
> we really trying to kid?

I think that that's an argument for the logo being under the wrong
license (and hence us having fucked up in the past) rather than the DFSG
being wrong.
-- 
Matthew Garrett | mjg59@srcf.ucam.org