Subject: Re: Status summary, IPR WG

From: [email-masked]
Date: Wed, 04 Jan 2006 15:35:49 +0000

I agree Joel, it is an accurate summary and that is what is wrong with it... 

Also - Since this WG is attempting to take on defining the Legal Framework for submission and IP Management Rights, it also bears responsibility for IP Damage and failings in the existing IETF process to support those rights and protect those IP's... and for those reasons it must be reasonable to talk about litigation to protect oneself from the IETF's screwups herein...

---

By the way, as a side note perhaps the real way to build an Open Standards framework would probably be to hand the IETF over to the EFF or someone like it. Something that also would likely cause litigation I bet... and make the OpenSource people wildly happy.

---

More specific Comments inline below.

Todd Glassey
 -------------- Original message ----------------------
From: "Joel M. Halpern" <[email-masked]>
> This seems to me to be a fair summary of the discussion to date.
> Yours,
> Joel M. Halpern
> 
> At 05:46 AM 1/4/2006, Harald Tveit Alvestrand wrote:
> > From the chairs:
> >
> >We believe that this is a fair summary of where the WG is today:
> >
> >- The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative 
> >works to be produced from I-Ds or drafts outside the IETF process. The 
> >authors have that right, but the IETF has not been granted it.

So then someone wanting to republish exceprts from those authors just needs to get a republication release from those parties, right?

> >This is a fact, 

Err OK but the IETF has no legal claims to anything outside its Standardization Process, since this is the deal it made for the submission for publicatiion of those said same IP's 

> and not something the WG can change, 

I would agree that this WG cannot change squat... but a formal straw poll as a vote submitted through the other WG's to the membership at large could do just that. 

That said, it is reasonable that any rule can be changed, it just takes the organization as a whole to do it and not you folks's here in this WG alone. This WG should be producing proposals for the Entirety of the IETF to vote on and that is it... Anything elsec constitutes tortuous Interference in my book and is actionable at that. The problem is I am willing to bet the court's agree on this.

> even if it wishes it 
> >was otherwise.
> >- The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in I-Ds 
> >that become RFCs. 

You mean of course moving forward right? There is NO way to accomplish this with what has been submitted to date, and if the Editors were to refuse to accept any materials that were say submitted under the RFC2026 proviso's they would be causing a tortuous interference with that initiatives standardization process which could and likely would show millions of dollars of damage. The litigation model is VERY simple, in that the IETF's membership as a whole, which any court in this world would agree is real, had no say in this policy change or anything since 2026's publication and as such those documents are not binding as framersork for any contracts regarding the submission of IP...

> This is what Scott's draft should accomplish.

I disagree. The IETF needs to do some real world surveying, rather than sucumbing these IPR WG members dictating what the IETF needs or wants, so that litigation is not needed to change these "IPR delusions" the management of this WG is trying to slam down the rest of the IETF's participants throats.

To that end I propose a formal survey be submitted to ALL members of ALL WG's who have published documents through the IETF, either I-D's RFC,s BCP's or otherwise to allow them to comment on what they wanted or needed with regard to IPR rights rather than what you folks think it is that they want. 

Otherwise, I fear that this matter may be eventually headed for litigation.

> >
> >With regard to outgoing rights - granted by the IETF to the community:
> >
> >- The IETF rights are administered by the IETF trust. The WG should strive 
> >to encode the community's guidance to the trust, not to draft legal language.

No - the Outgoing rights are administered and set by the document that codified the agreement between those submitter's and the IETF, and is mitigated and moderated by intent of the submitters in their attempts of making use of the IETF's "Publishing for Vetting" process.

> >
> >- The rights that we have consensus that the trust should grant to the
> >  community are:
> >  - The community MUST be able to access, copy and redistribute RFCs
> >    and I-Ds freely, including permission to prepare translations and
> >    reformatted versions.

No No NO - I-D's in the past have always been submitted as internal working documents only and are not referenceable outside the IETF. The purpose of the I-D was to create a ground-swell of interest in the initiative to foster the vetting pools production of an RFC. That Request For Comments Document is just that. A request for commentary in the effort to create a standard. Not to allow anyone else to use that IP.

What you are looking for is a way to commoditize and add financial value to pre-Standard documents, becuase of the gross failure in the management of this IETF to provide value in the actual persuit of an Internet Standard. So instead it is clearly the intent of this WG to make the RFC document that 'IETF Standard Lite' document -  and again I and others will seek litigation to prevent this.

> >  - The community MUST be able to extract code and tables from the I-Ds,
> >    and process these according to its usual process. This includes
> >    incorporating them into products distributed under the GPL license,
> >    products distributed as "closed source", and modifications of these.

No No NO... I-D's are for internal use ONLY... and the IPR WG doesnt get to change the contracually binding relationships with the previous published document owners. If this IETF claims that IETF I-D's are referenceable documents moving forward, then for all of us who were prevented from elevating our I-D's to RFC's like mine on FAIR AND OPEN for instance, would have grounds for litigation against the IETF and all of the WG members who prevented that documents elevation in their efforts to suppress IP's. Are you sure you want to do this - and I would check with my Corporate Attorney's on this before blowing it off as "Just Todd's Commentary" since they and you personally will be on the hook if you are wrong here.

> >
> >  - The trust SHOULD take steps to ensure that it's clear that modifying
> >    an RFC or a protocol and claiming that it's the "real" RFC or protocol
> >    is not permitted (unless such steps interfere with the more
> >    important goals above).

garbage - All they have to do is publish a note saying that their work is a derivative of those works and you have nothing to say about their use of the materials by your current proposed models. Further if those individuals were worried about the use of the IP itself, they could easily contact the Author and get a release directly from them in the use of the IP unless the IETF is going to claim that this would damage it because that IP has value... but then the IETF would be liable for damages to the value of that IP and its own failings too eh?

> >
> >
> >- The points that we have heard in the discussion that "seem like good 
> >ideas", but without enough discussion to be able to claim that there is a 
> >consensus, include:
> >
> >  - The trust should permit quotations from RFCs and I-Ds, with permissions
> >    at least as liberal as US "fair use", and easy to figure out

I dont think so...

> >  - The trust should give clear guidance on labelling excerpts from RFCs,
> >    for instance by recommending "extracted from RFC XXX" on unmodified
> >    text, and "based on RFC XXXX" for modified text (if permitted)

Again no - What you are saying is that the IETF of past was incompetent to manage the IETF's IP rights, and now we need a Trust to do that. If a trust is needed to manage a pool of IP then that pool of IP must have value - again the IETF is liable for its failures of the past if you pop-up and say "hey we were wrong, and Glassey and others who claimed the IP has serious value were right, and in the process wee have failed to do what we contracted with them to do, which was vet for standardization and then to publish the vetting results as an RFC candidate for Standarization... 

By the way - for this brain-dead Trust, I want to ask where is the oversight for the trust? Where is the legally enforcable contract between those submitting to the IETF for publishing and vetting, and the IP that flows from the IETF into the TRUST. What recourse is the submitter allowed in the language of the submission to the Trust for the IETF's and the Trust's failure to protect the IP's entrusted to it?

> >
> >- The points that are still under debate include:
> >
> >  - Whether or not all excerpts from non-code text should be permitted
> >  - Whether or not modified versions of excerpts from non-code text should
> >    be permitted
> >
> >Does this seem like a fair summary of the discussion so far?
> >
> >                  Harald and Steve

YES Steve and Harald - it does which is why I think that this WG and you folks personally are headed for litigation.

> >
> >
> >
> >_______________________________________________
> >Ipr-wg mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ipr-wg
> 
> 
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: [email-masked]
Date: Wed, 04 Jan 2006 15:43:42 +0000

My apologies to the group - the AT&T spell checker choked on this post... and my dyslexic typing... again sorry about the typo's in this commentaty because I believe it to be very important.

todd
 -------------- Original message ----------------------
