Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")

Pete Resnick <presnick@qti.qualcomm.com> Fri, 29 April 2016 19:59 UTC

Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3F12D10E for <ietf@ietfa.amsl.com>; Fri, 29 Apr 2016 12:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.017
X-Spam-Level:
X-Spam-Status: No, score=-8.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 KywKezwR7-3Y for <ietf@ietfa.amsl.com>; Fri, 29 Apr 2016 12:59:04 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D5B12D0DF for <ietf@ietf.org>; Fri, 29 Apr 2016 12:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1461959940; x=1493495940; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=YMC7RobgRNsW3CIYzuTx0t0FGFS8FNYSYdaH34W/O5o=; b=CnsBwE8yZA35JCw1T0ITfnizO6D3upFv6SxP+n/6cLGKwXtbSLuCZGUT kkCPzAOxJeeeMX4ZzWRLD5WTUktxOCTs1CxPyq5VO14AtV+u2to/mco3O BpdBFAr96LknM3Mbpmls0XFV9HeyFx8OTKWFM8FZDTDROvG/O85aLi8mZ U=;
X-IronPort-AV: E=Sophos;i="5.24,553,1455004800"; d="scan'208";a="284547520"
Received: from ironmsg02-l-new.qualcomm.com (HELO ironmsg02-L.qualcomm.com) ([10.53.140.109]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 12:59:00 -0700
X-IronPort-AV: E=McAfee;i="5700,7163,8150"; a="687220188"
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Apr 2016 12:59:00 -0700
Received: from [10.64.161.242] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 29 Apr 2016 12:58:59 -0700
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Stephan Wenger <stewe@stewe.org>
Subject: Re: Last Call on draft-bradner-rfc3979bis-08.txt ("Intellectual Property Rights in IETF Technology")
Date: Fri, 29 Apr 2016 14:58:58 -0500
Message-ID: <9AFC22D7-C509-4765-AAC9-3096F188C4C6@qti.qualcomm.com>
In-Reply-To: <EC4CBF0D-1B7C-4FB5-85EA-E622B24E9B9A@stewe.org>
References: <0000431F-F977-4A24-BA4D-064F740977A0@piuha.net> <E7E31E22-1C86-40C4-BC5B-F65132015EF5@qti.qualcomm.com> <6CA3C554-0FF6-4779-80B9-C75698FB61C1@piuha.net> <EC4CBF0D-1B7C-4FB5-85EA-E622B24E9B9A@stewe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5239)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dFzf67eQsgZjl_7s_KEOkI9b4uc>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2016 19:59:07 -0000

On 25 Apr 2016, at 16:31, Stephan Wenger wrote:

> On 4/25/16, 13:15, "ietf on behalf of Jari Arkko" 
> <ietf-bounces@ietf.org on behalf of jari.arkko@piuha.net> wrote:
>
>>
>>> - Section 5.5(C): Two things:
>>>
>
> [...]
>
>>> OLD
>>>      must ensure that such
>>>      commitments are binding on any subsequent transferee of the
>>>      relevant IPR.
>>> NEW
>>>      must ensure that such commitments are binding on a transferee 
>>> of
>>>      the relevant IPR, and that such transferee will use reasonable
>>>      efforts to ensure that such commitments are binding on a
>>>      subsequent transferee of the relevant IPR, and so on.
>>> END
>>>
>>> The object of the "subsequent" wasn't clear, so this just spells it 
>>> out. Wordy, but more precise.
>>
>> Right
>
> I’m not sure I agree that the object of “subsequent wasn’t clear 
> from context.  However, I don’t mind to see that fixed if others 
> feel so.  However, the fix as proposed sets a very low standard 
> (reasonable efforts) for ensuring that subsequent transferees are 
> bound. That a substantial change from the WG consensus, and IMO in the 
> wrong direction.

Let's be clear that there was no "WG consensus" on this, since there was 
no WG. But let's assume that the consensus of the BoF was for something 
strong.

I disagree that "use reasonable efforts to ensure" is such a low 
standard, and the stronger language you propose concerns me:

> What we want to achieve is that if A assigns a patent to B, B and all 
> further transferees (B to C, C to D, etc. etc.) are similarly bound.  
> We want to make sure if any of these entities doesn’t feel bound for 
> whatever reason, the patent is held unenforcible by a well-informed 
> court.  It’s clear that this is much more onerous to the 
> rightholder, and may well lower the value of the IPR.
>
> I would be fine if the NEW part would be reworded as follows:
> NEW
>       must ensure that such commitments are binding on a transferee of
>       the relevant IPR, and also binding on any subsequent transferees
> of the relevant IPR.
> END

This seems to require that if my IPR is transferred 20 times over 20 
years, I am on the hook in perpetuity to absolutely make sure that the 
next person down the line sticks to the agreement. I'm certainly willing 
to make *reasonable* efforts to do so, and it will be up to a court to 
determine if my efforts were reasonable, but I certainly don't want to 
be forced to completely indemnify to 21st person down the line. "Use 
reasonable efforts to ensure" seems reasonable. Otherwise, it's not 
clear to me what I'm signing up to.

>>> - Section 7, paragraph 6:
>>>
>>> The only change in this paragraph from 3979 was to add the word 
>>> "all" in the second-to-last sentence. My lawyer friends tell me that 
>>> this little change is opening a can of worms, having to do with 
>>> licensing to makers of parts instead of implementers of the whole 
>>> specification. I don't think we meant to change the meaning from the 
>>> 3979 meaning, and I certainly don't think that we meant to change 
>>> some implication about whether folks in general needed to license to 
>>> people that make parts where they wouldn't have before. Was there 
>>> something unclear about that sentence that needed the word "all" 
>>> added to it? We aren't making a substantive change, are we? Can we 
>>> just strike it? It seemed pretty clear to me before.
>>
>> Agree
>
> I’m not sure here.
> For context, the paragraph is in section 7 of RFC3979bis (which used 
> to be the second paragraph of section 8 of RFC3979).  The sentence in 
> question describes an purported IETF consensus established in 
> pre-RFC3979 times, as follows (the critical and new “ALL” is 
> capitalized):
>
> “
> An IETF consensus has developed that no mandatory-to-implement 
> security technology can be specified in an IETF specification unless 
> it has no known IPR claims against it or a royalty-free license is 
> available to ALL implementers of the specification unless there is a 
> very good reason to do so.
> “

Right, the only change between 3979 and the above is the addition of the 
word "ALL" (not in all caps in 3979bis).

> I agree that the tightened language removes an arguably unclear 
> loophole that has been present in RFC3979, and which Pete’s 
> lawyer-friends probably would like to preserve.  However, generally 
> speaking, removing loopholes like this is a Good Thing, unless the 
> consensus at the time was such that there ought to be a loophole.  I 
> did not follow the consensus process in sufficient detail to have an 
> opinion, but perhaps security and IPR conscious folks in the IETF 
> remember?

Wait, what "arguably unclear loophole" do you think was there that 
adding "all" in the above sentence tightens? Calling it a "loophole" 
implies that somehow the IETF intention was to disallow something that 
the current text allows. What is that something that you think we ought 
to be removing?

I know that my lawyer friend was concerned not about security technology 
per se, but the issue of licensing levels more generally. I'm pretty 
sure we only wanted to talk about requiring royalty-free licensing for 
security protocols specifically and never intended to require particular 
kinds of licensing across the board. Either way, I think that the 
original text was perfectly clear and had no loopholes.

So, why are we adding "all"? What loophole are we trying to close? If 
there is none, let's strike "all" and use the original text.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478