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

From: Nathanael Nerode <[email-masked]>
Date: Sat, 12 Feb 2005 00:10:37 -0500

> 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.

A license corresponding to this (with "Unicode" replaced as appropriate, of 
course, and "Data Files or Software" replaced with "Document" if necessary) 
would be considered perfect for RFCs by me and by every other free software 
or open source software person I have talked to.

Would this not be considered appropriate by others at the IETF, and if not, 
why not?

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

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 13 Feb 2005 01:10:23 +0100

> or open source software person I have talked to.

I agree.

> Would this not be considered appropriate by others at the IETF, and if not, 

I think the argument has been explained already, but to me it appears
to be that some people believe that permitting third parties to modify
IETF documents will somehow lead to negative consequences.  I can't
explain the arguments for this position, because I don't believe they
are valid.  I hope that Scott Bradner, or someone else, will
elaborate.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Fri, 18 Feb 2005 09:47:38 -0500 (EST)

> are valid.  I hope that Scott Bradner, or someone else, will

reasons are elaborated in the ID (you may not agree but please don't
pretend that no arguments have been made)

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Feb 2005 02:54:55 +0100

> pretend that no arguments have been made)

I don't see anyone pretending that no arguments have been made.

I am saying that I don't understand nor agree with your arguments.

I tried to start a discussion in:

http://article.gmane.org/gmane.ietf.ipr/2597

but you didn't reply.

Mentioning arguments in an ID doesn't make them true, and especially
so when there is no discussion.

The arguments in your ID appear to even make people uninterested in
participating in the discussion, see:

http://thread.gmane.org/gmane.linux.debian.devel.legal/19309

I am sincerely hoping you will take the time to discuss your thoughts
on this further.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Sun, 20 Feb 2005 20:56:56 -0500 (EST)

> http://article.gmane.org/gmane.ietf.ipr/2597

I did not see your try but I see no reason to not just use the ipr-wg
list

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Feb 2005 03:02:46 +0100

> I did not see your try but I see no reason to not just use the ipr-wg

Feel free to use the IPR-WG list to respond.  The message was posted
to the IPR list.  That link is to an archive of the IPR-WG list.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Sun, 20 Feb 2005 21:13:06 -0500 (EST)

sorry - I did see that message but it just looked like you disagree with
what I wrote 

my worries are set down in the ID - you dismiss them out of hand - whats
to talk about?

(by the way 
"there is nothing that guarantee that the IETF will be around forever"
is a very silly argument - if the ietf were to go away who would complain
if there were a 1000 things that claimed to be SIP? - whoever it was
it would not be the ietf so anything by the IETF that said 'don't do
that' would be far from effective)

Scott

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 20 Feb 2005 21:51:07 -0500

In message <[email-masked]>, Scott Bradner write
>I did not see your try but I see no reason to not just use the ipr-wg

Let me phrase it more strongly: all discussion on this topic that's 
intended to affect the IPR WG's decision MUST take place on this list.  
For one thing, this is the list that interested parties are directed to 
subscribe to by the WG charter web page.  For another, the contents of 
this list are archived by the Secretariat.

You are, of course, free to post comments and observations anywhere 
else.  But it's not reasonable to ask WG participants to know about 
such postings, let alone to subscribe and participate.

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

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 21 Feb 2005 02:53:46 +0000

> that' would be far from effective)

Why is this a concern? There is currently nothing preventing 1000
different documents from claiming to define any given standard. It would
make more sense to ensure that only one document can claim to be the
IETF standard for a given protocol. Once that's possible, there's no
harm in allowing standards documents to be modified as much as people
desire.

-- 
Matthew Garrett | [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Feb 2005 09:21:28 +0100

> my worries are set down in the ID - you dismiss them out of hand - whats

That was not my intention.  I believe there were several concrete
questions and problems raised in my message, and not merely opinions.

I will try to reword it, but I wanted to handle the following
separately.

> that' would be far from effective)

I do not think it is a silly argument.  It is not about who will
complain after IETF goes away.  It is about granting the proper rights
to people here and now.

License should be written so there aren't obvious escape holes that
can be used to get around the intention of the license.

Moving the technical work from the legal IETF entity to another legal
entity would be simple, and would nullify anything the IETF agreed to.

The IETFng would have the authority to speak on technical terms re the
older standards, because the technical competence would be in IETFng.
It is the IETF members who make up the trust in IETF, not the IETF's
name itself.

If you believe the problem is silly, why don't consider humoring me
and make sure the license on RFCs aren't tightly coupled to the
existence of some legal entity?  Doing so would make a difference,
e.g., Debian may be in a position to distribute to users my manuals
and software, which are derived from RFCs.

If you have another argument, other than "sillyness", I'd like to hear
it.

Thanks,
Simon

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Feb 2005 15:05:37 -0500

> harm in allowing standards documents to be modified as much as people

I fail to see the harm in requiring folks redistributing modified standards
documents to 1) notify the IETF that they're doing so 2) permit the IETF to 
use the text and then make further modifications as part of future standards work.  

						- Bill

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 21 Feb 2005 20:40:07 +0000

> use the text and then make further modifications as part of future standards work.  

I think there are certainly strong arguments for permitting the IETF to
incorporate derived works into future standards, but I'm not that
convinced by the need to notify the IETF - the vast majority of
derivations are unlikely to be interesting, and the effort required to
process notifications may be large. Regardless, I'd view this situation
as a significant improvement over the current one.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Feb 2005 17:31:30 -0500

On Mon, 2005-02-21 at 15:40, Matthew Garrett wrote:
> process notifications may be large. 

Given how many internet drafts are handled by the IETF, I suspect the IETF will cope.  (I don't actually think any new mechanism is required -- the i-d
submission mechanism will do).

> Regardless, I'd view this situation as a significant improvement over 
> the current one.

I don't think it's all that different from the current situation.

						- Bill

---

From: Matthew Garrett <[email-masked]>
Date: Mon, 21 Feb 2005 22:49:29 +0000

> submission mechanism will do).

Currently, drafts are submitted on the assumption that they'll end up
describing internet standards. If you grant permission for me to modify
RFC 2821 to describe my internal messaging system but require me to tell
the IETF that I'm doing so, it's likely to result in a somewhat larger
number of submissions. Many of the submissions would be entirely
inappropriate in the context of internet standards.

Providing that no passing off takes place, is there any reason why I
should not be able to modify RFCs in order to document local protocols
that are not intended for wider use?
-- 
Matthew Garrett | [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 22 Feb 2005 16:23:38 +0100

On Mon, Feb 21, 2005 at 03:05:37PM -0500,
 Bill Sommerfeld <[email-masked]> wrote 
 a message of 21 lines which said:

> 2) permit the IETF to use the text and then make further
> modifications as part of future standards work.

Nice, this is the equivalent of the GPL licence, but for standards and
not for programs. Microsoft will love it :-)

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 22 Feb 2005 10:44:58 -0500

On Tue, 2005-02-22 at 10:23, Stephane Bortzmeyer wrote:
> not for programs.

it's simply another way to describe part of our current requirement
that modified works only be produced through the IETF standards process.

						- Bill

---

From: Matthew Garrett <[email-masked]>
Date: Tue, 22 Feb 2005 16:16:16 +0000

> that modified works only be produced through the IETF standards process.

No. The requirements for something to be considered an IETF standard are
quite strict, and not always appropriate for certain use cases. I agree
that it should be possible for every modified RFC to be turned into an
IETF draft, but I don't agree this would be appropriate in every case.

---

From: "Lawrence Rosen" <[email-masked]>
Date: Mon, 21 Feb 2005 16:45:01 -0800

> use the text and then make further modifications as part of future

These objectives can be accomplished easily by licensing IETF documents
under an appropriate reciprocal open source license. For example, look at
sections 1(c) and 6 of the Open Software License (OSL version 2.1,
http://opensource.org/licenses/osl-2.1.php). Modifications of IETF documents
would be allowed, subject to reasonable reciprocity and other conditions
that would help IETF and its "customers" to recognize non-standard
implementations and protect everyone against patent lawsuits relating to the
standards. (See, e.g., OSL section 10.)

This is *not* incompatible with applying an IETF trademark only to the
official IETF versions of the documents. (See OSL section 4.) 

The OSL is but one of several reciprocal open source licenses that IETF
could use.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  ●  fax: 707-485-1243
Author of “Open Source Licensing: Software Freedom 
               and Intellectual Property Law” (Prentice Hall 2004)
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bill Sommerfeld> Sent: Monday, February 21, 2005 12:06 PM
> To: Matthew Garrett
> Cc: [email-masked]
> Subject: Re: draft-bradner-rfc-extracts-00.txt
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Feb 2005 19:57:56 -0500

> inappropriate in the context of internet standards.

To drill down further into your hypothetical, I would think that the document 
would possibly be very relevant to the IETF since:
 1) the IETF has been working on instant messaging for a while, and 
 2) SMTP includes a deprecated and rarely-implemented instant messaging feature (SEND, SAML, SOML; see rfc821 section 3.4).

> is there any reason why I

Your insights in solving your local problem may be more useful than you might 
think to the broader community.

						- Bill

---

From: Don Armstrong <[email-masked]>
Date: Wed, 23 Feb 2005 23:25:06 -0800

[I'm reesending this because the original message appears to have been
eaten somewhere along the way. Apologies if anyone receives it twice.]

On Mon, 21 Feb 2005, Bill Sommerfeld wrote:
> I fail to see the harm in requiring folks redistributing modified
> standards documents to 1) notify the IETF that they're doing so

The issues with requiring people to notify IETF have already been put
forward:

  1) Not everyone can physically notify the IETF that they're
     modifying the documents[1]
  
  2) Some individuals in specific locales may face legal ramifications
     if they are forced to make their modifications public.

Finally, there's the lack of any actual utility to the IETF of being
notified of the distribution of modified standards documents. To
illustrate this point, US Export controls require that the BXA be
notified everytime Debian adds a package implementing cryptography.
This results in a basically useless flood of messages to the BXA
which, I assume, are duly noted and redirected to /dev/null. [At
least, Debian, ttbomk, has never heard anything back from the BXA.]

Frankly, I'd strongly suggest wording this as a request to notify the
IETF when modifications are made, as this will handle the FOSS
comunity's concerns nicely, as well as curtailing useless
notifications that would likely just waste the IETF's time.

> modifications as part of future standards work.

Definetly. Ideally this would be worded so that the permisions that
the IETF needs to use the modifications would be granted to everyone.

Don Armstrong

1: See <[email-masked]> et al.
-- 
Filing a bug is probably not going to get it fixed any faster.
 -- Anthony Towns

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: Nathanael Nerode <[email-masked]>
Date: Thu, 24 Feb 2005 02:49:29 -0500

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".

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Feb 2005 16:51:00 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> On Sun, 2005-02-20 at 21:53, Matthew Garrett wrote:
    >> Why is this a concern? There is currently nothing preventing
    >> 1000 different documents from claiming to define any given
    >> standard. It would make more sense to ensure that only one
    >> document can claim to be the IETF standard for a given
    >> protocol. Once that's possible, there's no harm in allowing
    >> standards documents to be modified as much as people desire.

    Bill> I fail to see the harm in requiring folks redistributing
    Bill> modified standards documents to 1) notify the IETF that
    Bill> they're doing so 

Hi.  I'm still catching up on this discussion and will try to limit my
replies to earlier messages but felt this was worth responding to.

There is an obvious harm in that Debian and some other free-software
organizations have said they will be unable to extract code from our
documents or distribute copies of our standards.

I believe these organizations are accurately representing their
policies.  You and the IETF may think these policies are ludicrous,
wrong-headed, likely to lead to global warming and the extinction of
the human race, but at some level that doesn't matter.  Even if these
organizations are completely unreasonable in setting their policies,
the fact that they cannot extract code from our standards or ship
copies of our standards is a harm.  It makes development of software
implementing our standards more difficult and it makes our standards
incrementally harder to obtain because they will not accompany source
code to software implementing them.

Now that we've established a harm exists, the question becomes what
benefit does the IETF gain from requiring notification of changes and
does that benefit outweigh the harm that has been identified.

Personally I do not see significant benefits to notifying the IETF.

    Bill> 2) permit the IETF to use the text and then
    Bill> make further modifications as part of future standards work.

I think this would be a reasonable requirement.

--Sam

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Feb 2005 14:39:27 +0100

Personal opinion: I find much more confusion in these comments
than in the draft. I don't see any grounds to believe that it's
in the IETF's best interests, or in technology users' best interests,
for technical specifications to be "free documents" in the
sense used below. Technical specifications are used to achieve
interoperability; in the Internet we strive for global interoperability.
So *preventing* 3rd party modifications to specifications
is essential to their value as freely available open interoperability
standards.

Freely available: good
Freely modifiable: bad

    Brian