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.

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

License is inconsistent with visibility, other properties. Needs simplification/better opensource support. #1440

Closed
michaelsafyan opened this issue Jun 23, 2016 · 5 comments
Assignees
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Configurability platforms, toolchains, cquery, select(), config transitions type: feature request
Milestone

Comments

@michaelsafyan
Copy link

For consistency, package-level license() should be replaced with default_license in the package() declaration (to mimic the default_visibility and default_testonly declarations).

On top of this, I think the value of license should be a target, not a simple string so that you can more properly specify the license (including the text). That is, it should be possible to define something like:

     license(
        name = "simplified_bsd",
        srcs = ["simplified_bsd.txt"],
        copyleft = false,
        modification_allowed = true,
        ... other properties ....
     )

And then elsewhere:

     # third_party/some/package
     package(
          default_license = ["//licenses/opensource:simplified_bsd"]
     )

If that were done, it would also be ideal to provide a github repo with such license declarations already predefined, so that one can easily refer to licenses by their name (like "//licenses/opensource:gpl_v3"), without having to figure out if they are "unencumbered", "restricted", "reciprocal", etc.

@philwo
Copy link
Member

philwo commented Jun 24, 2016

This is a very nice idea. Thanks :)

@rahul-malik
Copy link
Contributor

@philwo - Any chance this can be prioritized sooner than 1.0? Debating writing a custom skylark rule to get around this if not

@philwo
Copy link
Member

philwo commented Jun 19, 2017

@ulfjack Any idea on this?

@ulfjack
Copy link
Contributor

ulfjack commented Jul 25, 2017

I'm afraid we won't be able to work on this sooner than 'some time next year'. It's a big change, and we'll have to run it by a number of stakeholders that are using the existing system. If someone wants to write up a more complete proposal, I'd be happy to run it by our internal stakeholders and provide feedback.

@aiuto aiuto self-assigned this Mar 22, 2019
@aiuto aiuto added team-Configurability platforms, toolchains, cquery, select(), config transitions and removed category: misc > misc labels Mar 22, 2019
@aiuto
Copy link
Contributor

aiuto commented Apr 25, 2019

Obsolete. Please follow the issue in #7444

@aiuto aiuto closed this as completed Apr 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Configurability platforms, toolchains, cquery, select(), config transitions type: feature request
Projects
None yet
Development

No branches or pull requests

6 participants