Limitations in our ability to manage our ecosystem

[Stephen Kitt]

Hi all,

I’m starting this in SIG Testing because it’s based on an issue that
cropped up in test code, but it’s broader than that, hence the
Steering cc; since it’s ultimately about dependencies I’m also
including the dep-approvers with whom I’ve interacted previously.

I’ve run into an issue which has been bothering me for a while, and
I’m curious whether others share my concern or whether it doesn’t
matter (or is too low priority to matter).

Essentially, the question I’m concerned about is whether we should
try to ensure that we (Kubernetes contributors) can contribute changes
to our dependencies; put another way, whether we should try to ensure
that our dependencies can be contributed to by Kubernetes contributors
at large.

The specific incident which led to this is gomock being abandoned and
then transferred to Uber (to be clear, I’m not trying to stigmatise
Uber here). I pushed the PR which acted on that in Kubernetes:
<https://github.com/kubernetes/kubernetes/pull/120969>; this revealed
a change in behaviour in gomock which affected the generated mocks in
k/k (see
<https://github.com/kubernetes/kubernetes/pull/120969#discussion_r1347624438>).
In such situations I usually try to help out upstream where I can;
another user had reported the issue
(<https://github.com/uber-go/mock/issues/80>), so that was taken care
of, but I suggested a possible fix
(<https://github.com/uber-go/mock/pull/105>). Unfortunately gomock
contributors must sign a CLA, and our legal department told me that I
couldn’t. This wasn’t obvious at the time, CONTRIBUTING.md was updated
two days later (<https://github.com/uber-go/mock/pull/108>).
Ultimately another user contributed a fix, so that particular problem
was resolved.

But the general issue remains: here we have a non-CNCF project which
is a relatively important dependency for k/k, and at least some
Kubernetes contributors can’t contribute to it.

Does this bother anyone else?

(Since I like to put my time where my mouth is, I have a possible fix
for this particular dependency: we could switch to
stretchr/testify/mock and mockery instead, see
<https://github.com/skitt/kubernetes/pull/2>. Or we could ask Uber to
relax their CLA. However this shouldn’t be about gomock or Uber
specifically.)

Regards,

--
Stephen Kitt
Senior Principal Software Engineer
Red Hat Application Networking

[Tim Hockin]

I don't think we can prevent them from asking for a CLA. Uber picked
up an abandoned repo and gave it new life, they have lawyers, they
make their own rules. Worse, I can't even evaluate their CLA because
the link in CONTRIBUTING.md takes me to
https://cla-assistant.io/uber-go/mock which has no information and
doesn't seem to DO anything (seems broken).

It's unfortunate that it didn't need a CLA before and now does, but I
am in no position to point fingers about CLAs. In the past we
discussed whether kube should keep a fork of all of our deps, and it
was deemed "too heavy". We could fork this, if we think this SPECIFIC
case matters, but what's the principle here? Is it "anything that
needs a CLA gets forked"? Or "anything not CNCF gets forked"? Is
that an eager fork or lazy? Are we trying to build community around
our fork(s)? How do we handle drift over time? etc.

Suppose it was some other library for which there was no equivalent
which suddenly sprouted a CLA. I doubt we want to "eagerly" fork.
More likely, I think, we would ride it out until it became an ACTUAL
problem at which point we would discuss that specific case.

Now, I'm not a big fan of go-mock, so I'd be glad to see this get
excised, but that is more opinion than principle :)

Tim

[Josh Berkus]

On 6/18/24 08:30, Tim Hockin wrote:
> I don't think we can prevent them from asking for a CLA. Uber picked
> up an abandoned repo and gave it new life, they have lawyers, they
> make their own rules. Worse, I can't even evaluate their CLA because
> the link in CONTRIBUTING.md takes me to
> https://cla-assistant.io/uber-go/mock which has no information and
> doesn't seem to DO anything (seems broken).

I doubt there's a strategy behind this, it feels like default policy
behavior. I think the first thing we could do as a project is to reach
out to the Uber folks and see if there's some other way to legally
handle these repos; the answer may be "yes".

--
-- Josh Berkus
Kubernetes Community Architect
OSPO, OCTO

[Tim Hockin]

From my experience in a large company with a robust legal team, the
answer was "This is how we do it. Period." I don't think we have any
basis on which to approach companies and demand they go against their
legal team's advice.

I mean, you don't get what you don't ask for, but this is not a strategy.

Tim

[Benjamin Elder]

Dependency management is under the purview of the code organization subproject of SIG Architecture, so adding that list
+kubernetes-sig-architecture 

> But the general issue remains: here we have a non-CNCF project which
is a relatively important dependency for k/k, and at least some
Kubernetes contributors can’t contribute to it.
> 
> Does this bother anyone else?

Yes, this is one of the reasons we enforce the CNCF policy about only using dependencies with approved licenses.

We haven't yet had a policy about contribution agreements, and we ourselves require a CLA, just foundation, not corporate ...

I think we should start by asking politely as suggested above, this was probably a default policy at Uber.

Let's file a tracking issue in kubernetes/kubernetes for more visibility outside of the SIG lists and the outcome of this particular dependency.

[Josh Berkus]

On 6/18/24 09:12, Tim Hockin wrote:
> From my experience in a large company with a robust legal team, the
> answer was "This is how we do it. Period." I don't think we have any
> basis on which to approach companies and demand they go against their
> legal team's advice.
>
> I mean, you don't get what you don't ask for, but this is not a strategy.

It would be easier to ask -- and ASK, not demand -- than maintain our
own fork. If they say "no" we're not any worse off.

Otherwise we're likely to end up in this convo next year:

Uber: Why did you fork mock? We were maintaining it for you.

K8s: it had a CLA that blocked our PRs.

Uber: why didn't you just ask? We could have fixed that.

Also, note that it's not a problem that the project has a CLA *at all*,
it's the terms of the CLA that are the problem, as I understand it.
After all, Kubernetes itself has a CLA. A different CLA might be fine.

[Benjamin Elder]

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-te...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-testing/b0188eff-7dc4-40df-8d1f-c2592b42a12e%40redhat.com.

[Sanchayan Ghosh]

I went through Uber's CLA. Is there any particular provision that would go against Kubernetes?

I see a provision where we give Uber a non revocable transferrable royalty free license to distribute our work (which if we contribute to go-mock , make PRs the existing Apache 2 license gives Uber permission to use our code/contribution).

Let me know if I am missing some concerning provision.

Sanchayan Ghosh

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-testing/CAOZRXm9GkGV4k7nqx-qA73%2BMKFzOm4%2B8poYGa1vrFVfNN8iAmw%40mail.gmail.com.

[John Belamaric]

In my experience with company-specific CLAs, it's not that there are necessarily specific issues with the CLA, it's that legal departments don't have the time to review every different CLA. So, if it's not a standard CLA or something, it's a painful process to get permission to contribute.

You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAChLpQCR95X5f75MEst%3D8%2B%3D6uWw2541F04V%2BXierXJGnBeQMww%40mail.gmail.com.

[Tim Hockin]

At least in the US, work done "off hours" may still belong to your employer.

On Tue, Jun 18, 2024 at 1:32 PM Sanchayan Ghosh
<sanchaya...@gmail.com> wrote:
>
> Small question here. I am new to CLAs in general. When you mean asking legal departments of employers is it needed by all? Or is it only asked if you are contributing from your work time/resources like work devices, open source contribution during work hours etc.
>
> If a company is restrictive towards open source in general, can we still sign CLAs to contribute off work (on our own time, our own systems, on projects that don't at all overlap with our company's tech stack of core offering)?

[Davanum Srinivas]

Stephen,

It's always good to reduce the number of dependencies, from that point of view alone it's worth figuring out if https://github.com/skitt/kubernetes/pull/2 is a way forward, please open a PR so we can test it out.

thanks,

Dims

--

Davanum Srinivas :: https://twitter.com/dims

[Sanchayan Ghosh]

Small question here. I am new to CLAs in general. When you mean asking legal departments of employers is it needed by all? Or is it only asked if you are contributing from your work time/resources like work devices, open source contribution during work hours etc.

If a company is restrictive towards open source in general, can we still sign CLAs to contribute off work (on our own time, our own systems, on projects that don't at all overlap with our company's tech stack of core offering)?

On Wed, 19 Jun, 2024, 1:35 am John Belamaric, <jbela...@google.com> wrote:

[Stephen Kitt]

In Red Hat’s case, legal does review CLAs on request. Specifically
regarding the Uber CLA, the main issue is that of representation — the
CLA requires that “If a legal entity is a copyright owner, in whole or
in part, of the Contribution, You represent and warrant that You are
authorized by such entity to enter into this Agreement on that
entity’s behalf and to bind that entity to this Agreement (in which
case, references to “You” and “Your” in this Agreement–other than in
this sentence–refer to that entity).”

> >> https://groups.google.com/d/msgid/kubernetes-sig-testing/CAOZRXm9GkGV4k7nqx-qA73%2BMKFzOm4%2B8poYGa1vrFVfNN8iAmw%40mail.gmail.com
> >> <https://groups.google.com/d/msgid/kubernetes-sig-testing/CAOZRXm9GkGV4k7nqx-qA73%2BMKFzOm4%2B8poYGa1vrFVfNN8iAmw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "steering" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to steering+u...@kubernetes.io.
> > To view this discussion on the web visit
> > https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAChLpQCR95X5f75MEst%3D8%2B%3D6uWw2541F04V%2BXierXJGnBeQMww%40mail.gmail.com

> > <https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAChLpQCR95X5f75MEst%3D8%2B%3D6uWw2541F04V%2BXierXJGnBeQMww%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .

[Stephen Kitt]

On Tue, Jun 18, 2024 at 10:01:44AM -0700, Benjamin Elder wrote:
> Dependency management is under the purview of the code organization
> subproject of SIG Architecture, so adding that list

> +kubernetes-sig-architecture <kubernetes-si...@googlegroups.com>

Thanks!

> > But the general issue remains: here we have a non-CNCF project which
> is a relatively important dependency for k/k, and at least some
> Kubernetes contributors can’t contribute to it.
> >
> > Does this bother anyone else?
>
> Yes, this is one of the reasons we enforce the CNCF policy about only using
> dependencies with approved licenses.
>
> We haven't yet had a policy about contribution agreements, and we
> ourselves require a CLA, just foundation, not corporate ...

Right, this is one of the possible outcomes I was wondering about.
The fact that k/k requires a CLA (and other CNCF projects can require
a CLA, as long as it’s the CNCF CLA) doesn’t mean that the CNCF
couldn’t have a list of acceptable CLAs for dependencies, or an
exception mechanism to check CLAs, in the same way that it has a list
of acceptable licenses and an exception mechanism, while using a
license too.

CLAs are less of a concern than licenses, since they can be worked
around by forking; but I always prefer to work with communities rather
than around them. After all, maintainers are doing us a service by
maintaining dependencies, and we shouldn’t punish them for that!

> I think we should start by asking politely as suggested above, this was
> probably a default policy at Uber.

I was also hoping for this (no real surprise there, as you can imagine
I discussed this with Josh), mostly so that I didn’t go out and ask on
my own ;-).

> Let's file a tracking issue in kubernetes/kubernetes for more visibility
> outside of the SIG lists and the outcome of this particular
> dependency.

https://github.com/kubernetes/kubernetes/issues/125595

[Stephen Kitt]

On Tue, Jun 18, 2024 at 06:28:41PM -0400, Davanum Srinivas wrote:
> It's always good to reduce the number of dependencies, from that point of
> view alone it's worth figuring out if
> https://github.com/skitt/kubernetes/pull/2 is a way forward, please open a
> PR so we can test it out.

Done: https://github.com/kubernetes/kubernetes/pull/125596

Thanks,

[Josh Berkus]

On 6/18/24 12:47, Sanchayan Ghosh wrote:
> I went through Uber's CLA. Is there any particular provision that would
> go against Kubernetes?
>
> I see a provision where we give Uber a non revocable transferrable
> royalty free license to distribute our work (which if we contribute to
> go-mock , make PRs the existing Apache 2 license gives Uber permission
> to use our code/contribution).

The problem with individual company CLAs is that each contributor needs
their company's legal department to approve them contributing,
individually. Many legal departments (including mine) refuse to do so.

There also may be a specific problem with the terms; I don't know, I'm
not an attorney.

[Davanum Srinivas]

On Thu, Jun 20, 2024 at 6:38 AM Sanchayan Ghosh <sanchaya...@gmail.com> wrote:

> The problem with individual company CLAs is that each contributor needs
their company's legal department to approve them contributing,
individually.  Many legal departments (including mine) refuse to do so.

Is this a problem also with foundation CLAs?

Depends on the company lawyers

 

Or is there a provision that makes foundation CLAs permissive?

Depends on the company lawyers

 

I hope that is the case since a lot of mission critical repos (eclipse, kubernetes, docker) have CLAs and sometimes depending on your personal projects doing a bugfix is often the only way to go.

Depends on the company if they will let you sign a personal CLA or not. Please check with them before you sign stuff or you will be in trouble in certain company/legal jurisdictions  

 

Also is there a list of whitelisted CLAs we can get information about? 

No, there is not white list in the community. it's up to each company, so reach out to your lawyers. 

There is a https://todogroup.org/ which may be a better place for you to ask these sort of questions as we are practitioners here and not policy makers. Also google for "OSPO CLA" as well. There is a list of folks with their own CLA here https://en.wikipedia.org/wiki/Contributor_License_Agreement as well.

Good Luck!

[Sanchayan Ghosh]

> The problem with individual company CLAs is that each contributor needs
their company's legal department to approve them contributing,
individually.  Many legal departments (including mine) refuse to do so.

Is this a problem also with foundation CLAs? Or is there a provision that makes foundation CLAs permissive? I hope that is the case since a lot of mission critical repos (eclipse, kubernetes, docker) have CLAs and sometimes depending on your personal projects doing a bugfix is often the only way to go.

Also is there a list of whitelisted CLAs we can get information about? 

On Wed, 19 Jun, 2024, 11:22 pm Josh Berkus, <jbe...@redhat.com> wrote:

[Sanchayan Ghosh]

Thanks Srinivas 

I didn't know the right place to get clarified on this. Thanks for the resources. Will get my CLA checked.

And will continue discussion in the other link you sent. A really good set of resources here.

[Josh Berkus]

On 6/20/24 03:38, Sanchayan Ghosh wrote:
> Is this a problem also with foundation CLAs? Or is there a provision
> that makes foundation CLAs permissive? I hope that is the case since a
> lot of mission critical repos (eclipse, kubernetes, docker) have CLAs
> and sometimes depending on your personal projects doing a bugfix is
> often the only way to go.

For several companies, the CNCF/LF CLA is preapproved.

I totally get where the lawyers are coming from on this. If you work in
a company that has a few hundred OSS engineers, and they want to
contribute to a few hundred projects, 10% of which have their own
special CLAs? It's like an entire lawyer worth of work.

Anyway, sounds like we have a workaround. Although I still think we
could have asked Uber politely.

[Sanchayan Ghosh]

>For several companies, the CNCF/LF CLA is preapproved.

That's good to know. Of course, best to confirm once.

>I totally get where the lawyers are coming from on this.  If you work in
a company that has a few hundred OSS engineers, and they want to
contribute to a few hundred projects, 10% of which have their own
special CLAs?  It's like an entire lawyer worth of work.

That would be a lot of work. Though that would technically also be the case with foundation CLAs. Since eclipse, CNCF, LF, are just one amongst many other foundations. And as foundations increase so do the CLAs. In any case, atleast with open source license (FOSS license) like Apache, MIT, MIT Expat, etc., lawyers tender to keep an excel sheet of pre approved licensed (atleast in my company) and do add new licensed on request. 

I haven't seen a CLA excel sheet so asked.

Thanks for the insight on this. Extremely helpful advice from everyone!