Tested this, and it seems to work Ok. I would perhaps have preferred a way to ignore 1st-party packages instead (packages in module being scanned), but this approach is more flexible, and makes this possible by ignoring module name

What about this pull request? Looks really good.

Any updates here?
This would be very useful.

plz merge. I need this, too

Hi people, I'm a new maintainer for go-licenses now. From the number of comments and thumb ups, I can see that this is requested by a lot.

My main concerns for merging this is that -- IMO, such kind of configurations likely grow in size, e.g. people may also need to override some packages with non-auto detectable licenses, so I want to make sure the current proposed argument syntax is compatible with that future use-case.

To my knowledge and suggested by @drigz, viper is a good option to allow configuring from both a command line argument and a config file symmetrically. Therefore, I just want to confirm the option's array syntax is compatible with cobra and viper.

To my knowledge and suggested by @drigz, viper is a good option to allow configuring from both a command line argument and a config file symmetrically. Therefore, I just want to confirm the option's array syntax is compatible with cobra and viper.

https://go.dev/play/p/QCK8-GwWV82
Cobra with viper can handle string array in the same way.

I didn't noticed there is StringSlice in pflag.
I'll update the PR to use pflag.StringSlice.

My main concerns for merging this is that -- IMO, such kind of configurations likely grow in size, e.g. people may also need to override some packages with non-auto detectable licenses, so I want to make sure the current proposed argument syntax is compatible with that future use-case.

I'm using my branch of go-licenses for more than a year in my company's product repositories to check all external dependencies have proper license.
I use --ignore option to exclude company internal packages with proprietary license.
(#46 (comment) seems having a same motivation.)
We haven't seen any other cases to add more configs.

In this kind of closed project use cases,

• if there is a repository expressing a license but can't be detected, google/licenseclassifier should be updated (*)
• if a repository doesn't have open license, it means it's unsafe to legally use it. Possible action of go-licenses users: (*)
  • Ignore the package if the package is individually licensed (including organization internal private packages)
  • Ask package owner to add license (*)
  • Unuse the package (*)
  • (Ignore the package and accept license risks)

In open source project use cases, above with (*) may be chosen.
So, I think there aren't many additional configs to be requested.

Thanks for simplifying with StringSlice! IMO supporting a config file is out-of-scope of this PR but if needed in future, Viper should support this (judging from status of spf13/viper#200).

My main concerns for merging this is that -- IMO, such kind of configurations likely grow in size, e.g. people may also need to override some packages with non-auto detectable licenses, so I want to make sure the current proposed argument syntax is compatible with that future use-case.

I'm using my branch of go-licenses for more than a year in my company's product repositories to check all external dependencies have proper license.
I use --ignore option to exclude company internal packages with proprietary license.
(#46 (comment) seems having a same motivation.)
We haven't seen any other cases to add more configs.

In this kind of closed project use cases,

• if there is a repository expressing a license but can't be detected, google/licenseclassifier should be updated (*)

Another possibility is that the license is too complex for go-licenses -- dual licenses, more than one licenses etc. So we need human intervention. This is where I think the config may grow.

• if a repository doesn't have open license, it means it's unsafe to legally use it. Possible action of go-licenses users: (*)
  • Ignore the package if the package is individually licensed (including organization internal private packages)
  • Ask package owner to add license (*)
  • Unuse the package (*)
  • (Ignore the package and accept license risks)

In open source project use cases, above with (*) may be chosen.
So, I think there aren't many additional configs to be requested.

Agreed with everything else!

Added a section to introduce the --ignore flag: https://github.com/at-wat/go-licenses/blob/add-ignore-option/README.md#ignoring-packages

Also cc @wlynch, do you want to have a look?

LGTM