Bug 200284 - linking to firebird, interbase/gpl license incompatibility, guarding with bindist needed
|
Bug#:
200284
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: NEW
|
Severity: normal
|
Priority: P2
|
|
Resolution:
|
Assigned To: carlo@gentoo.org
|
Reported By: carlo@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: linking to firebird, interbase/gpl license incompatibility, guarding with bindist needed
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-11-25 14:50 0000
|
> Interbase Public License, Version 1.0
>
>This is a free software license that is essentially the same as the Mozilla
>Public License, Version 1.1. Like the MPL, the IPL has some complex restrictions
>that make it incompatible with the GNU GPL. That is, a module covered by the GPL
>and a module covered by the IPL cannot legally be linked together. We urge you
>not to use the IPL for this reason.
http://www.gnu.org/philosophy/license-list.html
Affected packages:
dev-db/hk_classes
dev-db/libdbi-drivers¹
dev-db/opendbx¹
dev-java/jdbc-jaybird²
dev-python/orm³
dev-python/sqlobject³
dev-python/sqlalchemy³
gnome-extra/libgda
net-dialup/freeradius
x11-libs/qt
x11-libs/qt-embedded
[1] Dying because of no db backend chosen is not fine. Please default to one in
such a case and throw a warning about it.
[2] jdbc-jaybird is dlopen'ing the firebird client library and therefore
missing firebird as runtime dependency.
[3] via dev-python/kinterbas, in case of sqlalchemy gpl licensed stuff using it
somewhere in the dependency chain
Can't we add USE="bindist" ... or am I missing something?
Regarding Qt:
The Trolltech pages for 3.3 and 4.x say:
"Due to license incompatibilities with the GPL, users of the Qt Open Source
Edition are not allowed to link this plugin to the commercial editions of
InterBase. Please use Firebird or the free edition of InterBase."
It seems as though TT states that it's quite okay to link against Firebird.
As well, They have a page "http://trolltech.com/products/qt/gplexception" that
allows linking against the Mozilla Public License. So I think we're okay here.
dev-db/libdbi-drivers is LGPL, not GPL.
(In reply to comment #1)
> Can't we add USE="bindist" ... or am I missing something?
That's why I opened this bug. It's getting a bit tricky though, when use
depends come into play, because Portage still does not support them.
(In reply to comment #2)
> As well, They have a page "http://trolltech.com/products/qt/gplexception" that
> allows linking against the Mozilla Public License. So I think we're okay here.
Nearly. On the one hand Firebird isn't licensed MPL, Interbase Public License
and partly IDPL¹, which are not included in Trolltech's exception list, so
we'd need to inform them - and we have to copy the exception list add it to our
licenses and note it in the ebuilds. But yes, removing the Qt alias from this
bug for now.
(In reply to comment #3)
> dev-db/libdbi-drivers is LGPL, not GPL.
Right, it is. Though, this doesn't mean you can link anything into the LGPL'ed
library, but that you can link it to anything without the viral effect, afaik.
A minor, but important difference.
One thing none came up with yet, is, if the python stuff is affected at all.
Linking is widely accepted as derived work, according to the GPL 2. How about
the Python scripts, the byte code!?
[1] bug 200276
libdbi-drivers has you pretty beat them, but IANAL, and I don't want to argue
license issues till I'm blue in the face, I just don't have the time for it.
Fin.
There are two components to libdbi. The main libdbi, that you link your
application against, and a number of actual interfaces, which are dynamically
loaded, depending on how the end-usage code of libdbi wants it's database
(often entirely up to the user). This does mean that there is no explicitly
linking between the end application and the firebird libs.
Regardless, I changed the libdbi-drivers to just reject USE=firebird when
USE=bindist is in effect. Per your other comment with defaults, I'm not
changing it to have a default when none are built, as I did that before, and
had user complaints.
I don't know what I'm supposed to do with freeradius. Please tell me which
variant should be applied:
a) remove firebird support
b) disable firebird support if USE=-bindist.
(In reply to comment #5)
> and I don't want to argue license issues till I'm blue in the face, I just don't have the time for it.
Sorry to bother you with it, Robin. I know it's irksome, but everyone of us
wants his copyright and chosen licenses respected and as distributors we are
even more obliged to take it seriously. Moreso, correct license information is
something people, who want to distribute software, rely on. At the current
state this alone is a reason not to use Gentoo on the corporate side (and gain
some backing on our side in turn). I surely don't file such bugs to annoy you
or because it's so much fun. Quite the opposite, indeed.
> Regardless, I changed the libdbi-drivers to just reject USE=firebird when
> USE=bindist is in effect.
Thank you.
> Per your other comment with defaults, I'm not changing it to have a default
> when none are built, as I did that before, and had user complaints.
Actually it is our (informal?) policy that ebuilds should never fail in any
ebuild phase and the growing number of ebuilds violating this (known more or
less valid exceptions like "built_with_use()" as long as Portage doesn't
support use dependencies aside) are a burden. But I don't intend to pick a
fight over it.
(In reply to comment #6)
> b) disable firebird support if USE=-bindist.
The other way around. When the bindist use flag ist set, license safety
measures regarding binary distribuions should be in place.
fixed in net-dialup/freeradius.