Check for licensing issues in dependency tree

[3noch]

Having to deal with LGPL problems in integer-gmp manifested a possible enhancement for stack that would show users if their project might have licensing problems. At the simplest level, stack could merely warn the user if any project dependencies are not a BSD variant, MIT, or Public Domain.

More advanced versions of this feature could actually try to detect licensing problems for some given target license. For example, if building a project targeting LPGL, stack would consider LPGL dependencies as a non-issue. But if the same project were stated to be a commercial product, stack would issue a warning.

[mboes]

This sounds like something best done as a separate tool / plugin, perhaps? Since the space of possible policies to implement here is rather large.

[3noch]

I think the bare-bones version could be implemented rather easily. Since stack already has all the knowledge of the dependency tree, it is in an optimal place to provide some help in this area.

[3noch]

Take a look at this package for a possible solution: https://hackage.haskell.org/package/cabal-dependency-licenses

[mgsloan]

buildLicsFromPkgsin ide-backend is also worth a look: https://github.com/fpco/ide-backend/blob/master/ide-backend/IdeSession/Cabal.hs#L466

[legrostdg]

cabal-db licenses could also be useful: https://github.com/vincenthz/cabal-db
A more simple solution (and still very useful) would be to display the licenses of the dependency tree, without dealing with a policy for licensing issues.

[mgeisler]

I'm confused what the problem with LGPL is since #399 seems to have been closed without anything done? That is, depending on a LGPL program does not mean that you need to (L)GPL your program too. You're free to choose any license for your program (that's the whole point of LGPL).

[DemiMarie]

You do need to provide a way for users to use a different version of the LGPL library. That can be done by dynamic linking or by distributing object code that users can link into an executable.

[mgeisler]

See also #1049 for more about the requirements of the LGPL and the problem with lack of dynamic linking on Windows.

[ruuda]

Since #2576 Stack can print dependency licenses. It is not hard to then write a simple script that validates those against a whitelist of allowed licenses or packages:

$ stack list-dependencies --license --no-include-base | egrep -v "BSD3|MIT|Apache"

Would this satisfy your needs?

[3noch]

That's very cool. I think for this to be truly "helpful" it would need to be a check done by default (i.e. without opt-in). I think the vast majority of uses cases will involve someone accidentally including a package that is not licensed the way they expect. Because of that, you really want to warn them of the issue without asking. But maybe people disagree with me?

[mgsloan]

Something automated would be cool, @3noch. How about in your stack.yaml

allowed-dependency-licenses: [BSD3, MIT, Apache]

I'd only want to have the check done by sdist and upload though, maybe a future check command.

[3noch]

@mgsloan That would be awesome, I think.

[ruuda]

Once a user is aware that there could potentially be licensing issues, I think the current situation is sufficient. You can make the whitelist check part of CI to avoid accidentally depending on an incompatible library.

However, I think that many users are not aware of potential issues, or they simply haven’t thought about them. For that case a default-on check would be helpful indeed, but that would also mean that Stack has to know about license compatibility, which I’m not sure it should.

[mgsloan]

I wouldn't mind if stack sdist and related commands gave a warning based on some heuristic knowledge of license compatibility.

[Wizek]

I wanted to have a sorted overview of the licenses, similar to what cabal-db does, but for local, non-hackage stack-based packages. Based on @ruuda's comment, I considered piping together bash commands, then decided to instead:

stack list-dependencies --license --no-include-base | ghc -e 'import Data.List' -e 'getContents >>= lines .> map words .> sortOn (!!1) .> map unwords .> unlines .> return >>= putStrLn'

(.> is imported from compose-ltr for me via .ghci)

Implementing grouping and counting for an overview (just like cabal-db does) might be easy via
groupBy ((==) `on` (!!1)); it is however left as an exercise to the reader. Jokes aside if someone does decide to write it, please do share. :)

[snoyberg]

I don't believe this functionality should go into Stack itself, there are too many variations that could be desired. As mentioned above, Stack provides the ability to dump relevant output to automate this externally.