[openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)
Hi All Whilst working on the re-licensing of the OpenStack charms to Apache 2.0, its apparent that syncing and inclusion of the charm-helpers python module directly into the charm is not going to work from a license compatibility perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency of an OpenStack project - see [0]). We already have a plan in place to remove the inclusion of charm-helpers for execution of functional tests, but we need to come up with a solution to the runtime requirement for charm-helpers, preferably one that does not involve direct installation at deploy time from either pypi or from lp:charm-helpers. Thoughts? ideas? Cheers James [0] http://governance.openstack.org/reference/licensing.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)
I suspect that the reactive charming model wouldn't have this issue due to the ability to essentially statically link the libraries via wheels/pip packages. If that's the case, it's likely possible to follow along the same lines as the base-layer charm and bootstrap the environment using pip/wheel libraries included at build time. As I see it, this would require: * Updates to the process/tooling for pushing to the charm store * Update the install/upgrade-charm hook to bootstrap the environment with the requirements files * If using virtualenv (not a requirement in my mind), then each of the hooks needs to be bootstrapped to ensure that they are running within the virtualenv. To make life easier in development mode, the charms can download from pypi if the linked wheel/pip package isn't available - it saves a build step before deployment, though certainly for the published versions the statically linked libraries should be included (which, from my understanding, I believe the licensing allows and why the reactive charming/layered model wouldn't have this issue). On Tue, Jun 28, 2016 at 6:29 AM, James Page wrote: > Hi All > > Whilst working on the re-licensing of the OpenStack charms to Apache 2.0, > its apparent that syncing and inclusion of the charm-helpers python module > directly into the charm is not going to work from a license compatibility > perspective. charm-helpers is LGPL v3 (which is OK for a runtime dependency > of an OpenStack project - see [0]). > > We already have a plan in place to remove the inclusion of charm-helpers for > execution of functional tests, but we need to come up with a solution to the > runtime requirement for charm-helpers, preferably one that does not involve > direct installation at deploy time from either pypi or from > lp:charm-helpers. > > Thoughts? ideas? > > Cheers > > James > > [0] http://governance.openstack.org/reference/licensing.html > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [charms] inclusion of charm-helpers (LGPL licensed)
Hi Billy On Thu, 30 Jun 2016 at 17:24 Billy Olsen wrote: > I suspect that the reactive charming model wouldn't have this issue > due to the ability to essentially statically link the libraries via > wheels/pip packages. If that's the case, it's likely possible to > follow along the same lines as the base-layer charm and bootstrap the > environment using pip/wheel libraries included at build time. As I see > it, this would require: > > * Updates to the process/tooling for pushing to the charm store > * Update the install/upgrade-charm hook to bootstrap the environment > with the requirements files > * If using virtualenv (not a requirement in my mind), then each of the > hooks needs to be bootstrapped to ensure that they are running within > the virtualenv. > I was thinking of something along those lines as well. I'll spike on something this week to figure out exactly how this might work. > To make life easier in development mode, the charms can downla > build step before deployment, though certainly for the published > versions the statically linked libraries should be included (which, > from my understanding, I believe the licensing allows and why the > reactive charming/layered model wouldn't have this issue). > That sounds like a neat idea (although building out a layered charm is pretty easy as well). __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev