Subject: Rationale for Proposed TLP Revisions

From: IETF Administrative Director <[email-masked]>
Date: Sun, 19 Jul 2009 14:11:35 -0700 (PDT)

The IETF Trustees invited community comments on the proposed revisions to
the "Legal Provisions Relating to IETF Documents" (TLP) policy on 23 June
2009.  The proposed revisions are in rtf, pdf and doc formats and located
at: http://trustee.ietf.org/policyandprocedures.html under Draft Policies
and Procedures for IETF Documents.

On 18 July, in a reply to Subject:  Proposed Revisions to the IETF Trust
Legal Provisions (TLP), the IETF Trust Chair said: The rationale for the
remaining summary of proposed changes will be sent in a separate email.

This is a summary of the proposed revisions to the TLP by section with
explanations, 
where needed:

2.f -- this new language describes the conditions under which the IETF  
Trust will assume licensing and copyright responsibility for IAB, IRTF  
and Independent Stream submissions, should the managers of those  
streams request that it do so.

Explanation:  The IETF Trust was approached by representatives of the
IAB, IRTF and RFC Editor, who asked the Trust to assume the role of
"license administrator" for their respective document streams.  The
Trust is happy to do so as part of its role supporting the IETF.  The
language included in new Section 2.f of the TLP describes the procedure
by which the Trust proposes to handle documents from these non-IETF
streams.

4.c -- clarifies that the BSD License may not be applied to Code  
Components that come from IETF Documents as to which the Contributor  
has prohibited the making of derivative works.

Explanation:  An IETF participant noticed that, under the existing TLP,
the broad BSD
adoption language might "trump" a contributor's prohibition on the right
to make derivative works of his/her contribution.  The new language
clarifies that the BSD license will not apply if the contributor has
specified that no derivative works may be made of his/her contribution.

4.e -- this new section clarifies the legend requirements for Code  
Components that are used in software under the BSD License. 
In short, the user must include the full BSD License text or a shorter
pointer  to it (which is set forth in Section 6.d)

Explanation:  The issue of the appropriate BSD License language to
include in Code
Components extracted from IETF documents has been discussed extensively
within the IESG.  The proposed TLP language is intended to be consistent
with the IESG's latest guidance language, and allows the user of IETF
Code to include either the full BSD license language (about 15 lines of
text), or a short "pointer" to the BSD language (about 4 lines). 

6 -- the language regarding placement of legends on IETF Documents has  
been clarified.  Placement on the "first page" is no longer required,  
and authority for placement of the legends is  with the RFC Editor and  
IESG.

Explanation:  Self-explanatory

6.a - the words "to IETF" have been removed, to enable submission to  
IAB, IRFT and other streams.

Explanation:  Self-explanatory

6.b -- a new sentence has been added to the legend that must be placed  
on all IETF Documents, pointing out the BSD License requirements  
described in 4.e above and emphasizing that code in IETF Documents  
comes without any warranty, as described in the BSD License.

Explanation:  See 4.e above

6.d -- the BSD legend/pointer described in 4.e above

Explanation:  See 4.e above

Comments on the proposed revisions to the TLP are welcomed.

Ray
Trustee

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jul 2009 11:09:57 +0200

Harald Alvestrand wrote:
> ...

Hi,

I'm trying to understand whether this change affects me.

So...

1) Many specs I'm editor of contain ABNF. Does it need to be labeled as 
code component (I believe not).

2) These specs also collect all ABNF fragments into an appendix, 
containing the collected ABNF. Does that appendix need to contain the 
BSD license text (I believe not, but heard from colleagues that their 
docs are blocked because they do not).

3) If I *extract* ABNF from these documents (such as for the purpose of 
generating an input file for an ABNF parser), do I need to include the 
BSD license text? If so, can somebody explain how to do that given the 
constraints of the ABNF syntax?

Best regards, Julian

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jul 2009 10:02:38 +0200

Apologies for this being a month late.

> Explanation:  See 4.e above
The text added, which is intended to be placed on all IETF documents 
(internet-drafts and RFCs), is:

> Code Components
> extracted from this document must include BSD License text as 
> described in Section 4.e of
> the TLP and are provided without warranty as described in the BSD License.

I object to this change.

The reason is this:

- The RFCs are intended to be permanent (as in "forever").
- The purpose of the "incoming/outgoing split" was to make sure the 
Trust had the tools it needed to fix any errors made, or to respond to 
changed circumstances, by changing the rights granted under "outgoing".
- The BSD license is a specific license text, and there is no guarantee 
that there won't be new circumstances that warrant generic licensing 
under a different license in the future.

Thus, this change limits the ability of the Trust to respond to future 
changes; if it ever decides (as an example) to use the Apache License 
instead of the BSD license because some court has found the BSD text to 
be objectionable in some manner, this will lead to all documents 
published with this text to be misleading.

(As an example of changed circumstances - the Wikimedia Foundation just 
changed its licensing terms from GPL to a Creative Commons license - 
this required some fancy footwork to make it seem legal, even though a 
large majority of contributors agreed that it was the right thing to do. 
I don't want to see that kind of trouble in the IETF.)

If the text added instead read:

  Code Components extracted from this document must include license text
  as described in the TLP and are provided without warranty as described in
  the TLP license provisions

I would have no objection. This preserves the Trust's ability to change 
provisions.

                          Harald Alvestrand

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jul 2009 14:20:42 +0200

> constraints of the ABNF syntax?

Explanation: for some reason I thought that the ABNF syntax only allows 
comments that are attached to an ABNF rule; but it appears that I was 
confused.

So please ignore the third point.

BR, Julian

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Jul 2009 08:25:55 -0400

--On Monday, July 20, 2009 14:20 +0200 Julian Reschke
<[email-masked]> wrote:

> Julian Reschke wrote:
>> ...
>> 3) If I *extract* ABNF from these documents (such as for the
>> purpose of  generating an input file for an ABNF parser), do
>> I need to include the  BSD license text? If so, can somebody
>> explain how to do that given the  constraints of the ABNF
>> syntax?
>> ...
> 
> Explanation: for some reason I thought that the ABNF syntax
> only allows comments that are attached to an ABNF rule; but it
> appears that I was confused.

Independent of that, considering any sequence of ABNF statements
as necessarily "code" goes far beyond the intent of the IPR WG
as I, at least, understood it.   If you, as author, want to
identify it as "code", that is your perogative, but this is
about copyright and not patents and, at least IMO, metalanguage,
metasyntax, pseudo-code, etc., are not intrinsically code in the
sense that the WG discussed and intended it.

   john

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jul 2009 08:41:04 -0400

I think that the alternate text proposed by Harald meets the current 
need without constraining the future.

Russ

>>Components that are used in software under the BSD License. In 
>>short, the user must include the full BSD License text or a shorter
>Trust had the tools it needed to fix any errors made, or to respond 
>to changed circumstances, by changing the rights granted under "outgoing".
>- The BSD license is a specific license text, and there is no 
>guarantee that there won't be new circumstances that warrant generic 
>licensing under a different license in the future.
>
>Thus, this change limits the ability of the Trust to respond to 
>future changes; if it ever decides (as an example) to use the Apache 
>License instead of the BSD license because some court has found the 
>BSD text to be objectionable in some manner, this will lead to all 
>documents published with this text to be misleading.
>
>(As an example of changed circumstances - the Wikimedia Foundation 
>just changed its licensing terms from GPL to a Creative Commons 
>license - this required some fancy footwork to make it seem legal, 
>even though a large majority of contributors agreed that it was the 
>right thing to do. I don't want to see that kind of trouble in the IETF.)
>
>I would have no objection. This preserves the Trust's ability to 
>change provisions.
>
>                          Harald Alvestrand
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jul 2009 12:23:26 -0400

>sense that the WG discussed and intended it.

I agree this is about copyright (not patents).  However, your 
interpretation of "code" does not align with the words in the 
RFC.  See Section 4.3 of RFC 5377:

    IETF Contributions often include components intended to be directly
    processed by a computer.  Examples of these include ABNF definitions,
    XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
    MIBs, ASN.1, and classical programming code.  ...

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Jul 2009 12:35:43 -0400

You are correct.  I remembered the text differently, but should
have checked.  I apologize.

   john

--On Monday, July 20, 2009 12:23 -0400 Russ Housley
<[email-masked]> wrote:

>> >> 3) If I *extract* ABNF from these documents (such as for
>> >> the purpose of  generating an input file for an ABNF
>> >> parser), do I need to include the  BSD license text? If
>> >> so, can somebody explain how to do that given the
>> > only allows comments that are attached to an ABNF rule; but
>> > it appears that I was confused.
>> 
>> Independent of that, considering any sequence of ABNF
>> statements as necessarily "code" goes far beyond the intent
>> of the IPR WG as I, at least, understood it.   If you, as
>> author, want to identify it as "code", that is your
>> perogative, but this is about copyright and not patents and,
>> at least IMO, metalanguage, metasyntax, pseudo-code, etc.,
>> are not intrinsically code in the sense that the WG discussed
>> and intended it.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jul 2009 19:26:07 +0200

Julian Reschke wrote:
> 1) Many specs I'm editor of contain ABNF. Does it need to be labeled 
> as code component (I believe not).
In my understanding, all ABNF is code by definition (included in the 
Trust's list of "things considered code"), so no.
> docs are blocked because they do not).
I believe it would be silly to make it contain the BSD license.
Some people on the IESG seem to think that the IESG has made such a 
statement; one of my WGs has a couple of documents that are blocked 
until this is resolved.
>
> 3) If I *extract* ABNF from these documents (such as for the purpose 
> of generating an input file for an ABNF parser), do I need to include 
> the BSD license text? If so, can somebody explain how to do that given 
> the constraints of the ABNF syntax?
; is a fine character. A block of comment should be fine.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jul 2009 19:28:00 +0200

> sense that the WG discussed and intended it.
ABNF was specifically used as an example of "code" in the WG discussions.

RFC 5377 section 4.3:

   IETF Contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, and classical programming code.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 20 Jul 2009 14:19:24 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Monday, July 20, 2009 8:41 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Trustees] Objection to reworked para 6.d (Re: 
> Rationale for Proposed TLP Revisions)
> 

I also think that Harald's alternate language would work.  The sentence
in question was inserted to offer guidance to users of code, not to
comply with any specific legal requirement of the BSD License.  If
others think that Harald's formulation would be more helpful (and more
future-proof), then it is a reasonable approach to adopt.

> _______________________________________________
> Trustees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trustees
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 14:32:04 -0400

On Mon, Jul 20, 2009 at 02:19:24PM -0400, Contreras, Jorge wrote:
> 
> I also think that Harald's alternate language would work.  

Is it a problem that this means that shipping code's license could
change at some time in the future?  Are there practical issues to that
if (for instance) the Trust decided to change from BSD to some
copyleft-like license?  Note that I'm thinking of shipping, and not
already deployed, code.  So one develops based on the BSD-licensed
code, and then the license changes and you ship another instance.  Is
this a problem?  I'm assuming not, because the original licensee still
has the code under the original terms.  But I thought it wouldn't hurt
to ask.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Jul 2009 14:56:01 -0400

I don't think it means that.
Rather, what it does is the RfC says "the code must include whatever 
license the trust document says.
When the code is produced, that link is dereferenced, the license is 
determined, and the license is inserted in the code.

No, no one can reasonably produce code under an unspecified license. 
What this does is allow the trust to change, in a forward-going fashion, 
what license code produced from the RFC must use.  Otherwise, once the 
RFC came out, everyone must forever use BSD, even if the community 
decided that everyone should henceforth use ABC.

Thus, it is a later binding, but not so late that the code user does not 
know what he is committing to when that person produces software using 
our code.

Joel

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 15:25:24 -0400

> determined, and the license is inserted in the code.

Ok.  So is the point then just not to have to issue a new RFC if the
Trust decides they want a different license?  I.e. is that the
"future-proofing" that the proposed change is supposed to provide?

If so, in light of the other comments people are making about how the
Trust appears to be rather more activist than some people find
congenial (I am reserving my opinion on that topic), I'm not sure the
proposed change is a good one.  If the Trust needed to change the
license, there would be two reasons to do it, I think:

    1.  The community wants the change.

    2.  External forces (say, legal precedents) cause the
    currently-selected license to be the wrong one.

But both of those cases seem to me to be the sort of thing that
requires some community input and some rough consensus, no?  If so,
then what would be hard about writing a new RFC that captured this
update, and publishing it the way of the usual RFC process?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 20 Jul 2009 16:44:13 -0400

> "future-proofing" that the proposed change is supposed to provide?

I apologize if my unfortunate use of the term "future-proofing" has
caused angst.  But I was referring to the proposal made by Harald
Alvestrand, as a member of the community, not a proposal made by the
Trust.  Harald's proposal should not be taken as an indication of the
Trust's intentions.  I believe that Russ and I were merely saying that
Harald's proposal seemed reasonable.  If other members of the community
disagree, then that's fine too.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Jul 2009 16:53:48 -0400

I think Harald's suggestion makes sense and should be implemented.
Joel

---

From: Barry Leiba <[email-masked]>
Date: Mon, 20 Jul 2009 17:20:18 -0400

> I think Harald's suggestion makes sense and should be implemented.

I agree.

Barry

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2009 17:51:35 -0400

On 2009-07-20, at 16:44, "Contreras, Jorge" <[email-masked] 
 > wrote:

> disagree, then that's fine too.

No, no angst over the term. I find the idea fetching, in principle,  
too, but I can't see how the proposed change does what is needed. If  
the goal is to be able to allow the trust to relicence the code as it  
sees fit, parallel with its ability to cope with the license of rfc  
text, then I get the purpose of the change. If this is just to avoid  
the bureaucracy of publishing a new rfc then no, sorry, I don't think  
that's a good idea. The bureaucratic hurdles are there to find  
consensus, and I see no reason to make this a special case. If we  
think rfc production is too bureaucratic, let's fix that.

Andrew Sullivan
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 08:57:01 +0200

> update, and publishing it the way of the usual RFC process?
I agree completely that any licensing change needs solid community input 
and rough consensus (as well as being legal). That's entirely orthogonal 
to the binding time issue (I think). My worry is the logistics of 
executing the change.

We have two possibilities:

1 - the update consists of revisions of *every single RFC* that 
references the BSD license
2 - some RFCs continue to carry the BSD license, even while the "real" 
current license is different.

1 seems like a logistical nightmare. 2 seems confusing to me.

             Harald

---

From: Robert Elz <[email-masked]>
Date: Tue, 21 Jul 2009 17:20:31 +0700

Date:        Tue, 21 Jul 2009 08:57:01 +0200
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | We have two possibilities:
  | 
  | 1 - the update consists of revisions of *every single RFC* that 
  | references the BSD license
  | 2 - some RFCs continue to carry the BSD license, even while the "real" 
  | current license is different.

Harald,

what you're anticipating there is absurd, if an RFC gets issued containing
code with the BSD licence, then that is the licence that code, in that RFC
will have forevermore, nothing can change that - and nothing should change
that, nothng the trustees or community can do can ever change that - only
the rights holder (author) of the code can cause it to be offered with
some different licence.    Any system where it even looked as if it were
possible for anyone to simply alter the licence under which code that
had previously been published became available would be a disaster.

The issue is, and must be, entirely the licence under which code must be
offered in order to be published - that the IETF can decide - no code in an
RFC unless it has this licence on it (or one of those licences, or whatever
the community wants).  There is no obligation to publish code if it doesn't
meet our requirements, but once we have published it, and the IETF and code
authors have agreed upon licence terms for the code, the IETF (or trustees)
cannot simplly arbitrarily change the licence.

So, it seems to me as if what you're trying to accomplish is just absurd,
we don't want to, or need to, go back and change old RFCs, the licence on
code in those RFCs is, and always will be, whatever it says in that RFC
(which doesn't stop the author also offering the same code, via other
methods, with different licence terms - nor from one of those other
methods being via the IETF, either via the web page, or in a new RFC.

Given that, and the desire for considered community input, rather than
arbitrary trustee action, I think the proposed wording is better than
your proposed alternative.

On he latter, Joel at least interpreted your original message as giving the
TLP a status where ...

[email-masked] said:
  |  Otherwise, once the  RFC came out, everyone must forever use BSD, even if
  | the community  decided that everyone should henceforth use ABC.

which is impossible, nothing that we ever do can never be changed in the
future (as it applies in the further future) - if we were to decide later
that ABC is better than BSD, the TLP can be changed, just as they are now.

The only question currently is the method by which that should happen, by
an explicit community review process (just as now) or by simple trustee
action, simply publishing a changed requirement.  The original wording is
the former, Harald's proposal suggests the latter.

kre

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 10:27:40 -0400

> 1 seems like a logistical nightmare. 2 seems confusing to me.

Ok, this is what I was trying to understand.  What you are proposing
is that the licence on the code in the RFC can change
restrospectively, by virtue of the Trust changing the licence they
select.

This scenario is exactly what inspired my first question, then.
Imagine I have a product, and it is shipping.  It has code taken from
an RFC.  The original RFC was published when the Trust used the BSD
licence.  Therefore, as far as I know, the code I used is under BSD
licence.  

Suppose now that the Trust now changes the licence they use to the
GPL.  (I know, I know, this won't happen, &c.  But there's nothing to
prevent it, as far as I can tell, except community consensus.  I don't
know what that might be in the future.)  If I understand what you
want, I think there are four possibilities:

    a.  The product I have already shipped is now suddenly covered by
    the GPL.  It may be in violation of the licence therefore.

    b.  The prodict I have already shipped does not change, but
    products I ship after the Trust changes policy are covered under
    the new rules.  So my shipped product is BSD, and my unshipped
    stuff is suddenly GPL (possibly forcing me to change my product,
    or its licence).

    c.  The code I used remains under the BSD because of the date I
    used it, but new uses of that code are under GPL (so my
    competitors would have to have a different licence, or version 2
    of my product might have to have a different licence).

    d.  The date the RFC was published binds the licence, so that the
    terms on the code embedded in the RFC change.  This is equivalent
    to your option (2), I think, and you say its undesirable.

I argue that compared to (a-c), (d) is a big win.  If (d) is right,
however, your option (1) isn't a problem: the RFCs that are already
published don't need a new licence in them, because they stick to the
old one.  Therefore, the new text only gives the Trust a way around
getting a new RFC published with the new licence explicitly selected
by community consensus.  I don't see the reason to provide that short
cut.  If, however, you think (a-c) are preferable, then your proposed
change makes sense.  

If I were building a product, however, I would be very wary of using
any code whose licence might change after I've shipped my code.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jul 2009 10:52:30 -0400

NO, I believe he is suggesting something slightly different.

First, realize that the structure does not include any license statement 
with the code in the RFC.  That is covered by the boilerplate.

Second, the issue being addressed is the instruction to someone who 
extracts the code from the RFC and uses it.  We are trying to allow them 
to do this.  The instruction, as proposed by the trust says that we will 
put in the RFC text saying "when you extract this, put the BSD license, 
as defined by the trust at ..."

Clearly, any change in IETF policy can not change the text in an RFC. 
Nor can it change what someone has done historically complying with that 
text.

The issue is that we may discover that we would prefer that folks use a 
different license going forward.  There are two ways to allow for that.
1) As proposed by Harald, we can just have the text in the RFC say "use 
what the trust says."  If the trust changes what it says, then 
extractors thereafter have to comply with the new IETF policy.  (We 
assume, for this discussion, that the trust statements and IETF policy 
align.)
2) Or, the trust can keep a chronological log of required license 
statements, and when a change is needed record "after date X, use 
license Y", and provide new boilerplate to be used in I-Ds and RFCs 
after date X.

Mostly, it does not make a big difference.  The historical records have 
to exist in any case.
But given the pain that gratuitous boilerplate changes introduce, I 
would prefer not to need such for an easily foreseeable situation.

Yours,
Joel

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Jul 2009 10:59:06 -0400

>    to your option (2), I think, and you say its undesirable.

I am not a lawyer, but I don't see how legally we could do anything  
but (d).

Regards
Marshall

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 11:49:14 -0400

> Clearly, any change in IETF policy can not change the text in an RFC.  

Only if by "the text" you exclude all the implicitly included text
that is the resolution of a pointer in "the text" strictly construed.
If the actual text says, "This code is covered by the licence
currently published by the Trust," then the real meaning of that text
changes depending on $current_licence.  This sort of referential issue
is what Russell is talking about when discussing the present King of
France and whether His Imaginary Majesty is bald.  I'd prefer not to
relive that portion of my undergrad education every time someone
decides a licence change would be good.

> Nor can it change what someone has done historically complying with that  

Sure.

> different license going forward.  

That is the scenario (c) that I described.  I have shipping derivative
code under BSD, but new derivative code is forced to be under GPL, for
instance.  (I find that to be a pretty absurd situation to be trying
to cause, but it appears to be what is wanted by some.)  This means
that my competitor can't use the derived code under the same terms I
can, and presumably that new interoperating products of my own, using
the same code, can't be released under the same licence as I used the
first time.  Is that really what we want?

The position I outline in (d) is what we might call the early-binding
option: the Trust can't change the licence terms of code in an RFC
after the RFC is published, period.  If there is a desire to change
the licence, a new RFC is needed (and, of course, the obsoleted RFC's
code is still under its original licence).  From my point of view,
this is the clearest alternative.  Everything else sounds to me like a
good way to generate work for corporate counsel in figuring out
exactly what licence is in effect on any given day, but not a good way
to ensure that geeks can get their jobs done with a minimum of fuss
(which is, I assume, a major part of the ultimate goal).

> would prefer not to need such for an easily foreseeable situation.

Surely the right answer, then, is to minimise gratuitous boilerplate
changes, which can be partly achieved by saying, "You need a new RFC
to change the licence terms."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 18:28:27 +0200

>     of my product might have to have a different licence).
I think this is the version that applies, with one difference that matters.

Under the BSD license, you can ALSO give copies of the copy you took 
from the RFC to anyone at any time, and they will have the right of 
modification, but not the right to publish the code without the BSD 
license text - that is, the BSD license is a sublicenseable license.

Effectively, the code will be available under all licenses that the 
Trust has ever licensed stuff under between the time of publication and 
the present time; if a more restrictive license is used (perish the 
thought!), you have the right to fork the code, and distribute the 
forked code under the BSD license in perpetuity.
> any code whose licence might change after I've shipped my code.
See above. But as usual, IANAL, I just have opinions.

                       Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jul 2009 18:40:52 +0200

> had previously been published became available would be a disaster.
Robert,

I'm afraid that your perception disagrees with the structure that RFC 
5378 set up. The Trust has enough rights to license code under a license 
of its choice, and has currently chosen to use the BSD license.

The authors may *in addition* license the code under the BSD license, 
the GPL license, or any other license they feel like using, and there's 
no way the Trust can stop them from doing that. But neither can the 
authors restrict the Trust's ability to license the code.

It may be a disaster, but it's been in that state since November 2008.

                  Harald

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Jul 2009 12:27:04 -0400

I think Andrew makes a lot of sense. I really can't envision a situation where 
the IETF would want to change licence terms en masse, given the impact Andrew 
demonstrates on deployed or ready-to-deploy product.

---

From: David Morris <[email-masked]>
Date: Tue, 21 Jul 2009 11:52:17 -0700 (PDT)

What are we smoking? The license can't be changed after the RFC is 
published. At least, it can't be made more restrictive. I can't imagine 
the chaos if one must prove your right to follow a particular set of 
license rules based on proving exactly when you extracted code from a 
published RFC. Particularily as companies merge and split and due 
diligence is performed, etc.

Secondly, we need to consider the folks contributing the code ... they 
have a right to expect a particular set of license conditions will apply 
to their contribution. I can imagine being willing to release code under 
BSD or GPL but not either based on my personal philosophy, etc.

Dave Morris

On Tue, 21 Jul 2009, Joel M. Halpern wrote:

> First, realize that the structure does not include any license statement with 
> the code in the RFC.  That is covered by the boilerplate.
>
> Second, the issue being addressed is the instruction to someone who extracts 
> the code from the RFC and uses it.  We are trying to allow them to do this. 
> The instruction, as proposed by the trust says that we will put in the RFC 
> text saying "when you extract this, put the BSD license, as defined by the 
> trust at ..."
>
> Clearly, any change in IETF policy can not change the text in an RFC. Nor can 
> it change what someone has done historically complying with that text.
>
> 1) As proposed by Harald, we can just have the text in the RFC say "use what 
> the trust says."  If the trust changes what it says, then extractors 
> thereafter have to comply with the new IETF policy.  (We assume, for this 
> discussion, that the trust statements and IETF policy align.)
> 2) Or, the trust can keep a chronological log of required license statements, 
> and when a change is needed record "after date X, use license Y", and provide 
> new boilerplate to be used in I-Ds and RFCs after date X.
>
> Mostly, it does not make a big difference.  The historical records have to 
> exist in any case.
> But given the pain that gratuitous boilerplate changes introduce, I would 
> prefer not to need such for an easily foreseeable situation.
>
> Yours,
> Joel
>
>
> Andrew Sullivan wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jul 2009 15:07:15 -0400

The folks contributing the code have a different constraint.  They ahve 
agreed separately to let the IETF have all rights to do anything we want 
with the source, including giving it to anyone else, and giving them any 
rights we want.
(Note, this is copyright related rights only.  This has nothing to do 
with patent rights.)

The text we are discussing is only about what license we require other 
folks to put on code they extract from an RFC.
And, even more specifically, it is only about how we describe that 
license in the event that we want to change forward-going extractors. 
The difference in the wording has no effect on folks after they have 
extracted the code and complied with the instructions.

Joel

David Morris wrote:
>> First, realize that the structure does not include any license 
>> statement with the code in the RFC.  That is covered by the boilerplate.
>>
>> extracts the code from the RFC and uses it.  We are trying to allow 
>> them to do this. The instruction, as proposed by the trust says that 
>> we will put in the RFC text saying "when you extract this, put the BSD 
>> license, as defined by the trust at ..."
>>
>> Nor can it change what someone has done historically complying with 
>> that text.
>>
>> The issue is that we may discover that we would prefer that folks use 
>> a different license going forward.  There are two ways to allow for that.
>> 1) As proposed by Harald, we can just have the text in the RFC say 
>> "use what the trust says."  If the trust changes what it says, then 
>> Mostly, it does not make a big difference.  The historical records 
>> have to exist in any case.
>>>> 2 - some RFCs continue to carry the BSD license, even while the 
>>>> "real" current license is different.
>>>>
>>> licence. Suppose now that the Trust now changes the licence they use 
>>> to the
>>> change makes sense. If I were building a product, however, I would be 
>>> very wary of using

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 15:18:58 -0400

> license in the event that we want to change forward-going extractors.  

I think it is exactly this premise that some are wondering about.  Is
there any circumstance under which it is reasonable to try to change
the licence of a piece of code once that code has already been
released?

If so, then Harald's text makes sense, because otherwise his worry
about needing to re-publish all those covered RFCs is reasonable.

But some of us are wondering whether there is any circumstance in
which such an effort would be reasonable anyway.  As Harald points out
elsewhere, the code is already released under its first licence, so it
is not like it's possible to change the terms really.  To me,
therefore, this just seems like a way to make lawyers nervous without
adding any additional benefit.

If there is a real use case for wanting "to change forward-going
extractors", I don't know what it is.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Morris <[email-masked]>
Date: Tue, 21 Jul 2009 12:23:58 -0700 (PDT)

On Tue, 21 Jul 2009, Joel M. Halpern wrote:

>
> The text we are discussing is only about what license we require other folks 
> to put on code they extract from an RFC.
> And, even more specifically, it is only about how we describe that license in 
> the event that we want to change forward-going extractors. The difference in 
> the wording has no effect on folks after they have extracted the code and 
> complied with the instructions.

But that it might change adds a burden of being able to identify the point 
in time that the code was extracted and hence applicable license. I've 
worked in enough small development organizations to believe that to be a 
potentially significant problem.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jul 2009 15:35:31 -0400

Yes, I believe that there is a real world example.
Without creating needless FUD, let me say that someone did recently 
point out possible implications of the BSD license that we did not 
intend.  Fairly awkward implications.
1) It may well be possible to fix that with a clarification.
2) But suppose that it were harder to fix, and that it were discovered 4 
months from now.

At that point we need to fix the license to match our intentions.  And 
since that is really a matter that affects even RFCs that already came 
out, we would like to cover those without needing to re-issue them. 
There is nothing we can do, for good or ill, about folks who already 
used the earlier license.  But we can fix things going forward.

I believe that the trust's intention was for the BSD license to be as 
close as possible to the IETF RFC statement.  But things happen.  (In 
the worst case, courts say "those words don't mean what you think they 
mean.)

Since this is only about the rights we grant to folks in our documents, 
not about the rights folks grant to us, it seems simplest to write 
things in a way that gives us the flexibility we should have.

Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jul 2009 15:38:04 -0400

No matter what, we have to be clear in our records about when things 
change, and folks who extract things need to somehow record when they 
did so.  That is actually true no matter what, since once the code is 
extracted, without some backtrace there is no way verify things.  I 
would expect folks extracting large pieces of code to mark the RFC they 
got it from, and when they took it.  But that is up to them.  The IETF 
ought not mandate any more details than we absolutely have to about how 
the code is extracted / used.

Joel

David Morris wrote:
> But that it might change adds a burden of being able to identify the 
> point in time that the code was extracted and hence applicable license. 
> I've worked in enough small development organizations to believe that to 
> be a potentially significant problem.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2009 16:36:21 -0400

On Tue, Jul 21, 2009 at 03:35:31PM -0400, Joel M. Halpern wrote:

> At that point we need to fix the license to match our intentions.  

No, we need to change the licence to match the intentions _or_ accept
that the damage was done, too bad, and move on.

Note that the latter approach is actually the compromise that's been
worked out in respect of some other rights and explicit granting of
them: instead of forcing contributors to make absurd claims about
having explicitly obtained rights throughout history, we give them a
way to say, "Maybe I haven't got all the rights.  Be careful about
relicencing this."  

> used the earlier license.  But we can fix things going forward.

Harald argued earlier that you _can't_ fix things once you've released
something, at least in any more-restrictive way: once you've released
the code under some licence, whoever has the code under that licence
automatically can use those terms.  Since we've been talking about the
BSD licence, then anyone can republish any of the code under BSD
terms.  So you might as well just leave the licence on the
already-published things alone, and just change the rules for new
publication.  This has the happy property of not opening up some giant
legal sinkhole where the exact same code embedded in the exact same
document gets a different licence depending on the time of day someone
downloads it, and from whom.

> things in a way that gives us the flexibility we should have.

I am claiming that you cannot write things in a way that gives you the
ability to do what you want (which is, in effect, to undo an action
the results of which you don't find congenial).  I moreover note that
some people are expressing concerns about the way the Trust is
operating, and the proposed change moves one more thing from
"community agrees on a rule change" to "Trust informs community about
a change of rules".  And therefore, since I claim you can't get the
benefit you want anyway, there's no reason to make the change.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jul 2009 08:25:54 +0700

Date:        Tue, 21 Jul 2009 18:40:52 +0200
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm afraid that your perception disagrees with the structure that RFC 
  | 5378 set up.

I was misunderstanding what's going on, Joel has been educating me off list...

But while my reasoning changes slightly, my conclusion does not.

  | The Trust has enough rights to license code under a license 
  | of its choice, and has currently chosen to use the BSD license.

I think we can agree that the trust (the IETF) cannot give away more
rights than it has obtained from the contributor (however much they are,
and if that's "everything related to copyright" that's fine).

I can think of no reason why the trust (IETF) should ever offer less
than what the contributor has allowed - that would be entirely contrary
to the purposes for which we need licences from the contributor in the
first place - the aim is to make sure that the code is available with
as few restrictions as possible, having the trust add restrictive licence
terms would be counter productive (regardless of what those terms are).

If all that's reasonable, then it follows that licence in == licence out,
and while it is possible that might be change from time to time, the
change must be to the licence in first, and that then means that the
licence out change affects only those RFCs published after the change,
one earlier must still be on the old terms (if the change was broadening
the licence to the IETF, then no earlier submission by anyone would be
broader in the new way, and so the outgoing licence could not be the new
broader form, if the change is to narrow the rights given to the IETF,
that will necessarily narrow what the IETF can grant users of the code,
but there's no reason it should restrict the rights granted under older
submissions, that were published with a broader grant to the IETF.

So, I remain fairly convinced that there's no need at all to ever
make (or pretend to make) any change which would ever require updating all
past RFCs, a change should only ever affect future publications.

kre

ps; there is no assumption in anything above that every RFC must necessarily
have the exact same licence terms, negotiation with contributors might
sometimes be reasonable, nothing above is altered by this, what matters is
that the licence granted to the IETF for any particular code segment should
be exactly the licence the IETF grants to users of that code.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Jul 2009 08:32:38 +0200

> terms would be counter productive (regardless of what those terms are).
The working group's non-consensus on this point is documented in section 
4.4 of RFC 5377:

4.4.  Rights Granted for Use of Text from IETF Contributions

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF Contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the Contribution.

> submissions, that were published with a broader grant to the IETF.
The "RFC 5378" license to the trust allows, for instance, the Trust to 
grant the right of copying small snippets of code without attaching the 
full BSD license to them. The current TLP does not give that right.

Incoming and outgoing rights for code are currently different.
> past RFCs, a change should only ever affect future publications.
I'm fairly convinced that there will come a time when we need to 
relicense text that was previously licensed by the Trust in a way that 
is more liberal than the current text of the TLP allows for (while 
remaining within the scope of rights granted to the trust).

That's why I yell so much on this matter.

                   Harald

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jul 2009 18:22:47 +0700

Date:        Wed, 22 Jul 2009 08:32:38 +0200
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

I don't want to say much more on this issue, I suspect enough has
been said now, but just one final (from me) point ...

  | The working group's non-consensus on this point is documented in section 
  | 4.4 of RFC 5377:
  | 
  | 4.4.  Rights Granted for Use of Text from IETF Contributions
  | 
  |    There is no consensus at this time to permit the use of text from
  |    RFCs in contexts where the right to modify the text is required.  The
  |    authors of IETF Contributions may be able and willing to grant such
  |    rights independently of the rights they have granted to the IETF by
  |    making the Contribution.

I have no idea how to interpret that - one meaning might be that
contributors of code to the IETF can assume that the IETF will not
grant rights that allow modification of the text.   If that's how it
works out, then once again, whatever you think other parts of the
RFC say, contributors can rely upon that, and then the IETF cannot
later change its mind, and allow modification - the contributor gave
the code based upon the assumption that would not be permitted.

On the other hand, if we're all convinced that the contributor must be
giving the IETF the rights to do whatever it likes with the contribution,
including permitting modifications - then the IETF should be (and by
referring to a BSD like licence, in fact, is) allowing people do do
whatever they want with code in an RFC - which includes modifying it.

After all "there is no consensus to permit" also can be written with
the exact same meaning as "there is no consensus not to permit", that's
what "no consensus" means (though authors sometimes try to describe a
point where there's no agreement at all to make it look as if the result
of that should be what they think the outcome should be - which is what
the paragraph you quoted looks like to me.   That is, we couldn't get
people to agree to prohibit modifications, so we'll write a paragraph
that makes it look like the base position is to prohibit that, and then
make it clear that we didn't agree that distribution with modification
rights should be allowed - everyone will just conclude that it isn't
allowed...

That's bogus, and it looks to me (by use of the BSD licence, which if
the advertising clause were removed, which it should be (and is in the
current version of the BSD licence) about as liberal as it is possible to be.
That is, I cannot see it is possible to be more liberal (advertising
excepted, and that's a minor point) than the BSD licence which is being
specified.

Making it truly difficult to change makes it harder for the distribution
to be made more restricted, which looks to me to be just about the only
way it is possible to move (and if the advertising clause has been, or can
be quicky, removed from the IETF's version of the BSD licence, then we're
about as unrestricted as it is possible to get).

On the other hand, if the IETF's "BSD licence" is currently prohibiting
modifications, then it clearly is not a BSD licence at all (so you'd be
right, that name ought to be removed as being misleading) - and that ought
to be fixed, as quoted above (being read carefully) we have no consensus
to prohibit distribution with modifications permitted (unless the
contributors are not granting that right, of course) so we may as well
just allow modifications.

kre

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Jul 2009 13:12:40 -0400

> The working group's non-consensus on this point is documented in section 

   ... of historical interest only, IMHO...
 
> full BSD license to them. The current TLP does not give that right.

   This is getting awfully deep into IANAL territory.

   Since IANAL and I don't want to play one on TV, let me shift the focus
away from whether that distinction entails a difference -- to the question
of whether opening a discussion of such details tends to clarify or
confuse.

   IMHO, it tends to confuse far more than it clarifies.

> Incoming and outgoing rights for code are currently different.

   Likewise, discussing that difference, IMHO, tends to confuse far more
than it clarifies.

> remaining within the scope of rights granted to the trust).

   May I suggest that many of us don't share this conviction?

   May I also suggest that opening such a question (where the IPR WG
couldn't reach consensus) doesn't seem terribly likely to find any quick
consensus?

   May I suggest that punting such a question to some future group of
Trustees to decide for us is even less likely to find a quick consensus?

   IETF participants admittedly tend towards paranoia. We should accept
this and avoid things which feed their paranoia. We should especially
(IMHO) avoid things that feed their paranoia with exactly the same food
as a previous round.

   Please, Harald, do us a favor and accept the "BSD" license as "good
enough" for the "forseeable" future. Yes, we can all imagine scenarios
where something else would be "better", but we'd like to put something
to bed here so that RFC publication can stop stumbling over "license"
questions.

> That's why I yell so much on this matter.

   Your opinion is noted. You have our permission to say, "I told you so!"
when/if we're proven wrong.

--
John Leslie <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2009 11:40:24 +1200

This may seem like a small comment but I believe it is important.
We know that we have an issue to resolve collectively, namely the
IPR regimes for non-IETF stream documents. We probably agree that
(as the revised TLP says or implies) it is for each stream individually
to decide whether it accepts none, some or all of the IETF rules
and the IETF Trust's legal provisions.

However, Clause 2.f.i of the draft revised TLP includes the
statement "The IETF Trust does not determine the legal rules that
apply to documents in Alternate Streams."

I would like to see that changed to "The IETF Trust does not
*currently* determine the legal rules that apply to documents in
Alternate Streams."

Rationale: some of the other streams might choose to request the
Trust to do so. (Or they might not; I don't know.)

I have re-read the "Purpose" clause of the Trust Agreement, and
it has the flexibility to allow the Trust to do this, if so
requested and agreed. We shouldn't remove that flexibility.

There are other issues in this area, but John Klensin's appeal
already addresses them.

Regards
   Brian Carpenter