Re: Proposed statement wrt GNU FDL
On Wed, 2003-05-07 at 02:14, Branden Robinson wrote: Another good argument against the GNU FDL. Not to mention that publishing known false statements, like claiming it is a GNU Manual or that the FSF publishes copies, is of dubious legality. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Thu, May 08, 2003 at 06:07:10AM +1000, Anthony Towns wrote: As far as I know, we're happy to accept non-free stuff in pristine .orig.tar.gz's as long as it's not used. If you don't have a pristine .orig.tar.gz anyway, then it's silly to include unused non-free stuff, but it's not cause for a REJECT. Well, that's weird, because back when we had the xc/util/patch problem with XFree86, I asked if it was okay if I just let the sleeping dog lie until the next upstream release, and nobody said yes. http://lists.debian.org/debian-ctte/2001/debian-ctte-200108/msg00034.html Maybe the answer depends on how angry one has made the FTP admins lately... :) -- G. Branden Robinson| The last Christian died on the Debian GNU/Linux | cross. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpCGwFI3uW6q.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 01:41:27AM -0400, Glenn Maynard wrote: On Sat, Apr 26, 2003 at 12:24:56AM -0400, Anthony DeRobertis wrote: 1) You remove the FSF's endorsement of the license which is the preamble. The Debian Project has no problem with this; it is certainly an author's right to refuse to endorse arbitrary changes. So, the full terms that the GPL is distributed under, as explained on the FSF website, actually comply with the DFSG. It still contains an invariant section, though it's less severe than the GFDL type, as it can be removed. I don't believe there's consensus that invariant sections in general are okay as long as they can be removed, though. I think before Debian puts anything in main it should remove any invariant sections from the work, just as we do with non-free source code. I once had a big old nasty flamewar with the FTP admins that was tangentially related to this point, but the FTP admins and I agreed that having non-free source code in a package's .orig.tar.gz was unacceptable even if it wasn't used for anything and did not appear in any binary packages. In other words, invariant sections (small I, small S) are not DFSG-free, but the removal of invariant sections from a work may be sufficient to render it DSFG-free. -- G. Branden Robinson| There is no gravity in space. Debian GNU/Linux | Then how could astronauts walk [EMAIL PROTECTED] | around on the Moon? http://people.debian.org/~branden/ | Because they wore heavy boots. pgpnzBhtXogLa.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Tue, Apr 29, 2003 at 03:30:26PM +0200, Henning Makholm wrote: Actually, I wonder whether the current application of the GFDL for GNU manuals is internally consistent at all. For example, the GNU diffutils manual is licenced with the Front-Cover Text A GNU Manual. Say now that I'm a FooBSD user who for some reason have become dissatisfied with the quality of the documentation for diff that FooBSD ships with (this is a hypothetical example; I have access to no *BSD systems and don't know anything about the actual state of their documentation). So I take the texinfo source for the GNU diffutils manual and hack upon it so that it describes FooBSD diff. Now I have a manual for FooBSD diff whose license says that it needs to be called A GNU Manual on its front cover. That could be somewhat confusing for users - does this document describe the FooBSD or the GNU implementation of diff? And is this front-cover text even compatible with the requirement that I remove all Endorsements? Worse yet, my FooBSD diff manual must say on its *back* cover: Copies published by the Free Software Foundation raise funds for GNU development which is rather meaningless as long as the FSF does not publish copies of the FooBSD version of the manual at all! Another good argument against the GNU FDL. Sorry for the AOL remark, but I'm trying to flag stuff I think should go in our big FAQ. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgpkGySocsO7Z.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
Le mer 07/05/2003 à 08:12, Branden Robinson a écrit : I think before Debian puts anything in main it should remove any invariant sections from the work, just as we do with non-free source code. I once had a big old nasty flamewar with the FTP admins that was tangentially related to this point, but the FTP admins and I agreed that having non-free source code in a package's .orig.tar.gz was unacceptable even if it wasn't used for anything and did not appear in any binary packages. By removing invariant sections, don't we simply violate the GFDL ? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Wed, May 07, 2003 at 01:12:27AM -0500, Branden Robinson wrote: I think before Debian puts anything in main it should remove any invariant sections from the work, just as we do with non-free source code. I once had a big old nasty flamewar with the FTP admins that was tangentially related to this point, but the FTP admins and I agreed that having non-free source code in a package's .orig.tar.gz was unacceptable even if it wasn't used for anything and did not appear in any binary packages. As far as I know, we're happy to accept non-free stuff in pristine .orig.tar.gz's as long as it's not used. If you don't have a pristine .orig.tar.gz anyway, then it's silly to include unused non-free stuff, but it's not cause for a REJECT. In other words, invariant sections (small I, small S) are not DFSG-free, but the removal of invariant sections from a work may be sufficient to render it DSFG-free. Assuming that's allowed by the license of course. As far as I'm aware, it's quite okay to do this in either the .diff.gz or debian/rules, though. 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!'' pgpYMq117Au98.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, May 08, 2003 at 06:07:10AM +1000, Anthony Towns wrote: As far as I know, we're happy to accept non-free stuff in pristine .orig.tar.gz's as long as it's not used. Okay, so this is wrong. You're not allowed to include non-free stuff in anything uploaded to main, .deb, .diff.gz or .orig.tar.gz. 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!'' pgpy0UZeUUxSh.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, 08 May 2003, Anthony Towns wrote: As far as I know, we're happy to accept non-free stuff in pristine .orig.tar.gz's as long as it's not used. I'd actually expect apt-get source foo to return sources that are DFSG free, when foo is in main or contrib. Granted, you should be checking the licenses of any source that you use before you use it, but I would assume many of us expect all of the software and sources in main to be free under the DFSG. If you don't have a pristine .orig.tar.gz anyway, then it's silly to include unused non-free stuff, but it's not cause for a REJECT. But it seems strange (to me anyway) that an ftp-master would be finding this out in a situation where a maintainer didn't already know about it. Either someone didn't look over the code and licenses when they were packaging, didn't examine the diff between versions, was otherwise unaware of what they were uploading, or knew and didn't have time to do anything abou it. Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpqq70EPpoe5.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Sat, 26 Apr 2003, Henning Makholm wrote: But as we've found out now, the part of the GPL that is actually invariant is the preamble, which has no legal content... I've seen this meme popping up in a couple of places. Can you provide me a reference upon which you are basing this statement? Don Armstrong -- DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpfX6Vx1KTDa.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, 01 May 2003, Don Armstrong wrote: On Sat, 26 Apr 2003, Henning Makholm wrote: But as we've found out now, the part of the GPL that is actually invariant is the preamble, which has no legal content... Can you provide me a reference upon which you are basing this statement? I should remind myself to follow up with all of my unread mail before asking questions which are easily answered.[1] Although, note the dissonance between [1] and [2]: In fact, the GPL is copyrighted, and its license permits only verbatim copying of the entire GPL. Wheras [1] in the FAQ says something to the effect of: If you modify it, we probably wont take legal action against you Of course, the language of the GPL copyright clause itself is prety clear that it precludes modification. [I guess the FSF just wants it both ways...] Don Armstrong 1: http://www.gnu.org/licenses/gpl-faq.html#TOCModifyGPL 2: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble -- I never until now realized that the primary job of any emoticon is to say excuse me, that didn't make any sense. ;-P -- Cory Doctorow http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu pgpXv33IeHgkR.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Tue, 2003-04-29 at 15:22, Brian M. Carlson wrote: ^^^ Uhh, I didn't know that the IETF issued RFCs in the future. Perhaps you meant April 2003? Might have something to do with [EMAIL PROTECTED], or the effect of that on me :-D signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
Scripsit Anthony Towns aj@azure.humbug.org.au 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. Actually, I wonder whether the current application of the GFDL for GNU manuals is internally consistent at all. For example, the GNU diffutils manual is licenced with the Front-Cover Text A GNU Manual. Say now that I'm a FooBSD user who for some reason have become dissatisfied with the quality of the documentation for diff that FooBSD ships with (this is a hypothetical example; I have access to no *BSD systems and don't know anything about the actual state of their documentation). So I take the texinfo source for the GNU diffutils manual and hack upon it so that it describes FooBSD diff. Now I have a manual for FooBSD diff whose license says that it needs to be called A GNU Manual on its front cover. That could be somewhat confusing for users - does this document describe the FooBSD or the GNU implementation of diff? And is this front-cover text even compatible with the requirement that I remove all Endorsements? Worse yet, my FooBSD diff manual must say on its *back* cover: Copies published by the Free Software Foundation raise funds for GNU development which is rather meaningless as long as the FSF does not publish copies of the FooBSD version of the manual at all! -- Henning Makholm ... not one has been remembered from the time when the author studied freshman physics. Quite the contrary: he merely remembers that such and such is true, and to explain it he invents a demonstration at the moment it is needed.
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 01:50:33AM -0400, Anthony DeRobertis wrote: RFC 1884 (December 1995) RFC 2373 (July 1998) RFC 3515 (August 2003) ^^^ Uhh, I didn't know that the IETF issued RFCs in the future. Perhaps you meant April 2003? -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpjlBVCBWGn2.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Sat, 2003-04-26 at 03:12, Henning Makholm wrote: The current status of the preamble goes much farther than that. It says that I must not reuse the wordings in the preamble for composing a text that expresses *my* views on licensing (and makes clear that they are mine, not the FSF's). That's true. I wonder if the FSF would be willing to change that. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
Anthony DeRobertis [EMAIL PROTECTED] writes: On Fri, 2003-04-25 at 11:26, Jeremy Hankins wrote: On one hand, the benefits to be gained from a free-software-like approach to purely artistic/aesthetic (i.e., non-functional) works aren't as obvious. A rather ironic statement in a Bazaar-type development of the wording of a position statement, methinks :-) Also, I must strongly disagree in general. Take artwork for example. Suppose you create a (digital) painting of a flower, and you make it red. I decide that orange would be better, so I change it. Maybe aj comes along and thinks the leaf would look better if it were a little rounder. I'm not sure we're disagreeing, actually. The bit you quoted was more a setting up the problem bit, which I then argued against in the rest of the message. I think it is the case that the benefits aren't as obvious, but that doesn't mean that they aren't there. What's more, given that restrictive licensing isn't actually necessary to protect the pride-in-work style interests of authors, there's no reason for them. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 12:33:21PM +1000, Matthew Palmer wrote: RFC authors do it all the time, by issuing updates to existing RFC documents. They say Do it like this, except for this, this, and this. This argument would suggest that any unmodifiable, freely-distributable document is free. You can reference *any* document in this way. It's certainly not similar to software patches. (And I believe many people on this list consider the patches exception to have been an error.) There's nothing free about being forced to do this. -- Glenn Maynard
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 10:49:26PM +0200, Thomas Uwe Gruettmueller wrote: There's lots of software in non-free that is freely distributable, but non-free for other reasons, such as limitations on commercial use. Non- free things should go in non-free, even if there's a lack of free equivalents. I agree that they should not stay in main, but I don't think that freely distributable documents should be mixed with stuff which is not allowed to be distributed commercially, or which according to its license, cannot be exported to Iraq. Why should Debian distinguish between different shades of non-freeness? Are you aware that there is much software already in non-free which is freely redistributable but non-modifiable? -- Steve Langasek postmodern programmer pgpMT57AVSXPO.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
What About Unmodifiable Software Licenses Like the GNU GPL? Strike that text! It's not true. Noting http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL, let me try: start new answer The Free Software Foundation clarifies what it means by ...but changing [the GPL] is not allowed in its GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL. In brief, this says that you may change the GPL provided that: 1) You remove the FSF's endorsement of the license which is the preamble. The Debian Project has no problem with this; it is certainly an author's right to refuse to endorse arbitrary changes. 2) You do not call the license GPL and make it clear that it isn't the GPL. We understand that certain types of software, require this, and thus our DFSG explicitly permits this, stating The license may require derived works to carry a different name or version number from the original software. So, the full terms that the GPL is distributed under, as explained on the FSF website, actually comply with the DFSG. end new answer signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Fri, 2003-04-25 at 11:26, Jeremy Hankins wrote: On one hand, the benefits to be gained from a free-software-like approach to purely artistic/aesthetic (i.e., non-functional) works aren't as obvious. A rather ironic statement in a Bazaar-type development of the wording of a position statement, methinks :-) Also, I must strongly disagree in general. Take artwork for example. Suppose you create a (digital) painting of a flower, and you make it red. I decide that orange would be better, so I change it. Maybe aj comes along and thinks the leaf would look better if it were a little rounder. Or, more pertinently to Debian, I think the icon for a program is ugly, so I change it. Or I dislike a theme author's choice of fonts, colors, etc. These are, as much as anything can be, purely aesthetic considerations, and yet, clearly benefit from being free. Art also often includes other art into itself. For example, I've got a neat desktop background which uses the Debian Swirl. Novels may not benefit much from word-for-word copying from each other, but copying things like characters, scenes, etc. could sure be useful. You don't see it much because it's against copyright law. The ones that are seen are parodies, and are only allowed due to fair use. And they have to fight it out in court half the time anyway (recent example: _The Wind Done Gone_) Many movies have been made from fairy tales, fables, and legends that are, free due to their public-domain status (go ask Disney about that hypocracy). Many pieces of music borrow themes, or even the entire tune, from other, now public-domain music. I'm not sure where the myth that the benefits of freedom are less for non-software comes from, but it sure isn't true. signature.asc Description: This is a digitally signed message part
Re: Is documentation different from software [Re: Proposed statement wrt GNU FDL]
On Fri, 2003-04-25 at 22:27, Matthew Palmer wrote: Except that it's typically a lot easier to work out where a program has been incompatibly modified (oops, compile error, damn, the API changed) than a standard has been modified. The use of 'diff' notwithstanding. Well, when you modify a program enough to cause a compile error, sure it's easy to spot. It's also easy to spot when someone modifies a standard by renaming all the sections and changing the terminology. If you really think that its a lot easier to note where a program has been incompatibly modified, please find all the places where NCSA Mosiac has been incompatibly (with the relevant standards) been modified to produce Internet Exploder. Or, if you content that source must be available, please confirm that GCC-3.2 - GCC-3.3 won't cause any regressions in compatibility with the C++ standard, the various microprocessor standards, etc. The FSF, I'm sure, will be most grateful for that work. It's not easy to find program modifications that don't show up as compile- or link-time errors, even with the use of diff. Programs can be quite long, and often changes don't change behavior (e.g., optimizations). An even larger subset of changes don't break compatibility. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Fri, 2003-04-25 at 22:33, Matthew Palmer wrote: RFC authors do it all the time, by issuing updates to existing RFC documents. They say Do it like this, except for this, this, and this. No, that's generally only done for tiny changes: Adding a bit here or there, etc. For large changes, the old document is obsoleted and the relevant portions included into the new one. Any other way would be insane! Consider that to understand the IPv6 Addressing Architecture, you'd have to read, in order: RFC 1884 (December 1995) RFC 2373 (July 1998) RFC 3515 (August 2003) An RFC can either obsolete another RFC (completely replace it) or update it. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Thu, 2003-04-24 at 12:34, Henning Makholm wrote: Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. [Hmmm.. so I think at least, but I'm not sure that this is a clear d-l consensus. -HM] I don't think invariant-but-removable sections are OK; we'd certainly never accept things like that anywhere else, and I don't think that compromise would buy anyone much: If I am the author of a work, why would I want it? The only reason I'd have to make something invariant would be something like the manifesto, which contains my beliefs, arguments, etc. But would it not be a better solution to require that if its changed, it is clearly changed to show may not represent my views anymore? If I am the author, I could _possibly_ use one for an endorsement of the work, by e.g., making a statement in a removable invariant section that I endorse the work with a given MD5sum (calculated assuming the listed md5sum is all 0's, of course), but upon further reflection I don't need an invariant section for that: I could use gpg, or I could just include that statement anywhere in the document. Changing it to state I endorse a document I do not is already illegal. I don't need license conditions to make it so. If I am a distributor, sure, I can rip them all out, but not having them in the first place is better for me. I can see the motivation for non-removable invariant sections; they can be used for things like credits, dedications, odes to my pet anteater, etc. They just aren't free. signature.asc Description: This is a digitally signed message part
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 02:40:29AM -0400, Anthony DeRobertis wrote: It still contains an invariant section, though it's less severe than the GFDL type, as it can be removed. I don't believe there's consensus that invariant sections in general are okay as long as they can be removed, though. It's nothing special created by the copyright license. Its the general rule that you aren't allowed to misrepresent other's beliefs, which is what carrying the Preamble to your modified license (especially the first two paragraphs), without the FSF's permission, would be. I can change most of that text all I want, and as long as I don't claim the resulting text is the FSF's beliefs, I'm not misrepresenting anything. The only thing stopping me from doing that is the FSF's copyright. -- Glenn Maynard
Re: Proposed statement wrt GNU FDL
On Sat, Apr 26, 2003 at 11:50:45PM +0200, Thomas Uwe Gruettmueller wrote: Are you aware that there is much software already in non-free which is freely redistributable but non-modifiable? Then leave it there until someone starts complaining about it. (and then continue leaving it there) -- Glenn Maynard
Re: Proposed statement wrt GNU FDL
On 24 Apr 2003, Henning Makholm wrote: Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto be included in the Debian GNU/Linux Distribution anyway? I propose expanding this question to: Why does Debian want to remove (say) the GNU Manifesto from the manuals? Do you want to suppress Stallman's views and just benefit from the software he created? [Answer snipped] fx: resounding applause For what it's worth, I think this should go in pretty much unaltered (except for a typo fix: Changes to the software they get *from* us, line 8, para 2). It treads the line between rah, rah, we love Stallman and Stallman sucks quite well. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 06:20:27PM -0400, Joey Hess wrote: instead of a document like this one that warns about and criticises the FDL, perhaps Debian should issue a more general statement along the lines of: We have decided documentation in Debian must comply with the DFSG, and this will entail throwing the following documents out of the distribution, and certian licenses (FDL etc) are causing problems in this task. Just an idea and I don't feel like writing it myself, but it might be less inflammatory. I think we probably need this too, but it can't be instead of a thing about the FDL, since otherwise we'd just get But the GNU FDL's a free license -- it says so right in the name -- why're you throwing stuff licensed under it out? 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!'' pgpK223VZjOXS.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Fri, 25 Apr 2003, Anthony Towns wrote: If we are willing to accept invariant chapters in DFSG-free documentation, I don't see how we could possibly claim the GNU FDL is not DFSG-free. Merely being able to delete something doesn't make it free -- I can delete MS Office easily enough, eg. In short, I don't think that's a justifiable position. The difference between Office and Invariants is (if I understand the licence correctly) that Invariant sections can't be large chunks of the manual - only so-called secondary sections. It's merely just extending the unmodifiability from the copyright notice itself to other ephemeral parts of the documentation, while keeping the meat of the document flexible. I don't think Invariant sections are a good idea because if one small part of them is out-of-date (for instance the project website in a section on Getting the Software) you can't just update the address. Why someone would make a section Getting the Software invariant is beyond me, but it would probably fit in the definition of a Secondary Section, so someone somewhere would probably mark it as invariant through lack of knowledge. At least being able to remove an invariant section and replacing it with something equivalent solves that problem. I still don't like them, though. What we do want is for our *users* to be allowed to remove the GNU Manifesto from the manual if they can think of a reason to do so. No -- we want our users to be able to take everything we give them, and be able to build on any part of it they might choose, with few exceptions. Being able to remove an invariant secondary section wholesale allows the user to build on the meat of the document without having to put all of the invariant sections into their derived documentation if it doesn't fit (see The Reference Card example for why this is needed). If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. That would mean that part of what we distribute (namely the Invariant Section itself) would not, strictly speaking, be modifyable, but exceptions can be made for things that are both sufficiently non-software-like not to need modifyability for technical reasons and sufficienly relevant not to just constitute a waste of space in the distribution. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? I didn't read that anywhere (though I may have missed it). Since we're allowing non-modifyable licence texts (which I think everyone would agree is a given, and IIRC may be a legal requirement) allowing invariance on other things which do not affect the operability of the documentation/software doesn't seem like an overly huge problem. Defining operability in the realm of documentation would be the stumbling block. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 03:00:00PM +1000, Matthew Palmer wrote: The difference between Office and Invariants is (if I understand the licence correctly) that Invariant sections can't be large chunks of the manual - only so-called secondary sections. So, if I make a Debian system that includes a single non-free program, the entire system -- including the non-free program -- is DFSG-free, because the non-free program can be removed? 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!'' pgp7aOrN2h7t0.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Fri, 25 Apr 2003 04:57:36 +0200, Thomas Uwe Gruettmueller [EMAIL PROTECTED] said: On the other hand, the DFSGly non-free docs that are about to be thrown out of main are at least as freely distributable as any other package in main. This is a quality that many packages in non-free do not share with them. As I don't have non-free in my apt/sources.list, from my point of view, moving these docs to the 'non-free' section would practically mean the same thing as moving them to the trash dump. I guess this step would be far too radical. * Create a section 'distributable' that is between main and non-free, for stuff that is not free WRT modification, availability of the source code etc., but at least freely distributable in any medium, by anybody, for any price. Why are we special casing invariant sections? There are packages in main that are freely distributable in any medium, by anybody, and can be modified, but not for commercial distribution -- arguably, these are as free as anything else, since you can't even ask for money for them. Yet they are non-free (angband is one such package, if you are looking for examples). It seems to me that we have a well established tradition of deeming so-called freely-distributable-but-not-dfsg-free packages, and relegating them to non-free, and people like me who like tp play rogue-like games but prefer free software have to add non-free to our sources lists for ever. I am not finding this line of argument compelling. manoj -- Many books require no thought from those who read them, for a very simple reason--they made no such demand upon those who wrote them. Those works, therefore, are the most valuable that set our thinking faculties in the fullest operation. -- Colton 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: Proposed statement wrt GNU FDL
Scripsit Anthony Towns aj@azure.humbug.org.au If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? No, we just said that license text are sufficiently non-software-like to enjoy an exception. Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. And further, as a practical matter, it's not reasonable for us to be making judgement calls on every random piece of documentation that gets uploaded. A packager already has to make a lot of judgement calls when he packages something. Deciding which parts of the documentation is relevant and up-to-date to include in the binary package is already one of them. -- Henning Makholm Gå ud i solen eller regnen, smil, køb en ny trøje, slå en sludder af med købmanden, puds dine støvler. Lev!
Re: Proposed statement wrt GNU FDL
Scripsit Joey Hess [EMAIL PROTECTED] Anthony Towns wrote: What About Unmodifiable Software Licenses Like the GNU GPL? Many software licenses unfortunately disallow the creation ofderivative works. The FSF give everyone permission to distribute verbatim copies of the GPL, eg, but do not give you permission to take the Apparently they do allow it, according to Brian T. Sniffen who points out http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL If the license portion of the GPL can indeed be reused and modified then it is a bad example to use here. But the question itself is good, because many people do have the impression that the changing it is not allowed language at the top of the GPL itself is the final word. This question would be an excellent place to refer to Brian's discovery. And one notices that the original reasoning still applies to the GPL's Preamble, which seems to be explicitly non-reuseable. Beyond allowing invariant sections, why does the GNU FDL suck? A little peice of me wonders if why does the GNU FDL suck is politic even in a FAQ, but whatever. I think this is covered by the Draft Status Warning at the beginning of the FAQ. In the production version, let us chage it to what else is bad about the GNU FDL?. -- Henning Makholm ... popping pussies into pies Wouldn't do in my shop just the thought of it's enough to make you sick and I'm telling you them pussy cats is quick ...
Re: Proposed statement wrt GNU FDL
Scripsit Joe Moore [EMAIL PROTECTED] Henning Makholm said: Perhaps the O.A.C. ought to be our next target, but let us fight one battle at a time. EXPN O.A.C.? Obnoxious Advertising Clause. -- Henning Makholm However, the fact that the utterance by Epimenides of that false sentence could imply the existence of some Cretan who is not a liar is rather unsettling.
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 02:05:10PM +0200, Henning Makholm wrote: Scripsit Anthony Towns aj@azure.humbug.org.au If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? No, we just said that license text are sufficiently non-software-like to enjoy an exception. That's not why we're doing it. We're doing it because we don't have any choice about it. If you're seriously arguing that things that merely being not software-like is enough reason not to apply the DFSG to the GNU Manifesto or the GPL, then you can't apply it to documentation in general. If you want to draw a distinction between them, you need to draw a clear one, not handwave about it. There is a clear distinction between licenses and documentation -- one goes in /usr/share/doc/foo/copyright and is solely concerned about what you can and can't do with everything else, the other goes anywhere but in /usr/share/doc/foo/copyright. Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. And further, as a practical matter, it's not reasonable for us to be making judgement calls on every random piece of documentation that gets uploaded. A packager already has to make a lot of judgement calls when he packages something. It's not the packager that makes the judgement call as to what's allowable -- it's ftpmaster and -legal. Packagers simply aren't able to make reliable judgement calls as to what is and isn't DFSG-free in the general case. (And this is why I don't think me too posts are particularly relevant as to establishing consensus) 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!'' pgpgxicc8EJ1u.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
Henning Makholm [EMAIL PROTECTED] writes: If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. That would mean that part of what we distribute (namely the Invariant Section itself) would not, strictly speaking, be modifyable, but exceptions can be made for things that are both sufficiently non-software-like not to need modifyability for technical reasons and sufficienly relevant not to just constitute a waste of space in the distribution. Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. [Hmmm.. so I think at least, but I'm not sure that this is a clear d-l consensus. -HM] I think this is definitely not the d-l consensus. On one hand, the benefits to be gained from a free-software-like approach to purely artistic/aesthetic (i.e., non-functional) works aren't as obvious. While one can imagine exceptions, it's not as useful to mix-and-match bits of a novel into your own novel. You don't see nearly as many collaborative novels or paintings as programs, and I imagine that an authors pride in a work is much more associated with the work as a whole in the case of a novel or painting than in a program. On the other hand, this is an extremely fuzzy distinction, there are numerous exceptions, and bits that fall into one category will sometimes move into another. It seems to me that most of the pride-in-work issue can be resolved by a license that requires accurate attribution and changing the name (so as to make the changed attribution perfectly clear) when modified. Those requirements (assuming they're done right) are pretty clearly DFSG free, I think. So I'm sympathetic to someone who says: My work is my personal communication with the world and it doesn't make sense to put it in a commons. But I don't see any reason for Debian to distribute these folks' statements (fictional, rants, or otherwise) unless in some sort of (semi-)official way Debian actually supports or endorses the statement. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 02:21:24PM +0200, Henning Makholm wrote: But the question itself is good, because many people do have the impression that the changing it is not allowed language at the top of the GPL itself is the final word. This question would be an excellent place to refer to Brian's discovery. /me sniffles dejectedly But I made the same discovery 2 days earlier, on Tue, 22 Apr 2003 12:49:47 -0500 in Message-ID: [EMAIL PROTECTED]. /me pouts :) -- G. Branden Robinson|I am sorry, but what you have Debian GNU/Linux |mistaken for malicious intent is [EMAIL PROTECTED] |nothing more than sheer http://people.debian.org/~branden/ |incompetence! -- J. L. Rizzo II pgpYfJolANLW6.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
Henning Makholm said: Scripsit Anthony Towns aj@azure.humbug.org.au If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? No, we just said that license text are sufficiently non-software-like to enjoy an exception. I think the key reason (that licenses are acceptable invariant texts) is that the license text is a legal agreement between _you_ and the _copyright holder_. I can not change the agreement you have with the copyright holder, only you and she can. If you and she change your agreement (either by explicitly licensing under an alternative license, or implicitly by the holder changing the license, and you agreeing to those terms*) I have no control over that. I can not modify someone else's agreement. That is why the license texts must be invariant. --Joe * For example, if the work was originally released under a non-commercial use only license, but is later also released under the GPL, you might agree to the GPL's terms rather than the non-commercial use only.
Re: Proposed statement wrt GNU FDL
Hi Glenn,
On Friday 25 April 2003 05:00, Glenn Maynard wrote:
On Fri, Apr 25, 2003 at 04:57:36AM +0200, Thomas Uwe
Gruettmueller wrote:
On the other hand, the DFSGly non-free docs that are about
to be thrown out of main are at least as freely
distributable as any other package in main. This is a
quality that many packages in non-free do not share with
them.
There's lots of software in non-free that is freely
distributable, but non-free for other reasons, such as
limitations on commercial use. Non- free things should go in
non-free, even if there's a lack of free equivalents.
I agree that they should not stay in main, but I don't think
that freely distributable documents should be mixed with stuff
which is not allowed to be distributed commercially, or which
according to its license, cannot be exported to Iraq.
If the new section proposed below is considered a subset of
'non-free', then I fully agree with the above.
As I don't have non-free in my
apt/sources.list, from my point of view, moving these docs
to the 'non-free' section would practically mean the same
thing as moving them to the trash dump. I guess this step
would be far too radical.
Requiring you to add a line or two to sources.list isn't
trashing anything.
I'm not convinced, yet. Can I configure apt-cache that it
produces red '[contrib]' and '[non-free]' warnings like
packages.debian.org?
If this is a radical move, I'd say the earlier one of moving
non-free software to non-free was an order of magnitude more
radical.
Is there any documentation of the history of the 'non-free'
section? Have there been similar discussions?
So, now I'm repeating an idea that I alredy mentioned here,
after selfhtml had been kicked:
* Create a section 'distributable' that is between main and
non-free, for stuff that is not free WRT modification,
availability of the source code etc., but at least freely
distributable in any medium, by anybody, for any price.
Distributors can already do this. I don't think Debian should
be expending time categorizing non-free into non-free and
really non-free; let people who would actually use the
distinction (distributors) spend the time. (It'd be a fair bit
of time, requiring further analysis of clearly non-free
licenses.)
Right. The suggestion was primarily adressed to those people who
would like to change the DFSG. If they want to have guidelines
for lesser free software, in order to build a lesser free
variant of Debian, they are always free to create them, but
please not by replacing the original DFSG and the original
Debian!
cu,
Thomas
}:o{#
Re: Proposed statement wrt GNU FDL
On Fri, 25 Apr 2003, Jeremy Hankins wrote: [Disclaimer: if, at any point during the reading of this message, you see a point which has been raised and covered before, please point me to the archive message. I couldn't find anything in the d-legal archives back to Jan-2002 which appeared to deal with this. My apologies if I've rehashed something done to death before.] I think this is definitely not the d-l consensus. On one hand, the benefits to be gained from a free-software-like approach to purely artistic/aesthetic (i.e., non-functional) works aren't as obvious. While one can imagine exceptions, it's not as useful to mix-and-match bits of a novel into your own novel. You don't see nearly as many collaborative novels or paintings as programs, and I imagine that an authors pride in a work is much more associated with the work as a whole in the case of a novel or painting than in a program. I was about to pipe up with but we don't distribute novels with Debian until I realised that we want to distribute a few other novel-like things - pure documentation not associated with a specific software program (eg the hoary old chestnut of the RFCs). So, I have to start thinking again about documentation in a different light to software. Could we produce a distinction amongst our offerings in the following manner: * Software. Anything intended to instruct a computational device to perform some action. Yes, total crap definition, but it gets the idea across. * Documentation for software. Intended to enlighten humans on the design, implementation, usage, etc of a specific piece software. * Other documentation. Standards, DFSG, GNU manifesto, etc. DFSG applies to software. (duh). DFSG applied to docs for software (for all the very good reasons given in the draft Debian GFDL FAQ). But for other documentation (and we'd need to have a pretty clear definition of what that was before going too far forward) there could be a second set of guidelines for it's inclusion in Debian. To roast a hoary chestnut, I've not yet seen a good argument why we'd want the RFCs to be relicensed as DFSG-free, apart from the so it can go into Debian main. Modifying an RFC and re-releasing it is not a good thing, but the DFSG says it is, and we want that right (if we're applying DFSG to everything that goes into main, that is). The non-software documentation category seems to fit everything else we're worried about, too. The DFSG, social contract, GNU Manifesto, software licences, all of these are non-software documentation which we want to distribute (OK, maybe not the GM) but which in general we don't *want* to be DFSG-free. So, could it be possible to come up with a definition of non-software documentation, about which we could say it must be free for verbatim distribution (with copyright notices attached), translation, and conversion into other machine-readable formats but which, apart from that, normal copyright restrictions could apply? My first stab at a non-software documentation definition would be something like: * It must be intended for final consumption by a human reader. * It must not be specifically intended to apply to, or to refer to, a particular piece of software [I'm trying to word this so that the same doc which could be for many softwares, like a licence text, qualifies, but a README doesn't, because we'd want to modify a readme] * If distributed with a package of software, modification of the software or changing circumstance should not require a modification of the documentation. Not perfectly clear, and probably with loopholes you could put a jumbo through, but I think it's enough for the open-minded reader to get an understanding of. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Is documentation different from software [Re: Proposed statement wrt GNU FDL]
On Sat, 26 Apr 2003, Matthew Palmer wrote: I was about to pipe up with but we don't distribute novels with Debian until I realised that we want to distribute a few other novel-like things - pure documentation not associated with a specific software program (eg the hoary old chestnut of the RFCs). And interactive fiction, and screensaver artworks, and actual novels perhaps. So, I have to start thinking again about documentation in a different light to software. I'm still completely unconvinced that there is any useful distinction between a fractal generator, the generated fractal image (with human input on parameters, colors, etc), a paper describing what fractals are, a document describing how to make pretty fractals from the generator, and a poem inspired by a fractal. They're all encodable as streams of bits. They all require effort and creativity to create. They all are useful to a recipient. They all are free iff a user can modify and copy them. Could we produce a distinction amongst our offerings in the following manner: Why do we want to produce a distinction where there is none? DFSG applies to software. (duh). DFSG applied to docs for software (for all the very good reasons given in the draft Debian GFDL FAQ). But for other documentation (and we'd need to have a pretty clear definition of what that was before going too far forward) there could be a second set of guidelines for it's inclusion in Debian. Why? Why would we call a poem which cannot be modified free if we don't also think a poetry generator which cannot be modified is free? To roast a hoary chestnut, I've not yet seen a good argument why we'd want the RFCs to be relicensed as DFSG-free, apart from the so it can go into Debian main. Oh, that's easy. I wish they were free so I could reuse the good bits in other works, and otherwise improve my world by creating and distributing derived works. This is absolutly no different from why you'd want a piece of software to be licensed freely. Modifying an RFC and re-releasing it is not a good thing It's exactly as good a thing as modifying Apache and re-releasing it. The modified version is expected to fit someone's needs better than the original. The DFSG, social contract, GNU Manifesto, software licences, all of these are non-software documentation which we want to distribute (OK, maybe not the GM) but which in general we don't *want* to be DFSG-free. The owners of these documents should be encouraged to make them free, and if not, they should go in non-free. License texts themselves are a special case. The actual terms of the grant of permission cannot be changed, and can only be encoded in the original wording. That makes perfect sense, and is fundamentally different from a copyrightable work in a definable way. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Proposed statement wrt GNU FDL
Scripsit Branden Robinson [EMAIL PROTECTED] On Fri, Apr 25, 2003 at 02:21:24PM +0200, Henning Makholm wrote: excellent place to refer to Brian's discovery. /me sniffles dejectedly But I made the same discovery 2 days earlier, on Tue, 22 Apr 2003 12:49:47 -0500 in Message-ID: [EMAIL PROTECTED]. Apologies. I don't keep books on who said what first, just copied Joey's attibution. -- Henning Makholm - Or hast thee (perverted) designs to attempt (strange, hybrid) procreation experiments with this (virginal female) self?
Re: Proposed statement wrt GNU FDL
Scripsit Joe Moore [EMAIL PROTECTED] Henning Makholm said: No, we just said that license text are sufficiently non-software-like to enjoy an exception. I think the key reason (that licenses are acceptable invariant texts) is that the license text is a legal agreement between _you_ and the _copyright holder_. That is why the license texts must be invariant. But as we've found out now, the part of the GPL that is actually invariant is the preamble, which has no legal content... -- Henning Makholm Nemo enim fere saltat sobrius, nisi forte insanit.
Re: Is documentation different from software [Re: Proposed statement wrt GNU FDL]
On Fri, 25 Apr 2003, Mark Rafn wrote: Could we produce a distinction amongst our offerings in the following manner: Why do we want to produce a distinction where there is none? We obviously disagree on whether there is a distinction. To roast a hoary chestnut, I've not yet seen a good argument why we'd want the RFCs to be relicensed as DFSG-free, apart from the so it can go into Debian main. Oh, that's easy. I wish they were free so I could reuse the good bits in other works, and otherwise improve my world by creating and distributing derived works. I see nothing in the RFC licence which limits you from doing that. Even all rights reserved doesn't limit you from doing that in practice, since you can always make a reference to the other work. But the RFC licence allows you to go further - Section 3 of the general guidelines for copyright of RFCs (as I've just read it from /usr/share/doc/doc-rfc-std/copyright, doc-std-rfc version 20010829-1) states that Copying and distributing portions of an RFC is allowed. Proper credit and citations must be provided. Modifying an RFC and re-releasing it is not a good thing It's exactly as good a thing as modifying Apache and re-releasing it. The modified version is expected to fit someone's needs better than the original. Except that it's typically a lot easier to work out where a program has been incompatibly modified (oops, compile error, damn, the API changed) than a standard has been modified. The use of 'diff' notwithstanding. License texts themselves are a special case. The actual terms of the grant of permission cannot be changed, and can only be encoded in the original wording. That makes perfect sense, and is fundamentally different from a copyrightable work in a definable way. I'll agree with that. Should something along those lines go somewhere definitive so we can point people who say but you can't change the GPL! So that's non-free!. -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: Proposed statement wrt GNU FDL
On Fri, 25 Apr 2003, Glenn Maynard wrote: To roast a hoary chestnut, I've not yet seen a good argument why we'd want the RFCs to be relicensed as DFSG-free, apart from the so it can go into Debian main. Modifying an RFC and re-releasing it is not a good thing, but the DFSG says it is I suppose this is opportunity to say that this begs the question. :) Being able to modify an RFC and re-release it is absolutely a good thing. Why should I have to start from scratch when writing a new spec that resembles an older one? Why shouldn't I be able to reuse parts of other RFCs? RFC authors do it all the time, by issuing updates to existing RFC documents. They say Do it like this, except for this, this, and this. Since software is not written in English, we can't exactly use the same methodology as an RFC to write new versions of our software (unless we take this to be the human language equivalent of a patch). Hmm, that suggests that all documentation which can be redistributed is DFSG free... grin -- --- #include disclaimer.h Matthew Palmer, Geek In Residence http://ieee.uow.edu.au/~mjp16
Re: Proposed statement wrt GNU FDL
On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: -- would you prefer that they hadn't seconded the proposal either? We could have had a nicely silent majority. I don't really see much value in me too posts. We build consensus by responding to criticism, and there hasn't been *any* internal criticism of this stand since last November, when Branden found the FSF's responses to the issues he and others had brought to the FSF's attention. Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) (Section I, 'Preserve the section entitled History', is also a candidate for this list.) Is it? I couldn't see how it was much different to the GPL's You must cause the modified files to carry prominent notices stating that you changed the files. I suppose having a History section like: 2003-05-01 Title: _GNU Manifesto_ Debian (Extracted the GNU Manifesto from the GDB docs) 2003-04-28 Title: _GDB Documentation_ FSF 2003-04-12 Title: _GDB Documentation_ Debian 2003-04-11 Title: _GDB Documentation_ FSF 2003-04-01 Title: _GDB Documentation_ Debian 2003-03-20 Title: _GDB Documentation_ FSF could get tiresome. Does that make it non-free, though? I can't see any reason why it should. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. 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. I'd rather list them all in a comprehensive FAQ, and keep the statement short and to the point -- if we're going to make statements on non-free licenses that're commonly called and thought of as free, fair enough; making statements about every seriously flawed license out there would seem like a lot of effort. I'm happy to be shouted down, though. [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? http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00225.html In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' A stronger argument can be made that not only is it easy to misapply, but that it's harmful even when correctly applied: the wikipedia example of the addition of invariant backlinks making the modifications unusable for the original author; and the hypothetical example of random people who don't have RMS's credibility attaching their own manifestos to free software documentation as some weird unerasable graffiti are both convincing to me. Are they convincing to anyone else? If so, would someone else who's convinced like to pen a FAQ paragraph about it? Are there any other examples? Updated statement draft, and a draft FAQ attached, that should cover all your comments that I didn't address in this mail. 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!'' Debian's stance on the GNU Free Documentation License (2) ...OR NOT (completely unofficial, draft, blahblah) 24th April, 2003 In November 2002, 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, which apply to all modified versions, that disallow modifications. In particular, these are: * 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
Re: Proposed statement wrt GNU FDL
On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote: One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. Before someone schedules a MOAB test over my home, note that I am not advocating this course, merely that it should be mentioned and refuted. If we don't do this, someone, somewhere is going to make the jump, and proceed to pester the Project to death with questions about why we don't just modify that pesky ol' DFSG and solve the problem that way. I think Why are Unmodifiable Sections a Problem? in the proposed FAQ I just posted in reply to Richard's message covers this. Could you have a look at it to see if you agree? 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!'' pgpUJtGGLtzmF.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, 24 Apr 2003, Anthony Towns wrote: On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote: One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. I think Why are Unmodifiable Sections a Problem? in the proposed FAQ I just posted in reply to Richard's message covers this. Could you have a look at it to see if you agree? I agree with what's expressed in the FAQ, but apart from the section on why we think software and documentation should be treated equally under the DFSG (quite a good argument there, BTW) there's nothing there about why we can't as a project, for instance, just relax the rules of the DFSG generally. After all, we bump up against non-freeisms regularly (hence non-free), people are going to ask why can't you make an exception in the DFSG for this. Even if it's just something as simple as: Why can't the DFSG be modified to accomodate the restrictions imposed by the FDL? After all, RMS endorses it, so why shouldn't you? The Debian Free Software Guidelines, combined with the Social Contract, are the basic tenets by which Debian is guided. The DFSG has stood well with both Debian Developers and the Free Software community for some time, and is widely regarded as the canonical statement of what makes free software Free (the Open Source Definition [I think] was based on the DFSG). As such, changing the DFSG would be widely seen as a major compromise of the principles the Debian project was founded on, and continues to be based on today, as well as a key definition of what it means for software to be Free. On a more practical note, changing the DFSG requires a General Resolution of Debian Developers, a large logistical task and not one which should be undertaken lightly. ---[END]--- OK, so maybe it wasn't quite so simple after all. I'm not putting that up as the canonical form of the QA, but it reinforces to me why the GFDL needs fixing, and not us. - Matt
Re: Proposed statement wrt GNU FDL
Matthew Palmer [EMAIL PROTECTED] writes: Why can't the DFSG be modified to accomodate the restrictions imposed by the FDL? After all, RMS endorses it, so why shouldn't you? The Debian Free Software Guidelines, combined with the Social Contract, are the basic tenets by which Debian is guided. The DFSG has stood well with both Debian Developers and the Free Software community for some time, and is widely regarded as the canonical statement of what makes free software Free (the Open Source Definition [I think] was based on the DFSG). As such, changing the DFSG would be widely seen as a major compromise of the principles the Debian project was founded on, and continues to be based on today, as well as a key definition of what it means for software to be Free. On a more practical note, changing the DFSG requires a General Resolution of Debian Developers, a large logistical task and not one which should be undertaken lightly. ---[END]--- OK, so maybe it wasn't quite so simple after all. I'm not putting that up as the canonical form of the QA, but it reinforces to me why the GFDL needs fixing, and not us. This says to me It's hard to change the DFSG, and the DFSG is respected. Neither of those seems like a good reason for the GFDL to change. I think your argument could be much stronger if it included a because we're right paragraph. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. At the same time, I see no value in making cover sections, etc. of manuals invariant. Any thoughts on that?
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 08:27:19AM -0500, John Goerzen wrote: On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. The FAQ says: ] What About Unmodifiable Software Licenses Like the GNU GPL? ] ]Many software licenses unfortunately disallow the creation ofderivative ]works. The FSF give everyone permission to distribute verbatim ]copies of the GPL, eg, but do not give you permission to take the ]text of the GPL and change section (2(c)) to something you prefer, ]and license your own works under this new GPL-based license. This, ]clearly, does not pass the DFSG. ] ]Debian does not generally apply the DFSG to the text of licenses ]themselves, but rather to the software (programs, documentation, ]artwork) they cover. In the past, Debian has similarly overlooked ]applying the DFSG to documentation, but with the increasing focus on ]providing good free documentation, this no longer seems appropriate. Which doesn't really answer the question. The real answer is that: (a) There's never any point making these things unmodifiable. Deriving a new license that uses some parts of the GPL doesn't change the license of old works, and isn't dangerous in any way -- it merely makes it easier to write new license. Likewise for programs, documentation, and anything else. (b) We can't require freely modifiable licenses -- too much useful free software is covered by unmodifiable licenses. But conversely, this isn't something that can or should be extended: licenses aren't relevant to most users -- software and documentation is, and it's the users we're trying to protect here. Likewise, the line between software licenses, and documentation in general is much clearer than the line between documentation and software. Additionally, we're only required to give people a copy of the license, which is a much weaker requirement than including the complete text of the license in every binary we distribute. As such, we're happy to make a special exemption for licenses, that we're not willing to make for documentation in general. That might make more sense. 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!'' pgp996Sh83bJ7.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: Debian's stance on the GNU Free Documentation License ...OR NOT (completely unofficial, draft, blahblah) (Section I, 'Preserve the section entitled History', is also a candidate for this list.) Is it? I couldn't see how it was much different to the GPL's You must cause the modified files to carry prominent notices stating that you changed the files. I suppose having a History section like: 2003-05-01 Title: _GNU Manifesto_ Debian (Extracted the GNU Manifesto from the GDB docs) 2003-04-28 Title: _GDB Documentation_ FSF 2003-04-12 Title: _GDB Documentation_ Debian 2003-04-11 Title: _GDB Documentation_ FSF 2003-04-01 Title: _GDB Documentation_ Debian 2003-03-20 Title: _GDB Documentation_ FSF could get tiresome. Does that make it non-free, though? I can't see any reason why it should. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. The differences between the GPL's requirements and the GFDL's requirements are in where the required sections must be placed: the GPL, as you've noted elsewhere, usually makes special requirements only of the source, and then requires that the source be available. The GFDL tends to make requirements of all forms of the document. More importantly, for both the front cover texts and the history section, the GPL does not require its changelog be in the source file itself; it is enough to accompany the work with a separate changelog file. The GFDL's requirement that the History section be part of the work itself makes it unusable for a wide class of documents and formats, including video, audio, and static images. In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' How can the sample GDB Session possibly be a Secondary Section? Or is this just a good example of how confusing the Invariant Section rules can be, even to the FSF? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 08:27:19AM -0500, John Goerzen wrote: On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote: In particular: for emacs21, ``with the Invariant Sections being The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE'', and for gdb ``with the Invariant Sections being A Sample GDB Session and Free Software'' and ``with the Invariant Sections being Stabs Types and Stabs Sections'' While in general I must say that I agree with Branden on this issue, I'm not yet completely convinced, and one reason was brought home to me by the above: I large majority of our software ships with the file COPYING, which states changing it is not allowed. Combined with the requirement in section 1 that the GPL be given to any recipients of the program, this strikes me as similar to the invariant section. It leaves me wondering if we are being a bit hyopcritical about it. At the same time, I see no value in making cover sections, etc. of manuals invariant. Any thoughts on that? It seems that we have an implicit exception that legal statements about a work about allowed to be non-free. That seems to be quite reasonable since tampering with copyright statements is not allowed in many countries, and also since many licenses are also non-free. I don't mind works where it is manditory to reproduce: Copyright (C) 2003 J. R. Hacker. This manual is free documentation; yada yada yada. You should have received a copy of the license along with this manual; if not, write to Fubar, Inc. 123 Sesame St, New York, NY 10023, USA. There is ample precedent for putting these little notices on all sorts of things, typically in fine print. Look, I even have a serviette on my desk that says (C) 2003 DOCTOR'S ASSOCIATES INC. All rights reserved. Simon
Re: Proposed statement wrt GNU FDL
Scripsit Anthony Towns aj@azure.humbug.org.au On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote: -- would you prefer that they hadn't seconded the proposal either? We could have had a nicely silent majority. I don't really see much value in me too posts. We build consensus by responding to criticism, Me-too posts are a way of observing consensus. One rant (advocating a possibly controversial course of action leading straight into major flamewar territory) followed by complete silence does not establish a consensus. It merely eastablishes apathy. A rant followed by a handful of me-toos and still no criticism voiced allows consensus to be observed. Of course, a rant followed by constructive discussion about how to implement the proposal in practise is even better, and once that ball gets rolling, me-toos are superfluous. and there hasn't been *any* internal criticism of this stand since last November, True, we knew we had a consensus that we don't like the GFDL and find it lacking with respect to the DFSG if any of its options are exercised. But we didn't previously have a clear consensus on turning that feeling into action, and when the action is as momentous as that lurking in horizon, I think Branden was right in not assuming that consensus of assessment would automatically imply consensus on action. We seem now to have the latter, which is good. There's been some question whether the front-cover texts are DFSG free. Considering we accept the obnoxious advertising clause, I can't see any reason for them not to be. Perhaps the O.A.C. ought to be our next target, but let us fight one battle at a time. We do not accept the O.A.C. because we like it, but because of the logistic problems of tracking down the well-meaning but misguided authors who used it because it was in the template they were following. That situation is unstable and marginally acceptable only because there are probably none of those authors who actually care to enforce it. On the other hand, we have to assume that the FSF really mean what they write in a brand new license, the drafts of which whey have solicited and received extensive responses from the community. the hypothetical example of random people who don't have RMS's credibility attaching their own manifestos to free software documentation as some weird unerasable graffiti are both convincing to me. Are they convincing to anyone else? While we should definitely include the hijacking example, some care should be exercised in phrasing an explanation of what we think it proves. In particular it should be very clear that we do not claim that the possibility of hijacking in itself contributes to DFSG-nonfreedom. (For example, BSD-licensed software and documention can be hijacked too). On the other hand, the hijacking scenario does help explain why we're mystified to see the FSF backing the license as a copyleft. The Problem ~~~ The GNU FDL includes a number of conditions, which apply to all modified versions, that disallow modifications. In particular, these are: [K and] * 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: I think it would be good to emphasize more in the central section that it is the stickyness rather than the rigidity of Invariant Sections that bugs us. How about something like this after the DFSG quote: In particular, the DFSG requires that it must be legal to derive a new work by the particular modification that consists of removing one or more Invariant Sections. But this is expressly disallowed by condition L of the GFDL. If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. If necessary, the Debian maintainer could himself remove the Invariant Sections, but in most cases where the license were not obviously abused or misapplied, we would still be able to include the original unmodified documentation based on a case-by-case review of the relevance and technical importance of the Invariant Section. (See the attached FAQ, question XYZ for discussion). Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto be included in the Debian GNU/Linux Distribution anyway? I propose expanding this question to: Why does Debian want to remove (say) the GNU Manifesto from the manuals? Do you want to suppress Stallman's views and just benefit from the software he created? The question is one we often hear, but its phrasing betrays a misunderstanding. Debian does not want to remove the GNU Manifesto from the packaged GNU manuals that we distribute. On
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: The real answer is that: (a) There's never any point making these things unmodifiable. Deriving a new license that uses some parts of the GPL doesn't change the license of old works, and isn't dangerous in any way -- it merely makes it easier to write new license. Likewise for programs, documentation, and anything else. It is dangerous, as it leads to confusion: a document which looks much like the GPL, except for one small section, might not be noticed. However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. If Debian's going to eventually remove invariant sections, it's possible that the included copy of the GPL should have those sections removed as well. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 06:34:08PM +0200, Henning Makholm wrote: If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. We can distribute GNU FDL'ed docs as is -- they simply have to not include any invariant sections. I don't think it makes sense to include invariant sections ever -- whether they can be removed by others or not. We wouldn't accept anything that is entirely invariant as being DFSG-free -- so it doesn't make sense to accept books with chapters that're invariant as DFSG-free. If we are willing to accept invariant chapters in DFSG-free documentation, I don't see how we could possibly claim the GNU FDL is not DFSG-free. Merely being able to delete something doesn't make it free -- I can delete MS Office easily enough, eg. In short, I don't think that's a justifiable position. What we do want is for our *users* to be allowed to remove the GNU Manifesto from the manual if they can think of a reason to do so. No -- we want our users to be able to take everything we give them, and be able to build on any part of it they might choose, with few exceptions. If only we could be sure that the license on the manuals would allow a user who thinks that because! is reason enough for him, to remove the GNU Manifesto, we probably could still distribute the unmidified manuals with the Invariant Section in it. That would mean that part of what we distribute (namely the Invariant Section itself) would not, strictly speaking, be modifyable, but exceptions can be made for things that are both sufficiently non-software-like not to need modifyability for technical reasons and sufficienly relevant not to just constitute a waste of space in the distribution. Didn't we just say we're not making exceptions for things that are sufficiently non-software-like? Of course both of these limits are judgement calls, and each particular Invariant-But-Removable section will have to be considered on a case-by-case basis. And further, as a practical matter, it's not reasonable for us to be making judgement calls on every random piece of documentation that gets uploaded. Just analysing the random licenses people come up with is hard enough, trying to work out if some rant is valuable while another isn't isn't sensible. If we're going to make an exception for the GNU Manifesto -- and I think we should -- let's be clear and deliberate about how we do it. Let's note that it's completely non-free, and collect it, and any other defining documents we might want to make similar exceptions for, and put them in doc-debian with our own manifest and social contract, rather than scattered through various manuals. That also forms a good way of judging whether random rants are valuable enough: if they're important enough to go in doc-debian, they're important enough to waive the DFSG. 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!'' pgpHxlebuCBAZ.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 12:22:27PM -0400, Brian T. Sniffen wrote: However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. What makes you think this is the case? 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!'' pgp0baUyO0zbg.pgp Description: PGP signature
Re: Proposed statement wrt GNU FDL
On Thu, Apr 24, 2003 at 06:34:08PM +0200, Henning Makholm wrote: If the rule had, instead been, that Invariant Sections could not themselves be modified, but could freely be omitted entirely in derived works, Debian would be able to distribute GDFL'ed documentation. On Fri, 25 Apr 2003, Anthony Towns wrote: We can distribute GNU FDL'ed docs as is -- they simply have to not include any invariant sections. I don't think it makes sense to include invariant sections ever -- whether they can be removed by others or not. We wouldn't accept anything that is entirely invariant as being DFSG-free -- so it doesn't make sense to accept books with chapters that're invariant as DFSG-free. A GFDL document with no unmodifiable portions is free, but can be hijacked by someone later adding an invariant section. A GFDL document with non-removable non-modifiable sections is non-free. A document with non-modifiable removable sections (I don't think the GFDL has any provision for this, I'm including it just for completeness) is not free itself, but the portion of the document which is modifiable can be made free by removing the non-modifiable sections. The fourth case (modifiable non-removable sections) is irrelevant, as one possible modification is removal. If we are willing to accept invariant chapters in DFSG-free documentation, I don't see how we could possibly claim the GNU FDL is not DFSG-free. Merely being able to delete something doesn't make it free -- I can delete MS Office easily enough, eg. Right. The ability to remove it only preserves the freedom of the attached work, not the unmodifiable portion itself. If we're going to make an exception for the GNU Manifesto -- and I think we should -- let's be clear and deliberate about how we do it. Let's note that it's completely non-free, and collect it, and any other defining documents we might want to make similar exceptions for, and put them in doc-debian with our own manifest and social contract, rather than scattered through various manuals. Or better yet, put anything that's not freely modifiable (including the Social Contract and GNU Manifesto) in non-free, and work toward making them free. Claiming that documents which do not allow derived works can still be part of Debian is arrogant, hypocritical, and simply wrong. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Proposed statement wrt GNU FDL
Henning Makholm said: Perhaps the O.A.C. ought to be our next target, but let us fight one battle at a time. EXPN O.A.C.? (snip) While we should definitely include the hijacking example, some care should be exercised in phrasing an explanation of what we think it proves. In particular it should be very clear that we do not claim that the possibility of hijacking in itself contributes to DFSG-nonfreedom. (For example, BSD-licensed software and documention can be hijacked too). On the other hand, the hijacking scenario does help explain why we're mystified to see the FSF backing the license as a copyleft. Giving particular attention to the fact that the hijacking entity can use the Invariant sections to prevent returning thier improvements to the commons. Example: SomeCo writes a user-friendly GNUware manual based in part on the GNUware Manual (which is GFDL-licensed, so the SomeCo GNUware Manual must be GFDL also). The SomeCo GNUware Manual has lots of useful information in it, which the GNUware authors would like to incorporate. Unfortunately, SomeCo included an invariant section which describes the company and offers investment opportunities, and also the CEO's rant about how all software should be proprietary (and licensed from SomeCo). The original authors can not incorporate SomeCo's improvements without including the company's advertisement, or appearing to endorse the CEO's confused views. --Joe
Re: Proposed statement wrt GNU FDL
Anthony Towns aj@azure.humbug.org.au writes: On Thu, Apr 24, 2003 at 12:22:27PM -0400, Brian T. Sniffen wrote: However, the legal text of the GPL is reusable (allowing modification and distribution), as long as you don't include the name GPL, the Preamble, or the instructions for use. What makes you think this is the case? http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL Can I modify the GPL and make a modified license? You can use the GPL terms (possibly modified) in another license provided that you call your license by another name and do not include the GPL preamble, and provided you modify the instructions-for-use at the end enough to make it clearly different in wording and not mention GNU (though the actual procedure you describe may be similar). and more on why not to -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Proposed statement wrt GNU FDL
Anthony Towns wrote: 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. It may be worth noting that GNU manuals are hardly the only thing effected by the emerging consensus on treatment of document licenses. The RFC's are moving to non-free already as they cannot be modified, emacs contains a number of documents in its etc directory (WHY-FREE, PROJECT, INTERVIEW, CENSORSHIP, etc, etc) that cannot be modified. There are probably quite a few more examples. 2) Use an alternative copyleft license for your document. The GNU General Public License is a good license for documentation as well as software. It requires anyone who would want to do a print run of your documentation to either include a CD of the text with the book so anyone can modify it, or to include an offer to send copies to anyone who asks at cost; and also requires the modifiable copy to be in whichever transparent form was used to create the book originally. 3) Use a non-copyleft free license for your document. Example licenses include the FreeBSD Documentation License, and common software licenses such as the X11 license, or the updated BSD license. 4) Convince the FSF to change the GNU FDL to allow the removal of unmodifiable sections. While this does not prevent documents covered by the GNU FDL being non-free by Debian's definition of the term, it allows us to remove the non-free components (that by definition are irrelevant to the document), leaving simply the DFSG-free manual itself. It might be good to point to another license written explicitly with non-code in mind. What about the license used on the Debian web site? What About Unmodifiable Software Licenses Like the GNU GPL? Many software licenses unfortunately disallow the creation ofderivative works. The FSF give everyone permission to distribute verbatim copies of the GPL, eg, but do not give you permission to take the text of the GPL and change section (2(c)) to something you prefer, and license your own works under this new GPL-based license. This, clearly, does not pass the DFSG. Apparently they do allow it, according to Brian T. Sniffen who points out http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL If the license portion of the GPL can indeed be reused and modified then it is a bad example to use here. Or at least the reference to section 2c is a bad example. Debian does not generally apply the DFSG to the text of licenses themselves, but rather to the software (programs, documentation, artwork) they cover. In the past, Debian has similarly overlooked applying the DFSG to documentation, but with the increasing focus on providing good free documentation, this no longer seems appropriate. It might be worth noting that Debian historically did not apply the DFSG to software either (well, there was no DFSG), and had a large amount of non-free software in the distribution, and that applying a strict standard to the software we ship has led to a lot of software becoming free, and has not hurt the distribution or our users in any way. We hope applying these standards to documentation will have similar positive effects. I think this is mostly implicit in your answer, but many people will not know the history. Beyond allowing invariant sections, why does the GNU FDL suck? A little peice of me wonders if why does the GNU FDL suck is politic even in a FAQ, but whatever. 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.]) Has anyone figured out what you have to do to print a FDL licensed work as part of a collection like a magazine? I'm thinking particularly of my Linux Journals which always seem to arrive with a giant honking mailing lable right over the title of the two articles I'm most interested in. It would be very amusing if the placement of a label could violate a copyright. Languages other than English are poorly supported The GNU FDL defines special roles for several kinds of sections (such as History and Dedications), but refers to these sections by their names in English. A document under the GNU FDL will have to include a section with the title History, regardless of the language it's written in. I think if I were an author and was worried about this, I would quickly
Re: Proposed statement wrt GNU FDL
Hi Matthew and all,
On Thursday 24 April 2003 13:21, Matthew Palmer wrote:
I agree with what's expressed in the FAQ, but apart from the
section on why we think software and documentation should be
treated equally under the DFSG (quite a good argument there,
BTW) there's nothing there about why we can't as a project,
for instance, just relax the rules of the DFSG generally.
As a Debian user, I am glad that there is this set of rules --
namely the DFSG -- that strictly followed, help keeping Debian
100 % free software. I hope that these rules will not be
softened, so that in the end, Debian becomes a second SuSE.
I am also glad that the Debian project treats all different
sorts of content the same way, as I am very enthusiastic about
the idea of a transition of the principles of free software
towards other areas. The FSF has quite disappointed me in this
regard, as they not only deny the leadership of a general
free-everything-movement, but also discourage people from being
consequent by giving them a bad example. For me, this is another
reason why Debian should keep its rules as they are, and
continue to apply them consequently.
On the other hand, the DFSGly non-free docs that are about to be
thrown out of main are at least as freely distributable as any
other package in main. This is a quality that many packages in
non-free do not share with them. As I don't have non-free in my
apt/sources.list, from my point of view, moving these docs to
the 'non-free' section would practically mean the same thing as
moving them to the trash dump. I guess this step would be far
too radical.
Also, it seems to be more difficult to write and test
documentation than software, as it works on human beings, not
machines. Further, there still is too few good documentation.
This makes me think that trashing freely distributable
documentation would not be wise.
So, now I'm repeating an idea that I alredy mentioned here,
after selfhtml had been kicked:
* Create a section 'distributable' that is between main and
non-free, for stuff that is not free WRT modification,
availability of the source code etc., but at least freely
distributable in any medium, by anybody, for any price.
* Therefore, create a subset of the GFDL (a 'relaxed' GFDL)
which regulates what can go in there and what not, but not as
a replacement of the current GFDL, but rather a different set
of rules for a different purpose.
I think this would be a good compromise for those people who
want non-free docs out of main, and those who don't want them
trown onto the 'non-free' trash dump, and those who want both.
cu,
Thomas
}:o{#
Re: Proposed statement wrt GNU FDL
On Fri, Apr 25, 2003 at 04:57:36AM +0200, Thomas Uwe Gruettmueller wrote: On the other hand, the DFSGly non-free docs that are about to be thrown out of main are at least as freely distributable as any other package in main. This is a quality that many packages in non-free do not share with them. There's lots of software in non-free that is freely distributable, but non-free for other reasons, such as limitations on commercial use. Non- free things should go in non-free, even if there's a lack of free equivalents. As I don't have non-free in my apt/sources.list, from my point of view, moving these docs to the 'non-free' section would practically mean the same thing as moving them to the trash dump. I guess this step would be far too radical. Requiring you to add a line or two to sources.list isn't trashing anything. If this is a radical move, I'd say the earlier one of moving non-free software to non-free was an order of magnitude more radical. So, now I'm repeating an idea that I alredy mentioned here, after selfhtml had been kicked: * Create a section 'distributable' that is between main and non-free, for stuff that is not free WRT modification, availability of the source code etc., but at least freely distributable in any medium, by anybody, for any price. Distributors can already do this. I don't think Debian should be expending time categorizing non-free into non-free and really non-free; let people who would actually use the distinction (distributors) spend the time. (It'd be a fair bit of time, requiring further analysis of clearly non-free licenses.) -- Glenn Maynard
Re: Proposed statement wrt GNU FDL
On Sat, 19 Apr 2003, Anthony Towns wrote: The Solution There are a number of things that can be done to avoid this problem. One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. Before someone schedules a MOAB test over my home, note that I am not advocating this course, merely that it should be mentioned and refuted. If we don't do this, someone, somewhere is going to make the jump, and proceed to pester the Project to death with questions about why we don't just modify that pesky ol' DFSG and solve the problem that way. - Matt
Re: Proposed statement wrt GNU FDL
On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote: One which isn't mentioned there is to amend the DFSG to allow the FDL and similar licences. Before someone schedules a MOAB test over my home, note that I am not advocating this course, merely that it should be mentioned and refuted. If we don't do this, someone, somewhere is going to make the jump, and proceed to pester the Project to death with questions about why we don't just modify that pesky ol' DFSG and solve the problem that way. Sure, it's certainly worth addressing this point in the FAQ. It's a question that we're likely going to hear time and again: Why should the FSF have to change? Why don't *you* change? -- G. Branden Robinson| It's not a matter of alienating Debian GNU/Linux | authors. They have every right to [EMAIL PROTECTED] | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders pgplvJjUyomV4.pgp Description: PGP signature
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
