[RFC] shards licenses

[didactic-drunk]

Proposal: A new shards command to see all licenses in use.

shards licenses

Output:

foo MIT
gmp GPL2+
  dynamic link -lgmp GPL2
baz GPL2,GPL3
  static link -lbaz MIT,Apache,Other

A software package may have multiple licenses.

A more structured yaml option may be preferred with either a path to the file or the license itself.

Also see https://github.com/crystal-lang/crystal/issues/11488

[straight-shoota]

Sounds good! We can easily assemble the license properties of all dependencies' shards.yml.

The link information however would be difficult to obtain. And it probably doesn't make much sense for a source distribution format. The reason is that the Crystal code only contains lib bindings, not the libraries themselves. Which binary libraries are linked in the end and what licenses they have is not conclusively determined by the bindings. It depends on link time configuration. For example, the bindings may target libfoo but there's also a compatible libfu and you can link either one of them.

[didactic-drunk]

The link information however would be difficult to obtain. And it probably doesn't make much sense for a source distribution format. The reason is that the Crystal code only contains lib bindings, not the libraries themselves. Which binary libraries are linked in the end and what licenses they have is not conclusively determined by the bindings. It depends on link time configuration. For example, the bindings may target libfoo but there's also a compatible libfu and you can link either one of them.

Then I guess link targets could still be supplied? The file linked is probably more useful than -lfoo as some shards build with non-distro packages (I have 3 shards that download the latest software rather than use the package manager).

It's too bad pkg-config doesn't have this information.

There are a few distro specific shell one liners to get the copyright of a package. Maybe their inclusion isn't too cumbersome?

[straight-shoota]

Yeah, maybe we could collect all the @[Link] annotations from the source tree. That needs an understanding of Crystal syntax, so it would rather be a feature of the compiler, not shards. Not sure how reliable it would be, though. Which bindings end up being used depends on the target system and compile time configuration. You can either go by actually used code, but that's only valid for the current system and configuration. Or you can collect everything in any potentially reachable code, but that would likely include bindings that wouldn't ever be used (think about the bindings in stdlib, like libgmp, libxml, libyaml). It's a recall vs precision problem with no clear solution.

[didactic-drunk]

@[Link] may run shell commands. Should the compiler spit out a list of resolved '@[Link]`'s? Is there a simpler way to get this information?

[asterite]

If you pass -v to crystal it will spit out the final linker command

[straight-shoota]

It's --verbose, the short arg doesn't work. But --cross-compile is also more useful for this because all Crystal's object files are already merged, while --verbose prints tons of individual modules.