Re: Normatively referenced specifications

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 18 December 2013 18:18 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipr-wg@ietfa.amsl.com
Delivered-To: ipr-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65D31AE0B1 for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 10:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 yjkdLZ7KmcNX for <ipr-wg@ietfa.amsl.com>; Wed, 18 Dec 2013 10:18:39 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5B1AE0A6 for <ipr-wg@ietf.org>; Wed, 18 Dec 2013 10:18:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F2E4D1DD4E0; Wed, 18 Dec 2013 10:18:37 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-17.clppva.east.verizon.net [70.106.135.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9FDD21C0DA5; Wed, 18 Dec 2013 10:18:31 -0800 (PST)
Message-ID: <52B1E6F0.5060808@joelhalpern.com>
Date: Wed, 18 Dec 2013 13:18:24 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dcrocker@bbiw.net, "Dale Mohlenhoff (dmohlenh)" <dmohlenh@cisco.com>, SM <sm@resistor.net>, "Black, David" <david.black@emc.com>
Subject: Re: Normatively referenced specifications
References: <CED46C85.AC4EC%stewe@stewe.org> <6.2.5.6.2.20131217001052.0c5bff98@resistor.net> <8D3D17ACE214DC429325B2B98F3AE712026ECD3A9B@MX15A.corp.emc.com> <6.2.5.6.2.20131218001051.0c266ed0@resistor.net> <CED70C71.119D0%dmohlenh@cisco.com> <52B1CF27.3010905@joelhalpern.com> <52B1DE0C.8010201@dcrocker.net>
In-Reply-To: <52B1DE0C.8010201@dcrocker.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ipr-wg@ietf.org" <ipr-wg@ietf.org>
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipr-wg/>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2013 18:18:41 -0000

THe part that is relevant to this discussion are the IPR licensing terms 
stated by folks in conjunction with our policy.
And yes, they can make broader grants about other specifications when 
they provide those licenses, but from an IETF perspective what folks 
look at, and what we are discussing, is the licensing terms for use in 
the specification.

Yours,
Joel

On 12/18/13 12:40 PM, Dave Crocker wrote:
> On 12/18/2013 8:36 AM, Joel M. Halpern wrote:
>> Dale, your interpretation is exactly the opposite of what I thought
>> Dave was saying. Referencing a spec normally does not and ought not
>> mean that the referencers IPR rules apply to the referenced
>> specification.  They can't, since in the abstract the referencer has
>> no control over the IPR grants of the referenced document.
>>
>> And IETF IPR grants apply when implementing IETF RFCs, even when
>> those RFCs are implemented in conjunction with some other
>> specification.  The IPR grants don't apply (as I understand it all
>> bets are off) if you modify the spec.
>>
>> Equally, the IETF can not insist that our IPR rules apply to a spec
>> we reference.
>
>
> I think this confuses the nature of what our disclosure rules mean. For
> example, they don't mean that we are affecting some other standards
> group.  Rather they affect decision-making within the IETF.
>
> So, absent a clear consensus from legal experts who are familiar with
> the IETF's IPR rules, I disagree with Joel's assessment.
>
>
> As I just posted on rtcweb:
>
>> Normative language in a specification defines the syntax and
>> semantics of the thing being specified.
>>
>> It does not make much sense to handle IPR differently for normative
>> text that includes details by reference (citation) rather than by
>> inline explication.  In terms of the syntax and semantics, the
>> specification is an integrated whole.
>>
>> If there is an legal distinction between inline normative reference,
>> versus citation-based inclusion, which is relevant to the
>> interpretation of IETF IPR rules, then some lawyers should provide
>> the community with expert opinions on the matter.
>>
>> Absent a clear and compelling presentation from legal experts, common
>> sense needs to prevail in the IETF's interpretation of its rules.
>>
>> Our rule is quite simple:  participation obligates disclosure.
>
>
> Here's a simple example:
>
>    Assume I own a patent on a component technology that has been
> published somewhere other than the IETF.  The organization publishing
> that specification did not require me to divulge my intellectual
> property claims.
>
>    I now participate in an important IETF effort that considers
> including the component technology, by citing it normatively.  I of
> course, work vigorously to get the IETF to adopt the technology, but no
> one know that I stand to make serious money if the technology is included.
>
> Given the intent behind the IETF's IPR rules, it makes no sense to allow
> me to participate without divulging my IPR interest in the topic.
>
> d/