Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP) (November 25, 2009)

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/policies-and-procedures.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", asdescribed below. If a licensee elects to apply the BSD License to a Code Component, then the additional licenses and restrictions set forth in Section 3 and elsewhere in these Legal Provisions shall not apply thereto. ***Note that this license is specifically offered for IETF Documents and may not be available for Alternate Stream documents. See Section 8 for licensing information for the appropriate stream.***

Section 8. Application to non-IETF Stream Documents

[Note: This language added to IAB, IRTF and Indep Submissions paragraphs: ***Section 4 of these Legal Provisions shall not apply to documents in the [Stream], and all references to Section 4 hereof shall be disregarded with respect to documents in the [Stream]***]

e. IAB Document Stream. Pursuant to Section 11 of RFC 5378, the IAB requested, as of April 4, 2008, that the IETF Trust act as licensing administrator for the IAB Document Stream and that these Legal Provisions be applied to documents submitted and published in the IAB Document Stream following the Effective Date of RFC 5378. ***Section 4 of these Legal Provisions shall not apply to documents in the IAB Document Stream, and all references to Section 4 hereof shall be disregarded with respect to documents in the IAB Document Stream*** *** pursuant to [Refefrence] published on [DATE]***. [Note: this last addition reflects the authority for the Elimination of BSD licensing for the IAB]

f. Independent Submission Stream. Pursuant to RFC [xxxx] published on [DATE], the manager of the Independent Submission Stream has requested that the IETF Trust act as licensing administrator for the Independent Submission Stream and that these Legal Provisions be applied to documents submitted and published in the Independent Submission Stream following [DATE]. *** Section 4 of these Legal Provisions shall not apply to documents in the Independent Submission Stream, and all references to Section 4 hereof shall be disregarded with respect to documents in the Independent Submission Stream.***

g. IRTF Document Stream. Pursuant to RFC [xxxx] published on [DATE], the manager of the IRTF Document Stream has requested that the IETF Trust act as licensing administrator for the IRTF Document Stream and that these Legal Provisions be applied to documents submitted and published in the IRTF Document Stream following [DATE]. ***Section 4 of these Legal Provisions shall not apply to documents in the IRTF Document Stream, and all references to Section 4 hereof shall be disregarded with respect to documents in the IRTF Document Stream.***

B.) Addition of Alternate Stream managers to warranty disclaimer

This action requires revision to two sections, 7.a and 8.c.ii.

7. Terms Applicable to All IETF Document

ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY, THE IETF TRUST, THE INTERNET ENGINEERING TASK FORCE *** AND ANY APPLICABLE MANAGERS OF
ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW***, DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

8. Application to non-IETF Stream Documents
c. Alternate Stream License.

ii. Each occurrence of the term "IETF Contribution" and "IETF Document" in these Legal Provisions shall be read to mean a Contribution or document in such Alternate Stream, as the case may be. ***The disclaimer in Section 7.a of these Legal Provisions shall apply to the manager of such Alternate Stream as defined in RFC 4844 as though such manager were expressly listed in Section 7.a.***

C.) The 23 October announced changes

The 23 October changes are required based upon a request from the RFC Editor on behalf of the Independent Submissions Stream, and from the IRTF Steering Group (IRSG) on behalf of the IRTF Stream (Alternate Streams) that the IETF Trust act as the license administrators for the RFCs produced by their streams. The basic intent of these license administrators for the RFCs produced by their streams. The basic intent of these possible for these new streams to operate under "Postel Rules." Additional minor changes are sought by the Trustees to clarify language in TLP 3.0.

The Trustees believe the following changes are necessitated by the request of the RFC Editor and IRSG,

a. Section 1. -- eliminated reference to "IETF Standards Process" to broaden scope for Alternate Streams. Also added a sentence acknowledging the addition of Alternate Streams.

b. Section 6.a -- deleted "to IETF" so that this legend can be used in Alternate Stream documents in a less confusing way.

c. Section 7.f -- removed references to IETF Standards Process to accommodate Alternate Stream usage.

d. Section 8.a -- this paragraph provides some background/context for readers who have not been following the Alternate Stream discussion. It references RFC 4844 (which defines the Alternate Streams).

e. Section 8.b -- this paragraph says that Alternate Stream managers (as defined in 4844) can request that the IETF Trust act as the licensing administrator for their Alternate Stream documents, and that the Trust will do this, acting in accordance with their request and the Trust's legal obligations.

f. Section 8.c -- this paragraph contains the basic license grants for the Alternate Streams. Essentially, Alternate Stream contributions are licensed TO the Trust on the terms of 5378, and are licensed BY the Trust on the terms of the TLP (subject to any exceptions noted in later paragraphs).

g. Section 8.d -- IMPORTANT: clarifies that Alternate Stream contributors must ensure that they have all necessary rights to make their contributions, including the right to contribute previously-published material. There is no pre-5378 legend/carve-out for Alternate Stream documents, and authors of contributions in these streams take full responsibility for the entire contents of their contributions, whether or not they re-use older material. This is a different approach than for IETF Contributions, which have the pre-5378 legend escape-valve for older material.

h. Section 8.e - g -- there is a separate paragraph for each of the IAB, Independent and IRTF streams. Each of their "requests" to the Trust is made in a separate document and may have a different effective date, so it seemed cleaner to treat them separately. In each of these paragraphs there is a clause stating that there are no limits on making derivative works of these documents unless specific no-derivatives legends are included.

The changes requested by the Trustees are as follows:

i. Section 2.c -- bug fix: first reference was to contributions and documents, second was only to documents. "Contributions" was added for parallel construction.

j. Sections 4.e, 6.b and 6.d -- added "Simplified" before "BSD License" for consistent usage.

The proposed revisions as TLP 4.0 are in rtf, pdf and doc formats and located at: http://trustee.ietf.org/policies-and-procedures.html
under Draft Policies and Procedures for IETF Documents. There is also a 3.0 diff file in doc and pdf formats at the same location.

The discussion of these proposed changes is taking place on the TLP-interest mailing list. One may subscribe to the TLP mailing list at: https://www.ietf.org/mailman/listinfo/tlp-interest

If during the 30 day community review period the proposal is revised, the Trust may withdraw or modify the proposal, publish it and reset the counter to begin a new 30 day review period before the comment period is over.

If textual changes are needed after the 30 day community review period, the Trust may modify the proposal, publish it and announce a 14 day review period.

Please accept this message as a formal request by the IETF Trustees for your review and feedback on the proposed revision to the TLP document. The comment period will end on December 27, 2009.

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair