[Members] XEP-0001: Remove impossible guarantee from XSF Objectives
ralphm at ik.nu
Tue Jan 14 16:07:02 UTC 2020
On 14-01-2020 13:58, Matthew Wild wrote:
> On Tue, 14 Jan 2020 at 10:48, Ralph Meijer <ralphm at ik.nu> wrote:
>> On 14-01-2020 11:19, Dave Cridland wrote:
>> On Tue, 14 Jan 2020 at 00:13, Travis Burtrum <travis at burtrum.org> wrote:
>>> Basically the XSF being an organization that crosses all jurisdictions,
>>> this simply isn't possible. As far as I know we have no members
>>> qualified to give legal opinions, and thus shouldn't even try. Whether
>>> a given person/business/entity can implement a XEP in their
>>> can only be decided by them and their lawyers.
>> This is a bad idea. It will not benefit us as a community. It will
not benefit us individually.
> I disagree that this proposal cannot be discussed in isolation from
> the incredible drama surrounding it the past week or two. If anything,
> it helps immensely to focus on small tangible changes and whether we
> want to make them or not. At a high level it's clear there is
> significant disagreement, but both sides have argued the merits of
> their perspective relentlessly for quite a while now. I don't see
> either side backing down and saying "You're right, we were wrong" at
> this point.
> With that said, I'll therefore offer my thoughts on just the proposed
> I agree that we can provide no such guarantee - we would need a legal
> team and perform extensive research for every XEP we publish. Even
> then I don't think an absolute guarantee could be provided.
> However I also don't believe that we should publish protocols where we
> know there to be actual IP claims. I work on XMPP because I believe in
> having an open interoperable protocol for internet messaging. I don't
> want to have third-parties controlling who does and does not get to
> implement it.
> I agree with Peter's proposal or similar wording that establishes that
> we will not publish standards with known IP claims. As raised by this
> proposal, I worry that the current wording may indeed misrepresent the
> amount of effort we currently put into researching IP issues when
> publishing XEPs. If anything I'd also like to add a disclaimer if we
> don't have such already. "We tried, but don't blame us if we missed
Thanks Matthew for that point of view. However, upon closer inspection
we actually do guarantee this through the way XEP-0001 and IPR policy
XEP-0001 provides the basis of our standards development process.
Besides the Objectives in section 2, we also require Authors to accept
our IPR policy, and then assign ownership of specifications to the XSF.
Section 3.2 (thanks for the fix , Maxime) says in full:
3.3 Approval of Extensions
No Extension shall be approved by the XSF or its constituent
committees if there are Claims to the Extension itself, or any
Claims that would prevent perpetual, unrestricted, royalty-free use
of the Extension in a compliant Implementation or Deployment by any
interested party. If Claims preventing such use are discovered, the
XSF shall immediately seek to replace the Extension with
unencumbered protocols that may be implemented without condition by
It basically says that we assess protocols for encumbrance, and not
approve extensions failing that test. This is why XEP-0384 was
initially not accepted. I also read this to say that if we later find an
extension to fail this test, we will move to seek replacement. E.g. by
using OLM or MLS. If we adhere to that interaction of our policies, we
would in fact fulfill the objective to guarantee unencumbrance.
I understand concerns about existing deployments. OMEMO has done well in
certain circles, and nobody is happy about having interop issues because
the underlying protocols (which are not actually specified in this XEP)
are not open. This is the risk of any Experimental XEP being deployed in
the wild, but in OMEMO's case, in retrospect, we should have taken more
care with the change back from OLM to libsignal.
I also understand concerns about how long it might take to actually get
to a place where we have something new that is viable. MLS probably
needs some work, and then implementations. I also saw the e-mail by Paul
Schaub for a "OMEMO:2 Spec Sprint".
However valid these concerns, though, I believe it should *not* prevent
us from making a judgement call on the openness of OMEMO as it is
currently specified and deployed, just because it is inconvenient. As I
mentioned before, I'd be perfectly happy to write a blog post on this. I
am also not convinced we need to change XEP-0001 at this point.
More information about the Members