Add LICENSE visibility checks ("NonsolvableLicenseDeps")

[thesamesam]

It's possible for the tree to become "broken" by a package that has @FREE licenses suddenly gaining a dependency which is not in @FREE.

Example (covered at https://bugs.gentoo.org/832778).

• GNOME depends on app-accessibility/orca (LICENSE has only FOSS licenses contained within the @FREE set) for accessibility support
• app-accessibility/orca started to depend on app-accessibility/espeak-ng in a new version instead of app-accessibility/espeak
• app-accessibility/espeak-ng initially had a non-free licence
• This meant anyone with GNOME installed (with the right USE flags, anyway) pulling in Orca couldn't upgrade fully because espeak-ng could not be emerged.

We should have some way of detecting this via pkgcheck, as it's just as valid as dependencies otherwise being unresolvable (e.g. via keyword), and more serious even than RequiredUseDefaults IMO.

[thesamesam]

A quick way of making a bad ebuild which breaks the tree:

1. Create an ebuild sys-apps/foo with LICENSE="all-rights-reserved"
2. Add it to @system in profiles/
3. Try to do a world upgrade

[arthurzam]

I can perform the check, by each package checking it sub packages. But, what should be the correct behavior here? In theory I see no issue with a free software depending on non-free software (of course not in "base" profile system). Or am I wrong? I'm asking about "false report" cases here.

Also, if we say we should go with it, what level should it be? Should it be error and fail croacker?

[ajakk]

https://bugs.gentoo.org/872119 is one such example of an issue resulting from this.

[thesamesam]

I can perform the check, by each package checking it sub packages. But, what should be the correct behavior here? In theory I see no issue with a free software depending on non-free software (of course not in "base" profile system). Or am I wrong? I'm asking about "false report" cases here.

Also, if we say we should go with it, what level should it be? Should it be error and fail croacker?

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

Additionally, I think we may want a general warning for something with @FREE depending on non-@FREE, but this could be a 'style' level warning to avoid noise. I think it's useful for someone to know when packaging/adding a new dep that something is non-free, so they can inform upstream, etc.

[arthurzam]

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

OK, but this will notify for all non free packages in tree. I think we need to define which set of packages to scan.

Additionally, I think we may want a general warning for something with @FREE depending on non-@FREE, but this could be a 'style' level warning to avoid noise. I think it's useful for someone to know when packaging/adding a new dep that something is non-free, so they can inform upstream, etc.

This one is understood and would be added.

[thesamesam]

Maybe it could be like RequiredUseDefaults where we shouldn't have it be by default. This minimises the impact to users from such incidents like the linked bugs (it should hopefully pick them up). In such cases, it should be a warning.

OK, but this will notify for all non free packages in tree. I think we need to define which set of packages to scan.

It's okay if the leaf package is non-free. It's not okay if a package with LICENSE only consisting of @FREE has a dependency which isn't.

I don't think we need to worry about non-free depending on non-free.