Add a license

[mimi89999]

Please add a license file.

[copyninja]

Yeah it would be easier for distro's to pick this and package it. By the way I'm wondering under which license the code is released?. I saw website mentions its open source but no where mentions under which license source is released.

[AlexanderS]

The source files contain a GPLv2+ header:

 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.

[copyninja]

Ah thanks!. Sorry for not looking very closely. I was searching on the site and documentation about license.

[vitalyster]

Actually, the libtransport part of spectrum - is the "derivative work" of Swiften library and must follow strongly GPLv3 which doesn't allow to relicense code under GPLv2, but libtransport-plugin and all "backends" linked to it - may use different license. Proper license guides need more work than just placing a copy of some license, so this issue will remain open.

[Natureshadow]

I am currently packaging spectrum2 for the official Debian repositories and also stumbled upon a few unclear licence issues. Above all, it seems that spectrum2 code depends on OpenSSL, which is illegal under GPLv2 and GPLv3 without an OpenSSL linking exception.

Please help us providing Spectrum2 in distributions by clarifying that!

[Natureshadow]

Here's the current state of my analysis: https://salsa.debian.org/xmpp-team/spectrum2/blob/master/debian/copyright

[vitalyster]

@Natureshadow that code is Swiften derivative work so licensing issues with include/Swiften/* should be forwarded to Swiften itself.

[Natureshadow]

@Natureshadow that code is Swiften derivative work so licensing issues to `include/Swiften/*` should be forwarded to Swiften itself.

I don't think so. Swiften is GPL-3+. The issue simply is that a derivative of that cannot be GPL-2+. This issue is with libtransport, it simply also has to be GPL-3+ instead of GPL-2+.

[vitalyster]

Sure, libtransport is GPLv3, but libtransport-plugin and backends are not. Moreover, libtransport is in progress of splitting into frontends and Swiften derivative libtransport-xmpp-frontend will be the only strict GPLv3 part.

[Natureshadow]

@vitalyster Still, even spectrum itself (spectrum_manager, backends,…) directly use and link against OpenSSL. This is not swift-im. So Spectrum itself cannot be GPL without OpenSSL exception.

[Natureshadow]

Actually, it's only spectrum_manager, the others are a red herring.

spectrum_manager/src/mongoose.h:#include <openssl/ssl.h>
spectrum_manager/src/mongoose.h:#include <openssl/err.h>

mongoose.c even says it is "All rights reserved". The .h file is GPL (but without OpenSSL exception!), but mongoose.c is non-free.

It seems that the licence situation in spectrum_manager/src needs to be carified.

[vitalyster]

mongoose is a different project too and it is available under GPLv2

[Natureshadow]

@vitalyster I know that. And still, it cannot link against OpenSSL if it is illegal. And if Spectrum2 copies the code, then links it against OpenSSL, this is a licence violation ☺.

[vitalyster]

Isn't OpenSSL moved to more opensource-friendly Apache license yet? Anyway, my point is - if another project have licensing issues with OpenSSL then these issues needs to be solved in another projects first.
There is no problem to build spectrum_manager without OpenSSL and exclude it from packaging.

[Natureshadow]

Hmm, I am currently trying that.

But still, other parts of Spectrum still link against OpenSSL. This happens through the code copy of Swiften. Swiften itself is correctly licensed with OpenSSL exception, but Spectrum has copied its source files and recompiles them into its own code - and this code is GPL without OpenSSL exception.

I will look into the license change of OpenSSL. If all versions we use in Debian are already covered by that, then great!

[vitalyster]

Swiften itself is correctly licensed with OpenSSL exception,

So spectrum (libtransport!) must have the same license.

Backends are not linked against libtransport in any form (they communicate over tcp) so they can have any other license. It was made by design to allow less strict license for developers of backends.

spectrum_manager optionally links to OpenSSL, and this can be safely disabled. (https serving still does not work correctly/not well-tested part/require a lot of manual work)

[Natureshadow]

In fact, every single binary produced in the build is linked against OpenSSL. But by now, I found out this is an unintentional side effect of the build system and not needed.

[mirabilos]

Unfortunately, anything that links against swiften must use a licence that is compatible with both “GPLv3-or-later with OpenSSL exception” and the OpenSSL library.

This means that anything that links against swiften must be GPLv2-or-later with OpenSSL exception or GPLv3-or-later with OpenSSL exception (or GPLv3-only with OpenSSL exception), or a compatible licence such as BSD/MIT/etc. (LGPLv2-or-later or LGPLv3(-or-later) will also work) and this applies to almost everything in SpectrumIM…

[vitalyster]

@mirabilos Only Spectrum “frontend” links to Swiften, backends are not linked in any form (they communicate with frontend over TCP connection)

[mirabilos]

vitalyster dixit:

@mirabilos Only Spectrum “frontend” links to Swiften, backends are not @linked in any form (they communicate with frontend over TCP @connection)

The frontend is licenced under GPL without OpenSSL exception, though. Either moving to LGPL (or BSD or MIT or so) or adding that exception would be necessary (requiring all meaningful contributors to agree).

[vitalyster]

Frontend is licensed under the same license as Swiften and it can not be changed because it is Swiften derivative work

[mirabilos]

vitalyster dixit:

Frontend is licensed under the same license as Swiften

It is not.

[coldtobi]

Debian FTP Master assessed that spectrum2 / mongoose licensing is incompatible. See: #466