-
Link Mauve
adx, here is my recommendation: https://docs.modernxmpp.org/client/groupchat/#bookmarks
-
r4v3r23
MattJ: would you want uncencrypted messages sent to you on signal?
-
r4v3r23
or any other encrypted messaging app?
-
Link Mauve
r4v3r23, would you want to be unable to have this present discussion? :)
-
MattJ
r4v3r23: it's not about what is sent to you - you can't control what people send you. It's about what to do after you receive something. There is no security gained by ignoring.
-
MattJ
r4v3r23: even Signal does this - their Android app at least supports receiving unencrypted SMS messages. They don't ignore them, and they even let you reply unencrypted.
-
r4v3r23
MattJ: OK so imagine signal wasn't also an SMS app
-
MattJ
So, imagine that the basis of your argument existed 🙂
-
MattJ
The fact is, it's often helpful to be able to communicate with unencrypted/legacy users. It's how you could lead them to upgrade, for example.
-
MattJ
That's undoubtedly why Signal does it. Most people don't have Signal, so by supporting SMS they allow people to seamlessly upgrade when both parties support it.
-
r4v3r23
MattJ: that's not my question, and you're not going to convince me
-
r4v3r23
I wanted to know if an OMEMO based encrypted messenger was possible
-
Mx2
There has come a new app, those conversation forks are dead end
-
Mx2
Still many common features aren't important enough it seema
-
MattJ
r4v3r23: Conversations already marks unencrypted messages with a strong red background. It would probably be no more than a few lines of code to hide those messages completely.
-
MattJ
It just has no advantage and nobody wants that
-
nav
r4v3r23: it might be a more productive use of your time if you stop to think about what other people are telling you rather than try to convince them that you have a good, practical and feasible idea. But to summarise the answer already given to your specific question, yes an end to end encrypted messaging application is possible (why specifically OMEMO though?) if you have very tight control over every aspect of the system and its environment. What you are presenting smells strongly of an XY problem though.
-
Sam
So I was asking about chardata the other day and apparently was wrong that it wasn't allowed inside the top level of stanzas. Eg. <iq>\n\t<foo/>\n</iq> is acceptable. However, if that's allowed, wouldn't <iq>somemixedcontent<foo/></iq> also be allowed? That seems more of a problem
-
jonas’
how was the conclusion that <iq>\n\t<foo/>\n</iq> is acceptable reached?
-
lovetox2
jonas’, nobody could cite a document that says otherwise
-
jonas’
for which definition of "acceptable"?
-
lovetox2
usage in xml streams
-
jonas’
in xml streams, or in xmpp xml streams?
-
lovetox2
xmpp
-
lovetox2
its obvious that this is valid xml
-
lovetox2
the question is if xmpp has something that forbids it
-
jonas’
well
-
jonas’
you can at least not rely on support
-
jonas’
for IQ stanzas, in particular, RFC 6120 describes exactly what's in an IQ stanza, and anything beyond that is not necessarily supported by all entities
-
jonas’
https://www.rfc-editor.org/rfc/rfc6120#section-8.2.3
-
jonas’
the enumeration on page 106✎ -
jonas’
the enumeration on page 106--107 ✏
-
lovetox2
that interpretation seems to be a stretch
-
jonas’
why?
-
lovetox2
the whole document is one level to high
-
jonas’
(replying with bad-request would be completely ok in such a case)
-
Sam
That seems more reasonable to me too, but I was told multiple clients send formatted XML in the wild
-
lovetox2
you are searching in a IQ definition for rules whats allowed in xml streams
-
lovetox2
thats the stretch
-
jonas’
Sam, ah, mixed content and "ignorable whitespace" are two different beast✎ -
jonas’
Sam, ah, mixed content and "ignorable whitespace" are two different beasts ✏
-
jonas’
lovetox2, well, the rules don't need to be the same for <message/> etc.
-
Sam
No as far as XML is concerned
-
jonas’
lovetox2, case in point: all the SASL nonzas
-
lovetox2
But Sam is interested in the general case
-
lovetox2
not for one particular stanza
-
lovetox2
that maybe not clear from his example
-
jonas’
in the general case you need to support everything
-
jonas’
because, as I said, SASL.
-
jonas’
(and XMPP extensibility)
-
Sam
So where does it say "chardata that is just whitespace is okay, anything else bad"? Seems like a major oversight if it's not
-
Sam
Except for sasl and starttls which ban it just in those places, of course
-
Zash
I tried checking the XML specification but can't for the life of me navigate to it on w3.org
-
jonas’
Zash, https://www.w3.org/TR/REC-xml/#sec-white-space
-
jonas’
I have bookmarks for those :-)
-
Zash
Thanks
-
jonas’
#sec-white-space does not say that whitespace is ignorable on the XML layer, it needs to be defined by the application
-
Sam
oh, so it is different. Now I have no idea what to do. I'll elide the rant about how there's apparently a magical attribute that nobody knows about or supports because XML can't decide if it's a document language or a data serialization format and is therefore bad at both.
-
r4v3r23
nav: I was just curious of building a messenger with those properties was possible
-
Sam
I guess this really does mean that space should be passed through and other chardata should result in an error though? I really can't tell
-
jonas’
Sam, everything should be passed through
-
r4v3r23
instead I got comments of why enforced E2EE is stupid
-
Sam
jonas’: so if someone sends <iq>foo<bar/></iq> what does that even mean? IQs are only supposed to have one child, does this violate that rule?
-
Sam
Is it different for message/presence since they can have multiple children?
-
jonas’
Sam, that violates the *schema*
-
jonas’
which is different from what the XML layer does
-
jonas’
(IQs can also have two children, mind, if one of them is an error)✎ -
Sam
Does it? I can't tell that it's banned anywhere according to this
-
jonas’
(IQs can also have two children, mind, if exactly one of them is an error) ✏
-
Zash
(or zero children, for type=result)
-
Sam
Sure, doesn't matter though, the question is still valid. I guess the answer is to go figure out what other things are doing because this is underspecified? I really have no idea.
- jonas’ goes to check how aioxmpp handles that
-
jonas’
ah, drops unexpected character data by default
-
Zash
Prosody only cares about child tags
-
jonas’
(everywhere)
-
jonas’
in the true extensibility spirit of XMPP (ignoring unexpected/unknown stuff)
-
Sam
I guess that's fine; feels weird to allow sending it in the first place, but I can't think how it could be abused
-
Sam
I guess this is fine; no idea really 🤷 https://codeberg.org/mellium/xmpp/pulls/324
-
nav
r4v3r23: Yes it is possible. See Whatsapp for instance.
-
nav
As for the XMPP network, it might happen that one day some form of support for end to end encryption will be required (probably not OMEMO, given its unclear legal status), in the same form that RFC7590 already mandates support for TLS. It still doesn't mean that people *have* to use it. See also HTTP vs HTTPS.
-
techmetx11
nav: >unclear legal status
-
techmetx11
elaborate
-
techmetx11
please
-
nav
techmetx11: https://nextleap.eu/deliverables/deliverables-period1.zip See D3.3 & D3.6, for instance
-
nav
For some reason 3.6 is not in the zip. Here's an online copy: https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS
-
nav
Musiani goes in some more detail in this paper: https://hal.inria.fr/hal-01426845/document
-
nav
The long and the short of it is that OMEMO (or rather the protocol called Axolotl) is not a standard, and apparently quite intentionally so, as that allows the IP rights holder to exercise control over it, and monetise it.
-
jonas’
is that still an issue for omemo 0.8?
-
nav
Normally you would use patents for that kind of thing
-
nav
jonas’: I don't know. Hence the "unclear" qualifier.☺
-
nav
But I wouldn't want to be the next Wire.
-
Sam
I don't think any of that is true; the original axolotl spec was published using creative commons IIRC, the implementation everyone relied on was GPL, and newer OMEMO versions aren't based on it anyways and are an XSF spec. That all seems pretty clear, unless I'm wrong about that?
-
Sam
(I did not download the zip file, so maybe it tells me why I'm wrong, but that seems unsafe so apologies if it's in whatever that is somewhere)
-
MSavoritias (fae,ve)
Yeah that seems like a baseless fear
-
lovetox2
if a muc service does that merge multiple presences into one when connecting with different devices
-
lovetox2
is there a way to break this?
-
lovetox2
like can i break out of that as a device intentionally, maybe by changing nick or connecting to the muc in a certain way
-
jonas’
I don't fully undesrtand what you mean by break yet
-
jonas’
what's the goal?
-
lovetox2
to join a muc with 2 different resources
-
nav
Sam: > newer OMEMO versions aren't based on it anyways I just checked https://xmpp.org/extensions/xep-0384.htm and it refers me straight onto https://xmpp.org/extensions/xep-0384.html#nt-idm45811904665168 for the actual implementation.
-
lovetox2
and not get merged to one
-
jonas’
lovetox2, then you need two different nicknames
-
jonas’
(or two different accounts, then it'll complain to you about a nickname conflict if you attempt)
-
lovetox2
i have devica A and device B of the same account
-
lovetox2
i want to join a muc, with two different resources
-
jonas’
then use two different nicknames
-
lovetox2
or nicknames
-
lovetox2
ok so the MUC merging depends on the user joining with the same nickname across devices
-
lovetox2
?
-
jonas’
yes
-
lovetox2
what if i change the nick from one device while im in the MUC
-
lovetox2
will the MUC somehow tell my other device that my nick has changed?
-
jonas’
it depends on the implementation
-
Sam
My mistake. Doesn't matter though, that specifically says "This document is hereby placed in the public domain."
-
lovetox2
ok so i need to test it
-
jonas’
in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device✎ -
jonas’
in theory, an implementation has the folowing choices: - Reject the change (I think that's what old prosody did) - "split" the nickname: the changing device will see a successful nickname change *and* a join for the old nickname (for the other device), everyone else will see a join of the new nickname. - Force-change the nickname of the other device(s) alongside the one initiating the nick change ✏
-
jonas’
I think current prosody does the "split", because client support for the forced nickname change was questionable
-
lovetox2
ahhh great info thanks
-
lovetox2
thats what im seeing
-
lovetox2
and i thought its a Gajim bug
-
lovetox2
the splitting thing
-
Zash
I'm not actually sure if you can do server-initated force-rename of someone
-
jonas’
sending presence with code 110 and code 210 *may* work
-
jonas’
(which is how servers can override your nickname choices, and I suppose client implementations need code for handling that anyway and as most MUC operations are asynchronous (presence instead of IQ, so not tracked), I *suppose* that it'd just work)
-
Zash
While that may carry the appropriate semantics, I don't remember seeing any text about that case and when some clients had trouble with the server rewriting their nickname on join...
-
Zash
Worth testing I suppose
-
lovetox
Gajim handles that
-
lovetox
the Status Code is in the XEP and it says what its for, service changed your nickname
-
nav
Sam: the papers I linked to explain why the (non-)specification and one implementation being publicly available don't matter, as Wire found out much to their disadvantage (incidentally, please note that the licensing status of the document in which it's written does not convey any rights over the specification itself). Have the XSF commissioned a legal review? If not, the Nextleap project (https://cis.cnrs.fr/nextleap/) is as close as it gets that I'm aware of.
-
Sam
nav: What happened to wire? Can you summarize the documents? As far as I know there is no patent on the algorithm and the spec and implementation are licensed in an open way, so this all just seems wrong.
-
lovetox
i never heard that there are patents, i doubt that highly
-
MattJ
No, their defence is based on copyright and trademark, not patents
-
nav
Sam: I just linked to all of that, why not get it from the horse's mouth? And the summary is: "legal status unclear".
-
nav
MattJ: Exactly.
-
Sam
I'm not downloading a random zip file and I don't really want to try and read a long PDF on my phone.
-
Sam
MattJ: Copyright and trademark of what? Who's defense? Sorry, didn't understand that
-
nav
Sam: that's fine, but then please consider not jumping to conclusions.
-
Zash
The thing where they put their trademark into a protocol constant?
-
Sam
I just asked you to summarize, I didn't jump to any conclusions
-
MattJ
Sam: copyright of their implementations and trademark of "Signal" and "Signal protocol"
-
nav
My apologies, I then misunderstood the meaning of "so this all just seems wrong."
-
MattJ
So don't violate the GPL and don't advertise your implementation as using the Signal protocol
-
Sam
The implementations are copyright but licensed GPL, so that seems fine as long as you use that license or write your own impl
-
Sam
You beat me to the next thing :) what Matt just said
-
nav
No.
-
MattJ
There was an issue that even if you create your own implementation from scratch, there are some constants (some say intentionally) embedded in the protocol that mention "Signal"
-
nav
That's what got Wire in hot water.
-
MattJ
But this is not relevant in the latest version of OMEMO
-
Sam
There us zero chance you are violating a trademark if you gave a constant that says SignalProtocolv1 or whatever somewhere. Zero.
-
Sam
But as you said, doesn't matter anyways.
-
MattJ
Sam: they say different, and given that they make $$$ from licensing the protocol, they'll defend it too
-
Sam
nav: hot water how? You still haven't explained what happened to wire?
-
Sam
MattJ: oh, fair enough, if they're actually suing people over it it doesn't matter if it's technically okay or not, you still don't want to have to defend yourself
-
Sam
Do either of you have a link to an instance of them doing this? Searching "signal lawsuit" and the like is turning up nothing
-
Sam
Either way, none of this makes recent omemo legally gray area since that constant isn't used.
-
nav
Sam: I appreciate that you may not have access to a proper computer right not. If this is of interest to you, may I suggest coming back to it later when you do? You are jumping to pretty unwarranted conclusions.
-
Zash
So, how's your MLS implementations coming along?
-
Sam
What conclusions? Just explain what you're talking about so I don't have to read a ton of papers
-
nav
> What conclusions? > none of this makes recent omemo legally gray area > doesn't matter anyways. > There us zero chance you are violating a trademark > so that seems fine …etc.
-
nav
It's your choice not to inform yourself, but please do not disinform others.
-
nav
As it stands now, I would be very wary of implementing XEP-0384 in anything that's not GPL licenced.
-
nav
Note that this also includes MIT + BSD licences as well as closed source.
-
nav
Which makes that XEP non licence neutral.
-
nav
Which is not exactly the best state of affairs for an open protocol.
-
MattJ
Sam: there's not too much public about it, and I'm likewise not at my computer right now. But here's an overview: https://wireapp.medium.com/axolotl-and-proteus-788519b186a7
-
MattJ
I might be able to find some other references later
-
MattJ
I see no problem with modern OMEMO
-
nav
MattJ: How so?
-
MattJ
Because what would their argument be?
-
Zash
"See you in court for no reason!!!"
-
lovetox
nav, all this has been discussed and considererd on list when the XEP was made
-
lovetox
the opinion of the community is that is totally fine to implement under any license
-
lovetox
its not enoguth to say "hey maybe look at some links, maybe things are different"
-
MattJ
Other projects are also doing the same
-
lovetox
if you have concrete objection you need to formulate your argument in full
-
MattJ
It's not like OMEMO is the only one
-
moparisthebest
Some in the community (like me) don't care if it's impossible to implement a non-gpl OMEMO client
-
moparisthebest
But it was determined that's not even the case so whatever :)
-
nav
> the opinion of the community is that is totally fine to implement under any license Was that the result of a legal review?
-
nav
As in, an actual IP lawyer being consulted?
-
Zash
You pay for a lawyer and find out
-
nav
Not that that would make things clear (nothing in law ever is), but at least would give some weight to the argument.
-
lovetox
the spec is written in a way that you can implement it without looking at copyrighted material
-
nav
Zash: I'm not looking at implementing XEP-0384 in any context at the moment, but if that need ever comes up, I certainly will.
-
lovetox
so it follows if you do this, you dont need a lawyer that tells you that you didnt infringe copyright
-
nav
lovetox: Maybe I'm grossly misreading it, but the spec deals with the signalling rather than the underlying protocol (Axolotl) itself.
-
lovetox
of course if you look at copyrighted material, and copy it, then you are on your own
-
nav
> you dont need a lawyer that tells you that you didnt infringe copyright A lawyer will never tell you that.
-
nav
> of course if you look at copyrighted material, and copy it, then you are on your own So do we agree that the legal status of OMEMO encryption is unclear, then?
-
lovetox
there is no omemo encryption in general
-
lovetox
there is YOUR implementation of it
-
lovetox
and yes im unclear of the status of YOUR implementation
-
lovetox
could be well that you infringed someones copyright while implementing it
-
flow
nav, the omemo xep uses https://signal.org/docs/specifications/doubleratchet/ as building block which is an open spec put in the public domain
-
nav
So you are saying that XEP-0384 is fine, as long as you do not implement it?
-
lovetox
as long as you infringe no ones copyright while implementing it
-
flow
Hence I am not sure how implementing omemo based on the XEP and the provided open specification brings you into any kind of legal trouble
-
nav
flow: That was discussed already. Would you be able to point out where it says that the specification is in "the public domain" (whatever that means for a specification)?
-
flow
https://signal.org/docs/specifications/doubleratchet/#ipr
-
nav
Looking at https://signal.org/docs/specifications/doubleratchet/ it says "This document is hereby placed in the public domain."
-
nav
document ≠ specification
-
flow
hmm, not sure, given we talk about the document which specifies the protocol
-
nav
flow: you then are going to have to take my word for it, or get your own lawyer. ☺
-
nav
At least one company have been sued (Wired) and another chose to pay hefty licensing fees (Whatsapp). Is this really something that should be promoted as an "open" standard?
-
flow
I have a philosophy of not conulting a lawyer for obvious things to me and wait for the cease and desist eltter first, which, worked out fine for me
-
flow
und I haven't heard of any laywers letter regarding OMEMO in the past
-
lovetox
nav, wired has been sued, and as a result changed nothing, there impl still is there, so what should tell us that?
-
flow
I know about the Wired story
-
lovetox
disclaimer: My wired knowledge consists of the link MattJ posted earlier
-
flow
But the Whatsapp things is new to me, and given that there are strong ties between Signal and Whatsapp it appears unlikely or highly likely that there is more to the story
-
nav
flow: I can share with you a copy of Romeo and Juliet just fine, but I cannot share with you my electronic copy of this https://www.penguin.co.uk/books/54572/romeo-and-juliet-by-shakespeare-william/9780141396477
-
nav
That's the difference.
-
moparisthebest
Was Wired GPL ?
-
lovetox
yes, according to the blog post
-
flow
nav, well, you could share the electronic copy of this if it was placed in the public domain, no?
-
nav
flow: if both the contents and the representation are out of copyright, yes.
-
nav
Please note: this is analogous to the discussion about "source available" and free and open source.
-
flow
so in the core of the wire article is this "but if you do an independent implementation, using the published reference documentation and background knowledge from having seen their code online, you can be accused of copyright infringement"
-
flow
which is true if your independent implementation is not GPL-derivate compatible licensed
-
MattJ
There is a third-party write-up here, with comment from Signal: https://www.forbes.com/sites/thomasbrewster/2016/05/11/wire-skype-sued-moxie-marlinspike-extortion/
-
flow
and I totally understand that Moxie would then ask for a license fee, if you don't want to put it under a GPL-derivate compatible license
-
flow
I would do the same
-
flow
*understandable
-
nav
flow: that is your choice, but in implementing an open protocol, other parties might have other interests at heart.
-
flow
I am sorry, but I fear I don't get what you are getting at :)
-
flow
and from reading the latest link MattJ just posted, especially the Update section with Moxie's response, the picture in my head that someone just tried to create a derivate work from the GPL licensed libsignal, whithout obeying the GPL, is just solidifying
-
nav
The situation here is somewhat analogous to what we've seen in the past with video codecs and such.
-
flow
I can't comment on that because there haven been multiple situations with codes in the past decades that all are slightly different
-
flow
maybe not only even slightly different, but even completely different
-
nav
flow: What I'm getting at was posted hours ago: the legal status of (implementing) OMEMO is unclear.
-
nav
Someone asked for clarification and I posted relevant references, which apparently some chose not to read but argue about them anyway.
-
nav
It has been pointed out that the underlying technology is licenced and that the licence is actively and aggressively enforced. XEP-0384 does not mention any of this.
-
nav
No legal review has taken place, and someone suggested that it is caveat emptor, yet XEP-0384 is silent on that too.
-
flow
nav, would you be so kind to re-post the references again? I have to admit that I did not read the complete backlog
-
flow
I am also not sure where it has been pointed out the the underlying technology has been licensed. the "reference" implementation, libsignal, is under an open source license, maybe that is what you mean? but the specification itself is in the public domain
-
MattJ
nav: XEP-0384 builds on top of public domain specifications published by Signal, it doesn't use anything they assert copyright over
-
flow
so if you don't look at the libsignal code, then you can create an implementation and put that implementation under whatever license you like
-
nav
flow: https://logs.xmpp.org/jdev/2022-08-14?p=h#2022-08-14-ceb48d4a212ed1ea
-
nav
flow: that's called reverse engineering. In theory you can (and I've done it, in a different domain). In practice, well…
-
nav
…the first thing you learn when you take a law class: "there is no true or false, no yes or no, no black or white".
-
flow
nav, what exactly is reverse engineering?✎ -
MattJ
In copyright matters the general term is a "clean-room implementation"
-
flow
nav, where exactly is (what?) reverse engineering? ✏
-
nav
What MattJ says
-
MattJ
It's a well established practice for avoiding copyright issues
-
nav
Specifically, clean-room implementation is one form of reverse engineering, and what I was actually referring to. Thanks for the remark.
-
flow
ok I have multiple large PDF files in front of me
-
nav
Note that you might still get sued though.
-
flow
I am not sure, even with the restrictions (D3.3?) you gave me, where it says that the technology that current omemo uses is licensed
-
flow
I am not sure why we are talking about reverse engineering now
-
flow
given that all of omemo can be implemented by just looking at open standards
-
nav
flow: did we not already discuss the Wire and Whatsapp *licensing* cases?
-
flow
yeah, but those where about the license of *software*, not of an standard
-
flow
It feels like you are not properly separating software licensing concerns and standard ones
-
nav
flow: already discussed, read the history log.
-
flow
I probably won't, but if you can give me a brief summary I'll read it
-
nav
Wire got accused of looking at OWS' libsignal source code to implement theirs.
-
nav
Which, it was argued, made theirs a derived work (this is a legal term of art, basically means we still kind of own some of it)
-
nav
According to Wire, you cannot implement Axolotl just be reading the "specification".
-
flow
I think you are also not considering the timeline here
-
lovetox
yes that was their opinion in 2015 or even earlier
-
nav
Which is in itself a well-known trick from patent writing.
-
lovetox
this is not the case anymore
-
flow
the double ratched specification only came end 2016
-
nav
Always leave out the one crucial detail.
-
flow
these days you can implement omemom without looking at libsignal✎ -
flow
these days you can implement omemo without looking at libsignal ✏
-
lovetox
which is exactly what i wrote half an our ago
-
flow
I think multiple people stated by now that implementing omemo by just using the available open standards is not an issue
-
nav
flow: why are you trying to convince me that everything is fine with no evidence whatsoever? In the face of a proprietary protocol which, as has been established, the rights holder actively seeks to enforce licensing upon?
-
lovetox
nav, this gets old now
-
nav
> these days you can implement omemo without looking at libsignal Where should I look instead?
-
lovetox
your arguments is pointing to links, and if we bring a counter argument then you point again to the link
-
lovetox
either you take part in the discussion or not
-
nav
lovetox: I know it gets old. And I'm surprised at the reaction here.
-
flow
nav, start with xep384, everything else is linked by that xep✎ -
lovetox
i wrote half an our ago > the spec is written in a way that you can implement it without looking at copyrighted material now you ask > Where should I look instead?
-
MattJ
So the summary of OMEMO's "legal status" is: 1) XEP-0384 references only public domain specifications published by Signal, 2) GPL implementations can leverage most of libsignal, 3) non-GPL(/compatible) implementations must use a clean-room implementation, 4) Signal themselves haven't sued anyone and deny extortion of Wire (whether this is true does not really matter)
-
flow
nav, start with xep384, everything else you need to know to implement is linked by that xep ✏
-
flow
MattJ, +1
-
flow
(only that xep384 probably also references other open specifications, besides the one published by Signal, like the ones published by the XSF ;))
-
nav
MattJ: And XEP-0384 mentions none of that. I feel that at the very least 2) and 3) should be in there, as well as a note to the effect that the underlying technology might have IP restrictions which might prevent certain uses or implementations.
-
nav
And now for a question, does the XSF have any sort of legal counsel at all?
-
flow
why should a XEP tell you how software licensing works?
-
nav
flow: do you know what an essential patent is?
-
MattJ
nav: you think "the underlying technology might have IP restrictions" is true? We basically just established that it isn't true.
-
Link Mauve
nav, you have GPL implementations of most XEPs, it’d be weird to have to mention in each of them that if your software isn’t compatible with this license you shouldn’t use those implementations.
-
flow
nav, I don't
-
nav
Link Mauve: that's a different albeit related situation. There might indeed be other XEPs where the underlying technology is not freely available.
-
flow
Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge
-
Link Mauve
nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.
-
Link Mauve
There might exist implementations under a different license too.
-
Link Mauve
I’ve never looked at OMEMO, so I can’t comment on that part.
-
nav
flow: the "essential patent" appellative refers to the practice of pledging to allow other parties use of someone else's IP without that someone else forfeiting their rights to that IP, in the context of implementing a standard.
-
MattJ
At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870
-
MattJ
So... I'm not really sure what more there is to say
-
nav
For instance, I have a patent (or other claim) to X, and X is needed to implement RFC98938. I promise that I will not sue anyone who uses X to implement RFC98938.
-
flow
I am also not sure where to put the "essential patent" pice in the omemo picture
-
flow
I just wondered if it would be a good idea to prominently mark XEPs that are only based on open standards as such
-
nav
MattJ: a patent is just one type of IP right. I did not say anything about Axolotl and patents. I was trying to establish flow's level of awareness of the general domain of intellectual property, since I (don't think I) know him personally, that's all.
-
nav
flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge That seems like a good idea to me.
-
nav
…that's why I mentioned essential patents, to introduce that aspect of the discussion.
-
nav
Also, I had somehow assumed that to be the case, as is already the case in other areas of technology, such as ISO standards.
-
nav
That's why I found XEP-0384 a bit of an outlier.
-
MattJ
What makes it an outlier?
-
nav
But as Link Mauve pointed out, this probably (likely?) affects other XEPs as well.
-
Link Mauve
nav, did I?
-
Link Mauve
I only mentioned that there are XMPP libraries licensed under a GPL license.
-
nav
Link Mauve: > nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.
-
nav
Yup, that's it.
-
MattJ
We had a whole drama about it depending on a specific implementation which was GPL, and it got updated due to that (despite some disagreement)
-
Link Mauve
Speaking of which, the new https://xmpp.org/software/libraries/ doesn’t mention the license of a particular library, this should probably be fixed.
-
nav
MattJ: The fact that I was aware of the shenanigans concerning its licensing.
-
MattJ
What shenanigans?
-
nav
Link Mauve: 👍
-
Link Mauve
nav, but there are no shenanigans, that’s the conclusion of the past hour of discussion.
-
nav
Link Mauve: that's the conclusion only because seemingly nobody bothered to read the references that I posted.
-
Link Mauve
nav, it got debunked by Signal according to “19:25:45 MattJ> At least in 2016 they confirmed they had no patents on the protocol, and I fail to find any: https://news.ycombinator.com/item?id=11727870”
-
nav
Link Mauve: I never mentioned patents in the context of Axolotl.
-
MattJ
What is the context of this discussion, if not Axolotl?
-
nav
And forgive me for giving more credibility to a CNRS researcher than to the main interested party and a blog post.
-
nav
MattJ: I never said anything about Axolotl being or not being patented. That's a red herring. What I did mention is that their approach to IP enforcement is *different* from patenting.
-
MattJ
OK. I missed that then.
-
nav
no probs
-
nav
But, to wrap it up: does the XSF have access to legal counsel? Is there any sort of legal review or involvement in the publication of XEPs, or is it completely caveat emptor?
-
nav
I'm asking because, again, when working to ISO standards one is reasonably clear of the conditions under which a standard may be implemented.
-
MattJ
The XSF does not have a permanent legal council for stuff like this. We would seek such counsel if deemed necessary, but there is no indication here that it is necessary.
-
nav
And I, perhaps foolishly, assumed it would be the same with XEPs.
-
MattJ
The XSF's IPR policy is on the site
-
nav
MattJ: Thanks. I just found it via Google.
-
flow
nav, I actually look at the PDFs, but couldn't find anything related
-
flow
related to the discussion
-
flow
but then again, those XEPs are big
-
flow
and, tbh, just because it is a academic publication shouldn't give it automatically credability
-
flow
even if it was peer reviewed, which I am not sure if this even was
-
MSavoritias (fae,ve)
Yep. Its basically the same coclusion we arrived half an hour ago. Read the XEP, look for an implementation that fit your license.
-
MSavoritias (fae,ve)
If a dev doesnt look at licenses that his thing
-
MSavoritias (fae,ve)
And the XEP has nothing to do with the libsignal implementation. Its an open standard
-
flow
for example you mention D3.3 and D3.6. D3.3 is "Problems of peer-to-peer instant messaging: from contact discovery to battery consumption", which does not seem to deal with license or IP issues. And I can't even find a D3.6
-
nav
flow: that must be a different D3.3. This one, of which I do not have access to an offline copy that I can share right now and for which the one online copy I was able to find was inside that ZIP file linked from https://nextleap.eu/deliverables.html is titled "Draft Decentralized Case Studies" (the direct link on that page 404, hence why the need to go to the ZIP). The discussion is on page 14 &ss.
-
nav
D3.6 is indeed missing from the archive but I shared a link above (https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c208ad8b&appId=PPGMS – PDF). Relevant discussion starts on page 16.
-
nav
The authors have also published a number of papers on the subject, some of which are listed here: https://nextleap.eu/publications.html That's a bit heavier reading as you might expect and albeit interesting, probably do not add much to the discussion.
-
flow
nav, yes there is a whole D3.3DraftDecentralizedCaseStudis.pdf, which includes the § 3.3 I menionted
-
Sam
A giant list of papers on various topics indeed does not add anything to the discussion. If you can't even summarize it, and the only evidence you have is one or two papers that mention it in passing (possibly? In at least the one of them I just tried to look at I couldn't find anything related) then this discussion probably isn't going to go anywhere and I'd say the other side has presented a lot more evidence and should probably be trusted more.
-
flow
but the D3.3 PDF does not really talk about license, leave alone license issues wrt to the omemo specification
-
lovetox
i read 3.6 its just a summary of the history of the signal protocol and everything we talked about
-
flow
and the D3.6 PDF essentially just states that libsignal is GPL licensed
-
nav
flow: > Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge https://xmpp.org/about/xsf/ipr-policy/#contrib-approval
-
flow
so nothing so far in the PDFs convinces me that there are any license issues with omemo
-
flow
nav, yeah, I assumed that we have something like this in our IPR, but wasn't sure :)
-
nav
flow: that is clear and the goal is not to convince you. I just hadn't realised that there was no process or resources whatsoever to determine the licensing and availability status of technology underlying XEPs, that's all.
-
MSavoritias (fae,ve)
nav: have you read the mailing list at the time of it being discussed? Because you have been told that there were. Who is the one spreading the "disinformation" as you say here
-
nav
MSavoritias (fae,ve): Nope, though I have been told earlier on that there is none with a legal background that gets consulted in the process of approving XEPs. Do you recall the approximate date when this discussion that you refer to would have taken place in the mailing list?
-
flow
I think there is such a proces, but we just don't call a laywer each time
-
nav
"I think there is such a process" doesn't sound terribly confidence-inspiring. 🤪 Surely it's documented somewhere?
-
MSavoritias (fae,ve)
nav: Probably around the time the XEP got posted. It should be in the bottom of the page in versions.
-
nav
First revision you mean?
-
MSavoritias (fae,ve)
Yeah
-
MSavoritias (fae,ve)
So around then: 2015-10-25
-
nav
👍
-
flow
well, you can't really compare the XSF with the ISO
-
nav
To be clear, personally I don't have an issue with things just being thrown out there without compliance review, especially since we're far from the heydays of XMPP (and the funding that goes with it), but as a suggestion, perhaps a disclaimer to the effect – or at least getting rid of § 3.2 of the intellectual property rights policy (since there is no active enforcement) might be in order?
-
nav
MSavoritias (fae,ve): Thanks. The discussion I found takes place around May 2017 but I found no mention of a legal review and crucially, one person there, a developer, seems to make the fatal mistake of mixing up the rights to the document with the rights to the standard (to be fair, a casual reading of the OWS document does lead one to make that mistake).
-
MattJ
I'm not really sure what you're expecting an alternative would be though. There's no such thing as an exhaustive IPR review (i.e. anyone at any time can claim anyone is infringing, regardless of whatever review has/hasn't been performed)
-
MattJ
I can understand why a standards org that charges for access may undertake IPR reviews on behalf of its members, but that's quite obviously beyond scope of the XSF. The IPR policy details our scope and expectations of contributors.
-
nav
MattJ: XSF IPR § 1.2 (https://xmpp.org/about/xsf/ipr-policy/#intro-role) on the part of OWS is what I would expect.
-
nav
There is no such statement from them, is there?
-
MattJ
They explicitly decalare their specs as public domain, so yes
-
nav
Where that? Here? https://signal.org/docs/specifications/doubleratchet/#ipr
-
MattJ
Exactly
-
nav
So no, sorry.
-
MattJ
?
-
nav
We've been going back in circles and I got the information I wanted hours ago, so it's time to end this increasingly pointless discussion. Once again: "This document is hereby placed in the public domain." does not mean what you think it means. There is a reason why IPR § 1.2 is written the way it's written and the two are in no way equivalent.
-
nav
I have already said this: "this *document" … blah blah … public domain" means you're free to save a copy of that webpage to your hard drive, or post it on your own blog, or print it out, frame it and sell it. It does not give you any rights to the actual specification and most certainly does not mean "that in perpetuity any entity may independently, and without payment or hindrance, create, use, sell, distribute, or dispose of implementations of XMPP and of any XMPP Extension. "
-
MattJ
The document is the specification
-
nav
Nope. The document is the document.
-
MattJ
And the specification is...?
-
nav
Why would they (OWS) do that is not for me to guess, and I see how it's open to misinterpretation.
-
MattJ
I don't see any potential for misinterpretation. A specification is a type of document. I see no problem with saying "this document"
-
nav
MattJ: Really, ask a lawyer friend to explain this to you. I have already tried, and failed, by giving the example of an out of copyright work and a (forget what it's called now, a realisation?) of that work.
-
MSavoritias (fae,ve)
Or we can just read all the sources that have been given to the contrary here
-
MSavoritias (fae,ve)
Including wire mixinp up licenses for the implementation
-
nav
Yes, you can do whatever you want. Feel entirely free.
-
MSavoritias (fae,ve)
*not* the specification. As far as i understood that example that was brought up
-
Mx2
So finally was messing with xml stream acknowledged?
-
Mx2
I remember it pretty good
-
MattJ
?
-
nicoco_
goffi: I have a question about prosody's mod_privilege which you authored I think, I hope here is an OK place to ask. if a component sends a chat message on behalf of another JID, is this chat message supposed to create a MAM entry? After a little playing with it, I *think* it does not. is this the expected behaviour?