I am not sure that the practice of typing in the APIs using the source code
as a guide is addressing the same issue legally.
Presumably that is to get around licencing on the specific jars.
The issue I was referring to was around the use of the documentation itself
(as it states in the licence: "to review the Specification..."). By using
that documentation as the basis for another product not "intended to run on
the Java platform" it looks like you would be infringing the licence.
(Obviously I am not a lawyer so it would be useful to get some
clarification on this from someone who is).
RG
|---------+---------------------------->
| | "James Strachan" |
| | <[EMAIL PROTECTED]|
| | mail.com> |
| | |
| | 20/07/2006 08:51 |
| | Please respond to|
| | general |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: general@incubator.apache.org
|
| cc:
|
| Subject: Re: [Proposal] Blaze
|
>------------------------------------------------------------------------------------------------------------------------------|
I guess its a murky area legally - making similar APIs using
documentation as a guide. e.g. its quite striking how many extremely
similar APIs are in .Net and Mono to the JDK.
FWIW there's a current practice to get around Sun's bizarre licensing
on various Java/J2EE APIs - folks type in their own version of the
source code using the javadoc as a guide. e.g. try the
geronimo-spec-*.jar as an Apache licensed version of the
crappily-licensed-Sun J2EE jars. I guess thats legal right? So maybe
just using documentation to create similar APIs on other platforms is
OK?
On 7/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> I think there may be some legal issues with creating an API that
resembles
> JMS too closely.
>
> From the JMS licence terms:
>
> "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."
>
> The key bit here is "intended to run on the Java platform".
>
> That said there is definitely merit in having our .NET API and C++ API
> being relatively similar.
>
> XMS for C# does resemble JMS very closely although with delegates and
with
> the naming convention for interfaces. I am not sure whether IBM would be
> interested in donating XMS.
>
> RG
>
>
> |---------+---------------------------->
> | | "James Strachan" |
> | | <[EMAIL PROTECTED]|
> | | mail.com> |
> | | |
> | | 19/07/2006 20:50 |
> | | Please respond to|
> | | general |
> |---------+---------------------------->
>
>------------------------------------------------------------------------------------------------------------------------------|
> |
|
> | To: general@incubator.apache.org
|
> | cc:
|
> | Subject: Re: [Proposal] Blaze
|
>
>------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> On 7/19/06, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> > > Currently ActiveMQ has several C/C++ clients (with another client
> > > library waiting to get through the donator's lawyers), so it might
> > > make sense at some point to try unify the C++ clients together too so
> > > users have a single C++ API for their messaging client and then a
> > > number of implentations/transports/protocols to use at deployment
> > > time. i.e. making a JMS for C++ API. (We've got a good start called
> > > CMS in ActiveMQ...)
> >
> > I agree that a C++ (and also C) rendering of a JMS like API is going
> > to be a very useful thing.
> >
> > James - do you have any idea how CMS matches or differs from IBM's XMS
> > (
>
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0509_phillips/0509_phillips.html
> )?
> > XMS is also a rendering of JMS into C/C#/C++.
>
> Thanks for the link! I've had a quick look and it looks remarkably
> close to the current CMS client. Hardly surprising I guess since they
> are both kinda clones of the JMS API but in C++ and using JMS 1.1 and
> mostly ignoring the crappy bits of JMS 1.0.2b :)
>
> I couldn't see the C# client so not sure if we differ a bit there - we
> ended up changing the C# client a little from JMS to make use of C#
> coding conventions and features (like delegates and events etc) - and
> we followed that sucky C# practice of naming interfaces IConnection
> etc :). Not sure if the XMS in C# does the same. (We imaginatively
> called the C# client NMS for .Net Messaging System).
>
> I wonder if IBM and the XMS folks would be interested in donating the
> *API* code for XMS to Apache and working with other folks at Apache so
> we can merge some of the C/C++/C# clients together into a single
> reuable client API with pluggable providers (and maybe even some
> resuable optional implementation code different implementations could
> choose to reuse)?
>
> There's clearly a delta between AMQP and the features of JMS, but even
> if we just get the core JMS semantics reusable across the clients it'd
> be a big win IMHO.
>
>
> > I think it would be interesting to see a confluence of the APIs and
> > protocols between ActiveMQ and Blaze giving interoperability in both
> > code and on the wire.
>
> Agreed.
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices, data and other information are not warranted as to completeness or
accuracy and are subject to change without notice. Any comments or
statements made herein do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure under
applicable law. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution, or use of the
information contained herein (including any reliance thereon) is STRICTLY
PROHIBITED. Although this transmission and any attachments are believed to
be free of any virus or other defect that might affect any computer system
into which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is accepted
by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable,
for any loss or damage arising in any way from its use. If you received
this transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard copy
format. Thank you.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This communication is for informational purposes only. It is not intended as an
offer or solicitation for the purchase or sale of any financial instrument or
as an official confirmation of any transaction. All market prices, data and
other information are not warranted as to completeness or accuracy and are
subject to change without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and
affiliates.
This transmission may contain information that is privileged, confidential,
legally privileged, and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information contained herein (including
any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other defect that might
affect any computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and
affiliates, as applicable, for any loss or damage arising in any way from its
use. If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
