Package Dependency License Checking

[Duncan Coutts]

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