Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Almighty Buck

Lutris Closes Enhydra Source 180

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.
This discussion has been archived. No new comments can be posted.

Lutris Closes Enhydra Source

Comments Filter:
  • As indicated above, the reason for the closing of source is the J2EE license from Sun. All complaints should be addressed to Sun Microsystems [sun.com].
  • Sun refuses to open Java. No, the JCP is not open. Why at this stage Sun does not open up Java is beyond me. With Microsoft out of the Java community, I don't see ravenous, hostile competitors chomping at the bit to deform Java and destabilize Sun.

    They're only hurting themselves and developers with their idiotically stubborn unwillingness to get with the program.

    • You're right (Score:2, Insightful)

      by reynaert ( 264437 )
      If they would just hand over Java to some standards body, it would immediately be promoted from 'Sun technology' to 'Industry Standard'. How they can consider this a bad thing is beyond me.

      Oh, wait. If Java becomes a standard, people won't have to pay Sun anymore to be 'Java compliant'.

      • It's all about keeping some malicious organization like Microsoft from forking Java.
        If Sun loses the control over Java, along with all the compability test suites they reenforce, they can not prevent a fork from happening. And it will. Microsoft did it already once with their Java RNI implementation.
        And if Java was made GPL, it will be the worst thing of all, since all new Java objects would extend java.lang.Object and would need to be make GPL as well. No Corporate would accept that one.
    • They're only hurting themselves and developers with their idiotically stubborn unwillingness to get with the program.

      huh? Java has never been more popular. How exactly is sun hurting themselves by not making it open? Java is hurt far more by it's lack of performance and general bloat than by it's closed nature. You might be able to argue that the open source community could/would help increase the speed of the language, add features, fix bugs, etc, but I hardly think Sun is being hurt by not opening it. Let's face it, along with most Microsoft products, if you have to use Java, then you have to use Java. Generally you don't have the luxury of choosing another language/product based on it's open source nature; however, dammit, I am using Postgres and Linux!!!!

  • I know about Kaffe, but I just checked www.kaffe.org and it hasn't been updated for over a year. Why has it died? Legal reasons? Lack of interest?

    Japhar is another implementation, but it is in a very early stage (current version 0.10).

    Do other implementations exist?
    • Kaffe isn't dead, it continues to be maintained and extended as part of PocketLinux. Unfortunately the kaffe.org sote fails to mention this.
    • Kaffe is jdk 1.1 implementation. Sun added a lot of stuf in jdk 1.2, 1.3 and now 1.4. It will take a very long while for any body to catch up.

      The only other choice out there is IBM's implementation, called Cross Platform Toolkit. But even them are licensing some core classes from Sun.
    • ORP [sourceforge.net] is a research Java VM from Intel with fast JITs and GCs. It's not usable for real work, though.
    • I know about Kaffe, but I just checked www.kaffe.org and it hasn't been updated for over a year. Why has it died?

      Perhaps it has something to do with Microsoft's "investment" [wired.com] two years ago in the company that made Kaffe. That certainly wouldn't be the first time that a company with non-Windows products mysteriously stagnated after a cash infusion by Microsoft.

    • gcj (Score:2, Offtopic)

      by codealot ( 140672 )

      gcj [gnu.org] 3.0 implements a great deal of 1.2. It's lacking AWT/Swing and RMI. The latter will be in 3.1.

  • Are there different licenses for projects like Tomcat? Can you deploy them legally?
    • Tomcat uses an Apache license. Yes you can deploy them legally. You can even download the source code, modify it and redeploy it.
    • I don't think Tomcat counts, because it is just a servlet engine, and does not rely on any bundled Sun products to run, other than the runtime environment.
    • j2EE is just a spec and a trademark. You don't have to agree to Sun's license if you don't claim to be J2EE compliant.

    • my question is now without a EJB J2EE server, what does enhydra bring to the table?

      if i wanted to use a system that separated church (presentation) and state (coding) i'd go with Apache Jakarta's Cocoon XML based server. It's basically takes the concept of JSP, uses XML instead of HTML, and does not allow you to put code into the page.
      from what i could tell from a curory reading, this is similar to the Enhydra XMLC component does - reads in your HTML, finds tags and creates stub java code for it. sorta the reverse of JSP - creating code from HTML, instead of inserting or calling code from your .JSP ...

      which is better? i would imagine it depends on your shop's bent - if you're more a bunch of Web Monkeys er... HTML coders, then you could just code up the page, and give it over to your java monkeys who could then use Enhydra to XMLC the html to get stubs of code to fill in.

      on the other hand, you could have your two monkeys actually work together and plan and design out the system, and then use standard JSP or even Cocoon to work together to create JSP or XSP (cocoon) files which have all the pretty graphix and onMouseover javascripted stuff you want.

      i dunno, i suppose enhydra is now yet another way of doing the job.

      but on the other hand, it has nice pretty screens to manage the server... maybe someone on the Jakarta project teams can steal er... use that concept in their open stuff. cuz we all know that Apache needs a bit more GUI management for us to really sell its use in the Enterprise.

      spike

  • If what Lutris is saying is true, will the JBOSS project be able to continue? They are shipping an open source J2EE project now..
  • For lots of projects, XMLC is good enough. Let's keep using the open source part, and avoid J2EE when we don't have to. This is the kind of message we need to give back to Sun.
  • by Svartalf ( 2997 ) on Monday September 17, 2001 @11:40AM (#2309599) Homepage
    This tidbit ran sometime last week on LinuxToday- and the title they're closing the source to Enhydra's misleading; it's Enterprise Enhydra that they're closing the source to, not Enhydra itself.
  • by rassie ( 452841 )
    It's sad that a developers choice of language/tools can make him lose control over his own licensing policy.

    Send your complaints to Sun. We have seen the same with eg. Microsofts Mobile something developers kit, and it is very sad.
  • The policies governing Java technologies never blended well with open source/free software. Given recent events, we should not expect Java to become more open, on the contrary.

    Law enforcement agencies will probably demand closed-source, backdoor-enabled encryption and security subsystems. Open source doesn't lend itself to that.

    What is also a problem, is the fact that free software yields incredible consumer surpluses, but very little in terms of company profits. Since the government needs companies to make profits, so that they can levy taxes, they will not encourage free software.

    The most dangerous assault will, however, come from the copyright cartels. They will not rest until computers fully implement digital rights management in unalterable binary-only distributions, with source code locked up.

    In this light, It will become increasingly difficult to defend the values behind free software.
    • What is also a problem, is the fact that free software yields incredible consumer surpluses, but very little in terms of company profits. Since the government needs companies to make profits, so that they can levy taxes, they will not encourage free software.

      Damn, this is pretty shortsighted thinking. Does it not seem that companies that have more money can either SPEND IT ON OTHER THINGS BESIDES SOFTWARE LICENSING or PAY THEIR EMPLOYEES MORE or HIRE MORE PEOPLE? Less money on licensing (using more open source stuff) means more money leftover to spend on other things - tangible goods that help manufacturing and distribution companies - companies that hire REAL PEOPLE.

      The government doesn't tax profits (well, yes they do). Primarily, what the government taxes is TRANSACTIONS. Me holding on to 1000 dollars does NO good in terms of taxation. Me SPENDING 1000 dollars in various places incurs a sales tax on every transaction.

      Maybe more companies would make more profits if they didn't SPEND so much on closed source, proprietary software.

      To turn your argument around: Big deal if a few OS companies don't make much profit on their software - if thousands of other companies can realize PROFIT faster because of reduced costs, that means MORE taxes from those profits.

      Again, I don't subscribe to the notion that taxing profits is that big a revenue stream for governments. It's transactions that count.
  • Why use Enhydra? (Score:4, Informative)

    by elefantstn ( 195873 ) on Monday September 17, 2001 @11:44AM (#2309626)

    I'm not sure why someone looking for a J2EE implementation would go to Enhydra. JBoss [jboss.org] is a much better, robust, mature platform for that sort of thing than Enhydra. None of this is to say that Enhydra is worthless - it's very good at what it does, which is a much more lightweight Java web platform than DB + EJB + Servlets + the kitchen sink which is what full J2EE servers are. In fact, most projects would be better off with the lighter-weight Enhydra, especially published-content type projects.


    I guess what I'm trying to get at is Lutris should have kept Enhydra the way it was, and not screwed around with J2EE. We have JBoss for that, and Enhydra filled a much different need. The whole mess could have been avoided.

    • I completely agree that J2EE is a big stinkin' mess, but it's what managers want and are willing to pay big $$ for. WebLogic licenses run over $10k per CPU, and I'm sure Lutris smells some of that cash. Sure, they could continue to sell a superior product, but if it's a product that no one wants to buy, what's the point? You've got to listen to your customers.
    • so how does (or doesn't) this affect jboss. when i first read the original /. article, the first thing i thought was "what a crock" given the jboss model.
    • When I played around with Enhydra some time ago, the only really nice thing was the polished, web-based administration console. Hopefully, JBoss will come up with something like that soon.
  • An Alternative (Score:2, Informative)

    by robbyjo ( 315601 )

    SourceForge [sf.net] has nice projects: Open Business [sourceforge.net] or Enigma [sourceforge.net] for J2EE business software. It is still far from finish, but at least you can help to make it happen.

  • Are there supposed to be stories there? All I get is the fluff around the edges and links to the previous and next stories (which are also empty).

  • Does anyone remember the beginnings of InstantDB and the Enhydra project? When I originally picked it up, the buzz (and the statements on their webpages) was that its not Open Source yet, but "it will be Real Soon Now (tm)".

    After embedding it in my application, I needed to make a couple of changes and went to look for the source, and there was no more talk of 'open source' but rather 'Low deployment license fees'.

    Is this somehow related to the J2EE problem (how? its just a SQL db)? Was there another announcement I missed? Or did Lutris excercise their legally allowable but ethically questionable right to say "Its not open source now, we need $$, this is now a product."?

    If its the latter, then it makes one wonder how hard they negotiated with Sun.

    Zipwow
  • I am interested in porting the Web Start product to FreeBSD. However the legal requirements are unclear to me.

    I would really love to roll a distribution, like the Blackdown group did with Java3D for Linux, but I don't know how to get the OK from Sun.

    What is required? The present solution I see is leaving the user to sign the Sun's Communite Source License [sun.com] himself, and just offering a source patch set. For application a blessed binary release would be much nicer.

    Again, is anyone from the Blackdown guys here, how could explain what is needed?

    Regards,
    Marc

  • Red Herring (Score:2, Interesting)

    by chmod u+s ( 211367 )
    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.

    • I think you are halfright.

      They simple discovered the fact that now they can't just get loads of VC cash but must actually pay for themselfs and must have a income.
    • 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
  • Remember MySQL's old documentation, where it poo-pooh'ed the whole concept of transactions, which they didn't implement at the time? That which they couldn't or wouldn't implement, they trashed with FUD. I read something similar from Lutris [enhydra.org] in their "making waves" column that basically trashes J2EE for being, from what I can decipher from the article, an overall platform name and version for several technologies. The gist seems to be that the name J2EE has so much marketing power that you can no longer use the single pieces of it you need in your application and discard the rest, simply because in order to be branded J2EE, you have to (gasp) comply with the spec. And of course, since the spec is versioned, then well, the little guys can't keep up, so this is Sun's ploy to squeeze them out.

    I suppose this confusion is normal when his application happens to be a J2EE app server, but it's utterly absurd and wrong to say that an application running on a J2EE app server is somehow forced into a monolithic API. It sounds like Lutris is just facing the fact that they started with an app server that was not J2EE then went on a crash program to make it so, and are running into a shortage of manpower. So to compensate, they are including the code from Sun's own J2EE reference implementation.

    No, I'm not a fan of Sun's closed and expensive testing process, but Lutris's argument isn't about that, and it simply doesn't hold any water. Lutris is using Sun's code, not just their specs, and they are griping that they can't sublicense it however they wish. They might have been better off pulling a Zope instead, and just building on their existing app server and damn the J*-acronyms from Sun. Enhydra was damn functional, but as far as front-ends go, they have a lot of catching up to do with Zope.
    • Nope - the Lutris enterprise app server doesn't use Sun RI code. Take a look at the codebase, it was open source until fairly recently.

      The "monolithic" aspect is that if you use a branded J2EE platform you get all the APIs, of the specified version. Agreed you don't have to use all the APIs; your app can be portable to non-J2EE platforms, but the platform has to carry them, and in exactly those API levels. So you can't (legally) have an EJB 1.1 container and a Servlet 2.3 container, for instance - they belong to different monoliths. If you mix those, your platform isn't "J2EE." Thus your app can't call Servlet 2.3 APIs on a J2EE 1.2 platform. Simple as that.

  • I love this quote from Sun's PR flak:
    ...we are far closer to the Open Source community than someone like Microsoft and, dare I say, IBM.


    1: Sun is closer to Open Source than Microsoft is: It is equally true that Seattle, WA is closer to Mexico than Vancouver, BC is. That doesn't mean they're actually close.

    2: IBM: What a load of Lamborghini exhaust! With IBM, you know exactly where you stand. This is Open, that is Closed. Period. There's no lawyer-speak, snake-in-the-grass, hidden-gotcha licence like Sun Community Source License to worry about.
    • Lemme see:

      Full open source projects:

      OpenOffice [openoffice.org]

      Netbeans [netbeans.org]

      Tomcat [apache.org] (The source was gifted from Sun)

      NFS (gifted to the Linux community)

      They also have source that free for research and internal use at:

      http://www.sun.com/software/communitysource/index. html [sun.com]

      They also have given financial and programming support to:

      Gnome [gnome.org]

      Mozilla [mozilla.org]

      And I'm just scratching the surface! And for the record, Lutris was perfectly able to create a fully open source, J2EE branded server. The catch 22 was that they couldn't open source Sun's code so they would have to write their own. Did they? No.

      Geez, you people could at least TRY to understand the issue before shooting off at the mouth.

      Disclaimer: This post does not meet established Slashdot doctrine. Go ahead, mod me down. I dare you. Be a censor just like the news media. The truth? You can't handle the truth!
  • When MS' licence agreement doesn't allow Open Source programs to be developed with it, the world is coming to an end. When Sun's License agreement doesn't allow it, it's just matter of fact. Why the difference in views? Is Sun magically immune from all of the flames that MS gets?
  • by Anonymous Coward
    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.

    • You are in error. JBOSS makes extensive illegal use of Sun code. In JBoss 2.4, uploaded on Monday, Sept 10th 2001, I see: Sun's JAAS is in JBOSS, supplied under under the internal-use only BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JNDI is in JBOSS, jndi.jar in client package, ver 1.2.1), also released under BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JavaMail 1.2, released under internal-use BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") Sun's JAF, released under internal-use BCL, which is the non-deployment license ("use the binary form of the Software for the sole purpose of designing, developing and testing...") thanks, keith
      • Hi Keith
        You are in error. When you have a close look at all the used binary archives used in JBoss you will figure out that you can use it to distribute with you program as long as you don't change it, don't replace software in this archive and some other legal stuff.
        Therefore JBoss does not violate the license for the bundled archives.
        Have a nice day - Andy
    • by Anonymous Coward
      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.

      • If JBoss is merely taking the existing Sun implementation and packaging it with their software is this a problem? I mean, the SCSL and all that applies to MODIFYING their code, right? To quote the license:


        2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions), Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.


        I grabbed this section of the license from Sun's JNDI license. It seems that as long as you use their code as is you may simply redistribute their binaries which is what appears to be happening with JBoss. JBoss has lots of code that wraps these various packages and ties them all together, but as long as they are not actually modifiying Sun's code then they SHOULD be in the clear.
        • No, SCSL isn't about restricting code modifications; it's about restrivting the use the code is put to, and who gets to do it.

          The license to redistibute seems to require that you impose the same license on those to whom you redistribute, right? (See section 2(iv) as cited). Now go back to that same supplemental license, Section 1, and look at what rights you (or those to whom you redistribute) have with respect to actual use:

          1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software for the sole purpose of designing, developing and testing your Java applets and applications ("Programs").

          This says to me that you can use Sun code to help you build your programs, but not to deploy them. And that restriction is transitively applied.

          The primary license Section 1 grants you the right to "internal use" only.

          So as I (no lawyer) read it, when JBoss et al redistributes Sun RI code in their codebase, they restrict the codebase they supply to being used only for developer support purposes. When I as a user adopt the JBoss codebase, I accept the possibility that the license owner (Sun) may come and demand I stop using the code in deployed production use.

          • Hi
            You forgot to read the intro on the extension which says that it supersede the previous part if they conflict.
            Therefore JBoss does not violate (because I am not a layer (also) I can be wrong, of course).
            Have a nice day - Andy
            • I don't see the escape ... first, there isn't a conflict (only an extension), but even if there was then the superceding supplemental license is pretty clear about your right to use being limited to internal, development support.

              I'm not saying JBoss organization violates a license by redistributing the binaries of the Sun code; I'm saying the code so redistributed apparently cannot be used in production/deployment.

              • This part is from the "JAF" lisence:

                These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software.
                1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs").
                2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

                Doesn't the part 2 tell that you can re-distribute the software and can be used in conjunction with your programs (and only with them).

                • No, Section 2 of the BCL doesn't say that at all (to me).

                  When Section 2, part (iv) says you can only redistribute "subject to a license ... consistent with the terms in this Agreement..." I take that to mean that the BCL applies to each receiver of the software. When you pass on the Software, you pass on the license, in total.

                  And Section 1 says "use internally ... for the sole purpose" of developer support. This applies to any use of the software, whether you get it direct from Sun or by FedEx from an Open Source pure-hearted goodnik. The point isn't the redistribution as such, it is the limitation on the use, a limitation which I am concerned many users of open source software may not know about.

  • 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?
  • This is the exact reason that I do not use Java anymore. The Sun Community Source License (SCSL) is a farce. Is it *really* open-source? Not in my opinion. It could be closed at anytime, anyplace, without notice, leaving the community behind. It definitely *not* GPL compatible(see http://www.gnu.org/licenses/license-list.html#GPLI ncompatibleLicenses), so it is not promoting software freedom. So, why does not Sun leave Java as proprietary and closed-source? It is a hell of a lot better than upsetting a bunch of dedicated developers. If the "next big thing" is web services, Java does not have to be the only alternative to Microsoft .NET. There are others out there....
    • Who said SCSL was an open source license? Very little about Java is open source. It's effectively a proprietary Sun technology, notwithstanding IBM JDK and so on... Not that this is such a bad thing. There's something to be said for having a powerful vendor behind the technology, helping to make it useful and widespread. Java has become better supported by the industry than Perl, even though Java is only half as old. Cheers!
  • Lutris is using the license of the new J2EE draft as an excuse to close the OS initiative on the Enhydra project. The fact is, that license is only a DRAFT and not DEFINITIVE. Older J2EE especifications have different and more permisive licenses, it may be to prevent implementations on a not-yet-approved spec.

    Even if this was true, Lutris hasn't ever tried to solve the problem. The attitude of "well, we aren't gonna keep on this, but it's not our fault, blame Sun" is not very clean.

    If I had contributed to the OS part of a product that is now going to be closed up by Lutris, I would just be pissed.
  • by szcx ( 81006 )
    Boneheaded, opportunistic comment of the day [salon.com]. Last week Jerry Falwell blamed the WTC attack on the ACLU, feminists, and gays. Here's what ESR has to say about it;

    Raymond, the libertarian open-source guru, known for his love of firearms, suggested that if the passengers of the hijacked jets had had guns the four-plane tragedy might have been prevented: "We have learned today that trying to keep civilian weapons out of airplanes and other areas vulnerable to terrorist attack is not the answer either -- indeed, it is arguable that the lawmakers who disarmed all the non-terrorists on those four airplanes, leaving them no chance to stop the hijackers, bear part of the moral responsibility for this catastrophe."
    The story about this took less than five minutes to be rejected by the editors. Apparently when your stock is circling the drain, a member of the Board of Directors saying something like that isn't something you necessarily want publicised.

    Think air rage is bad now? Try arming those drunk businessmen and see what happens.

    • For a community which talks about freedom and openness, it amazes me to what level it will go to to stifle speech which is not favorable to it's cause.

      This article may have been Offtopic, but it's important to learn about these things.

      I'm glad I was browsing at -1 today.

  • I worked for Lutris not too long ago, in
    their Enhydra side (they also have a service
    oriented side to their business - building commercial websites etc)
    They were excited about the use of Open Source, but
    I could tell then that they didn't fully understand it, and they had troubles figuring out how to keep an open source Enhydra, even though they truly meant to keep it open source. The J2EE issue was the biggest obstacle they faced, but they never thought they would have to give up open source. I worked for a guy there that used to work for Sun, and had even worked on the Java language, so he knew what kind of a company Sun is... and it just turns out that they even if they made a J2EE product thats fully J2EE compliant, they wouldn't
    be able to market it as such without an expensive license from Sun, and that was a big difficulty they were having. Now the J2EE problem appears to have "resolved" itself by elliminating the open source side of Enhydra, which is SAD!!!! But, like I said, they seemed to have a mildly slippery grasp of what open source is about.

    Lutris is also having financial problems (who isnt?) which is another sad thing. They are a great company. It's sad that they had to give up the open source Enhydra.
  • I have worked with Lutris in the past with both Enhydra (version 2.3-3.0 and spec'd migration to the J2EE framework in enterprise) and there is more to all of this than just licenses from Sun and the J2EE framework. Don't get me wrong, what has been pointed out previously about the reference implementation and redeployment with different license terms would be an issue, but its more of a business trying to remain afloat.

    Lutris was a consulting services company to start with. Enhydra was developed by bringing together a lot of what they used to develop and deploy customer web applications in previous projects. Since they were a consulting services company first, an open source process served to both (marginally) push forward the development of the applications server with public support, but also create a low barrier to adoption for companies to get the services process in the door. I was a software director at one of those companies that adopted the process and then moved to bring in the consulting side to deploy a very large application on.

    Things were going great there when the economy was going great -- consulting services paid all the bills for the engineering crew to continue the primary development of the app server. The problem is when the economy turned south, the first thing to be cut were the consulting groups. Lutris had their contracts drying up and couldn't continue to pay the bills that way. Pretty soon they were left with a model that wouldn't work in an economy without a lot of free cash. There had to be another way to generate revenue or to go out of business. That model had to concentrate on traditional software development and open source companies haven't weathered that storm very well when there were commercial or other products that had more functionality or more entrenched customer bases. The quickest way to catch up was to push the enhydra enterprise process, use as much as possible to get it to a finished state (Sun ref implementation) and try to pull in product revenue with traditional sales. This couldn't be rectified with the open source licenses they were previously working on.

    It's economics. Sure Sun's license for using their implementation of things is going to effect that, but its an after the fact reason. The underlying problem is that a consulting services company with no contracts isn't going to stay in business... A software company at least has a fighting chance.

    I had friends that work(ed) there and this is not necessarily what they wanted out of things, but the survival instinct can be a powerful one. Has the discovery channel taught us nothing?

    • Just to reinforce LeeZard's commments on Lutris' financial problems.

      I live here in Santa Cruz, and know a lot of people who used to work for Lutris and are now looking for work.

      It was only a year ago that Lutris was in the middle of a hiring frenzy. I knew many people who had just started working for Lutris and many others who were interviewing there. Most of these are engineers (I don't know a whole lot of people who aren't engineers). Consulting companies that did a lot of work with Lutris, like Giavaneers, were also in a great position.

      These days, all of my buddies who were new Lutris hires are out looking for jobs, and many of the old guard at Lutris are also out. This isn't to say that Lutris axed most of their work force: many of the people who I know still work for Lutris, but its a much smaller number than it was 6 months back.

      The economy slump has hit Santa Cruz tech businesses hard, and those businesses who were hiring rapidly a year ago seem to be the hardest hit of all.
    • More than anything, the anger from their customers is due to the fact that they wouldn't say this outright. They make the decision to go closed source, fine. That is their decision to make and one I can respect. But don't blame Sun for that. Sun has very open licensing procedures and really does try to work with their licencees.

      Asking Sun to hand over control of source that they developed is extreme and is not a good excuse under any circumstances. End of story.
  • With things like Resin (very fast servlet runner), Tomcat, jboss, Jonas, and OpenEJB, why would we care about Enhydra? It was always kind of a bizarre product anyway, with one of the lamest templating languages I've seen. Open source Java is alive and well.
  • I'd go for Zope... has the better feelgood factor.

  • I don't think the issue is Lutris. Lutris probably tried to get the license and failed; after all, they'd be in a much better position if they were open-source and J2EE; that would be a completely unique market position. Per Sun, if you read the J2EE spec, you agree to do nothing unless you license J2EE from them. SCSL is the only J2EE license, and Sun won't let you sign it unless they're sure your open-source (good) won't conflict with theirs (bad). Sun is the only game in town because to interoperate with them, you've got to use their API's, under license. Get the gospel? With the JCP, they lock up all the priests. So we're back to the cathedral, with Sun in charge of gospel and clergy alike. Sun squelches competition in enterprise Java software by reaching backwards with the JCP process and viral licenses that require more licensing to deploy and forwards with SCSL's trademark-based scheme (can't deploy without the trademark; need the license to get the trademark). You want viral? Check out the J2EE spec license, JAXP 1.1, heck, even JavaHelp - they all say you can't implement javax.* namespace without getting a license from Sun. The only exceptions are the special Apache licenses which are designed to get us all onto java based two-tier systems. But Sun would not let lutris do this. Why? My bet is that Lutris had the open-source BUSINESS MODEL of giving it away and making money off services and add-on's. That goes completely against Sun's license-based scheme for using app-server vendors to reach into the pockets of developers. I doubt any vendor with netscape's razors-and-blades model would get a license from Sun, because that would hurt Sun and the other licensees too much. Sun prefers value to be in IP that can be licensed (and contained); they can't reasonable reach into services and other revenues. Licensing law is worse that copyright and patent in this regard; at least for those, there are objective standards. Here, Sun can impose any standard it wishes in its "licenses", even if the only thing it's licensing is the opportunity to play the game. At least when MS was setting de facto standards, they had the burden of delivering a quality implementation that beat the others in the marketplace first.
    • I love the internet. It's the best medium ever invnted for those who knwo nothing to inform those who know less.

      For the record, your logical chain breaks down in about the third sentance...

      " SCSL is the only J2EE license,"

      SCSL is the only open and freely available license. SCSL has nothing to do with the J2EE license, or for that matter even the license to create and destribute a VM.

      SCSL exists because a lot of us asked for a view into the java source for two reasons:
      (1) As additional documentation.
      (2) To assist in bug fixing.

      SCSL allows for both of these admirably.

      • "It's the best medium ever invnted for those who knwo nothing to inform those who know less" Every J2EE vendor - BEA, et al - has signed some variant of SCSL as applied to the J2EE technology. Ask Sun if there are any alternatives.
        • Great assertion, proof please?

          noone has yet shown anything that requires a J2EE licensee to be a SCSL licensee. There is nothing to my knwoeldge in the J2EE license agreement that requires you be a SCSl signee. if you have soemthing, please quote it.

          In order to get J2EE licensed AFAIK all you need do is sign the J2EE agreement and pass the appropriate TCKs. The "alternative" is simple. The J2EE spec is public. Build your own from-scratch implementation based on the spec.

          BUt if you want to use SUn's code then you need to license that code from Sun and Sun doesn't pretned that such code is open source.

          >>> IMO WARNING --- CHARGED OPINION BELOW

          This coming down to the same old "open source community" bullying/whining trying to force OTHERS to give away their stuff.

          Real open sourcers give away their OWN stuff, they don't bitch and moan tryign to force others to do it for them.

          Want to be open source, then write some open source code.
  • I would really like to see an actual explaination of how the J2EE license prevents then for going open source on their code. Particualrly intersting to note is that Sun itself donated an open source app server to Apache ("Tomcat").

    IMO Enhydra has decided that they can't make money in an open source model and are tyring to blame Sun in order to avoid the PR backlash.
    • SCSL prohibits you from distributing covered code to anyone who is not a SCSL licensee, and "distributing" includes even having an open cvs repository. That means everyone in your "open source" community has to be a SCSL licensee - which sounds doable, until you realize that SCSL licensees agree not to deploy except compliant covered code - i.e., tested and certified. So you can be open source, but you can't build and run it. I certainly would not contribute to a project where I couldn't use what I contributed. So then should Lutris have given away compliant covered code, only publishing what's tested? So I guess you're right, if Lutris published code that had been tested and certified and people agreed to SCSL terms and all the code was available to anyone who'd signed SCSL - I guess that's possible. But it's not compatible with the Mozilla license that it was under. As for Tomcat, it's hardly an app server, though 4.0 has some way cool stuff in it. To equate them is to ignore the difference in engineering effort between tomcat and the multi-thousand-dollar app servers. jBoss has a huge number of good developers, and the quality is still not commercial grade by any means. Don't get me wrong. Lutris may be using this to cover their retreat, but that doesn't mean they weren't forced into it or that Sun is using SCSL/JCP as a way of containing the open source movement as applied to Java.
      • Two problems:

        (1) SCSL is NOT the J2EE license agreement. You are talking about fundementally different things. I've seen that error all ove this board.

        (2) SCSL only covers code written by Sun. SO what you are tellign me is that Enhydra is complaining that they can't give away someone ELSES code? Pardon me for having no sympathy.....

        Maybe they should write their OWN code so they cna give it away.

  • by sohp ( 22984 )
    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 [ibm.com] and another even more relevant one at JSP technology -- friend or foe? [ibm.com]

    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.

  • Does anyone know of any reviews of the current leading open source platforms?
    The only link I could source the explicitly mentions JBoss is CSIRO Australia report [csiro.au].
    Suggestions?
  • Probably the only application server you can have up and running in 2 minutes. Plus since its all python based, you can get tracebacks and debug the thing live. Lots of cool new method-specific caching features all built in. DAs for lots of different DBs, transactions etc. Solid community. Check it out! [zope.org] Ya might like it.
  • Lutris used Sun's reference implementation, hence the problems... couldn't they switch in an open source impl of that component (e.g. JBoss's) for an OS release?
  • BS like this only flies because people who know nothing shoot off their mouths like they do, and others belive them because its easier then doing your own research.

    The SCSL and the J2EE licenses are totally seperate and dtstinct legal documents and thus seperate and distinct issues.

    If you'ld like to actually learn something about them, based on the posts I've seen here I wouldn't try slashdot. I

    Instead try the actual pointers contained in the post referenced below:

    http://slashdot.org/comments.pl?sid=21699&thresh ol d=-1&commentsort=1&mode=thread&pid=2312751#2312969

I have the simplest tastes. I am always satisfied with the best. -- Oscar Wilde

Working...