Re: Community Input on change to the Trust Legal Provisions to accommodate the inclusion of RFC Templates
John C Klensin <john-ietf@jck.com> Wed, 18 February 2015 19:01 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EC21A011B for <ietf@ietfa.amsl.com>; Wed, 18 Feb 2015 11:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhsXjpshFMcb for <ietf@ietfa.amsl.com>; Wed, 18 Feb 2015 11:01:41 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC091A0119 for <ietf@ietf.org>; Wed, 18 Feb 2015 11:01:41 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YO9sO-000NKw-7y; Wed, 18 Feb 2015 14:01:36 -0500
Date: Wed, 18 Feb 2015 14:01:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, Nico Williams <nico@cryptonector.com>
Subject: Re: Community Input on change to the Trust Legal Provisions to accommodate the inclusion of RFC Templates
Message-ID: <E119ACC9678D8A2CD262B48D@JcK-HP8200.jck.com>
In-Reply-To: <tslh9ukrvxm.fsf@mit.edu>
References: <54C79F50.20106@gondrom.org> <69BB994D3A6C37396C70C9BC@JcK-HP8200.jck.com> <tsl7fw8jkur.fsf@mit.edu> <CAK3OfOgo1q0uXnZmdCQPqju9czdrj64VhMieDW7BWWb-YZv-cw@mail.gmail.com> <tslh9ukrvxm.fsf@mit.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YFY4FUJES1CFPcHaJi0Bv5EaEXI>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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 Feb 2015 19:01:43 -0000
--On Tuesday, February 17, 2015 17:54 -0500 Sam Hartman <hartmans-ietf@mit.edu> wrote: > I've explained why I think that claims on empty templates are > really bad. > Imagine writing a free software application to assist someone > in filling in a template. Sam, As I have said before, I really don't think this issue is important enough to justify the time that has already been spent on it. I am therefore probably going to regret writing this note. Some years ago and perhaps influenced too much by some other standards bodies and their concerns, I was convinced that the IETF should be very protective of RFC text, especially against spoofing. Whether my views had any influence of not (I suspect they did not), the IETF Trust and its policies evolved in the direction of a fairly restrictive model. I'm no longer convinced that was a good idea. Consequently: (1) If we are going to continue to be restrictive, then I have every confidence that our legal team could devise language to deal with the case above and any other cases deemed important while protecting the substantive content of templates against things that would be considered alterations by someone exerting common sense (that is distinct from legal/copyright definitions of copying and alteration). (2) If we are going to move in less restrictive directions, then I think the IETF Trust ought to start a project to review the reasons why we need or want restrictive copyright policies on RFCs at all, including thinking through how much we would need to be provoked to actually spend resources trying to enforce the existing policies if someone decided to ignore them. It seems to me that we could save the members of the IETF Trust, and ultimately the community, a lot of time and energy by adopting a significantly less restrictive set of policies for RFC content generally. The question is whether doing that would be a good or bad idea. My initial reaction and comment about the template situation wasn't a desire to restrict reasonable and practical uses -- I don't think that is desirable and I don't care very much. I was, and am, concerned about the apparent inconsistency between an "everything not formally allowed is forbidden" model for RFC text generally and what appears to be a "do what you like" rule about templates (less restrictive than even our "code" requirements). best, john
- Community Input on change to the Trust Legal Prov… Tobias Gondrom
- Re: Community Input on change to the Trust Legal … John C Klensin
- Re: Community Input on change to the Trust Legal … Joel M. Halpern
- Re: Community Input on change to the Trust Legal … Sam Hartman
- Re: Community Input on change to the Trust Legal … Alia Atlas
- RE: Community Input on change to the Trust Legal … Eric Gray
- Re: Community Input on change to the Trust Legal … Stephan Wenger
- Re: Community Input on change to the Trust Legal … John Levine
- Re: Community Input on change to the Trust Legal … Brian E Carpenter
- Re: Community Input on change to the Trust Legal … John Levine
- Re: Community Input on change to the Trust Legal … Sean Turner
- Re: Community Input on change to the Trust Legal … Matthew Lepinski
- Re: Community Input on change to the Trust Legal … John C Klensin
- Re: Community Input on change to the Trust Legal … Nico Williams
- Re: Community Input on change to the Trust Legal … Nico Williams
- Re: Community Input on change to the Trust Legal … Sam Hartman
- Re: Community Input on change to the Trust Legal … John C Klensin