Skip to content
This repository has been archived by the owner on Jul 6, 2023. It is now read-only.

licensing of pkg/utils/ is confusing #1279

Closed
sigma opened this issue Jul 23, 2018 · 40 comments · Fixed by #1419
Closed

licensing of pkg/utils/ is confusing #1279

sigma opened this issue Jul 23, 2018 · 40 comments · Fixed by #1419
Labels
bug
Milestone
Sort out utils li...

Comments

@sigma
Copy link
Contributor

sigma commented Jul 23, 2018

Kind of issue

Bug

Observed behavior

As it is, the files in pkg/utils are dual-licensed under LGPLv3 and GPLv2.
But at the same time, the package is a dependency of client/api/go-client, which is dual-licensed under LGPLv3 and Apache 2

Expected/desired behavior

It would seem more logical to have the same approach as with pkg/glusterfs/api, which is also dual-licensed under LGPLv3 and Apache 2, as it provides a clearer path to downstream consumers who decide to take the client code under that Apache 2 terms.

Thanks for any clarification !
@nikhita
Copy link

nikhita commented Aug 12, 2018

This is turning problematic for us in kubernetes (see kubernetes/sig-release#223, kubernetes/steering#57).

@obnoxxx can pkg/utils be dual-licensed under LGPLv3 and Apache 2? Also, @sigma's comment in kubernetes/kubernetes#66305 (comment) has some more context.

/cc @justaugustus @swinslow

This was referenced Aug 12, 2018
Closed
Closed
Closed
@sigma sigma mentioned this issue Aug 15, 2018
Closed
@obnoxxx
Copy link
Contributor

obnoxxx commented Aug 15, 2018 •
edited

@sigma Thanks for filing this! Originally we meant to license only the needed parts (those that are required for compiling into kubernetes) under apache2 (+LGPL) and keep everything else under GPL/LGPL. There must have been an oversight, or else some dependency was introduced later.

We will make sure to have the licensing issue fixed.

Snide remark: Of course an alternative solution would be to give kubernetes a real open source license, aka a flavor of (L)GPL. ;-)

@obnoxxx obnoxxx added this to the Release 9 milestone Sep 12, 2018
@obnoxxx obnoxxx added the bug label Sep 19, 2018
@obnoxxx
Copy link
Contributor

obnoxxx commented Sep 19, 2018

We started cleaning up pkg/utils in PR #1357 as a first prep step for fixing the licensing.

@nikhita
Copy link

nikhita commented Sep 20, 2018

@obnoxxx Thanks for the update!

@obnoxxx obnoxxx modified the milestones: Release 9, Future, Sort out utils licensing Sep 27, 2018
@dims
Copy link

dims commented Oct 13, 2018

@obnoxxx thanks for driving the cleanup of pkg/utils. Looks like 3 files in there that we need were originally Apache License as you mentioned earlier.

Hope i am not over-stepping my bounds with my suggestion here... Is restarting from the files with old licenses acceptable?

So if i picked the old files (with the original licenses) and then layered the patches that were applied to them in a branch. If this is acceptable, i can open a PR. Please take a look at:

511022b...dims:restore-licenses-in-pkg-utils

cc @raghavendra-talur @jarrpa @lpabon @nixpanic as their patches are re-applied after we revert the changes (and start basically back) from 4a31dd8

@nixpanic
Copy link
Contributor

nixpanic commented Oct 14, 2018 via email

@lpabon
Copy link
Contributor

lpabon commented Oct 17, 2018 •
edited

Thanks for including me on this, but I passed the project along to Red Hat more than a year ago when I went to Portworx.

@dims
Copy link

dims commented Oct 17, 2018

@obnoxxx @phlogistonjohn your thoughts please?

@obnoxxx
Copy link
Contributor

obnoxxx commented Oct 17, 2018

We established the model of a dual licensing scheme of Apache license v2 or LGPLv3+ for those parts that need to be linked into kubernetes. Going back to only Apache is at this time not a good option any more. I prefer to re-license to Apachev2 or LGPLv3+. We are working on it. Cleaning up pkg/utils (moving out stuff that is not needed in the client) and will re-license afterwards. As we do this, we are also planning to fix the relationship with the external heketi/utils repo.

@dims
Copy link

dims commented Oct 17, 2018

@obnoxxx thanks for your response. that sounds good! some of us here would like to help, if there are things we can do, please let us know.

if possible we would like to get this into kubernetes 1.13, please see schedule at https://github.com/kubernetes/sig-release/tree/master/releases/release-1.13. So looks like we should shoot for latest by Nov 9th. Is this possible?

Thanks,
DIms

@dims
Copy link

dims commented Oct 18, 2018

