You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Arnaud Simon <as...@redhat.com> on 2007/06/01 16:34:27 UTC
NMS
Hello,
We have been thinking about implementing the NMS API as part of the
QPID .Net client. However we are concerned about potential legal issues.
It seems to me that the NMS API is very similar to the JMS one but the
JMS specification specifically licenses the technology "only for Java".
This is the relevant license, copied directly from the JMS Spec
document:
"Subject to the terms and conditions of this license, Sun hereby grants
you a fully-paid, non-exclusive, non-transferable, worldwide, limited
license (without the right to sublicense) under Sun's intellectual
property rights to review the Specification internally solely for the
purpose of designing and developing your Java applets and applications
intended to run on the Java platform. Other than this limited license,
you acquire no right, title or interest in or to the Specification or
any other Sun intellectual property. The Specification contains the
proprietary information of Sun and may only be used in accordance with
the license terms set forth herein. This license will terminate
immediately without notice from Sun if you fail to comply with any
provision of this license. Upon termination or expiration of this
license, you must cease use of or destroy the Specification."
Does anybody know if this concern has already been raised?
Regards
Arnaud
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> > what is NMS?
> NMS is a .NET version of JMS.
Not quite. Its a .Net Messaging API to the various MOMs available on
the .Net platform such as MSMQ, TibCo, MQSeries together with new
implementations such as for ActiveMQ and Stomp. Its just as similar to
JMS as it is to the various other APIs for all the MOMs available
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> I'm not sure about whether Sun has relevant patents on the JMS APIs.
FWIW that'd be pretty hard since there was prior art in MQSeries and
TibCo APIs which JMS mirrored pretty closely. There's only so many
ways you can create an API for sending & receiving messages over a
Connection/Channel using a Sender/Producer/Publisher and a
Consumer/Subscriber/Receiver. But then also I'm not a lawyer.
> Howver, there are two things that may have been violated. Firstly, the
> license agreement that was "clicked-through" whenever someone looked
> at the JMS specification. Secondly the JMS copyright. Since, as far as
> I can see, NMS is likely to be a "derived work" of JMS it is also
> likely that it breaches the copyright of the spec.
AFAIK there is not one line of NMS API which is the same as the JMS
API. Ditto CORBA Notification Service et al. Though conceptually all
of those messaging APIs I mentioned before are very similar for
reasons I already mentioned (all MOMs implement pretty much the same
semantics from an API perspective). If its a breach of copyright to
make something conceptually similar; lots of projects at Apache could
be in breach; as things like Axis, CXF, QPid, Tuscany, WSIF and others
have conceptually similar message exchange APIs in them (in Java and
other languages). Sure some are closer to JMS/CORBA NS to others but
conceptually messaging is messaging.
Anyone any idea of the legal definition of "derived work"? Certainly
none of the JMS spec or API was used to create NMS; but clearly most
of us who work on Apache projects which have a messaging component or
API will have been exposed to possible JMS spec contamination so some
legal advice would be very useful .
> In other words an API that allows .NET
> clients to interact with a messaging server, especially one that
> follows the same semantics as JMS (i.e. a JMS server like Apache
> ActiveMQ)
FWIW all MOMs follow pretty much the same semantics (MSMQ, TibCo,
MQSeries and ActiveMQ) which is what NMS reflects
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
> what is NMS?
NMS is a .NET version of JMS. In other words an API that allows .NET
clients to interact with a messaging server, especially one that
follows the same semantics as JMS (i.e. a JMS server like Apache
ActiveMQ)
> what is the NMS API?
Same as above.
> who specficies it?
NMS has been developed by the Apache ActiveMQ community who recently
graduated from the incubator.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by robert burrell donkin <ro...@gmail.com>.
On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I ceased use of and destroyed my copy of the Specification years ago =)
>
> But seriously, what kind of IP is it that is being violated?
> copyright? patent? or some other kind that I'm not aware of?
what is NMS?
what is the NMS API?
who specficies it?
- rober
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 June 2007 21:34, Paul Fremantle wrote:
> > Since this seems to be in the Idea category... I would have thought
> > that there would need some patents in place to enforce it.
>
> Not really. Once you agree to a contract (like that license) its
> simply contract law, AFAIK.
Nitpicking, AFAIUI, contract law covers contracts, which has two parties. A
click-thru license agreement only has one signatory (You), who are given
rights according to a set of conditions. Once you violate those conditions
the license is void. Contracts are quid pro quo, meaning both parties are
giving something to get something else. Licenses are normally not written
that way.
I assume definitions varies between jurisdictions.
However, the above fairly is irrelevant to the case at hand.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
>
> > I guess you are referring to the license to that allows a person to
> > hold a copy of the JMS spec. I wonder if violating/terminating the
> > that license IP taints any work created using Ideas obtain from it.
> > Since this seems to be in the Idea category... I would have thought
> > that there would need some patents in place to enforce it.
>
> Not really. Once you agree to a contract (like that license) its
> simply contract law, AFAIK.
>
>
> > > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > > I can see, NMS is likely to be a "derived work" of JMS it is also
> > > likely that it breaches the copyright of the spec.
> > >
> >
> > I can assure you that no copying has taken place. NMS was initially
> > not an abstract messaging API. It was just an API to the .NET client
> > implementation for ActiveMQ. Once that started to take shape an
> > abstract API that has the same domain model as JMS was extracted from
> > the implementation. It would be more accurate to say that NMS is a
> > derived work of an ActiveMQ client.
>
> Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
> designed - as I understand it - as an implementation of the JMS spec,
Not really - it was designed to be a message broker of similar
capability as things like MSMQ, MQSeries & TibCo. So there's various
APIs, protocols and clients for connecting to it...
http://activemq.apache.org/protocols.html
http://activemq.apache.org/cross-language-clients.html
JMS is just the API used on the Java platform for working with a provider.
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: NMS
Posted by Jim Barnett <ji...@bea.com>.
Interesting proposition, however the concept of derived work in a strict
copyright sense (i.e., derivative work) may not apply to implementation
of a specification. Copyright protects against copying ultimately. A
derivative work is a work that is based on and actually includes part of
the copyrighted work that it is derived from. Remember, copyright
protects only expressions of ideas that are fixed in a tangible form,
and not the underlying ideas themselves.
Applying this to the example of a specification, the question as to
whether an implementation is a derivative work of the specification
depends on whether portions of the expression of the copyrighted
specification are present in the implementation. The more detailed a
specification is, generally the greater the potential that an
implementation is a derivative work. The converse is also true. Take
the JVM specification for example. It rather vaguely specifies that a
JVM needs "garbage collection". It is unlikely therefore that an
implementation of garbage collection logic in a JVM implementation would
be derivative of the vague GC portion of the JVM specification. There's
some fringe greyness perhaps in the area of non-literal copying, but
that's a story for another day.
"Tainting" has a few different guises. One of them is tainting in a
copyright sense. The elements of a prima facie case of copyright
infringement are (i) access to the copyrighted work by the alleged
infringer, and (ii) substantial similarity between the copyrighted work
and the alleged infringing work. A party becomes copyright "tainted"
when it can be documented that they had access to another party's
copyrighted work and later produce works with similarities to that
copyrighted work. Another flavour of tainting relates to trade secrets
and/or contractually defined confidential information. The contract or
license granting access to a third party trade secret or confidential
information defines the rules for use of that intellectual property by
the accessor. Depending on those rules and restrictions, later work by
the accessor in areas where the ideas embodied in the trade secrets or
confidential information have relevance may pose a heightened risk of
misappropriation or breach of confidentiality obligations. This latter
type of tainting risk is what "residuals clauses" are intended to
mitigate.
I haven't formed an opinion on the issue in chief yet, but thought the
above might be helpful in structuring our review of the issue regarding
similarities between the JMS specification and the NMS API.
Regards,
Jim
-----Original Message-----
From: Paul Fremantle [mailto:pzfreo@gmail.com]
Sent: Thursday, June 07, 2007 6:35 AM
To: Hiram Chirino
Cc: general@incubator.apache.org; legal-discuss@apache.org;
asimon@redhat.com
Subject: Re: NMS
Hiram
> I guess you are referring to the license to that allows a person to
> hold a copy of the JMS spec. I wonder if violating/terminating the
> that license IP taints any work created using Ideas obtain from it.
> Since this seems to be in the Idea category... I would have thought
> that there would need some patents in place to enforce it.
Not really. Once you agree to a contract (like that license) its
simply contract law, AFAIK.
> > at the JMS specification. Secondly the JMS copyright. Since, as far
as
> > I can see, NMS is likely to be a "derived work" of JMS it is also
> > likely that it breaches the copyright of the spec.
> >
>
> I can assure you that no copying has taken place. NMS was initially
> not an abstract messaging API. It was just an API to the .NET client
> implementation for ActiveMQ. Once that started to take shape an
> abstract API that has the same domain model as JMS was extracted from
> the implementation. It would be more accurate to say that NMS is a
> derived work of an ActiveMQ client.
Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
designed - as I understand it - as an implementation of the JMS spec,
then it is itself a derived work of the JMS spec, and therefore NMS is
a derived work too. Now the JMS Spec license allows you to create
derived works, as long as they are Java implementations, so ActiveMQ
as a JMS server is covered, but that coverage doesn't apply to NMS
because Sun specifically limited the license.
Regards,
Paul
> > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > I ceased use of and destroyed my copy of the Specification years
ago =)
> > >
> > > But seriously, what kind of IP is it that is being violated?
> > > copyright? patent? or some other kind that I'm not aware of?
> > >
> > > Regards,
> > > Hiram
> > >
> > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > We have been thinking about implementing the NMS API as part of
the
> > > > QPID .Net client. However we are concerned about potential legal
issues.
> > > > It seems to me that the NMS API is very similar to the JMS one
but the
> > > > JMS specification specifically licenses the technology "only for
Java".
> > > >
> > > > This is the relevant license, copied directly from the JMS Spec
> > > > document:
> > > >
> > > > "Subject to the terms and conditions of this license, Sun hereby
grants
> > > > you a fully-paid, non-exclusive, non-transferable, worldwide,
limited
> > > > license (without the right to sublicense) under Sun's
intellectual
> > > > property rights to review the Specification internally solely
for the
> > > > purpose of designing and developing your Java applets and
applications
> > > > intended to run on the Java platform. Other than this limited
license,
> > > > you acquire no right, title or interest in or to the
Specification or
> > > > any other Sun intellectual property. The Specification contains
the
> > > > proprietary information of Sun and may only be used in
accordance with
> > > > the license terms set forth herein. This license will terminate
> > > > immediately without notice from Sun if you fail to comply with
any
> > > > provision of this license. Upon termination or expiration of
this
> > > > license, you must cease use of or destroy the Specification."
> > > >
> > > > Does anybody know if this concern has already been raised?
> > > >
> > > > Regards
> > > >
> > > > Arnaud
> > > >
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and
educational
> > only. Statements made on this list are not privileged, do not
> > constitute legal advice, and do not necessarily reflect the opinions
> > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > official ASF policies and documents.
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: NMS
Posted by "Noel J. Bergman" <no...@devtech.com>.
AIUI, the legality of Sun's specification licenses is considered dubious.
Not that dubious defines a stance or action, just a note.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
>
> > I guess you are referring to the license to that allows a person to
> > hold a copy of the JMS spec. I wonder if violating/terminating the
> > that license IP taints any work created using Ideas obtain from it.
> > Since this seems to be in the Idea category... I would have thought
> > that there would need some patents in place to enforce it.
>
> Not really. Once you agree to a contract (like that license) its
> simply contract law, AFAIK.
>
>
> > > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > > I can see, NMS is likely to be a "derived work" of JMS it is also
> > > likely that it breaches the copyright of the spec.
> > >
> >
> > I can assure you that no copying has taken place. NMS was initially
> > not an abstract messaging API. It was just an API to the .NET client
> > implementation for ActiveMQ. Once that started to take shape an
> > abstract API that has the same domain model as JMS was extracted from
> > the implementation. It would be more accurate to say that NMS is a
> > derived work of an ActiveMQ client.
>
> Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
> designed - as I understand it - as an implementation of the JMS spec,
Not really - it was designed to be a message broker of similar
capability as things like MSMQ, MQSeries & TibCo. So there's various
APIs, protocols and clients for connecting to it...
http://activemq.apache.org/protocols.html
http://activemq.apache.org/cross-language-clients.html
JMS is just the API used on the Java platform for working with a provider.
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: NMS
Posted by "Noel J. Bergman" <no...@devtech.com>.
AIUI, the legality of Sun's specification licenses is considered dubious.
Not that dubious defines a stance or action, just a note.
--- Noel
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: NMS
Posted by "Noel J. Bergman" <no...@devtech.com>.
John O'Hara wrote:
> On the IETF thread, the early standards were 'clean'. And there is a
> requirement to register patent interests against RFC's.
Yes *early* IETF standards were clean, but they are supposed to be the
guardians of the I in IETF, and have been delinquent by allowing IP
constrained standards. Hence my comment that "the IETF has lost a lot of
credibility as an independent standards body, and really ought to be
ashamed." They should be taking a purely hardline on IP, and requiring that
all IP related to every single IETF standard be effectively turned over, not
caving to commercial interests.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
On the IETF thread, the early standards were 'clean'. And there is a
requirement to register patent interests against RFC's.
On 07/06/07, Noel J. Bergman <no...@devtech.com> wrote:
>
> Justin Erenkrantz wrote:
>
> > the IETF specifically permits (and, some may say, encourages)
> > encumbered standards now. So, even implementing IETF standards
> > is now dangerous.
>
> The IETF has lost a lot of credibility as an independent standards body,
> and
> really ought to be ashamed. But they are hardly the only one with a
> gutless
> approach to IP.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: NMS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 6/7/07, John O'Hara <jo...@gmail.com> wrote:
>> AMQP itself was designed mostly based on IETF concepts which are
>> unencumbered (like smtp, nntp, nfs).
>
> This is not true going forward as the IETF specifically permits (and,
> some may say, encourages) encumbered standards now. So, even
> implementing IETF standards is now dangerous. -- justin
But the point was clear - go back to primary sources, and avoid interim
encumbrances.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: NMS
Posted by "Noel J. Bergman" <no...@devtech.com>.
Justin Erenkrantz wrote:
> the IETF specifically permits (and, some may say, encourages)
> encumbered standards now. So, even implementing IETF standards
> is now dangerous.
The IETF has lost a lot of credibility as an independent standards body, and
really ought to be ashamed. But they are hardly the only one with a gutless
approach to IP.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 6/7/07, John O'Hara <jo...@gmail.com> wrote:
> AMQP itself was designed mostly based on IETF concepts which are
> unencumbered (like smtp, nntp, nfs).
This is not true going forward as the IETF specifically permits (and,
some may say, encourages) encumbered standards now. So, even
implementing IETF standards is now dangerous. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Fwd: NMS
Posted by James Strachan <ja...@gmail.com>.
Forwarding to legal as its another aspect of this possible 'JMS
specification reading tainting' issue...
---------- Forwarded message ----------
From: James Strachan <ja...@gmail.com>
Date: Jun 7, 2007 6:06 PM
Subject: Re: NMS
To: general@incubator.apache.org
On 6/7/07, John O'Hara <jo...@gmail.com> wrote:
> Bingo. Nicely explained.
>
> I'm glad someone else sees the problem.
>
> We need to keep our software 100% clean; its amazing how much IP law you
> need to know to write code and give it away.
>
> Which is why the generic form API for AMQP should be derived from AMQP, not
> JMS.
>
> AMQP itself was designed mostly based on IETF concepts which are
> unencumbered (like smtp, nntp, nfs). *After* it was designed it was checked
> against the JMS specification to see that a JMS API could be implemented in
> terms of AMQP primitives.
>
> AMQP is not derived from JMS and has different architecture principles.
Well, I certainly gave some non-trivial input in the early days of the
design of the AMQP protocol to change it to map more closely the
semantics of MOMs like MQSeries, TibCo and in particular to map more
closely to the semantics of JMS & its concepts. Admittedly this was
about 6 years after reading the JMS specification - but if a .Net API
is tainted by its authors having read the JMS specification then maybe
AMQP is tainted too?
--
James
-------
http://macstrac.blogspot.com/
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/7/07, John O'Hara <jo...@gmail.com> wrote:
> Bingo. Nicely explained.
>
> I'm glad someone else sees the problem.
>
> We need to keep our software 100% clean; its amazing how much IP law you
> need to know to write code and give it away.
>
> Which is why the generic form API for AMQP should be derived from AMQP, not
> JMS.
>
> AMQP itself was designed mostly based on IETF concepts which are
> unencumbered (like smtp, nntp, nfs). *After* it was designed it was checked
> against the JMS specification to see that a JMS API could be implemented in
> terms of AMQP primitives.
>
> AMQP is not derived from JMS and has different architecture principles.
Well, I certainly gave some non-trivial input in the early days of the
design of the AMQP protocol to change it to map more closely the
semantics of MOMs like MQSeries, TibCo and in particular to map more
closely to the semantics of JMS & its concepts. Admittedly this was
about 6 years after reading the JMS specification - but if a .Net API
is tainted by its authors having read the JMS specification then maybe
AMQP is tainted too?
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by robert burrell donkin <ro...@gmail.com>.
On 6/7/07, James Strachan <ja...@gmail.com> wrote:
> On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> > Maybe we should create a set of APIs that offer genuinely open access
> > to messaging systems on .NET, Java, C, C# etc. Of course if Sun wished
> > to offer us the JMS API under an unencumbered license we could do
> > that, otherwise we could start from scratch.
> >
> > This Apache Messaging API could then be freely implementable under
> > AL2.0 license rules without having to worry about this sort of IP
>
> FWIW this is why we created NMS for .Net and CMS for C++ along with
> APIs for Ruby, Python, Perl, PHP, Smalltalk and yes, even Flash as
> well. Though clearly we need clarifiation on whether reading the JMS
> specification 8 years ago (among using heaps of other similar APIs)
> rules you out of being able to create a messaging API ever again :)
sounds like some more process would be useful. we need to understand
and record how and who devised the API since it will necessarily be
similar to many other MOM APIs.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> Maybe we should create a set of APIs that offer genuinely open access
> to messaging systems on .NET, Java, C, C# etc. Of course if Sun wished
> to offer us the JMS API under an unencumbered license we could do
> that, otherwise we could start from scratch.
>
> This Apache Messaging API could then be freely implementable under
> AL2.0 license rules without having to worry about this sort of IP
FWIW this is why we created NMS for .Net and CMS for C++ along with
APIs for Ruby, Python, Perl, PHP, Smalltalk and yes, even Flash as
well. Though clearly we need clarifiation on whether reading the JMS
specification 8 years ago (among using heaps of other similar APIs)
rules you out of being able to create a messaging API ever again :)
--
James
-------
http://macstrac.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Maybe we should create a set of APIs that offer genuinely open access
to messaging systems on .NET, Java, C, C# etc. Of course if Sun wished
to offer us the JMS API under an unencumbered license we could do
that, otherwise we could start from scratch.
This Apache Messaging API could then be freely implementable under
AL2.0 license rules without having to worry about this sort of IP
****.
Paul
On 6/7/07, John O'Hara <jo...@gmail.com> wrote:
> Bingo. Nicely explained.
>
> I'm glad someone else sees the problem.
>
> We need to keep our software 100% clean; its amazing how much IP law you
> need to know to write code and give it away.
>
> Which is why the generic form API for AMQP should be derived from AMQP, not
> JMS.
>
> AMQP itself was designed mostly based on IETF concepts which are
> unencumbered (like smtp, nntp, nfs). *After* it was designed it was checked
> against the JMS specification to see that a JMS API could be implemented in
> terms of AMQP primitives.
>
> AMQP is not derived from JMS and has different architecture principles.
>
> Cheers
> John
>
>
> On 07/06/07, Paul Fremantle <pz...@gmail.com> wrote:
> >
> > Hiram
> >
> >
> > > I guess you are referring to the license to that allows a person to
> > > hold a copy of the JMS spec. I wonder if violating/terminating the
> > > that license IP taints any work created using Ideas obtain from it.
> > > Since this seems to be in the Idea category... I would have thought
> > > that there would need some patents in place to enforce it.
> >
> > Not really. Once you agree to a contract (like that license) its
> > simply contract law, AFAIK.
> >
> >
> > > > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > > > I can see, NMS is likely to be a "derived work" of JMS it is also
> > > > likely that it breaches the copyright of the spec.
> > > >
> > >
> > > I can assure you that no copying has taken place. NMS was initially
> > > not an abstract messaging API. It was just an API to the .NET client
> > > implementation for ActiveMQ. Once that started to take shape an
> > > abstract API that has the same domain model as JMS was extracted from
> > > the implementation. It would be more accurate to say that NMS is a
> > > derived work of an ActiveMQ client.
> >
> > Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
> > designed - as I understand it - as an implementation of the JMS spec,
> > then it is itself a derived work of the JMS spec, and therefore NMS is
> > a derived work too. Now the JMS Spec license allows you to create
> > derived works, as long as they are Java implementations, so ActiveMQ
> > as a JMS server is covered, but that coverage doesn't apply to NMS
> > because Sun specifically limited the license.
> >
> > Regards,
> > Paul
> >
> >
> > > > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > I ceased use of and destroyed my copy of the Specification years ago
> > =)
> > > > >
> > > > > But seriously, what kind of IP is it that is being violated?
> > > > > copyright? patent? or some other kind that I'm not aware of?
> > > > >
> > > > > Regards,
> > > > > Hiram
> > > > >
> > > > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > We have been thinking about implementing the NMS API as part of
> > the
> > > > > > QPID .Net client. However we are concerned about potential legal
> > issues.
> > > > > > It seems to me that the NMS API is very similar to the JMS one but
> > the
> > > > > > JMS specification specifically licenses the technology "only for
> > Java".
> > > > > >
> > > > > > This is the relevant license, copied directly from the JMS Spec
> > > > > > document:
> > > > > >
> > > > > > "Subject to the terms and conditions of this license, Sun hereby
> > grants
> > > > > > you a fully-paid, non-exclusive, non-transferable, worldwide,
> > limited
> > > > > > license (without the right to sublicense) under Sun's intellectual
> > > > > > property rights to review the Specification internally solely for
> > the
> > > > > > purpose of designing and developing your Java applets and
> > applications
> > > > > > intended to run on the Java platform. Other than this limited
> > license,
> > > > > > you acquire no right, title or interest in or to the Specification
> > or
> > > > > > any other Sun intellectual property. The Specification contains
> > the
> > > > > > proprietary information of Sun and may only be used in accordance
> > with
> > > > > > the license terms set forth herein. This license will terminate
> > > > > > immediately without notice from Sun if you fail to comply with any
> > > > > > provision of this license. Upon termination or expiration of this
> > > > > > license, you must cease use of or destroy the Specification."
> > > > > >
> > > > > > Does anybody know if this concern has already been raised?
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Arnaud
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Hiram
> > > > >
> > > > > Blog: http://hiramchirino.com
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Paul Fremantle
> > > > Co-Founder and VP of Technical Sales, WSO2
> > > > OASIS WS-RX TC Co-chair
> > > >
> > > > blog: http://pzf.fremantle.org
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > DISCLAIMER: Discussions on this list are informational and educational
> > > > only. Statements made on this list are not privileged, do not
> > > > constitute legal advice, and do not necessarily reflect the opinions
> > > > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > > > official ASF policies and documents.
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > > For additional commands, e-mail: legal-discuss-help@apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
Bingo. Nicely explained.
I'm glad someone else sees the problem.
We need to keep our software 100% clean; its amazing how much IP law you
need to know to write code and give it away.
Which is why the generic form API for AMQP should be derived from AMQP, not
JMS.
AMQP itself was designed mostly based on IETF concepts which are
unencumbered (like smtp, nntp, nfs). *After* it was designed it was checked
against the JMS specification to see that a JMS API could be implemented in
terms of AMQP primitives.
AMQP is not derived from JMS and has different architecture principles.
Cheers
John
On 07/06/07, Paul Fremantle <pz...@gmail.com> wrote:
>
> Hiram
>
>
> > I guess you are referring to the license to that allows a person to
> > hold a copy of the JMS spec. I wonder if violating/terminating the
> > that license IP taints any work created using Ideas obtain from it.
> > Since this seems to be in the Idea category... I would have thought
> > that there would need some patents in place to enforce it.
>
> Not really. Once you agree to a contract (like that license) its
> simply contract law, AFAIK.
>
>
> > > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > > I can see, NMS is likely to be a "derived work" of JMS it is also
> > > likely that it breaches the copyright of the spec.
> > >
> >
> > I can assure you that no copying has taken place. NMS was initially
> > not an abstract messaging API. It was just an API to the .NET client
> > implementation for ActiveMQ. Once that started to take shape an
> > abstract API that has the same domain model as JMS was extracted from
> > the implementation. It would be more accurate to say that NMS is a
> > derived work of an ActiveMQ client.
>
> Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
> designed - as I understand it - as an implementation of the JMS spec,
> then it is itself a derived work of the JMS spec, and therefore NMS is
> a derived work too. Now the JMS Spec license allows you to create
> derived works, as long as they are Java implementations, so ActiveMQ
> as a JMS server is covered, but that coverage doesn't apply to NMS
> because Sun specifically limited the license.
>
> Regards,
> Paul
>
>
> > > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > I ceased use of and destroyed my copy of the Specification years ago
> =)
> > > >
> > > > But seriously, what kind of IP is it that is being violated?
> > > > copyright? patent? or some other kind that I'm not aware of?
> > > >
> > > > Regards,
> > > > Hiram
> > > >
> > > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > > Hello,
> > > > >
> > > > > We have been thinking about implementing the NMS API as part of
> the
> > > > > QPID .Net client. However we are concerned about potential legal
> issues.
> > > > > It seems to me that the NMS API is very similar to the JMS one but
> the
> > > > > JMS specification specifically licenses the technology "only for
> Java".
> > > > >
> > > > > This is the relevant license, copied directly from the JMS Spec
> > > > > document:
> > > > >
> > > > > "Subject to the terms and conditions of this license, Sun hereby
> grants
> > > > > you a fully-paid, non-exclusive, non-transferable, worldwide,
> limited
> > > > > license (without the right to sublicense) under Sun's intellectual
> > > > > property rights to review the Specification internally solely for
> the
> > > > > purpose of designing and developing your Java applets and
> applications
> > > > > intended to run on the Java platform. Other than this limited
> license,
> > > > > you acquire no right, title or interest in or to the Specification
> or
> > > > > any other Sun intellectual property. The Specification contains
> the
> > > > > proprietary information of Sun and may only be used in accordance
> with
> > > > > the license terms set forth herein. This license will terminate
> > > > > immediately without notice from Sun if you fail to comply with any
> > > > > provision of this license. Upon termination or expiration of this
> > > > > license, you must cease use of or destroy the Specification."
> > > > >
> > > > > Does anybody know if this concern has already been raised?
> > > > >
> > > > > Regards
> > > > >
> > > > > Arnaud
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Paul Fremantle
> > > Co-Founder and VP of Technical Sales, WSO2
> > > OASIS WS-RX TC Co-chair
> > >
> > > blog: http://pzf.fremantle.org
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > > ---------------------------------------------------------------------
> > > DISCLAIMER: Discussions on this list are informational and educational
> > > only. Statements made on this list are not privileged, do not
> > > constitute legal advice, and do not necessarily reflect the opinions
> > > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > > official ASF policies and documents.
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > > For additional commands, e-mail: legal-discuss-help@apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: NMS
Posted by Jim Barnett <ji...@bea.com>.
Interesting proposition, however the concept of derived work in a strict
copyright sense (i.e., derivative work) may not apply to implementation
of a specification. Copyright protects against copying ultimately. A
derivative work is a work that is based on and actually includes part of
the copyrighted work that it is derived from. Remember, copyright
protects only expressions of ideas that are fixed in a tangible form,
and not the underlying ideas themselves.
Applying this to the example of a specification, the question as to
whether an implementation is a derivative work of the specification
depends on whether portions of the expression of the copyrighted
specification are present in the implementation. The more detailed a
specification is, generally the greater the potential that an
implementation is a derivative work. The converse is also true. Take
the JVM specification for example. It rather vaguely specifies that a
JVM needs "garbage collection". It is unlikely therefore that an
implementation of garbage collection logic in a JVM implementation would
be derivative of the vague GC portion of the JVM specification. There's
some fringe greyness perhaps in the area of non-literal copying, but
that's a story for another day.
"Tainting" has a few different guises. One of them is tainting in a
copyright sense. The elements of a prima facie case of copyright
infringement are (i) access to the copyrighted work by the alleged
infringer, and (ii) substantial similarity between the copyrighted work
and the alleged infringing work. A party becomes copyright "tainted"
when it can be documented that they had access to another party's
copyrighted work and later produce works with similarities to that
copyrighted work. Another flavour of tainting relates to trade secrets
and/or contractually defined confidential information. The contract or
license granting access to a third party trade secret or confidential
information defines the rules for use of that intellectual property by
the accessor. Depending on those rules and restrictions, later work by
the accessor in areas where the ideas embodied in the trade secrets or
confidential information have relevance may pose a heightened risk of
misappropriation or breach of confidentiality obligations. This latter
type of tainting risk is what "residuals clauses" are intended to
mitigate.
I haven't formed an opinion on the issue in chief yet, but thought the
above might be helpful in structuring our review of the issue regarding
similarities between the JMS specification and the NMS API.
Regards,
Jim
-----Original Message-----
From: Paul Fremantle [mailto:pzfreo@gmail.com]
Sent: Thursday, June 07, 2007 6:35 AM
To: Hiram Chirino
Cc: general@incubator.apache.org; legal-discuss@apache.org;
asimon@redhat.com
Subject: Re: NMS
Hiram
> I guess you are referring to the license to that allows a person to
> hold a copy of the JMS spec. I wonder if violating/terminating the
> that license IP taints any work created using Ideas obtain from it.
> Since this seems to be in the Idea category... I would have thought
> that there would need some patents in place to enforce it.
Not really. Once you agree to a contract (like that license) its
simply contract law, AFAIK.
> > at the JMS specification. Secondly the JMS copyright. Since, as far
as
> > I can see, NMS is likely to be a "derived work" of JMS it is also
> > likely that it breaches the copyright of the spec.
> >
>
> I can assure you that no copying has taken place. NMS was initially
> not an abstract messaging API. It was just an API to the .NET client
> implementation for ActiveMQ. Once that started to take shape an
> abstract API that has the same domain model as JMS was extracted from
> the implementation. It would be more accurate to say that NMS is a
> derived work of an ActiveMQ client.
Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
designed - as I understand it - as an implementation of the JMS spec,
then it is itself a derived work of the JMS spec, and therefore NMS is
a derived work too. Now the JMS Spec license allows you to create
derived works, as long as they are Java implementations, so ActiveMQ
as a JMS server is covered, but that coverage doesn't apply to NMS
because Sun specifically limited the license.
Regards,
Paul
> > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > I ceased use of and destroyed my copy of the Specification years
ago =)
> > >
> > > But seriously, what kind of IP is it that is being violated?
> > > copyright? patent? or some other kind that I'm not aware of?
> > >
> > > Regards,
> > > Hiram
> > >
> > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > We have been thinking about implementing the NMS API as part of
the
> > > > QPID .Net client. However we are concerned about potential legal
issues.
> > > > It seems to me that the NMS API is very similar to the JMS one
but the
> > > > JMS specification specifically licenses the technology "only for
Java".
> > > >
> > > > This is the relevant license, copied directly from the JMS Spec
> > > > document:
> > > >
> > > > "Subject to the terms and conditions of this license, Sun hereby
grants
> > > > you a fully-paid, non-exclusive, non-transferable, worldwide,
limited
> > > > license (without the right to sublicense) under Sun's
intellectual
> > > > property rights to review the Specification internally solely
for the
> > > > purpose of designing and developing your Java applets and
applications
> > > > intended to run on the Java platform. Other than this limited
license,
> > > > you acquire no right, title or interest in or to the
Specification or
> > > > any other Sun intellectual property. The Specification contains
the
> > > > proprietary information of Sun and may only be used in
accordance with
> > > > the license terms set forth herein. This license will terminate
> > > > immediately without notice from Sun if you fail to comply with
any
> > > > provision of this license. Upon termination or expiration of
this
> > > > license, you must cease use of or destroy the Specification."
> > > >
> > > > Does anybody know if this concern has already been raised?
> > > >
> > > > Regards
> > > >
> > > > Arnaud
> > > >
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> >
---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and
educational
> > only. Statements made on this list are not privileged, do not
> > constitute legal advice, and do not necessarily reflect the opinions
> > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > official ASF policies and documents.
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
> I guess you are referring to the license to that allows a person to
> hold a copy of the JMS spec. I wonder if violating/terminating the
> that license IP taints any work created using Ideas obtain from it.
> Since this seems to be in the Idea category... I would have thought
> that there would need some patents in place to enforce it.
Not really. Once you agree to a contract (like that license) its
simply contract law, AFAIK.
> > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > I can see, NMS is likely to be a "derived work" of JMS it is also
> > likely that it breaches the copyright of the spec.
> >
>
> I can assure you that no copying has taken place. NMS was initially
> not an abstract messaging API. It was just an API to the .NET client
> implementation for ActiveMQ. Once that started to take shape an
> abstract API that has the same domain model as JMS was extracted from
> the implementation. It would be more accurate to say that NMS is a
> derived work of an ActiveMQ client.
Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
designed - as I understand it - as an implementation of the JMS spec,
then it is itself a derived work of the JMS spec, and therefore NMS is
a derived work too. Now the JMS Spec license allows you to create
derived works, as long as they are Java implementations, so ActiveMQ
as a JMS server is covered, but that coverage doesn't apply to NMS
because Sun specifically limited the license.
Regards,
Paul
> > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > I ceased use of and destroyed my copy of the Specification years ago =)
> > >
> > > But seriously, what kind of IP is it that is being violated?
> > > copyright? patent? or some other kind that I'm not aware of?
> > >
> > > Regards,
> > > Hiram
> > >
> > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > We have been thinking about implementing the NMS API as part of the
> > > > QPID .Net client. However we are concerned about potential legal issues.
> > > > It seems to me that the NMS API is very similar to the JMS one but the
> > > > JMS specification specifically licenses the technology "only for Java".
> > > >
> > > > This is the relevant license, copied directly from the JMS Spec
> > > > document:
> > > >
> > > > "Subject to the terms and conditions of this license, Sun hereby grants
> > > > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > > > license (without the right to sublicense) under Sun's intellectual
> > > > property rights to review the Specification internally solely for the
> > > > purpose of designing and developing your Java applets and applications
> > > > intended to run on the Java platform. Other than this limited license,
> > > > you acquire no right, title or interest in or to the Specification or
> > > > any other Sun intellectual property. The Specification contains the
> > > > proprietary information of Sun and may only be used in accordance with
> > > > the license terms set forth herein. This license will terminate
> > > > immediately without notice from Sun if you fail to comply with any
> > > > provision of this license. Upon termination or expiration of this
> > > > license, you must cease use of or destroy the Specification."
> > > >
> > > > Does anybody know if this concern has already been raised?
> > > >
> > > > Regards
> > > >
> > > > Arnaud
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and educational
> > only. Statements made on this list are not privileged, do not
> > constitute legal advice, and do not necessarily reflect the opinions
> > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > official ASF policies and documents.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
> I guess you are referring to the license to that allows a person to
> hold a copy of the JMS spec. I wonder if violating/terminating the
> that license IP taints any work created using Ideas obtain from it.
> Since this seems to be in the Idea category... I would have thought
> that there would need some patents in place to enforce it.
Not really. Once you agree to a contract (like that license) its
simply contract law, AFAIK.
> > at the JMS specification. Secondly the JMS copyright. Since, as far as
> > I can see, NMS is likely to be a "derived work" of JMS it is also
> > likely that it breaches the copyright of the spec.
> >
>
> I can assure you that no copying has taken place. NMS was initially
> not an abstract messaging API. It was just an API to the .NET client
> implementation for ActiveMQ. Once that started to take shape an
> abstract API that has the same domain model as JMS was extracted from
> the implementation. It would be more accurate to say that NMS is a
> derived work of an ActiveMQ client.
Yes, but where did the ActiveMQ design come from? Since ActiveMQ was
designed - as I understand it - as an implementation of the JMS spec,
then it is itself a derived work of the JMS spec, and therefore NMS is
a derived work too. Now the JMS Spec license allows you to create
derived works, as long as they are Java implementations, so ActiveMQ
as a JMS server is covered, but that coverage doesn't apply to NMS
because Sun specifically limited the license.
Regards,
Paul
> > On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > I ceased use of and destroyed my copy of the Specification years ago =)
> > >
> > > But seriously, what kind of IP is it that is being violated?
> > > copyright? patent? or some other kind that I'm not aware of?
> > >
> > > Regards,
> > > Hiram
> > >
> > > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > > Hello,
> > > >
> > > > We have been thinking about implementing the NMS API as part of the
> > > > QPID .Net client. However we are concerned about potential legal issues.
> > > > It seems to me that the NMS API is very similar to the JMS one but the
> > > > JMS specification specifically licenses the technology "only for Java".
> > > >
> > > > This is the relevant license, copied directly from the JMS Spec
> > > > document:
> > > >
> > > > "Subject to the terms and conditions of this license, Sun hereby grants
> > > > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > > > license (without the right to sublicense) under Sun's intellectual
> > > > property rights to review the Specification internally solely for the
> > > > purpose of designing and developing your Java applets and applications
> > > > intended to run on the Java platform. Other than this limited license,
> > > > you acquire no right, title or interest in or to the Specification or
> > > > any other Sun intellectual property. The Specification contains the
> > > > proprietary information of Sun and may only be used in accordance with
> > > > the license terms set forth herein. This license will terminate
> > > > immediately without notice from Sun if you fail to comply with any
> > > > provision of this license. Upon termination or expiration of this
> > > > license, you must cease use of or destroy the Specification."
> > > >
> > > > Does anybody know if this concern has already been raised?
> > > >
> > > > Regards
> > > >
> > > > Arnaud
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > Co-Founder and VP of Technical Sales, WSO2
> > OASIS WS-RX TC Co-chair
> >
> > blog: http://pzf.fremantle.org
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and educational
> > only. Statements made on this list are not privileged, do not
> > constitute legal advice, and do not necessarily reflect the opinions
> > and policies of the ASF. See <http://www.apache.org/licenses/> for
> > official ASF policies and documents.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
> I'm not sure about whether Sun has relevant patents on the JMS APIs.
> Howver, there are two things that may have been violated. Firstly, the
> license agreement that was "clicked-through" whenever someone looked
I guess you are referring to the license to that allows a person to
hold a copy of the JMS spec. I wonder if violating/terminating the
that license IP taints any work created using Ideas obtain from it.
Since this seems to be in the Idea category... I would have thought
that there would need some patents in place to enforce it.
> at the JMS specification. Secondly the JMS copyright. Since, as far as
> I can see, NMS is likely to be a "derived work" of JMS it is also
> likely that it breaches the copyright of the spec.
>
I can assure you that no copying has taken place. NMS was initially
not an abstract messaging API. It was just an API to the .NET client
implementation for ActiveMQ. Once that started to take shape an
abstract API that has the same domain model as JMS was extracted from
the implementation. It would be more accurate to say that NMS is a
derived work of an ActiveMQ client.
Regards,
Hiram
> Paul
>
> On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > I ceased use of and destroyed my copy of the Specification years ago =)
> >
> > But seriously, what kind of IP is it that is being violated?
> > copyright? patent? or some other kind that I'm not aware of?
> >
> > Regards,
> > Hiram
> >
> > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > Hello,
> > >
> > > We have been thinking about implementing the NMS API as part of the
> > > QPID .Net client. However we are concerned about potential legal issues.
> > > It seems to me that the NMS API is very similar to the JMS one but the
> > > JMS specification specifically licenses the technology "only for Java".
> > >
> > > This is the relevant license, copied directly from the JMS Spec
> > > document:
> > >
> > > "Subject to the terms and conditions of this license, Sun hereby grants
> > > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > > license (without the right to sublicense) under Sun's intellectual
> > > property rights to review the Specification internally solely for the
> > > purpose of designing and developing your Java applets and applications
> > > intended to run on the Java platform. Other than this limited license,
> > > you acquire no right, title or interest in or to the Specification or
> > > any other Sun intellectual property. The Specification contains the
> > > proprietary information of Sun and may only be used in accordance with
> > > the license terms set forth herein. This license will terminate
> > > immediately without notice from Sun if you fail to comply with any
> > > provision of this license. Upon termination or expiration of this
> > > license, you must cease use of or destroy the Specification."
> > >
> > > Does anybody know if this concern has already been raised?
> > >
> > > Regards
> > >
> > > Arnaud
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/7/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
> I'm not sure about whether Sun has relevant patents on the JMS APIs.
> Howver, there are two things that may have been violated. Firstly, the
> license agreement that was "clicked-through" whenever someone looked
I guess you are referring to the license to that allows a person to
hold a copy of the JMS spec. I wonder if violating/terminating the
that license IP taints any work created using Ideas obtain from it.
Since this seems to be in the Idea category... I would have thought
that there would need some patents in place to enforce it.
> at the JMS specification. Secondly the JMS copyright. Since, as far as
> I can see, NMS is likely to be a "derived work" of JMS it is also
> likely that it breaches the copyright of the spec.
>
I can assure you that no copying has taken place. NMS was initially
not an abstract messaging API. It was just an API to the .NET client
implementation for ActiveMQ. Once that started to take shape an
abstract API that has the same domain model as JMS was extracted from
the implementation. It would be more accurate to say that NMS is a
derived work of an ActiveMQ client.
Regards,
Hiram
> Paul
>
> On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > I ceased use of and destroyed my copy of the Specification years ago =)
> >
> > But seriously, what kind of IP is it that is being violated?
> > copyright? patent? or some other kind that I'm not aware of?
> >
> > Regards,
> > Hiram
> >
> > On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > > Hello,
> > >
> > > We have been thinking about implementing the NMS API as part of the
> > > QPID .Net client. However we are concerned about potential legal issues.
> > > It seems to me that the NMS API is very similar to the JMS one but the
> > > JMS specification specifically licenses the technology "only for Java".
> > >
> > > This is the relevant license, copied directly from the JMS Spec
> > > document:
> > >
> > > "Subject to the terms and conditions of this license, Sun hereby grants
> > > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > > license (without the right to sublicense) under Sun's intellectual
> > > property rights to review the Specification internally solely for the
> > > purpose of designing and developing your Java applets and applications
> > > intended to run on the Java platform. Other than this limited license,
> > > you acquire no right, title or interest in or to the Specification or
> > > any other Sun intellectual property. The Specification contains the
> > > proprietary information of Sun and may only be used in accordance with
> > > the license terms set forth herein. This license will terminate
> > > immediately without notice from Sun if you fail to comply with any
> > > provision of this license. Upon termination or expiration of this
> > > license, you must cease use of or destroy the Specification."
> > >
> > > Does anybody know if this concern has already been raised?
> > >
> > > Regards
> > >
> > > Arnaud
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only. Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF. See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
I'm not sure about whether Sun has relevant patents on the JMS APIs.
Howver, there are two things that may have been violated. Firstly, the
license agreement that was "clicked-through" whenever someone looked
at the JMS specification. Secondly the JMS copyright. Since, as far as
I can see, NMS is likely to be a "derived work" of JMS it is also
likely that it breaches the copyright of the spec.
Paul
On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I ceased use of and destroyed my copy of the Specification years ago =)
>
> But seriously, what kind of IP is it that is being violated?
> copyright? patent? or some other kind that I'm not aware of?
>
> Regards,
> Hiram
>
> On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part of the
> > QPID .Net client. However we are concerned about potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS one but the
> > JMS specification specifically licenses the technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun hereby grants
> > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > license (without the right to sublicense) under Sun's intellectual
> > property rights to review the Specification internally solely for the
> > purpose of designing and developing your Java applets and applications
> > intended to run on the Java platform. Other than this limited license,
> > you acquire no right, title or interest in or to the Specification or
> > any other Sun intellectual property. The Specification contains the
> > proprietary information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will terminate
> > immediately without notice from Sun if you fail to comply with any
> > provision of this license. Upon termination or expiration of this
> > license, you must cease use of or destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
I'm not sure about whether Sun has relevant patents on the JMS APIs.
Howver, there are two things that may have been violated. Firstly, the
license agreement that was "clicked-through" whenever someone looked
at the JMS specification. Secondly the JMS copyright. Since, as far as
I can see, NMS is likely to be a "derived work" of JMS it is also
likely that it breaches the copyright of the spec.
Paul
On 6/7/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I ceased use of and destroyed my copy of the Specification years ago =)
>
> But seriously, what kind of IP is it that is being violated?
> copyright? patent? or some other kind that I'm not aware of?
>
> Regards,
> Hiram
>
> On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part of the
> > QPID .Net client. However we are concerned about potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS one but the
> > JMS specification specifically licenses the technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun hereby grants
> > you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> > license (without the right to sublicense) under Sun's intellectual
> > property rights to review the Specification internally solely for the
> > purpose of designing and developing your Java applets and applications
> > intended to run on the Java platform. Other than this limited license,
> > you acquire no right, title or interest in or to the Specification or
> > any other Sun intellectual property. The Specification contains the
> > proprietary information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will terminate
> > immediately without notice from Sun if you fail to comply with any
> > provision of this license. Upon termination or expiration of this
> > license, you must cease use of or destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I ceased use of and destroyed my copy of the Specification years ago =)
But seriously, what kind of IP is it that is being violated?
copyright? patent? or some other kind that I'm not aware of?
Regards,
Hiram
On 6/1/07, Arnaud Simon <as...@redhat.com> wrote:
> Hello,
>
> We have been thinking about implementing the NMS API as part of the
> QPID .Net client. However we are concerned about potential legal issues.
> It seems to me that the NMS API is very similar to the JMS one but the
> JMS specification specifically licenses the technology "only for Java".
>
> This is the relevant license, copied directly from the JMS Spec
> document:
>
> "Subject to the terms and conditions of this license, Sun hereby grants
> you a fully-paid, non-exclusive, non-transferable, worldwide, limited
> license (without the right to sublicense) under Sun's intellectual
> property rights to review the Specification internally solely for the
> purpose of designing and developing your Java applets and applications
> intended to run on the Java platform. Other than this limited license,
> you acquire no right, title or interest in or to the Specification or
> any other Sun intellectual property. The Specification contains the
> proprietary information of Sun and may only be used in accordance with
> the license terms set forth herein. This license will terminate
> immediately without notice from Sun if you fail to comply with any
> provision of this license. Upon termination or expiration of this
> license, you must cease use of or destroy the Specification."
>
> Does anybody know if this concern has already been raised?
>
> Regards
>
> Arnaud
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Arnaud Simon <as...@redhat.com>.
Hiram,
Sorry for the statement "Even the ActiveMQ guys cannot agree" but I
thought that "Paul Fremantle" was an ActiveMQ contributor.
As you said we need legal council to provide an opinion on the
situation. But from the Qpid/AMQP point of view I am more worry about
NMS confusing people rather than introducing legal issues.
Arnaud
On Mon, 2007-06-11 at 10:53 -0400, Hiram Chirino wrote:
> I was just trying to clear up the earlier statement that "Even the
> ActiveMQ guys cannot agree." I don't think any of the ActiveMQ guys
> thought that NMS would have any problems. I think we can all agree
> that we would like legal council to provide an opinion on the
> situation, but I don't think it's fair to say that "Even the ActiveMQ
> guys cannot agree."
>
> Regards,
> Hiram
>
> On 6/11/07, Robert Greig <ro...@gmail.com> wrote:
> > On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >
> > > All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> > > Please stop the FUD.
> >
> > With the greatest respect, we are really looking for expert legal
> > opinion on this matter. Have you taken legal advice on this?
> >
> > Robert
> >
>
>
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I was just trying to clear up the earlier statement that "Even the
ActiveMQ guys cannot agree." I don't think any of the ActiveMQ guys
thought that NMS would have any problems. I think we can all agree
that we would like legal council to provide an opinion on the
situation, but I don't think it's fair to say that "Even the ActiveMQ
guys cannot agree."
Regards,
Hiram
On 6/11/07, Robert Greig <ro...@gmail.com> wrote:
> On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> > All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> > Please stop the FUD.
>
> With the greatest respect, we are really looking for expert legal
> opinion on this matter. Have you taken legal advice on this?
>
> Robert
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> Please stop the FUD.
With the greatest respect, we are really looking for expert legal
opinion on this matter. Have you taken legal advice on this?
Robert
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> The specifications were renumbered before AMQP WG was formed.
OK thanks.
> Let's talk, I want to make sure any contribution is correctly recognised.
I don't really mind about that; it was a very long time ago :). Am
more bothered about clearing up this (hopefully bogus) JMS spec
tainting issue for the good of both projects.
> Please remember, you are under NDA with respect to this, so let's do it with
> direct email!
OK!
--
James
-------
http://macstrac.blogspot.com/
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
The specifications were renumbered before AMQP WG was formed.
Let's talk, I want to make sure any contribution is correctly recognised.
Please remember, you are under NDA with respect to this, so let's do it with
direct email!
Cheers
John
On 11/06/07, James Strachan <ja...@gmail.com> wrote:
>
> On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> > "..please consider that the same folks who developed NMS helped develop
> the
> > AMQP specification so the same alleged 'taint' that is being claimed
> against
> > NMS would also apply to AMQP."
> >
> > To clarify.
> > James is not the source of any of the content of the AMQP specification
> thru
> > v0-9, to the best of my knowledge.
>
> So I've just been through my AMQP spec emails; The first version I was
> sent was 0.3a4 in August 2004 then I contributed to the specification
> up to around April 2005 when it had reached around 0.81a.
>
> So what happened to the specification I worked on? Was a new group
> formed excluding all the folks who were on the mailing list I was on
> (including yourself John you were on the mailing list with me) and
> were all versions of AMQP destroyed and a new cleanroom version
> created after 0.81a, ignoring all that previous work?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
So this takes me back to my proposal (earlier in this thread) that we
create a cross-language cross-messaging API that is both *good* and
*open*. The claim was that NMS/CMS/JMS is that API, but
1) I don't think you can really claim that NMS was independently developed.
2) I agree with John that we could do better.
Paul
On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> With JMS/NMS it's more likely to do with Copyright.
> The question is "Is NMS derived from JMS", not about other aspects of IP,
> but we need a lawyers comment.
>
> If the API looked substantially different from JMS there probably wouldn't
> be an issue.
>
> Since JMS is not the greatest messaging API in the world, imho, why do other
> languages have to suffer from it?
> Not everyone using these other languages has seen JMS.
>
> Given AMQP (above rant aside) was engineered to be cross platform/language -
> why not start with a fairly thin AMQP-centric API?
> Then on top of it build JMS, WCF, etc...
>
> JMS by no means the only shape for a messaging API.
>
> Just my 2c
> John
>
>
>
>
>
>
> On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >
> > I share the same sentiment. The 'tainting' assumptions that are being
> > made around the JMS spec need to get resolved ASAP for the sake of
> > both the projects.
> >
> > On 6/11/07, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > > You can not seriously tell me that because you've read the JMS spec you
> > may
> > > not write a spec for a messaging protocol, without breaking the rules of
> > the
> > > JMS spec. This discussion is bordering on the ridiculous.
> > >
> > > On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> > > >
> > > > On 6/11/07, John O'Hara < john.r.ohara@gmail.com> wrote:
> > > > > "..please consider that the same folks who developed NMS helped
> > develop
> > > > the
> > > > > AMQP specification so the same alleged 'taint' that is being claimed
> >
> > > > against
> > > > > NMS would also apply to AMQP."
> > > > >
> > > > > To clarify.
> > > > > James is not the source of any of the content of the AMQP
> > specification
> > > > thru
> > > > > v0-9, to the best of my knowledge.
> > > >
> > > > So I've just been through my AMQP spec emails; The first version I was
> > > > sent was 0.3a4 in August 2004 then I contributed to the specification
> > > > up to around April 2005 when it had reached around 0.81a.
> > > >
> > > > So what happened to the specification I worked on? Was a new group
> > > > formed excluding all the folks who were on the mailing list I was on
> > > > (including yourself John you were on the mailing list with me) and
> > > > were all versions of AMQP destroyed and a new cleanroom version
> > > > created after 0.81a, ignoring all that previous work?
> > > >
> > > > --
> > > > James
> > > > -------
> > > > http://macstrac.blogspot.com/
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
Other than noting that things sometimes turn out better the second time
around...
On 12/06/07, Rupert Smith <ru...@googlemail.com> wrote:
>
> Ok, I understand that. I was meaning an AMQP API and not a Qpid one. Its
> doesn't make sense to me to have to write all of the client code twice, when
> it could be done once.
>
> On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> >
> > Rupert,
> >
> > while we in Qpid may wish to start having ideas on an API... the AMQP
> > group has indicated it as a goal to have such an API deifned by AMQP.
> >
> > I don't think we should expend too much effort in that direction
> > purely as Qpid. Further, there will likely be more changes after 0-10
> > (although hopefully of a smaller magnitude), before we get to AMQP
> > 1-0.
> >
> > I suggest that while we may start thinking about an AMQP API right
> > now, we do not try to prematurely standardize.
> >
> > My suggestion remains that we use (in the Java version at least) an
> > "AMQP"-style API internally; and that early adopters *may* wish to use
> > this API but must do so with the knowledge that its is likely to
> > undergo change which may not have backwards compatability.
> >
> > From an interoperability point of view; the other important area we
> > must cover is to have the other Qpid clients easily able to produce
> > messages that are understood in JMS. For instance being able to
> > easily send "text", "stream" or "map" messages. This will need to be
> > standardized for AMQP - but for the moment at least having
> > interoperability at this level between the AMQP clients would be nice.
> >
> > -- Rob
> >
> > On 12/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > John,
> > >
> > > If this is to be the agreed way forward, I think it makes sense to
> > start
> > > defining that API as soon as possible. Rather than begining coding for
> > the
> > > 0.10 spec in an ad-hoc way; I think it is worth investing a little bit
> > of
> > > time in deciding up-front the shape of that API prior to coding.
> > >
> > > Personally, I'm +1 for this idea.
> > >
> > > Rupert
> > >
> > > On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
> > > >
> > > > >
> > > > > I'm going to bet that your average development shop is willing to
> > > > > sacrifice a little bit of performance of feature access in order
> > to
> > > > > gain the ability to choose between messaging vendors. APIs are
> > what
> > > > > usually lock in an application to a specific vendor. If the
> > > > > application uses an abstract API, vendor lock in can potentially
> > be
> > > > > avoided.
> > > > >
> > > >
> > > > 100% true. Which is why most applications have their own shim layer
> > too
> > > > :-)
> > > > In some ways, WCF and BizTalk are Microsoft's shims.
> > > >
> > > > Perhaps we're at concensus here:
> > > >
> > > > 1) Do non-Java API's for Qpid that is not constrained by the JMS
> > > > legacy. In
> > > > all liklihood, the same shape of API will be available for Java too,
> > just
> > > > for completeness, in addition to JMS support.
> > > >
> > > > 2) Build a WCF driver for Qpid, atop 1)
> > > >
> > > > 3) Those who are interested can map NMS to 1) also.
> > > >
> > > > Now we just need to decide the shape of that lower level API.
> > > > There is a lot of talk in the AMQP camp about doing a standard shape
> > API.
> > > > We already have some candidates in the wild from iMatix, Apache, and
> > > > Rabbit,
> > > > and there have been side discussions about having a beauty contest
> > or
> > > > doing
> > > > pick'n'mix.
> > > >
> > > > The API needs to look good and feel right. I get terrified when I
> > think
> > > > of
> > > > the last thing that tried to standardise an API shape across
> > languages --
> > > > DOM. I'm sure we can have something nicer looking than that ;-)
> > > >
> > > > Comments?
> > > > John
> > > >
> > >
> >
>
>
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
Ok, I understand that. I was meaning an AMQP API and not a Qpid one. Its
doesn't make sense to me to have to write all of the client code twice, when
it could be done once.
On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> Rupert,
>
> while we in Qpid may wish to start having ideas on an API... the AMQP
> group has indicated it as a goal to have such an API deifned by AMQP.
>
> I don't think we should expend too much effort in that direction
> purely as Qpid. Further, there will likely be more changes after 0-10
> (although hopefully of a smaller magnitude), before we get to AMQP
> 1-0.
>
> I suggest that while we may start thinking about an AMQP API right
> now, we do not try to prematurely standardize.
>
> My suggestion remains that we use (in the Java version at least) an
> "AMQP"-style API internally; and that early adopters *may* wish to use
> this API but must do so with the knowledge that its is likely to
> undergo change which may not have backwards compatability.
>
> From an interoperability point of view; the other important area we
> must cover is to have the other Qpid clients easily able to produce
> messages that are understood in JMS. For instance being able to
> easily send "text", "stream" or "map" messages. This will need to be
> standardized for AMQP - but for the moment at least having
> interoperability at this level between the AMQP clients would be nice.
>
> -- Rob
>
> On 12/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> > John,
> >
> > If this is to be the agreed way forward, I think it makes sense to start
> > defining that API as soon as possible. Rather than begining coding for
> the
> > 0.10 spec in an ad-hoc way; I think it is worth investing a little bit
> of
> > time in deciding up-front the shape of that API prior to coding.
> >
> > Personally, I'm +1 for this idea.
> >
> > Rupert
> >
> > On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
> > >
> > > >
> > > > I'm going to bet that your average development shop is willing to
> > > > sacrifice a little bit of performance of feature access in order to
> > > > gain the ability to choose between messaging vendors. APIs are what
> > > > usually lock in an application to a specific vendor. If the
> > > > application uses an abstract API, vendor lock in can potentially be
> > > > avoided.
> > > >
> > >
> > > 100% true. Which is why most applications have their own shim layer
> too
> > > :-)
> > > In some ways, WCF and BizTalk are Microsoft's shims.
> > >
> > > Perhaps we're at concensus here:
> > >
> > > 1) Do non-Java API's for Qpid that is not constrained by the JMS
> > > legacy. In
> > > all liklihood, the same shape of API will be available for Java too,
> just
> > > for completeness, in addition to JMS support.
> > >
> > > 2) Build a WCF driver for Qpid, atop 1)
> > >
> > > 3) Those who are interested can map NMS to 1) also.
> > >
> > > Now we just need to decide the shape of that lower level API.
> > > There is a lot of talk in the AMQP camp about doing a standard shape
> API.
> > > We already have some candidates in the wild from iMatix, Apache, and
> > > Rabbit,
> > > and there have been side discussions about having a beauty contest or
> > > doing
> > > pick'n'mix.
> > >
> > > The API needs to look good and feel right. I get terrified when I
> think
> > > of
> > > the last thing that tried to standardise an API shape across languages
> --
> > > DOM. I'm sure we can have something nicer looking than that ;-)
> > >
> > > Comments?
> > > John
> > >
> >
>
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
Anyone can write any API they like.
I think that's not a huge issue just now.
On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
> > This is just one of those bullets that we have to bite on.
> >
> > AMQP is "getting there", seeing what the low level API shapes out as is
> part
> > of the stabalising process.
> >
> > Top down design / bottom up design -- need both at the same time in my
> > experience.
>
> true... my only concern is from the IP point of view... the Qpid
> project is, rightly, open to those who have not signed the necessary
> IP legal agreements to contribute to AMQP... thus could any work that
> is done as Qpid actually be contributed to AMQP? Would it create
> problems for those of us who wear both hats?
>
> Others who are better versed in the IP issues than me should probably
> comment here!
>
> Cheers,
> Rob
>
> >
> > On 12/06/07, Robert Greig <ro...@gmail.com> wrote:
> > >
> > > On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> > >
> > > > I don't think we should expend too much effort in that direction
> > > > purely as Qpid. Further, there will likely be more changes after
> 0-10
> > > > (although hopefully of a smaller magnitude), before we get to AMQP
> > > > 1-0.
> > > >
> > > > I suggest that while we may start thinking about an AMQP API right
> > > > now, we do not try to prematurely standardize.
> > > >
> > > > My suggestion remains that we use (in the Java version at least) an
> > > > "AMQP"-style API internally; and that early adopters *may* wish to
> use
> > > > this API but must do so with the knowledge that its is likely to
> > > > undergo change which may not have backwards compatability.
> > > >
> > > > From an interoperability point of view; the other important area we
> > > > must cover is to have the other Qpid clients easily able to produce
> > > > messages that are understood in JMS. For instance being able to
> > > > easily send "text", "stream" or "map" messages. This will need to
> be
> > > > standardized for AMQP - but for the moment at least having
> > > > interoperability at this level between the AMQP clients would be
> nice.
> > >
> > > Completely agree with all of the above.
> > >
> > > The discussion of an AMQP API has come up several times in the past
> > > and I think given how much the protocol has evolved/is likely to
> > > evolve it is still too early to focus on attempting to create some
> > > kind of standard API.
> > >
> > > RG
> > >
> >
>
Re: NMS
Posted by Robert Godfrey <ro...@gmail.com>.
On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
> This is just one of those bullets that we have to bite on.
>
> AMQP is "getting there", seeing what the low level API shapes out as is part
> of the stabalising process.
>
> Top down design / bottom up design -- need both at the same time in my
> experience.
true... my only concern is from the IP point of view... the Qpid
project is, rightly, open to those who have not signed the necessary
IP legal agreements to contribute to AMQP... thus could any work that
is done as Qpid actually be contributed to AMQP? Would it create
problems for those of us who wear both hats?
Others who are better versed in the IP issues than me should probably
comment here!
Cheers,
Rob
>
> On 12/06/07, Robert Greig <ro...@gmail.com> wrote:
> >
> > On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> >
> > > I don't think we should expend too much effort in that direction
> > > purely as Qpid. Further, there will likely be more changes after 0-10
> > > (although hopefully of a smaller magnitude), before we get to AMQP
> > > 1-0.
> > >
> > > I suggest that while we may start thinking about an AMQP API right
> > > now, we do not try to prematurely standardize.
> > >
> > > My suggestion remains that we use (in the Java version at least) an
> > > "AMQP"-style API internally; and that early adopters *may* wish to use
> > > this API but must do so with the knowledge that its is likely to
> > > undergo change which may not have backwards compatability.
> > >
> > > From an interoperability point of view; the other important area we
> > > must cover is to have the other Qpid clients easily able to produce
> > > messages that are understood in JMS. For instance being able to
> > > easily send "text", "stream" or "map" messages. This will need to be
> > > standardized for AMQP - but for the moment at least having
> > > interoperability at this level between the AMQP clients would be nice.
> >
> > Completely agree with all of the above.
> >
> > The discussion of an AMQP API has come up several times in the past
> > and I think given how much the protocol has evolved/is likely to
> > evolve it is still too early to focus on attempting to create some
> > kind of standard API.
> >
> > RG
> >
>
Re: NMS
Posted by Gordon Sim <gs...@redhat.com>.
John O'Hara wrote:
> This is just one of those bullets that we have to bite on.
>
> AMQP is "getting there", seeing what the low level API shapes out as
> is part of the stabalising process.
>
> Top down design / bottom up design -- need both at the same time in
> my experience.
I agree, but I still think its premature to try and standardise the
translation of the AMQP application level protocol into language
specific bindings. For one thing I'm not convinced there is significant
user demand yet for such a standardisation. Any standardisation also
takes time and effort and the AMQP working group should in my opinion
focus on getting the protocol itself to the required state by 1.0.
Within the Qpid project, where there are existing standard APIs that are
applicable we are all agreed that providing implementations that use
AMQP is beneficial. I think we all also agree that we want the various
clients to 'fit' well as part of a larger 'product'.
At least as important for consumer choice as the existence standard APIs
is the availability of high-quality, mature, well documented and easy to
use client libraries and I think we should initially focus on providing
that.
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
This is just one of those bullets that we have to bite on.
AMQP is "getting there", seeing what the low level API shapes out as is part
of the stabalising process.
Top down design / bottom up design -- need both at the same time in my
experience.
On 12/06/07, Robert Greig <ro...@gmail.com> wrote:
>
> On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> > I don't think we should expend too much effort in that direction
> > purely as Qpid. Further, there will likely be more changes after 0-10
> > (although hopefully of a smaller magnitude), before we get to AMQP
> > 1-0.
> >
> > I suggest that while we may start thinking about an AMQP API right
> > now, we do not try to prematurely standardize.
> >
> > My suggestion remains that we use (in the Java version at least) an
> > "AMQP"-style API internally; and that early adopters *may* wish to use
> > this API but must do so with the knowledge that its is likely to
> > undergo change which may not have backwards compatability.
> >
> > From an interoperability point of view; the other important area we
> > must cover is to have the other Qpid clients easily able to produce
> > messages that are understood in JMS. For instance being able to
> > easily send "text", "stream" or "map" messages. This will need to be
> > standardized for AMQP - but for the moment at least having
> > interoperability at this level between the AMQP clients would be nice.
>
> Completely agree with all of the above.
>
> The discussion of an AMQP API has come up several times in the past
> and I think given how much the protocol has evolved/is likely to
> evolve it is still too early to focus on attempting to create some
> kind of standard API.
>
> RG
>
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 12/06/07, Robert Godfrey <ro...@gmail.com> wrote:
> I don't think we should expend too much effort in that direction
> purely as Qpid. Further, there will likely be more changes after 0-10
> (although hopefully of a smaller magnitude), before we get to AMQP
> 1-0.
>
> I suggest that while we may start thinking about an AMQP API right
> now, we do not try to prematurely standardize.
>
> My suggestion remains that we use (in the Java version at least) an
> "AMQP"-style API internally; and that early adopters *may* wish to use
> this API but must do so with the knowledge that its is likely to
> undergo change which may not have backwards compatability.
>
> From an interoperability point of view; the other important area we
> must cover is to have the other Qpid clients easily able to produce
> messages that are understood in JMS. For instance being able to
> easily send "text", "stream" or "map" messages. This will need to be
> standardized for AMQP - but for the moment at least having
> interoperability at this level between the AMQP clients would be nice.
Completely agree with all of the above.
The discussion of an AMQP API has come up several times in the past
and I think given how much the protocol has evolved/is likely to
evolve it is still too early to focus on attempting to create some
kind of standard API.
RG
Re: NMS
Posted by Robert Godfrey <ro...@gmail.com>.
Rupert,
while we in Qpid may wish to start having ideas on an API... the AMQP
group has indicated it as a goal to have such an API deifned by AMQP.
I don't think we should expend too much effort in that direction
purely as Qpid. Further, there will likely be more changes after 0-10
(although hopefully of a smaller magnitude), before we get to AMQP
1-0.
I suggest that while we may start thinking about an AMQP API right
now, we do not try to prematurely standardize.
My suggestion remains that we use (in the Java version at least) an
"AMQP"-style API internally; and that early adopters *may* wish to use
this API but must do so with the knowledge that its is likely to
undergo change which may not have backwards compatability.
>From an interoperability point of view; the other important area we
must cover is to have the other Qpid clients easily able to produce
messages that are understood in JMS. For instance being able to
easily send "text", "stream" or "map" messages. This will need to be
standardized for AMQP - but for the moment at least having
interoperability at this level between the AMQP clients would be nice.
-- Rob
On 12/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> John,
>
> If this is to be the agreed way forward, I think it makes sense to start
> defining that API as soon as possible. Rather than begining coding for the
> 0.10 spec in an ad-hoc way; I think it is worth investing a little bit of
> time in deciding up-front the shape of that API prior to coding.
>
> Personally, I'm +1 for this idea.
>
> Rupert
>
> On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
> >
> > >
> > > I'm going to bet that your average development shop is willing to
> > > sacrifice a little bit of performance of feature access in order to
> > > gain the ability to choose between messaging vendors. APIs are what
> > > usually lock in an application to a specific vendor. If the
> > > application uses an abstract API, vendor lock in can potentially be
> > > avoided.
> > >
> >
> > 100% true. Which is why most applications have their own shim layer too
> > :-)
> > In some ways, WCF and BizTalk are Microsoft's shims.
> >
> > Perhaps we're at concensus here:
> >
> > 1) Do non-Java API's for Qpid that is not constrained by the JMS
> > legacy. In
> > all liklihood, the same shape of API will be available for Java too, just
> > for completeness, in addition to JMS support.
> >
> > 2) Build a WCF driver for Qpid, atop 1)
> >
> > 3) Those who are interested can map NMS to 1) also.
> >
> > Now we just need to decide the shape of that lower level API.
> > There is a lot of talk in the AMQP camp about doing a standard shape API.
> > We already have some candidates in the wild from iMatix, Apache, and
> > Rabbit,
> > and there have been side discussions about having a beauty contest or
> > doing
> > pick'n'mix.
> >
> > The API needs to look good and feel right. I get terrified when I think
> > of
> > the last thing that tried to standardise an API shape across languages --
> > DOM. I'm sure we can have something nicer looking than that ;-)
> >
> > Comments?
> > John
> >
>
Re: NMS
Posted by Arnaud Simon <as...@redhat.com>.
> 100% true. Which is why most applications have their own shim layer too :-)
> In some ways, WCF and BizTalk are Microsoft's shims.
>
> Perhaps we're at concensus here:
>
> 1) Do non-Java API's for Qpid that is not constrained by the JMS legacy. In
> all liklihood, the same shape of API will be available for Java too, just
> for completeness, in addition to JMS support.
>
> 2) Build a WCF driver for Qpid, atop 1)
>
> 3) Those who are interested can map NMS to 1) also.
+1
> Now we just need to decide the shape of that lower level API.
> There is a lot of talk in the AMQP camp about doing a standard shape API.
> We already have some candidates in the wild from iMatix, Apache, and Rabbit,
> and there have been side discussions about having a beauty contest or doing
> pick'n'mix.
For now I would suggest that we use a simple AMQP protocol mapping. It
will simplify supporting new protocol versions and the standard AMQP API
when/if it comes to life. Note that I am only speaking about the .Net
client, the java case is slightly different.
Arnaud
Re: NMS
Posted by Gordon Sim <gs...@redhat.com>.
John O'Hara wrote:
> Now we just need to decide the shape of that lower level API. There
> is a lot of talk in the AMQP camp about doing a standard shape API.
> We already have some candidates in the wild from iMatix, Apache, and
> Rabbit, and there have been side discussions about having a beauty
> contest or doing pick'n'mix.
>
> The API needs to look good and feel right. I get terrified when I
> think of the last thing that tried to standardise an API shape across
> languages -- DOM. I'm sure we can have something nicer looking than
> that ;-)
>
> Comments?
I think there are two issues here:
(1) standardising an API for a particular language to allow applications
written to that API to easily move from one client implementation to
another, and
(2) aiming for 'consistency' across APIs in different languages
The first only makes sense in connection with other implementors, and is
in my view premature.
The second is something we can do within the qpid project. As has been
mentioned before, a degree of consistency would come automatically from
a direct translation of the AMQP 'methods' into native methods in each
language (differences will emerge even at that point based on support
for optional arguments and default values). The message abstractions are
an other area to consider as well as the handling of incoming commands
and messages.
I think implementing 0-10 will be a useful context to address some of
these. For one thing I think it will more cleanly demarcate between
'methods' of relevance to the application from those more important to
the lower levels of the implementation.
It is worth stressing also, as Robert Greig has pointed out, that the
more directly the API follows the protocol, the more likely it is to
change with successive versions of the protocol. A good example there is
the transition from 0-8 to 0-9: the change from 'basic' to 'message'
had a bigger impact on code written against the direct python API than
code written against the c++ API.
Let me be very clear that I am *not* in anyway suggesting that this
implies a directly generated API is a bad thing; I am a huge fan of the
python client and want to make the c++ client more consistent with it.
I'm just pointing out that at this stage of the protocols evolution
changes to such APIs are to be expected. Where we want to avoid that
causing problems we could consider providing higher level 'building blocks'.
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
John,
If this is to be the agreed way forward, I think it makes sense to start
defining that API as soon as possible. Rather than begining coding for the
0.10 spec in an ad-hoc way; I think it is worth investing a little bit of
time in deciding up-front the shape of that API prior to coding.
Personally, I'm +1 for this idea.
Rupert
On 12/06/07, John O'Hara <jo...@gmail.com> wrote:
>
> >
> > I'm going to bet that your average development shop is willing to
> > sacrifice a little bit of performance of feature access in order to
> > gain the ability to choose between messaging vendors. APIs are what
> > usually lock in an application to a specific vendor. If the
> > application uses an abstract API, vendor lock in can potentially be
> > avoided.
> >
>
> 100% true. Which is why most applications have their own shim layer too
> :-)
> In some ways, WCF and BizTalk are Microsoft's shims.
>
> Perhaps we're at concensus here:
>
> 1) Do non-Java API's for Qpid that is not constrained by the JMS
> legacy. In
> all liklihood, the same shape of API will be available for Java too, just
> for completeness, in addition to JMS support.
>
> 2) Build a WCF driver for Qpid, atop 1)
>
> 3) Those who are interested can map NMS to 1) also.
>
> Now we just need to decide the shape of that lower level API.
> There is a lot of talk in the AMQP camp about doing a standard shape API.
> We already have some candidates in the wild from iMatix, Apache, and
> Rabbit,
> and there have been side discussions about having a beauty contest or
> doing
> pick'n'mix.
>
> The API needs to look good and feel right. I get terrified when I think
> of
> the last thing that tried to standardise an API shape across languages --
> DOM. I'm sure we can have something nicer looking than that ;-)
>
> Comments?
> John
>
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
>
> I'm going to bet that your average development shop is willing to
> sacrifice a little bit of performance of feature access in order to
> gain the ability to choose between messaging vendors. APIs are what
> usually lock in an application to a specific vendor. If the
> application uses an abstract API, vendor lock in can potentially be
> avoided.
>
100% true. Which is why most applications have their own shim layer too :-)
In some ways, WCF and BizTalk are Microsoft's shims.
Perhaps we're at concensus here:
1) Do non-Java API's for Qpid that is not constrained by the JMS legacy. In
all liklihood, the same shape of API will be available for Java too, just
for completeness, in addition to JMS support.
2) Build a WCF driver for Qpid, atop 1)
3) Those who are interested can map NMS to 1) also.
Now we just need to decide the shape of that lower level API.
There is a lot of talk in the AMQP camp about doing a standard shape API.
We already have some candidates in the wild from iMatix, Apache, and Rabbit,
and there have been side discussions about having a beauty contest or doing
pick'n'mix.
The API needs to look good and feel right. I get terrified when I think of
the last thing that tried to standardise an API shape across languages --
DOM. I'm sure we can have something nicer looking than that ;-)
Comments?
John
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I agree qpid should have a API that exposes all the features of the
AMQP protocol since AMQP is the focus of the project.
But the point of NMS and CMS is not to have an API that you can access
ALL the features of the messaging provider. The idea is to have an
abstract API that can semantically be easily implemented by most
messaging providers. And why would you want to limit yourself to an
API that has a reduced set of features? So that application can have
a choice when it chooses the vendor for the implementation of the API.
We have seen that technologies like ODBC, JDBC, and JMS made it easier
for folks to stay vendor neutral. NMS and CMS is just trying bring
the same kind of abstraction for messaging on the .NET and C++ worlds.
I'm going to bet that your average development shop is willing to
sacrifice a little bit of performance of feature access in order to
gain the ability to choose between messaging vendors. APIs are what
usually lock in an application to a specific vendor. If the
application uses an abstract API, vendor lock in can potentially be
avoided.
So, while QPID should have a high performance low level API, I think
also supporting a more abstract messaging model like NMS and CMS would
be a big plus for your end users.
On 6/11/07, Colin Crist <co...@hermesjms.com> wrote:
>
> As an observer here and user of messaging stuff, all I can say is please
> don't force other languages to have to live with a JMS API varient. I agree
> its very limited and is a success as it's a common demoninator that was
> standardised - the standardisation is really it best asset, not the API per
> se.
>
> I've always thought an AMQP API that maps accurately to the protocol and is
> mostly familiar across languages (in the core abstractions that map to the
> protocol, constants and so on) but uses those languages constructs
> effectively is the way to go.
>
> AMQP != JMS so why go there? ActiveMQ is the Apache JMS implementation is it
> not after all?Build a compliant JMS on the side in Java. Only Java.
> Prefereably layered on top of a more appropriate AMQP API. Then you can
> forget about lawyers. Sighs of relief all round surely?
>
> Hope you don't mind my $0.02 from the the leftfield.
>
> Colin.
>
>
> > -----Original Message-----
> > From: John O'Hara [mailto:john.r.ohara@gmail.com]
> > Sent: 11 June 2007 17:13
> > To: qpid-dev@incubator.apache.org
> > Subject: Re: NMS
> >
> > With JMS/NMS it's more likely to do with Copyright.
> > The question is "Is NMS derived from JMS", not about other
> > aspects of IP, but we need a lawyers comment.
> >
> > If the API looked substantially different from JMS there
> > probably wouldn't be an issue.
> >
> > Since JMS is not the greatest messaging API in the world,
> > imho, why do other languages have to suffer from it?
> > Not everyone using these other languages has seen JMS.
> >
> > Given AMQP (above rant aside) was engineered to be cross
> > platform/language - why not start with a fairly thin AMQP-centric API?
> > Then on top of it build JMS, WCF, etc...
> >
> > JMS by no means the only shape for a messaging API.
> >
> > Just my 2c
> > John
> >
> >
> >
> >
> >
> >
> > On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > >
> > > I share the same sentiment. The 'tainting' assumptions
> > that are being
> > > made around the JMS spec need to get resolved ASAP for the sake of
> > > both the projects.
> > >
> > > On 6/11/07, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > > > You can not seriously tell me that because you've read
> > the JMS spec
> > > > you
> > > may
> > > > not write a spec for a messaging protocol, without breaking the
> > > > rules of
> > > the
> > > > JMS spec. This discussion is bordering on the ridiculous.
> > > >
> > > > On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> > > > >
> > > > > On 6/11/07, John O'Hara < john.r.ohara@gmail.com> wrote:
> > > > > > "..please consider that the same folks who developed
> > NMS helped
> > > develop
> > > > > the
> > > > > > AMQP specification so the same alleged 'taint' that is being
> > > > > > claimed
> > >
> > > > > against
> > > > > > NMS would also apply to AMQP."
> > > > > >
> > > > > > To clarify.
> > > > > > James is not the source of any of the content of the AMQP
> > > specification
> > > > > thru
> > > > > > v0-9, to the best of my knowledge.
> > > > >
> > > > > So I've just been through my AMQP spec emails; The
> > first version I
> > > > > was sent was 0.3a4 in August 2004 then I contributed to the
> > > > > specification up to around April 2005 when it had
> > reached around 0.81a.
> > > > >
> > > > > So what happened to the specification I worked on? Was
> > a new group
> > > > > formed excluding all the folks who were on the mailing
> > list I was
> > > > > on (including yourself John you were on the mailing
> > list with me)
> > > > > and were all versions of AMQP destroyed and a new cleanroom
> > > > > version created after 0.81a, ignoring all that previous work?
> > > > >
> > > > > --
> > > > > James
> > > > > -------
> > > > > http://macstrac.blogspot.com/
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I agree qpid should have a API that exposes all the features of the
AMQP protocol since AMQP is the focus of the project.
But the point of NMS and CMS is not to have an API that you can access
ALL the features of the messaging provider. The idea is to have an
abstract API that can semantically be easily implemented by most
messaging providers. And why would you want to limit yourself to an
API that has a reduced set of features? So that application can have
a choice when it chooses the vendor for the implementation of the API.
We have seen that technologies like ODBC, JDBC, and JMS made it easier
for folks to stay vendor neutral. NMS and CMS is just trying bring
the same kind of abstraction for messaging on the .NET and C++ worlds.
I'm going to bet that your average development shop is willing to
sacrifice a little bit of performance of feature access in order to
gain the ability to choose between messaging vendors. APIs are what
usually lock in an application to a specific vendor. If the
application uses an abstract API, vendor lock in can potentially be
avoided.
So, while QPID should have a high performance low level API, I think
also supporting a more abstract messaging model like NMS and CMS would
be a big plus for your end users.
On 6/11/07, Colin Crist <co...@hermesjms.com> wrote:
>
> As an observer here and user of messaging stuff, all I can say is please
> don't force other languages to have to live with a JMS API varient. I agree
> its very limited and is a success as it's a common demoninator that was
> standardised - the standardisation is really it best asset, not the API per
> se.
>
> I've always thought an AMQP API that maps accurately to the protocol and is
> mostly familiar across languages (in the core abstractions that map to the
> protocol, constants and so on) but uses those languages constructs
> effectively is the way to go.
>
> AMQP != JMS so why go there? ActiveMQ is the Apache JMS implementation is it
> not after all?Build a compliant JMS on the side in Java. Only Java.
> Prefereably layered on top of a more appropriate AMQP API. Then you can
> forget about lawyers. Sighs of relief all round surely?
>
> Hope you don't mind my $0.02 from the the leftfield.
>
> Colin.
>
>
> > -----Original Message-----
> > From: John O'Hara [mailto:john.r.ohara@gmail.com]
> > Sent: 11 June 2007 17:13
> > To: qpid-dev@incubator.apache.org
> > Subject: Re: NMS
> >
> > With JMS/NMS it's more likely to do with Copyright.
> > The question is "Is NMS derived from JMS", not about other
> > aspects of IP, but we need a lawyers comment.
> >
> > If the API looked substantially different from JMS there
> > probably wouldn't be an issue.
> >
> > Since JMS is not the greatest messaging API in the world,
> > imho, why do other languages have to suffer from it?
> > Not everyone using these other languages has seen JMS.
> >
> > Given AMQP (above rant aside) was engineered to be cross
> > platform/language - why not start with a fairly thin AMQP-centric API?
> > Then on top of it build JMS, WCF, etc...
> >
> > JMS by no means the only shape for a messaging API.
> >
> > Just my 2c
> > John
> >
> >
> >
> >
> >
> >
> > On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > >
> > > I share the same sentiment. The 'tainting' assumptions
> > that are being
> > > made around the JMS spec need to get resolved ASAP for the sake of
> > > both the projects.
> > >
> > > On 6/11/07, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > > > You can not seriously tell me that because you've read
> > the JMS spec
> > > > you
> > > may
> > > > not write a spec for a messaging protocol, without breaking the
> > > > rules of
> > > the
> > > > JMS spec. This discussion is bordering on the ridiculous.
> > > >
> > > > On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> > > > >
> > > > > On 6/11/07, John O'Hara < john.r.ohara@gmail.com> wrote:
> > > > > > "..please consider that the same folks who developed
> > NMS helped
> > > develop
> > > > > the
> > > > > > AMQP specification so the same alleged 'taint' that is being
> > > > > > claimed
> > >
> > > > > against
> > > > > > NMS would also apply to AMQP."
> > > > > >
> > > > > > To clarify.
> > > > > > James is not the source of any of the content of the AMQP
> > > specification
> > > > > thru
> > > > > > v0-9, to the best of my knowledge.
> > > > >
> > > > > So I've just been through my AMQP spec emails; The
> > first version I
> > > > > was sent was 0.3a4 in August 2004 then I contributed to the
> > > > > specification up to around April 2005 when it had
> > reached around 0.81a.
> > > > >
> > > > > So what happened to the specification I worked on? Was
> > a new group
> > > > > formed excluding all the folks who were on the mailing
> > list I was
> > > > > on (including yourself John you were on the mailing
> > list with me)
> > > > > and were all versions of AMQP destroyed and a new cleanroom
> > > > > version created after 0.81a, ignoring all that previous work?
> > > > >
> > > > > --
> > > > > James
> > > > > -------
> > > > > http://macstrac.blogspot.com/
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
RE: NMS
Posted by Colin Crist <co...@hermesjms.com>.
As an observer here and user of messaging stuff, all I can say is please
don't force other languages to have to live with a JMS API varient. I agree
its very limited and is a success as it's a common demoninator that was
standardised - the standardisation is really it best asset, not the API per
se.
I've always thought an AMQP API that maps accurately to the protocol and is
mostly familiar across languages (in the core abstractions that map to the
protocol, constants and so on) but uses those languages constructs
effectively is the way to go.
AMQP != JMS so why go there? ActiveMQ is the Apache JMS implementation is it
not after all?Build a compliant JMS on the side in Java. Only Java.
Prefereably layered on top of a more appropriate AMQP API. Then you can
forget about lawyers. Sighs of relief all round surely?
Hope you don't mind my $0.02 from the the leftfield.
Colin.
> -----Original Message-----
> From: John O'Hara [mailto:john.r.ohara@gmail.com]
> Sent: 11 June 2007 17:13
> To: qpid-dev@incubator.apache.org
> Subject: Re: NMS
>
> With JMS/NMS it's more likely to do with Copyright.
> The question is "Is NMS derived from JMS", not about other
> aspects of IP, but we need a lawyers comment.
>
> If the API looked substantially different from JMS there
> probably wouldn't be an issue.
>
> Since JMS is not the greatest messaging API in the world,
> imho, why do other languages have to suffer from it?
> Not everyone using these other languages has seen JMS.
>
> Given AMQP (above rant aside) was engineered to be cross
> platform/language - why not start with a fairly thin AMQP-centric API?
> Then on top of it build JMS, WCF, etc...
>
> JMS by no means the only shape for a messaging API.
>
> Just my 2c
> John
>
>
>
>
>
>
> On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >
> > I share the same sentiment. The 'tainting' assumptions
> that are being
> > made around the JMS spec need to get resolved ASAP for the sake of
> > both the projects.
> >
> > On 6/11/07, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > > You can not seriously tell me that because you've read
> the JMS spec
> > > you
> > may
> > > not write a spec for a messaging protocol, without breaking the
> > > rules of
> > the
> > > JMS spec. This discussion is bordering on the ridiculous.
> > >
> > > On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> > > >
> > > > On 6/11/07, John O'Hara < john.r.ohara@gmail.com> wrote:
> > > > > "..please consider that the same folks who developed
> NMS helped
> > develop
> > > > the
> > > > > AMQP specification so the same alleged 'taint' that is being
> > > > > claimed
> >
> > > > against
> > > > > NMS would also apply to AMQP."
> > > > >
> > > > > To clarify.
> > > > > James is not the source of any of the content of the AMQP
> > specification
> > > > thru
> > > > > v0-9, to the best of my knowledge.
> > > >
> > > > So I've just been through my AMQP spec emails; The
> first version I
> > > > was sent was 0.3a4 in August 2004 then I contributed to the
> > > > specification up to around April 2005 when it had
> reached around 0.81a.
> > > >
> > > > So what happened to the specification I worked on? Was
> a new group
> > > > formed excluding all the folks who were on the mailing
> list I was
> > > > on (including yourself John you were on the mailing
> list with me)
> > > > and were all versions of AMQP destroyed and a new cleanroom
> > > > version created after 0.81a, ignoring all that previous work?
> > > >
> > > > --
> > > > James
> > > > -------
> > > > http://macstrac.blogspot.com/
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
With JMS/NMS it's more likely to do with Copyright.
The question is "Is NMS derived from JMS", not about other aspects of IP,
but we need a lawyers comment.
If the API looked substantially different from JMS there probably wouldn't
be an issue.
Since JMS is not the greatest messaging API in the world, imho, why do other
languages have to suffer from it?
Not everyone using these other languages has seen JMS.
Given AMQP (above rant aside) was engineered to be cross platform/language -
why not start with a fairly thin AMQP-centric API?
Then on top of it build JMS, WCF, etc...
JMS by no means the only shape for a messaging API.
Just my 2c
John
On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> I share the same sentiment. The 'tainting' assumptions that are being
> made around the JMS spec need to get resolved ASAP for the sake of
> both the projects.
>
> On 6/11/07, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > You can not seriously tell me that because you've read the JMS spec you
> may
> > not write a spec for a messaging protocol, without breaking the rules of
> the
> > JMS spec. This discussion is bordering on the ridiculous.
> >
> > On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> > >
> > > On 6/11/07, John O'Hara < john.r.ohara@gmail.com> wrote:
> > > > "..please consider that the same folks who developed NMS helped
> develop
> > > the
> > > > AMQP specification so the same alleged 'taint' that is being claimed
>
> > > against
> > > > NMS would also apply to AMQP."
> > > >
> > > > To clarify.
> > > > James is not the source of any of the content of the AMQP
> specification
> > > thru
> > > > v0-9, to the best of my knowledge.
> > >
> > > So I've just been through my AMQP spec emails; The first version I was
> > > sent was 0.3a4 in August 2004 then I contributed to the specification
> > > up to around April 2005 when it had reached around 0.81a.
> > >
> > > So what happened to the specification I worked on? Was a new group
> > > formed excluding all the folks who were on the mailing list I was on
> > > (including yourself John you were on the mailing list with me) and
> > > were all versions of AMQP destroyed and a new cleanroom version
> > > created after 0.81a, ignoring all that previous work?
> > >
> > > --
> > > James
> > > -------
> > > http://macstrac.blogspot.com/
> > >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I share the same sentiment. The 'tainting' assumptions that are being
made around the JMS spec need to get resolved ASAP for the sake of
both the projects.
On 6/11/07, Rupert Smith <ru...@googlemail.com> wrote:
> You can not seriously tell me that because you've read the JMS spec you may
> not write a spec for a messaging protocol, without breaking the rules of the
> JMS spec. This discussion is bordering on the ridiculous.
>
> On 11/06/07, James Strachan <ja...@gmail.com> wrote:
> >
> > On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> > > "..please consider that the same folks who developed NMS helped develop
> > the
> > > AMQP specification so the same alleged 'taint' that is being claimed
> > against
> > > NMS would also apply to AMQP."
> > >
> > > To clarify.
> > > James is not the source of any of the content of the AMQP specification
> > thru
> > > v0-9, to the best of my knowledge.
> >
> > So I've just been through my AMQP spec emails; The first version I was
> > sent was 0.3a4 in August 2004 then I contributed to the specification
> > up to around April 2005 when it had reached around 0.81a.
> >
> > So what happened to the specification I worked on? Was a new group
> > formed excluding all the folks who were on the mailing list I was on
> > (including yourself John you were on the mailing list with me) and
> > were all versions of AMQP destroyed and a new cleanroom version
> > created after 0.81a, ignoring all that previous work?
> >
> > --
> > James
> > -------
> > http://macstrac.blogspot.com/
> >
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
You can not seriously tell me that because you've read the JMS spec you may
not write a spec for a messaging protocol, without breaking the rules of the
JMS spec. This discussion is bordering on the ridiculous.
On 11/06/07, James Strachan <ja...@gmail.com> wrote:
>
> On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> > "..please consider that the same folks who developed NMS helped develop
> the
> > AMQP specification so the same alleged 'taint' that is being claimed
> against
> > NMS would also apply to AMQP."
> >
> > To clarify.
> > James is not the source of any of the content of the AMQP specification
> thru
> > v0-9, to the best of my knowledge.
>
> So I've just been through my AMQP spec emails; The first version I was
> sent was 0.3a4 in August 2004 then I contributed to the specification
> up to around April 2005 when it had reached around 0.81a.
>
> So what happened to the specification I worked on? Was a new group
> formed excluding all the folks who were on the mailing list I was on
> (including yourself John you were on the mailing list with me) and
> were all versions of AMQP destroyed and a new cleanroom version
> created after 0.81a, ignoring all that previous work?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> "..please consider that the same folks who developed NMS helped develop the
> AMQP specification so the same alleged 'taint' that is being claimed against
> NMS would also apply to AMQP."
>
> To clarify.
> James is not the source of any of the content of the AMQP specification thru
> v0-9, to the best of my knowledge.
So I've just been through my AMQP spec emails; The first version I was
sent was 0.3a4 in August 2004 then I contributed to the specification
up to around April 2005 when it had reached around 0.81a.
So what happened to the specification I worked on? Was a new group
formed excluding all the folks who were on the mailing list I was on
(including yourself John you were on the mailing list with me) and
were all versions of AMQP destroyed and a new cleanroom version
created after 0.81a, ignoring all that previous work?
--
James
-------
http://macstrac.blogspot.com/
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/11/07, John O'Hara <jo...@gmail.com> wrote:
> "..please consider that the same folks who developed NMS helped develop the
> AMQP specification so the same alleged 'taint' that is being claimed against
> NMS would also apply to AMQP."
>
> To clarify.
> James is not the source of any of the content of the AMQP specification thru
> v0-9, to the best of my knowledge.
So I've just been through my AMQP spec emails; The first version I was
sent was 0.3a4 in August 2004 then I contributed to the specification
up to around April 2005 when it had reached around 0.81a.
So what happened to the specification I worked on? Was a new group
formed excluding all the folks who were on the mailing list I was on
(including yourself John you were on the mailing list with me) and
were all versions of AMQP destroyed and a new cleanroom version
created after 0.81a, ignoring all that previous work?
--
James
-------
http://macstrac.blogspot.com/
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
"..please consider that the same folks who developed NMS helped develop the
AMQP specification so the same alleged 'taint' that is being claimed against
NMS would also apply to AMQP."
To clarify.
James is not the source of any of the content of the AMQP specification thru
v0-9, to the best of my knowledge.
Regards
John
On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> Hi,
>
> On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> > According to the discussion we have had on the ActiveMQ mailing list, it
> > looks as if it is impossible to make a decision on whether implementing
> > NMS is legal or not.
> >
> > Even the ActiveMQ guys cannot agree.
>
> All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> Please stop the FUD.
> If you guys want FUD, please consider that the same folks who
> developed NMS helped develop the AMQP specification so the same
> alleged 'taint' that is being claimed against NMS would also apply to
> AMQP.
>
> > As a potential Qpid implementation
> > of NMS would be hosted by their project they should decide whether this
> > is useful to have one and also take responsibility for potential legal
> > aspects.
> >
> > Arnaud
> >
> >
> > On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > > Take a look at this - it might amuse you
> > >
> > > http://smallprint.netzoo.net/reag/
> > >
> > > Paul
> > >
> > > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > > Great! My infallable plan for world domination:
> > > >
> > > > "By opening this email, you agree that you have read, understood,
> and will
> > > > comply with all of the terms
> > > > and conditions set forth herein"
> > > >
> > > > You will, pass this on to everyone you know.
> > > > Agree to everything I say from now on.
> > > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
Re: NMS
Posted by Martin Ritchie <ri...@apache.org>.
On 11/06/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
> While I know that its possible to argue that there is commonality
> amongst messaging systems, I think the following list of core
> interfaces might just seem a teeny tiny bit similar.
>
> JMS NMS
> BytesMessage IBytesMessage
> Connection IConnection
> ConnectionFactory IConnectionFactory
> Destination IDestination
> MapMessage IMapMessage
> Message IMessage
> MessageConsumer IMessageConsumer
> MessageProducer IMessageProducer
> Queue IQueue
> Session ISession
> TextMessage ITextMessage
> Topic ITopic
>
> Paul
> On 6/11/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi,
> >
> > On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> > > According to the discussion we have had on the ActiveMQ mailing list, it
> > > looks as if it is impossible to make a decision on whether implementing
> > > NMS is legal or not.
> > >
> > > Even the ActiveMQ guys cannot agree.
> >
> > All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> > Please stop the FUD.
> > If you guys want FUD, please consider that the same folks who
> > developed NMS helped develop the AMQP specification so the same
> > alleged 'taint' that is being claimed against NMS would also apply to
> > AMQP.
> >
> > > As a potential Qpid implementation
> > > of NMS would be hosted by their project they should decide whether this
> > > is useful to have one and also take responsibility for potential legal
> > > aspects.
> > >
> > > Arnaud
> > >
> > >
> > > On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > > > Take a look at this - it might amuse you
> > > >
> > > > http://smallprint.netzoo.net/reag/
> > > >
> > > > Paul
> > > >
> > > > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > > > Great! My infallable plan for world domination:
> > > > >
> > > > > "By opening this email, you agree that you have read, understood, and will
> > > > > comply with all of the terms
> > > > > and conditions set forth herein"
> > > > >
> > > > > You will, pass this on to everyone you know.
> > > > > Agree to everything I say from now on.
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
As I understand it Cliff has done a lot of work for Apache on
licensing. Cliff can you provide some legal insight?
Cheers
--
Martin Ritchie
Re: NMS
Posted by Martin Ritchie <ri...@apache.org>.
On 11/06/07, Paul Fremantle <pz...@gmail.com> wrote:
> Hiram
>
> While I know that its possible to argue that there is commonality
> amongst messaging systems, I think the following list of core
> interfaces might just seem a teeny tiny bit similar.
>
> JMS NMS
> BytesMessage IBytesMessage
> Connection IConnection
> ConnectionFactory IConnectionFactory
> Destination IDestination
> MapMessage IMapMessage
> Message IMessage
> MessageConsumer IMessageConsumer
> MessageProducer IMessageProducer
> Queue IQueue
> Session ISession
> TextMessage ITextMessage
> Topic ITopic
>
> Paul
> On 6/11/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi,
> >
> > On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> > > According to the discussion we have had on the ActiveMQ mailing list, it
> > > looks as if it is impossible to make a decision on whether implementing
> > > NMS is legal or not.
> > >
> > > Even the ActiveMQ guys cannot agree.
> >
> > All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> > Please stop the FUD.
> > If you guys want FUD, please consider that the same folks who
> > developed NMS helped develop the AMQP specification so the same
> > alleged 'taint' that is being claimed against NMS would also apply to
> > AMQP.
> >
> > > As a potential Qpid implementation
> > > of NMS would be hosted by their project they should decide whether this
> > > is useful to have one and also take responsibility for potential legal
> > > aspects.
> > >
> > > Arnaud
> > >
> > >
> > > On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > > > Take a look at this - it might amuse you
> > > >
> > > > http://smallprint.netzoo.net/reag/
> > > >
> > > > Paul
> > > >
> > > > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > > > Great! My infallable plan for world domination:
> > > > >
> > > > > "By opening this email, you agree that you have read, understood, and will
> > > > > comply with all of the terms
> > > > > and conditions set forth herein"
> > > > >
> > > > > You will, pass this on to everyone you know.
> > > > > Agree to everything I say from now on.
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
As I understand it Cliff has done a lot of work for Apache on
licensing. Cliff can you provide some legal insight?
Cheers
--
Martin Ritchie
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
While I know that its possible to argue that there is commonality
amongst messaging systems, I think the following list of core
interfaces might just seem a teeny tiny bit similar.
JMS NMS
BytesMessage IBytesMessage
Connection IConnection
ConnectionFactory IConnectionFactory
Destination IDestination
MapMessage IMapMessage
Message IMessage
MessageConsumer IMessageConsumer
MessageProducer IMessageProducer
Queue IQueue
Session ISession
TextMessage ITextMessage
Topic ITopic
Paul
On 6/11/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi,
>
> On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> > According to the discussion we have had on the ActiveMQ mailing list, it
> > looks as if it is impossible to make a decision on whether implementing
> > NMS is legal or not.
> >
> > Even the ActiveMQ guys cannot agree.
>
> All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> Please stop the FUD.
> If you guys want FUD, please consider that the same folks who
> developed NMS helped develop the AMQP specification so the same
> alleged 'taint' that is being claimed against NMS would also apply to
> AMQP.
>
> > As a potential Qpid implementation
> > of NMS would be hosted by their project they should decide whether this
> > is useful to have one and also take responsibility for potential legal
> > aspects.
> >
> > Arnaud
> >
> >
> > On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > > Take a look at this - it might amuse you
> > >
> > > http://smallprint.netzoo.net/reag/
> > >
> > > Paul
> > >
> > > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > > Great! My infallable plan for world domination:
> > > >
> > > > "By opening this email, you agree that you have read, understood, and will
> > > > comply with all of the terms
> > > > and conditions set forth herein"
> > > >
> > > > You will, pass this on to everyone you know.
> > > > Agree to everything I say from now on.
> > > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 11/06/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> Please stop the FUD.
With the greatest respect, we are really looking for expert legal
opinion on this matter. Have you taken legal advice on this?
Robert
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Hiram
While I know that its possible to argue that there is commonality
amongst messaging systems, I think the following list of core
interfaces might just seem a teeny tiny bit similar.
JMS NMS
BytesMessage IBytesMessage
Connection IConnection
ConnectionFactory IConnectionFactory
Destination IDestination
MapMessage IMapMessage
Message IMessage
MessageConsumer IMessageConsumer
MessageProducer IMessageProducer
Queue IQueue
Session ISession
TextMessage ITextMessage
Topic ITopic
Paul
On 6/11/07, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi,
>
> On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> > According to the discussion we have had on the ActiveMQ mailing list, it
> > looks as if it is impossible to make a decision on whether implementing
> > NMS is legal or not.
> >
> > Even the ActiveMQ guys cannot agree.
>
> All the ActiveMQ guys seem to be of the opinion that NMS is legal.
> Please stop the FUD.
> If you guys want FUD, please consider that the same folks who
> developed NMS helped develop the AMQP specification so the same
> alleged 'taint' that is being claimed against NMS would also apply to
> AMQP.
>
> > As a potential Qpid implementation
> > of NMS would be hosted by their project they should decide whether this
> > is useful to have one and also take responsibility for potential legal
> > aspects.
> >
> > Arnaud
> >
> >
> > On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > > Take a look at this - it might amuse you
> > >
> > > http://smallprint.netzoo.net/reag/
> > >
> > > Paul
> > >
> > > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > > Great! My infallable plan for world domination:
> > > >
> > > > "By opening this email, you agree that you have read, understood, and will
> > > > comply with all of the terms
> > > > and conditions set forth herein"
> > > >
> > > > You will, pass this on to everyone you know.
> > > > Agree to everything I say from now on.
> > > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi,
On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> According to the discussion we have had on the ActiveMQ mailing list, it
> looks as if it is impossible to make a decision on whether implementing
> NMS is legal or not.
>
> Even the ActiveMQ guys cannot agree.
All the ActiveMQ guys seem to be of the opinion that NMS is legal.
Please stop the FUD.
If you guys want FUD, please consider that the same folks who
developed NMS helped develop the AMQP specification so the same
alleged 'taint' that is being claimed against NMS would also apply to
AMQP.
> As a potential Qpid implementation
> of NMS would be hosted by their project they should decide whether this
> is useful to have one and also take responsibility for potential legal
> aspects.
>
> Arnaud
>
>
> On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > Take a look at this - it might amuse you
> >
> > http://smallprint.netzoo.net/reag/
> >
> > Paul
> >
> > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > Great! My infallable plan for world domination:
> > >
> > > "By opening this email, you agree that you have read, understood, and will
> > > comply with all of the terms
> > > and conditions set forth herein"
> > >
> > > You will, pass this on to everyone you know.
> > > Agree to everything I say from now on.
> > >
> >
> >
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: NMS
Posted by Arnaud Simon <as...@redhat.com>.
As I said it s going to be painful to have everybody agreeing on whether
there exist legal doubts about NMS and/or AMQP. Moreover, it is not yet
clear if we want to define a language transparent AMQP API and we are
debating whether JMS should be extended. So, under those circumstances I
would suggest that we postpone a little bit providing a NMS support for
concentrating on a .Net client that is directly targeting WCF and
BizTalk.
Note that I am not saying that we should not support NMS right now only
because of legal issues (I was the one suggesting first that it may be a
good idea to support it). I only feel that supporting a new API may
confuse us more that it would help.
Arnaud
> > I have not read through all the threads on the topic, but if there is
> > legal doubt about it
> > , it would make sense to explore all other alternatives first.
>
> The same legal doubt over NMS (i.e. does reading the JMS API taint you
> from ever writing other non-Java messaging stuff) also applies to AMQP
> itself - it could be tainted too; as at least one contributor to the
> AMQP specification has read the JMS specification (myself). There
> could well be others too.
>
> So I guess both NMS and AMQP need legal clarification on the tainting
> caused by reading the JMS specification.
>
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
James Strachan wrote:
> On 6/11/07, Carl Trieloff <cc...@redhat.com> wrote:
>> Robert Greig wrote:
>> > On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
>> >
>> >> Even the ActiveMQ guys cannot agree. As a potential Qpid
>> implementation
>> >> of NMS would be hosted by their project they should decide whether
>> this
>> >> is useful to have one and also take responsibility for potential
>> legal
>> >> aspects.
>> >
>> > OK but this impacts us in the sense that we would be doing the
>> > implementation?
>> >
>> > Surely we should not be putting effort into something where the legal
>> > position is not clear? What are we supposed to say to our users? "Use
>> > this but we can't decide whether it's violating a licence agreement"?
>> >
>> > RG
>>
>> I have not read through all the threads on the topic, but if there is
>> legal doubt about it
>> , it would make sense to explore all other alternatives first.
>
> The same legal doubt over NMS (i.e. does reading the JMS API taint you
> from ever writing other non-Java messaging stuff) also applies to AMQP
> itself - it could be tainted too; as at least one contributor to the
> AMQP specification has read the JMS specification (myself). There
> could well be others too.
>
> So I guess both NMS and AMQP need legal clarification on the tainting
> caused by reading the JMS specification.
>
James,
I don't think the analogy is at all accurate as AMQP has specified NO
API's to date where as JMS and NMS
are all about API. Every impl of AMQP today has done its own thing on
API to date. Personally I am
not comfortable and the replies from the list have not helped. If the
committers of Qpid want to pursue use
of NMS I will take the time to form my own view on the topic.
Having the Qpid project ask the question is a fine thing to do. For
example in C++, Python, Ruby etc we
have a non JMS mapped API and there are many other approaches to do
.NET, The is question on how we should
continue to develop the .NET client for Qpid which could be done with or
without NMS. nothing wrong in asking the
questions before the project makes the call which way to go with regard
to NMS.
Carl.
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
James Strachan wrote:
> On 6/11/07, Carl Trieloff <cc...@redhat.com> wrote:
>> Robert Greig wrote:
>> > On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
>> >
>> >> Even the ActiveMQ guys cannot agree. As a potential Qpid
>> implementation
>> >> of NMS would be hosted by their project they should decide whether
>> this
>> >> is useful to have one and also take responsibility for potential
>> legal
>> >> aspects.
>> >
>> > OK but this impacts us in the sense that we would be doing the
>> > implementation?
>> >
>> > Surely we should not be putting effort into something where the legal
>> > position is not clear? What are we supposed to say to our users? "Use
>> > this but we can't decide whether it's violating a licence agreement"?
>> >
>> > RG
>>
>> I have not read through all the threads on the topic, but if there is
>> legal doubt about it
>> , it would make sense to explore all other alternatives first.
>
> The same legal doubt over NMS (i.e. does reading the JMS API taint you
> from ever writing other non-Java messaging stuff) also applies to AMQP
> itself - it could be tainted too; as at least one contributor to the
> AMQP specification has read the JMS specification (myself). There
> could well be others too.
>
> So I guess both NMS and AMQP need legal clarification on the tainting
> caused by reading the JMS specification.
>
James,
I don't think the analogy is at all accurate as AMQP has specified NO
API's to date where as JMS and NMS
are all about API. Every impl of AMQP today has done its own thing on
API to date. Personally I am
not comfortable and the replies from the list have not helped. If the
committers of Qpid want to pursue use
of NMS I will take the time to form my own view on the topic.
Having the Qpid project ask the question is a fine thing to do. For
example in C++, Python, Ruby etc we
have a non JMS mapped API and there are many other approaches to do
.NET, The is question on how we should
continue to develop the .NET client for Qpid which could be done with or
without NMS. nothing wrong in asking the
questions before the project makes the call which way to go with regard
to NMS.
Carl.
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/11/07, Carl Trieloff <cc...@redhat.com> wrote:
> Robert Greig wrote:
> > On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
> >
> >> Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
> >> of NMS would be hosted by their project they should decide whether this
> >> is useful to have one and also take responsibility for potential legal
> >> aspects.
> >
> > OK but this impacts us in the sense that we would be doing the
> > implementation?
> >
> > Surely we should not be putting effort into something where the legal
> > position is not clear? What are we supposed to say to our users? "Use
> > this but we can't decide whether it's violating a licence agreement"?
> >
> > RG
>
> I have not read through all the threads on the topic, but if there is
> legal doubt about it
> , it would make sense to explore all other alternatives first.
The same legal doubt over NMS (i.e. does reading the JMS API taint you
from ever writing other non-Java messaging stuff) also applies to AMQP
itself - it could be tainted too; as at least one contributor to the
AMQP specification has read the JMS specification (myself). There
could well be others too.
So I guess both NMS and AMQP need legal clarification on the tainting
caused by reading the JMS specification.
--
James
-------
http://macstrac.blogspot.com/
Re: NMS
Posted by James Strachan <ja...@gmail.com>.
On 6/11/07, Carl Trieloff <cc...@redhat.com> wrote:
> Robert Greig wrote:
> > On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
> >
> >> Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
> >> of NMS would be hosted by their project they should decide whether this
> >> is useful to have one and also take responsibility for potential legal
> >> aspects.
> >
> > OK but this impacts us in the sense that we would be doing the
> > implementation?
> >
> > Surely we should not be putting effort into something where the legal
> > position is not clear? What are we supposed to say to our users? "Use
> > this but we can't decide whether it's violating a licence agreement"?
> >
> > RG
>
> I have not read through all the threads on the topic, but if there is
> legal doubt about it
> , it would make sense to explore all other alternatives first.
The same legal doubt over NMS (i.e. does reading the JMS API taint you
from ever writing other non-Java messaging stuff) also applies to AMQP
itself - it could be tainted too; as at least one contributor to the
AMQP specification has read the JMS specification (myself). There
could well be others too.
So I guess both NMS and AMQP need legal clarification on the tainting
caused by reading the JMS specification.
--
James
-------
http://macstrac.blogspot.com/
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 11/06/07, Carl Trieloff <cc...@redhat.com> wrote:
> Arnaud Simon wrote:
> > There is a legal doubt about NMS and it will subsist. This is why I was
> > suggesting that we leave a potential AMQP support to the NMS people. We
> > should therefore concentrate on straight WCF, BizTalk supports.
>
> Sounds like a reasonable approach.
+1
RG
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
Arnaud Simon wrote:
> There is a legal doubt about NMS and it will subsist. This is why I was
> suggesting that we leave a potential AMQP support to the NMS people. We
> should therefore concentrate on straight WCF, BizTalk supports.
>
>
Sounds like a reasonable approach.
Re: NMS
Posted by Arnaud Simon <as...@redhat.com>.
There is a legal doubt about NMS and it will subsist. This is why I was
suggesting that we leave a potential AMQP support to the NMS people. We
should therefore concentrate on straight WCF, BizTalk supports.
On Mon, 2007-06-11 at 07:59 -0400, Carl Trieloff wrote:
> Robert Greig wrote:
> > On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
> >
> >> Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
> >> of NMS would be hosted by their project they should decide whether this
> >> is useful to have one and also take responsibility for potential legal
> >> aspects.
> >
> > OK but this impacts us in the sense that we would be doing the
> > implementation?
> >
> > Surely we should not be putting effort into something where the legal
> > position is not clear? What are we supposed to say to our users? "Use
> > this but we can't decide whether it's violating a licence agreement"?
> >
> > RG
>
> I have not read through all the threads on the topic, but if there is
> legal doubt about it
> , it would make sense to explore all other alternatives first.
>
> Carl.
>
>
>
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
>
>> Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
>> of NMS would be hosted by their project they should decide whether this
>> is useful to have one and also take responsibility for potential legal
>> aspects.
>
> OK but this impacts us in the sense that we would be doing the
> implementation?
>
> Surely we should not be putting effort into something where the legal
> position is not clear? What are we supposed to say to our users? "Use
> this but we can't decide whether it's violating a licence agreement"?
>
> RG
I have not read through all the threads on the topic, but if there is
legal doubt about it
, it would make sense to explore all other alternatives first.
Carl.
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 11/06/07, Arnaud Simon <as...@redhat.com> wrote:
> Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
> of NMS would be hosted by their project they should decide whether this
> is useful to have one and also take responsibility for potential legal
> aspects.
OK but this impacts us in the sense that we would be doing the implementation?
Surely we should not be putting effort into something where the legal
position is not clear? What are we supposed to say to our users? "Use
this but we can't decide whether it's violating a licence agreement"?
RG
Re: NMS
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi,
On 6/11/07, Arnaud Simon <as...@redhat.com> wrote:
> According to the discussion we have had on the ActiveMQ mailing list, it
> looks as if it is impossible to make a decision on whether implementing
> NMS is legal or not.
>
> Even the ActiveMQ guys cannot agree.
All the ActiveMQ guys seem to be of the opinion that NMS is legal.
Please stop the FUD.
If you guys want FUD, please consider that the same folks who
developed NMS helped develop the AMQP specification so the same
alleged 'taint' that is being claimed against NMS would also apply to
AMQP.
> As a potential Qpid implementation
> of NMS would be hosted by their project they should decide whether this
> is useful to have one and also take responsibility for potential legal
> aspects.
>
> Arnaud
>
>
> On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> > Take a look at this - it might amuse you
> >
> > http://smallprint.netzoo.net/reag/
> >
> > Paul
> >
> > On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > Great! My infallable plan for world domination:
> > >
> > > "By opening this email, you agree that you have read, understood, and will
> > > comply with all of the terms
> > > and conditions set forth herein"
> > >
> > > You will, pass this on to everyone you know.
> > > Agree to everything I say from now on.
> > >
> >
> >
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: NMS
Posted by Arnaud Simon <as...@redhat.com>.
According to the discussion we have had on the ActiveMQ mailing list, it
looks as if it is impossible to make a decision on whether implementing
NMS is legal or not.
Even the ActiveMQ guys cannot agree. As a potential Qpid implementation
of NMS would be hosted by their project they should decide whether this
is useful to have one and also take responsibility for potential legal
aspects.
Arnaud
On Wed, 2007-06-06 at 15:56 +0100, Paul Fremantle wrote:
> Take a look at this - it might amuse you
>
> http://smallprint.netzoo.net/reag/
>
> Paul
>
> On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> > Great! My infallable plan for world domination:
> >
> > "By opening this email, you agree that you have read, understood, and will
> > comply with all of the terms
> > and conditions set forth herein"
> >
> > You will, pass this on to everyone you know.
> > Agree to everything I say from now on.
> >
>
>
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Take a look at this - it might amuse you
http://smallprint.netzoo.net/reag/
Paul
On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> Great! My infallable plan for world domination:
>
> "By opening this email, you agree that you have read, understood, and will
> comply with all of the terms
> and conditions set forth herein"
>
> You will, pass this on to everyone you know.
> Agree to everything I say from now on.
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
Great! My infallable plan for world domination:
"By opening this email, you agree that you have read, understood, and will
comply with all of the terms
and conditions set forth herein"
You will, pass this on to everyone you know.
Agree to everything I say from now on.
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Unfortunately the people who wrote NMS did look at the spec.
The only way to do this that doesn't break IP copyright rules is very
complex and expensive. It usually involves a team who have had no
exposure to any of the IP in question, either directly or indirectly,
plus some IP lawyers on $000s a day and a team of reviewers who have
experience of the IP and can provide carefully filtered feedback via
the lawyers.
I don't imaging qpid wants to go through that process.
Paul
On 6/6/07, Rupert Smith <ru...@googlemail.com> wrote:
> Well I'm ok then, I don't think I've ever looked at the spec!
>
> On 06/06/07, Robert Greig <ro...@gmail.com> wrote:
> >
> > On 06/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> > > This sounds likely to me. I think you can break Sun's rules if you are
> > not a
> > > licensee, after all you were never a party to the agreement in the first
> > > place. If IBM are a licensee and they have rewritten JMS as XMS in C++
> > they
> > > must have an exception.
> >
> > Unfortunately unless you try to claim you have never read or
> > downloaded the JMS spec, you have agreed to its terms and conditions:
> >
> > "By viewing, downloading or otherwise copying the Specification, you agree
> > that you have read, understood, and will comply with all of the terms
> > and conditions set forth herein"
> >
> > RG
> >
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
Well I'm ok then, I don't think I've ever looked at the spec!
On 06/06/07, Robert Greig <ro...@gmail.com> wrote:
>
> On 06/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> > This sounds likely to me. I think you can break Sun's rules if you are
> not a
> > licensee, after all you were never a party to the agreement in the first
> > place. If IBM are a licensee and they have rewritten JMS as XMS in C++
> they
> > must have an exception.
>
> Unfortunately unless you try to claim you have never read or
> downloaded the JMS spec, you have agreed to its terms and conditions:
>
> "By viewing, downloading or otherwise copying the Specification, you agree
> that you have read, understood, and will comply with all of the terms
> and conditions set forth herein"
>
> RG
>
Re: NMS
Posted by Robert Greig <ro...@gmail.com>.
On 06/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> This sounds likely to me. I think you can break Sun's rules if you are not a
> licensee, after all you were never a party to the agreement in the first
> place. If IBM are a licensee and they have rewritten JMS as XMS in C++ they
> must have an exception.
Unfortunately unless you try to claim you have never read or
downloaded the JMS spec, you have agreed to its terms and conditions:
"By viewing, downloading or otherwise copying the Specification, you agree
that you have read, understood, and will comply with all of the terms
and conditions set forth herein"
RG
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
This sounds likely to me. I think you can break Sun's rules if you are not a
licensee, after all you were never a party to the agreement in the first
place. If IBM are a licensee and they have rewritten JMS as XMS in C++ they
must have an exception.
On 06/06/07, Paul Fremantle <pz...@gmail.com> wrote:
>
> Unfortunately IBM licenses Sun technology under a different set of
> rules, meaning that you cannot be sure that the IBM did not get an
> exclusion to the license.
>
> Paul
>
> On 6/1/07, Colin Crist <co...@hermesjms.com> wrote:
> >
> > In case you've not seen this, IBM have long since rendered the JMS API
> into
> > C++, C and C#
> >
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> > ps/0509_phillips.html
> >
> > Colin.
> >
> > > -----Original Message-----
> > > From: Arnaud Simon [mailto:asimon@redhat.com]
> > > Sent: 01 June 2007 15:34
> > > To: legal-discuss@apache.org; general@incubator.apache.org
> > > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > > Subject: NMS
> > >
> > > Hello,
> > >
> > > We have been thinking about implementing the NMS API as part
> > > of the QPID .Net client. However we are concerned about
> > > potential legal issues.
> > > It seems to me that the NMS API is very similar to the JMS
> > > one but the JMS specification specifically licenses the
> > > technology "only for Java".
> > >
> > > This is the relevant license, copied directly from the JMS Spec
> > > document:
> > >
> > > "Subject to the terms and conditions of this license, Sun
> > > hereby grants you a fully-paid, non-exclusive,
> > > non-transferable, worldwide, limited license (without the
> > > right to sublicense) under Sun's intellectual property rights
> > > to review the Specification internally solely for the purpose
> > > of designing and developing your Java applets and
> > > applications intended to run on the Java platform. Other than
> > > this limited license, you acquire no right, title or interest
> > > in or to the Specification or any other Sun intellectual
> > > property. The Specification contains the proprietary
> > > information of Sun and may only be used in accordance with
> > > the license terms set forth herein. This license will
> > > terminate immediately without notice from Sun if you fail to
> > > comply with any provision of this license. Upon termination
> > > or expiration of this license, you must cease use of or
> > > destroy the Specification."
> > >
> > > Does anybody know if this concern has already been raised?
> > >
> > > Regards
> > >
> > > Arnaud
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> Paul Fremantle
> Co-Founder and VP of Technical Sales, WSO2
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Unfortunately IBM licenses Sun technology under a different set of
rules, meaning that you cannot be sure that the IBM did not get an
exclusion to the license.
Paul
On 6/1/07, Colin Crist <co...@hermesjms.com> wrote:
>
> In case you've not seen this, IBM have long since rendered the JMS API into
> C++, C and C#
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> ps/0509_phillips.html
>
> Colin.
>
> > -----Original Message-----
> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > Sent: 01 June 2007 15:34
> > To: legal-discuss@apache.org; general@incubator.apache.org
> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > Subject: NMS
> >
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part
> > of the QPID .Net client. However we are concerned about
> > potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS
> > one but the JMS specification specifically licenses the
> > technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun
> > hereby grants you a fully-paid, non-exclusive,
> > non-transferable, worldwide, limited license (without the
> > right to sublicense) under Sun's intellectual property rights
> > to review the Specification internally solely for the purpose
> > of designing and developing your Java applets and
> > applications intended to run on the Java platform. Other than
> > this limited license, you acquire no right, title or interest
> > in or to the Specification or any other Sun intellectual
> > property. The Specification contains the proprietary
> > information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will
> > terminate immediately without notice from Sun if you fail to
> > comply with any provision of this license. Upon termination
> > or expiration of this license, you must cease use of or
> > destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
>
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: NMS
Posted by Rupert Smith <ru...@googlemail.com>.
Interestingly:
>...and when not to use XMS
>
>When using WebSphere MQ and maximum performance is required
>
>XMS provides a wrapper on top of the native WebSphere MQ programming verbs
(MQI), which means that an XMS application may not >perform as well as a
well-written MQI application.
In other words, they are finding that overly stacked API's degrade
performance.
Rupert
On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
>
>
> In case you've not seen this, IBM have long since rendered the JMS API
> into
> C++, C and C#
>
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> ps/0509_phillips.html
>
> Colin.
>
> > -----Original Message-----
> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > Sent: 01 June 2007 15:34
> > To: legal-discuss@apache.org; general@incubator.apache.org
> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > Subject: NMS
> >
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part
> > of the QPID .Net client. However we are concerned about
> > potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS
> > one but the JMS specification specifically licenses the
> > technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun
> > hereby grants you a fully-paid, non-exclusive,
> > non-transferable, worldwide, limited license (without the
> > right to sublicense) under Sun's intellectual property rights
> > to review the Specification internally solely for the purpose
> > of designing and developing your Java applets and
> > applications intended to run on the Java platform. Other than
> > this limited license, you acquire no right, title or interest
> > in or to the Specification or any other Sun intellectual
> > property. The Specification contains the proprietary
> > information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will
> > terminate immediately without notice from Sun if you fail to
> > comply with any provision of this license. Upon termination
> > or expiration of this license, you must cease use of or
> > destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
>
>
>
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
NMS is something that the Apache ActiveMQ team have done.
http://activemq.apache.org/nms/
Whether we are in violation of the Sun licenses is a fine question.
Paul
On 6/6/07, robert burrell donkin <ro...@gmail.com> wrote:
> which standards body created NMS?
>
> - robert
>
> On 6/1/07, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > Coping incubator general and apache legal lists on this thread for
> > additional comments on this topic.
> > Carl.
> >
> > John O'Hara wrote:
> > > Yes, IBM are I fully paid up licensee of Java technology - and can do
> > > whatever they like with it.
> > >
> > > I asked permission of IBM if we could implement the XMS API some time
> > > back,
> > > and they said they did not have the right to grant that approval....
> > >
> > > Unless Apache has a license to do this that I am not aware of, we are
> > > not on
> > > safe ground since NMS is clearly a derived work of JMS.
> > >
> > > Wait for the lawyers....
> > > John
> > > On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
> > >>
> > >>
> > >> In case you've not seen this, IBM have long since rendered the JMS API
> > >> into
> > >> C++, C and C#
> > >>
> > >> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> > >>
> > >> ps/0509_phillips.html
> > >>
> > >> Colin.
> > >>
> > >> > -----Original Message-----
> > >> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > >> > Sent: 01 June 2007 15:34
> > >> > To: legal-discuss@apache.org; general@incubator.apache.org
> > >> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > >> > Subject: NMS
> > >> >
> > >> > Hello,
> > >> >
> > >> > We have been thinking about implementing the NMS API as part
> > >> > of the QPID .Net client. However we are concerned about
> > >> > potential legal issues.
> > >> > It seems to me that the NMS API is very similar to the JMS
> > >> > one but the JMS specification specifically licenses the
> > >> > technology "only for Java".
> > >> >
> > >> > This is the relevant license, copied directly from the JMS Spec
> > >> > document:
> > >> >
> > >> > "Subject to the terms and conditions of this license, Sun
> > >> > hereby grants you a fully-paid, non-exclusive,
> > >> > non-transferable, worldwide, limited license (without the
> > >> > right to sublicense) under Sun's intellectual property rights
> > >> > to review the Specification internally solely for the purpose
> > >> > of designing and developing your Java applets and
> > >> > applications intended to run on the Java platform. Other than
> > >> > this limited license, you acquire no right, title or interest
> > >> > in or to the Specification or any other Sun intellectual
> > >> > property. The Specification contains the proprietary
> > >> > information of Sun and may only be used in accordance with
> > >> > the license terms set forth herein. This license will
> > >> > terminate immediately without notice from Sun if you fail to
> > >> > comply with any provision of this license. Upon termination
> > >> > or expiration of this license, you must cease use of or
> > >> > destroy the Specification."
> > >> >
> > >> > Does anybody know if this concern has already been raised?
> > >> >
> > >> > Regards
> > >> >
> > >> > Arnaud
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
NMS is something that the Apache ActiveMQ team have done.
http://activemq.apache.org/nms/
Whether we are in violation of the Sun licenses is a fine question.
Paul
On 6/6/07, robert burrell donkin <ro...@gmail.com> wrote:
> which standards body created NMS?
>
> - robert
>
> On 6/1/07, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > Coping incubator general and apache legal lists on this thread for
> > additional comments on this topic.
> > Carl.
> >
> > John O'Hara wrote:
> > > Yes, IBM are I fully paid up licensee of Java technology - and can do
> > > whatever they like with it.
> > >
> > > I asked permission of IBM if we could implement the XMS API some time
> > > back,
> > > and they said they did not have the right to grant that approval....
> > >
> > > Unless Apache has a license to do this that I am not aware of, we are
> > > not on
> > > safe ground since NMS is clearly a derived work of JMS.
> > >
> > > Wait for the lawyers....
> > > John
> > > On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
> > >>
> > >>
> > >> In case you've not seen this, IBM have long since rendered the JMS API
> > >> into
> > >> C++, C and C#
> > >>
> > >> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> > >>
> > >> ps/0509_phillips.html
> > >>
> > >> Colin.
> > >>
> > >> > -----Original Message-----
> > >> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > >> > Sent: 01 June 2007 15:34
> > >> > To: legal-discuss@apache.org; general@incubator.apache.org
> > >> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > >> > Subject: NMS
> > >> >
> > >> > Hello,
> > >> >
> > >> > We have been thinking about implementing the NMS API as part
> > >> > of the QPID .Net client. However we are concerned about
> > >> > potential legal issues.
> > >> > It seems to me that the NMS API is very similar to the JMS
> > >> > one but the JMS specification specifically licenses the
> > >> > technology "only for Java".
> > >> >
> > >> > This is the relevant license, copied directly from the JMS Spec
> > >> > document:
> > >> >
> > >> > "Subject to the terms and conditions of this license, Sun
> > >> > hereby grants you a fully-paid, non-exclusive,
> > >> > non-transferable, worldwide, limited license (without the
> > >> > right to sublicense) under Sun's intellectual property rights
> > >> > to review the Specification internally solely for the purpose
> > >> > of designing and developing your Java applets and
> > >> > applications intended to run on the Java platform. Other than
> > >> > this limited license, you acquire no right, title or interest
> > >> > in or to the Specification or any other Sun intellectual
> > >> > property. The Specification contains the proprietary
> > >> > information of Sun and may only be used in accordance with
> > >> > the license terms set forth herein. This license will
> > >> > terminate immediately without notice from Sun if you fail to
> > >> > comply with any provision of this license. Upon termination
> > >> > or expiration of this license, you must cease use of or
> > >> > destroy the Specification."
> > >> >
> > >> > Does anybody know if this concern has already been raised?
> > >> >
> > >> > Regards
> > >> >
> > >> > Arnaud
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by robert burrell donkin <ro...@gmail.com>.
which standards body created NMS?
- robert
On 6/1/07, Carl Trieloff <cc...@redhat.com> wrote:
>
> Coping incubator general and apache legal lists on this thread for
> additional comments on this topic.
> Carl.
>
> John O'Hara wrote:
> > Yes, IBM are I fully paid up licensee of Java technology - and can do
> > whatever they like with it.
> >
> > I asked permission of IBM if we could implement the XMS API some time
> > back,
> > and they said they did not have the right to grant that approval....
> >
> > Unless Apache has a license to do this that I am not aware of, we are
> > not on
> > safe ground since NMS is clearly a derived work of JMS.
> >
> > Wait for the lawyers....
> > John
> > On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
> >>
> >>
> >> In case you've not seen this, IBM have long since rendered the JMS API
> >> into
> >> C++, C and C#
> >>
> >> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> >>
> >> ps/0509_phillips.html
> >>
> >> Colin.
> >>
> >> > -----Original Message-----
> >> > From: Arnaud Simon [mailto:asimon@redhat.com]
> >> > Sent: 01 June 2007 15:34
> >> > To: legal-discuss@apache.org; general@incubator.apache.org
> >> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> >> > Subject: NMS
> >> >
> >> > Hello,
> >> >
> >> > We have been thinking about implementing the NMS API as part
> >> > of the QPID .Net client. However we are concerned about
> >> > potential legal issues.
> >> > It seems to me that the NMS API is very similar to the JMS
> >> > one but the JMS specification specifically licenses the
> >> > technology "only for Java".
> >> >
> >> > This is the relevant license, copied directly from the JMS Spec
> >> > document:
> >> >
> >> > "Subject to the terms and conditions of this license, Sun
> >> > hereby grants you a fully-paid, non-exclusive,
> >> > non-transferable, worldwide, limited license (without the
> >> > right to sublicense) under Sun's intellectual property rights
> >> > to review the Specification internally solely for the purpose
> >> > of designing and developing your Java applets and
> >> > applications intended to run on the Java platform. Other than
> >> > this limited license, you acquire no right, title or interest
> >> > in or to the Specification or any other Sun intellectual
> >> > property. The Specification contains the proprietary
> >> > information of Sun and may only be used in accordance with
> >> > the license terms set forth herein. This license will
> >> > terminate immediately without notice from Sun if you fail to
> >> > comply with any provision of this license. Upon termination
> >> > or expiration of this license, you must cease use of or
> >> > destroy the Specification."
> >> >
> >> > Does anybody know if this concern has already been raised?
> >> >
> >> > Regards
> >> >
> >> > Arnaud
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
Coping incubator general and apache legal lists on this thread for
additional comments on this topic.
Carl.
John O'Hara wrote:
> Yes, IBM are I fully paid up licensee of Java technology - and can do
> whatever they like with it.
>
> I asked permission of IBM if we could implement the XMS API some time
> back,
> and they said they did not have the right to grant that approval....
>
> Unless Apache has a license to do this that I am not aware of, we are
> not on
> safe ground since NMS is clearly a derived work of JMS.
>
> Wait for the lawyers....
> John
> On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
>>
>>
>> In case you've not seen this, IBM have long since rendered the JMS API
>> into
>> C++, C and C#
>>
>> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
>>
>> ps/0509_phillips.html
>>
>> Colin.
>>
>> > -----Original Message-----
>> > From: Arnaud Simon [mailto:asimon@redhat.com]
>> > Sent: 01 June 2007 15:34
>> > To: legal-discuss@apache.org; general@incubator.apache.org
>> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
>> > Subject: NMS
>> >
>> > Hello,
>> >
>> > We have been thinking about implementing the NMS API as part
>> > of the QPID .Net client. However we are concerned about
>> > potential legal issues.
>> > It seems to me that the NMS API is very similar to the JMS
>> > one but the JMS specification specifically licenses the
>> > technology "only for Java".
>> >
>> > This is the relevant license, copied directly from the JMS Spec
>> > document:
>> >
>> > "Subject to the terms and conditions of this license, Sun
>> > hereby grants you a fully-paid, non-exclusive,
>> > non-transferable, worldwide, limited license (without the
>> > right to sublicense) under Sun's intellectual property rights
>> > to review the Specification internally solely for the purpose
>> > of designing and developing your Java applets and
>> > applications intended to run on the Java platform. Other than
>> > this limited license, you acquire no right, title or interest
>> > in or to the Specification or any other Sun intellectual
>> > property. The Specification contains the proprietary
>> > information of Sun and may only be used in accordance with
>> > the license terms set forth herein. This license will
>> > terminate immediately without notice from Sun if you fail to
>> > comply with any provision of this license. Upon termination
>> > or expiration of this license, you must cease use of or
>> > destroy the Specification."
>> >
>> > Does anybody know if this concern has already been raised?
>> >
>> > Regards
>> >
>> > Arnaud
>> >
>> >
>> >
>>
>>
>>
>
Re: NMS
Posted by Carl Trieloff <cc...@redhat.com>.
Coping incubator general and apache legal lists on this thread for
additional comments on this topic.
Carl.
John O'Hara wrote:
> Yes, IBM are I fully paid up licensee of Java technology - and can do
> whatever they like with it.
>
> I asked permission of IBM if we could implement the XMS API some time
> back,
> and they said they did not have the right to grant that approval....
>
> Unless Apache has a license to do this that I am not aware of, we are
> not on
> safe ground since NMS is clearly a derived work of JMS.
>
> Wait for the lawyers....
> John
> On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
>>
>>
>> In case you've not seen this, IBM have long since rendered the JMS API
>> into
>> C++, C and C#
>>
>> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
>>
>> ps/0509_phillips.html
>>
>> Colin.
>>
>> > -----Original Message-----
>> > From: Arnaud Simon [mailto:asimon@redhat.com]
>> > Sent: 01 June 2007 15:34
>> > To: legal-discuss@apache.org; general@incubator.apache.org
>> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
>> > Subject: NMS
>> >
>> > Hello,
>> >
>> > We have been thinking about implementing the NMS API as part
>> > of the QPID .Net client. However we are concerned about
>> > potential legal issues.
>> > It seems to me that the NMS API is very similar to the JMS
>> > one but the JMS specification specifically licenses the
>> > technology "only for Java".
>> >
>> > This is the relevant license, copied directly from the JMS Spec
>> > document:
>> >
>> > "Subject to the terms and conditions of this license, Sun
>> > hereby grants you a fully-paid, non-exclusive,
>> > non-transferable, worldwide, limited license (without the
>> > right to sublicense) under Sun's intellectual property rights
>> > to review the Specification internally solely for the purpose
>> > of designing and developing your Java applets and
>> > applications intended to run on the Java platform. Other than
>> > this limited license, you acquire no right, title or interest
>> > in or to the Specification or any other Sun intellectual
>> > property. The Specification contains the proprietary
>> > information of Sun and may only be used in accordance with
>> > the license terms set forth herein. This license will
>> > terminate immediately without notice from Sun if you fail to
>> > comply with any provision of this license. Upon termination
>> > or expiration of this license, you must cease use of or
>> > destroy the Specification."
>> >
>> > Does anybody know if this concern has already been raised?
>> >
>> > Regards
>> >
>> > Arnaud
>> >
>> >
>> >
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: NMS
Posted by John O'Hara <jo...@gmail.com>.
Yes, IBM are I fully paid up licensee of Java technology - and can do
whatever they like with it.
I asked permission of IBM if we could implement the XMS API some time back,
and they said they did not have the right to grant that approval....
Unless Apache has a license to do this that I am not aware of, we are not on
safe ground since NMS is clearly a derived work of JMS.
Wait for the lawyers....
John
On 01/06/07, Colin Crist <co...@hermesjms.com> wrote:
>
>
> In case you've not seen this, IBM have long since rendered the JMS API
> into
> C++, C and C#
>
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> ps/0509_phillips.html
>
> Colin.
>
> > -----Original Message-----
> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > Sent: 01 June 2007 15:34
> > To: legal-discuss@apache.org; general@incubator.apache.org
> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > Subject: NMS
> >
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part
> > of the QPID .Net client. However we are concerned about
> > potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS
> > one but the JMS specification specifically licenses the
> > technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun
> > hereby grants you a fully-paid, non-exclusive,
> > non-transferable, worldwide, limited license (without the
> > right to sublicense) under Sun's intellectual property rights
> > to review the Specification internally solely for the purpose
> > of designing and developing your Java applets and
> > applications intended to run on the Java platform. Other than
> > this limited license, you acquire no right, title or interest
> > in or to the Specification or any other Sun intellectual
> > property. The Specification contains the proprietary
> > information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will
> > terminate immediately without notice from Sun if you fail to
> > comply with any provision of this license. Upon termination
> > or expiration of this license, you must cease use of or
> > destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
>
>
>
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Unfortunately IBM licenses Sun technology under a different set of
rules, meaning that you cannot be sure that the IBM did not get an
exclusion to the license.
Paul
On 6/1/07, Colin Crist <co...@hermesjms.com> wrote:
>
> In case you've not seen this, IBM have long since rendered the JMS API into
> C++, C and C#
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> ps/0509_phillips.html
>
> Colin.
>
> > -----Original Message-----
> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > Sent: 01 June 2007 15:34
> > To: legal-discuss@apache.org; general@incubator.apache.org
> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > Subject: NMS
> >
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part
> > of the QPID .Net client. However we are concerned about
> > potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS
> > one but the JMS specification specifically licenses the
> > technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun
> > hereby grants you a fully-paid, non-exclusive,
> > non-transferable, worldwide, limited license (without the
> > right to sublicense) under Sun's intellectual property rights
> > to review the Specification internally solely for the purpose
> > of designing and developing your Java applets and
> > applications intended to run on the Java platform. Other than
> > this limited license, you acquire no right, title or interest
> > in or to the Specification or any other Sun intellectual
> > property. The Specification contains the proprietary
> > information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will
> > terminate immediately without notice from Sun if you fail to
> > comply with any provision of this license. Upon termination
> > or expiration of this license, you must cease use of or
> > destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
>
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: NMS
Posted by Paul Fremantle <pz...@gmail.com>.
Unfortunately IBM licenses Sun technology under a different set of
rules, meaning that you cannot be sure that the IBM did not get an
exclusion to the license.
Paul
On 6/1/07, Colin Crist <co...@hermesjms.com> wrote:
>
> In case you've not seen this, IBM have long since rendered the JMS API into
> C++, C and C#
> http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
> ps/0509_phillips.html
>
> Colin.
>
> > -----Original Message-----
> > From: Arnaud Simon [mailto:asimon@redhat.com]
> > Sent: 01 June 2007 15:34
> > To: legal-discuss@apache.org; general@incubator.apache.org
> > Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> > Subject: NMS
> >
> > Hello,
> >
> > We have been thinking about implementing the NMS API as part
> > of the QPID .Net client. However we are concerned about
> > potential legal issues.
> > It seems to me that the NMS API is very similar to the JMS
> > one but the JMS specification specifically licenses the
> > technology "only for Java".
> >
> > This is the relevant license, copied directly from the JMS Spec
> > document:
> >
> > "Subject to the terms and conditions of this license, Sun
> > hereby grants you a fully-paid, non-exclusive,
> > non-transferable, worldwide, limited license (without the
> > right to sublicense) under Sun's intellectual property rights
> > to review the Specification internally solely for the purpose
> > of designing and developing your Java applets and
> > applications intended to run on the Java platform. Other than
> > this limited license, you acquire no right, title or interest
> > in or to the Specification or any other Sun intellectual
> > property. The Specification contains the proprietary
> > information of Sun and may only be used in accordance with
> > the license terms set forth herein. This license will
> > terminate immediately without notice from Sun if you fail to
> > comply with any provision of this license. Upon termination
> > or expiration of this license, you must cease use of or
> > destroy the Specification."
> >
> > Does anybody know if this concern has already been raised?
> >
> > Regards
> >
> > Arnaud
> >
> >
> >
>
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: NMS
Posted by Colin Crist <co...@hermesjms.com>.
In case you've not seen this, IBM have long since rendered the JMS API into
C++, C and C#
http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
ps/0509_phillips.html
Colin.
> -----Original Message-----
> From: Arnaud Simon [mailto:asimon@redhat.com]
> Sent: 01 June 2007 15:34
> To: legal-discuss@apache.org; general@incubator.apache.org
> Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> Subject: NMS
>
> Hello,
>
> We have been thinking about implementing the NMS API as part
> of the QPID .Net client. However we are concerned about
> potential legal issues.
> It seems to me that the NMS API is very similar to the JMS
> one but the JMS specification specifically licenses the
> technology "only for Java".
>
> This is the relevant license, copied directly from the JMS Spec
> document:
>
> "Subject to the terms and conditions of this license, Sun
> hereby grants you a fully-paid, non-exclusive,
> non-transferable, worldwide, limited license (without the
> right to sublicense) under Sun's intellectual property rights
> to review the Specification internally solely for the purpose
> of designing and developing your Java applets and
> applications intended to run on the Java platform. Other than
> this limited license, you acquire no right, title or interest
> in or to the Specification or any other Sun intellectual
> property. The Specification contains the proprietary
> information of Sun and may only be used in accordance with
> the license terms set forth herein. This license will
> terminate immediately without notice from Sun if you fail to
> comply with any provision of this license. Upon termination
> or expiration of this license, you must cease use of or
> destroy the Specification."
>
> Does anybody know if this concern has already been raised?
>
> Regards
>
> Arnaud
>
>
>
RE: NMS
Posted by Colin Crist <co...@hermesjms.com>.
In case you've not seen this, IBM have long since rendered the JMS API into
C++, C and C#
http://www.ibm.com/developerworks/websphere/library/techarticles/0509_philli
ps/0509_phillips.html
Colin.
> -----Original Message-----
> From: Arnaud Simon [mailto:asimon@redhat.com]
> Sent: 01 June 2007 15:34
> To: legal-discuss@apache.org; general@incubator.apache.org
> Cc: users@activemq.apache.org; qpid-dev@incubator.apache.org
> Subject: NMS
>
> Hello,
>
> We have been thinking about implementing the NMS API as part
> of the QPID .Net client. However we are concerned about
> potential legal issues.
> It seems to me that the NMS API is very similar to the JMS
> one but the JMS specification specifically licenses the
> technology "only for Java".
>
> This is the relevant license, copied directly from the JMS Spec
> document:
>
> "Subject to the terms and conditions of this license, Sun
> hereby grants you a fully-paid, non-exclusive,
> non-transferable, worldwide, limited license (without the
> right to sublicense) under Sun's intellectual property rights
> to review the Specification internally solely for the purpose
> of designing and developing your Java applets and
> applications intended to run on the Java platform. Other than
> this limited license, you acquire no right, title or interest
> in or to the Specification or any other Sun intellectual
> property. The Specification contains the proprietary
> information of Sun and may only be used in accordance with
> the license terms set forth herein. This license will
> terminate immediately without notice from Sun if you fail to
> comply with any provision of this license. Upon termination
> or expiration of this license, you must cease use of or
> destroy the Specification."
>
> Does anybody know if this concern has already been raised?
>
> Regards
>
> Arnaud
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org