Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] shards licenses #548

Open
didactic-drunk opened this issue Mar 10, 2022 · 6 comments
Open

[RFC] shards licenses #548

didactic-drunk opened this issue Mar 10, 2022 · 6 comments

Comments

@didactic-drunk
Copy link

didactic-drunk commented Mar 10, 2022

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 crystal-lang/crystal#11488

@straight-shoota
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

@[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
Copy link
Member

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

@straight-shoota
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants