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.
Direct complaints to the right place (Score:2)
Direct complaints not to SUN (Score:2)
Blame Sun (Score:2)
They're only hurting themselves and developers with their idiotically stubborn unwillingness to get with the program.
You're right (Score:2, Insightful)
Oh, wait. If Java becomes a standard, people won't have to pay Sun anymore to be 'Java compliant'.
Re:You're right (Score:2)
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.
Re:You're right (Score:2)
Re:You're right (Score:2)
Re:You're right (Score:2)
You don't consider the stackless Python a fork?
Re:You're right (Score:1)
Re:Blame Sun (Score:2)
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!!!!
Re:Blame Sun (Score:1)
Yeah, Java does run pretty damn slow on my HP-48.
Free Java implementations? (Score:2, Insightful)
Japhar is another implementation, but it is in a very early stage (current version 0.10).
Do other implementations exist?
Re:Free Java implementations? (Score:1)
Re:Free Java implementations? (Score:2)
The only other choice out there is IBM's implementation, called Cross Platform Toolkit. But even them are licensing some core classes from Sun.
Re:Free Java implementations? (Score:1)
ORP (Score:2)
Re:Free Java implementations? (Score:2)
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.
Re:Free Java implementations? (Score:1)
Kaffe isn't dead, it continues to be maintained and extended as part of PocketLinux. Unfortunately the kaffe.org sote fails to mention this.
gcj (Score:2, Offtopic)
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.
Re:Free Java implementations? (Score:2)
java itself may not be the hype of the future, but the related technology will, in one form or the other. Strong object orientation and a VM for userspace applications
Non J2EE App Servers legal? (Score:2, Interesting)
Re:Non J2EE App Servers legal? (Score:2)
Re:Non J2EE App Servers legal? (Score:1)
Re:Non J2EE App Servers legal? (Score:2)
Cocoon vs Enhydra (Score:1)
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. .JSP ...
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
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
What is the future of the JBOSS project now? (Score:1)
Re:What is the future of the JBOSS project now? (Score:2, Interesting)
Don't care about being recognized by Sun? => Problem solved!
Re:What is the future of the JBOSS project now? (Score:1)
XMLC is the core of Enhydra (Score:1)
Re:XMLC is the core of Enhydra (Score:1)
In fact I have yet to find the "killer application" for EJB.
Uh, this is OLD NEWS- and the title's misleading! (Score:4, Informative)
sad (Score:1)
Send your complaints to Sun. We have seen the same with eg. Microsofts Mobile something developers kit, and it is very sad.
open source increasingly under siege ... (Score:1)
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.
Re:open source increasingly under siege ... (Score:2)
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.
Re:open source increasingly under siege ... (Score:1)
Why use Enhydra? (Score:4, Informative)
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.
Re:Why use Enhydra? (Score:1)
Re:Why use Enhydra? (Score:1)
Re:Why use Enhydra? (Score:1)
An Alternative (Score:2, Informative)
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.
Newsforge (Score:2)
This one looks like Sun's fault, but InstantDB? (Score:1)
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 should mention... (Score:1)
Zipwow
How did the Blackdown project do it? (Score:1)
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)
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.
Re:Red Herring (Score:1)
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.
Why JBoss will succeed (Score:2, Interesting)
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
Lutris is pulling a MySQL (Score:2)
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.
Re:Lutris is pulling a MySQL (Score:1)
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.
Sun man speak with forked tongue (Score:2)
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.
Who modded this yahoo up? (Score:1)
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
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!
Re:Who modded this yahoo up? (Score:1)
They probably closed the source so they could use the RI code. JOnAS was never a very good EJB container, but it was the first free one. However, that distinction won't help it pass the J2EE tests. As a result, they probably dumped it in favor of tweaking Sun's container. Not too surprising.
License doesn't allow Open Source (Score:1)
FEAR NOT! The problem is not with J2EE! (Score:2, Interesting)
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.
Re:FEAR NOT! The problem is not with J2EE! (Score:1)
Re:FEAR NOT! The problem is not with J2EE! (Score:1)
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
Re:FEAR NOT! The problem is not with J2EE! (Score:1, Interesting)
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.
Is this an issue though? (Score:2)
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.
Re:Is this an issue though? (Score:1)
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.
Re:Is this an issue though? (Score:1)
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
Re:Is this an issue though? (Score:1)
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.
Re:Is this an issue though? (Score:1)
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).
Re:Is this an issue though? (Score:1)
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.
Ok, sort of a dumb question... (Score:2, Interesting)
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?
Embrace Openness and Freedom.... (Score:1)
Re:Embrace Openness and Freedom.... (Score:1)
Lutris is saving the face on this (Score:1)
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.
ESR on the WTC Attack (Score:1, Offtopic)
Think air rage is bad now? Try arming those drunk businessmen and see what happens.
Re:ESR on the WTC Attack (Score:2)
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 at Lutris (Score:1)
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.
More on the Lutris Situation (Score:2, Informative)
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?
Re:More on the Lutris Situation (Score:1)
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.
This is not the issue (Score:1)
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.
Who needs Enhydra? (Score:2, Funny)
Zope Enterprise is still open (Score:1)
SCSL is a commercial virus (Score:1)
Re:SCSL is a commercial virus (Score:2)
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.
Re:SCSL is a commercial virus (Score:1)
Re:SCSL is a commercial virus (Score:2)
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.
Enhydra is full of.... (Score:2)
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.
Re:Enhydra is full of.... (Score:1)
Re:Enhydra is full of.... (Score:2)
(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.
Re:Enhydra is full of.... (Score:2)
The SCSL is the "Sun Community Source License" and is for access to the base of source code written by sun (ie the VM source).
Try reading abotu it here:
http://www.sun.com/communitysource/
To put out a J2EE server you need a J2EE license which requries passing a suite of compatability tests called the TCK and agree to pay a royalty on sales in return for use of the J2EE trademark.
You can find out all about it by filling out this form here:
http://java.sun.com/j2ee/license_form.html
Thanks for proving my point about the Internet.
philosophical differences (Score:2, Interesting)
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.
Open Source J2EE AS Reviews? (Score:1)
The only link I could source the explicitly mentions JBoss is CSIRO Australia report [csiro.au].
Suggestions?
Try Zope... (Score:1)
Seems like an easy fix (Score:1)
IMO this needs saying.... (Score:2)
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
Re:Java is dead anyway (Score:1)
Re:Java is dead anyway (Score:1)
Re:Oh really? (Score:1, Funny)
You mean the Scandinavian Air Lines [scandinavian.net]?
Well, they're about to go under so perhaps you could convince them to drop a few planes on Osama and claim the insurance instead...
Re:Oh really? (Score:1)
Re:Newsforge (Score:1)
Foregery may have a similar root but the use of Forge here seems pretty strong -- a good name if ever I've seen one.
Re:Why not provided two versions ? (Score:1)
Re:Something Is wrong (Score:2)
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.
Re:Something Is wrong (Score:1)
The problem is that as long as Sun holds on to SCSL, Java and open source are basically incompatible, especially GPL-based projects. The scary thing about JBoss is that at any time Sun feels that they're a threat, they can send out their lawyers and have all references to J2EE specs removed from JBoss docs and code.
The open source community needs an open source J2EE-like platform which isn't tied to Java. We need to look at the features of J2EE and
Re:economics stupid (Score:1)
The companies that now sees their stocks go through the floor just DOESN'T MAKE MONEY. And if you don't make money you can't justify that others should by your stocks for lots of $$$. And in the long run you can't pay your salaries and bills.
Companies needs to make money, it's as simple as that.
sig: for your daily dose of fanatism visit www.taliban.com, www.hamas.org or www.gnu.org
Re:economics stupid (Score:1)
1) Current earnings, assets, and dividends.
2) Speculation on future earnings, etc.
Venture capital and stock offerings are a loan, expected to be paid back with interest. What happened to our economy is that people forgot that. $18 Million VC or IPO -- we're rich! No, that means you're poor. You just sold your business to someone else and the money has to be put back into the business. It's like selling your house and agreeing that all the money has to go into upkeep on the house. If home repair is your trade, that might be a good business plan, but only if you manage your business properly.
Re:Burned by Enhydra Before... (Score:1)
Anyway, Lutris never did release the source of InstantDB, and they never made an official statement any stronger than a vague intention to release the source of InstantDB. They own InstantDB, and they have the right to do with it what makes sense for their business.
What some people overlook is that companies do own their software, they don't sell it to you, they license it to you for specific uses, with conditions. This is true of MS Windows, and Java, and InstantDB, and almost everything -- including most open source software!
Re:Sad to see (Score:1)