Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
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. -Original Message- From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Wednesday, March 19, 2014 2:39 PM To: OpenStack Development Mailing List (not for usage questions) Cc: legal-disc...@lists.openstack.org Subject: Re: [legal-discuss] [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API? Its my understanding that the only case the A in the AGPL would kick in is if the cloud provider made a change to MongoDB and exposed the MongoDB instance to users. Then the users would have to be able to download the changed code. Since Marconi's in front, the user is Marconi, and wouldn't ever want to download the source. As far as I can tell, in this use case, the AGPL'ed MongoDB is not really any different then the GPL'ed MySQL in footprint here. MySQL is acceptable, so why isn't MongoDB? It would be good to get legal's official take on this. It would be a shame to make major architectural decisions based on license assumptions that turn out not to be true. I'm cc-ing them. Thanks, Kevin From: Chris Friesen [chris.frie...@windriver.com] Sent: Wednesday, March 19, 2014 2:24 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API? On 03/19/2014 02:24 PM, Fox, Kevin M wrote: Can someone please give more detail into why MongoDB being AGPL is a problem? The drivers that Marconi uses are Apache2 licensed, MongoDB is separated by the network stack and MongoDB is not exposed to the Marconi users so I don't think the 'A' part of the GPL really kicks in at all since the MongoDB user is the cloud provider, not the cloud end user? Even if MongoDB was exposed to end-users, would that be a problem? Obviously the source to MongoDB would need to be made available (presumably it already is) but does the AGPL licence contaminate the Marconi stuff? I would have thought that would fall under mere aggregation. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ legal-discuss mailing list legal-disc...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmas...@dlapiper.com. Thank you. ___ legal-discuss mailing list legal-disc...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
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
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
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. Or continue to ostracize current *amazing* projects. ;) There has long been a rift in the Openstack community around the implementation details of swift. I know someone mentioned earlier, but I want to focus on the fact that Swift (like marconi) is a very different service. The API *is* the product. With something like Nova, the API can be down, but users can still use their VM's. For swift, if the API is down, the whole product is down. We have a very different set of constraints that we have to work with, and thus why we often have to take very different approaches. There absolutely can't be a one fit solution for all. If we are going to be so strict about what an Openstack project uses, are we then by the same token going to kick swift out of Openstack because it will *never* use Pecan? And I say that not because I think Pecan is a bad tool, just not the right tool for swift. -- Chuck ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
On 03/20/2014 11:11 AM, Chuck Thier wrote: 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. Or continue to ostracize current *amazing* projects. ;) There has long been a rift in the Openstack community around the implementation details of swift. I know someone mentioned earlier, but I want to focus on the fact that Swift (like marconi) is a very different service. The API *is* the product. With something like Nova, the API can be down, but users can still use their VM's. For swift, if the API is down, the whole product is down. We have a very different set of constraints that we have to work with, and thus why we often have to take very different approaches. There absolutely can't be a one fit solution for all. If we are going to be so strict about what an Openstack project uses, are we then by the same token going to kick swift out of Openstack because it will *never* use Pecan? And I say that not because I think Pecan is a bad tool, just not the right tool for swift. I don't think we'd kick out an existing project over this point. We've already said that we don't expect existing projects to migrate an existing API. It's a movement to standardize for new APIs. If swift were building a new API, I do think it would be good to into this in more detail. For the existing one, I think it's fine. Swift has more different than everything else issues than just library choices. It's a real problem IMO, but I'd rather separate that discussion from this thread. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
The incorporation of AGPLv3 code Into OpenStack Project is a significant decision To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Concerns over AGPL were raised when Marconi was incubated, and I totally respect that some folks are not comfortable with deploying something like MongoDB that is AGPL-licensed. Those discussions precipitated the work we have been doing on SQLAlchemy and Redis drivers. In fact, the sqla driver was one of the graduation requirements put in place but the TC. Now, if people want to use something else than what the Marconi team is already working on, we are more than happy to have them contribute and help us evolve the driver interface as needed. On the subject of minimizing the number of different backends that operators need to manage, some relief may be found by making the backends for projects more customizable. For example, as we move more projects to using the oslo caching library, that will give operators an opportunity to migrate from memcached to, say, Redis. And if OpenStack Service X (Marconi, for example) supports Redis as a backing store, now the operator can reuse their Redis infrastructure and know-how. The software industry has been moving towards hybrid NoSQL+SQL architectures for a long time now, in order to create best-fit solutions; I think we’ll see more OpenStack projects following this model in the future, not less, and so we need to work out a happy path for supporting these kinds of operating environments. Kurt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
On 03/20/2014 12:29 PM, Kurt Griffiths wrote: The incorporation of AGPLv3 code Into OpenStack Project is a significant decision To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Concerns over AGPL were raised when Marconi was incubated, and I totally respect that some folks are not comfortable with deploying something like MongoDB that is AGPL-licensed. Those discussions precipitated the work we have been doing on SQLAlchemy and Redis drivers. In fact, the sqla driver was one of the graduation requirements put in place but the TC. Now, if people want to use something else than what the Marconi team is already working on, we are more than happy to have them contribute and help us evolve the driver interface as needed. On the subject of minimizing the number of different backends that operators need to manage, some relief may be found by making the backends for projects more customizable. For example, as we move more projects to using the oslo caching library, that will give operators an opportunity to migrate from memcached to, say, Redis. And if OpenStack Service X (Marconi, for example) supports Redis as a backing store, now the operator can reuse their Redis infrastructure and know-how. Yep, that's definitely goodness. The software industry has been moving towards hybrid NoSQL+SQL architectures for a long time now, in order to create best-fit solutions; I think we’ll see more OpenStack projects following this model in the future, not less, and so we need to work out a happy path for supporting these kinds of operating environments. Absolutely, but lets at least be deliberate about it. Also, the burden, and thus concern, would go way down if the service actually used heat and/or nova to deploy it's backend as well. Like Savana and Trove do. It seems like we've got all this infrastructure in OpenStack already to deploy and manage things on computes programatically. It would be nice to reuse that for application centric services. -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
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
On Mar 20, 2014, at 5:52 AM, Sean Dague s...@dague.net 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) (Don’t forget load balancers and/or proxies) 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. This is an excellent point that I want to emphasize. Maintaining these things in production is non-trivial; it is the burden of maintenance that has prevented some of us from integrating Mongo. It is especially troublesome that there are not options on the noSQL side. If you are already running redis or cassandra or couch or riak in production, you have to install mongo as well. Maintaining a noSQL db is a problem, but maintaining a SPECIFIC noSQL db with no option to replace it with another makes the problem worse. Vish 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Understood, but here's the rub. Someone else is going to want to build on this (which it the point of this open source project). Whereas 'pymongo' is Apache licensed, since the copyright holder, MongoDB Inc. declared it as such, the authors of the other community drivers (for other language bindings and features of MongoDB, etc.) are also of releasing drivers under the Apache or BSD licenses too (thinking that's OK to do since no one is telling them otherwise). That community is unaware of their legal obligations when creating drivers to an AGPL database. Thus if one of those community drivers gets intertwined in a court case clarifying their license to be infringing on the AGPL terms, we've inadvertently impacted our community. This is a credible risk that is difficult for OpenStack to abate, since the problem lies with the way a different community chose to operate. There are three interconnected issues here: 1. The confusion that MongoDB has created in Open Source licensing due to the asymmetric control they have on licensing terms. 2. The diligence of Open Stack to remain careful with OpenStack's CLA compliance and Apache-friendly terms. 3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic viability and legal risks at large. The first problem is out of scope for this list. But I think people who rely upon Open Source for their business ought to understand what MongoDB is doing to open source software. The second is, to your point, the issue in this conversation. As long as Openstack only use Apache licensed code from MondgoDB Inc. and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. But you will have to exclude the rest of the MongoDB community (which goes against the spirit of Open Source -- back to the problem #1, which is out of scope). As for #3, I think the foundation needs to weigh in on the pragmatics here, since this has an economic and legal impact to the entire endeavor, not just to persisting data in one component of the project. Gil Yehuda Sr. Director Of Open Source, Open Standards -Original Message- From: Kurt Griffiths [mailto:kurt.griffi...@rackspace.com] Sent: Thursday, March 20, 2014 9:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API? The incorporation of AGPLv3 code Into OpenStack Project is a significant decision ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
Kurt, Your point is that NoSQL solution may be required for innovative project. And that is MongoDB. But what if come another amazing project that needs CouchDB, neo4j, Riak, (put your favorite NoSQL DB here)? It would be in the same position cause everyone would say hey, we already have NoSQL in OpenStack so you have to use MongoDB which is not fair. But is also obvious that OpenStack cannot demand cloud operators to maintain MySQL, MongoDB, CouchDB, neo4j etc in simultaneously I hate to say that (I happen to be MongoDB fan) but the only way we can introduce external dependencies to OpenStack is by making technology that would make possible the project to be responsible for deployment and maintenance of that dependency (DBMS) rather then cloud operator. It seems to me that the right way to introduce MongoDB is to invest in projects like TripleO, Fuel, Murano, Heat and Ironic On Thu, Mar 20, 2014 at 9:09 PM, Gil Yehuda gyeh...@yahoo-inc.com wrote: To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Understood, but here's the rub. Someone else is going to want to build on this (which it the point of this open source project). Whereas 'pymongo' is Apache licensed, since the copyright holder, MongoDB Inc. declared it as such, the authors of the other community drivers (for other language bindings and features of MongoDB, etc.) are also of releasing drivers under the Apache or BSD licenses too (thinking that's OK to do since no one is telling them otherwise). That community is unaware of their legal obligations when creating drivers to an AGPL database. Thus if one of those community drivers gets intertwined in a court case clarifying their license to be infringing on the AGPL terms, we've inadvertently impacted our community. This is a credible risk that is difficult for OpenStack to abate, since the problem lies with the way a different community chose to operate. There are three interconnected issues here: 1. The confusion that MongoDB has created in Open Source licensing due to the asymmetric control they have on licensing terms. 2. The diligence of Open Stack to remain careful with OpenStack's CLA compliance and Apache-friendly terms. 3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic viability and legal risks at large. The first problem is out of scope for this list. But I think people who rely upon Open Source for their business ought to understand what MongoDB is doing to open source software. The second is, to your point, the issue in this conversation. As long as Openstack only use Apache licensed code from MondgoDB Inc. and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. But you will have to exclude the rest of the MongoDB community (which goes against the spirit of Open Source -- back to the problem #1, which is out of scope). As for #3, I think the foundation needs to weigh in on the pragmatics here, since this has an economic and legal impact to the entire endeavor, not just to persisting data in one component of the project. Gil Yehuda Sr. Director Of Open Source, Open Standards -Original Message- From: Kurt Griffiths [mailto:kurt.griffi...@rackspace.com] Sent: Thursday, March 20, 2014 9:29 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API? The incorporation of AGPLv3 code Into OpenStack Project is a significant decision ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours Stanislav (Stan) Lagun Senior Developer Mirantis 35b/3, Vorontsovskaya St. Moscow, Russia Skype: stanlagun www.mirantis.com sla...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
If we limited Openstack projects to just one database, is that database (e.g. MySQL) going to be the best storage deployment for that job? Or are there cases where other technologies such as Redis, MongoDB, Cassandra, CouchDB, etc make more sense? Marconi has a pluggable storage driver model which allows these other storage drivers to be implemented (Redis is on the books). The operator can then make their own informed choice on which backend makes the most sense for them based on their needs. The alternative is that Openstack projects limit themselves to just one option (to reduce the deployment stack operators have to be concerned with – for example: only MySQL backends allowed), but may (likely) result in reduced performance/features/experience. To me that would be an injustice to the users of that cloud. How do back ends utilized relate to the amount/type/churn of data? Is the blessed database ideal for that job or are there more scalable options? Im not saying you can’t scale MySQL, but db’s like Mongo/Cassandra/etc are better equipped for it (personal opinion). I agree that investments in projects like Heat etc will reduce the burden on operators that deploy Openstack. Amit Gandhi Senior Manager, Rackspace. From: Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 20, 2014 at 2:23 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API? Kurt, Your point is that NoSQL solution may be required for innovative project. And that is MongoDB. But what if come another amazing project that needs CouchDB, neo4j, Riak, (put your favorite NoSQL DB here)? It would be in the same position cause everyone would say hey, we already have NoSQL in OpenStack so you have to use MongoDB which is not fair. But is also obvious that OpenStack cannot demand cloud operators to maintain MySQL, MongoDB, CouchDB, neo4j etc in simultaneously I hate to say that (I happen to be MongoDB fan) but the only way we can introduce external dependencies to OpenStack is by making technology that would make possible the project to be responsible for deployment and maintenance of that dependency (DBMS) rather then cloud operator. It seems to me that the right way to introduce MongoDB is to invest in projects like TripleO, Fuel, Murano, Heat and Ironic On Thu, Mar 20, 2014 at 9:09 PM, Gil Yehuda gyeh...@yahoo-inc.commailto:gyeh...@yahoo-inc.com wrote: To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Understood, but here's the rub. Someone else is going to want to build on this (which it the point of this open source project). Whereas 'pymongo' is Apache licensed, since the copyright holder, MongoDB Inc. declared it as such, the authors of the other community drivers (for other language bindings and features of MongoDB, etc.) are also of releasing drivers under the Apache or BSD licenses too (thinking that's OK to do since no one is telling them otherwise). That community is unaware of their legal obligations when creating drivers to an AGPL database. Thus if one of those community drivers gets intertwined in a court case clarifying their license to be infringing on the AGPL terms, we've inadvertently impacted our community. This is a credible risk that is difficult for OpenStack to abate, since the problem lies with the way a different community chose to operate. There are three interconnected issues here: 1. The confusion that MongoDB has created in Open Source licensing due to the asymmetric control they have on licensing terms. 2. The diligence of Open Stack to remain careful with OpenStack's CLA compliance and Apache-friendly terms. 3. The pragmatics of the effect MondgoDB would have onto OpenStack's economic viability and legal risks at large. The first problem is out of scope for this list. But I think people who rely upon Open Source for their business ought to understand what MongoDB is doing to open source software. The second is, to your point, the issue in this conversation. As long as Openstack only use Apache licensed code from MondgoDB Inc. and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. But you will have to exclude the rest of the MongoDB community (which goes against the spirit of Open Source -- back to the problem #1, which is out of scope). As for #3, I think the foundation needs to weigh in on the pragmatics here, since this has an economic and legal impact to the entire endeavor, not just to persisting data in one component of the
Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?
Ianal, but I know there are some lawyers out there who are concerned that the mechanism of attachment is vague. If there is an issue (I'm not saying there is) I don't think mongodb's view is relevant, as they are quite likely to be bought by someone, say Oracle, who might not share and would not be bound by that opinion. That said, I don't think a mongo driver is an issue, as long as it's not the only driver... That way deployers can make an agpl call on their own. We've had mongo driver for ceilometer for a while. On Mar 20, 2014 7:28 AM, Richard Fontana rfont...@redhat.com wrote: Why not contact MongoDB to understand its viewpoint, if there's concern? On Wed, Mar 19, 2014 at 09:38:53PM +, Fox, Kevin M wrote: Its my understanding that the only case the A in the AGPL would kick in is if the cloud provider made a change to MongoDB and exposed the MongoDB instance to users. Then the users would have to be able to download the changed code. Since Marconi's in front, the user is Marconi, and wouldn't ever want to download the source. As far as I can tell, in this use case, the AGPL'ed MongoDB is not really any different then the GPL'ed MySQL in footprint here. MySQL is acceptable, so why isn't MongoDB? It would be good to get legal's official take on this. It would be a shame to make major architectural decisions based on license assumptions that turn out not to be true. I'm cc-ing them. Thanks, Kevin From: Chris Friesen [chris.frie...@windriver.com] Sent: Wednesday, March 19, 2014 2:24 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API? On 03/19/2014 02:24 PM, Fox, Kevin M wrote: Can someone please give more detail into why MongoDB being AGPL is a problem? The drivers that Marconi uses are Apache2 licensed, MongoDB is separated by the network stack and MongoDB is not exposed to the Marconi users so I don't think the 'A' part of the GPL really kicks in at all since the MongoDB user is the cloud provider, not the cloud end user? Even if MongoDB was exposed to end-users, would that be a problem? Obviously the source to MongoDB would need to be made available (presumably it already is) but does the AGPL licence contaminate the Marconi stuff? I would have thought that would fall under mere aggregation. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ legal-discuss mailing list legal-disc...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss ___ legal-discuss mailing list legal-disc...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
