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:
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: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 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 BSDlicence. Suppose now that the Trust now changes the licence they use to theGPL. (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 proposedchange makes sense. If I were building a product, however, I would be very wary of usingany code whose licence might change after I've shipped my code. A_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf