FW: IPR follow up
Please see below for draft principal terms as provided by Jari Arkko. Note that this draft was provided as an example that "could apply to other parties as well as the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done." -- Example Principal Terms of Intellectual Property Agreements This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated. A. Background The ICG proposal indicates that the IANA trademark and iana.org <http://iana.org> domain should be transferred to an entity independent of the IANA Numbering Services Operator. The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust's position and an overview of how the role and responsibilities may be fulfilled. While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements. The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology. B. Framework The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s). These agreements include: 1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust 2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust's commitments to each as further described below, and 3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org <http://iana.org> domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities. The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself. The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections. In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks. C. Terms The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. C.1. IP Transfer Agreement (between ICANN and IETF Trust) a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the "Transfer"). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer. b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org <http://iana.org> (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org <http://iana.org> and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar. c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN's in-house legal department. d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity. C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community) a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community. b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the "IANA IP Reps". c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps. d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps. C.3. IANA IP License Agreement (between IETF Trust and PTI) a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions. b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed. c. The IETF Trust will authorize PTI to operate via the iana.org <http://iana.org> domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org <http://iana.org> domain during the term of the agreement. PTI shall use iana.org <http://iana.org> and all associated subdomains exclusively for purposes of offering the IANA functions. d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name. e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks. f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust's opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps. g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org <http://iana.org> domain to the IETF Trust.
Thanks for sharing this Jonathan, its a very welcome approach. Kindly a few comments inline: On 8 Jan 2016 6:57 PM, "Jonathan Robinson" <jrobinson@afilias.info> wrote:
A. Background
The ICG proposal indicates that the IANA trademark and iana.org domain
should be transferred to an entity independent of the IANA Numbering Services Operator.
+1 on this simple and straight forward requirement.
B. Framework
These agreements include: An Agreement between ICANN and the IETF Trust transferring the IANA IP
to the IETF Trust
SO: Isn't this going to include the domain iana.org? Aside from the normal technical record transfer described further below(godaddy), it may be good to capture the actual transfer of the domain on paper as well.
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
SO: Who is the names recipient/party in this segment? ICANN or PTI?
3. Agreement(s) whereby the IETF Trust provides for the use of the
iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
SO: Am I right by assuming that PTI would sign for the 3 OCs as that would become the IFO post transition? So there may be no need for plural agreement in this segment.
The Trust understands that each community would need to follow its own
internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
SO: This is fair enough but I hope this is not suggesting a new process to selecting IANA service provider as I think the ICG proposal should be enough source of information for the initial agreement. I see no reason why anyone would change their mind before completion of current transition process.
The Community Assurance Agreements with the IANA communities would
establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
SO: comment same as above.
In order to preserve the value and integrity of the IANA trademarks, the
IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
SO: Thanks
C. Terms .
C.1. IP Transfer Agreement (between ICANN and IETF Trust)
a. When requested by the IETF Trust, ICANN will transfer and assign all
of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
SO: May be good to know/understand if indeed there are any existing liabilities and its implications once the transfer happen. Perhaps this question could be sent to ICANN legal/staff incharge of these
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
SO: If this includes subsequent fees, then it should be indicated.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
SO: makes sense.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
SO: Seem to be similar to section a above? My comment on that applies.
C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)
a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
SO: It's not clear if the reps referred to would be from the community or staff. I would suggest that it be from staff. Or better still 1 from both.
C.3. IANA IP License Agreement (between IETF Trust and PTI)
a. The IETF Trust will grant PTI a non-exclusive, worldwide,
royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
SO: Most likely this answers my question on section B3
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
SO: Fair enough, does this mean the service agreements will be renewed periodically? I think it may be good to have something constant that only changes once there is a breach or change in IANA service provider.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
SO: Does this envisage that PTI may actually be serving at least one of the OCs and so may still require to have need to have access to the IPR. A scenario where numbers for instance decide to pull out OR a scenario where PTI's breach is only in connection with one of the OCs Overall I am glad with the progress made on this and most importantly the direction this is going. Thanks to the IETF for owning up on this. ;-) Regards
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
I like what I see here. Clear thinking about what any trust needs to do for us, and in particular the community assurance agreement and the commitment to maintain, monitor and license the use of the marks addresses the concerns some had about the IETF Trust. --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Jonathan Robinson Sent: Friday, January 8, 2016 12:56 PM To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] FW: IPR follow up Please see below for draft principal terms as provided by Jari Arkko. Note that this draft was provided as an example that "could apply to other parties as well as the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done." -- Example Principal Terms of Intellectual Property Agreements This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated. A. Background The ICG proposal indicates that the IANA trademark and iana.org<http://iana.org> domain should be transferred to an entity independent of the IANA Numbering Services Operator. The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust's position and an overview of how the role and responsibilities may be fulfilled. While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements. The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology. B. Framework The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s). These agreements include: 1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust 2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust's commitments to each as further described below, and 3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org<http://iana.org> domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities. The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself. The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections. In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks. C. Terms The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. C.1. IP Transfer Agreement (between ICANN and IETF Trust) a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the "Transfer"). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer. b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org<http://iana.org> (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org<http://iana.org> and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar. c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN's in-house legal department. d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity. C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community) a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community. b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the "IANA IP Reps". c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps. d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps. C.3. IANA IP License Agreement (between IETF Trust and PTI) a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions. b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed. c. The IETF Trust will authorize PTI to operate via the iana.org<http://iana.org> domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org<http://iana.org> domain during the term of the agreement. PTI shall use iana.org<http://iana.org> and all associated subdomains exclusively for purposes of offering the IANA functions. d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name. e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks. f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust's opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps. g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org<http://iana.org> domain to the IETF Trust.
All, Below are my comments and questions on the "Example Principal Terms." There are over-arching issues raised by the DT-IPR draft principles about the structure of any new owner of the IPR that are not addressed here. Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose? We need to address those issues first. Once we get past those questions, many of the ideas below are agnostic, i.e., they would be adopted in any scenario. I would include the agreement transferring the IPR to the new owner, and licenses from the new owner to the IFO(s) in that category. I would not include the "community assurance agreements" in that category -- I see those as the weakest possible way of controlling any new owner and holding it accountable. Greg
*Example Principal Terms of Intellectual Property Agreements* This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background* The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- iana.org, iana.net, and iana.com. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community.
GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets. According to the IETF Trust Agreement ( http://trustee.ietf.org/trust-agreement-2014.html) the beneficiary of the IETF Trust is the IETF (rather than the IETF community), and the successor Beneficiary is "the IETF's successor with respect to the development of technical standards for the Internet." As I understand it, the IETF is an "organized activity" of ISOC, and not a legal entity. Thus, in some sense, ISOC (as the legal entity) is the beneficiary of the IETF Trust. This is also significant in understanding the nature of the IETF Trust, since the beneficiary of a trust has unique rights, including rights with regard to the trust's assets. The beneficiary is also owed unique duties by the Trustees, particularly the duty to act in the interests of the beneficiary.
The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up. More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel). Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
GSS: I agree that a License Agreement (or License and Lease Agreement, or something similar) will be needed for any future owner to grant rights to use trademarks and domain names to the IANA Functions Operator(s) (or, in this email's terms, the "IANA service provider(s)").
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks. This "Quality Control" obligation is at the heart of any trademark licensor/licensee relationship. That said, to the extent the OC's have (or will have) their own quality control mechanisms, the trust should be able to take advantage of these to a very great extent in satisfying its quality control obligations. This is another topic that would need to be covered in the Community Assurance Agreements (or other mechanisms put in place).
*C. Terms* The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust)* a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org(GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
GSS: These terms seem broadly customary and acceptable, but would need significant review by the CWG and its counsel.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)* a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
GSS: Does the IETF contemplate one or three of these agreements? Earlier in the email it seems to be three, but in this discussion it appears to be one. If this is the method chosen for the relationship between the OC's and the trust, there is not enough stated to really define the relationship, and some of the details that are here may not work. The interrelationship between the OC's needs to be clarified. The party or parties representing the names community will also be an issue.
*C.3. IANA IP License Agreement (between IETF Trust and PTI)* a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well). The trust should not retain any right to use the trademarks; it is here only to serve as licensor. Some of the terms here seem to be taken from a copyright license ("display and reproduce"), but that will be taken care of....
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
GSS: As noted above, the quality control requirements must apply to the goods and services offered by the licensee. This needs to be absolutely explicit in any summary of this (or any other) trademark license agreement. Without it, we would have a "naked license," which is a major "no-no." A naked license can lead to abandonment of the mark, cancellation of the registrations, and loss of the mark's capacity to be a trademark. The quality of the use of the mark is a separate and much less important obligation between licensor and licensee.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall useiana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
GSS: The role of the OC's in relationship to these rights must be clarified, including rights to cause the trust to enforce (or not) against a particular infringer, the course of such enforcement, and the apportionment of damages received, if any)
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
GSS: This would have to be limited by any transitional requirements, both by the "losing" licensee and the "gaining" licensee. On Sun, Jan 10, 2016 at 11:30 PM, Mueller, Milton L <milton@gatech.edu> wrote:
I like what I see here. Clear thinking about what any trust needs to do for us, and in particular the community assurance agreement and the commitment to maintain, monitor and license the use of the marks addresses the concerns some had about the IETF Trust.
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Jonathan Robinson *Sent:* Friday, January 8, 2016 12:56 PM *To:* cwg-stewardship@icann.org *Subject:* [CWG-Stewardship] FW: IPR follow up
Please see below for draft principal terms as provided by Jari Arkko.
Note that this draft was provided as an example that “could apply to other parties as well as the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done.”
——
*Example Principal Terms of Intellectual Property Agreements * This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background*
The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
*C. Terms *
The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust) * a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community) * a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
*C.3. IANA IP License Agreement (between IETF Trust and PTI) * a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall use iana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hello Greg, I think we need to be clear on what the goal is and I believe the main goal is that the IPR and domain be transferred to an entity independent of the IANA function operator. Does the IETF meet that requirement? Yes. The other requirement is that the OCs are able to access the IPR and domain in a manner they currently do. This is where I think the text of the agreement comes into play and we should check the text against that requirement. I believe that is what you are attempting with your comments in blue. I think your initial concern about who the beneficiary is may be considered mute considering that the agreement would give each OC ample option to access the resource entrusted to the IETF trust. FWIW, it's not helpful to spin up a whole new trust just for this purpose. It makes a lot of sense both economically and resource wish to utilise existing platforms. As it's been said many times, IETF's is not just one of the 3 OCs it's more than that and its operating approach remove any fears of capture or any form of coup that you may be thinking could occur. That said, (if possible) we could perhaps include a requirement that allows transfer of the resource to another trust if all the 3OCs agree to do so in future. Maybe that would put to rest the mind of Greg and any other person concerned about this. Regards On 11 Jan 2016 5:02 PM, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
All,
Below are my comments and questions on the "Example Principal Terms."
There are over-arching issues raised by the DT-IPR draft principles about the structure of any new owner of the IPR that are not addressed here. Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose?
We need to address those issues first.
Once we get past those questions, many of the ideas below are agnostic, i.e., they would be adopted in any scenario. I would include the agreement transferring the IPR to the new owner, and licenses from the new owner to the IFO(s) in that category. I would not include the "community assurance agreements" in that category -- I see those as the weakest possible way of controlling any new owner and holding it accountable.
Greg
*Example Principal Terms of Intellectual Property Agreements* This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background* The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- iana.org, iana.net, and iana.com. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community.
GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets.
According to the IETF Trust Agreement ( http://trustee.ietf.org/trust-agreement-2014.html) the beneficiary of the IETF Trust is the IETF (rather than the IETF community), and the successor Beneficiary is "the IETF's successor with respect to the development of technical standards for the Internet." As I understand it, the IETF is an "organized activity" of ISOC, and not a legal entity. Thus, in some sense, ISOC (as the legal entity) is the beneficiary of the IETF Trust. This is also significant in understanding the nature of the IETF Trust, since the beneficiary of a trust has unique rights, including rights with regard to the trust's assets. The beneficiary is also owed unique duties by the Trustees, particularly the duty to act in the interests of the beneficiary.
The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up.
More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel).
Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
GSS: I agree that a License Agreement (or License and Lease Agreement, or something similar) will be needed for any future owner to grant rights to use trademarks and domain names to the IANA Functions Operator(s) (or, in this email's terms, the "IANA service provider(s)").
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks. This "Quality Control" obligation is at the heart of any trademark licensor/licensee relationship. That said, to the extent the OC's have (or will have) their own quality control mechanisms, the trust should be able to take advantage of these to a very great extent in satisfying its quality control obligations. This is another topic that would need to be covered in the Community Assurance Agreements (or other mechanisms put in place).
*C. Terms* The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust)* a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org(GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
GSS: These terms seem broadly customary and acceptable, but would need significant review by the CWG and its counsel.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)* a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
GSS: Does the IETF contemplate one or three of these agreements? Earlier in the email it seems to be three, but in this discussion it appears to be one. If this is the method chosen for the relationship between the OC's and the trust, there is not enough stated to really define the relationship, and some of the details that are here may not work. The interrelationship between the OC's needs to be clarified. The party or parties representing the names community will also be an issue.
*C.3. IANA IP License Agreement (between IETF Trust and PTI)* a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well). The trust should not retain any
right to use the trademarks; it is here only to serve as licensor. Some of the terms here seem to be taken from a copyright license ("display and reproduce"), but that will be taken care of....
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
GSS: As noted above, the quality control requirements must apply to the goods and services offered by the licensee. This needs to be absolutely explicit in any summary of this (or any other) trademark license agreement. Without it, we would have a "naked license," which is a major "no-no." A naked license can lead to abandonment of the mark, cancellation of the registrations, and loss of the mark's capacity to be a trademark. The quality of the use of the mark is a separate and much less important obligation between licensor and licensee.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall useiana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
GSS: The role of the OC's in relationship to these rights must be clarified, including rights to cause the trust to enforce (or not) against a particular infringer, the course of such enforcement, and the apportionment of damages received, if any)
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
GSS: This would have to be limited by any transitional requirements, both by the "losing" licensee and the "gaining" licensee.
On Sun, Jan 10, 2016 at 11:30 PM, Mueller, Milton L <milton@gatech.edu> wrote:
I like what I see here. Clear thinking about what any trust needs to do for us, and in particular the community assurance agreement and the commitment to maintain, monitor and license the use of the marks addresses the concerns some had about the IETF Trust.
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Jonathan Robinson *Sent:* Friday, January 8, 2016 12:56 PM *To:* cwg-stewardship@icann.org *Subject:* [CWG-Stewardship] FW: IPR follow up
Please see below for draft principal terms as provided by Jari Arkko.
Note that this draft was provided as an example that “could apply to other parties as well as the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done.”
——
*Example Principal Terms of Intellectual Property Agreements * This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background*
The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
*C. Terms *
The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust) * a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community) * a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
*C.3. IANA IP License Agreement (between IETF Trust and PTI) * a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall use iana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Seun, My answers are in-line below. On Mon, Jan 11, 2016 at 12:40 PM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hello Greg,
I think we need to be clear on what the goal is and I believe the main goal is that the IPR and domain be transferred to an entity independent of the IANA function operator.
The goals are what we need to decide in the CWG. There is a shared minimum requirement that the new owner is independent of the IFO. While that is a shared minimum requirement, it is very much an open question here whether *any* entity independent of the IFO is acceptable or whether the CWG (and ultimately the names community) has additional principles and requirements. Another goal that has been stated is that the entity be "neutral" but the definition of neutral is not yet settled. I believe that at a minimum, an entity controlled by one operational community does not meet that criterion as well as one that is controlled by all three or none at all. I understand that the NRO/RIRs appear to be comfortable with the result you support. That doesn't mean that the names community should follow along. We need to make our own minds up about this, and that is what the DT-IPR draft principles and requirements need to reflect. Those principles and requirements really where our conversation needs to start, so that we can agree to principles that then guide our review of any specific proposal, including this one.
Does the IETF meet that requirement? Yes. The other requirement is that the OCs are able to access the IPR and domain in a manner they currently do. This is where I think the text of the agreement comes into play and we should check the text against that requirement. I believe that is what you are attempting with your comments in blue.
I'm not sure what you mean when you say that the "OCs are able to access the IPR and domain in a manner they currently do." The domain is currently "accessed" by providing data to the IFO. The new owner, whoever it is, needs to provide the IFO operational control of the domain so that the IFO can continue to provide services to the OCs. As for "access" to the trademarks, unless you are referring to access by the IFO so that it can hold itself out as the "Internet Assigned Numbers Authority" or the "IANA," I'm really at a loss. I don't see a circumstance where the OCs "access" the trademarks in any other way.
I think your initial concern about who the beneficiary is may be considered mute considering that the agreement would give each OC ample option to access the resource entrusted to the IETF trust.
There's absolutely nothing moot here. You need to take into account what a beneficiary is in the context of a trust. The beneficiary is the entity for whose benefit the trust was set up. As such it's perfectly logical that the IETF is the sole beneficiary of the IETF Trust, since it was set up solely to hold IETF IPR. There is also a fiduciary relationship between the trustees and the beneficiary, which means that the trustees have a duty to act solely in the best interests of the beneficiary when with dealing with trust assets. The trustees do not owe this duty to any other person or entity. These are not just empty words or concepts; these are core principles of governance of a trust, and the trustees can get in big trouble if they violate them. (It's similar to the fiduciary duty of ICANN Board members to act in the best interests of the corporation -- except here it's the beneficiary and not the trust that is owed that duty.) If we want to use a trust as the owner, we need to understand its governance, just as we have spent so much time (particularly in the CCWG) understanding the governance of a non-profit corporation. (It's notable, by the way, that many "charitable trusts" are set up without a beneficiary, which means that the trustees duty is to manage the trust solely for the purposes of the trust and not for the beneficiary. This avoids confusion about the purposes of the trust and the duties of the trustees.) I'm far from certain that any agreement proposed in these terms gives any OC (other than the IETF) "ample option to access the resource entrusted to the IETF Trust" and I'm not sure which of several agreements you are referring to. But I am concerned that the IETF Trust could have the ability to cut off access even over the objections of any particular OC. I'm not saying that there is no way for the IETF Trust to be a workable owner of the IPR assets; something could be put together. But to my mind, it is expedient rather than preferable.
FWIW, it's not helpful to spin up a whole new trust just for this purpose. It makes a lot of sense both economically and resource wish to utilise existing platforms.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust. The transfer agreements (assigning IPR to the new owner) and license agreements (granting rights to the IPR to the IFO) will largely be the same under any owner (the license may actually be somewhat simpler under a shared trust). Creating and setting up the governance of a new trust vs. setting up the relationships between the IETF Trust and the OCs (presumably, including the IETF even though its on both sides) are similarly challenging. There is no such thing as a "community assurance agreement," so whatever we and our counsel invent to fill that agreement will be novel as well. Trust governance documents, by contrast, are more established, so we will at least have a basis for whatever unique arrangements are required in this particular circumstances.
As it's been said many times, IETF's is not just one of the 3 OCs it's more than that and its operating approach remove any fears of capture or any form of coup that you may be thinking could occur.
Can you explain what you mean when you say the IETF is "more than" "just one of the 3 OCs"? I don't see that its role setting protocol parameters elevates it above the other two OCs. Frankly, if there is a belief that the IETF is "more equal" than names or numbers, that increases my concerns about putting a shared resource into the hands of a Trust controlled by and established for the benefit of the IETF. Please also explain what you mean by its "operating approach." I'm not aware of anything in its operating approach that removes "any fears of capture or any form of coup." This statement also shows how easily the line can be blurred between the IETF Trust and the IETF itself, which again raises concerns rather than resolving them. None of this is intended to cast any aspersions against the IETF or any of the administrators serving as Trustees of the IETF Trust. The IETF is set up for a particular purpose and as far as I can tell they do it very well. I have a great deal of respect for them (and for the IETF) across the board. But neither do I see a reason to cast the IETF as some sort of neutral and benevolent "holy spirit" that has no viewpoints or opinions other than those that are always best for everybody.
That said, (if possible) we could perhaps include a requirement that allows transfer of the resource to another trust if all the 3OCs agree to do so in future. Maybe that would put to rest the mind of Greg and any other person concerned about this.
I believe this is a minimum requirement in connection with any new owner. But it really puts nothing to rest. At best it offers the possibility of moving the assets if the new owner is not performing as it should. But this is a very slim possibility if the IETF essentially has a veto over moving the assets out of the IETF Trust -- yet another issue to be overcome in that scenario. Greg
Regards On 11 Jan 2016 5:02 PM, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
All,
Below are my comments and questions on the "Example Principal Terms."
There are over-arching issues raised by the DT-IPR draft principles about the structure of any new owner of the IPR that are not addressed here. Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose?
We need to address those issues first.
Once we get past those questions, many of the ideas below are agnostic, i.e., they would be adopted in any scenario. I would include the agreement transferring the IPR to the new owner, and licenses from the new owner to the IFO(s) in that category. I would not include the "community assurance agreements" in that category -- I see those as the weakest possible way of controlling any new owner and holding it accountable.
Greg
*Example Principal Terms of Intellectual Property Agreements* This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background* The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- iana.org, iana.net, and iana.com. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community.
GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets.
According to the IETF Trust Agreement ( http://trustee.ietf.org/trust-agreement-2014.html) the beneficiary of the IETF Trust is the IETF (rather than the IETF community), and the successor Beneficiary is "the IETF's successor with respect to the development of technical standards for the Internet." As I understand it, the IETF is an "organized activity" of ISOC, and not a legal entity. Thus, in some sense, ISOC (as the legal entity) is the beneficiary of the IETF Trust. This is also significant in understanding the nature of the IETF Trust, since the beneficiary of a trust has unique rights, including rights with regard to the trust's assets. The beneficiary is also owed unique duties by the Trustees, particularly the duty to act in the interests of the beneficiary.
The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up.
More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel).
Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
GSS: I agree that a License Agreement (or License and Lease Agreement, or something similar) will be needed for any future owner to grant rights to use trademarks and domain names to the IANA Functions Operator(s) (or, in this email's terms, the "IANA service provider(s)").
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks. This "Quality Control" obligation is at the heart of any trademark licensor/licensee relationship. That said, to the extent the OC's have (or will have) their own quality control mechanisms, the trust should be able to take advantage of these to a very great extent in satisfying its quality control obligations. This is another topic that would need to be covered in the Community Assurance Agreements (or other mechanisms put in place).
*C. Terms* The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust)* a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org(GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
GSS: These terms seem broadly customary and acceptable, but would need significant review by the CWG and its counsel.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community)* a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
GSS: Does the IETF contemplate one or three of these agreements? Earlier in the email it seems to be three, but in this discussion it appears to be one. If this is the method chosen for the relationship between the OC's and the trust, there is not enough stated to really define the relationship, and some of the details that are here may not work. The interrelationship between the OC's needs to be clarified. The party or parties representing the names community will also be an issue.
*C.3. IANA IP License Agreement (between IETF Trust and PTI)* a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well). The trust should not retain any
right to use the trademarks; it is here only to serve as licensor. Some of the terms here seem to be taken from a copyright license ("display and reproduce"), but that will be taken care of....
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
GSS: As noted above, the quality control requirements must apply to the goods and services offered by the licensee. This needs to be absolutely explicit in any summary of this (or any other) trademark license agreement. Without it, we would have a "naked license," which is a major "no-no." A naked license can lead to abandonment of the mark, cancellation of the registrations, and loss of the mark's capacity to be a trademark. The quality of the use of the mark is a separate and much less important obligation between licensor and licensee.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall useiana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
GSS: The role of the OC's in relationship to these rights must be clarified, including rights to cause the trust to enforce (or not) against a particular infringer, the course of such enforcement, and the apportionment of damages received, if any)
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
GSS: This would have to be limited by any transitional requirements, both by the "losing" licensee and the "gaining" licensee.
On Sun, Jan 10, 2016 at 11:30 PM, Mueller, Milton L <milton@gatech.edu> wrote:
I like what I see here. Clear thinking about what any trust needs to do for us, and in particular the community assurance agreement and the commitment to maintain, monitor and license the use of the marks addresses the concerns some had about the IETF Trust.
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Jonathan Robinson *Sent:* Friday, January 8, 2016 12:56 PM *To:* cwg-stewardship@icann.org *Subject:* [CWG-Stewardship] FW: IPR follow up
Please see below for draft principal terms as provided by Jari Arkko.
Note that this draft was provided as an example that “could apply to other parties as well as the IETF Trust, are in no way set in stone, but hopefully they give some indication of the kind of arrangements that could be done.”
——
*Example Principal Terms of Intellectual Property Agreements * This draft relates to a possible use of IETF Trust as an independent entity to hold IANA-related IPR. The IETF Trust is one of the discussed alternative holders of IPR.
This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein. The IETF Trust has provided this draft as a hopefully helpful initial contribution, but clearly discussion in the various communities and further work is needed. Comments are appreciated.
*A. Background*
The ICG proposal indicates that the IANA trademark and iana.org domain should be transferred to an entity independent of the IANA Numbering Services Operator.
The IETF Trust would be a potentially acceptable candidate for this role, and the Trust has discussed the implications of assuming this responsibility. The following is some background of the Trust’s position and an overview of how the role and responsibilities may be fulfilled.
While this fulfillment is a part of implementation rather than the ICG proposal, the IETF Trust wants to ensure progress on determining those implementation steps. The Trust is of course only one of the possible ways to satisfy the requirements from the ICG proposal. Nevertheless, the Trust wanted to start by suggesting an overall framework for one way of satisfying the requirements.
The IETF Trust is a Virginia USA private trust, the trustees of which are the members of the IETF Administrative Oversight Committee (IAOC), and the beneficiary of which is the IETF community. The purpose of the IETF Trust includes acquiring, holding, maintaining and licensing certain existing and future intellectual property and other property used in connection with the Internet standards process and its administration, for the advancement of the science and technology associated with the Internet and related technology.
*B. Framework*
The Trust believes it would need to enter into three different types of agreements to effect the transfer of the IANA intellectual property (IP) and to enter into licensing arrangements with the IANA service provider(s).
These agreements include:
1. An Agreement between ICANN and the IETF Trust transferring the IANA IP to the IETF Trust
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
3. Agreement(s) whereby the IETF Trust provides for the use of the iana.org domain, or a subdomain, and licenses the use of the IANA trademarks to the IANA service provider(s) selected by the IANA communities.
The Trust understands that each community would need to follow its own internal processes before entering into any agreements, or selecting an IANA service provider. The same is true of the Trust itself.
The Community Assurance Agreements with the IANA communities would establish and recognize the responsibilities for each community to identify and enter into agreement with their selected service provider, and for the IETF Trust to provide, update, and revoke licenses as needed to support these selections.
In order to preserve the value and integrity of the IANA trademarks, the IETF Trust would maintain, license and monitor the use of the trademarks. Trust actions would include enforcement against unauthorized users and monitoring the quality and uses by the licensed user(s). The Trust would work with the relevant IANA communities to address issues involving a licensee before taking action to maintain the quality of the trademarks.
*C. Terms *
The following contains examples of the principal terms that may need to be included in such agreements should the community desire for the IETF Trust to take on the role of the Independent Entity. This non-binding draft has been prepared in order to assist in discussion only. No offer to enter into a binding agreement is expressed or implied herein.
*C.1. IP Transfer Agreement (between ICANN and IETF Trust) * a. When requested by the IETF Trust, ICANN will transfer and assign all of its rights in and to the IANA IP, including all goodwill therein, to the IETF Trust (the “Transfer”). The IETF Trust will not assume any obligations or liabilities of ICANN that arose prior to the Transfer.
b. ICANN will file all necessary assignment documentation with all local, national and regional offices in which the IANA IP is registered including, without limitation, the U.S. Patent and Trademark Office and the registrar for iana.org (GoDaddy), and will pay all fees associated with such filings. With respect to iana.org and any other domain names within the IANA IP, the IETF Trust will be designated as the administrative contact with the registrar.
c. ICANN will make customary representations and warranties to the IETF Trust regarding title to the IANA IP, absence of actual or threatened litigation, the existence of any licenses or other encumbrances on the IANA IP, and non-infringement of third party rights, all qualified by the knowledge of ICANN’s in-house legal department.
d. ICANN will indemnify the IETF Trust, PTI and any future licensee of the IANA IP against any liability associated with use of the IANA IP prior to the Transfer Date. The IETF Trust will indemnify ICANN and any prior licensee of the IANA IP against any liability associated with use of the IANA IP after the Transfer Date to the extent that IETF Trust receives a comparable indemnity from PTI or its successor entity.
*C.2. Community Assurance Agreement (between IETF Trust, IETF, RIRs, and the names community) * a. This Agreement will ensure that the IETF Trust holds and licenses the IANA IP in a manner that is agreed with the IETF, RIRs and the names community.
b. For purposes of this Agreement, the RIRs, the IETF and the names community will each select a single Representative to be the point of contact with the IETF Trust on matters pertaining to the IANA IP, collectively the “IANA IP Reps”.
c. The IETF Trust will hold, maintain and renew the IANA IP in accordance with good IP management practices and shall seek new territorial registrations based on the IANA IP as instructed by the IANA IP Reps.
d. The IETF Trust will license the IANA IP to PTI and any successor provider(s) of the IANA functions identified by the IANA IP Reps. Such license shall include the provisions described in Part III below. The IETF Trust will terminate the license to PTI or any successor upon the instructions of the IANA IP Reps.
*C.3. IANA IP License Agreement (between IETF Trust and PTI) * a. The IETF Trust will grant PTI a non-exclusive, worldwide, royalty-free license, without the right to sublicense, to display and reproduce the IANA marks in connection with its provision and marketing of the IANA functions.
b. All use of the IANA marks shall be in accordance with mutually-agreed quality requirements, as well as size, color, placement and similar guidelines to be agreed.
c. The IETF Trust will authorize PTI to operate via the iana.org domain and any number of sub-domains. IETF Trust shall appoint PTI as the technical contact for the iana.org domain during the term of the agreement. PTI shall use iana.org and all associated subdomains exclusively for purposes of offering the IANA functions.
d. All goodwill arising from use of the IANA IP will inure to the benefit of the IETF Trust, and PTI will not register or reserve any mark that contains, is identical or confusingly similar to any IANA mark in any jurisdiction, whether as a trademark, service mark, trade name or domain name.
e. The IETF Trust will have the sole right to enforce the IANA marks against infringers, at its expense. PTI will use reasonable efforts to notify IETF Trust of any such infringement that comes to its attention. IETF Trust will be entitled to retain all damages received as a result of its enforcement of the IANA marks.
f. The IETF Trust will be entitled to terminate the agreement, without penalty, following a material breach by PTI which is not cured within 30 days following notice thereof, an insolvency or bankruptcy event by PTI, the involvement of PTI or any of its officers or directors in any criminal, civil or regulatory proceeding or investigation that is likely, in IETF Trust’s opinion, to tarnish the IANA marks or the reputation of IETF, the termination, expiration or non-renewal of the PTI Service Agreement(s), or upon the express instruction of the IANA IP Reps.
g. Upon termination of the agreement, PTI will immediately cease all use of the IANA IP and shall transfer technical control of the iana.org domain to the IETF Trust.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
GS wrote: Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust. MM: Greg, when you say things like that, you lose a lot of credibility in this discussion. There is a vast difference in complexity, time, and uncertainty in creating an entirely new entity and governance structure versus adding a function to an existing, known, functioning and widely trusted entity. There are already widespread concerns that the proposal is too complex and prior to this several options were rejected because they were creating new structures. Now you want to add another Ptolemaic cycle to the celestial machine. During our discussions of the DT-IPR principles you have repeatedly attempted to transform and enlarge the concept of “neutrality” to include some kind of shared governance role for all three OCs, despite the fact that the IETF Trust provides the only type of neutrality that is really needed for a separable IANA, which is the community assurance agreement. Two of the three OCs have formalized their support for IETF Trust, and in the third one, as far as I can tell, no one else I know of has echoed your concerns about this. We do need to have the discussion of the principles we worked up in DT-IPR, but please don’t be surprised or become obstructionist when you learn that most of us are ready to move on and get this done. --MM
Hi, On Mon, Jan 11, 2016 at 01:56:41PM -0500, Greg Shatan wrote:
But to my mind, it is expedient rather than preferable.
I won't speak for the IETF Trust, but speaking as a Trustee I can say that _I_ think it is expedient rather than preferable, too. Given that whatever we do has to be completely sewn up in time for a transition in Q4 of 2016 (i.e. roughly 10 months from now), I think that "expedient and workable" ought to be a high-value qualifying criterion.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust.
You are suggesting is that hammering out a new trust agreement among three operational communities that will specify a new governance structure, and then hammering out all the other issues that one needs in an agreement, will take no more time than just doing the second of those things. I would like to know why you think that. It's certainly true that setting up a new trust is the work of an afternoon for a competent lawyer. But I don't think that's the hard part here. Given that we've had months to tackle this question and haven't yet even agreed amongst ourselves what principles should apply, I cannot say I'm optimistic that setting up a completely new legal entity in collaboration with two other communities -- both of which have to go through their own consensus processes in order to agree to do it -- will be the fast path. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, You’ve spoken too mildly. Setting up a lightweight trust that parallels the IETF Trust is indeed a small piece of work, but the direction of the proposal for a separate trust is implies a LOT of work, exploration of an unbounded and undefined set of issues, and an unclear but potentially substantial level of expenditure. So, your suggestion that expedient and workable should be given high value is indeed a strong point. But I will suggest the argument in favor of the IETF Trust is even stronger. The marks and domain names were transferred from the IETF to ICANN as part of the creation of the IETF Administrative Support Activity (IASA), in 2005. (I think I have the date correct.) Prior to that, the marks were held by the Corporation for National Research Initiatives (CNRI), Bob Kahn’s non-profit operation. There was a lengthy tussle between Bob Kahn and the IETF that lasted a few years. Bob had been providing the support for the IETF and had been controlling its funds. Eventually, Bob withdrew from providing these services and controlling the funds, and the IETF took control of its finances and its services. The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF. In my view, it is entirely natural and appropriate for these marks to be placed in the IETF Trust and that arrangements for their continued use by ICANN in order to provide the IANA service is all that’s necessary. Steve On Jan 12, 2016, at 1:31 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Mon, Jan 11, 2016 at 01:56:41PM -0500, Greg Shatan wrote:
But to my mind, it is expedient rather than preferable.
I won't speak for the IETF Trust, but speaking as a Trustee I can say that _I_ think it is expedient rather than preferable, too. Given that whatever we do has to be completely sewn up in time for a transition in Q4 of 2016 (i.e. roughly 10 months from now), I think that "expedient and workable" ought to be a high-value qualifying criterion.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust.
You are suggesting is that hammering out a new trust agreement among three operational communities that will specify a new governance structure, and then hammering out all the other issues that one needs in an agreement, will take no more time than just doing the second of those things. I would like to know why you think that. It's certainly true that setting up a new trust is the work of an afternoon for a competent lawyer. But I don't think that's the hard part here. Given that we've had months to tackle this question and haven't yet even agreed amongst ourselves what principles should apply, I cannot say I'm optimistic that setting up a completely new legal entity in collaboration with two other communities -- both of which have to go through their own consensus processes in order to agree to do it -- will be the fast path.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Steve, The history you are recounting seems to be primarily the story of the IETF trademarks, not the IANA trademarks. This is based on my review of US Patent & Trademark Office records. Specifically, it was the IETF trademarks that were originally applied for by CNRI. The IETF SECRETARIAT mark was applied for in 1999 by CNRI, and registered in 2000. The IETF and IETF Logo trademarks were applied for by CNRI in November 2005. On December 15, 2005, the IETF SECRETARIAT registration and the two IETF applications were assigned to the IETF Trust. (Assignment attached) The two applications subsequently registered in the name of the IETF Trust. The history of the IANA trademarks is quite different: USC applied to register two trademarks in 1997: IANA and INTERNET ASSIGNED NUMBERS AUTHORITY. These both registered in the name of USC in 1999. In 2000, USC and ICANN entered into a “USC/ICANN Transition Agreement” in which USC agreed to assign to ICANN the marks INTERNET ASSIGNED NUMBERS AUTHORITY, IANA and IANA (Logo form). USC also signed an assignment document, transferring to ICANN USC’s "entire right, title and interest” in and to (i) Reg. No. 2,277,028 for IANA, (ii) Reg. No. 2,217978 for INTERNET ASSIGNED NUMBERS AUTHORITY, and (iii) the common law trademark rights to the IANA Logo. (Assignment attached) ICANN filed its own applications for the IANA Logo (in 2001), INTERNET ASSIGNED NUMBERS AUTHORITY (in 2003) and IANA in 2007, all of which subsequently registered in the name of ICANN. (These newer registrations improved upon and replaced the original USC registrations.) I see no evidence that CNRI or IETF ever had any ownership interest or other interest in the IANA marks, or that either entity engaged in any transaction with ICANN regarding the IANA marks. I find this very hard to reconcile with the claim that "The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF." Perhaps you were thinking of the IETF marks? Any help in clearing all this up would be most appreciated. Greg On Tue, Jan 12, 2016 at 1:48 AM, Steve Crocker <steve.crocker@icann.org> wrote:
Andrew,
You’ve spoken too mildly. Setting up a lightweight trust that parallels the IETF Trust is indeed a small piece of work, but the direction of the proposal for a separate trust is implies a LOT of work, exploration of an unbounded and undefined set of issues, and an unclear but potentially substantial level of expenditure. So, your suggestion that expedient and workable should be given high value is indeed a strong point. But I will suggest the argument in favor of the IETF Trust is even stronger.
The marks and domain names were transferred from the IETF to ICANN as part of the creation of the IETF Administrative Support Activity (IASA), in 2005. (I think I have the date correct.) Prior to that, the marks were held by the Corporation for National Research Initiatives (CNRI), Bob Kahn’s non-profit operation. There was a lengthy tussle between Bob Kahn and the IETF that lasted a few years. Bob had been providing the support for the IETF and had been controlling its funds. Eventually, Bob withdrew from providing these services and controlling the funds, and the IETF took control of its finances and its services. The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF. In my view, it is entirely natural and appropriate for these marks to be placed in the IETF Trust and that arrangements for their continued use by ICANN in order to provide the IANA service is all that’s necessary.
Steve
On Jan 12, 2016, at 1:31 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Mon, Jan 11, 2016 at 01:56:41PM -0500, Greg Shatan wrote:
But to my mind, it is expedient rather than preferable.
I won't speak for the IETF Trust, but speaking as a Trustee I can say that _I_ think it is expedient rather than preferable, too. Given that whatever we do has to be completely sewn up in time for a transition in Q4 of 2016 (i.e. roughly 10 months from now), I think that "expedient and workable" ought to be a high-value qualifying criterion.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust.
You are suggesting is that hammering out a new trust agreement among three operational communities that will specify a new governance structure, and then hammering out all the other issues that one needs in an agreement, will take no more time than just doing the second of those things. I would like to know why you think that. It's certainly true that setting up a new trust is the work of an afternoon for a competent lawyer. But I don't think that's the hard part here. Given that we've had months to tackle this question and haven't yet even agreed amongst ourselves what principles should apply, I cannot say I'm optimistic that setting up a completely new legal entity in collaboration with two other communities -- both of which have to go through their own consensus processes in order to agree to do it -- will be the fast path.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Greg, Thanks for the quick response. I confess my focus is almost entirely on the control of the domain names. I know you place great weight on the control of the trademarks, but I truly believe that’s of only modest concern in this context. I have asked a couple of the current IETF Trust trustees to recover the sequence related to the domain names. Meanwhile, even with the record of the IANA trademarks being created at USC and transferred to ICANN, my sense is the creation of the IANA function in the first place and its mode of operation was by agreement with the IETF and its predecessors. I understand this might not seem relevant to you if you’re researching only court and agency filings, but the connection between the IETF and the IANA function is at the absolute core of the de facto history. Steve On Jan 12, 2016, at 2:44 AM, Greg Shatan <gregshatanipc@gmail.com> wrote:
Steve,
The history you are recounting seems to be primarily the story of the IETF trademarks, not the IANA trademarks. This is based on my review of US Patent & Trademark Office records.
Specifically, it was the IETF trademarks that were originally applied for by CNRI. The IETF SECRETARIAT mark was applied for in 1999 by CNRI, and registered in 2000. The IETF and IETF Logo trademarks were applied for by CNRI in November 2005. On December 15, 2005, the IETF SECRETARIAT registration and the two IETF applications were assigned to the IETF Trust. (Assignment attached) The two applications subsequently registered in the name of the IETF Trust.
The history of the IANA trademarks is quite different:
USC applied to register two trademarks in 1997: IANA and INTERNET ASSIGNED NUMBERS AUTHORITY. These both registered in the name of USC in 1999. In 2000, USC and ICANN entered into a “USC/ICANN Transition Agreement” in which USC agreed to assign to ICANN the marks INTERNET ASSIGNED NUMBERS AUTHORITY, IANA and IANA (Logo form). USC also signed an assignment document, transferring to ICANN USC’s "entire right, title and interest” in and to (i) Reg. No. 2,277,028 for IANA, (ii) Reg. No. 2,217978 for INTERNET ASSIGNED NUMBERS AUTHORITY, and (iii) the common law trademark rights to the IANA Logo. (Assignment attached) ICANN filed its own applications for the IANA Logo (in 2001), INTERNET ASSIGNED NUMBERS AUTHORITY (in 2003) and IANA in 2007, all of which subsequently registered in the name of ICANN. (These newer registrations improved upon and replaced the original USC registrations.)
I see no evidence that CNRI or IETF ever had any ownership interest or other interest in the IANA marks, or that either entity engaged in any transaction with ICANN regarding the IANA marks. I find this very hard to reconcile with the claim that "The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF." Perhaps you were thinking of the IETF marks?
Any help in clearing all this up would be most appreciated.
Greg
On Tue, Jan 12, 2016 at 1:48 AM, Steve Crocker <steve.crocker@icann.org> wrote: Andrew,
You’ve spoken too mildly. Setting up a lightweight trust that parallels the IETF Trust is indeed a small piece of work, but the direction of the proposal for a separate trust is implies a LOT of work, exploration of an unbounded and undefined set of issues, and an unclear but potentially substantial level of expenditure. So, your suggestion that expedient and workable should be given high value is indeed a strong point. But I will suggest the argument in favor of the IETF Trust is even stronger.
The marks and domain names were transferred from the IETF to ICANN as part of the creation of the IETF Administrative Support Activity (IASA), in 2005. (I think I have the date correct.) Prior to that, the marks were held by the Corporation for National Research Initiatives (CNRI), Bob Kahn’s non-profit operation. There was a lengthy tussle between Bob Kahn and the IETF that lasted a few years. Bob had been providing the support for the IETF and had been controlling its funds. Eventually, Bob withdrew from providing these services and controlling the funds, and the IETF took control of its finances and its services. The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF. In my view, it is entirely natural and appropriate for these marks to be placed in the IETF Trust and that arrangements for their continued use by ICANN in order to provide the IANA service is all that’s necessary.
Steve
On Jan 12, 2016, at 1:31 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Mon, Jan 11, 2016 at 01:56:41PM -0500, Greg Shatan wrote:
But to my mind, it is expedient rather than preferable.
I won't speak for the IETF Trust, but speaking as a Trustee I can say that _I_ think it is expedient rather than preferable, too. Given that whatever we do has to be completely sewn up in time for a transition in Q4 of 2016 (i.e. roughly 10 months from now), I think that "expedient and workable" ought to be a high-value qualifying criterion.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust.
You are suggesting is that hammering out a new trust agreement among three operational communities that will specify a new governance structure, and then hammering out all the other issues that one needs in an agreement, will take no more time than just doing the second of those things. I would like to know why you think that. It's certainly true that setting up a new trust is the work of an afternoon for a competent lawyer. But I don't think that's the hard part here. Given that we've had months to tackle this question and haven't yet even agreed amongst ourselves what principles should apply, I cannot say I'm optimistic that setting up a completely new legal entity in collaboration with two other communities -- both of which have to go through their own consensus processes in order to agree to do it -- will be the fast path.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
<assignment-tm-2283-0068.pdf><assignment-tm-3312-0222.pdf>
Thank you Steve for providing further historical background to this and hopefully it helps answer Greg's question about the uniqueness of the IETF (in this context) and the appropriateness in transferring the marks to them. Overall I think there is a common understanding on the promptness that would be ensured using the IETF trust. Since there is no immediate negative consequences of the transfer that is envisaged coupled with the fact that this issue is a dependency for the transition, I suggest that we move on using the IETF trust. For the record, I am in support of ensuring that there will still be opportunity provided to transfer from IETF to a newly setup trust whenever it's absolutely required (though I don't envisage this). Regards On 12 Jan 2016 7:50 a.m., "Steve Crocker" <steve.crocker@icann.org> wrote:
Andrew,
You’ve spoken too mildly. Setting up a lightweight trust that parallels the IETF Trust is indeed a small piece of work, but the direction of the proposal for a separate trust is implies a LOT of work, exploration of an unbounded and undefined set of issues, and an unclear but potentially substantial level of expenditure. So, your suggestion that expedient and workable should be given high value is indeed a strong point. But I will suggest the argument in favor of the IETF Trust is even stronger.
The marks and domain names were transferred from the IETF to ICANN as part of the creation of the IETF Administrative Support Activity (IASA), in 2005. (I think I have the date correct.) Prior to that, the marks were held by the Corporation for National Research Initiatives (CNRI), Bob Kahn’s non-profit operation. There was a lengthy tussle between Bob Kahn and the IETF that lasted a few years. Bob had been providing the support for the IETF and had been controlling its funds. Eventually, Bob withdrew from providing these services and controlling the funds, and the IETF took control of its finances and its services. The transfer of the IANA marks to ICANN was with the clear understanding these fundamentally belonged to the IETF. In my view, it is entirely natural and appropriate for these marks to be placed in the IETF Trust and that arrangements for their continued use by ICANN in order to provide the IANA service is all that’s necessary.
Steve
On Jan 12, 2016, at 1:31 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Mon, Jan 11, 2016 at 01:56:41PM -0500, Greg Shatan wrote:
But to my mind, it is expedient rather than preferable.
I won't speak for the IETF Trust, but speaking as a Trustee I can say that _I_ think it is expedient rather than preferable, too. Given that whatever we do has to be completely sewn up in time for a transition in Q4 of 2016 (i.e. roughly 10 months from now), I think that "expedient and workable" ought to be a high-value qualifying criterion.
Actually, I think it would be quite helpful. Furthermore, I don't think that there are significant economic or resource differences between working up an arrangement with the IETF and working up an arrangement for a new trust.
You are suggesting is that hammering out a new trust agreement among three operational communities that will specify a new governance structure, and then hammering out all the other issues that one needs in an agreement, will take no more time than just doing the second of those things. I would like to know why you think that. It's certainly true that setting up a new trust is the work of an afternoon for a competent lawyer. But I don't think that's the hard part here. Given that we've had months to tackle this question and haven't yet even agreed amongst ourselves what principles should apply, I cannot say I'm optimistic that setting up a completely new legal entity in collaboration with two other communities -- both of which have to go through their own consensus processes in order to agree to do it -- will be the fast path.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, I think Jari actually answered some of these, but I'll make some remarks below. On Mon, Jan 11, 2016 at 11:01:33AM -0500, Greg Shatan wrote:
Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose?
I really would like the CWG to come to a quick decision about that. The IETF Trust has offered to do this really just because it seemed easier than working out a new trust agreement and all the checks and balances that Greg seems above to be suggesting are important. If the CWG thinks those are important, then the IETF Trust can stop doing any preparation work around this.
GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- iana.org, iana.net, and iana.com. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?
Yes, that's the idea.
GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets.
The words "a provate trust" came from the IETF Trust's lawyer. So yes, I'm pretty sure.
GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)
There seems to have been a paperwork snafu in this case, which came to my attention last fall when we started talking about doing this. I've asked again why this isn't fixed yet. I regard it as a high priority item. The IETF Trustees actually sign something explicitly taking this duty on when we become Trustees, so I was both vexed and surprised to discover the completion of that work was incomplete.
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up.
It's just the name we came up with for the kind of agreement we'd need. Yes, the terms are the important thing.
More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel).
As I think I've said repeatedly, the "control the actions of the trust" bit would require changes to the IETF Trust itself, and I don't think that's a practical alternative. So the CWG really needs to make up its collective mind as to whether the IETF Trust with some sort of agreement between it and the names community (ICANN, I guess?) will be an acceptable solution. If so, we can get to work on the terms of that agreement (and this is just one suggestion, in the interests of having something concrete to talk about). IF not, then we have a different problem, and it'll be important to know that pronto.
Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.
It's hard for me to see how the communities can have "control", since as you keep pointing out it is the trade mark holder (which would be the Trust) that has the duty to make decisions about the trademark. So, the Trust (whichever Trust we use) ends up having to assure the community that it will act in accordance with community wishes. Hence the name.
GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.
I don't understand the imbalance you see, but the IETF Trustees can be removed according to the IETF recall procedures and otherwise can't be. It is a waste of time to explore changing those arrangements, because it would involve a full IETF process discussion (which, I assure you, you probably don't want to start) requiring opening a fairly delicate set of issues. If the CWG really thinks that it cannot get the assurances it needs from the IETF Trust, then we should simply say so and tell the other communities that we need to get a new trust in place.
IETF Trust would maintain, license and monitor the use of the trademarks.
GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks.
I think this is plainly a distinction that is important to you, because you keep talking about it, but I think in that text you can assume the distinction isn't being attended to. We agree that any trust would need to monitor that quality of goods and services. The way to do that, of course, is to ask the relevant community whether it is satisfied.
GSS: Does the IETF contemplate one or three of these agreements?
I don't think we care. For the sake of simplicity it might be easier to do three bilateral agreements.
GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well).
That would appear to me to create yet another barrier to such an alternative IFO, without any obvious benefit. Why do it that way?
GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.
I don't see how you can have it this way and still have the Trust own the trademark. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew, Thanks for your comments. My responses are below yours. Greg On Mon, Jan 11, 2016 at 1:23 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
I think Jari actually answered some of these, but I'll make some remarks below.
On Mon, Jan 11, 2016 at 11:01:33AM -0500, Greg Shatan wrote:
Particularly, we need to determine whether an entity controlled by IETF's administrative group with the IETF as its sole beneficiary is an appropriate home for a resource shared among the three operating communities? Should any entity holding the IPR ultimately be controlled by all 3 communities? Would a shared, purpose-built trust be more appropriate in the long run for holding the IPR, rather than using an entity built for another purpose?
I really would like the CWG to come to a quick decision about that. The IETF Trust has offered to do this really just because it seemed easier than working out a new trust agreement and all the checks and balances that Greg seems above to be suggesting are important. If the CWG thinks those are important, then the IETF Trust can stop doing any preparation work around this.
GSS: There are 3 trademarks, each separately registered with the US Patent & Trademark Office: "Internet Assigned Numbers Authority", "IANA" and the IANA logo (which, as registered, includes the phrase "Internet Assigned Numbers Authority"). There are also 3 domains -- iana.org, iana.net, and iana.com. Presumably, all of these would be transferred away from ICANN to the trust. Can you confirm that is the intention?
Yes, that's the idea.
GSS: Are you sure that the IETF Trust is a "private trust" and not a "public trust"? As I understand it, private trust is a trust created to benefit a particular named entity, person or set of persons. In contrast, a public trust (also known as a charitable trust) is created for a charitable purpose. This is significant in understanding the nature of the IETF Trust, as well as the relationship between the beneficiary and the trust's assets.
The words "a provate trust" came from the IETF Trust's lawyer. So yes, I'm pretty sure.
If this is a private trust, set up for the benefit of the IETF, and not a public (i.e., charitable) trust, set up for a public benefit, that raises significant concerns about its fitness for purpose here. Can you double check this with counsel, and forward him my comment above? By the way, who is the lawyer in this instance?
GSS: I agree that an Assignment Agreement will be needed to transfer the IANA IPR to any future owner. (Note that the USPTO disregards trusts as trademark owners, so the owners of record would be the trustees (and would need to be updated when these change -- I note that the IETF Trust has neglected to do this with its own marks).)
There seems to have been a paperwork snafu in this case, which came to my attention last fall when we started talking about doing this. I've asked again why this isn't fixed yet. I regard it as a high priority item. The IETF Trustees actually sign something explicitly taking this duty on when we become Trustees, so I was both vexed and surprised to discover the completion of that work was incomplete.
2. Community Assurance Agreements between the IETF Trust and each of the names, numbers, and protocol communities (the IANA communities) regarding the Trust’s commitments to each as further described below, and
GSS: I am not familiar with this type of agreement. Is this a novel agreement, invented for this purpose? If not, it would be helpful to be pointed to information on this type of agreement. If these are novel, they could include almost anything; as such, their terms would be absolutely critical to the success of any set-up.
It's just the name we came up with for the kind of agreement we'd need. Yes, the terms are the important thing.
More broadly, this is only one of several ways in which the OC's could relate to and control the actions of the trust. Although I appreciate this as one suggestion, it would be appropriate to consider the alternatives (especially since this alternative appears to be novel).
As I think I've said repeatedly, the "control the actions of the trust" bit would require changes to the IETF Trust itself, and I don't think that's a practical alternative. So the CWG really needs to make up its collective mind as to whether the IETF Trust with some sort of agreement between it and the names community (ICANN, I guess?) will be an acceptable solution. If so, we can get to work on the terms of that agreement (and this is just one suggestion, in the interests of having something concrete to talk about). IF not, then we have a different problem, and it'll be important to know that pronto.
I too hope that we can get to the nub of the issues here. It's unfortunate that the IETF is not more flexible about remaking the trust into a form more appropriate for a shared asset, but perhaps that's helpful in that it gives us fewer and clearer alternatives (i.e., take the IEFT Trust as is or don't take it at all). "Some sort of agreement" is unfortunately rather vague. What's critical at this point is the "balance of power" between the OCs (on the one hand) and the IETF Trust (on the other hand). I should think that the CWG, having wrested control of the IANA marks and domain names from ICANN, would not just hand that IPR over to an entity over which it has even less control, and which is controlled by and governed for the benefit of another OC (i.e., IETF).
Finally, the term "Assurance Agreement" is peculiar, and presumably intended to invoke a particular type of relationship. I would be curious to know more about this "assurance" relationship. I would probably call these "Community Control Agreements" -- but that would invoke a different type of relationship. This is not a semantic issue -- it's critical to know how the parties view their relationship to each other.
It's hard for me to see how the communities can have "control", since as you keep pointing out it is the trade mark holder (which would be the Trust) that has the duty to make decisions about the trademark. So, the Trust (whichever Trust we use) ends up having to assure the community that it will act in accordance with community wishes. Hence the name.
This is exactly why having the OCs structurally part of the governance of the trademark owner would be preferable -- in that set-up the issue of control is dealt with quite naturally (just as control of the IETF Trust by the IETF is dealt with quite naturally now). Failing that, we will need to gain as much control as possible, by use of agreements, advisory boards and the like. I strongly disagree that "assurance" is the only approach to that relationship.
GSS: The Community Assurance Agreements (and/or any other arrangements put in place) need to do more than this -- they need to establish how the OC's control the actions of the trust and how they hold the trust accountable (up to and including removal of trustees and transferring the IANA trademarks and domain names away from the trust if it is not acting in accordance with its obligations). As noted above, the IETF AOC also act as the Trustees of the IETF Trust. This creates an imbalance that needs to be addressed if the IETF Trust is to be the future owner.
I don't understand the imbalance you see, but the IETF Trustees can be removed according to the IETF recall procedures and otherwise can't be. It is a waste of time to explore changing those arrangements, because it would involve a full IETF process discussion (which, I assure you, you probably don't want to start) requiring opening a fairly delicate set of issues. If the CWG really thinks that it cannot get the assurances it needs from the IETF Trust, then we should simply say so and tell the other communities that we need to get a new trust in place.
Fair enough. The imbalance is simple -- the IETF Trust is controlled by the IETF and set up for the benefit of the IETF, and the Trustees owe a fiduciary duty to the IETF (and nobody else) to manage the Trust and its assets for the benefit of the IETF (and nobody else). [This is consistent with the IETF Trust being a "private trust," by the way; hence the relevance of that question.]
IETF Trust would maintain, license and monitor the use of the trademarks.
GSS: This overlooks (probably inadvertently) the key obligation of a trademark licensor -- to monitor the quality of the goods and services offered by the licensee. This is a different obligation than monitoring the use of the trademarks.
I think this is plainly a distinction that is important to you, because you keep talking about it, but I think in that text you can assume the distinction isn't being attended to. We agree that any trust would need to monitor that quality of goods and services. The way to do that, of course, is to ask the relevant community whether it is satisfied.
It's a distinction that's important (really, critical) under trademark law. A license without control over quality of goods/services is a form of trademark suicide. I appreciate the clarification that in fact the IETF Trust understands it needs to maintain quality control over goods/services. and I agree that a strong and possibly even leading role should be played by the OCs (who through MoUs or the CSC will already being doing just that).
GSS: Does the IETF contemplate one or three of these agreements?
I don't think we care. For the sake of simplicity it might be easier to do three bilateral agreements.
GSS: Initially, this license should be exclusive, until another entity takes on a role as an IFO for names, numbers or protocols, and thus needs a license as well).
That would appear to me to create yet another barrier to such an alternative IFO, without any obvious benefit. Why do it that way?
The "benefit" is getting it right. A non-exclusive license is one that allows the licensor to continue to use the marks even for the identical goods/services that the licensee is using the marks for. That is clearly not the intent here, so a non-exclusive license is not appropriate. An exclusive license is absolutely not a barrier to a single replacement IFO; the license to the current IFO would be terminated and a new license entered into with the new IFO (alternatively, the license could simply be assigned by the current IFO to the new IFO). If multiple IFOs end up as the way things will work, the license can be assigned in part (or terminated in part) with regard to each OCs new IFO-of-choice. This just needs to be anticipated in the drafting of the license. Since this is clearly an obvious feature of "separability," I'm sure it will be well taken care of.
GSS: This is unacceptable. The trust cannot have a unilateral right to terminate the license, so long as one or more OC's wishes to have PTI continue as its IFO. The trust should only be able to terminate the license upon express instruction from one or more OC's, and unless its from all 3 OC's, the termination would have to be partial (limited to the relevant function) while continuing for the remaining OC's. I should also note that these are particularly "licensor-favorable" (as opposed to neutral) termination rights, based on my experience with trademark licenses.
I don't see how you can have it this way and still have the Trust own the trademark.
I don't understand why you say that. The IETF Trust (or any new owner) cannot have the unilateral right to terminate an IFO over the objections of the community that wants to use that IFO. This could point to another serious concern with using the IETF Trust as a holder of the IPR, so it's critically important to clarify this issue. Greg
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Hi, On Tue, Jan 12, 2016 at 03:55:32AM -0500, Greg Shatan wrote:
significant concerns about its fitness for purpose here. Can you double check this with counsel, and forward him my comment above? By the way, who is the lawyer in this instance?
I'll ask again, sure. The lawyer is the IETF's lawyer, Jorge Contreras.
I too hope that we can get to the nub of the issues here. It's unfortunate that the IETF is not more flexible about remaking the trust into a form more appropriate for a shared asset
Just to be clear, the reason I think the IETF won't do this is not because it's somehow pig-headed or inflexible. Instead, it's because such a change would be a distraction. To do it would take a lot of time and we'd need to be very careful. The main reason the IETF set up the Trust has to do with the IETF's main concerns (i.e. Internet standards): it's overhead as far as we're concerned. The IETF offered the Trust as a home for this IANA stuff because it was already there and therefore convenient. If it's not convenient, then there is no reason to use the IETF Trust at all, and certainly no reason to make our overhead more expensive (in time).
I should think that the CWG, having wrested control of the IANA marks and domain names from ICANN, would not just hand that IPR over to an entity over which it has even less control, and which is controlled by and governed for the benefit of another OC (i.e., IETF).
Given that the very existence of IANA is predicated on standards developed and published by the IETF, it seems to me you have a control problem of this sort anyway.
This is exactly why having the OCs structurally part of the governance of the trademark owner would be preferable -- in that set-up the issue of control is dealt with quite naturally (just as control of the IETF Trust by the IETF is dealt with quite naturally now). Failing that, we will need to gain as much control as possible, by use of agreements, advisory boards and the like. I strongly disagree that "assurance" is the only approach to that relationship.
Ok. If you strongly believe this we'd better get to work coming up with a new organizational structure in the next 2 or 3 months. Because each community is going to need to undertake its own consensus process and be past the appeals stage, and the IETF requires perhaps 6 months to guarantee that (I don't know about the RIRs). Not to put too fine a point on it, I'd be more sanguine if I thought this group could propose something simple enough to attract IETF support within a period anything close to 3 months.
not the intent here, so a non-exclusive license is not appropriate. An exclusive license is absolutely not a barrier to a single replacement IFO; the license to the current IFO would be terminated and a new license entered into with the new IFO (alternatively, the license could simply be assigned by the current IFO to the new IFO). If multiple IFOs end up as the way things will work, the license can be assigned in part (or terminated in part) with regard to each OCs new IFO-of-choice. This just needs to be anticipated in the drafting of the license. Since this is clearly an obvious feature of "separability," I'm sure it will be well taken care of.
You have nicely described the barrier I see: that's another thing to do _in future_ when there is some sort of contentious issue. I'd prefer to have the arrangements in place now to accommodate that. I think that's why Jorge concluded a non-exclusive license was right, but there might be another way to do it.
I don't understand why you say that. The IETF Trust (or any new owner) cannot have the unilateral right to terminate an IFO over the objections of the community that wants to use that IFO. This could point to another serious concern with using the IETF Trust as a holder of the IPR, so it's critically important to clarify this issue.
If any Trust is in fact legally responsible for quality control, then by definition it must be able to say, "So-and-so doesn't mean the test, we have to cancel," regardless of what the relevant operational community says. It's entailed by the duty to enforce. Hence the idea that the Trust in effect provides a definition of "quality" that builds in what the relevant communities think (the assurance agreements). The Trust has to be able to act unilaterally because it owns the trademark, but that unilateral action is defined in such a way that the Trust does what the community wants anyway. It appears to me that we have a deep difference of outlook here. To me, the key thing is that we arrange things so that the right thing happens. I get the feeling that you think the key thing is to have the formal powers arranged correctly, so that if something goes wrong legal action can perhaps provide a remedy. It is that division of outlook that makes me so pessimistic about the prospect of setting up a new entity quickly. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
I wanted to send a high-level follow-up — I had not followed this discussion in the last couple of days even though I had exchanged some private mail on the matter. From my perspective I wanted to highlight three things: * We wanted to provide an example, so that discussions could start. But it really is only an example, please feel free to pick it apart and suggest better ways. * The key piece from my perspective is what rights & responsibilities for the parties are set up by the agreements between the trust and the OCs. The OCs need to be comfortable that they get what they want. Again, please suggest what you need here. * We continue to offer IETF trust as a possible home for the setup. For practical reasons, such a setup works best when the IETF Trust can continue also its existing duties without too many distractions, which is why we have suggested structuring the setup as a set of contracts that govern the specific rights regarding the IANA IPR. But at least I personally have no particularly attachment to using the IETF Trust, other setups are also quite acceptable. However, being the practical engineers we wanted to provide something that is up and running and could be setup for further IPR holding quickly. For what it is worth, I also fully agree with what my colleague Andrew said in his e-mails on this thread. Jari
I wanted to send a high-level follow-up — I had not followed this discussion in the last couple of days even though I had exchanged some private mail on the matter. From my perspective I wanted to highlight three things: * We wanted to provide an example, so that discussions could start. But it really is only an example, please feel free to pick it apart and suggest better ways. * The key piece from my perspective is what rights & responsibilities for the parties are set up by the agreements between the trust and the OCs. The OCs need to be comfortable that they get what they want. Again, please suggest what you need here. * We continue to offer IETF trust as a possible home for the setup. For practical reasons, such a setup works best when the IETF Trust can continue also its existing duties without too many distractions, which is why we have suggested structuring the setup as a set of contracts that govern the specific rights regarding the IANA IPR. But at least I personally have no particularly attachment to using the IETF Trust, other setups are also quite acceptable. However, being the practical engineers we wanted to provide something that is up and running and could be setup for further IPR holding quickly. For what it is worth, I also fully agree with what my colleague Andrew said in his e-mails on this thread. Jari
Hi, I guess this has sort of been overtaken by events, given the WG's provisional conclusion, but for completeness: On Tue, Jan 12, 2016 at 03:55:32AM -0500, Greg Shatan wrote:
If this is a private trust, set up for the benefit of the IETF, and not a public (i.e., charitable) trust, set up for a public benefit, that raises significant concerns about its fitness for purpose here. Can you double check this with counsel, and forward him my comment above? By the way, who is the lawyer in this instance?
Jorge got back to me, and he said, "The IETF Trust is a Virginia common law trust, the beneficiary of which is the entire IETF community." In other words, this is a registered trust (as often used for business purposes) and not a trust for charitable purposes as such. I hope that helps. If more follow-up is needed, perhaps I can loop Jorge into the conversation. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
participants (7)
-
Andrew Sullivan -
Greg Shatan -
Jari Arkko -
Jonathan Robinson -
Mueller, Milton L -
Seun Ojedeji -
Steve Crocker