Subject: Last Call for Comments on " Legal Provisions Related to IETF Documents"

From: "Ed Juskevicius" <[email-masked]>
Date: Sun, 10 Aug 2008 23:58:00 -0400

This is to announce that the IETF Trustees have just
posted a revised version of a draft policy on 
"Legal Provisions Related to IETF Documents" dated
08-05-08 at:
http://trustee.ietf.org/policyandprocedures.html

This draft includes all of the changes agreed during
the July 31st meeting of the IPR working group held
in Dublin.

On behalf of the IETF Trustees, we invite your
review and final comments and suggestions on this
policy.  

The IETF Trustees will meet via telechat on Aug 21st
with the goal of finalizing this policy.  If you
have any final comments, please post them on the
IPR WG mailing list.  

Best Regards, and Thanks in advance, 

Ed Juskevicius      Ray Pelletier
Chair               Trustee
IETF Trust          IETF Administrative Director
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Aug 2008 09:38:02 +0200

Thanks for publishing a new version of the document.  There has been
some regressions in this version compared to earlier versions.

#1:

The latest version of the IETF Legal Provisions adds a new section 4.d.:

      d.  Attribution. In addition to the language required under the
      BSD License, each Code Component must be clearly attributed to
      IETF and identify the RFC or other IETF Document or IETF
      Contribution from which it is taken.

That license condition is beyond what the BSD license requires.  That
means the above license clause needs to be included in the license text
of every code copied from a RFC, since the requirement applies to all
material derived from code extracted from an RFC.

It also means that code copied from an IETF document cannot be used as
"BSD code", because the above restriction needs to be preserved in every
modified copy of the code.

This variation of the BSD license is original, and MAY be incompatible
with some free software licenses; at least it does not appear to have
been reviewed for compatibility by anyone familiar with free software
licensing.

It is important to use an already widely reviewed free software license
instead of inventing new licenses!  There are plenty of examples of bad
things that happen if this advice isn't followed, see [1] [2] for two
histories.

Explained in a different way, the above new addition is against what the
IETF has expressed in draft-ietf-ipr-outbound-rights-07.txt:

   As such, the rough consensus is that the IETF Trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired.

The new clause 4.d. is incompatible with the expressed wish of the IETF,
in my reading.  The outbound-rights-07 document doesn't say anything
about preserving attribution for code components.

The concern regarding code attribution was discussed in the IPR WG a
long time ago, when people brought up similar ideas about requiring
attributions.  As far as I could tell, no consensus developed, and
consequently the document didn't say anything related to attribution for
code components.

Please remove section 4.d completely.

#2:

There is another addition to section 4.c of the new document version:

       c.  License. Code Components are hereby licensed to each person
       who wishes to receive such a license on the terms of the “BSD
       License”, as follows (in addition to any licenses granted with
       respect to the text of such Code Components as they appear in
       IETF Contributions or IETF Documents pursuant to Section 3
       above):

The text inside the parenthesis is new.

The use of the word "in addition to" implies that the code components
will NOT be strictly licensed only under the BSD license, but under a
dual-license of the BSD license and the restrictive license (for text in
RFCs) in section 3 of the document.  That is likely what is intended
too: code components should be possible to use just like text from RFCs
under the normal (section 3) IETF rules.

In a dual-license situation, to be able to use the code component under
only the BSD license, the license needs to grant you the right to drop
one of the license texts for it.

This is the same problem as explained in my initial comment on this
document, see #1 in:

http://permalink.gmane.org/gmane.ietf.ipr/5360

What is missing is text such as the following:

  The licensee can chose whether to use the BSD License or the Section 3
  rules when extracting this component.

Once a licensee has extracted a component under the BSD license, that
version cannot later be used under the IETF section 3 rules.

Alternatively, you could adopt the suggestion I made in my initial
comment: clearly say that licensee can use the BSD license as the ONLY
license for extracted code components.  This would avoid much confusion
about which license applies to code components extracted from RFCs.

The text to add would be:

       To clarify, the entire license for Code Components is the above
       BSD license, and if you use this license for a Code Component,
       the license terms in section 3 does not apply to that material.

#3:

The URL given for "common code components" doesn't work:
www.ietf.org/trust/code.

Thanks,
/Simon

[1] http://www.dwheeler.com/essays/gpl-compatible.html
[2] http://www.gnu.org/philosophy/bsd.html

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Aug 2008 08:07:49 -0700

As someone who always prefers the BSD license, I agree with Simon on 
#1 and #2. Saying "BSD except..." means it is a new type of license, 
one that typical implementers will not expect.

One way to look at this is to consider what happens if someone treats 
this as a real BSD license and doesn't give attribution. Is the IETF 
Trust really going to sue them over the lack of attribution? If not, 
why even have that addition to the BSD license? Like in our technical 
protocols, simplicity is good here.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ray Pelletier <[email-masked]>
Date: Tue, 12 Aug 2008 14:00:03 -0400

NEW DOCUMENT Dated 8-12-08

This is to announce that the IETF Trustees have just posted a revised 
version of a draft policy on "Legal Provisions Related to IETF 
Documents" dated 08-12-08 at: 
http://trustee.ietf.org/policyandprocedures.html

There is also a Comparison document and a separate Code Components List.

Below is a summary of the changes and an explanation of them.

On behalf of the IETF Trustees, we invite your review and final comments 
and suggestions on this
policy.

Given these changes, the Trustees will meet via telechat on September 
4th with the goal of
finalizing this policy. If you have any final comments, please post them 
on the
IPR WG mailing list.

Thanks

Ray Pelletier
IAD
Trustee

Summary of Changes

1. Intro -- changed "this document" to "these Legal Provisions" 
throughout the document.

2. Applicability -- moved Section 4 up to Section 2 for better flow.

2.a Effective Date -- Inserted a specific date for the effectiveness of 
the document, as discussed in Dublin.
2.b Effectiveness -- the Legal Provisions apply to IETF Contributions 
that are submitted after effectiveness, and to IETF Documents that are 
published after effectiveness.

3.a and 3.c Licenses -- the licenses now apply to IETF Contributions and 
IETF Documents in most places

3.c and 4.c Code -- clarified that Code included in IETF Documents can 
be reproduced and modified per the document licenses, while Code 
intended for execution is covered by the BSD License under Section 4.

3.c.iii.y Substantial Portion -- I was not sure whether there was 
consensus regarding the amount of text that could be extracted without 
applying the full RFC text/legends.

3.d Licenses Not Granted -- removed reference to disallowance of 
publishing I-Ds outside the IETF Standards Process.

3.f Termination -- deleted, per Dublin discussion

4.a Code Definition -- moved list of common code components to a URL

4.c Copyright notice -- changed notice in BSD license to reflect that 
this license now covers code from all IETF Contributions and Documents, 
not only RFCs.

4.d Attribution -- added a clause requiring identification of the 
relevant IETF Document/Contribution, per Dublin discussion.

6 Required Text -- added "on the first page" per Dublin discussion.

6.b Copyright Notice -- moved up from 6.c for improved flow. Also 
tweaked the text of the copyright notice to be more flexible, "IETF 
Trust and the persons identified as its authors"

7.e Definitive Version -- added a sentence to address the point about 
translations of these Legal Provisions.

Ed Juskevicius wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Aug 2008 09:33:38 +1200

How about adding some weasel words, or even simply making the
attribution requirement a "should"? I think it's perfectly reasonable
to ask for attribution when possible, so any form of words that
doesn't "break" the BSD license in a narrow legalistic sense
would do fine for me.

It's not like we're asking for much:

# This code was derived from IETF RFC XXXX. Please retain this comment if possible.

    Brian

On 2008-08-13 03:07, Paul Hoffman wrote:
> As someone who always prefers the BSD license, I agree with Simon on #1
> and #2. Saying "BSD except..." means it is a new type of license, one
> that typical implementers will not expect.
> 
> Trust really going to sue them over the lack of attribution? If not, why
> even have that addition to the BSD license? Like in our technical

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Aug 2008 16:04:28 -0700

># This code was derived from IETF RFC XXXX. Please retain this 

I would prefer a request to weasel words because it would be clearer.

   Please give attribution of the source of the code in the code itself,
   such as "This code was derived from IETF RFC XXXX".

--Paul Hoffman, Director
--VPN Consortium

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 13 Aug 2008 02:13:52 +0200

Brian E Carpenter wrote:

> attribution requirement a "should"?

I tend to forget the details, but IIRC we have a SHOULD for an
attribution elsewhere (not in the part about code).  If that is
very clear folks might arrive at the conclusion that it's also
*desired* for code snippets.  But not *required*.

> # This code was derived from IETF RFC XXXX. Please retain this

Not fair.  We can't put code with similar statements in an RFC
in some cases, where somebody also didn't "ask for much", just
a beerware licence or copyright note or similar.  Therefore we
should also not "ask for much" from others if there's a chance
that this is too much.

 Frank

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Aug 2008 08:46:02 -0400

On Tuesday 12 August 2008 19:04, Paul Hoffman wrote:
>    such as "https://shipit.ubuntu.com/specialrequest
>
I'd suggest being even more subtle.  

