Question: Can vendor LGPL3 Go code be included? #35557
Comments
bgrant0607
added
team/none
sig/contributor-experience
|
We should file a separate issue about this somewhere (maybe not in this repo): We need an official, documented policy about which licenses are permitted. Probably some subset of these: cc @kubernetes/contributor-experience |
|
This is one of the places where I would like to get CNCF Legal advice. @dankohn and or @caniszczyk can you work with the LF lawyers to list CNCF acceptable licenses for /vendor within our project? |
|
@sarahnovotny alright, we'll put this on the list, it's not super clear in the CNCF Charter's IP Policy, but we would lean towards permissive licensed options (ASL, MIT etc) @lpabon I'd give you advice to keep the Apache license here was going to a less permissive license isn't the best idea for adoption IMHO (also license changes are never fun) |
|
@caniszczyk I am not a lawyer, but if I get it right, the IP section of the CNCF charter is relevant for contributions to the actual project's code, not so much for the external project's code included under vendor/ - correct? And I appreciate the hint regarding adaption, but the major question here is whether relicensing the heketi parts (under vendor/) to LGPLv3 would be problematic for the kubernetes project. We'll care about the broader adaption separately. |
|
@obnoxxx we would really prefer permissive licenses and licenses that match the parent project, it simplifies distribution, thanks! |
|
Issues go stale after 30d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
k8s-ci-robot
added
the
lifecycle/stale
|
It appears that heketi decided on a license: https://github.com/heketi/heketi/blob/master/LICENSE Note that the CNCF charter applies to both the licenses of a project's code and its dependencies, and that there are concerns with LGPLv3. But since this project is dual-licensed, that doesn't apply. |
|
We still have files that are just We had a couple of attempts from our side in #67448 and #66305, but we cannot fix it in k/k repository. Please see heketi/heketi#1279 that tracks the problem in heketi repo |
|
FWIW, the intent in the https://github.com/heketi/heketi/blob/master/LICENSE is very clear, However it does not match the files we need for GlusterFS in-tree plugin to work in k/k |
|
/remove-lifecycle stale |
k8s-ci-robot
removed
the
lifecycle/stale
|
/sig release cc @kubernetes/steering-committee |
k8s-ci-robot
added
sig/release
|
@dims do we have a tracking issue on the steering board that we can cross ref? |
|
Is it something we think will land in 1.13 with Code freeze on 11/16? I am adding the 1.13 milestone anyway to keep this in our radar /milestone v1.13 |
|
/priority important-soon |
k8s-ci-robot
added
the
priority/important-soon
|
if we are targeting this for 1.13, the Code freeze date is 11/16. |
|
@AishSundar we are trying our best to get this for |
|
@dims apologies for the lack of updates in heketi issue. We are on it :) |
|
/milestone none |
|
@AishSundar: The provided milestone is not valid for this repository. Milestones in this repository: [ Use In response to this:
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/test-infra repository. |
|
/milestone clear |
In a sequence of commits fc8e4c5 31b83a8 7c3cd4c Heketi was relicensed from Apache to the following model: - the rest api client code is under dual Apache2 or LGPLv3+ - all other parts (server, cli, tests, ...) are under dual LGPLv3+ or GPLv2 Now an oversight/mistake was made in that parts of the pkg/utils are used in the client and hence apache-licensed projects that compile in heketi client, like kubernetes, have a license problem since they pull GPL code in. See: heketi#1279 kubernetes/kubernetes#35557 kubernetes/kubernetes#70802 This patch fixes the oversight by relicensing the remaining pieces of pkg/utils to the same dual Apache2 or LGPLv3+ license after those parts that are only used in the server have been moved out of pkg/utils. Resolves: heketi#1279 Signed-off-by: Michael Adam <obnox@redhat.com> Signed-off-by: John Mulligan <jmulligan@redhat.com>
In a sequence of commits fc8e4c5 31b83a8 7c3cd4c Heketi was relicensed from Apache to the following model: - the rest api client code is under dual Apache2 or LGPLv3+ - all other parts (server, cli, tests, ...) are under dual LGPLv3+ or GPLv2 Now an oversight/mistake was made in that parts of the pkg/utils are used in the client and hence apache-licensed projects that compile in heketi client, like kubernetes, have a license problem since they pull GPL code in. See: #1279 kubernetes/kubernetes#35557 kubernetes/kubernetes#70802 This patch fixes the oversight by relicensing the remaining pieces of pkg/utils to the same dual Apache2 or LGPLv3+ license after those parts that are only used in the server have been moved out of pkg/utils. Resolves: #1279 Signed-off-by: Michael Adam <obnox@redhat.com> Signed-off-by: John Mulligan <jmulligan@redhat.com>
|
heketi license issue has been taken care of /close |
|
@dims: Closing this issue. In response to this:
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/test-infra repository. |
In our GlusterFS storage manager we are contemplating changing our license from Apache 2 to LPGL 3.
Currently this code is used in the vendor/... for the storage dynamic provisioner of GlusterFS. Would there be any conflicts if we change license?
I also noticed that the Yaml code is currently using a LGPL3 with a clause to allow static linking, although they changed their license in their repo to Apache 2.
The text was updated successfully, but these errors were encountered: