From housley@vigilsec.com Fri Aug 2 01:52:31 2013 Return-Path: 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 2EF6511E82DF; Fri, 2 Aug 2013 01:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 32QnbJyqfrB4; Fri, 2 Aug 2013 01:52:19 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 06ED711E82F9; Fri, 2 Aug 2013 01:48:50 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E1711F24082; Fri, 2 Aug 2013 04:49:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id uHOrXlMX0sFW; Fri, 2 Aug 2013 04:48:45 -0400 (EDT) Received: from v150.vpn.iad.rg.net (v150.vpn.iad.rg.net [198.180.150.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 35062F24038; Fri, 2 Aug 2013 04:49:18 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-64--158351121 Subject: IETF 87 IPRbis BOF evaluation Date: Fri, 2 Aug 2013 04:48:43 -0400 Message-Id: To: IESG IESG , IAB IAB Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Cc: Scott Bradner , IETF IPR WG X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:52:32 -0000 --Apple-Mail-64--158351121 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I attended the IPRbis BOF. The idea is to update the BCPs to = incorporate experience from the last 8 years. Jorge Contreras and Scott = Bradner had a list of proposed changes, and they were each discussed in = turn. The discussion was much more calm than the discussion in Orlando, = but this calmness did not allow review of all of proposed changes. As a = result, the BOF ended without a real conclusion. By impression is that = the I-D will be updated based on the ones that were discussed, and that = discussion is needed on the remaining proposed changes. I'd recommend a thread on each proposed change on the ipr-wg@ietf.org so = that there is a hope of getting this stuff done before the end of 2013. =20 Russ =20 --Apple-Mail-64--158351121 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
I attended the IPRbis BOF.  The idea is to update the BCPs to incorporate experience from the last 8 years.  Jorge Contreras and Scott Bradner had a list of proposed changes, and they were each discussed in turn.  The discussion was much more calm than the discussion in Orlando, but this calmness did not allow review of all of proposed changes.  As a result, the BOF ended without a real conclusion.  By impression is that the I-D will be updated based on the ones that were discussed, and that discussion is needed on the remaining proposed changes.

I'd recommend a thread on each proposed change on the ipr-wg@ietf.org so that there is a hope of getting this stuff done before the end of 2013.
 
Russ
 
 --Apple-Mail-64--158351121-- From scott.brim@gmail.com Fri Aug 2 02:25:31 2013 Return-Path: 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 426BC21F9BF1; Fri, 2 Aug 2013 02:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 gMrRofYxz86K; Fri, 2 Aug 2013 02:25:26 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5AE21E82E4; Fri, 2 Aug 2013 02:24:34 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id bi5so469914pad.8 for ; Fri, 02 Aug 2013 02:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ByLAoS3H8qapvBC6NHk85WqU2gGXUyWg/iftJgu8TZo=; b=FEFfb/Mibw5J+lYtsQ5zh3Hot8DpwGweMMWwdWeSDPHrkIv0XZAW++jS7zFhYGuUec duVabXKdmwjgL5ENta7UMSDyG5fqnkmDEC6+JHPhh4NzLBfMm7tdLxv+5wKEWLYw983U r8aFvFC/L8cnBXdrK3GRhT/g9XCBNhGDbHNX6UPK9hdMxwVRv3fwmcm4+JC08VvI/Gzi ccl52Ao39DhQ4ww3X+xMDlEFTnrKwfHNy0/MHxWwVmjkaqgifvMQ9GY0C2z1qGNjP9wb OZ4ltx39Ar26pkn59izNtchAVwMR2fEH8o580sdXqQNZ//tTZGjf/TE4A1wn3bcnwoU9 Eakg== X-Received: by 10.68.196.134 with SMTP id im6mr6635988pbc.110.1375435471652; Fri, 02 Aug 2013 02:24:31 -0700 (PDT) Received: from dhcp-1668.meeting.ietf.org ([2001:df8:0:16:6cdd:e68b:5d89:c8b1]) by mx.google.com with ESMTPSA id eq5sm9173729pbc.15.2013.08.02.02.24.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 02:24:30 -0700 (PDT) Message-ID: <51FB7ACA.4050605@gmail.com> Date: Fri, 02 Aug 2013 11:24:26 +0200 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Russ Housley Subject: Re: IETF 87 IPRbis BOF evaluation References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IAB IAB , IESG IESG , Scott Bradner , IETF IPR WG X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:25:31 -0000 On 08/02/13 10:48, Russ Housley allegedly wrote: > I attended the IPRbis BOF. The idea is to update the BCPs to > incorporate experience from the last 8 years. Jorge Contreras and Scott > Bradner had a list of proposed changes, and they were each discussed in > turn. The discussion was much more calm than the discussion in Orlando, > but this calmness did not allow review of all of proposed changes. As a > result, the BOF ended without a real conclusion. By impression is that > the I-D will be updated based on the ones that were discussed, and that > discussion is needed on the remaining proposed changes. > > I'd recommend a thread on each proposed change on the ipr-wg@ietf.org > so that there is a hope of getting this stuff > done before the end of 2013. What do you think about a "use cases and experience" replacement for 3669? If yes, I invite others to do it, since I won't get to it. From sob@harvard.edu Fri Aug 2 02:28:20 2013 Return-Path: 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 1199421E8269; Fri, 2 Aug 2013 02:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 TqQxJANWjwGq; Fri, 2 Aug 2013 02:28:02 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id ADA1111E812C; Fri, 2 Aug 2013 02:27:23 -0700 (PDT) Received: from exchange.university.harvard.edu (entwedge0000000.university.harvard.edu [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 7EE28E9451; Fri, 2 Aug 2013 05:27:19 -0400 (EDT) Received: from ENTWHUBT0000005.university.harvard.edu (10.32.208.51) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 2 Aug 2013 05:27:14 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.134]) by ENTWHUBT0000005.university.harvard.edu ([10.32.208.51]) with mapi id 14.03.0146.000; Fri, 2 Aug 2013 05:27:19 -0400 From: "Bradner, Scott" To: Scott Brim Subject: Re: IETF 87 IPRbis BOF evaluation Thread-Topic: IETF 87 IPRbis BOF evaluation Thread-Index: AQHOj13cjy41ktbsIku448S9OPMD+pmB6HwAgAAAzIA= Date: Fri, 2 Aug 2013 09:27:18 +0000 Message-ID: <29C80848-4FBF-4AEE-A99D-955AAF56FF62@harvard.edu> References: <51FB7ACA.4050605@gmail.com> In-Reply-To: <51FB7ACA.4050605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E69922E976CA44EACEA4643720946FD@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IAB IAB , IESG IESG , IETF IPR WG X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:28:21 -0000 that possibility came up during the BOF Scott Scott Bradner Harvard University Information Technology Innovation & Architecture +1 617 495 3864 1350 Mass Ave., Room 760 Cambridge, MA 02138 www.harvard.edu/huit On Aug 2, 2013, at 5:24 AM, Scott Brim wrote: > On 08/02/13 10:48, Russ Housley allegedly wrote: >> I attended the IPRbis BOF. The idea is to update the BCPs to >> incorporate experience from the last 8 years. Jorge Contreras and Scott >> Bradner had a list of proposed changes, and they were each discussed in >> turn. The discussion was much more calm than the discussion in Orlando, >> but this calmness did not allow review of all of proposed changes. As a >> result, the BOF ended without a real conclusion. By impression is that >> the I-D will be updated based on the ones that were discussed, and that >> discussion is needed on the remaining proposed changes. >>=20 >> I'd recommend a thread on each proposed change on the ipr-wg@ietf.org >> so that there is a hope of getting this stuff >> done before the end of 2013. >=20 > What do you think about a "use cases and experience" replacement for > 3669? If yes, I invite others to do it, since I won't get to it. > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-wg From tglassey@earthlink.net Fri Aug 2 08:00:05 2013 Return-Path: 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 D751911E80FA for ; Fri, 2 Aug 2013 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 4ri5lFmjGkJm for ; Fri, 2 Aug 2013 07:59:59 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55921F8C72 for ; Fri, 2 Aug 2013 07:59:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mZNnAE8db3PWea65zarS7DoDRLU14IT89t67/Dfj/9tYSFLU8kKa2LxJyqRxTgNg; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.1.102]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V5Gpi-0001Uj-7i for ipr-wg@ietf.org; Fri, 02 Aug 2013 10:59:58 -0400 Message-ID: <51FBC96C.7080003@earthlink.net> Date: Fri, 02 Aug 2013 07:59:56 -0700 From: tsg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipr-wg@ietf.org Subject: Re: IETF 87 IPRbis BOF evaluation References: <51FB7ACA.4050605@gmail.com> <29C80848-4FBF-4AEE-A99D-955AAF56FF62@harvard.edu> In-Reply-To: <29C80848-4FBF-4AEE-A99D-955AAF56FF62@harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d7b149be7fda7de09373fd1d94f76931350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:00:05 -0000 Scott/Chair/All - The real issue here is that IETF technology licenses are broader than the use recommendations are and that is the core-failing of the current model. Further there is no teeth in the IPR process because it cannot be used to pull technology or mitigate that publication-and-open-license-to-use after the publication. If anything is to be done about IPR then the licensing agreements need to be changed to address the following 3 (three) key issues: 1) Type of Use License must be specified so that if a USE RULES specification document is produced by any team and approved with the technology, that it will moderate the licensing rules. That is to say - a license must be supported that says IPR is more important that Creating Genesis here. IPR and the legal issues of who owns the IP are key to all aspects of this technology. As such the licensing must be included in the IP. 2) Any IPR controlled rights to IP produced inside any org like the IETF needs a formal withdrawal process and a mechanism to revoke use rights. 3) Licensing for use of IPR must (MUST) be able to control future use - meaning that the IETF one-way-publication-to-global-use-licensing models must be controllable under global IP law after AIA and the First to File changes in US Patent Law. Its no longer negotiable... Todd > that possibility came up during the BOF > > Scott > > Scott Bradner > > Harvard University Information Technology > Innovation & Architecture > +1 617 495 3864 > 1350 Mass Ave., Room 760 > Cambridge, MA 02138 > www.harvard.edu/huit > > On Aug 2, 2013, at 5:24 AM, Scott Brim > wrote: > >> On 08/02/13 10:48, Russ Housley allegedly wrote: >>> I attended the IPRbis BOF. The idea is to update the BCPs to >>> incorporate experience from the last 8 years. Jorge Contreras and Scott >>> Bradner had a list of proposed changes, and they were each discussed in >>> turn. The discussion was much more calm than the discussion in Orlando, >>> but this calmness did not allow review of all of proposed changes. As a >>> result, the BOF ended without a real conclusion. By impression is that >>> the I-D will be updated based on the ones that were discussed, and that >>> discussion is needed on the remaining proposed changes. >>> >>> I'd recommend a thread on each proposed change on the ipr-wg@ietf.org >>> so that there is a hope of getting this stuff >>> done before the end of 2013. >> What do you think about a "use cases and experience" replacement for >> 3669? If yes, I invite others to do it, since I won't get to it. >> _______________________________________________ >> Ipr-wg mailing list >> Ipr-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/ipr-wg > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-wg > -- // Standard "perasonal email" disclaimers apply From sob@sobco.com Fri Aug 2 02:08:16 2013 Return-Path: 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 E4A1511E82DA; Fri, 2 Aug 2013 02:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 TD25p7e56Do8; Fri, 2 Aug 2013 02:08:11 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 32D2811E8329; Fri, 2 Aug 2013 02:02:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id E90BA1AE9E9; Fri, 2 Aug 2013 04:55:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HORa3_KNvRI; Fri, 2 Aug 2013 04:55:07 -0400 (EDT) Received: from dhcp-1772.meeting.ietf.org (dhcp-1772.meeting.ietf.org [130.129.23.114]) by sobco.sobco.com (Postfix) with ESMTPSA id 911291AE9D9; Fri, 2 Aug 2013 04:54:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: IETF 87 IPRbis BOF evaluation From: Scott O Bradner In-Reply-To: Date: Fri, 2 Aug 2013 04:53:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Russ Housley X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Fri, 02 Aug 2013 10:12:44 -0700 Cc: IETF IPR WG , IAB IAB , IESG IESG X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:08:17 -0000 the only thing we did not get to was Harald's question on how IPR in = normative references=20 should be handled - we got basic consensus on all of what we thought = were the open issues Scott On Aug 2, 2013, at 4:48 AM, Russ Housley wrote: > I attended the IPRbis BOF. The idea is to update the BCPs to = incorporate experience from the last 8 years. Jorge Contreras and Scott = Bradner had a list of proposed changes, and they were each discussed in = turn. The discussion was much more calm than the discussion in Orlando, = but this calmness did not allow review of all of proposed changes. As a = result, the BOF ended without a real conclusion. By impression is that = the I-D will be updated based on the ones that were discussed, and that = discussion is needed on the remaining proposed changes. >=20 > I'd recommend a thread on each proposed change on the ipr-wg@ietf.org = so that there is a hope of getting this stuff done before the end of = 2013. > =20 > Russ > =20 From stewe@stewe.org Tue Aug 13 09:19:40 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:19:40 -0000 --_000_CE30292AA0AE7stewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_CE30292AA0AE7stewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <58BF7094C700E04BA7ECDD28DD8650C1@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,

In Berlin's IPR BOF, one of the topi= cs discussed was language in section 7.  I had specific comments, and = was asked to provide input on the list.  In the process of composing m= y 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-editoria= l) topics the list.  This is the first of a series of emails all concerning this section.

To set context, section 7 is arguabl= y 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 disclosure= s.  (Note that RFC3979 covers only WGs, and not other IETF bodies, suc= h as the IESG or individuals ADs or whatever-none of these are currently mentioned-but I believe that Jorge and Scott will f= ix that bug in the next revision).

This post is about the first sentenc= e of RFC 3979, which reads:

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

I propose to replace this sentence w= ith:

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-discriminator= y 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 lic= ensable.

I believe that the above change refl= ects reality in the IETF at large as of 2013, and obviously only to the poi= nt I have insight.  I believe that the RFC3979 text does not reflect r= eality 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 whic= h bi-lateral licenses need to be signed, regardless of whether those licenses are royalty-free or not or whether un= licensed use of the technology generally is tolerated even if it were again= st the text of the disclosure. Let me also note that we have (moderately) r= ecent 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 friendl= y non-assert" part.  However, doing so meaningfully would quite l= ikely require references to licensing schemes supported by certain open source "camps", and I do not believe that the IE= TF needs to go down to that granularity, nor could I stand the flame wars t= hat would likely break out.  So I tried to keep it simple by saying th= at there is something "better" from an adoption viewpoint than RANDZ, but "worse" than IPR-claim-free, without g= oing into details.

I also stayed away from defining &qu= ot;RAND".  I mentioned RAND a because the vast majority of IETF d= isclosures mention RAND for reasons that are known to the disclosers, the r= equirement 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 requirem= ent 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.<= /font>

Thanks for your consideration of my = proposal.

Stephan

--_000_CE30292AA0AE7stewesteweorg_-- From barryleiba.mailing.lists@gmail.com Tue Aug 13 09:38:29 2013 Return-Path: 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 89B2211E8199 for ; Tue, 13 Aug 2013 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.778 X-Spam-Level: X-Spam-Status: No, score=-101.778 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 K5MXGNfLjgTm for ; Tue, 13 Aug 2013 09:38:29 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D752C11E818C for ; Tue, 13 Aug 2013 09:38:28 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id b10so1259893vea.35 for ; Tue, 13 Aug 2013 09:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IgonK6oHum84+8ZpH6J8/9DrSz4HQNhsPjj3KaP2h3Y=; b=wQFBD7+bVWHbIo1qTm3D4a/q4+XH14k7ZxTLTnEjHykfVGRTEaoMkxG5pg0PDyLI7N vXD84w8zFvK2rGOaEFfxVJGOQ9tczjELBUC7+LCJht6MXiTf9lDJPDZSY91ut+4VwY+a n7J2vxfCzURevaTa4YQqlkzj++CQwAxdX22G7p7ePzKeunV7TceCnSOi+u/6JnKNo+RB Mg8FMuabzZQ1YWbmkp9bP6689Gz+tze7q7O2bqF0gmS3kjzJNVPqo/LPSkwGbWCdslWk wMaw2eSxCAmlyMeqkvHvCq+4vc+np61G/74gj/JlyBFdB8up1F7AkTMNQa4377N0rYhU qvbQ== MIME-Version: 1.0 X-Received: by 10.58.171.4 with SMTP id aq4mr5187108vec.26.1376411908157; Tue, 13 Aug 2013 09:38:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Tue, 13 Aug 2013 09:38:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 18:38:27 +0200 X-Google-Sender-Auth: trj_Salxhp3k2pf3aQ1Jav-ynW4 Message-ID: Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing From: Barry Leiba To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 16:38:29 -0000 > 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. Oh, my. Only a lawyer could love that. I find it entirely incomprehensible. Over, over, over. Over. Are you really trying to set up a hierarchy, wherein option A is preferred over B, and B is preferred over C, and so on? Then why not set it up that way, as a list? How's this?: ------------- 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 considers the following list of terms to be in decreasing order of preference: 1. open-source-friendly non-assert terms 2. reasonable and non-discriminatory royalty-free terms (RAND-Z) 3. technologies offered under reasonable and non-discriminatory terms but possibly incurring royalties (RAND) 4. technologies with IPR against them where the terms are non-RAND 5. the worst case, where the IPR is declared as being not licensable ------------- Barry From stewe@stewe.org Tue Aug 13 10:20:43 2013 Return-Path: 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 452D211E8172 for ; Tue, 13 Aug 2013 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 nepN9R-isEze for ; Tue, 13 Aug 2013 10:20:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1911E8150 for ; Tue, 13 Aug 2013 10:20:36 -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 17:05:27 +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 17:05:27 +0000 From: Stephan Wenger To: Barry Leiba Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmTVpCA//+SLAA= Date: Tue, 13 Aug 2013 17:05:26 +0000 Message-ID: In-Reply-To: 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)(51704005)(199002)(74662001)(77096001)(53806001)(83322001)(74366001)(74706001)(50986001)(76786001)(76796001)(74876001)(19580395003)(77982001)(49866001)(65816001)(56776001)(54316002)(36756003)(19580405001)(59766001)(63696002)(56816003)(80022001)(80976001)(31966008)(47976001)(4396001)(16406001)(66066001)(76482001)(69226001)(79102001)(51856001)(47446002)(76176001)(81542001)(83072001)(46102001)(47736001)(54356001)(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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:20:43 -0000 Barry, Your formulation is certainly more accessible. I'm fine with it. Stephan On 8.13.2013 18:38 , "Barry Leiba" wrote: >> 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. > >Oh, my. Only a lawyer could love that. I find it entirely >incomprehensible. Over, over, over. Over. > >Are you really trying to set up a hierarchy, wherein option A is >preferred over B, and B is preferred over C, and so on? Then why not >set it up that way, as a list? How's this?: > >------------- >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 >considers the following list of terms to be in decreasing order of >preference: > >1. open-source-friendly non-assert terms >2. reasonable and non-discriminatory royalty-free terms (RAND-Z) >3. technologies offered under reasonable and non-discriminatory terms >but possibly incurring royalties (RAND) >4. technologies with IPR against them where the terms are non-RAND >5. the worst case, where the IPR is declared as being not licensable >------------- > >Barry From stpeter@stpeter.im Tue Aug 13 10:23:40 2013 Return-Path: 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 04E9E11E8199 for ; Tue, 13 Aug 2013 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zh-dT8fxvgUd for ; Tue, 13 Aug 2013 10:23:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E316D11E8150 for ; Tue, 13 Aug 2013 10:23:34 -0700 (PDT) Received: from sjc-vpn5-2.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 28EC44010C; Tue, 13 Aug 2013 11:26:28 -0600 (MDT) Message-ID: <520A6B91.4020705@stpeter.im> Date: Tue, 13 Aug 2013 11:23:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Wenger Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 17:23:40 -0000 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. I wonder: do we need to specify a bit more what we mean by "open-source-friendly non-assert terms"? Peter -- Peter Saint-Andre https://stpeter.im/ From stephen.farrell@cs.tcd.ie Tue Aug 13 13:02:47 2013 Return-Path: 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 B8B5521F9CA2 for ; Tue, 13 Aug 2013 13:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] 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 xAnGa1vSXgop for ; Tue, 13 Aug 2013 13:02:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 356CB21F9C6F for ; Tue, 13 Aug 2013 13:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA850BE51; Tue, 13 Aug 2013 21:02:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2mylR51Verf; Tue, 13 Aug 2013 21:02:27 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.54.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A32CBE4D; Tue, 13 Aug 2013 21:02:26 +0100 (IST) Message-ID: <520A90D1.20802@cs.tcd.ie> Date: Tue, 13 Aug 2013 21:02:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephan Wenger Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing References: <520A6B91.4020705@stpeter.im> In-Reply-To: <520A6B91.4020705@stpeter.im> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:02:47 -0000 On 08/13/2013 06:23 PM, Peter Saint-Andre 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. I wonder: do we need to specify a bit more what we mean by > "open-source-friendly non-assert terms"? Overall this is a good change IMO, thanks Stephan. I prefer Barry's formulation. I think we should ask some folks who care a lot about OSS, IPR and licensing to see what they think at some point since it'd be a real shame to make this change but then discover that some important OSS group find it objectionable. (I do however agree with Stephan's approach of not going into too much detail in case we accidentally prefer one OSS camp over another.) One other comment, I'd add a 2.5 to Barry's list: - 2.5. same-as-2 but with mutually assured destruction (MAD). Someone would have to figure out how to phrase that but there're plenty of examples (e.g. most or all Cisco declarations) where you lose the right to an RF license if you sue the IPR declarer over your claimed IPR. S. > > Peter > From stewe@stewe.org Tue Aug 13 14:03:40 2013 Return-Path: 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 F2A7C21E8186 for ; Tue, 13 Aug 2013 14:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 lfMPC9eNSSS1 for ; Tue, 13 Aug 2013 14:03:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id E4FBE21E8159 for ; Tue, 13 Aug 2013 14:03:22 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB192.namprd07.prod.outlook.com (10.242.167.144) with Microsoft SMTP Server (TLS) id 15.0.731.16; Tue, 13 Aug 2013 21:03:19 +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:03:18 +0000 From: Stephan Wenger To: Stephen Farrell Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmTVpCA//+SLACAAHppgIAALGiA//+boAA= Date: Tue, 13 Aug 2013 21:03:17 +0000 Message-ID: In-Reply-To: <520A90D1.20802@cs.tcd.ie> 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:(57704003)(377454003)(479174003)(199002)(189002)(24454002)(51704005)(46102001)(19580395003)(54316002)(51856001)(49866001)(74366001)(31966008)(54356001)(76176001)(74502001)(79102001)(83072001)(36756003)(47446002)(80022001)(69226001)(56776001)(65816001)(53806001)(77982001)(81542001)(66066001)(83322001)(77096001)(76786001)(16406001)(74876001)(74706001)(81686001)(4396001)(80976001)(59766001)(19580405001)(56816003)(63696002)(81342001)(74662001)(76482001)(47736001)(47976001)(50986001)(76796001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB192; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Barry Leiba , "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:03:41 -0000 Steve, Please see inline. Stephan On 8.13.2013 13:02 , "Stephen Farrell" wrote: > > >On 08/13/2013 06:23 PM, Peter Saint-Andre wrote: >> On 8/13/13 11:05 AM, Stephan Wenger wrote: >>> Barry, >>> Your formulation is certainly more accessible. I'm fine with it. >>=20 >> Agreed. >>=20 >> Formatting aside, is that hierarchy of options complete and accurate? It >> looks fine to me and consistent with our "running code" in these >> matters. I wonder: do we need to specify a bit more what we mean by >> "open-source-friendly non-assert terms"? > >Overall this is a good change IMO, thanks Stephan. >I prefer Barry's formulation. > >I think we should ask some folks who care a lot about OSS, IPR and >licensing to see what they think at some point since it'd be a real >shame to make this change but then discover that some important OSS >group find it objectionable. (I do however agree with Stephan's >approach of not going into too much detail in case we accidentally >prefer one OSS camp over another.) Feel free :-) (Let me note that I ran my idea, before posting, against two colleagues who have some experience in the field, but prefer not to be named. Neither of them had a concern.) > >One other comment, I'd add a 2.5 to Barry's list: > >- 2.5. same-as-2 but with mutually assured destruction (MAD). > >Someone would have to figure out how to phrase that but there're >plenty of examples (e.g. most or all Cisco declarations) where >you lose the right to an RF license if you sue the IPR declarer >over your claimed IPR. MAD sounds scary. But a patent lawsuit hardly falls under the category of "destruction". Even small companies get occasionally sued over patents, without going down. Big ones get sued every other week or so. It's not the end of the world. Moderately scary sometimes, and surely annoying, but not necessarily (not even frequently, in my personal experience) destructive. 2.5 would be called something like "open-source friendly non-assert terms with reciprocity condition." I have yet to see a non-assert covenant anywhere (inside or outside the IETF) that does not include a reciprocity clause (termination of promise not to sue in case of litigation or, in some cases, assertion of a patent against the rightholder, or his friends, or his customers, or another user of the standard, ...). AFAIR, all IETF disclosures with non-assert terms would fall under 2.5 according to your definition. And, while we are at it, I have yet to see a license agreement under RAND or RAND-Z that does not include reciprocity conditions. Therefore, let me suggest it would be an unnecessary add of word count and confusion if we were adding 2.5 (and corresponding 3.5, 4.5, etc.). > >S. > >>=20 >> Peter >>=20 From brian.e.carpenter@gmail.com Tue Aug 13 14:07:32 2013 Return-Path: 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 9AC6721E80EE for ; Tue, 13 Aug 2013 14:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] 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 iW7VvH7YOqWC for ; Tue, 13 Aug 2013 14:07:32 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D621F90DC for ; Tue, 13 Aug 2013 14:07:31 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id wz12so5056455pbc.11 for ; Tue, 13 Aug 2013 14:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E+pMFpmujZhugJBvvtsaWpzFP0JqdRP+Y0ez0NlzZdY=; b=SNUQdIIbwhkfbnHEWOJwlopJZshX3uVNQB6DxF86L2Q+KeqUUgF+jBK8/9QCRu7+ph 49ZW/sfnOYLT18Wk8SS8zOnozUMkIByvbn+rHzvQ1ww8goRMnK3lkkd6qZFMw/GX9DDL To5MrPw75Iz84BFBLtThZZ9BmxJ74eHZFXnx8aofuJtf1iYwHQDIyDGJqlco79pdC0RH RGJEWssd28SXi8UZrfljBo9Mrtijwi9YvVCJhLpQhYpVQPHtaqi0YrCgn5ST+F/VtNym JNrp+KSSYSSsMoyezrh5fduJwnDQrdPXKhXyw/rzTSdqH4U8jHggXrNMqx4kAhV9mg7l CpDQ== X-Received: by 10.68.189.8 with SMTP id ge8mr5839315pbc.49.1376428042338; Tue, 13 Aug 2013 14:07:22 -0700 (PDT) Received: from [10.1.9.168] ([203.167.141.74]) by mx.google.com with ESMTPSA id py4sm45972246pbc.14.2013.08.13.14.07.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Aug 2013 14:07:21 -0700 (PDT) Message-ID: <520AA00C.2020702@gmail.com> Date: Wed, 14 Aug 2013 09:07:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Farrell Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing References: <520A6B91.4020705@stpeter.im> <520A90D1.20802@cs.tcd.ie> In-Reply-To: <520A90D1.20802@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipr-wg@ietf.org" , Barry Leiba X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:07:32 -0000 On 14/08/2013 08:02, Stephen Farrell wrote: > > On 08/13/2013 06:23 PM, Peter Saint-Andre 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. I wonder: do we need to specify a bit more what we mean by >> "open-source-friendly non-assert terms"? > > Overall this is a good change IMO, thanks Stephan. > I prefer Barry's formulation. > > I think we should ask some folks who care a lot about OSS, IPR and > licensing to see what they think at some point since it'd be a real > shame to make this change but then discover that some important OSS > group find it objectionable. (I do however agree with Stephan's > approach of not going into too much detail in case we accidentally > prefer one OSS camp over another.) > > One other comment, I'd add a 2.5 to Barry's list: > > - 2.5. same-as-2 but with mutually assured destruction (MAD). There are good reasons why we never tried to define RAND in an RFC. (Basically WANL and WADNJ, we are not lawyers and we are *definitely* not judges.) The same reasons mean that we shouldn't try to define any of these terms precisely in an RFC. "Open-source friendly"??? Of course that is way out of our competence to define. So, while expressing some preferences (and mine might well agree with the proposed list), we have to be extremely clear that we are not laying down rules and that the only criterion in the end is WG rough consensus to adopt or not adopt a particular technology. In fact I wonder about putting this in a BCP rather than in RFC3669bis. Brian > > Someone would have to figure out how to phrase that but there're > plenty of examples (e.g. most or all Cisco declarations) where > you lose the right to an RF license if you sue the IPR declarer > over your claimed IPR. > > S. > >> Peter >> > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-wg > From stewe@stewe.org Tue Aug 13 14:13:05 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Peter Saint-Andre 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: 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 , "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:13:05 -0000 Hi Peter, On 8.13.2013 10:23 , "Peter Saint-Andre" 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.=20 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 > >--=20 >Peter Saint-Andre >https://stpeter.im/ > > From stephen.farrell@cs.tcd.ie Tue Aug 13 14:28:10 2013 Return-Path: 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 A31C521E8188 for ; Tue, 13 Aug 2013 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] 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 2MsV4Oe+s-+D for ; Tue, 13 Aug 2013 14:28:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9A10B21E8186 for ; Tue, 13 Aug 2013 14:28:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 559D2BE51; Tue, 13 Aug 2013 22:28:02 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3btESRXiREoy; Tue, 13 Aug 2013 22:28:01 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.54.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 25551BE4C; Tue, 13 Aug 2013 22:28:01 +0100 (IST) Message-ID: <520AA4E0.6010303@cs.tcd.ie> Date: Tue, 13 Aug 2013 22:28:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephan Wenger Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 21:28:16 -0000 Hiya, On 08/13/2013 10:03 PM, Stephan Wenger wrote: > Steve, > Please see inline. > Stephan > > > On 8.13.2013 13:02 , "Stephen Farrell" wrote: > >> >> >> On 08/13/2013 06:23 PM, Peter Saint-Andre 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. I wonder: do we need to specify a bit more what we mean by >>> "open-source-friendly non-assert terms"? >> >> Overall this is a good change IMO, thanks Stephan. >> I prefer Barry's formulation. >> >> I think we should ask some folks who care a lot about OSS, IPR and >> licensing to see what they think at some point since it'd be a real >> shame to make this change but then discover that some important OSS >> group find it objectionable. (I do however agree with Stephan's >> approach of not going into too much detail in case we accidentally >> prefer one OSS camp over another.) > > Feel free :-) > > (Let me note that I ran my idea, before posting, against two colleagues > who have some experience in the field, but prefer not to be named. > Neither of them had a concern.) Good to hear. I'm sure it'd happen as part of IETF LC anyway, but sooner is better. > >> >> One other comment, I'd add a 2.5 to Barry's list: >> >> - 2.5. same-as-2 but with mutually assured destruction (MAD). >> >> Someone would have to figure out how to phrase that but there're >> plenty of examples (e.g. most or all Cisco declarations) where >> you lose the right to an RF license if you sue the IPR declarer >> over your claimed IPR. > > MAD sounds scary. Sorry, its a slang-term I've heard used for these. Not sure how widely its used. > But a patent lawsuit hardly falls under the category of > "destruction". Even small companies get occasionally sued over patents, > without going down. Big ones get sued every other week or so. It's not > the end of the world. Moderately scary sometimes, and surely annoying, > but not necessarily (not even frequently, in my personal experience) > destructive. > > 2.5 would be called something like "open-source friendly non-assert terms > with reciprocity condition." > > I have yet to see a non-assert covenant anywhere (inside or outside the > IETF) that does not include a reciprocity clause (termination of promise > not to sue in case of litigation or, in some cases, assertion of a patent > against the rightholder, or his friends, or his customers, or another user > of the standard, ...). AFAIR, all IETF disclosures with non-assert terms > would fall under 2.5 according to your definition. And, while we are at > it, I have yet to see a license agreement under RAND or RAND-Z that does > not include reciprocity conditions. Therefore, let me suggest it would be > an unnecessary add of word count and confusion if we were adding 2.5 (and > corresponding 3.5, 4.5, etc.). I do think I've seen declarations without reciprocity, though yes they're perhaps getting very scarce these days. Nonetheless reciprocity is problematic for some OSS folks I believe. I think the issue was if a user of the OSS s/w sues the IPR holder then was it ok for the developer to write that OSS in the first place? (I might have gotten that wrong though.) However, I don't really mind too much about this part - the main good thing here IMO is reflecting the reality that we do prefer our work to be usable in OSS (for those things where that makes sense, which is most things). S. > > > >> >> S. >> >>> >>> Peter >>> > > > From David.Rudin@microsoft.com Tue Aug 13 22:04:51 2013 Return-Path: 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 D952511E80F8 for ; Tue, 13 Aug 2013 22:04:51 -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 7iM9oc6d3f9r for ; Tue, 13 Aug 2013 22:04:45 -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 B584C11E80F0 for ; Tue, 13 Aug 2013 22:04:44 -0700 (PDT) Received: from BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) by BLUPR03MB067.namprd03.prod.outlook.com (10.255.209.155) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 14 Aug 2013 05:04:41 +0000 Received: from BY2FFO11FD007.protection.gbl (2a01:111:f400:7c0c::23) by BLUPR03CA028.outlook.office365.com (2a01:111:e400:879::21) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Wed, 14 Aug 2013 05:04:41 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Wed, 14 Aug 2013 05:04:40 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.180]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0136.001; Wed, 14 Aug 2013 05:03:44 +0000 From: "David Rudin (LCA)" To: Stephan Wenger , "ipr-wg@ietf.org" Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQ Date: Wed, 14 Aug 2013 05:03:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_B68EFB284B10C249835C566A0CE08AA2498F8704TK5EX14MBXC294r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(53754006)(377454003)(199002)(189002)(512954002)(80022001)(46102001)(66066001)(65816001)(81542001)(81342001)(49866001)(47736001)(50986001)(47976001)(4396001)(69226001)(71186001)(77096001)(56816003)(16406001)(33656001)(76796001)(76786001)(561944002)(15202345003)(79102001)(74706001)(55846006)(59766001)(77982001)(20776003)(63696002)(54356001)(53806001)(74366001)(56776001)(76482001)(74876001)(81686001)(54316002)(31966008)(74662001)(47446002)(74502001)(6806004)(83322001)(19580405001)(44976005)(19580385001)(19580395003)(16236675002)(19300405004)(83072001)(80976001)(51856001)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB067; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0938781D02 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD007.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB067.namprd03.prod.outlook.com X-Mailman-Approved-At: Wed, 14 Aug 2013 08:33:13 -0700 X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 05:04:52 -0000 --_000_B68EFB284B10C249835C566A0CE08AA2498F8704TK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephan, I think there are a lot of issues in this statement "[w]ith respect to tech= nologies with IPR claim(s) against them, the IETF prefers open-source-frien= dly non-assert terms over reasonable and non-discriminatory royalty-free te= rms (RAND-Z)" that need to be considered. One issue is the notion that non-asserts are preferred over RANDz. A royal= ty-free non-assert and RANDz licensing commitment are very different things= . While a RANDz commitment generally doesn't include specific terms, it do= es mean that an implementer will be able to get a reasonable and non-discri= minatory license, and those terms can be negotiated by the parties (though = in reality actual RANDz licenses tend to be extremely rare). We also have = an increasing amount of case law to tell us what kind of terms are reasonab= le and non-discriminatory. Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be = take it or leave it affairs. If you don't like the terms, there are no ass= urances that you can get different ones. And that leads directly to the no= n-assert terms themselves. I've certainly seen non-asserts that are solid,= but I've also seen a number that can be extremely problematic to implement= ers. With a take it or leave it non-assert, an implementer can be held up = by patent holder providing unacceptable terms. For just one example, non-asserts can include extremely broad grant back pr= ovisions that effectively require an implementer not to assert any of its p= atents, even for those that read on things that have nothing do to with the= covered RFC, in exchange for a patent grant for a single RFC. There are c= ertainly good arguments that broad grant back provisions are not RANDz term= s, and providing a preference to non-RANDz terms just because they're in th= e form of a non-assert is not going to help adoption. Requiring compatibility with OSS licenses also doesn't help much since it's= not at all clear what that means. Is it ok if the non-assert is compatibl= e with BSD but not Apache? What about if it's compatible with Apache and n= ot GPL? (Even Apache is not considered to be compatible with GPLv2.) It's probably also worth considering whether the non-asserts themselves wou= ld be compatible with each other. I've seen a number of non-asserts at IET= F that are conditioned on the recipient making their patents available und= er the same terms, yet most IETF declarants providing non-asserts use their= own custom terms. If you have two non-asserts each requiring recipients p= rovide the same terms, whose terms trump? Or, does it result in a cascadin= g effect where everyone needs to provide multiple terms to satisfy the cond= itions of the various non-asserts for a given RFC? Like any other legal agreement, with non-asserts the devil is in the detail= s. Expressing a preference for non-asserts that may include problematic te= rms is just as likely to hurt adoption as it is to help. At least speaking for one implementer, a RANDz commitment provides a much g= reater level of comfort compared to the situation posed by various incompat= ible and potentially onerous non-asserts. David From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of= Stephan Wenger Sent: Tuesday, August 13, 2013 9:19 AM To: ipr-wg@ietf.org Subject: RFC3979bis section 7 -- hierarchy of preference for licensing 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_B68EFB284B10C249835C566A0CE08AA2498F8704TK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

 <= /p>

I think there are a lot o= f issues in this statement “[w]ith respect to technologies with IPR c= laim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z)&#= 8221; that need to be considered.

 <= /p>

