Mule: A Case Study

Discussions

News: Mule: A Case Study

  1. Mule: A Case Study (70 messages)

    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 other’s characteristics.

    Threaded Messages (70)

  2. Greate Case Study.[ Go to top ]

    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
  3. Mule rocks[ Go to top ]

    I don't say that often but Mule rocks! Ahmm, can you please solve my Jira issue I posted several month ago? ;-) -- Andreas
  4. Adware/Badgeware[ Go to top ]

    "Mule and all its bundled subcomponents are licensed under a variation of the well-known Mozilla Public License 1." To clarify - that variation is known as the MPL+Attribution. Mule, along with a number of VC backed companies, has opted for the MPL+Attribution license: http://www.mulesource.com/MSPL/ That means anyone using Mule must diplay the Mule logo at 130x25pixels on each and every user screen of their application. This license type has since become known as Adware/Badgeware. For more information on Adware/Badgware see: http://www.nicholasgoodman.com/bt/blog/2006/11/15/open-source-has-a-little-secret-exhibit-b/ http://www.nicholasgoodman.com/bt/blog/2006/12/22/badgeware-ceo-to-community-buy-a-commercial-license/ http://blog.buni.org/blog/acoliver/opensource/2006/12/12/The-Buni-Special-Attribution-License-Proposal http://weblog.infoworld.com/openresource/archives/2007/01/roy_russo_on_op.html http://blog.buni.org/blog/acoliver/opensource/2007/01/15/Roy-Russo-wrong-on-so-called-badgeware
  5. BPEL support[ Go to top ]

    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.
  6. Re: BPEL support[ Go to top ]

    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-
  7. BPEL support[ Go to top ]

    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.
  8. Re: BPEL support[ Go to top ]

    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-
  9. BPEL support[ Go to top ]

    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
  10. About Intalio's Licensing Terms[ Go to top ]

    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
  11. Re: BPEL support[ Go to top ]

    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
  12. Re: BPEL support[ Go to top ]

    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
  13. Re: Adware/Badgeware[ Go to top ]

    "Mule and all its bundled subcomponents are licensed under a variation of the well-known Mozilla Public License 1."

    To clarify - that variation is known as the MPL+Attribution. Mule, along with a number of VC backed companies, has opted for the MPL+Attribution license:
    http://www.mulesource.com/MSPL/
    That means anyone using Mule must diplay the Mule logo at 130x25pixels on each and every user screen of their application. This license type has since become known as Adware/Badgeware.

    For more information on Adware/Badgware see:
    http://www.nicholasgoodman.com/bt/blog/2006/11/15/open-source-has-a-little-secret-exhibit-b/
    http://www.nicholasgoodman.com/bt/blog/2006/12/22/badgeware-ceo-to-community-buy-a-commercial-license/
    http://blog.buni.org/blog/acoliver/opensource/2006/12/12/The-Buni-Special-Attribution-License-Proposal
    http://weblog.infoworld.com/openresource/archives/2007/01/roy_russo_on_op.html
    http://blog.buni.org/blog/acoliver/opensource/2007/01/15/Roy-Russo-wrong-on-so-called-badgeware
    I assume you are still the project lead on JBoss Rules? ;-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  14. Re: Adware/Badgeware[ Go to top ]

    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-
  15. Re: Adware/Badgeware[ Go to top ]

    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 :)
  16. Re: Adware/Badgeware[ Go to top ]

    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-
  17. Re: Adware/Badgeware[ Go to top ]

    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."
  18. Re[ Go to top ]

    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.
  19. Re: Re[ Go to top ]

    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
  20. Re: MPL+Attribution[ Go to top ]

    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
  21. Re: MPL+Attribution[ Go to top ]

    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
  22. Re: MPL+Attribution[ Go to top ]

    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
  23. 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.
  24. Re: Adware/Badgeware[ Go to top ]

    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
  25. Re: Adware/Badgeware[ Go to top ]

    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
  26. Re: Adware/Badgeware[ Go to top ]

    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
  27. Re: Adware/Badgeware[ Go to top ]

    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/
  28. Re: Adware/Badgeware[ Go to top ]

    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
  29. Re: Adware/Badgeware[ Go to top ]

    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.
  30. Quite a layer of abstraction![ Go to top ]

    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
  31. Re: Quite a layer of abstraction![ Go to top ]

    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/
  32. 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?
  33. 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.
  34. Re: Mule rocks[ Go to top ]

    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 :)
  35. 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
  36. Dugg it.[ Go to top ]

    This is really a great article, even if I am biased :>
  37. Old wine, new bottles?[ Go to top ]

    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
  38. 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.
  39. 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
  40. 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
  41. Ah, thanks for the clarification! Cheers, E
  42. codehouse.. hmm[ Go to top ]

    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.
  43. Re: codehouse.. hmm[ Go to top ]

    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
  44. Mule Rocks[ Go to top ]

    We (Hyperic) love Mule and MuleSource In fact, we partnered with them on their monitoring and management capabilities - http://www.hyperic.com/news/releases/11_13_2006.html -John Mark
  45. Open ESB and JBoss ESB[ Go to top ]

    I am evaluating some tools for a new system, and recently we started to play with: Open ESB, from SUN: https://open-esb.dev.java.net/ JBoss ESB: http://labs.jboss.com/portal/jbossesb/ if you have better advices about thatm please let me know.
  46. Re: Mule: A Case Study[ Go to top ]

    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 ....
  47. Re: Mule: A Case Study[ Go to top ]

    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
  48. Re: Mule: A Case Study[ Go to top ]

    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/
  49. Mule Case Study[ Go to top ]

    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.
  50. Re: Mule Case Study[ Go to top ]

    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/
  51. This reminds...[ Go to top ]

    Nothing personal, but you sound much like IBM on Sun GPL'ing Java. Any hidden agenda?
  52. Re: Mule Case Study[ Go to top ]

    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
  53. Re: Mule Case Study[ Go to top ]

    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).
  54. 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.
  55. Re: Mule Case Study[ Go to top ]

    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
  56. 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
  57. Licensing and OSS--not that scary[ Go to top ]

    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
  58. not OSI approved?[ Go to top ]

    Matt on the subject (a recommended read) - http://weblog.infoworld.com/openresource/archives/2007/01/why_im_tired_of.html
  59. Matt on the subject (a recommended read) - http://weblog.infoworld.com/openresource/archives/2007/01/why_im_tired_of.html
    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
  60. 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.
  61. Re: not OSI approved?[ Go to top ]

    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
  62. 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/
  63. 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
  64. 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.
  65. 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.
  66. 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.
  67. 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
  68. Subscriptions, not licenses[ Go to top ]

    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.
  69. Silly license[ Go to top ]

    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.
  70. 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
  71. Adware[ Go to top ]

    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