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

Harald Alvestrand harald at alvestrand.no
Tue Jul 21 09:28:27 PDT 2009

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).
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.
>     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.
See above. But as usual, IANAL, I just have opinions.


More information about the rfc-interest mailing list