More permissive license

[tehnick]

Please consider switching to more permissive license. At least to "LGPLv2.1 or later". BSD-2-Clause or MIT would be even better.

With current license there is almost zero chance that your library will be used in open-source software licensed not under GPL.

[ghost]

Unless there's a compelling case of an of an existing chat system which wants to use libomemo but can't I'd stick with GPL.

[gkdr]

The problem is that OMEMO is designed to work with libsignal-protocol-c, which is GPLv3. Since I link statically, all parts have to be GPLv3, as far as I understand.

If you can tell me a way to somehow double-license it, I'll gladly do it.

[tehnick]

The problem is that OMEMO is designed to work with libsignal-protocol-c, which is GPLv3.

Hmm, I have not noticed this before your comment.

Since I link statically, all parts have to be GPLv3, as far as I understand.

Nope. They should be GPLv3 compatible.

If you can tell me a way to somehow double-license it, I'll gladly do it.

There is no need in double-license: you may choose any GPL compatible license. License compatibility is well described at FSF and OSI websites and even at Wikipedia. For example, see note about permissive licenses.

[gkdr]

Nope. They should be GPLv3 compatible.

So the information given to me in gkdr/lurch#21 is wrong?

Edit: I just realized I might have just read it wrong all this time.

[tehnick]

So the information given to me in gkdr/lurch#21 is wrong?

Here is a false statement:

Since libsignal is GPLv3, you are correct that GPLv2 is not an option. Unfortunately, since libsignal does not have an or-later clause, you can only do GPLv3, not GPLv3+.

If fact, you may use GPLv2+, GPLv3, GPLv3+, LGPLv2.1+, LGPLv3+ or any GPL compatible permissive license, because all of them are compatible with GPLv3. Just have in mind that final result (binary file) will be distributed under GPLv3.

[gkdr]

Hmm, I have not noticed this before your comment.

Just wanted to come back to this: This library does not contain any of the double-ratchet session code, and I myself was using the official Signal Protocol implementation, since all other clients are doing it as well.

Now, the draft for the new spec is out, and it looks like I will have to fork and heavily modify libsignal-protocol-c, and include it in here. So even if I pick a permissive license, the compiled lib will be GPLv3, but I guess I could design the interface to not necessarily depend on it, the same way it is now.

Unless you have an urgent need, I'd like to wait for the results of the discussion regarding the new XEP draft (i.e. if it's possible to not use libsignal-protocol-c).

[alibitek]

@gkdr The new OMEMO specification wants to:

use our own, new wire format, making the protocol independent from third parties Additionally, as ODR has its own, XML-based wire format, the protobuf serialization of the Signal protocol can be removed.

This means you will be able to plug an implementation that adheres to the OMEMO Double Ratchet (ODR) requirements. i.e. have a crypto lib that implements the Double Ratchet algorithm with X3DH key agreement with the right parameters and construct the OMEMO message in the specified wire format from the output of that lib.

Although the updated spec closely follows the specification used in by the Signal protocol:

This XEP defines a protocol that leverages Double Ratchet [3] encryption with X3DH [4] Key Agreement to provide multi-end to multi-end encryption, allowing messages to be synchronized securely across multiple clients, even if some of them are offline. Double Ratchet [3] and X3DH [4] are cryptographic protocols designed by Trevor Perrin and Moxie Marlinspike and were first published under the name Axolotl.

The cryptographic algorithms used by OMEMO are collectively referred to as the OMEMO Double Ratchet (ODR). In order to make the protocol independent from specific server-side support, Personal Eventing Protocol (XEP-0163) [7] (PEP) is used to fill the 'server' role of X3DH [4].

For more info see Implementation notes , which mentions that:

The OMEMO Double Ratchet deliberately uses mostly identical parameters for its Double Ratchet [3] and X3DH [4] as the Signal protocol does so that Signal protocol implementations can be reused with only minor modifications.

As the the old OMEMO specification used Olm (An implementation of the Double Ratchet cryptographic ratchet), from the Matrix project, which is under Apache License 2.0, I think Olm can be used instead of Signal with the new spec: https://github.com/xsf/xeps/pull/460#issuecomment-290539602 https://github.com/igniterealtime/Smack/pull/117#issuecomment-290413532

Probably with some adaptation to provide the necessary session info:

Bundle A collection of publicly accessible data that can be used to build a session with a device, namely its public Identity-key, a signed-pre-key with corresponding signature, and a list of (single use) pre-keys.

and the other ODR-specific params

I'm going to try to use Olm/MegaOlm or create a non-GPL Double Ratchet (ODR) implementation that can be plugged into an XMPP client library that implements XEP-0384: OMEMO Encryption without license restrictions.

[gkdr]

@mnemonicflow I meant that I believe a library called "libomemo" should also include the "ODR" part. Right now, the double ratchet has to be done by a different library, which results in glue code that can be avoided.

As for Olm, it cannot be used as it stands since does not use the XEdDSA signature algorithm like libsignal-protocol-c. In fact, none of the clients currently use Olm, and it seems this is the reason why this won't change (see the discussion on the the mailing list).

Like I said, I could easily design the interface in a way that allows the user to supply their own ODR implementation, so that the resulting compiled library is not GPLv3 like libsignal. I was just not sure if anyone would do that, since aside from patching Olm (which was not audited yet, as opposed to libsignal), XEdDSA also has to be implemented. Since you seem to be interested, I will do it that way.

If I got @tehnick right, it is permissible for this library to have a permissive license. I will look into those soon then.

[alibitek]

@gkdr As of Nov 21, 2016: https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/ ,

the NCC Group have publicly released their security assessment of the underlying libolm library, kindly funded by the Open Technology Fund, giving a full and independent transparent report on where the core implementation is at. The assessment was incredibly useful, finding some interesting issues, which have all been solved either in libolm itself or at the Matrix client SDK level.

Olm also has signing, but seems to be doing it in a different way than the XEdDSA and VXEdDSA schemes.

As for Olm, it cannot be used as it stands since does not use the XEdDSA signature algorithm like libsignal-protocol-c.

Indeed, then we have a problem, as the OMEMO spec says:

This XEP defines a protocol that leverages Double Ratchet [3] encryption with X3DH [4] Key Agreement to provide multi-end to multi-end encryption.

And the X3DH Key Agreement Protocol paper mentions that:

Sig(PK, M) represents a byte sequence that is an XEdDSA signature on the byte sequence M and verifies with public key PK , and which was created by signing M with PK’s corresponding private key. The signing and verification functions for XEdDSA are specified in XEdDSA and VXEdDSA Signature Schemes paper.

[gkdr]

Ah, thanks, I must have misunderstood something on the mailing list discussion and should have verified it first. Olm being audited is a good thing!

As for the XEdDSA problem, I half-heartedly suggested to just drop this conversion step and introduce a separate signing key, but since you provided me with the information that Olm includes signing I started to like that, actually. Let's see if anyone agrees. Another suggestion is to do it the other way round (generate the Ed25519 key first and then use libsodium's Ed25519->Curve25519 conversion).

[gkdr]

I just realized that the XML library I use (mini-xml) is GPLv2. I'm not sure I'm willing to rewrite all of that code right now... But I wanted to maybe use libxml2 instead anyway so that my Pidgin plugin doesn't need two different XML libraries and the mxml version in Debian stable is really old, causing problems. I guess I have some more reasons to do it now.

I'll leave the license as it is (MIT) because I don't think it hurts, but will reopen this issue because in effect this software is still GPLv2, as far as I understand.

[ghost]

I don't know why you switch to a permissive license. GPLv3 works better to make the project growing fast, and at same time protect everyone's efforts.

[tehnick]

@wnereiz Probably you just do not know, but there are a huge amount of issues with GPL licensed code. Even with incompatibility of code which is licensed under different versions of GPL. Personally I have faced with many examples in Debian project.

But specifically in this issue I have made an accent on using libomemo library in projects which use non-GPL licenses. FLOSS community in common is much bigger that its part which use GPL licenses.

Thanks to @gkdr this issue is solved at early step of library development.

As for libraries required for OMEMO implementation... @gkdr this discussion is might be interesting for you: https://github.com/anurodhp/Monal/issues/9#issuecomment-208063040

[tehnick]

I just realized that the XML library I use (mini-xml) is GPLv2.

As far as I see it is under LGPLv2. And this is really strange choice. It is not compatible with GPLv3, for example. LGPLv2.1 or LGPLv2.1+ would be much better for mxml library. Probably this should be discussed with mxml developers.

the mxml version in Debian stable is really old, causing problems.

The situation have already changed, see: https://tracker.debian.org/pkg/mxml

More over, it is not a problem at all. There is an official Debian repository with backports. If you ask, package maintainer may upload updated version of the package into it.

this software is still GPLv2, as far as I understand.

LGPLv2, but yes, (L)GPL licenses are viral...

[ghost]

@tehnick

Probably you just do not know, but there are a huge amount of issues with GPL licensed code. Even with incompatibility of code which is licensed under different versions of GPL. Personally I have faced with many examples in Debian project.

I know how difficult to deal with license incompatible problem. I just worry about the future of many FLOSS projects, which easily turn to permissive and finally the effort of contributors "flow to / drain by" some big companys/orgs without any return.

But I'm not to say stand against the switching (MIT is also an acceptable FLOSS license). I do understand the situation you faced. Maybe it is the correct decision at the moment :-)