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
- draft-bradner-rfc-extracts-00.txt Scott Bradner
- Re: draft-bradner-rfc-extracts-00.txt Steven M. Bellovin
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Scott Bradner
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt todd glassey
- Re: draft-bradner-rfc-extracts-00.txt Steven M. Bellovin
- Re: draft-bradner-rfc-extracts-00.txt Harald Tveit Alvestrand
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Robin Cover
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt todd glassey
- Re: draft-bradner-rfc-extracts-00.txt Don Armstrong
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Don Armstrong
- Re: draft-bradner-rfc-extracts-00.txt Nathanael Nerode
- Re: draft-bradner-rfc-extracts-00.txt Nathanael Nerode
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Scott Bradner
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Scott Bradner
- Re: draft-bradner-rfc-extracts-00.txt Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Scott Bradner
- Re: draft-bradner-rfc-extracts-00.txt Steven M. Bellovin
- Re: draft-bradner-rfc-extracts-00.txt Matthew Garrett
- Coupling RFC copying conditions with the existenc… Simon Josefsson
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Matthew Garrett
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Matthew Garrett
- Re: draft-bradner-rfc-extracts-00.txt Stephane Bortzmeyer
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Matthew Garrett
- RE: draft-bradner-rfc-extracts-00.txt Lawrence Rosen
- Re: draft-bradner-rfc-extracts-00.txt Bill Sommerfeld
- Re: draft-bradner-rfc-extracts-00.txt Don Armstrong
- Re: Coupling RFC copying conditions with the exis… Nathanael Nerode
- Re: Coupling RFC copying conditions with the exis… Sam Hartman