Subject: Simplified BSD License for Code Components

From: Russ Housley <[email-masked]>
Date: Thu, 07 Jan 2010 14:52:07 -0500

The IETF Stream requires that code extracted from an RFC be put under 
the simplified BSD license.  The other RFC streams (IAB, IRTF, and 
Independent Submission) have rejected this approach.  Instead these 
streams simply require proper attribution.

Why is the IETF Stream different?  It would be much easier on everyone 
if the same approach were used across all of the RFC streams.

Russ

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jan 2010 12:25:33 -0800

On Jan 7, 2010, at 11:52 , Russ Housley wrote:

> The IETF Stream requires that code extracted from an RFC be put under the simplified BSD license.  The other RFC streams (IAB, IRTF, and Independent Submission) have rejected this approach.  Instead these streams simply require proper attribution.
> 
> Why is the IETF Stream different?  It would be much easier on everyone if the same approach were used across all of the RFC streams.

The issue is conflicting license if there is more than one and some people want  a way to limit the liability they have in code components.  I'm not expressing my opinion on this ... I'm just trying to mention one of the arguments that was brought in the past that I think lead to the current situation. 

> 
> Russ
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Jan 2010 15:52:31 -0500

In an attempt to provide more context to answer my query, here is the 
paragraph from RFC 5744 that describes the situation for the Independent 
Submission stream:

    The IETF Trust will indicate that, in cooperation with the
    Independent Submission Editor, the Trust grants to readers and users
    of material from Independent Submission documents the right to make
    unlimited derivative works, unless the document specifies that no
    derivative works are permitted.  This will permit anyone to copy,
    extract, modify, or otherwise use material from Independent
    Submission documents as long as suitable attribution is given.

Russ

On Thu, Jan 7, 2010 at 11:52 AM, Russ Housley <[email-masked]> wrote:
> The IETF Stream requires that code extracted from an RFC be put under the
> simplified BSD license.  The other RFC streams (IAB, IRTF, and Independent
> Submission) have rejected this approach.  Instead these streams simply
> require proper attribution.
>
> Why is the IETF Stream different?  It would be much easier on everyone if
> the same approach were used across all of the RFC streams.
>
> Russ

---

From: SM <[email-masked]>
Date: Thu, 07 Jan 2010 16:06:45 -0800

Hi Russ,
At 11:52 07-01-2010, Russ Housley wrote:
>The IETF Stream requires that code extracted from an RFC be put 
>under the simplified BSD license.  The other RFC streams (IAB, IRTF, 
>and Independent Submission) have rejected this approach.  Instead 
>these streams simply require proper attribution.
>
>Why is the IETF Stream different?  It would be much easier on 
>everyone if the same approach were used across all of the RFC streams.

In short, IETF participants are granted the right to reuse 
contributions to create derivative work within the IETF Standards 
Process.  The IETF retains change control.  Having the limitation on 
derivative work for source code was viewed as problematic for some 
open source projects as their license does not permit restrictions on 
producing derivative work.  They could not include code from RFCs 
because of that.  The matter was solved by adopting the simplified 
BSD license for code components.  The corporate side also agreed that 
it suited their legal requirements.

The Independent Stream allows unlimited derivative work usually as 
long as there is attribution.  The same rights apply to text and 
code.  The IRTF adopted the same approach.  The IAB adopted a liberal 
copyright policy too.  Code is not an issue in RFCs from the IAB Stream anyway.

The IETF Stream is different because of change control.  The IETF 
would have to adopt an unlimited derivative works policy for all the 
RFC streams to be harmonized.

Regards,
-sm

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Jan 2010 08:53:27 +0100

Russ Housley <[email-masked]> writes:

> paragraph from RFC 5744 that describes the situation for the
> Independent Submission stream:
>

To be useful as a replacement of the simplified BSD license, the above
license texts needs to be evaluated by organization that know how to
evaluate free software licensing compatibility issues, such as the Free
Software Foundation and Debian.  The simplified BSD license have gone
through this legal review.  Otherwise the goal of having free software
compatible licensing for code components in RFCs will not be fulfilled.

If you want to ask the FSF/Debian to perform this review, I can channel
the request if it would help.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Jan 2010 06:00:36 -0500

--On Thursday, January 07, 2010 14:52 -0500 Russ Housley
<[email-masked]> wrote:

> The IETF Stream requires that code extracted from an RFC be
> put under the simplified BSD license.  The other RFC streams
> (IAB, IRTF, and Independent Submission) have rejected this
> approach.  Instead these streams simply require proper
> attribution.
> 

Russ,

As what may be just a different take on what some others have
tried to say, the IETF Stream is different because its Standards
Track subset is different and because differentiating _within_
the IETF Stream would have been too complicated for all
involved.  The Standards Track sub-stream is different because
this WG and the  community wanted to use control over the IPR to
put stronger pressure against, and restrictions on, representing
something as an IETF Standard that was actually not completely
consistent with it.  The BSD license was a way to respond to the
necessity to be more liberal about copying and reusing "code"
than we wanted to permit for simple running text.   In the case
of those other streams, it is the licenses to reuse the running
text that are more liberal -- liberal enough that no special
provisions are required for code.  

To answer your specific question, as far as I can tell as a
non-lawyer who has not tried to study the issues even as an
amateur, there isn't a lot of difference between the BSD license
and "attribution only; just don't blame me".   As Simon
indirectly points out, it is never that easy and the BSD license
has been tested.  But the complexity, IMO, arises not from the
use of the BSD license versus something else.  It arises from
the greater restrictions on the running text and the need to
identify "code" differently and have a separate license for it.
And that distinction cannot go away as long as the IETF wants to
apply an "if you explicitly or implicitly claim that the
document you are going to publish is an IETF Standard RFC, then
it must be the IETF Standard RFC" rule.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jan 2010 08:37:37 +1300

> it must be the IETF Standard RFC" rule.

I believe that is correct. Another way to look at it is that for
standards track documents, we want to retain change control of
the normative content, but we also want to ensure that code can be
used and modified without bureaucracy; attaching the BSD license
to the code appeared to be the most convenient way to do this.

The Independent Stream text explicitly does not retain change
control, so will not do for standards track documents.

Writing our own license and ensuring that it achieves what we
want has already proved hard, which is why the tried and tested
Simplified BSD was chosen.

      Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 29 Jan 2010 17:38:43 +0100

> if the same approach were used across all of the RFC streams. 
I have not studied the language of the other streams.

The community consensus of the IPR group was that there should be 
reasonably-unlimited ability to create derived works from code in RFCs, 
while no such right existed for the text.

The decision to implement this by means of the BSD license was taken by 
the IETF Trust; I don't have insight into the processes that led to this 
decision.

                   Harald

---

From: Todd Glassey <[email-masked]>
Date: Fri, 29 Jan 2010 08:51:42 -0800

On 1/29/2010 8:38 AM, Harald Alvestrand wrote:
> reasonably-unlimited ability to create derived works from code in 
> RFCs, while no such right existed for the text.
The problem is that this is NOT LEGAL, and intentionally creating a rule 
to flaunt the law is more than stupid it shows the contempt for process 
as well which resides so well in this IETF.

You MAY not create derivative licenses to anything you dont have the 
legal power of attorney over Harald whether you write it down or not.

Todd Glassey
>
> The decision to implement this by means of the BSD license was taken 
> by the IETF Trust; I don't have insight into the processes that led to 
> this decision.
>
>                   Harald
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.432 / Virus Database: 271.1.1/2655 - Release Date: 01/29/10 09:08:00
>
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jan 2010 16:10:08 -0500

> to the code appeared to be the most convenient way to do this.

This was not the advice to the Trust in the published RFC.  It came 
along later.

> control, so will not do for standards track documents.

Derivative works are allowed for code components in both situations.

The ability to update a standards track RFC seems to be a vary different 
matter.  I cannot see how the license applied to extracted code 
components impacts it.

> Simplified BSD was chosen.

I have not heard the open source community say that they cannot use code 
components from IRTF and Independent Submission Stream RFCs.

Russ

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 Jan 2010 22:16:54 +0100

Russ Housley <[email-masked]> writes:

> I have not heard the open source community say that they cannot use
> code components from IRTF and Independent Submission Stream RFCs.

Whom did you ask?

What is the license for code components from IRTF and Independent
Submission Stream RFCs?

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Jan 2010 16:26:14 -0500

The license, as stated on the boilerplate, is that you may use the code 
any way you like.  Specifically, it says that unlimited derivative works 
are permitted.

You can take it, and modify it, and include it in your programs.
You should include proper credit as to where you got it, as with 
anything you take from anyone.
You can even slap any license you like on the resulting code in your 
package.

There is no need for an explicit separate license, given the clear 
statement that unlimited derivative works are permitted.
(And yes, I have checked this with a skilled lawyer.)

Yours,
Joel M. Halpern

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 Jan 2010 16:31:59 -0500

> In short, IETF participants are granted the right to reuse contributions
> to create derivative work within the IETF Standards Process. The IETF
> retains change control. Having the limitation on derivative work for
> source code was viewed as problematic for some open source projects as
> their license does not permit restrictions on producing derivative work.
> They could not include code from RFCs because of that. The matter was
> solved by adopting the simplified BSD license for code components. The
> corporate side also agreed that it suited their legal requirements.
>
> The Independent Stream allows unlimited derivative work usually as long
> as there is attribution. The same rights apply to text and code. The
> IRTF adopted the same approach. The IAB adopted a liberal copyright
> policy too. Code is not an issue in RFCs from the IAB Stream anyway.
>
> The IETF Stream is different because of change control. The IETF would
> have to adopt an unlimited derivative works policy for all the RFC
> streams to be harmonized.

I realize that it will not be possible, or even desirable, to use the 
same license for text.  Both approaches allow derivative works for code 
components, but they do so under different licenses.  I'm simply trying 
to understand if a more simple approach is possible.

Russ

---

From: Todd Glassey <[email-masked]>
Date: Sat, 30 Jan 2010 07:08:44 -0800

On 1/29/2010 1:26 PM, Joel M. Halpern wrote:
> The license, as stated on the boilerplate, is that you may use the 
> code any way you like.  Specifically, it says that unlimited 
> derivative works are permitted.
For what purpose? To implement commercial products from?
> anything you take from anyone.
This is effectively more than an open source license and is something 
that NONE of the people working in the IETF engineering community except 
for some very rare instances, have the legal authority to convey SH*T to 
the IETF. Knowing this make this use license useless since it is 
unenforceable under any number of state and federal standards I can name...
> You can even slap any license you like on the resulting code in your 
That takes an iron clad IP conveyance process for a commercial entity to 
rely on since it must be able to show the gentry and governance for any 
IP it uses as well as that IP's license.
> (And yes, I have checked this with a skilled lawyer.)
Me too... Joel - in fact I have checked with five separate IP 
specialists, and have reviewed public IP policy from CISCO, QUALCOMM, 
NEC, FUJITSU, INTEL, and about 20 others,  all which would be unable to 
rely on IP license-to-use which cannot be properly proven.

If you want to put an Open Source or more liberal BSD type license in as 
an option then do that, as an option, not as the ONLY way of 
participating in the IETF.

Just my two cents...

Todd Glassey

---

From: SM <[email-masked]>
Date: Sat, 30 Jan 2010 11:27:10 -0800

Hi Russ,
At 13:31 29-01-10, Russ Housley wrote:
>I realize that it will not be possible, or even desirable, to use 
>the same license for text.  Both approaches allow derivative works 
>for code components, but they do so under different licenses.  I'm 
>simply trying to understand if a more simple approach is possible.

Although both approaches allow derivative works for code components, 
there are differences when we consider the attitude and requirements 
of the user-base.  Simon Josefsson commented on the evaluation of the 
license [1].  Cullen Jennings mentioned liability [2].

It would be simpler for the IETF Stream to adopt the "attribution" 
approach (for code) instead of the change being done for the other 
streams.  It is unlikely that the IETF would be sending out letters 
of "enforcement" anyway as the IETF community is aware of the consequences.

The IETF community has grown over the years and the culture has 
changed somewhat.  It would previous consider "attribution" as 
implicit.  Now, it has to be explicit for people to understand.  Some 
people may be more comfortable with a license and some people find it 
easier when they are told what to do.  There are mitigating 
circumstances; we have to take into account that our word is not good 
enough nowadays.

It may be possible to adopt a simpler approach.  You would have to 
overcome the cultural hurdles first.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ipr-wg/current/msg06032.html
2. http://www.ietf.org/mail-archive/web/ipr-wg/current/msg06029.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Jan 2010 14:35:08 -0500

Actually, with regard to the code, I believe that the intention of the 
various streams is identical.  Anyone may take the code and do anything 
with it.  That was the statement the working group made.  The License 
added by the trust was a good faith effort to meet that goal, not a 
statement of the goal.

In specific, there was no intent by the working group to prevent or 
restrict commercial or open source use of the code.   The intend, as I 
understood it, and editted it, was roughly: Anyone can use code from 
RFCs in any way they want.  They may modify it.  They may include it in 
commercial, free, weird, or any other kind of software you can imagine. 
  They are not required to give away their changes.

Yours,
Joel

SM wrote:
>> same license for text.  Both approaches allow derivative works for 
>> code components, but they do so under different licenses.  I'm simply 
>> trying to understand if a more simple approach is possible.
> 
> there are differences when we consider the attitude and requirements of 
> the user-base.  Simon Josefsson commented on the evaluation of the 
> streams.  It is unlikely that the IETF would be sending out letters of 
> "enforcement" anyway as the IETF community is aware of the consequences.
> 
> The IETF community has grown over the years and the culture has changed 
> somewhat.  It would previous consider "attribution" as implicit.  Now, 
> it has to be explicit for people to understand.  Some people may be more 
> comfortable with a license and some people find it easier when they are 
> told what to do.  There are mitigating circumstances; we have to take 
> into account that our word is not good enough nowadays.
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 2010 15:27:30 -0500

--On Saturday, January 30, 2010 14:35 -0500 "Joel M. Halpern"
<[email-masked]> wrote:

> Actually, with regard to the code, I believe that the
> intention of the various streams is identical.  Anyone may
> take the code and do anything with it.  That was the statement
> the working group made.  The License added by the trust was a
> good faith effort to meet that goal, not a statement of the
> goal.
> 
> In specific, there was no intent by the working group to
> prevent or restrict commercial or open source use of the code.
> The intend, as I understood it, and editted it, was roughly:
> Anyone can use code from RFCs in any way they want.  They may
> modify it.  They may include it in commercial, free, weird, or
> any other kind of software you can imagine.   They are not
> required to give away their changes.

Yes, although Joel's comments should be clarified by "with
attribution" as appropriate.  The substantive differences are
about the text, not about the code.  The differences about the
text, in very lay language, are that the IETF Stream needs/wants
to use copyright as one of its tools for maintaining change
control and clarity about the content of standards.  The other
streams don't make standards, so don't have that problem.   By
happy coincidence for the other streams, that eliminates the
code-specific licensing and need to differentiate code from text
that the IETF Stream requires.  

IMO, that actually is pretty simple; I don't know how to make it
more so unless the IETF decides that it doesn't need copyright
over non-code text as part of its change control and related
tools.  And I think even asking that question would require
restarting the WG, etc., etc.

     john