On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote:
We do have precedent for include code that has explicit open source
licensing rights. For example, the MD5 implementation in RFC 1321 has
an explicit BSD-style license.
Sure, but under the post-RFC 2026 rules that would not be allowed since
the rules do not permit additional copyright notices to be present in
documents. There has been exceptions and mistakes, so there are
post-RFC 2026 documents with other licensing information in them, but
the IESG/IAB has also rejected including free software code in RFCs.
Allowing BSD-like code to be included in RFCs would be great step
forward. It is not allowed under the RFC 5378 license either, at least
not generally when the code was not written by the document author.
This should clearly be fixed in RFC 5378-bis, in my opinion. If the
goal is to allow code to be allowed in Open Source Software, then
requiring a maximally compatible OSS license for code makes sense.
But requiring for random protocol text, especially if this is going to
make reuse of older RFC's text, seems to not be a great cost/benefit
A more realistic approach may be to think about how text in RFCs are
used. Text often end up in free software projects as comments. This is
useful and helps get the RFC implemented correctly in a more
maintainable fashion. The goals of the IETF is furthered by this, I
argue, so it is disappointing RFC 5378 does not solve the problem.
At least in the linux kernel, quoting a 2-3 sentences of an RFC in
comments is common practice, even before RFC 5378. It is also been
done with great frequency in documentation, magazine articles and
journals, and so on. Fair use takes care of this problem, and there I
don't think even the most insanely paranoid and unreasonable corporate
lawyer would think that 2-3 sentences quoted in manuals, code, etc.,
would be unreasonable.
Certainly this is something where we have over two decades historical
practice, and if anyone thinks an IETF contributor or company would be
suicidially idiotic enough from a Public Relations point of view to
try to sue someone for using 2-3 sentences when this would be pretty
clearly fair use, and the reputations of said IETF contributor or
company would be pilloried in the press, I would gently suggest that
whoever is worried about is greatly disconneted from reality, if they
were to think about the risks involved.
Ietf mailing list