[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AUCTeX-devel] Re: New auctex version coming, and the freeze

From: David Kastrup
Subject: Re: [AUCTeX-devel] Re: New auctex version coming, and the freeze
Date: Tue, 03 Oct 2006 21:09:57 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2006-10-02) writes:
>> Anyway, I just got back the reply from Richard Stallman, and we can
>> leave off the front and back cover texts and invariant sections (the
>> license text itself will be excluded from being covered by the GFDL
>> since it obviously is not subject to modification).
> That's good news.  I am not particulary thrilled about these features
> of the license, although I understand the reason why they are there.
>> That means that according to the decision of the Debian vote, AUCTeX
>> documentation will be considered DFSG-compliant and will not need to
>> be split even in Debian, without the Debian maintainer having to take
>> responsibility for any compromises on Debian policies.
> So Debian is fine with this particular usage of the license although
> the license includes the options to require cover texts and
> invariant sections?  Interesting.

The BSD license contains implicit options to release binary-only.  It
is not the problem when the options are there.  The problem is when
they get actually used.

>> For most of AUCTeX's developers, I hope this should be sufficient.
> I was about to suggest to wait with the license change until there
> is a final version of the GSFDL which I'd prefer over the current

That was no option.  I have been contacted after a general GNU project
license audit and explained that we did not have the copyright for the
main contributor to the manual.  Richard and Karl finally managed to
secure the assignment of Kresten.  It would have been rather strange
to explain then that I'd prefer to wait for a release of GSFDL and a
change of maintainer policies.

In effect, what we have now is pretty similar to the GSFDL, except
that the license is more complex than I like, in order to explain the
unused options.  I consider it likely that we may move to the GSFDL at
some later point of time.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]