Re: [tlp-interest] Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP)

Hi,

a few questions:

1) Do you have a summary about how that affects the ID boilerplate, 
optimally in text or diff format? Does generation of the new boilerplate 
require additional parameters that were previously not needed?

2) Is there any chance that the introduction of this could be synced 
with other changes, such as those defined in headers-and-boilerplates?

3) Who's going to make the changes to xml2rfc?

Best regards, Julian

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
> 
> 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 
> 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 Documents
> 
> 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 changes is to 
> both make changes necessary to accept these new streams, and to make it 
> 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/policyandprocedures.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
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 