@obnoxxx, Looks like there are only 3 files in pkg/utils and all are used in the rest api scenario, So is it enough to do this? dims@9325fc2

Or should we update https://github.com/heketi/utils with the changes needed first and then switch over to using the file from there?

@humblec
Copy link
Contributor

humblec commented Oct 22, 2018

Thanks @dims for the PR. We will get this done at the earliest.

@obnoxxx
Copy link
Contributor

obnoxxx commented Oct 22, 2018 •
edited

@dims the plan is to move stuff from https://github.com/heketi/utils into the heketi main repo, relicense the in-tree copy of pgk/utils, and stop using the external one entirely. There's no real point in that external repo anyways (it's a kitchen sink of misc stuff and I doubt anyone outside heketi is actually using it).

Bare with us, we'll soon be there...

@obnoxxx
Copy link
Contributor

obnoxxx commented Oct 22, 2018

@dims, oh, I see you referenced a patch (@humblec that is not technically a PR, btw... ;-) ). This is indeed pretty much what's needed for the current content of the pkg/utils dir, and what I wanted to propose today (or so) anyways. And I'd be usually happy to take it from you (with some modification of the commit msg), but in this kind of fundamental and critical licensing issue, we might prefer that the patch comes from one of the repo maintainers. We'll discuss and have a PR up this way or another, soon.

@obnoxxx
Copy link
Contributor

obnoxxx commented Oct 22, 2018

@dims and yeah, Nov 9 should not be an issue!

@dims
Copy link

dims commented Oct 22, 2018

@obnoxxx AWESOME! thanks. yes, that's why i hesitated to start a PR :) (fundamental and critical licensing issue)

phlogistonjohn added a commit to phlogistonjohn/heketi that referenced this issue Oct 22, 2018
@phlogistonjohn
reintroduce rest framework into source tree
ab664e6 
This change takes the source files for the formerly external
"heketi/rest" package and makes it a server utility library
(under "heketi/heketi/server/rest") with a license updated
to match the other server components.

The imports of the source files are adjusted to match the
internal "pkg/" utility packages, rather than the external
"heketi/utils" package.

This change is part of the effort to standardize and unify
licensing of the heketi packages as noted in issue heketi#1279.
With this change the heketi server always uses the updated
in-tree utility functions.

Signed-off-by: John Mulligan <jmulligan@redhat.com>
@dims
Copy link

dims commented Nov 5, 2018

@obnoxxx @humblec, Any updates? we are close to Nov 9. thanks in advance!

@dims dims mentioned this issue Nov 8, 2018
Closed
@justaugustus
Copy link

@obnoxxx @humblec -- Would you mind providing an update on this? We're dangerously close to the end of the Kubernetes 1.13 release cycle and will soon have to make a decision about whether or not we can actually continue to include the GlusterFS in-tree plugin in this licensing state.

Please let us know as soon as you can. Thanks in advance!

cc: @swinslow @AishSundar @spiffxp @tpepper

@humblec
Copy link
Contributor

humblec commented Nov 8, 2018

@obnoxxx Can we address this issue in priority here in this repo ? As soon as its done , I can pull the changes in kubernetes vendor tree , We have limited time in hand for 1.13 release

@humblec
Copy link
Contributor

humblec commented Nov 8, 2018

@justaugustus I am working with heketi maintainers ( @obnoxxx @phlogistonjohn @raghavendra-talur ) to get this done in full priority.

@justaugustus
Copy link

Thanks, @humblec! Please keep myself, @tpepper, @dims, and the Release Team in the loop as you make progress.

@humblec
Copy link
Contributor

humblec commented Nov 8, 2018

@justaugustus sure!! iic, this has to be done before 11/16 , can you please confirm ?

@childsb
Copy link

childsb commented Nov 8, 2018

code freeze for kube is next week, they are wanting this updated before the freeze i believe.

@humblec
Copy link
Contributor

humblec commented Nov 8, 2018

code freeze for kube is next week, they are wanting this updated before the freeze i believe.>

@childsb Yep, so I think its on 11/16.

@childsb
Copy link

childsb commented Nov 8, 2018

@humblec sorry i should have been clear.. the KUBE code freeze is next week and we need the change here in time to pickup before code freeze.. so ideally its updated here by 11/12 or 11/13 so we can make the change in kube before the freeze.

@humblec
Copy link
Contributor

humblec commented Nov 8, 2018

@humblec sorry i should have been clear.. the KUBE code freeze is next week and we need the change here in time to pickup before code freeze.. so ideally its updated here by 11/12 or 11/13 so we can make the change in kube before the freeze.

Agreed. Even I should have been clear :) , what I meant was the change should be merged in kube before `11/16. Thanks :)

@justaugustus
Copy link

Yep. Echoing what you both said. Sooner is always better to allow us to get through approvals and ensure CI signal is clean going into the freeze.

@AishSundar
Copy link

Huge +1 to getting the upstream Heketi change in by this week (11/6) or early next week, so we can have the k/k changes merged by 1.,13 Code freeze on 11/6. Thanks all for working on this.

@AishSundar
Copy link

Here's the tracking issue to update licenses on k/k end kubernetes/kubernetes#70802

@obnoxxx
Copy link
Contributor

obnoxxx commented Nov 8, 2018

@childsb writes:

@humblec sorry i should have been clear.. the KUBE code freeze is next week and we need the change here in time to pickup before code freeze.. so ideally its updated here by 11/12 or 11/13 so we can make the change in kube before the freeze.

Apologies for the delay. We did work on the prep stuff in the background, but got derailed again and again... Will look into this now. Update here by 11/12 of 11/13 should be doable. Thanks for extending the original statement of 11/09 somewhat. :-)

@thockin
Copy link

thockin commented Nov 8, 2018

I'm going to prep a PR to rip gluster out of Kubernetes, just in case we can't get this sorted in time.

obnoxxx added a commit to obnoxxx/heketi that referenced this issue Nov 8, 2018
@obnoxxx
pkg/utils: relicense to dual Apache2 and LGPLv3+
e2144c3 
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>
@obnoxxx obnoxxx mentioned this issue Nov 8, 2018
Merged
@obnoxxx
Copy link
Contributor

obnoxxx commented Nov 8, 2018

PR #1419 has just been created to address this.

@thockin writes:

I'm going to prep a PR to rip gluster out of Kubernetes, just in case we can't get this sorted in time.

Threatening almost always works. :-) I hope your patch won't be necessary...

@thockin
Copy link

thockin commented Nov 8, 2018

@obnoxxx Thanks! :)

It wasn't a threat - as per sig-architecture today, this was my AI. :)

to k8s folks: is this the last directory we need fixed?

@obnoxxx
Copy link
Contributor

obnoxxx commented Nov 8, 2018

@thockin ok, thanks for the clarification! :-)

@dims
Copy link

dims commented Nov 8, 2018

@thockin we ( not me! but @humblec ) did a test run of what is in heketi repo currently ( https://patch-diff.githubusercontent.com/raw/kubernetes/kubernetes/pull/70811.patch ). pretty sure that's the last directory as of what's in there today.

Thanks,
Dims

obnoxxx added a commit that referenced this issue Nov 9, 2018
@obnoxxx
pkg/utils: relicense to dual Apache2 and LGPLv3+
558b292 
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>
@justaugustus
Copy link

Thank you everyone for rallying so quickly on this!!

@AishSundar
Copy link

Thanks so much all. I will ping the k/k issue to take it from here.

@humblec
Copy link
Contributor

humblec commented Nov 9, 2018

@AishSundar I have updated the PR , waiting for tests to pass. kubernetes/kubernetes#70811

@obnoxxx
Copy link
Contributor

obnoxxx commented Nov 9, 2018

@humblec your patch LGTM, i commented the same in the PR, thanks!

@thockin
Copy link

thockin commented Nov 9, 2018

Thanks so much. I've never been happier to close a PR than the one I sent yesterday :)

phlogistonjohn added a commit to phlogistonjohn/heketi that referenced this issue Jun 3, 2019
@phlogistonjohn
reintroduce rest framework into source tree
a5fc2e1 
This change takes the source files for the formerly external
"heketi/rest" package and makes it a server utility library
(under "heketi/heketi/server/rest") with a license updated
to match the other server components.

The imports of the source files are adjusted to match the
internal "pkg/" utility packages, rather than the external
"heketi/utils" package.

This change is part of the effort to standardize and unify
licensing of the heketi packages as noted in issue heketi#1279.
With this change the heketi server always uses the updated
in-tree utility functions.

Signed-off-by: John Mulligan <jmulligan@redhat.com>
raghavendra-talur pushed a commit that referenced this issue Jun 4, 2019
@phlogistonjohn @raghavendra-talur
reintroduce rest framework into source tree
bec7ae6 
This change takes the source files for the formerly external
"heketi/rest" package and makes it a server utility library
(under "heketi/heketi/server/rest") with a license updated
to match the other server components.

The imports of the source files are adjusted to match the
internal "pkg/" utility packages, rather than the external
"heketi/utils" package.

This change is part of the effort to standardize and unify
licensing of the heketi packages as noted in issue #1279.
With this change the heketi server always uses the updated
in-tree utility functions.

Signed-off-by: John Mulligan <jmulligan@redhat.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
Sort out utils licensing
Development

Successfully merging a pull request may close this issue.

pkg/utils: relicense to dual Apache2 and LGPLv3+ obnoxxx/heketi