"OpenStack Development Mailing List (not for usage questions)"
mailto: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 in
gal 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,
rt.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 cod
On Mar 20, 2014, at 5:52 AM, Sean Dague 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
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,
> 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 w
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 ab
>
>
> 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
On 20/03/14 08:52 -0400, Sean Dague 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
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
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
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 famili
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 i
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
14 matches
Mail list logo
