It’s time that AS/400 shops take a look at open source. And December is a great time to talk about it because this is the month that the Apache Software Foundation’s HTTP Server will be available for OS/400. You already know that Linux can now run on OS/400, and, in
“Tomcat for the OS/400: An Open Source Web Application Server,” on page 86, I’ll show you how to install and configure Tomcat on your AS/400. Furthermore, because OS/400 has one of the best Java Virtual Machines (JVMs) in the industry, the AS/400 can run any of the myriad all-Java open source products.

Perhaps the biggest reason for the widespread availability of open source Java products was the introduction of Sun Microsystems’ Java 2 Platform Enterprise Edition (J2EE) standard last year. The J2EE standard provides the infrastructure for cross-platform Web application servers. Today, there are dozens of vendors that are scrambling to provide J2EE-compliant Web application servers. Some of the best-known commercial products are BEA Systems’ WebLogic, IBM’s WebSphere, and Sun Microsystems’ and Netscape Communications’ iPlanet. But these are pricey products ($5,000 to $10,000 and up), whereas the open source alternatives are not.

What’s J2EE?

J2EE is a collection of about a dozen technologies, the most important of which are Enterprise JavaBean (EJB), Java Database Connectivity (JDBC), Java Message Service (JMS), XML, JavaServer Page (JSP), and servlets. Realize that Sun’s J2EE merely provides a standard interface. To get an implementation of J2EE, you need to acquire a J2EE-compliant Web application server. That’s where the beauty of open source products fits in with J2EE. You can use an open source solution and later switch to a commercial J2EE product, and your application will still work. In fact, another advantage of open source Java products is that they rarely go beyond the J2EE standard. As a result, if you develop and test with an open source product, you have a better chance of being able to switch to other J2EE vendors, open source or otherwise.

Application Software Vendors

Many application software vendors are embracing open source. Consider, for instance, a small vendor of an order entry system. The vendor develops an application using J2EE technologies because it doesn’t want to limit the marketing of its product to one operating system. So the vendor ends up in a situation in which a commercial Web application server

effectively adds about $10,000 to the cost of its product. But if the vendor bundles the open source jBoss EJB server along with Apache’s HTTP Server and Apache’s Tomcat Web application server, it reduces the net cost of its product.

Say the application software vendor finds a problem with jBoss. What does it do? It can submit the bug to jBoss. Better yet, since the vendor has the source code, it can fix the problem and submit the fix to jBoss. This scenario is exactly what is happening today. That’s how the Apache HTTP Server started, and that’s how Linux became one of the leading operating systems for running Web applications. Because open source software is peer-reviewed, it ends up being more reliable than closed, proprietary software.

Sign Here

There are a number of open source software licenses. The most prevalent are GNU General Public License (GNU GPL), Open Source Initiative (OSI), and Apache Software License. The mark OSI Certified shows that the license under which the software is distributed conforms to the Open Source Definition (OSD). (To read the OSD, visit www.opensource.org/osd.html.) The GPL mark means that the license is under the terms specified by the Free Software Foundation (www.gnu.org). Free Software Foundation started in 1984 to distribute UNIX-like software for free, but today it has expanded to encompass other open source solutions such as those implemented in Java. Anyway, regardless of the organization, you’ll see a relatively similar license at the top of every open source file. As an example, I’m going to summarize, in my own terms, the license for the Apache Software License, Version 1.1:

• Don’t rip the tag off—Well, what you’re not supposed to do is delete the copyright off the top of a source file, but that reminds me of ripping warning labels off of sofas. Whereas you probably won’t be selling your sofa any time soon, you very well might be selling your code.

• New code gets the label—When you create new code that enhances open source code, it gets the same copyright. This prevents a vendor from making mild enhancements to an open source OS or server and calling the whole thing its product.

• Tell users where the code came from—All documentation must credit the organization that controls the open source.

• Don’t use the organization’s name—You can’t go around saying your application is endorsed by an open source organization if it’s not.

• If you die, it’s not their fault—Well, maybe you won’t die, but your business might, so don’t expect to sue the Apache Software Foundation.

The first two items are the big ones because they effectively say that any software with open source copyrights will always be open source.

Plug It In

Here’s one last but very important point: Just because your business application uses an open source J2EE product doesn’t mean that your software needs the copyright. The J2EE is used as an API where you plug in a J2EE provider. Your business software uses the J2EE API; it doesn’t extend it. Now, if you want to add a feature or fix a bug in the J2EE’s open source, then you are extending or enhancing that product and the new code and documentation needs to include the copyright.

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale