[client com] FW: IANA IPR Community Agreement and License Agreement drafts
jrobinson at afilias.info
Mon Aug 1 10:36:49 UTC 2016
You may have seen some of my connected emails but the short answer is, yes, we do need to discuss these prior to an “all hands” call with the other OCs.
I for one need to understand these apparent redlines and how much they are governed by a position or point of view as opposed to a view of one or more hard legal constraints.
I do agree that we need to understand how any positions (however derived) are consistent with the principles previously agreed such as the functional neutrality.
Once we have the above, we will be in a much better position to discuss with the other OCs and the IETF trust (on email before and in call on Wed) and then to go back to the CWG for (hopefully) final instructions on Thursday.
From: Greg Shatan [mailto:gregshatanipc at gmail.com]
Sent: 31 July 2016 22:18
To: Hofheimer, Joshua T. <jhofheimer at sidley.com>
Cc: Client Committee <cwg-client at icann.org>
Subject: Re: [client com] FW: IANA IPR Community Agreement and License Agreement drafts
Two issues, a placeholder and an aside:
1. Should we have a call prior to the all-hands call with the other communities? We really need to consider how to respond to these changes (and the rejection/deletion of many of our changes), so that we have an approach going into the call.
2. We need to consider how to respond to the points raised in the IETF Trust's email texts (paraphrased below, with some very preliminary thoughts below each).
* We do not believe we can accept any arrangement in which the Trust is subject to "approvals" by the CCG. Such acceptance would be contrary to the Trust's anticipated fiduciary responsibility as the holder of the Marks. We believe that any independent trust would face this problem.
* Approvals and consents are mentioned a number of times in the Principal Terms. This document was presented to the IETF Trust's counsel for comment and (after waiting weeks) we were told counsel had no comment. It's disappointing that this issue is coming to a head now, as opposed to months ago when counsel had the opportunity to raise it and did not.
* If the "advice" of the communities (or any community) can have the same weight as "GAC Advice" or GNSO policy recommendations, "advice" rather than "approvals" may be acceptable.
* It should be noted that (as I understand it) the Trust's "anticipated fiduciary responsibility" is to the IETF Trust and to the Beneficiary of that Trust (the "IETF as a whole"), not to the other communities.
* I'm not sure what the reference to an "independent Trust" alludes to. I assume it alludes to a Trust independent of the communities (but of course, the IETF Trust is not independent of all the communities, given its structure and where its fiduciary responsibilities lie).
* We do not think that, given the terms of our Trust Agreement, the Trust is capable of acting as a "steward" for other operational communities.
* Interesting that the IETF Trust itself chose to head Section 3 of the Community Agreement "Stewardship of the IANA Intellectual Property," but now claims it can't act as a "steward."
* This term isn't mentioned in the ICG Proposal or in the Principal Terms, but it is meaningful as a concept aligned to accountability, which the Trust also seems to resist. The ICANN community has spent nearly two years making ICANN more accountable. Is it ironic (or worse) to give the IANA IPR to an entity that is not willing to be accountable (at least not "with teeth") to the communities (other than the IETF)?
* The existing Trust Agreement also does not permit the Trust to transfer away any asset once it is owned by the Trust, so we cannot accept any term that anticipates such a transfer.
* How do we feel about this being a perpetual transfer to the IETF Trust, regardless of circumstances? Note that the communities were able to cause ICANN to give up the IANA IPR. Is it ironic (or worse) to give it to an organization where we have no such ability?
* Technically, Jorge may be correct, so long as one assumes the IANA IPR will become "Trust Assets" under the Trust Agreement (which states "except as otherwise expressly permitted hereunder, the Trustees shall not, and shall not have the right or power to, (i) exchange, distribute, assign, sell, transfer, renounce, or convey, the Trust Assets"). But, could they take on the IANA IPR as owner without making them "Trust Assets"?
* We realize that some people would prefer to amend some terms of the IETF Trust Agreement. That may be possible in the future in order to accommodate some of the above worries. But all changes have to go through the IETF consensus process, and there simply isn't time to do that this year. Hence our agreement must work with the Trust as it currently exists.
* I'm not sure why this is being said. We've been trying to work within the terms of the Trust Agreement for many months, so I'm not sure who "some people" are.
* However, if this is an opening to make some future changes to the Trust Agreement, that would be worth exploring.
3. The Placeholder: We need the chart that Sidley is preparing so we can analyze the issues in the most efficient manner.
4. The (Important) Aside. I was tempted to ask whether we can expect comments from the IETF (as distinguished from the IETF Trust) on these documents -- or are the IETF and the Trust working as one here? How does the fit with the CWG's stated goal of "neutrality" (namely, no community having any more influence over the holder of the IANA IPR than any other community). How do the agreements as envisioned by the IETF Trust fit with the idea that we would solve "neutrality" issues "functionally" (through the agreements) rather than "structurally" (through changing the IETF Trust or establishing a new Trust)?
On Sun, Jul 31, 2016 at 3:08 PM, Greg Shatan <gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com> > wrote:
I thought it would be helpful to prepare the attached redline comparisons of the IETF Trust's new version vs the CWG version.
The IETF Trust only provided redlines against their own first draft. Typically, the redline provided with the latest draft shows changes to the immediate prior draft. Presumably, the IETF Trust did not do this because they were responding to both the CWG and the RIR drafts.
In any event, the attached comparisons show which changes in our drafts were deleted by the IETF Trust and which were retained by the IETF Trust. This cannot be ascertained from the redlines circulated by the IETF Trust.
We should consider whether to circulate these redlines on the iana-ipr list. We may wish to do so if we are going to refer back to the changes that we made which were then deleted by the IETF Trust.
On Sat, Jul 30, 2016 at 4:43 PM, Hofheimer, Joshua T. <jhofheimer at sidley.com <mailto:jhofheimer at sidley.com> > wrote:
Jonathan, Lise and the Client Committee,
See attached. Sidley will prepare a table for your review that highlights the key departures from our proposed drafts.
Sidley Austin LLP
jhofheimer at sidley.com <mailto:jhofheimer at sidley.com>
(213) 896-6061 <tel:%28213%29%20896-6061> (LA direct)
(650) 565-7561 <tel:%28650%29%20565-7561> (Palo Alto direct)
(323) 708-2405 <tel:%28323%29%20708-2405> (cell)
From: iana-ipr-bounces at nro.net <mailto:iana-ipr-bounces at nro.net> [mailto:iana-ipr-bounces at nro.net <mailto:iana-ipr-bounces at nro.net> ] On Behalf Of Jorge Contreras
Sent: Saturday, July 30, 2016 10:03 AM
To: iana-ipr at nro.net <mailto:iana-ipr at nro.net>
Subject: [Iana-ipr] IANA IPR Community Agreement and License Agreement drafts
We have attached for your review clean and redlined versions of the Community Agreement and License Agreement, which have been marked against the versions distributed on July 5. We have inserted numerous
comments in the marked version using the MS Word comment feature. These comments are intended to address specific text or suggestions made by CWG, RIR or IETF during the last round.
In these candidate agreements, we have accepted a number of suggestions both the operational communities. We know that everyone is anxious to get these done, and many of the changes seem to us to be reasonable and in keeping with the Trust’s responsibilities.
What we have not accepted, and what we do not believe we can accept, is any arrangement in which the Trust is subject to "approvals" by the CCG. We remain convinced that such acceptance would be contrary to
the Trust's anticipated fiduciary responsibility as the holder of the Marks, and the Trustees cannot responsibly expose the Trust to such a threat. We believe that any independent trust would face this problem.
In addition, we do not think that, given the terms of our Trust Agreement, the Trust is capable of acting as a "steward" for other operational communities. The existing Trust Agreement also does not permit the Trust to transfer away any asset once it is owned by the Trust, so we cannot accept any term that anticipates such a transfer.
We realize that some people would prefer to amend some terms of the IETF Trust Agreement. That may be possible in the future in order to accommodate some of the above worries. But all changes have to go through the IETF consensus process, and there simply isn't time to do that this year. Hence our agreement must work with the Trust as it currently exists.
We hope that you will agree that we are making substantive and collegial process here, and we hope you understand that the existing terms of the Trust Agreement are a hard limit on what we may possibly
do. We look forward to additional comments and to a fruitful discussion on our next call.
Jorge L. Contreras
Contreras Legal Strategy LLC
1711 Massachusetts Ave. NW, No. 710
Washington, DC 20036
contreraslegal at att.net <mailto:contreraslegal at att.net>
The contents of this message may be attorney-client privileged and confidential. If you are not the intended recipient, please delete this message immediately.
This e-mail is sent by a law firm and may contain information that is privileged or confidential.
If you are not the intended recipient, please delete the e-mail and any attachments and notify us
Cwg-client mailing list
Cwg-client at icann.org <mailto:Cwg-client at icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cwg-client