From: [email-masked]
> Also - Since this WG is attempting to take on defining the Legal Framework for 
> submission and IP Management Rights, it also bears responsibility for IP Damage 
> and failings in the existing IETF process to support those rights and protect 
> those IP's... and for those reasons it must be reasonable to talk about 
> litigation to protect oneself from the IETF's screwups herein...
> 
> ---
> 
> By the way, as a side note perhaps the real way to build an Open Standards 
> framework would probably be to hand the IETF over to the EFF or someone like it. 
> Something that also would likely cause litigation I bet... and make the 
> OpenSource people wildly happy.
> 
> ---
> 
> So then someone wanting to republish exceprts from those authors just needs to 
> get a republication release from those parties, right?
> 
> > >This is a fact, 
> 
> Err OK but the IETF has no legal claims to anything outside its Standardization 
> Process, since this is the deal it made for the submission for publicatiion of 
> those said same IP's 
> 
> I would agree that this WG cannot change squat... but a formal straw poll as a 
> vote submitted through the other WG's to the membership at large could do just 
> that. 
> 
> That said, it is reasonable that any rule can be changed, it just takes the 
> organization as a whole to do it and not you folks's here in this WG alone. This 
> WG should be producing proposals for the Entirety of the IETF to vote on and 
> that is it... Anything elsec constitutes tortuous Interference in my book and is 
> actionable at that. The problem is I am willing to bet the court's agree on 
> this.
> 
> > even if it wishes it 
> > >was otherwise.
> You mean of course moving forward right? There is NO way to accomplish this with 
> what has been submitted to date, and if the Editors were to refuse to accept any 
> materials that were say submitted under the RFC2026 proviso's they would be 
> causing a tortuous interference with that initiatives standardization process 
> which could and likely would show millions of dollars of damage. The litigation 
> model is VERY simple, in that the IETF's membership as a whole, which any court 
> in this world would agree is real, had no say in this policy change or anything 
> since 2026's publication and as such those documents are not binding as 
> framersork for any contracts regarding the submission of IP...
> 
> 
> I disagree. The IETF needs to do some real world surveying, rather than 
> sucumbing these IPR WG members dictating what the IETF needs or wants, so that 
> litigation is not needed to change these "IPR delusions" the management of this 
> WG is trying to slam down the rest of the IETF's participants throats.
> 
> To that end I propose a formal survey be submitted to ALL members of ALL WG's 
> who have published documents through the IETF, either I-D's RFC,s BCP's or 
> otherwise to allow them to comment on what they wanted or needed with regard to 
> IPR rights rather than what you folks think it is that they want. 
> 
> No - the Outgoing rights are administered and set by the document that codified 
> the agreement between those submitter's and the IETF, and is mitigated and 
> moderated by intent of the submitters in their attempts of making use of the 
> IETF's "Publishing for Vetting" process.
> 
> > >
> No No NO - I-D's in the past have always been submitted as internal working 
> documents only and are not referenceable outside the IETF. The purpose of the 
> I-D was to create a ground-swell of interest in the initiative to foster the 
> vetting pools production of an RFC. That Request For Comments Document is just 
> that. A request for commentary in the effort to create a standard. Not to allow 
> anyone else to use that IP.
> 
> What you are looking for is a way to commoditize and add financial value to 
> pre-Standard documents, becuase of the gross failure in the management of this 
> IETF to provide value in the actual persuit of an Internet Standard. So instead 
> it is clearly the intent of this WG to make the RFC document that 'IETF Standard 
> Lite' document -  and again I and others will seek litigation to prevent this.
> 
> No No NO... I-D's are for internal use ONLY... and the IPR WG doesnt get to 
> change the contracually binding relationships with the previous published 
> document owners. If this IETF claims that IETF I-D's are referenceable documents 
> moving forward, then for all of us who were prevented from elevating our I-D's 
> to RFC's like mine on FAIR AND OPEN for instance, would have grounds for 
> litigation against the IETF and all of the WG members who prevented that 
> documents elevation in their efforts to suppress IP's. Are you sure you want to 
> do this - and I would check with my Corporate Attorney's on this before blowing 
> it off as "Just Todd's Commentary" since they and you personally will be on the 
> hook if you are wrong here.
> 
> > >
> garbage - All they have to do is publish a note saying that their work is a 
> derivative of those works and you have nothing to say about their use of the 
> materials by your current proposed models. Further if those individuals were 
> worried about the use of the IP itself, they could easily contact the Author and 
> get a release directly from them in the use of the IP unless the IETF is going 
> to claim that this would damage it because that IP has value... but then the 
> IETF would be liable for damages to the value of that IP and its own failings 
> too eh?
> 
> > >
> > >
> Again no - What you are saying is that the IETF of past was incompetent to 
> manage the IETF's IP rights, and now we need a Trust to do that. If a trust is 
> needed to manage a pool of IP then that pool of IP must have value - again the 
> IETF is liable for its failures of the past if you pop-up and say "hey we were 
> wrong, and Glassey and others who claimed the IP has serious value were right, 
> and in the process wee have failed to do what we contracted with them to do, 
> which was vet for standardization and then to publish the vetting results as an 
> RFC candidate for Standarization... 
> 
> By the way - for this brain-dead Trust, I want to ask where is the oversight for 
> the trust? Where is the legally enforcable contract between those submitting to 
> the IETF for publishing and vetting, and the IP that flows from the IETF into 
> the TRUST. What recourse is the submitter allowed in the language of the 
> submission to the Trust for the IETF's and the Trust's failure to protect the 
> IP's entrusted to it?
> 
> > >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Jan 2006 16:25:45 -0500

