Re: GFDL/GPL incompatibility
Michael K. Edwards wrote: As I see it, the individuals who assigned their copyright in GNU documentation to the FSF probably didn't expect to see the relicensing of their work under a GPL-incompatible license, creating yet another gated community carved out of the ostensible commons. You're quite right. I know Zack Weinberg -- author of a large portion of the GNU cpp manual -- didn't, and dislikes the policy, to mention someone who was willing to make his views public. I personally stopped submitting copyrightable amounts of documentation to GNU when I figured out what was going on. This, of course, indicates a problem at the heart of the FSF: Stallman has been able to unilaterally impose a bad licensing policy, which the vast majority of GNU developers think is a bad idea. He hasn't even been able to point to two other people who agree with him about the GFDL (Georg Greve *might* count as one person, *maybe*, though his views seem rather different), yet it remains official FSF dogma. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GFDL and incompatibility
Richard Stallman [EMAIL PROTECTED] writes: I have never considered the question of whether the GFDL is a free software license. The question seems purely academic, since it is (1) not meant as a license for programs, and (2) clearly an annoying license to use for programs. So I don't know if I would agree this is true. You claim that it really doesn't matter, and yet, you have not payed much attention to the examples of cases where the boundary between documentation and software is blurry in the extreme. An excellent example is TeX or other such literate programming experiments. Is that software or documentation? What I can say is that the question has no practical significance. If I have a manual for FOO, I might want to merge it with FOO. Whether that is possible does have practical significance. As I've explained, this cannot be a criterion for whether the manual's license is free, since merging may be forbidden due to incompatibility even with licenses that Debian agrees are free; also, there are other ways to get the job done when merging is impossible. But at least the question is a real question. My point is that a manual for FOO, if that manual is DFSG-free, can be merged with at least some free software somewhere. If it's a GFDL-d manual, by contrast, it cannot be merged with any free software anywhere. And we have real-life examples where merging manual text into programs is useful, so this isn't a fake question. Thomas
GFDL and incompatibility
My point is precisely that a GFDL manual *cannot* be incorporated into *ANY* free software project. And this is *different* from the old documentation license, which did not have that problem. I have never considered the question of whether the GFDL is a free software license. The question seems purely academic, since it is (1) not meant as a license for programs, and (2) clearly an annoying license to use for programs. So I don't know if I would agree this is true. What I can say is that the question has no practical significance. If I have a manual for FOO, I might want to merge it with FOO. Whether that is possible does have practical significance. As I've explained, this cannot be a criterion for whether the manual's license is free, since merging may be forbidden due to incompatibility even with licenses that Debian agrees are free; also, there are other ways to get the job done when merging is impossible. But at least the question is a real question. But if we cannot merge it with FOO, why in the world would we care whether theoretically we could merge it with some other hypothetical program BAR? That question is in meaningful in a theoretical sense, but I don't see a need to ask it. However, the point is that the simple license, was always compatible with at least one free software license. For example, one could easily distribute software under the simple license itself. I don't think anyone ever did so. In practice, the issue is not significant, since you can distribute the manual along with the software, and make the software access the manual in whichever way you want. Is that how Emacs gets its doc strings? The text in the manual is usually not suitable for a doc string, and vice versa. I don't copy text from the Emacs manual into a doc string, even though the FSF as copyright holder for both could do so.
Re: GFDL and incompatibility
Richard Stallman [EMAIL PROTECTED] writes: The text in the manual is usually not suitable for a doc string, and vice versa. I don't copy text from the Emacs manual into a doc string, even though the FSF as copyright holder for both could do so. The problem is that you can't even re-edit it into a doc string. Anything that's a derivative work is out-of-bounds. The GFDL forces a particular implementation of program-with-documentation, and that's already a bug.
