Subject: A couple of questions about the IETF trust outbound licensing.

From: Thierry Moreau <[email-masked]>
Date: Mon, 14 Nov 2005 09:11:42 -0500

To the iaoc "mailing list":

Thanks to Lynn St-Amour for the presentation at IETF-64 IPR wg
about the IETF trust. Having read the IETF trust agreement, I
have a couple of questions.

The licenses to be granted by the trust have a "contaminating
property" even stronger than GPL'ed source code. This is how I
read the clause 9.5 of the trust agreement:

9.5 Licenses. The Trust (acting through the Trustees) shall have
the right to grant licenses [...] the licensee agrees to grant
and assign to the Trust all right, title, and interest it may
have or claim in any derivative works of Licensee that are based
on or incorporate the IPR. [...]

Let's take the DNS-centric bind software, currently licensed as a
3-clause BSD fee software licence. Suppose a future version of
bind requires a license from the trust. Then, a future bind
software "proprietary fork" would need to be assigned back to the
trust.

Am I reading this correctly?

Is this the intent of the trust agreement signatories?

Also, this e-mail [email-masked] is said to be a mailing list, but
there is no indication of an archive and instructions to
subscribe/unsubscribe. (at least in
http://koi.uoregon.edu/~iaoc/).

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 15 Nov 2005 12:50:31 -0800

> on or incorporate the IPR. [...]

I believe that this is poorly written.

The part of the problem I encountered in my time as IETF chair was the case 
where a contractor got a license from the IETF Trust to use the IETF 
history databases and the management tools written so far to generate new 
management tools for the IETF (under contract) - think "I-D tracker version 
II".

The language here seems to be trying to make it clear that the IETF would 
be able to use the result of such work even after the expiration of the 
contract.

I do not think that there was ever an intent to enforce any such "giveback" 
on the implementors of IETF standards.

(note - I'm currently at the IEEE, where they are no longer using the 
online ballot and registration system they were using at the previous 
meetings - apparently, the reason why involves a contract dispute and 
substantial legal fees. These are not hypothetical questions, but they are 
not about the content of the standards.....)

                  Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Nov 2005 11:28:58 +0100

a) It was Lucy Lynch who presented briefly in the IPR WG, not Lynn.

b) That isn't the intent of clause 9.5. It's actually intended to
ensure that work done for us by the secretariat or any other service
provider reverts to the IETF, and that mods made by other bodies
to our specifications revert to us. But since it could be interpreted
the way Thierry is concerned about, we will put clarifying text
in place (outside the Trust agreement itself) to avoid this unintended
side effect. We worked on this in Vancouver with other people who
noticed the same point and the clarifications are in preparation.

    Brian

Harald Tveit Alvestrand wrote:
> The part of the problem I encountered in my time as IETF chair was the 
> case where a contractor got a license from the IETF Trust to use the 
> IETF history databases and the management tools written so far to 
> generate new management tools for the IETF (under contract) - think "I-D 
> tracker version II".
> 
> The language here seems to be trying to make it clear that the IETF 
> would be able to use the result of such work even after the expiration 
> of the contract.
> 
> I do not think that there was ever an intent to enforce any such 
> "giveback" on the implementors of IETF standards.
> 
> substantial legal fees. These are not hypothetical questions, but they 
> are not about the content of the standards.....)
> 
>                  Harald
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2005 15:30:42 +0100

> noticed the same point and the clarifications are in preparation.

That is another instance of where the license text suggest one thing,
people read it in another way, leading to clarifying text outside the
license.

The problem with that approach is that the clarifying text may not
mean what the license says.  When people go to the license text, they
realize they were fooled by "clarifying text".  The FAQs are not
legally binding.

History indicate that this has happened several times.  The RFC Editor
has still not updated its incorrect RFC 3978 "explanation" although
everyone appear to agree it is incorrect.

Please, PLEASE, make the license text say what you mean, rather than
add clarifying text outside the license.  This is very important.

I strongly suggest that people should avoid reading the IPR Trust FAQs
and IAOC "clarification" and go straight to the license agreement.  If
you find a problem with the text, don't settle with a clarifying
update that is not part of the contract.

Having to read too many FAQs that claim various things, which are not
legally binding, and that nobody is accountable for, before you read
the license text smell like a smoke screen to me.

Thanks,
Simon

>> The part of the problem I encountered in my time as IETF chair was
>> the case where a contractor got a license from the IETF Trust to use
>> the IETF history databases and the management tools written so far
>> to generate new management tools for the IETF (under contract) -
>> think "I-D 
>> tracker version II".
>> would be able to use the result of such work even after the
>> expiration of the contract.
>> (note - I'm currently at the IEEE, where they are no longer using
>> the online ballot and registration system they were using at the
>> previous meetings - apparently, the reason why involves a contract
>> dispute and substantial legal fees. These are not hypothetical
>> questions, but they are not about the content of the standards.....)
>>                  Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2005 16:37:10 +0100

"Lucy E. Lynch" <[email-masked]> writes:

> On Wed, 16 Nov 2005, Simon Josefsson wrote:
>
> Simon -
> I'm confused. Do you mean the Trust or the License?

Both.  I was pointing out a generic problem that apply to both the
trust and the license for IETF Contributions.

> Point of clarification. The clarifing text that Brian mentions will be
> some form of written agreement from the Settlors stating that the terms of
> the IETF Trust effect only those items transfered into the IETF Trust and
> not the content of the RFCs, email messages, etc. The FAQ text is not
> binding but the letters of agreement would be.

The clarifying text will be part of the agreement?  If so, that is
better.  Still, it seem redundant.  If the license is clear from the
start, clarifying text would not be required.

Thanks,
Simon

>> IAOC mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/iaoc
>>

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Wed, 16 Nov 2005 07:32:16 -0800 (PST)

Simon -

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Wed, 16 Nov 2005 07:13:07 -0800 (PST)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Nov 2005 08:16:16 -0800

Simon,

> trust and the license for IETF Contributions.

Remember that the two things are fundamentally different in who can change 
them.... the trust agreement is the result of a long negotiation between 
ISOC, CNRI and the IAOC, and can only be reopened if all of them agree to 
"go back and start over" - which would halt all work that requires the 
trust to be in place.

Additional clarifications, agreed by the same parties, are (I think) not an 
unreasonable way to "fix" language in the trust agreements that didn't seem 
to say what the parties thought they should be saying when others read them.

The model license agreement, on the other hand, is just that - a model - 
and the IASA can choose to use it, use another, or publish a new model 
agreement whenever it sees the need - so "please change the license 
agreement" is a very reasonable thing to ask the IASA to do.

I have read the IASA model license as a license it would use with 
subcontractors doing paid work for the IASA; the context of RFC users and 
protocol implementors is different. So the first order of business wrt the 
model license may very well be to add "This applies to..." to the top.

                       Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2005 18:10:16 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> Remember that the two things are fundamentally different in who can
> change them.... the trust agreement is the result of a long
> negotiation between ISOC, CNRI and the IAOC, and can only be reopened
> if all of them agree to "go back and start over" - which would halt
> all work that requires the trust to be in place.

Hi Harald.  Am I reading this right; the IETF is not in a position to
change the trust agreement at this point, without the agreement of
ISOC/CNRI?  What's the point of any public review at all then?

You don't get community co-operation in something that the community
cannot modify the outcome of.

I think people will be less motivated to participate if they are
presented a done-deal that they can either support, or be considered
"halting all work" by rejecting the proposal.  In my opinion,
providing only those two options is bad community management.  It is
important to have community input as early as possible, when there is
time to make the license reflect the community opinions.  If I
understand the situation correctly, that doesn't seem to be possible
now.

> Additional clarifications, agreed by the same parties, are (I think)
> not an unreasonable way to "fix" language in the trust agreements that
> didn't seem to say what the parties thought they should be saying when
> others read them.

I agree it is not unreasonable.  However, I believe it is a poor
solution.  Clarifying text can always be challenged, the actual
license less so.  The situation with the RFC 2026 license meaning one
thing and the community consensus suggesting another meaning is one
example of that.

I feel that this discussion has moved beyond solving any problem that
the IPR WG was chartered to solve, so I'll (try to..) avoid responding
further in this thread.

Regards,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 16 Nov 2005 09:42:26 -0800

[note that this is no longer about outbound licensing - I'll stop too...]

> cannot modify the outcome of.

Unfortunately, community management is not the only concern here.

As I can certainly testify to, developing ANYTHING with a community 
line-item veto (which is what "can be modified based on community 
discussion" amounts to) is an *extremely* time-consuming and 
resource-draining process.

And in a situation like this, where the result:

- must be agreed to *in full* by an external party
- must be legally feasible based on multiple lawyers' reviews
- has already had the principles of the desired outcome spelled out in some 
detail by the community in BCP 101

I think that the model of negotiating an agreement and presenting it to the 
community for an up/down opinion is not only sensible, it's the only choice 
that could possibly lead to an agreement of this type.

We might have wanted more notification of what was being negotiated, so 
that we could give more "advice" to our negotiation team during the 
negotiations, but in the end, I think we have to work in this fashion.

And - I repeat this again - the TRUST AGREEMENT is NOT, repeat NOT, a 
LICENSE. We have all the time in the world to badger the IASA about the 
langauge of the licenses it signs; the trust agreement is the only thing we 
are asked to have an opinion on in that Last Call.

                 Harald

---

From: Steve Crocker <[email-masked]>
Date: Wed, 16 Nov 2005 13:32:07 -0500

[To reduce duplicates, I removed individual names assuming each was a  
member of the ipr-wg or IAOC or both.  If someone knows that I've  
left out someone who should be addressed, please forward.]

I'm a member of the IAOC and hence will be one of the trustees when  
the trust is put into operation.  I've paid fairly close attention to  
the wording and helped draft some of the early versions.  (Section  
9.5 is not my work and I agree it does not read as clearly as it  
should.  I think the plan is to clarify it in a separate document  
rather than rewrite it, but that remains to be seen.  In any case,  
the intended meaning of section 9.5 is exactly in line with the  
IETF's principles and is not aimed at changing the rules on  
implementations of IETF standards.)

Harald's description of the process is exactly right.  The community  
spoke clearly in BCP 101, which is entirely consistent with the long- 
standing practice of making the technology available without charge.   
The trust agreement is really an implementation of BCP 101, not a new  
policy or new direction.  Of course, in a community as diverse as the  
IETF, some feel the trust agreement should have been iterated through  
the whole community at each step, and others feel it's just another  
contract and hence entirely within the purview of the IAOC to approve  
without further review.  The course we've chosen is not that severe  
and the document is available for review and comment.  If there are  
truly unacceptable elements in the document, then we have to reopen  
negotiations.  But that's a very big deal at this point and carries a  
substantial cost, so there's a strong preference to accept the  
document as it currently stands.  As I said above, clarifying the  
meaning of section 9.5 is being discussed.)

Negotiating the trust agreement has been a long and difficult  
course.  From my point of view, the terms of the trust do satisfy our  
needs.  That is, they allow the IETF to continue to operate according  
to its principles and they do not get in the way.  This is the  
primary test, and I think the document passes without much debate.

Some of the dialog addresses the stronger question of whether the  
language in the trust would permit the trustees to veer off in  
another direction, say perhaps by charging for the intellectual  
property.  The answer is yes.  This instrument is not designed to  
constrain all possible actions of the trustees.  Fortunately, that's  
not necessary.  The trustees are the IAOC members, and the IAOC  
members are selected by the community.  If the trustees veer off in  
the wrong direction, the community has recourse to deal with the  
IAOC.  Frankly, I think the scenarios being discussed are unlikely  
and of little concern, but I understand opinions vary.  As a  
practical matter, the specific problems we've faced in the past have  
been contention over who owned the "internal" IPR, i.e. the tools,  
databases, tracking software, domain names, meeting attendance lists,  
etc.  All of that is now unambiguously under the control of the IETF,  
and we are further protected in that when we make this available to a  
contractor providing secretariat services, they are not allowed to  
evolve the tools, databases, etc. and then claim ownership.  I can  
tell you that if we had these matters under control two or three  
years ago, we could have shortened the entire restructuring process  
and saved a huge amount of work and contention.

Hope this helps.

Steve

Steve Crocker
[email-masked]

On Nov 16, 2005, at 12:42 PM, Harald Tveit Alvestrand wrote:

> - has already had the principles of the desired outcome spelled out  
> in some detail by the community in BCP 101
>
> I think that the model of negotiating an agreement and presenting  
> it to the community for an up/down opinion is not only sensible,  
> it's the only choice that could possibly lead to an agreement of  
> this type.
>
> We might have wanted more notification of what was being  
> negotiated, so that we could give more "advice" to our negotiation  
> team during the negotiations, but in the end, I think we have to  
> work in this fashion.
>
> And - I repeat this again - the TRUST AGREEMENT is NOT, repeat NOT,  
> a LICENSE. We have all the time in the world to badger the IASA  
> about the langauge of the licenses it signs; the trust agreement is  
> the only thing we are asked to have an opinion on in that Last Call.
>
>                 Harald
>
>
>
>