Subject: RE: New version of my proposal posted

From: [email-masked]
Date: Thu, 3 Nov 2005 21:33:20 -0500

Simon,

> 2) Examples of problems has been listed for problem #1, i.e., that BCP
>    78 disallow derivative works that were permitted under RFC 2026.  I
>    also expanded slightly on the discussion regarding this problem.
>    Being able to take portions of RFCs, modify them and send to the
>    RFC errata appear to be another example, but I didn't have time to
>    add it.

I talked to one of EMC's lawyers about this.  The lawyer suggests that
any automatic grant of copyright for anyone to make derivative works be
limited a specific field of use, namely implementation of the original
unmodified RFC from which the text was derived.  This addresses all five
of the examples in your draft while clearly blocking someone who makes
a minor incompatible change to the RFC, as the incompatibility places the
result outside the field of use, hence blocking the automatic grant of
copyright (which is the desired outcome).  The right to reproduce and
distribute an RFC without modification should remain unlimited.

Beyond this, for situations like the one I described in a previous
message, I prefer Scott's approach of acquiring sufficient rights to
enable the IESG to permit derivative works outside the IETF when that
is the proverbial "right thing to do".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 4 Nov 2005 06:57:46 -0600

> is the proverbial "right thing to do".

I am often surprised by the side effects of IPR policies, so I'm not saying 
this is a GOOD thing, but it does seem to me to be a good thing, because 
every time we have a conversation that includes the phrase, "so, what do we 
do about the first 4000 or so RFCs?", everything just kind of grinds to a 
halt immediately after that.

Spencer

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 04 Nov 2005 15:21:48 +0100

[email-masked] writes:

> unmodified RFC from which the text was derived.

David,
That appear to be what RFC 2026 said (in "and derivative works that
[...] assist in its implmentation [sic] may be prepared, copied [...]
without restriction of any kind").  RFC 3978 removed that right.

> This addresses all five of the examples in your draft while clearly
> blocking someone who makes a minor incompatible change to the RFC,
> as the incompatibility places the result outside the field of use,
> hence blocking the automatic grant of copyright (which is the
> desired outcome).

This argument sound compelling, and in a perfect world, it might work.

However, I see two problems here.  The first is philosophical, and the
second is practical.

Philosophical: I believe granting the right to modify RFCs lead to a
   better working Internet, and better standards, in the long run.
   The reason is that people can build on past protocols and make
   minor changes to adapt it to their needs, and make a product.  If
   the implementation gain market shares, it may eventually be useful
   to standardize the protocol in IETF, but standardizing shouldn't be
   required before deploying a product that include a modified
   protocol description.  Historically, implementations preceded IETF
   standardization, and from the protocols I'm involved in, this is
   often the case.

Practical: RFCs are frequently ambiguous and sometimes they even
   contain errors or internally inconsistent descriptions.  A recent
   example is the Unicode 3.2 NFKC algorithm which IDN is using.  When
   implementing a RFC, it is sometimes necessary to make an
   interpretation of the text, because it is not fully specified.  I
   believe implementers must have the right to make these
   interpretations, without consulting a IETF consensus on what the
   correct interpretation is, before deploying their product.  Waiting
   for the IETF to revise and update a RFC before they can finish
   implementing their product is ridiculous.

I wouldn't agree that the RFC 2026 license fully solve the problems
listed in my draft.  It may solve many practical instances of the
problems, but not all.

> The right to reproduce and distribute an RFC without modification
> should remain unlimited.

Right.  I don't anyone dispute that.

> is the proverbial "right thing to do".

As far as I understand -- there is a lack of public information about
the relationship between the IETF and the IPR Trust -- the IESG
doesn't have that right either.  Only the IAOC members will have that
right, because they control the IPR Trust.  See
<http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01603.html>,
specifically:

,----
| The Trustees will be the members of the IAOC.
...
| The Trust (acting through the Trustees) shall have the right to grant
| licenses for the use of the Trust Assets on such terms, as the Trustees
| deem appropriate; provided, however, that the Trust shall not grant any
| license that would be deemed a transfer of ownership or abandonment of any
| Trust Assets under applicable law.
| 
| Initial contributed IPR shall be (as far as the parties' rights extend):
| 
| -   Trademarks
| -   Domain names
| -   Current databases, mailing lists, web pages, working group
|     and IESG materials
| -   Current I-Ds and RFCs
| -   Rights in extracted historical data (records of past meetings,
|      past I-Ds and RFCs and their processing history)
`----

I also note that this would include past I-Ds and RFCs, which if I
understood Jorge correctly, would be legally questionable.  It doesn't
seem like the IPR Trust would have the rights to grant others rights
to past I-Ds or RFCs.

Regards,
Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Nov 2005 20:57:31 +0100

Simon Josefsson wrote:
...
> <http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01603.html>,

I can't speak as a Trustee, because the Trust doesn't formally exist
yet, but my personal position is that:
a) the IETF can in fact fire most of the Trustees if they misbehave,
and I think that ignoring an IETF or IESG consensus on licensing
would be a firing offense;
b) it's my personal intention to insist that the Trust's procedures
include a commitment to follow the IETF's wishes in matters
of licensing.

...
> seem like the IPR Trust would have the rights to grant others rights

Not unless the original rights owners choose to assign their rights
to the Trust. But that's nothing new; today ISOC can't grant rights
that have never been assigned to ISOC.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Nov 2005 23:37:41 -0500

> include a commitment to follow the IETF's wishes in matters

This intention would ease several concerns.  However, section
9.5 of the trust agreement contains provisions that appear to me
to be equivalent to those of the GPL copyleft only retaining the
rights for the Trust rather than the public.  Specifically, the
Trust cannot license or assign any rights in Trust-owned IPR,
including the right to to create derivative works, unless the
licensee agrees that those derivative works will belong entirely
to the Trust.  In addition, not being a lawyer, I'm not certain
what 9.5(b) means in practice, but it appears to mean that, if a
licensee were to marginally profit as a consequence of using the
IETF's IPR, the Trust would have a claim on a share of those
profits.

It seems to me that this raises two issues that have been hotly
debated in the past in another context.  The restriction would
appear to require individual negotiation of licenses, not a
blanket grant, which some members of the community have argued
is too onerous for other types of IPR.  It also creates a "what
is mine is mine and what is yours is mine too" condition, to
which many organizations have taken strong exception in the past.

I note that this working group was not consulted on that
language or on the appropriateness of these licensing
constraints.

I hope we can avoid re-debating either of those substantive
issues here.  But I  think it is important to point out that,
should the IETF change its mind in this matter, or reach a
conclusion about terms different from those specified in the
trust agreement, and do so by some mechanism that clearly
reflected community consensus:

(1) The IAOC, in addition to or instead of the IESG, would need
to ratify that consensus.  While I agree with Brian's
observation that 

> 	a) the IETF can in fact fire most of the Trustees if
> 	they misbehave, and I think that ignoring an IETF or
> 	IESG consensus on licensing would be a firing offense;

the "running code" is that the community has found "firing" to
be a much too difficult and unpleasant procedure to deal with
any but the most obnoxious of behavior.  It is not yet
demonstrated that behavior that obnoxious is even possible
because the mechanisms have never been exercised at all.   If an
IAOC concluded that it simply knew better than the community
consensus, perhaps on the basis of information available to them
and not the community, experience so far would lead them to
reasonably predict that recall/ firing is not a sufficient
threat to prevent following their judgment rather than the
community's.  

More generally, if we have designed a procedure for which we
need to use the threat of recall as the only mechanism to ensure
that an IETF consensus on licensing is followed, we are probably
in bad trouble.  I suggest that, if the IETF believes that IETF
consensus, especially on the policies to be followed by the
Trustees, should be binding on the IAOC and those Trustees, the
IETF needs to insist on that as a requirement.

Unfortunately, under the Trust Agreement as I read it, the IETF
doesn't get to impose that requirement, as least not as an IETF
action.  

(2) Any changes to the basic licensing requirements or rules of
the Trust, such as changes to the licensing provisions of 9.5
described, should the IETF decide to make them, require the
consent of both CNRI and ISOC unless we are prepared to wait
until July of 2010.  These are requirements of the Trust
agreement and CRNI and ISOC must agree to any amendments to that
agreement.   If they don't agree, they don't need to give
reasons.  They are not even obligated to indicate whether they
agree or not within any specified period of time.  Should one of
them not agree, then, as the Trust Agreement is written, IETF
consensus is worth exactly nothing.   And there is no mechanism
for "firing" either of the Settlors, at least without the
consent of both of them.

As I have communicated privately (and in much more detail) to
the IAOC, I believe that the Trust Agreement sets policies for
the IETF and gives away decision-making authority over which the
IETF has believed that it _as a community_ had consensus
control.  Because it involves setting policies, rather than
"managing" the IPR portfolio, I don't believe the IAOC has the
right/authority to do any such thing without explicit community
consensus.   Whether their doing so is a matter that would be
considered equivalent to one of the activities for which Brian
believes people should be "fired" is something that he should,
IMO, comment on.  And it is one on which the community should
reach some conclusion... a conclusion that I believe is
ultimately about whether IETF decision-making, at the most basic
of policy levels, is bottom up or top-down, controlled by the
community or controlled by a few of its appointed leaders acting
on their own judgment rather than on community consensus.

    john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 05 Nov 2005 09:34:57 +0100

> seem like the IPR Trust would have the rights to grant others rights

just to put this distraction on a different subject line....

the IPR language is, I believe, intended as a "quitclaim", not a 
"make-claim" - the settlors (ISOC and CNRI) declare that any rights they 
have is now vested in the trust, and do so without specifying anything 
about what those rights are.

The purpose is not to create new claims of rights for the IETF Trust, but 
to make sure that there cannot be any later discussion about who (between 
CNRI,   ISOC and the IPR trust) owns rights that have been granted "to the 
IETF" - after the agreement, it all belongs to the trust.

The authors are not part of the agreement; they have exactly the same 
rights as before (whatever that is). Being specific about that would 
probably have tied up the trust creation in legal knots for another few 
years.....

My understanding, and I'm STILL not a lawyer....

                     Harald

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Nov 2005 06:39:02 +0100

> IETF needs to insist on that as a requirement.

I agree with John here.  Giving up the ownership of I-Ds and RFCs (and
trademarks, domain names, mailing lists, ...) to an organization
without a binding agreement that it will do as the IETF community
wishes seem frivolous.

Could someone point me to the IETF Trust Agreement?  I can't seem to
locate it.  The recently approved draft-carpenter-bcp101-update-03.txt
only include a normative reference:

   [2]  "IETF Trust Agreement, http://www.ietf.org/TBD.txt", Month-
        TBD 2005.

I wonder how the public was supposed to be able to review that
document when one of the normative references had not yet been
written.

Thanks,
Simon

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Nov 2005 13:01:10 +0100

Simon Josefsson wrote:

> Could someone point me to the IETF Trust Agreement?

<http://koi.uoregon.edu/~iaoc/docs/IETF-Trust.pdf>  Bye, Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Nov 2005 16:46:49 +0100

Harald Tveit Alvestrand wrote:
> The purpose is not to create new claims of rights for the IETF Trust, 
> but to make sure that there cannot be any later discussion about who 
> (between CNRI,   ISOC and the IPR trust) owns rights that have been 
> granted "to the IETF" - after the agreement, it all belongs to the trust.
> 

Neither am I, but the FAQ has been checked by our lawyer and
says roughly the same thing.
http://koi.uoregon.edu/~iaoc/docs/TrustFAQv1.1.txt

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Nov 2005 16:42:39 +0100

Simon,

> without a binding agreement that it will do as the IETF community

It would be, but that won't happen. The IAOC is very much aware
that it exists to serve the IETF. My personal intention is to
ensure that the formal Trust procedures will contain this
condition. Voting those procedures into existence will be the
Trustee's first action, once the Trust is formally created.

> document when one of the normative references had not yet been

Indeed, that is why the normative reference was inserted, since the update
cannot become an RFC before that TBD is resolved. At the time, we were
obliged to keep the text confidential during negotiation.

You seem to have missed the announcement at
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01703.html
which points to the Trust text and FAQ to be found at
http://koi.uoregon.edu/~iaoc/

There will be a definitive URL for the text soon.

     Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2005 12:14:54 -0800

> without a binding agreement that it will do as the IETF community

I don't think this is a problem.

Remember that the trustees of the IETF trust are defined as the IAOC.
And the IAOC is defined in BCP 101, which says among other things:

 3.  Structure of the IASA

   The IASA structure is designed to ensure accountability and
   transparency of the IETF administrative and fiscal activities to the
   IETF community.  The IETF Administrative Oversight Committee (IAOC)
   directs and oversees the IASA.  The IAOC consists of volunteers, all
   chosen directly or indirectly by the IETF community, as well as
   appropriate ex officio members from ISOC and IETF leadership.  The
   IAOC shall be accountable to the IETF community for the
   effectiveness, efficiency, and transparency of the IASA.

.....

 3.2.  IAOC Responsibilities

   The IAOC's role is to provide appropriate direction to the IAD, to
   review the IAD's regular reports, and to oversee IASA functions to
   ensure that the administrative needs of the IETF community are being
   properly met.

and various other words - all based on the assumption that "the IASA does 
what the IETF needs it to do".

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Nov 2005 20:02:29 +0100

This is a late reply and may have been partly overtaken by
discussions in Vancouver, but John raised some important
points. It's also a personal reply, not an IAOC reply
or an AD reply or an IETF Chair reply.

John C Klensin wrote:
> rights for the Trust rather than the public.

The intention of that text was to ensure that the IETF has the
right to make derivative works from derivative works of its
own text made by a licensee. It certainly wasn't intended to have
a viral effect. We've discussed this during the week and believe
that there are two things to do

1. Add clarifcation of the legal interpretation to the Trust FAQ.
2. Obtain assurance that ISOC (as the Settlor as far
as RFCs is concerned) does not intend the sort of perverse side
effect you fear and does intend the IETF to determine the licensing
conditions.

> Specifically, the

I think it's true that the Trust text doesn't exclude royalties
by construction. And who can say that we might not encounter
a form of commercial exploitation of our IPR that doesn't in itself
serve the IETF's purposes? In that case, would we want to exclude
royalties by construction? As the text stands, the IETF has the
option open.

> which many organizations have taken strong exception in the past.

Yes, and as noted above I don't believe that is the intention.
The blanket license question is a good one, but I don't see
why the Trust text would prevent a blanket license if that's
what we wanted. However (see discussion of draft-josefsson-)
it's not yet clear whether we do want it.

> language or on the appropriateness of these licensing

No, because the IAOC was constrained. I feel that this was
unfortunate myself.

> threat to prevent following their judgment rather than the

There's truth in that. All I can say is that the IAOC is very
conscious of the community, although we also have to deal with
legal and financial constraints that may be less compelling to
the community than they are to those of us on the hook.

> in bad trouble. 

I don't think we have. I suspect that if the Trust had been
proposed when BCP 101 was written, we'd have some specific
language in there about the IAOC being bound to act in the
IETF's best interests even in their Trustee role, or whatever.
I only mentioned recall because it does emphasise that the IAOC
is in place to serve the community. I have proposed language for
the Trust's procedures that says "All the Trustees' decisions
shall be subject to the community review process defined in
Section 3.5 of BCP 101 for IAOC decisions."

> I suggest that, if the IETF believes that IETF

But with the beneficiary of the Trust being the IETF, and the
majority of the Trustees serving at the IETF's pleasure,
I really believe that is functionally equivalent. And see my
previous comment.

> for "firing" either of the Settlors, at least without the

That is why we worked hard for several months to ensure that
the Trust sets boundary conditions that appear to us to be
compatible with as wide range as possible of IETF policies.
> consensus.

There, John, we simply disagree. I believe that the Trust agreement
actually doesn't set policy; it gives the Trustees the power
to set policy, and the Trustees are beholden to the IETF. Now
that is certainly a judgement call but I am also proposing
this language for the Trust procedures: "The Trust shall
be guided by IETF process documents, decisions of the IETF
leadership, and IETF consensus when licensing use of its
intellectual property in accordance with the Trust Agreement."

>  Whether their doing so is a matter that would be

If, say, the Trustees in their first meeting decide to start
charging for RFCs or, at the other extreme, to donate rights
in all RFCs to the ITU, that would be reprehensible policy change
without consensus. But the Trust agreement in itself is pretty
much neutral with respect to the IETF's IPR policy (modulo the
comments on 9.5 at the head of this note).

     Brian