Frank Küster <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> wrote: > >> Frank Küster <[EMAIL PROTECTED]> 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 _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
