Open Stack

On Wed, Mar 20, 2013 at 09:39:35AM +0000, Mark McLoughlin wrote:
 
> The main[1] issue is that the ASF has this policy:
> 
>   all Apache software must be distributed under the Apache License

Which BTW the ASF does not actually follow, except possibly by
tortured definition of "Apache software". 

> 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.

I do not believe that is absolute ASF policy. I believe it may be more
like a default policy as to which exceptions have been made from time
to time.

> 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.

I hate to disagree with VanL on anything, but:

I do not agree that the FSF (a former client of mine) would adopt an
absolute interpretation there.

As for SFLC, I will just note that it is (AFAIK) currently counsel to
both FSF and ASF. If anything SFLC as an entity is less likely to
adopt an absolute interpretation of a GPL issue than the FSF, one of
its clients (particularly if the ASF is another of its clients). I say
that in part as a former lawyer for SFLC familiar with its work in
general.

>    Mark Lemley and Larry Rosen would probably say no.

I'm not sure what Lemley would say, but I agree that Larry Rosen would
probably say no. 

However, since we're talking about lawyers and clients I must also
point out the interesting fact that the AGPL licensor in the specific
case that led to this thread, Rising Tide Systems, is represented by
Larry Rosen as to at least some open source software licensing
matters.

>    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.

That is unclear, as noted above. 

Quite unlike the ASF, the OpenStack Foundation has baked an Apache
License 2.0 policy into its bylaws:

"The Foundation shall distribute the software in the OpenStack Project
under the Apache License 2.0."

As to what the "OpenStack Project" is for purposes of such a
statement, that is also addressed in the bylaws:

  The management of the technical matters relating to the OpenStack
  Project shall be managed by the Technical Committee. The management
  of the technical matters for the OpenStack Project is designed to be
  a technical meritocracy. The “OpenStack Project” shall consist of a
  “Core OpenStack Project,” library projects, gating projects and
  supporting projects. . The Core OpenStack Project means the software
  modules which are part of an integrated release and for which an
  OpenStack trademark may be used. The other modules which are part of
  the OpenStack Project, but not the Core OpenStack Project may not be
  identified using the OpenStack trademark except when distributed
  with the Core OpenStack Project. The role of the Board of Directors
  in the management of the OpenStack Project and the Core OpenStack
  Project are set forth in Section 4.13. On formation of the
  Foundation, the Core OpenStack Project is the Block Storage,
  Compute, Dashboard, Identity Service, Image Service, Networking, and
  Object Storage modules. The Secretary shall maintain a list of the
  modules in the Core OpenStack Project which shall be posted on the
  Foundation’s website.

> 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.

I would just suggest that the OpenStack project should not be adopting
policies based on what it thinks ASF policy is. 


- RF