Open Stack

On 03/20/2014 10:27 AM, Richard Fontana wrote:
> On Thu, Mar 20, 2014 at 08:44:39AM +0000, Mark McLoughlin wrote:
>> 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.
>
> I do not understand this part of Gil Yehuda's argument -- an
> Apache-licensed driver is per se engaged in "intimate data
> communication" with MongoDB?
>
>> 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.
>
> But that statement is part of the license as to the code that exists
> now, and if the issue is concern about future versions, well, the
> upstreams of other library and non-library dependencies might someday
> alter their licensing too. Experience if anything suggests that
> present-day AGPL code tends to later on become Apache-licensed.
>
>> 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.
>
> I have to say "highly questionable" is an understatement to me; it is
> preposterous to suppose that MongoDB, the thing that is AGPL-licensed,
> is "specifically designed to require" Marconi or Ceilometer or any
> part of them. By all means I encourage Gil to come up with a different
> theory of AGPL interpretation to explain why there is a problem here,
> but this one won't fly.
>
>> (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.)
>
> I entirely agree.

++