Subject: WG Last Call on draft-ietf-ipr-rules-update-07.txt

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 28 Jul 2006 12:31:48 -0400

I would like to do a quick (one week) WG Last Call on
draft-ietf-ipr-rules-update-07.txt.  As Lucy explained in Montreal, there
is some urgency in changing the boilerplate to refer to the IETF Trust
instead of ISOC.

The full rationale for this draft was given by Jorge in his list posting
(http://www1.ietf.org/mail-archive/web/ipr-wg/current/msg04305.html).  As
he noted, it fixes the Trust issue and some other minor matters; it is not
a full update to 3978, and the WG *will* continue to work on that.

If the WG is unhappy with this draft, we will proceed with
draft-ietf-ipr-ietf-trust-update-00.txt instead, a draft that changes
nothing but the ISOC->Trust text.  However, I'd prefer if we adopted 
draft-ietf-ipr-rules-update-07.txt instead.  (Of course, neither draft
takes effect until the Trustees have accepted it.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jul 2006 21:29:48 +0200

The -07 draft is completely different from -06!  It is not a small
modifications.

Given that I'm in the middle of a month-long vacation, I cannot dig up
my problems with -06 and post them as a WGLC comment.  I have to read
the -07 document from scratch.  Others may have similar experiences,
and this suggests to me that a WGLC on rules-update-07 is premature.

First, after a short read-through, the rewritten -07 seem to be much
clearer and more readable than -06.  Nice work!

-07 is still in the form of a delta, which makes it difficult to read
the license, and I thought the majority of people favored a full
update?

-07 discusses both inbound and outbound rights, which I thought we
agreed to separate?

Discussing outbound rights to third parties in the document would seem
to me to close the discussion on this issue.  I think that would be
premature.

The document dodges the issue of defining code vs text.  The WG have
discussed this extensively, and to ignore all of that discussion and
use the RFC 2026-style distinction seem to poorly reflect the WG's
work.

I want to run the license granted to third parties with lawyers and
organizations like the FSF and Debian.  This takes several weeks.

A nit, the term "IETF Participant is not defined as far as I can tell.

Another nit, the abstract suggest that this document have very limited
impact.  Given the changes to the license in the document, this would
be incorrect.  I hope this was an oversight, and that we don't try to
hide license changes under the preface of administrative
modifications.

Conclusion:

I cannot review a new legal document within one week, especially
during the one month in the year where many people have vacations (at
least in Europe).  I doubt any serious WG member can do a good review
of a document in one week.  I don't think we can claim any useful
consensus on -07.

I think it would be useful if Joel's document progressed further, and
those ideas were incorporated into future versions of rules-update.

Given that no other choice is given, my preference is trust-update-00
and (more importantly) to continue discussing and decide on the other
issues.

Frankly, I'm worried about how resolving these issues is turning out.
Do a one-week WGLC of a rewritten core WG document that nobody has
reviewed?  What's the next step?

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 29 Jul 2006 13:14:42 +0200

In this message, I review rules-update-07 from this aspect:

  Assume that rules-update-07 is approved, what problems will we have
  later on?

It seems to me that the inbound license in the new section 3.3 is
tightly bound to the outbound license in the new section 3.7 and 3.8.

The reason for that is this text in the new section 3.3, and in
particular the highlighted part:

      3.3.  Rights Granted by Contributors to IETF Trust

      To the extent that a Contribution or any portion thereof is
      protected by copyright or 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 IETF Trust under all such copyrights and
      other rights in the Contribution, provided that the IETF Trust
      shall have the right to sublicense these rights solely to the
                                                     ^^^^^^^^^^^^^^
      extent described in Section 3.7 and 3.8 below:
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Therefor, the IETF Trust cannot grant IETF participants or third
parties additional rights (beyond 3.7/3.8) to future documents, even
when the IETF Trust holds all rights to the document.

The IETF Trust is effectively bound by the outbound license in section
3.7 and section 3.8 forever, unless the inbound license is changed
too.

Several people have stated that they want to separate inbound rights
from outbound rights.  I believe that is a good idea, and that the
document should reflect this.

Given that we don't know what the outbound license from the IETF
should be, I believe we shouldn't restrict the IETF Trust from
following the IETF's wishes in this area.

If the IETF Trust is granted all rights to documents, and all
capabilities to sub-license those rights further, this problem
wouldn't exist.

We can solve this by removing the text from the first paragraph that I
highlighted above.

Note that this is not a conclusive review.  There may be other fatal
problems in -07 that will restrict the IETF Trust from implementing
the IETF's wishes for documents published under the rules-update-07
policy.  Thus, this should not be read as endorsement of
rules-update-07 if the document is modified.  One week to review a
legal document is not enough.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 29 Jul 2006 14:20:43 +0200

I noted earlier that the term "IETF Participant" is not defined in
rules-update-07, and this led me to investigate how other terms in the
license are defined and used.

The inbound license use the term "Contributions" but the outbound
license (to third parties, reproduced below) use the term "IETF
Document".  A "Contribution" seem to be about everything that is
submitted to the IETF (see RFC 3978 for the full definition), but
"IETF Document is more limited:

   h. "IETF Documents":  RFCs and Internet-Drafts except for Internet-
      Drafts that are RFC Editor Contributions and the RFCs that are
      published from them.

Which builds on:

   f. "RFC Editor Contribution": An Internet-Draft intended by the
      Contributor to be submitted to the RFC Editor for publication as
      an Informational or Experimental RFC but not intended to be part
      of the IETF Standards Process.

Ok, so now the rights granted to third parties only cover documents on
the standards track.  No rights whatsoever are granted to third
parties for Informational or Experimental RFCs.

For whatever reason, many important RFCs are published as
Informational today.

The most important examples are RFCs for cryptographic primitives.
These often contain source code which are useful to extract.  For
example, RFC 3610, RFC 4493, and the recently approved HMAC-SHA-2
document.

Another important example are socket APIs, e.g., RFC 3542, RFC 3678,
RFC 4584.  These often contain C header prototypes which are useful to
extract.

Another example are, ironically given the examples in (C) below, some
MIB modules, e.g. RFC 3806, RFC 3808, and RFC 4498.

Yes, I realize RFC 3978 use similar language (but RFC 2026 did not),
so this post should not be read as a WGLC comment on rules-update-07.

Instead, it as a request to consider modifying the outbound license to
give third parties similar rights to Information/Experimental that are
given to standards track documents.

For the same reason that I believe having different policies for code
and text is not useful, I believe it not useful to have different
policies for standards track and non-standards track documents.  I
believe it is a sign of over-engineering, and causes unnecessary
administrative burden.

Thanks,
Simon

   "3.8 Rights Granted by the IETF Trust to Third Parties

      The IETF Trust hereby grants to any person wishing to obtain such
      rights, to the greatest extent it is permitted to do so, the
      following perpetual, irrevocable, non-exclusive, royalty-free,
      world-wide rights and licenses under all copyrights and other
      rights of authors, which rights may be exercised within or outside
      the IETF Standards Process:

   (A)  to copy, publish, display, and distribute each IETF Document
      (including all Contributions and other portions thereof) in
      unmodified form,

   (B)  to prepare translations of IETF Documents (including all
      Contributions and other portions thereof) into languages other
      than English, and to copy, publish, display, and distribute such
      translations,

   (C)  to extract, modify, incorporate into other works, copy, publish,
      display, and distribute executable code or code fragments that are
      included in any IETF Document (such as MIB and PIB modules),
      subject to the notification requirements of Section 5."

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Jul 2006 10:08:41 +0200

To be clear: this update is not intended to solve all the open
issues. It's intended to fix one problem that has become urgent:
the anomalous reference to ISOC, which has been obsolete since
December 15, 2005.

So, it's well understood that whether the WG agrees to this draft
or the even simpler -ietf-trust-update, the job isn't done.
We need one of these two drafts approved very quickly.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Jul 2006 10:12:21 +0200

Simon,

I don't think the word "participant" needs definition in the way
that "contributor" does. Its dictionary meaning will do fine.

Jorge has assured me in the past that any document that's
approved in the IETF (i.e. by the IESG) is part of the IETF standards
process, even if it isn't on the IETF Standards Track. This doesn't apply
to documents from other sources (e.g. IRTF or Independent Submissions.)

    Brian

---

From: Scott W Brim <[email-masked]>
Date: Sun, 30 Jul 2006 09:13:05 -0400

> 3.7 and section 3.8 forever, unless the inbound license is changed

Can you really decouple inbound and outbound completely?  Doesn't the
grantor of rights to the IETF deserve to know the extent of what the
IETF might do with his/her text?

---

From: "Bill Fenner" <[email-masked]>
Date: Sun, 30 Jul 2006 10:46:03 -0400

> parties for Informational or Experimental RFCs.

There are Informational or Experimental RFCs that are IETF Documents.
Standards Track documents can only be IETF Documents; Informational
and Experimentals can be IETF Documents or RFC Editor Contributions.

  Bill

(Note that I have no real idea how to tell that RFC 4554 is an IETF
Document and RFC 4559 is an RFC Editor Contribution, other than the
extra couple of words in the copyright statement in RFC 4559.)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Jul 2006 11:25:33 +0200

> extra couple of words in the copyright statement in RFC 4559.)

Indeed. It isn't an IPR WG issue, but we do need to ensure that the Status
of this Memo words indicate the source of each RFC in future.

    Brian