Frank Küster <[EMAIL PROTECTED]> writes: > David Kastrup <[EMAIL PROTECTED]> wrote: > >> Frank Küster <[EMAIL PROTECTED]> writes: > >>> 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.
As I said: the FSF does not move fast, and they don't have the personnel for doing so. The GPLv3 process has taken a lot of focus and energy lately. > 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. You don't want to have something like "this clause was opposed just by three developers, so we decided the concerns did not justify further work". Without your input, you don't have a reason to complain. > 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. That is because the licensing is "under this or any later versions". Even if the license is not in its final state now, licensing under the current version does not preclude moving to a version _similar_ _in_ _spirit_ that expresses the intent better. So there is no reason to stall moving to the current version, as the way to perfection is not barred. And "forces" is a word I don't like. Nobody forces anybody to become a GNU project. Being a GNU project entails the active support of the FSF for the project, and the active support of the project for GNU. This cuts both ways. >> 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. You are qualified enough to ask on the developer list of a GNU project for a forking of the manual and try rallying support for it. You are qualified enough to call for a strike of the developers of a GNU project. You are qualified enough to flaunt the GNU policies and a maintainer following them and trying to dissuade people from working on GNU on a GNU project mailing list, using derogatory language. And now you are telling me you are not even qualified of putting your concern into words on the one channel where you can make a constructive difference? Because you are not qualified enough? Please. Anyway, I just got back the reply from Richard Stallman, and we can leave off the front and back cover texts and invariant sections (the license text itself will be excluded from being covered by the GFDL since it obviously is not subject to modification). That means that according to the decision of the Debian vote, AUCTeX documentation will be considered DFSG-compliant and will not need to be split even in Debian, without the Debian maintainer having to take responsibility for any compromises on Debian policies. For most of AUCTeX's developers, I hope this should be sufficient. > 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. The GNU maintainer guidelines are not a secret and can be seen at <URL:http://www.gnu.org/prep/maintain/>. I already pointed that out. The rules for licensing have not changed in the last few years according to what I am aware of: certainly the use of GFDL was already prescribed by the time AUCTeX applied as a GNU project. > 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. All development on AUCTeX happens on a voluntary basis. I have to accept _any_ decision not to contribute to any part of AUCTeX, for whatever reason. And I certainly am not glad to see you go, and in that manner. But I should still not wish you success demotivating other AUCTeX developers from working on our project, for the sake of pushing your personal agenda not even supported by the Debian voting outcome. No part of AUCTeX will end up in Debian non-free without Davide having to bend Debian rules even slightly. This is a better situation than that of Emacs itself, and I am grateful to be able to save users and developers the respective hassles. While I have to accept that it is impossible to please everybody, I hope that the dissatisfaction will stay contained in that manner. Incidentally: the main idea of checking in the GFDL license even before the exact conditions were cleared up was to get feedback about the _layout_ of the changes, not its contents. So if people see any problems with the layout or organisation, it would be nice to hear back. While I'll change the texts presently, the layout should not be much affected by the minor adjustments. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
