"Tom.Petch" <sisyphus@xxxxxxxxxxxxxx> writes: > Reading this, and reading it and reading it again, I think we are going > backwards more than is desirable where code is concerned. > > I expect that for some years, the s.6.iii.c clause will be common ie no > derivative works outside the Standards process without obtaining an adequate > licence. The s.5.c clause then explains this as meaning that the IETF Trust > will not grant such rights without obtaining sufficient rights to do so from the > person controlling the pre-5378 material. This seems to trump the additional > rights granted for code in s.4. I agree. But that is true only for document that exercises the pre-RFC5378 rule, which in the long term, from what I understand, will be the exception rather than the rule. There is nothing we can do about pre-RFC 5378 contributions except to ask the authors to release more rights to their work. > Where code is concerned, IETF counsel has stated that RFC3978 already gives us > such rights for code, in response to which Simon Joseffson has pointed out > clauses which might be construed differently to which counsel has agreed it > could be clearer but has not changed his advice (eg IPR WG July 2006). RFC 5378 makes the code licensed under a free software compatible license, i.e., the BSD license. The RFC 3978 rights, even if they were granted to third parties, were evaluated by the FSF to be non-free. I haven't seen anyone claim that the RFC 3978 is a useful software license. Thus, RFC 5378 is considerably better than RFC 3978 for code. > My lay reading of this new text is that it does not give us an exemption for > code or if it does, then it does so even more obscurely than RFC3978 does and > this I would regard as a retrograde step. I disagree. The legal provisions from the Trust seems clear to me that code can be extracted and used under the BSD license. This is a considerably step forward, and the rules around it does not strike me as obscure. I wish the rules were less complex, but section 4 of the legal provisions seems relatively low-complex compared to the rest. /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf