[rfc-i] [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

Joel M. Halpern jmh at joelhalpern.com
Tue Jul 21 07:52:30 PDT 2009

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 

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


Andrew Sullivan wrote:
> On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote:
>> 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.
> 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

More information about the rfc-interest mailing list