Ensure Kubeflow meets the CNCF IP Policy

[annajung]

Part of cncf/toc#1139

As part of CNCF onboarding, the Kubeflow community must fulfill the CNCF IP Policy.

This issue will be used to track progress toward meeting the CNCF IP Policy requirements.

Status	Owner	Policy
In progress (ref)	Google + CNCF	(a) Any project that is added to the CNCF must have ownership of its trademark and logo assets transferred to the Linux Foundation.
In progress	@jbottum @james-jwu @theadactyl + @rimolive	(b) Each project shall determine whether it will require use of an approved CNCF CLA. For projects that select to use a CLA, all code contributors will undertake the obligations set forth in the Apache contributor license agreement(s), altered only as necessary to identify CNCF as the recipient of the contributions, and which shall be approved by the Governance Board. See CNCF Contributor License Agreements available at https://github.com/cncf/cla. The process for managing contributions in accordance with this policy shall be subject to Governance Board approval.
		(c) All new inbound code contributions to the CNCF shall be (i) accompanied by a Developer Certificate of Origin sign-off (https://developercertificate.org/) and (ii) made under the Apache License, Version 2.0 (available at https://www.apache.org/licenses/LICENSE-2.0), such license to be in addition to, and shall not supersede, obligations undertaken under the contribution license agreement(s) provided for in (b) above.
Completed		(d) All outbound code will be made available under the Apache License, Version 2.0.
Completed (ref)		(e) All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.
Completed (ref)		(f) All documentation will be received and made available by the CNCF under the Creative Commons Attribution 4.0 International License.
		(g) If an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project or is otherwise required to achieve the CNCF’s mission, the Governing Board may approve the use of an alternative license for inbound or outbound contributions on an exception basis.

Interim Steering Committee @james-jwu @theadactyl @jbottum
Katib: @andreyvelich @gaocegege @johnugeorge @tenzen-y
Manifests: @elikatsis @kimwnasptd @PatrickXYS @StefanoFioravanzo @yanniszark @juliusvonkohout
MPI Operator: @alculquicondor @rongou @terrytangyuan
Notebooks: @elikatsis @kimwnasptd @thesuperzapper @StefanoFioravanzo @yanniszark
Pipelines: @chensun @zijianjoy @james-jwu @IronPan
Pipelines on Tekton: @animeshsingh @ckadner @fenglixa @pugangxa @ScrapCodes @Tomcli @yhwang
Training Operators: @gaocegege @Jeffwan @johnugeorge @zw0610 @terrytangyuan @tenzen-y @andreyvelich

[annajung]

(e) All projects evaluated for inclusion in the CNCF shall be completely licensed under an OSI-approved open source license. If the license for a project included in CNCF is not Apache License, Version 2.0, approval of the Governing Board shall be required.

Hi WG leads, could you confirm that your components are licensed under an OSI-approved open source license to meet the required (e) stated under CNCF IP Policy?

This is related to https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md#approved-licenses-for-allowlist which is part of #656

[alculquicondor]

I can confirm that mpi-operator is licensed as Apache 2.0

[Tomcli]

KFP-Tekton is licensed under Apache 2.0.

[annajung]

Sorry folks, looks like simple look up of LICENSE files in each repo would be sufficient for the requirement (e).
I can confirm that each WG do have LICENSE file and are licensed under Apache 2.0 as listed below

• Katib https://github.com/kubeflow/katib/blob/master/LICENSE
• Manifests https://github.com/kubeflow/manifests/blob/master/LICENSE
• MPI Operator https://github.com/kubeflow/mpi-operator/blob/master/LICENSE
• Notebooks https://github.com/kubeflow/kubeflow/blob/master/LICENSE
• Pipelines https://github.com/kubeflow/pipelines/blob/master/LICENSE
• Pipelines on Tekton https://github.com/kubeflow/kfp-tekton/blob/master/LICENSE
• Training Operators https://github.com/kubeflow/training-operator/blob/master/LICENSE

No additional action is needed for requirement (e), unless you want to add any comments.

[annajung]

Hi everyone, I am no longer able to continue on this issue, but @rimolive has volunteered to work on Kubeflow CLA/DCO migration with the interim steering committee to ensure Kubeflow meets the CNCF IP Policy and to update GitHub to ensure DCO or CLA are enabled for all GitHub repositories of the project.

Completion of the tasks should allow this issue to be closed and should be reported back to the main issue cncf/toc#1139 as well. Thanks!

[jbottum]

@rimolive - James Wu and I discussed in Kubeflow Steering Committee call. We approved this migration to the CNCF CLA/DCO. Do we need to enable one or both of these options ?

[thesuperzapper]

@jbottum The CLA is much more comprehensive than the standard DCO (and we currently don't have a DCO requirement, so it would require contributors to start using the "sign-off" section at the end of their commits if we adopted it).

[jbottum]

@thesuperzapper I tend to agree with your analysis. I propose to start with the CNCF CLA option (only). If some contributors find that unusable and they want/need the DCO, then we can add DCO. @james-jwu - your thoughts ?

[rimolive]

@jbottum I added an item in the next Kubeflow Community meeting to discuss the differences.

[terrytangyuan]

I'd recommend using DCO. Argo project has switched from CLA to DCO before and here's our rationale:

CNCF provides support for implementing both the DCO and CLA. Choice of one over the other is left to each CNCF project. Neither is currently viewed as providing stronger legal protection than the other.

The Linux kernel as well as most CNCF projects use the DCO. The DCO is viewed as a more developer-friendly alternative to the CLA.

[james-jwu]

@terrytangyuan The Linux kernel as well as most CNCF projects use the DCO. - do you have a sense of how DCO adoption percentage-wise?

[terrytangyuan]

@james-jwu I don't know specific percentage (perhaps CNCF can get us a number) but I just randomly picked several graduated projects and they all seem to use DCO.

[rimolive]

@james-jwu I did that research. 22 out of 24 Graduated CNCF projects are confirmed that they use DCO. I have more info to share in the next Kubeflow community meeting.

[rimolive]

Bumping this issue. Since KSC agreed to use DCO and it is implemented the PR checks in Kubeflow repositories, can we consider it done? Or there are still missing action items?

[juliusvonkohout]

This is probably something that can be decided in the community call or KSC meeting.

[terrytangyuan]

DCO/CLA related requirements are met. There's one remaining item from this list though:

(a) Any project that is added to the CNCF must have ownership of its trademark and logo assets transferred to the Linux Foundation.

Looks like @zijianjoy is working on it based on cncf/toc#1139 (comment). @zijianjoy Can you confirm that this is done?

[zijianjoy]

DCO/CLA related requirements are met. There's one remaining item from this list though:

(a) Any project that is added to the CNCF must have ownership of its trademark and logo assets transferred to the Linux Foundation.

Looks like @zijianjoy is working on it based on cncf/toc#1139 (comment). @zijianjoy Can you confirm that this is done?

https://github.com/amye is going to be the best person for sharing the progress on this item.

[terrytangyuan]

@amye Do you have an update on that? Thanks!

[amye]

You'll want to do this over in the TOC repo, we have cncf/toc#1139 open for you!

[zijianjoy]

We have enabled DCO for Kubeflow, as a result, I believe the CNCF IP Policy item is completed. I am going to close this item as finished, feel free to comment if not the case.