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

[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

[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.

[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:

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.

[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

On Tue, Jun 18, 2024 at 4:05 PM John Belamaric <jbela...@google.com> wrote:

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.

On Tue, Jun 18, 2024 at 1:02 PM Sanchayan Ghosh <sanchaya...@gmail.com> wrote:

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.

--

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

[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]

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).”

On Tue, Jun 18, 2024 at 01:05:11PM -0700, John Belamaric wrote:
> 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.
>
> On Tue, Jun 18, 2024 at 1:02 PM Sanchayan Ghosh <sanchaya...@gmail.com>
> wrote:
>

> >> 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 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.

[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? 

[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!

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

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.

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

[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!