Tracking issue: evaluating dependencies with non-CNCF CLAs about kubernetes

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[skitt]

/sig architecture

[dims]

@skitt we have had this issue for a long time now... for example cadvisor one of our very important dependencies needs a non-CNCF CLA ( google/cadvisor#3541 (comment) for example )

[skitt]

Right, but we don’t have a policy around it — should we?

(The Google CLA is OK, at least for my employer — google/cadvisor#3078. But I’m more interested in a general stance before we dive into specifics, which we can’t do anyway.)

[dims]

@skitt every employer may likely make different choices with respect to the same CLA, so probably no common ground that i can see to write a policy that revolves around explicit terms in CLA or which companies are willing to sign it or not.

This probably needs to be booted up the stack to CNCF level as our licensing posture comes from what's allowed and not allowed from the CNCF charter and Governing Body deliberations etc.

For now, we muddle around with what we have, asking folks who can contribute to fixing something in a repo to do so and when that becomes a burden figure out alternatives to remove them. This is what we have been doing in general for a bunch of dependencies already for one reason or another.

See https://github.com/kubernetes/kubernetes/blob/master/hack/unwanted-dependencies.json where we drop things into that we track longer term to cleanup/get-rid-off. To get something into that json files, needs the consensus of the dependency approvers. So that's the current "policy" if you will.

[skitt]

@dims I agree 100%, this can’t be decided at “our” level, and rather than a list of principles, we’d end up with (if anything) a list of approved CLAs (in the same way there’s a list of approved licenses, which may also be at odds with member companies’ own lists of approved licenses).

I suppose the question for the community is whether it’s OK to muddle along, or whether it’s worth pushing this up the stack.

[skitt]

See https://github.com/kubernetes/kubernetes/blob/master/hack/unwanted-dependencies.json where we drop things into that we track longer term to cleanup/get-rid-off. To get something into that json files, needs the consensus of the dependency approvers. So that's the current "policy" if you will.

That reminds me that I wondered about adding gomock to this as part of this PR... What do you think?

[BenTheElder]

I suppose the question for the community is whether it’s OK to muddle along, or whether it’s worth pushing this up the stack.

I think it's a good question for the TOC, but currently I'm not sure it's worth blocking on.

It's not ideal, but we do need maintained dependencies, however the maintainers want to work on it, and as long as it's under the license policy we have the ability to fork later if it comes to it.

Even if a dependency has no CLA, we can't predict if it will accept contributions from our contributor base for any other reasons.

Forking or replacing dependencies is always on the table if we can't get necessary changes implemented otherwise, but doing so preemptively for every dependency we think may be difficult for some of our contributors to patch is expensive and probably unnecessary.

Deciding on that seems pretty in scope for the TOC, and we otherwise largely stick to CNCF dependency policy.

[BenTheElder]

Also: If every open source project took the attitude that only their own CLA was acceptable, then any non-CNCF projects couldn't use our libraries ...

That doesn't seem like a desirable place to be, so I'd hesitate to endorse a blanket ban on dependencies having non-CNCF CLAs.

If we have specific dependencies where we're unable to achieve essential fixes, then we should probably deal with those.