Subject: San Diego meeting slot

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 3 Oct 2006 00:08:12 -0400

We have a *tentative* slot assignment for Wednesday 1520-1720.  Agenda
items will follow shortly.

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

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 04 Oct 2006 02:26:01 -0700

> items will follow shortly.
Note that we expect a major agenda item to be the revision of 
draft-ietf-ipr-outbound-rights, which has been submitted to the I-D 
repository, but not yet published.

                 Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Oct 2006 12:11:53 +0200

It would be useful to have the WG discuss whether it wish to adopt:

http://www.ietf.org/internet-drafts/draft-josefsson-ipr-notices-00.txt

Pending a more clear view of the IETF consensus on that issue, RFC
3548bis (RFC4648) is somewhat stuck in AUTH48.

The running code seems to differ from the policy here.

Thanks,
Simon

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 Oct 2006 11:45:13 -0700

>The running code seems to differ from the policy here.

I agree with Simon's request, and I'd actually like to see if we can get
close to WG agreement on a way forward.  If we cannot, the only way
to get the full functionality of 3548bis is going to be remove the LGPL-ed
code and replace it with a pointer to a non-RFC place where it is maintained.
That has a list of problems we're all familiar with, and I'd rather get clear
answers to the base problem.
			thanks,
				Ted

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Oct 2006 17:08:07 -0400

I doubt it fully solves the problems, but section 5.5 of the outbound 
draft does address this.
Yours,
Joel Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 10:01:17 +0200

Section 5.5 of your document seem to discuss this topic, but it does not
solve the problem.

One problem is that free software licenses are poorly understood by this
WG.  In particular, your section 5.3 and 5.5 work against each other.

To be applicable for inclusion in a free software product, which is
something your section 5.3 claim is something we want to permit, the
work need to have a clear license.

Organizations and companies, such as Debian, review the license for
works that are candidates for being included in their distributions.  If
the license is not clear, the work cannot be included.

Most, if not all, internationally valid licenses are based on copyright.
The licenses typically require that the copyright notice is present and
preserved.

Compare the BSD license:
http://www.opensource.org/licenses/bsd-license.php

   Redistributions of source code must retain the above copyright
                                                        ---------
   notice, this list of conditions and the following disclaimer.

Compare the GPL:
http://www.opensource.org/licenses/gpl-license.php

   1. You may copy and distribute verbatim copies of the Program's
   source code as you receive it, in any medium, provided that you
   conspicuously and appropriately publish on each copy an
   appropriate copyright notice and disclaimer of warranty
               ----------------

Compare the Apache license:
http://www.opensource.org/licenses/apache2.0.php

   You must retain, in the Source form of any Derivative Works that You
   distribute, all copyright, patent, trademark, and attribution notices
                   ---------
   from the Source form of the Work

You can read other licenses too, if you like, but I believe you'll find
that many relevant licenses require that a correct copyright notice is
present and preserved in all copies.

I believe we have established that the author of material in an RFC
retain the copyright on the contributed material.  The author is not
necessarily the one listed as the RFC author.  Frequently material is
contributed by others, who of course retain their copyright.

Thus, an "appropriate" copyright notice would thus have to refer to the
author of the relevant material, and not to the IETF Trust or
(necessarily) to the RFC author.  If there is more than one code
contribution to a document, there may be multiple copyright notices.

This is the reason I believe we need to permit additional copyright
notices in RFCs.  If we don't permit this, it is difficult to establish
the correct copyright notice and license of code included in a document,
and people will have doubts over the legal rights to the code.

Also, it seems that the running code in the IETF is already to permit
multiple copyright notices, we have several example of this in the RFC
4xxx series.

See:

http://tools.ietf.org/wg/ipr/draft-josefsson-ipr-notices-00.txt

Thanks,
Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Oct 2006 02:48:42 -0700

> The licenses typically require that the copyright notice is present and
Changing the subject line, since this needs to be discussed on the list 
(Simon won't be in San Diego, and we need to discuss it on the list anyway).

I think the thrust of -outgoing is that there needs to be legal language 
crafted to achieve the desired effect; I think such legal language will 
have at least 2 components:

- The actual license from the IETF to whoever uses the documents
- The way in which other rights are acknowledged or referenced

The "additional difficulties" that 5.5 refers to are, I think, the 
difficulty of making sure in a way that is acceptable to IETF 
participants and users of IETF products that the rights granted through 
the IETF are in no way limited by the additional notices. (I think the 
draft needs to be updated to be explicit about what those difficulties 
are, btw - the people reading it 5 years down the road won't be able to 
remember this discussion).

The GPL is a good example, because I think the IETF will have problems 
claiming that software licensed *only* under the GPL conforms to the 
desire that "anyone can use them" in section 5.3; people who refuse to 
use code that is under "viral" licensing terms will not be able to use it.

So something in an RFC that is marked as

  this code sample copyright (c) Simon. All rights reserved. Available 
under the GPL

is not acceptable under 5.3 (I think - more opinions wanted), while

  this code sample copyright (c) Simon. All rights reserved.
  Available under the GPL and under the IETF licensing regime defined in 
RFC XXXX

would be - once all we're talking about here is finished. Again - I 
think. Not sure.

Thoughts?

                     Harald

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 12:31:30 +0200

> would be - once all we're talking about here is finished. Again - I 

I believe some code is always better than no code in an RFC.  Code helps
people get things done, which leads to a better Internet.

Even if you can't use the code in your products, you can at least read
it and use it internally for interop testing.

For example, the MD5 code in RFC 1321 has a license that makes it
difficult to use in many products.  (Few products use that code today.)
Not everyone wants to print "derived from the RSA Data Security, Inc.
MD5 Message-Digest Algorithm" in all material mentioning or referencing
the derived work.  Many people have chosen to not use the RFC 1321 code
for their MD5 implementations, but to develop their own.

Further, the RFC 1321 license doesn't seem compatible with the IETF
license.  For RFC 1321, I suspect the code was only intended to be
available under the specified license, and not under the IETF license
(whatever it was at that time).

Still, I have no doubt that presence of the MD5 C code in RFC 1321
helped get MD5 deployed and working faster.  Would you agree to that?

Another more recent example is SHA-2 in RFC 4634.  Notice the ambigious
license text in section 1.1 and the license (including copyright
notice!) in section 8.  Which license is the right one?  Many will not
use that code in their products, because of the license, but that
doesn't mean the code doesn't help.

Further, the RFC 4634 license is also not compatible with the IETF
license.  I suspect that the code in that document was NOT released
under the IETF license, but under the license indicated by the document.

The license of code in RFCs need to permit that the code is copied and
distributed, but beyond that, I believe the IETF should not place any
additional restrictions.  Authors will understand that picking a less
restrictive code available furthers the goal of having the specification
more widely and more rapidly implemented.

Finally, I think section 5.3 is wrong to imply that "everyone can use
the code" is a required goal.  It is certainly a good goal, but
sometimes the only options are to either not include code at all, or
include code with a license that results in not everyone being able to
use it.  In those situations, I think the choice is simple.

The running policy in the IETF appear to be that including code with
problematic licenses is not a problem -- I don't know of a single
example where code in an RFC is "usable by everyone".  People have
different requirements, and sometimes those requirements lead to not
being able to use a particular code.  That's life.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Oct 2006 03:37:20 -0700

> use it.  In those situations, I think the choice is simple.
That seems like a good basis for updating 5.3 - after all, we're trying 
to document what we want to accomplish....

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Oct 2006 09:20:02 -0400

Well, I sure understood the rough consensus of the working group to 
be "everyone can use the code any way they want."

I originally was in favor of a more restricted view, and came around 
to the unlimited perspective.

I would be very uncomfortable if every author could slap any 
restrictions they want on the code in RFCs.
That would seem to distinctly fail the agreed goal.

And that's why 5.5 is written the way it is, I think.
We want to allow other licenses.  But those licenses can not prevent 
people from using code in RFCs according to the IETF goal.
And, according to the WG agreeement, we are not trying to craft legal 
language in the RFC.

Yours,
Joel M. Halpern

At 06:37 AM 10/5/2006, Harald Alvestrand wrote:

>That seems like a good basis for updating 5.3 - after all, we're 
>trying to document what we want to accomplish....
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Oct 2006 15:56:58 +0200

Joel M. Halpern wrote:
> Well, I sure understood the rough consensus of the working group to be 
> "everyone can use the code any way they want."

I agree, but (as for text) this is inevitably limited by any
copyright restrictions placed by the author on top of what the
IETF says. Given that we are not asking for all possible
inbound rights, I don't see how to avoid doing something.

I would suggest changing this:

    However, the IETF does not wish to have IETF
    Contributions contain additional copyright notices and licenses, as
    that introduces a number of additional difficulties.

into

    However, the IETF believes it is confusing for IETF Contributions
    to contain additional copyright notices and licenses, and wishes
    such material to be external to IETF documents.

(I'm thinking that a registry of copyright and license conditions,
somewhat similar to our existing IPR disclosure database, might work.)

     Brian
> 
> I originally was in favor of a more restricted view, and came around to 
> the unlimited perspective.
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 16:14:41 +0200

>    such material to be external to IETF documents.

Let's take this slow.

The above change (if approved etc) would make it harder to include any
source code in IETF documents.  Agree, yes/no?

Removing source code from IETF documents would decrease the usefulness
of the specifications.  Agree, yes/no?

If you answer yes to both, then I hope that you see how I can claim
that this approach is actively working against both the running code
and the stated goals of the IETF.

Working against the IETF's mission could be justified, I suppose, if
there is some strong reason why things have to be in a particular way.
I don't see a strong reason here.  Above, I see a weak justification
that "it is confusing".  If something appears to be confusing, I think
we should strive towards making it less confusing.  Personally, I
don't find this topic that confusing.  A lot of people that work on
free software, myself included, work with material that carry multiple
copyright notices every day.  What's confusing about it?

/Simon

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 5 Oct 2006 10:17:18 -0400

Hi,

I have a real problem with copyrighting and licensing sections of an
IETF standard.

In the same way the author list was abused, I can see copyrighting
sections of an RFC being abused. Corporations would love to embed
licenses in industry standards, and the IETF has opposed that practice
for a long time (it is losing the battle, but we tried).

Imagine when each contributor can claim copyright on "their
contribution" to the document. Does the WG get to rewrite the
copyrighted sample code if it is implemented in a manner that is not
consistent with WG consensus, or is the WG required to keep it intact?
If the document editor rewords contributed copyrighted paragraphs, is
it still copyrighted by the original contributor, or does the editor
get to copyright it, or the WG if it is reworded to meet WG consensus?
Or do we need to keep all the contributions as they were submitted,
and end up with an anthology of copyrighted paragraphs? Will our
documents balloon to twice their current size because of all the
copyrights? Will the documents still be readable?

I think allowing contributors to copyright their contributions is
simply not a useful way to go, even if the contribution is a section
of code.

Viral licenses should be treated the way any other license is treated
by the IETF - the owner of the material can declare the licensing
terms on the IETF's IPR page, and the WG can decide whether to accept
the licensing terms in the draft. 

Then implementers of a commercial product can decide whether to
include the encumbered standard based on the terms and implementers of
open source can decide whether to include the encumbered standard
based on the terms. Debian and others can decide they will not include
commercially-encumbered standards in their products, and commercial
vendors can decide not to include virally-encumbered standards in
their products.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 5:49 AM
> To: Simon Josefsson
> Cc: Joel M. Halpern; [email-masked]; Steven M. Bellovin
> Subject: Outgoing section 5.5 and draft-josefsson (Re: San 
> Diego meetingslot)
> 
> Simon Josefsson wrote:

> Available

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Oct 2006 16:35:24 +0200

> source code in IETF documents.  Agree, yes/no?

No! it means that if you want to attach a license to source code
in an RFC, you do so external to the RFC.

> of the specifications.  Agree, yes/no?

Yes, but that is not a consequence.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Oct 2006 16:36:59 +0200

> contribution" to the document. 

I don't need to imagine. That is today's reality.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 16:54:29 +0200

> in an RFC, you do so external to the RFC.

Oh, I see.  It sounds like a good idea in theory.

However, it would make it impossible to use code licensed under many
software licenses in IETF documents.  I'm not sure if that was what
you intended?

For example, take the BSD license.
http://www.opensource.org/licenses/bsd-license.php

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:

    * Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.
...

Similar conditions are found in many licenses, including the GPL, the
MIT license, and the Apache license.

I believe we have two choices:

1) Require that code in RFCs are released under the at-publication
   then-current IETF copying conditions.  The IETF license is
   incompatible with most free software licenses, so we'd see a lot
   less source code in RFC with this option.  None of the RFCs with
   code in them today would have been acceptable, as far as I can
   tell.  I consider this a serious problem, and something that would
   be against the goal of the IETF.

2) Accept source code with other licenses.  We place some requirements
   on the licenses, but looking at the currently accepted licenses in
   RFCs, I don't think we can find any lowest common denominator.

If someone can think of other alternatives, that would be very good.

/Simon

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 5 Oct 2006 10:48:16 -0400

I strongly support keeping the license external to the RFC.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 10:35 AM
> To: Simon Josefsson
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: Outgoing section 5.5 and draft-josefsson (Re: 
> San Diego meeting slot)
> 
> Simon Josefsson wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Oct 2006 10:48:00 -0400

The whole point of the exercise is to ensure that those making use 
of  IETF RFCs can do so without difficulty.
We have agreed that making use of code from RFCs is a good think.
We have agreed that to do so, one needs the right to make changes to that code.

Allowing authors to place additional restrictions on that code is 
simply not consistent with the above.
The existence of additional copyright holders, who all grant the 
necessary rights, should be acknowledged.
But putting additional licensing text into the code fragments is a disaster.

There would be no point in having defined outbound rights.

With regard to the comment about getting the rights we need, clearly 
if we go with requiring unlimited use of code from RFCs, then we have 
to require that the IETF be given the right to allow that by all 
contributors.  In general, inbound rights have to be a superset of 
outbound rights.  But we can arrange that going forward.

Simon argued cogently on the list that code that could only be used, 
but not modified, was not helpful.  Well then, we should not permit 
licenses in code in RFCs that have that restriction.  Going down the 
path of trying to decide exactly what licenses we will permit is 
clearly a disaster.  We decided to avoid that.

Yours,
Joel M. Halpern

---

From: "todd glassey" <[email-masked]>
Date: Thu, 5 Oct 2006 07:45:12 -0700

Joel
The Group's consensus does NOT speak for the rest of the IETF and that is a
core failing therein. The issue is whether code is licensed for any and all
uses needed to facilitate a standard" OR "for any and all uses" period.

If the license is written with the current language then the IETF gave the
control of the code and its trademarks which are part of the document away.
This isn't my interpretation its the law and if Jorge is unwilling to
formally comment on this, you might ask him off the record why...

As to the issues here - this is the IETF - not the "We own your IP forever"
place. Its purpose is to be an open and fair framework and process flow for
the creation of 'standards by consensus of those involved in the development
of that standard' and nothing else.

That means that the way to deal with the Troll issue that pisses so many of
you off is to force the Trolls to be an active part of the Vetting Process.
The fact that there is no formal road map as to what Vetting is or how its
accomplished is a failing of the process architects now (Hey SOB yes I am
speaking of you... and a number of others - the mechanics of your systems
are broken, without oversight and without process-management for contingency
or real dispute resolution.

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 05, 2006 6:20 AM
Subject: Re: Outgoing section 5.5 and draft-josefsson (Re: San Diego meeting
slot)

> to the unlimited perspective.

Why - that makes it impossible to include IP controlled under any more
restrictive IP Grants or Licenses.

> restrictions they want on the code in RFCs.

Why ? - You DONT OWN the Standard and that is one of the core failings of
the mindset of this Group evidently.

> That would seem to distinctly fail the agreed goal.

Who agreed upon that Goal and was it 'vetted' in any form with the people it
will effect? No? Didnt think so.

> people from using code in RFCs according to the IETF goal.

Again - who's goal?

> And, according to the WG agreeement, we are not trying to craft legal

You CANNOT craft a submission process and guideline for Intellectual
Properties without dealing with the Legal issues. Especially the Copyright
issues per se.

> >>the code" is a required goal.  It is certainly a good goal,

Only if the intent of the IETF is to become an "Open Source" type resource
where any and all standanrds codified through it are particular to products
and processes that MUST be licensed to all under those terms.

Also what happens to all of the IP that came in before the amendments to the
RFC2026 or BCP78/79 guidelines existed? This is a serious question since
those license grants are not retroactive to those IP's submitted before
those amended terms of participation were included.

Also - if this IETF (today's) is offering services and requiring rights that
the previous IETF didnt, then those participants were allowed a different
set of processes for their participation and that creates an adversarial
model between todays IP and yesterday's.

> >> but

---

From: "todd glassey" <[email-masked]>
Date: Thu, 5 Oct 2006 07:57:49 -0700

----- Original Message ----- 
From: "David B Harrington" <[email-masked]>
To: "'Harald Alvestrand'" <[email-masked]>; "'Simon Josefsson'"
<[email-masked]>
Cc: "'Joel M. Halpern'" <[email-masked]>; <[email-masked]>; "'Steven
M. Bellovin'" <[email-masked]>
Sent: Thursday, October 05, 2006 7:17 AM
Subject: RE: Outgoing section 5.5 and draft-josefsson (Re: San
Diegomeetingslot)

> simply not a useful way to go, even if the contribution is a section

Why? - is the purpose of the process so that the IETF owns any and all
rights to the Standard and the Underlying IP's?

If that's true then the IETF has an issue with the Tax Value of those IP's
and what it plans to do about that ***IS*** going to become a serious issue
since I am formally filing a claim on the Bounty against that unpaid Tax.

> the licensing terms in the draft.

No It CAN NOT. The IETF cannot refuse any IP submission without creating a
tortuous interferrance claim for the Submitter against the IETF and those
WG/AD/IESG members that decided not to 'allow that entity's work to be
standardized'

> vendors can decide not to include virally-encumbered standards in

Not with the IETF's current process they cant.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Oct 2006 11:04:34 -0400

This note seems to assume that most of the code in RFCs comes from 
existing sources and is subject to external license restrictions.

At least in my experience that is not the case.  The code consists of
Code written by individuals for the RFC to expalin processing
MIB definitions written for the RFC
XML Schemas written for the RFC
ASN.1 written for the RFC
ABNF written for the RFC

Remember, the RFC is not normally used as an implementation 
library.  We are not trying to provide sample (much less reference) 
code.  We are trying to provide enough information that people will 
build interoperable implementations.

We have agreed that Open Source, GPL, commercial, and other users 
need to be able to use the code from RFCs.
Personally, I think that including code with a GPL in the RFC would 
be counter to that goal.

Yes, there are a few RFCs where commercial code has been included in 
the RFC.  There may be a problem for such cases in the future.  But 
allowing arbitrary restrictions on the code in RFCs is much, much worse.

Yours,
Joel M. Halpern

PS: Remember that authors can still make available anything they 
want, with any terms and conditions they want.  So an author can 
still have a copy of the same code with GPL conditions. But if the 
code needs to go in the RFC then the author needs to make it 
available according to the IETF rules.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Oct 2006 11:14:17 -0400

You observe that this working group does not speak for the whole IETF.
Indeed it does not.
But we already understand that and have a well defined way of dealing with it.
Once the working group reaches rough consensus, and the AD reviews, 
etc, there is an IETF last call.  That gives the IETF as a whole a 
chance to confirm or deny the rough consensus.

You also seem to conflate control of code and control of 
trademark.  Giving people the right to modify code we publish does 
give up "control" over that code.  That was the working groups rough 
consensus.  That has no impact on the IETF trademarks.  Please do not 
conflate the many different forms of intellectual property.  They are 
not interchangeable.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 17:32:53 +0200

"Joel M. Halpern" <[email-masked]> writes:

> licenses in code in RFCs that have that restriction.

That is a simplified view of things.

If we have two options:

1) No code in the RFC.

2) Code under a less than perfect license in an RFC (for example, the
   MD5 code in RFC 1321 or the SHA-2 code in RFC 4634).

I would chose the latter, since it helps to implement the standard.

I would agree that we don't always have only these two choices, but
sometimes, that is the case.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Oct 2006 17:48:03 +0200

> existing sources and is subject to external license restrictions.

Ah, right.  I would not go as far as to assume "most", but I do assume
that a significant portion of code that would be useful to include in
RFCs do come from existing sources and is subject to external license
restrictions, and I have so far been focusing on such code.

My view is based on documents that I'm familiar with.  We have code
from external sources or with additional licenses in several
documents, including RFC 1321, RFC 3492, RFC 4122, RFC 4226, and RFC
4634.

> ASN.1 written for the RFC

It seems our experience differ somewhat here.

I agree that these are good examples.  When possible, I think we
should strive towards making them available under the most liberal
license possible.

> Remember, the RFC is not normally used as an implementation library.
> We are not trying to provide sample (much less reference) code.  We
> are trying to provide enough information that people will build
> interoperable implementations.

I'm not sure I share this view.  There are RFCs whose purpose is to
provide easy access to actual implementations, e.g., RFC 4634.  They
are useful.  I would prefer if more RFCs were accompanied with
relevant example code, because I find them helpful when implementing
the document (regardless of whether I use the code or not).

> We have agreed that Open Source, GPL, commercial, and other users need
> to be able to use the code from RFCs.
> Personally, I think that including code with a GPL in the RFC would be
> counter to that goal.

I disagree, because I believe code in RFCs under, say, the BSD license
or the GPL is better than no code.

> PS: Remember that authors can still make available anything they want,
> with any terms and conditions they want.  So an author can still have
> a copy of the same code with GPL conditions. But if the code needs to
> go in the RFC then the author needs to make it available according to
> the IETF rules.

Of course.  However, that position prevent the IETF from including
useful code portions licensed under the BSD/GPL licenses, that could
help implement the RFC.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Oct 2006 11:58:30 -0400

Comment below the text, to ensure full context because I think this 
is the crux of the matter.

>the document (regardless of whether I use the code or not).

It seems to me that if the code is important enough that we want to 
publish the code in an RFC, then we need to make that code available 
to everyone to use.  That means it can not be subject to rules 
requiring publication of changes, or distribution of source, or any 
other such license restrictions.  If it is reasonable to say that 
only some readers can make use of the code, then it probably suffices 
to include an informational reference that says "sample code that is 
believed to implement this RFC can be found, along with its licensing 
conditions at URL X://Y.Z"

Yours,
Joel M. Halpern

---

From: "todd glassey" <[email-masked]>
Date: Thu, 5 Oct 2006 08:57:21 -0700

Pardon my being a little heated about this, but I was tossed out of this WG
for discussing the 5.5 issues some time ago and its well. Annoying to me.

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "David B Harrington" <[email-masked]>; "'Harald Alvestrand'"
<[email-masked]>; "'Simon Josefsson'" <[email-masked]>
Cc: "'Joel M. Halpern'" <[email-masked]>; <[email-masked]>; "'Steven
M. Bellovin'" <[email-masked]>
Sent: Thursday, October 05, 2006 7:57 AM
Subject: Re: Outgoing section 5.5 and draft-josefsson (Re:
SanDiegomeetingslot)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Oct 2006 17:08:28 +0200

> software licenses in IETF documents.  I'm not sure if that was what

If the code originates in the RFC and is added to an open source
package afterwards, it will be a matter of choosing a sensible
OSS license. (Where my definition of "sensible" means "has
no problem with adding code from another source".) Theoretically,
doing it the other way round would perhaps violate an OSS license,
but I feel confident it would be considered fair use and would
never get anybody in trouble.

    Brian

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 5 Oct 2006 09:59:49 -0400

> That would seem to distinctly fail the agreed goal.
It would also drive the IESG crazy, since it would have to evaluate each
and every variant license presented to it.  That's the sort of thing that
gets lots of documents bogged down.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Oct 2006 22:02:40 +0200

> simply not a useful way to go, even if the contribution is a section

+1

> the licensing terms in the draft.

I'd like to use CC-BY-SA and be done with it, and I think (IANAL) that
this is a superset of what the IETF needs.  Some draft submission tool
could automatically convert CC-BY-SA into RFC 3978 etc. boilerplates,
and if necessary derive a corresponding IPR statement, if "share alike"
is considered as "viral".

Those IPR notes are quite incomplete, nothing about the wannabe-patent
for RFCs 4405 up to 4407, nothing about the real patent for SHA-256 and
longer, nothing about the licence about conforming SHA implementations,
and many RFCs already depend on SHA instead of offering a choice.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 05 Oct 2006 22:35:55 +0200

> for their MD5 implementations, but to develop their own.

[...]
| /* In version 0.5 I've added the missing RSA credits to the code. */
[...|
| /* MD5 procedures derived from
[...]
|    and the RSA Data Security, Inc. MD5 Message-Digest Algorithm : */
[...]

If that's not good enough they're free to tell me.  It's certainly my
own code, only the algorithm is (no surprise) almost identical.  Some
drafts claim that MD5 is broken, and at the same time argue that SHA-1
is still okay for HMAC - IIRC I saw that in a HOTP draft.

Frank

---

From: Don Armstrong <[email-masked]>
Date: Thu, 5 Oct 2006 14:20:10 -0700

On Thu, 05 Oct 2006, David B Harrington wrote:
> licenses in industry standards, and the IETF has opposed that
> practice for a long time (it is losing the battle, but we tried).

There's nothing wrong with licenses embedded in standards, so long as
they grant the needed rights. [Granted, it's doubtful that
corporations would want to embed licenses which grant these rights
over more restrictive licenses.]

> simply not a useful way to go, even if the contribution is a section

Unless the IETF starts requiring copyright assignment, that is the way
that it will be (and indeed, is the way it has been.) I'm not in favor
of copyright assignment unless it comes with a reciprocal unlimited
licensing grant from the IETF to the copyright holder doing the
assignment.[1]

What we should do instead is make sure that works submitted to the
IETF are licensed by the copyright holders in a manner that enables
the IETF to do the things that the IETF needs to do (and likewise the
users of IETF standards.)

Don Armstrong

1: And frankly, getting companies to sign on to this will be a bit
difficult.
-- 
"Facts" are the refuge of people unwilling to reassess what they hold
to be "True".

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Oct 2006 02:01:14 -0700

> WG/AD/IESG members that decided not to 'allow that entity's work to be
Todd,

you are raising an off-topic issue again.

The IETF has decided a long time ago that it has the right to refuse to 
make a contribution a standard. RFC 3978 section 3.5:

3.5.  No Duty to Publish

   The Contributor, and each named co-Contributor, acknowledges that the
   IETF has no duty to publish or otherwise use or disseminate any
   Contribution.

This is not a current discussion item within this working group's 
charter, and is therefore offtopic for this mailing list. Please take it 
elsewhere.

                      Harald Alvestrand, as WG chair

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Oct 2006 11:07:05 +0200

> gets lots of documents bogged down.

The only reason the IESG do this appear to be because the policy imply
that they need to do it.  If we change the policy and permit code
licensed under non-IETF licenses to be published, the IESG wouldn't
have to do that work.  I assume that would make the IESG happier, and
allow them to spend more time on technical matters instead.

There are corner-cases, though, for licenses that even conflict with
the IETF copying conditions, which may argue for establishing a set of
known-good licenses, e.g. the revised BSD or the GPL licenses that
both appear to me be compatible with the IETF copying conditions if we
permit additional copyright notices, and strongly encourage authors to
pick one of the recommended licenses.

I see no reason why IETF documents shouldn't be able to include code
licensed under the BSD/GPL or other similar licenses.  It would
improve many RFCs.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Oct 2006 02:26:49 -0700

I think we need to separate the question of copyright notices from the 
question of copying conditions. The BSD licenses require preservation of 
copryight notices; the GPL licenses place requirements on the copying 
conditions.

The concerns overlap, but I think they are fundamentally different.

Joel M. Halpern wrote:
> Comment below the text, to ensure full context because I think this is 
> the crux of the matter.
>
> other such license restrictions. If it is reasonable to say that only 
> some readers can make use of the code, then it probably suffices to 
> include an informational reference that says "sample code that is

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Oct 2006 12:28:17 +0200

Harald Alvestrand <[email-masked]> writes:

> question of copying conditions.

Why?

> The BSD licenses require preservation of copryight notices; the GPL
> licenses place requirements on the copying conditions.

That is false, from the BSD license:
http://www.opensource.org/licenses/bsd-license.php

The "list of conditions and the following disclaimer" refer to the
copying conditions.

The BSD and GPL are similar in this respect, at least if I understand
what you are getting at.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Oct 2006 03:45:49 -0700

>> question of copying conditions.
Because a copyright notice is a statement about a fact that we have no 
intention of changing (we have not planned to do copyright assignment).

We *are* debating copying conditions.
> The BSD and GPL are similar in this respect, at least if I understand
So the BSD license may have the same problem as the GPL license in this 
regard.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Oct 2006 12:54:12 +0200

> intention of changing (we have not planned to do copyright

Ah, right, I agree.

> We *are* debating copying conditions.

I believe draft-josefsson-ipr-notices-00 discuss copyright notices
only.

> So the BSD license may have the same problem as the GPL license in
> this regard.

Right.  That's why I suggest that a "IETF source code license" may be
a poor idea, especially if that would preclude the ability of
including BSD/GPL code in RFCs.  Source code in RFCs are useful.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Oct 2006 03:57:09 -0700

> including BSD/GPL code in RFCs.  Source code in RFCs are useful.
I have a problem understanding the consistency of your stance.

You've fought long and hard for NOT permitting the publication of source 
code in RFCs where modification was impossible. Why wasn't that useful?

Harald

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Oct 2006 08:24:31 -0400

But, even the GPL license conflicts with the policy that I understood 
to be the rough consensus of the working group.

Personally, if we start allowing other, more stringent conditions on 
code in RFCs then I conclude that we have wasted the entire exercise 
to date.  Either we have to debate a whole list of conditions, and 
decide which ones are acceptable.  Or we have to declare that every 
working group has to make that decision for itself.  In which case we 
have not accomplished a darned thing, and likely have set up a 
situation in which many rFCs will have code that is not useable for 
many purposes.

Yours,
Joel M. Halpern

PS: If it were useful, I can believe we could find a way to add 
notices which explicitly matched our conditions, but required notice 
preservation.  It is not clear to me that such is useful.  It is 
clear to me that such is not what Simon is asking for.,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Oct 2006 15:54:11 +0200

(Sorry, this gets into inbound rights but that seems to be our
problem here.) I'm beginning to wonder if we shouldn't be rather
hard headed and say to authors:

Code embedded in IETF Contributions MUST NOT be subject to
any conditions that prevent the IETF from granting unrestricted
rights to use, republish or modify it. It is the Contributor's
responsibility to ensure that contributed code is free
of such restrictions.

IMHO if someone puts the cart before the horse by putting
code under an irrevocable license before contributing it
to the IETF, they should build their own clean room and rewrite
the code for us.

After the code has already become an IETF Contribution, a copy
of it could be put under any license; we wouldn't care.

     Brian

---

From: "todd glassey" <[email-masked]>
Date: Fri, 6 Oct 2006 05:16:28 -0700

Harald - if you are saying that there is no possibility of reviewing any
past decisions and their value or implications based on new legal
requirements then how would anything in the IETF get changed.

My commentary stands.

Todd Glassey

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; "'Steven M. Bellovin'" <[email-masked]>
Sent: Friday, October 06, 2006 2:01 AM
Subject: ADMIN: Offtopic warning (Re: Outgoing section 5.5 and
draft-josefsson (Re: San Diegomeetingslot))

---

From: "todd glassey" <[email-masked]>
Date: Fri, 6 Oct 2006 07:21:50 -0700

How then do you deal with the changes in the licensing model over the years.
These constrain the IP submitted and create a set of user rights  that will
have to be administered separately forever or the IETF breaches the contract
with those clients and all who participated in those efforts.

This is a critical consideration and design requirement moving forward - the
IETF cannot ignore the agreements and commitment's it contractually bears
for all of that earlier submitted IP.

Todd

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 06, 2006 5:24 AM
Subject: Re: Outgoing section 5.5 and draft-josefsson (Re: San Diego meeting
slot)

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 Oct 2006 18:53:14 +0200

> requirements then how would anything in the IETF get changed.
note - I have received advice that "offtopic" is not strictly true of 
the statement you made.
It is within the scope of what the IPR WG could possibly work on, but is 
not related to a current work item.

The steps necessary to change something through a working group are:
- Get agreement that whatever it is needs changing
- Get that agreement documented as a chartered work item of a WG
- Get WG agreement on what the change should be.

So far, your statement has no relevance to steps 2 and 3.

>>> No It CAN NOT. The IETF cannot refuse any IP submission without creating
>>>       
> a
>   
>>> tortuous interferrance claim for the Submitter against the IETF and
>>>       
> those
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Oct 2006 14:20:28 -0400

Yes, whatever rights we plan to grant for outbound have to be granted 
to us on the inbound side.

If we stick with the rough consensus that all code may be used and 
modified in any fashion, than anyone including code in an IETF 
contribution has to grant us the right to do that, including the 
ability to let others do that.

And yes, that may mean that some existing code can not appear in 
RFCs.  If doing this in the sensible fashion means that 1 or 2 RFCs 
per thousand face some production obstacle, but everyone knows 
clearly what they can do, and we don't need to argue about whether 
specific uses are permitted, then that is a (very) good trade off.

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 07 Oct 2006 10:52:47 +0200

Harald Alvestrand <[email-masked]> writes:

> You've fought long and hard for NOT permitting the publication of
> source code in RFCs where modification was impossible. Why wasn't that
> useful?

Someone had the same reaction privately, so I suppose I should explain
my stance.  My preference is, in order of priority:

1. RFCs (entire RFCs [1]) should be free to distribute and modify,
   under specific conditions required to solve the problem of modified
   works implying or claiming to be the real work.

2. Having code in RFCs is better than having no code in RFCs,
   regardless of license.

I realize that it may be the case that some aspects of 2 work against
some aspects of 1, and depending on your priorities, you'd might
change 2 into "non-free code is worse than no code" and then this
issue becomes a non-issue.  I could see good arguments for either
case.

I don't want to a priori assume that 1 and 2 are mutually exclusive
goals.  There may be an intersection that is acceptable.

To understand what I mean with a compromise between 1 and 2, consider
this situation:

We require RFCs to be modifiable, but invent a new document serie "RFC
Attachments" which is permitted to contain non-free material, because
such material may be useful for implementers.  The attachments could
be stored in a file RFC4711-foobar.txt.  Then, it would be legal to
include the RFC itself in free software, as long as you don't also
store the RFC attachment in the free software.

This approach would solve the problem Harald mentioned that, to the
extent this really is a problem, it is difficult to read and implement
an RFC without exposing yourself to reading copyrighted code that you
can't use.

Of course, this was a strawman that may have obvious problems, but I
don't want to assume that it is impossible to solve those problems.

/Simon

[1] I consider the assumption that we must distinguish between code
and text a mistake, people have attempted to derive useful definitions
of code and text and failed before.  Until the WG is approaching a
solution to this problem, I'd continue advocating a simpler solution
(entire modifiable RFCs) because I believe we won't find a good
solution to the problem of separating code and text.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 07 Oct 2006 08:15:37 -0400

I think I see where at least part of my concern comes from.
I don't agree with your item 2.
I can easily imagine several different licenses that would be very 
bad to have in an RFC.  Hence I disagree strongly with your statement 
that "[H]aving code in RFCs is better than having no code in RFCs, 
regardless of license."

To give two examples, a license that said 'if you use this code in 
your product, you must give away the source to your entire product" 
would be unacceptable to me.  Equally, a license which said "if you 
use this code, you must license all intellectual property in the 
product to company X."  I can imagine many other unacceptable licenses.
As was recently mentioned on the list, it is very hard to avoid 
claims of contamination by code published in an RFC.

Hence, there is no way we can simply allow any and all licenses.
Getting into a debate about which licenses we can allow would be a 
disaster.  I doubt we could agree.  (I expect that some people 
disagree with what I consider unacceptable above.)

That is part of why we decided on no restrictions for code.

There is no problem with having restrictions on things that are 
referenced (particularly informational references) in the RFC.  And 
there is no need for such items to be published by the IETF, as such 
references can point anywhere one wants.  My concern is with code 
that we consider to be part of the RFC (MIBs, ASN.1, sample algorithms, etc...)

Yours,
Joel M. Halpern

PS: If the IAOC comes back to us and says that they can not craft 
legal language and procedures to do what we say, then we will have to 
consider alternatives.  But given taht there have been suggestions of 
ways that may work to accomplish the working group agreement, I see 
no reason to push for a change based on the possibility it may be 
hard to craft a practical implementation.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 6 Oct 2006 11:10:00 -0700

Give me a chance Harald - I just made the statement this AM. So I need a
reasonable amount  of time to do #2 and #3 so - lets kick it around before
you try and nail me to the cross again OK?

Todd

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Oct 2006 08:55:54 +0200

> don't want to assume that it is impossible to solve those problems.
A strawman that would fit much better with what I percieve as the 
possible consensus of this WG would be to require that RFCs *not* be 
modifiable, and that all modifiable parts were in attachments. Would 
this be acceptable to you?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Oct 2006 10:45:40 -0400

Unfortunately, the code often contains normative information, and 
very frequently is very helpful for actually understanding the 
RFC.  I can not see, for example, moving the MIB to an attachment to 
an RFC.  Without the MIB text, there is no substance.  Hence, I think 
it would be a very bad idea to require that all code that is to be 
modifiable (as per the WG rough consensus)  be in a separate attachment.

I have no problem with having references to code that has other, more 
restrictive licenses.

And I am willing to let the IAOC and the lawyers figure out what the 
best way is  to meet our stated goals (RFC text useable without 
modification, RFC code useable in any way desired including 
modifications.)  If they come back and say it can't be done, then we 
try again.  But since I have seen several ideas on the list which 
seem likely to work, I see no reason to change the agreement because 
of the risk that it might not be possible to define a practical procedure.

Yours,
Joel

---

From: "todd glassey" <[email-masked]>
Date: Mon, 9 Oct 2006 09:10:35 -0700

Per WIPO the  addition of the Code to the Document in any form makes it an
INDUSTRIAL DESIGN and not something alone that Copyright controls. This is
an issue since the entire suite of protections the IETF has are specific to
use statements that are tied to copyright assignments and so ineffective
since they don't control the other Industrial Design Rights.

Todd Glassey

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 09, 2006 7:45 AM
Subject: Re: Outgoing section 5.5 and draft-josefsson (Re: San Diego meeting
slot)