Open Stack

On Thu, 2014-03-20 at 08:22 +0000, Mark McLoughlin wrote:
> On Thu, 2014-03-20 at 07:37 +0400, Monty Taylor wrote:
> > Ianal, but I know there are some lawyers out there who are concerned
> > that the mechanism of attachment is vague.
> 
> AFAICT, you're proxying some concerns from others at HP here? At least,
> that's the way I've understood the issue each time it has been raised
> since it came up with Ceilometer and MongoDB - "some people at HP have
> some concerns about AGPLv3 and we'd never deploy MongoDB".
> 
> I'm no fan (personally) of AGPLv3, but taking a stance that there must
> be a way of deploying OpenStack in production without requiring any
> AGPLv3 code to be deployed is a significant policy decision for the
> project and I don't think we've ever articulated the reasons clearly for
> it.
> 
> I've added a stub entry to the legal issues FAQ:
> 
>   https://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_non-library_dependencies
> 
> Can we get it fleshed out with more specifics?

Great, some specifics from Yahoo!'s Open Source Director, Gil Yehudo:

  http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html

The issue is that the "intimate data communication" language is read by
some as meaning applications which use an Apache licensed client library
(aka driver) may not actually be considered a separate work and are then
subject to the terms of the AGPLv3.

Also, that while MongoDB, Inc. themselves say:

  http://www.mongodb.org/about/licensing/
  http://blog.mongodb.org/post/103832439/the-agpl

  "we promise that your client application which uses the database is a
  separate work"

the license is what's important, particularly when you think about what
could happen in the future if MongoDB is acquired by a company with
different objectives.

IANAL, and I've spent 10 seconds thinking about this ... but the stance
that Marconi or Ceilometer is a "dynamically linked subprogram" that
MongoDB is "specifically designed to require" (by any means), seems
highly questionable.

(To repeat my intent here - we need to dig into the details of these
concerns because, if OpenStack makes important policy decisions based on
these concerns, we are least lending some credence to the concerns. If
they are completely indefensible, I don't think we should do it.)

Mark.