Cabal && license combinations

Vivian McPhail haskell.vivian.mcphail at
Tue Feb 8 15:47:47 CET 2011

> On Mon, 2011-02-07 at 14:42 +0000, Malcolm Wallace wrote:
> > > It seems then that a package should be the least restrictive
> > > combination of all the licenses in all the contained modules.
> >
> > Omit the words "least restrictive" and I think you are correct.


> >
> > To combine licences, just aggregate them.  There is no lattice of
> > subsumption; no "more" or "less" restrictive ordering.  It's simple:
> > you must obey all of them.  Some aggregations introduce a
> > contradiction of terms, so you cannot legally aggregate those modules
> > without breaking some term.  But if the terms of the aggregated
> > licences are compatible rather than contradictory, then all is good.
> Right, so the effect of per-file/mixed licenses could be achieved by
> letting packages specify a list of licenses:
> license: Foo, Bar

Could this be computed automatically from the source files by Cabal?

> Meaning you may copy/distribute provided you comply with all these
> licenses.
> Note that this does not cover dual licensing, e.g. Foo or Bar at
> distributor's choice.
> Duncan

Looking specifically at hmatrix, there are three kinds of modules

   i) bindings to GSL            GPL
   ii) bindings to LAPACK     BSD
   iii) pure Haskell                hmatrix author's choice

1) Am I correct in thinking that even the bindings modules (the Haskell
parts, not the C files) can be under any licence, FOO, chosen by the author,
but the binary _linked_ to, say, GSL has to comply with FOO and GPL?

2) If someone uses hmatrix but no GSL functions (hence there are no GSL
functions in the linked binary) can they get away with not complying with
the GSL requirement?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cabal-devel mailing list