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

[Frank Küster]

David Kastrup <address@hidden> wrote:

> Frank Küster <address@hidden> writes:
>
>> David Kastrup <address@hidden> wrote:
>>
>>> 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?

This is right.  I was very superficially when I said about using the
"last GPL'ed" manual.  But in fact I just remembered that previously I
checked and found that it has a suitable license.  Which it indeed still
has in the released version, there's nothing in it that requires passing
on source code with printed versions (this is suboptimal, since it's an
incomplete copyleft, but at least it is consistent).

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

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

Which is a good reason not to put any document under the current, "old"
version of the GFDL.  Well, it doesn't matter much for a GNU project,
though, since the FSF has the copyright and can relicense at will.

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

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

> 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.  All these problems have been public for years.
Given the public fuss Debian made about it, I'm kind of surprised that
this isn't more general knowledge.  To me, it seems as familiar as the
difference between copyleft and non-copyleft Free Software licenses.

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

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. 

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

At that time, it was still possible to choose freely a license for
documentation.  The switch to forcing new projects to use the GFDL (and
actually forbid dual licensing) has happened much later, and I wasn't
even aware of a policy of forcing projects to switch existing documents
to the GFDL until Davide told me.

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

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.

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

This I did not want to imply at all.  I was thinking of a fork as a kind
of "going on strike".  I see this is not going to happen, so let's stop
this. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)