Subject: #1400 Opinion poll - question draft

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2006 08:54:41 +0100

This issue is now #1400 in the tracker.

And I think it's time for one of my (in)famous opinion polls.

First - let's see if I can get the question right. If it's OK, we'll go on 
to state opinions. So please do NOT spend bandwidth on stating your opinion 
now - this is about whether the question is right.

Question formulation follows.
--------------------------------------------------------------------
We have two alternative formulations suggested for section 5.3 of the draft:

1) Original:

   IETF contributions often include components intended to be directly
   processed by a computer.  These may be ABNF definitions, XML Schemas
   or DTDs, MIBs, or even classical programming code.  These are include
   for clarity and precision in specification.  It is clearly
   beneficial, when such items are included in IETF contributions, to
   permit the inclusion of such code fragments in products which
   implement the contribution.  It has been pointed out that in several
   important contexts, use of such code requires the ability to modify
   the code.  One common example of this is simply the need to adapt
   code for use in specific contexts (languages, compilers, tool
   systems, etc.)  Such use frequently requires some changes to the text
   of the code from the IETF contribution.  Another example is that code
   included in open source products is frequently licensed to permit any
   and all of the code to be modified.  Since we want this code included
   in such products, it follows that we need to permit such
   modification.  While there has been discussion of restricting the
   rights to make such modifications in some way, the rough consensus is
   that such restrictions are likely a bad idea, and are certainly very
   complex to define.

   As such, the rough consensus is that code components of IETF
   contributions can be extracted, modified, and used by anyone in any
   way desired.

2) Reformulation:

   IETF contributions often include components intended to be directly
   processed by a computer.  These may be ABNF definitions, XML Schemas
   or DTDs, MIBs, or even classical programming code.  These are include
   for clarity and precision in specification.  It is clearly
   beneficial, when such items are included in IETF contributions, to
   permit the inclusion of such code fragments in products which
   implement the contribution.  It has been pointed out that in several
   important contexts, use of such code requires the ability to modify
   the code.  One common example of this is simply the need to adapt
   code for use in specific contexts (languages, compilers, tool
   systems, etc.)  Such use frequently requires some changes to the text
   of the code from the IETF contribution.  Another example is that code
   included in open source products is frequently licensed to permit any
   and all of the code to be modified.  Since we want this code included
   in such products, it follows that we need to permit such
   modification.  While there has been discussion of restricting the
   rights to make such modifications in some way, the rough consensus is
   that such restrictions are likely a bad idea, and are certainly very
   complex to define.

   As such, the rough consensus is that code components of IETF
   contributions can be extracted, modified, and used.

   Draft authors or editors MAY state that substantial
   modifications based on the published code have to be
   "shared alike", i.e. published with a similar proviso.

There were 14 people who stated at the San Diego meeting that they were 
part of a consensus for the first version. While the second alternative was 
not explicitly put on the table in San Diego, I think the debate has been 
circling around the issue long enough that it's reasonable to consider 
these 14 as not supporting the second - but it's better to ask than to 
blindly assume that. So I'll give more than two alternatives:

A) I stated a preference in San Diego, and prefer version 1
B) I stated a preference in San Diego, but prefer version 2
C) I did not state a preference in San Diego, and prefer version 1
D) I did not state a preference in San Diego, and prefer version 2
E) I have another opinion, which is...

----------------------------------------------------------
Remember: I AM NOT ASKING FOR PEOPLE TO STATE AN OPINION NOW.
I am asking on whether the question formulation is "good enough".

When trying to evalate responses, I intend to look at the number of people 
who choose A and B, and see how they match up with the 14:0 distribution of 
people who stated an opinion in San Diego. If they all choose A, I'll count 
the 14 people in San Diego as preferring version 1; if they spread out, 
I'll evaluate it differently - if A:B has the same distribution as C:D, 
I'll just forget about reading anything into the San Diego poll and 
continue just based on the email poll.

But this is the IETF, so it's NOT a vote; the purpose of the exercise is to 
figure out whether there is a rough consensus present, or whether there is 
a sizeable group of participants who agree that version 2 is better than 
version 1.

A 51:49 outcome will decide nothing.

                           Harald

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

---

From: Mukundan R <[email-masked]>
Date: Tue, 05 Dec 2006 14:22:58 +0530

Respected all,

Some of my queries on the question draft.

Queries related to question Draft Version 2:

   1. In para 3, using "MAY" could lead to non-uniform implementation.
      Can this be replaced with "MUST".
   2. In para 3, using "similar" is ambiguous. Should we include a more
      binding statement on the type of rights that has to be shared?
   3. In para 3, "shared alike" is ambiguous without any particular
      reference.
   4. In para 3, "published" - Any restrictions on the type of
      publications that needs to be done is not clear

Queries common to both the versions:

   1. Can we replace the occurence of "code" with "pseudo code" to make
      it clear and generalistic in nature?
   2. Can we replace "often" in para 1 with "can".

Thanks and Regards
Mukundan

Harald Tveit Alvestrand wrote:

> First - let's see if I can get the question right. If it's OK, we'll 
> go on to state opinions. So please do NOT spend bandwidth on stating 
> your opinion now - this is about whether the question is right.
>
> There were 14 people who stated at the San Diego meeting that they 
> were part of a consensus for the first version. While the second 
> alternative was not explicitly put on the table in San Diego, I think 
> the debate has been circling around the issue long enough that it's 
> reasonable to consider these 14 as not supporting the second - but 
> it's better to ask than to blindly assume that. So I'll give more than 
> two alternatives:
>
> When trying to evalate responses, I intend to look at the number of 
> people who choose A and B, and see how they match up with the 14:0 
> distribution of people who stated an opinion in San Diego. If they all 
> choose A, I'll count the 14 people in San Diego as preferring version 
> 1; if they spread out, I'll evaluate it differently - if A:B has the 
> same distribution as C:D, I'll just forget about reading anything into 
> the San Diego poll and continue just based on the email poll.
>
> But this is the IETF, so it's NOT a vote; the purpose of the exercise 
> is to figure out whether there is a rough consensus present, or 
> whether there is a sizeable group of participants who agree that 
> version 2 is better than version 1.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Dec 2006 11:18:18 +0100

> I am asking on whether the question formulation is "good enough". 

Yes, but I am about to comment on the new text...

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Dec 2006 12:39:46 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

>   or DTDs, MIBs, or even classical programming code.

Because it has been discussed numerous times, and some of the
StringPrep/IDNA authors' beliefs regarding document copyrights seem to
be in conflict with what this WG appear to have consensus on, I'd
prefer if the explicit example "data tables" were included in that
paragraph too.

I'm assuming here that there is consensus, which I believe there is,
that tables such as those in, e.g., RFC 3454, are intended to be
covered by the above, and be usable by implementers.

>   These are include for clarity and precision in specification.  It
>   is clearly beneficial, when such items are included in IETF
>   contributions, to permit the inclusion of such code fragments in
>   products which implement the contribution.

Note that the same argument holds for non-code material as well.

Several of the copyright violations that I mentioned in Vancouver were
regarding text in RFCs, and not the source code.

I don't believe the separation of licenses for code and text will be a
fruitful one.  I believe the IETF will be forced to revise its license
again in a few years to allow use of text in RFCs under similar rights
that is now being discussed regarding code.  I think we should keep
this in mind in the discussions.  We should make sure future license
revisions will be able to add rights to earlier documents.  It doesn't
seem wise to make it possible to remove rights to earlier documents,
though.

>   It has been pointed out that in several important contexts, use of
>   such code requires the ability to modify the code.  One common
>   example of this is simply the need to adapt code for use in
>   specific contexts (languages, compilers, tool systems, etc.)  Such
>   use frequently requires some changes to the text of the code from
>   the IETF contribution.  Another example is that code included in
>   open source products is frequently licensed to permit any and all
>   of the code to be modified.  Since we want this code included in
>   such products, it follows that we need to permit such
>   rights to make such modifications in some way, the rough consensus
>   is that such restrictions are likely a bad idea, and are certainly
>   very complex to define.
>

I suggest to add "copy and distribute" as well, and say that "anyone"
can do this, and to require that those who extract/modify/etc still
have to follow the IETF license.  I suggest replacing it with:

   As such, the rough consensus is that code components of IETF
   contributions can be extracted, modified, copied, distributed and
   used, by everyone in any way desired, as long as the license is
   followed.

The "copy and distribute" covers those two uses for code, which is
commonly granted by free licenses.  Assuming that there is consensus
around extracting, modifying and using code, I don't think adding
copying and distributing is controversial.

The second part "by everyone in any way desired" is there to make sure
that everyone is granted the rights, and not, as in RFC 3978, the
right is only granted to the ISOC.  That text was in the first text in
your message, I'm not sure why you dropped it.  The final
qualification "as long as the license is followed" is there to make
sure that any license variations permitted by the IETF are still
enforced (e.g., the "shared alike" clause below).

>   "shared alike", i.e. published with a similar proviso.

I understand the intention here, but I'm not sure everyone understands
what this refers too.  I don't have a specific suggestion how to
clarify it yet, though.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2006 13:04:30 +0100

Simon, you're raising different issues.

> covered by the above, and be usable by implementers.
I think that's a reasonable addition - the list here is examples, not 
exhaustive.
> seem wise to make it possible to remove rights to earlier documents,
I believe that the WG has declared consensus that it disagrees with you 
on the code/text separation issue.

The question of how to formulate the permissions granted from the author 
to the IETF is part of the "incoming" discussion - and the question of 
how to make the incoming rights be as stable as possible, so that we do 
NOT have another round of "go back to the authors", will, I believe, be 
a heavily featured item of that discussion.
> enforced (e.g., the "shared alike" clause below).
"Copy and distribute" is allowed for any part of the RFC. If that isn't 
clear from the rest of the document, this needs changing. But it's not 
what we're currently discussing.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2006 13:10:31 +0100

--On 5. desember 2006 14:22 +0530 Mukundan R <[email-masked]> 
wrote:

>   • In para 3, using "MAY" could lead to non-uniform implementation.
>   • In para 3, using "similar" is ambiguous. Should we include a more
>   • In para 3, "shared alike" is ambiguous without any particular
> reference.
>
>   • In para 3, "published" - Any restrictions on the type of

This is Frank's proposed text. I'll let him deal with that.

>   • Can we replace the occurence of "code" with "pseudo code" to make

No. Pseudocode is not intended to be directly processed by a computer, and 
that's what this section is about. See first line, and discussions in list 
archive.

>   • Can we replace "often" in para 1 with "can".

I do not think that change materially affects the issue under discussion, 
and I think "often" serves to underscore the fact that this happens a lot 
of the time. So I will not offer to change this.

             Harald

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Dec 2006 13:33:09 +0100

Harald Alvestrand <[email-masked]> writes:

> I believe that the WG has declared consensus that it disagrees with
> you on the code/text separation issue.

If so, please have that be reflected in Joel's draft, so it is
recorded as the WG consensus.  The code vs text separation is a
decision that has to be made before the current discussions makes
sense.  Recording that earlier decision, which this discussion assume,
seems to be the appropriate way forward.

> The question of how to formulate the permissions granted from the
> author to the IETF is part of the "incoming" discussion - and the
> question of how to make the incoming rights be as stable as possible,
> so that we do NOT have another round of "go back to the authors",
> will, I believe, be a heavily featured item of that discussion.

Right.

> "Copy and distribute" is allowed for any part of the RFC. If that
> isn't clear from the rest of the document, this needs changing. But
> it's not what we're currently discussing.

The text in the document doesn't contain the word "distribute".  If I
remember correctly, it is currently permitted to only copy and
distribute entire RFCs, not parts of RFCs.

You didn't address why you dropped the "by anyone" part, which amounts
to a similar error that is in BCP 78 now: granting rights to the
IETF/ISOC only, and not the "everyone".  A license statement, and even
an intention for a license statement, must be clear on whom license
the material and to whom.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2006 14:04:01 +0100

> seems to be the appropriate way forward.
It is reflected in Joel's draft.

It is also reflected in the text of the consensus from San Diego.

And I sent you this note on January 17:

> Simon,
>
> --On tirsdag, januar 17, 2006 15:02:54 +0100 Simon Josefsson 
> <[email-masked]> wrote:
>
>>
>>> I don't see consensus for *dis*allowing "modified text" either, but
>>> I'd like to establish the pieces of consensus that we have, so that we
>>> don't have to loop around *those* endlessly.
>>
>> You agreed that we don't have consensus on how to separate "code" and
>> "text", but still you wish to continue down that road.  I don't
>> understand the motivation for that.  It seems like short-cutting the
>> interesting discussion on principles in order to achieve some
>> milestones that doesn't solve the expressed problems, results that may
>> even further complicate the license situation.
>
> I'm ruling you out of order here.
>
> It's perfectly OK for you to argue that we need to treat text the same 
> way we treat code.
>
> But as far as I can tell, you are the only person arguing that we 
> should not be conducting the discussion by considering them separately 
> - and I consider THAT to be likely to derail the debate.
>
> Welcome to "rough" consensus.
>
>                      Harald
>
I did not see any sign of support for your position.

This issue is closed.
> distribute entire RFCs, not parts of RFCs.
5.1.  Rights Granted for Reproduction of RFCs

   It has long been IETF policy to encourage copying of RFCs in full.
   This permits wide dissemination of the material, without risking loss
   of context or meaning.  The IETF wishes to continue to permit anyone
   to make full copies and translations of RFCs.

5.2.  Rights Granted for Quoting from IETF Contributions

   There is rough consensus that it is useful to permit the quoting
   without modification of excerpts from IETF Contributions.  Such
   excerpts may be of any length and in any context.  Translation of
   quotations is also to be permitted.  All such quotations SHOULD be
   attributed properly to the IETF and the IETF document from which they
   are taken.

You're right that the word "distribute" does not occur.
If you're suggesting that these 2 paragraphs are not clear enough in 
expressing the desire to permit distribution, that's a separate (and 
reasonable) issue. Send text.
> the material and to whom.

You're right - Frank asked for the last 4 words to be dropped, not the 
last 6. I'll restore those 2 words in the version I send out when I call 
the question.

FWIW: Alternative 1 is what's in the draft now (no changes).
Alternative 2 is what I percieve Frank's counter-proposal to be, based 
on the editing instructions he has sent to the list.

Nothing in the proposed poll text should be taken as me supporting a 
position; I'll list my name when I report the poll results.

                    Harald

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 Dec 2006 09:42:07 -0500

Yes.  

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 2:55 AM
> To: [email-masked]
> Subject: #1400 Opinion poll - question draft
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Dec 2006 16:20:49 +0100

I'm changing the subject because this is a separate issue.

> It is reflected in Joel's draft.

No, it does not appear to be reflect explicitly.  I re-read Joel's
draft now, and it implicitly assumes that rights to code and text will
be handled differently from each other.  You can see that in how
section 5 is divided into rights granted for different purposes,
without discussion of how that separation came to be.  There is
nothing explicit in there to indicate that how the sub-sections of 5
are outlined is based on an implicit assumption.

I suggest adding a paragraph before section 5.1, in the introduction
text in section 5:

  The structure below assumes that there can be different licenses,
  and different outgoing rights, for different parts of a particular
  document.  For example, the rights to code portions of a document
  may be different from the rights to text portions of a document.  To
  permit different licenses for different parts of a document was an
  intentional decision, and it allows more flexibility when deciding
  the license for any specific parts.

With text like that, or actually, any text whatsoever that explicitly
mention the problem, I would regard the issue closed.  I still believe
it will be an unfortunate decision that we'll have to revise in a few
years, though, but I understand that unless someone gives me support
on this, the above appear to be the current consensus.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Dec 2006 16:31:19 +0100

> reasonable) issue. Send text.

Right, I believe that this is not sufficiently clear to be
non-ambiguous when parsed by the lawyers who will eventually write
legal text for this.  How about the following?

   It has long been IETF policy to encourage copying and distribution
   of RFCs in full.  This permits wide dissemination of the material,
   without risking loss of context or meaning.  The IETF wishes to
   continue to permit anyone to make full copies and translations of
   RFCs, and to distribute them to anyone.

   There is rough consensus that it is useful to permit the quoting
   without modification of excerpts from IETF Contributions and
   distributing the quotes.  Such excerpts may be of any length and in
   any context.  Translation of quotations is also to be permitted.

What remain is the current last sentence of 5.2:

   All such quotations SHOULD be attributed properly to the IETF and
   the IETF document from which they are taken.

I wonder whether lawyers will understand the fine precision intended
by that SHOULD?  How about:

   All such quotations SHOULD be attributed properly to the IETF and
   the IETF document from which they are taken.  That means that there
   should be a strong recommendation that all such quotations be
   attributed, but it should not be a legal requirement for being able
   to quote a document.

I suspect that this might be a controversial change, but given that it
currently reads SHOULD and not MUST, I suspect that this is what was
intended.  Clarifying that would be useful.

Thanks,
Simon

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Dec 2006 17:11:15 +0100

>> E) I have another opinion, which is...

If you pick E better say if you're one of the 14:1 in San Diego
(or not) for Harald's trend analysis.  For me it's simple, I pick D.

The poll could be more interesting if it's copied to the general list,
if there are no other (or not enough) C-D-E folks on the IPR list.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Dec 2006 17:44:15 +0100

Simon Josefsson wrote:

> How about the following?

>    RFCs, and to distribute them to anyone.
           ^^^ ^^ ^^^^^^^^^^ ^^^^ ^^ ^^^^^^
Diff mark by me, please correct me if I missed another diff.  It's okay,
maybe a bit verbose, but less chances to get it wrong and split hairs.

>    any context.  Translation of quotations is also to be permitted.
                   ^^^^^^^^^^^ ^^ ^^^^^^^^^^ ^^ ^^^^ ^^ ^^ ^^^^^^^^^
At some point it will be too verbose, when folks desperately look for a
"trap", and there is none.  You could also say that any "quotation of
translations" are permitted, translating pieces of text outside of their
complete context can be difficult.

> by that SHOULD?

Lawyers not understanding a 2119-SHOULD probably can't help with this
job.  The SHOULD IMO only means that there can be compelling reasons to
violate it, e.g. you can post grep- or diff-results without annotations,
you can write "be liberal" without a link RFC 1123, and you can talk
about "features with a high astonishment factor" without a link to REXX
and Mike Cowlishaw - IIRC in an IAB document Harald wrote "traditional".

>  How about:

Actually "cannot be".  Otherwise the lawyers could send us back an essay
about "fair use" that nobody (excl. lawyers) can decode.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Dec 2006 18:20:22 +0100

> This is Frank's proposed text. I'll let him deal with that.

That was about Mukundan's questions

>> In para 3, using "MAY" could lead to non-uniform implementation.

No, offering a simple choice is essential.  Brian said he hates any
"viral" clauses, therefore he must not be forced to use it, even in
the weak form presented here.

>> In para 3, using "similar" is ambiguous. Should we include a more

Intentional fuzzy, let the lawyers figure it out, it could mean that
the GFDL or CC-BY-SA or anything in that direction is similar enough.

IANAL, I can't tell what the real differences are in legal conflicts.

>> In para 3, "shared alike" is ambiguous without any particular
>> reference.

"Alike" = as stated in section 5.3 inluding the proposed MAY clause,
it's a self-reference.

>> In para 3, "published" - Any restrictions on the type of

There are no explicit restrictions, I thought that it goes without
saying that this means "making freely available", any place visited
by Googlebot... :-)

Maybe the amended version posted yesterday is minimally better:

~~~ old ~~~

~~~ new ~~~
contributions can be extracted, modified, and used by anyone
worldwide.

Draft authors or editors MAY state that substantial modifications
based on the published code have to be "shared alike", i.e.
published with a similar proviso, or contributed to the IETF.

~~~ end ~~~

Frank

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 Dec 2006 12:31:38 -0500

Actually, I though we were supposed to say "the wording of the
question is correct or not" 

> From: Frank Ellermann [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 11:11 AM
> To: [email-masked]
> Subject: Re: #1400 Opinion poll - question draft
>

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 Dec 2006 12:36:56 -0500

I really dislike allowing viral licensing in IETF standards.
I don't think it belongs there.
If a contributor wants to use different licensing than IETF standards,
then don't put the code in an IETF document; make it available
elsewhere.

dbh 

> Sent: Tuesday, December 05, 2006 12:20 PM
> To: [email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 05 Dec 2006 18:44:05 +0100

David B Harrington wrote:

> Actually, I thought we were supposed to say "the wording of the

You're right, Harald can mix a fine tuned second version, adding
"by anyone" plus "worldwide" plus Brian's improvement.

Frank

---

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 5 Dec 2006 11:48:09 -0800

Through all of this discussion, I'm still left wondering whether the
Academic Free License (AFL 3.0), www.rosenlaw.com/AFL3.0.htm (also published
at www.opensource.org as an OSI-approved license), would satisfy the IETF
policies? Can I contribute both code and text to IETF under AFL 3.0? 

Regarding contributors' commitment to specific outbound rights, see AFL 3.0
section 1(c). I would like it if something like AFL 3.0 also served as
IETF's outbound license.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
Stanford University, Lecturer in Law
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)

> Sent: Tuesday, December 05, 2006 8:44 AM
> To: [email-masked]
> Subject: Re: Improvements to section 5.{1,2} in outbound-rights
> 
> Simon Josefsson wrote:
> 
> > How about the following?
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2006 22:15:46 +0100

--On 5. desember 2006 11:48 -0800 Lawrence Rosen <[email-masked]> 
wrote:

> Academic Free License (AFL 3.0), www.rosenlaw.com/AFL3.0.htm (also
> published at www.opensource.org as an OSI-approved license), would
> satisfy the IETF policies? Can I contribute both code and text to IETF
> under AFL 3.0?

This document is about stating what the IETF wishes to grant, not about 
picking the mechanism to do it.

You're a lawyer, so you can give informed advice about whether the AFL as 
an inbound grant of rights to the IETF, or as an outbound license from the 
IETF, would allow the IETF to do what the -outbound document says is the 
IETF's desire....

>
> Regarding contributors' commitment to specific outbound rights, see AFL
> 3.0 section 1(c). I would like it if something like AFL 3.0 also served as
> IETF's outbound license.
>
> /Larry
>
> Lawrence Rosen

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Dec 2006 22:10:13 -0500

--On Tuesday, 05 December, 2006 08:54 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> First - let's see if I can get the question right. If it's OK,
> we'll go on to state opinions. So please do NOT spend
> bandwidth on stating your opinion now - this is about whether
> the question is right.
>...

Harald, I don't think it is quite right because I think the text
you are using as examples (both versions) does not properly
capture one aspect of the discussions.   Without proposing
specific text (and further complicating the discussion), my
understanding of where we are is that we have agreed to

	(i) unlimited copying, [re]distribution, and translation
	of full text, with attribution.
	
	(ii) nearly the same permissions for excerpts, also on
	condition of attribution.

and the debate is about rights in addition to those.  If that is
not a correct formulation so far, then I am seriously confused
and the rest of this note can probably be safely ignored.

Now, with regard to those other rights, you've made a relatively
big deal (IMO) about adapting code for use in specific contexts,
e.g., mapping from one programming language or data structure
representation to another.   I think those are non-issues and
should be dealt with by (explicitly if necessary) simply making
them special cases of "translation" above.  You should check
with Jorge, but I believe that there is some case law supporting
interpreting those types of modifications as "translation", even
without very explicit definitions.

I assert, without taking a position as to whether it is the
right thing to do, that, with a proper definition of
"translation", all of the rights needed to strictly implement a
standard are covered by "copy, extract, distribute, and
translate" or words to that effect.  

An assertion that a standard will not be implemented unless
additional rights are available appears to me to require a
separate question, noting that similar assertions have been made
about IPR options and restrictions (such as RAND on underlying
patents) that we explicitly permit.

If that separation were made, then the question you would be
asking would be about precisely the two issues where the
controversy lies, i.e., 

(i) whether unlimited modification of "code", for any purpose,
is to be permitted, and

(ii) if so, whether that is best accomplished by the IETF
obtaining and granting "outbound rights" or whether it is better
accomplished by the type of parallel licensing mechanism that
has been discussed on and off since San Diego.

      john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 05 Dec 2006 22:56:34 -0500

I wish your assertion below were true.
I do not believe it is.

At 10:10 PM 12/5/2006, John C Klensin wrote:
>  assert, without taking a position as to whether it is the

Specifically, the easy to see case is when there turns out to be a 
bug in the code in the standard.
Fixing the bug is not "translation."  (A proper translation of a 
sentence with the "wrong" word is not a sentence with the word 
corrected, but a sentence with the same error.)

Unfortunately, I doubt that is the only hole in using "translation" 
to permit the necessary code rights.

Yours,
Joel

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Dec 2006 21:14:35 -0800

At 10:10 PM -0500 12/5/06, John C Klensin wrote:
>I think those are non-issues and

I note that I have already objected to modeling this as translation,
since I think that is understood as being for the benefit of the human
reader.  If Jorge says that's what the courts say translation means
in this context, I will shut up.

>translate" or words to that effect. 

This still does not seem to include the right to run the
code, something I mentioned previously.  It also misses
some of "use its information content" that Simon has
pointed out in the past.  It is possible that this is included
in "extract", but I think that we need to go back to the
theory of describing what we want and then letting the lawyers
tell us how to say it.  I believe that current list is:

"copy, extract, distribute, and translate all text; copy, extract,
distribute, run, derive any information content needed to
perform the operations above, and modify (both to accomplish
the rights preceding and to ensure broad distribution".

If I have got that wrong, please tell me.  Assuming it is correct,
even if incomplete, if "translate" as a legal phrase subsumes
some of that, great, but I don't think we should subsume it at
this point in the discussion.
				Ted

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 06 Dec 2006 07:52:55 +0100

John,

Summary of a long note:

If you want a third alternative on the table, send text.

Longer note:

I believe that this document *has* to state things in a way that the people 
who are trying to agree upon it understand.

And I don't believe that an interpretation of "translation" to mean the 
same as "extracted, modified, and used by anyone in any way desired" is 
useful in that context.

To recap: The use cases we've been tossing about include, among others:

- Modifications to make code compile with a specific compiler suite
- Modifications to fix bugs in the code
- Modifications to make the code run faster
- Modifications to adapt the code to specific runtime contexts

These are rights that can be seen as "required to implement the standards".
THe other groups of modifications include:

- Modifications to experiment with other ways of doing things (such as 
figuring out possible candidates for a later version of the standard)

(some have argued that such activity should only be done "within the IETF"; 
others have argued that such a distinction is not a good one to make.)

And, based on the discussion of distributing code under various open-source 
licenses:

- Modification to reuse the same code for different purposes, with or 
without release of those modifications under specified conditions.

Note that reimplementation in another programming language is *not* on my 
list; I've always thought (but without benefit of legal advice) that such a 
reimplementation would be seen as a new work with new copyrights - based on 
the older code, but not a derivative work from it. You can't do things 
exactly the same way in Perl and C. (Jorge, if you read this - please 
advise).

Details...

> and the rest of this note can probably be safely ignored.

That fits my interpretation of what issue #1400 is about, yes.

> has been discussed on and off since San Diego.

I believe that the question on the table is on whether unlimited 
modification of "code" is the desire of the IETF.

The poll text as written is intended to figure out whether the IETF prefers 
that formulation, or a slightly more restrictive formulation suggested by 
Frank. If you want a third alternative on the list, please send text.

Once we have consensus on that (your (i)), we can discuss mechanisms for 
accomplishing it (your (ii)), but I don't believe that needs to be 
considered as part of #1400.

                       Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 09:42:44 +0100

> then don't put the code in an IETF document; make it available

I believe it should be up to each contributor.  The IETF tradition is
to let each author decide the license terms.  In theory, they should
be compatible with the IETF rules, but that hasn't been the running
code.

Note that neither RFC 2026 nor RFC 3978 gives you the right to extract
code from RFC and use it.  Permitting authors to grant even a
"share-alike" right to parts of RFC gives you MORE rights than before,
not less.

I suspect that in practice, many IETFers would be inclined to license
code in their contributions under a BSD or MIT license.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 10:10:35 +0100

>>    It has long been IETF policy to encourage copying and distribution
                                                       ^^^^^^^^^^^^^^^^^
> Diff mark by me, please correct me if I missed another diff.

You missed one diff here.

> It's okay, maybe a bit verbose, but less chances to get it wrong and
> split hairs.

Yup.  As instructions to lawyers, adding the word "distribute" is
probably not being verbose, but clear.  I'd even prefer if we'd more
of the terms that Ted mentioned as well:

  "copy, extract, distribute, and translate all text; copy, extract,
  distribute, run, derive any information content needed to perform
  the operations above, and modify (both to accomplish the rights
  preceding and to ensure broad distribution".

>>    without modification of excerpts from IETF Contributions and
                                                               ^^^
>>    distributing the quotes.  Such excerpts may be of any length and in
      ^^^^^^^^^^^^
>>    any context.  Translation of quotations is also to be permitted.

Here you got the diff wrong.  The text you marked is already in the
document.  I was merely adding "and distributing" here.  I marked the
real diff.

> job.

Still, I think it helps to provide examples and clarification of what
you intend.  I believe too much of the intended meaning depends on the
interpretation of the word SHOULD here.

> The SHOULD IMO only means that there can be compelling reasons to
> violate it, e.g. you can post grep- or diff-results without
> annotations, you can write "be liberal" without a link RFC 1123, and
> you can talk about "features with a high astonishment factor"
> without a link to REXX and Mike Cowlishaw - IIRC in an IAB document
> Harald wrote "traditional".
>
>>  How about:

Makes sense.  How about this:

    All such quotations SHOULD be attributed properly to the IETF and
    the IETF document from which they are taken.  That means that there
    should be a strong recommendation that all such quotations be
    attributed, but it cannot be a legal requirement for being able
    to quote a document.

/Simon

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 6 Dec 2006 12:27:14 +0100

It is perhaps implicit, but I would rather it were explicit, that there are
other types of code than those listed in both questions;  The wording has
overtones for me that this is an exclusive list.  'XML Schema' sort of
implies the W3C schema but (I keep being told) RelaxNG is much simpler and
widely used in the Transport Area and then there is XML itself, while security
documents are littered with ASN.1 that will never see the inside of a MIB.  I
know we debated earlier what is code and I cannot see a resolution of that and,
as I say, the question sort of implies that this is what code is, period.

Tom Petch

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Dec 2006 07:33:07 -0500

My best guess to the "IETF tradition" in this space is that we have 
been very unclear.
In all cases, as was noted with earlier text, any such choice would 
have to be up to the working group, not the author.

But I think that leaving it up to the working group is a bad idea, 
for several reasons:
First and foremost, it means that readers do not know what to 
expect.  Even if we gave the WG a small list of choices 9as small as 
two) we are introducing confusion.
At the same time, asking the WG to discuss such issues is putting a 
new problem on the WG's plate.  They have plenty to do, and a hard 
enough time doing it.  Getting into arguments about whether, for 
their particular situation, some particular restriction is acceptable 
(or a good idea, or a bad idea) when it is not central to their task 
is just a bad idea.

(In the following I will refer to "we conclude", meaning the WG, as 
confirmed by the IETF as a whole at last call.  That's as close as we 
can come to telling anything around here.)
If we conclude that the IETF needs major modifications republished, 
then we should require.
Correspondingly, if we conclude that it does not "need" that, then we 
should not mandate it.
Obviously, we want bugs reported.  But that isn't the same as needing 
everyone's modifications published.

Yours,
Joel M. Halpern

---

From: Mukundan R <[email-masked]>
Date: Wed, 06 Dec 2006 19:14:58 +0530

Hi all,
certain sections snipped. comments inline.

>  preceding and to ensure broad distribution".
Do we need to warn that the derivative work(in whatever form it is) need 
not be on par with the original? like what is given below in a previous 
mail of simon:

>A concrete example: I took the Punycode code in RFC 3492 and adapted
>it to the coding style I use in LibIDN.  If RFC 3492 would have been
>licensed under RFC 2026, RFC 3978 or under a license that only permits
>"translations", this would not have been possible.  Fortunately, Adam
>Costello wisely placed RFC 3492 under a liberal license:
>
>   Regarding this entire document or any portion of it (including the
>   pseudocode and C code), the author makes no guarantees and is not
>   responsible for any damage resulting from its use.  The author grants
>   irrevocable permission to anyone to use, modify, and distribute it in
>   any way that does not diminish the rights of anyone else to use,
>   modify, and distribute it, provided that redistributed derivative
>   works do not contain misleading author or version information.
>   Derivative works need not be licensed under similar terms.
>
<<end of snip>>

<<another snip>>

>    attributed, but it cannot be a legal requirement for being able
<<end of snip>>

How about indicating that only the "moral rights" are being stressed 
during this attribution?

Thanks and Regards
Mukundan

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Dec 2006 14:54:29 +0100

I thought we had agreed that "code" is text intended to be read by
a computer program.

It could be a data definition, a syntax definition, or an actual
program fragment. As far as I can see, it could be either normative
or informative, depending on the role it plays in the document.
I don't think those distinctions affect this discussion at all.
This is about the fact that for practical reasons, it may be
physically necessary to transform such code in order to make use of
it, and that is an exception to our general restriction on derivative
works outside the IETF process.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 15:53:58 +0100

> I thought we had agreed that "code" is text intended to be read by

I don't believe that is a good definition.

I have implemented several protocols that use ABNF, even multiple
times in different languages, and in no case (that I recall now) did
the computer parse the ABNF directly.  Typically, I translated the
ABNF syntax into parser code by hand.  The problem is that many common
programming languages are imperative and not declarative; it's
difficult to use ABNF directly in an imperative language.

Look at any software that deals with SMTP, e-mail, etc, and you will
find that few, for good and bad, that actually use the official ABNF
definition.  I'd be surprised if any of the more popular MUAs on the
Internet have the RFC 2822 ABNF be part of the real source code.

I do not think that the "intention" in protocols such as DIGEST-MD5 is
that the ABNF should be read by a computer program.  No
implementation, as far as I know, do that.  So the definition, at
least as phrased above, doesn't seem to work.

In general, I haven't seen any sufficiently strict definition of
"code" that is applicable to text input that doesn't lead to
corner-cases that need human interpretation sooner or later.

It is possible to give a non-exhaustive list of examples that we do
consider to be code (ABNF, ASN.1, XML, source code, pseudo-code, data
tables, ...), and also include some general discussions that help
humans to get a feel of what is code and what is not code.  That will
not help to decide whether some new notation should be considered text
or code.

I believe that separation of code and text ultimately leads to only
two situations that can work in practice:

1) An informative document lists various notations (ABNF, ASN.1, etc)
   and discusses properties that are typically present for code, to
   let humans decide what is code and what is not code, when
   interpreting what should be released under the "IETF code license".

2) Code excerpts in IETF documents are marked with special markers to
   indicate that the particular portion is considered to be "code" and
   released under the "IETF code license".

I'm not sure which I prefer, they seem to both have their own
problems.  Perhaps a combination is better than either of the choices
separately.

Rather than trying to strictly define what "code" is, I believe either
1), 2), or possibly (and perhaps even most likely) both, should be
discussed and fleshed out in more detail.

If I can dream, I'd wish we don't have to define what code is.  Look
at the problems related to code vs documentation that the Debian
GNU/Linux distribution has been discussing for years.  Currently I
believe Debian don't consider there to be any difference between code
and text, and apply the same rules for both.  I believe the IETF will
eventually arrive at the same conclusion, or that a lot of frustration
will result from any separation between the two.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 16:06:13 +0100

> My best guess to the "IETF tradition" in this space is that we have

I've not seen anyone claim that the rights which are granted to IETF
documents were not up to each author to decide.  The author's decision
can naturally be influenced by others in a working group, and by the
rules needed by the IETF to be able to publish the documents at all.

> have to be up to the working group, not the author.

Hm, can you give a reference or expand on that?

I believe that the one who wrote the text decides the rules for the
text.

It may be that a working group decides, that if an author demands
certain special license texts, the author has to be replaced by
someone else who is willing to use a different license, but that is as
far as, I believe, working group powers reach.

> But I think that leaving it up to the working group is a bad idea, for
> several reasons:
> First and foremost, it means that readers do not know what to expect.
> Even if we gave the WG a small list of choices 9as small as two) we
> are introducing confusion.
> enough time doing it.  Getting into arguments about whether, for their
> particular situation, some particular restriction is acceptable (or a
> good idea, or a bad idea) when it is not central to their task is just
> a bad idea.

Working groups that don't care about this issue don't have to.  It
only has to be discussed if someone in a WG is interested in
discussing it.  Otherwise it is up to the document author, as long as
the rights granted are within what the IETF require.

Some working groups are interested in requiring that their
specifications meet certain additional IPR restrictions, which doesn't
hold everywhere in the IETF.  Compare the DNSEXT's desire to not
consider any proposal to solve key-rollover that is encumbered by any
patent.  I believe IETF WG's should have the powers to decide things
like that, on a consensual basis, as long as the IETF have the
sufficient rights to publish documents and get things done.

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Dec 2006 16:06:08 +0100

Joel M. Halpern wrote:

> I think that leaving it up to the working group is a bad idea

Agreed, but isn't example code typically written by individual
contributors ?  The Chairs won't tolerate it if WGs waste time
with legalese.  Most examples I could name without looking are
individual contributions, not written by a committ^WWG.

> expect.  Even if we gave the WG a small list of choices (as
> small as two) we are introducing confusion.

They'll get over it, the examples in old RFCs and elsewhere use
various licenses.  For independent submissions that apparently
will stay as is.  For anything else we'd get say two standard
choices, and the exceptions for special cases.

If WGs waste time it's probably about exceptional cases, and
with only one standard choice there might be more exceptions.

Frank

---

From: "todd glassey" <[email-masked]>
Date: Wed, 6 Dec 2006 07:21:04 -0800

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 06, 2006 7:06 AM
Subject: Re: #1400 Opinion poll - question draft

> documents were not up to each author to decide.

I have - and I continue to. The rights that the author's submitted under are
controlled by the scope of the rights that the IETF grants end users. The
issue is the derivative uses language which essentially gives away and any
all uses.

Simply put, the lanaguage of the submission does not match the language of
the Granting Portions of BCP 78 and 79 IMHO. The point is blindlingly
simple - lets simply ask the question "what rights does the IETF need to
manage a standards process?" and does that mean that the Standard's use
including the rights to build and deploy a derivative of it are available to
any and all once its submitted to the IETF?

If so then the Submittor has no say in the use of their properties per se
once they are submitted to the IETF.

Todd Glassy

> The author's decision

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 16:24:46 +0100

"todd glassey" <[email-masked]> writes:

> I have - and I continue to.

Re-reading what I wrote, I see that it was badly phrased.

I meant that the tradition appears to have been that document authors
get to define their own _additional_ licenses, if they want, as long
as they give to the IETF the rights that the IETF needs.  But beyond
that, authors decide.  Looking at old RFCs, most authors don't care
about this possibility, and did not add any additional license.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Dec 2006 10:26:07 -0500

Actually, if I am reading Simon right this suggests that there is no 
need to cover ABNF in the code requirements.

If the human being has to write the code that has the same meaning, 
then the copyright on the ABNF is irrelevant to that code 
segment.  This argues that ABNF should be considered text, not 
code.  It does not argue that there is an error in the suggested 
definition of code. Copyright does not protect the idea of the ABNF, 
only the expression.

Remember that the point of allowing code to be modified is that you 
need to include the code in the program, and you may have to modify 
the code to make it work.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Dec 2006 10:32:46 -0500

Since I provoked this, I'll expand on my comment.

Authors decide whether they are willing to grant the IETF the rights 
the IETF has indicated it wants granted.
The working group then produces the document which becomes the 
standards track RFC.
As such, if there is to be any restriction or change in the outbound 
rights granted in the RFC, those rights have to be granted by the 
IETF, based on a decision by the working group.  Not by the individual.
(For individual contributions, since the only rough consensus call is 
the IETF last call, it becomes the IETF that has to make the decision.)

Now, if we have several sets of outbound rights, and if we further 
complicate our life by having several sets of inbound rights, then if 
a contributor chooses to use a more restrictive set of inbound rights 
that would restrict the options available to the working group.  This 
strongly suggests that having multiple inbound rights introduces 
significant complications.  And in the absence of multiple inbound 
rights I can see no reason whatsoever for multiple otubound rights.

Yours,
Joel M. Halpern

---

From: "todd glassey" <[email-masked]>
Date: Wed, 6 Dec 2006 07:37:41 -0800

Thanks Simon for clarifying that. Again I want to raise the question that
has ***never*** been answered and that is "What rights does the IETF need to
process a standard submission through its process to issue that
Standard???" - what is the minimum set of rights needed to accomplish this.

That sets the baseline of the submission process I think and it allows the
IETF to operate. So what more is needed then beyond that set of minimum
rights for submissions.

Todd

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Dec 2006 10:47:57 -0500

My understanding of my instructions from San Diego was to be explicit 
in the section about code rights that these were distinct from text 
rights.  And that I was to document that
a) the code rights applied to any sections of RFCs which were of the 
form X, Y, Z, W.  A specific list of cases.
b) That the trust would define a way of marking portions of RFCs as 
code so that if there were other things that the WG concluded needed 
to be treated as code (such as a RelaxNG schema if I don't include 
that in the list above), the the working group can indicate that the 
code rights apply to that section as well.

I much prefer being explicit in the right place about what the rights 
apply to, rather than putting a general description up at the front.

Yours,
Joel

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Dec 2006 16:51:52 +0100

--On 6. desember 2006 10:26 -0500 "Joel M. Halpern" <[email-masked]> 
wrote:

> Actually, if I am reading Simon right this suggests that there is no need
> to cover ABNF in the code requirements.
>
> If the human being has to write the code that has the same meaning, then
> the copyright on the ABNF is irrelevant to that code segment.  This
> argues that ABNF should be considered text, not code.  It does not argue
> that there is an error in the suggested definition of code. Copyright
> does not protect the idea of the ABNF, only the expression.
>
> Remember that the point of allowing code to be modified is that you need
> to include the code in the program, and you may have to modify the code
> to make it work.

There are tools that read ABNF.

At least one tool does something more with it than saying "it's 
syntactically valid": It generates test data.

             Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 16:59:39 +0100

> need to cover ABNF in the code requirements.

I believe ABNF should be counted as code, since it is technically
possible, and sometimes useful, to use ABNF definitions in code.
Consider ABNF validating parsers.  For another reason ABNF should be
regarded as code, see below...  My comment should be read as an
argument against Brian's definition of "code".

> then the copyright on the ABNF is irrelevant to that code segment.
> This argues that ABNF should be considered text, not code.  It does
> not argue that there is an error in the suggested definition of
> code. Copyright does not protect the idea of the ABNF, only the
> expression.
>

The ABNF is often quoted in code comments to explain a particular
state in a parser.  If there is a bug in the ABNF, you'd want to fix
that in the comment, so the comment reflect reality.  It doesn't seem
like the license for text would allow that, would it?  If not, using a
code license for ABNF higher quality implementations.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Dec 2006 11:23:56 -0500

Quoting in comments is not the question under discussion.  All sorts 
of text from RFCs is quoted in comments.  We have agreed that we are 
not giving modification rights to those excerpts.

However, Harald pointed out that there are programs that compile 
ABNF.  As such, it would need to be treated as code.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Dec 2006 17:26:49 +0100

> need to cover ABNF in the code requirements.

I'm not convinced. Someone might want to build a code generator based on
the ABNF (that is how compiler-compilers work, and think about how CORBA
works) or alternatively a protocol analyzer. I think that "intended to
be read by a computer program" covers these cases very precisely. (At the
minimum, we require the RFC Editor to check that the ABNF parses - that
is a clear intention for the text to be read by a computer program.)

> does not protect the idea of the ABNF, only the expression.

Indeed not - the idea might be protected by patent, but that's a whole
other BCP.

> to include the code in the program, and you may have to modify the code 

Exactly my point above - there are use cases of this kind for ABNF.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Dec 2006 17:30:41 +0100

Agreed. Of course, since the contributor retains copyright, he or she
can grant additional rights independently of the IETF; but it's an IETF
decision whether any statement about that appears in an IETF document.

     Brian

Joel M. Halpern wrote:
> My understanding of my instructions from San Diego was to be explicit in 
> the section about code rights that these were distinct from text 
> b) That the trust would define a way of marking portions of RFCs as code 
> so that if there were other things that the WG concluded needed to be 
> treated as code (such as a RelaxNG schema if I don't include that in the 
> list above), the the working group can indicate that the code rights 
> apply to that section as well.
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 17:45:28 +0100

> not giving modification rights to those excerpts.

Huh, that's not what I was talking about.  I am talking about where
the ABNF definitions in the RFC is used in a source code comment.  If
there is a bug in the ABNF definition, one would want to fix that in
the source code comment.  If the ABNF definition is not licensed as
code, that would not be possible.

> However, Harald pointed out that there are programs that compile ABNF.
> As such, it would need to be treated as code.

Right.  And I was giving you another argument for the same thing.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Dec 2006 17:53:16 +0100

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

> rights.

Good!  Then my suggested text to be explicit about the separation of
licenses code should be non-controversial.

> And that I was to document that

That wouldn't result in a document that explains that we've made a
decision about separating licenses for text and code.  If I understand
correctly, Harald said there was consensus that there needs to be
different licenses for text and code.  (And I'm not disputing that
consensus...)  Explicitly reflecting that decision in the document
would be useful as a trail of what the WG has discussed and decided.

/Simon

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 6 Dec 2006 13:33:00 -0800

> would be useful as a trail of what the WG has discussed and decided.

This confusion is why I keep insisting people should license "original works
of authorship" to IETF for open standards rather than some imprecise IETF
invention purporting to distinguish between text and code. (See [1] and
[2].)

It is a waste of time to change code (for whatever open source or
proprietary reason!) embodying an IETF standard and then not be able to
change the IETF-published text that explains that code. Placing this
unnecessary burden on recipients of IETF's open standards documentation is a
penalty that serves no valid purpose yet identified and endorsed by this WG.

When any of us give our copyrighted (and perhaps patented) works to IETF in
collaboration with others for the creation of industry standards, we
shouldn't want people sitting around in working groups trying to divine what
the difference is between code and text in IETF draft specifications, and
then waste more time documenting such hair-splitting in the published
official IETF specifications themselves, and even more time within the
companies that implement those specifications trying to decide what they can
use and what they can't.

To the extent that this suggestion to distinguish code from text came up for
a vote before, but is still pending, I vote -1. 

/Larry Rosen

[1] 17 USC 102, first sentence, at
http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_00000102----000-.
html.

[2] AFL 3.0, first sentence, at www.rosenlaw.com/AFL3.0.htm. 

