Slashdot Mirror

← Back to Stories (view on slashdot.org)

Lutris Closes Enhydra Source

Posted by ryuzaki0 on from the slam dept.

Ron van Balen writes: "Lutris has retracted the open source Entreprise Enhydra product. The old version will remain open source, but the open source community will not get access to the new J2EE compliant product. The decision was made because Sun J2EE license requirements don't allow an open source release, Lutris says. Lutris also says it wil refocus its efforts to its commercial products and support the open source community at a lower priority. It seems there is one less commercially supported OSS project on the planet." Newsforge has an excellent piece on this as well which gets into the reasoning and details on this move.

8 of 180 comments (clear)

  1. Non J2EE App Servers legal? by djweis · · Score: 2, Interesting

    Are there different licenses for projects like Tomcat? Can you deploy them legally?

  2. Re:What is the future of the JBOSS project now? by drodver · · Score: 2, Interesting

    I think the issue is they can't get the nice logo's on the box by going Open Source with the current J2EE license.

    Don't care about being recognized by Sun? => Problem solved!

  3. Red Herring by chmod+u+s · · Score: 2, Interesting
    Lutris has been leaning commercially for a while. I think the licensing 'issue' is a red herring they've thrown out as an excuse to transition into a closed-source only product. A few months back when I was trying to get the open source version of enhydra, I couldn't find it. They buried it in their enhydra.com website and redirected enhydra.org to it. Everywhere I looked was a 'purchase' button.

    Anyhow, how can JBoss have an open source J2EE implementation ?(which is lightyears better, in my opinion) Maybe becasue they don't have so many suits trying to put a spin on the product in order to get it to sell.

    It really seems like Lutris is just trying to transition back to the closed source model because they can't sell an inferior, late J2EE application server when you can see what is 'really under the hood' - an almost J2EE 1.1 compliant application server. They are chasing JBoss' and others' tails on a prior standard even.

    I used enhydra 3.01 for a major project and it was/is quite good: scalable, robust and fault tolerant, but it seems to have been poisoned by commercial interest and delays in implementing J2EE.

  4. FEAR NOT! The problem is not with J2EE! by Anonymous Coward · · Score: 2, Interesting
    The problem here is not with the J2EE license, as some have claimed.

    The problem is that Enhydra is based on Sun's reference implementation of J2EE, not on a clean-room implementation like JBOSS. Sun's license for the reference implementation is the problem, not the J2EE license.

    OSS and J2EE work together.

  5. Ok, sort of a dumb question... by weslocke · · Score: 2, Interesting

    but since I'm not a Java developer it's sort of an "on the outside looking in" thing.

    Sun developed the J2EE SDK, and released it to developers with the licensing requirements (and whatnot) fully disclosed. Lutris then comes along later and is upset that Sun won't rewrite their licensing procedures and open source their language interface just to suit them?

    And the people here are actually upset about this?

    How is Sun the bad guy for not giving away the sourcecode to their product (when they've never had any intention of doing so) just because some other company (I imagine the 'Good Guy') thinks they should?

    --

    'Life is like a spoonful of Drain-O, it feels good on the way down but leaves you feeling hollow inside'
  6. Re:FEAR NOT! The problem is not with J2EE! by Anonymous Coward · · Score: 1, Interesting
    No, the Lutris EAS is not based on Sun reference implementation code at all, and that's not the core issue. In fact, Lutris went to significant lengths to find or provide clean-room (non-Sun) implementations of the APIs in the app server. Last time I looked at the codebase it was all non-Sun (except for the JNDI providers, maybe) or had been supplied by Sun with a permissive license (for example, the Servlet API came via Apache)

    The issue is simply that if you want to brand as "J2EE" you have to sign a license, then pass a test (which is A Good Thing, IMO - as a consumer, I like the brand protection). Part of the license you sign holds that your use of all the code you used to pass the test is brought under the control of that license. The SCSL license thereby prohibits the kind of code sharing and changing that is a hallmark of OSS.

    JBoss does redistribute Sun RI code without license - lots of it. Take a look! As far as I can tell, the JBoss community isn't concerning itself with their "customer's" future problem of being in violation of Sun copyrights, licenses and deployment restrictions.

  7. Why JBoss will succeed by Brummund · · Score: 2, Interesting

    1. It's an excellent implementation of J2EE

    2. The project has a really active (like in hyperactive :-) project leader/lead programmer, Marc Fleury.

    3. The expertise of the other main programmers on JBoss is impressive.

    4. The community is very active

    5. Now provides a "turn key" (if that's possible with J2EE :-) download with embedded Tomcat or Jetty.

    6. Extremely developer friendly with a working hot deployment (no crappy weblogic "compilers" etc. here ), quick to restart if you want to,
    and handles load fairly well.

    I've used JBoss for some time now and I'm very impressed. JBoss has been rock stable for me, and usable on both Linux and Windows. (The servers on my latest project use JBoss/Tomcat/Debian Potato/Blackdown JDK and it's running 24/7)

    Recommended! Check out http://www.jboss.org

  8. philosophical differences by sohp · · Score: 2, Interesting
    Enhydra first came to my attention almost a year ago when the company I was working for at the time was looking at JSP vs. XML for wireless and web presentation development. The folks at Lutris made no secret of their disdain for JSP and J2EE technology generally and their preference for their proprietary XML generating technology for web applications. There's an article about it at IBM's developerworks website at Objects, objects everywhere and another even more relevant one at JSP technology -- friend or foe?

    At this point, Lutris has too much ground to make up against the J2EE server leaders, and no one is jumping onto their proprietary XML binding bandwagon, so Enhydra needs a way to distinguish itself from other Java application servers to get attention. My own evaluation of Enhydra gave me serious reservations with its architecture, including some issues around its scalability. Pointing to Sun and crying foul over the J2EE licensing issues (and that's all it is: an spat over whether or not their product can have the official J2EE compliant label or not), is just poor form.