On 01/08/2014 08:50, manning bill wrote: > we will now enter the realm of word definitions. An IETF Standard is any document published by the IETF. Standards come in a range of attire, full standards (rare), proposed, informational, historic and a few others. Well, no; cf RFC2026 and RFC6410. But it doesn't really matter, since IPR disclosures are required for all contributions anyway. > As you properly have tabled, some of these IETF standards are subject to IPR claims, which the IETF mgmt and its sponsoring organization have prudently recognized. Publication of such material, > encumbered by Intellectual Property Rights, clearly suggests that the IETF standard in question can not, in fact, be represented in open source without violation of IP laws. > > Codec and Crypto specs tend to be owned. If they are published as RFCs the boilerplate will indicate rights; but watch out for the change of rules introduced by RFC5378. > then there is this from ISOC in 2003: www.isoc.org/briefings/014/briefing14.pdf > which suggests that, “Mobile IPv4 NAT-traversal protocol extension is specified in > a separate RFC that is IPR-encumbered. “ > > I’ll leave the creation of the detailed list as a homework assignment. Yes, implementors need to check the fine print (i.e. the version of the rules in force when an RFC was published, and any IPR disclosures against the document). And they need to understand the difference between IETF and non-IETF RFCs. And of course none of the above applies if the encumbered technology is published other than as an RFC but referenced by an RFC. Brian > > /bill > Neca eos omnes. Deus suos agnoscet. > > On 31July2014Thursday, at 13:13, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > >> On 01/08/2014 05:39, manning bill wrote: >>> it has always been my understanding that (with a few exceptions that have become more and more common over the years) IETF standards allowed for open source development. >> What exceptions, Bill? IETF standards are open voluntary standards >> that anyone can implement how they like. >> >> It's a fact that open source implementations that infringe patents >> are intrinsically problematic, so if there is an IPR disclosure that >> doesn't offer open-source-friendly conditions, that can be a problem. >> >> It's a fact that code fragments in RFCs are normally subject to the >> Simplified BSD License (for the full story see the IETF Trust Legal >> Provisions). >> >> Brian