Re: [Roll] Roll IPR issues

Geoff Mulligan <geoff@proto6.com> Wed, 10 February 2010 16:11 UTC

Return-Path: <geoff@proto6.com>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E223A7740 for <roll@core3.amsl.com>; Wed, 10 Feb 2010 08:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMlQP9mZ3xy7 for <roll@core3.amsl.com>; Wed, 10 Feb 2010 08:11:12 -0800 (PST)
Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id 975C33A7207 for <roll@ietf.org>; Wed, 10 Feb 2010 08:11:12 -0800 (PST)
Received: from server1.coslabs.com (unknown [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 713C81808A; Wed, 10 Feb 2010 09:12:23 -0700 (MST)
Received: from [192.168.174.133] ([12.190.142.90]) by server1.coslabs.com (8.13.6/8.13.6) with ESMTP id o1AGCMFs019385; Wed, 10 Feb 2010 09:12:22 -0700 (MST)
From: Geoff Mulligan <geoff@proto6.com>
To: Dan Lang <dlang@cisco.com>
In-Reply-To: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com>
References: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com>
Content-Type: text/plain
Date: Wed, 10 Feb 2010 09:12:16 -0700
Message-Id: <1265818336.3895.12.camel@dellx1>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 7bit
Cc: roll@ietf.org
Subject: Re: [Roll] Roll IPR issues
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 16:11:18 -0000

Dan,
  thanks for the information.  this is somewhat helpful.

are there some ietf documents that are not early stage drafts that are
standards track that have this licensing (your list didn't include any)?

I would like to understand the impact on RPL should the WG decide that
we'd like to avoid the IPR.  From what you said, it seems that this is
not possible to determine. Then I only wish that we had known about the
IPR encumbrance earlier in the process. 	geoff

On Tue, 2010-02-09 at 23:45 -0800, Dan Lang wrote:
> Hi All:
> 
> I understand that several people on this mailer have raised questions
> about Cisco's IPR commitment for RPL, and about which Cisco patents
> cover which parts of the RPL specification.  I'll address both of
> these
> points below.  First, a disclaimer:  Even though I am a lawyer for
> Cisco, I am not giving you legal advice;  that can only come from your
> own legal counsel.  
> 
> Preliminarily, all standards organizations grapple in some way with
> IPR
> issues because formulating a standard often involves incorporating the
> intellectual property of one or more participants.  In some
> organizations such as the ITU and IEEE, virtually all the contributors
> simply commit to license their essential IPR on reasonable and
> non-discriminatory terms, leaving themselves free to to later charge
> royalties that are not exactly specified.  Other organizations such as
> the W3C insist that IPR be licensed on a royalty-free basis.  The IETF
> for its part does not have a royalty-free requirement and there is a
> range of licensing commitments that are used by participants. 
> 
> Turning now to RPL, the exact language of Cisco's commitment is at
> http://www.ietf.org/ietf-ftp/IPR/cisco-ipr-draft-dt-roll-rpl-01.txt.
> This is a legal statement and again, although IAAL, remember that I am
> not your legal counsel, so my comments are here to help you understand
> some of the underlying issues and not to provide an interpretation.
> I'll focus on the issues that people have asked about.  
> 
> First, Cisco promises not to sue anyone for products that implement
> the
> standard under any of its essential patents.  Even though Cisco lists
> several patents and patent applications in its disclosure, its promise
> not to sue is not limited to those patent assets, but to *any* Cisco
> essential patents.  In contrast to this promise to not assert patents,
> many participants in other IETF WGs have made commitments that allow
> for
> royalty-bearing licenses on their disclosed IPR. 
> 
> Second, Cisco has a "defensive suspension" provision, which allows
> Cisco
> to assert those essential patents against someone who asserts their
> own
> patent (whether or not related to RPL) against Cisco ("...Cisco
> retains
> the right to assert its patents (including the right to claim past
> royalties) against any party that asserts a patent it owns or controls
> (either directly or indirectly) against Cisco or any of Cisco's
> affiliates or successors in title or against any products of Cisco or
> any products of any of Cisco's affiliates either alone or in
> combination
> with other products").  The wording of our statement may seem complex
> to
> a lay reader, but in fact similar statements are commonly used by
> other
> IETF participants.  Here are some examples that are similar, if not
> exactly identical to, Cisco's defensive suspension terms:
> 
> https://datatracker.ietf.org/ipr/1173/  (Juniper)
> https://datatracker.ietf.org/ipr/1254/  (Huawei)
> https://datatracker.ietf.org/ipr/1244/  (Ericsson)
> https://datatracker.ietf.org/ipr/947/  (H3C Technology)
> https://datatracker.ietf.org/ipr/1170/  (Vidyo)
> https://datatracker.ietf.org/ipr/1253/  (Verizon)
> https://datatracker.ietf.org/ipr/1235/  (Apple)
> https://datatracker.ietf.org/ipr/674/  (Digital Fountain)
> https://datatracker.ietf.org/ipr/935/  (Avaya)
> 
> Indeed, there are numerous I-Ds and RFCs that have progressed and
> succeeded with this type of statement even where there may be patent
> coverage.  The majority of Internet technologies are patented, some
> under more onerous licensing conditions than ours above, and have been
> deployed successfully for years.  
> 
> 
> We see the practice of making this kind of declaration (combining our
> commitment to not assert and the "defensive suspension") on the vast
> majority 
> of IETF I-Ds and RFCs where we have essential patents as being both 
> generous and effective in driving open standards and the development
> of the Internet.
>   The IETF and Cisco have extensive positive experience with this
> style of statement,
> gathered over years of development, deployment, and use.
> 
> Finally, questions have been raised on the mailer about which portions
> of the specification are covered by Cisco patents.  It is natural to
> be
> interested in this question but we have good reasons for not answering
> it.  Infringement analysis and claim construction are legal questions
> which are best answered by your own legal advisers and not by Cisco
> lawyers or engineers.   Furthermore, if even if we presented our own
> current views
>  they would not reflect later changes in patent claims during
> prosecution or even changes in the
> specification.   
> 
> I hope that this helps clarify the issues and move the discussion to
> resolution.
> 
> Best regards,
> 
> Dan Lang
> 
> 
> 
> 
> 
> 
> Dan Lang
> Director, Intellectual Property
> Legal Services
> Cisco Systems, Inc.
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll