Open Stack

On 03/19/2013 01:54 PM, Russell Bryant wrote:
> On 03/19/2013 01:31 PM, Mark McLoughlin wrote:
>> On Tue, 2013-03-19 at 13:27 -0400, Sean Dague wrote:
>>> On 03/19/2013 10:51 AM, Mark McLoughlin wrote:
>>>> On Mon, 2013-03-18 at 16:30 -0400, Sean Dague wrote:
>>>>> Recently just doing a license analysis of the dependencies for the
>>>>> various projects and one popped up that seemed worth discussing.
>>>>>
>>>>> rtslib is currently listed as a dependency for cinder. The package
>>>>> itself is AGPL, which has some rather strong requirements for a cloud
>>>>> provider using it
>>>>> (https://github.com/agrover/rtslib-fb/blob/master/COPYING).
>>>>>
>>>>> It's currently used only in bin/cinder-rtstool, so it's largely isolated
>>>>> in it's use. However given that the spirit of the OpenStack project was
>>>>> Apache 2 style licensing, it's a bit odd to have an AGPL dependency that
>>>>> really means cinder-rtstool is AGPL (even though it says Apache2 in the
>>>>> header).
>>>>>
>>>> ...
>>>>> My inclination is that tooling which requires AGPL libraries probably
>>>>> shouldn't be in the main OpenStack tree. Maybe externally available as
>>>>> some sort of contrib. However, licensing always opens up new cans of
>>>>> worms. So I'd like to hear other opinions here.
>>>>
>>>> Just to be clear on something here - our policy is to not allow the use
>>>> of any GPL libraries. And we don't know of any cases where we currently
>>>> use GPL libraries.
>>>
>>> I wasn't sure if that was formal policy or not, but if it is, I'm happy 
>>> with that. If that's the case though, it got missed in at least one 
>>> instance here by rtslib coming in as a cinder dependency.
>>
>> 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.

> In terms of policy and process ... we need a policy, and reviewing
> dependencies against the policy should be a required part of approving
> changes to the central requirements list.  This sounds like something
> the TC should take on.
> 


-- 
Russell Bryant