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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
