Re: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled

Toke Høiland-Jørgensen <toke@redhat.com> Thu, 04 July 2019 12:08 UTC

Return-Path: <toke@redhat.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C361204C2 for <tsvwg@ietfa.amsl.com>; Thu, 4 Jul 2019 05:08:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1BajLamV5DK for <tsvwg@ietfa.amsl.com>; Thu, 4 Jul 2019 05:08:09 -0700 (PDT)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B0E12004F for <tsvwg@ietf.org>; Thu, 4 Jul 2019 05:08:09 -0700 (PDT)
Received: by mail-ed1-f41.google.com with SMTP id p15so5198194eds.8 for <tsvwg@ietf.org>; Thu, 04 Jul 2019 05:08:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=zQ89nPmCnb5tSfgxpkPpH4B7C/TOhq+f0L8ObuhkOsI=; b=puy7A+7cy9vRAHkwwDMkDtQ1gRqmcUIvPuYcnhhwRWEhmoi4mgE6pk2ilAOJwBPe1k fZYv8734rmIv2Mm52gTkIV9jOCp/+k0yDtAddcB0XQvr97PhDyP1fjMVacD5lD1KkK6S NWrSXcezvHmUoKkGkVBtmLXjrHq6auy6T3XIDHnpDXLoSe7lfYrJjY+36I+wYHazJACh IWGZESWv9oxdvTdGZY8R5g7pgrpNnhyGJQ/HpLZE5C7nM0/dJKWNAYHxkMxDEgzUBQar aBkpcWaCWs5bqoYVRGVFs0acBrrpx3uiJfujFqEg1qbrpQJiNqRNxoOx11ldY7e7M4Tz hfRw==
X-Gm-Message-State: APjAAAWjigA8rF7SlYFE6b57fzOrC7qSPko3t/3WhrJq8feAE4hvKwAw qiCjnvIu5IS1XKxUlF3ItbaRLQ==
X-Google-Smtp-Source: APXvYqylz1OoqcbWatzc8UzTBp1Ud0CsycViJ0ZyDrH9akbEtClBJkbJ2SDCZr2SUmi8XxHqbmVAfg==
X-Received: by 2002:a05:6402:14d4:: with SMTP id f20mr47541552edx.125.1562242087607; Thu, 04 Jul 2019 05:08:07 -0700 (PDT)
Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id gr1sm805226ejb.19.2019.07.04.05.08.06 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 04 Jul 2019 05:08:06 -0700 (PDT)
Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 5F313181CA8; Thu, 4 Jul 2019 14:08:06 +0200 (CEST)
From: Toke Høiland-Jørgensen <toke@redhat.com>
To: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936305EA1E0@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D24327794936305EA1E0@MX307CL04.corp.emc.com>
X-Clacks-Overhead: GNU Terry Pratchett
Date: Thu, 04 Jul 2019 14:08:06 +0200
Message-ID: <87pnmq2eah.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ZGYM4WcfAFxEnKNRKM67fwOuPvA>
Subject: Re: [tsvwg] Summary: IPR Declarations on draft-ietf-tsvwg-aqm-dualq-coupled
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 12:08:13 -0000

"Black, David" <David.Black@dell.com> writes:

> As promised, this note summarizes the off-list discussions on this topic.
>
> The following summary is sent in my role as WG Chair, and is intended as guidance to the Working Group (WG):
>
>
>   1.  Background:
>
>   *   Section 7 of RFC 8179 and all of RFC 3669 are important background to this discussion of intellectual property concerns  - reading both of them before responding to this note is RECOMMENDED.
>   *   The two IPR Disclosures involved are 3561 and 3562 (https://datatracker.ietf.org/ipr/3561/ and https://datatracker.ietf.org/ipr/3562/).
>
>
>
>   1.  IPR Disclosures and IETF Technology Evaluation in general:
>
>   *   The IETF and the IESG in particular disclaim responsibility for evaluating IPR Disclosures.  WG participants are expected to reach their own conclusions, consulting their own legal counsel if/as appropriate.
>   *   IPR Disclosures, including license terms, are inputs to WG evaluation of technology.  WG evaluation of technology is expected to be broad, considering all factors, and not tightly focused on license terms or IPR Disclosures.
>   *   An important factor for the WG to consider is applicability of the patent to the technology of interest to the WG - see Section 5.5 of RFC 3669.   That factor is left for the WG to discuss further as part of WG evaluation of technology.
>   *   The WG mailing list is an important forum for WG activity, hence discussion of license terms on the mailing list as part of WG evaluation of technology is acceptable.
>
>
>
>   1.  The IPR Disclosures on the aqm-dualq-coupled draft and the concern that led to the off-list discussion:
>
>   *   The license terms involved in the original concern are called "Defensive Suspension" or "Defensive Termination" - e.g., see https://en.wikipedia..org/wiki/Defensive_termination.
>   *   The original concern involves the broad scope of the "Defensive Suspension" terms in the IPR Disclosures, specifically that Defensive Suspension is triggered by assertion of any patent(s) whatsoever against the patent holder.
>   *   Perusal of recent IPR disclosures to the IETF (see https://datatracker.ietf.org/ipr/#specific) indicates that similar Defensive Suspension terms are common.
>   *   The WG remains free to evaluate the degree of acceptability (or lack thereof) of these Defensive Suspension terms to this specific WG for this specific technology as part of overall WG evaluation of technology.
>
> A number of additional topics were raised in the off-list discussion but no conclusions were drawn.   Participants in that discussion may (and are likely to) bring those topics to the list for further discussion.

Yes, thank you for the summary David. To expand on my concerns re: the
termination clause:

Termination provisions in licenses vary in a number of ways, including
the breadth of and the types of actions that can trigger termination,
and the scope of what is terminated. Termination provisions are often
found in royalty-free patent licenses, including some open source
licenses (one widely used example:
https://www.apache.org/licenses/LICENSE-2.0), as well as in
standards-related licenses and commitments.

Standards activities with patent rules that specifically seek to foster
royalty-free solutions typically describe or outline a required or
acceptable royalty-free commitment or license. These generally include a
termination provision where the trigger is limited action against the
standard. This avoids the possible use of a patent that is required in
order to implement the standard from being used as leverage in ways
unrelated to the standard, while permitting the termination to operate
in the interest of the standard (tending to discouraging patent action
against the standard).

These are two examples of such royalty-free patent policies; each
permits termination, with differing, but limited, triggers (same
standard, or any standard from the org, respectively):
https://www.oasis-open.org/policies-guidelines/ipr#licensing_req
https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements

As David pointed out, the IETF doesn't have such a patent policy, but
instead leaves IPR issues to be a matter of consideration, rather than
requirement, as is discussed in RFC 3669. Thus, please consider this
message as material for such consideration.

As I have earlier pointed out, the feature of IPR statement 3561 that I
have concerns about is that, even though the fee is zero, its
termination provision could still allow the patent to be used to
leverage the weight of the standard, not just the patented invention.

As termination provisions differ in their details, let me offer an example
of a scenario that illustrates the leverage potential that I see with this
particular termination provision. This scenario would play out by the
following sequence of events:

1. Holder of a patent on the standard says: the patent is licensed for
   free; but, if you assert any patent against me, your license
   terminates and, if the patent does apply to the standard, you may no
   longer implement the standard.

2. Holder also has other patents and it uses these to engage in various
   licensing activities.

3. Holder seeks license fees from Target. Target, which holds patents
   for defensive purposes, says: I have patents, too; I wasn't going to
   charge you anything, but, since you are demanding money from me,
   let's talk.

4. Holder is unhappy with the resulting talk and sues Target.

5. As a defensive matter, Target considers counter-suing Holder. But,
   now, Target must consider the cost of being required to stop shipping
   anything that implements the standard.

6. The result is that, even though the license price is zero, Holder
   remains able to leverage the value of being able to implement the
   standard, not just the value of whatever invention the patent was
   granted for.

>From an off-list message thread, I came to understand that Nokia views
the earlier RAND statement as not being replaced by the royalty-free
statement, but that both remain in effect. If this is the case, then
this would reduce the leverage provided by the broadly-triggered
termination provision, because one would not be excluded from
implementing the standard. With the continued availability of a RAND
license, while the RF license can go away and Holder is able to charge a
fee for practising the standard (in theory, the value of the patented
invention should be factored into the ultimate settlement), this is
better than being able to shut someone out from the standard. Thus, the
concern would be reduced.

I am expecting a statement to be made on this list concerning that
particular off-list point.


Finally, I'll add that while the scenario above is generic, I am mostly
concerned about ensuring any standard be palatable to upstream open
source projects. This has different implications depending on the
project, of course, and this email is already long enough that I won't
go into more detail about that now. Just wanted to include this point to
help make everyone understand where I'm coming from.

-Toke