ralphmFrom a quick reread, I think we agreed to disagree, where the majority seems to not think this is a problem.
ralphmAnything we need to discuss further?
pep.Also related: https://www.mnot.net/blog/2020/08/28/for_the_users, that I linked last week
GuusI missed it.
GuusI'm still at the same place where I was a couple of months ago: to me, this all feels like a semantics discussion where I've yet to see tangible results.
pep.TL;DR: “So at its heart, The Internet is for End Users is a call for IETF participants to stop pretending that they can ignore the non-technical consequences of their decisions”
pep.Guus, I'm not entirely sure what you call tangible
pep.I think that's actually the main goal of board, to discuss of what you all call meta-stuff
ralphmI haven't read that fully yet, but I'm not sure how the XSF is pretending that they can ignore non-technical consequences of their decisions, if that's the implication.
pep.Even the mission statement is not clear on who are priorities are. It states « freedom, openness », but these words mean nothing without any context and they can be used for anything
MattJSo we need to include in the mission statement definitions of all the terms?
pep.Maybe be slightly more specific? For exemple even just mentioning (end-)users
MattJAs far as I'm concerned our protocols are open (they are developed and published publicly) and free (anyone can use them)
pep.(And of course applying it afterwards, not just for show)
pep.MattJ, good. Now who are these protocols designed for, what purpose. Does the XSF accept anything that comes by? If so why? Or why not?
ralphmThe mission statement doesn't live a vacuum. It lives on our website, so it other documents go into details, like https://xmpp.org/about/technology-overview.html. Additionally there are well-established meanings behind these words. I am not sure we need ironclad definitions.
MattJI don't think that level of detail belongs in a mission statement. Maybe in some other document...
pep.Whatever the answer to these questions these are choices that the XSF (board / members) has to make, and choice means taking sides
pep.So no we are not neutral, even if we haven't answered these questions they are answered implicitely
pep.Anyway I encourage you to read that blog article, and the RFC that goes with it
ralphmYes, it might be that we decide to non accept a submission. Usually this is on technical grounds. Sometimes on license issues. I don't think the XSF is 100% neutral. We encourage, and require at a stage, open source implementations. But we do not, as an organisation, favour particular contributors or specific implementations.
pep.Would we accept a spec that encourages tracking users for example
pep.Also just the use of the word "open-source" and not "free software", etc. etc.
SyndaceSorry to interrupt, where would I find said mission statement? Is it the first paragraph of https://xmpp.org/about/xmpp-standards-foundation.html ?
pep.It's not linked from anywhere :/
ralphmWe can fill hours of discussions on the difference between Open Source and Free Software.
Ge0rGI'd also like to contribute a small AOB topic to the meeting: the IETF's use of Jabber.
GuusTo me, this feels like an never-ending rabbit hole of trying to preemptively define everything - I wonder what the benefit will be of us putting in the time and effort to do so.
pep.ralphm, the actual difference is not the point. The mere fact that there are differences is a clue that choices have been made and this is not neutral
MattJThe "neutral" thing is being thrown about a lot, did we actually formalize any statement on what this means?
ralphmBut what is the *problem* with that then? We are not 100% neutral, and I also don't think we claim to be.
pep.MattJ, I haven't seen any :/
ralphmSo where does this perceived incongruence come from?
MattJThe primary neutrality that I am concerned with is one of implementation neutrality, along the lines of the question that was included in the members survey a few years ago
pep.ralphm, don't we? Maybe not publicly but everybody present here at least has heard of the so-called neutrality I'd hope
pep.There has even been a poll a few years ago
MattJi.e. the idea that the XSF should not favour/promote certain XMPP projects above others
MattJIt's nothing to do with favouring one or another stance on protocols
pep.Guus, is it not important to define who we're doing what we're doing for?
ralphmTo me, the XSFs so-called neutrality is focussed on the ability for everyone to implement protocols we standardize in our process, and not actively promote certain implementations over others.
pep.I mean, not developers, obviously they're gonna be the ones using the technology, but who is that technology for
ralphmAnd we did have a loooong discussion on the Signal protocol used in our XEPs, *because* of the neutrality stance on this point.
pep.I disagree on why we had that discussion, but that's another story
ralphmWell, it was had, and we had an opinion.
ralphmAnd to be clear Dave did raise that discussion to its fullest because of that specific reason.
pep.I still disagree, and that's a discussion we can have later if you want. That does relate to that so-called neutrality certainly
pep.And who we're making/accepting protocols for
pep.I note that nobody answered "Would we accept a spec that encourages tracking users for example" :)
GuusDid that issue come up in the last ~20 years?
MattJNobody has proposed such a spec, so discussing it is helpful how?
Guusand if it did, don't you think we can handle those on a case-by-case basis?
MattJThere are many thought experiments we could run along similar lines, but I don't see the benefit
MattJEven if we made a decision now (before any such spec has been submitted), what's to say our stance couldn't change?
ralphmwe would, as the IETF does. The statement refenced by pep. was accepted by the IAB, not the IETF itself.
MattJWould we preemptively accept such a spec by saying "yes" to your question now?
pep.Guus, I don't, actually. That's a pretty obvious example of what people might be uneasy about, but there are plenty of other exapmles, more subtle
ralphm(case by case, I mean)
pep.ralphm, surely it's "only" the IAB (and yeah that's another excuse I hear often), but it still has quite a lot of weight
ralphmIt all depends on what "tracking users" means in the context of that hypothetical specification.
ralphmpep., and that weight is felt in our community too. I don't see us actively opposing that.
pep.I see us talking about things that are opposite to this. What does « neutrality » even mean in the context of this hypothetical spec?
pep."yeah well we're neutral we'll accept your spec, sure"
pep.A more concrete example maybe. I read that two weeks ago board voted to support/sponsor an event on message encryption or something,
pep.Great, I would probably have agreed as well (even though I now think it might have been a SCAM matter? anyway). But why?
pep.Why do we care about message encryption
pep.I have my answers obviously, and they are political
pep.(I don't even know what neutral would mean here tbh)
ralphmI saw a no-objection mention in minutes. It covers messaging, a space the XSF seems to live in. Why is that a neutrality issue?
pep.Ok so, whatever comes in we'll just accept? Is that what that means to you?
pep.What if tomorrow encrypting things becomes illegal in most of the world? (note that it already is in some countries)
pep.Is the XSF explicitely going to support evil people wanting to encrypt messages
ralphmIn the context of the earlier discussion on Signal, MLS has come up several times. It makes sense to me to be involved with topics like that, so that if people want to do encryption of message, there's a common way that also works for XMPP.
ZashSecure Messaging Summit, that's happening today and tomorrow?
ralphmNo only good-doers.
pep.ralphm, but they'd be against the law!!
ralphmThere's no 'the law'.
pep.Isn't there. Not that I care much about it either and I'd explicitely support encryption even if it was illegal in most countries.
pep.(Because it is illegal in some countries already, as mentioned above.)
GuusCan we come to some kind of conclusion please?
ralphmI don't think this discussion is leading in a particular direction. pep.: if you really want to change something here, you need to make it more concrete.
pep.I say we drop the neutral stance, because it doesn't actually mean anything (or at least I'd expect some document defining what this means to us), and we aren't neutral anyway (according to my definition).
vanitasvitaeOr rather than dropping it, define explicitly in what ways the XSF is neutral and in which not?
pep.Might as well put that in the mission statement or similar document and say how we'll do things and how we won't do things. Instead of clinging to that notion of neutrality
pep.And there maybe we'll realize it's not that easy
vanitasvitaeAs in "the xsf is neutral in regards to implementations, but will protect end-users™"
pep.Fortunately(?) we don't have the same trafic as the IETF
GuusI do not like the optics of removing a 'neutral' stance - even without defining it. "ah, the XSF is no longer neutral" That will not have any positive effects.
ralphmpep. if you want to draft a change like that, we can discuss it more concretely. IMO
ralphmand what Guus says
Guusas to defining things - I'm not seeing the point, but I'm happy to discuss a concrete suggestion.
pep.Who are we trying to please when we're afraid that the XSF is "no longer neutral"
pep.(I bet that's exactly those I don't really care about)
ralphmCutting it short here. Let's pick this up for a next meeting.
ralphmAlso the AOB will move to next week.
ralphm3. Date of Next
pep.Sorry Ge0rG I took all your time :p
Ge0rGpep.: wasn't important anyway :
GuusI think we need better time management than this
Ge0rGit was just that I've recently impersonated the XSF and offered our resources for free.
Guusalso, can we please have agendas, as we agreed earlier?
ralphmGuus: I'm sorry.
pep.fwiw, I'm not so fond of defining something I have no stakes in. This neutrality thing is not on the website yet and I'm not going to try to promote it for you
pep.I'd just like that we drop the ball internally once and for all
ralphmunfortunately, you seem to be the only one so far that believes there's a ball to drop and we have a problem. Again, make a concrete proposal, and we will discuss it.
SyndaceTo me it seemed like the board members agreed that the XSF is not 100% neutral in all matters, so I agree with ralphm that the ball is already dropped at least among Board members?
pep.I'm not the one claiming that we are neutral
pep.Syndace, might as well drop the word then
MattJNeither is anyone else, to such an extent as you seem to believe?
Holgerpep.: Isn't that a good topic for a broader mailing list discussion? I think I'd personally disagree with your goal (sorry) but I do get your point, and think your examples weren't bad to clarify it (i.e. I don't agree with your point being vague). I'd see value in clarifying these points.
pep.Can you rephrase
MattJI see several examples of different kinds of neutrality that have been discussed in the past year, they are not all the same thing, and we don't have a single "neutrality" stance
pep.MattJ, right, so that's even more confusing
MattJ1) implementation neutrality, which as I said earlier, is the thing that was asked about in the members survey
MattJ2) licensing neutrality, which was heavily discussed to death during the OMEMO debate
MattJ3) political neutrality, in which some non-tech issues were recently discussed at board meetings, and what action the XSF should take, if any
ralphm1) and 2) are explicitly encoded in our Mission and in XEP-0001
MattJA single person can have different views on each of these three "neutralities", and still be a member of the XSF
ralphmFor 3, if we can't get consensus in Board, we tend to ask our membership and/or wider community.
pep.2) isn't about "neutrality", it's about being permissive, not about allowing any kind of license, right
pep.See how that's also confusing
ralphm2) definitely ties into neutrality in that we want *everyone* to be able to implement our protocols. Most of the OMEMO debate was exactly about this point.
MattJneutrality in that sense is that we should not exclude people from implementing the protocols we publish
ralphmby applying a limiting license to the protocol itself (Signal), that invalidated that goal
pep.ralphm, I still disagree wrt. the point of the OMEMO debate. I agree it has touched this subject of neutrality but I disagree that was the main purpose
ralphmOf course others can have other angles, but the discussion was kicked off on this point particularly, by dwd
pep.The purpose of the OMEMO debate to me was about saying "Hey if we allow specs to mandate GPL implementations, I don't have off-the-shelf pieces I can use anymore for my non-GPL product". And tbh, I couldn't care less about this specific point
ralphmThat quoted statement is internally inconsistent.
Ge0rGpep.: well, it was about adding a dependency on something that only existed as a GPL implementation
pep.MattJ, so neutrality of implementation still
ralphmNon-GPL product developers would totally ok with implementing MEMO, if the spec would allow for this.
pep.ralphm, how so?
Ge0rGpep.: if there was a permissively-licensed protocol specification, adding it would be neutral.
ralphmOMEMO, I meant from scratch
pep.ralphm, yes and note that I'm not talking about OMEMO in the quote
pep.Because it doesn't matter
ralphmIndeed, we would reject all such protocols
pep.I think you're missing my point. Anyway..
Ge0rGpep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"
pep.Or just ignoring it, dunno
Syndace> Or just ignoring it, dunno
pep.Syndace, I'm genuinely asking :/
ZashMakes more sense to me if you think of it as the protocol and its normative references being incomplete and insufficient to implement the protocol.
ralphmpep. yes, I have a track record on ignoring peoples opinions when they don't match mine, and always shutdown discussions
pep.Ah well, that explains it :P
pep.MattJ, so to me the "neutrality" that's been used around for years is really just about allowing anybody to implement our stuff, nothing less nothing more
pep.It doesn't say anything about what we accept or we don't, who our protocols target etc.
pep.(who we're doing all this for)
Ge0rGthat'd be #2 from the above list, then
ralphmYou raise a good point on not being explicit on who we develop protocols for.
MattJThen why are talking about our "neutrality" stance in the context of sponsoring a secure messaging summit? (which is implementation-agnostic)
ralphmI think that is orthogonal to the neutrality thing.
pep.MattJ, because it does seem all mixed up
MattJClearly you think the "neutrality" thing *does* cover more than just implementation neutrality
pep.Well I don't remember a clear statement anywhere so..
pep.(and no I don't remember that one private survey from 2-3-4 years ago)
ralphmOk, in that case, let's assume that there isn't anything beyond that, until shown otherwise.
pep."Ge0rG> pep.: the important difference is between "there is only a GPL implementation of this" and "there can only ever be a GPL implementation of this"" now seeing this. And as much as I understand the difference, I'm not entirely sure it did matter in the thread. I can quote parts of it if you'd like
Ge0rGpep.: well, it's a complex topic and I'm sure there were misunderstandings both in reading and in writing opinions.
Ge0rGI like the three dimensions of neutrality that MattJ outlined above, and it probably wouldn't hurt to have some sort of Mission Statement Explanation that identifies our position, if any, on each of them
Dele Olajidehas left
Dele Olajidehas joined
pep.I think 1 and 2 are exactly the same
Ge0rGI read #1 as giving money to developers
ralphmNo licensing is not the only possible issue. So are things like patents, copyright (on literal strings like with Signal), trademarks.
ZashIf you s/money/advertising space/ and then look at the software listing pages
theTeddnot to drag this on, but I interpret pep.'s point as being: it's impossible to be universally impartial, so the XSF should state in which directions it aims to be and what what actions it takes to pursue those aims
pep.Anyway.. I still don't like the word "neutral", because most often it's a lie. Being neutral most often just means supporting the status quo. Be it when it comes to licenses (What's our impact in terms of what kind of implementation (licenses)'s got the most users?), politics (who are our direct users in terms of their number of users?), etc.
MattJtheTedd, and as far as I'm concerned, we do, on a case-by-case basis
pep.On what basis, what document should I refer to
MattJI wouldn't oppose some general document that summarizes our stance in certain areas
MattJBut I'm not volunteering to write it, because I see other priorities
MattJMaybe this will get me unelected soon, but: I care relatively little about the XSF as an organization
MattJI think it serves as a decent steward of the protocol, but I think XMPP is bigger than the XSF
ralphmThe XSF is a means, not a goal.
MattJIn terms of the ecosystem, and the directions XMPP needs to go in
pep.Tbh if I didn't care about the XSF as an org I wouldn't be in board right now. It's not exactly going the way I want it (which is why I'm here), it's a huge time sink. If I only care about XMPP I wouldn't bother with the XSF
pep.Tbh if I didn't care about the XSF as an org I wouldn't be in board right now. It's not exactly going the way I want it (which is why I'm here), it's a huge time sink. If I only cared about XMPP I wouldn't bother with the XSF
theTeddwho should I poke for a website issue?
pep.(also emotional sink, exactly because it's not going the way I want it, and lots of resistance :))
pep.theTedd, issue, or commteam, but ultimately board members and iteam also have commit rights
MattJThe only thing an actual organization is useful for is holding IP (trademark, etc.) and channelling money... and I'm not sure the XSF is excelling at either of these things (though slowly improving)
ralphmpep. What if you never get consensus in your favor?
KevI think the XEP series without an organisation wouldn't work.
MattJKev, many open-source projects don't have an organization to back them
KevAnd I do think the XEP series, for its flaws, is still worthwhile.
MattJand they work just fine
pep.ralphm, I'm probably gonna give up. It's crossed my mind quite a few times. And I'll let you be in piece (finally?) :)
KevMattJ: But they don't generally provide open standards.
pep.I know I'm not the only one with this kind of opinions, but I'm the only one vocal about it
intosiOpen source and open standards are two vastly different domains.
pep.So is free software
theTeddall of those terms have become loaded, so different people understand them to mean different things
pep.theTedd, https://thebaffler.com/salvos/the-meme-hustler I encourage you to read this
pep.it was a good read
ralphmpep. I would hate to see you go. You say there are others, but rough consensus only works if people speak up. I can see that arguing against the 'rest' can be tiresome. On both ends.
ZashtheTedd: It was mentioned elsewhere that https://bitbucket.org/mrtedd/compliance-badges/ has been lost to the gitbucket. Putting those up somewhere else would be nice if it could be arranged.
theTeddpep., it looks long, but maybe later ;)
pep.yeah it is long
theTeddZash, I'm going to update it anyway, so I'll fix it then
theTeddon the website issue: xmpp.org/extensions/ has a broken link in the head -- <script src="/js/extensions-table.js"... should be "/theme/js/extensions-table.js"
pep.If you can PR I'll merge it
pep.(indeed it's borked)
ralphmI agree with Kev on needing an org for standards development. If only for our IPR policy
pep.theTedd, or I can PR if you don't want to do github, that's fine :)
theTeddif you can pep., thanks
Dele Olajidehas left
pep.https://github.com/xsf/xmpp.org/pull/784 somebody to merge?