Support for repositories that are dual-licensed

[google]

Support for repositories that are dual-licensed

[agibson-bluecat]

@Bobgy I think it would be nice to allow manual path overrides by the user in case they have dependencies which use non-standard paths for their license files. This way the behaviour of go-licenses could be predictable (even for repos with dual licenses), and we wouldn't need to wait for go-licenses to add support for every license location that any module uses.

For example, I'm having an issue with the dependency github.com/hashicorp/cronexpr. This repo has dual licenses available at /GPLv3 and /APLv2. go-licenses doesn't recognize any license file in this repo, so it ends up outputting:

github.com/hashicorp/cronexpr,Unknown,Unknown

To make the go-licenses tool's behaviour as predictable as possible, I think something like the following would be a nice feature:

go-licenses csv . --override-license-paths overrides.json

Where the contents of overrides.json is a set of repo -> path kv pairs:

{
    "github.com/hashicorp/cronexpr": "/APLv2",
    ......
}

Another way to support this would be to allow multiple inline --override-path arguments, for example:

go-licenses csv . --override-path 'github.com/hashicorp/cronexpr=/APLv2' --override-path ......

What do you think?

[Bobgy]

It's very complex to programmatically understand the difference between dual-licensed (user can choose a license) vs contains code for both licenses (user must comply with both).

Yes, I think reporting both and show a warning to ask users to check can be a good step forward.

Open for suggestions and contribution.

[Bobgy]

Makes perfect sense to me.

Regarding how to override, ideally we support both an arg as well as a config file.

viper seems to be a go to option to achieve that.

[Bobgy]

Welcome contributions in this direction!

[Bobgy]

JFYI, https://stackoverflow.com/a/58470849 seems to be a code example to achieve that

[Bobgy]

Also note more complex cases exist:

• One package has multiple licenses
• One module has multiple packages with licenses
• One module has non standard and unrecognizable license, so specifying license path may not be enough

We don't need to solve all of them at once, but for any proposed solution, it's better to quickly think how it may be extended for future requirements.