"Joel M. Halpern" <jmh@xxxxxxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf