RFC3979bis section 7 -- hierarchy of preference for licensing

Stephan Wenger <stewe@stewe.org> Tue, 13 August 2013 16:19 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 3AB6721F8EB5 for <ipr-wg@ietfa.amsl.com>; Tue, 13 Aug 2013 09:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YXQNmhVpIvjR for <ipr-wg@ietfa.amsl.com>; Tue, 13 Aug 2013 09:19:30 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id B516621F8EFE for <ipr-wg@ietf.org>; Tue, 13 Aug 2013 09:19:30 -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 16:19:29 +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 16:19:28 +0000
From: Stephan Wenger <stewe@stewe.org>
To: "ipr-wg@ietf.org" <ipr-wg@ietf.org>
Subject: RFC3979bis section 7 -- hierarchy of preference for licensing
Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing
Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gA==
Date: Tue, 13 Aug 2013 16:19:27 +0000
Message-ID: <CE30292A.A0AE7%stewe@stewe.org>
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:(189002)(199002)(53754006)(16406001)(80976001)(16236675002)(4396001)(47976001)(31966008)(76176001)(81542001)(83072001)(47446002)(561944002)(81342001)(74502001)(81686001)(46102001)(54356001)(47736001)(51856001)(66066001)(79102001)(69226001)(76482001)(74366001)(76786001)(50986001)(74706001)(74662001)(77096001)(53806001)(83322001)(59766001)(80022001)(56816003)(63696002)(36756003)(74876001)(77982001)(49866001)(54316002)(76796001)(65816001)(56776001)(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: multipart/alternative; boundary="_000_CE30292AA0AE7stewesteweorg_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.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 16:19:40 -0000

Hi all,

In Berlin's IPR BOF, one of the topics discussed was language in section 7.  I had specific comments, and was asked to provide input on the list.  In the process of composing my input, I noted that a section 7 has a number of issues that could benefit from clarifications or modifications that go beyond editorial input.  I had some private discussions with Scott and Jorge, and was asked by them to provide input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concerning this section.

To set context, section 7 is arguably one of the more important sections in the RFC3979, because it covers the application of the IETF IPR policy in the day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologies in IETF Working Groups".  It explains, among other things, how working groups can react to received IPR disclosures.  (Note that RFC3979 covers only WGs, and not other IETF bodies, such as the IESG or individuals ADs or whatever-none of these are currently mentioned-but I believe that Jorge and Scott will fix that bug in the next revision).

This post is about the first sentence of RFC 3979, which reads:

In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing.

I propose to replace this sentence with:

In general, to solve a given problem, the IETF prefers technologies with no known IPR over technologies with IPR claim(s) against them.  With respect to technologies with IPR claim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z), over technologies offered under reasonable and non-discriminatory terms but possibly incurring royalties (RAND), over technologies with IPR against them where the terms are non-RAND or, in the worst case, where the IPR is declared as being not licensable.

I believe that the above change reflects reality in the IETF at large as of 2013, and obviously only to the point I have insight.  I believe that the RFC3979 text does not reflect reality as of 2013.

The perhaps most important change is to acknowledge the existence of a (free and) open source ecosystem which, in at least some cases, has difficulties in accepting technologies for which bi-lateral licenses need to be signed, regardless of whether those licenses are royalty-free or not or whether unlicensed use of the technology generally is tolerated even if it were against the text of the disclosure. Let me also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories mentioned above, including the final one.

The list of categories could easily be extended, especially with respect to the broad "open-source friendly non-assert" part.  However, doing so meaningfully would quite likely require references to licensing schemes supported by certain open source "camps", and I do not believe that the IETF needs to go down to that granularity, nor could I stand the flame wars that would likely break out.  So I tried to keep it simple by saying that there is something "better" from an adoption viewpoint than RANDZ, but "worse" than IPR-claim-free, without going into details.

I also stayed away from defining "RAND".  I mentioned RAND a because the vast majority of IETF disclosures mention RAND for reasons that are known to the disclosers, the requirement for reasonable and non-discriminatory licensing is commonly believe to offer some protection, even if the amount of protection offered is currently unclear, and because RAND is a requirement for normative down referencing to many other SDOs.  I do not believe that the cumulative expertise of this list has the expertise--let alone the authority--to define the term RAND.

Thanks for your consideration of my proposal.

Stephan