James Strachan wrote: > 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?
That's not why people do it - they do it because until recently, Sun's binaries for for the API classes/interfaces were available only under unacceptable restrictive terms. geir > > > 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] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
