New Java license: Smells like open-source. Looks like shared-source.

New Java license: Smells like open-source. Looks like shared-source.

Summary: Sun has once again -- this time with Java -- opened the kimono on some of its most coveted code (the last time was with OpenSolaris) but may be falling short of what open source advocates had been hoping for. "One of the new licenses," reports News.

SHARE:
TOPICS: Open Source
5
Sun has once again -- this time with Java -- opened the kimono on some of its most coveted code (the last time was with OpenSolaris) but may be falling short of what open source advocates had been hoping for. "One of the new licenses," reports News.com's Martin Lamonica, "called the Java Internal Use License, is targeted at corporate customers that use Java to build business applications. The JIUL, pronounced 'jewel,' makes it simpler for these customers to view the source code and so to root out the problems a Java application is having." This sounds an awful lot like the shared-source license that Microsoft uses to let large customers and governments look at its source code.

So, why won't Sun just go and open source Java? Read LaMonica's report and you'll see how James Gosling, chief technology officer at Sun's Developer Products Group, talks about the company's concerns over forking and compatibility. Forking happens when multiple groups take a single technology and go different directions with it in a way that produces different and often incompatible versions. Looking at another large open source project, Sun doesn't want history to repeat itself.

Sun has never been that impressed by the Free Standards Group-maintained Linux Standards Base (LSB) project. According to the LSB mission statement the goal is a follows: To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.

When you talk to Sun president and COO Jonathan Schwartz about the open sourcing of Java, one of the first examples he'll point to as a key reason why it shouldn't happen is Linux. For all of its good intentions, the bottom line is that up until now, the LSB may be succeeding in its mission to increase compatibility amongst Linux distributions, but it so far it has not been able to guarantee it and it's unlikely that the LSB ever will. Enough incompatibilities between the various distributions exist -- especially the distributions that appeal to enterprises -- that you can't not call them proprietary or say that Linux has forked Schwartz has argued.

Schwartz defines "proprietary solutions" in CIO terms (and in terms that I agree with): when, because of incompatibilities with alternatives, the cost to switch to a more attractive alternative is just too much to stomach both financially and logistically. This is a fair assessment of the situation with Linux. It's in neither Red Hat's nor Novell's best interest to make it easy for their customers to

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • EXACTLY!

    Debian is a great example of "forked" Linux. The config files are don't follow the *NIX naming conventions and are placed in odd directories - also not following the *NIX conventions. If it was the wish of Debian folks to make things "better", they should have worked with the community to incorporate their ideas. Instead they just go out and do them, and the community becomes forked.

    Any time an application needs to alter a system config file while installing, it would really help if those files were named the same and were located in the same place! Shame on you Debian!
    Roger Ramjet
    • Isn't that what

      /etc/ld.so.cache is supposed to resolve? Doesn't that tell an application where all libraries are? And why would an installed program (i.e. one that is not native to the Debian distribution) need access to the configuration files of the entire system? Wouldn't giving applications you are installing a roadmap to your system configuration files be a roadmap to disaster?

      One thing I really like about Gentoo is that updating a program will NOT automatically update anything in the /etc folder that already exists. If changes are to be made, I run etc-update, and I can interactively, one by one, see what changes are being made and decide whether the change is needed for the updated program, or whether the updates are just overwriting config files I've already perfected and do not want changed.
      Michael Kelly
  • Where are the facts?

    Berlind first mentions that migration from one Linux Distro (Red Hat, for instance) to another (SuSE, for instance) is a huge task with costs making it not worth the bother, and thus making the Linux distros proprietary in a practical sense.

    Then Berlind goes on to say it is trivial to migrate from one commercial J2EE Application server to another.

    In neither case does Berlind offer any evidence whatsoever to back up these claims.

    First, migrating from Red Hat to SuSE (or a migration from any distro to another), while not trivial, can be done, and has been done in many real world cases, without costs being out of control. Many enterprises migrated from Red Hat 9 to Debian or SuSE or another distro when Red Hat did the RHEL / Fedora Core split. And they did so with out breaking the bank. Also, there are RHEL clones, such as CentOS and White Box. Finally, there are lot's of third party service providers, and the Red Hat Fedora legacy project for customers to utilize. So Berlind's claims that Linux migration is overly costly is pure, ignorant FUD.

    Then on the J2EE side, I know a number of J2EE developers, and I've followed many forum postings regarding J2EE migration, and the anecdotal evidence is that migrating from one commercial J2EE application container to another is very non trivial, particularily if you use the vendor's extensions (which everyone does, to get needed functionality).

    If you walked up to a J2EE developer who has worked with different J2EE app containers, and told him/her that migration from IBM Websphere to BEA WebLogic was a piece of cake, he/she would laugh in your face.

    Basically, each J2EE app container has it's own extensions, it's own development environments and tools, and it's own Java Virtual Machine. And taking large enterprise applications from one J2EE container to another is a process ripe for disaster. J2EE is huge and complicated, and each J2EE vendor has it's own proprietary extensions. Migration is not a no-brainer, and a huge expense. No doubt about it.

    If any J2EE developer has experienced a low cost, seamless commercial J2EE application container migration, please feel free to share your experience.

    But evidence on web forums, as well as people I personally know, is that J2EE migration is a major pain in the rear.

    I'm not saying that Linux migration is all easy, or that J2EE migration is all hard. But what I am saying is that Berlind doesn't know what he is talking about, and seems to be very biased against open source. Thus, in his blogs, he puts out FUD that is not backed up with facts or evidence.

    Any smart CTO or IT manager should take Berlind's blogs with a grain of salt.
    boobasaurus
  • Right on!

    One of the best (i.e. coherent, logical, non-religious) opinion pieces I've seen with regard to open-sourcing Java.

    I have always believed and still believe that Sun has had the Java community's best interests in mind when it comes to keeping the Java standard and WORA (with all it's warts) safe from forking. If they've been a bit on the paranoid side up until recently, it's because they got burned real bad by Microsoft's "licensing" of Java and susequent attempt to kill the WORA promise by forking a proprietary Windows-only Java. Much of the "incompatibilities" between JVMs, etc is a direct result of Microsoft's partially successful sabatoge attempt in the late 1990's.

    Regarding any evidence that Sun's stewardship of Java has resulted in any real difficulties for developers and/or users, I can only point to Sun's unduly restrictive redistribution policy. For whatever reason Sun will not let, for example, Debian bundle Sun's JDK or JRE with their Linux distro because it violates this rather draconian redistribution policy. I can't understand why Sun would not do everything they can to allow/encourage other companies to redistribute 100% pure Java JDKs and JREs. Is it because of the viral nature of the GPL?

    In any case, nice article.

    --
    Jeff
    jg1013
  • More than meets the eye

    First, I never said porting from one J2EE server to another is trival. Second, regarding the extensions you speak of that could interfere with portability, I believe I parenthetically disclaimed my portability comment with "(and you were careful not to make use of any vendor-specific extensions in your deployments)". One of the reasons to GO with J2EE (as opposed to .NET) is the leverage it gives you as a buyer of J2EE infrastructure. If you're a BEA customer and they change the business terms you don't like, or don't respond quickly enough, there are other vendors that might be able to do that for you. But if you opt to take advantage of J2EE proprietary extensions, then you're sacraficing on e of the greatest reason to pick Java in the first place.

    So, if you stick to the non-proprietary stuff, you 're not tied to any development environment and what works on one 1.4 certified container should be 100 percent portable to another.

    You could argue..."David.. you're argument is flawed. If your the sort of company that would watch out for proprietary extensions to J2EE, wouldn't you do the same for Linux?"

    My answer? Not many people are doing development on Linux like they would be on J2EE. In fact, any coding work that you're doing should not be at the OS level. I'd suggest that everything should be at a higher level such as Java, .Net, or a scripting language like Perl, Python, etc. Where portability becomes a serious issue from one distro to the next is in the qualification of their third party provided applications and the expected level of support from enterprise vendors. I've spoken with Linux users who have so many Linux servers in place and who know exactly what enterprise apps they didn't write break if they attempt to move to a different distro that they say they are absolutely 100 percent married to the distro they're using and that there's no going back. Perhaps others can speak more to this issue than I. You're absolutely right. I don't have first hand experience regarding this. The apps I've used...I've just recompiled. But when you're getting support from a big software vendor like Oracle or from a hardware vendor like Dell, changing distros is different than changing app servers.
    dberlind