Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Wed, 16 Apr 2003 09:27:43 -0400 || Peter S Galbraith [EMAIL PROTECTED] wrote: psg No if it were released under the GPL. Compare to: psg I'm sorry, but if somebody wrote something into SOFTWARE that psg was important to him and you didn't like it and removed it to psg distribute that as a newer version of the SOFTWARE, you'd be psg violating that persons Copyright. psg Care to defend that again? Software and documentation are quite different according to the way they are treated by the legal system. Moral rights (on which this is based) are seen much more strongly for documentation. The scenario in question is normal daily business for documents, but so far nobody has tried it for software. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgphMdyB92ENQ.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Wed, 16 Apr 2003 09:06:51 -0400 || Peter S Galbraith [EMAIL PROTECTED] wrote: The GFDL deeks to do the same thing. Only this time you find yourself in the position of middleman and have to take care to not violate the rights of either party. psg Quite the opposite actually. Any redistributor can add psg invariant sections which makes sharing difficult. Yes. But that is a question of Copyright law, not license. Given that a document is under a license that permits modification, any redistributor could add anything and then say that removing it would hurt his or her moral rights. Any license trying to allow modification/removal of such sections would run a higher risk of being ruled invalid as a whole because these are inalienable rights. So by having no possibility for invariant sections in a documentation license, all you do is increase the possibility that it will one day be ruled to be invalid as a whole. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgpU5NGm6eH3p.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Thu, 17 Apr 2003 12:28:36 -0700 (PDT) || Mark Rafn [EMAIL PROTECTED] wrote: Are you referring to documentation under the GFDL? Why would that have to be removed? mr Not all GFDL documentation, only that which contains invariant mr sections which cannot be removed or modified. I see. I was just trying to understand the reasons as someone at some point indicated it was possibly illegal to ship GPL and GFDL licensed things together. If you say that you are planning to remove it because Debian thinks it is non-free, that is something else. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgpQIiUtrdKYY.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Thu, 17 Apr 2003 15:05:48 -0400 || [EMAIL PROTECTED] (Brian T. Sniffen) wrote: bts A reference card has a subset of commands, chosen for bts usefulness, elegance, or aesthetic appeal. It has succinct bts descriptions, which are a creative effort. It is definitely bts copyrightable on either of those points. Although you phrase it that way, you are in fact not contradicting any of what I wrote. One can certainly argue that the choice of subset as well as the way they are presented are Copyrightable. But then only those parts would be Copyrightable, not the references themselves. bts I'm not at all sure what to say to this. Are you talking about bts Berne Convention copyright law? Also, but not only. Berne is very loose and leaves a lot of room for the national initiatives. Also there is Stockholm. Then there are the national laws that need to be taken into account. Naturally, I'm more familiar with the European Copyright -- or Droit d'Auteur, rather -- systems, but since Europe is a very active region for Free Software, considering the European situation seems useful. bts Are you really asserting that the comments and strings in a bts source file labelled as being under the GPL might not be under bts the GPL? I wrote no such thing. It might be interesting to find the grey areas for that, but normally one would probably see the comments and strings as parts of the program rather than an independent document. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgpNL8viUW1Na.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Wed, 16 Apr 2003 11:34:17 +0100 || Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: Although I have said it before, I'll say it again: I don't consider the GFDL to be perfect, but from the free documentation licenses I have seen so far, it seems to be the most solid one for the reasons I've described. ege What do you mean by a free documentation licence? A documentation license that will provide a good balance between the freedoms of the individual and the freedoms and needs of society in a way that it will maximize freedom for society while keeping that freedom legally defendable. ege Personally, I will stick to using the GPL, even for non-software. That is putting freedom at risk, however -- possibly even more than with a free documentation license that does not permit invariant sections -- as the license was clearly written for software, not documentation. So although you probably won't run into immediate problems with it, it does make the legal situation somewhat fuzzy for such documentation. Of course technical manuals require change. So it may be possible that authors use invariant sections in an unwise way, covering parts that need to be changed to keep the manual useful. In that case such manuals should maybe be put into contrib. ege So you agree that some documents licensed under the GFDL are not ege free. I thought contrib was for things under free licenses that are somehow suffering from limitations. But I may be wrong. Sometimes authors consider more things invariant than would be technically useful. Nobody can take that right away from an author under Droit d'Auteur, which we have to take into account for global projects. But of course it limits the usefulness of the documentation for the Debian project and its users. So I guess my suggestion would be the following policy: 1) The GNU Free Documentation License (GFDL) is a free documentation license; recommended for use in Debian without invariant sections. 2a) Documents without invariant sections go into main. 2b) Documents with invariant sections are to be reviewed by the Debian Documentation Project whether the invariant section makes the document technically unmaintainable. [An example for non-maintainable technical parts would be if the documentation of a web browser has the description of the key bindings in an invariant section.] If the invariant sections still allow maintaining the document technically, it can go into main. If the invariant sections do not allow technical maintenance, it goes into contrib as it might still be somewhat useful. That said, I think I've done what I could to explain the situation to the best of my knowledge and provide a viable solution. So I would like to put this to rest for now and suggest to maybe reexamine the situation in half a year, or so. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgpCtCPmNdz4x.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Tue, Apr 15, 2003 at 11:30:17AM +0200, Georg C. F. Greve wrote: psg I don't want to ship the 5MB documentation with my 100KB GUI, psg just the few paragraphs that matter. That seems too genereralized to be useful. It seems hard to imagine a situation where an obviously very long and detailed piece of documentation -- 5MB is unusually large for plain text -- would not be useful as a whole. Or rather that including only a few paragraphs would be a useful activity. Do you have a concrete example? I find it hard to believe that you are serious here. If you really need a concrete example, fire up Emacs, hit C-h i, choose any large package from the menu, and tell me with a straight face that the introduction on its own could not be useful in another context (I picked bison). And if it is just a few paragraphs that need to be hard-coded into your application, why not write them yourself? Um, same could be asked of those few lines of code that you want to use from any piece of software. You really are seriously missing the point. If it is more than just a few paragraphs, is this a special situation where harddisk space is so limited that the whole documentation could not be reasonable placed somewhere in the system? This is just so far out it's almost funny. psg It's _very_ weird to have to convince a GNU representative of psg these issues. As the GNU Free Documentation License is the license that was written with a lot of thought going into balancing the rights of the author of a documentation and the rights of the users -- including, but not limited to, programmers -- I wouldn't find it surprising that GNU people will seek to explain the background. All that should be needed is that the author be assured by the license terms that readers will be given an accurate representation of the degree to which any and all contributors are responsible for the work that they are reading. If authors want more, I'd like to see a damn good reason why they deserve it, and so far none has been forthcoming. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Stay away from hurricanes for a while.
Re: motion to take action on the unhappy GNU FDL issue
On Wed, Apr 16, 2003 at 03:09:17PM -0500, Branden Robinson wrote: I propose that we: * draft a comprehensive critique of the GNU FDL 1.2, detailing section-by-section our problems with the license * draft a FAQ regarding why we differ with FSF orthodoxy on this issue * draft a document advising users of the GNU FDL how to add riders to their license terms such that works so licensed are DFSG-free, and pointing out alternative documentation licenses that are also DFSG-free Then: * exhaustively identify works in main and contrib using the GNU FDL[1] * contact[2] the package maintainers and upstream authors of each affected source package, and include pointers to the above documents * post a list of affected packages to debian-devel-announce and/or debian-announce, so that no one is surprised by whatever later actions occur * give people some time to consider and act upon the above contact (some may relicense, some will tell us to go pound sand, others won't reply at all) * remove packages from main and contrib whose licenses have not been brought into compliance with the DFSG I am seeking seconds for this proposal. [1] I don't restrict this to GNU FDL-licensed documents that have Cover Texts or Invariant Sections because previous discussions have indicated that there may be still other problems with the GNU FDL 1.2. I seem to recall someone raising a fairly persuasive critique of section 4K, for instance. Thus, if we're going to nail some theses to the church door, we might as well make sure that they're comprehensive. [2] possibly through a mass bug-filing, but I leave this detail to future determination I strongly support this proposal. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Stay away from hurricanes for a while.
Proposed statement wrt GNU FDL
(Hrm, asking for someone to handle this results in a motion for it to be handled, and lots of seconds that aren't willing to actually do anything. How helpful.) Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) 20th April, 2003 In November 2002, the version 1.2 of the GNU Free Documentation License (GNU FDL) was released by the Free Software Foundation after a long period of consultation. Unfortunately, some concerns raised by members of the Debian Project were not addressed, and as such the GNU FDL can apply to works that do not pass the Debian Free Software Guidelines (DFSG), and may thus only be included in the non-free component of the Debian archive, not the Debian distribution itself. This document attempts to explain the reasoning behind this conclusion, and offers some suggestions on how authors of free documentation may avoid these problems. The Problem ~~~ The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications, particularly: * K. For any section Entitled Acknowledgements or Dedications, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. * L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, which state: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. As such, we cannot accept works that include Invariant Sections and similar unmodifiable components into our distribution, which unfortunately includes a number of current manuals for GNU software. The Solution There are a number of things that can be done to avoid this problem. 1) Avoid using the various options the GNU FDL allows. If you do not make use of Invariant Sections, or include an Acknowledgements or Dedication section, there are no problems with your GNU FDL licensed document passing the DFSG. However, if someone modifies your document, and adds an Invariant Section, the new document will become tainted and can no longer be made to pass the DFSG. 2) Use an alternative copyleft license for your document. Alternative licenses that you should consider for your documentation include the GNU General Public License, or the Creative Commons ShareAlike or Attribution-ShareAlike licenses. 3) Use a non-copyleft free license for your document. Example licenses include the FreeBSD Documentation License, the Creative Commons ShareAlike license, and common software licenses such as the X11 license, or the updated BSD license. 4) Update the GNU FDL to allow the removal of unmodifiable sections. While this does not prevent documents covered by the GNU FDL being non-free, it allows you to extract the non-free components from the document, leaving just the juicy DFSG-free goodness. More Information http://www.gnu.org/licenses/fdl.html http://www.gnu.org/licenses/fdl-1.2-comments.txt http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00285.html http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00287.html http://www.wikipedia.org/pipermail/wikipedia-l/2002-June/002238.html http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html http://www.debian.org/social_contract.html http://creativecommons.org/licenses/ Open Questions ~~ We want to do a FAQ as well. Should the documentation = software thing be justified there? How about the practical examples we have? What other practical examples are there? Which packages are affected? What are we going to do about all the documentation with clearly non-free licenses, or that lack clear licenses? This seems to include things like the Debian Manifesto, that's part of doc-debian. Do we really want to recommend Creative Commons Licenses? They've very long and legalistic -- even the do what you want, but keep my name license is disgustingly complicated, to the point where it's not obviously DFSG-free. Are those all that makes the GFDL conflict with the DFSG? What else needs to be covered? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgp2h3Foa02cr.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Thu, Apr 17, 2003 at 03:05:48PM -0400, Brian T. Sniffen wrote: But the issue here is not copying or modifying an existing card, but deriving a reference card from the Emacs manual. If the documentation was licensed under the BSD license, wouldn't you still have to include the full license text on the card? If the GPL, a change list as well? If these are a problem as well, the argument against the GFDL here is less interesting; and if they're not, this GFDL argument probably isn't, either. There seem to be other, more convincing arguments against invariant sections. -- Glenn Maynard
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Sat, Apr 19, 2003 at 01:51:22PM +0200, Georg C. F. Greve wrote: Given that a document is under a license that permits modification, any redistributor could add anything and then say that removing it would hurt his or her moral rights. Any license trying to allow modification/removal of such sections would run a higher risk of being ruled invalid as a whole because these are inalienable rights. So by having no possibility for invariant sections in a documentation license, all you do is increase the possibility that it will one day be ruled to be invalid as a whole. If this is the reason for allowing invariant sections, it doesn't explain why GNU is actually using them in their own documentation. If this was the only reason--that it's ugly but needed--then the license should recommend against their use, and GNU should be setting an example by not using them at all. The fact that they are, in fact, being actively used indicates that they're driven by more than this legal requirement. There have been suggestions that GFDL-licensed text be considered free only if it doesn't actually contain any invariant sections. This would seem to accomodate the reason you're giving (the possibility is still there, even though Debian has no obligation to ditfibute the result)--but as GNU is actively *using* them, it would still result in GNU documentation being removed from Debian. -- Glenn Maynard
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Thu, 17 Apr 2003 12:37:28 -0500, Branden Robinson [EMAIL PROTECTED] said: On Tue, Apr 15, 2003 at 09:10:00AM -0700, Mark Rafn wrote: Good luck with that, and I look forward to hearing from you and/or other FSF representatives soon. I hope it's not terribly much longer, as the current semi-consensus is likely to congeal into an actual necessity to remove un-free emacs documentation from Debian. Not if people don't second my motion, or propose something similar. It may be that we're content to complain but lack the will to act. For what it is worth, as a memeber of the silent lurkers, I agree with and would second your proposal. manoj pgpTLq5kGQFsa.pgp Description: PGP signature -- There is no doubt that my lawyer is honest. For example, when he filed his income tax return last year, he declared half of his salary as 'unearned income.' Michael Lara Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
Florian Weimer [EMAIL PROTECTED] writes: Hans Reiser [EMAIL PROTECTED] writes: You'll note that ReiserFS anticipated the GNU GPL V3 by including clauses that forbid removal of credits in its license, and for a long time I have been telling Stallman that he needs to get V3 of the GPL out the door. Oh, I think it's natural to assume that these clauses are superfluous because the GPL explicitly states that a distributor may not impose any further restrictions on the recipients' exercise of the rights granted herein. If these clauses were of any legal relevance, your software wouldn't be redistributable at all. Just don't use the GPL for your software if you don't like it, but don't complain if anyone misunderstands your homemade license mishmash. Well, usually we also try to use common sense, syllogism and rocket science to find out what the author's intent was. Fortunately Hans Reiser made his intent clear by posting this statement to debian-devel. The only consequence I can see is to move reiserfsprogs to non-free. For those who have not followed the discussion and such, the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Cheers, Lukas P.S.: Cc'ed to debian-legal, which is probably the better place to discuss this. -- Give a man an answer, and he's satisfied today. Teach him to program, and he will be frustrated for the rest of his life.
Re: query from Georg Greve of GNU about Debian's opinion of the FDL
On Mon, 2003-04-14 at 15:24, Anthony Towns wrote: [1] http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html The rule is that the invariant section can contain anything as long as it is not the subject matter of the article. In particular, the invariant section can contain HTML code for linking back to the article. If this is the case, then it is another problem: I could not print a book with this article (can't put HTML in a book); use it in a LaTeX manual (no HTML in latex); convert it to PDF, etc. signature.asc Description: This is a digitally signed message part
Re: plagiarism of reiserfs by Debian
Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message is certainly not the same as a list of sponsors, they both require some messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. That said, the screenfull of messages indeed is a nuisance; could they be replaced by a reference to them? I'd think of something like 'development of ReiserFS was sponsored by multiple third parties; please see compile-time defined filename for details', or maybe 'development of ReiserFS was sponsored by list of names of third parties; please see compile-time defined filename for details' if your contracts don't allow for removal of those names from the output... -- wouter at grep dot be An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. signature.asc Description: Dit berichtdeel is digitaal gesigneerd
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Wed, Apr 16, 2003 at 10:52:55AM +0200, Georg C. F. Greve wrote: The GFDL offers the users and distributors such as Debian a higher degree of legal security, however, as someone who has not used the possible measure of invariant section will have a much harder time suing for violation of his or her moral rights than someone using a license that didn't offer such measures. I find this argument unconvincing, for two reasons. First, Invariant sections don't actually accomplish this. Only Secondary Sections can be marked Invariant. Other sections, i.e. the meat of the document, cannot be so marked under the GFDL. Therefore, using the GFDL says nothing about the author's claims to moral rights on the majority of the document. Second, documentation is often just as functional as the programs it describes, and this goes both ways. Consider TeX, where the documentation and the code were created as a single work. Consider also how protective Donald Knuth has been of TeX's rendering algorithms. I don't see why the code-part-of-TeX should be treated under entirely different rules than the book-part-of-TeX, and I don't see how you could seriously claim that there are no aesthetic components to the way TeX lays out documents. I don't see this critical difference that makes Invariant Sections necessary for documentation but leaves the GPL just fine for code. Richard Braakman
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote: Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message is certainly not the same as a list of sponsors, they both require some messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. The choice of the word legalese seems appropriate here; whereas the GPL requirement is a concession to the legal reality that one must actively disclaim warranty in some jurisdictions to avoid lawsuits from users (who needn't agree to the GPL in full in order to use the software), there is no such *legal* justification for a requirement that credits be listed in the program's output. Therefore, while most would concede that authors shouldn't have to expose themselves to legal liability in order to release free software, it's not so obvious that a requirement to list credits in the output of a running program is necessarily DFSG-free. -- Steve Langasek postmodern programmer pgp9MjqfFFRlU.pgp Description: PGP signature
Re: motion to take action on the unhappy GNU FDL issue
Branden Robinson wrote: Well, I've been too cowardly to raise this issue of late, but given that the temperature of debian-legal has been taken a few times over the past several months, and there seems to be a steady or growing feeling that Invariant Sections are not something we can live with, shall we resolve to move forward on this issue? I propose that we: * draft a comprehensive critique of the GNU FDL 1.2, detailing section-by-section our problems with the license * draft a FAQ regarding why we differ with FSF orthodoxy on this issue * draft a document advising users of the GNU FDL how to add riders to their license terms such that works so licensed are DFSG-free, and pointing out alternative documentation licenses that are also DFSG-free Then: * exhaustively identify works in main and contrib using the GNU FDL[1] * contact[2] the package maintainers and upstream authors of each affected source package, and include pointers to the above documents * post a list of affected packages to debian-devel-announce and/or debian-announce, so that no one is surprised by whatever later actions occur * give people some time to consider and act upon the above contact (some may relicense, some will tell us to go pound sand, others won't reply at all) * remove packages from main and contrib whose licenses have not been brought into compliance with the DFSG ... I am seeking seconds for this proposal. I am not a Debian developer, but I am one of the upstream developers of a piece of software (GCC) that would be affected by this proposal, and so I would like to say that I wholeheartedly support it. I wrote a lot of the text in the cpp manual, at a time when its license was the old vague FSF- documentation license; I'm not at all happy with its relicensing under terms I don't consider to be free. I attempted earlier this year to convince RMS to remove the invariant sections from the GCC manuals, which he would not do; unfortunately, there isn't any further recourse available to me (I suppose I could sue the FSF for violating its end of the copyright assignment contract, but that would be totally counterproductive). So I would very much like to see Debian take action as outlined above, because you collectively might have enough clout to get the FSF to change its position. zw The above is my personal opinion, not the opinion of the GCC maintainers collectively, nor is it necessarily endorsed by my employer. Please do NOT cc: me on replies to this message.
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
Glenn Maynard [EMAIL PROTECTED] writes: On Thu, Apr 17, 2003 at 03:05:48PM -0400, Brian T. Sniffen wrote: But the issue here is not copying or modifying an existing card, but deriving a reference card from the Emacs manual. If the documentation was licensed under the BSD license, wouldn't you still have to include the full license text on the card? If the GPL, a change list as well? No. I could include them on another piece of paper with the card. Those licenses merely require text be included *with* the document. The GFDL mandates that invariant sections be part of the document, which is much worse. For example, if I want to create some art with Richard Stallman's photograph over a backdrop of text from the emacs manual, I have to include the GNU manifesto as *part of the picture*. It's not enough to include it alongside the picture, it has to be part of the same document. In contrast, the free GPL or free BSD license lets me just include a copyright statement for the text, and a copy of the license, with the picture. If these are a problem as well, the argument against the GFDL here is less interesting; and if they're not, this GFDL argument probably isn't, either. There seem to be other, more convincing arguments against invariant sections. For example, if I want to perform a dramatic reading of a page from the Emacs Manual in some horribly expensive format, I have to read a bunch of invariant sections with it. I agree that there are more convincing philosophical arguments to avoid invariant sections, and to consider invariant sections non-free. But this is an example of a category of practical problems introduced by invariant sections, something which can be presented to those who say this is merely a philosophical issue. -Brian
Re: Proposed statement wrt GNU FDL
On Sat, Apr 19, 2003 at 11:29:38PM +1000, Anthony Towns wrote: (Hrm, asking for someone to handle this results in a motion for it to be handled, and lots of seconds that aren't willing to actually do anything. How helpful.) That comment was unhelpful, and just discourages people from helping. Speaking for myself, I was waiting for Branden to conclude that he had enough seconds. As for the people who said they wouldn't have time to help -- would you prefer that they hadn't seconded the proposal either? We could have had a nicely silent majority. Also, remember that it's Easter. Lots of people are busy with family stuff. Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) [...] The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications, particularly: I was confused by the pronouns here. How about this? The GNU FDL includes a number of conditions, which apply to all modified versions, that disallow modifications. In particular: (Section I, 'Preserve the section entitled History', is also a candidate for this list.) [...] I also have a list of other problems with the GFDL. They should probably all be listed together, though we may want to skip some as being too nitpicky. That is, if this is to be the comprehensive list Branden mentioned. It's easy to misapply the GNU FDL. The GNU FDL says that only Secondary Sections (a term it defines) may be marked Invariant, but does not say what should happen if a section that is not Secondary is listed as an Invariant Section. The FSF itself has made this mistake several times[1], so we know it's an easy mistake to make. [1] I remember two in the GDB manual and one in the Emacs manual. (Un)fortunately these mistakes have been corrected and I no longer have the old versions around. Does anyone have references? Definition of Transparent copy is limiting The GNU FDL defines the words Transparent and Opaque to distinguish between source-like and object-like documents (e.g. comparing LaTeX to PDF). Unfortunately, this definition focuses on implementation rather than intent. It requires that every component of a document is either text, or an image, or a drawing. This leaves out for example sound files, which can never be distributed as part of a document under the GNU FDL. ([Maybe insert rant about PostScript not being Opaque by definition. In fact, PostScript is the perfect example for documentation == software.]) GNU FDL creates a wall between documentation and code The GFDL is incompatible with the GPL, and many of its requirements don't translate well to functional software. This makes it difficult to embed such documents into a program, for example in order to present on-line help. In the other direction, many documents contain example code, sometimes sizeable chunks of it, which will be unusable by default unless specifically licensed otherwise. Obnoxious Accumulation of Cover Texts Every contributor can add up to 5 words of Front-Cover Text and up to 25 words of Back-Cover Text. It won't take long before there is no space for artwork on the front cover, just a dense list of short texts. ([Nit: The front cover must present the full title with all words of the title equally prominent and visible. So no artistic license allowed in title arrangement. Nethack: Journey through the MAZES of MENACE is right out, especially if MENACE has little goblins holding up the letters.]) Obnoxious Accumulation of Invariant Sections If two documents under the GNU FDL are reorganized (producing two new documents with parts from each), then the Invariant Sections from each of them have to be duplicated in both, except for sections that are identical. If they differ (for example, both documents have a Distribution section, but one has the old FSF address and another has the new one), then both have to be included. This can become unmanageable as documents evolve. ([This point might be subsumed under Invariant Sections are bad, and in any case we might not care because DFSG#4 allows something similar. Do we care?]) The GNU FDL restricts the presentation of documents (This is a general point, I'm not sure how to word it. We accept many limitations in free software licenses, such as changelog requirements, because they affect the source code but not the object code. It's still possible to create whatever technical effect is desired, even if manipulating the source can get a little awkward. The GFDL, by contrast, makes nearly all of its demands on the object of a document, not its source. For example, its requirements for Front-Cover Texts are very similar to the Zope and PHP-Nuke requirements that we have rejected as non-free. This point is also the root problem of the reference-card scenario.) Languages other
Re: Proposed statement wrt GNU FDL
On Sat, Apr 19, 2003 at 11:29:38PM +1000, Anthony Towns wrote: (Hrm, asking for someone to handle this results in a motion for it to be handled, and lots of seconds that aren't willing to actually do anything. How helpful.) Yeesh. I'm so used to getting screamed at when I make proposals, that one would think people would understand when I give people an opportunity to object before going forward. Thanks for your contribution to this effort in question, but I could do without the sniping about my efforts at building consensus. I was only engaging in the sort of activity Martin Michlmayr flatly accused me of being incapable of doing in his DPL platform rebuttal... (As an aside, I do wonder why we bother with platforms and rebuttals at all in our DPL election process -- I suspect people make up their minds about how they'll vote without such documents exerting much in the way of influence at all.) -- G. Branden Robinson| Never attribute to malice that Debian GNU/Linux | which can be adequately explained [EMAIL PROTECTED] | by stupidity. http://people.debian.org/~branden/ | pgpMB3XMinK3U.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: On Sat, Apr 19, 2003 at 11:29:38PM +1000, Anthony Towns wrote: (Hrm, asking for someone to handle this results in a motion for it to be handled, and lots of seconds that aren't willing to actually do anything. How helpful.) That comment was unhelpful, and just discourages people from helping. Speaking for myself, I was waiting for Branden to conclude that he had enough seconds. Oh, I think Anthony's just trying to make it clear that the fact that he and I agree about something is the purest accident, and must not be taken as inductive evidence that he and I have anything else at all in common. He's got his dignity to protect, you know. :) Anyway, before going *full* steam ahead I'd like to see if we get any cries of anguish after my message gets covered in Debian Weekly News (which gets circulated among the broader community). However, Anthony's put together an excellent draft to guide us forward, and we can definitely be honing our arguments and marshaling our facts in the meantime. I run a Subversion repository at necrotic.deadbeast.net, and was considering housing the documents there. However a Project machine would likely be more appropriate, and since all developers would have accounts on it, it would be trivial to use the svn:// scheme with SSH tunneling. Thoughts? -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpwy08l0Vhon.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 01:24:09AM +0200, Wouter Verhelst wrote: Op za 19-04-2003, om 22:51 schreef Lukas Geyer: the issue seems to be the fix of #152547. If we are not allowed to remove a screenful of advertising from the output of a program, then this unduly restricts the freedom to distribute modified versions. Uhm. From the GPL, section 2: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Otherwise put: if the program shows the 'no warranty' clause from the GPL at startup, you may not remove it. Although a 'no warranty' message is certainly not the same as a list of sponsors, they both require some messages being printed for legalese reasons. I, personally, see nothing wrong with that; it certainly doesn't result in software being non-free. I disagree. Some people on the debian-legal list feel that GPL 2c is only barely tolerable from a DFSG-freeness standpoint, and some also feel that it is ambiguously worded (see the debian-legal archives for the gory details -- it's in the PHPNuke license thread, which is huge). GPL 2c only requires the presence of a copyright notice, warranty disclaimer, notice that the work is licensed under the GNU GPL, and instructions on how to view the license text. A list of sponsors is none of these. Preservation of such is not required by the GNU GPL itself. Therefore this material can be removed under the permissions granted in section 2. If such a restriction is de facto being imposed by the copyright holder, then the work is not actually licensed under the GPL, but rather the GNU GPL plus extra restrictions, and as a result is not GPL-compatible. If the work dynamically links to or otherwise incorporates other copyright holders' GPLed works, then as a consequence of section 7 of the GNU GPL, Debian cannot distribute this work *at all*. Not even in non-free. Of course, to put this discussion in proper perspective, given some of the provisions of the GNU Free Documentation License[1], it may be that a future version of the GNU GPL permits copyright holders to compel the display of arbitrary amounts of material on program startup. GNU Emacs, for instance, may be altered to display the GNU Manifesto in the scratch buffer at startup, and it may be against the terms of this future version of the GNU GPL to defeat this behavior. So, the sort of thing the author of the work in question is doing may actually be perceived by the FSF as a good thing, and future versions of their licenses may not only support it, but encourage it. If all of this sounds surprising to people on debian-devel, I suggest they subscribe to, or review the archives of, the debian-legal mailing list. [1] http://www.gnu.org/copyleft/fdl.html -- G. Branden Robinson| We either learn from history or, Debian GNU/Linux | uh, well, something bad will [EMAIL PROTECTED] | happen. http://people.debian.org/~branden/ | -- Bob Church pgpQTVWu8Hp4u.pgp Description: PGP signature
