|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 70
Messages: 70
Messages: 70
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Mule: A Case Study
Enterprise service buses are the preferred tools for integrating systems with heterogeneous data interchange interfaces and based on a wide array of technologies, from COBOL to CORBA to JEE. This article is an introduction to ESBs and enterprise integration using Mule, the open-source ESB.Major vendors first sold message queuing as the ultimate interoperability solution, then SOAP and REST, before realizing that multiple applications need to share data but had significant interface differences. Architects and vendors suggested many approaches to solving this issue, from writing wrappers using a common protocol to porting legacy systems to Java or .Net and, in the process, create a modern interface that fit in the enterprise architecture. None of these approaches is practical because they are code-intensive, expensive, and are coupled to specific systems, programming languages, and protocols.
Early attempts at solving this issue involved creating a bus using a common transport like MQ Series and defining a common message format (positional or XML). Systems participating in data exchanges would implement messages with specific attributes and place them in a queue. This soon becomes impractical because message formats need to be revised too often to accommodate new attributes and exponentially increases regression testing and debugging time and expense. Similar problems occur when using SOAP, REST, or almost any protocol.
The solution to this problem is elegant and obvious: let the applications communicate with one another in the protocols they already support, from EDI to SOAP, over a common transport aggregator independent of the native protocols, and adding application- or protocol-specific translation modules or message routing only where required at the endpoints. This approach allows a mainframe application written in COBOL to interoperate with a mobile device written with J2ME without either end knowing anything about the others characteristics.
|
|
|
Message #225440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Greate Case Study.
Eugene has done an excellent job. Great job! Now tell me how Mule compares to ServiceMix? What are some short comings to Mule?
Best Regards,
Richard L. Burton III
|
|
|
Message #225444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Mule rocks
I don't say that often but Mule rocks! Ahmm, can you please solve my Jira issue I posted several month ago? ;-)
-- Andreas
|
|
|
Message #225446
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPEL support
In addition to the unfortunate logo requirement, the actual price for the "per-year" subscription to remove the logo is not present on the web site.
To add to this problem, it seems that the WS-BPEL component is provided by a 3rd party company, Intalio, with no published price for a proper production license.
|
|
|
Message #225449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: BPEL support
In addition to the unfortunate logo requirement, the actual price for the "per-year" subscription to remove the logo is not present on the web site.
To add to this problem, it seems that the WS-BPEL component is provided by a 3rd party company, Intalio, with no published price for a proper production license.
Intalio's BPEL engine is "free" if used on Redhat I believe, it would be wise to check though because these things change, one day they're free then next day you have to pay :-)
-John-
|
|
|
Message #225451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPEL support
Intalio's BPEL Engine is "free" if used on Redhat I believe
Intalio has recently relicensed it's stuff and is also now MPL+Attribution.
|
|
|
Message #225452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
I have to say this is rather sad BUT at the end of the day people have to earn a living.
I think the main problem with the Mule attribution is that it was not well thought out. It was obviously take from another product that was more GUI based. Mule is essentially headless so where do you display the nag-ware on a server based on Mule? Sure there are ways to do it but it's not well written legally.
I think Mule is an excellent product but it's a shame they've had to resort to these measures, it will slow their uptake. Badgeware or no badgeware it will still run loops around ServiceMix, it has a better architecture.
-John-
|
|
|
Message #225456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Badgeware or no badgeware it will still run loops around ServiceMix, it has a better architecture.
LOL! There you go again John, no wonder its hard to take you seriously :)
|
|
|
Message #225459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Badgeware or no badgeware it will still run loops around ServiceMix, it has a better architecture.
LOL! There you go again John, no wonder its hard to take you seriously :)
Well, perhaps you're right, may be not loops but I do find it more open than ServiceMix, there's less dependency on certain parts of the stack.
I have to say that I do actually like ServiceMix too, it's not black and white, sorry if I offended you.
-John-
|
|
|
Message #225460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: BPEL support
Intalio's BPEL Engine is "free" if used on Redhat I believe
Intalio has recently relicensed it's stuff and is also now MPL+Attribution.
What is the world coming to?
-John-
|
|
|
Message #225462
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Digg the article if you liked it...
Thanks for your support and comments about the article - awesome!
Help us get the ratings up, inform more people about Mule, and drive more traffic to The Server Side...
Digg the article.
Thanks again!
Cheers,
Eugene
|
|
|
Message #225463
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Interesting thread...it'd be nice if someone from mulesource could comment further on this situation. My company has been concerned about this too, but when I contacted them about it saying we'd be forced to drop all usage of mule because of this, they wrote back that the badge requirement didn't apply to non-commercial applications. Here's a snippet of the conversation:
Me: "I develop software at our bank for our internal ESB implementation.
The clients of the application are other internal applications that
use our web services. We don't sell this software as a commercial
product.
So if I understand this correctly, an internal software application
not for sale outside the company is not bound to that additional
license requirement?"
Them: "That is correct. As long as you are not selling a commercial product you are in the clear."
|
|
|
Message #225465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re
2 Eugene - there's an error in Figure 2. The flow is left to right, so the message receiver should be on the left, and sender (dispatcher in Mule terminology) - on the right. And congrats on this article, it hopefully takes one hurdle out on Mule adopter's path.
2 Dan. IANAL, but that's the meat of MPL+Attribution. As long as it's for internal consumption, you are free to use it at will (much like with GPL for internal use). Once you go out in this wild world, that's where the attribution vs commercial steps in.
|
|
|
Message #225467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re
2 Eugene - there's an error in Figure 2. The flow is left to right, so the message receiver should be on the left, and sender (dispatcher in Mule terminology) - on the right. And congrats on this article, it hopefully takes one hurdle out on Mule adopter's path.
Ah! Good catch -- I'll update it and post a link to the updated diagram later, perhaps even ask TSS to update the image.
Thanks and cheers,
E
|
|
|
Message #225469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: MPL+Attribution
Andrew:
IANAL, but that's the meat of MPL+Attribution. As long as it's for internal consumption, you are free to use it at will...
The concept of distribution vs. internal use is a potential minefield, IMHO.
Consider the case of a distributing your program to a subsidiary of your own company. Is that considered "distribution" for the purposes of Exhibit B? You are transferring the program outside the legal entity in which it was created.
What if that subsidiary is not wholly owned by your company? Or worse, your company is a minority owner?
There are questions here that haven't been clarified by the courts yet so I'm treading carefully.
Eugene: A timely and relevant article! Thanks!
--Scott
|
|
|
Message #225473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MuleSource team ready to take your questions...
Hey Dan,
I am the guy (CEO) you emailed with a few months back and the conversation is still the same. Basically the MPL+ lets us protect our IP without forcing users down any specific path.
We recognize that this license may not be the most appropriate thing for everyone and we are actively looking into options. Mind you, this is not the easiest thing to figure out.
For example, the GPL is not an option for Mule--primarily because our users are not interested in GPL, and we don't like certain aspects. The MPL+ was the best choice as we launched the company and rev'd the project into 1.3.
|
|
|
Message #225476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Old wine, new bottles?
I like the idea of messaging and ESBs sounds like a neat idea. Comming from a Tuxedo background though, the question that comes to mind is how do these new tools compare with something like Tuxedo?
Have they the same fexibility as FML for instance? It would be nice to hear from soneone with experience with both ESBs and Tuxedo.
Paul
|
|
|
Message #225478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interesting article, but leaving some for the curious...
Interesting introductory article.
What makes me curious:
"Several open-source and commercial ESBs exist now. Each offers different features and caveats."
-- A (link to a) list with features and caveats for ESB products would be a great help.
"Mule is the best of breed open-source enterprise service bus."
-- Is this for the features, the lack of caveats, the quality of implementation, the support, ...?
Regards, Rob.
|
|
|
Message #225488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Hi Mark,
Just to clarify, the Attribution only comes into play when you are embedding Mule in a commercial application that you intend to sell on an open market. For example, if I am a department in an investment bank and I have built a front office application with a user interface, which I sell to other lines of business, the Attribution does not apply. This is because I am selling the application in a closed market, i.e. other departments and lines of business within my organisation. However, if I build an application on top of Mule and I sell it for a license fee or sell support for my application to anyone (i.e. people outside my organisation), then the Attribution does apply. The only consumers that are affected by the Attribution are those that embed Mule in an application that they sell on an open market. These companies also have the option of obtaining a commercial license from MuleSource.
We are actively working to correct the wording of this Attribution. Attribution on the user interface doesn't make sense for many applications of Mule and I believe we can define a better Attribution that is clearer for Mule users.
Cheers,
Ross Mason
|
|
|
Message #225489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: MPL+Attribution
Andrew:
IANAL, but that's the meat of MPL+Attribution. As long as it's for internal consumption, you are free to use it at will...
The concept of distribution vs. internal use is a potential minefield, IMHO.
Consider the case of a distributing your program to a subsidiary of your own company. Is that considered "distribution" for the purposes of Exhibit B? You are transferring the program outside the legal entity in which it was created.
What if that subsidiary is not wholly owned by your company? Or worse, your company is a minority owner?
Hi Scott,
See my previous post regarding the scope of Attribution. I think we can also work on the wording of our Attribution to reduce most of the grey area.
Cheers,
Ross Mason
|
|
|
Message #225491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Hi Dan,
If you think of selling applications that embeds Mule in terms of two types of market it becomes easier to understand. If you are selling within you organisation then you are selling to a closed market and Attribution does not apply. If you are selling to outside organisations that are not part of your enterprise then you are selling to an open market and this is where Attribution applies. If you are selling in both closed and open markets then you need to address each distribution channel separately. Of course, you also have the option of a commercial/OEM license from MuleSource. I hope this clarifies the situation.
Cheers,
Ross Mason
|
|
|
Message #225493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule rocks
I don't say that often but Mule rocks!
Thanks Andreas!
Ahmm, can you please solve my Jira issue I posted several month ago? ;-)
We're on it now :)
|
|
|
Message #225495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: BPEL support
Hi Balazs,
It seems that the WS-BPEL component is provided by a 3rd party company, Intalio, with no published price for a proper production license.
The whole point of Mule is that it gives you the flexibility to pick and choose the components of your application. We do indeed partner with open source and proprietry vendors that we believe add a high level of value with their products, but we do not limit your choices to these vendors. If you want to use ActiveBPEL, or Oracle BPEL Process Manager you can. We've found that many of our customers have already invested significantly in middleware products such as Messaging, BPEL and App Server. We give them the possibilty to leverage this existing investment rather that force them to use our own suite of tools. This is what we mean by avoiding vendor lock-in.
Cheers,
Ross Mason
|
|
|
Message #225499
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Hi Mark,
Just to clarify, the Attribution only comes into play when you are embedding Mule in a commercial application that you intend to sell on an open market. For example, if I am a department in an investment bank and I have built a front office application with a user interface, which I sell to other lines of business, the Attribution does not apply. This is because I am selling the application in a closed market, i.e. other departments and lines of business within my organisation. However, if I build an application on top of Mule and I sell it for a license fee or sell support for my application to anyone (i.e. people outside my organisation), then the Attribution does apply. The only consumers that are affected by the Attribution are those that embed Mule in an application that they sell on an open market. These companies also have the option of obtaining a commercial license from MuleSource.
We are actively working to correct the wording of this Attribution. Attribution on the user interface doesn't make sense for many applications of Mule and I believe we can define a better Attribution that is clearer for Mule users.
Cheers,
Ross Mason
Thanks, Ross, that's useful.
But what if I sell an online service that is implemented with Mule in the backend? Does 'online service' == 'application'?
Who'd be a lawyer in this business, huh? (ok, form an orderly queue ;)
Kit
|
|
|
Message #225507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
a commercial application that you intend to sell on an open market
The MuleSource definition of commercial is very broad and has no concept of "non-commercial use":
"1.0.1. "Commercial Use" means distribution or otherwise making the Covered Code available to a third party"
So it's not just if "you intend to sell on an open market" any other open source project will have to display the adware. So all the projects that Mule builds on, such as the Prova Rule Engine, will no longer receive reciprocal rights. The question is, will other Open Source developers continue to upstream their stuff to Mule, or will they turn to more reciprocal licensed software, such as CeltiXfire.
Mark Proctor
JBoss Rules Project Lead
http://markproctor.blogspot.com/
|
|
|
Message #225515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: MPL+Attribution
Thank you, Ross!
Clarifying that will make the corporate lawyers much happier and make it possible for me to use Mule in my enterprise.
--Scott
|
|
|
Message #225519
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: BPEL support
Hi Balazs,
I forgot to address this point -
In addition to the unfortunate logo requirement, the actual price for the "per-year" subscription to remove the logo is not present on the web site.
The reason that there isn't a figure published for this is that we look a commercial licensing on a case by case basis. Sometimes the commercial vendor offers value to MuleSource or to the Mule project (by way of contributions) by embedding Mule in their product. This obviously affects how a commercial license is granted. So we can't just publish a one-price-fits-all cost. Also, we like to get to know a bit about the companies that embed Mule in commercial products since they often give us valuable feedback about Mule and how we can inprove it for their use cases.
Cheers,
Ross Mason
|
|
|
Message #225521
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Interesting article, but leaving some for the curious...
Interesting introductory article.
What makes me curious:
"Several open-source and commercial ESBs exist now. Each offers different features and caveats."
-- A (link to a) list with features and caveats for ESB products would be a great help.
"Mule is the best of breed open-source enterprise service bus."
-- Is this for the features, the lack of caveats, the quality of implementation, the support, ...?
Hi Rob,
The list of features and caveats is available from every ESB vendor and open-source project, and it would be too long and boring to cover it here. It can be summarized as follows:
- Commerical ESBs emphasize integration with their own product suites. Sonic, TIBCO, IBM follow this approach. From those, TIBCO plays very nice with third party software, commercial or open-source. Sonic ESB and IBM Websphere try to lock you in, and provide third-party adapters only from their partners (which tend to have another price tag).
- Open-source ESBs cover ServiceMix, OpenESB, and Mule. If you look at the feature sets on those, ServiceMix and OpenESB try to make JBI the center of the world. Mule is JBI compliant and, from an integrator's point of view, that's what you'd care the most if your application uses JBI. Mule towers over the others in the number of other adapters that it supports.
Mule being "best of breed" among open-source products is a subjective assessment based on:
* Out of the box, you can connect to more things with Mule than with ServiceMix or OpenESB combined. More things than most commercial products too.
* Support: both the open-source community around Mule and the guys from MuleSource have bent over backwards to assist users. I've seen this first hand and worked with all the vendors and communities behind the ESBs mentioned in the article.
* Quality of implementation: It Just Works. No lengthy discovery process. My guys got it talking to JMS and REST within minutes. Adding a new service provider or client takes seconds.
Mule's biggest "problem" at this time is the documentation. It takes an hour of reading and you may have to look at some of the API stuff to figure out what the configuration parameters in the mule-config.xml file should be before you can be productive with it; once you grok how it does things, though, it's as easy to deal with as any of the commercial applications and easier than most other open-source ESBs.
Cheers,
E
Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade:
The Tesla Testament
|
|
|
Message #225529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tibco BusinessWorks clarification
You mentioned that Tibco BW supports: SOAP, EMS, JMS, Rendezvous, MQ, BPEL. Actually it support much more ou-of-the-box: JDBC, FTP, POP3/SMTP/IMAP, HTTP(s), Flat files, LDAP, native .NET connectivity through COM. Additionally it suports all major application "protocols" like SAP, Oracle Apps, PeopleSoft, SWIFT, CICS etc.
Artur
|
|
|
Message #225553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
codehouse.. hmm
well, sounds good, nice article, but since it is a codehaus project i may have second thoughts. Codehaus does not have a good track on product documentation, and backwards compatibility issues. . of course, this is my experience.
|
|
|
Message #225565
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Hi Ross,
does the Attribution applies in the following scenario :
a project is outsourced to a SI as a turnkey development who decides to use Mule as the ESB for the project. It is thus a one off development, and the SI will not be re-selling the solution, and the customer will own the project. The grey area here is that the SI is not part of the customer's organisation.
Would appreciate if you could clarify the above. Thanks.
|
|
|
Message #225567
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Quite a layer of abstraction!
The answer is that the attribution does NOT apply in this scenario. The attribution is only applicable when you are selling a commercial application that runs on Mule, not when you are developing a system for internal use--which is how I would interpret the scenario described.
-Dave
MuleSource Team
|
|
|
Message #225570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a layer of abstraction!
The attribution is only applicable when you are selling a commercial application that runs on Mule
The MuleSource definition of commercial is very broad and has no concept of "non-commercial use":
"1.0.1. "Commercial Use" means distribution or otherwise making the Covered Code available to a third party"
So it's not just if "you intend to sell on an open market" any other open source project will have to display the adware.
While allowing open source projects to build on Mule without being impacted by the Attribution clause may be the intent, it is not written into the license in any form.
http://www.mulesource.com/MSPL/
|
|
|
Message #225574
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I can only assume you want to use Mule for your app
The weirdest thing about this whole thread is that I can't figure out what your point is. What's your suggestion?
You'll note from the previous posts that we said we were reviewing the license.
My guess is that your comment is because you want to use Mule in a commercial application?
|
|
|
Message #225580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I can only assume you want to use Mule for your app
The weirdest thing about this whole thread is that I can't figure out what your point is. What's your suggestion?
You'll note from the previous posts that we said we were reviewing the license.
My guess is that your comment is because you want to use Mule in a commercial application?
Or, possibly, just maybe, he is using another license himself and needs to validate his own decision ;-) "There can only be one License", ya know.
|
|
|
Message #225584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule: A Case Study
a, we are evaluating mule also, but this logo will reduce the chances now.. an OSS software is suposed to be free for distribution, modification and copy.. if the logo is really necessary, mule is not OSS.. a pitty because it seems fantastic ....
|
|
|
Message #225588
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Adware/Badgeware
Hi Mark,
So it's not just if "you intend to sell on an open market" any other open source project will have to display the adware. So all the projects that Mule builds on, such as the Prova Rule Engine, will no longer receive reciprocal rights. The question is, will other Open Source developers continue to upstream their stuff to Mule, or will they turn to more reciprocal licensed software, such as CeltiXfire.
Like I said in a previous post, we are currently working on improving the wording to make it crystal clear that we do differenciate between selling to an open market and a closed market and that open source projects can use Mule in the same way any other user can use Mule.
Having this discussion helps us cover the necessary scenarios, so thanks to everyone for their input.
Cheers,
Ross
|
|
|
Message #225598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule: A Case Study
a, we are evaluating mule also, but this logo will reduce the chances now.. an OSS software is suposed to be free for distribution, modification and copy.. if the logo is really necessary, mule is not OSS.. a pitty because it seems fantastic ....
Hi Felipe,
I believe I've made the situation and the intent of the license quite clear on this thread, but if you have any other questions, feel free to contact us directly. For almost all situations you are free to use Mule and we'll make sure in the coming weeks that this is abundantly clear in the license definition and on the website.
Cheers,
Ross Mason
|
|
|
Message #225599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: codehouse.. hmm
well, sounds good, nice article, but since it is a codehaus project i may have second thoughts. Codehaus does not have a good track on product documentation, and backwards compatibility issues. . of course, this is my experience.
Codehaus, like SourceForge doesn't the control the the projects it hosts. Hence, each project is independently managed by the project owner. I suggest you look at Mule for yourself. There is always room for improvement, but we have over 400 pages of documentation, our biggest issue is how to allow users to easily navigate through it all.
Cheers,
Ross Mason
|
|
|
Message #225643
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule: A Case Study
a, we are evaluating mule also, but this logo will reduce the chances now.. an OSS software is suposed to be free for distribution, modification and copy.. if the logo is really necessary, mule is not OSS.. a pitty because it seems fantastic ....
Hi Felipe,
I believe I've made the situation and the intent of the license quite clear on this thread, but if you have any other questions, feel free to contact us directly. For almost all situations you are free to use Mule and we'll make sure in the coming weeks that this is abundantly clear in the license definition and on the website.
Cheers,
Ross Mason
Is the intent for those those modifications to make the MuleSource License OSI compliant - which is necessary to correctly use the Open Source brand. The information I have observed so far indicates that the OSI are going to allow a non intrusive form of attribution, just not adware/badgeware.
Mark Proctor
JBoss Rules Project Lead
http://markproctor.blogspot.com/
|
|
|
Message #225646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Mule Case Study
The intent of the license review is to ensure that our users are potential users clearly understand the terms by which Mule is licensed.
It is possible that we will adopt the OSI attribution once it is decided. Until then Mark, we are happy to provide you with a license to use Mule in your project--I can't see why else you are so concerned.
|
|
|
Message #225655
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule Case Study
No it's ok, don't need a license - I don't use Mule or any other ESB. I'm just concerned on the current move to adware/badgeware licenses by VC backed companies and the harm this may do to the Open Source eco-system and the Open Source brand. What concerns me more is how it's purposefully glossed over or not mentioned at all, it's something I think end users should be aware off - this was what I was doing here. Obviously any company/person has the right to license their code as they feel fit, but when you use the Open Source brand there is a expected level of quality and assurnace, which I would not like to see watered down for marketting purposes. How about Shared Source?
Mark Proctor
JBoss Rules Project Lead
http://markproctor.blogspot.com/
|
|
|
Message #225657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This reminds...
Nothing personal, but you sound much like IBM on Sun GPL'ing Java. Any hidden agenda?
|
|
|
Message #225661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule Case Study
No it's ok, don't need a license - I don't use Mule or any other ESB. I'm just concerned on the current move to adware/badgeware licenses by VC backed companies and the harm this may do to the Open Source eco-system and the Open Source brand.
This reminds me of the ideological sophisms that RMS likes to engage in regarding Linux vs. GNU/Linux.
Maybe I glossed over some part of the Mule sites (including MuleSource.com) and missed something... but I don't see anything there using the Open Source(tm) brand.
Open-source is a well-understood term now. To the best of my knowledge the Open Source Initiative and its Open Source(tm) brand are a subset of the open-source ecology, not the other way around. There are plenty of open-source applications and entities that for whatever reason chose to not adopt the OSI branding. That doesn't diminish their value, nor reduce their "open-sourceness quotient".
So far nobody is arguing that the Open Source(tm) brand is being used here one way or another, and the Mule license is clear about what it allows and doesn't allow you to do. When in doubt, contact MuleSource and clarify the point. If you're still in doubt about what you can or cannot do, then hand the query to your IP attorney and let her deal with the issue and make a recommendation. So far the guys from Mule have been forthcoming about the license meanings and scope, in this and other forums.
Last, what exactly is the "damage" to the Open Source(tm) brand resulting from badgeware? That falls again into the realm of intellectual property. If a company produces something and they own the IP, they are free to license it in any way they see fit for meeting their objectives. As a user, I have the option to chose that product or any other, based on a number of factors that will influence my decision. If I plan on commercial distribution of an open-source product it's my choice to use whichever one meets MY objectives. At that point I either align myself with the original IP owner, negotiate a license, or use something else. It's all very simple.
Can we put the whole issue to bed yet, or are we going to continue the circular arguments for a few more iterations?
Cheers,
E
Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade:
The Tesla Testament
|
|
|
Message #225663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule Case Study
This reminds me of the ideological sophisms that RMS likes to engage in regarding Linux vs. GNU/Linux.
[...]
So far nobody is arguing that the Open Source(tm) brand is being used here one way or another, and the Mule license is clear about what it allows and doesn't allow you to do. When in doubt, contact MuleSource and clarify the point. If you're still in doubt about what you can or cannot do, then hand the query to your IP attorney and let her deal with the issue and make a recommendation. So far the guys from Mule have been forthcoming about the license meanings and scope, in this and other forums.
Amen. I attribute any further complaints in this thread about the license to muleheadedness (I couldn't resist).
|
|
|
Message #225674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Adware licenses are not open source
There is certainly an agenda going on. It is an agenda by a few small companies to expand the definition of open source to include adware. OSI is not a subset spliter group of open source, they ARE the group who coined the term. I have disagreements with the group (I'd like to contract the definition to be only open source licensed software that is developed OPENLY and I'd like OSI itself to be a bit less of a star chamber with their secret open source meetings), but to say that they are open source licensed when their license does not meet the open source definition certainly borders on fraud. I have no horse in the ESB business. However I and others do have a very vested interest in preserving open source (and the randomly capitalized [tm] thing is a straw man argument). I do not object to them licensing their software as they see fit. I object to their errant claim that it is open source as it is damaging to open source. Spin it how you like, their license doesn't meet the open source definition as defined by the people who coined the very term, they specifically know that their license is at the very least controversial, and yet they're trying to take advantage of an idea that a lot of people have worked hard to create for their own ends without paying their dues (keeping their code as part of the actual open source ecosystem that it builds on). I am most definitely NOT pandering for a free proprietary license for an ESB.
|
|
|
Message #225679
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule Case Study
Mark,
I had a chance to discuss this licensing issue with Bruce Perens a few minutes ago and I can understand your (and OSI's) point of view. From your perspective, the definition of Open Source and its implications, and the burdens of the badgeware make sense. I'm reading now additional information to better inform myself about OSI and related topics.
In our current context I still applaud MuleSource's willingness to work out a deal with value-added companies or entities going forward.
I didn't realize earlier how enlightening this debate really was. Thanks.
Cheers,
E
Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade:
The Tesla Testament
|
|
|
Message #225705
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MPL+Attribution will scare away many
MULE is really great, well architected, relatively easy to use, not based on the mantra that SOAP/JBI is the only way to solve all problems yet flexible anough to cater to that usage pattern. This really good article also highlights that it is relatively free of the lock-in that applies to other ESB's which is yet another important benefit.
In our company some smaller projects have worked successfully with MULE and others have worked with it experimentally to learn more -- all are impressed with it. Some serious work in the larger scale has been proposed and outline planned. However, since I discovered the adware clause in the new 1.3 license it has given me cause for serious concern and has generated serious concern in others, the extent of which is likely to be that further consideration of MULE may, very sadly, be ruled out.
This would be EXTREMELY unfortunate. The license in no way aligns with the statements elsewhere in this discussion that it only applies to selling commercial software in which mule is packaged, which is already very disconcerting. Additionally, the sudden license change demonstrates that the rug can be pulled out from under anyone's adoption of 'open source' that it is likely to send jitters back into larger enterprises which had recently come to have some level of comfort with open source. In addition, the 'commercial' license conditions on display at mulesource do not make clear the effect or duration of the removal of the attribution (e.g. is it only while you maintain a support contract with mulesource) nor do they make any guarantees that yet another license change will take place.
In our company we use open source widely, we contribute to some open source, we collaborate with the open source community and we avail of services provided by open source committers (e.g. consultancy, training, etc) -- we do not assume open source means a free lunch. In the case of MULE it is highly likely that we would have contracted service business from SymphonySoft/mulesource. I think many companies of reasonable size would do the same and it seems that many open source committers, like I21 and others, survive well on this model of producing a really good quality competitive product available freely without condition making money from providing services/training and collaborative deals with other IT providers.
In my opinion this adware clause is badly conceived, likely by accountants, and is likely to ultimately destroy mule as a product. I would strongly urge you to reconsider this almost strong arm approach and align your business model more closely with that of other very successful open source providers. It would be a significant pity to see such an excellent product as MULE sink due to badly conceived business decisions such as this.
Ken
|
|
|
Message #225713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Licensing and OSS--not that scary
We really do appreciate the feedback here despite the fact that much of it seems more malignant than helpful. One thing that's interesting from our side is that Mule seems to be viewed akin to a "framework", where we thought that people thought of it more as a "product." That helps drive the licensing thoughts going forward.
A few notes:
-The switch to the MPL+ for Mule was driven by the fact that there was no clear way for Ross/MuleSource to protect the intellectual property within the project under the BSD license. GPL is not an option for a vast majority of corporate Mule users.
-The BSD license was actually in conflict with some of the other components that Mule leverages within it's plugins etc. As such we needed to move to a license that met the requirements of all of the components working together. This is also important in that we can offer indemnification.
-You'll note that within these 53 comments we have said repeatedly that we are going to review the license. That work is beginning today. You'll also note that we have offered to provide people with our commercial license at no charge for their project or usage. In the time that you all wrote these comments you could have just emailed us for a license for your project.
Dave
MuleSource Team
|
|
|
Message #225734
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Licensing and OSS--not that scary
You'll also note that we have offered to provide people with our commercial license at no charge for their project or usage. In the time that you all wrote these comments you could have just emailed us for a license for your project.
Dave
MuleSource Team
None of the reasons you gave are a compelling reason that you must both offer your product under a non-open source license and call it open source.
However I have no interest in using your product. I have an interest in preserving the term "open source" as having SOME meaning. You are attempting to turn it into a "shared source" synonym and others are calling foul. Just don't pretend to call your software open source and there is no problem. Take Atlassian as an example. The source to JIRA is available to their customers and they contribute. You have chosen a slightly more open distribution model. This is fine.
The GPL vs BSD vs "our special adware license" is a "False dilemma" argument.
|
|
|
Message #225739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Then make a suggestion and stop complaining
To sit here and complain for the sake of complaining doesn't "preserve the term "open source". If you really wanted to help you would offer something productive. You think that anyone using MPL+ should switch to GPL? Fine. You think it should be BSD? Fine.
The source code to Mule has always been open, and will continue to be open and available. The license issue that has you so vexed (despite the fact that you aren't using it) will be addressed accordingly.
The interpretation of open source licensing has been a difficult process since day one. I fail to see how any of this has been helpful.
This thread hasn't been helpful for anything but driving web traffic.
|
|
|
Message #225740
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Then make a suggestion and stop complaining
I do not care whether you use GPL, BSD or any number of other licenses. I simply wish you would not advertise non open source software as open source.
If you are indeed adopting an open source license or dropping "open source" from your advertising then it has been very productive.
|
|
|
Message #225744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Licensing and OSS--not that scary
Thank you Dave for your response.
I have two points in this, though, that I would like to have some clarification on:
* How does the addition of attribution to the MPL license effect the indemnification you say was a driver given your use of 3rd party open source dependencies, especially when many other open source components do not find the same need ?
* I had intended seeking a commercial license at the appropriate time but my concern is that I am uncertain what this means and what it entitles me to. My understanding from your web site is that we need to take out a commercial support contract to obtain a commercial usage which removes the attribution clause but your comments here seem to imply otherwise. Would you kindly clarify.
As I expressed to Ross in an additional email on this I think the concept of MPL+Attribution is a badly conceived model that has the potential to cause damage to MULE and that such damage would be an extreme pity given the quality and uniqueness of what MULE offers. Making something essentially unusable to many enterprises, which with attribution according to the license wording has the effect of doing, is really a negative and unfortunately shortsighted approach to getting business (i.e. attracting users). I am glad to hear you guys are reconsidering this and I hope you resolve it in a way that makes it possible to adopt and helps drive your company to commercial success.
Ken
|
|
|
Message #225746
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
BPEL support
Intalio's BPEL Engine is "free" if used on Redhat I believe
Intalio has recently relicensed it's stuff and is also now MPL+Attribution.
To be clear, Intalio's whole BPMS (modeler, engine, etc.) is what's covered by the MPL+Attr. The BPEL engine itself is under incubation at Apache as "ODE", so that component is available under the APL2.0 with no strings whatsoever.
ODE project: http://cwiki.apache.org/ODExSITE/home.html
|
|
|
Message #225748
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About Intalio's Licensing Terms
Just for clarification, Intalio|BPMS Community Edition is licensed under the MPL+Attribution. Some components of the solution are available under Apache Software License (ASL) or Eclipse Public License (EPL). For example, our BPMN process modeler is available under EPL, and our BPEL process engine under ASL. For a more detailed overview of our Open Source work, please take a look at this page:
http://www.intalio.com/company/open-source/
Best regards
Ismael Ghalimi
CEO, Intalio
|
|
|
Message #225749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Subscriptions, not licenses
Just to clarify, what we sell is a support subscription. When you are a subscriber you get a license that allows you to use Mule in whatever way you want with no attribution. The open source license is the means by which the product is distributed. This would be the same as GPL or other license.
* Indemnification is related to the fact the BSD license is not in compliance with certain aspects of certain other licenses. As such we needed to move to something that was in compliance. GPL is not an option for Mule, so we chose MPL.
MPL unfortunately offers zero protection for our intellectual property, which the authors of the code were not comfortable with so we chose to add the attribution clause--just like SugarCRM, Zimbra, Alfresco and SocialText. I think the main issue is that the "image" type of attribution needs to be addressed.
* If you are an enterprise user--that is you are using Mule in your internal systems, not using it in a commercially sold software product, you don't have to attribute. We are working with the OSI attorney right now to make that clearer in the license.
* If you want support and the management tools you need a subscription.
We appreciate your help and questions. I fear that many of these comments are making people unnecessarily afraid of open source.
|
|
|
Message #225781
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Silly license
a) You don't allow trademarks to be used in any way, yet you demand that they be (ab)used all the time.
Beside being very silly, that's a good way to lose the trademark in court if you ever decide to take someone to court on the ground that they don't give you proper attribution.
b) Requiring display of a logo all the time does not work very well with accessibility requirements ... how does a user display your logo on Braille displays? If you make deployer chose between non-compliance with accessibility regulations and not using your code, many will have to chose not using your code.
c) A phone's display is barely larger than your logo, so your software can not be used for enterprise applications that (may) need to talk with that sort of devices (in the future).
d) Some governments increasingly require open source solutions. Your code can not be used in that circumstance.
e) Yeah, the major issue is the highly specific type of attribution you require, that does not work well in many settings.
Sorry that you're getting banged up with all the other almost-open-source projects, but what's made open source successful has been to preserve the rights granted to the users in the open source definition, rather than letting companies take a free ride on the back of the open source community by falsely labeling their products as open source, when they are not granting all the freedoms that are granted through the Open Source definition. The graphic clause you added to the MPL violates OSD #10, and in consequence OSD #5 and OSD #6.
FWIW, a simple way forward is to dual-license your code with the GPL, or any other license that's 'not an option' for your current user base. That way you've got your code under an OSI-certified license as an option for the (government) users that need open source(TM), and can expand into that market segment, without hurting your current user base for whom GPL is not an option.
|
|
|
Message #225797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: not OSI approved?
and why would it be a "recommended read"?
Asay's note is utterly biased, because SugarCRM/Alfresco is in the same boat with Mule w.r.t. the MPL+attribution case
here is what I call a recommended read instead: http://linuxgazette.net/134/moen.html
Why don't you bother to post under your real name? A recommendation from the 'well-intended anonymous' is surely a valued argument...
Your point is if you can't rip off because of a license, it's not OSS? Try that with GPL.
|
|
|
Message #225827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: not OSI approved?
Your point is if you can't rip off because of a license, it's not OSS? Try that with GPL.
It does bring up an interesting point -- the "attribution" licenses are incompatible with the GPL, so [theoretically] you cannot use one of these frameworks to build GPL-licensed software, because the result would have as a dependency a library that introduces restrictions that are in addition to what GPL permits.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #225954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Real Open Source and forkability puts the end user in control
The biggest problem is that Open Source implies certain assurances that puts the end-user, not the vendor, in control. It is assurances like this that have accelerated the adoption of Open Source by end users. This success is also why commercial companies want to hop on the Open Source bandwagon, it's great marketting, they get to imply their product has all those same assurances - it doesn't.
This is because if the Real Open Source vendor/community refuse to accept patches or implement features or go a particular direction for what ever reason the end-user is free to fork and create a new community - this is an extremely powerful mechanism to ensure the end-user has control, not the vendor. It means that vendors have to compete by offering the best services, writting the best software, building the best communities - or they can have the rug taken out from underneath them. Adware/Badware removes, in all practicalness, the ability to fork thus it puts the vendor back in control - this is antithesis to the way Open Source works, and what people expect from the brand. The vendor can't claim attribution protects their IP and that their stuff is forkable in the same sentence - the two are complete diametric opposites. Further to this when a company tweaks the license the first time to gain control and drive a bit more revenue, whats to stop them tweaking it a bit more in the future to drive a bit more revenue - after all the protection of their IP, due to adware attribution, ensures end-user lockin.
I will be blogging on this in more detail soon.
Mark Proctor
JBoss Rules
http://markproctor.blogspot.com/
|
|
|
Message #225988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Real Open Source and forkability puts the end user in contro
The biggest problem is that Open Source implies certain assurances that puts the end-user, not the vendor, in control. It is assurances like this that have accelerated the adoption of Open Source by end users. This success is also why commercial companies want to hop on the Open Source bandwagon, it's great marketting, they get to imply their product has all those same assurances - it doesn't.
This is because if the Real Open Source vendor/community refuse to accept patches or implement features or go a particular direction for what ever reason the end-user is free to fork and create a new community - this is an extremely powerful mechanism to ensure the end-user has control, not the vendor. It means that vendors have to compete by offering the best services, writting the best software, building the best communities - or they can have the rug taken out from underneath them. Adware/Badware removes, in all practicalness, the ability to fork thus it puts the vendor back in control - this is antithesis to the way Open Source works, and what people expect from the brand. The vendor can't claim attribution protects their IP and that their stuff is forkable in the same sentence - the two are complete diametric opposites. Further to this when a company tweaks the license the first time to gain control and drive a bit more revenue, whats to stop them tweaking it a bit more in the future to drive a bit more revenue - after all the protection of their IP, due to adware attribution, ensures end-user lockin.
Hi Mark,
Apart from repeating yourself, (those who want to see my previous responses please read from the top) I think you protest is misguided in this context. Mule is open source software. Companies can use Mule in their applications without attribution and are doing so in their hundreds if not thousands (we discover new people every week). 99.9% of these people are not in violation of the license. If they want to fork the code they can. However, many of them do not want to do this since they would rather work with the founders of the Mule project to assist moving the product forward and get help from us when they need it. We certainly can say we own the IP since I've always been strict on quality control for the project; no code gets in without going through a vetting process. This has worked well for Mule users since it ensures that not any old code gets put into the core of Mule.
The Attribution was put in place to stop unscrupulous software vendors from using the Mule project against its founders to their own gain. The Mule team are dedicated to keep up the quality and innovation that Mule is known for, so a little protection was needed.
As discussed above, we recognise that the Attribution clause needs to be better worded to ensure that our intentions are absolutely clear: those who want to use Mule in their enterprise applications or open source projects, or want to sell that application to a 'closed market' can do so without Attribution. We are working on getting this language corrected in the license at this very moment.
Cheers,
Ross Mason
|
|
|
Message #249227
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Mule Case Study Late question
Hi Eugene,
Thanks for the article, it seems like an adequate approach.
Two questions pop up:
- can the routing be changed without loosing messages? (Using an embedded tx manager seems a bit obscure to me)
- what are all the out queues for if all applications deliver messages to the outJMSBitco queue?
Rgrds,
Sanne
|
|
|
Message #328092
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Adware
I'm just concerned on the current move to adware/badgeware licenses by VC backed companies and the harm this may do to the Open Source eco-system and the Open Source brand. What concerns me more is how it's purposefully glossed over or not mentioned at all, it's something I think end users should be aware off - this was what I was doing here.
---------------
Phentermine blog
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
