Slashdot Mirror
Lutris Closes Enhydra Source
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.
As indicated above, the reason for the closing of source is the J2EE license from Sun. All complaints should be addressed to Sun Microsystems.
My office has been taken over by iPod people.
They're only hurting themselves and developers with their idiotically stubborn unwillingness to get with the program.
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?
Are there different licenses for projects like Tomcat? Can you deploy them legally?
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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!
According to the comments at newsforge, complaints should not be addressed to SUN. See these comments.
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'.
I'm not sure why someone looking for a J2EE implementation would go to Enhydra. JBoss 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.
If it ain't broke, you need more software.
SourceForge has nice projects: Open Business or Enigma for J2EE business software. It is still far from finish, but at least you can help to make it happen.
--
Error 500: Internal sig error
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).
--
E_NOSIG
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.
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 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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
This sig intentionally left blank.
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.
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'
The problem is that Lutris used the Sun reference code to build the J2EE Enhydra server. It would be kind of like Mono releasing a GPL'ed .NET based on Microsoft's reference code submitted to ECMA.
Sun, on the other hand, has no problem with JBoss, which is a clean-room implementation of the J2EE spec.
If it ain't broke, you need more software.
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?
ORP is a research Java VM from Intel with fast JITs and GCs. It's not usable for real work, though.
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.
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.
This sig has been temporarily disconnected or is no longer in service
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.
gcj 3.0 implements a great deal of 1.2. It's lacking AWT/Swing and RMI. The latter will be in 3.1.
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.
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.
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.
creation science book
1. It's an excellent implementation of J2EE
:-) project leader/lead programmer, Marc Fleury.
:-) download with embedded Tomcat or Jetty.
2. The project has a really active (like in hyperactive
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
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
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.
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.
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.
h ol d=-1&commentsort=1&mode=thread&pid=2312751#2312969
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&thres