On Tue, 2010-07-06 at 17:58 -0700, Trevor Elliott wrote:
Hi Everyone,
I have started implementing a license compatibility check in Cabal, and was interested in getting some early feedback. The attached patch will, as part of the configure step, check that the dependencies have licenses that are compatible with the license chosen for the package being configured. No errors are thrown as a result of incompatible licenses, though warnings are printed.
Hi Trevor, I've finally got around to properly reviewing this patch. I'm not going to apply this version of the patch but I'll give feedback and either you or I can write a revised version. My main concern is about the legal interpretation. To summarise your approach: you take the license of the top level package and compares it against each of the licenses of the dependencies. It declares things to be incompatible if the top level license does not "effectively subsume" the license of the dependent. For example it says that AllRightsReserved can depend on BSD3 but BSD3 cannot depend on LGPL and declares them "incompatible". I think this is confusing two issues. When we distribute a collection of code under a mixture of licenses we have to abide by all the licenses (simply because we are copying, so copyright applies). So the first question is whether we can simultaneously satisfy all the licenses. Under reasonable assumptions we can do a pairwise compatibility test on all pairs of licenses. Note though that this test is necessarily commutative, not hierarchical. The secondary stage is where the hierarchical aspect comes in. It is not wrong to have BSD code depend on LGPL, just as it is not wrong for LGPL code to depend on BSD code. In each case you must abide by both licenses. Copyright makes no distinction on the direction of dependencies. It is however surprising to distributor who sees a package that is marked BSD to find that they must also abide by the terms of the LGPL. The second stage then is to check if the valid set of licenses matches the expectations of the distributor, and if it seems likely that they may be surprised by which licenses they must comply with, to warn/notify them of that fact. So to check this expectation we can look at the top level license and the set of licenses that the distributor must abide by and look for any cases where one of the licenses is more onerous than the top level license. So I want to avoid giving warnings like: "The BSD3 license used by foo-1.0 is not compatible with the LGPL-2.1 license used by bar-1.0" because it's not true. It is a valid combination: the distributor must abide by both licenses. So I'm looking for something like: "Warning: note that while foo-1.0 itself is available under the license 'BSD3', if you distribute the compiled program/library, you must also abide by the terms of the license 'LGPL-2.1' because foo-1.0 uses bar-1.0 which is under that license." [suggestions for improved wording appreciated] If you substitute BSD3 there for AllRightsReserved then that also covers the proprietary distribution case. Given the warning, it is then up to the distributor to work out if the terms of your AllRightsReserved license are compatible with the LGPL (they might be, they might not be). On the other hand, AllRightsReserved will (almost) inevitably be incompatible with the GPL so we would catch that at the first phase when we try to make the set of valid licenses. Other license issues: We do not have enough information to distinguish "GPL-2 or later" from "GPL-2 only". So the matrix at http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility is only partially useful. Without more information I suggest we make the optimistic assumption that they're all the "or later" variety. We're looking for obviously wrong combinations not a 100% guarantee that everything is fine (since we cannot automatically check C libs anyway). Other, more minor code issues: In Configure.hs we should include the license check into the existing checkPackageProblems function. In Check.hs while it is ok to export the checkDependencyLicense function on it's own, we really ought to add a new general function for checking a package in the context of a set of dependencies (represented as InstalledPackageInfo records). Then the license check is the first to be included in that class of checks, but we'll eventually have PVP checking in there too etc. All make sense? If you don't have time to rework the patch then I'll have a go. I think I have a sense of how to do it. I'm reasonably sure I understand what you're looking for in the proprietary distribution situation but I want to make sure that Cabal does not start telling FOSS devs that their valid license combos are invalid, since that'll cause a ruckus. Duncan