[openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?

Mark McLoughlin markmc at redhat.com
Thu Mar 20 08:54:48 UTC 2014


On Thu, 2014-03-20 at 01:28 +0000, Joshua Harlow wrote:
> Proxying from yahoo's open source director (since he wasn't initially
> subscribed to this list, afaik he now is) on his behalf.
> 
> From Gil Yehuda (Yahoo’s Open Source director).
> 
> I would urge you to avoid creating a dependency between Openstack code
> and any AGPL project, including MongoDB. MongoDB is licensed in a very
> strange manner that is prone to creating unintended licensing mistakes
> (a lawyer’s dream). Indeed, MongoDB itself presents Apache licensed
> drivers – and thus technically, users of those drivers are not
> impacted by the AGPL terms. MongoDB Inc. is in the unique position to
> license their drivers this way (although they appear to violate the
> AGPL license) since MongoDB is not going to sue themselves for their
> own violation. However, others in the community create MongoDB drivers
> are licensing those drivers under the Apache and MIT licenses – which
> does pose a problem.
> 
> Why? The AGPL considers 'Corresponding Source' to be defined as “the
> source code for shared libraries and dynamically linked subprograms
> that the work is specifically designed to require, such as by intimate
> data communication or control flow between those subprograms and other
> parts of the work." Database drivers *are* work that is designed to
> require by intimate data communication or control flow between those
> subprograms and other parts of the work. So anyone using MongoDB with
> any other driver now invites an unknown --  that one court case, one
> judge, can read the license under its plain meaning and decide that
> AGPL terms apply as stated. We have no way to know how far they apply
> since this license has not been tested in court yet.
> Despite all the FAQs MongoDB puts on their site indicating they don't
> really mean to assert the license terms, normally when you provide a
> license, you mean those terms. If they did not mean those terms, they
> would not use this license. I hope they intended to do something good
> (to get contributions back without impacting applications using their
> database) but, even good intentions have unintended consequences.
> Companies with deep enough pockets to be lawsuit targets, and
> companies who want to be good open source citizens face the problem
> that using MongoDB anywhere invites the future risk of legal
> catastrophe. A simple development change in an open source project can
> change the economics drastically. This is simply unsafe and unwise.
> 
> OpenStack's ecosystem is fueled by the interests of many commercial
> ventures who wish to cooperate in the open source manner, but then
> leverage commercial opportunities they hope to create. I suggest that
> using MongoDB anywhere in this project will result in a loss of
> opportunity -- real or perceived, that would outweigh the benefits
> MongoDB itself provides.
> 
> tl;dr version: If you want to use MongoDB in your company, that's your
> call. Please don't turn anyone who uses OpenStack components into a
> unsuspecting MongoDB users. Instead, decouple the database from the
> project. It's not worth the legal risk, nor the impact on the
> "Apache-ness" of this project.

Thanks for that, Josh and Gil.

Rather than cross-posting, I think this MongoDB/AGPLv3 discussion should
continue on the legal-discuss mailing list:

  http://lists.openstack.org/pipermail/legal-discuss/2014-March/thread.html#174

Bear in mind that we (OpenStack, as a project and community) need to
judge whether this is a credible concern or not. If some users said they
were only willing to deploy Apache licensed code in their organization,
we would dismiss that notion pretty quickly. Is this AGPLv3 concern
sufficiently credible that OpenStack needs to take it into account when
making important decisions? That's what I'm hoping to get to in the
legal-discuss thread.

Mark.




More information about the OpenStack-dev mailing list