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

[David Kastrup]

Frank Küster <address@hidden> writes:

> David Kastrup <address@hidden> wrote:
>
>> Frank Küster <address@hidden> writes:
>
>>> Moreover, it has a number of other serious flaws, as e.g. outlined
>>> in http://people.debian.org/~srivasta/Position_Statement.xhtml.
>>> The FSF has more or less clearly (sometimes in fact less) stated
>>> that they intend to interpret these clauses in a free,
>>> DFSG-compliant way for the documents they publish.  But that
>>> doesn't guarantee that other copyright holders who use the license
>>> do the same, and in fact it can't guarantee that the FSF will
>>> continue to do so.
>>
>> Frank, PLEASE, PLEASE, PLEASE bring this up and explain this in the
>> feedback for the new GFDL drafts.
>
> This is completely unnecessary.  The FSF has known these concerns
> for years.

As I said: the FSF does not move fast, and they don't have the
personnel for doing so.  The GPLv3 process has taken a lot of focus
and energy lately.

> Representatives have told repeatedly that they are going to fix it,
> but nothing has happened except that once or twice RMS has said they
> won't fix anything.  And more skilled people like me will for sure
> bring this up again.  Debian even has formal delegates for that.

You don't want to have something like "this clause was opposed just by
three developers, so we decided the concerns did not justify further
work".  Without your input, you don't have a reason to complain.

> From the published e-mails, it's not even sure what RMS intent is.
> More so from that fact that the FSF forces their projects to use
> that license while they know about its perceived flaws, and before
> they finish their review process.

That is because the licensing is "under this or any later versions".
Even if the license is not in its final state now, licensing under the
current version does not preclude moving to a version _similar_ _in_
_spirit_ that expresses the intent better.  So there is no reason to
stall moving to the current version, as the way to perfection is not
barred.  And "forces" is a word I don't like.  Nobody forces anybody
to become a GNU project.  Being a GNU project entails the active
support of the FSF for the project, and the active support of the
project for GNU.  This cuts both ways.

>> Don't just hope.  Phrase your concerns: you appear to be one of
>> those who have invested some work in researching the license.  Make
>> it pay off.
>
> I'm just one of the (uneducated guess) 50% of Debian developers who
> actually read the documents they were voting on.  I'm in no way
> particularly qualified.

You are qualified enough to ask on the developer list of a GNU project
for a forking of the manual and try rallying support for it.  You are
qualified enough to call for a strike of the developers of a GNU
project.  You are qualified enough to flaunt the GNU policies and a
maintainer following them and trying to dissuade people from working
on GNU on a GNU project mailing list, using derogatory language.  And
now you are telling me you are not even qualified of putting your
concern into words on the one channel where you can make a
constructive difference?  Because you are not qualified enough?
Please.

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 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.

For most of AUCTeX's developers, I hope this should be sufficient.

> I have no idea about the internal constitution of the FSF and the
> formal role of project maintainers and developers.  But in practice,
> I'm sure the developer teams do have a say.  In the worst case, they
> could go on strike.

The GNU maintainer guidelines are not a secret and can be seen at
<URL:http://www.gnu.org/prep/maintain/>.  I already pointed that out.
The rules for licensing have not changed in the last few years
according to what I am aware of: certainly the use of GFDL was already
prescribed by the time AUCTeX applied as a GNU project.

> I see that I do not get much support for my position, so I won't
> further argue for it.  However, from a pure logical point of view,
> there's nothing that prevents the AUCTeX developers from stopping to
> improve the manual, and from writing a manual outside the AUCTeX
> project as well.  So there is something to decide in fact.  You have
> decided, and I accept this decision.  I hope you also accept my
> decision not to contribute to a GFDL'ed document, at least not in
> the current state of the license.

All development on AUCTeX happens on a voluntary basis.  I have to
accept _any_ decision not to contribute to any part of AUCTeX, for
whatever reason.  And I certainly am not glad to see you go, and in
that manner.  But I should still not wish you success demotivating
other AUCTeX developers from working on our project, for the sake of
pushing your personal agenda not even supported by the Debian voting
outcome.

No part of AUCTeX will end up in Debian non-free without Davide having
to bend Debian rules even slightly.  This is a better situation than
that of Emacs itself, and I am grateful to be able to save users and
developers the respective hassles.

While I have to accept that it is impossible to please everybody, I
hope that the dissatisfaction will stay contained in that manner.

Incidentally: the main idea of checking in the GFDL license even
before the exact conditions were cleared up was to get feedback about
the _layout_ of the changes, not its contents.  So if people see any
problems with the layout or organisation, it would be nice to hear
back.  While I'll change the texts presently, the layout should not be
much affected by the minor adjustments.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum