headers
Russ Housley | 7 Jan 20:52

Simplified BSD License for Code Components

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
Permalink | Reply | 16 comments |
headers
Cullen Jennings | 7 Jan 21:25
Picon
Favicon
Gravatar

Re: Simplified BSD License for Code Components


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
> Ipr-wg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipr-wg
Permalink | Reply | 0 comments |
headers
Russ Housley | 7 Jan 21:52

Re: Simplified BSD License for Code Components

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 <housley <at> vigilsec.com> 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
Permalink | Reply | 1 comment |
headers
SM | 8 Jan 01:06

Re: Simplified BSD License for Code Components

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,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Simon Josefsson | 8 Jan 08:53
Favicon
Gravatar

Re: Simplified BSD License for Code Components

Russ Housley <housley <at> vigilsec.com> writes:

> 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.

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

> Russ
>
> On Thu, Jan 7, 2010 at 11:52 AM, Russ Housley <housley <at> vigilsec.com> wrote:
>> The IETF Stream requires that code extracted from an RFC be put under the
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 8 Jan 12:00

Re: Simplified BSD License for Code Components


--On Thursday, January 07, 2010 14:52 -0500 Russ Housley
<housley <at> vigilsec.com> 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,

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.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Brian E Carpenter | 8 Jan 20:37
Picon

Re: Simplified BSD License for Code Components

On 2010-01-09 00:00, John C Klensin wrote:
> 
> --On Thursday, January 07, 2010 14:52 -0500 Russ Housley
> <housley <at> vigilsec.com> 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,
> 
> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Freek Dijkstra | 16 Jan 02:24
Picon
Favicon
Gravatar

Determine the stream of an RFC

The Legal Provisions Relating to IETF Documents,
http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm,
make an important distinction between documents in the IETF Stream and
documents in Alternative Streams, such as independent submissions.

Given a RFC, how can I determine its stream, and thus its license?

In most cases, I can guess based on the authors, or the category.
However, this will not be fool-proof. For example, RFC 5745 is clearly
part of the IAB stream, thus according to part 8b of the IETF TLP, part
of Alternate Stream. However, it does contain the boilerplate text of 6
b i (for the IETF stream), instead of the boilerplate text of 6 b ii
(for the alternate stream).

Would it be useful to explicitly include the stream in the boilerplate
text of the Copyright Notice section, so that the appropriate license
terms are clear for all readers?

Regards,
Freek Dijkstra
Permalink | Reply | 3 comments |
headers
Russ Housley | 16 Jan 23:48

Re: Determine the stream of an RFC

Freek:

> The Legal Provisions Relating to IETF Documents,
> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy-20091228.htm,
> make an important distinction between documents in the IETF Stream and
> documents in Alternative Streams, such as independent submissions.
>
> Given a RFC, how can I determine its stream, and thus its license?

Please see http://www.rfc-editor.org/rfc/rfc5741.txt

The upper left hand corner of the title page tells you the RFC stream.

Russ
Permalink | Reply | 2 comments |
headers
Freek Dijkstra | 17 Jan 11:11
Picon
Favicon
Gravatar

Re: Determine the stream of an RFC

Russ Housley wrote:

>> Given a RFC, how can I determine its stream, and thus its license?
> 
> Please see http://www.rfc-editor.org/rfc/rfc5741.txt
> 
> The upper left hand corner of the title page tells you the RFC stream.

Thanks, I missed that one! (and xml2rfc v1.35pre1 still produces the old
headers with "Network Working Group").

Just an observation. I'm trying to create a independent submission I-D
(to register a urn prefix for another standardization body), and with
the fuss on the non-free nature of RFC licenses (derivate works may only
be made within the IETF), I wanted to make sure that contributors in the
other standardization body could freely re-use texts from the RFC for
documents in their standardization body. I found the answer: they can,
but also wanted to make sure this is immediately obvious. The later is
certainly not the case (yet). I found the copyright notice rather vague:
it refers to the TLP, which is not very clear -- you first have to
figure out that the license differs wildly depending on the document
stream, then figure out what the document stream is, which stream the
document in question belongs to, and finally grasp the license rights
for this particular stream. To me this contrasts sharply with let's say
the creative commons license where it is immediately obvious what the
rights are.

Likely is is just me, but I got lost in the document jungle. For
example, I was looking for the correct boilerplate, and read:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane