Skip to content
This repository has been archived by the owner on Mar 6, 2024. It is now read-only.

Should license types be formalized? #9

Open
luxe opened this issue Apr 19, 2022 · 1 comment
Open

Should license types be formalized? #9

luxe opened this issue Apr 19, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@luxe
Copy link
Contributor

luxe commented Apr 19, 2022

cat bazel-bin/buildfarm-server.bom.yaml | grep license | sort | uniq -c | sort -rn | grep Apache 
     21   license: The Apache Software License, Version 2.0
     13   license: Apache License, Version 2.0
     11   license: Apache 2.0
      1   license: The Apache License, Version 2.0
      1   license: MPL 1.1;LGPL 2.1;Apache License 2.0
      1   license: Apache 2.0 License
      1   license: Apache-2.0
      1   license: Apache 2

Most of these are the same license. Are they extracted from source code? Or does maven allow people to annotate the license in their own format?

Has there been any discussion on formalizing license types? It will make other static analysis easier. For example, in the future, I'd like to error the build based on discovered license type (similar to what we do now with library names).

@luxe luxe added the enhancement New feature or request label Apr 19, 2022
@danielmachlab
Copy link
Collaborator

@luxe these licenses are coming from the POM file that licensetool.py finds next to the download location of the jar. Since we don't have control over the POM files, we can't change or standardize them.

However, there is a new ruleset called bazelbuild/rules_license, which allows us to represent licenses in starlark. I am working on a prototype to add rules_license support to rules_jvm_external, which you can read more about here. Additionally, we have a new Bazel SIG about license handling with Bazel, which you can join or read the meeting notes here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants