Subject: I-D ACTION:draft-ietf-ipr-3978-incoming-00.txt

From: [email-masked]
Date: Thu, 01 Mar 2007 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Intellectual Property Rights Working Group of the IETF.

	Title		: Rights Contributions provide to the IETF Trust
	Author(s)	: S. Bradner, J. Contreras
	Filename	: draft-ietf-ipr-3978-incoming-00.txt
	Pages		: 18
	Date		: 2007-3-1

   The IETF policies about rights in Contributions to the IETF are
   designed to ensure that such Contributions can be made available to
   the IETF and Internet communities while permitting the authors to
   retain as many rights as possible. This memo details the IETF
   policies on rights in Contributions to the IETF. It also describes
   the objectives that the policies are designed to meet.  This memo
   obsoletes RFC 3978 and, with RFC 3979 and RFC xxx (-outgoing),
   replaces Section 10 of RFC 2026.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-3978-incoming-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ipr-3978-incoming-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipr-3978-incoming-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 Mar 2007 12:16:57 +0100

Please clarify whether section 7 is normative or not.

I recall that Scott Bradner referenced to section 7 as an argument
that the IETF policy grants third parties various rights, but I
believe such an argument is flawed.  The title of section 7 is:

7. Exposition of Why These Procedures Are the Way They Are

Thus I believe the entire chapter was intended to be non-normative.

It is unfortunate that text in section 7 may not appear to say the
same as the normative part of the document, but making it clear that
section 7 is non-normative would be a good starting point.  We can fix
the factual problems in section 7 later.

Therefor, I suggest inserting as the first sentence in section 7 the
following:

   This entire section is not normative.  Thus, in case of conflict
   with normative text on a subject, the normative text has priority.

What do you think?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 02 Mar 2007 12:43:16 +0100

All,

As far as I can see, this document leaves no rights granted to third
parties.  That is against both RFC 2026 and RFC 3978.  RFC 2026 grants
third parties rights in the boiler plate, section 10.4

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
                      ^^^^^^
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         ...

RFC 3978 section 3.3 was intended to do the same, but the wordings
were poorly chosen, and the third parties now granted rights only
include the loosely defined recipient "IETF":

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual
                                            ^^^^
      property rights in the Contribution:

However, to clarify, Jorge has said that the following term in RFC
3978 section 3.3 give third parties additional rights directly:

      (E) to extract, copy, publish, display, distribute, modify and
          incorporate into other works, for any purpose (and not limited
                                                         ^^^^^^^^^^^^^^^
          to use within the IETF Standards Process) any executable code
          or code fragments that are included in any IETF Document (such
          as MIB and PIB modules), subject to the requirements of

This text is not clear, I believe it speaks about intended use, not
intended recipients.  However, Jorge's opinion indicates that RFC 3978
also grant rights directly to third parties.

It may be useful to look at the IPR WG charter about this document:

- An update to RFC 3978 (BCP) that attempts to specify a complete set
  of rights with respect to derivative works granted to the IETF by
  authors, as well as technical updates necessitated by the existence
  of the Trust

The way I read that is that this document has the specific scope of
talking about rights granted to the IETF.  Thus, it should not
restrict what rights are granted to third parties by RFC 3978, and let
that part of RFC 3978 remain in effect.  There seem to be a conflict
between the WG charter and with the documents' claims that it
obsoletes RFC 3978.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 02 Mar 2007 08:29:35 -0500

I apparently understand the goal slightly differently from the way Simon does.
I agree that -incoming does not talk about direct grants of third 
party rights in documents.
That's because we (the working group) agreed on the -incoming / 
-outbound split whereby the -outbound document describes all rights 
granted to others in IETF contributions, while -inbound talks about 
the rights the authors grant to the IETF in 
contributions.  (-incoming rights clearly needing to be a superset of 
-outbound.)  Hence, it is almost inevitable that this is going to 
tighten up the 3978 language that provides indirect grants.

Yours,
Joel M. Halpern

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Mar 2007 15:53:16 +0100

If we are strict, the normative text in -incoming must only
obtain rights, to be vested in the IETF Trust, and then the
Trust must give the outgoing rights, in accordance with
the advice in -outbound. But logically, -incoming could
meet this test by saying the equivalent of

   Contributor must grant to the Trust necessary and
   sufficient rights for the Trust to be able to grant the
   following outbound rights to third parties: XXXX, YYYY, ...

      Brian

On 2007-03-02 14:29, Joel M. Halpern wrote:
> I agree that -incoming does not talk about direct grants of third party 
> rights in documents.
> granted to others in IETF contributions, while -inbound talks about the 
> rights the authors grant to the IETF in contributions.  (-incoming 
> rights clearly needing to be a superset of -outbound.)  Hence, it is 
> almost inevitable that this is going to tighten up the 3978 language 
> that provides indirect grants.
> 
> Yours,
> Joel M. Halpern
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 03 Mar 2007 12:16:42 +0100

Simon Josefsson wrote:
> parties. 
The intent of this document is that it should say what rights others 
grant to the IETF Trust, so that the IETF Trust can follow the 
instructions in -outgoing and grant rights to third parties according to 
current IETF policy. (Currently, I believe -outgoing says that those 
grants should be irrevocable - just mentioning that so that nobody feels 
they have to raise the issue of revocation again).

So if you can't find any rights granted in this document, the document 
is as was intended. If you can help us find and remove any text that 
seems to say that the document should have granted rights to others, 
that is a Good Thing.

                 Harald