Enydra drops J2EE server due to J2EE licensing restrictions


News: Enydra drops J2EE server due to J2EE licensing restrictions

  1. Enhydra is dropping its Enterprise project, which was their J2EE effort that included the Jonas EJB server, due to licensing issues that prevents any open source group from legally implementing J2EE and EJB. Since Sun owns the API's, creating your own clean-room implementations is illegal. Will jBoss be next?

    Check out A Message to the Enhydra.Org Community.

    Threaded Messages (33)

  2. This is quite a sad sign for the open source community as regards J2EE. Sun should provide some mechanism for allowing open source solutions - open source is a valid and innovative method for software development and plays a part in driving the rest of the market.
  3. We are not talking about a clean-room implementation like JBoss here, as far as I can see. The message from Lutris refers to the Sun Community Source Licensing for the source code making up the J2EE reference implemantation you can download from Javasoft. I guess everybody is free to implement any of the Sun specifications for Java they want to, as long as you don't violate trademarks.
  4. Lutris does have a clean room implementation of the J2EE specs. They haven't used any of the code in the RI.
    I don't know if that is the case with JBoss too.
     You need to sign SCSL in order to get the
    test suite which allows you to use the J2EE brand if you pass the tests. It seems that once you run those tests, all
    your tested code becomes "covered code" and you can only share it with other SCSL licensees. I am not sure about this
    though. Can someone here confirm this ?

  5. Could Floyd explain what he means by "due to licensing issues that prevents any open source group from legally implementing J2EE and EJB." I'm just about to make a commitment to JBoss......
  6. Allright guys, here are all the details:

        As I understand the issue (having spoken to various licensees and non-licensees alike), Sun owns the very API's themselves. This prevents anyone from writing the text "public interface EJBHome {" for example without Sun's

        Companies can ship J2EE products by becoming licensees. This gives you access to the J2EE source code, but more importantly allows you to *ship* the J2EE API's with your products.

        Thus, the crux of the issue is that an open source company (or any company that is not willing to pay to become a licensee) cannot ship Sun's API's, so their only recourse is to re-write them and ship their own copy, which of course violates the limited license agreement you all clicked 'accept' when downloading the J2EE sdk.

        So just because it is in a spec, and just because folks have written clean-room implementations, doesn't mean that Sun doesn't still hold copyrights and that folks haven't violated them. It just means that Sun isn't enforcing the copyrights yet. Lutris wasn't willing to take the risk that Sun would decide in the future to enforce it.

        I personally don't think Sun will ever hound down jBoss (not as long as they keep their server free and open source anyway), so there is really no problem with using jBoss or committing to it in your projects.

  7. I don't know about the other J2EE APIs, but for JMS (which is part of J2EE) you can of course implement it and you can of course ship the binary API classes with your product. It is explicitely stated in the license agreement when you download the JMS jar.

    And I think it's the same with all other J2EE APIs. So the action taken by Lutris makes only sense if they have changed the J2EE *sources*. This falls under the community license. Only J2EE licensees are allowed to do that. They have to commit the changes back to the community.

    -- Andreas Mueller, http://www.swiftmq.com
  8. This is insane. Can I get a patent on the *specifications* for the wheel...
    * it must be round
    * it must roll

    and then charge people for coming up with their own design?
  9. implementing the J2EE spec[ Go to top ]

    The specification is more than just an english description. J2EE is also specified by the classes and interfaces for a great many packages. For example, javax.ejb.* and javax.jms.* to name two important ones. There are also things like the XML DTDs for the deployment descriptors. Such things are not code that you can reinvent, because they must be provided literally as per the code included with the specification.
  10. The license agreement from SUN says:

    "In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers."


    In otherwords, the API specifications are always free under java, that means all J2EE API's are free for anyone to implement, what is not free is the SUN's implementation, w/c requires that you abide by their license.
  11. This is crazy. If this was the case then every JDBC driver written for open source db's (non-licensed) would be against the law?

    I heard from someone at Lutris that the real reason they are dumping their support of enhydra is business related. They don't want to keep giving their work away for free. It sounds to me like their company is falling on hard times and they can't devote time to the open-source side of Enhydra anymore
  12. From what I've read (in Floyd's mail) the license prevents you from shipping the API's with your product.

    So what? JServ from Apache does NOT ship the servlet.jar file with it's installation, for the same reason. It simply says that you will have to go and download the relevant JAR file from Sun (which is free.)

    So all you really have to do is to not include the API JAR files with your distribution, and inform your downloaders they will need to get the JAR files from Sun.

    That worked for Apache. And it gets round the letter of the law (which is what caused the problem in the first place.)


  13. Actually, JBOSS is not a clean room implementation. If one downloads version 2.4 made available 9/10/01, one finds countless inclusions of Sun Reference Implementation code, which is in violation of the Sun Binary Code License (see inclusions of JAAS, JNDI, XML.JAR (Project X, ver 0.8.0),
    JavaMail 1.2, JAF). The Sun BCL states specifically that "use the binary form of the Software for the sole purpose of designing, developing and testing...", and not for redistribution. Sun could quite easily issue a cease and desist order if they so chose.

    With respect to JBOSS, Enhydra Enterprise and Lutris EAS, these implement the J2EE. The collection of APIs called the J2EE are covered under the SCSL 2.8 license, which specifically forbids the deployment of code covered by this license without a signed license from Sun. Thus, all of the products/projects discussed are impacted by SCSL, and have the same legal issues.

    Having emailed with Marc Fleurry at JBOSS repeatedly regarding strategies to approach Sun to attempt to find an open source resolution to SCSL, I assure you that both the Enhydra Enterprise project and the JBOSS project are very well aware of SCSL restrictions and Sun's licensing. Having been involved in the licensing of J2EE with Sun since April of 2000, I would have to say that Sun has no intention of changing the SCSL license...

    best regards,
    Keith Bigelow

  14. This isn't the case with JBoss. All the redistributed Archives like JAAS, JNDI etc. come with a "redistribution" license from Sun therefore JBoss does not violate the Sun license with the redistribution of these archives.

  15. Hmm. How can writing software for a SPEC be covered by a license ? I think lutris used code from the reference implementation. And why don't they develop a closed source version, give it away for free and live from the support ? No, the abondon the free projekt and try to sell in the same mail their EJB products. This has nothing to do with Sun or licenses, but with Lutris not spending more money in theri open source projects. Btw. see instantDB, they did the same thing there.

  16. This is strange. As an Open Source project, do you have to put a J2EE stamp on your projects ?
    SUN is actively participating in Tomcat 4.0 which is Open Source an complie to J2EE. That does not make sense.
    I might think that enhydra is now focusing on Wireless technologies. J2EE is becoming bigger and bigger, therefore takes a lot of resources to implement new specs.
    Enhydra might have also realized that there was a duplicate effort with Apache, and they might focus more on services/components built on top of J2EE containers. Just like ATG with Dynamo.
    So in a way that might be a good sign. We need more frameworks, components out there to make it easier to release web/wireless services and not re-invent the wheel everytime.
  17. Can anyone point me to the exact licens that prevents open source projects from implementing J2EE. I was under the impression that the only licensing connected to J2EE is the "branding". I.e. if you want to use the J2EE-loggo with your appserver you have to pass SUN's test suite - and pay up.

  18. Awesome news!!!!

    Can't wait to see jboss close down next.
  19. Okay, I refer to the following clause in the EJB class files binary license agreement:

    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.

    JDBC Optional Packages, JMS and JTA all have similar clauses in their licenses. IANAL, but it seems that if your software license (whether open source or closed source) allows inclusion of third-party software with closed licenses (for example, BSD or Artistic), your product would be okay.
  20. Some one at Javalobby pointed out that Enhydra is making excuses and also what they did with InstantDB.

    Have a look at it:

  21. Buried in the link provided by Mettu is this link


    to an article from NewsForge, that IMHO, sheds light on the Enhydra-Lutris/Sun "licensing situation" as well as providing statements from each party involved.
  22. I think the confusion lies in what API means, 1) the specifications, or 2) the implementation.

    My understanding is that you can implement your own clean-slate J2EE servers without violating Sun's agreement.

    If you want to use their implementation or modify and derive work from it, you have to pay.

    Correct me if I am wrong.
  23. If you want to have the right to deploy a J2EE app server [meaning use in an environment other than research], you must license the J2EE from SUN. In J2EE 1.3, the right to implement the app server, even for research, is removed.

  24. Jonas?[ Go to top ]

    Lutris Enhydra was just a shrinkwrap of the open source Jonas, wasn't it? Is Jonas impacted, or has it long since lost its parity with Enhydra?

    BTW I don't believe that you have to worry about JBOSS, Inc. going out of business or closing the source since there is no JBOSS, Inc. (as there is a Lutris).


  25. Jonas?[ Go to top ]

    I believe the keeps of JOnAS are Evidian which is not directly tied to Lutrus. Therefore, I do not believe the JOnAS project is shutting down.
  26. sunw == msft
  27. Licensing issues... at the time of J2EE success.. Bad time.
    Why won't Sun become like Microsoft ?
    I think it is prime time to get back & find out all these issues. I never read any of the licensing agreement till now. Simply download ,install & play with them..Here after i think i should spend lot of time in reading licensing
     agreements :(

    Now let me go back to the basics..
    What is the pricing model of Sun for its Specs & APIs?
    Why is java (java spec & JVMs) free?
    Given this market condition why should it take pain to develop them & give it for free????
    How does SUN generate money to keep these (APIs) growing?
    Is it planning to charge exorbitant money once the product saturates in the market?
    If the market worsens, can SUN charge for the Core Java APIs?
    Can any one throw some light on these..

  28. Over a year ago we were looking at using an OpenSource app server. Back then Lutris did not have EJB support and it was *promised* in a future version, etc...

    Even back then the company seemed *against* EJB. Even to the point of having letters posted on their sight as to why it was not necessary in an app server...

    Now they have a licensing problem, I think its more of an excuse for them since they never seemed to be behind EJB from the start.

    My 2 cents
  29. Did I get this right?

    1) I can re-distribute the API (like servlet.jar) in binary for free.

    2) I can extend it if i publish the spec of my extensions. My extensions cannot replace Sun's binary version, only extend it with additional API functionality.

    3) I can freely write my own server using the API, as long as I use the JavaSoft binary (servlet.jar) to interface it, together with my extensions.

    What I can't do is change sun's API or re-implement it my own way from the specs.

    I think I like it...

  30. No, you cannot distribute servlet.jar for free. You must refer your customers to the Sun site where they can download it.

    You can do what you like with regards (2) and (3) but you must not ship servlet.jar with your package. Just refer customers to the Sun site and stipulate which version of the API they need.


  31. This is pretty worrying. At a time when MS is pushing .NET with all of its might, the last thing Java needs is the Open Source community pulling the plug on J2EE because of licencing restrictions.

    If we are left with nothing but the 10K per year per CPU licences of the likes of BEA and IBM then I fear that MS will be on the way to market domination (again) :(

    Does this have any affect on Orion, which if free for non-commercial use?
  32. My understanding is that, as Floyd pointed out, you can't write "public interface EJBHome {" into one of your files and ship it. There's nothing to prevent you from writing tools that act on interfaces that extend this interface though. This allows you to implement something like Weblogic's ejbc without violating any license.

    You can of course also create an infrastructure that is able to host EJB components. But for your customers to be able to do something with you product, they need the APIs. So you now have two choices: 1) You license J2EE from SUN, and if your product passes the compliance tests, you can call it "J2EE certified" or 2.) You refer you customers to Sun's website to get access to the APIs.

    So inspite of Lutris's claims, I still believe that it's possible to create an open source EJB server. Just don't use the brand "J2EE" and don't implement the APIs yourself and there shouldn't be any problem.
  33. I haven't seen so much FUD in one place since..., since...

    Enhydra does not support J2EE and never has, AFAIK. Where have they been? They're in the proprietary interface business themselves, and it smells like they were monkeying with the J2EE in the attempt to be compliant with it.


  34. FYI

    JBoss' Marc Fleury has posted a statement regarding the FUD surrounding this licensing issue and how it relates to JBoss: