Subject: draft-bradner-rfc-extracts-00.txt

From: [email-masked] (Scott Bradner)
Date: Thu, 10 Feb 2005 19:18:47 -0500 (EST)

I've just published draft-bradner-rfc-extracts-00.txt 

this ID addresses the issues of extracting RFCs and derivative works

this is meant to stimulate discussion but is not a WG document
because it is not an even-handed treatment 

I expect it to be discussed during teh IPR WG session

Scott

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 10 Feb 2005 20:00:21 -0500

In message <[email-masked]>, Scott Bradner write
>I expect it to be discussed during teh IPR WG session

Yes -- it's on the draft agenda Scott Brim and I have been working on.  
(I won't be in Minneapolis; Scott [B[rim]] will be the chair pro tem.)

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Feb 2005 20:04:28 -0500

> I've just published draft-bradner-rfc-extracts-00.txt 

there are many sorts of reasons to change a code extract, creating
a derivative work, which have no impact on standards or interoperability.

I seem to recall at least one incident involving allegedly uncompilable 
MIBs found in IETF documents.  If i'm not in a position to fix my mib 
compiler I may still be able to fix the source to cause my implementation
to produce the correct behavior...

I have this vague memory of running into an ASN.1-driven code generator
which allowed you to mix code fragments with ASN.1 (much as parser 
generators such as yacc let you mix code fragments with a grammar 
description).  I'd imagine that you could do the same with a MIB as well.

On several occasions I've extracted the MD5 code from RFC1321 and made 
it run faster while still computing the same function.

Other things I'd like to be able to do:

 - code changes to make RFC-derived code pass various static or dynamic 
checkers (lint, purify, gcc -Wall, ...)

 - changes to make it match local conventions for indentation, identifier 
naming, header file naming, etc.,

 - changes to eliminate global variables, add locking for multithread 
safety, or allow for localized messages.

 - Translations into other programming languages or to cope with the
evolution of the programming language (e.g., the K&R C to standard C 
transition).

in -rfc-extracts you wrote: "I do not see that the open source community
requires the ability to create a modified and incompatible version of 
ATM signaling".

Hmm.  What about RFC1953/1954/1987?  The way it's worded makes me think
it's not cleanly layered atop ATM but rather involves discarding and 
replacing some of the upper layers of ATM...

						- Bill

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Feb 2005 02:30:39 +0100

> this ID addresses the issues of extracting RFCs and derivative works

Thanks!

The proposed RFC 3667 update in section 2 looks like an improvement to
me.  It is clear we disagree on permitting unrestricted derivate
works.  Let me try to rebut your arguments:

Re 3: The fact that W3C, ITU etc behave similar to IETF is not a
convincing argument to me.  The Unicode Consortium permit modified
versions of their standards to be published (again, kudos to them!),
see <http://www.unicode.org/copyright.html>.

Re 3.2.1: I don't buy that this will create any significant confusion.
I think you need to show that confusion exists in other areas where
modified derived works are permitted.  I.e., for Unicode or for RFCs
before RFC 2026.  I further think that Larry Rosen's suggestion is too
complex and too costly to implement for the IETF.

Re 3.2.2: Working groups typically close after they are done with a
core specification.  Further, WGs are not required to review or help
anyone modify the product of a WG.  Thus, I challenge that the "best
place" to extend a standard is within the WG that created it.  One of
my examples has been StringPrep/IDN, that WG doesn't exist any more.

Re the second 3.2.2 (the section numbering seem off): This appear to
be the same argument as 3.2.1, i.e., that permitting modified
documents would create confusion or problems.

Re 3.2.3: The requirement to be able to modify documents come from
free software developers like myself.  It may be the case that the
open source community do not need this requirement, but I don't see
the relevance.  Further, the argument that the free software community
could come to the IETF if they want to extend standards is weak: there
is nothing that guarantee that the IETF will be around forever or that
it will welcome the free software community.  It must be possible to
modify free software without talking to the IETF about it.

Thanks,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 11 Feb 2005 09:06:18 +0100

factoid.... the Unicode website you point to says:

> Certain documents and files on this website contain a legend indicating
> that "Modification is permitted." Any person is hereby authorized,
> without fee, to modify such documents and files to create derivative
> works conforming to the Unicode® Standard, subject to Terms and
> Conditions herein.

Note that you can't modify the documents for anything BUT creating 
derivative works conforming to the Unicode Standard - and there are 
documents (such as this one) that you can't create modified versions of.

(I assume that this quote is within the boundaries of acceptable quotation 
for commentary, although I haven't checked with my lawyer on the point...)

and later in the same document, for the "Unicode Database" files:

> Permission is hereby granted, free of charge, to any person obtaining a
> copy of the Unicode data files and associated documentation (the "Data
> Files") or Unicode software and associated documentation (the "Software")
> to deal in the Data Files or Software without restriction, including
> without limitation the rights to use, copy, modify, merge, publish,
> distribute, and/or sell copies of the Data Files or Software, and to
> permit persons to whom the Data Files or Software are furnished to do so,
> provided that (a) the above copyright notice(s) and this permission
> notice appear with all copies of the Data Files or Software, (b) both the
> above copyright notice(s) and this permission notice appear in associated
> documentation, and (c) there is clear notice in each modified Data File
> or in the Software as well as in the documentation associated with the
> Data File(s) or Software that the data or software has been modified.

All that said, I think the Unicode rules seem reasonable :-)

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Feb 2005 09:38:11 +0100

> documents (such as this one) that you can't create modified versions of.

Indeed, that seem troubling.  And a little confusing, I might add.
What is the "Unicode standard"?  Different version of the Unicode
standard doesn't confirm to each other, after all.

We only reviewed the license for the Unicode Character Database,
because that is the part I needed.

Ok, UTC is not a good example then.

> All that said, I think the Unicode rules seem reasonable :-)

Do you think the second paragraph alone is reasonable?  Then we have
definitely achieved something, for that license appear reasonable to
us as well.  As far as I can tell, for the UCD, the final part of the
page is the complete agreement.  I'll ask them to make sure I didn't
misunderstand the page.

Thanks,
Simon

---

From: Robin Cover <[email-masked]>
Date: Fri, 11 Feb 2005 05:01:15 -0500 (EST)

> see <http://www.unicode.org/copyright.html>.

For what it's worth, OASIS recently updated its IPR policy [1].  The
standard notice for copyright (including derivative works based
upon OASIS specifications) is as follows:

=============
Any document produced by an OASIS Technical Committee shall
include the following notices (bracketed language, other than
the date, need only appear in specification documents): 

Copyright (c) OASIS Open 2005. All Rights Reserved. 

All capitalized terms in the following text have the meanings
assigned to them in the OASIS Intellectual Property Rights
Policy (the "OASIS IPR Policy"). The full Policy may be found
at the OASIS website.

This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published, and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this section are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, including by removing the copyright notice
or references to OASIS, except as needed for the purpose of
developing any document or deliverable produced by an OASIS
Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be
followed) or as required to translate it into languages other
than English. 

The limited permissions granted above are perpetual and will
not be  revoked by OASIS or its successors or assigns...

========================

[1] http://www.oasis-open.org/who/intellectualproperty.php

--