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