Subject: Draft Trust Policy re: Rights in IETF Documents

From: Ray Pelletier <[email-masked]>
Date: Fri, 18 Jul 2008 07:30:07 -0400

The IETF Trust is considering  adopting a policy for granting rights in 
IETF documents as required by draft-ietf-ipr-outbound-rights-06.txt.  
The IPR WG will be considering this policy during its session on 31 July 
at IETF 72 in Dublin.  Community comments during that session and on 
this list are requested.

The second iteration of that Draft policy dated 7-17-08, along with its 
predecessor dated 7-04-08, can be found at: 
http://trustee.ietf.org/policyandprocedures.html in doc, pdf  and txt 
formats.

Policy areas covered include:
1. Licenses to IETF Documents during the Standards Process
2. Licenses to IETF Documents outside the Standards Process
3. Licenses that are *not* granted
4. License to Code Components
5. Pre-Existing Documents
6. License Limitations
7. Text to be included in IETF Documents

Some changes include:

a. 2ciii
to copy, publish, display and distribute unmodified portions of IETF 
RFCs (ADD - other than Code Components, as defined in Section 3.a below) 
and translations thereof, provided that:

b. 2ciii (y)
all IETF legends, legal notices and indications of authorship contained 
in the original IETF RFC must also be included where
(DELETE - more than one half) (ADD - any substantial portion of  the 
text of an IETF RFC, and in any event where more than one-fifth
of such text),  (DELETE - of an IETF RFC) is reproduced in a single 
document or series of related documents.

c. 2di
any license to modify IETF RFCs (ADD - or portions thereof) (other than 
to make translations (ADD - or to use Code Components
as permitted under the licenses granted under Section 3 of this 
document)) in any context outside the IETF Standards Process,

d. 2f
Termination.  The IETF Trust may terminate any license granted under 
Section 2 of this document if the licensee has, in the
 judgment of the IETF Trust, materially breached the terms of such 
license.  (ADD - For the avoidance of doubt, such right to terminate
 does not apply to licenses granted under Section 3 with respect to Code 
Components.)

e. 3a
For ease of reference, Code Components in IETF RFCs (ADD- MUST be 
clearly identified as code, and one technique for clearly identifying it 
is <CODE BEGINS> <CODE ENDS>.)

f. 3b
Copyright (c) <YEAR>, IETF Trust and (ADD -the persons identified as 
authors listed in the associated RFC.)  All rights reserved.

g. 7f
ADD - For the avoidance of doubt, each Contributor to the IETF Standards 
Process licenses each Contribution that he or she makes as part of the 
IETF Standards Process to the IETF Trust pursuant to the provisions of 
[-Inbound].  No language to the contrary, or terms, conditions or rights 
that differ from or are inconsistent with the rights and licenses 
granted under BCP 78, shall have any effect and shall be null and void, 
whether published or posted by such Contributor, or included with or in 
such Contribution.

The IETF Trust expects to adopt a policy upon the publication of 
RFC[outbound].

Your input is most appreciated.

Ed Juskevicius
Chair
IETF Trust

Ray Pelletier
Trustee
IETF Administrative Director

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 18 Jul 2008 14:39:26 +0200

Ray Pelletier wrote:

Until "7f" that all sounds good, but I'm not sure about "7f":

> ADD - For the avoidance of doubt, each Contributor to the
> IETF Standards Process licenses each Contribution that he
> or she makes as part of the IETF Standards Process to the
> IETF Trust pursuant to the provisions of [-Inbound].  No
> language to the contrary, or terms, conditions or rights 
> that differ from or are inconsistent with the rights and
> licenses granted under BCP 78, shall have any effect and
> shall be null and void, whether published or posted by such
> Contributor, or included with or in such Contribution.

That also sounds right for published RFCs.  But apparently
it's not limited to RFCs and affects *all* Contributions.

At the moment folks can and (rarely) do post drafts with a
"no derivative works" boilerplate.  That's permitted in
I-D.ietf-ipr-3978-incoming, you have that as [-inbound]:

| In these cases the Contributor may include a limitation
| on the right to make derivative works in the form specified
| in the Legend Instructions.

Apparently there is an exception.  Maybe that's perfectly
clear in your text, and I just don't see it (IANAL).

 Frank

---

From: "C.T. Aiken" <[email-masked]>
Date: Fri, 18 Jul 2008 09:55:04 -0400

> it's not limited to RFCs and affects *all* Contributions.

SNIP

> clear in your text, and I just don't see it (IANAL).

I agree with Frank, the disparity needs to be resolved. After looking at
both documents, I couldn't see a way to reconcile the two.

Also, petty point, but it would make sense to strike "for the avoidance of
doubt" from 7f. I don't see what, if anything, it adds.

C.T.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Fri, 18 Jul 2008 11:50:05 -0400

Dropping "for the avoidance of doubt" is fine.  
 
The ability to prohibit derivative works of I-Ds is still allowed, just
as it was under 3978.  See Section 6.b of this document.

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of C.T. Aiken
	Sent: Friday, July 18, 2008 9:55 AM
	To: [email-masked]; [email-masked]
	Subject: Re: Draft Trust Policy re: Rights in IETF Documents

		Until "7f" that all sounds good, but I'm not sure about

		> Contributor, or included with or in such Contribution.

		That also sounds right for published RFCs.  But
apparently
		it's not limited to RFCs and affects *all*
Contributions.

	SNIP

		Apparently there is an exception.  Maybe that's
perfectly
		clear in your text, and I just don't see it (IANAL).

	I agree with Frank, the disparity needs to be resolved. After
looking at both documents, I couldn't see a way to reconcile the two. 
	
	Also, petty point, but it would make sense to strike "for the
avoidance of doubt" from 7f. I don't see what, if anything, it adds. 

	C.T.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 19 Jul 2008 11:00:20 +0200

Ray Pelletier <[email-masked]> writes:

> The second iteration of that Draft policy dated 7-17-08, along with
> its predecessor dated 7-04-08, can be found at:
...
> Your input is most appreciated.

Hi Ray.  One of my earlier comments (#6) that Jorge agreed with doesn't
seem to have been incorporated in the new draft.  Quotes from earlier
discussions below.  Was this simply forgotten, or could you give any
insight to the thinking around this issue?

Thanks,
/Simon

Simon Josefsson <[email-masked]> writes:

> "Contreras, Jorge" <[email-masked]> writes:
>
>>>Simon wrote:
>>
>>> Comment #6:
>>> 
>>> Regarding section 5:
>>> 
>>>    b.  Supersedure. The terms of any license granted under this
>>>    document may be superseded by a written agreement between the IETF
>>>    Trust and the licensee that specifically references and supersedes
>>>    the relevant provisions of this document, except that the 
>>> IETF Trust
>>>    shall in no event be authorized to grant rights with respect to any
>>>    Contribution in excess of those which it has been granted by the
>>>    Contributor.
>>> 
>>> This clause seems problematic for code: I don't want to excerpt code
>>> from an RFC under a BSD license and later find out that the 
>>> license has
>>> been superseded by the GPL.
>>> 
>>> I suspect the intention behind this clause is that _additional_ rights
>>> could be granted by the IETF Trust to some parties.  Is that correct?
>>
>> Correct
>
> Thanks for confirmation.
>
>>> A simple way to solve this would be add another exception: that you
>>> can't negotiate away rights already granted through this document.
>>> Thus, change the text to:
>>> 
>>>    b.  Supersedure. The terms of any license granted under this
>>>    document may be superseded by a written agreement between the IETF
>>>    Trust and the licensee that specifically references and supersedes
>>>    the relevant provisions of this document.  There are two 
>>> exceptions:
>>> 
>>>      i) the IETF Trust shall in no event be authorized to grant rights
>>>      with respect to any Contribution in excess of those which it has
>>>      been granted by the Contributor,
>>> 
>>>      ii) the new terms cannot grant less rights that are 
>>> granted through
>>>      this document.
>>
>> I think that your item (ii) is a great idea.  How about the following
>> tweaks:
>>
>> "ii) the rights granted shall not be less than those otherwise granted
>> under this document."
>
> Excellent.
>
> Thanks,
> Simon

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 19 Jul 2008 09:00:48 -0400

> insight to the thinking around this issue?

Dear Simon;

Isn't this issue covered in part ii of the "Supersedure" paragraph ?

b. Supersedure.  The terms of any license granted under this document  
may be
superseded by a written agreement between the IETF Trust and the  
licensee that specifically
references and supersedes the relevant provisions of this document,  
except that (i) the IETF Trust
shall in no event be authorized to grant rights with respect to any  
Contribution in excess of those
which it has been granted by the Contributor, and (ii) the rights  
granted shall not be less than
those otherwise granted under this document.

Regards
Marshall

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 19 Jul 2008 15:48:08 +0200

> Isn't this issue covered in part ii of the "Supersedure" paragraph ?

My mistake!  I had run wdiff on the two different versions to compare
the changes, and didn't spot this change since it was buried deep inside
the paragraph.

I don't have any further comments on the final proposal.  Thanks for
working with everyone to get feedback on the license text.

Thanks,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jul 2008 10:41:36 +1200

Hi,

You still have two occurrences of "at the beginning", which has confused
tool-writers in the past. You can't require two things to both be
in the same place. I still think "on the first page" is better.

   Brian

On 2008-07-18 23:30, Ray Pelletier wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>