`brew audit` will detect the license for the main branch instead of the release

[SMillerDev]

brew doctor output

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  python-dateutil
  python-charset-normalizer

Verification

• [X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
• [X] I ran brew update twice and am still able to reproduce my issue.
• [X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output

HOMEBREW_VERSION: 4.2.9-50-g14ba271
ORIGIN: https://github.com/Homebrew/brew
HEAD: 14ba2715335c1b2eefeb2f2c6d013c256e2968d3
Last commit: 3 hours ago
Core tap HEAD: 01a51a04f200f260f334fa566fac80f48cf721ea
Core tap last commit: 14 minutes ago
Core tap JSON: 20 Feb 10:53 UTC
Core cask tap HEAD: fac2e263c50eaba54a62dca6dbfe1ff52a873e42
Core cask tap last commit: 22 minutes ago
Core cask tap JSON: 20 Feb 10:53 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DEVELOPER: set
HOMEBREW_EDITOR: nano
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 10
HOMEBREW_NO_ENV_HINTS: set
HOMEBREW_NO_INSTALL_FROM_API: set
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 15.0.0 build 1500
Git: 2.43.2 => /opt/homebrew/bin/git
Curl: 8.4.0 => /usr/bin/curl
macOS: 14.4-arm64
CLT: 15.1.0.0.1.1700200546
Xcode: 15.2 => /Applications/Xcode-15.2.0.app/Contents/Developer
Rosetta 2: false

What were you trying to do (and why)?

Update manticoresearch to resolve a icu4c build problem

What happened (include all command output)?

Build failed with:

Full audit manticoresearch --online --git --skip-style output
  manticoresearch
    * Formula license ["GPL-2.0-only"] does not match GitHub license ["GPL-3.0"].

What did you expect to happen?

The audit checks the license of the release.

Step-by-step reproduction instructions (by running brew commands)

brew audit manticoresearch --online --git --skip-style

[apainintheneck]

It seems like we use a Github API endpoint to fetch this information which doesn't provide any way to specify the version of the repo.

https://github.com/Homebrew/brew/blob/c35546167da22c3c00d34332ff84a1bb40153766/Library/Homebrew/utils/github.rb#L500-L509

• https://docs.github.com/en/rest/licenses/licenses?apiVersion=2022-11-28#get-the-license-for-a-repository

[Bo98]

One option would be to use the licensee gem that GitHub use themselves for that API, which would have the bonus of working with not-GitHub sources. But it would require having the source downloaded and I don't think any of our audits do that.

Given we do have metadata file copying however, we could make it an installed keg check and read those files.

[SMillerDev]

We check files in the install all the time. Should be disable to add license

[carlocab]

I think we have a license mismatch allowlist we can use here? It might get forgotten though.

[issyl0]

Are we saying that the license could change between a release branch and the main branch? Feels like something the /repos/license endpoint should be able to handle (personal opinion).

EDIT: Hmm, tested this and gh api "repos/issyl0/rl-testing/license" returns MIT. I noticed it might take a ref query parameter, but gh api "repos/issyl0/rl-testing/license?ref=test-new-license" still returns MIT (despite the other fields saying that it's definitely on the new branch).

Maybe it only computes licenses on the main branch?

[SMillerDev]

Yeah, I'd expect the same of the endpoint

[Bo98]

I think we have a license mismatch allowlist we can use here? It might get forgotten though.

We do and are using that for now. But allowlists really should be for genuine exceptions rather than silencing a buggy audit.

[issyl0]

You've successfully nerd-sniped me into figuring out why /repos/.../license?ref=blah doesn't work. 🙃

[SMillerDev]

And did you fix it when you found out? 😅

[MikeMcQuaid]

We check files in the install all the time. Should be disable to add license

Agreed. I don't think we should do this always but it would be nice to have some sort of license audit here that can handle the case where the tarball output is correct even if the upstream repo is not.

[SMillerDev]

Okay, I now see that comment was different than what I meant, which was:

We check files in the install all the time. Should be possible to add a license check

[MikeMcQuaid]

@SMillerDev Yeh, I agree with that too. My thinking is that we'll need to do something clever so that the install time license check is only used some of the time when we know there's problems and a mismatch otherwise (rather than moving all license checks to always be install time)

[SMillerDev]

If @issyl0 managed to make the license API work for branches I think that should be good enough at least for cases like this. I don't really know of any cases where an install time check would be better.

[issyl0]

@SMillerDev I have a PR open, it's waiting on the team who actually works on this stuff to tell me how I should have done it. 😂