On 20/03/14 08:52 -0400, Sean Dague wrote:
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.
I agree this is quite an issue but I also think that pretending that we'll be able to let OpenStack grow with a minimum set of databases, brokers and web servers is a bit unrealistic. The set of supported technologies won't be able to fulfill the needs of all the yet-to-be-discovered *amazing* projects. I think we'll need to either relax this constraint or create some sort of separate group of projects that are still official but not considered when we say "Deploy OpenStack". This group will allow some limited sort of divergence when it comes to the technology requirements. I'm sure there's more to consider here. For instance, CI issues, CD issues etc. Cheers, Flavio -- @flaper87 Flavio Percoco
pgpPria2zbe5i.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
