Re: OpenLDAP Licenseing issues
Hi Howard, On Fri, May 23, 2003 at 07:26:06PM -0700, Howard Chu wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stephen Frost Of those 15 licenses there are a few questions when it comes to GPL interaction. In the UoC license (Regents of the University of California Berkley) there is the infamous 'advertising clause'. The Regents have however, from my understanding, retroactively removed that clause from all of their licenses, at the request of the FSF. In the HC (Howard Chu) and PM (Pierangelo Masarati) there is 'should' do this and a 'should' do that. If those are to be interpreted as 'must' then they conflict with the GPL. 'should', however, can also be interpreted as a request, in which case there isn't a conflict. For the licenses that I have explicitly used, clauses (2) and (3) both include a must before the should. The main point is that the origin of the software MUST NOT be misrepresented, either by explicit claim or by omission. If you can address the omission responsibility without providing credit in your documentation, you're welcome to do so, though I find it hard to imagine how this might be possible without having annoying credits listed at runtime on every execution... As I understand it, the must requirement of your license is entirely GPL-compatible, as the GPL also stipulates that one may not misrepresent the origin of the work. The problem arises if we understand your license to require a specific interpretation of misrepresentation by omission. If your should can be understood as a recommendation rather than a binding requirement, and you are willing to leave the final determination of misrepresentation by omission to the courts, I see no reason why this license couldn't be regarded as GPL-compatible. Please note that Debian is more than happy to respect your wishes regarding acknowledgement so long as we're distributing your code; the issue only comes up because the GPL imposes contradictory requirements that could prevent us from shipping LDAP-enabled binaries of many GPL applications. Regards, -- Steve Langasek postmodern programmer pgp4cWrqZxLcC.pgp Description: PGP signature
RE: OpenLDAP Licenseing issues
-Original Message- From: Steve Langasek [mailto:[EMAIL PROTECTED] Hi Howard, Hello there As I understand it, the must requirement of your license is entirely GPL-compatible, as the GPL also stipulates that one may not misrepresent the origin of the work. The problem arises if we understand your license to require a specific interpretation of misrepresentation by omission. If your should can be understood as a recommendation rather than a binding requirement, and you are willing to leave the final determination of misrepresentation by omission to the courts, I see no reason why this license couldn't be regarded as GPL-compatible. Since I'm not a lawyer I seem to be missing where the conflict arises. Having just read thru the text of the GPL at http://www.gnu.org/licenses/gpl.html I see nothing in that license that conflicts with these terms. The GPL's distribution terms require you to distribute source code or make source code available when you distribute a Program. It's primary concern is ensuring free access to source code. There is nothing in my license statement that restricts anyone's ability to distribute source code. Nor is there anything in the GPL that talks about the documentation that accompanies a Program; as such I see these issues as completely orthogonal. Please note that Debian is more than happy to respect your wishes regarding acknowledgement so long as we're distributing your code; the issue only comes up because the GPL imposes contradictory requirements that could prevent us from shipping LDAP-enabled binaries of many GPL applications. I thank you for your conscientious attention to these matters, but I believe in this case there is no reason for concern. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: Removal of non-free
Joey Hess [EMAIL PROTECTED] wrote: Yes, there are many cases of this apparently happening. Such as? And was uploading to non-free a temporary measure to prepare a package while the copyright holder deliberated? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Changeset algebra is really difficult.
Re: Removal of non-free
Bernhard R. Link [EMAIL PROTECTED] wrote: [...] Free software sadly needs some time to fit in al the niches, as much too few institutions have adopted it, and good code just needs time. Maybe, but giving a supported distribution system for it removes some of the desire, doesn't it? [...] Do you really think even the thread of removing would be realistic? ) [...] Yes. And the point about things in main before is really important. With enough exceptions made for things that had nicer licences earlier or which badness was not prior found, it'd get much harder to avoid non-free things slipping in in main directly. I do not advocate making exceptions for main, so please do not raise that. If non-free things are uploaded to main, surely that's a bug? is fairly minimal (set up a BTS, apt repository - what else?). webpages, autobuilders, account managment, keyrings, Web? When did an apt source have a web page? Autobuilders? Are pbuilder et al so hard? Account management? wtf? Keyrings? Can't we use the same one. I'm quite sure that situation for non-free stuff will get better, if non-free is thrown out of debian I don't see why. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Changeset algebra is really difficult.
Re: Removal of non-free
Joel Baker [EMAIL PROTECTED] wrote: [...] *this* is something that belongs in non-free as a useful service. People could provide an RFC apt source as a useful service. [...policy vs users?...] Isn't that more or less exactly what some folks have been accusing the FSF of recently? I don't think so. Things shouldn't stay in non-free, no. [...] Would you support a maximum length of stay proposal for non-free? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://[EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: Changeset algebra is really difficult.
Re: Removal of non-free
* MJ Ray [EMAIL PROTECTED] [030524 13:08]: Maybe, but giving a supported distribution system for it removes some of the desire, doesn't it? I think a distribution system with an emphasis on free software, also helping with non-free bits one can not get rid from is something useful to many people. Wihtout non-free parts, people needing them will have two possibilities: They might use another system, which might force them to even use non-free parts for installation or configuration. (They might not like it, but not everyone can value long term goods as freedom over short term things like manpower needed). Or they might use some non-free parts from another source. As this source has no more emphasis on free software, it is less likely to drop things when a replacement arises and the non-free parts might recommend other non-free parts more than the free parts. (additonally such a source would need resources, our project would no longer have). [...] Do you really think even the thread of removing would be realistic? ) [...] Yes. I think this is one of the most important difference. I just can not even imagine how much I had to narrow my mind to believe this. I daily struggel to get free software anywhere near me. If I just cannot close my eyes and pretend nothing non-free exists or is needed. If I did, this might even cause non-free operating systems to return to places I banished them from. If non-free things are uploaded to main, surely that's a bug? It is. And anyone will see it this way, as long as there is non-free. is fairly minimal (set up a BTS, apt repository - what else?). webpages, autobuilders, account managment, keyrings, Web? When did an apt source have a web page? Now, consider there was a nondebian.org. Wouldn't it need webpages to describe what it is, how to participate, what guidelines to follow. Websites searching the package description and looking at package dependencies? Autobuilders? Are pbuilder et al so hard? There are no autobuilders for non-free stuff within Debian. Do you really want autobuilders for non-free created somewhere else? Account management? wtf? Keyrings? Can't we use the same one. As long as non-free is handled by Debian infrastructure, nothing has to be done for this. I hope the developer database will not be exported anywhere. (If it was, I and hopefully man others would insist in Debian having control over the place it is exported to. But then it would be just time-consuming change of nomenclature. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
GPL vs. LGPL
I'm an upstream developer for swish-e. I'm trying to get some help in understanding GPL vs. LGPL, and in plain language. Swish-e is currently under GPL. I've been asking around and there seems to be debate about if using swish-e (a GPL program) in a proprietary product would force the proprietary code into GPL, or if not force into GPL, at least force their code into Open Source. I think it's hard to define when something is a a work based on the Program vs. mere aggregation, which seems like an important, yet hard to define point. Here's where I'm coming from: Swish-e is a search engine. A common use would be for someone to use swish-e to index and search their documentation. Most people write a CGI front-end script to use with Swish-e, or use the provided example Perl CGI script that's included in the Swish-e package. Therefore, in such a use I do not see it as a separate entity so that use would be fine for me even if the main program was proprietary. In a nutshell, I don't mind anyone using swish-e as long as they: a) say they are using it (and where they got it) and include the license b) don't claim it as their own work c) make any bug fixes and feature additions available back to the swish-e project an users LGPL bugs me for a number of reasons. Perhaps that's my lack of understanding of it, though. First, even though it's the lesser GPL, it still talks a lot about libraries. The swish-e source code builds a library and a binary. The binary is basically a wrapper around the library. So I see NO difference in someone using the libswish-e library vs. using the swish-e binary program. So all the discussion of libraries in LGPL is just confusing in this case. Second, (although very unlikely for swish-e) I wouldn't want someone to take swish-e (or the swish-e library) and add a thin wrapper and then make feature improvements and end up with a proprietary product such that current users of Swish-e have only the proprietary version as an upgrade choice. In other words, I don't want a situation where users would be forced to use the proprietary version if they wanted to continue using swish-e. So, I'm leaning toward keeping it GPL, with the understanding that use of swish-e is typically used as an aggregation and therefore doesn't force other bundled code into GPL. But it prevents someone from taking swish-e, rename it and see it as their own creation. Is that a reasonable use of GPL? My guess that's more liberal than RMS has in mind, but more restrictive than LGPL. Or am I way off? Finally, would any of this effect the inclusion of swish-e in Debian? Thanks very much, -- Bill Moseley [EMAIL PROTECTED]
Re: The debate on Invariant sections (long)
John Holroyd [EMAIL PROTECTED] said: FWIW I think RMS is right to insist that others cannot modify his political comments, but I think you are right to say that unmodifiable comments and texts (UTs) have no place being mandatorily included in the functional world of Free Software. Personally, I found a lot of the GNU philosophical texts included in emacs to be very interesting and educational, they led me to the GNU and Debian projects, it would be a shame to remove them simply to prove a point when they are fundamental in helping new users to understand the basis of the Free Software movement. Would a possible answer be that distribution of the UTs is not mandatory, so purely functional versions of the package can be distributed, but if the UTs are distributed then they remain unmodifiable? It looks like a sensible compromise to me. A fair number of people (like me) think that this would be a reasonable answer and a sensible compromise. (Although, to be fair, a fair number of others think that philosophical texts demand modifiability to be free.) Unfortunately, RMS has said NO by means of the GNU FDL. So-called invariant sections simply cannot be removed, which is what got our attention in the first place. This is the point on which Debian has consensus and cannot compromise. Unremovable material tied to functional manuals is pernicious. RMS said: These sections are consistent with freedom because practically speaking they don't stop people from making the software do what they want it to do, or the making the manual the manual teach what they want it to teach. Many examples have been given for why this is *false*, and they're pretty much all tied to the *non-removability* rather than the non-modifiability. Should we repeat them again? --Nathanael
Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used byGPL-incompatible apps
On Tue, 2003-05-20 at 05:15, Branden Robinson wrote: I am uncomfortable with some of the ramifications but I am also uncomfortable with totally declawing the GNU GPL by adopting and interpretation of it that would let people wrapper and language-bind their way out of the copyleft commons. Anthony DeRobertis then said: At some point, we've got to draw a line where it's de-clawed. After all, I think we all agree that if a shell script calls GNU grep[0], it isn't required to be under the GPL. This is the way I usually see it. :-) Beware that this is not the FSF's position, or anyone else's as far as I know. The rest of this message is simply *my* position. Programming to a public, totally open interface puts no license requirements on the programmer. By this, I mean an interface which is fully documented so that many programs could implement it, and so that there are no legal impediments to implementing it. This is because the subsequent use of the program (via execve, shell script, or dynamic linking) constitutes normal, expected use of the program, rather than creation of a derived work. This does not affect legal issue beyond programming to the interface. If, for example, including header files is required to program to the interface, the header files must be public domain or X11/BSD-style licensed (since they're included in the program code when compiled) to allow inclusion in proprietary software. Writing scripts for a publicly documented, freely implementable language like Bourne shell script is fine, and imposes no requirements. (Bash is for running shell scripts, so running one with bash is normal everyday use.) Writing a script specifically for undocumented features of bash would impose bash's GPL requirements, at least on the distribution of the combination of the script and bash. (It can't be considered a mere aggregation or collection because the script absolutely *depends* on bash, so the combination is a derived work.) Calling POSIX grep is therefore fine. Calling GNU grep with GNU-grep-specific options (supposing there were any; I suspect there aren't) is fine only if the options are publicly documented so that they could be implemented in other versions of 'grep'. Preferably documented by the creator of the new program. So for instance, if someone creates a program which uses a special GNU grep option, and says This program requires GNU grep to work, the program should go under the GPL. If instead they say This program requires a version of grep supporting the -xxx option, meaning precisely blah blah blah. For example, GNU grep, then the program can be under any license. (If there are grep-specific options, they may not be freely implementable. If the only descriptions of them are under GPL or more restrictive copyrights, they probably aren't, until someone reverse-engineers them using a Chinese Wall process.) No doubt this isn't the interpretation of most people who look at this, but I believe it is the closest to the concept intended by the GPL. Using a published interface is ordinary and expected use of the original program, which is unrestricted. Using a secret interface is effectively making use of the original program's source code to make a derived work, since the new program is intrinsicly tied up with the original program and useless without it. So in regards to declawing, this makes a *non-arbitrary* distinction, unlike the distinction between dynamic linking and execve() calls. Certain execve() calls create a combined, derived work. Certain dynamic links don't. It's a matter of whether the linkage is integral to the program, or not. Admittedly the distinction must be applied carefully on a case-by-case basis, but that's often what makes good law. So there's my two cents; make of it what you will. --Nathanael
Re: The debate on Invariant sections (long)
Barak Pearlmutter said: lots of important and correct stuff snipped Simply make the GFDL be GPL compatible, the same way the LGPL was. Add a clause saying that the covered materials can be construed as source code and used under the GPL; and that the invariant sections should, under such circumstances, be regarded as materials simply accompanying the GPLed technical materials but not themselves covered by the GPL, like the essays that accompany the GNU Emacs source code. At the risk of saying Me too, Me too. This solution would deal with the primary, most troublesome problem with the GFDL. (As another example of how it would deal with the problems brought up: the proposed GNU Emacs reference card wouldn't have to include monster invariant sections on the back of the card; it would simply be licensed under the GPL, and distributed only along with a copy of the GPL. The only added text on the card would be the copyright notice and the usual This reference card is free. You can use it under the terms of the GNU General Public license...)
Re: GDB manual
I investigated the situation with the GDB manual. It has two invariant sections, entitled Free Software and Free Software Needs Free Documentation. Both sections are secondary. That doesn't make the issue go away. It addresses the issue that was raised here before. Someone said that the GDB manual had marked a section invariant which was not secondary. An invariant section is invariant, and it is not free (even according to your own definition), With all due respect, this is not for you to say. You are entitled to your opinion, and Debian is entitled to choose its own standards, but you do not interpret the GNU Project's standards any more than I interpret Debian's standards.
Re: The debate on Invariant sections (long)
When people think that invariant sections cause a practical problem, they tend to be overlooking something--either the scenario is unrealistic anyway, or the problem can be solved. When we make decisions in the GNU Project about what counts as free software, or free documentation, they are based looking at freedom as a practical question, not as an abstract mathematical one. As a practical consequence, I can't make a reference card from the Emacs manual, The invariant sections make no practical difference to this scenario, because the license itself is 6 pages, which already would not fit on a reference card. But that the issue is a moot point, because a reference card would use so little of the text of the manual that it would be fair use. In fact, the very idea that a reference card is derived from the manual in copyright terms seems like an unrealistic idea. nor can I extract bits for online help in Emacs itself. If they were small bits, that too would be fair use. You can use the manual in its entirety, and have Emacs display parts of the manual. That is the best approach technically if you are using a substantial part. Either way, there is no problem. The idea of merging the documentation into the software is in general a purely academic issue--a hoop that there is no reason to jump through. It is always better to keep the manual separate and have the program display it, as in fact Emacs already does in sophisticated ways. More fundamentally, the argument that I can't merge A with B so A is non-free is generally invalid. That criterion is simply wrong, because there are many cases when you can't merge a free program A with a free program B. For instance, you can't merge Emacs with TeX, or TeX with Emacs, because their licenses are incompatible. This is despite the fact that they are both free licenses. Incompatibility of licenses is a significant practical inconvenience, and we have sometimes made changes for the sake of compatibility, but mere inconvenience doesn't make a license non-free.
Re: The debate on Invariant sections (long)
But in more practical terms even, political speech is very functional -- it's meant to persuade and educate. By the same token it can have bugs (typos or poor phraseology), malware (screeds advocating racism, or encouraging people to kill themselves), and can be improved and/or adapted to new purposes. The difference, if there is one, is that it is executed by our minds rather than our computers. Programmers often approach issues by looking for the similarities between a large number of cases, and trying to generalize as far as possible. That is a useful approach for thinking about software, but when applied to ethical questions, it is very likely to miss the point. The differences are often more important than the similarities. Analogies are often irrelevant. A political essay is (typically) written by certain persons to persuade the public of a certain position. If it is modified, it does not do its job. So it makes sense, socially, to say that these cannot be modified. We could imagine an analogous situation for a program: certain persons writing a program to do a job on other people's computers in one particular way and only that way. They could say that if it can be modified, it does not do the job. These situations are analogous, but the ethics of the two situations are different. The essay does not really do a job for the reader. You read it, you think, and then you formulate your own views. If you want to think differently from the authors, you can just do it--a modified essay isn't necessary. No version of that essay is necessary. The situation with the program is different. It runs on your computer, rather than communicating to your mind. If you want your computer to do a somewhat different job, you need to change the program (or else write a new one from zero). I have spent many years fighting for freedom, and I continue to stand up for my views. I have stated the above views in speeches many times, though here I have gone further into the reasoning behind them. My views are not the most extreme possible (though my detractors often call them extreme), and it appears you have views that are more radical than mine. I have always tried to be a pragmatic idealist.
Re: The debate on Invariant sections (long)
Richard Stallman [EMAIL PROTECTED] wrote: When people think that invariant sections cause a practical problem, they tend to be overlooking something--either the scenario is unrealistic anyway, or the problem can be solved. When we make decisions in the GNU Project about what counts as free software, or free documentation, they are based looking at freedom as a practical question, not as an abstract mathematical one. As a practical consequence, I can't make a reference card from the Emacs manual, The invariant sections make no practical difference to this scenario, because the license itself is 6 pages, which already would not fit on a reference card. The GFDL is broken in so many ways. That is just one more way. The GPL (and all of the other free licenses that I can think of) allows you to _accompany_ the license with the covered material. The GFDL requires the license to be _included_ in the material. I (and others, I think) raised this point during the comment period for GFDL 1.2, but the license was not fixed. But that the issue is a moot point, because a reference card would use so little of the text of the manual that it would be fair use. In fact, the very idea that a reference card is derived from the manual in copyright terms seems like an unrealistic idea. You obviously haven't looked at reference cards recently. They can be quite dense, with lots of little type, far more than is allowed by fair use. nor can I extract bits for online help in Emacs itself. If they were small bits, that too would be fair use. You can use the manual in its entirety, and have Emacs display parts of the manual. That is the best approach technically if you are using a substantial part. Either way, there is no problem. The idea of merging the documentation into the software is in general a purely academic issue--a hoop that there is no reason to jump through. It is always better to keep the manual separate and have the program display it, as in fact Emacs already does in sophisticated ways. I work on a piece of GPL'd software that has significant amounts of hard-coded online documentation [1]. It also has a GFDL'd manual inherited from the original implementor. I can't improve the manual by including the online documentation, and I can't improve the online documentation by using the manual. Are you saying that I just have to rewrite the manual or online documentation? I thought I was working on free software, where I don't have to jump through these kinds of hoops? This is a real problem for me personally, and I really wish that you would stop encouraging people to use non-free licenses on documentation. I don't understand why you've been so good about ensuring freedom for software and so terrible about ensuring freedom for documentation. It it hadn't been the _GNU_ FDL, this obviously unfree license would have been ignored. Regards, Walter Landry [EMAIL PROTECTED] [1] http://arx.fifthvision.net
Re: The debate on Invariant sections (long)
Hi Richard Stallman, The idea of merging the documentation into the software is in general a purely academic issue--a hoop that there is no reason to jump through. It is always better to keep the manual separate and have the program display it, as in fact Emacs already does in sophisticated ways. Would you mind stating for the record that the creation of context-sensitive help and other sophisticated ways of presenting GNU GFDL documentation does not lead to issues with GPL compatibility because it creates no situation of a derived work through dynamic linking with software. A lot of us would be very happy to learn that we can present GNU GFDL documentation in sophisticated ways without any concerns about software licence compatibility with the GFDL. [And this also goes the other way. Please also state for the record that one may annotate vast screeds of GNU GPL code in GNU GFDL documentation and the mere fact the licences are incompatible is no more than a purely academic issue because it is always better to keep a manual separate from code.] Frankly this claim that it is always better to keep the manual separate--as if it is always better to keep data separate from code--is a shocking and nonsensical claim from someone with such a distinguished Lisp background as yourself. I suppose for your next trick you'll claim ignorance of what Knuth achieved with literate programming. Don't think you can treat us all like fools by glossing over sound methodologies of documentation and software engineering in order to push the mandatory inclusion of your political texts. Regards, Adam Warner
Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, May 23, 2003, at 01:45 PM, Stephen Ryan wrote: On Fri, 2003-05-23 at 09:52, Brian T. Sniffen wrote: The other option, of course, is that the kernel exec() function *is* a barrier, Debian *can* be used for real work and not just an exercise in ivory-tower masturbation. Whoa! Those are not my words. I'm not quite sure whose they are. Well, I don't believe exec is a magic copyright barrier; instead, I think we need to generalize _why_ we generally consider it be one. But this leads me to believe that we may well be on common ground; what generalization do you see there? -Brian
Re: The debate on Invariant sections (long)
Richard Stallman [EMAIL PROTECTED] writes: A political essay is (typically) written by certain persons to persuade the public of a certain position. If it is modified, it does not do its job. So it makes sense, socially, to say that these cannot be modified. This may be true of some political speech; I'm not sure enough in my own mind to give a definitive answer one way or the other. (For example, how much of this is due to conflating the role of the text for the author with the role of the text for the reader? The job of the text for society and the job of the text for the author are not necessarily the same.) But changing political speech is only part of the issue. That political speech is also, in the form of invariant sections, being irrevocably attached to technical, more obviously functional speech. Thus we're also concerned with the ability to modify the documentation itself. One example that was raised in discussions here that you may not have heard, is that of taking documentation for one purpose and combining it into a greater work with a new purpose, such that the invariant texts are no longer secondary. The essay does not really do a job for the reader. You read it, you think, and then you formulate your own views. If you want to think differently from the authors, you can just do it--a modified essay isn't necessary. On an individual level, what you say may be true. But there is still a benefit for society if the work can be modified and redistributed. I have spent many years fighting for freedom, and I continue to stand up for my views. I have stated the above views in speeches many times, though here I have gone further into the reasoning behind them. My views are not the most extreme possible (though my detractors often call them extreme), and it appears you have views that are more radical than mine. I have always tried to be a pragmatic idealist. Certainly, and I didn't mean to give the impression that I doubt that you continue to stand up for your views. But nonetheless I think that invariant sections are a compromise with freedom, and that when more people than just the FSF are adding invariant sections to documents the interests of Free Software will be damaged. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: The debate on Invariant sections (long)
J?r?me Marant said: En r?ponse ? Branden Robinson [EMAIL PROTECTED]: On Fri, May 16, 2003 at 09:37:31AM +0200, J?r?me Marant wrote: What is the best way to convince GNU people to change their licenses? (without being pissed of, that is). I'm not sure GNU people need to be convinced. The only person I know of who has come out in vigorous defense of the GNU FDL is Richard Stallman. (Georg Greve does also agree) It seems to be. But if so, why do they seem not to try to convince him? Well. There are several categories of GNU People. If you mean contributors to FSF-copyrighted projects, then these are the views I've seen: 1. The FDL is repugnantly non-free. We tried to convince RMS, who runs the FSF as his personal fiefdom, and he wouldn't listen. What can we do now? (There are a fair number of us in this category.) 2. I don't care about documentation licensing. 3. I don't care about documentation at all. 4. I don't care about freedom of software or documentation, as long as I can use it. (This is a surprising collection of people, who simply use GCC or Autoconf, for example, and want to help out, but would probably do the same for Microsoft Windows if they could. Linus Torvalds would belong in this category...) 5. If RMS says it, it must be right. (Mostly the uninformed. A few others.) 6. Having a legal guarantee that RMS's screeds are attached to the corresponding manuals is more important than the downside. A little tiny bit more important. (This doesn't seem to be many people, and they don't seem to feel too strongly about it.) 7. Invariant sections aren't free, but RMS is so insistent that we shouldn't bother to complain, because it isn't that important. 8. No comment. (I have no idea what these people think.) -- If you mean FSF employees, there aren't very many and they generally defer to RMS, as far as I can tell. If you mean people who operate GNU projects *not* under FSF copyright, I don't know any of their opinions. Sorry. :-) --Nathanael
