Add --ignore option

[at-wat]

Fixes #88

Packages beginning with the specified path will be ignored.
Imported packages by ignored packages are still checked.

---

In my case, I would like to use go-licenses to check library licenses used in our product system.
--ignore will be used to ignore internal private packages with proprietary license.

[andoks]

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

[lavrd]

What about this pull request? Looks really good.

[EizTimor]

Any updates here?
This would be very useful.

[hansinator]

plz merge. I need this, too

[Bobgy]

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.

[at-wat]

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.

[at-wat]

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.

[drigz]

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).

[Bobgy]

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!

[Bobgy]

Thank you! The simplified PR looks great!

Only some nitpickings

[Bobgy]

Can you also add a section in https://github.com/google/go-licenses/blob/master/README.md to introduce this new feature?

[at-wat]

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

[Bobgy]

Looks perfect! Thank you for this great contribution!

cc @drigz do you want to have another look?

[Bobgy]

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

[drigz]

LGTM