Hi,
I think I might have found 12 problems with code that dynamically links into GPL code.
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 kdebase-workspace -> qedje kdebase-workspace -> qzion kdebase3 -> libsmbclient libtirpc -> libgssglue
These ones I'm not so sure about, since they are Maintainer specified (not AutoReqProv): ---------------------------------- eclipse-callgraph -> systemtap ghostscript -> urw-fonts
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
More details are here (e.g. licenses, and what AutoReqProv picked): ------------------------------------- http://juliusdavies.ca/uvic/csc490-2009-fall-dmg/fedora12_lic_probs.html
Two questions:
1. Am I actually identifying some real problems?
2. What does Fedora normally do to detect and avoid similar problems?
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:
- 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.
- 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
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@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:
- 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.
- 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
-
Julius Davies -
Tom Callaway