Bazel should not hardcode license enforcement for third_party/

[cgrushko]

Bazel enforces licenses in BUILD files in third_party/ directories.

Users other than Google might not be interested in enforcement at all, or may be interested in using a different directory.

Proposal: make licenses enforcement depend on a flag to Bazel which we enable in Bazel's bazelrc, but others are free to do something else.

[ittaiz]

+100

…

On Wed, 30 Aug 2017 at 0:02 cgrushko ***@***.***> wrote: Bazel enforces licenses in BUILD files in third_party/ directories. Users other than Google might not be interested in enforcement at all, or may be interested in using a different directory. Proposal: make licenses enforcement depend on a flag to Bazel which we enable in Bazel's bazelrc, but others are free to do something else. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3639>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIFxBO-FNA-Tik1xst-Scu1nIArVZBks5sdHxpgaJpZM4PGiqX> .

[cgrushko]

Got bitten by this again...

[ittaiz]

@cgrushko any chance you'll tackle this?

[cgrushko]

I took a peek; it seems that this check happens in at least two places (RuleClass.createRule and PackageFactory.callExportsFiles).
The code around the first check doesn't have an obvious way to get a configuration (where a flag can be defined), so it'll probably be time consuming to figure this one out.

The straightforward workaround is to use thirdparty instead of third_party, which is lame but easy :)

[gregestren]

I'm starting to look more at cleaning up Bazel's licensing logic (of which there's a lot of opportunity, but it's a project).

Is this issue still currently biting anyone?

[ittaiz]

Indeed

…

On Thu, 7 Jun 2018 at 23:59 Greg ***@***.***> wrote: I'm starting to look more at cleaning up Bazel's licensing logic (of which there's a lot of opportunity, but it's a project). Is this issue still currently biting anyone? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3639 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF6T3rqC76GFb-KZICfDlbolSMrHgks5t6ZQxgaJpZM4PGiqX> .

[gregestren]

The best near-term solution I can think of is to move this checking to --check_licenses, which is flag-gated logic that does a deeper form of license checking. The actual semantics of that logic is outdated and precisely what I want to redesign. But it could at least provide a home for the third_party check that's properly flag gated and easy to toggle (and for what it's worth --check_licenses already defaults to off).

The only downside is it would take Bazel longer to identify missing third_party license declarations. But obviously that doesn't matter to people who don't want that anyway.

[petemounce]

@gregestren I'm interested in how this check-licenses feature works (or, will work); at present, we're integrating a third-party to flag up if we add a dependency (whether directly or transitively) that has a license we disqualify from our codebase. Having a way for bazel to do this would be great.

[gregestren]

@petemounce: @aiuto has been leading a license redesign. Not sure where the best current doc / tracking bug for that is.

[cgruber]

A feature request for that redesign would be to allow such checking in generated workspaces. For instance, I wrote a maven integration, which generates a workspace in /external that reflects the full artifact space referenced that will be pulled in from maven. Being able to turn on license enforcement, so that (where possible to detect from maven metadata, or overridden where not) one could avoid licenses not permitted in one's repo, like AGPL, etc.

…

On Fri, Jan 25, 2019 at 10:38 AM Greg ***@***.***> wrote: @petemounce <https://github.com/petemounce> : @aiuto <https://github.com/aiuto> has been leading a license redesign. Not sure where the best current doc / tracking bug for that is. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3639 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUN4v5MMtGX3O9Qntsb948MKK4DFzqXks5vG08zgaJpZM4PGiqX> .

-- ----- Christian Gruber christianedwardgruber@gmail.com

[aiuto]

The only downside is it would take Bazel longer to identify missing third_party license declarations. But obviously that doesn't matter to people who don't want that anyway.

Bazel has no business checking that itself. That should be handled by rules_licenses.
My mantra on this is "No Google specific policy w.r.t. license is baked into Bazel". Everything I am planning to build is just rules and (maybe) an external enforcement tool.

@cgruber I think what you want should be possible.
You would need someway to transform the maven license spec into a (new) license() rule. In this scheme a license is a tuple [path to file, type, copyright notice]
The "type" is just a string that is meaningful to your organization. Ideally, everyone will be using the same, well-known types (agpl, apache, bsd, gpl, lgpl, xfree86, ...)
You would have to map whatever appears in the maven spec to the type names used in your organization. We will be provide a sample policy enforcement tool, but it is up to any organization using Bazel to customize what license mixing is allowed based on their needs.