[Fedora-legal-list] 12 dynamic GPL link problems

[Tom "spot" Callaway]

On 12/03/2009 02:48 AM, Julius Davies wrote:
> I think I might have found 12 problems with code that dynamically
> links into GPL code.

First of all, thank you for your help! It is certainly not Fedora's
intention to have any GPL incompatibility scenarios.

I will look into each case and determine whether it is valid, and what
actions to take if so.

For example, replacing readline with libedit is almost always a viable
solution.

Here's my initial notes:

> These ones I'm pretty sure are a problem since AutoReqProv caused them:
> ----------------------------------
> pilot-link -> readline
> pilot-link-devel -> readline
> device-mapper -> readline
> device-mapper-event -> readline
> lvm2 -> readline

Have not checked for validity, but should be resolvable using libedit.

> kdebase-workspace -> qedje
> kdebase-workspace -> qzion

plasma/generic/scriptengines/qedjescript/ depends on qedje and qzion,
notably:

plasma/generic/scriptengines/qedjescript/qedje_applet.cpp (GPLv2+)
plasma/generic/scriptengines/qedjescript/qedje_package.cpp (GPLv2+)

They get compiled into:
/usr/lib64/kde4/plasma_appletscript_qedje.so

That depends on kdelibs (LGPLv2+), qt (LGPLv2 with exceptions or GPLv3
with exceptions), qzion (GPLv3+), and qedje (GPLv3+), so it should all
be fine.

> kdebase3 -> libsmbclient

There are two files in the kdebase3 package that are dependent on
libsmbclient:

/usr/lib64/kde3/kio_smb.la
/usr/lib64/kde3/kio_smb.so

The kio_smb direct code is GPLv2+, they depend on the kdelibs which are
LGPLv2 (which is GPLv2+ compatible) and libsmbclient (GPLv3+ and LGPLv2+).

So, in this specific case, there is no compatibility issue.

> libtirpc -> libgssglue

This is a known concern, and we are currently working with Sun to
resolve the issue by removing the SISSL from the three files in libtirpc.

> These ones I'm not so sure about, since they are Maintainer specified
> (not AutoReqProv):
> ----------------------------------
> eclipse-callgraph -> systemtap

eclipse-callgraph is EPL which is incompatible with systemtap (GPLv2+),
but Red Hat is the copyright holder for eclipse-callgraph. I've
escalated this to Red Hat Legal.

> ghostscript -> urw-fonts

This isn't a code dependency, but even if it was, ghostscript is GPLv3+
and urw-fonts is GPL+, so I think this may be a mistake.

> 
> This one is AutoReqProv, but maybe gvfs's LGPL just switches into GPL,
> since LGPL allows that?  (But wouldn't this cause a transitivity
> problem for others that expect gvfs to be LGPL?)
> -------------------------------------
> gvfs -> libgudev1

The FSF permits the LGPL -> GPL, and it doesn't really cause a
transitivity issue. There is a theoretical issue there, but in practice,
it is not a concern.

> Two questions:
> 
> 1.  Am I actually identifying some real problems?

I think so. Even though it is more work for me, I'd rather know about
them like this than find out via a lawsuit.

> 2.  What does Fedora normally do to detect and avoid similar problems?

We look during package import, but we could definitely stand to improve
our auditing techniques in this area. I'm very interested in your code
efforts, and possibly implementing them in Fedora directly as part of an
automated audit effort.

Thanks again,

~spot