[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:
>
>>> Although that's the outcome of the Debian vote, it's still logically
>>> flawed.  And I still do not want my work to be licensed under the
>>> current GFDL.
>>
>> Let's face it: the GPL is unsuitable for a manual.  You can't hand
>> somebody a copy on paper without handing him a written offer for
>> the source code of it (for three years) and/or handing him the
>> source code on a machine readable medium.
>
> The GFDL is also unsuitable for a manual.  When you hand out more
> than 100 copies, you must also provide the source code online for
> (for one year instead of three, well) or include the source code in
> machine-readable form.

Frank, that's a red herring.  You wanted to fork the manual under the
GPL, and there you need to include the source code for every single
hardcopy.  It is not even clear with the GPL what the act of printing
produces: a derived work or a modification?

> 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.  If the FSF says it wants the
license interpreted in some way, and the text could be taken
to mean something different, this is the sort of thing that the FSF
will want to fix:

a) since they would rather than not have the license just interpreted
as they do,
b) they are legally able to incorporate such changes without violating
their promise to authors that "subsequent licenses will be equal in
spirit".

Now it might happen due to the "similar in spirit" warrantee that the
GFDL will still provide invariant sections.  Eben Moglen has been on
record saying that it won't in a recent interview, but the drafts look
different, and a "simplified" version has been added without invariant
sections.  I hope that the GNU maintainer guidelines will permit using
the simplified version once that has been passed.

But it might also mean that documents historically under the GFDL will
not easily be turned into documents where nobody can add an invariant
section.  No idea how this is intended to work out all in all.

But if you find that the license is not able to secure the _intent_
and interpretation of the FSF, by all means give some feedback to the
drafts.

>>> And as for the "slated for change", the FSF could have done that
>>> months (years) ago, but they didn't.  So why should I believe that
>>> it's going to happen, and when?
>>
>> The drafts and calls for discussion for the GFDL and the GSFDL have
>> been announced and posted just this week.
>
> This is new to me, and in fact changes the situation.  I really hope
> things will change for good.

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 didn't mean that you speak for me.  But it might help to tell the
> FSF that not only some outsiders, "the Debian project", but also
> members (well, loosely associated members in my case) of their
> development teams oppose to the current GFDL.

There have been internal discussions.  Nobody is really happy with the
current state of the GFDL, but it was something that needed to be done
at that point of time.

> As I already said, the invariant sections are a reason for not
> including the document in Debian, but the reason for not
> contributing (unless the new GFDL version turns out to be acceptable
> to me) is the complete license.

It won't "turn out" without people having concerns describing the
concerns and possible remedies.  And in contrast to GPLv3 feedback of
the "please don't do anything about DRM and patents" sort, the
feedback of "this could be interpreted other than you think" kind is
quite more likely to lead to actual changes: it is hard to suggest to
the FSF to change their intent, but changing their wording is much
more likely to register.

>> Feel free to use the provided feedback channels for the current
>> draft of the GFDL and GSFDL.  If you have a concern with them, I
>> would consider your energy better invested explaining it there
>> properly rather than trying to fork a GNU project and making some
>> message in that rather divisive manner.
>
> I trust there are enough people who have a similar opinion as I
> have, and more experience in dealing with such topics, as well as
> with FSF representatives and processes, than I have.

Sigh.  And they all say it is a sham, and afterwards everybody
complains about the results and that the FSF did not bother about the
developers' concerns that have been publicized in a basement of an
abandoned building without a staircase and light under a locked filing
cabinet in the lavatory with the "beware of the leopard" sign on it.

Happens all the time.

> Making developers of FSF projects aware of the "bugs" in the license
> for their documentation is also something I consider important.

It is completely irrelevant.  They don't get to decide about this.
The only way to discuss this is to bring it up with Richard Stallman.
The developers are not responsible for the political decisions.  The
task of the maintainers is it to put the guidelines into practice.

If there had been anything where the developers had a say, I would
have asked on the list.  But the time when this was decided was when
the project applied to be a GNU project.  I told the people that there
were guidelines to follow (and pointed out those I thought would have
the most impact) and a price to pay.  The set of developers at that
point of time supported my decision.

Recently Karl Berry made a license audit of GNU projects and told me
that the license of AUCTeX's documentation did not conform to the
project guidelines.  At that point of time, we were still missing the
copyright assignment from Kresten, so I would not have been able to
change the license reasonably.  This prompted Richard and Karl to
invest some work to round up Kresten (which I had failed to succeed in
for several years, though I tried quite a few times) and get this
problem out of the way, one of the biggest obstacles for AUCTeX
becoming a part of Emacs at some point in the future.

The price, if you want to call it that (and it will make quite little
difference for the vast majority of AUCTeX users, in particular since
the license, having no invariant sections, is tamer than the Emacs
documentation) was that there was no more reason to postpone the
change to GFDL.

It was nothing that I discussed on the list (though I told people the
result) because there was nothing to vote about.  As a GNU maintainer,
a job I have assumed with support of other developers in the interest
of the AUCTeX project, it is my responsibility to see to the policies
of the GNU project.  It is not a particularly wonderful job, but it is
something that needs to be done in the course of having put AUCTeX
under the umbrella of the GNU project, close to Emacs.

It is my conviction, GFDL or not, that this is the best course for
AUCTeX.  And the best way to remove perceived shortcomings of the
licensing of AUCTeX's documentation in my opinion is not to start a
duplication of effort, but rather correspond with the FSF.

Yes, the FSF works slowly, but it does listen and move eventually as
long as one tries staying a serious conversation partner.

> I assumed that the problems where known to the team (I didn't have
> time to follow the list in the last months), and therefore just
> wanted to ask whether the bad feelings about the GFDL are general
> enough to do something about that as a team.  Now I got the
> impression that you haven't discussed the license so far, and Ralf's
> mail seems to imply that there's interest in doing that.

The problem is, as I said, that there is no sense in discussing the
license on the list since it is not up to members of this list
(including myself) to set the GNU policies.

The lists to discuss this on are the GNU maintainer lists, the GFDL
feedback channels and possibly Richard Stallman and a few other single
persons.

But there is no point in disagreeing or agreeing about this matter
among the developers: there are not too many rules for maintaining a
GNU project, but the licensing is one.

Whoever is interested in the details, can take a look at
<URL:http://www.gnu.org/prep/maintain_toc.html>.  I don't think I can
in good conscience claim to maintain a GNU project when I don't
attempt to follow the guidelines.

If there was consensus on the list that I am not doing a good job as a
GNU project maintainer, or that AUCTeX should try to cease being a GNU
project, I would be willing to pass the buck of maintenance to anybody
with the majority of support of the list members, as long as he can
guarantee all the infrastructure and support AUCTeX needs to continue.

But this is a move that I would consider detrimental for the future of
AUCTeX, much more detrimental than putting its documentation under the
GFDL could ever be.

So I'd very much prefer if everybody who has strong feelings about
this vents them at the GFDL drafting process and similar channels,
mentioning his project affiliations and persuasions, and tried to get
the GFDL turned into something he can live with.

It may be more frustrating and tiresome, but it is the right way, and
it will benefit several projects instead of damaging a single one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum