Re: Community Input on change to the Trust Legal Provisions to accommodate the inclusion of RFC Templates

John C Klensin <john-ietf@jck.com> Sat, 31 January 2015 13:56 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 405A21A02BE for <ietf@ietfa.amsl.com>; Sat, 31 Jan 2015 05:56:40 -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 7xAkckG5qm4D for <ietf@ietfa.amsl.com>; Sat, 31 Jan 2015 05:56:38 -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 8C6F41A0242 for <ietf@ietf.org>; Sat, 31 Jan 2015 05:56:38 -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 1YHYXM-0001HU-NE; Sat, 31 Jan 2015 08:56:36 -0500
Date: Sat, 31 Jan 2015 08:56:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
Subject: Re: Community Input on change to the Trust Legal Provisions to accommodate the inclusion of RFC Templates
Message-ID: <04DAE34BD40772CD753611D3@JcK-HP8200.jck.com>
In-Reply-To: <tsl7fw8jkur.fsf@mit.edu>
References: <54C79F50.20106@gondrom.org> <69BB994D3A6C37396C70C9BC@JcK-HP8200.jck.com> <tsl7fw8jkur.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/MtzZef--Y3o3vu8-k76aSa0G-QY>
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: Sat, 31 Jan 2015 13:56:40 -0000


--On Tuesday, January 27, 2015 10:37 -0500 Sam Hartman
<hartmans-ietf@mit.edu> wrote:

>>>>>> "John" == John C Klensin <john-ietf@jck.com> writes:
> 
>     John> Tobias,
> 
>     John> IANAL (other disclaimers incorporated by
> hand-waving), but a     John> plain-English reading of this
> indicated that the text gives     John> permission to modify
> the text of the template itself.  That     John> raises all of
> the issues that caused us to try to make     John> enforceable
> copyright claims on the RFC series in the first     John>
> place-- someone could use such derived text (maliciously or
> John> not) to mislead others about IETF statements, intent, and
>     John> requirements.
> 
> I'd like to specifically disagree with John and say that I'd
> like to see the trust be very liberal in grating license
> exceptions when the IETF purposes are served.
> There are significant  costs to asking the trust to be more
> liberal when we discover that our needs are not  met by our
> licensing. I have always disagreed that there is significant
> harm that will happen if people modify IETF documents
> especially if those modifications are labeled.
>...

Just to close the loop, my hope was that the trust would
consider the advantages and disadvantages of a policy broad
enough to allow people to reproduce _and_ modify the templates
in non-IETF / non-IANA contexts.  Sam has explained (thoroughly
and well, IMO) the advantages.

However, when I combine his position with several of the other
comments that have been made, I wonder whether the right policy
would be to take us back to just about where were were long
before we started making strong copyright claims about RFCs and
certainly before several IPR WG efforts and the IETF Trust came
into being and started making very specific policies.  That
ancient policy was, in essence, "do what you like with RFCs but
please acknowledge and, if you making excerpts and/or changes,
be very clear about what you have done and how it relates to the
original in your acknowledgments".

I have _very_ mixed feelings whether that policy or the current
"need to ask permission except for a list of exception cases
that keeps getting longer and more complicated" policy (noting
the comments about why the "template" policy needs to be
different from the "code" policy) is the better one, but I hope
that the IETF Trust is asking that question again each time a
requirement for a new, and time consuming, policy tweak comes
up.  Part of that question, which I'm sure the Trust has
considered but on which it has not briefed the community, is how
egregious or harmful a violation would have to be before
presumably-limited resources were spent trying to mount an
enforcement action.

    john