[Members] Patents and Copyright in XEPs

Winfried Tilanus winfried at tilanus.com
Tue Jan 14 14:21:14 UTC 2014

On 12/18/2013 06:36 PM, Dave Cridland wrote:


I took some time to answer to this one, sorry for that.

> In the Board meeting just now, Kevin Smith raised the important issue of
> how we operate in terms of copyright in XEPs.
> In return, I raised the issue of how we don't, really, deal with patent
> related issues in XEPs.
> Currently, submissions to a XEP, including the initial protoXEP, operate
> on the basis of a Copyright Assignment, so the owner of the copyright in
> XEPs is the XSF, and not the original author.
> This contrasts heavily with the IETF, where the original contributor
> retains copyright, and merely licenses. This in turn causes us
> frustrating issues with copyright conflicts, which we've seen recently
> on a couple of RFC examples imported into XEPs.
> We should probably make the situation clearer, but it might be nice to
> also see if we can handle particular cases of third-party copyright -
> should we wish. It's also not clear to me if an XSF contributor retains
> the copyright of a rejected protoXEP.

The only difference I see between having a license and holding the
copyright is the right to issue a license for the work or change the

Assigning the copyright to the XSF when submitting a XEP (like it is
now) is legally fine. By submitting a XEP, the submitter transfers the
right to re-license or dual-license the work to the XSF. Both are great
for accepted XEPs that are published by the XSF under the XSF license:
we don't want the submitter to be able to re-license the work and
dual-licensing is more or less useless because the XSF license
(http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/) allows almost everything.

But when looking at the case where a ProtoXEP is submitted but not
accepted and not (further) published by the XSF, there may be some
issues indeed. First of all, when the submission is rejected, the
submitter loses, as far as I can see, still the right to re-license or
dual-license the work. That may deter potential submitters: it becomes
impossible to still publish the rejected ProtoXEP under a more
restrictive license. Secondly the XSF may experience it as a burden or
even immoral to be the copyright holder of countless rejected ProtoXEPs.

But as far as I can see, neither of these are really a problem in
practice. So I don't see any reason here to change this.

> Next... We have very little policy on patents and related IPR, excepting
> that "We don't like Patents" as a general, if unspoken, organizational
> stance. Unfortunately, this isn't preventing someone submitting a XEP,
> following our assignment requirement perfectly, and never mentioning a
> key Patent required to implement. Until, you know, "later". The "later"
> has never occurred - but I can't honestly tell if there are submarine
> patents in XEPs or not.

Well, http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/ states (not
explicitly mentioning patents): "By submitting an XMPP Extension for
consideration by the XSF, the author of the Extension shall assign any
ownership rights or other Claims asserted over the Extension to the XSF."

As far as I can see, that would also include patents. So if you own a
submarine patent and submit a XEP that contains something that falls
under that patent, then you make the XSF owner of that patent. So IMHO
you should say: "I honestly can't tell if I made the XSF owner of any
submarine patents". ;-)

If my interpretation is correct (and only a bunch of judges can tell),
then I think the XSF 'eats' too much of the IPR's of its submitters, a
license is enough here. If my interpretation is incorrect, then I think
the XSF should be better protected against people submitting submarine

So this has to be fixed.

> The generally accepted solution for this is to have a patent disclosure
> agreement, similar to the IETF's BCP 79, and a corresponding equivalent
> to the IETF's "Note Well" - a précis of, and pointer to, the full
> contributor requirements in BCP 79, read at every meeting, mailing list
> reminder, and so on. Note that despite the IETF being *fairly*
> anti-patent, their goal has always been to inform as a first step, and
> design around if practical. We cannot coerce non-contributors to RF
> license, after all.

Before choosing a solution, we should make up our mind about how to
handle patents. Often we regard patents as evil, as irritating and as a
source of abuse. But lets assume the XSF is owner or licensee of some
patents on real time techniques, then those patents may also be used to
gain a competitive advantage for XMPP and/or to strengthen the XSF. So
do we really want to 'disable' patents (by license or workaround) or do
we want use the system to our advantage? In stead of demanding a royalty
free license when submitting a XEP with a patent, we may for example
demand a license that grants the XSF the right to re-license the patent
on the XSF's terms and limit the license to use with XMPP (and charge
all other use).

Anyway, though a bit bureaucratic, a system like BCP 79 is IMHO the only
realistic way of dealing with patents in an open standards process.
Regardless of our policy on patents.

> So, with that, I'll open the floor for discussion:
> 1) Should we restate our existing copyright assignment procedure somewhere?

I see no direct need for that, though some clarification may be good.

> 2) Should we attempt to solve the "RFC Examples" issue somehow?

As far as I can see, the problem is here that the work was originally
published under the IETF license and that we redistribute it under the
XSF license. These two conflict: the IETF license
(http://trustee.ietf.org/license-info/IETF-TLP-4.htm) does not allow
modification where the XSF license
(http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/) does. So taking over an
example from a RFC and publish it under the XSF license is a violation
of the IETF license.

So yes, this has to be fixed.

More in general the issue is: "including material in a XEP that has a
license that conflicts with the license of the XEP". I see three ways to
resolve this:

1) Don't include such material.
That is what the current XSF IPR policy mandates and what should have
been done already for all current XEPs.

2) Change the license of the included material.
In this case the XSF does not become the copyright holder of the
material (and probably has to include a copyright notice) but the
copyright holder grants a free license that is compliant with the XSF
license. Of course the copyright holder has to be willing to
dual-license their material.

3) Change the license of the XEP.
If we include material in a XEP that has, for example, the IETF license,
we have to (at least) mark that section as having an other copyright
owner and an other license. This effectively results in a XEP with a
more restrictive license then the XSF license.

I would prefer the first option.
The second option is acceptable, but has some drawbacks: a change in
policies and procedures is needed, because we allow XEPs with other
copyright holders then the XSF. These copyright holders should also
grant the XSF the right to re-license the work, in case the XSF wants to
change its license.
I would like to avoid the third option, because I feel a risk of
'infecting' much of the XSF material with unclear licenses.

Note that the issue of the conflicting licenses also applies to quoting
the XMPP core RFCs in a XEP. The current XMPP RFCs state various
copyright holders: Peter at Cisco+IETF Trust, Peter at XSF+IETF Trust, The
Internet Society, and the IETF Trust. I think it would be good to
transfer the copyrights of all of these to only the XSF. If not possible
I think it would be second best when the copyright holders issue a dual
license for all of these that is compliant with the XSF license.

> 3) Should we attempt to create an XSF equivalent of BCP 79?

Yes, though we should first make up our mind about how the XSF wants to
deal with patents in general.

> 4) Should we setup a patent pool, so everyone who implements XMPP has to
> pay me millions, and I can become rich?

The XSF already created a patent pool (though some people may think they
still own the patents) and is ready to troll. But the only people
getting rich from it are the patent attorneys, not you Dave.

> Thanks for reading this far,

all the same!


More information about the Members mailing list