jdev - 2022-08-14

adx, here is my recommendation: https://docs.modernxmpp.org/client/groupchat/#bookmarks

MattJ: would you want uncencrypted messages sent to you on signal?

or any other encrypted messaging app?

r4v3r23, would you want to be unable to have this present discussion? :)

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.

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.

MattJ: OK so imagine signal wasn't also an SMS app

So, imagine that the basis of your argument existed 🙂

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.

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.

MattJ: that's not my question, and you're not going to convince me

I wanted to know if an OMEMO based encrypted messenger was possible

There has come a new app, those conversation forks are dead end

Still many common features aren't important enough it seema

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.

It just has no advantage and nobody wants that

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.

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

how was the conclusion that <iq>\n\t<foo/>\n</iq> is acceptable reached?

jonas’, nobody could cite a document that says otherwise

for which definition of "acceptable"?

usage in xml streams

in xml streams, or in xmpp xml streams?

xmpp

its obvious that this is valid xml

the question is if xmpp has something that forbids it

well

you can at least not rely on support

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

https://www.rfc-editor.org/rfc/rfc6120#section-8.2.3

the enumeration on page 106--107 ✏

that interpretation seems to be a stretch

why?

the whole document is one level to high

(replying with bad-request would be completely ok in such a case)

That seems more reasonable to me too, but I was told multiple clients send formatted XML in the wild

you are searching in a IQ definition for rules whats allowed in xml streams

thats the stretch

Sam, ah, mixed content and "ignorable whitespace" are two different beasts ✏

lovetox2, well, the rules don't need to be the same for <message/> etc.

No as far as XML is concerned

lovetox2, case in point: all the SASL nonzas

But Sam is interested in the general case

not for one particular stanza

that maybe not clear from his example

in the general case you need to support everything

because, as I said, SASL.

(and XMPP extensibility)

So where does it say "chardata that is just whitespace is okay, anything else bad"? Seems like a major oversight if it's not

Except for sasl and starttls which ban it just in those places, of course

I tried checking the XML specification but can't for the life of me navigate to it on w3.org

Zash, https://www.w3.org/TR/REC-xml/#sec-white-space

I have bookmarks for those :-)

Thanks

#sec-white-space does not say that whitespace is ignorable on the XML layer, it needs to be defined by the application

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.

nav: I was just curious of building a messenger with those properties was possible

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

Sam, everything should be passed through

instead I got comments of why enforced E2EE is stupid

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?

Is it different for message/presence since they can have multiple children?

Sam, that violates the *schema*

which is different from what the XML layer does

Does it? I can't tell that it's banned anywhere according to this

(IQs can also have two children, mind, if exactly one of them is an error) ✏

(or zero children, for type=result)

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.

ah, drops unexpected character data by default

Prosody only cares about child tags

(everywhere)

in the true extensibility spirit of XMPP (ignoring unexpected/unknown stuff)

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

I guess this is fine; no idea really 🤷 https://codeberg.org/mellium/xmpp/pulls/324

r4v3r23: Yes it is possible. See Whatsapp for instance.

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.

nav: >unclear legal status

elaborate

please

techmetx11: https://nextleap.eu/deliverables/deliverables-period1.zip See D3.3 & D3.6, for instance

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

Musiani goes in some more detail in this paper: https://hal.inria.fr/hal-01426845/document

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.

is that still an issue for omemo 0.8?

Normally you would use patents for that kind of thing

jonas’: I don't know. Hence the "unclear" qualifier.☺

But I wouldn't want to be the next Wire.

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?

(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)

Yeah that seems like a baseless fear

if a muc service does that merge multiple presences into one when connecting with different devices

is there a way to break this?

like can i break out of that as a device intentionally, maybe by changing nick or connecting to the muc in a certain way

I don't fully undesrtand what you mean by break yet

what's the goal?

to join a muc with 2 different resources

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.

and not get merged to one

lovetox2, then you need two different nicknames

(or two different accounts, then it'll complain to you about a nickname conflict if you attempt)

i have devica A and device B of the same account

i want to join a muc, with two different resources

then use two different nicknames

or nicknames

ok so the MUC merging depends on the user joining with the same nickname across devices

?

yes

what if i change the nick from one device while im in the MUC

will the MUC somehow tell my other device that my nick has changed?

it depends on the implementation

My mistake. Doesn't matter though, that specifically says "This document is hereby placed in the public domain."

ok so i need to test it

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 ✏

I think current prosody does the "split", because client support for the forced nickname change was questionable

ahhh great info thanks

thats what im seeing

and i thought its a Gajim bug

the splitting thing

I'm not actually sure if you can do server-initated force-rename of someone

sending presence with code 110 and code 210 *may* work

(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)

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...

Worth testing I suppose

Gajim handles that

the Status Code is in the XEP and it says what its for, service changed your nickname

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.

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.

i never heard that there are patents, i doubt that highly

No, their defence is based on copyright and trademark, not patents

Sam: I just linked to all of that, why not get it from the horse's mouth? And the summary is: "legal status unclear".

MattJ: Exactly.

I'm not downloading a random zip file and I don't really want to try and read a long PDF on my phone.

MattJ: Copyright and trademark of what? Who's defense? Sorry, didn't understand that

Sam: that's fine, but then please consider not jumping to conclusions.

The thing where they put their trademark into a protocol constant?

I just asked you to summarize, I didn't jump to any conclusions

Sam: copyright of their implementations and trademark of "Signal" and "Signal protocol"

My apologies, I then misunderstood the meaning of "so this all just seems wrong."

So don't violate the GPL and don't advertise your implementation as using the Signal protocol

The implementations are copyright but licensed GPL, so that seems fine as long as you use that license or write your own impl

You beat me to the next thing :) what Matt just said

No.

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"

That's what got Wire in hot water.

But this is not relevant in the latest version of OMEMO

There us zero chance you are violating a trademark if you gave a constant that says SignalProtocolv1 or whatever somewhere. Zero.

But as you said, doesn't matter anyways.

Sam: they say different, and given that they make $$$ from licensing the protocol, they'll defend it too

nav: hot water how? You still haven't explained what happened to wire?

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

Do either of you have a link to an instance of them doing this? Searching "signal lawsuit" and the like is turning up nothing

Either way, none of this makes recent omemo legally gray area since that constant isn't used.

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.

So, how's your MLS implementations coming along?

What conclusions? Just explain what you're talking about so I don't have to read a ton of papers

> 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.

It's your choice not to inform yourself, but please do not disinform others.

As it stands now, I would be very wary of implementing XEP-0384 in anything that's not GPL licenced.

Note that this also includes MIT + BSD licences as well as closed source.

Which makes that XEP non licence neutral.

Which is not exactly the best state of affairs for an open protocol.

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

I might be able to find some other references later

I see no problem with modern OMEMO

MattJ: How so?

Because what would their argument be?

"See you in court for no reason!!!"

nav, all this has been discussed and considererd on list when the XEP was made

the opinion of the community is that is totally fine to implement under any license

its not enoguth to say "hey maybe look at some links, maybe things are different"

Other projects are also doing the same

if you have concrete objection you need to formulate your argument in full

It's not like OMEMO is the only one

Some in the community (like me) don't care if it's impossible to implement a non-gpl OMEMO client

But it was determined that's not even the case so whatever :)

> the opinion of the community is that is totally fine to implement under any license Was that the result of a legal review?

As in, an actual IP lawyer being consulted?

You pay for a lawyer and find out

Not that that would make things clear (nothing in law ever is), but at least would give some weight to the argument.

the spec is written in a way that you can implement it without looking at copyrighted material

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.

so it follows if you do this, you dont need a lawyer that tells you that you didnt infringe copyright

lovetox: Maybe I'm grossly misreading it, but the spec deals with the signalling rather than the underlying protocol (Axolotl) itself.

of course if you look at copyrighted material, and copy it, then you are on your own

> you dont need a lawyer that tells you that you didnt infringe copyright A lawyer will never tell you that.

> 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?

there is no omemo encryption in general

there is YOUR implementation of it

and yes im unclear of the status of YOUR implementation

could be well that you infringed someones copyright while implementing it

nav, the omemo xep uses https://signal.org/docs/specifications/doubleratchet/ as building block which is an open spec put in the public domain

So you are saying that XEP-0384 is fine, as long as you do not implement it?

as long as you infringe no ones copyright while implementing it

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

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)?

https://signal.org/docs/specifications/doubleratchet/#ipr

Looking at https://signal.org/docs/specifications/doubleratchet/ it says "This document is hereby placed in the public domain."

document ≠ specification

hmm, not sure, given we talk about the document which specifies the protocol

flow: you then are going to have to take my word for it, or get your own lawyer. ☺

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?

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

und I haven't heard of any laywers letter regarding OMEMO in the past

nav, wired has been sued, and as a result changed nothing, there impl still is there, so what should tell us that?

I know about the Wired story

disclaimer: My wired knowledge consists of the link MattJ posted earlier

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

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

That's the difference.

Was Wired GPL ?

yes, according to the blog post

nav, well, you could share the electronic copy of this if it was placed in the public domain, no?

flow: if both the contents and the representation are out of copyright, yes.

Please note: this is analogous to the discussion about "source available" and free and open source.

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"

which is true if your independent implementation is not GPL-derivate compatible licensed

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/

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

I would do the same

*understandable

flow: that is your choice, but in implementing an open protocol, other parties might have other interests at heart.

I am sorry, but I fear I don't get what you are getting at :)

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

The situation here is somewhat analogous to what we've seen in the past with video codecs and such.

I can't comment on that because there haven been multiple situations with codes in the past decades that all are slightly different

maybe not only even slightly different, but even completely different

flow: What I'm getting at was posted hours ago: the legal status of (implementing) OMEMO is unclear.

Someone asked for clarification and I posted relevant references, which apparently some chose not to read but argue about them anyway.

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.

No legal review has taken place, and someone suggested that it is caveat emptor, yet XEP-0384 is silent on that too.

nav, would you be so kind to re-post the references again? I have to admit that I did not read the complete backlog

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

nav: XEP-0384 builds on top of public domain specifications published by Signal, it doesn't use anything they assert copyright over

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

flow: https://logs.xmpp.org/jdev/2022-08-14?p=h#2022-08-14-ceb48d4a212ed1ea

flow: that's called reverse engineering. In theory you can (and I've done it, in a different domain). In practice, well…

…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".

In copyright matters the general term is a "clean-room implementation"

nav, where exactly is (what?) reverse engineering? ✏

What MattJ says

It's a well established practice for avoiding copyright issues

Specifically, clean-room implementation is one form of reverse engineering, and what I was actually referring to. Thanks for the remark.

ok I have multiple large PDF files in front of me

Note that you might still get sued though.

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

I am not sure why we are talking about reverse engineering now

given that all of omemo can be implemented by just looking at open standards

flow: did we not already discuss the Wire and Whatsapp *licensing* cases?

yeah, but those where about the license of *software*, not of an standard

It feels like you are not properly separating software licensing concerns and standard ones

flow: already discussed, read the history log.

I probably won't, but if you can give me a brief summary I'll read it

Wire got accused of looking at OWS' libsignal source code to implement theirs.

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)

According to Wire, you cannot implement Axolotl just be reading the "specification".

I think you are also not considering the timeline here

yes that was their opinion in 2015 or even earlier

Which is in itself a well-known trick from patent writing.

this is not the case anymore

the double ratched specification only came end 2016

Always leave out the one crucial detail.

these days you can implement omemo without looking at libsignal ✏

which is exactly what i wrote half an our ago

I think multiple people stated by now that implementing omemo by just using the available open standards is not an issue

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?

nav, this gets old now

> these days you can implement omemo without looking at libsignal Where should I look instead?

your arguments is pointing to links, and if we bring a counter argument then you point again to the link

either you take part in the discussion or not

lovetox: I know it gets old. And I'm surprised at the reaction here.

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?

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)

nav, start with xep384, everything else you need to know to implement is linked by that xep ✏

MattJ, +1

(only that xep384 probably also references other open specifications, besides the one published by Signal, like the ones published by the XSF ;))

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.

And now for a question, does the XSF have any sort of legal counsel at all?

why should a XEP tell you how software licensing works?

flow: do you know what an essential patent is?

nav: you think "the underlying technology might have IP restrictions" is true? We basically just established that it isn't true.

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.

nav, I don't

Link Mauve: that's a different albeit related situation. There might indeed be other XEPs where the underlying technology is not freely available.

Ideally there is a policy that XEPs have to be only based on other open standards that are available free of charge

nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.

There might exist implementations under a different license too.

I’ve never looked at OMEMO, so I can’t comment on that part.

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.

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

So... I'm not really sure what more there is to say

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.

I am also not sure where to put the "essential patent" pice in the omemo picture

I just wondered if it would be a good idea to prominently mark XEPs that are only based on open standards as such

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.

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.

…that's why I mentioned essential patents, to introduce that aspect of the discussion.

Also, I had somehow assumed that to be the case, as is already the case in other areas of technology, such as ISO standards.

That's why I found XEP-0384 a bit of an outlier.

What makes it an outlier?

But as Link Mauve pointed out, this probably (likely?) affects other XEPs as well.

nav, did I?

I only mentioned that there are XMPP libraries licensed under a GPL license.

Link Mauve: > nav, I didn’t say they weren’t freely available, just that there exists implementations under a given license.

Yup, that's it.

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)

Speaking of which, the new https://xmpp.org/software/libraries/ doesn’t mention the license of a particular library, this should probably be fixed.

MattJ: The fact that I was aware of the shenanigans concerning its licensing.

What shenanigans?

Link Mauve: 👍

nav, but there are no shenanigans, that’s the conclusion of the past hour of discussion.

Link Mauve: that's the conclusion only because seemingly nobody bothered to read the references that I posted.

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”

Link Mauve: I never mentioned patents in the context of Axolotl.

What is the context of this discussion, if not Axolotl?

And forgive me for giving more credibility to a CNRS researcher than to the main interested party and a blog post.

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.

OK. I missed that then.

no probs

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?

I'm asking because, again, when working to ISO standards one is reasonably clear of the conditions under which a standard may be implemented.

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.

And I, perhaps foolishly, assumed it would be the same with XEPs.

The XSF's IPR policy is on the site

MattJ: Thanks. I just found it via Google.

nav, I actually look at the PDFs, but couldn't find anything related

related to the discussion

but then again, those XEPs are big

and, tbh, just because it is a academic publication shouldn't give it automatically credability

even if it was peer reviewed, which I am not sure if this even was

Yep. Its basically the same coclusion we arrived half an hour ago. Read the XEP, look for an implementation that fit your license.

If a dev doesnt look at licenses that his thing

And the XEP has nothing to do with the libsignal implementation. Its an open standard

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

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.

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.

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.

nav, yes there is a whole D3.3DraftDecentralizedCaseStudis.pdf, which includes the § 3.3 I menionted

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.

but the D3.3 PDF does not really talk about license, leave alone license issues wrt to the omemo specification

i read 3.6 its just a summary of the history of the signal protocol and everything we talked about

and the D3.6 PDF essentially just states that libsignal is GPL licensed

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

so nothing so far in the PDFs convinces me that there are any license issues with omemo

nav, yeah, I assumed that we have something like this in our IPR, but wasn't sure :)

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.

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

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?

I think there is such a proces, but we just don't call a laywer each time

"I think there is such a process" doesn't sound terribly confidence-inspiring. 🤪 Surely it's documented somewhere?

nav: Probably around the time the XEP got posted. It should be in the bottom of the page in versions.

First revision you mean?

Yeah

So around then: 2015-10-25

👍

well, you can't really compare the XSF with the ISO

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?

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).

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)

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.

MattJ: XSF IPR § 1.2 (https://xmpp.org/about/xsf/ipr-policy/#intro-role) on the part of OWS is what I would expect.

There is no such statement from them, is there?

They explicitly decalare their specs as public domain, so yes

Where that? Here? https://signal.org/docs/specifications/doubleratchet/#ipr

Exactly

So no, sorry.

?

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.

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. "

The document is the specification

Nope. The document is the document.

And the specification is...?

Why would they (OWS) do that is not for me to guess, and I see how it's open to misinterpretation.

I don't see any potential for misinterpretation. A specification is a type of document. I see no problem with saying "this document"

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.

Or we can just read all the sources that have been given to the contrary here

Including wire mixinp up licenses for the implementation

Yes, you can do whatever you want. Feel entirely free.

*not* the specification. As far as i understood that example that was brought up

So finally was messing with xml stream acknowledged?

I remember it pretty good

?

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?