One issue is the notion t= hat non-asserts are preferred over RANDz.  A royalty-free non-assert a= nd RANDz licensing commitment are very different things.  While a RANDz commitment generally doesn’t include specific terms, it does= mean that an implementer will be able to get a reasonable and non-discrimi= natory license, and those terms can be negotiated by the parties (though in= reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law to= tell us what kind of terms are reasonable and non-discriminatory.

 <= /p>

Unlike a RANDz commitment= , which can be negotiated, non-asserts tend to be take it or leave it affai= rs.  If you don’t like the terms, there are no assurances that you can get different ones.  And that leads directly to the non-= assert terms themselves.  I’ve certainly seen non-asserts that a= re solid, but I’ve also seen a number that can be extremely problemat= ic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing unacceptable term= s.

 <= /p>

For just one example, non= -asserts can include extremely broad grant back provisions that effectively= require an implementer not to assert any of its patents, even for those that read on things that have nothing do to with the covere= d RFC, in exchange for a patent grant for a single RFC.  There are cer= tainly good arguments that broad grant back provisions are not RANDz terms,= and providing a preference to non-RANDz terms just because they’re in the form of a non-assert is not going = to help adoption.

 <= /p>

Requiring compatibility w= ith OSS licenses also doesn’t help much since it’s not at all c= lear what that means.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it’s compatible with Apache = and not GPL? (Even Apache is not considered to be compatible with GPLv2.)

 <= /p>

It’s probably also = worth considering whether the non-asserts themselves would be compatible wi= th each other.  I’ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents available unde= r the same terms, yet most IETF declarants providing non-asserts use their = own custom terms.  If you have two non-asserts each requiring recipien= ts provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone needs to provide m= ultiple terms to satisfy the conditions of the various non-asserts for a gi= ven RFC?

 <= /p>

Like any other legal agre= ement, with non-asserts the devil is in the details.  Expressing a pre= ference for non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 <= /p>

At least speaking for one= implementer, a RANDz commitment provides a much greater level of comfort c= ompared to the situation posed by various incompatible and potentially onerous non-asserts.

 <= /p>

David

 <= /p>

 <= /p>

 <= /p>

From: ipr-wg= -bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensi= ng

 

Hi all,

 

In Berlin's IPR BOF, one of the topics discussed was lan= guage 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 clar= ifications or modifications that go beyond editorial input.  I had som= e private discussions with Scott and Jorge, and was asked by them to provid= e input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concern= ing this section.

 

To set context, section 7 is arguably one of the more im= portant sections in the RFC3979, because it covers the application of the I= ETF IPR policy in the day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologie= s in IETF Working Groups".  It explains, among other things, how = working groups can react to received IPR disclosures.  (Note that RFC3= 979 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 techno= logies with claims against them, an offer of royalty-free licensing.=

 

I propose to replace this sentence with:

 

In general, to s= olve a given problem, the IETF prefers technologies with no known IPR over = technologies with IPR claim(s) against them.  With respect to technolo= gies 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 unde= r 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. &= nbsp;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 cas= es, has difficulties in accepting technologies for which bi-lateral licenses need to be signed, regardless of whether those license= s are royalty-free or not or whether unlicensed use of the technology gener= ally is tolerated even if it were against the text of the disclosure. Let m= e also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories men= tioned above, including the final one.

 

The list of categories could easily be extended, especia= lly with respect to the broad "open-source friendly non-assert" p= art.  However, doing so meaningfully would quite likely require refere= nces to licensing schemes supported by certain open source "camps", a= nd 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&= quot; 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 R= AND for reasons that are known to the disclosers, the requirement for reaso= nable and non-discriminatory licensing is commonly believe to offer some protect= ion, even if the amount of protection offered is currently unclear, and bec= ause 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 defi= ne the term RAND.

 

Thanks for your consideration of my proposal.

 

Stephan

 

--_000_B68EFB284B10C249835C566A0CE08AA2498F8704TK5EX14MBXC294r_-- From ted.ietf@gmail.com Wed Aug 14 08:48:08 2013 Return-Path: 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 590C621E80B7 for ; Wed, 14 Aug 2013 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Y9V7xXN0U54M for ; Wed, 14 Aug 2013 08:48:07 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9663621E80B5 for ; Wed, 14 Aug 2013 08:48:07 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so13058008iec.34 for ; Wed, 14 Aug 2013 08:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yof1HoH3eCiqSqaDuPrC6qMcPyj80n7KnOTLlP3kbN8=; b=XHyUWZXwszw/0YFEQG5bN3CpTRrwe6mMO3MPDjeoFF06U98MpoGBmGbE8ROcNRLs/Z Tif6K9WjqNbbEjs4FXb19TGGaouVsmQMwNql9kE9LCYDaDERd8uz9ooiMs4D5++aa2oJ cmT3bhmEOFvoOWGHC343hNLLctpGdyr8JPtIVQuKKz9G4Du0agUfQbYG4tnHSYLXRQlj /QVQZ5W+BLhZhE2vRDLs91T84rW6E6lQqYRrccVUZ0VN5gN7grNjAALNjepuJXVpit7t ArFTLMbmjePDMrzVT2SnCZP/iHStMdjxqCuOpcVDha0oqeTrNeKKAPQRcuGU8CezcQVP lz7A== MIME-Version: 1.0 X-Received: by 10.42.37.203 with SMTP id z11mr747864icd.56.1376495287234; Wed, 14 Aug 2013 08:48:07 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Wed, 14 Aug 2013 08:48:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Aug 2013 08:48:07 -0700 Message-ID: Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing From: Ted Hardie To: Stephan Wenger Content-Type: multipart/alternative; boundary=90e6ba613836a1797004e3ea4846 Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:48:08 -0000 --90e6ba613836a1797004e3ea4846 Content-Type: text/plain; charset=ISO-8859-1 So, I've read the thread to this point, and as I watched I got more and more niggled with the feeling that it was heading in the wrong direction. As I thought about why, I realized that the whole of hierarchy of preference discussion is disconnected from what a WG does: make tradeoffs. A working group faced with technology A with license FOO and technology B with license BAR is almost never going to pick solely on license; it's a balance of the benefits of the technology and the consequences of the license. Creating a hierarchy of preference for license terms has a sort of theoretical advantage in that it tells people who are considering what licenses the IETF likes. Those people probably have lawyers with other things to think about it, so I suspect it of being pretty theoretical, but harmless. This section, though, does not seem to me good enoughfi we are going to state a preference hierarchy.: 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. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. I think we need language that says explicitly that the working group makes the trade-off between the technology's advantages and the license's conditions. Otherwise, I foresee WGs with people arguing that technology B must be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable). --90e6ba613836a1797004e3ea4846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, I've read the thread to this point, and as I watched I got more and= more niggled with the feeling that it was heading in the wrong direction.= =A0

As I thought about why, I realized that the whole of hierarchy = of preference discussion is disconnected from what a WG does:=A0 make trade= offs.=A0=A0 A working group faced with technology A with license FOO and te= chnology B with license BAR is almost never going to pick solely on license= ; it's a balance of the benefits of the technology and the consequences= of the license.=A0 Creating a hierarchy of preference for license terms ha= s a sort of theoretical advantage in that it tells people who are consideri= ng what licenses the IETF likes.=A0 Those people probably have lawyers with= other things to think about it, so I suspect it of being pretty theoretica= l, but harmless.

This section, though, does not seem to me good enoughfi=A0 we are going= to state a preference hierarchy.:

   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.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
I think we need language that says explicitly that the working group = makes the trade-off between the technology's advantages and the license= 's conditions.=A0 Otherwise, I foresee WGs with people arguing that tec= hnology B must be chosen because its license is higher in the hierarchy and= acceptable (for some value of acceptable).
--90e6ba613836a1797004e3ea4846-- From stewe@stewe.org Thu Aug 15 07:13:55 2013 Return-Path: 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 A207621E814B for ; Thu, 15 Aug 2013 07:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 uRog0rMjoOEw for ; Thu, 15 Aug 2013 07:13:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB821E8145 for ; Thu, 15 Aug 2013 07:13:49 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB221.namprd07.prod.outlook.com (10.242.167.146) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 15 Aug 2013 14:13:46 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 15 Aug 2013 14:13:43 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) with mapi id 15.00.0745.000; Thu, 15 Aug 2013 14:13:43 +0000 From: Stephan Wenger To: Ted Hardie Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgADAy4CAAQKTAA== Date: Thu, 15 Aug 2013 14:13:42 +0000 Message-ID: In-Reply-To: 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: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(16406001)(74876001)(69226001)(79102001)(63696002)(49866001)(47736001)(4396001)(81542001)(81342001)(31966008)(47446002)(74662001)(74502001)(76482001)(80976001)(56776001)(54316002)(53806001)(54356001)(74706001)(56816003)(77096001)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(76176001)(36756003)(50986001)(47976001)(46102001)(83072001)(19580395003)(16236675002)(19580405001)(76786001)(76796001)(83322001)(81816001)(81686001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; 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_CE322D32A0EABstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:13:55 -0000 --_000_CE322D32A0EABstewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, I very much agree that the any hierarchy of licensing schemes MUST NOT be t= he only, or even the key criteria in evaluating competing technologies. Th= e balance between technical merits and commercial impact, as seen by the in= dividual participant, is all that really counts. With that in mind, please= note that there is a lot more in the existing section 7 than just this fir= st sentence. Much of it is directly related to your concern. In particula= r, right after the sentence I try to improve on, follows: " But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. " Isn't that already addressing your concern? Should we change the order of the parts of the section, such that the above= citation (or something similar) appears prominently at the begin of sectio= n 7? Stephan From: Ted Hardie > Date: Wednesday, 14 August, 2013 08:48 To: Stephan Wenger > Cc: "ipr-wg@ietf.org" > Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing So, I've read the thread to this point, and as I watched I got more and mor= e niggled with the feeling that it was heading in the wrong direction. As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does: make tradeoffs. A work= ing group faced with technology A with license FOO and technology B with li= cense BAR is almost never going to pick solely on license; it's a balance o= f the benefits of the technology and the consequences of the license. Crea= ting a hierarchy of preference for license terms has a sort of theoretical = advantage in that it tells people who are considering what licenses the IET= F likes. Those people probably have lawyers with other things to think abo= ut it, so I suspect it of being pretty theoretical, but harmless. This section, though, does not seem to me good enoughfi we are going to st= ate a preference hierarchy.: 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. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons. Otherwise, I foresee WGs with people arguing that technology B must b= e chosen because its license is higher in the hierarchy and acceptable (for= some value of acceptable). --_000_CE322D32A0EABstewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A45EA97EB275C459D1B9CE1D5D62530@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Ted,
I very much agree that th= e any hierarchy of licensing schemes MUST NOT be the only, or even the key = criteria in evaluating competing technologies.  The balance between te= chnical merits and commercial impact, as seen by the individual participant, is all that really counts.  With = that in mind, please note that there is a lot more in the existing section = 7 than just this first sentence.  Much of it is directly related to yo= ur concern.  In particular, right after the sentence I try to improve on, follows:
"
But IETF working groups have the discretion
to adopt technology with a commitment of fair a= nd non-discriminatory
terms, or even with no licensing commitment, if= they feel that this
technology is superior enough to alternatives w= ith fewer IPR claims
or free licensing to outweigh the potential cos= t of the licenses.
"
Isn't that already addres= sing your concern?  
Should we change the orde= r of the parts of the section, such that the above citation (or something s= imilar) appears prominently at the begin of section 7?

Stephan



From: Ted Hardie <ted.ietf@gmail.com>
Date: Wednesday, 14 August, 2013 08= :48
To: Stephan Wenger <stewe@stewe.org>
Cc: "ipr-wg@ietf.org" <= ipr-wg@ietf.org>
Subject: Re: RFC3979bis section 7 -= - hierarchy of preference for licensing

So, I've read the thread to this point, and as I watched I got more an= d more niggled with the feeling that it was heading in the wrong direction.=  

As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does:  make tradeoffs.&nbs= p;  A working group faced with technology A with license FOO and techn= ology B with license BAR is almost never going to pick solely on license; it's a balance of the benefits of the technolog= y and the consequences of the license.  Creating a hierarchy of prefer= ence for license terms has a sort of theoretical advantage in that it tells= people who are considering what licenses the IETF likes.  Those people probably have lawyers with other things= to think about it, so I suspect it of being pretty theoretical, but harmle= ss.

This section, though, does not seem to me good enoughfi  we are going = to state a preference hierarchy.:

   In general, IETF working groups prefer technologies with no known I=
PR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons.  Otherwise, I foresee WGs with people arguing that technology B m= ust be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable).
 --_000_CE322D32A0EABstewesteweorg_-- From stewe@stewe.org Thu Aug 15 07:16:29 2013 Return-Path: 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 C4B8021E8156 for ; Thu, 15 Aug 2013 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 rR77lTOloZNd for ; Thu, 15 Aug 2013 07:16:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id ECD7421E815E for ; Thu, 15 Aug 2013 07:16:19 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB189.namprd07.prod.outlook.com (10.242.167.147) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 15 Aug 2013 14:01:03 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) with mapi id 15.00.0745.000; Thu, 15 Aug 2013 14:01:03 +0000 From: Stephan Wenger To: "David Rudin (LCA)" , "ipr-wg@ietf.org" Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgAG/2IA= Date: Thu, 15 Aug 2013 14:01:03 +0000 Message-ID: In-Reply-To: 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: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(377454003)(199002)(189002)(1511001)(16406001)(69226001)(74876001)(4396001)(79102001)(15202345003)(561944002)(47736001)(49866001)(81542001)(47446002)(31966008)(74502001)(81342001)(74662001)(54316002)(56776001)(53806001)(54356001)(76482001)(80976001)(74706001)(77096001)(56816003)(63696002)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(19300405004)(76176001)(46102001)(36756003)(50986001)(47976001)(19580395003)(16236675002)(19580385001)(83072001)(19580405001)(76796001)(83322001)(76786001)(81686001)(81816001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB189; H:CO1PR07MB191.namprd07.prod.outlook.com; CLIP:71.202.147.60; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE30F25BA0C2Dstewesteweorg_" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:16:30 -0000 --_000_CE30F25BA0C2Dstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi David, Please see inline. Stephan From: "David Rudin (LCA)" > Date: Tuesday, 13 August, 2013 22:03 To: Stephan Wenger >, "ipr-wg@ietf.= org" > Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Hi Stephan, I think there are a lot of issues in this statement =93[w]ith respect to te= chnologies with IPR claim(s) against them, the IETF prefers open-source-fri= endly non-assert terms over reasonable and non-discriminatory royalty-free = terms (RAND-Z)=94 that need to be considered. One issue is the notion that non-asserts are preferred over RANDz. A royal= ty-free non-assert and RANDz licensing commitment are very different things= . While a RANDz commitment generally doesn=92t include specific terms, it = does mean that an implementer will be able to get a reasonable and non-disc= riminatory license, and those terms can be negotiated by the parties (thoug= h in reality actual RANDz licenses tend to be extremely rare). We also hav= e an increasing amount of case law to tell us what kind of terms are reason= able and non-discriminatory. Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be = take it or leave it affairs. If you don=92t like the terms, there are no a= ssurances that you can get different ones. And that leads directly to the = non-assert terms themselves. I=92ve certainly seen non-asserts that are so= lid, but I=92ve also seen a number that can be extremely problematic to imp= lementers. With a take it or leave it non-assert, an implementer can be he= ld up by patent holder providing unacceptable terms. For just one example, non-asserts can include extremely broad grant back pr= ovisions that effectively require an implementer not to assert any of its p= atents, even for those that read on things that have nothing do to with the= covered RFC, in exchange for a patent grant for a single RFC. There are c= ertainly good arguments that broad grant back provisions are not RANDz term= s, and providing a preference to non-RANDz terms just because they=92re in = the form of a non-assert is not going to help adoption. StW: I concur with most of what you say above, including the underlying sen= timent that a signed and sealed RAND-Z license is preferable to many implem= enters (though not necessarily all the open source folks). However, nothin= g what you write above changes that, at least based on my impression, the I= ETF as an organization indeed prefers non-assert statements, even with broa= d grant back provisions and other unpalatable terms, over RAND-Z licensing = covenants. As the very minimum, the overwhelming majority of participants,= and the IETF is a consensus based organization, right? The reason for my = proposed modification lies in the alignment of the policy to the practice o= f the IETF as of today. Let me also note that practically all non-assert d= isclosures include an offer for negotiation of a bilateral (typically RAND)= license, for reasons I certainly do not need to explain to you :-) That o= ught to alleviate some of your concerns. Requiring compatibility with OSS licenses also doesn=92t help much since it= =92s not at all clear what that means. Is it ok if the non-assert is compa= tible with BSD but not Apache? What about if it=92s compatible with Apache= and not GPL? (Even Apache is not considered to be compatible with GPLv2.) StW: I disagree with your first sentence. It helps, even if it is not clear= ly defined. As I have already stated, it is up to the implementer communit= y of an RFC--however that community may be composed--to beat up a non-asser= t disclosure that it considers incompatible with their business model. It=92s probably also worth considering whether the non-asserts themselves w= ould be compatible with each other. I=92ve seen a number of non-asserts at= IETF that are conditioned on the recipient making their patents available= under the same terms, yet most IETF declarants providing non-asserts use t= heir own custom terms. If you have two non-asserts each requiring recipien= ts provide the same terms, whose terms trump? Or, does it result in a casc= ading effect where everyone needs to provide multiple terms to satisfy the = conditions of the various non-asserts for a given RFC? StW: Once more, the preferences stated are what I believe (and others have = concurred!) the current practice of the IETF at large. The problem you men= tion may well exist in theory, but I have not seen an outcry--or even a civ= ilized discussion--about a problem like the one you mention that has occurr= ed in practice. Like any other legal agreement, with non-asserts the devil is in the detail= s. Expressing a preference for non-asserts that may include problematic te= rms is just as likely to hurt adoption as it is to help. At least speaking for one implementer, a RANDz commitment provides a much g= reater level of comfort compared to the situation posed by various incompat= ible and potentially onerous non-asserts. StW: On a personal level, I prefer a signed bilateral or pool license any d= ay over an uni-lateral non-assert statement, especially with broad reciproc= ity conditions or other unpalatable terms. I'm even willing to pay for it.= Makes me sleep better, and my business model allows for it. I'm not so s= ure, however, that a disclosure offering a RAND-Z license with undisclosed = terms (minus the =96Z, of course) makes me sleep better as well. With a no= n-assert, at least I know the conditions beforehand, and can cope with them= , or negotiate a license, or whatever... With the type of RAND-Z offers th= e check-box system of the disclosure tool allows, I would actually have to = negotiate a license before I know the conditions, which is not only an expe= nsive and lengthily undertaking (at least in misty cases), but also incompa= tible with some open source business models. David From: ipr-wg-bounces@ietf.org [mailto:ipr-w= g-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, August 13, 2013 9:19 AM To: ipr-wg@ietf.org Subject: RFC3979bis section 7 -- hierarchy of preference for licensing 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_CE30F25BA0C2Dstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1F16B565ABE3A64194FAC6F95038265C@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi David,
Please see inline.
Stephan

From: "David Rudin (LCA)"= <David.Rudin@microsoft.com= >
Date: Tuesday, 13 August, 2013 22:0= 3
To: Stephan Wenger <stewe@stewe.org>, "ipr-wg@ietf.org" <ipr-wg@ietf.org>
Subject: RE: RFC3979bis section 7 -= - hierarchy of preference for licensing

Hi Stephan,

 

I think there are a lot of issues = in this statement =93[w]ith respect to technologies with IPR claim(s) again= st them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms= (RAND-Z)=94 that need to be considered.

 

One issue is the notion that non-a= sserts are preferred over RANDz.  A royalty-free non-assert and RANDz = licensing commitment are very different things.  While a RANDz commitment generally doesn=92t include specific terms, it do= es mean that an implementer will be able to get a reasonable and non-discri= minatory license, and those terms can be negotiated by the parties (though = in reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law= to tell us what kind of terms are reasonable and non-discriminatory.<= /o:p>

 

Unlike a RANDz commitment, which c= an be negotiated, non-asserts tend to be take it or leave it affairs. = If you don=92t like the terms, there are no assurances that you can get different ones.  And that leads directly = to the non-assert terms themselves.  I=92ve certainly seen non-asserts= that are solid, but I=92ve also seen a number that can be extremely proble= matic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing un= acceptable terms.

 

For just one example, non-asserts = can include extremely broad grant back provisions that effectively require = an implementer not to assert any of its patents, even for those that read on things that have nothing do to wi= th the covered RFC, in exchange for a patent grant for a single RFC.  = There are certainly good arguments that broad grant back provisions are not= RANDz terms, and providing a preference to non-RANDz terms just because they=92re in the form of a non-assert is n= ot going to help adoption.

StW: I concur with most of what you say above, including the underlyin= g sentiment that a signed and sealed RAND-Z license is preferable to many i= mplementers (though not necessarily all the open source folks).  Howev= er, nothing what you write above changes that, at least based on my impression, the IETF as an organization indeed = prefers non-assert statements, even with broad grant back provisions and ot= her unpalatable terms, over RAND-Z licensing covenants.  As the very m= inimum, the overwhelming majority of participants, and the IETF is a consensus based organization, right?  = ;The reason for my proposed modification lies in the alignment of the polic= y to the practice of the IETF as of today.  Let me also note that prac= tically all non-assert disclosures include an offer for negotiation of a bilateral (typically RAND) license, for reas= ons I certainly do not need to explain to you :-)  That ought to allev= iate some of your concerns.

 

Requiring compatibility with OSS l= icenses also doesn=92t help much since it=92s not at all clear what that me= ans.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it=92s compatible with Apache= and not GPL? (Even Apache is not considered to be compatible with GPLv2.)<= o:p>

StW: I disagree with your first sentence. It helps, even if it is not = clearly defined.  As I have already stated, it is up to the implemente= r community of an RFC--however that community may be composed--to beat up a= non-assert disclosure that it considers incompatible with their business model.    

 

It=92s probably also worth conside= ring whether the non-asserts themselves would be compatible with each other= .  I=92ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents avai= lable under the same terms, yet most IETF declarants providing non-asserts = use their own custom terms.  If you have two non-asserts each requirin= g recipients provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone= needs to provide multiple terms to satisfy the conditions of the various n= on-asserts for a given RFC?

StW: Once more, the preferences stated are what I believe (and others = have concurred!) the current practice of the IETF at large.  The probl= em you mention may well exist in theory, but I have not seen an outcry--or = even a civilized discussion--about a problem like the one you mention that has occurred in practice.

 

Like any other legal agreement, wi= th non-asserts the devil is in the details.  Expressing a preference f= or non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 

At least speaking for one implemen= ter, a RANDz commitment provides a much greater level of comfort compared t= o the situation posed by various incompatible and potentially onerous non-asserts.

StW: On a personal level, I prefer a signed bilateral or pool license = any day over an uni-lateral non-assert statement, especially with broad rec= iprocity conditions or other unpalatable terms.  I'm even willing to p= ay for it.  Makes me sleep better, and my business model allows for it.  I'm not so sure, however, that a di= sclosure offering a RAND-Z license with undisclosed terms (minus the =96Z, = of course) makes me sleep better as well.  With a non-assert, at least= I know the conditions beforehand, and can cope with them, or negotiate a license, or whatever...  With the type of R= AND-Z offers the check-box system of the disclosure tool allows, I would ac= tually have to negotiate a license before I know the conditions, which is n= ot only an expensive and lengthily undertaking (at least in misty cases), but also incompatible with some open source bus= iness models.

 

David

 

 

 

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensi= ng

 

H= i all,

 

I= n 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 clar= ifications or modifications that go beyond editorial input.  I had som= e private discussions with Scott and Jorge, and was asked by them to provid= e input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concern= ing this section.

 

T= o 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 th= e day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologie= s in IETF Working Groups".  It explains, among other things, how = working groups can react to received IPR disclosures.  (Note that RFC3= 979 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).=

 

T= his post is about the first sentence of RFC 3979, which reads:<= /o:p>

 

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

 

I= propose to replace this sentence with:

 

In general, to s= olve a given problem, the IETF prefers technologies with no known IPR over = technologies with IPR claim(s) against them.  With respect to technolo= gies 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 unde= r 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.

 

T= he 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 license= s are royalty-free or not or whether unlicensed use of the technology gener= ally is tolerated even if it were against the text of the disclosure. Let m= e also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories men= tioned above, including the final one.

 

T= he 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", a= nd 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&= quot; 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 protect= ion, even if the amount of protection offered is currently unclear, and bec= ause 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 defi= ne the term RAND.

 

T= hanks for your consideration of my proposal.

 

S= tephan

 

 --_000_CE30F25BA0C2Dstewesteweorg_-- From michael.cameron@ericsson.com Thu Aug 15 07:21:12 2013 Return-Path: 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 190EC21E815F for ; Thu, 15 Aug 2013 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 JH6FvnYqyXrM for ; Thu, 15 Aug 2013 07:21:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2021E8158 for ; Thu, 15 Aug 2013 07:20:58 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-70-520ce3c8600b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 03.F4.09414.8C3EC025; Thu, 15 Aug 2013 16:20:56 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 15 Aug 2013 10:20:54 -0400 From: Michael Cameron To: "ipr-wg@ietf.org" Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgAED2YCAATGKsA== Date: Thu, 15 Aug 2013 14:20:53 +0000 Message-ID: <36BAA6A693139D4BBCB37CCCA660E08A02A88AFD@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_36BAA6A693139D4BBCB37CCCA660E08A02A88AFDeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXRPlO6JxzxBBt9WaVq8/fCF2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGbP2PmYuOGBeMfvuYaYGxol6XYycHBICJhIHGiczQdhiEhfu rWfrYuTiEBI4yijx88kPZghnOaPEvEMvGLsYOTjYgDqeP2MBaRARUJdoOPaTFcQWFvCSeHxg GlTcW2JW40tmCNtJYu7Ux2ALWARUJZ4uug1WzyvgK7HjxRF2iPmnGCW6LuwAS3AKBEq8+vCO EcRmBLro+6k1YM3MAuISt57Mh7pUQGLJnvPMELaoxMvH/1ghbGWJJU/2s0DU50sc2t7AArFM UOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZ brqRwSZGYKwck2DT3cG456XlIUZpDhYlcd5VemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCWzJC7LF7bnCM5TSH8wOZ26fM3v+99cmbazN9S7P9OTvm7z1plueuO43nlU72+S4czmbo6 SRgazQlpF7XrmProbfPaSv//Cw53p3zP+lS1+7l1vVPC4+S3UqYh6u/6ywSrNb921wqk+aXv +nvzntkXe1X584pBF7pnnNfPtKxcWZle/udrvawSS3FGoqEWc1FxIgDvr/1SYwIAAA== X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:21:12 -0000 --_000_36BAA6A693139D4BBCB37CCCA660E08A02A88AFDeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted is correct--the WG should be focused on adopting the best technology fo= r the problem at hand, with the IPR profiles of alternatives initially, at = least, in the background. If, during the discussion of technology alternat= ives, a holder of essential IPR declares they will not make the IPR related= to one of them available under any circumstances, then the WG can switch t= o plan B. But it is the WG that makes the trade-off between the technology= 's advantages and the license's conditions. Otherwise, I also foresee WGs = with people arguing that technology B must be chosen because its license is= higher in the hierarchy. Perhaps we can state that notwithstanding a IPR = hierarchy, the technical advantages of a solution should be predominant in = the WG. ________________________________ From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of= Ted Hardie Sent: Wednesday, August 14, 2013 10:48 AM To: Stephan Wenger Cc: ipr-wg@ietf.org Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing So, I've read the thread to this point, and as I watched I got more and mor= e niggled with the feeling that it was heading in the wrong direction. As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does: make tradeoffs. A work= ing group faced with technology A with license FOO and technology B with li= cense BAR is almost never going to pick solely on license; it's a balance o= f the benefits of the technology and the consequences of the license. Crea= ting a hierarchy of preference for license terms has a sort of theoretical = advantage in that it tells people who are considering what licenses the IET= F likes. Those people probably have lawyers with other things to think abo= ut it, so I suspect it of being pretty theoretical, but harmless. This section, though, does not seem to me good enoughfi we are going to st= ate a preference hierarchy.: 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. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons. Otherwise, I foresee WGs with people arguing that technology B must b= e chosen because its license is higher in the hierarchy and acceptable (for= some value of acceptable). --_000_36BAA6A693139D4BBCB37CCCA660E08A02A88AFDeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ted is c= orrect--the WG should be focused on adopting the best techno= logy for the problem at hand, with the IPR profiles of alternativ= es initially, at least, in the background.  If, during the discus= sion of technology alternatives, a holder of essential IPR decla= res they will not make the IPR related to one of them available&n= bsp;under any circumstances, then the WG can switch to plan B.  B= ut it is the WG that makes the trade-off between the techn= ology's advantages and the license's conditions.  Otherwise, I also foresee WG= s with people arguing that technology B must be chosen because its license = is higher in the hierarchy.  Perhap= s we can state that notwithstanding a IPR hierarchy, the technical advantages of a solution should be predominant in the W= G. 

From: ipr-wg-bounces@ietf.org [mail= to:ipr-wg-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Wednesday, August 14, 2013 10:48 AM
To: Stephan Wenger
Cc: ipr-wg@ietf.org
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for lic= ensing

So, I've read the thread to this point, and as I watched I got more and mor= e niggled with the feeling that it was heading in the wrong direction. = ;

As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does:  make tradeoffs.&nbs= p;  A working group faced with technology A with license FOO and techn= ology B with license BAR is almost never going to pick solely on license; it's a balance of the benefits of the technolog= y and the consequences of the license.  Creating a hierarchy of prefer= ence for license terms has a sort of theoretical advantage in that it tells= people who are considering what licenses the IETF likes.  Those people probably have lawyers with other things= to think about it, so I suspect it of being pretty theoretical, but harmle= ss.

This section, though, does not seem to me good enoughfi  we are going = to state a preference hierarchy.:

   In general, IETF working groups prefer technologies with no known I=
PR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons.  Otherwise, I foresee WGs with people arguing that technology B m= ust be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable).
--_000_36BAA6A693139D4BBCB37CCCA660E08A02A88AFDeusaamb101erics_-- From kimberly.a.turner@intel.com Thu Aug 15 11:30:28 2013 Return-Path: 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 0606911E8178 for ; Thu, 15 Aug 2013 11:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 uVnCBPvRyidW for ; Thu, 15 Aug 2013 11:30:22 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id A7B8611E8184 for ; Thu, 15 Aug 2013 11:30:22 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 15 Aug 2013 11:30:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,886,1367996400"; d="scan'208,217";a="386910104" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga002.fm.intel.com with ESMTP; 15 Aug 2013 11:30:20 -0700 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 15 Aug 2013 11:30:19 -0700 Received: from orsmsx109.amr.corp.intel.com ([169.254.2.134]) by ORSMSX153.amr.corp.intel.com ([169.254.12.253]) with mapi id 14.03.0123.003; Thu, 15 Aug 2013 11:30:19 -0700 From: "Turner, Kimberly A" To: "David Rudin (LCA)" , Stephan Wenger , "ipr-wg@ietf.org" Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgAE/9NA= Date: Thu, 15 Aug 2013 18:30:19 +0000 Message-ID: <2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1@ORSMSX109.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dm-mail-id: 249B0941-F4F6-4922-B37C-1CB49F7A00B7 x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1ORSMSX109amrcor_" MIME-Version: 1.0 X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 18:30:28 -0000 --_000_2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1ORSMSX109amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree with David on the issues are the use of the statement "[w]ith = respect to technologies with IPR claim(s) against them, the IETF prefers op= en-source-friendly non-assert terms over reasonable and non-discriminatory = royalty-free terms (RAND-Z)". I don't agree that this is clear enough to e= ven understand what is truly meant and, as David points out, leaves open th= e opportunity for many questions and interpretations. I also agree that ha= ving this hierarchy will lead to quite a bit of difficulty within the work = groups because we have no idea how or when or who will decide when to invok= e the hierarchy. Also, it will make it difficult for the IETF to liaise wi= th or submit specs to organizations like the W3C and other international bo= dies who rely on RAND terms as the non assert can cause confusion in variou= s jurisdictions. Kim Turner From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of= David Rudin (LCA) Sent: Tuesday, August 13, 2013 10:04 PM To: Stephan Wenger; ipr-wg@ietf.org Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Hi Stephan, I think there are a lot of issues in this statement "[w]ith respect to tech= nologies with IPR claim(s) against them, the IETF prefers open-source-frien= dly non-assert terms over reasonable and non-discriminatory royalty-free te= rms (RAND-Z)" that need to be considered. One issue is the notion that non-asserts are preferred over RANDz. A royal= ty-free non-assert and RANDz licensing commitment are very different things= . While a RANDz commitment generally doesn't include specific terms, it do= es mean that an implementer will be able to get a reasonable and non-discri= minatory license, and those terms can be negotiated by the parties (though = in reality actual RANDz licenses tend to be extremely rare). We also have = an increasing amount of case law to tell us what kind of terms are reasonab= le and non-discriminatory. Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be = take it or leave it affairs. If you don't like the terms, there are no ass= urances that you can get different ones. And that leads directly to the no= n-assert terms themselves. I've certainly seen non-asserts that are solid,= but I've also seen a number that can be extremely problematic to implement= ers. With a take it or leave it non-assert, an implementer can be held up = by patent holder providing unacceptable terms. For just one example, non-asserts can include extremely broad grant back pr= ovisions that effectively require an implementer not to assert any of its p= atents, even for those that read on things that have nothing do to with the= covered RFC, in exchange for a patent grant for a single RFC. There are c= ertainly good arguments that broad grant back provisions are not RANDz term= s, and providing a preference to non-RANDz terms just because they're in th= e form of a non-assert is not going to help adoption. Requiring compatibility with OSS licenses also doesn't help much since it's= not at all clear what that means. Is it ok if the non-assert is compatibl= e with BSD but not Apache? What about if it's compatible with Apache and n= ot GPL? (Even Apache is not considered to be compatible with GPLv2.) It's probably also worth considering whether the non-asserts themselves wou= ld be compatible with each other. I've seen a number of non-asserts at IET= F that are conditioned on the recipient making their patents available und= er the same terms, yet most IETF declarants providing non-asserts use their= own custom terms. If you have two non-asserts each requiring recipients p= rovide the same terms, whose terms trump? Or, does it result in a cascadin= g effect where everyone needs to provide multiple terms to satisfy the cond= itions of the various non-asserts for a given RFC? Like any other legal agreement, with non-asserts the devil is in the detail= s. Expressing a preference for non-asserts that may include problematic te= rms is just as likely to hurt adoption as it is to help. At least speaking for one implementer, a RANDz commitment provides a much g= reater level of comfort compared to the situation posed by various incompat= ible and potentially onerous non-asserts. David From: ipr-wg-bounces@ietf.org [mailto:ipr-w= g-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, August 13, 2013 9:19 AM To: ipr-wg@ietf.org Subject: RFC3979bis section 7 -- hierarchy of preference for licensing 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1ORSMSX109amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also agree with David o= n the issues are the use of the statement “[w]ith respect to technologies with IPR claim(s) against them, the IETF prefers o= pen-source-friendly non-assert terms over reasonable and non-discriminatory= royalty-free terms (RAND-Z)”.  I don’t agree that this is= clear enough to even understand what is truly meant and, as David points out, leaves open the opportunity for many questions a= nd interpretations.  I also agree that having this hierarchy will lead= to quite a bit of difficulty within the work groups because we have no ide= a how or when or who will decide when to invoke the hierarchy.  Also, it will make it difficult for the IET= F to liaise with or submit specs to organizations like the W3C and other in= ternational bodies who rely on RAND terms as the non assert can cause confu= sion in various jurisdictions.

 <= /p>

Kim Turner

 <= /p>

From: ipr-wg-b= ounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of David Rudin (LCA)
Sent: Tuesday, August 13, 2013 10:04 PM
To: Stephan Wenger; ipr-wg@ietf.org
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for lic= ensing

 

Hi Stephan,

 <= /p>

I think there are a lot o= f issues in this statement “[w]ith respect to technologies with IPR c= laim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z)&#= 8221; that need to be considered.

 <= /p>

One issue is the notion t= hat non-asserts are preferred over RANDz.  A royalty-free non-assert a= nd RANDz licensing commitment are very different things.  While a RANDz commitment generally doesn’t include specific terms, it does= mean that an implementer will be able to get a reasonable and non-discrimi= natory license, and those terms can be negotiated by the parties (though in= reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law to= tell us what kind of terms are reasonable and non-discriminatory.

 <= /p>

Unlike a RANDz commitment= , which can be negotiated, non-asserts tend to be take it or leave it affai= rs.  If you don’t like the terms, there are no assurances that you can get different ones.  And that leads directly to the non-= assert terms themselves.  I’ve certainly seen non-asserts that a= re solid, but I’ve also seen a number that can be extremely problemat= ic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing unacceptable term= s.

 <= /p>

For just one example, non= -asserts can include extremely broad grant back provisions that effectively= require an implementer not to assert any of its patents, even for those that read on things that have nothing do to with the covere= d RFC, in exchange for a patent grant for a single RFC.  There are cer= tainly good arguments that broad grant back provisions are not RANDz terms,= and providing a preference to non-RANDz terms just because they’re in the form of a non-assert is not going = to help adoption.

 <= /p>

Requiring compatibility w= ith OSS licenses also doesn’t help much since it’s not at all c= lear what that means.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it’s compatible with Apache = and not GPL? (Even Apache is not considered to be compatible with GPLv2.)

 <= /p>

It’s probably also = worth considering whether the non-asserts themselves would be compatible wi= th each other.  I’ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents available unde= r the same terms, yet most IETF declarants providing non-asserts use their = own custom terms.  If you have two non-asserts each requiring recipien= ts provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone needs to provide m= ultiple terms to satisfy the conditions of the various non-asserts for a gi= ven RFC?

 <= /p>

Like any other legal agre= ement, with non-asserts the devil is in the details.  Expressing a pre= ference for non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 <= /p>

At least speaking for one= implementer, a RANDz commitment provides a much greater level of comfort c= ompared to the situation posed by various incompatible and potentially onerous non-asserts.

 <= /p>

David

 <= /p>

 <= /p>

 <= /p>

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensi= ng

 

Hi all,

 

In Berlin's IPR BOF, one of the topics discussed was lan= guage 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 clar= ifications or modifications that go beyond editorial input.  I had som= e private discussions with Scott and Jorge, and was asked by them to provid= e input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concern= ing this section.

 

To set context, section 7 is arguably one of the more im= portant sections in the RFC3979, because it covers the application of the I= ETF IPR policy in the day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologie= s in IETF Working Groups".  It explains, among other things, how = working groups can react to received IPR disclosures.  (Note that RFC3= 979 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 techno= logies with claims against them, an offer of royalty-free licensing.=

 

I propose to replace this sentence with:

 

In general, to s= olve a given problem, the IETF prefers technologies with no known IPR over = technologies with IPR claim(s) against them.  With respect to technolo= gies 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 unde= r 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. &= nbsp;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 cas= es, has difficulties in accepting technologies for which bi-lateral licenses need to be signed, regardless of whether those license= s are royalty-free or not or whether unlicensed use of the technology gener= ally is tolerated even if it were against the text of the disclosure. Let m= e also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories men= tioned above, including the final one.

 

The list of categories could easily be extended, especia= lly with respect to the broad "open-source friendly non-assert" p= art.  However, doing so meaningfully would quite likely require refere= nces to licensing schemes supported by certain open source "camps", a= nd 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&= quot; 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 R= AND for reasons that are known to the disclosers, the requirement for reaso= nable and non-discriminatory licensing is commonly believe to offer some protect= ion, even if the amount of protection offered is currently unclear, and bec= ause 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 defi= ne the term RAND.

 

Thanks for your consideration of my proposal.

 

Stephan

 

--_000_2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1ORSMSX109amrcor_-- From tglassey@earthlink.net Thu Aug 15 11:55:57 2013 Return-Path: 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 26B4211E810B for ; Thu, 15 Aug 2013 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 x3Vkhz8hQDU3 for ; Thu, 15 Aug 2013 11:55:49 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6562211E8128 for ; Thu, 15 Aug 2013 11:55:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=oBs5Q+DHOkaIKSjTsVD0TESnrwZHpQIJ/mNiRDqzw32w5yyABAPV12GL+pZD6rNw; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.1.102]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1VA2i1-0006IN-Te; Thu, 15 Aug 2013 14:55:46 -0400 Message-ID: <520D242F.7060107@earthlink.net> Date: Thu, 15 Aug 2013 11:55:43 -0700 From: tsg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: kimberly.a.turner@intel.com Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing References: <2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1@ORSMSX109.amr.corp.intel.com> In-Reply-To: <2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1@ORSMSX109.amr.corp.intel.com> Content-Type: multipart/alternative; boundary="------------040600050409000207000402" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796fbefa482fc842a138a4f523c5975bba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 Cc: ipr-wg@ietf.org X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 18:55:57 -0000 This is a multi-part message in MIME format. --------------040600050409000207000402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/15/2013 11:30 AM, Turner, Kimberly A wrote: So Kimberly - what does Intel at the Corporate IP Level think of this? Would these use controls meet their corporate requirements for the acquisition of IP under a veil of a license? This is both a fair and reasonable question to ask here since it is they who are underwriting much of your effort here I would assume. Todd Glassey > > I also agree with David on the issues are the use of the statement > "[w]ith 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)". I don't agree that > this is clear enough to even understand what is truly meant and, as > David points out, leaves open the opportunity for many questions and > interpretations. I also agree that having this hierarchy will lead to > quite a bit of difficulty within the work groups because we have no > idea how or when or who will decide when to invoke the hierarchy. > Also, it will make it difficult for the IETF to liaise with or submit > specs to organizations like the W3C and other international bodies who > rely on RAND terms as the non assert can cause confusion in various > jurisdictions. > > Kim Turner > > *From:*ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] *On > Behalf Of *David Rudin (LCA) > *Sent:* Tuesday, August 13, 2013 10:04 PM > *To:* Stephan Wenger; ipr-wg@ietf.org > *Subject:* RE: RFC3979bis section 7 -- hierarchy of preference for > licensing > > Hi Stephan, > > I think there are a lot of issues in this statement "[w]ith 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)" that need to be > considered. > > One issue is the notion that non-asserts are preferred over RANDz. A > royalty-free non-assert and RANDz licensing commitment are very > different things. While a RANDz commitment generally doesn't include > specific terms, it does mean that an implementer will be able to get a > reasonable and non-discriminatory license, and those terms can be > negotiated by the parties (though in reality actual RANDz licenses > tend to be extremely rare). We also have an increasing amount of case > law to tell us what kind of terms are reasonable and non-discriminatory. > > Unlike a RANDz commitment, which can be negotiated, non-asserts tend > to be take it or leave it affairs. If you don't like the terms, there > are no assurances that you can get different ones. And that leads > directly to the non-assert terms themselves. I've certainly seen > non-asserts that are solid, but I've also seen a number that can be > extremely problematic to implementers. With a take it or leave it > non-assert, an implementer can be held up by patent holder providing > unacceptable terms. > > For just one example, non-asserts can include extremely broad grant > back provisions that effectively require an implementer not to assert > any of its patents, even for those that read on things that have > nothing do to with the covered RFC, in exchange for a patent grant for > a single RFC. There are certainly good arguments that broad grant > back provisions are not RANDz terms, and providing a preference to > non-RANDz terms just because they're in the form of a non-assert is > not going to help adoption. > > Requiring compatibility with OSS licenses also doesn't help much since > it's not at all clear what that means. Is it ok if the non-assert is > compatible with BSD but not Apache? What about if it's compatible > with Apache and not GPL? (Even Apache is not considered to be > compatible with GPLv2.) > > It's probably also worth considering whether the non-asserts > themselves would be compatible with each other. I've seen a number of > non-asserts at IETF that are conditioned on the recipient making > their patents available under the same terms, yet most IETF declarants > providing non-asserts use their own custom terms. If you have two > non-asserts each requiring recipients provide the same terms, whose > terms trump? Or, does it result in a cascading effect where everyone > needs to provide multiple terms to satisfy the conditions of the > various non-asserts for a given RFC? > > Like any other legal agreement, with non-asserts the devil is in the > details. Expressing a preference for non-asserts that may include > problematic terms is just as likely to hurt adoption as it is to help. > > At least speaking for one implementer, a RANDz commitment provides a > much greater level of comfort compared to the situation posed by > various incompatible and potentially onerous non-asserts. > > David > > *From:*ipr-wg-bounces@ietf.org > [mailto:ipr-wg-bounces@ietf.org] *On Behalf Of *Stephan Wenger > *Sent:* Tuesday, August 13, 2013 9:19 AM > *To:* ipr-wg@ietf.org > *Subject:* RFC3979bis section 7 -- hierarchy of preference for licensing > > 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 > > > > _______________________________________________ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-wg -- // Standard "perasonal email" disclaimers apply --------------040600050409000207000402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/15/2013 11:30 AM, Turner, Kimberly A wrote:

So Kimberly - what does Intel at the Corporate IP Level think of this? Would these use controls meet their corporate requirements for the acquisition of IP under a veil of a license?

This is both a fair and reasonable question to ask here since it is they who are underwriting much of your effort here I would assume.

Todd Glassey

I also agree with David on the issues are the use of the statement “[w]ith 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)”.  I don’t agree that this is clear enough to even understand what is truly meant and, as David points out, leaves open the opportunity for many questions and interpretations.  I also agree that having this hierarchy will lead to quite a bit of difficulty within the work groups because we have no idea how or when or who will decide when to invoke the hierarchy.  Also, it will make it difficult for the IETF to liaise with or submit specs to organizations like the W3C and other international bodies who rely on RAND terms as the non assert can cause confusion in various jurisdictions.

 

Kim Turner

 

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of David Rudin (LCA)
Sent: Tuesday, August 13, 2013 10:04 PM
To: Stephan Wenger; ipr-wg@ietf.org
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing

 

Hi Stephan,

 

I think there are a lot of issues in this statement “[w]ith 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)” that need to be considered.

 

One issue is the notion that non-asserts are preferred over RANDz.  A royalty-free non-assert and RANDz licensing commitment are very different things.  While a RANDz commitment generally doesn’t include specific terms, it does mean that an implementer will be able to get a reasonable and non-discriminatory license, and those terms can be negotiated by the parties (though in reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law to tell us what kind of terms are reasonable and non-discriminatory.

 

Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be take it or leave it affairs.  If you don’t like the terms, there are no assurances that you can get different ones.  And that leads directly to the non-assert terms themselves.  I’ve certainly seen non-asserts that are solid, but I’ve also seen a number that can be extremely problematic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing unacceptable terms.

 

For just one example, non-asserts can include extremely broad grant back provisions that effectively require an implementer not to assert any of its patents, even for those that read on things that have nothing do to with the covered RFC, in exchange for a patent grant for a single RFC.  There are certainly good arguments that broad grant back provisions are not RANDz terms, and providing a preference to non-RANDz terms just because they’re in the form of a non-assert is not going to help adoption.

 

Requiring compatibility with OSS licenses also doesn’t help much since it’s not at all clear what that means.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it’s compatible with Apache and not GPL? (Even Apache is not considered to be compatible with GPLv2.)

 

It’s probably also worth considering whether the non-asserts themselves would be compatible with each other.  I’ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents available under the same terms, yet most IETF declarants providing non-asserts use their own custom terms.  If you have two non-asserts each requiring recipients provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone needs to provide multiple terms to satisfy the conditions of the various non-asserts for a given RFC?

 

Like any other legal agreement, with non-asserts the devil is in the details.  Expressing a preference for non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 

At least speaking for one implementer, a RANDz commitment provides a much greater level of comfort compared to the situation posed by various incompatible and potentially onerous non-asserts.

 

David

 

 

 

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensing

 

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

 



_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www.ietf.org/mailman/listinfo/ipr-wg



-- 
// Standard "perasonal email" disclaimers apply
--------------040600050409000207000402-- From stewe@stewe.org Thu Aug 15 12:44:40 2013 Return-Path: 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 2CC9611E80EE for ; Thu, 15 Aug 2013 12:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 WsUGizW6Wj3V for ; Thu, 15 Aug 2013 12:44:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id C8BE411E80AD for ; Thu, 15 Aug 2013 12:44:33 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB192.namprd07.prod.outlook.com (10.242.167.144) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 15 Aug 2013 19:44:29 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) with mapi id 15.00.0745.000; Thu, 15 Aug 2013 19:44:28 +0000 From: Stephan Wenger To: "Turner, Kimberly A" , "David Rudin (LCA)" , "ipr-wg@ietf.org" Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgAE/9NCAAN/PgA== Date: Thu, 15 Aug 2013 19:44:28 +0000 Message-ID: In-Reply-To: <2D626A91E9F8394BAD9FC1A863B8C1F75B86F9E1@ORSMSX109.amr.corp.intel.com> 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: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(53754006)(377454003)(51856001)(18717965001)(77982001)(59766001)(74366001)(76176001)(19300405004)(65816001)(66066001)(80022001)(19580405001)(19580385001)(83072001)(19580395003)(16236675002)(81816001)(81686001)(76796001)(76786001)(83322001)(36756003)(46102001)(50986001)(47976001)(63696002)(561944002)(47736001)(49866001)(79102001)(15202345003)(4396001)(81542001)(1511001)(69226001)(74876001)(16406001)(53806001)(54356001)(56776001)(80976001)(54316002)(76482001)(77096001)(56816003)(74706001)(47446002)(74502001)(74662001)(81342001)(31966008)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB192; 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_CE327772A0F20stewesteweorg_" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 19:44:40 -0000 --_000_CE327772A0F20stewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kim, Long time=85 Please see inline. Stephan From: , Kimberly A > Date: Thursday, 15 August, 2013 11:30 To: "David Rudin (LCA)" >, Stephan Wenger >, "ipr-= wg@ietf.org" > Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing I also agree with David on the issues are the use of the statement =93[w]it= h respect to technologies with IPR claim(s) against them, the IETF prefers = open-source-friendly non-assert terms over reasonable and non-discriminator= y royalty-free terms (RAND-Z)=94. I don=92t agree that this is clear enoug= h to even understand what is truly meant and, as David points out, leaves o= pen the opportunity for many questions and interpretations. StW: Intentionally so, as explained before (in my initial email). Tighteni= ng this up would be a nightmare, and remember: the IETF does allow free-for= m declarations of licensing terms, and the use of free-form is the norm. I also agree that having this hierarchy will lead to quite a bit of difficu= lty within the work groups because we have no idea how or when or who will = decide when to invoke the hierarchy. StW: You are aware that we have such a hierarchy already, since at least 20= 04 (RFC 3668, and RFC 3979, Section 8)? All I did was adding the non-asser= t, and a bit of tightening up the language. I have closely followed the IE= TF's IPR developments between 2004 and now, and I do not recall any issues = that have come up with respect to this. Also, it will make it difficult for the IETF to liaise with or submit specs= to organizations like the W3C and other international bodies who rely on R= AND terms as the non assert can cause confusion in various jurisdictions. StW: I disagree. I assume the issue with "liaising" is related to normativ= e referencing and things like Rec. A.5 in the ITU, and corresponding policy= restrictions in other SDOs. With respect to that: A majority of IETF disc= losures, today, are non-assert statements. IETF RFCs with disclosed patent= s under non-assert terms are routinely normatively referenced by bodies suc= h the ITU, 3GPP (ETSI), and others. Kim Turner From: ipr-wg-bounces@ietf.org [mailto:ipr-w= g-bounces@ietf.org] On Behalf Of David Rudin (LCA) Sent: Tuesday, August 13, 2013 10:04 PM To: Stephan Wenger; ipr-wg@ietf.org Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Hi Stephan, I think there are a lot of issues in this statement =93[w]ith respect to te= chnologies with IPR claim(s) against them, the IETF prefers open-source-fri= endly non-assert terms over reasonable and non-discriminatory royalty-free = terms (RAND-Z)=94 that need to be considered. One issue is the notion that non-asserts are preferred over RANDz. A royal= ty-free non-assert and RANDz licensing commitment are very different things= . While a RANDz commitment generally doesn=92t include specific terms, it = does mean that an implementer will be able to get a reasonable and non-disc= riminatory license, and those terms can be negotiated by the parties (thoug= h in reality actual RANDz licenses tend to be extremely rare). We also hav= e an increasing amount of case law to tell us what kind of terms are reason= able and non-discriminatory. Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be = take it or leave it affairs. If you don=92t like the terms, there are no a= ssurances that you can get different ones. And that leads directly to the = non-assert terms themselves. I=92ve certainly seen non-asserts that are so= lid, but I=92ve also seen a number that can be extremely problematic to imp= lementers. With a take it or leave it non-assert, an implementer can be he= ld up by patent holder providing unacceptable terms. For just one example, non-asserts can include extremely broad grant back pr= ovisions that effectively require an implementer not to assert any of its p= atents, even for those that read on things that have nothing do to with the= covered RFC, in exchange for a patent grant for a single RFC. There are c= ertainly good arguments that broad grant back provisions are not RANDz term= s, and providing a preference to non-RANDz terms just because they=92re in = the form of a non-assert is not going to help adoption. Requiring compatibility with OSS licenses also doesn=92t help much since it= =92s not at all clear what that means. Is it ok if the non-assert is compa= tible with BSD but not Apache? What about if it=92s compatible with Apache= and not GPL? (Even Apache is not considered to be compatible with GPLv2.) It=92s probably also worth considering whether the non-asserts themselves w= ould be compatible with each other. I=92ve seen a number of non-asserts at= IETF that are conditioned on the recipient making their patents available= under the same terms, yet most IETF declarants providing non-asserts use t= heir own custom terms. If you have two non-asserts each requiring recipien= ts provide the same terms, whose terms trump? Or, does it result in a casc= ading effect where everyone needs to provide multiple terms to satisfy the = conditions of the various non-asserts for a given RFC? Like any other legal agreement, with non-asserts the devil is in the detail= s. Expressing a preference for non-asserts that may include problematic te= rms is just as likely to hurt adoption as it is to help. At least speaking for one implementer, a RANDz commitment provides a much g= reater level of comfort compared to the situation posed by various incompat= ible and potentially onerous non-asserts. David From:ipr-wg-bounces@ietf.org [mailto:ipr-wg= -bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, August 13, 2013 9:19 AM To: ipr-wg@ietf.org Subject: RFC3979bis section 7 -- hierarchy of preference for licensing 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_CE327772A0F20stewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3348D9C42677924F9AAF614D99795C29@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Kim,
Long time=85
Please see inline.
Stephan

From: <Turner>, Kimberly A &l= t;kimberly.a.turner@intel.co= m>
Date: Thursday, 15 August, 2013 11:= 30
To: "David Rudin (LCA)" &= lt;David.Rudin@microsoft.com>, Stephan Wenger <stewe@stewe.o= rg>, "ipr-wg@ietf.org&qu= ot; <ipr-wg@ietf.org>
Subject: RE: RFC3979bis section 7 -= - hierarchy of preference for licensing

I also agree with David on the iss= ues are the use of the statement =93[w]ith respect to technologies with IPR claim(s) against them, the IETF prefers o= pen-source-friendly non-assert terms over reasonable and non-discriminatory= royalty-free terms (RAND-Z)=94.  I don=92t agree that this is clear e= nough to even understand what is truly meant and, as David points out, leaves open the opportunity for many questions a= nd interpretations. 


StW: Intentionally so, as explained before (in my initial email). &nbs= p;Tightening this up would be a nightmare, and remember: the IETF does allo= w free-form declarations of licensing terms, and the use of free-form is th= e norm.

I also agree that having this hier= archy will lead to quite a bit of difficulty within the work groups because= we have no idea how or when or who will decide when to invoke the hierarchy. 


StW: You are aware that we have such a hierarchy already, since at lea= st 2004 (RFC 3668, and RFC 3979, Section 8)?  All I did was adding the= non-assert, and a bit of tightening up the language.  I have closely = followed the IETF's IPR developments between 2004 and now, and I do not recall any issues that have come up with respec= t to this.

Also, it will make it difficult fo= r the IETF to liaise with or submit specs to organizations like the W3C and= other international bodies who rely on RAND terms as the non assert can cause confusion in various jurisdictio= ns.

StW: I disagree.  I assume the issue with "liaising" is= related to normative referencing and things like Rec. A.5 in the ITU, and = corresponding policy restrictions in other SDOs.  With respect to that= : A majority of IETF disclosures, today, are non-assert statements.  IETF RFCs with disclosed patents under non-assert terms = are routinely normatively referenced by bodies such the ITU, 3GPP (ETSI), a= nd others.  

 

Kim Turner

 

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of David Rudin (LCA)
Sent: Tuesday, August 13, 2013 10:04 PM
To: Stephan Wenger; ipr-wg@ietf.o= rg
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for lic= ensing

 

Hi Stephan,

 

I think there are a lot of issues = in this statement =93[w]ith respect to technologies with IPR claim(s) again= st them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms= (RAND-Z)=94 that need to be considered.

 

One issue is the notion that non-a= sserts are preferred over RANDz.  A royalty-free non-assert and RANDz = licensing commitment are very different things.  While a RANDz commitment generally doesn=92t include specific terms, it do= es mean that an implementer will be able to get a reasonable and non-discri= minatory license, and those terms can be negotiated by the parties (though = in reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law= to tell us what kind of terms are reasonable and non-discriminatory.<= /o:p>

 

Unlike a RANDz commitment, which c= an be negotiated, non-asserts tend to be take it or leave it affairs. = If you don=92t like the terms, there are no assurances that you can get different ones.  And that leads directly = to the non-assert terms themselves.  I=92ve certainly seen non-asserts= that are solid, but I=92ve also seen a number that can be extremely proble= matic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing un= acceptable terms.

 

For just one example, non-asserts = can include extremely broad grant back provisions that effectively require = an implementer not to assert any of its patents, even for those that read on things that have nothing do to wi= th the covered RFC, in exchange for a patent grant for a single RFC.  = There are certainly good arguments that broad grant back provisions are not= RANDz terms, and providing a preference to non-RANDz terms just because they=92re in the form of a non-assert is n= ot going to help adoption.

 

Requiring compatibility with OSS l= icenses also doesn=92t help much since it=92s not at all clear what that me= ans.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it=92s compatible with Apache= and not GPL? (Even Apache is not considered to be compatible with GPLv2.)<= o:p>

 

It=92s probably also worth conside= ring whether the non-asserts themselves would be compatible with each other= .  I=92ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents avai= lable under the same terms, yet most IETF declarants providing non-asserts = use their own custom terms.  If you have two non-asserts each requirin= g recipients provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone= needs to provide multiple terms to satisfy the conditions of the various n= on-asserts for a given RFC?

 

Like any other legal agreement, wi= th non-asserts the devil is in the details.  Expressing a preference f= or non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 

At least speaking for one implemen= ter, a RANDz commitment provides a much greater level of comfort compared t= o the situation posed by various incompatible and potentially onerous non-asserts.

 

David

 

 

 

From:ipr-= wg-bounces@ietf.org [mailto:= ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensi= ng

 

H= i all,

 

I= n 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 clar= ifications or modifications that go beyond editorial input.  I had som= e private discussions with Scott and Jorge, and was asked by them to provid= e input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concern= ing this section.

 

T= o 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 th= e day-to-day operations of the IETF.  The title of the section is "Evaluating Alternative Technologie= s in IETF Working Groups".  It explains, among other things, how = working groups can react to received IPR disclosures.  (Note that RFC3= 979 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).=

 

T= his post is about the first sentence of RFC 3979, which reads:<= /o:p>

 

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

 

I= propose to replace this sentence with:

 

In general, to s= olve a given problem, the IETF prefers technologies with no known IPR over = technologies with IPR claim(s) against them.  With respect to technolo= gies 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 unde= r 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.

 

T= he 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 license= s are royalty-free or not or whether unlicensed use of the technology gener= ally is tolerated even if it were against the text of the disclosure. Let m= e also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all categories men= tioned above, including the final one.

 

T= he 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", a= nd 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&= quot; 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 protect= ion, even if the amount of protection offered is currently unclear, and bec= ause 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 defi= ne the term RAND.

 

T= hanks for your consideration of my proposal.

 

S= tephan

 

 --_000_CE327772A0F20stewesteweorg_-- From ted.ietf@gmail.com Thu Aug 15 16:31:18 2013 Return-Path: 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 08DAA11E8176 for ; Thu, 15 Aug 2013 16:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 S3Ho1-5NTA6Y for ; Thu, 15 Aug 2013 16:31:17 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4411E814D for ; Thu, 15 Aug 2013 16:31:16 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd12so2429926ieb.0 for ; Thu, 15 Aug 2013 16:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fNqtSUs1Ey3EaxEst94yOd2gK9W8wZJZSRKcVb4/GhA=; b=z6yFmPaWeUZPwtvavGJ8zFdcbu/facLQ0sq0dQe4i6Md+ebOlnfmWeXWuEKUJwpuI9 I5wl1Pp/g/zE17p/LvG5lFkZhUP22FvPNsItnMuFpkd0ryFhqfXZy+Nr4gkDyfCYg96o rAKu+XalnXkp6AHX6ivF/YDPoSz+HdX26n+RdE5D0x5fLZpa8KElEi7VRVPZi56dgBdM mKGpFeEbWrgOlU8LSdBtmthTFrprRsjdt5l1HuOjzrvWSrFVvcaYs6vVyN9KgyOrZLBT r/vZVU5hJE+Y8kLfm7fPwzSw3ozghobN2jGLna9hrlKFylqwiqO+AsLnssOZdlLdHBYI T/8A== MIME-Version: 1.0 X-Received: by 10.50.111.197 with SMTP id ik5mr3462351igb.19.1376609475689; Thu, 15 Aug 2013 16:31:15 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Thu, 15 Aug 2013 16:31:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Aug 2013 16:31:15 -0700 Message-ID: Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing From: Ted Hardie To: Stephan Wenger Content-Type: multipart/alternative; boundary=047d7b4142d6cb049f04e404deec Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:31:18 -0000 --047d7b4142d6cb049f04e404deec Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger wrote: > In particular, right after the sentence I try to improve on, follows: > " > But IETF working groups have the discretion > to adopt technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel that this > technology is superior enough to alternatives with fewer IPR claims > or free licensing to outweigh the potential cost of the licenses. > " > Isn't that already addressing your concern? > I don't think it is adequate any more. The old stuff basically said "We want to get fair and non-discriminatory, and when we don't get it for a superior technology, the working group could still choose the superior technology". Not quite a binary view of "yes,we got what we want" vs. "no we didn't", but certainly not a full hierarchy either. A working group choosing between technology A. (non-assert) and technology B. (RAND-Z) isn't really in the same place as one chosing between C (non-assert) and F (rand-with-royalties). It's making a very different trade-off, and I think that should be made clear. We should say that the working group (not this hierarchical list) makes the trade-off; it may be informed by this general list, but if it has even a moderate reason to prefer B over A, that may be justifiable. Put a very different way "superior enough" is pretty variable, and the judge is the working group--let's make that clear. > Should we change the order of the parts of the section, such that the > above citation (or something similar) appears prominently at the begin of > section 7? > > I don't think the ordering is salient, here, personally, as by the time we get to referring to this document, people better be reading the whole thing. Ted > Stephan > > > > From: Ted Hardie > Date: Wednesday, 14 August, 2013 08:48 > To: Stephan Wenger > Cc: "ipr-wg@ietf.org" > Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing > > So, I've read the thread to this point, and as I watched I got more and > more niggled with the feeling that it was heading in the wrong direction. > > As I thought about why, I realized that the whole of hierarchy of > preference discussion is disconnected from what a WG does: make > tradeoffs. A working group faced with technology A with license FOO and > technology B with license BAR is almost never going to pick solely on > license; it's a balance of the benefits of the technology and the > consequences of the license. Creating a hierarchy of preference for > license terms has a sort of theoretical advantage in that it tells people > who are considering what licenses the IETF likes. Those people probably > have lawyers with other things to think about it, so I suspect it of being > pretty theoretical, but harmless. > > This section, though, does not seem to me good enoughfi we are going to > state a preference hierarchy.: > > 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. But IETF working groups have the discretion > to adopt technology with a commitment of fair and non-discriminatory > terms, or even with no licensing commitment, if they feel that this > technology is superior enough to alternatives with fewer IPR claims > or free licensing to outweigh the potential cost of the licenses. > > I think we need language that says explicitly that the working group makes > the trade-off between the technology's advantages and the license's > conditions. Otherwise, I foresee WGs with people arguing that technology B > must be chosen because its license is higher in the hierarchy and > acceptable (for some value of acceptable). > --047d7b4142d6cb049f04e404deec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger <stewe@ste= we.org> wrote:
=A0In particular, right = after the sentence I try to improve on, follows:
"
But IETF working groups have the discretion
to adopt technology with a commitment of fair a= nd non-discriminatory
terms, or even with no licensing commitment, if= they feel that this
technology is superior enough to alternatives w= ith fewer IPR claims
or free licensing to outweigh the potential cos= t of the licenses.
"
Isn't that already = addressing your concern? =A0

I don't think it is adequate any more.=A0 The old stuff= basically said "We want to get fair and non-discriminatory, and when = we don't get it for a superior technology, the working group could stil= l choose the superior technology".=A0=A0 Not quite a binary view of &q= uot;yes,we got what we want" vs. "no we didn't", but cer= tainly not a full hierarchy either.=A0

A working group choosing between technology A. (non-assert) and technol= ogy B. (RAND-Z)=A0 isn't really in the same place as one chosing betwee= n C (non-assert) and F (rand-with-royalties).=A0 It's making a very dif= ferent trade-off, and I think that should be made clear.=A0 We should say t= hat the working group (not this hierarchical list) makes the trade-off; it = may be informed by this general list, but if it has even a moderate reason = to prefer B over A, that may be justifiable.

Put a very different way "superior enough" is pret= ty variable, and the judge is the working group--let's make that clear.=

=A0
Should we change the order of the parts of the sectio= n, such that the above citation (or something similar) appears prominently = at the begin of section 7?

=

I don't think the ordering is salient, here, person= ally, as by the time we get to referring to this document, people better be= reading the whole thing.

Ted
=A0
Stephan



From: Ted Hardie <ted.ietf@gmail.com>
Date: Wednesday, 14 August, 2013 08= :48
To: Stephan Wenger <stewe@stewe.org>
Cc: "ipr-wg@ietf.org" <ipr-wg@ietf.org>
Subject: Re: RFC3979bis section 7 -= - hierarchy of preference for licensing

So, I've read the thread to this point, and as I watched I got mor= e and more niggled with the feeling that it was heading in the wrong direct= ion.=A0

As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does:=A0 make tradeoffs.=A0=A0 = A working group faced with technology A with license FOO and technology B w= ith license BAR is almost never going to pick solely on license; it's a balance of the benefits of the techn= ology and the consequences of the license.=A0 Creating a hierarchy of prefe= rence for license terms has a sort of theoretical advantage in that it tell= s people who are considering what licenses the IETF likes.=A0 Those people probably have lawyers with other things to= think about it, so I suspect it of being pretty theoretical, but harmless.=

This section, though, does not seem to me good enoughfi=A0 we are going to = state a preference hierarchy.:

   In general, IETF working groups prefer technologies with no known I=
PR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's= conditions.=A0 Otherwise, I foresee WGs with people arguing that technolog= y B must be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable).

--047d7b4142d6cb049f04e404deec-- From stewe@stewe.org Thu Aug 15 16:42:38 2013 Return-Path: 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 D6C4311E81C1 for ; Thu, 15 Aug 2013 16:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 KRgKx8OU9R5I for ; Thu, 15 Aug 2013 16:42:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48C11E80D7 for ; Thu, 15 Aug 2013 16:42:32 -0700 (PDT) Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB109.namprd07.prod.outlook.com (10.242.167.15) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 15 Aug 2013 23:42:29 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) by CO1PR07MB191.namprd07.prod.outlook.com (10.242.167.145) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 15 Aug 2013 23:42:28 +0000 Received: from CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) by CO1PR07MB191.namprd07.prod.outlook.com ([169.254.3.103]) with mapi id 15.00.0745.000; Thu, 15 Aug 2013 23:42:28 +0000 From: Stephan Wenger To: Ted Hardie Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgADAy4CAAQKTAIABESeA//+NvgA= Date: Thu, 15 Aug 2013 23:42:27 +0000 Message-ID: In-Reply-To: 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: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51444003)(189002)(199002)(377454003)(4396001)(47736001)(81342001)(54316002)(56776001)(77982001)(47976001)(50986001)(74662001)(31966008)(69226001)(74502001)(47446002)(81542001)(49866001)(56816003)(76482001)(53806001)(59766001)(54356001)(77096001)(19580395003)(83322001)(19580405001)(16236675002)(83072001)(80022001)(66066001)(65816001)(46102001)(80976001)(51856001)(76176001)(79102001)(16406001)(36756003)(76786001)(74366001)(76796001)(81816001)(63696002)(74876001)(74706001)(81686001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB191; 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_CE32B41FA1081stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:42:39 -0000 --_000_CE32B41FA1081stewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, I see your points, and I concur. If we were extending the hierarchy by add= ing non-assert, that sentence I quoted below has to be adjusted and most li= kely expanded on. I have no problems in adding word count here as this is = IMO one of the most important features of the IETF IPR policy and certainly= one that is uncommon in major SDOs. I should have mentioned this in my o= riginal mail. Stephan From: Ted Hardie > Date: Thursday, 15 August, 2013 16:31 To: Stephan Wenger > Cc: "ipr-wg@ietf.org" > Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger > wrote: In particular, right after the sentence I try to improve on, follows: " But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. " Isn't that already addressing your concern? I don't think it is adequate any more. The old stuff basically said "We wa= nt to get fair and non-discriminatory, and when we don't get it for a super= ior technology, the working group could still choose the superior technolog= y". Not quite a binary view of "yes,we got what we want" vs. "no we didn'= t", but certainly not a full hierarchy either. A working group choosing between technology A. (non-assert) and technology = B. (RAND-Z) isn't really in the same place as one chosing between C (non-a= ssert) and F (rand-with-royalties). It's making a very different trade-off= , and I think that should be made clear. We should say that the working gr= oup (not this hierarchical list) makes the trade-off; it may be informed by= this general list, but if it has even a moderate reason to prefer B over A= , that may be justifiable. Put a very different way "superior enough" is pretty variable, and the judg= e is the working group--let's make that clear. Should we change the order of the parts of the section, such that the above= citation (or something similar) appears prominently at the begin of sectio= n 7? I don't think the ordering is salient, here, personally, as by the time we = get to referring to this document, people better be reading the whole thing= . Ted Stephan From: Ted Hardie > Date: Wednesday, 14 August, 2013 08:48 To: Stephan Wenger > Cc: "ipr-wg@ietf.org" > Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing So, I've read the thread to this point, and as I watched I got more and mor= e niggled with the feeling that it was heading in the wrong direction. As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does: make tradeoffs. A work= ing group faced with technology A with license FOO and technology B with li= cense BAR is almost never going to pick solely on license; it's a balance o= f the benefits of the technology and the consequences of the license. Crea= ting a hierarchy of preference for license terms has a sort of theoretical = advantage in that it tells people who are considering what licenses the IET= F likes. Those people probably have lawyers with other things to think abo= ut it, so I suspect it of being pretty theoretical, but harmless. This section, though, does not seem to me good enoughfi we are going to st= ate a preference hierarchy.: 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. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons. Otherwise, I foresee WGs with people arguing that technology B must b= e chosen because its license is higher in the hierarchy and acceptable (for= some value of acceptable). --_000_CE32B41FA1081stewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <12DC02B612267D4CB0297A1F6610BF30@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Ted,
I see your points, and I concur.  If we were extending the hierar= chy by adding non-assert, that sentence I quoted below has to be adjusted a= nd most likely expanded on.  I have no problems in adding word count h= ere as this is IMO one of the most important features of the IETF IPR policy and certainly one that is uncommon in majo= r SDOs.   I should have mentioned this in my original mail.  
Stephan


From: Ted Hardie <ted.ietf@gmail.com>
Date: Thursday, 15 August, 2013 16:= 31
To: Stephan Wenger <stewe@stewe.org>
Cc: "ipr-wg@ietf.org" <= ipr-wg@ietf.org>
Subject: Re: RFC3979bis section 7 -= - hierarchy of preference for licensing

On Thu, Aug 15, 2013 at 7:13 AM, Stephan Wenger <stewe@ste= we.org> wrote:
 In particular, rig= ht after the sentence I try to improve on, follows:
"
But IETF working groups have the discretion
to adopt technology with a commitment of fair a= nd non-discriminatory
terms, or even with no licensing commitment, if= they feel that this
technology is superior enough to alternatives w= ith fewer IPR claims
or free licensing to outweigh the potential cos= t of the licenses.
"
Isn't that already addressing= your concern?  

I don't think it is adequate any more.  The old stuff basically s= aid "We want to get fair and non-discriminatory, and when we don't get= it for a superior technology, the working group could still choose the sup= erior technology".   Not quite a binary view of "yes,we got what we want" vs. "no we didn't", but c= ertainly not a full hierarchy either. 

A working group choosing between technology A. (non-assert) and technology = B. (RAND-Z)  isn't really in the same place as one chosing between C (= non-assert) and F (rand-with-royalties).  It's making a very different= trade-off, and I think that should be made clear.  We should say that the working group (not this hierarchical l= ist) makes the trade-off; it may be informed by this general list, but if i= t has even a moderate reason to prefer B over A, that may be justifiable.
Put a very different way "superior enough" is pretty variabl= e, and the judge is the working group--let's make that clear.

 
Should we change the order of= the parts of the section, such that the above citation (or something simil= ar) appears prominently at the begin of section 7?


I don't think the ordering is salient, here, personally, as by the tim= e we get to referring to this document, people better be reading the whole = thing.

Ted
 
Stephan



From: Ted Hardie <ted.ietf@gmail.com>
Date: Wednesday, 14 August, 2013 08= :48
To: Stephan Wenger <stewe@stewe.org>
Cc: "ipr-wg@ietf.org" <ipr-wg@ietf.org>
Subject: Re: RFC3979bis section 7 -= - hierarchy of preference for licensing

So, I've read the thread to this point, and as I watched I got more an= d more niggled with the feeling that it was heading in the wrong direction.=  

As I thought about why, I realized that the whole of hierarchy of preferenc= e discussion is disconnected from what a WG does:  make tradeoffs.&nbs= p;  A working group faced with technology A with license FOO and techn= ology B with license BAR is almost never going to pick solely on license; it's a balance of the benefits of the technolog= y and the consequences of the license.  Creating a hierarchy of prefer= ence for license terms has a sort of theoretical advantage in that it tells= people who are considering what licenses the IETF likes.  Those people probably have lawyers with other things= to think about it, so I suspect it of being pretty theoretical, but harmle= ss.

This section, though, does not seem to me good enoughfi  we are going = to state a preference hierarchy.:

   In general, IETF working groups prefer technologies with no known I=
PR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  But IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
I think we need language that says explicitly that the working group makes = the trade-off between the technology's advantages and the license's conditi= ons.  Otherwise, I foresee WGs with people arguing that technology B m= ust be chosen because its license is higher in the hierarchy and acceptable (for some value of acceptable).

 --_000_CE32B41FA1081stewesteweorg_-- From David.Rudin@microsoft.com Fri Aug 16 14:23:26 2013 Return-Path: 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 2747B21F9D11 for ; Fri, 16 Aug 2013 14:23:13 -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 icxSwCn1GxrA for ; Fri, 16 Aug 2013 14:23:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id AE8D211E815B for ; Fri, 16 Aug 2013 14:22:56 -0700 (PDT) Received: from BLUPR03CA036.namprd03.prod.outlook.com (10.141.30.29) by BLUPR03MB277.namprd03.prod.outlook.com (10.255.213.15) with Microsoft SMTP Server (TLS) id 15.0.745.25; Fri, 16 Aug 2013 21:22:53 +0000 Received: from BY2FFO11FD019.protection.gbl (2a01:111:f400:7c0c::23) by BLUPR03CA036.outlook.office365.com (2a01:111:e400:879::29) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Fri, 16 Aug 2013 21:22:53 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Fri, 16 Aug 2013 21:22:52 +0000 Received: from TK5EX14MBXC294.redmond.corp.microsoft.com ([169.254.3.180]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Fri, 16 Aug 2013 21:21:21 +0000 From: "David Rudin (LCA)" To: Stephan Wenger , "ipr-wg@ietf.org" Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Topic: RFC3979bis section 7 -- hierarchy of preference for licensing Thread-Index: AQHOmEDhcIeQON3L40qNzrLqKz06gJmUGgqQgAG/2ICAAmwHAA== Date: Fri, 16 Aug 2013 21:21:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_B68EFB284B10C249835C566A0CE08AA2499022BDTK5EX14MBXC294r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(189002)(199002)(53754006)(47446002)(74662001)(44976005)(74502001)(31966008)(15202345003)(19300405004)(33656001)(19580395003)(561944002)(83072001)(83322001)(81686001)(6806004)(19580385001)(56816003)(16236675002)(81816001)(51856001)(19580405001)(74876001)(80976001)(77096001)(53806001)(46102001)(77982001)(512954002)(59766001)(76796001)(74366001)(69226001)(63696002)(76786001)(56776001)(20776003)(54316002)(66066001)(54356001)(74706001)(80022001)(79102001)(76482001)(55846006)(65816001)(71186001)(47736001)(49866001)(47976001)(81342001)(4396001)(50986001)(81542001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB277; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0940A19703 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BY2FFO11FD019.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB277.namprd03.prod.outlook.com X-Mailman-Approved-At: Sat, 17 Aug 2013 08:03:14 -0700 X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 21:23:27 -0000 --_000_B68EFB284B10C249835C566A0CE08AA2499022BDTK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Stephan, I've included my responses inline. Best, David From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, August 15, 2013 7:01 AM To: David Rudin (LCA); ipr-wg@ietf.org Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing Hi David, Please see inline. Stephan From: "David Rudin (LCA)" > Date: Tuesday, 13 August, 2013 22:03 To: Stephan Wenger >, "ipr-wg@ietf.= org" > Subject: RE: RFC3979bis section 7 -- hierarchy of preference for licensing Hi Stephan, I think there are a lot of issues in this statement "[w]ith respect to tech= nologies with IPR claim(s) against them, the IETF prefers open-source-frien= dly non-assert terms over reasonable and non-discriminatory royalty-free te= rms (RAND-Z)" that need to be considered. One issue is the notion that non-asserts are preferred over RANDz. A royal= ty-free non-assert and RANDz licensing commitment are very different things= . While a RANDz commitment generally doesn't include specific terms, it do= es mean that an implementer will be able to get a reasonable and non-discri= minatory license, and those terms can be negotiated by the parties (though = in reality actual RANDz licenses tend to be extremely rare). We also have = an increasing amount of case law to tell us what kind of terms are reasonab= le and non-discriminatory. Unlike a RANDz commitment, which can be negotiated, non-asserts tend to be = take it or leave it affairs. If you don't like the terms, there are no ass= urances that you can get different ones. And that leads directly to the no= n-assert terms themselves. I've certainly seen non-asserts that are solid,= but I've also seen a number that can be extremely problematic to implement= ers. With a take it or leave it non-assert, an implementer can be held up = by patent holder providing unacceptable terms. For just one example, non-asserts can include extremely broad grant back pr= ovisions that effectively require an implementer not to assert any of its p= atents, even for those that read on things that have nothing do to with the= covered RFC, in exchange for a patent grant for a single RFC. There are c= ertainly good arguments that broad grant back provisions are not RANDz term= s, and providing a preference to non-RANDz terms just because they're in th= e form of a non-assert is not going to help adoption. StW: I concur with most of what you say above, including the underlying sen= timent that a signed and sealed RAND-Z license is preferable to many implem= enters (though not necessarily all the open source folks). However, nothin= g what you write above changes that, at least based on my impression, the I= ETF as an organization indeed prefers non-assert statements, even with broa= d grant back provisions and other unpalatable terms, over RAND-Z licensing = covenants. As the very minimum, the overwhelming majority of participants,= and the IETF is a consensus based organization, right? The reason for my = proposed modification lies in the alignment of the policy to the practice o= f the IETF as of today. Let me also note that practically all non-assert d= isclosures include an offer for negotiation of a bilateral (typically RAND)= license, for reasons I certainly do not need to explain to you :-) That o= ught to alleviate some of your concerns. DR: You're correct than many non-asserts made at IETF include an offer to = negotiate a RAND license in place of a non-assert, but it's by no means uni= versal. Even those that do, however, generally provide a royalty-free non-= assert plus the option to negotiate a royalty-bearing RAND license. In oth= er words, in those non-asserts the free option is still a take it or leave = it affair, but if you're not comfortable with the non-assert, you'll need t= o pay. It's not at all clear to me why a non-assert with, for example, bro= ad reciprocity with the option to pay if you want better terms would be pre= ferable to a RAND-z commitment that says implementers will be able to get a= royalty-free license. In the case of a non-assert with a RAND option, it'= s hard to say that's a royalty-free grant, or that it's a grant that better= than a RANDz commitment. Requiring compatibility with OSS licenses also doesn't help much since it's= not at all clear what that means. Is it ok if the non-assert is compatibl= e with BSD but not Apache? What about if it's compatible with Apache and n= ot GPL? (Even Apache is not considered to be compatible with GPLv2.) StW: I disagree with your first sentence. It helps, even if it is not clear= ly defined. As I have already stated, it is up to the implementer communit= y of an RFC--however that community may be composed--to beat up a non-asser= t disclosure that it considers incompatible with their business model. DR: While I still don't see it helps given the variety of OSS licenses tha= t are available or could be drafted, perhaps a larger issue is why IETF wou= ld provide preferential treatment to one licensing model over others? I am= not aware of any other standards setting organization that does so, and I = believe there are very good reasons for SSOs to operate in a non-discrimina= tory manner. It's probably also worth considering whether the non-asserts themselves wou= ld be compatible with each other. I've seen a number of non-asserts at IET= F that are conditioned on the recipient making their patents available und= er the same terms, yet most IETF declarants providing non-asserts use their= own custom terms. If you have two non-asserts each requiring recipients p= rovide the same terms, whose terms trump? Or, does it result in a cascadin= g effect where everyone needs to provide multiple terms to satisfy the cond= itions of the various non-asserts for a given RFC? StW: Once more, the preferences stated are what I believe (and others have = concurred!) the current practice of the IETF at large. The problem you men= tion may well exist in theory, but I have not seen an outcry--or even a civ= ilized discussion--about a problem like the one you mention that has occurr= ed in practice. DR: I actually am aware of at least one IETF group that has tried to encou= rage uniform licensing statements in an effort to avoid issues presented by= multiple and potentially conflicting licensing statements. That said, I t= hink the problems presented around RAND-z commitments tend to be largely th= eoretical in practice, and the standards world has much more time and exper= ience with RANDz commitments that we do with non-asserts. I see no lack o= f implementation of RANDz standards in practice. It's also exceedingly rar= e for implementers to seek a RANDz license and for patent holders to try to= enter into RANDz licenses with implementers (or litigate over them). Prov= iding a preference to non-asserts over RANDz over the theoretical issues ar= ound RANDz appears to replace a proven approach that has worked extremely w= ell with an alternative non-assert based approach that presents a new set o= f issues. Like any other legal agreement, with non-asserts the devil is in the detail= s. Expressing a preference for non-asserts that may include problematic te= rms is just as likely to hurt adoption as it is to help. At least speaking for one implementer, a RANDz commitment provides a much g= reater level of comfort compared to the situation posed by various incompat= ible and potentially onerous non-asserts. StW: On a personal level, I prefer a signed bilateral or pool license any d= ay over an uni-lateral non-assert statement, especially with broad reciproc= ity conditions or other unpalatable terms. I'm even willing to pay for it.= Makes me sleep better, and my business model allows for it. I'm not so s= ure, however, that a disclosure offering a RAND-Z license with undisclosed = terms (minus the -Z, of course) makes me sleep better as well. With a non-= assert, at least I know the conditions beforehand, and can cope with them, = or negotiate a license, or whatever... With the type of RAND-Z offers the = check-box system of the disclosure tool allows, I would actually have to ne= gotiate a license before I know the conditions, which is not only an expens= ive and lengthily undertaking (at least in misty cases), but also incompati= ble with some open source business models. David From: ipr-wg-bounces@ietf.org [mailto:ipr-w= g-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Tuesday, August 13, 2013 9:19 AM To: ipr-wg@ietf.org Subject: RFC3979bis section 7 -- hierarchy of preference for licensing 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 bey= ond 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) topic= s the list. This is the first of a series of emails all concerning this se= ction. 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 t= he day-to-day operations of the IETF. The title of the section is "Evaluat= ing Alternative Technologies in IETF Working Groups". It explains, among o= ther things, how working groups can react to received IPR disclosures. (No= te that RFC3979 covers only WGs, and not other IETF bodies, such as the IES= G 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 claim= s or, for technologies with claims against them, an offer of royalty-free l= icensing. 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-sourc= e-friendly non-assert terms over reasonable and non-discriminatory royalty-= free terms (RAND-Z), over technologies offered under reasonable and non-dis= criminatory terms but possibly incurring royalties (RAND), over technologie= s 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 (fre= e and) open source ecosystem which, in at least some cases, has difficultie= s in accepting technologies for which bi-lateral licenses need to be signed= , regardless of whether those licenses are royalty-free or not or whether u= nlicensed use of the technology generally is tolerated even if it were agai= nst 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 ment= ioned 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 meani= ngfully would quite likely require references to licensing schemes supporte= d 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 so= mething "better" from an adoption viewpoint than RANDZ, but "worse" than IP= R-claim-free, without going into details. I also stayed away from defining "RAND". I mentioned RAND a because the va= st majority of IETF disclosures mention RAND for reasons that are known to = the disclosers, the requirement for reasonable and non-discriminatory licen= sing is commonly believe to offer some protection, even if the amount of pr= otection offered is currently unclear, and because RAND is a requirement fo= r normative down referencing to many other SDOs. I do not believe that the= cumulative expertise of this list has the expertise--let alone the authori= ty--to define the term RAND. Thanks for your consideration of my proposal. Stephan --_000_B68EFB284B10C249835C566A0CE08AA2499022BDTK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Stephan,

 <= /p>

I’ve included my re= sponses inline.

 <= /p>

Best,

 <= /p>

David

 <= /p>

From: Stepha= n Wenger [mailto:stewe@stewe.org]
Sent: Thursday, August 15, 2013 7:01 AM
To: David Rudin (LCA); ipr-wg@ietf.org
Subject: Re: RFC3979bis section 7 -- hierarchy of preference for lic= ensing

 

Hi David,=

Please see inline.

Stephan

 

From: "David Rudin (LCA)" <David.Rudin@microsoft.com> Date: Tuesday, 13 August, 2013 22:03
To: Stephan Wenger <stewe@stew= e.org>, "ipr-wg@ietf.org= " <ipr-wg@ietf.org>
Subject: RE: RFC3979bis section 7 -- hierarchy of preference for lic= ensing

 

Hi Stephan,

 

I think there are a lot o= f issues in this statement “[w]ith respect to technologies with IPR c= laim(s) against them, the IETF prefers open-source-friendly non-assert terms over reasonable and non-discriminatory royalty-free terms (RAND-Z)&#= 8221; that need to be considered.

 

One issue is the notion t= hat non-asserts are preferred over RANDz.  A royalty-free non-assert a= nd RANDz licensing commitment are very different things.  While a RANDz commitment generally doesn’t include specific terms, it does= mean that an implementer will be able to get a reasonable and non-discrimi= natory license, and those terms can be negotiated by the parties (though in= reality actual RANDz licenses tend to be extremely rare).  We also have an increasing amount of case law to= tell us what kind of terms are reasonable and non-discriminatory.

 

Unlike a RANDz commitment= , which can be negotiated, non-asserts tend to be take it or leave it affai= rs.  If you don’t like the terms, there are no assurances that you can get different ones.  And that leads directly to the non-= assert terms themselves.  I’ve certainly seen non-asserts that a= re solid, but I’ve also seen a number that can be extremely problemat= ic to implementers.  With a take it or leave it non-assert, an implementer can be held up by patent holder providing unacceptable term= s.

 

For just one example, non= -asserts can include extremely broad grant back provisions that effectively= require an implementer not to assert any of its patents, even for those that read on things that have nothing do to with the covere= d RFC, in exchange for a patent grant for a single RFC.  There are cer= tainly good arguments that broad grant back provisions are not RANDz terms,= and providing a preference to non-RANDz terms just because they’re in the form of a non-assert is not going = to help adoption.

 

StW: I concur with most of = what you say above, including the underlying sentiment that a signed and se= aled RAND-Z license is preferable to many implementers (though not necessarily all the open source folks).  However, nothing what yo= u write above changes that, at least based on my impression, the IETF as an= organization indeed prefers non-assert statements, even with broad grant b= ack provisions and other unpalatable terms, over RAND-Z licensing covenants.  As the very minimum, the ove= rwhelming majority of participants, and the IETF is a consensus based organ= ization, right?  The reason for my proposed modification lies in the a= lignment of the policy to the practice of the IETF as of today.  Let me also note that practically all non-asse= rt disclosures include an offer for negotiation of a bilateral (typically R= AND) license, for reasons I certainly do not need to explain to you :-) &nb= sp;That ought to alleviate some of your concerns.

 <= /p>

DR:  You’re co= rrect than many non-asserts made at IETF include an offer to negotiate a RA= ND license in place of a non-assert, but it’s by no means universal.&= nbsp; Even those that do, however, generally provide a royalty-free non-assert p= lus the option to negotiate a royalty-bearing RAND license.  In other = words, in those non-asserts the free option is still a take it or leave it = affair, but if you’re not comfortable with the non-assert, you’ll need to pay.  It’s not at all= clear to me why a non-assert with, for example, broad reciprocity with the= option to pay if you want better terms would be preferable to a RAND-z com= mitment that says implementers will be able to get a royalty-free license.  In the case of a non-assert with a RAND opti= on, it’s hard to say that’s a royalty-free grant, or that it= 217;s a grant that better than a RANDz commitment.

 

Requiring compatibility w= ith OSS licenses also doesn’t help much since it’s not at all c= lear what that means.  Is it ok if the non-assert is compatible with BSD but not Apache?  What about if it’s compatible with Apache = and not GPL? (Even Apache is not considered to be compatible with GPLv2.)

 

StW: I disagree with your f= irst sentence. It helps, even if it is not clearly defined.  As I have= already stated, it is up to the implementer community of an RFC--however that community may be composed--to beat up a non-assert discl= osure that it considers incompatible with their business model.<= /span>

 <= /p>

DR:  While I still d= on’t see it helps given the variety of OSS licenses that are availabl= e or could be drafted, perhaps a larger issue is why IETF would provide preferential treatment to one licensing model over others?  I am not = aware of any other standards setting organization that does so, and I belie= ve there are very good reasons for SSOs to operate in a non-discriminatory = manner.    

 

It’s probably also = worth considering whether the non-asserts themselves would be compatible wi= th each other.  I’ve seen a number of non-asserts at IETF that are conditioned on the recipient  making their patents available unde= r the same terms, yet most IETF declarants providing non-asserts use their = own custom terms.  If you have two non-asserts each requiring recipien= ts provide the same terms, whose terms trump?  Or, does it result in a cascading effect where everyone needs to provide m= ultiple terms to satisfy the conditions of the various non-asserts for a gi= ven RFC?

 

StW: Once more, the prefere= nces stated are what I believe (and others have concurred!) the current pra= ctice of the IETF at large.  The problem you mention may well exist in theory, but I have not seen an outcry--or even a civilized d= iscussion--about a problem like the one you mention that has occurred in pr= actice.

 <= /p>

DR:  I actually am a= ware of at least one IETF group that has tried to encourage uniform licensi= ng statements in an effort to avoid issues presented by multiple and potentially conflicting licensing statements.  That said, I think= the problems presented around RAND-z commitments tend to be largely theore= tical in practice, and the standards world has much more time and experienc= e with RANDz commitments that we do with non-asserts.   I see no lack of implementation of RANDz standard= s in practice.  It’s also exceedingly rare for implementers to s= eek a RANDz license and for patent holders to try to enter into RANDz licen= ses with implementers (or litigate over them).  Providing a preference to non-asserts over RANDz over the theoretical issues around = RANDz appears to replace a proven approach that has worked extremely well w= ith an alternative non-assert based approach that presents a new set of iss= ues.

 

Like any other legal agre= ement, with non-asserts the devil is in the details.  Expressing a pre= ference for non-asserts that may include problematic terms is just as likely to hurt adoption as it is to help.

 

At least speaking for one= implementer, a RANDz commitment provides a much greater level of comfort c= ompared to the situation posed by various incompatible and potentially onerous non-asserts.

 

StW: On a personal level, I= prefer a signed bilateral or pool license any day over an uni-lateral non-= assert statement, especially with broad reciprocity conditions or other unpalatable terms.  I'm even willing to pay for it.  Ma= kes me sleep better, and my business model allows for it.  I'm not so = sure, however, that a disclosure offering a RAND-Z license with undisclosed= terms (minus the –Z, of course) makes me sleep better as well.  With a non-assert, at least I know the conditions be= forehand, and can cope with them, or negotiate a license, or whatever... &n= bsp;With the type of RAND-Z offers the check-box system of the disclosure t= ool allows, I would actually have to negotiate a license before I know the conditions, which is not only an expensive and= lengthily undertaking (at least in misty cases), but also incompatible wit= h some open source business models.

 

David

 

 

 

From: ipr-wg-bounces@ietf.org [mailto:ipr-wg-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Tuesday, August 13, 2013 9:19 AM
To: ipr-wg@ietf.org
Subject: RFC3979bis section 7 -- hierarchy of preference for licensi= ng

 =

Hi all,

 =

In Berlin's IPR BOF, one of the topics discu= ssed was language in section 7.  I had specific comments, and was aske= d 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 benef= it from clarifications or modifications that go beyond editorial input. &nb= sp;I had some private discussions with Scott and Jorge, and was asked by th= em to provide input on a few major (non-editorial) topics the list.  This is the first of a series of emails all concern= ing this section.

 =

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

 =

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

 =

In g= eneral, IETF working groups prefer technologies with no known IPR claims or= , for technologies with claims against them, an offer of royalty-free licen= sing.

 =

I propose to replace this sentence with:

 =

In g= eneral, to solve a given problem, the IETF prefers technologies with no kno= wn 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 reasonab= le and non-discriminatory royalty-free terms (RAND-Z), over technologies of= fered 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 rea= lity in the IETF at large as of 2013, and obviously only to the point I hav= e insight.  I believe that the RFC3979 text does not reflect reality as of 2013.

 =

The perhaps most important change is to ackn= owledge the existence of a (free and) open source ecosystem which, in at le= ast some cases, has difficulties in accepting technologies for which bi-lateral licenses need to be signed, regardless of whether tho= se licenses are royalty-free or not or whether unlicensed use of the techno= logy generally is tolerated even if it were against the text of the disclos= ure. Let me also note that we have (moderately) recent examples of IETF RFCs with IPR claims that cover all c= ategories mentioned above, including the final one.

 =

The list of categories could easily be exten= ded, especially with respect to the broad "open-source friendly non-as= sert" part.  However, doing so meaningfully would quite likely require references to licensing schemes supported by certain open source &= quot;camps", and I do not believe that the IETF needs to go down to th= at granularity, nor could I stand the flame wars that would likely break ou= t.  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 detai= ls.

 =

I also stayed away from defining "RAND&= quot;.  I mentioned RAND a because the vast majority of IETF disclosur= es mention RAND for reasons that are known to the disclosers, the requireme= nt for reasonable and non-discriminatory licensing is commonly believe to off= er some protection, even if the amount of protection offered is currently u= nclear, and because RAND is a requirement for normative down referenci= ng to many other SDOs.  I do not believe that the cumulative expertise of this list has the expertise--let alone th= e authority--to define the term RAND.

 =

Thanks for your consideration of my proposal= .

 =

Stephan

 

--_000_B68EFB284B10C249835C566A0CE08AA2499022BDTK5EX14MBXC294r_-- From narten@us.ibm.com Mon Aug 19 05:19:18 2013 Return-Path: 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 4934311E8249 for ; Mon, 19 Aug 2013 05:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 0oE8YxrDy-yN for ; Mon, 19 Aug 2013 05:19:11 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA411E80E2 for ; Mon, 19 Aug 2013 05:19:10 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 19 Aug 2013 08:19:09 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 19 Aug 2013 08:19:08 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 9FD1E38C804D for ; Mon, 19 Aug 2013 08:18:35 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r7JCIb6r146568 for ; Mon, 19 Aug 2013 08:18:37 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r7JCIa0N021348 for ; Mon, 19 Aug 2013 09:18:37 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-36-34.mts.ibm.com [9.65.36.34]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r7JCIXtf021144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 09:18:35 -0300 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r7JCIXUN005969; Mon, 19 Aug 2013 08:18:33 -0400 Message-Id: <201308191218.r7JCIXUN005969@cichlid.raleigh.ibm.com> To: Stephan Wenger Subject: Re: RFC3979bis section 7 -- hierarchy of preference for licensing In-reply-to: References: Comments: In-reply-to Stephan Wenger message dated "Tue, 13 Aug 2013 16:19:27 -0000." Date: Mon, 19 Aug 2013 08:18:33 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13081912-7182-0000-0000-000008225923 Cc: "ipr-wg@ietf.org" X-BeenThere: ipr-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPR-WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 12:19:18 -0000 I wasn't able to attend the Berlin session. Can you please remind us of what problem the suggested text is intended to fix? I.e., what is broken that needs fixing? If the intent is to just to make clear that Non-assert is more friendly to open source, and thus a preferance over simple RF, that is one thing, and I think is closer to where the IETF is today than the current RFC text. On the other hand, I'm less sure that spelling out a heirarchy is something we should (or need to) do. For one thing, it's not a straight hierarchy. IPR disclosures tend to have pesky reciprocity clauses, which mean that something like a specific RAND license may well be viewed as better (by some folks) than something "above it" in the heirarchy. It all depends on the specific clauses, which have to be evaluated on a case-by-case basis and vary quite widely today. Thomas