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@xxxxxxxxxx> 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 _______________________________________________ Fedora-legal-list mailing list Fedora-legal-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-legal-list
