Open Stack

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 <gyehuda at 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.griffiths at 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 at 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
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140320/87b2de24/attachment.html>