Ralf Angeli <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
