Open Stack

Hey

cc-ing VanL and rfontana in the hope they can bring some new perspective
to this. For reference, the full thread is here:

  http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6705

On Tue, 2013-03-19 at 11:04 -0700, Eric Windisch wrote:
> On Tue, 2013-03-19 at 13:50 -0400, Sean Dague 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.
> >  
> > This would be a good thing for the TC to formalize, because it sounds 
> > right for the project culture, and would be good to make it something 
> > that's formal and we all review for.
> > 
> Here is the Apache foundation's own interpretation on this issue in
> regard to their license and project policies:
> http://www.apache.org/licenses/GPL-compatibility.html
> 
> TL;DR - don't link to GPL code.

IMHO your TL;DR oversimplifies and misrepresents the issue.

The main[1] issue is that the ASF has this policy:

  all Apache software must be distributed under the Apache License

Since (some claim that) linking an ALv2 project with a GPL library means
the resulting combination must be distributed according to the terms of
the GPL, an ASF project linking to GPL code would result in an ASF
policy violation.

The question this thread raises is whether we have the same or similar
policy. Using the Apache License does not *automatically* mean we adopt
the ASF's licensing policy.

There is also the question of whether including an optional,
not-used-by-default program which imports a GPL licensed Python module
in an OpenStack project really does mean that the project must be
distributed under the terms of the GPL - i.e. (1) would cinder-rtstool
be considered a derivative work of rtslib and (2) would you be required
to distribute just cinder-rtstool or all of Cinder or all OpenStack
projects under the terms of the GPL?

On (1) a quick google turns up e.g. this interesting take from VanL:

  http://jacobian.org/writing/gpl-questions/

   1. foo.py is a Python library released under the GPLv3. bar.py is a
   library distributed commercially. If bar contains import foo, must
   bar.py be released under the GPL?

   Maybe. This has not been resolved by the court, and the answer you
   get depends on who you ask. The FSF and SFLC will say absolutely yes.
   Mark Lemley and Larry Rosen would probably say no.

   The relevant legal question is whether the interpreted file bar.py is
   a derivative work of the contents of foo.py. [...]

   The best advice is to act in accordance with the GPL as a social
   contract, as that will keep you out of the most trouble. [...]


I assumed our policy was to avoid using GPL libraries in OpenStack
because we want all of OpenStack to be distributable under the ALv2. In
that sense, our stance wouldn't be all that different from the stance
taken by the ASF. However, it is really important to be very clear why
we're taking this stance.

Honestly, I'd love someone to argue for  a different stance because
otherwise it feels like we're adopting this policy without proper
consideration.

Thanks,
Mark.

[1] - there's also the ASF's claim of an incompatibility between the
GPLv2 and the patent provisions in ALv2. Let's leave that aside since
we're talking about an AGPLv3 licensed project.