Marshall Eubanks | 25 Nov 2009 22:35
Picon

Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP)

Greetings;

The Trustees are proposing additional changes to the Legal Provisions  
Relating to IETF Documents effective September 12, 2009 (TLP 3.0).  
This is a formal request for community review, with a 30 day review  
period ending on December 27, 2009

The additional changes proposed here (TLP 4.1) are A.) at the request  
of the Alternate Stream managers regarding the treatment of 'code  
components' and B.) at the request of the community regarding the  
addition of Alternate Stream managers to the warranty disclaimer.  
These changes result from the discussion of the proposed changes  
announced on 23 October, which are included in this document for  
review as section C. PDF versions and differences between the existing  
TLP are available at http://trustee.ietf.org/policyandprocedures.html.

A.)  Elimination of BSD licensing for Alternate Stream documents

This action requires revisions to four sections: 4.c, 8.e, 8.f, and  
8.g as follows: [Note *** indictes begin and end added text)

Section 4.	License to Code Components.

c.	License.    In addition to the licenses granted under Section 3,  
unless one of the legends contained in Section 6.c.i or 6.c.ii is  
included in an IETF Document containing Code Components, such Code  
Components are also licensed to each person who wishes to receive such  
a license on the terms of the “Simplified BSD License", as described  
below.  If a licensee elects to apply the BSD License to a Code  
Component, then the additional licenses and restrictions set forth in  
(Continue reading)

Marshall Eubanks | 25 Nov 2009 22:35
Picon

Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP)

Greetings;

The Trustees are proposing additional changes to the Legal Provisions  
Relating to IETF Documents effective September 12, 2009 (TLP 3.0).  
This is a formal request for community review, with a 30 day review  
period ending on December 27, 2009

The additional changes proposed here (TLP 4.1) are A.) at the request  
of the Alternate Stream managers regarding the treatment of 'code  
components' and B.) at the request of the community regarding the  
addition of Alternate Stream managers to the warranty disclaimer.  
These changes result from the discussion of the proposed changes  
announced on 23 October, which are included in this document for  
review as section C. PDF versions and differences between the existing  
TLP are available at http://trustee.ietf.org/policyandprocedures.html.

A.)  Elimination of BSD licensing for Alternate Stream documents

This action requires revisions to four sections: 4.c, 8.e, 8.f, and  
8.g as follows: [Note *** indictes begin and end added text)

Section 4.	License to Code Components.

c.	License.    In addition to the licenses granted under Section 3,  
unless one of the legends contained in Section 6.c.i or 6.c.ii is  
included in an IETF Document containing Code Components, such Code  
Components are also licensed to each person who wishes to receive such  
a license on the terms of the “Simplified BSD License", as described  
below.  If a licensee elects to apply the BSD License to a Code  
Component, then the additional licenses and restrictions set forth in  
(Continue reading)

Todd Glassey | 26 Nov 2009 17:43
Picon
Favicon

Re: Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP)

Marshall Eubanks wrote:
> Greetings;
>
> The Trustees are proposing additional changes to the Legal Provisions 
> Relating to IETF Documents effective September 12, 2009 (TLP 3.0). 
> This is a formal request for community review, with a 30 day review 
> period ending on December 27, 2009

Cool the Charter and History statement has a couple of typos in it which 
create contract loopholes. The first is the use of the phrase "certain 
existing and future intellectual properties"

There are two failings in this - the first is that the idea was not that 
there were 'certain properties exempted from the IETF's trust ownership 
moving forward' and this statement clearly says there is but the rest of 
the document fails to support that or provide the processes for 
submitting around the trust-assignment.The statement should be revised 
to read "certain existing as can be converted or assigned to the Trust 
and all future intellectual properties"...

But there is a MUCH LARGER screw up here and that is that RFC2026 cannot 
be legally turned off - and anyone can in fact file a document with the 
IETF under the terms of RFC2026 still today. It has to do with how the 
IETF at that time set up policy and control for the use of that IP which 
can now in my opinion never be redacted or its use under those terms 
existing at the time be prevented. All someone has to do is file a 
current IETF submission under those terms and the refusal to accept it 
will constitute contractual breach in my opinion. So 5378 is relatively 
meaningless from a legal perspective unless Jorge wants to tell us all 
why this is not true.
(Continue reading)

Russ Housley | 29 Nov 2009 20:11

Re: Question about BCP79's Section 4a and its Section 4.1

I believe that it was argued that IETF-stream RFCs should include a 
pointer to the place where a reader can find any IPR statements that 
have been issued.  That way, the reader can locate the statements, 
even if they are issued well after the RFC is published.

Russ

At 12:39 PM 11/29/2009, Todd Glassey wrote:
>Folks
>in reading section 4a of BCP79 it raises a specific set of questions 
>- the first of those being per this section it seems to me that a 
>new IPR Header Page needs to be formally added to the RFC template 
>and to the I-D template as well; Seriously this clearly says that 
>there will be a formal disclosure as part of the RFC (or I-D) that 
>ties that document formally to any IPR's filed in that Working 
>Group's Efforts for that protocol.
>
>Just read BCP79 itself... its at http://www.ietf.org/rfc/rfc3979.txt
>
>Section 4.a
>------------
>Actions for Documents for which IPR Disclosure(s) Have Been Received 
>(A) When any Intellectual Property Right is disclosed before 
>publication as an RFC, with respect to any technology or 
>specification, described in a Contribution in the manner set forth 
>in Section 6 of this document, the RFC Editor shall ensure that the 
>document include a note indicating the existence of such claimed 
>Intellectual Property Rights in any RFC published from the 
>Contribution. (See Section 5 below.)
>-------------------
(Continue reading)


Gmane