incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <>
Subject Re: [Proposal] Blaze
Date Thu, 20 Jul 2006 07:57:28 GMT
IANAL, but I believe Carl has volunteered to get legal clarifications on 
any points you consider nebulous. I agree with you that the terms are 
well intentioned, and intention is often the critical issue. The 
objective of those who were in involved in the creation of this spec 
(though I am not one of them) seems quite clearly to be to create a 
truly 'open' specification. As well as being open it is important the 
protocol is relevant, i.e. supported. When large organisations get 
together, especially in areas touching on the sensitive issue of IP, 
lawyers are inevitable and there often seem to be more than one valid 
interpretation of laws and contracts. The legal requirements as they 
stand for joining the specification group are there to protect the 
specification. Given the intention of the group behind the spec, which I 
think we agree is good, I am confident that the standards body it ends 
up with will be one that enhances rather than restricts its openness.

As for being meritocratic or otherwise, it seems similar to me to 
Apache. The initial merit lies with those who have initiated the spec 
and driven it to a first public release. To continue as a meritocracy, 
they will absolutely need to listen to good advice and accept 
involvement from those who prove themselves. I have personally not seen 
or heard anything to suggest this would not be the case. Their processes 
aren't the same as ASFs but this in itself shouldn't make an 
implementation of their published specifications incompatible as an 
Apache project providing such a project would violate no contracts on 
either side.

The blaze project will in no way be a 'reference implementation' of 
AMQP. It will merely be one (hopefully of many), open-source and freely 
available implementation. I believe that this project remaining separate 
from the specification, as it is, is a good thing considering the 'goal 
of establishing an open standard protocol for async messaging' (which 
like you I wholly support). Only when there are multiple implementations 
will the openness translate into real choice, and if any one 
implementation is coupled with the specification, that would seem to 
create a bias.

I hope we can alleviate your concerns. As I say, I am not the right 
person to discuss legal specifics with (Carl will be happy to deal with 
those) but I can assure you of the good intentions and character of the 
current blaze team and have for myself no concern that if accepted as an 
incubated project we would conduct ourselves as anything other than an 
open meritocratic community of individuals, committed to a high quality 
implementation of an emerging standard, in the spirit of the ASF.

Brian McCallister wrote:
> On Jul 18, 2006, at 8:41 PM, Noel J. Bergman wrote:
>> Ian Holsman wrote:
>>> if blaze's goal is to create a standardized widely available and
>>> interoperable messaging solution (you forgot enterprise class)
>>> why is it creating a new one, and not using JMS ?
>> Blaze's goal (AMQP) is to provide multple language implementations of a
>> language-neutral, wire-level, protocol with a ton of detailed 
>> semantics for
>> interoperable messaging.  JMS is a a Java API.
> I am wholly behind the goal of establishing an open standard protocol 
> for async messaging. Heck, I helped spec one out (which I would be 
> happy to see supplanted by something better!), but I fear the way the 
> protocol spec works here probably won't work well for an Apache project.
> Blaze seems to be about about providing implementations of a 
> proprietary protocol controlled by a group of vendors and one major 
> customer. The protocol is specified behind closed doors with good 
> intentioned but legally nebulous licensing. Participation in the 
> protocol specification process by folks outside the initial group is 
> by submitting suggestions to a private channel. The protocol is 
> specifically controlled by a group of companies, with no provision for 
> individual participation. On the other hand, Apache is specifically 
> made up of individuals, not companies, and merit is based on the 
> actions of the individual.
> The protocol being implemented is pretty much controlled by a 
> separate, closed body. There is presently no way for Apache 
> contributors to participate in, or even observe, the protocol 
> specification process. The eventual standards body to which it is to 
> be submitted is unknown, and there are definitely standards bodies 
> which are incompatible with Apache (any pay-to-play, or any barring 
> individual participation, tend to be difficult) style development.
> So basically, if the project's goal is to provide a couple reference 
> implementations and various client libraries for an in-development 
> closed protocol (with well intentioned licensing) which is being 
> developed via a process which precludes participation by folks working 
> on the Apache project unless their employer (who may not even be aware 
> of their participation) signs an IP agreement? Even then, the path to 
> joining the protocol specification group is by submitting suggestions 
> to private discussion in which you are not included.
> If the protocol came with the project, the protocol lived in a 
> standards body such as the IETF, or even if the protocol was being 
> developed in the open using an apache-style meritocracy, I would be 
> 100% for this. As it stands, I worry that it is incompatible with Apache.
> -Brian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message