IETF Logo Mail Archive

Re: RFC3979bis section 7 -- hierarchy of preference for licensing

Stephan Wenger <stewe@stewe.org> Tue, 13 August 2013 21:13 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: ipr-wg@ietfa.amsl.com
Delivered-To: ipr-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D74E21F9DBA for <ipr-wg@ietfa.amsl.com>; Tue, 13 Aug 2013 14:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTnLO5yxvwpk for <ipr-wg@ietfa.amsl.com>; Tue, 13 Aug 2013 14:13:00 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A021F9D7B for <ipr-wg@ietf.org>; Tue, 13 Aug 2013 14:12:59 -0700 (PDT)
Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB190.namprd07.prod.outlook.com (10.242.167.139) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 21:12:57 +0000
Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.108]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.108]) with mapi id 15.00.0731.000; Tue, 13 Aug 2013 21:12:57 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing
Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing
Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmTVpCA//+SLACAAHppgP//yrkA
Date: Tue, 13 Aug 2013 21:12:57 +0000
Message-ID: <CE2FED23.A0B6E%stewe@stewe.org>
In-Reply-To: <520A6B91.4020705@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [71.202.147.60]
x-forefront-prvs: 0937FB07C5
x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(189002)(479174003)(377454003)(57704003)(51704005)(199002)(74662001)(77096001)(83322001)(74706001)(74366001)(76796001)(50986001)(53806001)(76786001)(49866001)(77982001)(80976001)(74876001)(19580395003)(54316002)(56776001)(65816001)(19580405001)(63696002)(59766001)(56816003)(36756003)(80022001)(54356001)(47736001)(31966008)(4396001)(47976001)(16406001)(76176001)(66066001)(79102001)(76482001)(69226001)(51856001)(47446002)(83072001)(81542001)(46102001)(74502001)(81342001)(81686001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB190; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2F0D99D76F6E5C40A662246ECFBE9632@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Cc: Barry Leiba <barryleiba@computer.org>, "ipr-wg@ietf.org" <ipr-wg@ietf.org>
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 13 Aug 2013 21:13:05 -0000

Hi Peter,

On 8.13.2013 10:23 , "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

>On 8/13/13 11:05 AM, Stephan Wenger wrote:
>> Barry,
>> Your formulation is certainly more accessible.  I'm fine with it.
>
>Agreed.
>
>Formatting aside, is that hierarchy of options complete and accurate? It
>looks fine to me and consistent with our "running code" in these
>matters. 

That's what I aimed for.  Not being creative, but simply reflecting what
has been going on for years.

>I wonder: do we need to specify a bit more what we mean by
>"open-source-friendly non-assert terms"?

In my original email I recommended against an attempt to be more specific
in defining RAND.  The same thought applies here.

The term "non-assert term", in the context of Section 7, is, I believe,
well understood and does not need further explanation or description.

What is "open-source friendly" is not up to the IETF to decide.  It is to
be decided by the open source communities, each of which may well have
their own criteria and may well arrive at different conclusions for the
same disclosure text.  And whether they are right or wrong in their
assessment is ultimately to be decided the courts.

>
>Peter
>
>-- 
>Peter Saint-Andre
>https://stpeter.im/
>
>

v2.23.0 | Report a Bug | By Email