[Members] Patents and Copyright in XEPs

Kurt Zeilenga kurt.zeilenga at isode.com
Thu Jan 16 15:29:48 UTC 2014


and one note more specifically about patents...

good luck getting any large firm to assign needed patents to the XSF.

However, getting most any contributor to grant license to use needed patents is far less of a problem.

What's need is licensing of copyright and patents not assignment of copyright and patents.

-- Kurt

On Jan 16, 2014, at 7:22 AM, Kurt Zeilenga <Kurt.Zeilenga at Isode.COM> wrote:

> 
> On Jan 14, 2014, at 6:21 AM, Winfried Tilanus <winfried at tilanus.com> wrote:
> 
>> On 12/18/2013 06:36 PM, Dave Cridland wrote:
>> 
>> Hi,
>> 
>> 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
>> license.
> 
> One issue with copyright assignment is that in certain jurisdictions, like the US, copyrights assignments between non-related entities (such as XSF and the submitter) cannot be made without a writing (e.g., contract) to that affect.
> 
> In generally easier for a submitter to grant a license than to assign copyright.  For instance, a developer working for a commercial firm may have permission to grant licenses to their spec contributions but not to provide the writing necessary to assign copyright of owned by that firm.
> 
> How many of you really have permission from your employers to enter into legal agreements on behalf of your employer? 
> 
> 
>> 
>> Assigning the copyright to the XSF when submitting a XEP (like it is
>> now) is legally fine.
> 
> Well, its fine in the sense that we've had no issue with it.  Wether it's fine if some issue were to arise, well, is another matter.
> 
>> By submitting a XEP, the submitter transfers the
>> right to re-license or dual-license the work to the XSF.
> 
> Assigning copyright is not the same as granting a license that allows re-licesnsing, or to use a more common term, sublicensing.
> 
> A grant of a license to use and sub-license would be sufficient for XSF standard publication purposes.  Assignment of copyright is really not needed.
> 
>> 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
> 
> Why not?
> 
> For instance, say submitter wants to submit materials he submitted to the XSF to the IETF.  When he does this, he needs to grant the IETF certain licenses.  If he submitter holds the coppright, he can do this.  If he doesn't, he has to get XSF permission to submit the materials to the IETF and have the XSF grant the IETF the necessary licenses for publication on the desired track.
> 
> If we were to follow more (*) or less the IETF model here, we could do what we needed to do without creating hassles for contributors who might well want to publish the materials elsewhere, such as at the IETF or at conferences or in journals.
> 
> 
>> 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.
> 
> Well, the only reason I see to change to explicit license grant instead of a copyright assignment is that our copyright assessment practice, IMO, is that what we're effectively doing is license grant not copyright assignment in that we have no writings... and hence we're rely on implicit license grants.
> 
>> 
>>> 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."
> 
> Here I'd follow IETF rules for patent disclosures and consideration of those disclosures as part of the standards process.
> 
> They have working code, we should use it!  We're unlikely to develop independently a better working code here.
> 
>> 
>> 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
>> patents.
>> 
>> 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!
>> 
>> Winfried
> 



More information about the Members mailing list