I believe that Harald was quite clear in other parts of the summary that we 
do not have consensus on allowing arbitrary modification to the specification.

As for where the code-like components have to go, either in the RFC with 
suitable labeling or copied to some other repository or some even more 
complex mechanism, I believe that is basically a detail to be resolved once 
we have agreed on the goal.

Yours,
Joel

At 03:16 PM 1/4/2006, you wrote:
>At 11:46 AM +0100 1/4/06, Harald Tveit Alvestrand wrote:
> >
> >- The IETF rights are administered by the IETF trust. The WG should 
> strive to encode the community's guidance to the trust, not to draft 
> legal language.
> >
>I do not think you have consensus on this.  There is consensus, I believe,
>that the community needs to be able to extract code and tables from
>the I-Ds.  "process them according to its usual process", though, is too vague
>as guidance and "incorporating them into products distributed under the 
>GPL license"
>elides one of the problems.  If code derived from an RFC is GPLed, one of
>the rights granted by the GPL is the right to modify the code; it is not
>clear yet whether we can grant that right without granting the right to
>modify the specification.
>
>I believe that we have seen opposition from John, Dave, and me to the
>IETF granting the right to modify the specification without reference to the
>IETF standards process.
>
>So, I do not agree with this aspect of the summary.
>                                 regards,
>                                         Ted Hardie
>

---

From: [email-masked]
Date: Wed, 04 Jan 2006 22:28:44 +0000

Ted, in case you hadnt noticed, implementing a code footprint from a design that is specified in a RFC is a derivative use model, so legally speaking if someone was to do that without the derivative use mdoel licensing included in the IETF's working papers they would be in violation of that IP licening model.

That means WITHOUT the derivative use license model NO interoperability can be done since NO ONE can use that design without violating the derivative use rights requirements therein... Same is true for I-D based specifications as well...

Todd Glassey

 -------------- Original message ----------------------
From: Ted Hardie <[email-masked]>
> At 9:49 PM +0100 1/4/06, Harald Tveit Alvestrand wrote:
> >
> >Ted, in an attempt at clarifying what you're saying when you say "I do not 
> think you have consensus on this":
> >
> >Do you believe that modifying code that was originally excerpted from an RFC 
> can be construed as modifying the specification?
> 
> I don't think it is clear.  Up to now, I believe code in many RFCs has been seen 
> as one
> of the elements of the specification, along with the free text description and
> any psuedo-code.    That is, you didn't have to use that code to get 
> interoperability,
> but it was available for you to examine as you wrote your own code. 
> 
> I don't think that case is the real problem here, though; I think we're dealing
> with situations like those where mapping tables are included in an RFC.  Any
> code which is going to do the relevant mapping is going to use those tables or 
> re-create
> those same mappings.  Clearly, we want to allow folks to do that, since that is 
> required
> for them to follow the spec.  So we may want to allow those tables _as_code_ to 
> be
> eligible for inclusion in larger code bases.  If we decide that the
> code in some RFCs is software distributed for inclusion in a larger code
> base (rather than only for the purposes of elucidating a standard), there are
> considerations that come into play that don't arise in the other case.
> 
> The main one, from my personal perspective, is how we use the distribution
> of code to achieve interoperable behavior of implementations
> (since that is usual driver for an Internet standard).  This is tricky because
> things like these mapping tables are *both* part of the specification and code,
> potentially available for inclusion in other code bases.  As specifications, we
> do not want them modified without reference to the IETF standards process. 
> As code, releasing them with a license that allows them to be included but not
> modified limits their distribution.
> 
> I don't think the working group is yet clear on whether it is possible to
> release these _as_code_ under a license like the GPL without affecting
> their behavior as part of the spec.  If the IETF publishes mapping tables that 
> say
> code points 4E1C and 6671 are equivalent, and  you change your code to use 
> mapping
> tables in which  4E1C and 6671 are not equivalent, you  have clearly deviated
> from the RFC.  If you change your code and then release it, with new mapping
> tables that can similarly be excerpted, have you released a new specification
> for the mapping tables?  How about if you publish those mapping tables
> as an excerpt?  In general, when does that publication cease to be 
> non-interoperable
> code and become a modified spec?  For open source software, this is not a
> frivolous question, as the local copy of the source for a mapping table may
> be far more ubiquitous than an RFC.
> 
> I don't think we know yet if we can achieve the IETF's goal of producing stable
> specifications of Internet standards and match specific licenses designed for
> software.  It may be that we cannot, and we will have to work out a way of
> publishing the specifications with pointers to code released under a license
> different from the specification itself.  Maybe we can, using a form like
> the lgpl or BSD.  But I don't think we have consensus on it now, and  I don't 
> think
> it is going to be that easy to work out. We might imagine requiring that any
> modification be marked as a mod to the spec in the relevant RFC. 
> We don't, however, currently require that any  implementation using an RFC
> to do anything assert compliance with the RFC, so that would be a bit strange. 
> And it is not clear whether that restriction would pass GPL or Debian tests
>  (given the "advertising clause" issues between GPL and BSD in the past,
> there is good reason to be cautious here).
> 
> I probably should not have gone this deeply into specifics, but I hope this
> is at least marginally clearer now. 
> 			regards,
> 				Ted Hardie
> 
>

---

From: [email-masked]
Date: Thu, 05 Jan 2006 17:27:02 +0000

Since there is no formal way or defined proecss for achieving an IETF concensus the term as listed below is inoperable, and as such may open the entire context of any contractual terms to become invalid. That no one has formally asked the Lawyers about this is also a problem, but ANY portion of the TRUST Operations, the IETF Submission process, or the description of what the IETF is providing to those that submit IP being unenforcebale will render the entire contract framework inoperable and unenforceable since in the IETF's process models the failing of any one stage becomes adversarial to those presenting work for vetting and standardization efforts within the IETF.

Sorry - that is justthe way it is.

Todd Glassey

 -------------- Original message ----------------------
From: John C Klensin <[email-masked]>
> Brian,
> 
> I think we are in agreement, perhaps violent agreement.   I was
> only pointing out that some plausible evolution of the IPR
> policies could, as a possibly unintentional side-effect of IETF
> decisions, put the IAOC into exactly that case-by-case position.
> I presume that is a position you don't want to be in either, but
> that is a separate matter.
> 
>     john
> 
> 
> --On Thursday, 05 January, 2006 11:46 +0100 Brian E Carpenter
> <[email-masked]> wrote:
> 
> > 
> > 
> > John C Klensin wrote:
> > ...
> >> I also do not believe that we should do anything that would
> >> force (or even permit) the IAD or IAOC to get into the
> >> business of making case-by-case decisions about licensing.
> >> To do so would require a rather different skill set in those
> >> people and in those who select them.   As I've said in other
> >> circumstances, I believe that the IETF should make policy and
> >> that the IASA should administer and implement it only.
> > 
> > That's why the Trustees voted the following into the IETF
> > Trust procedures
> > on December 15th:
> > 
> > "10.	The Trust shall be guided by IETF process documents,
> > decisions of
> > the IETF leadership, and IETF consensus when licensing use of
> > its
> > intellectual property in accordance with the Trust Agreement."
> > 
> > I don't think there's any contention about this point.
> > 
> > Now, I can't exclude that there might be special cases,
> > requiring
> > a case-by-case decision; an example would be where the IETF
> > desires
> > to hand a standard over to another SDO for future maintenance
> > (as we did with HTML, for example). But that doesn't change the
> > words quoted above - it's still the IETF that decides.
> > 
> >     Brian
> > 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 09 Jan 2006 15:44:52 +0000

Harald - why not eliminate all of the confusing set of releases in favor of a cafeteria style release document allowing the submitter to specify which rights they want conferred on the IETF for the Standards Generation process, and for those not, what derivative use licenses are critical - and here is why...

1) Any licensing of the IP that is to be used for any purpose (i.e. republishing or derivative uses must be properly defined and the submitter provides proper releases stating their intent in the submission.

2) Any 3rd party use for republishing is supposed to be for the "furtherance of the IETF's charter in developing Internet Standards" and any other use MAY invalidate the transfer of property to the IETF under the UETA and US Contract Law contstraints.

3)
 -------------- Original message ----------------------
From: Harald Tveit Alvestrand <[email-masked]>
> 
> 
> --On mandag, januar 09, 2006 12:32:37 +0100 Tom Petch 
> <[email-masked]> wrote:
> 
> > Yes, I agree it is a fair summary provided the words mean what I want
> > them to mean:-).
> >
> > I am concerned about the code and tables, that is a more precise
> > definition thereof may show up disgreement, such as
> > a) what is code? eg are ABNF and FSM included? (I assume yes); I think the
> > constituents need nailing down sooner rather than later.
> 
> I don't know (although I have opinions); I think we have consensus that 
> there are things that are definitely "code" and things that are definitely 
> not, but I think it's hard to nail down.
> 
> One heavyweight process for determining it would be to require the WG or 
> individual submitting a specification to submit separately/alongside a file 
> containing *only* the parts *he* thinks is code. I don't like it because 
> it's heavyweight, an extra processing step, requires changes to the I-D 
> process and runs the risk of losing consistency between the specification 
> and the code - but it's possible.
> 
> > b) when extracting a MIB module, I always have a lot of editing to do to
> > remove those pesky running headers and footers - does this constitute
> > modification? Common sense says not, but common sense seems in short
> > supply whenever lawyers are around.
> 
> Let's focus on figuring out what we want in this case; we *know* that the 
> legal language doesn't come out right on the first try...... if we want to 
> allow the extraction, we have to allow the extraction, so what you're doing 
> is what we want to allow, whether a lawyer would call it "modification" or 
> not.
> 
> > c) what is the status of information on the IANA website, much of which is
> > tables, but which also includes MIB modules derived from several sources,
> > which I would expect to be incorporated unchanged.  This may code or
> > table in an RFC, may come from expert review, may come from a text
> > paragraph in IANA Considerations, etc.  Derivative work, modified?  Do
> > the rights we are talking of encompass IANA?  I don't know (come to think
> > of it, I have lost track of the relationship of IANA to our new IAOC
> > world:-(
> 
> Me too.... I know what I'd like to view the work of the IANA as (work for 
> hire, with the IASA being the hirer, and all IP rights assigned to the IETF 
> Trust), but history makes this web uncomfortably tangled.
> 
> I think we should try to think of IANA as a situation we'd want to give 
> IASA advice on, but they will have to take on the task of sorting out what 
> the situation is....
> 
>                   Harald
>

---

From: [email-masked]
Date: Mon, 09 Jan 2006 15:55:03 +0000

Ooops - fat fingered that one...

 -------------- Original message ----------------------
> Harald - why not eliminate all of the confusing set of releases in favor of a 
> cafeteria style release document allowing the submitter to specify which rights 
> they want conferred on the IETF for the Standards Generation process, and for 
> those not, what derivative use licenses are critical - and here is why...
> 
> 1) Any licensing of the IP that is to be used for any purpose (i.e. republishing 
> or derivative uses must be properly defined and the submitter provides proper 
> releases stating their intent in the submission.
> 
> 2) Any 3rd party use for republishing is supposed to be for the "furtherance of 
> the IETF's charter in developing Internet Standards" and any other use MAY 
> invalidate the transfer of property to the IETF under the UETA and US Contract 
> Law contstraints.
> 
> 3)

#3 Any 3rd party use of the code/text for developing anything, whether its a product or a a furthering of the standards process or otherwise, would probably REQUIRE a derivative license, since the republishing rights are generally granted only for the furthering of the original intention - that being the creation of an Internet Standard.

T.