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
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
