Hi Tristan, I don't have enough background on the FreeDesktop side of things, but a couple of comments inline regarding the BuildStream part of the proposal.
<snip> > For a vast portion of open source / free software available in the > wild, this conscious interpretation and decision needs to be made by a > human being. > > I would see this implemented in BuildStream in the following way: > > * Declare a new "licenses" public data format in the bst public data > domain[3] > > This is a place where BuildStream project maintainers can record > the decided license for the module being built, similar to yocto's > LICENSE variable[1]. Personally, I think BuildStream itself shouldn't care about licenses. It should probably not even know that licenses are a thing. As I see it, BuildStream is a build tool and managing licenses shouldn't be its responsibility. Auditing of sources seems like a separate concern to me. At least the way I use BuildStream, by the time I decide to use a source in a BuildStream element, I have already made a decision to use it and hopefully have done my due diligence and auditing. But, maybe others have different usage patterns. In any case, I feel like BuildStream core shouldn't have an opinion about licenses or how to manage them. But, having a plugin do this job is definitely fair game. > For compatibility across tooling, and consideration of possible > further automation (see further below), we should probably assert > that these license annotations be valid SPDX license > identifiers[4]. > > * We would add a new Element plugin in BuildStream, and call it > something like `assertlicense` > > In this element's `config`, it would allow the user to declare > a blacklist. > > This element could output a manifest of licenses in the artifact, > or produce no output at all, the important part is that this > element can be added to the pipeline, depend on some elements, > and halt the build with an error in the case that invalid > licenses are detected. I don't have anything against such a plugin. But, I'd be much happier if the public data specification was defined by such a plugin rather than BuildStream itself. Maybe a family of plugins decide to follow a shared format, and maybe some other family could decide to do things differently if their needs aren't met. Either way, BuildStream core won't need to change or care. <snip> Cheers, Chandan
