Proposed modification of IPR notice inside each ID/RFC

"tglassey@earthlink.net" <tglassey@earthlink.net> Wed, 18 May 2016 23:33 UTC

Return-Path: <tglassey@earthlink.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3445212D7DD; Wed, 18 May 2016 16:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.144
X-Spam-Level:
X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=tglassey@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj8S_ugYKje0; Wed, 18 May 2016 16:33:47 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id E64E712D7D8; Wed, 18 May 2016 16:33:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ma5BkHYjZyCTFiiyzlk7dra//lOj5VzWZE0PD7tAdZSAJIKVuFG5PViDiXnfh+pd; h=Received:To:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [50.136.180.24] (helo=[192.168.0.55]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <tglassey@earthlink.net>) id 1b3Axn-0008OF-4p; Wed, 18 May 2016 19:33:15 -0400
To: IETF Secretariat <ietf-ipr@ietf.org>, IETF@IETF.ORG, IESG@IETF.ORG
From: "tglassey@earthlink.net" <tglassey@earthlink.net>
Subject: Proposed modification of IPR notice inside each ID/RFC
Message-ID: <573CFBB9.1050908@earthlink.net>
Date: Wed, 18 May 2016 16:33:13 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------000502070502010304090308"
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7998f657ed0060f67295d14c64038c8aab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 50.136.180.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/zroT9JDYEu459L_LaJei9Rrb5VA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2016 23:33:49 -0000

I want to propose placing some very specific language into the IETF IPR 
PROCESS, meaning there needs to be something like the following added to 
BCP78 and the Copyright Boilerplate.

Also we need to start tracking the original copyright dates and the 
updated changed  protocol copyright dates because they have legal 
implications.

Here is my proposed text additions; This is actually much more serious 
now that the timestamp litigation is complete and IETF lost - both 
Settlements were formally affirmed as fully enforceable in their 
existing state meaning they now control all uses of US6370629 and 
US6393126 in any IETF protocol. The thing they do is make it impossible 
to apply anything but California Law to their use without a formal 
release from the Settlement partners. It means RFC3161 timestamping in 
say Austria is in fact controlled by California law and the treaties 
make this air-tight. But that is just the tip of the iceberg.

So... this is my proposal for changing the existing release info. The 
thing I propose is really strong language making it the ADOPTING PARTIES 
resoponsibility to ensure they dont have license-based code restrictions 
in their products.

THE IETF REQUIRES ANY PARTY USING ITS PROTOCOL TEMPLATES (ITS RFC AND 
I-D DOCUMENTS) TO OBTAIN RELEASES FORMALLY FROM ALL PARTIES WITH 
LEGITIMATE IPR NOTICES AND ANY THIRD PARTIES CONTROLLING INTELLECTUAL 
PROPERTIES CONTAINED INSIDE IETF STANDARDS OR NETWORK PROTOCOL DESIGNS.


THE IETF CANNOT AND DOES NOT PROVIDE ANY FORMAL OR IMPLIED RELEASE FOR 
ANY PRODUCTION USE OF ANY PARTIES INTELLECTUAL PROPERTIES AND USE OF 
IETF PROTOCOLS WITH PROPRIETARY INCLUSIONS MAY HAVE SIGNIFICANT 
FINANCIAL IMPLICATIONS FOR BOTH PARTIES PRODUCING PRODUCTS AS SUCH AND 
THEIR END-USER CLIENTS OR RESELLER/DISTRIBUTORS. IETF FORMALLY DECRIES 
AND DENIES ANY RESPONSIBILITY FOR THIRD PARTY USE IN ANY FORM OF ITS 
NETWORK STANDARDS.



-- 
Regards,
Todd Glassey
Standard Confidentiality Provisions and Disclaimer Provisions apply;This message, along with any attachments, is intended solely for the recipient and is considered confidential information and may well be legally privileged. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Thank you for your cooperation. This message, along with any attachments, is intended solely for the recipient and is considered confidential information and may well be legally privileged. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Thank you for your attention and cooperation.