Open Stack

On 03/20/2014 08:36 AM, Mark McLoughlin wrote:
> 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.

This is a little problematic from a deployer requirement perspective.
Today we say to all deployers: To run all of OpenStack:

 * You will need to run and maintain a relational database environment
(and probably cluster it for scale / availability)
 * You will need to run and maintain a queue system (rabbit, qpid, zmq)
 * You will need to run and maintain a web server (apache)

Deciding to integrate something to OpenStack that requires a base piece
of software that is outside of that list is a pretty big deal.

Forget license for a moment, just specifying that you have to run and
maintain and monitor a nosql environment in addition to a RDBMS is
definitely adding substantial burden to OpenStack deployers.

Big public cloud shops, that's probably fine for them. However OpenStack
as a site level deploy ? Having to add expertise in nosql engine
lifecycle management is a real cost. And we better be explicit about it
from a project wide stance if that's what we're saying.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/52d27620/attachment.pgp>