> From: Simon Josefsson [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2006 8:53 AM
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: Suggested text for text vs code
>

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 6 Dec 2006 18:36:52 -0500

Hi Larry,

This sounds similar to the reasoning I have for opposing
author-specific, and especially viral, licensing in IETF documents. 

I don't want WGs and companies trying to implement standards to be
forced to waste time trying to divine which piece of a document has a
author-specific (possibly viral) license associated with it, and I
certainly do not want contribution of a code snippet to allow the
author of that snippet to impose viral licensing for the whole IETF
document. 

dbh

> From: Lawrence Rosen [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 4:33 PM
> To: [email-masked]
> Subject: RE: Suggested text for text vs code
> 
> > >> >> sense.  Recording that earlier decision, which this
discussion
> > assume,

---

From: "todd glassey" <[email-masked]>
Date: Wed, 6 Dec 2006 16:57:49 -0800

Companies have real lawyers who can generally read so since there is no
assurance of the IETF to the adopters of the IP rights in the matter, they
already have to do this level of diligence.

Todd Glassey

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 6 Dec 2006 17:32:29 -0800

> author-specific, and especially viral, licensing in IETF documents.

I don't know what you mean by "author-specific" licensing. 

So-called "viral" licenses (I prefer the term "reciprocal" as being less
associated with disease states), even though they are wonderful for
encouraging free software and discouraging free riders, are also
incompatible with open standards. That is because open standards must be
available for implementation in proprietary software also.

If someone here is proposing allowing reciprocal licenses for either IETF
contributions or IETF out-licensing, I vote -1 on that too.

/Larry

> From: David B Harrington [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2006 3:37 PM
> To: [email-masked]; [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 07 Dec 2006 07:36:49 +0100

--On onsdag, desember 06, 2006 10:47:57 -0500 "Joel M. Halpern" 
<[email-masked]> wrote:

> the section about code rights that these were distinct from text rights.
> a) the code rights applied to any sections of RFCs which were of the form
> X, Y, Z, W.  A specific list of cases.

Actually, the instructions from San Diego were (quoting from the minutes):

> Stefan Wenger: Why not both in the draft?
> JK: Do both as appropriate (use rules by default but can mark if no clear)
> TH: Both case: If somebody didn't put something in that matched the rules
> and didn't mark it then it isn't code.
> JH: thinks both s a good thing. Avoids judgment call on borderline cases.
> Only have to maintain the rules.. can put in code markers (as an author)
> Concensus to go with both.

The "list of decisions to be confirmed" says:

> What's the appropriate definition for "code" vs "non-code"? 3 alternatives
> - Markers in the text: 1
> - Rules to apply: 0
> - Hybrid approach: Rules, with markers that can be used if desired: 17

When I was there, I interpreted this as "maintain a document with a set of 
rules about what is considered code" (initial set would be in the RFC). So 
if the initial set included DTDs but excluded RelaxNG, the first RFC to use 
it would use markers, but it would be included in the list in a later 
version.

But that's not 100% clear from quotes above, so it's worth discussing.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Dec 2006 08:45:07 +0100

> contributions or IETF out-licensing, I vote -1 on that too.

The point is, as far as I understand, that the IETF rules should
_permit_ authors to use code licensed under a share-alike license as
examples in documents.

Of course, having code available under a more liberal license,
e.g. the BSD license, is preferable.  Several code examples in RFCs
use similar licenses, and I expect that to be the norm.

However, I believe it doesn't make sense to decrease the quality of a
specification by removing code that is only available under, say, the
GPL.  That works against the goals of the IETF of having
specifications implemented widely and quickly.  Some code is better
than no code in a document.

Code in older RFCs, licensed under a license that nobody can use
legally, is still helpful when developing a new implementation.  The
license is unfortunate, and I don't believe we should permit it in
future RFCs, but not being able to use widely available GPL'ed code as
examples seems like a mistake to me.

I'll vote to permit reciprocal licenses, but will suggest that when
there is a choice, a BSD-licensed implementation should be preferred.
It is for the cases where there isn't a choice a GPL implementation
would be useful to be able to include.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2006 13:19:25 +0100

...
> than no code in a document.

The specific problem with GPL is that if GPLed code is included
in a standard, any implementor who cannot accept the risk
of GPL contamination in his or her code is going to have a heck
of a time understanding the standard without inadvertently reading
the GPL code. It might be necessary to have a colleague outside the
clean room blank out those sections of the RFC first. I think
we should avoid that.

As already observed, it can be avoided by contributing the code
to the IETF process directly instead of via a GPLed document.
Nobody is forced to put their code under GPL before contributing
it to the IETF.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Dec 2006 13:44:03 +0100

Brian E Carpenter <[email-masked]> writes:

> the GPL code.

If you are required to read code to understand a standard, I'd say the
standard is already too inadequate for further consideration, and
should never be published anyway.  I believe we should assume that
standards continue to have high quality.

Further, it seems you are talking about a patent situation.  There is
no problem in reading and running GPL'd code and trying it out against
your proprietary or BSD licensed code.  It is only if you distribute
the GPLed code in a product that the reciprocal terms of GPL apply.

> It might be necessary to have a colleague outside the clean room
> blank out those sections of the RFC first. I think we should avoid
> that.

Sure, but that is not the case.  That's the situation with patents,
but not with copyrights.

> Nobody is forced to put their code under GPL before contributing

Sure, and I absolutely agree.  What I'm talking about is when that
situation did not happen and was not feasible.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Dec 2006 13:52:06 +0100

> situation did not happen and was not feasible.

What I'm referring to here may not be obvious to everyone, so here is
a example from my own experience.

There is RFC 3548 on base64 encoding.  There were _many_ requests to
include sample code in the document, to make it easier to verify
correctness of implementations, and to provide more details, for those
who are interested.

I created a 'bis-document, now RFC 4648, and asked contributors to
supply example code.  Few of the people who requested that example
code was present sent me any code, which is to be expected.  I can
only recall that people sent me pointers to existing code in various
free software.

I looked at those implementations, and in the ~10 implementations that
I surveyed, I found one bug or another that made the code violate the
specification.  Including such code would make the situation worse.

Instead I created my own implementation based on parts from the best
implementations that I could find.  I chose the GPL for the license,
because nobody paid me to work on this, and I find the GPL the most
appropriate for work that I do on my spare time.  That choice allowed
me to base my work on other GPL'd code as well, which was another
motivation for me to use the GPL.  That also enabled me to get code
review and improvements from C89 and POSIX portability experts around
the world, since the code was included in the "gnulib" portability
library.

The draft contained the code, and it went through the IETF process,
but there were some objections.  Still, it passed IETF last calls and
IESG review unchanged.

The IAB rejected Ted's request to make a process-variation to be able
to include the code, but it was denied.  I removed the code, and the
document was published.

The net result?  The document didn't fulfil the primary motivation for
developing the revised document, and was delayed considerably.

People now have to chase a URL to my own home page and download the
code instead, and the problems with that solution should be familiar
to everyone.

I believe this is a good example of how the IETF rules here worked
against the goal of making the Internet work better (i.e., RFC 3935).
People now have less easy access to an implementation of an important
protocol, which is referenced by many other protocols, than what they
would have if the code was included in RFC 4648.  The end result is
disappointing to the number of people who requested sample code.

/Simon

PS.  If someone wants to donate an implementation under a BSD license
that follows RFC 4648, I'll happily include it in RFC 4648bis.  (Don't
forget to validate the implementation against the specification first,
most widely used implementations are broken in one way or another...)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2006 14:13:42 +0100

Simon,

Code contamination is a problem. If rewritten code accidentally
contains a few lines the same as the original, lawyers can
get active. It has happened.

     Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Dec 2006 15:25:49 +0100

> the world, since the code was included in the "gnulib" portability
Query: What was your reason to not dual-license the code?

If "based on" means "copied pieces from", I understand it, but this term 
can have multiple meanings.

Harald

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Dec 2006 15:59:18 +0100

> Query: What was your reason to not dual-license the code?

As far as I can tell, even in retrospect, it would not have made a big
difference.  Technically, my code had to be removed due to section 5.4
of RFC 3978.  Code licensed under, e.g., the BSD license would fail
the same test.  That is how I recall that I understood the problem at
the time, at least, but my memory may be fading, and I'm really trying
to forget everything about it, since it was a disappointing
experience.

Btw, I posted draft-josefsson-ipr-notices-00.txt regarding this, see
old threads on this list and the tracker issue 1282.

> If "based on" means "copied pieces from", I understand it, but this
> term can have multiple meanings.

Yes, "based on" meant "copied pieces from" in this example.  Further,
the improvements by others were under the same license.

/Simon

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 7 Dec 2006 10:05:29 -0800

Simon,

> _permit_ authors to use code licensed under a share-alike license as

Far more important is the goal that IETF specifications, even the
"examples," can be implemented with equal rights and conditions in both
proprietary and open source software and documentation. 

As you know, I'm a strong supporter of open source. But when it comes to
*open standards*, I believe we have a broader responsibility to be free for
all--without a share-alike license that disadvantages proprietary software.

That is why, for a patent covenant, I support the Microsoft Open
Specification Promise as the clearest expression yet of this principle. IETF
should demand similar covenants today from other patent-owning companies for
free implementation of patented technology in IETF industry standards--in
both open source and proprietary software.

And that is also why, for a copyright grant, I recommend a license such as
AFL 3.0, which grants a license to everyone (for both text and code!)
conditioned only upon fair attribution and the retention of defensive rights
in the event of patent or copyright litigation. 

Of course, when someone implements an IETF specification, he or she can
*then* choose to distribute that implementation under a share-alike license.
I'll cheer that decision! I may even recommend, as do Linux standards
organizations and other open source projects, that the GPL-licensed software
become a model implementation against which others are judged. :-) But
that's very different from contaminating IETF specifications with code or
text that some companies can't or won't be able to use.

/Larry Rosen

> Sent: Wednesday, December 06, 2006 11:45 PM
> To: [email-masked]
> Cc: [email-masked]