XSF Discussion - 2020-01-21

Are there public records of OWS pursuing legal action against people using libsignal while not adhering to GPL?

Guus: like https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

(technically, not using libsignal while not adhering to GPL though)

(but re-implementing libsignal while not adheering to GPL)

moar! moar!

Guus, context?

I don't want to say stuff about OWS enforcing GPL without proof to back it up.

Guus, then I think that @wireapp thing is what you need

because assuming or suggesting that OWS is not enforing GPL on direct uses of libsignal is definitely not a good idea either way ✏

that they enforce GPL on derivates or users of libsignal should be the default

the main issue here is that they also enforce GPL on reimplementations, which is what @wireapp shows

or am I totally on the wrong track right now?

No, you're not. I'd just like to see more documented cases.

ok

Thanks!

(I don’t have any more, tho)

Has anybody actually tried a clean-room implementation?

is that what wire tried to do?

Of interest: https://moderncrypto.org/mail-archive/messaging/2016/002275.html

Ge0rG, and for what it is worth, Wire sued OWS, and then there was a settlement. Also, Wire's stuff is still GPL3.

pep., according to https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7, I think so

> Like everyone else in the cryptographic community, our team obviously had access to OWS’ GPL’d Java reference implementation online.

well, ok, maybe not

the article does mention the gpl'd code yeah

The thread I linked also has Moxie in it somewhere.

Thanks.

In any case, you'll see that SilentCircle pulled libsalamander in favour of libzina.

The reply from Moxie in that thread basically says they only care about the trademark

(which is part of the evil constants)

Ah

Fun

But even GPL doesn't save you from that

I wonder if that was all planned out from the beginning or just a lucky coincidence.

The protocol includes constants with 'signal' in them, no? It seems to me that OWS considers any protocol-compatible implementation to be a derivative work.

ralphm, WhisperSystems even

ah, nice

of course XMPP has literal occurances of 'jabber', but at least there's an arrangement with the XSF for this.

ralphm, As I recall, that caused a lot of wrangling in the IETF.

ralphm, Not least the name of the protocol changed.

dwd: I thought that XMPP was actually proposed by Jabber, Inc.

nah, i think the ietf concluded that having a protocol and a trademark was not going to work. smart. I am looking at you, w3c+webrtc...

I don't know where the name came from. I do know that the IETF got very concerned about a protocol name being trademarked.

dwd: interestingly, the first draft (https://tools.ietf.org/html/draft-ietf-xmpp-core-00) had this notice: 1.4 Intellectual Property Notice This document is in full compliance with all provisions of Section 10 of RFC 2026. Parts of this specification use the term "jabber" for identifying namespaces and other protocol syntax. Jabber[tm] is a registered trademark of Jabber, Inc. Jabber, Inc. grants permission to the IETF for use of the Jabber trademark in association with this specification and its successors, if any.

Dear Editors. I'm sorry-not-sorry.

I tried to look at the old xmppwg mail archives, but it seems that our mailman doesn't show them (anymore).

MattJ, are they still there?

Our mailman?

(they used to be here: https://mail.jabber.org/pipermail/xmppwg/)

Guus, You might care about this: https://github.com/xsf/xeps/pull/883

I didn't know this

Thanks Dave 🙂

What has Dave done now?

Be a gentleman.

Zash, yeah, the xmppwg mailinglist (first WG) was initially hosted by the JSF.

Another two ProtoXEPs. Given my current success rate, I'm not sure why I bother, but still.

dwd: thanks, that's an item off my to-do :)

dwd: for what it's worth my plan was to spec two fields, a universal "plain" search and an "advanced" variant that is implementation/deployment-specific but includes a slot for the server to provide some (localized) help text that clients could display to users

See the popup when you enter the search box in Slack for example

{jabber❌data}desc ?

with the emoji?

Yes

Interestingly around that time also a lot of e2e discussion (for RFC 3923)

Possible

ralphm: IIRC peter once said that he wasn't aware of any implementations of 3923. It was more of a mandated checkbox because of the IMPS-requirements

It was, but it still had a lot of discussion

dwd: small typo in PR 883, reviewed.

Ah, crap. Yep.

https://xmpp.org/about/xsf/mission Is it possible to get context around this? I've been skimming through the member list without success. Added in a71bc1df7a100a72b9e840c2a7308668fa385e32 on Sun Jul 26 23:41:33 2015 -0700 by Adam Brault ✏

Reading old threads makes me feel like we're a broken record

https://mail.jabber.org/pipermail/members/2014-November/007920.html "Abstaining on XSF ballots"

Ah, there's https://mail.jabber.org/pipermail/members/2014-November/007932.html "Goals for the XSF board". Not sure if that's what lead to the mission statement, but that's probably worth reading anyway

pep., in 2015 the entire website was redone

The origin of this page is in 2007.

I see

I.e. that's how far I've traced it back for now.

Because I think it is even older, and Jan 2007 was an earlier website overhaul

I.e. this is when our site moved to xmpp.org

pep., this page used to be on jabber.org, and virtually hasn't changed since the fall of 2003.

http://web.archive.org/web/20031011082930/http://www.jabber.org/jsf/

Apart from the typo in the current version, it still pretty much captures what I think we should be doing.

Thanks for digging it up

If you want drama, that's the best era, I think.

not looking for drama no

> ProtoXEP: Inbox

interesting!

Yeah, I got around to it eventually, and knocked out the full text thing while I was in the right place. Thanks for processing those.

dwd, you’re also not in council@ at the moment, so I tell you here: my calendar lied to me and I’ll be able to chair tomorrow

Excellent.

does anyone do extended stanza adressing over s2s? If not, wouldn't it be a nice way to reduce the bandwith? I assume for example there to be some presence dupes over s2s links

I don't think Openfire does that, flow .

Interesting thought though

IIRC the main issue I ran into was needing to disc#info remote servers and preferably caching the response, and Prosody barelay had PEP-specific bits for that at the time.

Is bandwidth that much of an issue for servers tho?

Over STANAG maybe

And you get more benefits the fewer and larger servers there are. Not sure that's the direction I want to focus on.

Zash, I see your point. I just like to theorize about potential optimizations. I also think that this could easily lead to stanza-size issues

flow: I'm partial for XEP-0288 myself. Reducing the number of s2s connections reduces memory usage and CPU-intensive TLS handshakes.

Zash, why only "partial"?

flow: s/I'm partial for/I like/

Something something preference for

There's some obvious irony or sarcasm that I'm not getting in the fulltext protoxep

Is it just to start a discussion?

pep.: have you been here for yesterday's discussion with Guus?

I was. Have you read the document?

Yes

It's very dave

k

It serves the purpose.

Guus, what is the purpose?

Just registering a standard name for the field to abandon it later because actually using it in a standard at some point would cause incompatibilites?

Yes, no.

At least have a standard name with a defined set of functionality.

I am missing the defined set of functionality in that ProtoXEP...

I mostly read: don't use me because my behavior is undefined

Maybe a defined field with undefined behaviour is better than an undefined field with undefined behaviour

Does it help with interoperability? Or is it even less useful than {xmpp:private.foo/mam-fulltext}fulltext? (as behaviour is undefined anyway)

I'd like to expand it as I said yesterday, so it would have two fields

One defined, one undefined

well having a defined undefined field is certainly better than everyone using the undefined 'withtext'

The name of that field is obviously bad (no namespace), but how is as single defined undefined field better?

it allows clients to implement search

server side search (obviously)

with undefined behaviour

yes

That's evidently good enough for some people/use-cases

to me that's good enough

k

i mean in practice it won’t be that undefined

Well yes, the XEP says so :P

i mean it says you can return nothing but then you have to buy everyone beer; which is like a total logistical nightmare

In practice it'll be somewhat undefined rules floating around

i don’t think anyone would go through with that

Which is a nightmare for the external dev

It's probably fine as long as you only send [A-Za-z0-9]+ 😉

and don't send the words NOT, AND or OR

even then it's unclear if it only searches in body or the full XML

so you might see very unexpected results

And content doesn't only sit in body either

Yeah, that too

I can't imagine a proper UX for that

at least nothing that could compete with Dino search UX 😉