Re: Proposed IESG Statement on IPR Declarations

John C Klensin <john-ietf@jck.com> Fri, 08 July 2016 17:57 UTC

Return-Path: <john-ietf@jck.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 76A1C12D124; Fri, 8 Jul 2016 10:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 FmdmhNUMBCTp; Fri, 8 Jul 2016 10:57:46 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8269D12D800; Fri, 8 Jul 2016 10:57:43 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bLa21-000Ob0-Bq; Fri, 08 Jul 2016 13:57:41 -0400
Date: Fri, 08 Jul 2016 13:57:36 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
Subject: Re: Proposed IESG Statement on IPR Declarations
Message-ID: <1AD48BA0EE02B8F72EA73EB8@JcK-HP8200>
In-Reply-To: <CALaySJJBmpz+LRWzB5EdGpvCgr3O7eX_2bDjFeMnJF68MrgNMg@mail.gmail.com>
References: <20160707202122.23634.18168.idtracker@ietfa.amsl.com> <CAC4RtVAEQfWN-xgtrDS0kKg6EV22hdskJKL++vsp80vi0XOjUA@mail.gmail.com> <69CA0FF8E7852A4C7C7947B5@JcK-HP8200> <CALaySJJBmpz+LRWzB5EdGpvCgr3O7eX_2bDjFeMnJF68MrgNMg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/E6re0qUYuoCEkSOwwpLQLqVWClA>
Cc: IETF discussion list <ietf@ietf.org>, IESG <iesg@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, 08 Jul 2016 17:57:49 -0000


--On Friday, July 08, 2016 13:05 -0400 Barry Leiba
<barryleiba@computer.org> wrote:

> On the third point...
> 
>> (3) When I heard that the IESG was planning an additional
>> statement in this area, I assumed it would address the one
>> recent claimed development that seemed to be a loose end --
>> whether someone who is listed as both an inventor and a
>> co-author on a document can possibly claim to not have
>> reasonably have personal knowledge of a possible or perceived
>> interaction between the two.   I think current version of BCP
>> 79 might actually be a tad weak there: such inventors not
>> disclosing because of (unpublished) hair-splitting that might
>> make the invention inapplicable is not in the community's
>> interest.  I think the intent of BCP 79 is (or should be) that
>> they disclose and, if appropriate, disclose why they don't
>> think there is an interaction.    Anything else just feels a
>> little sleazy and does not benefit either the IETF processes
>> or the inventor -- especially given the risk that the
>> inventor's company will later come along and try to enforce
>> the patent against users of the IETF's spec, disclosing only
>> after others build products or when the enforcement action is
>> started.  I think BCP 79 allows enough latitude for a formal
>> interpretation along those lines.  But this statement is
>> completely silent on the matter.
> 
> I agree that clarification of that is important, but I think
> it's entirely out of scope for an IESG statement, and, rather,
> something that has to be addressed by the BCP 79 update work.

We could quibble about where the boundary about clarifications
lies, especially given the language of 6701, but wfm.  But that
also suggests that, if _any_ additional clarification about the
rules, or pointers to them, are needed beyond what BCP 79 and
the Note Well already say, the substantive issues need to be
sorted out as part of that BCP 79 update discussion and that an
IESG statement is not a proper way to accomplish it.  It may
also suggest that key provisions of 6701 should be considered as
part of that BCP 79 effort.

   john