On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote: > On Tue, Jan 04, 2005 at 10:28:29PM -0500, Glenn Maynard wrote: > > On Wed, Jan 05, 2005 at 02:11:03PM +1100, Craig Sanders wrote: > > > [ ... referencing earlier docs ... ] > > > > Sometimes this is a good approach, sometime it isn't. It certainly isn't > > good to do this for several generations of protocols, so a reader would > > have to understand a chain of several protocols, each described as a > > plain-English diff against the previous. Whether to modify the document > > directly or to explain as a set of changes should be up to the person > > creating a new standard, not set in stone by the license in an overly- > > broad attempt at preventing confusion. > > sorry, but that argument is bogus. convenience is NOT the same as freedom. > more to the point, freedom does not require convenience. Convenience and freedom are not the same, but they are related. You have the freedom to write a program which operates in a manner exactly the same as acroreader, but without some irritating bug (choose whichever one you like). It would be far more convenient if you had the source to acroread to make simply the bugfix you require, but freedom does not require convenience. So acroread is Free. Cool. > personally, i think that: > > a) the utility value of RFCs and similar technical documentation, > > combined with > > b) the fact that there is an established procedure for amending RFCs and > creating new ones which is *open to all*, > > AND > > c) the fact that very few people (far less than one in a million readers) will > ever have any desire to modify them, > > is more than sufficient reason to be a bit more tolerant about freedom > criteria for documents. > > in short, it doesn't make any practical *OR* ethical difference so it doesn't > matter in the slightest. I don't see much of a case at all for "no practical difference" in what you wrote above. The only form of "amendment" that can be made is to reissue a newly written RFC saying "this previous one is wrong", but your new RFC cannot be a derived work of the superceded one. That's a real practical difference to me. > ps: the GPL itself is non-free. you're not allowed to modify it, so it is > non-free. it must therefore be discarded from debian (or moved to non-free). > furthermore, since GPL-licensed software requires that the license be > distributed with the software, and we are unable to meet that requirement, all > GPL-licensed software must likewise be discarded from debian. > > please explain why we should be willing to make an exception for the GPL text, > but not for other texts. Ghods, not this one again. The GPL, as a text of it's own, would most certainly fail the DFSG. We only include the GPL as a description of the terms under which much of the software in Debian is distributed, which is very, very inviolable -- the moment you start trying to modify the licence terms of a piece of software without the permission of the copyright holder, you're deep in "do not pass go, do not collect $200" territory. - Matt
Attachment:
signature.asc
Description: Digital signature