10:13 p.m.
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(a)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