"Joel M. Halpern" <jmh(_at_)joelhalpern(_dot_)com> writes:
My own take has been that the code reuse problem is the dominant
problem.
My interpretation has been that the problem has been (and remain) that
the license on IETF documents is incompatible with free software
licensing, which is counter-productive for the IETF.
Document transfer outside the IETF is sufficiently rare that I would
agree with Fred that not solving that is fine.
I agree too.
Theodore Tso <tytso(_at_)mit(_dot_)edu> writes:
This also means that from my personal perspective, a solution that says
(loosely based on a suggestion from someone else in a side conversation)
that
1) If you can, you grant 5378 rights
2) If you can't, you grant the old rights, as long as there is no code
in the document
3) If there is code, get the rights to the code so people can actually
use the code in the RFC to implement the RFC. (MIBs are already
covered, but we have lots of other kinds of code.)
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.
How much code is there, really?
Looking at the last 10 published RFC's for material (text or code) that
potentially may end up in free software implementations, I find:
5391 sample test-vectors
5393 no
5394 pseudo-code
5395 data table with messages
5396 no
5397 no
5398 no
5401 code, pseudo-code
5405 no
5407 pseudo-code
This is a small sample, and you could discuss each interpretation, but
still I believe this shows that this is a common enough problem to worry
about. RFC 5378 improves the situation in some specific cases but does
not solve the general problem, and understanding whether the specific
case rules apply or not is complex.
I suppose pseudo-code might be a gray area tht will depend on how
paranoid of a lawyer you are dealing with. One who uses the argument
that "copyright can not protect ideas, just the expression of the
idea", will probably say that it's OK. One who tries to draw a
parallel to translations as derived works might be more concerned.
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.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf