[Members] Publishing Non-Open-Standard Specifications
Guus der Kinderen
guus.der.kinderen at gmail.com
Fri Jan 17 09:53:45 UTC 2020
I appreciate the call for compromise as much as I understand the desire to
not upset an existing ecosystem.
An argument is made to "let this one go" because OMEMO is a popular, widely
implemented specification. To its (and everyone involved in its creation)
credit: I think it indeed brought a lot to the XMPP ecosystem. Not only did
it fill a gap in the features that were available up until that time, it
also sparked interest within individuals and communities for XMPP. I truly
think it was a feat to pull that off. A lot of hard work went into that,
and I am thankful for everyone that played a part in that.
The "OMEMO has happened, let's accept and move on" strategy will, however,
have a number of consequences that I find somewhere between "very
undesirable" and "unacceptable":
- Its popularity is exactly why it is important to enforce our objective
of offering a protocol without encumbrance. Because the functionality that
it provides is so desirable to have, we should take extra care to not add
encumbrance, as that would make the desirable feature unavailable to
certain persons or entities. This, to those people, would be very negative
characteristics of XMPP.
- By allowing an encumbering protocol to evolve, we take away from the
effort to replace it with an alternative that is not encumbering: those
that are not encumbered by the protocol are less motivated to work on an
alternative. Their need for a replacement is, after all, not as great and
it might even be counter-productive to them. In that light, a truly applaud
those among us that have invested in the original, and are now already
investing in a replacement of OMEMO.
- It sets a precedent, which could be abused in the future, further
diluting the XSF principles and objectives.
We find ourselves in a tough spot. At times like these, I prefer to look at
our own defined principles, objectives and rules to find an outcome, rather
than trying to redefine these to somehow try and make things fit. For the
issue at hand, our guidelines are clear to me (I know that this is
contested, and I'm happy to clear that up before moving forward):
1. The XSF safeguards against producing protocols that encumber
(XEP-0001, objective #4)
2. If (...) are discovered, the XSF shall immediately seek to replace
the Extension with unencumbered protocols that may be implemented without
condition by any entity. (XSF IPR policy, section 3.2)
With these in hand, the XSF should:
1. Verify that OMEMO, in it's current form, entails encumbrance. We
should talk with OWS, and verify that their intended usage of the parts
that OMEMO uses from their IP is limited to GPL (which I believe to be the
only 'encumbrance' that is under discussion).
2. If OMEMO is found to be encumbering, we should Reject it, stating why.
3. We should seek to replace OMEMO - an effort that, judging from
earlier messages on XSF discussion venues, is already under way.
Nothing of this means that OMEMO implementations cannot continue to exist.
I strongly feel that if the XSF continues to let it exist under its banner,
it is giving up on important parts of its objectives on interoperability
and openness - things that community members have worked hard at defending
(ironically, some of which in direct response to perspectives offered by
the author of the implementation that's now giving us grief in OMEMO).
I think that in the end, this all boils down to a choice between fostering
a highly desirable set of existing functionality, and our principles. I
understand and appreciate the desire to not do harm the existing status quo
by acting as above "against" OMEMO. Compromising (or worse, not doing
anything) will do more harm to XMPP in the long run.
On Thu, 16 Jan 2020 at 20:35, Dave Cridland <dave at cridland.net> wrote:
> On Thu, 16 Jan 2020 at 18:46, Daniel Gultsch <daniel at gultsch.de> wrote:
>> Am Do., 16. Jan. 2020 um 18:32 Uhr schrieb Matthew Wild <mwild1 at gmail.com
>> > On Thu, 16 Jan 2020, 18:18 Jonas Schäfer, <jonas at wielicki.name> wrote:
>> >> Actually, I think adoption by someone except the XSF would be great,
>> but I
>> >> fear that this is not going to happen. Instead, we will see tribal
>> >> like with AESGCM and the various MUC hacks which are barely
>> documented. This
>> >> makes it hard for newcomers to implement a modern XMPP client.
>> >> I, however, see your points about being an Open Standards organization
>> >> having principles. Maybe we simply need to find a different venue for
>> some of
>> >> the extensions needed for XMPP-as-a-modern-IM-system. That feels like
>> a lot of
>> >> overhead for AESGCM and OMEMO though.
>> > For what it's worth I'd accept PRs to modernxmpp.org, I already
>> documented smaller stuff that way.
>> > I'm fine with that outcome if the XSF decides it has other objectives
>> above serving to document XMPP on the behalf of developers.
>> A different venue is what this might ultimately boil down to because
>> the underlying conflict here is that the open source community, which
>> is super constraint on resources, sometimes has to focus on producing
>> working code rather than 'open standards'. It's equally unfair of the
>> XSF to try to force the open source community to produce open
>> standards than it is for the open source community to essentially
>> bully the XSF to accept something that clearly goes against the XSFs
>> stated goals.
> For what it's worth, there are plenty of Open Source developers who
> haven't bullied the XSF or tried to reinterpret its documents and practice
> to claim it allows them to do whatever they want. I have done plenty of
> Open Source over the years, so I'd be one of them, but so are you, and
> Matthew, and plenty of others who have focused more exclusively on Open
> Source then I. I have zero interest in polarizing or dividing the community
> along the lines of preferred software licensing.
> I think there are important advantages in maintaining fully-specified,
> unencumbered specifications. Yes, these are harder to write, and please
> don't for a moment think that FLOSS developers are the only ones with
> constrained resources - very few companies are interested in working on
> Open Standards, in no small part because of the time it will take. But by
> pooling the talent we have across a number of different companies, markets,
> and more, we can get useful things done together. Sacrificing any
> significant portion of that pool does not help anyone.
> I appreciate that many people don't see the immense benefits that this
> Open Standard stance has. I'll happily show people what Pando (my employer)
> has been doing with XMPP over the Summit in person, but it's made many
> patients' and clinicians' lives very much better.
> I know that people have concerns that the technology we write gets used in
> the military too - but if it helps, a major use is in medical response
> there, as in this video: https://vimeo.com/7392430 ("JChat" runs over
> XMPP, with no proprietary extensions at all - multiple XEPs have been
> published in support of this).
> There's lots of other use too, and it's very hard to get companies
> involved in Open Standards work as it is; I don't think changing the
> organisation to be not simply pro-FLOSS, but anti anything else, would
> help. Nor, of course, do I want to undermine the pro-FLOSS nature of the
> XSF - we remain the only SDO to mandate Open Source implementation, and we
> should continue that.
> For what it's worth, I'm somewhat bemused by the "OMEMO is bad" argument
> that floats about occasionally - often put into my mouth along with my
> nefarious aims. If OMEMO were so terrible I was interested in killing it on
> technical merit, then it'd be dead on its own - the reason it takes action
> to resolve the mess it has put us in as an Open Standards Organisation is
> because it is fundamentally solving a problem we have no other deployed
> solution for.
> Documenting XMPP is what we do. However, OMEMO is in conflict with how we
> do it. And this is the mess we find ourselves in.
> If our best solution to this mess is to publish things which are not open
> standards, that's not ideal.
> My proposal is that we do so carefully, and ensure that anyone coming to
> our documents clearly understand that there are licensing (or - shudder -
> patent) issues existing in a specification which is otherwise aiming toward
> the same high quality as everything else we do. A distinct XEP Type seems
> to represent the right level of compromise here, and being a compromise, I
> mean "least worst".
> I would hope that this is not treated as an invitation to deliberately
> burden developers with the GPL or other encumbrances, but is taken in the
> spirit it's offered - as a rare solution to unusual cases.
> The question of whether we need to lower the bar to Experimental or (as
> Kev suggests) allow and encourage development in Inbox is another question,
> and I'd rather answer it separately.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members