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

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2006-10-01) writes:
>
>> 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.
>
> The phrasing on this page regarding the license would leave room to
> decide against the guideline if there are strong reasons for it.

"Manuals should use the GNU Free Documentation License."

A strong (actually compelling) reason was that the copyright of
Kresten had not yet been assigned.  I can't as the maintainer of a GNU
project change the licensing of something not copyrighted by the FSF.

Another reason would have been that it would have been smarter to wait
until all previous copyright holders to AUCTeX's code have been
contacted before changing the license.  I would have considered this
dishonest, even though it might have made things easier.

One of the express goals of making AUCTeX a GNU project was to be able
to fold it into Emacs at one time.  It is illusionary to think that
its manuals will then be licensed differently.

As the GNU project maintainer, it is my responsibility to cater for
the maintenance policies.  I was contacted because of it, and I did
not see that there was a reasonable excuse for me not to follow the
guidelines.  Mainly because of the current Debian policies, I asked
whether we could omit the front and back cover texts (and invariant
sections), since it did not seem that they were worth the cost for us.
That was OKed, and it _is_ an exception from the guidelines.

"strong reasons" for not following the guidelines for a GNU project
have to be reasons that Richard is going to accept as valid.  I put
forward the reasons for not using front and back cover texts, and they
were accepted.  I saw no leeway for a vote about whether and how I
should, in my position of the GNU project maintainer, follow the
guidelines or not.

<URL:http://www.gnu.org/prep/maintain/html_node/Recruiting-Developers.html#Recruiting-Developers>
states:

    Some of the people who offer to help will support the GNU Project,
    while others may be interested for other reasons. Some will
    support the goals of the Free Software Movement, but some may
    not. They are all welcome to help with the work—we don't ask
    people's views or motivations before they contribute to GNU
    packages.

    As a consequence, you cannot expect all contributors to support
    the GNU Project, or to have a concern for its policies and
    standards. So part of your job as maintainer is to exercise your
    authority on these points when they arise. No matter how much of
    the work other people do, you are in charge of what goes in the
    release. When a crucial point arises, you should calmly state your
    decision and stick to it.

    Sometimes a package has several co-maintainers who share the role
    of maintainer. Unlike developers who help, co-maintainers have
    actually been appointed jointly as the maintainers of the package,
    and they carry out the maintainer's functions together. If you
    would like to propose some of your developers as co-maintainers,
    please contact address@hidden

I am perfectly willing to share the duties of a project maintainer, or
pass them to somebody else altogether.

In particular as I still completely fail to see how I could have
handled the situation better than I did.  If others see this
differently, it might well mean that it would be a good idea to have
somebody else participating in that sort of decision.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum