Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem

John C Klensin <john-ietf@jck.com> Fri, 09 January 2009 16:01 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 0916C3A6A5D; Fri, 9 Jan 2009 08:01:44 -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 C8C7F3A6B1C; Fri, 9 Jan 2009 08:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level:
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 GSQD9w1W3kQW; Fri, 9 Jan 2009 08:01:41 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 81EE63A6889; Fri, 9 Jan 2009 08:01:41 -0800 (PST)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LLJnQ-000AFh-Aj; Fri, 09 Jan 2009 11:01:16 -0500
Date: Fri, 09 Jan 2009 11:01:09 -0500
From: John C Klensin <john-ietf@jck.com>
To: Thomas Narten <narten@us.ibm.com>, Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
Message-ID: <4260CD9462ADE55A7DFC3C99@PST.jck.com>
In-Reply-To: <200901091516.n09FGJsI023601@cichlid.raleigh.ibm.com>
References: <70873A2B7F744826B0507D4B84903E60@noisy> <FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com> <F857DDBB-CDEE-48A8-B59C-56AEDA65CE79@cs.tcd.ie> <4966CEF3.8080506@gmail.com> <6.0.0.20.2.20090109143653.05e3ebd8@localhost> <200901091516.n09FGJsI023601@cichlid.raleigh.ibm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Trustees <trustees@ietf.org>, Working Group Chairs <wgchairs@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>, IETF Discussion <ietf@ietf.org>, Fred Baker <fred@cisco.com>
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


--On Friday, January 09, 2009 10:16 -0500 Thomas Narten
<narten@us.ibm.com> wrote:

> Martin Duerst <duerst@it.aoyama.ac.jp> writes:
> 
>> WHO exactly are we supposed to get permissions from.
> 
>> The situation of a deceased author is a tought one, but it's
>> an obvious one. But I haven't seen any clear answer to whether
>> permission from all the authors/editors (the people listed in
>>...

> IANAL, but if you are expecting anyone (like the IETF) to give
> a clear final, legally defensible answer to "who do you need
> permission from", you won't get it. That is the nature of
> legal questions and is what makes this entire discussion so
> difficult. And why what is an accptable risk for you may not
> be an acceptable risk for me or someone else.
> 
> To answer the question, you have to look at who bears the risk
> if they make an assertion (i.e, by claiming that all
> contributers have signed off) that someone later challenges.
> And what the potential consequences would be.

I think this is the crux of the issue.  Let's consider three
possible assertions (deliberately trying to avoid expressing
them in lawyer-speak):

	(1) I give the Trust any rights that I or my company
	have and can give, but make absolutely no assertions
	about anyone else's rights.
	
	(2) I give the Trust any rights that I or my company
	have and can give, and have verified that everyone
	listed on the front page (or in some other list), with
	the following exceptions, have signed off on this.  But
	I make absolutely no assertions about either the rights
	of anyone not listed, nor about anyone whom I had to
	identify as an exception.
	
	(3) I transfer all rights in the document to the Trust
	and guarantee the Trust that I've gotten the ok to do so
	from everyone who might be able to assert a claim of
	rights to the content, whether they are explicitly
	listed or not and whether the claim is bogus or not.
	Implicitly, if the Trust acts on the assumption that
	they have all the rights and someone complains or
	litigates, that is my problem to defend against and not
	the Trust's.

Unless I am hugely confident, either

	*  That I wrote every word of the text myself,
	paraphrasing contributions or suggestions from others,
	or 
	
	* that no one will pop out of the woodwork,

I believe that making assertion (3) is basically insane unless
one is convinced that no one will _ever_ litigate any of this.
If the Trust and IPR WG believed the latter, we wouldn't need
any of this stuff, so forget that.  The 2026/ 3739/ 4879
requirement is not insane because it only requires me to make
assertions based on what I can be reasonably expected to know
(and the transfer is less general, lowering the odds of protests
somewhat).  That doesn't eliminate the risk, but, IMO, brings it
into manageable proportions.

(1) is easy.  (2) is a lot harder, but still plausible.   But
either of those do the one thing that (3) does not and that the
current state of things seem intended to avoid: With (1) or (2),
the Trust cannot write licenses that assert that they actually
control all of the relevant rights (at least without a lot of
expensive insurance).  Consequently, with either of those
options, the risk that someone unidentified might show up and
assert a claim falls on either the Trust or the user of the
material, not the author/editor of the document.

That is the common characteristic of my I-D, Brian's recent I-D,
and at least part of some of the "repeal 5378" suggestions: the
Trust doesn't get to assume that they have clear and unambiguous
title to documents and permission to license them further on
whatever terms they determine (and that, if the assumption is
wrong, it is the author's problem).

It is also, IMO, the fundamental problem with 5378/5377 and with
almost any attempt to patch them.  They are designed to protect
the Trust against granting rights it doesn't have by making the
submitter assume all of the obligations and risks of
guaranteeing the Trust that it does have certain rights.  That
is just not how we ought to be designing things if we want
people to make contributions to the IETF that build on the work
of others.

YMMD
   john

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