[CWG-Stewardship] FW: [client com] IPR Memo

Greg Shatan gregshatanipc at gmail.com
Mon Aug 17 21:05:13 UTC 2015


Andrew,


The meaning of "source or origin" in trademark law is considerably
different than the meaning used in your email below.

In the trademark context, the "source or origin" referred to is the source
of the goods or services currently being offered to a customer, not the
source of the idea for that service.  It is a "present day" analysis: if I
am buying these goods or services today, the trademark identifies a single
source that is providing me the service or manufactured the product that I
am now buying. Originally, this was construed so narrowly that trademark
licensing was prohibited.  Over time, by obligating a trademark owner to
actively engage in quality control over the goods and services (and to
reflect that in a contract), trademark licensing was allowed.  The
trademark licensee is not viewed as the "source or origin" of the product
or service -- the trademark owner (i.e., the licensor) continues to be the
"source or origin," even though they are not physically manufacturing the
product or providing the service.  The "goodwill" (or reputation) that
comes from making a good product or offering a good service accrues to the
benefit of the trademark owner, not the licensee.

"Source or origin" has nothing to do with "genesis" or historical
foundation; for trademark "source" purposes, it doesn't matte where the
idea for something comes from or where the function was first created, or
even where "standards" (in the sense of parameters set by a
standards-setting organization) are set.  All kinds of goods and services
must conform to external standards, whether set by governments or by
non-governmental standards-setting bodies (e.g., the ISO).  And of course,
those standards-setting bodies do amend standards from time to time.

So, when looking at the question of "source," the questions to be asked in
the IANA context by someone receiving a service from the IANA group at
ICANN are the following:  "Do I believe that the responsibility for the
execution of the service I am receiving today lies with ICANN or with some
other source? Do I believe that how well (or how poorly) that service is
being provided (e.g., how timely, how accurate, how professionally) is the
responsibility of ICANN or of some other entity?"

I believe that the answer in both cases is "ICANN."  That does not
denigrate the role of the IETF in any way.

Nor does it mean that ICANN cannot move from being the "source" of the
services to being a licensee, by transferring the IANA marks to a third
party and entering into a trademark license.  However, that would mean that
this third party would need to exercise active and ongoing "quality
control" over the services being delivered by ICANN (and potentially, some
other IANA service provider); that is not something that the IETF (or the
IETF Trust) does today.

Another important point: It's not necessary to argue that the IETF was
always somehow the "source and origin" for IANA services in order to
propose the IETF Trust as a potential home for the IANA brand.  That would
also be a "present day" analysis.

However, the argument that the IETF has always been and continues to be the
"source" of IANA services for trademark purposes does have several
unintended consequences.  First, the IETF has never entered into a license
for ICANN (or its predecessor as the IANA service provider) to use IANA or
Internet Assigned Numbers Authority as a trademark.  The IETF has never
exercised "quality control" in the trademark sense over ICANN or its
predecessor (or if it did, it stopped a very long time ago).  The IETF has
never challenged the trademark registrations owned by ICANN or its
predecessor.  All of these things would lead to a finding that the IETF had
abandoned the trademark and that whatever claim it once had to the
trademark is extinguished.  Conversely, if the IETF was the rightful owner
of the IANA trademarks at the time that the current registrations (or the
earlier registrations assigned to ICANN by its predecessor) were applied
for, then ICANN and its predecessor committed "fraud on the trademark
office," since the applicants claimed (as required by law) that they were
the rightful owners of the marks and that they know of no other party that
could make a claim to own the marks in connection with the relevant
services.  The end result of "fraud on the trademark office" is that the
current registrations would be void and subject to cancellation by the
trademark office. Ironically, ICANN could then reapply to register the
marks now without "fraud on the trademark office" so long as it established
that the IETF had abandoned the mark.  (Alternatively, if ICANN established
that the IETF was never the rightful owner of the marks, the current
registrations would not be void.)  There's no reason to subject the IANA
trademarks to these risks -- and frankly, there's no basis to do so either.

Hope that helps.

Greg


On Mon, Aug 10, 2015 at 11:51 PM, Andrew Sullivan <ajs at anvilwalrusden.com>
wrote:

> Hi Greg,
>
> In case it isn't clear below, I really don't know the answer to what
> I'm asking and I'm not trying to advance an argument by pretending to
> ask a question.  I'm not a lawyer, as I've noted, but I've heard an
> interesting argument (hinted at by Milton more than once) and I'd like
> to understand your view of it.
>
> On Mon, Aug 10, 2015 at 07:45:52PM -0400, Greg Shatan wrote:
>
> > assets, but transferring ownership of the IANA trademarks/domain names
> > would be a transformational change -- it would no longer be internal to
> the
> > IETF.  In essence, *if the IETF Trust becomes the owner of the IANA
> > trademarks, the IETF Trust essentially becomes IANA*.
>
> […]
>
> > As such, the source and origin of the services offered by IANA will be
> the
> > IETF Trust.
>
> At the foundation of an IANA registry[1] is an RFC that either was
> subject to IETF consensus, or for which the IETF now has change
> control, or for which the IAB (now a committee of the IETF) is the
> source of authority.  This includes the very idea of the DNS root zone
> and the very idea of the root of an IP allocation tree.  Some of the
> RFCs in question predate the IETF, in some cases by many years.  But
> I've never seen an argument that they're not now subject to IETF
> change control.  This is different to the individual entries in any
> given registry.
>
> If that is true, then is it or is it not the case that the IETF is the
> "source and origin of the services" offered by IANA, and IANA is
> merely executing the function created by the IETF in the first place?
> If so, does that mean that the IETF Trust turns out to be an
> appropriate place for these marks and the associated iana.org domain
> name?  If not, why not?
>
> To be clear, I don't think the argument I sketch above depends on the
> idea that the IETF maintains policy authority over all these areas.
> It clearly does not, and I'm confident in believing that it does not
> want such policy authority.  I'm rather asking about the "source and
> origin of the services" claim, which I understand to be critical to
> the point you're making.
>
> Thanks and best regards,
>
> A (asking as usual only for myself)
>
> [1] all IANA registries?  I'm unable to come up with a clear
> counter-example at the moment, but I won't swear there are none; the
> IDN practices registry might be a counter-example, but I'm not sure.
> It's in any case an awkward case.  RFC 1591 is another difficult case;
> it's never been updated, and it was in my opinion an IANA statement of
> policy outside IETF control, so the int. registry might be another
> case.
>
> --
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150817/5ea9682d/attachment.html>


More information about the CWG-Stewardship mailing list