XSF Discussion - 2020-01-10

larma, There are no ways to extract the info strings used in HKDF from the output, or at least not wihtout having broken HMAC, which is generally considered by cryptographers to be "A bit tricky".

larma, And you publishing the constants under a difference license wouldn't mean that you exclusively took liability either.

moparisthebest, As for whether or not the XSF should take any position on IPR, the XSF does, so in order to change that you'd need to (at least) convince Board to do so. You could, for example, move to the IETF position that IPR constraints are detailed but left the the implementer to decide upon their validity. For patents etc, that's a fine position to take, but for copyright issues, less so (since they're much more rigidly defined).

I suppose one way to reverse engineer the info strings would be to exhaustively search for them, on the assumption they would be ascii strings. It'd take some time, though, and I'm uncertain as to whether anyone would believe you unless you documented it all thoroughly. I don't know enough about the protocol itself to know if yu could get the test vectors out, either.

damn you "WhisperRatchet". But then again, I am fine with a XEP that requires GPLed compatible implementations.

I don't think that the question if we can device a way to legally find those strings is all that important, to be honest. I feel that it is more important that the XSF avoids a legal battle, if it reasonably can. If OWS does not want others to implement their mechanism, any form of reverse engineering - done legally or not - is likely going to be challenged. That makes that approach moot.

So leaving the bad quality of the OMEMO XEP beside, the real question is if you think that encumbers the XEP

which potentially leads to the question if the GPL increases or decreases your freedom

"If OWS does not want others to implement their mechanism" OWS wants other to implement their mechanism, that's why they made the implementation available under the GPL

flow, No; I think everyone agrees the GPL forces developers to do certain things (ie, license under the GPL), so the question is whether this is a problem for the XSF.

That's what confusing me flow - they GPL'ed something, but I've heard (through third parties) that they're actively pursuing legal fights over it.

dwd, I am not sure which question the "No" is supposed to answer, but besides that, yes, the question is if we are fine with a XEP that requires GPL compatible implementations

Because GPL is a useful way to generate a licensing revenue stream for people who don't want to (or cannot) use it.

Guus, they can only pursuing legal fights over it if they assume a violation of the GPL

flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. The question is whether the XSF accepts this encumberence.

e.g. if matrix would have build OLM on the wire protocol of libsignal, then all matrix implementations would be required to be GPL compatible

dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. I tend to disagree

flow, But they changed the constants. The wire format can - probably - be reverse engineered.

flow, How is the GPL not an encumberence to developers? It requires them to license a particular way.

Guus, everybody knows that Signal is not open-source because Moxie believes in open-source, it's open-source because that turned out to be the better business model

larma, A better business model for a non-profit.

"everbody knows" is not an argument that we can use in any form of decision making.

What flow wrote, if accurate, would be a very nice stick against what we can measure things.

dwd, (re info string) I already asked for some help from legal experts on that matter, so we probably should just wait for their input

This bit, I mean: > the question is if we are fine with a XEP that requires GPL compatible implementations ✏

dwd, it wasn't a non profit back then. There were times when Moxie tried to sell TextSecure as a proprietary messaging app and nobody wanted to buy it

Guus, Well, XEP-0001's Objectives, and particularly Objective 4, would seem to state that we are not.

Also there was something with Twitter in Signals history (them buying the company and then releasing as open source?)

dwd, sure gpl requires some things, but you are free to use it, and especially free of charge. Not sure where the encumbrance comes from. If your buisness model requires you to implement non-gpl compatible software, then the XEP is probably simply not for you and you should probably write your own

dwd I'm open to some back and forth on that, but on broad strokes, that'd settle the entire discussion for me (if all these assumptions hold up).

flow, "requires some things" is surely what encumberence means.

dwd, well, the gpl is only a burden people who can or are not willing to comply to it

flow, How does that differ from, say, requiring a paid license?

a, potentially large, part if the xmpp community is probably fine with it

flow, that goes for _any_ restriction. 😃

Guus, well there are restrictions that apply to everyone

The XSF is explicitly not in the business of making things unavailable to non-FLOSS parties.

requiring GPL would hurt that.

Also, it'd hurt us - as major players can't use (part of) XMPP.

Guus, it's not like we require all e2ee schemes to be gpl only

You should be able to implement based on specification alone ✏

+ dependency specs

The precedent is dangerous.

I strongly feel that we should not go down that path.

I've already had customers worry about licensing as-is.

Note that the people in here are not a good cross section of our users.

people in this MUC tend to lean a lot more towards open source principles than many of our (commercial) users.

which makes me think that this quote is not quite accurate: > a, potentially large, part if the xmpp community is probably fine with it

I guess OMEMO is so controversial because the FOSS part of the xmpp community is fine with it, which is backed by the various implementations and the high traction it got, while some from for-profit part struggles with the GPL. But then OMEMO is probalby not for them and they are free (and encouraged) to come up with their own e2ee XEP.

dwd, what Zash said

flow, What?

I agree to that - but (I'm parroting dwd here) the XSF apparently does not want to publish XEPs that have these limitations (and I'd see value in that).

The XSF _not_ publishing the OMEMO XEP does not limit anyone from implementing it, right?

flow, I also don't understand, "[10:06:40] ‎flow‎: Guus, well there are restrictions that apply to everyone" - surely the restrictions of the GPL apply to everyone, it's just that for some these are acceptable restrictions?

I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties. ✏

flow, How does this differ from, for example, the RTMP licensing requirements that we rejected?

Guus, see that is probably where we differ

flow yeah, I think so. A matter of different opinion.

Guus, An interesting point is that we require "at least one" implementation to be GPL or OSI-approved when moving to Final. What we don't require is that they both cannot be GPL (for example).

dwd, sorry, lunch, not ignoring you, but hungy

dwd I must admit I'm not up to speed with the details. From what I read here, I feel that the intention of these objectives is to make XEPs as accessible as possible.

accessible/usable/permissible, license wise. I'm struggling to find the right words.

Guus, Yes; my point is that our process assumes that if something can be implemented as FLOSS it's good. I don't think we considered a case where a protocol would be GPL-only.

dwd right. That may warrant an update of our objectives then.

as I do agree with you that GPL is restrictive.

Guus, The objectives are clear enough, IMO. It's whether the enforcement at the Draft->Final stage needs improvement.

Just in case it's not obvious, I'd be as thoroughly against any XEP that couldn't be implemented fully as GPL (and, moreover, have been in the past n the record).

shoot. I should've done stuff by now.

Guus ralphm MattJ pep. https://mensuel.framapad.org/p/9ece-xsf-board-weekly-meeting-2020-01-09 please review/edit the notes before we/I send them

What I'm happy with is that, for me, flow boiled down a discussion that I could not really get a grip on to an essential question. Him and me appear to be on opposite sides of the argument, but if it is acceptable to boil down the discussion to that question, we can make progress.

nyco looks good. I've added some of the standard headings to what you already had.

ok, thx

shoot. I should've finished stuff by now.

> flow> dwd> flow, I mean, GPL is definitely an "encumberence" by any reasonable definition. > I tend to disagreee I also disagree

pep., Again, on what basis? Because the actual purpose of the GPL is to enforce that derivative works are under the GPL. SO *if* the GPL applies here, then that surely imposes requirements on developers?

(And again, I say, I've argued against the XSF accepting any XEP which cannot be implemented under the GPL, too).

(minutes sent, thx)

nyco, Thanks, I hope I captured the conclusions accurately. Summarizing the debate in an unbiased way would be tricky for me, I think.

agree, unless you are an AD&D "true neutral"

"Guus> I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties." < I think you got the GPL wrong. Nothing prevents a commercial party from using it

pep., I agree with that, but it still requires any software to be itself GPL, which is a restriction, or encumberence.

nyco, thanks for the minutes

pep., I mean, you're welcome to argue that the GPL is an *acceptable* encumberence - I would disagree, mind. But I don't think you can logically claim it's not an encumberence at all without redefining what an encumberence *is*.

I can agree with that. I don't especially see that as an encumberence, but people who for reasons don't want to use GPL (or say any other copyleft licenses) could see that as an encumberence. Now the reasons as to why not just use copyleft things (and thus be copyleft themselves) is always funny. I would argue it's never a "we can't", it's a "we don't want to".

Sure, but equally, you may "not want to" use Adobe's RTMP library, or you may "not want to" pay patent license fees. I don't think these are any different.

I don't know about these discussions (RTMP), I'll have a look

pep., One of three cases where a Council I've been on has been presented with a ProtoXEP that relies on encrumbered technology, and I've rejected it.

But yes. We clearly have different goals. I am generally in favor of empowering the end user of my projects, that might not be the intent of everyone

pep., In both the other two, there was a material change which meant I could change my vote. However, there have been other cases where we've pushed back on rpoposals before they got to that point - they're just very poorly documented of course.

Mind you, I wouldn't make all this fuss if OMEMO never had been accepted

Because it might not have been such a big thing

In this particular case I'm mostly annoyed that we're not providing a replacement

Wether I want to change Objective 4 of 001 is not something I am trying to answer here (even if I'd certainly agree to)

pep., That implies that I am not interested in empowering my users, thanks for that. I am, but my users are not programmers, so the availability of source code is immaterial. I am also interested in empowering developers, which is why I'm keen not to encumber our protocols.

I said "end-users"

(but yes those on the way as well)

It's really astonishing how much vitriol can be released by a bunch of short ASCII strings

:)

pep., The spec generated just as much argument when it was in ProtoXEP stage, actually. Eventually this was diffused by changing it to Olm. I genuinely thought that OWS had released full specifications - they released a lot of cryptographic specs some time back, I thought these had included wire formats and everything else needed.

If omemo relies on GPL libs how can monal and Chatsecure support it? I thought the Apple store and GPL are incompatible.

I asked myself the same question. Signal probably has exceptions in the license for iOS, unsure about the others

The license surely doesn't apply to them. They can release the iOS app under a non-GPL license.

Oh, wait, Monal and Chatsecure. Yeah, they're probably technically in breach.

But not in a way that OWS cares about most likely.

> The license surely doesn't apply to them. They can release the iOS app under a non-GPL license. I'm no lawyer but is this possible when linking gpled libs?

Ah, you meant signal.

You can't submit anything GPL to the App store, FWIW. Even if there's an exception for iOS made for the virality clause, Apple's terms don't allow it.

(At least, this was true last time I looked at the terms, I suppose they might have changed)

https://github.com/signalapp/libsignal-protocol-c#license

Apple might care. OWS probaly not. And copyright licensing is not like patents and trademarks - you don't have to enforce to maintain it.

> Open Whisper Systems also grants you the additional permission to convey through the Apple App Store non-source executable versions of the Program as incorporated into each applicable covered work as Executable Versions only under the Mozilla Public License version 2.0

AH, there we go, good spot.

On Signal's GPL license and Apple, Moxie released this: https://signal.org/blog/license-update/

dwd, yes the license applies to them (independently of what Kev just said about the Apple store). If they wanted to relicense it they'd need at least a CLA that I don't see

Or forbid any contribution that's not from OWS

> Applications that comply with the GPL are now explicitly authorized to be distributed through the Apple App Store and remain in compliance with the license.

So if anybody wants to: grab a version of ChatSecure from the AppStore and then extract the info strings from there, they are under MPL

larma, they'd be under whatever license Apple says it is rather? If you grab the binary from the AppStore

pep., no the license remains what the copyright holder grants you

it is probably against Apples ToS to do so

but they can only sue you for actual damages caused by being non-compliant with ToS and I don't see damages from extracting strings from a library

larma, I don't see how that removes the copyright.

it doesn't

but it's under MPL then

which is more permissive than GPL

And should allow non-free implementations IIRC

yep, without re-reading the MPL again, that is probably correct. If so, that's a nice loophole ;)

flow, there are probably a bunch of other loopholes, that's why I have been asking for some legal help on that

for example you could write a program that is under the GPL and outputs those constants. Output of GPL programs that are not the program itself are not under the GPL

larma, i'm sure interested in the result/outcome of that legal help :)

hmm, what if the program outputs itself?

well, if the program outputs itself it remains under the GPL

All this doesn't change the fact that it's a bad idea to publish a XEP on the premise of a loophole.

ahh, there was a "that are not the program itself"

"This week in the XSF: How to use GPL loopholes"

We should do just like "This week in Matrix"

I wouldn't call it a loophole

If that wasn't part of the GPL, then you would be required to deliver the source code of every signal encrypted message (read unencrypted message)

because you are outputting the hash of that string (kind of)

If it directly opposes the intended application by OWS, it's undesired for the XSF to act on, in my opinion.

We can still ask OWS on their opinion on that matter

I'm very much in favor of that. ✏

Me too

But any talk about exploiting loopholes would be very unhelpful.

phonecall, afk

We'd like to make use of OWS's specification. They've chosen to release that under conditions that we might not agree with, but that does not give us the right to try and find loopholes.

I'd be pissed if someone uses my stuff in a way that I don't want it to be used.

Guus, aren't that what lawyers are for? :x

Finding loopholes.

At the very least not morally. ✏

isn't that*

(see my message correction: I ment 'morally', not 'legally')

:)

Guus, I don't think so. If we can argue that legally we are allowed to use those strings and we just ask for permission because we are friendly, that puts us in a completely different position

Guus, the world wouldn't be as it is if people cared about morale

or rather, if more* people cared

Currently it's like, we have a competing chat system and are begging for permission to use their encryption, that's not the best position to be in

I care about the morality of this.

We put ourselves in that position - that's not on OWS.

Guus, sure so it's also on us to ensure we are in a better position

If we are to use their stuff, it needs to be clear that it is permissible to do so - morally and legally.

We should talk to them. If they say "no", then it's a no.

A moral permission alone does not help, but I am happy to agree that legal permission alone is also not enough

I very much do not want to be in the business of abusing others by means of legal loopholes. ✏

Also, by discussing these loopholes, we're actively hurting our chances of getting permission.

In their shoes, I'd take offense.

although I'd like to point out that for the matter of the specification, actually only the legal side matters

It would be up to implementations then to care about the moral side

Oh, whatever we do must be legally valid, I don't argue that.

by using libsignal you would be clearly on the moral side anyway

so the only question that remains (if it is legally fine to extract those strings) is if non-GPL implementations of the spec are moral

My estimate is that a) OWS explicitly wants all of the implementations to be GPL compatible and b) the XSF does not want to publish XEPs that are implementable only with this restriction. If both are true, I feel that the XSF should not futher pursue the OMEMO XEP in this state.

