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