Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bazel should not hardcode license enforcement for third_party/ #3639

Closed
cgrushko opened this issue Aug 29, 2017 · 11 comments
Closed

Bazel should not hardcode license enforcement for third_party/ #3639

cgrushko opened this issue Aug 29, 2017 · 11 comments
Labels
team-Configurability platforms, toolchains, cquery, select(), config transitions type: feature request

Comments

@cgrushko
Copy link
Contributor

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
Copy link
Member

ittaiz commented Aug 30, 2017 via email

@ittaiz ittaiz mentioned this issue Dec 2, 2017
Open
@cgrushko
Copy link
Contributor Author

Got bitten by this again...

@ittaiz
Copy link
Member

ittaiz commented Feb 27, 2018

@cgrushko any chance you'll tackle this?

@cgrushko
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Member

ittaiz commented Jun 8, 2018 via email

@gregestren
Copy link
Contributor

gregestren commented Jun 8, 2018 •
edited
Loading

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.

@aiuto aiuto added team-Configurability platforms, toolchains, cquery, select(), config transitions and removed category: misc > misc labels Dec 10, 2018
@gregestren gregestren mentioned this issue Jan 2, 2019
Closed
@petemounce
Copy link
Contributor

petemounce commented Jan 11, 2019 •
edited
Loading

@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
Copy link
Contributor

gregestren commented Jan 25, 2019 •
edited
Loading

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

@cgruber
Copy link
Contributor

cgruber commented Jan 25, 2019 via email

gregestren added a commit to gregestren/bazel that referenced this issue Jan 25, 2019
@gregestren
Add --check_third_party_targets_have_licenses.
52cf982 
When on, all rules and files declared with exports_file()
under //third_party must declare licenses().

This is the flag's default, and also status quo semantics.
The point of this flag is to let users turn off that
checking when they don't want to treat //third_party as
special.

Fixes bazelbuild#3639
@gregestren gregestren mentioned this issue Jan 25, 2019
Closed
weixiao-huang pushed a commit to weixiao-huang/bazel that referenced this issue Jan 31, 2019
@gregestren @weixiao-huang
Add --check_third_party_targets_have_licenses.
8136682 
When on, all rules and files declared with exports_file() under //third_party must declare licenses().

This is the flag's default, and also status quo semantics. The point of this flag is to let users turn off that
checking when they don't want to treat //third_party as special.

Fixes bazelbuild#3639

Closes bazelbuild#7262.

PiperOrigin-RevId: 231645495
@aiuto
Copy link
Contributor

aiuto commented Feb 4, 2019

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.

@gregestren gregestren mentioned this issue Feb 15, 2019
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
team-Configurability platforms, toolchains, cquery, select(), config transitions type: feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@petemounce @vladmos @cgruber @ittaiz @cgrushko @aiuto @gregestren