(note that this does not limit anyone from implementing OMEMO under GPL)

Is it morally better to trick out OWS by not using those strings (like olm)?

I don't see why it would be morally bad to implemement the spec under a different license. The spec is CC and there is no mention of copyleft.

I'm assuming OWS has no issue with Olm (as OWS released the specs based on which is was build). That would be fine.

larma, I am not sure if OLM did trick out OWS. As far as I can tell they simple used the open standard and specified their own constants

> I don't see why it would be morally bad to implemement the spec under a different license. OWS explicitly states: you need to do this under GPL.

Syndace, the discussion is not about the spec but about the libsignal implementation(s)

which are based on the spec but use constants that are not part of the spec

> My estimate is that a) OWS explicitly wants all of the implementations to be GPL compatible and flow, ^

Syndace, what Guus really ment to say is that "OWS explicitly wants all of the implementations compatible with the libsignal wire protocol to be GPL compatible"

the spec is open standard an implemenations can be under any license as far as I can tell

Maybe is should have typed "applications of signal" instead of "implementations". ✏

If OWS wants all implementations of what effectively is the signal protocol (minus constants) to be under GPL, it does not give us any moral advantage to use different strings

Okay I get it

> If OWS wants all implementations of what effectively is the signal protocol (minus constants) to be under GPL, it does not give us any moral advantage to use different strings

true, but I don't think that's what OWS wants.

They've not challenged Olm, did they?

They don't want signal compatible implementations of the signal protocol in third parties?

> larma> Is it morally better to trick out OWS by not using those strings (like olm)? This. I don't think it changes anything

why would they care about those strings, if it wasn't for the protocol?

We'll have to talk to them to be sure.

what Guus said

the strings might be a way to control interop.

Guus, our goal is not to do interop with them

there is no interop between signal and anything because they don't federate

> They don't want signal compatible implementations of the signal protocol in third parties? The specification does not specify the "Singal Protocl", it specifies DoubleRatchet and the X3DH key exchange. The "Signal Protocol" just utilizes these two specifications to build their own protocol. The Signal Protocol is not specified at all, you have to read the source code to see how it's done

maybe it's important to them to only allow interop with GPL stuff (or things they have a side deal with). It's all speculation, and doesn't really matter though.

But it is my interpretation that they want libsignal wire protocol compatible implementations under the GPL, as all their implementations are GPLed. But made the doubleratched/x3dh and open specification so that everyone can implement it and put it under a license they want

flow: +1, that's how I understand it

flow meaning that they would be fine with 'Olm', right?

Guus, I assume so, yes

(But I haven't look at Olm in a while)

That's also how I think things stand.

but we'll have to check with them.

Unfortunately, and that was because of a bad timeing, e.g. there was no open standard doubleratched/x3dh at that time, OMEMO depends on the GPLed libsignal wire protocol and not the open standard. While nowadays there is no need for OMEMO to depend on the libsignal wire protocol

Exactly. The big issue is that we can't change these constants now without a breaking change to OMEMO, which would probably confuse the XMPP ecosystem for quite a while.

I see that people want to keep compability with the libsignal wire protocol in OMEMO for backwards compatibility reasons, but I think OMEMO, in it's current state, could deserve so much (breaking) improvement, that switching the wire protocol would be sensible

The second problem is, that there are other issues with OMEMO that might require a breaking change in the future and we want to make sure that there is one _one_ breaking change and not multiple ones. That's why it's taking so long for us to prepare the improved version of the OMEMO XEP.

flow, I agree, but would add that if omemo were published outside of the XSF it would be perfectly fine to leave it as-is.

But obviously it is not my call but up to the ecosystem and community of (implementation and specificatin) developers to decide

But yes, a breaking change is a must if we don't want OMEMO to stay as it is forever

I think it makes sense to upgrade the wire format of OMEMO. And there is a "clean" upgrade path for the wire format, which is having everyone be able to receive the new format and then at some point switch to it. BUT this requires the constants to remain the same

Syndace, it is perfectly fine that you want to avoid namespace bumps whenever possible

Syndace, although I really like to see the current state of the protocol specification, I hear so much about it, you are working on

yeah some transparency would be nice :)

Syndace, Is there any reason why you didn't just made an annoucement on standards@ that some are working on OMEMO2? I don't care that the development does not happen within the XSF.

Weird. Someone just pinged my dev workstation's XMPP server from the Seychelles - sent a stream open, waited for the features, and dropped.

Teh anonymous are onto you

larma, I don't think it does need the constants to remain the same if you're doing a flip-over, does it?

We (the SIG-E2EE) plan to do an OMEMO-focussed sprint soon (in the next few months). Our goal is to put together all the things we have collected over the past years into an OMEMO2 kind of XEP.

pep., They'll be massively confused at hitting a healthtech messaging platform that just happened to speak XMPP.

Shodan.io?

Not that it matters, but has the E2EE SIG already offically been formed?

jonas’, This? No, forwardhealth.co

flow, Nobody knows because we can't remember the process. :-)

dwd, I meant as a candidate for an origin of the scan

flow, no, at the very least because council didn’t completely vote yet

flow, it's not deliberate secrecy; it's just that a lot of what makes omemo 2 has been discussed in person during multiple events spanning a period of 2 years or so

we just haven’t had the time to actually write something down

I see

which is what we are trying to do soon(tm) as Syndace pointed out

Daniel, FWIW, I appreciate that it's transparency that takes effort and deliberation; secrecy is the default unless a considerable effort is made.

It's not only the tranparency that takes effort, but also collaborative development of specifications is hard, as there are usually many different opinions and finding consensus, which is usually the goal but not always possible, is not trivial

dwd, if we change the constants, it will at least break all sessions, so you can't have both at the same time (like one client sending the old version and the other sending the new version when both can receive both versions)

larma, I think you have to handle it via something similar to happy eyeballs, but it ought to work. It's unpleasant, I agree.

larma: I don't think the goal of OMEMO2 is to stay backward compatible.

especially if people insist on their approach without at least looking for compromises

Syndace, I think there are different things going under the name of OMEMO2 😉

If you can write such a thing, then at least omemo1 is horribly broken, no?

If we just change the wire format it would be possible

All E2EE is horribly broken, because the endpoints are users :)

Right, if that's the only thing that changed.

larma, changing only the wire format doesn't help anybody.

MattJ, *devices, not users

Syndace, so what issues are there that you'd like to solve?

yes i don’t imagine omemo2 being compatible either. instead we agree on some kind of upgrade path that is somewhat easy for the user

jonas’, in this case I think devices are the lesser evil. Users are those that make e2ee horribly broken :p

jonas’, the devices generally defer trust decisions to the users (or TOFU/BTBV/etc.) which makes life easier

I think Dave's right that it'll end up being happy-eyeballs-ish.

larma: one second, having trouble to find the link on mobile

Here you can find a list of things we want to change or consider for OMEMO2: https://github.com/Syndace/xeps/projects/1

And that list does not include the actual change of the wire format :D

pah, no need to state the obvious ;)

Syndace: those don't really sound like critical breaking changes. Certainly breaking in terms of wire protocol changes, but I don't see anything breaking crypto things

Also honestly it would be better if we stayed compatible with libsignal if possible

Because there are a bunch of libsignal implementations already

Well then we won't ever move away from GPL

"Because popularity" ?

larma, surely you could take those implementations and change the constants

flow, if the implementations directly link against libsignal?

jonas’, hmm?

We could fork libsignal and change the constants

Dynamic linking is a thing

of course the outcome would still be GPLed

flow, if I write a client and link against libsignal, changing the constants is rather meh, because then I need a fork of libsignal

jonas’, potentially yes, but maybe the libsignal library provides an interface to feed those constants into it

my point was merely that you could still use those libsignal implementations even if we change the wire protocol. But yes that potentially means forking of those

but I would also expect new generic doubleratched/x3dh implementations to appear. For example in case of Syndace's library, that probably just means creating a new backend and be done

yes, though that is concerning in its own

lots of crypto-implementations

and I don’t think we have as many cryptographers as we have languages in which xmpp clients exist

yep, but OTOH omemo implementations have already gone through review, that may happens with new libraries too

did they?

and you can't really forbid people from publishing a library

jonas’, https://conversations.im/omemo/audit.pdf

plus a non-gpled doubleratched/x3dh library has potentially a even higher chance from getting audited because of $buisness interest

Even though Copyleft is actually quite aligned with business interests..

> Guus: I'd prefer the XSF to publish only XEPs that are usable by both commercial and non commercial parties.

Great so for example the GPL

Name one large commercial entity that doesn't use Linux for instance

moparisthebest, I don't think that's what Guus actually intended to mean - I assumed it to mean FLOSS vs non-FLOSS.

This "gpl is bad for businesses" thing is pretty recent and I don't like it, I feel like it's brainwashing from the likes of Apple etc

And to be honest I couldn't care less about non-FLOSS, they made their bed, they can lay in it

moparisthebest, Recent? It's ancient - don't you remember the GPL is cancer thing from Ballmer? True to say it *is* bad for *some* business models, but it's essential for others.

They always have the option to go FLOSS

"doc it hurts when I do this" "stop doing it"

I strongly feel that the XSF should not adopt the strategy of telling people that.

We'd loose more potential users than that we'd make people use FLOSS.

moparisthebest, You're saying any use of XMPP should be GPL? Like, say, Fortnite? I can't see that being viable.

What I ment to say was that I feel that the XSF should not publish XEPs that are only suitable for one particular license model.

Guus, I think it's the other way around: we loose potential community members if we forbid "gpl-only-xeps"

I think part of the people currently in this room are here because of omemo

flow, I'm talking about "people/organizations applying XMPP", you're talking about "members of the XSF" I think.

Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better

flow, I think you cannot have a specification that is GPL only. If something is fully specified, then no particular license can exist, and the entire question is moot.

> Sure I'd be fine if all XMPP implementations had to be GPL, actually AGPL would be better I strongly disagree.

That's well put flow , I'm explicitly here because of the open source freedom, nothing else

Guus, no I mean community members in the bordest sense, taht is XSF members and ppl/orgs applying XMPP

I agree with Guus

moparisthebest, And I'll continue to defend your right to choose to release under any license you choose, especially FLOSS licensing.

part of being an open and free standard is the freedom of license model

I was reading the discussion and it seems that the crux of the issue is whether XSF should push/enforces GPL licencing... IMHO it should not - XSF should define sets of interoperable standards and it's up to users/developers whether they want to implement it under GPL or non-FOSS licence, but in the end their product should be interoperable. If there is no mandate to prefere something GPL than both parties are content.

+1

An open standard should be complete. If you need to read some stuff out of a library to implement it, regardless of license of that library, then it's not complete and it's a bug in the specification.

And to be clear I'd also be fine with an XSF xep that said "you must pay my company $x to implement this" I would just ignore it

moparisthebest, What if we put that XEP into a compliance suite?

That part I wouldn't consider an open standard

A gpl standard I would consider open

"a gpl standard" doesn't even make sense!

moparisthebest, You literally cannot have a "GPL specification" though.

dwd: no one has to care about that either

Isn't the argument that omemo is gpl

Or requires gpl, that's what I mean

The problem as I see it is that you apparently need to look at something that isn't a specification in order to implement the specification.

dwd, right, hence I wrote "gpl-only-xep"

Doesn't help that this thing is a GPL library

but otoh I am not sure if we haven't here the case of a specifcation which requires gpl

flow, Indirectly, we do. But this is a combination of two problems.

if I where to write the constants in the xep with a disclaimer that I have extracted them from an gpl implementation…

it's complicated → time for coffee

flow, Can't, since that would violate the copyright.

flow, Our XEPs are explicitly under an MIT license.

fair point, then I do not write them into the xep but into some other document

> it's complicated → time for coffee +1 ☕

☕ !

so the fix is just to get the board to allow our XEPs to be under MIT *or* GPL, author's choice

then the omemo details can be published in the XEP and everyone is happy

we could have a whole new category of GPL'd specs called GEPs :)

I'm very much against this.

People will need to start to worry if they can actually use a XEP.

my point is they already have to

currently? not from a license perspective - other than with OMEMO? ✏

yes, I have no assurance the rest of the XEPs have been thoroughly vetted for license/IPR issues

Guus, of course they would have to.

if my business were to rely on it, I'd need a lawyer or something to do that presumably

As moparisthebest says

The IPR only says "if something happens, it's not us!!"

(or at least that its legal value.)

There's a huge difference in verifying that indeed the implementation that you create base of off a XEP is compliant with the license that you choose to release your work under, and: you can't implement certain XEPs without your work adhering to the license of a very specific third party implementation.

I don't think we're on the same page still

If XMPP would only be observed as doing the latter, it wouldn't even be considered in many businesses.

You'd not even get a foot in the door, so to speak. It'd be dismissed outright.

I'm not saying I agree to that, or that those businesses _need_ to dismiss it - but it's what will happen.

it's not considered in many businesses already, I don't think making it less free (and yes I'm definining that as not GPL, sue me) will change that

moparisthebest, I'm assuming you know that first statement is entirely wrong?

moparisthebest, And therefore the second.

I don't see any problem whatsoever with a XEP explicitly saying "for $reasons implementations of this must be GPL"

If tomorrow $company wants to use XEP-0987 in $legislation that differs from the XSF's, it needs to do the work of verification itself (that they can legally use it). And even if $company were in the same legislation as the XSF, the XSF is not actually putting any effort in legally vetting the XEPs

it's crystal clear, it's an open standard, what else are we after

You're not very 'open' if you're requiring a specific license, in my opinion.

This has nothing to do with 0987 referencing $implementation

dwd, no, we don't even have a lawyer on staff so I know for sure they haven't been legally vetted, putting aside we'd need a lawyer for every jurisdiction around the world

This ^

moparisthebest, You're attempting to require to prove a negative.

I'm off to get the kids. later!

bottom line is this, if $company implements a XEP and that XEP has problems, who is legally responsible? $company or the XSF ?

moparisthebest, There is a world of difference between striving to achieve a level playing field for everyone, and not aiming for that.

I think it's always $company and therefore they can't rely on anything the XSF says

If xeps start requiring licenses and some of them are incompatible, you suddenly can't implement those xeps in one server/client at the same timr

dwd, I don't think we should aim for that in any way no

moparisthebest, OK, but that is an entirely different argument. You're arguing we should not be an open standards organisation.

no I'm arguing that a GPL-requiring standard is an open standard

I always enjoy how everybody uses "open" in so many ways

and if someone chooses not to implement it, that's on them

moparisthebest, Well, you're very much in the rough there. Every other organisation with a definition of what "open standard" means would not agree.

moparisthebest, I don’t see a difference between a standard which requires a proprietary license and a standard which requires GPL. Both hinder implementors.

(and I’m a very pro-GPL person)

that's fine, reasonable people can disagree :)

jonas’, I'd disagree, the first hinders implementors (though I'd also be fine with it, just wouldn't call it a open standard)

moparisthebest, Yes, sure, but if you're going against a well-established definition...

moparisthebest, the second also hinders implementors who are bound to non-GPL for whichever reason.

a standard which requires GPL doesn't hinder implementors, their act of not choosing the GPL is their own hinderence

which might very well be external even

moparisthebest, But the act of not choosing my commercial license is surely their own hinderence too?

moparisthebest, I mean, I could use a license like the old MSFT license that used to be used for MSVS examples, which allowed any use *except* open source.

and I'd simply choose not to use it

I don't know why we'd require anything else of anyone

moparisthebest, But itd still be an open standard by your unique definition?

not an open license not an open standard I guess ?

moparisthebest, That's not what the term means.

I guess there is no point in arguing over semantics, which I probably started so my bad

bottom line, I'm perfectly fine with a XEP that requires implementations to be GPL for whatever reason

I'm also fine with a XEP that requires $proprietary_license, I'd just ignore it

And I (alongside many others) would say that's not an open standard. So what you're saying is that you're fine with the XSF being something other than an open standards organisation.

whatever that ends up being I'm fine with

I'd like to point out that Guus 's fear of "no one will consider the XEP if it's GPL" is unfounded, after all look at all the OMEMO implementations

I don't care about non FOSS anything

> I'd like to point out that Guus 's fear of "no one will consider the XEP if it's GPL" is unfounded, after all look at all the OMEMO implementations That's not what I meant at all

> I don't care about non FOSS anything You don't have to, but the XSF should not exclude XMPP from nonFloss.

I don't mind if it does, since I don't care about any non FLOSS people/things/companies

how does it help any of us if say slack is using XMPP underneath? meh

Relatedly, I'd like to find a way to make these proprietary implementations/usage visible tbh. Some argue they're a majority and I'm sure at least in terms of numbers that's true, but they're invisible to most. (Not that I especially want to be part of any of these proprietary implementations)

ideally they should use their own halfbaked buggy protocol, will help them die sooner

> I don't mind if it does, since I don't care about any non FLOSS people/things/companies > how does it help any of us if say slack is using XMPP underneath? meh Many of us are employed by people that create proprietary implementations.

moparisthebest, I agree, it doesn't, at least as long as their goal is not to federate and be happy ever after.

For what it's worth, the UK Government, for example, would explicitly outlaw standardising on XMPP if we didn't allow XMPP in "both open source and proprietary licensed solutions". FSFE, FFI, and OSI all agree.

Guus, and you wouldn't be employed if those were relicensed GPL down the line?

interesting dwd , I'd be curious what the reason is for that or the specific law

moparisthebest: those solutions wouldn't have been based on XMPP then

dwd, I'm not especially happy with OSI fwiw.

Guus, eeehhh that seems again like "businesses won't use GPL" and that's simply not true, Linux

And relicensing is absolutely out of the question in many board rooms.

moparisthebest, It's not law, but policy.

and I don't care about those board rooms, they can roll their own xmpp-like replacement and die

moparisthebest, And I can tell you that my employer wouldn't be using XMPP if it weren't an open standard - they switched from a proprietary solution in part because of this.

some better company will come along, take over their business, and hire their devs :)

You severely underestimate how much the XMPP community benefits from these organisations.

Guus, well that's an issue as I said above. They hide themselves.

(or take it the other way if you prefer. They're not visible)

In the meantime, XMPP is still largely influenced by these implementations

Gtg, kid is here

you misunderstand me, maybe that's a huge segment, I don't care about those use-cases or organizations

pep_, I have tried to get some of the organisations I've worked with to be a bit more open abut their usage, but it's quite difficult.

dwd, and that's one of my issues with them

this is an aside, but how many of those non-open-source companies would have implemented OMEMO if not for GPL thing? my guess is none

I guess a decent proxy might be how many support PGP or OTR? my guess is also none

moparisthebest, Entirely possible that it's none, I agree. But what if it were something else?

moparisthebest, I can tell you that my employer will be implenting E2EE this year, but not OMEMO. That's not only due to licensing, though the licensing makes it a non-starter.

I guess that's part of why I'm fine if individual XEPs are marked "in our legal opinion (IANAL) this is only implementable in GPL code"

We can't *have* a legal opinion if we're not lawyers.

We might, wrongly :-°

Companies using XMPP in proprietary ways can obviously help by (as has been said) paying some of us, and by debugging the software we use and having fixes back upstreamed. I don't agree with "let's just fuck them, that'll magically give us better companies". It won't.

Agree. I believe in open standards for interoperability. I think the discussions would be different if a proprietary E2EE protocol was dominant already...

MattJ, free software implementations just wouldn't use it..

Requiring implementations be GPL will not make closed-source implementations become GPL. It will just make closed-source implementations become non-interoperable.

Which is not a world I want to live in, which is why I dedicate so much to open standards

MattJ, and how is that different than the current situation?

reworded, name an existing public federated interoperable closed source implementation

moparisthebest, we want to fix the current situation. As I understand it people are arguing that the current situation is acceptable (GPL-only implementations allowed)

moparisthebest, that doesn't make sense - this whole discussion is about the fact that closed-source interoperable implementations are not possible

so it hasn't happened in 21 years but maybe it'll happen soon? meh

because of the GPL restriction

moparisthebest, *public*? That's difficult. But federated, partially closed-source (and partially open-source), and interoperable: https://en.wikipedia.org/wiki/Federated_Mission_Networking

moparisthebest, Even includes some GPL clients, I think. Certainly includes open source. That page doesn't actually mention XMPP at all, but a Google for "NATO XMPP" will get you a lot. You might even recognise some company names there.

ok I'll try another take, e2ee is a bit of a special case and I could make the case that it'd be irresponsible to allow non-open-source implementations, so maybe only e2ee XEPs can enforce GPL? :)

moparisthebest, Neither TLS, PGP, or MLS require GPL, so that rather falls down as an argument.

doesn't mean we couldn't do it differently

moparisthebest, Doesn't mean we have to do it differently either.

(fwiw, I wouldn't especially be proud that the army is using XMPP..)

govts aren't really bound by licenses/GPL anyway

pep_, that's going down yet another rabbit-hole - if you want to choose who is even allowed to use your technology/software

At that point yeah, we might as well just remove any reference to "open"

I suppose if you want to relegate XMPP to an even more limited group of implementors, users, then excluding commercial entities is the way to go.

moparisthebest, They seriously are. I could tell some tales about that, but they're real sticklers for licensing.

I for one find that acceptable for the XSF.

dwd, they aren't even bound by laws, UK for example just broke a ton of laws then changed them retroactively? :)

ralphm, acceptable? or unacceptable?

hah, *not* acceptable.

Phew

MattJ: Sure it is. I'm not saying that's easy. I'm also not saying I want to move in that direction right away, but it's crossed my mind quite a few times

I do not intend to take any steps to exclude any field of endevour from our standards process or membership.

Me neither

ralphm, who is talking about excluding commercial entities

pep. expecting commercial entities to adhere to GPL-type licensing for so-called open standards is not a realistic world view in my opinion.

GPL doesn't in any way exclude commercial entities though

^

and we are talking on an individual XEP basis

except it does

ralphm, that's maybe your biased view. Many implementations succeed in using copyleft licenses and being sustainable

moparisthebest, you said yourself (iirc) that such a XEP wouldn't be able to be included in the compliance suite

I mean, it could, but it means it's not quite as simple as "it's just one XEP"

I am happy for people to thrive with GPL code. I think that Open Standard and requiring a specific license to implement said standard is mutually exclusive.

ralphm, maybe you mean it excludes non-GPL implementations, sure, but those could be commercial or non commercial

We're trying to reduce fragmentation in XMPP, or at least that's what I've been working on

MattJ, "we"?

"in XMPP", which part?

The XSF, from the very beginning.

"The XSF" is not one person

So much text produced over this issue.

pep_, compliance suites are for reducing fragmentation

and that has been a community effort

for years

MattJ, but you just ignore the part you don't want or can't implement, I don't think it matters there

moparisthebest, I just tried to chat with a non-OMEMO client in Conversations and it took 3 taps through various confirmation boxes

there are a whole slew of reasons why $company/$project can't or won't implement a XEP, licensing is just one of them

If we also care about UX, yes, fragmentation matters

MattJ, good? :)

pep., I won't go into legal definitions, but US corporations are actually considered to be equivalent to a person. That aside, the XSF was founded on principles of openness. This is why we have this set out in our bylaws and XEP-0001, and I will do everything in my power to not deviate from those values.

you are of course free to fork Conversations to fix the UX

#semantics

ralphm, and GPL is the pinnacle of openness so that's great! :)

but yes, what pep_ said

moparisthebest, and decrease practical security in return

How so?

moparisthebest, all because the XSF refused to provide a fair standard

"Security by obscurity"?

We all know that doesn't work

moparisthebest, I'm sure there are many people that believe this, but I think there's an explicit difference between code and protocols, and I'd like to not muddle those concepts by requiring a license for implementations.

pep_, disabling E2EE silently without informing/confirming with the user is a security problem

I suppose forking is always an option, GXSF publishing GPL'd GEPs anyone? :/

Without informing the user? What client does that?

pep_, the one moparisthebest just suggested I create in order to fix the UX caused by a fragmented ecosystem

moparisthebest, And the XSF's licensing allows that.

moparisthebest, indeed, XMPP standards development is not somehow restricted to the XSF or the IETF. If you want to have your own extension protocols, that's entirely possible. Also by design.

MattJ, I missed that bit sorry

moparisthebest, Because we're an *open* standards organisation.

In fact, the namespaces in XEP-0384 are not even tied to or regulated by the XSF.

It's not the only XEP fwiw

sure

I guess this whole thing has been enlightening to me

I'm not saying fork all XEPs, I'm saying I (and apparantly at least 1 other person here) don't see any harm in publishing specific XEPs that might require GPL-compatible implementations

I'd like the XSF to change to allow that

but if it won't it might be valuable to have an open place to publish them

moparisthebest, not entirely sure what I think about it tbh, but I'm not entirely closed to the idea. At least I'm not arguing the other way

moparisthebest, For OMEMO specifically, that's a fine idea. I suggested it earlier.

moparisthebest, I think everyone here is totally fine with them being published, just not by the XSF

I think the copyleft/GPL != business is just very wrong

I think a lot of people and corporations (including probably all sponsors) would leave the XSF if we would ever change that, moparisthebest.

I would.

that'd be ridiculous

but I also couldn't care less if they did, no loss as far as I'm concerned

pep_, another time I'd love to hear your thoughts on how a pure GPL "commercial entity" would work

Sure

But I think that's even too OT for here right now

you could try next door

I didn't want to disturb the tranquility there

I'm on a nazi network I only have http available atm..

MattJ, Pure software, not services? Tricky. I've seen people try, but I've seen all of them fail.

dwd, logically that makes sense, yes :)

dwd, wait are their pure software companies that just sell proprietary software with no support or services? :/

I think Conversations is a nice example of this fwiw

*there wow...

Conversations.im being separate from Conversations.

pep_, Possibly. Though I wasn't sure whether Conversations was a serious revenue stream, or if that was mostly the services.

I'm sure he's not making millions, but you don't need that to live anyway

moparisthebest, By services I meant hosted services. I've seen plenty of GPL-and-support companies fail.

I'd be very surprised if Conversations' play store income suffices to continue its development other than as a hobby.

Conversations’ app store sales make much more money than conversations.im

what's Redhat dwd / MattJ ?

not in absolut numbers (both are pretty low) but in relative terms

Daniel, could it be your day job?

no

i mean it is. but no

hahahaha

:-D

And you do consulting around it, right

And it's just fine

in a past life I made a good living giving away only open source software for free, on a website that had ads on it

Nobody "just" sells software anyway. You sell support, training, hosting, contracting (adding features/fixing bugs)

so there are plenty of ways, which is beside the point that I think the XSF should be able to publish GPL-requiring XEPs

I don't see the point and think allowing that is harmful. Maybe even just entertaining the idea is.

I don't think I can be convinced entertaining any idea is ever harmful

ralphm, and I don't see the point in non-GPL software existing, different perspectives eh?

moparisthebest, different perspectives is fine.

moparisthebest, I'm honestly not convinced copyleft (our hackish use of copyright) is the solution. It's just the least worst solution we have for now :x

sure let's get a law banning distribution of binaries ? :D

Obliterate patents and copyright

But is literally my job to serve the XSF and the larger XMPP Community the best I can. Protocols and formats should be entirely open. For code, I am happy for people to make their own choices. I am not even a big fan of copyright law (which GPL ironically depends on to work) or patents.

I know we'll never fully agree on everything and that's fine, and I think it'd be ridiculous for all XEPs to require GPL, I know that's not going to happen, probably even shouldn't happen

but I don't see any problem whatsoever with an e2e XEP requiring GPL, and maybe the rare XEP here and there requiring it

I would like the XSF to change to allow that

and if it doesn't, fine, I'd still like to see it though, that's all

moparisthebest, ok. Do you intend to take a particular course of action?

Right.

I do see a problem with the XSF publishing specifications that, from a licensing perspective, limits people from using it. I do not want the XSF to allow for this. ✏

I mean, I'm not 100% against that idea

But it reduces the XSF to a repository of documents

I'd go further and say that I hope that no-one creates such XEPs and publishes them anywere (out of XSF context), which is clearly out of my hands - but doing so would, in my opinion, hurt XMPP.

good point ralphm , might be good to bring it up for an official vote by board and/or XSF membership, not entirely clear on how that works

Such a document could just as easily be hosted elsewhere

MattJ, tbh, the XSF is not far from that to me atm.. a badly organized repository of documents

pep_, sad you feel that way, I think it has quite a bit of expertise to offer as well

> Guus> I'd go further and say that I hope that no-one creates such XEPs and publishes them anywere (out of XSF context), which is clearly out of my hands - but doing so would, in my opinion, hurt XMPP. You're late to the party, this is already being done (not OMEMO)

Hmm, not license related, but "standards" used in the whole community that are not XEPs

That's a hugely different thing there.

Not so different to me. That makes some of them proprietary documents

XMPP extension protocols published (or not) by entities other than the XSF or the IETF is totally fine. By design!

So proprietary is fine, but free software isn't

We designed XMPP to be distributedly extensible.

I see

Maybe you weren't replying to what Guus said. because it seems to me we're not in sync

(I was explicitly referring the XEPs with specific license restrictions applied to their implementations - I'm totally fine with XEPs being published outside of the XSF)

Or I'm not reading that correctly

pep., my own opinion: I think protocols and formats should be entirely open. I don't believe in copyleft, publish all my own code under MIT, and am happy for everyone to make their own choices in this.

I'd rather people didn't actively subvert the XSF's goals, but otherwise I'm fine with people publishing stuff like OMEMO (or RTMP/Jingle, or whatever) outisde the XSF.

Guus, what does it change then if it's published out of the XSF to you? Free software or proprietary

i haven’t been reading the entire backlog but i don’t like the implied hostility towards commercial services. commercial services bring a lot of knowledge into the xsf

pep_ I'm unsure if I understand your question.

I'm trying to reread your message that I quoted and see what I didn't get

> I hope that no-one creates such XEPs and publishes them anywere

Daniel, Yes, but we're evil. So it's evil knowledge. EVIL!

Daniel, personally I'm not hostile towards commercial services

pep_ XEPs that are published for adoption by community at large, that include a restriction that their implementation requires a specific license, hurts XMPP, in my opinion. I hope that no-one publishes that (very specific) type of XEP.

I'm unsure how to word that differently.

Because it by its very nature fractures the community.

Guus, so you also don't like practices like say.. MUC avatars?

I personally don't like the way MUC avatars were introduced, no

Multiple attempts to specify that have been rejected by council

An interesting observation from that is that OMEMO is only a problem because it's fundamentally a useful and desirable feature at its core.

I'm not familiar with MUC avatars, but it doesn't require someone that implements it to release that implementation under a very specific license, does it?

It crashed at least one client, and I still get a ghost user in some of my clients/MUCs

So we're using some proprietary protocol atm, that sits on processone's website

But no one is actually complaining about them

weirdly

I mean, no one that is complaining about OMEMO

pep_ I think we're talking about different things.

I mean, other than MattJ, two whole lines above. ✏

Why even have a standards organization, just implement whatever you want and whatever becomes popular is the standard! /s

in that point i disagree with Guus. I think OMEMO can (and maybe should) exist outside the XSF. by using gpl libraries we were able to move (relatively) rapidly with omemo and bring e2ee to 'our' community

Loosely a +1 to that.

pep., Do you mean https://xmpp.org/extensions/inbox/muc-avatars.html

Daniel OMEMO as-is will never be adopted fully, because of the license issues. If this remains the defacto standard, then potential users that don't want to use it because of the license restrictions will see that as a major disadvantage of XMPP>

ralphm, yes, and another one as well

I do have concerns about doing an "end-run" around the standards process, as indeed pep. is talking about with MUC Avatars. (Honestly I've not followed that - I knew there were implementations, but figured it had gone away).

dwd, no, MUC avatars are a thing

Everyone has MUC avatars

pep., so having been submitted to the XSF for consideration already has it bound by our IPR, and is therefore, in fact, without restrictions to implement.

also the fact that 'our' community (free, open source, publicly federating) gained a little more traction in recent years (in part thanks to OMEMO as a 'brand') also benefits the commercial community because it brings xmpp back into the minds of people who want to build something closed on xmpp

I’m for sure not setting them manually on search.jabber.network ;)

pep., I don't remember why it didn't get accepted as a XEP, though.

Daniel I'm not arguing it's all bad at all - but in the long run, I think it hurts more than that it brings benefit - especially if we're going to see more of this.

Daniel, That's true. Though if we bring lots of interest to XMPP for them to find the thing that brought them here isn't available to them, that'd be a bit of a pointless exercise. :-)

Guus, well it is 'fully adopted' in the free open source world

i think any actively developed client has support for it

ralphm, can't find the original document atm, but it wasn't hosted on the XSF infra at all.

Swift doesn't (yes, it's still developed) :)

Daniel I can't add it to Apache2-licensed clients, as far as I can tell.

Guus, no. but you can relicense the client

ralphm, That one? Introducing pubsub on MUC, I think, blocked it. Perhaps.

which i think some clients have done

But I don't want to relicense the client.

i don’t like the gpl either and i'm not happy about the current situation. but it is still fairly widely deployed

Because that might affect people that are using my client as a base for something that they're developing (it'll require them to relicense too)

Sure, absolutely, I agree to that.

i mean show me another xep from the past 5 years that is as widely deployed as omemo

MIX

Guus> Daniel I can't add it to Apache2-licensed clients, as far as I can tell. You can, but the result is GPLv3

There were quite a few smaller commercial clients based on Smack which blindly brought in OMEMO support too.

Sadly, we did not sue them all and made $$$

Daniel, MAM

ralphm, i would like to see stats on that. it might be very close or equal

But yes, just because something isn't behind a paywall on the internet, does not automtaically mean that you can use it in your product. That is true for software, but also for standards

flow: enforcing GPL, with what money? these free software people they're not supposed to produce work for free? 🙂

Wasn't OMEMO already on the path to popularity before becoming a XEP?

Zash, It was in Conversations for ~1 year before becoming a XEP.

And, isn't it still the pre-XEP version that's popular?

Look, OMEMO is pretty great. It gave good value. It's just very unfortunate that we waded into this weird licensing territory with it.

(also http upload, i'm obviously exaggerating to make a point)

HTTP Upload has at least moved within the standards process since

has it? (looking at you http upload encryption)

but is currently stuck for some unknown reason

but that's a different story

moparisthebest, yeah that's a different XEP..

or ProtoXEP, rather

basically, we aren't lawyers, and as dwd aren't qualified to have a legal opinion as to whether omemo can be reverse engineered and/or implemented non-GPL, but are somehow still making the decision that it can't and that we shouldn't publish it

I'd prefer to end-run that and just say we are ok with GPL requiring XEPs

moparisthebest, no, you misunderstood

this

Daniel, haha what, stuck in last call?

ok that's fair I guess jonas’

we made the decision that the licensing situation is very ambiguous (much more than the average XEP), and consider that a problem in and of itself ✏

moparisthebest, see my edit tho

still what's the appropriate method to bring up "allowing GPL-requiring XEPs" for a membership vote or whatever?

All this said, I'm still not happy with the message we're sending, and whatever you may say about it won't make me change my opinion

moparisthebest, also, to answer your question on how do do this: (it will take some time to type)

moparisthebest, send it to Alex or Board I think?

> The Last Call ends on 2019-01-22 mhh ok

editors should look into that

Daniel, I think there was unaddressed last call feedback

but I may be wrong

pep_ I agree with you that this all reflects poorly on us.

Daniel, ... but I can’t find any evidence of that

and neither 'solution' will be able to fix that.

We just differ on opinion on which solution is the least worst one, I think.

moparisthebest, to get rid of Objective #4 in XEP-0001, you can put in a PR. This will be reviewed by Board. From gauging the current set of Directors, that would not gain a majority. The next step could be to have it discussed and put up for a vote with the Membership. This you can suggest and schedule with Alex, our Secretary. I'd be surprised if you'd get a majority there.

I'd like to bring it up for a membership vote just out of principle honestly

I guess you can start a thread on the list, without putting it for a vote. There is no majority for sure

just gauging the room I also suspect it won't reach a majority

jonas’, i think it has had multiple last calls. some had feedback (which got addressed)

I vote no!

No to everything!

and then the last last call didn’t have any replies at all

Zash, thanks I'll just word it negative then :)

Daniel, I guess we should put it on the next council agenda to restart the LC

or maybe the editors can just do that

(or even have to)

jonas’, XEP-0363 had LC feedback, but that was the first LC in Fedb 2018. That all got addressed in Dec 2018, and I don't see any LC feedback at all in Jan 2019.

reminds me that I need to update the spreadsheet of dooom

i'm going to assume that's because everyone is happy :-)

jonas’, I'd stick an LC on the agenda for the next Council meeting.

jonas’, Oh, you can automatically restart it, actually. Declare it as a Council change auto-restart.

dwd, exactly

That's a thing?

pep_, Yes, if a Council changes after an LC but before the advancement to Draft is complete, the LC restarts.

Even if the LC is almost a year long? 😛

Consideration for advancement to draft* I think

It doesn't get restarted if one Council rejects the move to Draft.

Kev, Yes. Before the vote to Draft or before such a vote completes, I suppose.

pep_, Well, it's not *meant* to happen this way.

(Not that I'm opposing this move)

moparisthebest: I don't think trying all these endruns around our procedures is a great idea. It would be great if you'd at least respected the procedures we currently have in place: Council can form its opinion on OMEMO (and they will next week), Board can weigh in because of (at least) liability concerns. If you are then unhappy, please first just do the PR and let Board do its job. Then as a final thing you can still go to the membership. You'd need at least 5% of the membership to put a matter up for a vote, by the way.

I don't have super strong feelings about OMEMO specifically

I do have a strong feeling that we *should* be able to publish GPL-requiring XEPs

Well, I don't like to waste time on hypotheticals, to be honest.

dwd: > The second form, "full", presents every message stanza in the results, including all fastenings, errors, and so on. that's a <result xmlns="mam"> with multiple forwards?

or just multiple results?

well also it's not a hypothetical, it means whether omemo requires GPL is a non-issue right?

then it can be evaluated on technical merits as it should (in my opinion)

*only on technical merits

a never mind

that's kinda the status quo

moparisthebest, as I see it, you have three options: (a) Accept that the people who’re currently deciding things in the Council and Board do not agree with you and move on. (b) Start the process to approve GPL-only XEPs (via PR against XEP-0001 and possibly membership vote) (c) Continue to fight this fight, consuming lots of resources on all parties, without going through the process, thus making any chance for change very slim

moparisthebest, I’d like it if you did not take option (c), because it is very streneous on my mental capacities, and I’m sure others too

right, I'd like to just do (b)

moparisthebest, please do so then

thank you very much.

yep and I appreciate the discussion and pointers on how to do that

Does Xep1 get a membership vote? Bylaws do, doesn't Xep1 just get Board?

I forget, and don't have cycles to look it up

Kev: yes, XEP-0001 is Board only.

But, the membership is king

So they could override Board.

That's why I presented that order.

They could overthrow Board, and elect a new one that would produce a different result. I don't think they can simply overturn Board's decision, though.

Unless I'm missing something.

Kev, in my understanding, membership can start a vote on about anything. If board rejects a PR against '1 which membership wants to have, I don’t see a reason why membership couldn’t start a vote (given the prerequisites for a membership vote) to accept this PR overriding boards decision

I think they would have to change the process first that says that only Board can approve changes.

couldn’t membership vote for a process exception? :)

Daniel, MAMFC? That's like current MAM, but if it archived everything, not just "traditional IM messages".

jonas’: I hope we don't get to the stage that we need such a discussion.

Kev: in any membership organisation I've served in, what jonas’ described can be done. However, it is also often a huge hammer that Directors walk out over.

so if moparisthebest thinks this is the best course of action to prove a point, well, I guess that's what has to happen

I personally think it is irresponsible.

dwd, yes. thank you

re: fallback body

I would like to make this a regular practice fwiw, having members vote on things, without all the weight you all just mentioned

For the little it's worth, I'm feeling quite hurt at the moment, as a person who has contributed to the XSF for 'a while' while producing GPL, OSS-but-not-GPL and closed-source XMPP projects, that the the current tone of the conversation is that because I'm involved in non-GPL projects I matter less.

What's wrong with that.

If directors can alleviate some of the work for members, great. if members feel they need to vote themselves, why not

iirc message processing hints was rejected because people thought that the hints should be closer to the XEP they are influencing. like store should be in MAM, no-copy should be in carbons etc

pep_, because it’s not just members, but also secretary who has to do the work

and given that we’re all volunteers...

by that defintion shouldn't fallback be in either MAM or mamfc

Kev, I’m quite unhappy that you feel that way, and I need to say that you or your opinion doesn’t matter less to me.

jonas’, that's fine, that doesn't justify the "that is also often a huge hammer that Directors walk out over"

I think fallback being outside MAM/MAMFC/Fastening is preferable, but I'm not sure I would hugely care to see it move.

Daniel, Well, I thought fallback was more general - it could be used by clients which don't know what the fallback is for to mark the message in some way.

jonas’: Thank you.

imho if you like general; put it in hints; if you don’t put it in mamfc

Kev, and to mitigate some fallout, I also need to say that I’m a strong GPL proponent. I’m however aware that the XSF is not the vehicle for that, and I’m also clear that GPL isn’t always (often, actually) working out for commercial projects.

both are valid approaches. but a new XEP i don’t get

I hold that an open specification can't mandate licensing of implementations.

pep., the thing is this: a Board of Directors is there to govern the Corporation on behalf of its membership. It gets elected to do this, and thus a mandate. When you get to the point that you want to *override* the Board on a topic, that's a huge hammer. That was my point.

I don't see that as a hammer, I think it's great actually

Having members participate

Daniel: FWIW, I think fallbacks are often harmful, and it's useful for a client to know because it could choose to handle them differently from a normal body.

Maybe harmful is hyperbole

I didn't say we should get rid of the possibility, I just think that it should not be used frivolously.

But out of place in a normal flow.

ralphm: I'd like to see that a lot more often. I'd even like it to be the default. I do understand that people don't have that much time and that's why the board of Directors is appointed

e.g. you could do something like: [There are some messages in this chat that you can't handle. Would you like to see a fallback rendering? Y/N]

Not the opposite. I don't think I'm here to govern anybody, I'm here to serve

Daniel, I did say I'd go for hints, but that's been pushed back by a previous Council.

pep_, so how I see it, and I think what ralphm wants to express is: The board gets elected to delegate work and that comes with some trust. If membership overrides decisions by board, that’s effectively a statement of distrust.

i agree on the harmfullness and i was team no-fallback for reactions

and that’s hurtful, demotivating and unsettling for the elected members of board

And if the chat was full of +1 noise, it would hide/show that.

but i wouldn’t know how to handle a fallback message in the client

See above :)

Daniel, <fallback/> is an attempt to allow us to be less anti-fallback.

dwd, I'd like to point out that there's some overlap with the EME XEP

Zash, Oh. Yes, there probably is.

jonas’, yes indeed.

And on Ralph's point, I agree that Membership overriding Board is a thing that implies a lack of trust in Board and is very possibly a message to Board that they would be best to step down. Or at the least it would be reasonable for a member of Board to feel that that was the message.

pep., you *are* appointed to govern the XSF, the corporation. This is different from governing its membership.

Govern: conduct the policy, actions and affairs of (an organisation) with authority.

I think that's pretty much the definition of what Board does. ✏

Yes, I tried to convey that I don't view members as underlings :-D

ralphm: And we love you all the more for it ;)

I just prefer to see that from the members' perspective, as I am also one, and I want everybody not to be afraid to express an opinion and push it through our process.

Well, if any topic has been discussed to death in the last week, it has been this one. I'm not sure how much more opinion you can squeeze out of people without rage ensuing.

Sure 🙂

Asking everyone about everything is what gets you Brexit.

That's just wrong

Where 'wrong' means 'demonstrably right' :)

You're forgetting lots of context here

dwd: I also feel like in most cases where the body is there for fallback reasons, that by itself doesn't help with knowing how to treat it. IE an encrypted message should probably be treated as a chat message with a body, but reactions might warrant different treatment. I think Ge0rG touched on this, that you need understand the thing it's a fallback for to treat it right in many cases. But it still feels like it could be useful somewhere.

Zash: I think my suggestion is actually a fairly reasonable least-knowledge way of handling fallbacks.

Kev, where?

I'm having a hard time following everything in this :(

> e.g. you could do something like: [There are some messages in this chat that you can't handle. Would you like to see a fallback rendering? Y/N]

pep_, nothing stops a member from proposing a PR against for example '1 and arguing their case

Kev, yeah, that's sensible.

jonas’, exactly, and I'm saying people should do it 🙂

(Whether it's this specific case or another)

Kev, and just to be clear I mean no insult, I just think the XSF should be able to publish XEPs that require GPL implementations, and anyone can choose whether they want to implement them or not, that's it (I'm explicitly opposed to the idea this is anti-business or anything)

I think that is a reasonable position to hold, fwiw

pep_, it’s a different thing to say: "Make a PR against '1 and let board decide" and "request a membership vote to bypass board"

I don't think so

One is bypassing the authority of the elected board, one isn’t.

I agree with jonas’.

one is sending a message of distrust, one isn’t.

The authority lies with the members.

Board is elected by the members

yes

I’m not arguing that point

the members elect board to delegate authority

if they do votes to bypass board, they effectively state that they don’t trust that board will execute the delegation as they want them to

that’s distrust

I understand what you're saying, I just don't see that as distrust

something something never ask the people unless you know the outcome

I fail to see how you can’t, pep_, and I’d like to know your rebuttal to my arguments

I'm not sure how to formulate that indeed. I'll sleep over it

jonas’, I think it makes sense in cases where the board doesn't want to decide over the members

from the e2ee sig proposal > Represent the interests and requirements of the XMPP community during the development of end-to-end encryption protocols that are non-exclusive to XMPP. that opens the interesting question if the xsf would be willing to / has the funds to sponsor a representative to go to one of the IETF MLS meetings

jonas’, I am not sure if that ever was a thing in the XSF, I personally know that from one organisation, the directors just refuse to do certain things without asking the members first, because they feel obligated to act in the members interests and thus if they feel they don't know exactly what the members want, they will ask them

larma: I think there are plenty of good reasons for Board to ask the Members on something.

Daniel, Yes, but that line was the single line that I objected to.

because i wouldn’t want to pay that out of my own pocket (never mind the fact that i probably wont be a good person to to that because i don’t know anything about cyrpto)

I think that's a very different prospect from the Board making a decision on something that our process says is Board's to decide, and the Members then calling a vote to overturn it.

Daniel, Actually, you'd be great - the problem that group has is in practical messaging, not the crypto side.

Daniel, (I objected to that line because I think external representation is a Board thing)

jonas’, or maybe, even if it's distrust, I actually find this healthy, and that it should be common practice to challenge board every so often. "A majority of Yes in a vote for a president/government is not especially a good sign" 🙂

Kev, I'd kind of believe that in most cases when it says, board decides, the motivation is not that board does what makes most sense for them, but board does what would be what members want, no?

Daniel, I don't think physical presense is required to participate in MLS at all.

but representing our interests within the mls working group is important and should be done before it is too late (i think paul might have actually put that into the proposal because i said something along those lines)

ralphm, It's really really helpful.

that

larma: I think that's a very complicated question that doesn't have a pithy answer.

but I am not opposed to sponsoring a visit to an IETF

Daniel, I've been to a couple of the meetings (London IETF and the London Interim). Really useful to understand where they are, and really useful to be able to provide input.

We have sponsored a visit to an IETF previously, haven't we?

Kev: we did?

Kev, Yes, I think so. Previous London IETF, we sponsored Thijs, didn't we?

Maybe I'm misremembering, I thought we sponsored Thijs to attend IETF London a while back.

https://ietf.org/how/meetings/upcoming/

The next 'close' one for most of us is 108, in July, Madrid

ralphm, MLS gets a lot of its work done in f2f interims, too.

ralphm, Of which there's one tomorrow: https://datatracker.ietf.org/meeting/interim-2020-mls-01/session/mls

There's one this weekend it seems

Agenda is empty though

"When" the E2EE SIG gets approved (when we figure this out :p), I'm also happy to use our dormant money for this

https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD

ralphm, Daniel https://github.com/mlswg/wg-materials/blob/master/interim-2020-01/README.MD

hah

Be sure to read the NOTE WELL!

the mls@jabber.ietf.org channel only has known xmpp people in it :-/

I think it only gets traffic during meetings normally.

Seriously people, what happened to this MUC? I've taken most of today just to catch up with the logs

as long as it actually does it's fine

Can we please have a bot that will auto-kickban on mention of "GPL"?

Ge0rG, will it exclude AGPL ?

Daniel, Sadly not very much during Interims.

it says i MUST register. it doesn’t say where

ok I'll just start using GNU General Public License everywhere, break my keyboard

moparisthebest: after seeing other people engage with you on this topic, let's just agree to disagree.

one person seemed to at least semi-agree, and I suspect membership in general might agree more than majority of this room, but I guess we'll find out won't we

Kev: I somewhat like your idea of [show fallback messages? (y/n)], but I fear that having different unsupported fallbacks in the same chat flow might cause issues as well.

Ge0rG: It is certainly not a perfect solution.

Nor is the fallbacks XEP.

But we don't strive for perfect, merely for good enough.

I can't immediately think of anything better - although that might be a lack of imagination.

[Unable to display message, fallback displayed] ** Something like this? **

Kev: add the namespace and a human-readable description of the fallback-inducing element into the fallback element, have the client maintain a list of checkboxes :P

dwd: that's an interesting angle indeed: "Your client is too old and doesn't support all elements of this message"

That was what I was thinking a client might do. A server might not index it for MAM, or something.

Ge0rG, Yes.

Ge0rG, I didn't think of it.

dwd: what is the reason for <fallback> not containing the namespace of the causing element? ✏

Great!

dwd: is there _still_ a reason for <fallback> not containing the namespace of the causing element?

Ge0rG, I'm somewhat ambivalent to that - I don't know what a client/server would do differently.

Ge0rG, But equally, it does no harm.

Ge0rG, It'd be a good reason *not* to try to put this in Hints, though.

dwd: it could fetch the XEP that defines that namespace from the registry :P

AND USE MACHINE LEARNING TO AUTOMATICALLY IMPLEMENT THE XEP AND THEN STORE THE RESULT IN THE BLOCKCHAIN.

Sorry, don't know what came over me then.

dwd: who are you and what have you done to dwd?

with all the roster shenanigans, probably dwd got replaced by aliens.

dwd, happened to have read my comment re partial fallback body?

larma: please don't add more complexity

It does actually seem pretty useful though..

larma: I know it's sexy to put five different things into one message, but it makes everything more complicated

Ge0rG, if it's not in there it has to be somewhere else

pep_: it should be redefined in terms of fastenings.

So this is only for fastening, not for anything else?

No, it's for everything where we're only using <body/> as a fallback.

larma: do you have a convincing use case for that?

Ge0rG, reply to

I think we need to revive https://xmpp.org/extensions/xep-0226.html

larma: ah, right. Hm....

larma: what if we just ignore the problem of legacy clients showing a fallback body in a slightly awkward way?

Ge0rG, what do you mean?

larma, Ah, that. Yeah, I figured that it'd be an all-or-nothing; I think something like you're proposing ought to be in one of our many markup/down/sideways things.

larma: I'm just thinking out loud. I suppose we'd have to add a new <reply> element that would contain just the body of the reply for that to work

larma, But, mea culpa for not responding.

Ge0rG, I was thinking along those lines https://gist.github.com/mar-v-in/8f66872bb533f7e805fb174e341be992

larma: yeah, I understand that. Would also work great for Reaction fallbacks :D

Ge0rG, you mean: we can explore if this would also work great for reactions fallbacks and then decide it doesn't 😀

but yeah, there are various things where it would be handy

larma: the question is: is it worth the added complexity?

If the complexity is not added to <fallback /> it would have to be added to reply-to or reply-to will not be backwards compatible

I don't like the third option really

alternatively we can have something else for that

larma, It's what we have now.

larma, By which I mean, I've just replied to you. And again here.

dwd, I think we can also do this as an annotation mostly for fastenings, then both (what it is a fallback for and the begin/end thing) wouldn't be necessary

It would still make sense to have the other thing though

but could be separated from each other

because my usecase is obviously completely unrelated to fastening