Re: RFC5378 alternate procedure

Simon Josefsson <simon@josefsson.org> Tue, 16 December 2008 14:03 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7553A68C1; Tue, 16 Dec 2008 06:03:33 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1BD3A6A80 for <ietf@core3.amsl.com>; Tue, 16 Dec 2008 06:03:32 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edxUInoVB9tV for <ietf@core3.amsl.com>; Tue, 16 Dec 2008 06:03:32 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D57A93A63CB for <ietf@ietf.org>; Tue, 16 Dec 2008 06:03:30 -0800 (PST)
Received: from m83-178-8-35.cust.tele2.se ([83.178.8.35] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from <simon@josefsson.org>) id 1LCaW2-0005KG-Fl; Tue, 16 Dec 2008 15:03:17 +0100
From: Simon Josefsson <simon@josefsson.org>
To: John C Klensin <john-ietf@jck.com>
Subject: Re: RFC5378 alternate procedure
References: <961E43D63CD6B33C232D8330@p3.int.jck.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:081216:ietf@ietf.org::Rh5JV7L+M5k+B5jL:8KI6
X-Hashcash: 1:22:081216:john-ietf@jck.com::YKGS3lOvh5lO6uMw:FRiu
Date: Tue, 16 Dec 2008 15:03:00 +0100
In-Reply-To: <961E43D63CD6B33C232D8330@p3.int.jck.com> (John C. Klensin's message of "Mon, 15 Dec 2008 15:27:47 -0500")
Message-ID: <87prjs8bfv.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John C Klensin <john-ietf@jck.com> writes:

> Hi.
>
> In an attempt to get this discussion unstuck and to provide a
> way forward for those of us whose reading of 5378 (or advice
> from counsel) have convinced us that we cannot post most
> documents that contain older text written by others under the
> new rules, I've posted a new I-D,
> draft-klensin-rfc5378var-00.txt.

Thanks for trying to do something about this problem.  I've read the -01
document.  It describes a solution that would be very far from a good
copyright situation -- even further away than RFC 5378 alone, given that
RFC 3978 is seriously flawed in some ways.  However, I think your draft
is likely to be one of few approaches that can gain consensus quickly
enough to be an effective solution to the problem you describe.  It
could be a stop-gap measure for the next year or so, until better
copyright policies can be developed.

There is one detail I disagree with rather strongly.  Section 7 suggests
that the Trustees should prepare a replacement for BCP 78.  First, I
don't think the Trustees have the necessary competences or resources to
take on that huge effort.  Further, there is a conflict of interest
here: any policies written by the Trustees is likely to just give more
rights to the IETF Trust That is the problem that caused this situation
to begin with.  I don't believe the output would be representative of
the needs of the wider IETF community.  Instead, I suggest there should
be a wider IETF effort to document the copyright policy that will serve
the IETF better...

...and hopefully such an effort can review some of the bigger pictures
that were declared out of scope in the IPR WG.  One consideration would
then be:

* Whether the two-phase construct with an IETF Trust is a good idea.
  One alternative is to require contributors to release their work under
  a liberal license that allows everyone to copy and modify it.  This
  would avoid the liability issues that are inherent in the IETF Trust
  construct.  This would save money for the IETF.  The license would be
  significantly less complex.

  I agree there are some situations were contributors doesn't find this
  model acceptable.  Just like there are exceptions in the current
  license, there could be a exception in the new license to allow
  exceptions for non-modifiable content.  Compare how the GNU FDL
  license restricts certain parts of a manual to be modified freely.

/Simon
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf