ninenines / cowboy

Small, fast, modern HTTP server for Erlang/OTP.
https://ninenines.eu
ISC License
7.27k stars 1.16k forks source link

Add `licenses` to `.app` for `rebar3_sbom` #1651

Closed kivra-pauoli closed 4 months ago

kivra-pauoli commented 4 months ago

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 commented 4 months ago

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

kivra-pauoli commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

It's done in https://github.com/ninenines/erlang.mk/issues/1001. Closing this one... Thanks.