Subject: [Roll] An AD Comments on IPR

From: Adrian Farrel <[email-masked]>
Date: Tue, 02 Feb 2010 13:28:02 +0000

Hi,

I can understand people's frustration with the nature of IPR claims and 
disclosures.

However, while you can ask anyone to give you advice about what is covered 
by a claim, and what the IPR terms actually mean, this is ultimately a 
question that must be handled as an individual issue by you, or as a 
corporate issue by your legal advisers. You would be poorly advised to rely 
on the advice of an individual on this list, whatever their technical or 
legal qualifications.

JP's question is intended to allow you to state your opinions so that he can 
judge working group consensus.

He asked:

> Given the discussions about the IPR disclosure at
> https://datatracker.ietf.org/ipr/1246/ and the IETF's IPR
> policy at http://www.ietf.org/ipr/policy.html I would like
> to make sure that the working group is happy to proceed
> with draft-ietf-roll-rpl in its current form. Please state your
> opinions on the list. I will make a consensus call on Friday
> 11 February.

[We can probably assume that he means Friday 12 February :-)]

In answering this question you need to say "yes, let's go ahead" or "no, we 
have to take steps to avoid the IPR". Your reasons for holding a position 
may be helpful to others and to the chairs in finding the way forward.

By way of background, the IETF has always attempted to find unencumbered 
technical solutions, but there is a general recognition that very few 
specifications reach RFC status without the possibility of some IPR claim at 
some time. By requiring IETF participants to disclose IPR, the IETF is 
seeking to enable informed decisions why its participants, and this helps to 
avoid claims of entrapment. It should be noted that the absence of an IPR 
disclosure is not a guarantee that no IPR exists, but the presence of a 
disclosure allows everyone to see the licensing terms. In deciding whether 
to support or deny continuation of technical work in the presence of an IPR 
disclosure, individuals (or their companies) will want to consider whether 
they think the IPR actually covers the technical work, whether it is 
enforceable, and whether they consider the licensing terms to be favourable. 
They will also need to consider the cost-benefit of the various options that 
exist. No-one else can make these decisions for you!

May I also take this opportunity to ask you all to look at the IETF's IPR 
policy. In particular, can I remind you all about the policy with respect to 
IPR that you know about as described in RFC 3979 and RFC 4879. All document 
authors and contributors to discussions need to be aware of their personal 
commitments to disclose IPR as expressed in those two RFCs.

Thanks,
Adrian

---

From: Kris Pister <[email-masked]>
Date: Thu, 04 Feb 2010 11:35:23 -0800

Yes, let's go ahead.

For what it's worth, this will not be the last time someone discloses IP 
related to RPL or sensor networks in general.  Cisco's policies are well 
known, and in my opinion quite reasonable.  Other IP is likely to be 
disclosed in a friendly letter as soon as someone perceives that you are 
making a profit. To quote Casablanca (Peter Lorre?): There are vultures, 
vultures everywhere!
I can't count the number of times that I've been approached after a talk 
by someone who says "you know, I've got the fundamental patent that 
covers that".  I've heard so many people claim that they are the ones 
who patented combining a microprocessor/sensor/radio that it makes me 
wonder if the patent office isn't paying attention, or if I just attract 
nut cases.

It would be a wonderful thing if we had a central database describing 
the first public disclosure of the building block ideas that go into 
sensor networks, because we will, as a community, need to be able to 
fight back against those who see IP as a profit center, not a protocol :)
Maybe a brainstorming session at the next meeting is in order?

ksjp

Adrian Farrel wrote:
> Hi,
>
> I can understand people's frustration with the nature of IPR claims 
> and disclosures.
>
> However, while you can ask anyone to give you advice about what is 
> covered by a claim, and what the IPR terms actually mean, this is 
> ultimately a question that must be handled as an individual issue by 
> you, or as a corporate issue by your legal advisers. You would be 
> poorly advised to rely on the advice of an individual on this list, 
> whatever their technical or legal qualifications.
>
> JP's question is intended to allow you to state your opinions so that 
> he can judge working group consensus.
>
> He asked:
>
> In answering this question you need to say "yes, let's go ahead" or 
> "no, we have to take steps to avoid the IPR". Your reasons for holding 
> a position may be helpful to others and to the chairs in finding the 
> way forward.
>
> By way of background, the IETF has always attempted to find 
> unencumbered technical solutions, but there is a general recognition 
> that very few specifications reach RFC status without the possibility 
> of some IPR claim at some time. By requiring IETF participants to 
> disclose IPR, the IETF is seeking to enable informed decisions why its 
> participants, and this helps to avoid claims of entrapment. It should 
> be noted that the absence of an IPR disclosure is not a guarantee that 
> no IPR exists, but the presence of a disclosure allows everyone to see 
> the licensing terms. In deciding whether to support or deny 
> continuation of technical work in the presence of an IPR disclosure, 
> individuals (or their companies) will want to consider whether they 
> think the IPR actually covers the technical work, whether it is 
> enforceable, and whether they consider the licensing terms to be 
> favourable. They will also need to consider the cost-benefit of the 
> various options that exist. No-one else can make these decisions for you!
>
> May I also take this opportunity to ask you all to look at the IETF's 
> IPR policy. In particular, can I remind you all about the policy with 
> respect to IPR that you know about as described in RFC 3979 and RFC 
> 4879. All document authors and contributors to discussions need to be 
> aware of their personal commitments to disclose IPR as expressed in 
> those two RFCs.
>
> Thanks,
> Adrian
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Tim Winter <[email-masked]>
Date: Fri, 12 Feb 2010 11:37:22 -0500

I believe we should go ahead, and share Kris' opinion that Cisco's polices seem
reasonable.  Given these terms, I do not think that it is necessary to re-engineer
RPL for the express intent of avoiding possible Cisco IPR.  Further, I would like to
encourage others to continue to disclose any claims to IPR that relates to the
activities of this WG as per IETF policy.

Regards,

-Tim

---

From: Philip Levis <[email-masked]>
Date: Fri, 12 Feb 2010 08:55:04 -0800

> activities of this WG as per IETF policy.

I agree with Tim and Kris. In this space, it's inevitable that almost any reasonable design will touch on someone's IPR. If we re-engineer RPL to avoid Cisco's, all we'll do is more greatly impinge on someone else's, under much less kind terms.

Phil

---

From: Richard Kelsey <[email-masked]>
Date: Sat, 13 Feb 2010 06:46:47 -0500

> From: Philip Levis <[email-masked]>
> Date: Fri, 12 Feb 2010 08:55:04 -0800
> 
> I agree with Tim and Kris. In this space, it's inevitable that almost
> any reasonable design will touch on someone's IPR. If we re-engineer
> RPL to avoid Cisco's, all we'll do is more greatly impinge on someone
> else's, under much less kind terms.

There are strong arguments for why we should continue with
RPL, but I do not think that this is one of them.  Why would
the existence of Cisco IPR covering RPL make it any less
likely that there is other IPR covering it?

                                      -Richard
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.