Re: Coupling RFC copying conditions with the existence of the IETF

Nathanael Nerode <neroden@twcny.rr.com> Thu, 24 February 2005 07:54 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13130 for <ipr-wg-web-archive@ietf.org>; Thu, 24 Feb 2005 02:54:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4EBv-0005fC-5l for ipr-wg-web-archive@ietf.org; Thu, 24 Feb 2005 03:17:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DoZ-0000bN-Va; Thu, 24 Feb 2005 02:53:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DkO-0005w6-NB for ipr-wg@megatron.ietf.org; Thu, 24 Feb 2005 02:49:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12792 for <ipr-wg@ietf.org>; Thu, 24 Feb 2005 02:49:19 -0500 (EST)
Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4E7F-0005a4-Lp for ipr-wg@ietf.org; Thu, 24 Feb 2005 03:12:58 -0500
Received: from [24.59.106.96] (cpe-24-59-106-96.twcny.res.rr.com [24.59.106.96]) by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id j1O7nGK3009787; Thu, 24 Feb 2005 02:49:16 -0500 (EST)
Message-ID: <421D8709.4030806@twcny.rr.com>
Date: Thu, 24 Feb 2005 02:49:29 -0500
From: Nathanael Nerode <neroden@twcny.rr.com>
User-Agent: Debian Thunderbird 1.0 (X11/20050116)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>
References: <iluy8dir7p5.fsf@latte.josefsson.org> <20050221021306.897F122ADB7@newdev.harvard.edu> <iluoeeeqq5z.fsf_-_@latte.josefsson.org>
In-Reply-To: <iluoeeeqq5z.fsf_-_@latte.josefsson.org>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: 7bit
Cc: ipr-wg@ietf.org, neroden@twcny.rr.com
Subject: Re: Coupling RFC copying conditions with the existence of the IETF
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
Sender: ipr-wg-bounces@ietf.org
Errors-To: ipr-wg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: 7bit

The following comments by Glenn Maynard, in response to the I-D, 
summarize, I believe, the confusion and misunderstandings present in 
Bradner's Internet Draft.  He has kindly allowed me to reproduce it, but 
questions requesting clarification or defense of the points should go to 
me or someone else, not him.

>> 3.2.1. Confusion over what constitutes the standard
>>    It would clearly be confusing if someone could take an IETF standard
>>    such as RFC 3270 (MPLS Support of Differentiated Services), change a
>>    few key words and republish it, maybe in a textbook, as the
>>    definitive standards for MPLS Support of Differentiated Services.
> 
> Debian, at least, has no problem with a license requiring that a modified
> standard not be misrepresented as the original.  It is not confusing in
> any way for me to take RFC 3270, change a few key words, and republish it,
> as long as I don't call it RFC 3270.
> 
> Further, nothing prevents me from writing up my own bogus standard
> and calling it "RFC 3270 (MPLS Support of Differentiated Services)";
> since it's not a derivative work of the other RFC 3270, its copyright
> license is irrelevant.  (I believe the only possible protection against
> this is trademarks.)
> 
> The fact that he's even presenting this tired old argument means that
> either nobody is competently presenting the arguments for freeing of
> standards documents, or the arguments aren't being heard ...
[Hopefully this message will cause these arguments to be properly 
presented. --Nathanael]

>> IETF working groups undertake a great deal of effort to develop a
>> common understanding of the underlying architectural assumptions of
>> the standards they develop.  Modifications or extensions to a
>> standard done without an understanding of those architectural
>> assumptions may easily introduce significant operational or security
>> issues.  The best place to extend a standard is in the working group
> 
> Preventing modifications to the standards document does nothing to
> prevent this.  You can still say "use RFC 1234, with the following
> modifications ...", and just as easily cause trouble.  This is not
> a reason for standards documents to be non-free.
> 
>> 3.2.2. Cooperation between standards organizations
> 
> This essentially says "we want to prevent competition by making our
> standards non-free", which is a central theme of non-free licenses.
> 
>> I do not buy the argument that the open source community requires the
>> ability to make capricious changes in standards.
> 
> Here, he seems to misunderstand the notion of "required freedoms".  We
> don't require the ability to modify the standard in order to implement
> it.  We require the ability to modify the standard before considering
> it a free document, just as we require the ability to modify a program
> before considering it a free program.
[By "modify the standard", he actually means "make a new document based 
on the standard".  Similarly, by "modify a program", he means "make a 
new program based on the program".  The original program or standard is 
of course unchanged.  This is common shorthand, but can be confusing in 
this context. --Nathanael]

> Of course, Debian's notion of freedom has less weight here, because the
> IETF probably doesn't really care whether Debian distributes the RFCs.
> 
>> The open source community does not have this ability with the output
>> of other standards organizations, I do not see justification to say
>> that its OK to do so for Internet technology.  It seems to be
> 
> The standards of other organizations are also non-free; this merely
> says "they're non-free, so we should be, too".


_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg