Why can't we define licenses per dependency?

[haikalpribadi]

Hi @johnynek,

Sorry for the silly question which may be based on a wrong understanding of the license requirement of third_party/ dependencies.

From what I understand, we can only define the licenses option for the full set of the dependencies declared in the .yaml file. Why is that? Why are we not able to define a license type per dependency?

Does the license argument in the build rules represent the license in which the vendor defined for their code distribution, or does it represent our copyright/ownership over the "build rule" for the dependency (and not the dependency itself)? If it is the former, what if we have different license types across different dependencies?

Thank you!

[johnynek]

@haikalpribadi the licenses setting was something I accepted as a PR and maybe should have required more work.

we don't put our deps in third_party at stripe, we use 3rdparty which is shorter and what was used at Twitter which we copied, so we don't get hit by this issue.

I'm happy to accept a PR to improve this, but currently it is low priority for me personally so I probably won't get to it.

The way to add support is to add license as an optional field the classes that represent projects in the yaml file, and then after it is parsed pass it through at generation time.

[haikalpribadi]

Thanks, @johnynek. I'm happy to submit a PR for this, but I should first understand what the expected usage of license is.

Are we supposed to declare license individually per dependency?

What about the transitive dependencies that are pulled in during parseproject? How do we declare them / modify the generated BUILD files?

[johnynek]

I really don't know why bazel want this, and since i think bazel wants them on the builds it is resistant to automatic transitive tooling.

I think requiring it is a misfeature that is forcing bazel users into managing third party licensing the way google thinks it should be done.

Like I said, just using a different directory fixes the issue. I'm not that interested in satisfying this problem. We review changes to dependencies.yaml and workspace.bzl and make sure they point to Apache or BSD licensed code, and we are satisfied with that approach.

[haikalpribadi]

We actually already do have it in a different directory. However, we also see the value on declaring the license of your dependency - it fits our use case.

Anyways, I'll see what we can do with our team and submit PR when we come up with a solution. And of course, it will be optional to enable the feature. :)