On Jul 21, 2009, at 10:27 AM, 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 am not a lawyer, but I don't see how legally we could do anything
but (d).
Regards
Marshall
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
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Trustees mailing list
Trustees(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/trustees
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf