[Freedesktop-sdk] License blacklisting [Was: license-checking script for BuildStream projects]

[Tristan Van Berkom]

Hi,

On Tue, 2020-09-01 at 21:08 +0100, Chandan Singh wrote:
> Hi Tristan,
[...]
> Thanks for the summary. I do understand what we are trying to do here,
> and I do think BuildStream itself should allow for such an assertion
> to happen, This can be done via allowing sufficient API for a plugin
> to exist that makes such assertions. I just don't think BuildStream
> core itself should have to do anything relating to licenses. Would you
> agree with this?

Yes.

> Indeed, this is mostly a question around the ownership of the `bst`
> namespace. My suggestion is that it should be reserved by BuildStream
> core itself. That is, if the presence of that plugin data concerns
> BuildStream itself in any way.
> 
> The current builtin public data fields are: integration-commands,
> split-rules and overlap-whitelist. All of these change BuildStream's
> behavior in one way or the other. For example, integration-commands is
> so much part of the core interface, that it gets its own flag in `bst
> artifact checkout --integrate/--no-integrate`.

I should point out that for each of these, these public data were
conceived of for the purpose of consumption by reverse dependency
elements, and for convenience, some of it eventually ended up getting
meshed into core convenience APIs (and even functionality) indeed.

> As such, I think we should keep the `bst` namespace for things
> concerning the BuildStream core.
> 
> If we agree on this separation of concerns, I'm not sure what would be
> the best alternative, i.e. how should we group things together, and
> how fine-grained should that be. If we can't come up with a better
> scheme, something like `core-plugins` or `bst-plugins` won't be any
> worse than `bst` in my opinion.

I think it would make sense to use the `bst-` prefix for any public
data belonging to plugins maintained by BuildStream.

Also, I don't think public data consumed only by plugins needs to be
tied to a specific plugin name, but rather should be named after a
domain / use case (naming the data after what it represents, and not
after what it first happened to be used for, public data annotations
can be reused by multiple plugins).

I think that in a world where we split plugins out of the core (very
near future), all plugins maintained by BuildStream are "upstream
buildstream plugins", and as such, I would not mind sharing the "bst"
namespace directly across those.

While I don't mind so much about using the "bst" name directly, I do
think that BuildStream plugins should either use the "bst" domain
directly, or use the "bst-" prefix for their domain names (i.e.
buildstream plugins should not use un-prefixed public data domain
names).

Cheers,
    -Tristan