Add option to list recursive dependencies of a package along with their licenses

[bos]

(Imported from Trac #889, reported by joeyadams on 2011-09-27)

It should be possible to list all of the dependencies of a package, including their licenses. This would be useful for:

• Developers writing proprietary applications.

• Developers who don't want their liberally-licensed libraries to be "upgraded" to the GPL or similar by subtle dependencies.

Attached is a simple patch that makes cabal-install list this information when the verbosity level is 2 or higher. Sample usage:

$ cabal install --verbose=2 --dry-run gnutls
Reading available packages...
Resolving dependencies...
base         BSD3
bytestring   BSD3
ffi          BSD3
ghc-prim     BSD3
gnutls       GPL (Just (Version {versionBranch = [3], versionTags = []}))
integer-gmp  BSD3
monads-tf    BSD3
rts          BSD3
transformers BSD3
In order, the following would be installed:
monads-tf-0.1.0.0 (new package)
gnutls-0.1 (new package)

This is a quick hack, as I am not familiar with the Cabal codebase. This should probably be wrapped as a --list-licenses command line switch. Pretty-printing licenses would be a plus.

I am already finding this feature useful, and hope others will too.

[bos]

(Imported comment by @kosmikus on 2011-09-27)

Vaguely related to #539. (Both are about getting more info about the overall dependency graph, but admittedly in quite different ways.)

[ivanperez-keera]

I would find this useful to list all the dependencies of a project when I need to reinstall them (for instance, with --enable-library-profiling).

I suggest that this behaviour be included with 'list-dependencies' (either as a command or a flag of some other command), and that licenses be printed only when --verbose is used.

[tibbe]

@ivanperez-keera We're solving the freezing of dependencies another way, namely using #1519

[mtullsen]

This (the "along with their licenses" part) is something that Galois is very interested in. On one of our projects we are delivering a binary to a customer and we want some confidence regarding the license(s) for that binary.
What we currently have is highly ad hoc:

• a "cabal test" target with a 'postTest' user hook that prints the licenses.

We basically want a way to list the package dependencies and their licenses. Here's some ideas as to a more principled way to add this capability:

How to invoke the feature:

• Alternative 1: add options to the cabal list command:

  cabal list --dependencies-only
  cabal list --dependencies-only --simple-output --show-licenses
  

  (In the latter case we need --show-licenses because --simple-output doesn't print the license information.)

• Alternative 2: a new cabal command that works similar to 'cabal list':

  cabal list-dependencies ... [--show-licenses]
  

Also, we might generalize --showlicenses to an ability to display the value of any cabal field:

cabal list-dependencies --show-field=license
cabal list-dependencies --show-field=author
...

What seem to be less desirable approaches:

• As an option to install: we'd like to extract this information after installation without having to re-install.

• Using the by-products of cabal freeze: I see that I can get the list of dependencies from

  cabal freeze --dry-run
  

  but I'd much prefer to not be parsing the by-product of another command.

Yet another need we have:

• Getting the information needed so that we can snag all the license files to bundle them into our binary distribution. Maybe this capability could be built into the --show-field option, but I'm not sure how we'd get the information where the license files are stored.

Galois is interested in doing the development needed. But before we start, we'd like to get some consensus on what the community is interested in (and what patches would be likely to be accepted :-).

Input? Wishes? Other thoughts?

Thanks, Mark

[23Skidoo]

@mtullsen

Galois is interested in doing the development needed.

Great! You may be interested in https://github.com/jaspervdj/cabal-dependency-licenses which also implements this functionality.

Alternative 1: add options to the cabal list command.

I'm +1 on this alternative.

Getting the information needed so that we can snag all the license files to bundle them into our binary distribution. Maybe this capability could be built into the --show-field option, but I'm not sure how we'd get the information where the license files are stored.

The licenses are stored under ~/.cabal/share/doc/$arch-$os-$compiler/$pkgid (aka InstallDirs.docdir), so if you know the target platform and have a package description of the dependency in question (which tells you the value of license-file), retrieving them is easy. Note that there can be multiple license files per package. Also note that with GHC 7.10, $pkgid also includes the package key in addition to package name and version. Maybe we could add a flag to cabal copy to do what you want.

[23Skidoo]

/cc @dcoutts

[mtullsen]

Great! You may be interested in https://github.com/jaspervdj/cabal-dependency-licenses which also implements this functionality.

Thanks for the pointer, I was completely unaware of this.

We'd still be interested in bringing this functionality into cabal-install. I'm assuming that others would also find this useful ...?

[mietek]

In a similar vein, I would like to be able to list the build-tools and extra-libs used by a project's transitive dependencies. I have done some work towards this, but it is not quite satisfactory (mietek/haskell-on-heroku#34).

[dcoutts]

People have looked before at the feature to collect the bundle of licenses for a package (in a particular configuration). Would that be enough and cover the other use cases or do we need it in multiple places?

[libeako]

I was about to request this feature.

Many common licenses require a reproduction of the license when the software is distributed in binary form. For example : BSD3 :
"Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution."

It is too tedious and error-prone to manually traverse the dependency graph and the individual licenses.

I imagine a command line tool that collects the license info into a folder dedicated for this purpose, which would be distributed together with the executable.

[hvr]

fwiw, @ekmett mentioned on #hackage he hacked up a script which generates
output like https://gist.github.com/ekmett/34024e26479763d77bc3e1ecaa24b819

[Profpatsch]

A command line feature like this would be awesome, to see which package introduced which dependencies. For reference, here’s how nix-store 1.11 implements it (though I’m not a fan of the naming at all).

OPERATION --QUERY
   Synopsis
       nix-store {--query | -q} {--outputs | --requisites | -R | --references |
                 --referrers | --referrers-closure | --deriver | --deriver | --graph
                 | --tree | --binding name | --hash | --size | --roots}
                 [--use-output] [-u] [--force-realise] [-f] paths...

   Description
       The operation --query displays various bits of information about the store
       paths . The queries are described below. At most one query can be specified.
       The default query is --outputs.

       The paths paths may also be symlinks from outside of the Nix store, to the Nix
       store. In that case, the query is applied to the target of the symlink.

   Common query options
       --use-output, -u
           For each argument to the query that is a store derivation, apply the query
           to the output path of the derivation instead.

       --force-realise, -f
           Realise each argument to the query first (see nix-store --realise).

   Queries
       --outputs
           Prints out the output paths of the store derivations paths. These are the
           paths that will be produced when the derivation is built.

       --requisites, -R
           Prints out the closure of the store path paths.

           This query has one option:

           --include-outputs
               Also include the output path of store derivations, and their closures.
           This query can be used to implement various kinds of deployment. A source
           deployment is obtained by distributing the closure of a store derivation.
           A binary deployment is obtained by distributing the closure of an output
           path. A cache deployment (combined source/binary deployment, including
           binaries of build-time-only dependencies) is obtained by distributing the
           closure of a store derivation and specifying the option --include-outputs.

       --references
           Prints the set of references of the store paths paths, that is, their
           immediate dependencies. (For all dependencies, use --requisites.)

       --referrers
           Prints the set of referrers of the store paths paths, that is, the store
           paths currently existing in the Nix store that refer to one of paths. Note
           that contrary to the references, the set of referrers is not constant; it
           can change as store paths are added or removed.

       --referrers-closure
           Prints the closure of the set of store paths paths under the referrers
           relation; that is, all store paths that directly or indirectly refer to
           one of paths. These are all the path currently in the Nix store that are
           dependent on paths.

       --graph
           Prints the references graph of the store paths paths in the format of the
           dot tool of AT&T's Graphviz package[1]. This can be used to visualise
           dependency graphs. To obtain a build-time dependency graph, apply this to
           a store derivation. To obtain a runtime dependency graph, apply it to an
           output path.

       --tree
           Prints the references graph of the store paths paths as a nested ASCII
           tree. References are ordered by descending closure size; this tends to
           flatten the tree, making it more readable. The query only recurses into a
           store path when it is first encountered; this prevents a blowup of the
           tree representation of the graph.
       
        … a few more

Interesting is the distinction between run-time and build-time dependencies, though I’m not sure if that’s relevant for cabal.