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

Add licenses to .app for rebar3_sbom #1651

Closed
kivra-pauoli opened this issue May 21, 2024 · 11 comments
Closed

Add licenses to .app for rebar3_sbom #1651

kivra-pauoli opened this issue May 21, 2024 · 11 comments

Comments

@kivra-pauoli
Copy link

Hi 👋.

Would you accept a pull request adding {licenses, ["ISC"]} to cowboy's .app?

This would allow for https://github.com/voltone/rebar3_sbom to identify this in CI, for license reporting purposes.

Asking before pull request'ing since I'm also interested in doing this for ranch and cowlib 😄

Thanks.

@essen
Copy link
Member

essen commented May 21, 2024

I'm not sure where that licenses key is documented?

@kivra-pauoli
Copy link
Author

kivra-pauoli commented May 21, 2024

Lemme try to find that. I don't think it's Erlang/OTP -specific, but rather Hex.pm. On the other hand, https://hex.pm/packages/cowboy is identified as ISC, so I wonder where that information's obtained from.

Edit: I can find it mentioned for .app.src at https://hex.pm/docs/rebar3-publish#adding-metadata-to-code-classinlinesrcltmyappgtappsrccode, and now that I searched for ISC is cowboy I understand it might come from hex_metadata.config: {<<"licenses">>,[<<"ISC">>]}. The same happens for cowlib and ranch.

@essen
Copy link
Member

essen commented May 21, 2024

Yes it's from the hex metadata. I don't use rebar3 so the hex metadata is given directly to hex. The .app file is generated by Erlang.mk from the Makefile (it's only pushed to the repo for rebar3 compatibility). If there's a need to add it then Erlang.mk must be modified to include it, which means there has to be a new Makefile variable. So having as more details as possible would help.

Alternatively if it could take it from hex when fetching the package, problem solved?

@kivra-pauoli
Copy link
Author

The .app file is generated by Erlang.mk from the Makefile

I wondered about this, but missed this "detail".

If there's a need to add it then Erlang.mk must be modified to include it

I understand, but this (adding for a specific use case) is probably "too specific" (?)

So having as more details as possible would help.

At the moment, the only details I have are those I linked to. 😢

Alternatively if it could take it from hex when fetching the package, problem solved?

I'm not sure it's not working on the local files, by looking at _build (where rebar3 keeps the compilation artefacts).

I'll check with the maintainers if they'd be Ok to read this from hex_metadata.config, but I can't find a reference to how this file is consumed (or what the expected content is - I'm assuming it's an Erlang term, much like a sys.config).

@essen
Copy link
Member

essen commented May 21, 2024

It's not a file for the hex metadata. It's an Erlang term given directly to hex_core. I meant getting it from hex.pm directly. But it's probably a different plugin altogether so no clear path there.

Perhaps a better path would be to first have rebar3_sbom let you override the license of specific dependencies (so you could configure them manually for now), and then later do the changes in Erlang.mk if they can be useful.

@kivra-pauoli
Copy link
Author

so you could configure them manually for now

This I'm doing already, in the output, by opening an exception for lib.s without license (this is how cowboy et al get reported, because of what we discussed above). But this is a "less ideal solution" because (and I know it's not common) licenses change, and we want to have an automated process based on the source of information, not one overridden by us.

I wouldn't mind tackling it directly from erlang.mk if you're willing to have that variable and behaviour. 👍

@essen
Copy link
Member

essen commented May 21, 2024

I think it would be best to just look at the license file like GitHub does to be honest. I'm not a fan of duplicating information. Ideally we wouldn't need to do it for hex either. Perhaps there could be a function in Erlang.mk that looks at the license file and detects the license, maybe using https://github.com/licensee/licensee/blob/main/docs/command-line-usage.md for the detection (and jq for getting the license name). That's likely not cheap enough to run on every build (when we generate the .app file). On the other hand it could be fine when building on Hex (so wouldn't need to duplicate that info anymore), and that might also be something rebar3_sbom could use when it doesn't have the license in the .app file.

Here is another place where that information is duplicated, that might be better done differently: https://github.com/ninenines/cowboy/blob/master/doc/src/guide/introduction.asciidoc#license

@kivra-pauoli
Copy link
Author

Yeah, I was thinking about automating it, too (I'm also not a fan of duplicating information), but, as you say, using an online tool to detect the license is most likely not cheap. I'll close this one, for now, and check what rebar3_sbom's maintainers say. I think having the same information in cowboy in 3 different places (the LICENSE file, erlang.mk, and the Hex metadata file), at least, even if it doesn't change often, is slightly overkill.

@essen
Copy link
Member

essen commented May 21, 2024

I don't think licensee is an online tool. It has a command line that just produces too much information so JSON works better as the output to get what we want.

@essen
Copy link
Member

essen commented May 21, 2024

In the case of Erlang.mk the detection could be cached as well if necessary. Regardless of outcome please open a ticket in https://github.com/ninenines/erlang.mk for future reference.

@kivra-pauoli
Copy link
Author

It's done in ninenines/erlang.mk#1001. Closing this one... Thanks.

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

No branches or pull requests

2 participants