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

[Simon Josefsson <simon at josefsson.org>]

"Joel M. Halpern" <jmh at joelhalpern.com> writes:

> My own take has been that the code reuse problem is the dominant
> problem.

My interpretation has been that the problem has been (and remain) that
the license on IETF documents is incompatible with free software
licensing, which is counter-productive for the IETF.

> Document transfer outside the IETF is sufficiently rare that I would
> agree with Fred that not solving that is fine.

I agree too.

Theodore Tso <tytso at mit.edu> writes:

>> This also means that from my personal perspective, a solution that says  
>> (loosely based on a suggestion from someone else in a side conversation)  
>> that
>> 1) If you can, you grant 5378 rights
>> 2) If you can't, you grant the old rights, as long as there is no code  
>> in the document
>> 3) If there is code, get the rights to the code so people can actually  
>> use the code in tFrom ietf-bounces at ietf.org  Sat Jan 10 05:38:26 2009
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 24B1628C1AE;
	Sat, 10 Jan 2009 05:38:26 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3A5FD28C1AE
	for <ietf at core3.amsl.com>; Sat, 10 Jan 2009 05:38:25 -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 gGQuxd1gxfSw for <ietf at core3.amsl.com>;
	Sat, 10 Jan 2009 05:38:24 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39])
	by core3.amsl.com (Postfix) with ESMTP id DE05028C19D
	for <ietf at ietf.org>; Sat, 10 Jan 2009 05:38:22 -0800 (PST)
Received: from m90-137-71-108.cust.tele2.se ([90.137.71.108]
	helo=mocca.josefsson.org)
	by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
	(Exim 4.69) (envelope-from <simon at josefsson.org>)
	id 1LLe2J-0002EX-FN; Sat, 10 Jan 2009 14:38:03 +0100
X-Hashcash: 1:22:090110:tytso at mit.edu::6WXssVZ9aPk9WmQ8:3ZOi
From: Simon Josefsson <simon at josefsson.org>
To: "Joel M. Halpern" <jmh at joelhalpern.com>, Theodore Tso <tytso at mit.edu>
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees	invite	your reviewand
	comments on a proposed Work-Around to the	Pre-5378	Problem
References: <70873A2B7F744826B0507D4B84903E60 at noisy>
	<FB8A848E-E415-4CDE-9E3F-5C74A561 4F18 at cisco.com>
	<49678B2A.8000100 at dcrocker.net> <20090109181503.GP24908 at verdi>
	<6E372F257B0C42E7AB9B7DA6231FF4E4 at LROSENTOSHIBA>
	<p06240800c58d5466241b at [10.227.48.131]>
	<DBAA71AA401E5398212B1E03 at PST.jck.com> <4967CAA1.9020608 at gmail.com>
	<B2385D8E5F5BA599A174BD43 at PST.jck.com>
	<4967E348.7050300 at joelhalpern.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090110:jmh at joelhalpern.com::I6HNA0lhUJkqf+mb:0la/
X-Hashcash: 1:22:090110:ietf at ietf.org::yQZoiZiSI4QsqX8R:+F2I
Date: Sat, 10 Jan 2009 14:37:50 +0100
In-Reply-To: <4967E348.7050300 at joelhalpern.com> (Joel M. Halpern's message of
	"Fri, 09 Jan 2009 18:52:40 -0500")
Message-ID: <87d4evgu35.fsf at mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: 'IETF Discussion' <ietf at ietf.org>
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

"Joel M. Halpern" <jmh at joelhalpern.com> writes:

> My own take has been that the code reuse problem is the dominant
> problem.

My interpretation has been that the problem has been (and remain) that
the license on IETF documents is incompatible with free software
licensing, which is counter-productive for the IETF.

> Document transfer outside the IETF is sufficiently rare that I would
> agree with Fred that not solving that is fine.

I agree too.

Theodore Tso <tytso at mit.edu> writes:

>> This also means that from my personal perspective, a solution that says  
>> (loosely based on a suggestion from someone else in a side conversation)  
>> that
>> 1) If you can, you grant 5378 rights
>> 2) If you can't, you grant the old rights, as long as there is no code  
>> in the document
>> 3) If there is code, get the rights to the code so people can actually  
>> use the code in the RFC the RFC to implement the RFC.  (MIBs are already  
>> covered, but we have lots of other kinds of code.)
>
> We do have precedent for include code that has explicit open source
> licensing rights.  For example, the MD5 implementation in RFC 1321 has
> an explicit BSD-style license.

Sure, but under the post-RFC 2026 rules that would not be allowed since
the rules do not permit additional copyright notices to be present in
documents.  There has been exceptions and mistakes, so there are
post-RFC 2026 documents with other licensing information in them, but
the IESG/IAB has also rejected including free software code in RFCs.
Allowing BSD-like code to be included in RFCs would be great step
forward.  It is not allowed under the RFC 5378 license either, at least
not generally when the code was not written by the document author.

> How much code is there, really?

Looking at the last 10 published RFC's for material (text or code) that
potentially may end up in free software implementations, I find:

5391 sample test-vectors
5393 no
5394 pseudo-code
5395 data table with messages
5396 no
5397 no
5398 no
5401 code, pseudo-code
5405 no
5407 pseudo-code

This is a small sample, and you could discuss each interpretation, but
still I believe this shows that this is a common enough problem to worry
about.  RFC 5378 improves the situation in some specific cases but does
not solve the general problem, and understanding whether the specific
case rules apply or not is complex.

> I suppose pseudo-code might be a gray area tht will depend on how
> paranoid of a lawyer you are dealing with.  One who uses the argument
> that "copyright can not protect ideas, just the expression of the
> idea", will probably say that it's OK.  One who tries to draw a
> parallel to translations as derived works might be more concerned.

A more realistic approach may be to think about how text in RFCs are
used.  Text often end up in free software projects as comments.  This is
useful and helps get the RFC implemented correctly in a more
maintainable fashion.  The goals of the IETF is furthered by this, I
argue, so it is disappointing RFC 5378 does not solve the problem.

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


o implement the RFC.  (MIBs are already  
>> covered, but we have lots of other kinds of code.)
>
> We do have precedent for include code that has explicit open source
> licensing rights.  For example, the MD5 implementation in RFC 1321 has
> an explicit BSD-style license.

Sure, but under the post-RFC 2026 rules that would not be allowed since
the rules do not permit additional copyright notices to be present in
documents.  There has been exceptions and mistakes, so there are
post-RFC 2026 documents with other licensing information in them, but
the IESG/IAB has also rejected including free software code in RFCs.
Allowing BSD-like code to be included in RFCs would be great step
forward.  It is not allowed under the RFC 5378 license either, at least
not generally when the code was not written by the document author.

> How much code is there, really?

Looking at the last 10 published RFC's for material (text or code) that
potentially may end up in free software implementations, I find:

5391 sample test-vectors
5393 no
5394 pseudo-code
5395 data table with messages
5396 no
5397 no
5398 no
5401 code, pseudo-code
5405 no
5407 pseudo-code

This is a small sample, and you could discuss each interpretation, but
still I believe this shows that this is a common enough problem to worry
about.  RFC 5378 improves the situation in some specific cases but does
not solve the general problem, and understanding whether the specific
case rules apply or not is complex.

> I suppose pseudo-code might be a gray area tht will depend on how
> paranoid of a lawyer you are dealing with.  One who uses the argument
> that "copyright can not protect ideas, just the expression of the
> idea", will probably say that it's OK.  One who tries to draw a
> parallel to translations as derived works might be more concerned.

A more realistic approach may be to think about how text in RFCs are
used.  Text often end up in free software projects as comments.  This is
useful and helps get the RFC implemented correctly in a more
maintainable fashion.  The goals of the IETF is furthered by this, I
argue, so it is disappointing RFC 5378 does not solve the problem.

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