the RFC mess: tentative summary
Ok, people. Even if I'm not native speaker, I'll now try to sum up the
flamewar we just had about the RFC licencing. Don't get me wrong here. In
fact I personnaly have no fixed opinion about this. I just want to be able
to fix the tons of RC bugs involved by this issue, close them, get other
bugs do the same, see Sarge released before mid-2004 and drink a bier to
celebrate. Please be patient with me and correct me if I'm wrong.
This is all about one of the oldest RC bug in debian, the infamous #92810.
The issue here is that the RFC licence (at least for the modern ones) is
clearly non free. For some people, that's a reason to throw this out of
main, for some other, RFCs can stay in main for several reasons.
I belive that the discussion showed that the status-quo (ie, RFC being in
main without being free) cannot stay as is. Here are first the arguments
proposed by people for this status-quo and their refutation proposed by
others.
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")
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 1: Nobody asked the right to change the content of the file
RFC23423.txt and distribute it as is. This would clearly be wrong and
it would be ok to ask for a file rename, for a clear notice changes
between the original version and the distributed one, and so on.
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.
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.
Answer 4: "Ceci n'est pas une RFC". The file containing the standard is
not the standard itself. Sure I won't change the standard. But I may
want to use bits of the standard if I want (see also argument 6).
3. It serves our users (no need to download)
or
Banning RFCs from Debian is just silly.
Answer 1: Serving our users is not a sufficient reason. It would help a lot
of people to have a complete implementation of java in main, but since
there is no free implementation, that's currently impossible.
Answer 2: If anyone but the IETF wanted to get something under such
licence in Debian main, nobody would agree. We have to be consistent
with ourselves. Netscape and acrobate did get banned.
See also answer 2.3.
4. It would be arrogant to ask IETF to change its licence to fit our views.
Answer 1: So far, we just discussed about moving it to non-free.
Answer 2: Some people belive that the intention of the licence is good
(authors intended the RFCs to be freely usable, but also trustable, ie
that a file claiming to be the RFC1253215 is actually the version
endorsed by IETF), but the wording is wrong and makes it non-free.
Answer 3: We asked a loooot of stuff around to *clarify* their licence.
5. ISOC is not granted an exclusive copyright license, and even if they
wanted, they cannot relicence the file.
Answer 1: People wanting to include a perticular RFC in a free packages
can contact the RFC authors directly to manage this.
Answer 2: ISOC could change the licence terms for future RFCs.
6. There is a "fair use" provision.
Answer 1: "fair use" provisions are not legally appliable everywhere in
the world (UK only have a more limited concept called "fair dealing").
See also answer 2.2
That's the main arguments I've seen. As in any flamewar, some "not so
fundamental and related" arguments were also given:
7. There is a tons of other craps in main which should be removed.
Answer 1: Fine, let's remove them
Answer 2: Package foo have a RC bug. I can have one in my package,
too. Boo.
8. Moving more stuff from main to non-free will make more difficult to
remove non-free from our servers.
Answer: commitment to distribute free material is far more important.
(and that's a complete other topic)
9. We need a Debian Free Documentation Guidelines
Answer: That's underway (but that's another topic I won't detail here)
10. There is no need for documentation to be free
Answer: If you adapt the code and cannot adapt the documentation to
reflect the changes, you'll get into trouble.
(but that's more related to the GDL. One flamewar after the other, please)
Arguments against the status-quo:
1. "Social Contract" with the Free Software Community:
Debian Will Remain 100% Free Software
2. Moving stuff to non-free is not an insult. Quoting Branden Robinson:
How *dare* we *condemn* the *great work* of the IETF so!
Except we're not condemning it at all. The DFSG provides us with a
series of tests that help us determine whether something is Free as in
Freedom. RFCs under the "new license" clearly are not. Big deal.
Plenty of enjoyable things in life aren't Free as in Freedom.
Answer: packages in non-free are second class package, not distributed
by vendors, not dbuilded and so on.
There was even a proposition of an acceptable licence for [future] RFCs:
You are free to distribute this RFC. You are free to modify the RFC and
redistribute your modifications provided it is clearly marked as bein a
modified version and NOT endorsed by IETF (perhaps forcing a rename also).
So, if I'm right, here we are. #92810 is apparently fixed since doc-rfc
package recently moved to non-free, but the issue survived this bug, since a
lot of other package in main contain the RFCs related to their subject. If
you permit[*], I would like to conclude with some proposals for the future:
- Short term:
All not-free-enough (ie, not-old-enough) RFCs should be removed from
main. I guess that now that doc-rfc is installable, usable and so on,
this issue will get less problematic.
- Mid term:
Maybe a resplit of the packages (so that users can really get only the
ones they want and not xMo of useless cruft) installed would help even
further for that. I did look at that during the time where the package
was not maintained, and cam up with another split. But I didn't have
the time to discuss of it with the maintainer, and I'm really not sure
he wants to collaborate with me. Why so is another question...
Another way could be to package a tool to get only the RFC you wants from
the net. Jfs did found such package, that's ITP #199692, but this
script is very non-free (even if I oversaw it at the first glance,
shame on me), and I still wait for an answer from upstream for a
licence clarification.
- Long term:
After such a flamewar on debian-devel, someone *ought* to contact the
RFC editors. My opinion is that all this story is based on a
misunderstanding. In fact the "some people" from answer 4.2 seem to be
only me :) I may be wrong, but as long as nobody steps to contact
those guys, we will never know.
And, no, *I* won't do that. It was risked enough for me (as non-native
english speaker) to try to sumarize this thread.
Please someone, do something.
That's it, guys. Let's try to find solutions, not discuss again and again.
[*]: But I guess I could allow myself to do so, since I already used "we" a
lot in this document even if I'm not DD yet :)
--
The "US department of defense" should be renamed the "US department of
attack".
Reply to: