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

Fri Dec 4 04:13:11 UTC 2009

Thanks for your reply, Tom.

That's fascinating how these resolved!
----------------------------------------
kdebase-workspace -> qedje
kdebase-workspace -> qzion
kdebase3 -> libsmbclient
----------------------------------------

As for:
* -> readline
----------------------------------------
Since all of the Readline issues are essentially this problem:
(gplv2) -> (gplv3+), I'm wondering if maybe Fedora-12 upgraded
Readline a little too soon, and should have held on to an older GPLv2+
version of Readline a little longer.  This wouldn't have helped with
the PHP issue, but certainly takes care of these.

As for:
eclipse-callgraph -> systemtap
----------------------------------------
Probably Eclipse could insert an LGPL "eclipse-callgraph-systemtap"
module inbetween those two to play it safe?  Or maybe Eclipse calls
systemtap via exec(), so it's okay?  In this case I didn't spend that
much time trying to figure out if it truly is a dynamic linking
problem.  I was also getting a little bit stuck on the fact systemtap
is a script interpreter, so do the scripts need to be GPLv2+?  (I
suspect not, otherwise all bash scripts would also have to be
GPLv3+!).  Sorry, still a bit of a newb on these issues.  This page
you wrote has been *invaluable* !
http://fedoraproject.org/wiki/Licensing

As for:
ghostscript -> urw-fonts
----------------------------------------
I was considering the package license "as a whole" and ghostscript
gets tainted by that Adobe "no modifications" rider.  So I presumed
the "no modifications" rider would kill ghostscript's ability to use
"urw-fonts".  But based on the way the kde problems above resolved, I
realize the logic for license compliance is not so simple!

Thank you very very very much!  I know, I know, mailing lists hate to
help undergrads with their homework.  ;-)  But I think my professor
might be subscribed to the list, so he'll adjust my mark accordingly.
:-p

By the way, the 12 license problems I sent to the list are not just a
random sample.  They are the only 12 I could find in all of Fedora 12.
 Maybe my techniques will improve and I will find more, but for now
this is all I got.

yours,

Julius

On Thu, Dec 3, 2009 at 12:54 PM, Tom "spot" Callaway
<tcallawa at redhat.com> wrote:
> 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
>
>
>

-- 
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/logging.html