The copyright statement cannot be removed (and that is fine with any license 
that I'm aware of), so it will always be clear that the code came from an 
RFC.  I believe that the IETF is sufficiently notable that the IETF standard 
copyright notice is roughly sufficient for this.

What this lacks is knowing which RFC it came from.  This is technically 
useful, but is not an IPR issue.

My suggestion is adopt a rule that code snippets in any RFC MUST include a 
comment to the effect that "This code was derived from IETF RFC XXXX".  If 
it's in the code snipppet as a comment to copy/paste virtually everyone will 
copy/paste it.  I suspect that those that wouldn't aren't likely to be 
significantly deterred by a license statement.

Once it's a documented requirement and it's on the ID nits checklist, I 
suspect that solves 99% of the problem with no license incompatibility risk.

Scott K

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Aug 2008 15:24:19 +0200

> suspect that solves 99% of the problem with no license incompatibility risk.

Adding a comment like that seems like a good idea, and having it on the
ID nits checklist seems equally useful.  So +1.  However I don't see any
point in the MUST here.

/Simon

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Aug 2008 10:34:58 -0400

>ID nits checklist seems equally useful.  So +1.  However I don't see any
Agreed, but since some people wanted a legal requirement that such a 
statement be in the code (much stronger than any IETF MUST), it seems like 
what would be wanted.  Personally, I'd say should is plenty.

My main point is that this isn't fundamentally an IPR issue, it's a 
technical/convenience issue.  There are standard ways to deal with such 
issues without getting lawyers involved.

Scott K

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Aug 2008 10:36:36 -0700

>useful, but is not an IPR issue.

The "knowing which RFC it came from" is the point made at the
last IPR WG meeting (by Bill Fenner, I believe, but it is not explicit
in the minutes, so I'm not sure).  While I agree that it is not an IPR
issue, it is a standards process issue.  Without the RFC Number, the
link to feed back into the standards process is too weak to work.
If someone finds a problem, optimization, or has a question,
they are stuck, and the community loses a chance to benefit.

>significantly deterred by a license statement.

This sounds reasonable to me; thanks for the suggestion.

			regards,
				Ted Hardie

---

From: Ray Pelletier <[email-masked]>
Date: Thu, 14 Aug 2008 08:32:46 -0400

Ooops, wrong version.  But it has been corrected.

Ray

Ray Pelletier wrote:

> On behalf of the IETF Trustees, we invite your review and final 
> comments and suggestions on this
> policy.
>
> finalizing this policy. If you have any final comments, please post 
> them on the
> IPR WG mailing list.
>
> Thanks
>
> Ray Pelletier
> IAD
> Trustee
>
> Summary of Changes
>
> 2.a Effective Date -- Inserted a specific date for the effectiveness 
> of the document, as discussed in Dublin.
> 3.a and 3.c Licenses -- the licenses now apply to IETF Contributions 
> and IETF Documents in most places
>
> this license now covers code from all IETF Contributions and 
> Documents, not only RFCs.
>
>------------------------------------------------------------------------
>

---

From: "George Willingmyre" <[email-masked]>
Date: Thu, 14 Aug 2008 09:06:51 -0400

relevant recent legal decision  http://www.patentlyo.com/patent/2008/08/open-source-lic.html

8/13 Open Source License Conditions Enforceable Through Copyright Law
Jacobson v. Katzer (Fed. Cir. 2008) 

In an interesting decision, the CAFC held that open source license conditions are enforceable under the copyright laws. Jacobson's open source license at issue here allowed anyone to use his software so long as his conditions are met (such as making any modified code freely available). 

Copyright vs Contract: The district court held that violation of the open source conditions are remedied through a contract claim rather than copyright. The CAFC sided with the copyright holder - holding that "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material.

George T. Willingmyre, P.E.
GTW Associates
1.301.421.4138
www.gtwassociates.com
  ----- Original Message ----- 
  From: Ray Pelletier 
  To: Ray Pelletier ; Ed Juskevicius ; [email-masked] ; IETF Discussion 
  Sent: Thursday, August 14, 2008 8:32 AM
  Subject: Re: Last Call for Comments on " Legal Provisions Related to IETFDocuments"

  Ray

  Ray Pelletier wrote:

    This is to announce that the IETF Trustees have just posted a revised version of a draft policy on "Legal Provisions Related to IETF Documents" dated 08-12-08 at: http://trustee.ietf.org/policyandprocedures.html

    On behalf of the IETF Trustees, we invite your review and final comments and suggestions on this
    policy.

    Given these changes, the Trustees will meet via telechat on September 4th with the goal of 
    finalizing this policy. If you have any final comments, please post them on the
    IPR WG mailing list. 

    Thanks

    Ray Pelletier
    IAD
    Trustee

    Summary of Changes

    1. Intro -- changed "this document" to "these Legal Provisions" throughout the document.

    2.a Effective Date -- Inserted a specific date for the effectiveness of the document, as discussed in Dublin.
    2.b Effectiveness -- the Legal Provisions apply to IETF Contributions that are submitted after effectiveness, and to IETF Documents that are published after effectiveness.

    3.a and 3.c Licenses -- the licenses now apply to IETF Contributions and IETF Documents in most places

    3.c and 4.c Code -- clarified that Code included in IETF Documents can be reproduced and modified per the document licenses, while Code intended for execution is covered by the BSD License under Section 4.

    3.c.iii.y Substantial Portion -- I was not sure whether there was consensus regarding the amount of text that could be extracted without applying the full RFC text/legends.

    3.d Licenses Not Granted -- removed reference to disallowance of publishing I-Ds outside the IETF Standards Process.

    4.c Copyright notice -- changed notice in BSD license to reflect that this license now covers code from all IETF Contributions and Documents, not only RFCs.

    4.d Attribution -- added a clause requiring identification of the relevant IETF Document/Contribution, per Dublin discussion.

    6.b Copyright Notice -- moved up from 6.c for improved flow. Also tweaked the text of the copyright notice to be more flexible, "IETF Trust and the persons identified as its authors"

    7.e Definitive Version -- added a sentence to address the point about translations of these Legal Provisions. 

    Ed Juskevicius wrote:

  ----------------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

------------------------------------------------------------------------------