Provide a license report

[hseg]

At the moment, it is hard to generate a bill of materials for dependencies. Since IIUC standard Haskell practice is to link statically, that seems to mean that binary distributions effectively are redistributing derivative works of all dependencies, and so my understanding is that all their license terms need to be distributed along with the software.

However, I acknowledge that even projects as conservative as Debian aren't bothering to do this, so this may be a solution looking for a problem. On the other hand, the existence of cabal-plan license-report suggests to me that some people are bothering to do this.

In particular stack ls dependencies --license isn't enough. This is for a couple of reasons:

• For some licenses (MIT, BSD, ISC, ...), the license text needs to also be distributed.
• The output still needs to be massaged into an actual report
• It'd be nice if the report could canonicalize the license strings -- right now it seems it produces the raw license strings from the .cabal files.

(A further ask that requires social, not technical, solutions is to have the license strings be SPDX identifiers, since the current freeform standard gives rise to such ambiguities as "What does GPL mean?" (version is ambiguous, as is whether using later versions is permitted))

Hacking a solution around cabal-plan is not viable, since it requires both a plan.json (which might be generated from a freezefile, but…) and also a populated Cabal store. Hence, a stack-native solution is necessary. For the same reason, it is unreasonable to push this to cabal-plan, and given that stack ls dependencies --license exists, it makes sense to push for it to actually be useful.

[mpilgrem]

@hseg, thanks for the suggestion. I would be happy to see that implemented. I am wondering where it could sit, within Stack's current user interface. My current thought is perhaps:

stack ls dependencies license-report

as (using a Swiss Army knife analogy) it strikes me as a special purpose 'blade' that could be tucked away in the 'handle' for most Stack users.

I did not know cabal-plan and looked at its example license report: https://hackage.haskell.org/package/cabal-plan-0.7.4.0/src/example/cabal-plan.html. However, I wondered how it would work for immutable packages versions not published on Hackage (i.e. repositories at a specific commit or local or remote archive files: https://docs.haskellstack.org/en/stable/topics/package_location/) or mutable packages locally. What is the desired output, in each of those cases?

On canonicalisation, the license field of the Cabal package description has been canonicalised since version 2.2 of the package description format: https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#pkg-field-license. I suspect the 'costs' of Stack trying to canonicalise further would outweigh the 'benefits'.

[hseg]

10 ene 2025 22:54:11 Mike Pilgrem ***@***.***>:

@hseg[https://github.com/hseg], thanks for the suggestion. I would be happy to see that implemented. I am wondering where it could sit, within Stack's current user interface. My current thought is perhaps: *stack ls dependencies license-report * as (using a Swiss Army knife analogy) it strikes me as a special purpose 'blade' that could be tucked away in the 'handle' for most Stack users.

Note `stack ls` seems to be more of a querying tool than a reporting tool, but that invocation can be seen as just "query the dependencies in a license-report format"

I did not know *cabal-plan* and looked at its example license report: https://hackage.haskell.org/package/cabal-plan-0.7.4.0/src/example/cabal-plan.html. However, I wondered how it would work for immutable packages versions not published on Hackage (i.e. repositories at a specific commit or local or remote archive files: https://docs.haskellstack.org/en/stable/topics/package_location/) or mutable packages locally. What is the desired output, in each of those cases?

I'm not sure what should be different? After all, `stack` presumably has access to the source files for these dependencies, which should expose in their `.cabal` files their licensing terms, versions and descriptions?

On canonicalisation, the *license* field of the Cabal package description has been canonicalised since version 2.2 of the package description format: https://cabal.readthedocs.io/en/stable/cabal-package-description-file.html#pkg-field-license. I suspect the 'costs' of Stack trying to canonicalise would outweigh the 'benefits'.

True. At best, I'd perhaps add an asterisk to the preamble for packages formatted in cabal <2.2, saying "these packages specified their licensing requirements in a machine-illegible format. A best-effort attempt at guessing the license has been made, consult the license text to confirm". The fact that the report would by itself provide the license texts should be enough either way - the index file shouldn't be considered authoritative anyway. (Ofc, IANAL)

[mpilgrem]

@hseg, on output and what would be different, in the case of the cabal-plan tool, its example HTML report does not give the text of a licence but only a URL to Hackage (where the licence text may be found). Are you looking for a report that sets out (a) the text of the licence or (b) a pointer to where the text of the licence may be found?

If it is a pointer, I was wondering what that pointer would be in each possible case.

In Stack's local database of built immutable packages, it preserves the licence file. For example, on my Windows machine, there is a D:\sr\snapshots\4d595060\doc\active-0.2.1\LICENSE (D:\sr is my Stack root). The Cabal file is not preserved, the the *.conf file in the package database has a 'license' field (which, I assume, is taken from the 'license' field of the original Cabal file) but does not have anything equivalent to the 'licence-file' of a Cabal package description. Stack, I think, does not know where a built immutable package has 'come from'. So, presumably it would either report (continuing with the active-0.2.1 example):

active-0.2.1 Any licence file is at D:\sr\snapshots\4d595060\doc\active-0.2.1

or it would report

active-0.2.1 Content of licence file(s) at D:\sr\snapshots\4d595060\doc\active-0.2.1 are:
File name: LICENSE
Copyright (c) 2011-2015, active team:

Andy Gill [email protected]
Ben Gamari [email protected]
Bollu [email protected]
Brent Yorgey [email protected]
Christopher Chalmers [email protected]
Daniel Bergey [email protected]
Jeffrey Rosenbluth [email protected]
Ryan Scott [email protected]

All rights reserved.

... [rest of familiar licence text]

[hseg]

19 ene 2025 19:06:26 Mike Pilgrem ***@***.***>:

in the case of the *cabal-plan* tool, its example HTML report does not give the text of a licence but only a URL to Hackage (where the licence text may be found). Are you looking for a report that sets out (a) the text of the licence or (b) a pointer to where the text of the licence may be found?

I'm afk, but iirc `cabal-plan` can either be given a flag `--license-dir` under which it will write the license tests (with the report serving as an index for the directory), or it will emit these global links as you've noted. The former is my usecase, but the latter might be useful in others - if you need testimonials for that I'd ask the `cabal-plan` maintainers. I'm not sure what to do in the latter case - if they're relying on the public availability of the source (and license text) to meet obligations, then that's not a valid optimization for local packages (but might be for remote git repos). But then perhaps it might be enough to mark those packages as "this is where our best efforts fail".

If it is a pointer, I was wondering what that pointer would be in each possible case.

In the "bundle of license texts" case, I'd copy the license texts from the snapshots over. In the "global pointer" case - does stack not store the original URL of the package? If so, it can special-case hackage and stackage, and otherwise just point to the URL for the entire package and say the license is somewhere there.