Open Stack

On Thu, 2014-03-20 at 12:07 +0100, Thierry Carrez wrote:
> Monty Taylor wrote:
> > On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:
> >> The problem with AGPL is that the scope is very uncertain and the
> >> determination of the  consequences are very fact intensive. I was the
> >> chair of the User Committee in developing the GPLv3 and I am therefor
> >> quite familiar with the legal issues.  The incorporation of AGPLv3
> >> code Into OpenStack Project  is a significant decision and should not
> >> be made without input from the Foundation. At a minimum, the
> >> inclusion of APLv3 code means that the OpenStack Project is no longer
> >> solely an Apache v2 licensed project because AGPLv3 code cannot be
> >> licensed under Apache v. 2 License.  Moreover, the inclusion of such
> >> code is inconsistent with the current CLA provisions.
> >>
> >> This code can be included but it is an important decision that should
> >> be made carefully.
> > 
> > I agree - but in this case, I think that we're not talking about
> > including AGPL code in OpenStack as much as we are talking about using
> > an Apache2 driver that would talk to a server that is AGPL ... if the
> > deployer chooses to install the AGPL software. I don't think we're
> > suggesting that downloading or installing openstack itself would involve
> > downloading or installing AGPL code.
> 
> Yes, the issue here is more... a large number of people want to stay
> away from AGPL. Should the TC consider adding to the OpenStack
> integrated release a component that requires AGPL software to be
> installed alongside it ? It's not really a legal issue (hence me
> stopping the legal-issues cross-posting).

We need to understand the reasons "people want to stay away from the
AGPL". Those reasons appear to be legal reasons, and not necessarily
well founded. I think legal-discuss can help tease those out.

I don't (yet) accept that there's a reasonable enough concern for the
OpenStack project to pander to.

I'm no fan of the AGPL, but we need to be able to articulate any policy
decision we make here beyond "some people don't like the AGPL".

For example, if we felt the AGPL fears weren't particularly well founded
then we could make a policy decision that projects should have an
abstraction that would allow those with AGPL fears add support for
another technology ... but that the project wouldn't be required to do
so itself before graduating.

> This was identified early on as a concern with Marconi and the SQLA
> support was added to counter that concern. The question then becomes,
> how usable this SQLA option actually is ? If it's sluggish, unusable in
> production or if it doesn't fully support the proposed Marconi API, then
> I think we still have that concern.

I understood that a future Redis driver was what the Marconi team had in
mind to address this concern and the SQLA driver wasn't intended for
production use.

Mark.