Re: [Roll] Roll IPR issues

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 10 February 2010 16:36 UTC

Return-Path: <adrian@olddog.co.uk>
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 4B9EF3A774F for <roll@core3.amsl.com>; Wed, 10 Feb 2010 08:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 GHZsRNYWw9DL for <roll@core3.amsl.com>; Wed, 10 Feb 2010 08:36:25 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id A61D73A7709 for <roll@ietf.org>; Wed, 10 Feb 2010 08:36:24 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1AGbIYZ023484; Wed, 10 Feb 2010 16:37:23 GMT
Received: from your029b8cecfe (62-50-195-17.client.stsn.net [62.50.195.17]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1AGbGk0023454; Wed, 10 Feb 2010 16:37:17 GMT
Message-ID: <C46BCFD4A6094FCF8DDD33C1D930C6D6@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Geoff Mulligan <geoff@proto6.com>, Dan Lang <dlang@cisco.com>
References: <93EFA7F9-39AB-4ACE-8E33-9F30D0FC0EA7@cisco.com> <1265818336.3895.12.camel@dellx1>
Date: Wed, 10 Feb 2010 16:37:08 -0000
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: roll@ietf.org
Subject: Re: [Roll] Roll IPR issues
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
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:36:26 -0000

Hi,

If you go to https://datatracker.ietf.org/ipr/search/ you can enter "Cisco" 
in the keyword search.

You will see a list of drafts and RFCs for which Cisco have disclosed IPR 
and for which they have notified about their license terms.

There are some examples in the routing area, for example RSVP-TE and LDP for 
MPLS networks (widely deployed), BFD (deployed and currently being discussed 
by the BFD WG).

Cheers,
Adrian

----- Original Message ----- 
From: "Geoff Mulligan" <geoff@proto6.com>
To: "Dan Lang" <dlang@cisco.com>
Cc: <roll@ietf.org>
Sent: Wednesday, February 10, 2010 4:12 PM
Subject: Re: [Roll] Roll IPR issues


> 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
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>