On Sun, Jul 13, 2003 at 05:11:30PM -0500, Adam Heath wrote: > On Sun, 13 Jul 2003, Martin Quinson wrote: > > 1. RFC are not software but standards. > > > > Answer 1: What is a software, then? It's impossible to establish a clear > > definition of that (Perl interpreting scripts is not clearly different > > from mozilla or php processing an html document). > > Answer 2: Ok, that's not software. But it should remain free anyway to > > make its way to main (non-free non-software is not equivalent to free > > software) > > Answer 3: If they are not software, they don't belong to Debian (one > > interpretation of "Debian will remain 100% free software") > So, if we add non-free documention, debian will *still* be 100% free software. So packages in Debian main which contain documentation are not part of Debian? Where, then, are the boundaries of what "Debian" is? Debian can only be 100% Free Software if 100% of everything in Debian is both free, and software. If either of these criteria are not met, you might be able to make many other claims about it -- "Debian is made from 100% all natural Florida free software juice", perhaps -- but not that it *is* 100% Free Software. > > 2. Standards gain their value from their rigid rigid procedure for updates > > and modifications. > > or: > > Who needs to edit the RFCs by the way? > > or: > > Keep cool, IETF are good guys, sharing some goals with us. > > > > Answer 2: As long as the IETF is a good willing institution, that's fine, > > but what will happen in 10 years? If they disapear, we need the *right* > > to modify the existing RFCs to create new ones, and fork the > > standardisation process. > > This is not very different forking gcc: in both cases it's generally a > > bad idea, but the health of a free system depends on it being > > potentially possible. > Er, hasn't it always been that you never modify an RFC, but just create a new > one, that subsumes the old? There are countless cases of this already(DNS > being a prime example). And a license that meets the IETF's needs for modifiability is all we need to allow inclusion in Debian? So for software, we use the DFSG; but for documentation, we do whatever works for the IETF. This is not, and never has been, about whether the IETF's current licensing scheme works well for standards development. It's about whether this licensing scheme grants sufficient freedom for these documents to be included in Debian. Every single argument in support of shipping the RFCs with our operating system could be applied just as well to the question of shipping Netscape 4 in Debian (in years past), or qmail, or any number of other /useful/, or /common/ pieces of software, or software written by beings of goodwill. If these reasons are not sufficient to merit overriding the DFSG for software, why are they sufficient where documentation is concerned? Perhaps there's an implicit belief that software is more difficult to reimplement than prose is, and that the freedom to modify is therefore more important for programs. One wonders what someone holding such a belief would offer as an explanation for the large number of programs in Debian that still don't have manpages... > > Answer 3: If I want to document a program following quite well a given > > RFC, but not completely, it's easier for me to edit the RFC file (and > > rename it of course) than paraphrasing it. If I'm not allowed to do > > this edit, I'll probably never document those changes, which is a loss > > for the users. > > Same thing for comments in code explaining which part of the RFC > > constraints some design decision. > Why would you need to edit and rfc to say that your program doesn't follow it? To publish a divergent spec, one which the IETF will never endorse, which this program does follow; so that others can implement it as well. The freedom to fork is fundamental to Free Software. -- Steve Langasek postmodern programmer
Attachment:
pgpszgzpq57x2.pgp
Description: PGP signature