Re: RFS: jabbin
* Andrew Donnellan <ajdlinux@gmail.com> [070126 12:07]:
> >* As it contains so much stuff, I'm a bit lost what code is actually
> > used. But the resulting binaries might be indistributeable, as the
> > main program is GPL with exceptions for qt and stuff only accessed
> > via qt or qca, while it also seems to be used at other parts which
> > look like they might also be used more directly. (libjingle, xmlsec)
> > If nothing bad happens, some note in the source package that nothing
> > bad happens and why would be nice.
>
> Sorry, I don't understand what you're saying here.
If a program contains code that is only available under GPL, GPL
requests for all the program being available under GPL without
additional restrictions. OpenSSL has multiple such additional
restrictions (like 'Products derived from this software may not be
called "OpenSSL"[...]' or 'All advertising materials mentioning
features or use of this software must display the following
acknowledgment: [...]'), so a program with GPL-only code linking[1]
with OpenSSL is not distributeable at all.
So a GPL program linking with OpenSSL is not possible, but a
"GPL and additional permissions to allow that" program can link
with OpenSSL. But that of course needs two things, namely
1) all GPL code included having that additional permission
2) the conditions for this permission have to be matched.
1) should be no problem if your debian/copyright is correct and list
all licenses.
2) the license listed there for the main program gives the following
additional (over GPL) permissions:
| As a special exception, the copyright holder(s) give permission to link
| this program with the Qt Library (commercial or non-commercial edition),
| and distribute the resulting executable, without including the source
| code for the Qt library in the source distribution.
This clearly gives no permission for linking with OpenSSL, so lets look
at the next paragraph:
| As a special exception, the copyright holder(s) give permission to link
| this program with any other library, and distribute the resulting
| executable, without including the source code for the library in the
| source distribution, provided that the library interfaces with this
| program only via the following plugin interfaces:
|
| 1. The Qt Plugin APIs, only as authored by Trolltech
| 2. The QCA Plugin API, only as authored by Justin Karneges
That seems to be the clause intended to allow linking to OpenSSL,
but only when it is only linked via a Qt or QCA plugin.
But e.g. /3party/libjingle/talk/base/ssladapter.cc does
#include <openssl/[...]>, which indicated that it might be intended
to be linked with openSSL and might be done so when building a package.
In this case it looks like that file is only used in the windows build,
so it most likely no problem. But having for each of those files to think
about why it causes no problem, makes it quite some work for a sponsor.
If your source package included a short explaination for each such file
why it is no problem, you would help a sponsor quite a lot to sponsor it.
(and I guess FTP-masters, too, when they have to look at it)
While all files including openssl headers seem to be not used under Linux
(at least when looking as shallow at it as I did), what puzzles me more is
unix:LIBS += -lssl in voip.pri. Perhaps the easiest way is to just remove
it. If nothing breaks then it can just be removed, if something breaks one
has to look what part is using ssl.
If something is mixing GPL and OpenSSL code there mainly three possibilities:
1) rewriting to not use OpenSSL but e.g. gnutls
2) rewriting to use it in a way allowed by your permissions (i.e. over qca)
3) get additional permissions from all copyright holders in code with not
enough permissions.
Hochachtungsvoll,
Bernhard R. Link
[1] What the actual status of this affairs is, is a bit disbuted,
as the program does not contain most of the code of the library,
but the library was used when creating it, header[2] files have been
used when compiling and so on. And since it is disputed and no
judge has yet decided, and noone was confident enough in this being
no problem to offer take over all possible costs of all Debian users
if a judge decides the other way, the only safe way is to assume
this is undistributeable, whether or not one believes that to be the
way copyright should work.
[2] which may include algorithmic or inline stuff, but even without
exceptions for interface stuff might not be enough to allow this.
Reply to: