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
- [tsvwg] Summary: IPR Declarations on draft-ietf-t… Black, David
- Re: [tsvwg] Summary: IPR Declarations on draft-ie… Toke Høiland-Jørgensen
- Re: [tsvwg] Summary: IPR Declarations on draft-ie… De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Summary: IPR Declarations on draft-ie… Bob Briscoe