Kubernetes license scanning

[jdumars]

This comes from an email to Steering@

Hello Kubernetes maintainers,

I'm running the Linux Foundation's license scanning and analysis services for several LF projects. For CNCF's IP policy and its new license whitelist (approved at the May Governing Board meeting), going forward I'll be running and providing monthly scan reports for CNCF projects, including Kubernetes.

Attached are two spreadsheets showing the license notices found in the kubernetes and kubernetes-client orgs' code repos as of July 3. (Future results will be available through a web interface and in other file formats.) This report shows licenses actually contained in the source code repos, and does not address external dependencies pulled in at build-time or run-time.

Apache-2.0 files are under CNCF's project license, and many of the "Attribution" licenses will be auto-approved under CNCF's whitelist policy. For the remainder, I'll work with CNCF's IP Committee to review and discuss recommending approvals by the Governing Board.

In preparation for that, I have a few questions for you, focusing on the key findings. If you'd prefer that I submit issues in Github for these, I'm happy to do so -- just let me know. But for #1 and #2 in particular I wanted to raise these first with the maintainer list, in light of the particular license issues.

1. The component github.com/heketi/heketi is used in four repos. Heketi uses a mix of licenses, but the main issue is that files in heketi/pkg/utils/ can only be used under LGPL-3.0 or GPL-2.0, both of which are likely problematic here. Can the files in heketi/pkg/utils/ be removed, or replaced with an alternative library under a more permissive license?
   The repos are: kubernetes, minikube, autoscaler/cluster-autoscaler, and contrib/rescheduler

2. There are GPL-2.0 LICENSE text files in the github.com/docker/docker component, within the contrib/selinux-* subfolders in four repos. There is no corresponding code in these directories. Can these directories and LICENSE files be removed?
   The repos are: cloud-provider-aws, federation, kops and test-infra

3. The component github.com/juju/ratelimit is under LGPL-3.0 with a linking exception. It was replaced in the main kubernetes repo in #38320 to use golang.org/x/time/rate instead. juju/ratelimit is still present in several other kubernetes repos; can these be similarly updated to the alternate library?
   The repos are: autoscaler/addon-resizer, contrib (in diurnal, docker-micro-benchmark, election, keepalived-vip, scale-demo and service-loadbalancer), dashboard, dns, federation, frakti, heapster, kompose, kube-deploy, node-problem-detector, perf-tests, and test-infra.

4. The component gopkg.in/yaml.v2 used to have the same LGPL-3.0 license, but has now been updated in the kubernetes repo to a newer version with Apache-2.0. Several other repos still use the old version under LGPL-3.0; can these also be updated?
   The repos are: autoscaler/addon-resizer, contrib (in diurnal, docker-micro-benchmark, election, keepalived-vip, podex, scale-demo and service-loadbalancer), dashboard, federation, heapster, kube-deploy, node-problem-detector, perf-tests, publishing-bot and test-infra.

5. In minikube, there is a config file which states that it is part of systemd and is under LGPL-2.1. Most of the file is commented out. Is it necessary to distribute this file, or could it be obtained by the downstream user separately (along with systemd, which I assume we aren't distributing)?

6. In kops, /hooks/nvidia-bootstrap/README.md says that "Using this hook indicates that you agree to" a non-OSS license from NVIDIA. Is this intended to refer to software separately installed by the Dockerfile, rather than code in the kops repo itself? If so, I may propose a tweak to the language here.

7. In the translations/ folder in kubernetes, there are 12 files stating that "This file is distributed under the same license as the PACKAGE package." (e.g., here) Can these be corrected to refer to Kubernetes specifically?

8. In the kubernetes-client javascript repo, a package.json file was added stating that the kubernetes-client-typescript package is under the Unlicense. Can this be corrected to Apache-2.0?

Going forward I will likely have other suggestions and questions around licenses, but those above will help me to prepare Kubernetes for review and approval by the IP Committee / GB.

Thanks again for all your help, and please let me know if you have any questions. Best,
Steve

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
swinslow@linuxfoundation.org

[cblecker]

/cc
related to: https://github.com/kubernetes/kubernetes/issues/44505

[philips]

Asked SIG release and SIG contribx: https://groups.google.com/forum/#!topic/kubernetes-sig-release/6oljCwkD6HQ

[philips]

I am assigning this to @justaugustus because he volunteered to hunt this down via SIG Release.

@justaugustus I think some great next steps would be:

• Writing a doc for handling these audits for SIG release
• Creating an umbrella issue on https://github.com/kubernetes/sig-release/issues
• File issues/PRs with the various sub projects to fix their individual issues
• Come back here and note when everything is closed out

ref: https://groups.google.com/d/msg/kubernetes-sig-release/6oljCwkD6HQ/L2KnInDBAgAJ

[swinslow]

Hi @justaugustus, I'm running the license scanning process for CNCF projects and I prepared the scan report that's included at the top of this issue.

I'm happy to work with you on this, the license scanning process and the action items described above. If you want to reach out to me directly (swinslow@linuxfoundation.org), we can chat and discuss next steps. I really appreciate your volunteering to help with this.

[justaugustus]

@philips -- will do!

@swinslow -- sounds good! I'll ping you next week. :)

[cblecker]

also relevant: https://github.com/kubernetes/kubernetes/issues/44505

[spiffxp]

Per discussion in 2018-07-18 steering meeting I kicked this into backlog as we're not really doing much on this right now, will pull into a future sprint to check back in on progress

[jdumars]

Discussed 20180718: https://youtu.be/I6BwkOA9dn4?t=49m22s

[thockin]

The parts I can answer easily...

The component github.com/heketi/heketi is used in four repos. Heketi uses a mix of licenses, but the main issue is that files in
heketi/pkg/utils/ can only be used under LGPL-3.0 or GPL-2.0, both of which are likely problematic here. Can the files in
heketi/pkg/utils/ be removed, or replaced with an alternative library under a more permissive license?

heketi/pkg/utils is used by heketi/client/api/go-client which is used by exactly one package in k/k - glusterfs (not surprising since that is what heketi is about). It may require re-writing that module.

There are GPL-2.0 LICENSE text files in the github.com/docker/docker component, within the contrib/selinux-* subfolders in
four repos. There is no corresponding code in these directories. Can these directories and LICENSE files be removed?

We'd need to figure out why godep is including this.

The component github.com/juju/ratelimit is under LGPL-3.0 with a linking exception. It was replaced in the main
kubernetes repo in #38320 to use golang.org/x/time/rate instead. juju/ratelimit is still present in several other
kubernetes repos; can these be similarly updated to the alternate library?

We were previously advised that the linking exception covered Go because it is statically linked. Does LF feel differently?

The component gopkg.in/yaml.v2 used to have the same LGPL-3.0 license, but has now been updated in the
kubernetes repo to a newer version with Apache-2.0. Several other repos still use the old version under LGPL-3.0;
can these also be updated?

Same question. That said, it PROBABLY can be updated...

In minikube, there is a config file which states that it is part of systemd and is under LGPL-2.1. Most of the file is
commented out. Is it necessary to distribute this file, or could it be obtained by the downstream user separately
(along with systemd, which I assume we aren't distributing)?

In kops, /hooks/nvidia-bootstrap/README.md says that "Using this hook indicates that you agree to" a non-OSS
license from NVIDIA. Is this intended to refer to software separately installed by the Dockerfile, rather than code
in the kops repo itself? If so, I may propose a tweak to the language here.

@vishh

In the translations/ folder in kubernetes, there are 12 files stating that "This file is distributed under the same license
as the PACKAGE package." (e.g., here) Can these be corrected to refer to Kubernetes specifically?

seems plausible. @brendandburns

In the kubernetes-client javascript repo, a package.json file was added stating that the kubernetes-client-typescript
package is under the Unlicense. Can this be corrected to Apache-2.0?

github search can't find this - what path?

[vishh]

In minikube, there is a config file which states that it is part of systemd and is under LGPL-2.1. Most of the file is commented out. Is it necessary to distribute this file, or could it be obtained by the downstream user separately (along with systemd, which I assume we aren't distributing)?

@dlorenc ^^

In kops, /hooks/nvidia-bootstrap/README.md says that "Using this hook indicates that you agree to" a non-OSS
license from NVIDIA. Is this intended to refer to software separately installed by the Dockerfile, rather than code
in the kops repo itself? If so, I may propose a tweak to the language here.

The actual Nvidia SW is installed by the docker container and is not distributed as part of kops AFAIK. cc @justinsb to facilitate updating the language in the Readme.

[dlorenc]

In minikube, there is a config file which states that it is part of systemd and is under LGPL-2.1. Most of the file is commented out. Is it necessary to distribute this file, or could it be obtained by the downstream user separately (along with systemd, which I assume we aren't distributing)?

Do you have a link to the file? We do distribute a Linux distro (as a .iso file) which contains systemd.

[swinslow]

Thanks all for your feedback here.

@thockin For ratelimit and yaml.v2, the linking statement only provides an exception to a couple subsections of LGPL-3.0. The concern is that other provisions of LGPL-3.0 may not align with usage under Apache-2.0.

For the Unlicense reference, the fix has now been merged in kubernetes-client/javascript#61.

@vishh @justinsb Thanks for confirming on the NVIDIA code; I'll send you a separate note on slightly clarifying the license language there.

@dlorenc The file I mentioned is at /deploy/iso/minikube-iso/board/coreos/minikube/rootfs-overlay/etc/systemd/journald.conf. Apologies, the links from my original email didn't copy over into this issue.

[justaugustus]

Email update to steering + sig-release + sig-contribex: https://groups.google.com/d/msg/kubernetes-sig-release/6oljCwkD6HQ/sH8W-uwwAAAJ

[nikhita]

also relevant: kubernetes/kubernetes#44505

@cblecker 👍 we should definitely be making this automated.

quick update on heketi: Have asked the maintainers if they could update the license (instead of us updating our code) since it could have been a side-effect of a whole sale licensing change - heketi/heketi#1279.

[spiffxp]

/committee steering

[nikhita]

Fyi: The following repos did not have the LICENSE file. I have created PRs to add them:

• kubernetes-client/go - Add LICENSE kubernetes-client/go#19
• kubernetes-client/go-base - Add LICENSE kubernetes-client/go-base#10
• kubernetes/cloud-provider-sample - Add template files cloud-provider-sample#1

[dims]

a recent FOSSA scan on kubernetes/kubernetes run by @justaugustus is here : https://s3.amazonaws.com/blob.fossa.io/FOSSA_BOMS/162/REPORT_kubernetes_1547780670928.html?AWSAccessKeyId=AKIAJEGBNPHNC7DM3S3A&Expires=1547927840&Signature=2eVXu7KZwzyX2LYuSqDbGesh26I%3D

Looks like we may have a MPL 2.0 dependency from https://github.com/hashicorp/golang-lru we'll have to check with folks if that's acceptable.

[justaugustus]

The link above expired, so providing this one for passerbys (it will always pull the latest results): https://app.fossa.io/reports/dce31219-52a8-4d88-903d-3885f427bba6

[dims]

We now have a sig-release sub project meeting (hoping to get a regular schedule for it) : https://docs.google.com/document/d/147eeNq72lreANWNtL1HWJYbAYMfQoB7S_2sG8ycQ8_g/edit?usp=sharing

Please see approved licenses here : https://docs.google.com/presentation/d/1tbH15qF7bXOp8veRKHlWSeH6w1NWkMN3qmIwB6LvvgU/edit#slide=id.p1

And a recent scan by CNCF folks : https://docs.google.com/spreadsheets/d/1uPk6Q4CUbYOwOtTIP6Fm_m0arOkd16MbPU2zGqPi1VY/edit#gid=1724209879

Another thing to note is that the CNCF Governing Board recently "blessed" some of the packages we use that had licenses NOT in the whitelist. Example a bunch of hashicorp ones that use MPL 2.0:

• github.com/hashicorp/golang-lru
• github.com/hashicorp/errwrap
• github.com/hashicorp/go-cleanhttp
• github.com/hashicorp/go-multierror

[swinslow]

Thanks @dims. One clarification: the dependencies you mentioned were recommended for approval as license exceptions by the CNCF IP committee, and are pending approval by the GB; the formal GB vote to approve has not yet occurred.

[justaugustus]

@swinslow -- just for visibility, do we know when that vote will be?

[dims]

Ack thanks for the revision @swinslow :)

[dankohn]

The vote will be in March, but I assure you that the GB does not want to delay Kubernetes releases. If you're following the guidance in those documents (e.g., avoiding blacklisted licenses), you should go forward with the regular release process. If we come upon problems, or the GB requests a change in policy, we will work with SIG-release to find alternative libraries.

[nikhita]

I have created kubernetes/community#3231 to add the list of whitelisted licenses to k/community.

[tpepper]

See kubernetes/sig-release#223

[bgrant0607]

SIG Release is tracking this now.

[countspongebob]

There is no current public and complete list of exceptions, tracking the request to create such a list here:
cncf/foundation#45

[dims]

Looks like this is done https://github.com/cncf/foundation/tree/master/license-exceptions