Subject: Re: The Trust and licensing [Re: New version of my proposal posted]

From: [email-masked]
Date: Fri, 11 Nov 2005 19:30:30 +0000

-------------- Original message ----------------------
From: Brian E Carpenter <[email-masked]>
> This is a late reply and may have been partly overtaken by
> discussions in Vancouver, but John raised some important
> points. It's also a personal reply, not an IAOC reply
> or an AD reply or an IETF Chair reply.
> 
> John C Klensin wrote:
> > 
> > --On Friday, 04 November, 2005 20:57 +0100 Brian E Carpenter
> > <[email-masked]> wrote:
> > 
> > 
> >>...
> >>b) it's my personal intention to insist that the Trust's
> >>procedures
> >>include a commitment to follow the IETF's wishes in matters
> >>of licensing.
> >>...
> > 
> > 
> > This intention would ease several concerns.  However, section
> > 9.5 of the trust agreement contains provisions that appear to me
> > to be equivalent to those of the GPL copyleft only retaining the
> > rights for the Trust rather than the public.
> 
> The intention of that text was to ensure that the IETF has the
> right to make derivative works from derivative works of its
> own text made by a licensee. 

I suggest that this is the way to kill the trust - No one who made a commercial derivative from a IETF public technology will want to give their work away and for the IETF to mandate that they must if the IP from the trust is used, insures lawsuits and pain for the IETF and the Trust both.

> It certainly wasn't intended to have
> a viral effect. We've discussed this during the week and believe
> that there are two things to do
> 
> 1. Add clarifcation of the legal interpretation to the Trust FAQ.

I also suggest that this is something that constrains the relationship between the participants in the IETF processes and the IETF itself. How will you deal with someone that says to you - "The IETF processed any number of documents without the trust or without any of these transfer requirements, I want to submit a draft or RFC under the old terms". My feeling is that not accepting it may be another lawsuit."

> 2. Obtain assurance that ISOC (as the Settlor as far
> as RFCs is concerned) does not intend the sort of perverse side
> effect you fear and does intend the IETF to determine the licensing
> conditions.

>From material submitted - the IETF cannot make rediculous licensing terms as no one will submit to it when they find out what they are giving away by doing so - and (here we are again) those submissions may not be binding as far as those release go if the IETF doesnt change its induction process IMHO.

> 
> > Specifically, the
> > Trust cannot license or assign any rights in Trust-owned IPR,

Why is not the TRUST then the caretaker of the IP and the IETF remains the owner?

> > including the right to to create derivative works, unless the
> > licensee agrees that those derivative works will belong entirely
> > to the Trust.  

Which no one in their right mind would do as far as I can tell.

> > In addition, not being a lawyer, I'm not certain
> > what 9.5(b) means in practice, but it appears to mean that, if a
> > licensee were to marginally profit as a consequence of using the
> > IETF's IPR, the Trust would have a claim on a share of those
> > profits.

Only if the Trust is made as the owner. Further those submitting those IP's to the TRUST would also have the same rights as collateral contributors then.

> 
> I think it's true that the Trust text doesn't exclude royalties
> by construction. 

yeah...

> And who can say that we might not encounter
> a form of commercial exploitation of our IPR that doesn't in itself
> serve the IETF's purposes? In that case, would we want to exclude
> royalties by construction? As the text stands, the IETF has the
> option open.

Actually in my licensing plan - there is a commercial service the IETF can offer people!!! - Oh yeah - a revenue stream can be had! - my intent was to price it at something like 5K to 10K per 'Commercial Informational Grant" and this all will make more sense when you see the two types of IP Grants codified in my new draft.

> 
> > 
> > It seems to me that this raises two issues that have been hotly
> > debated in the past in another context.  The restriction would
> > appear to require individual negotiation of licenses, not a
> > blanket grant, which some members of the community have argued
> > is too onerous for other types of IPR.  

With the plans that have been submitted to date this is true - but wait until my plan is submissted this evening. If the list wants I can forward copies of it to whoever wants early access to it.

> > It also creates a "what
> > is mine is mine and what is yours is mine too" condition, to
> > which many organizations have taken strong exception in the past.

Amen.

> 
> Yes, and as noted above I don't believe that is the intention.

Uh, I would disagree here - I think that was entirely the intention. I

> The blanket license question is a good one, but I don't see
> why the Trust text would prevent a blanket license if that's
> what we wanted. However (see discussion of draft-josefsson-)
> it's not yet clear whether we do want it.
> 
> > 
> > I note that this working group was not consulted on that
> > language or on the appropriateness of these licensing
> > constraints.
> 
> No, because the IAOC was constrained. I feel that this was
> unfortunate myself.
> 
> > 
> > I hope we can avoid re-debating either of those substantive
> > issues here.  But I  think it is important to point out that,
> > should the IETF change its mind in this matter, or reach a
> > conclusion about terms different from those specified in the
> > trust agreement, and do so by some mechanism that clearly
> > reflected community consensus:
> > 
> > (1) The IAOC, in addition to or instead of the IESG, would need
> > to ratify that consensus.  While I agree with Brian's
> > observation that 
> > 
> > 
> >>	a) the IETF can in fact fire most of the Trustees if
> >>	they misbehave, and I think that ignoring an IETF or
> >>	IESG consensus on licensing would be a firing offense;
> > 
> > 
> > the "running code" is that the community has found "firing" to
> > be a much too difficult and unpleasant procedure to deal with
> > any but the most obnoxious of behavior.  It is not yet
> > demonstrated that behavior that obnoxious is even possible
> > because the mechanisms have never been exercised at all.   If an
> > IAOC concluded that it simply knew better than the community
> > consensus, perhaps on the basis of information available to them
> > and not the community, experience so far would lead them to
> > reasonably predict that recall/ firing is not a sufficient
> > threat to prevent following their judgment rather than the
> > community's.  
> 
> There's truth in that. All I can say is that the IAOC is very
> conscious of the community, although we also have to deal with
> legal and financial constraints that may be less compelling to
> the community than they are to those of us on the hook.
> 
> > 
> > More generally, if we have designed a procedure for which we
> > need to use the threat of recall as the only mechanism to ensure
> > that an IETF consensus on licensing is followed, we are probably
> > in bad trouble. 
> 
> I don't think we have. I suspect that if the Trust had been
> proposed when BCP 101 was written, we'd have some specific
> language in there about the IAOC being bound to act in the
> IETF's best interests even in their Trustee role, or whatever.
> I only mentioned recall because it does emphasise that the IAOC
> is in place to serve the community. I have proposed language for
> the Trust's procedures that says "All the Trustees' decisions
> shall be subject to the community review process defined in
> Section 3.5 of BCP 101 for IAOC decisions."
> 
> > I suggest that, if the IETF believes that IETF
> > consensus, especially on the policies to be followed by the
> > Trustees, should be binding on the IAOC and those Trustees, the
> > IETF needs to insist on that as a requirement.
> > 
> > Unfortunately, under the Trust Agreement as I read it, the IETF
> > doesn't get to impose that requirement, as least not as an IETF
> > action.  
> 
> But with the beneficiary of the Trust being the IETF, and the
> majority of the Trustees serving at the IETF's pleasure,
> I really believe that is functionally equivalent. And see my
> previous comment.
> 
> > 
> > (2) Any changes to the basic licensing requirements or rules of
> > the Trust, such as changes to the licensing provisions of 9.5
> > described, should the IETF decide to make them, require the
> > consent of both CNRI and ISOC unless we are prepared to wait
> > until July of 2010.  These are requirements of the Trust
> > agreement and CRNI and ISOC must agree to any amendments to that
> > agreement.   If they don't agree, they don't need to give
> > reasons.  They are not even obligated to indicate whether they
> > agree or not within any specified period of time.  Should one of
> > them not agree, then, as the Trust Agreement is written, IETF
> > consensus is worth exactly nothing.   And there is no mechanism
> > for "firing" either of the Settlors, at least without the
> > consent of both of them.
> 
> That is why we worked hard for several months to ensure that
> the Trust sets boundary conditions that appear to us to be
> compatible with as wide range as possible of IETF policies.
> > 
> > As I have communicated privately (and in much more detail) to
> > the IAOC, I believe that the Trust Agreement sets policies for
> > the IETF and gives away decision-making authority over which the
> > IETF has believed that it _as a community_ had consensus
> > control.  Because it involves setting policies, rather than
> > "managing" the IPR portfolio, I don't believe the IAOC has the
> > right/authority to do any such thing without explicit community
> > consensus.
> 
> There, John, we simply disagree. I believe that the Trust agreement
> actually doesn't set policy; it gives the Trustees the power
> to set policy, and the Trustees are beholden to the IETF. Now
> that is certainly a judgement call but I am also proposing
> this language for the Trust procedures: "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."
> 
> >  Whether their doing so is a matter that would be
> > considered equivalent to one of the activities for which Brian
> > believes people should be "fired" is something that he should,
> > IMO, comment on.  And it is one on which the community should
> > reach some conclusion... a conclusion that I believe is
> > ultimately about whether IETF decision-making, at the most basic
> > of policy levels, is bottom up or top-down, controlled by the
> > community or controlled by a few of its appointed leaders acting
> > on their own judgment rather than on community consensus.
> 
> If, say, the Trustees in their first meeting decide to start
> charging for RFCs or, at the other extreme, to donate rights
> in all RFCs to the ITU, that would be reprehensible policy change
> without consensus. But the Trust agreement in itself is pretty
> much neutral with respect to the IETF's IPR policy (modulo the
> comments on 9.5 at the head of this note).
> 
>      Brian
> 
> 
> 
> 
> _______________________________________________
> 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: Fred Baker <[email-masked]>
Date: Mon, 14 Nov 2005 07:16:05 -0800

My small mind travels in circles on what a "derivative" and an  
"implementation" constitute in your mind.

Lots of people implement IETF specifications. That's why we write  
them. Sometimes a feature is added over and above the specification,  
normally in response to a customer requirement. For example, a while  
back we wanted to deploy a concept that eventually became known as  
MPLS, and we needed to find ways to determine what path the LSP  
needed to follow and we needed a protocol to install it. These were  
instantiated in updated features in OSPF and RSVP. Both modifications  
were brought back to the standards process. Similarly, various issues  
require changes in global BGP routing, such as the fact that MD5 was  
recently broken etc; these are discussed in the 26 current internet  
drafts in idr. In general, when IETF protocols are modified, it is  
for similar reasons, and in fact the modifications similarly make it  
back.

What "commercial derivative" do you have in mind that is *not*  
characteristically brought back? Can you get specific?

On Nov 11, 2005, at 11:30 AM, [email-masked] wrote:
> I suggest that this is the way to kill the trust - No one who made  
> a commercial derivative from a IETF public technology will want to  
> give their work away and for the IETF to mandate that they must if  
> the IP from the trust is used, insures lawsuits and pain for the  
> IETF and the Trust both.