Subject: Simplified BSD License for Code Components and linux GPL kernel

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Feb 2010 19:46:38 +0100

Hi IPR WG,

I have interest in licensing and IPR of the technology in RFCs.

I recently stumbled on the RPL protocol WG item draft (in the RoLL WG,
Routing Over Low power and Lossy networks) and worried about "Code
Components" in the boilerplate.

Could one implement RPL in a linux kernel?

Knowing that linux kernel is mostly GPL, avoiding BSD, and that I see
the word BSD in the bolierplate.

If I may be missing something - sorry,

Alex

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Feb 2010 17:54:24 -0500

Alex:

The intent was to find a license that would permit the code to be used 
as-in in any environment with attribution.  If that goal has not been 
achieved, please explain the details of the problem.

Russ

On 2/10/2010 1:46 PM, Alexandru Petrescu wrote:
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Feb 2010 14:20:47 +1300

Of course, this only applies if you are actually cutting and pasting
code from the RFC. You can write new code to implement the RFC under
any license you want.

    Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 00:49:34 -0500

> If I may be missing something - sorry,

Code components on IETF WG documents are licensed by the IETF Trust  
using the "Simplified" BSD license. Whether
or not that license is suitable with the Linux Kernel is not for the  
Trust or the IETF to decide. I believe, however, that you are correct  
and that Linus Torvalds does not approve of the BSD license for the  
Linux kernel.

Here is a long email thread involving him on this issue that might  
provide some background.

http://kerneltrap.org/node/8382

I would also look at sites such as this http://kernelnewbies.org/ and  
start asking around on the various mailing lists devoted to the Linux  
kernel. If you find a definitive answer on the use of IETF code  
components in the Linux kernel, please post it here on this list.

Regards
Marshall

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Feb 2010 08:47:28 +0100

On Feb 11, 2010, at 06:49, Marshall Eubanks wrote:

> Linus Torvalds does not approve of the BSD license for the Linux kernel.

That is not quite what Linus said.
He said that he doesn't want to license Linux under the BSD license.
This is relatively straightforward, as this would mean giving up rights that (he and many others think) have turned out to be beneficial for the project.

But this has no bearing on whether the TLP-prescribed handling of Code Components is compatible with introducing these into Linux.  IANAL, but there is overwhelming evidence that there is no problem at all with that.

(The discussion originated in the ROLL WG aroung the current RPL draft, which does not even have Code Components, so the whole issue is moot.)

Part of the confusion comes from using the "BSD" name for a number of different licenses: The original BSD license (more specifically, its advertising clause) is generally considered incompatible with the GPL, so we would have a problem if we had adopted that.  But we are using what we call the Simplified BSD license, which is compatible with the GPL, so we are all set.

An interesting tangent would be discussing whether the same considerations that made Linus choose GPL would make GPL more appropriate for Code Components: i.e., the desire to get back modified versions of the code.  I think the potential benefits, if any, are demonstrably very small for the specific area of Code Components, and the complications of using a license that restricts the use of the Code Components (in more ways than our Simplified BSD license does) overwhelmingly make GPL a very bad idea for them.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 09:44:26 +0100

Le 10/02/2010 23:54, Russ Housley a écrit :
> Alex:
>
> The intent was to find a license that would permit the code to be
> used as-in in any environment with attribution. If that goal has not
> been achieved, please explain the details of the problem.

Hi Russ, thanks for asking.

I see many problems with it: linux kernel GPL is but one.  I can
enumerate: export control restrictions on security code, IPR and open
source, many half-open half-closed cooperative projects prefer GPL (not
BSD), modifications of existing GPL code must be GPL, and more.  I am
not sure which one you want me to describe.

My surprise is that I see a license in the boilerplate at all.  I am
used to RFCs which don't impose a license, and let the implementer chose
the software license.

For example, SHA1 RFC3174 does contain C code ready to be copypasted in
a new program, create a new license (non-BSD), license which allows one
to abide to the local export control rules as well as those of a
multi-national company.

The "AS-IS" wording is tough to translate and understand legally in
other language than English, IMHO.

Alex

>> I recently stumbled on the RPL protocol WG item draft (in the RoLL
>> WG, Routing Over Low power and Lossy networks) and worried about
>> "Code Components" in the boilerplate.
>>
>> Knowing that linux kernel is mostly GPL, avoiding BSD, and that I
>> see the word BSD in the bolierplate.
>>
>> _______________________________________________ Ipr-wg mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ipr-wg
>>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 09:52:52 +0100

> code from the RFC. You can write new code to implement the RFC under

Brian - yes, the "BSD" tag seems to apply only if I copypaste C code
from the RFC.  I do appreciate a lot the RFCs containing C code.  Let me
say I always prefer to copypase from the RFC because I am sure it is
more reliable than what I could write first.

But this "BSD" also prevents me to suggest example C code to RFC-to-be
authors, because my C code is a modification of a pure GPL code.  For
example, I want to write an extension to Router Advertisement - I
implement it as extension to linux radvd, which is pure GPL, which can't
become BSD when it arrives in the RFC-to-be.

This means to me that I can not suggest C code to RFCs-to-be.  Which is
a loss to the RFCs.

I also wanted to ask: what does it mean "Code Components extracted from
this document" present in the boilerplate, if there are no Code
Components in the document?

Is for example the name of some constant such as timer value, supposed
to be used in a macro, or the value in the IANA table apply as Code
Component?

Alex

>> used as-in in any environment with attribution.  If that goal has
>> not been achieved, please explain the details of the problem.
>>
>> Russ
>>
>>> I recently stumbled on the RPL protocol WG item draft (in the
>>> RoLL WG, Routing Over Low power and Lossy networks) and worried
>>> about "Code Components" in the boilerplate.
>>>
>>> _______________________________________________ Ipr-wg mailing
>>> list [email-masked]
>> _______________________________________________ Ipr-wg mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/ipr-wg
>>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 09:54:39 +0100

Le 11/02/2010 06:49, Marshall Eubanks a écrit :
> using the "Simplified" BSD license. Whether or not that license is
> suitable with the Linux Kernel is not for the Trust or the IETF to
> decide. I believe, however, that you are correct and that Linus
> Torvalds does not approve of the BSD license for the Linux kernel.
>
> I would also look at sites such as this http://kernelnewbies.org/
> and start asking around on the various mailing lists devoted to the
> Linux kernel. If you find a definitive answer on the use of IETF
> code components in the Linux kernel, please post it here on this
> list.

Hi Marshall,

Thanks for the references.  I will stay open looking around for various
cases.

I also prefer to report first-hand experience.

Alex

> Regards Marshall

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 10:02:51 +0100

Le 11/02/2010 08:47, Carsten Bormann a écrit :
[...]
> (The discussion originated in the ROLL WG aroung the current RPL
> draft, which does not even have Code Components, so the whole issue
> is moot.)

Carsten - if there are no Code Components in the RPL document then why
does it say "Code Components extracted from this document..."?  Is this
unnecessary bells and whistles?

Is a value in a IANA table a Code Component or not?  RPL does have such
IANA values.

MUST RPL deliver a MIB (now or later) or not?  Will that MIB be tagged
BSD or not?

To me, the moot point is to impose BSD in the boilerplate of all RFCs.

Sorry if too direct,

Alex

>
> Part of the confusion comes from using the "BSD" name for a number of
> different licenses: The original BSD license (more specifically, its
> advertising clause) is generally considered incompatible with the
> GPL, so we would have a problem if we had adopted that.  But we are
> using what we call the Simplified BSD license, which is compatible
> with the GPL, so we are all set.
>
> An interesting tangent would be discussing whether the same
> considerations that made Linus choose GPL would make GPL more
> appropriate for Code Components: i.e., the desire to get back
> modified versions of the code.  I think the potential benefits, if
> any, are demonstrably very small for the specific area of Code
> Components, and the complications of using a license that restricts
> the use of the Code Components (in more ways than our Simplified BSD
>  license does) overwhelmingly make GPL a very bad idea for them.
>
> Gruesse, Carsten
>

---

From: SM <[email-masked]>
Date: Thu, 11 Feb 2010 02:08:44 -0800

Hi Alexandru,
>Components in the document?

You can read the Code Components list at 
http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt

Boilerplates are standard formulation and are used for 
uniformity.  If there are no code components in a RFC, there won't be 
any code component to extract.

>to be used in a macro, or the value in the IANA table apply as Code

If the Trust Legal Provisions are enforced for the IANA table, that 
defeats the purpose of having a IANA registry.

Regards,
-sm

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 11:55:18 +0100

Le 11/02/2010 11:08, SM a écrit :
> Hi Alexandru, At 00:52 11-02-10, Alexandru Petrescu wrote:
>> I also wanted to ask: what does it mean "Code Components extracted
>> from this document" present in the boilerplate, if there are no
>> Code Components in the document?
>
That includes "tables of values" as Code Components.  There are several
tables of values in the RPL (a protocol in RoLL WG) document, IANA
tables being among them.

> Boilerplates are standard formulation and are used for uniformity. If
>  there are no code components in a RFC, there won't be any code
> component to extract.

I don't like this kind of uniformity.  I want things to make sense.  It
makes no sense to talk "Code Components" if there are no Code
Components.  No benefit to anybody - only risks of confusion added for
those who implement this particular RFC-to-be and legal misunderstandings.

Who benefits from this uniformity of putting "Code Components" text on
RFCs not having Code Components?

>> Is for example the name of some constant such as timer value,
>> supposed to be used in a macro, or the value in the IANA table
>> apply as Code Component?
>

The the Trust Legal Provisions should say they are not enforced on IANA
tables.

Alex

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 07:40:47 -0500

Dear Carsten;

Thanks for clarifying this.

Regards
Marshall

On Feb 11, 2010, at 2:47 AM, Carsten Bormann wrote:

> This is relatively straightforward, as this would mean giving up  
> rights that (he and many others think) have turned out to be  
> beneficial for the project.
>
> But this has no bearing on whether the TLP-prescribed handling of  
> Code Components is compatible with introducing these into Linux.   
> IANAL, but there is overwhelming evidence that there is no problem  
> at all with that.
>
> Part of the confusion comes from using the "BSD" name for a number  
> of different licenses: The original BSD license (more specifically,  
> its advertising clause) is generally considered incompatible with  
> the GPL, so we would have a problem if we had adopted that.  But we  
> are using what we call the Simplified BSD license, which is  
> compatible with the GPL, so we are all set.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 07:49:48 -0500

> RFCs not having Code Components?

There appears to be no deterministic means of determining with  
certainty whether or not a given RFC has
code components, and so no certain means of deciding whether or not to  
have that text.

I would, in fact, turn this on its head. If you want to use part of an  
RFC as code (whether or not it is marked as code, and whether or not  
it is a form of code listed in the Code-Components-List), you have a  
BSD license for it. Why is that flexibility a bad thing ?

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 08:02:23 -0500

On Feb 11, 2010, at 5:08 AM, SM wrote:

>> from
> You can read the Code Components list at http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt
>
> Boilerplates are standard formulation and are used for uniformity.   
> If there are no code components in a RFC, there won't be any code  
> component to extract.
>
>> supposed

Can you describe your concerns here ? IANA did not complain about the  
TLP, and to my recollection no one else
has brought this up.

Regards
Marshall

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 14:12:38 +0100

Le 11/02/2010 13:49, Marshall Eubanks a écrit :
>>>> I also wanted to ask: what does it mean "Code Components
>>>> extracted from this document" present in the boilerplate, if
>>>> there are no Code Components in the document?
>>>
>> That includes "tables of values" as Code Components. There are
>> several tables of values in the RPL (a protocol in RoLL WG)
>> document, IANA tables being among them.
>>
>>> uniformity. If there are no code components in a RFC, there
>>> won't be any code component to extract.
>>
>> I don't like this kind of uniformity. I want things to make sense.
>> It makes no sense to talk "Code Components" if there are no Code
>> Components. No benefit to anybody - only risks of confusion added
>> for those who implement this particular RFC-to-be and legal
>> misunderstandings.
>>
>> Who benefits from this uniformity of putting "Code Components"
>> text on RFCs not having Code Components?
>
> certainty whether or not a given RFC has code components, and so no
> certain means of deciding whether or not to have that text.
>
> I would, in fact, turn this on its head. If you want to use part of
> an RFC as code (whether or not it is marked as code, and whether or
> not it is a form of code listed in the Code-Components-List), you
> have a BSD license for it. Why is that flexibility a bad thing ?

Let me turn this back on its feet.

Assume (a plausible case) I have some RPL GPLed C code that I want to
submit to this RPL RFC-to-be.  Being GPL it can't be stripped off of its
license.  Or, the draft says BSD.

Does IETF want my code to become a mixture of BSD-GPL just because I
want it into the RFC-to-be?

I think the main authors of the original GPL code will not accept my
code modifications integrated into that code's main trunk if it's tagged
BSD in an RFC.

I as developper want to maintain full control of the license of the code
I write.  This was the case in the past with vairous RFCs.  I don't
understand why it has to change.

Yours,

Alex

>>> If the Trust Legal Provisions are enforced for the IANA table,
>>> that defeats the purpose of having a IANA registry.
>>
>> The the Trust Legal Provisions should say they are not enforced on
>> IANA tables.
>>
>> Alex
>>

---

From: Scott Brim <[email-masked]>
Date: Thu, 11 Feb 2010 08:20:03 -0500

> used to RFCs which don't impose a license, and let the implementer chose

When you subscribed to the ROLL mailing list, and when you register for
each meeting you clicked an "OK" saying that you agreed to the terms of
the "Note Well", including the terms of RFC 5378.  Have you read it?
Among other things, you agreed to putting the boilerplate on RFCs.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 14:33:23 +0100

Le 11/02/2010 14:20, Scott Brim a écrit :
>> My surprise is that I see a license in the boilerplate at all.  I
>> am used to RFCs which don't impose a license, and let the
>> implementer chose the software license.
>
> When you subscribed to the ROLL mailing list, and when you register
> for each meeting you clicked an "OK" saying that you agreed to the
> terms of the "Note Well", including the terms of RFC 5378.  Have you
>  read it? Among other things, you agreed to putting the boilerplate
> on RFCs.

I agreed to the boilerplate which was valid at the time when I
subscribed, ago.  It was not including the default "BSD" wording.
Then I got resubscribed (when list moved) without being asked whether I
agree with the new "BSD" scheme.

I am used to see new notices from various IETF-related bodies about
change in procedure.  But nobody says _what_ exactly has changed.

(Witness the recent 1-week change in the "Guidelines to Authors".  Yes,
  we were informed in ROLL there were new Guidelines.  But what changed
  precisely?  Witness the "Abstract-first policy (previously Abstract
  came _after_ the Copyright notice) - this is valid only for _some_
  drafts, no uniformity).

And no, I haven't registered for meetings lately.  (and no, I will not
come to the next IETF - and I some times congratulate myself for not
doing so because I don't want IETF to equate BSD).  This no-BSD
decision was made for me long ago and I could live with it at IETF.  But
now with this default BSD policy it's very tough - it requires more
legal work.  Were it to be a GPL-default policy then I would have been
happier.

Yours,

Alex

---

From: Scott Brim <[email-masked]>
Date: Thu, 11 Feb 2010 10:46:06 -0500

> agree with the new "BSD" scheme.

Are you saying that you are participating in the IETF while not agreeing
to the rules for doing so?  If I were a WG chair where you were active,
I would unsubscribe you and have you resubscribe.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2010 11:30:29 -0500

Actually, after due analysis, the IPR working concluded (by rough 
conensus, there were those who disagreed), that it would actually be bad 
for the IETF for code included in IETF RFCs to be subject to GPL 
restrictions.  That would create significant contamination difficulties 
for several classes of users of RFCs.  (Our goal is that the code should 
be useable by anyone, including teachers, open source implementors, and 
commercial implementors, without restriction or special conditions.)

It is possible even the BSD license places too many restrictions.  But 
permitting GPL code was discussed, and was agreed not to be a goal.

Yours,
Joel M. Halpern

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 17:42:20 +0100

Le 11/02/2010 16:46, Scott Brim a écrit :
>>>> My surprise is that I see a license in the boilerplate at all.
>>>> I am used to RFCs which don't impose a license, and let the
>>> When you subscribed to the ROLL mailing list, and when you
>>> register for each meeting you clicked an "OK" saying that you
>>> agreed to the terms of the "Note Well", including the terms of
>>> RFC 5378.  Have you read it? Among other things, you agreed to
>>> putting the boilerplate on RFCs.
>>
>> Then I got resubscribed (when list moved) without being asked
>> whether I agree with the new "BSD" scheme.
>
> Are you saying that you are participating in the IETF while not
> agreeing to the rules for doing so?  If I were a WG chair where you
> were active, I would unsubscribe you and have you resubscribe.

Interesting...  I will go back asking.

I hope this Note Well won't block me when posting about no-BSD.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 17:52:43 +0100

Le 11/02/2010 17:30, Joel M. Halpern a écrit :
> conensus, there were those who disagreed), that it would actually be
> bad for the IETF for code included in IETF RFCs to be subject to GPL
> restrictions. That would create significant contamination
> difficulties for several classes of users of RFCs. (Our goal is that
> the code should be useable by anyone, including teachers, open source
> implementors, and commercial implementors, without restriction or
> special conditions.)

Well - the best freedom is given when no statement is made - no
licensing.  Let the implementer decide the license.

> It is possible even the BSD license places too many restrictions.
> But permitting GPL code was discussed, and was agreed not to be a
> goal.

Well thank you for the clarification.  It is good that rough consensus
was used to decide.

But I doubt the extent of impact of using a BSD-derivative was fully
reckoned when the decision was made.

Why there's no possibility to submit an IETF draft which has no "BSD" 
derivative license, no GPL license, no software license at all.

Alex

> Yours, Joel M. Halpern
>> Assume (a plausible case) I have some RPL GPLed C code that I want
>> to submit to this RPL RFC-to-be. Being GPL it can't be stripped off
>> of its license. Or, the draft says BSD.
>>
>> Does IETF want my code to become a mixture of BSD-GPL just because
>> I want it into the RFC-to-be?
>>
>> I think the main authors of the original GPL code will not accept
>> my code modifications integrated into that code's main trunk if
>> it's tagged BSD in an RFC.
>>
>> I as developper want to maintain full control of the license of
>> the code I write. This was the case in the past with vairous RFCs.
>> I don't understand why it has to change.
>>
>> Yours,
>>
>> Alex
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 11 Feb 2010 11:52:55 -0500

> I hope this Note Well won't block me when posting about no-BSD.

I don't think it should, but you should be participating with knowledge
of the rules.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 17:56:26 +0100

Le 11/02/2010 17:52, Scott Brim a écrit :
> I don't think it should, but you should be participating with
> knowledge of the rules.

Scott - I agree there should be rules, and they are ok in general for me
at IETF.

But this particular BSD point itches me too much to stay silent about it.

I realize I can't submit an IETF draft without the "BSD" word in it.  I
find that to be extreme.  Or a big mistake.  Sorry for saying so.

Alex

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2010 12:06:59 -0500

Let me split your comment into three pieces.
On the one hand, we want only one set of licensing terms for code in 
RFCs and I-Ds (at any one time at least.)  So I would not want to offer 
"options."

On the other hand, as far as I can tell, having no license text at all, 
but a statement in our TLP license terms that code components can be 
used by anyone for any purpose, would seem to be effective and meet the 
goals.  (I have checked with a lawyer that this suffices when it applies 
to the whole document.)

On the third hand, the trustees have worked very hard to get us as far 
as they ahve.  The various folks who have to work with the boilerplate 
have already complained that we change it too fast.  As such, I am 
inclined to leave well enough alone unless the BSD license actually 
causes us difficulty.

Yours,
Joel

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 18:36:49 +0100

Le 11/02/2010 18:06, Joel M. Halpern a écrit :
> Let me split your comment into three pieces. On the one hand, we
> want only one set of licensing terms for code in RFCs and I-Ds (at
> any one time at least.) So I would not want to offer "options."

I beg to differ, obviously.

> On the other hand, as far as I can tell, having no license text at
> all, but a statement in our TLP license terms that code components
> can be used by anyone for any purpose, would seem to be effective
> and meet the goals. (I have checked with a lawyer that this suffices
> when it applies to the whole document.)

No - it's not sufficient.  It doesn't require (as GPL does) to make the
source available upon request.  It doesn't forbid the hiding of the
source code.  I.e. the Code Components in that RFC could be marked
<deleted>.  Potentially an RFC with hidden parts :-(

I should say first and foremost that we tempt (in the spirit) to be as
compatible and with as many licenses as possible.  Give _them_ priority
and let the mandatory-BSD aspect come after.  E.g. if the linux kernel
GPL requires stripping the RFC's license then be ok with it; if no
particular requirement outside IETF only then float the RFC BSD license
everywhere.

RFCs exist in such a rich ecosystem of languages, rules, governments,
super-governments, security control, time - all mean different things to
different lawyers.

Stating BSD upfront reduces RFCs' applicability, customers, implementers.

> On the third hand, the trustees have worked very hard to get us as
> far as they ahve. The various folks who have to work with the
> boilerplate have already complained that we change it too fast. As
> such, I am inclined to leave well enough alone unless the BSD
> license actually causes us difficulty.

Well yes, me too I find it changes too fast, and it's not good.
Guidelines to Authors changed 3 times in a week, difficult to follow.

I can come to this later.

Alex

> Yours, Joel
>> Why there's no possibility to submit an IETF draft which has no
>> "BSD" derivative license, no GPL license, no software license at
>> all.
>>
>> Alex
>>
>>>

---

From: SM <[email-masked]>
Date: Thu, 11 Feb 2010 10:30:37 -0800

Hi Marshall,
>TLP, and to my recollection no one else

I don't have any strong concerns about the TLP.  The IETF Trust has 
done its best.  What follows should not be read as legal advice.  It 
is not an argument to support any change.

The code components list, effective on 23 April 2009, lists "tables 
of values" as a code component.  The finer details require a reading 
of the RFC and the TLP.  Changes to a protocol parameter registry 
generally goes in the IANA Considerations section.  It's not up to me 
to determine whether the assigned values are code components.  If the 
assigned values fall under the Simplified BSD License, they can be modified.

    "All assigned values are to be published and made available free
     of any charges and free of any constraints relating to further
     redistribution, with the caveat that the assignment information
     may not be modified in any redistributed copy."

The rationale for that is probably the same as for IETF change 
control.  That makes the "text" copyright a better fit.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Feb 2010 14:20:42 -0500

The point of picking a well known license was to avoid issues of newbies 
trying to interpret the license test.  This one is supposed to be well 
studied.

Russ

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 14:26:53 -0500

On Feb 11, 2010, at 1:30 PM, SM wrote:

> generally goes in the IANA Considerations section.  It's not up to  
> me to determine whether the assigned values are code components.  If  
> the assigned values fall under the Simplified BSD License, they can  
> be modified.
>

OK, thanks for this. We might want to put IANA registries and other  
parameter values as not suitable for code components in some future TLP.

However, just because you can change something in code (I want my  
protocol to be protocol # 1 !) doesn't mean it would be wise to do so.  
The same thing could be said for many indisputable code components. If  
RFC-FOO says that (say)

RTT = t_reception - t_transmission

and I use that as code, the BSD license does mean that I can change  
"-" to "+" if I want to. Doesn't mean that I should, but conversely no  
license policy would say "you can change this code anyway you want, as  
long as you don't introduce errors." So I personally agree with you,  
and think that this is "not an argument to support any change."

Regards
Marshall

---

From: Russ Housley <[email-masked]>
Date: Thu, 11 Feb 2010 14:27:50 -0500

Carsten:

> appropriate for Code Components: i.e., the desire to get back modified
> versions of the code.  I think the potential benefits, if any, are
> demonstrably very small for the specific area of Code Components, and
> the complications of using a license that restricts the use of the Code
> Components (in more ways than our Simplified BSD license does)
> overwhelmingly make GPL a very bad idea for them.

We do not have a desire to get back modified versions of the code.

Consider a piece of code that uses malloc, and someone wants to use it 
in an embedded system where malloc is not available.  Suppose that a 
programmer makes the necessary changes for the malloc-challenged 
embedded environment.  This is likely to be a proprietary environment, 
meaning that such changes are not useful to anyone else.  The IETF Trust 
does not want these changes.  What would we do with them?

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Feb 2010 08:37:57 +1300

> license.  Or, the draft says BSD.

A third party can't strip the license off it, but the original authors
can do what they want, unless they have also signed away their copyright
to somebody else.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 11 Feb 2010 15:22:25 -0500

One other clarification.
The right to modify code components is there for many purposes.
The most obvious is to allow the textual and similar changes that folks 
need to use the code in the things they are building (products, samples, 
...)
As such, that needs to apply to tables of IANA values as well.  For 
drafts which assign a lot of values, people are likely to want to take 
the table, reformat it, and use it in their code.  We want to permit 
this, as it encourages accuracy and interoperability.

Yes, as a side-effect this means that they can replace the values in 
their code.  If they want to use the sample as a starting point for an 
experiment (which needs different values), one can understand doing that.
And trying to write the rules to permit one kind of change and not 
another is simply a losing proposition.

Yours,
Joel

Marshall Eubanks wrote:
>> The code components list, effective on 23 April 2009, lists "tables of 
>> values" as a code component.  The finer details require a reading of 
>> the RFC and the TLP.  Changes to a protocol parameter registry 
> and I use that as code, the BSD license does mean that I can change "-" 
> to "+" if I want to. Doesn't mean that I should, but conversely no 
> long as you don't introduce errors." So I personally agree with you, and 
> think that this is "not an argument to support any change."
> 
>>
>> Regards,
>> -sm
>>
> 
> Regards
> Marshall
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Feb 2010 22:37:21 +0100

Le 11/02/2010 20:37, Brian E Carpenter a écrit :
>>  to submit to this RPL RFC-to-be.  Being GPL it can't be stripped
>> off of its license.  Or, the draft says BSD.
>
> A third party can't strip the license off it, but the original
> authors can do what they want, unless they have also signed away
> their copyright to somebody else.

Brian - thank you for the reply.

There are really very few original authors who write code really from
scratch, i.e. real empty space.  That concept exists less and less.
Even "=" and printf are licensed, very often GPL, or LGPL.  The very
fact that one compiles a C source code it might be GPL or LGPL.

Most code is modification of existing code.

For example, the RA code I want to publish is based on GPL code.  I
can't put another license on it.  It's GPL stays GPL.

I have seen this very many times in the WGs where I look recently: the
available code used as support feedback to RFC specifiers _is_ GPL.  And
by magic the protocol spec becomes BSD?

BTW, is it normal that I just received private mail telling me I'm now
subscribed to "Ipr-wg-honest"?  Do you think I am honest or not honest?
  Do you want my public key?  Google my pgp keys - it is there since years.

Also, you might know that in RoLL WG recently there was an anonymous
poster who signed "RAV" talking about IPR malefic aspects, etc.  S/he'd
not decline identity after several public requests.  Even WG Chair
wouldn't know his/her identity.

Is it normal that things happen _so_ strangely whenever talking
licensing and IPR?  I hope here is a venue I can trust.

Yours,

Alex

> Brian _______________________________________________ Ipr-wg mailing

---

From: Lars Eggert <[email-masked]>
Date: Thu, 11 Feb 2010 23:48:35 +0200

Hi,

> another is simply a losing proposition.

I agree with Joel that this is a non-issue. (At least that's how I read what Joel said.) Yes, implementors can change the values ("reformat the table"), but as soon as they do they cannot claim conformance with the RFC anymore.

Lars

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 11 Feb 2010 17:05:49 -0500

On Feb 11, 2010, at 4:48 PM, Lars Eggert wrote:

> I agree with Joel that this is a non-issue. (At least that's how I  
> read what Joel said.) Yes, implementors can change the values  
> ("reformat the table"), but as soon as they do they cannot claim  
> conformance with the RFC anymore.

Exactly. And, if this were to be a problem, it's not one you can  
really address by license terms.

Regards
Marshall

>
> Lars_______________________________________________
> Ipr-wg mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Feb 2010 07:54:56 +0100

> can't put another license on it.  It's GPL stays GPL.

I think part of the disconnect between us here is that we don't understand what code you are talking about that would need to go into an RFC.  Generally, code in RFCs is short enough that there is rather limited burden in reformulating the code to obtain fresh copyright status (and a rewrite may be a good idea anyway to enable better exposition).  Remember that copyright governs the expression of an idea, not the idea itself, so if you freshly express the idea, that new expression is free of previous copyrights.  And no, nobody can copyright "=" or "printf".

Re weirdness:

> subscribed to "Ipr-wg-honest"?  

It may not be "normal" in all senses of that word, but it is a regular occurrence.
This is a scheme by one individual that evokes the German saying "Ich esse meine Suppe nicht! Nein, meine Suppe ess ich nicht!" which I don't know how to translate.
Just unsubscribe, and ignore that individual.

> licensing and IPR?  

Things do get much weirder when you go into the domain of patent law.
Fortunately, this discussion is about copyright law, which is a relatively sane domain in what certain parties like to mush together as "IPR".

Gruesse, Carsten

---

From: SM <[email-masked]>
Date: Fri, 12 Feb 2010 00:02:10 -0800

At 22:54 11-02-10, Carsten Bormann wrote:
>I think part of the disconnect between us here is that we don't 
>understand what code you are talking about that would need to go 
>into an RFC.  Generally, code in RFCs is short

This sounds like the inbound/outbound rights which was discussed in 
the IPR WG.  The discussion in terms of open source was more about 
having a license which is compatible with the requirements of that 
part of the community, i.e. the ability to take code from a RFC and 
use it in their software.

The discussion here sounds like the one about inbound rights.

   "It is important that the IETF receive assurances from all
    Contributors that they have the authority to grant the IETF the
    rights that they claim to grant because, under the laws of most
    countries and applicable international treaties, copyright rights
    come into existence when a work of authorship is created (but see
    Section 3.5 [BCP 78] below regarding public domain documents), and the IETF
    cannot make use of IETF Contributions if it does not have sufficient
    rights with respect to these copyright rights.  The IETF and its
    participants would run a greater risk of liability to the owners of
    these rights without this assurance."

In the case (previous disclaimer applies) of GPL, the person may be 
reusing code from an unknown author.  He/she may not have the rights 
to grant under a different license.  As Carsten Bormann mentioned 
above, the code extract that goes into a RFC is generally 
short.  There is an assumption that the code will be submitted by the 
person who wrote it.

>  enough that there is rather limited burden in reformulating the 
> code to obtain fresh copyright status (and a rewrite may be a good 
> idea anyway to enable better exposition).  Remember that copyright 
> governs the expression of an idea, not the idea itself, so if you 
> freshly express the idea, that new expression is free of previous 
> copyrights.  And no, nobody can copyright "=" or "printf".

That may be a workable solution.

If I understood the arguments correctly, it is about:

  1. Don't mention the "BSD license" when there are no code components.

  2. Leave it to the author of a RFC to license the code 
(boilerplate) under a GPL license and not the current license.

Copyright discussions can be a frustrating exercise as it is very 
difficult to achieve interoperability between IETF participants.

Regards,
-sm

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 10:02:28 +0100

Le 11/02/2010 23:05, Marshall Eubanks a écrit :
>>> As such, that needs to apply to tables of IANA values as well.
>>> For drafts which assign a lot of values, people are likely to
>>> want to take the table, reformat it, and use it in their code. We
>>> want to permit this, as it encourages accuracy and
>>> interoperability.
>>>
>>> Yes, as a side-effect this means that they can replace the values
>>> in their code. If they want to use the sample as a starting point
>>> for an experiment (which needs different values), one can
>>> understand doing that. And trying to write the rules to permit
>>> one kind of change and not another is simply a losing
>>> proposition.
>>

I think the problem is the following:

I want to write exclusively GPL code.  This RFC-to-be has a IANA table,
supposedly BSD-ed, because it is supposedly a Code Component.  Do I have
the right to not mention at all this Simplified BSD License in my
exclusively GPL code?   I don't think so.  Hence, the problem.

Alex

>
> Regards Marshall
>
>>
>> Lars_______________________________________________ Ipr-wg mailing

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 10:11:22 +0100

Le 12/02/2010 07:54, Carsten Bormann a écrit :
> into an RFC.

It's code in radvd which is GPL, and which runs on linux.

(and this is not the only disconnect.  The other disconnect is about
using BSD-derived license everywhere RFCs are implemented.  IANA table
in an RFC is supposedly Code Component, i.e. covered by the preamble
(bolierplate).)

> Generally, code in RFCs is short enough that there is rather limited
>  burden in reformulating the code

Reformulating is an option.  But it has the big inconvenient of not
being tested.  If one wants to test it then one has to reformulate too
many other things around to make sure results are deterministic.

I wouldn't suggest non-tested code for inclusion in RFC.

> to obtain fresh copyright status (and a rewrite may be a good idea
> anyway to enable better exposition).  Remember that copyright

Well, I agree, I am not concerned about Copyright.  I find the Copyright
conditions in the RFC very good to my needs.

It is that when one thinks that "=" is Code Component and "=" is
implemented as GPL code then one can't say it must become BSD just
because it's extracted from the RFC.

> Re weirdness:
>
>> BTW, is it normal that I just received private mail telling me I'm
>> now subscribed to "Ipr-wg-honest"?
>
> It may not be "normal" in all senses of that word, but it is a
> regular occurrence. This is a scheme by one individual that evokes

Who?

I refuse to participate in discussions not knowing who I am talking to,
what are his/her interests.  This makes it even less serious.

> the German saying "Ich esse meine Suppe nicht! Nein, meine Suppe ess
> ich nicht!" which I don't know how to translate. Just unsubscribe,
> and ignore that individual.

I thought about that, but if I unsubscribe then maybe the unknown
individual re-subscribes me to "dont want to be honest" or whatever
his/her imagination can be.   One should find a way to break this
vicious circle.  It's disturbing.

> Fortunately, this discussion is about copyright law, which is a
> relatively sane domain in what certain parties like to mush together
> as "IPR".

Ok, I agree weirder when including IPR, thanks,

At least I have confirmation that I am not the only one thinking it's weird.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 10:21:39 +0100

SM, I tend to agree with you, I comment below,

Le 12/02/2010 09:02, SM a écrit :
> rights

Of course I have this authority, it is recommended.  GPL makes it that I
MUST submit my code whenever anybody asks me.

> that they claim to grant because, under the laws of most countries
> and applicable international treaties, copyright rights come into
> existence when a work of authorship is created (but see Section 3.5
> [BCP 78] below regarding public domain documents), and the IETF
> to grant under a different license.

Yes, that is right, and constitutes a problem.  I don't understand why
it is artificially made into a problem at IETF.

I don't even dare to imagine an experiment where all IETF participants
don't use GPL code for one day...

> As Carsten Bormann mentioned above, the code extract that goes into
> a RFC is generally short. There is an assumption that the code will
> be submitted by the person who wrote it.

YEs, it is short.  And it must be reliably tested.  I can't just extract
code, rewrite by my taste and then include in RFC without testing, this
is not serious towards the RFC readers.

When testing, one has to include in an existing system.  The GPLed
systems are easily available...

> 1. Don't mention the "BSD license" when there are no code

I agree.

> 2. Leave it to the author of a RFC to license the code (boilerplate)
>  under a GPL license and not the current license.

I agree.

> difficult to achieve interoperability between IETF participants.

:-) I see,

Alex

>
> Regards, -sm _______________________________________________ Ipr-wg
> mailing list [email-masked]

---

From: Todd Glassey <[email-masked]>
Date: Fri, 12 Feb 2010 04:37:09 -0800

> The right to modify code components is there for many purposes.
Yes and there is too much RTM allowed in my opinion. Nothing beyond 
republication rights inside the standards process and not as a 
freestanding document is appropriate.
> The most obvious is to allow the textual and similar changes that 
> folks need to use the code in the things they are building (products, 
> samples, ...)
Sure but realize rogue tools dont necessarily follow standards or their 
reference implementations and this is done by design.

What if there was a simple way to restructure the licensing model so 
that all of the rights per any protocol were contained in 'its current 
BCP document' and not in the technology specification document???  So 
the IETF's entire practice could be simplified so that it pertained to

1)    Technical protocol specifications - this is the RFC on the design 
and controls the protocol uses. The protocol RTU and the Specification 
for how it is used are spit off of this document so that the entire IP 
package is used rather than pieces or 'cuttings' from it.

2)    Approved BCP's for the use of that protocol which are actually 
where the right to use license would need to be inserted to protect the 
legal standing of being able to say "hey you must implement the whole 
enchilada or nothing" and no misuse.

Since the protocol interactions have no license to do anything with, 
except use this protocol per the rules of the BCP then this becomes 
almost too easy. The technology control document is easily protected and 
through its any use defined in the approved BCP type IP transfer it 
makes this process seamless and easily enforced.
> As such, that needs to apply to tables of IANA values as well. 
Sure but these would be a BCP specification for the use of this protocol 
Maybe just reference the IANA specification RFC's and your done there 
from the proposed BCP document.
> For drafts which assign a lot of values, people are likely to want to 
> take the table, reformat it, and use it in their code.  We want to 
> permit this, as it encourages accuracy and interoperability.
Yes but it also opens another door to abuse and sloppy engineering which 
is rampant in a number of documents on file.
> experiment (which needs different values), one can understand doing that.
The problem is that someone could take a formulae and change the text 
wording in it but leave the formulae functionally intact claiming its 
new genesis because the labels were changed. Its not... and tha'ts an 
issue.

> another is simply a losing proposition.
Maybe not...
>> protocol to be protocol # 1 !) doesn't mean it would be wise to do 
>> so. The same thing could be said for many indisputable code 
>> components. If RFC-FOO says that (say)
>>
>> "-" to "+" if I want to. Doesn't mean that I should, but conversely 
>> no license policy would say "you can change this code anyway you 
>> want, as long as you don't introduce errors." So I personally agree 
>> with you, and think that this is "not an argument to support any 
>> change."
>>
>>>
>>> Regards,
>>> -sm
>>>
>>
>> Regards
>> Marshall
>>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2679 - Release Date: 02/10/10 07:40:00
>
>

---

From: <[email-masked]>
Date: Fri, 12 Feb 2010 10:06:43 -0500

Alexandru,

Disclaimer: I am not a lawyer, this is not legal advice, etc.

> exclusively GPL code?   I don't think so.  Hence, the problem.

The author of that table has that right.  A second author can obtain the effect of the GPL but does need to mention the BSD license.

The author of the original code can choose to BSD-license the RFC version and GPL-license the version for an environment such as the Linux kernel - this sort of dual licensing of different versions is a well-understood and common open source practice.  For a second author who did not write the code in the RFC, it should be fine to take BSD-licensed code from an RFC, modify that code (an IANA table will inevitably be modified in order to embed it in executable code) and apply a GPL license to the result (the BSD license that the IETF uses is GPL-compatible); permission of that second author is then required to legitimately remove the GPL license from that result.

In general, a choice to write exclusively GPL code is a choice to write code that is not appropriate for inclusion in RFCs, as there are important implementation environments for RFCs in which GPL code cannot be used but BSD code can be (this is a fact, e.g., as I'm using such an environment to write this email, so please take disagreements with this statement offline, preferably to /dev/null :-) ), and it's important that RFCs be implementable in such environments.  The values in an IANA table cannot be GPL protected because that pose an obstacle to interoperability with implementations for such environments.

Beyond this is the question of whether an IANA table should be a Code Component.  IMHO, there's no inherent reason why it has to be a Code Component, but treating it as one is a pragmatic way to ensure that implementers can copy and paste IANA tables from RFCs into their code.  While I have no doubt that there are ways to improve on this by not treating a table of values as if it's code (e.g., treating it as a table of values with different copyright terms), I'd like to be convinced that something is actually broken here before spending serious time and effort on a fix, as the history of IETF work on IP issues is that serious time and effort (well beyond whatever was initially anticipated) is *always* involved.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, February 12, 2010 4:02 AM
> To: [email-masked]
> Subject: Re: Simplified BSD License for Code Components and linux GPL kernel
>

---

From: Scott Brim <[email-masked]>
Date: Fri, 12 Feb 2010 10:30:30 -0500

> vicious circle.  It's disturbing.

It's okay to unsubscribe from -honest

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 17:08:33 +0100

Le 12/02/2010 16:06, [email-masked] a écrit :
>> I want to write exclusively GPL code.  This RFC-to-be has a IANA
>> table, supposedly BSD-ed, because it is supposedly a Code
>> Component.  Do I have the right to not mention at all this
>> Simplified BSD License in my exclusively GPL code?   I don't think
>> so.  Hence, the problem.
>
> The author of that table has that right.  A second author can obtain
> the effect of the GPL but does need to mention the BSD license.
>
> The author of the original code can choose to BSD-license the RFC
> version and GPL-license the version for an environment such as the
> Linux kernel - this sort of dual licensing of different versions is a
> well-understood and common open source practice.

Well-understood?  Sometimes this BSD-GPL  makes little sense to me, to
quote an excerpt from the linux kernel someone recently sent:
> * Copyright (C) 2000 - 2008, Intel Corp.
[...]
> 1. Redistributions of source code must retain the above copyright
[...]
> Alternatively, this software may be distributed under the terms of
> the * GNU General Public License ("GPL")

(I don't work for Intel, not competitor, not a lawyer, etc.)

But does it make any sense at all? Is Intel sure to have its name
figuring everywhere its code reside?  No.  Is GPL sure its code is open
source?  No.  It's just some text that everybody and nobody at the same
time, understands.  It's out of common sense, how to say.

Would we like to see the word "IETF" at the place where "Intel" figures?

> For a second author who did not write the code in the RFC, it should
> be fine to take BSD-licensed code from an RFC, modify that code (an
> IANA table will inevitably be modified in order to embed it in
> executable code) and apply a GPL license to the result (the BSD
> license that the IETF uses is GPL-compatible); permission of that
> second author is then required to legitimately remove the GPL
> license from that result.

No no, please don't, it's not that that I want.

I want to be able to remove the BSD license, not the GPL license.

Exactly as the word "Alternatively" above.

> In general, a choice to write exclusively GPL code is a choice to
> write code that is not appropriate for inclusion in RFCs, as there
> are important implementation environments for RFCs in which GPL code
> cannot be used but BSD code can be (this is a fact, e.g., as I'm
> using such an environment to write this email, so please take
> disagreements with this statement offline, preferably to /dev/null
> :-) ),

:-) :-)

> and it's important that RFCs be implementable in such environments.
> The values in an IANA table cannot be GPL protected because that pose
> an obstacle to interoperability with implementations for such
> environments.
>
> Beyond this is the question of whether an IANA table should be a Code
> Component.  IMHO, there's no inherent reason why it has to be a Code
> Component, but treating it as one is a pragmatic way to ensure that
> implementers can copy and paste IANA tables from RFCs into their
> code.  While I have no doubt that there are ways to improve on this
> by not treating a table of values as if it's code (e.g., treating it
> as a table of values with different copyright terms), I'd like to be
> convinced that something is actually broken here before spending
> serious time and effort on a fix, as the history of IETF work on IP
> issues is that serious time and effort (well beyond whatever was
> initially anticipated) is *always* involved.

YEs, I agree, I am not asking for more work.

Alex

>
> Thanks, --David ----------------------------------------------------
> David L. Black, Distinguished Engineer EMC Corporation, 176 South
> St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508)
> 293-7786 [email-masked]        Mobile: +1 (978) 394-7754
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, February 12, 2010 4:02 AM To: [email-masked]
>>>>> As such, that needs to apply to tables of IANA values as
>>>>> well. For drafts which assign a lot of values, people are
>>>>> likely to want to take the table, reformat it, and use it in
>>>>> their code. We want to permit this, as it encourages
>>>>> accuracy and interoperability.
>>>>>
>>>>> Yes, as a side-effect this means that they can replace the
>>>>> values in their code. If they want to use the sample as a
>>>>> starting point for an experiment (which needs different
>>>>> values), one can understand doing that. And trying to write
>>>>> the rules to permit one kind of change and not another is
>>>>> simply a losing proposition.
>>>>
>>>> I agree with Joel that this is a non-issue. (At least that's
>>>> how I read what Joel said.) Yes, implementors can change the
>>>> values ("reformat the table"), but as soon as they do they
>>>> cannot claim conformance with the RFC anymore.
>>>
>> I want to write exclusively GPL code.  This RFC-to-be has a IANA
>> table, supposedly BSD-ed, because it is supposedly a Code
>> Component.  Do I have the right to not mention at all this
>> Simplified BSD License in my exclusively GPL code?   I don't think
>> so.  Hence, the problem.
>>
>> Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 17:15:06 +0100

Le 12/02/2010 13:37, Todd Glassey a écrit :
[...]
>  that all of the rights per any protocol were contained in 'its
> current BCP document' and not in the technology specification
> document???

That sounds good to me.

> So the IETF's entire practice could be simplified so that it
> pertained to
>
>  and controls the protocol uses. The protocol RTU and the
> Specification for how it is used are spit off of this document so
> that the entire IP package is used rather than pieces or 'cuttings'
> from it.
>
> where the right to use license would need to be inserted to protect
> the legal standing of being able to say "hey you must implement the
> whole enchilada or nothing" and no misuse.

I agree with this separation guideline.  I am not sure I follow
precisely your proposal but I fully agree with the full decoupling
between the protocol spec and its license specification (sometimes 
Copyright).

Alex

>  almost too easy. The technology control document is easily protected
>  and through its any use defined in the approved BCP type IP transfer
>  it makes this process seamless and easily enforced.
> Sure but these would be a BCP specification for the use of this
> protocol Maybe just reference the IANA specification RFC's and your
> done there from the proposed BCP document.
>> For drafts which assign a lot of values, people are likely to want
>>  to take the table, reformat it, and use it in their code. We want
>>  to permit this, as it encourages accuracy and interoperability.
> Yes but it also opens another door to abuse and sloppy engineering
> which is rampant in a number of documents on file.
>>
>> understand doing that.
>>>> Hi Marshall, At 05:02 11-02-10, Marshall Eubanks wrote:
>>>>> Can you describe your concerns here ? IANA did not complain
>>>>> about the TLP, and to my recollection no one else has brought
>>>>> this up.
>>>>
>>>> I don't have any strong concerns about the TLP. The IETF Trust
>>>>  has done its best. What follows should not be read as legal
>>>> advice. It is not an argument to support any change.
>>>>
>>>> The code components list, effective on 23 April 2009, lists
>>>> "tables of values" as a code component. The finer details
>>>> require a reading of the RFC and the TLP. Changes to a protocol
>>>> parameter registry generally goes in the IANA Considerations
>>>> section. It's not up to me to determine whether the assigned
>>>> values are code components. If the assigned values fall under
>>>> the Simplified BSD License, they can be modified.
>>>>
>>>> "All assigned values are to be published and made available
>>>> free of any charges and free of any constraints relating to
>>>> further redistribution, with the caveat that the assignment
>>>> information may not be modified in any redistributed copy."
>>>>
>>> OK, thanks for this. We might want to put IANA registries and
>>> other parameter values as not suitable for code components in
>>> some future TLP.
>>>
>>> protocol to be protocol # 1 !) doesn't mean it would be wise to
>>> do so. The same thing could be said for many indisputable code
>>> and I use that as code, the BSD license does mean that I can
>>> change "-" to "+" if I want to. Doesn't mean that I should, but
>>> conversely no license policy would say "you can change this code
>>>  anyway you want, as long as you don't introduce errors." So I
>>> personally agree with you, and think that this is "not an
>>> argument to support any change."
>>>
>>>>
>>>> Regards, -sm
>>>>
>>>
>>> Regards Marshall
>>>
>> No virus found in this incoming message. Checked by AVG
>> -www.avg.com Version: 8.5.435 / Virus Database: 271.1.1/2679 -
>> Release Date: 02/10/10 07:40:00
>>
>>
>
>
>

---

From: <[email-masked]>
Date: Fri, 12 Feb 2010 12:06:25 -0500

Alexandru,

> > the * GNU General Public License ("GPL")

But that's not the structure that's involved here.  Rather, the original author of the code can produce two files that contain the same source code:
	- File 1 is for the RFC and carries only a BSD license.
	- File 2 is for the Linux kernel and carries only a GPL license.
The original author of the code can do this, and for open source this can happen when there's both an open source distribution and a commercially-licensed distribution based on the same source code (the Linux kernel is *not* an example, as all of its distributions are open source).  The result would be a Linux kernel file (File 2) that only has a GPL license.  An author who is unwilling to produce File 1 has decided not to contribute code to RFCs.

> Exactly as the word "Alternatively" above.

Sorry, licenses are licenses, and the basic rules don't distinguish among them - someone who's not the original author of the code can't legitimately remove the original author's code license, no matter what that code license was.  That said, the resulting file does not use the "Alternatively" construct noted above, rather it has the GPL license on the entire file with portions extracted from the RFC subject to an embedded version of the simplified BSD license.  Because the simplified BSD license that the IETF uses does *not* require attribution, it's GPL-compatible, and the GPL license governs the resulting file.  The above snippet has to use the "Alternatively" construct because the requirement for attribution is not GPL-compatible, a problem that the IETF does not have.

Thanks,
--David

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, February 12, 2010 11:09 AM
> To: Black, David
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 18:47:36 +0100

David,

Le 12/02/2010 18:06, [email-masked] a écrit :
>>> The author of the original code can choose to BSD-license the
>>> RFC version and GPL-license the version for an environment such
>>> as the Linux kernel - this sort of dual licensing of different
>>> versions is a well-understood and common open source practice.
>>
>> Well-understood?  Sometimes this BSD-GPL  makes little sense to me,
>> to quote an excerpt from the linux kernel someone recently sent:
>>> Alternatively, this software may be distributed under the terms
>>> of the * GNU General Public License ("GPL")
>
> But that's not the structure that's involved here.  Rather, the
> original author

What's an original author in more detail?

I personally think it's very tough to be original author, next to
impossible, because running code exists in an ecosystem which often was
using GPL as implementation feedback to RFC protocol specifiers.

I think people who claim to be original authors of C code and not to be
bound to _any_ license (such as to be able to write their own license)
are not aware of many things they actually use.

> of the code can produce two files that contain the same source code:

If I write my extensions into the radvd code (a GPL source in linux, for
Router Advertisement daemon), then my code is GPL.  I can't make it BSD.
  Unless I try the ununderstandable GPL+BSD text using words such as
"alternatively you can not use this license but use another one".

If I try to be an original author - start everything from scratch, then
I must write much more code (kernel, stack, compilers) than just the
little proof-of-concept for Router Advertisement for a little RFC.

I am not sure how to explain this.

> - File 2 is for the Linux kernel and carries only a GPL license. The
> original author of the code can do this, and for open source this
> can happen when there's both an open source distribution and a
> commercially-licensed distribution based on the same source code
> (the Linux kernel is *not* an example, as all of its distributions
> are open source).  The result would be a Linux kernel file (File 2)
> that only has a GPL license.  An author who is unwilling to produce
> File 1 has decided not to contribute code to RFCs.

Again - what does "original author" mean?  What kind of existing
software is s/he using to develop her/his little code for RFC?

Is an original author using a library?  Which one?  libc yes no?

Is an original author modifying an existing code?

Is an original author writing a kernel module or a userspace app?

Is an original author using GPLed code to compile his/her "original" code?

Is an original author executing automatically generated assembly code?

There are so many questions like this each leading to a license in the end.

I am seeking clarification about "original author" and license.

>>> For a second author who did not write the code in the RFC, it
>>> should be fine to take BSD-licensed code from an RFC, modify that
>>> code (an IANA table will inevitably be modified in order to embed
>>> it in executable code) and apply a GPL license to the result (the
>>> BSD license that the IETF uses is GPL-compatible); permission of
>>> that second author is then required to legitimately remove the
>>> GPL license from that result.
>>
> Sorry, licenses are licenses, and the basic rules don't distinguish
> among them - someone who's not the original author of the code can't
>  legitimately remove the original author's code license, no matter
> what that code license was.  That said, the resulting file does not
> use the "Alternatively" construct noted above, rather it has the GPL
>  license on the entire file with portions extracted from the RFC
> subject to an embedded version of the simplified BSD license.

It would be advantageous if it were possible, but I am afraid it's
hardly feasible because: (1) it's hard to easily write new little code
for little RFC without reusing existing code and (2) when that existing
code's license is GPL one can't strip GPL out of it.

Alex

---

From: <[email-masked]>
Date: Fri, 12 Feb 2010 13:55:28 -0500

Alexandru,

It's important to distinguish copyright from patents, as Carsten already wrote:

>> Generally, code in RFCs is short enough that there is rather limited burden
>> in reformulating the code to obtain fresh copyright status (and a rewrite
>> may be a good idea anyway to enable better exposition).  Remember that
>> copyright governs the expression of an idea, not the idea itself, so if
>> you freshly express the idea, that new expression is free of previous

If someone completely rewrites code, that person is the original author of the rewritten code.

> "alternatively you can not use this license but use another one".

That's not a rewrite, it's extensions, and the "alternatively" construct is not legitimate.  The existing code that was modified was GPL code, the "Alternatively" construct has the effect of removing the GPL from the original code that remains in the modified file, and that requires permission from the authors of that original code.  OTOH ...

> little proof-of-concept for Router Advertisement for a little RFC.

Nonsense - while this is not an appropriate forum for an explanation of licenses used for tools, the compiler example is completely wrong (e.g., code produced by a GNU compiler is *not* automatically GPL-licensed), and just running code on a Linux kernel does *not* bring that code under the GPL either.

> Is an original author using a library?  Which one?  libc yes no?

Oh, good grief ... GNU libc is LGPL-licensed, not GPL-licensed, and that makes a massive difference.

Beyond this, I think you're trying to do something that's not possible in general.

A project such as Linux adopts a license like GPL in part to ensure that its code is only used for open source development.  Code in RFCs is intended to be used for any development, including non-open-source. Hence putting GPL code into an RFC violates the intents of its developers, as expressed in their use of the GPL license.  So, it should come as no surprise that putting arbitrary GPL code in an RFC is not possible in general (need to get permission of all the authors to copy the code, and for a heavily modified Linux file, that may be a lot of authors).

As noted in the above quote from Carsten, rewriting the code from scratch for the RFC is a viable approach.

Thanks,
--David

> Sent: Friday, February 12, 2010 12:48 PM
> To: Black, David
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 21:25:15 +0100

Le 12/02/2010 19:55, [email-masked] a écrit :
[...]
>>> Generally, code in RFCs is short enough that there is rather
>>> limited burden in reformulating the code to obtain fresh
>>> copyright status (and a rewrite may be a good idea anyway to
>>> enable better exposition).  Remember that copyright governs the
>>> expression of an idea, not the idea itself, so if you freshly
>>> express the idea, that new expression is free of previous

I don't think really anybody rewrites code in a void of license.

>> If I write my extensions into the radvd code (a GPL source in
>> linux, for Router Advertisement daemon), then my code is GPL.  I
>> can't make it BSD. Unless I try the ununderstandable GPL+BSD text
>> using words such as "alternatively you can not use this license but
>> use another one".
>
> That's not a rewrite, it's extensions, and the "alternatively"
> construct is not legitimate.  The existing code that was modified was
> GPL code, the "Alternatively" construct has the effect of removing
> the GPL from the original code that remains in the modified file, and
> that requires permission from the authors of that original code. OTOH
> ...
>
>> If I try to be an original author - start everything from scratch,
>>  then I must write much more code (kernel, stack, compilers) than
>> just the little proof-of-concept for Router Advertisement for a
>> little RFC.
>
> Nonsense - while this is not an appropriate forum for an explanation
>  of licenses used for tools, the compiler example is completely wrong
>  (e.g., code produced by a GNU compiler is *not* automatically
> GPL-licensed), and just running code on a Linux kernel does *not*
> bring that code under the GPL either.

Difficult to be sure about that I have to check.

I meant more than just code out of compiler, I meant all the process of 
compiling, linking, lex/yacc, debugging, wiresharking, sitting above or 
inside sockets, using ciphering algorithms under export control - 
everything development one can't do without.  I strongly suspect GPL is 
all over.

> that makes a massive difference.

Yes, LGPL.  Not BSD.  Compatible yes, but do mention LGPL in RFC.  It is 
used.

> Beyond this, I think you're trying to do something that's not

That's to be noted, I set it aside.

> A project such as Linux adopts a license like GPL in part to ensure
> that its code is only used for open source development.  Code in RFCs
> is intended to be used for any development, including
> non-open-source.

WEll yes - then say (the preamble) so.  Don't say BSD.  Say that RFCs
are targeted to be implemented for _any_ development, not necessarily BSD.

Write an IETF license which says that _any_ license could be applied.
The "ANY IETF License".

People have invented such words in the past ("AS-IS", "Copyleft") why
not IETF.

> Hence putting GPL code into an RFC violates the intents of its
> developers, as expressed in their use of the GPL license.

That's a strong statement making GPL code implementers go away from
IETF.  I do not think this is the intention.  I think the wrong
intention gets communicated in the preamble by saying "BSD".

> So, it should come as no surprise that putting arbitrary GPL code in
> an RFC is not possible in general (need to get permission of all the
> authors to copy the code, and for a heavily modified Linux file,
> that may be a lot of authors).

> As noted in the above quote from Carsten, rewriting the code from
> scratch for the RFC is a viable approach.

For the radvd example: radvd implements a lot of stuff of the ICMPv6
protocol (and not all of it, parts of ICMPv6 are in kernel).  I don't
have time and ressource to reimplement everything ICMPv6.  I just need
one bit and a few prefixes.   I only need an extension. It would be
stupid from my part to think I can ever implement everything.  For what?
  Just for that little bit in RA?

I do not understand why I have to struggle with this.

I can also share about the large amount of communication protocols I
have seen running and never mentioned at IETF.  I think this is not good.

I have also seen a large amount of licensing schemes, commercial
interests, and not all mention BSD.  I don't understand why IETF has to.

End of stubordness :-)

Alex

>
> Thanks, --David
>
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Friday, February 12,
>> 2010 12:48 PM To: Black, David Cc: [email-masked] Subject: Re:
>> Simplified BSD License for Code Components and linux GPL kernel
>>
>> David,
>>
>>>>> The author of the original code can choose to BSD-license
>>>>> the RFC version and GPL-license the version for an
>>>>> environment such as the Linux kernel - this sort of dual
>>>>> licensing of different versions is a well-understood and
>>>>> common open source practice.
>>>>
>>>> Well-understood?  Sometimes this BSD-GPL  makes little sense to
>>>> me, to quote an excerpt from the linux kernel someone recently
>>>> sent:
>>>>> Alternatively, this software may be distributed under the
>>>>> terms of the * GNU General Public License ("GPL")
>>>
>> impossible, because running code exists in an ecosystem which often
>> was using GPL as implementation feedback to RFC protocol
>> specifiers.
>>
>> I think people who claim to be original authors of C code and not
>> to be bound to _any_ license (such as to be able to write their own
>> license) are not aware of many things they actually use.
>>
>>> of the code can produce two files that contain the same source
>>> code: - File 1 is for the RFC and carries only a BSD license.
>>
>> If I write my extensions into the radvd code (a GPL source in
>> linux, for Router Advertisement daemon), then my code is GPL.  I
>> can't make it BSD. Unless I try the ununderstandable GPL+BSD text
>> using words such as "alternatively you can not use this license but
>> use another one".
>>
>> If I try to be an original author - start everything from scratch,
>>  then I must write much more code (kernel, stack, compilers) than
>> just the little proof-of-concept for Router Advertisement for a
>> little RFC.
>>
>>>  The original author of the code can do this, and for open source
>>>  this can happen when there's both an open source distribution
>>> and a commercially-licensed distribution based on the same source
>>> code (the Linux kernel is *not* an example, as all of its
>>> distributions are open source).  The result would be a Linux
>>> kernel file (File 2) that only has a GPL license.  An author who
>>>  is unwilling to produce File 1 has decided not to contribute
>>> code to RFCs.
>>
>>>>> For a second author who did not write the code in the RFC,
>>>>> it should be fine to take BSD-licensed code from an RFC,
>>>>> modify that code (an IANA table will inevitably be modified
>>>>> in order to embed it in executable code) and apply a GPL
>>>>> license to the result (the BSD license that the IETF uses is
>>>>>  GPL-compatible); permission of that second author is then
>>>>> required to legitimately remove the GPL license from that
>>>>> result.
>>>>
>>> Sorry, licenses are licenses, and the basic rules don't
>>> distinguish among them - someone who's not the original author of
>>> the code can't legitimately remove the original author's code
>>> license, no matter what that code license was.  That said, the
>>> resulting file does not use the "Alternatively" construct noted
>>> above, rather it has the GPL license on the entire file with
>>> portions extracted from the RFC subject to an embedded version of
>>> the simplified BSD license.
>>
>> hardly feasible because: (1) it's hard to easily write new little
>> code for little RFC without reusing existing code and (2) when that
>> existing code's license is GPL one can't strip GPL out of it.
>>
>> Alex
>>
>
>

---

From: <[email-masked]>
Date: Fri, 12 Feb 2010 15:46:35 -0500

Alexandru,

Most of your statements about licenses for tools (e.g., compiling, linking, debugging) are wrong - most of the open source tools you've listed are used on a regular basis to build non-open-source software.  A specific example is that the reason I mentioned LGPL is that the GNU libc can be (and routinely is) linked with non-open-source software because GNU libc is licensed with LGPL and not GPL.

> interests, and not all mention BSD.  I don't understand why IETF has to.

IMHO, writing a new license as you would have IETF do is a "cure worse than the disease."

The Simplified BSD license is GPL-compatible; that fact makes code components from RFCs usable in GPL-licensed projects.

Thanks,
--David

> Sent: Friday, February 12, 2010 3:25 PM
> To: Black, David
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Feb 2010 22:26:01 +0100

David, I give up on this.

It's right to believe one compatible license may be compatible to others
and leave the implementers to avoid nonsense (e.g. "do but Alternatively
don't".)

All I can hope is that the new Guideline tagging "Simplified BSD" in
preamble (boilerplate) will not apply retroactively to earlier RFCs.

Alex

Le 12/02/2010 21:46, [email-masked] a écrit :
> Most of your statements about licenses for tools (e.g., compiling,
> linking, debugging) are wrong - most of the open source tools you've
> listed are used on a regular basis to build non-open-source
> software. A specific example is that the reason I mentioned LGPL is
> that the GNU libc can be (and routinely is) linked with
> non-open-source software because GNU libc is licensed with LGPL and
> not GPL.
>
> The Simplified BSD license is GPL-compatible; that fact makes code
> components from RFCs usable in GPL-licensed projects.
>
> Thanks, --David
>
>> 2010 3:25 PM To: Black, David Cc: [email-masked] Subject: Re:
>> Le 12/02/2010 19:55, [email-masked] a écrit : [...]
>>>>>  enable better exposition).  Remember that copyright governs
>>>>> the expression of an idea, not the idea itself, so if you
>>>>> freshly express the idea, that new expression is free of
>>>>> previous copyrights.  And no, nobody can copyright "=" or
>>>>> "printf".
>>>
>>>> can't make it BSD. Unless I try the ununderstandable GPL+BSD
>>>> text using words such as "alternatively you can not use this
>>>> license but use another one".
>>>
>>> construct is not legitimate.  The existing code that was
>>> modified was GPL code, the "Alternatively" construct has the
>>> effect of removing the GPL from the original code that remains in
>>> the modified file, and that requires permission from the authors
>>> of that original code. OTOH ...
>>>
>>>> If I try to be an original author - start everything from
>>>> scratch, then I must write much more code (kernel, stack,
>>>> compilers) than just the little proof-of-concept for Router
>>>> Advertisement for a little RFC.
>>>
>>> Nonsense - while this is not an appropriate forum for an
>>> explanation of licenses used for tools, the compiler example is
>>> completely wrong (e.g., code produced by a GNU compiler is *not*
>>> automatically GPL-licensed), and just running code on a Linux
>>> kernel does *not* bring that code under the GPL either.
>>
>> I meant more than just code out of compiler, I meant all the
>> process of compiling, linking, lex/yacc, debugging, wiresharking,
>> sitting above or inside sockets, using ciphering algorithms under
>> export control - everything development one can't do without.  I
>> strongly suspect GPL is all over.
>>
>>>> Again - what does "original author" mean?  What kind of
>>>> existing software is s/he using to develop her/his little code
>>>> for RFC?
>>>>
>> Yes, LGPL.  Not BSD.  Compatible yes, but do mention LGPL in RFC.
>> It is used.
>>
>>> A project such as Linux adopts a license like GPL in part to
>>> ensure that its code is only used for open source development.
>>> Code in RFCs is intended to be used for any development,
>>> including non-open-source.
>>
>> WEll yes - then say (the preamble) so.  Don't say BSD.  Say that
>> RFCs are targeted to be implemented for _any_ development, not
>> necessarily BSD.
>>
>> Write an IETF license which says that _any_ license could be
>> applied. The "ANY IETF License".
>>
>> People have invented such words in the past ("AS-IS", "Copyleft")
>> why not IETF.
>>
>>> So, it should come as no surprise that putting arbitrary GPL
>>> code in an RFC is not possible in general (need to get permission
>>> of all the authors to copy the code, and for a heavily modified
>>> Linux file, that may be a lot of authors).
>>
>> For the radvd example: radvd implements a lot of stuff of the
>> ICMPv6 protocol (and not all of it, parts of ICMPv6 are in
>> kernel). I don't have time and ressource to reimplement everything
>> ICMPv6. I just need one bit and a few prefixes.   I only need an
>> extension. It would be stupid from my part to think I can ever
>> implement everything.  For what? Just for that little bit in RA?
>>
>> I can also share about the large amount of communication protocols
>> I have seen running and never mentioned at IETF.  I think this is
>> not good.
>>
>>>> [mailto:[email-masked]] Sent: Friday, February
>>>> 12, 2010 12:48 PM To: Black, David Cc: [email-masked]
>>>>>> Well-understood?  Sometimes this BSD-GPL  makes little
>>>>>> sense to me, to quote an excerpt from the linux kernel
>>>>>> someone recently sent:
>>>>> But that's not the structure that's involved here.  Rather,
>>>>> the original author
>>>>
>>>> I personally think it's very tough to be original author, next
>>>> to impossible, because running code exists in an ecosystem
>>>> which often was using GPL as implementation feedback to RFC
>>>> protocol specifiers.
>>>>
>>>> I think people who claim to be original authors of C code and
>>>> not to be bound to _any_ license (such as to be able to write
>>>> their own license) are not aware of many things they actually
>>>> use.
>>>>
>>>>> of the code can produce two files that contain the same
>>>>> source code: - File 1 is for the RFC and carries only a BSD
>>>>> license.
>>>>
>>>> can't make it BSD. Unless I try the ununderstandable GPL+BSD
>>>> text using words such as "alternatively you can not use this
>>>> license but use another one".
>>>>
>>>> If I try to be an original author - start everything from
>>>> scratch, then I must write much more code (kernel, stack,
>>>> compilers) than just the little proof-of-concept for Router
>>>> Advertisement for a little RFC.
>>>>
>>>>> - File 2 is for the Linux kernel and carries only a GPL
>>>>> license. The original author of the code can do this, and
>>>>> for open source this can happen when there's both an open
>>>>> source distribution and a commercially-licensed distribution
>>>>> based on the same source code (the Linux kernel is *not* an
>>>>> example, as all of its distributions are open source).  The
>>>>> result would be a Linux kernel file (File 2) that only has a
>>>>> GPL license.  An author who is unwilling to produce File 1
>>>>> has decided not to contribute code to RFCs.
>>>>
>>>> Again - what does "original author" mean?  What kind of
>>>> existing software is s/he using to develop her/his little code
>>>> for RFC?
>>>>
>>>>>>> For a second author who did not write the code in the
>>>>>>> RFC, it should be fine to take BSD-licensed code from an
>>>>>>> RFC, modify that code (an IANA table will inevitably be
>>>>>>> modified in order to embed it in executable code) and
>>>>>>> apply a GPL license to the result (the BSD license that
>>>>>>> the IETF uses is GPL-compatible); permission of that
>>>>>>> second author is then required to legitimately remove
>>>>>>> the GPL license from that result.
>>>>>>
>>>>> distinguish among them - someone who's not the original
>>>>> author of the code can't legitimately remove the original
>>>>> author's code license, no matter what that code license was.
>>>>> That said, the resulting file does not use the
>>>>> "Alternatively" construct noted above, rather it has the GPL
>>>>> license on the entire file with portions extracted from the
>>>>> RFC subject to an embedded version of the simplified BSD
>>>>> license.
>>>>
>>>> It would be advantageous if it were possible, but I am afraid
>>>> it's hardly feasible because: (1) it's hard to easily write
>>>> new little code for little RFC without reusing existing code
>>>> and (2) when that existing code's license is GPL one can't
>>>> strip GPL out of it.
>>>>
>>>> Alex
>>>>
>>>
>>>
>>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Feb 2010 10:30:43 +0100

> unnecessary bells and whistles?

I believe the intent was that the IETF Trust should have the ability to
modify what is and what is not regarded as a "Code Component" over time,
based on requests from the IETF community, to accommodate new forms of
code-like material.  Thus, the disclaimer needs to be there from the
start, or else it is not possible to use it.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Feb 2010 15:48:18 +1300

> start, or else it is not possible to use it.

Certainly. And as the holder of rights under RFC5378 (or its
predecessors, as the case may be), the Trust can vary the license
in a particular case, if someone convinces them that this is a good
idea (for example, to help make the Internet work better).

Also, I don't really think that the Trust is going to start chasing
down every piece of code that's GPLed just in case a few lines
from an RFC have slipped into it. This just isn't worth bothering
about. (So I will now shut up.)

    Brian

---

From: Todd Glassey <[email-masked]>
Date: Mon, 15 Feb 2010 05:33:57 -0800

On 2/14/2010 6:48 PM, Brian E Carpenter wrote:
>> Alexandru Petrescu<[email-masked]>  writes:
>>
>>      
Uh No it cant. The Trust cannot change the licensing once something is 
published... no-one in IP Law would agree that the IETF or the Trust can 
modify the terms it releases code under after that code is donated under 
a specific set of code.

What you have conveniently left out of this is the cost of the 
engineering vetting that happens through NoteWell and the meetings 
freezes the rights since those terms cannot be retroactively changed. 
Sorry...

Todd Glassey
> Version: 8.5.435 / Virus Database: 271.1.1/2688 - Release Date: 02/14/10 19:35:00
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Feb 2010 11:32:14 -0500

> modify the terms it releases code under after that code is donated under

Currently, the IETF Trust is not passing on all of the rights that it 
receives to readers.  For example, the right to make derivative works of 
IETF standards-track documents is provided only to the IETF standards 
process.  Since the Contributors have given the IETF Trust more rights 
than are passed along, the IETF Trust could grant further rights; of 
course, these right cannot exceed the rights that the IETF Trust received.

This capability was included so that the IETF Trust could pass change 
control to another SDO if the community decides that is the appropriate 
thing to do.  As far as I know, this has happened only once, and it was 
burdensome because it happened before this structure was in place.  In 
the case I know about, a MIB document was transferred from the IETF to 
IEEE 802.1.

Russ