Open Stack

On Tue, Mar 19, 2013 at 2:01 PM, Chuck Short <chuck.short at canonical.com>wrote:

> On 13-03-19 03:06 PM, Russell Bryant wrote:
>
>> On 03/19/2013 02:56 PM, Sean Dague wrote:
>>
>>> On 03/19/2013 02:16 PM, Russell Bryant wrote:
>>>
>>>> On 03/19/2013 01:54 PM, Russell Bryant wrote:
>>>>
>>>>> On 03/19/2013 01:31 PM, Mark McLoughlin wrote:
>>>>>
>>>> <snip>
>>>
>>>> To be clear, I'm really not sure whether this is our policy either. I
>>>>>> guess I always assumed it was, but that's based on nothing
>>>>>> substantive.
>>>>>>
>>>>> So Sean, if you were doing a license review, was this the only (A)GPL
>>>>> dependency you found (are there any GPL deps) ?
>>>>>
>>>> For the record, I was speaking to Sean and neither of us know of any
>>>> problematic Python dependencies in the Folsom release.  This would only
>>>> apply to new dependencies introduced in the Grizzly timeframe.
>>>>
>>> The list of new dependencies for Grizzly that got are the following:
>>>
>>> jsonpointer                BSD-like    0.5
>>> python-alembic            MIT    0.4.2
>>> python-jsonpatch            BSD-like    0.10
>>> python-openssl (pyOpenSSL)     Apache V2    0.13
>>> python-rtslib                AGPL V3    2.1.fb27
>>> python-stevedore            Apache V2    0.8
>>>
>>> All the others are fine and license compatible besides python-rtslib.
>>>
>> Great, thanks.  So how about we do this:
>>
>> 1) Move cinder-rtstool to its own separate repo (rtstool).  This could
>> be on stackforge for convenience, but it would not be an official
>> OpenStack project.
>>
>
> Sure why dont we ask the cinder people how they want to handle this.
>
>
>
>> 2) Remove rtslib from the requirements list of Cinder.  Don't list
>> rtstool as a requirement.
>>
> How about we email the author of rtslib to re-license it to a more
> friendlier license and bump the version required by cinder?
>
>  3) Make sure Cinder can gracefully handle whether or not rtstool is
>> present on the system.
>>
> Afaik rtstool is not enabled by default so this shouldnt be a problem.
>
>
>  4) The TC needs to work on clarifying license policy and ensuring that
>> we have a process in place to make sure the policy is reviewed for each
>> new dependency.
>>
>> 5) Cinder folks may want to consider targetd support in Havana.  It
>> would be HTTP access to something (A)GPL licensed as opposed to having
>> to execute something.  Executing something should still be fine though
>> AFIAK, but IANAL.  :-)
>>
>>  chuck
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>

So my proposal was/is, leave the LIO driver functionality in the code but
do not package the rtslib.  The rtslib is the only piece that's AGPL, from
there if end users/providers would like to use the LIO driver they can
either choose to install/import the library theme selves.  We also do in
fact hope to have a replacement (read Apache licensed) version of this code
going forward.

Right now the LIO driver and this package are optional configuration items,
I think this is a descent solution that provides the driver to those that
want to use and and still protects us from the issues of the ridiculous
AGPL.  To be honest I don't necessarily see how this proposal differs from
conflicts between VMWare, Microsoft or Citrix licenses for folks that
choose to use those hypervisors?

I've already removed the package entry from pip-requires (and later today
that'll be irrelevant anyway when I suck in the OSLO pip/test-requires
assuming testing is ok), so I was hoping that would be sufficient.  There
is a demand for the LIO driver from service providers and enterprise folks,
so removing it altogether seems a bit harsh.

That being said, if there is some legal implications still and a concern
I'll surely yield on this and just remove any mention of rtslib from the
code.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130319/caa6e60c/attachment.html>