My topic in this column is open source software licenses, and more specifically why the choice of license can be an important decision for both software developers and end users.

When you embark on an open source project (as we did with the Globus Toolkit about ten years ago), you start off with a very small, close-knit community of technologists who share a common goal.

In our case, we were a group of developers writing Grid middleware (which came to be known as the Globus Toolkit) - seeking to tie together geographically dispersed compute resources within federally funded research organizations to enable new capabilities in resource sharing and problem solving.

As time passed and the Globus Toolkit code evolved, our community grew in many different directions. Grid usage was strongest in research and academia (for big compute science requirements - such as particle physics), but the Globus Toolkit was seeing strong participation from a number of other areas as well. Vendors with commercial-level Grid interests were contributing funding and code to the Globus Toolkit, and experimenting with commercial-level products built upon the open source code. Enterprise end users (particularly in the financial services industry) were beta testing the Globus Toolkit. And our pool of contributing developers had expanded beyond the U.S. to include a large international community.

As time passed and the code matured, new constituencies abounded. We were no longer a small community of technologists who all shared a common goal - we had morphed into a large number of distributed groups sometimes with conflicting priorities and visions. This is the price of success for such a widely adopted open source effort.

Recently, I participated with my colleagues in the drudgery of sorting through countless open source licenses and choosing the one license we felt would best represent the best interests of the Globus Toolkit community at large. It was not an easy task.

Were it not for the SCO / IBM legal battle or the Microsoft copyright infringement allegations, I would not presume that the average reader would even care about such intricacies. But it's no longer acceptable for the average IT pro to just give software licensing a haphazard glance like it's the 4-point-font liability waiver legalese on your parking ticket. Today's open source software licenses can have a tremendous impact on how software is written and consumed.

There are many different open source licenses these days (read leading expert Eben Moglen's Q&A in this month's Globus Consortium Journal for a great run-down on the related considerations), but the two predominant open source licenses are the so-called "BSD" and "GPL" licenses. Both forms of license allow free use of software. However, while BSD licenses allow individuals or organizations to make modifications or enhancements to the code without contributing that code back to the open source community, the "viral" General Public License (GPL) requires that modifications be contributed back to the community.

Each of these two types of licenses has its unique pros and cons. The upside for the GPL is that it guarantees developers that their code will forever remain free, and that any future developers who contribute will be similarly required to keep it free. The downside is that the GPL can create liabilities for enterprise end users when mixed with non GPL software in their production environments. Thus, enterprise software vendors and end users are sometimes reluctant to use GPLed software.

A major upside for BSD is that it is enterprise friendly. The lack of viral concerns encourages enterprise use, which in turn can spur both contributions and the development of a vibrant commercial support industry. BSD licenses also allow vendors to package and sell enhanced versions of open source as proprietary solutions. Such developments can be seen as a downside for the original development community that created the open source under the auspices of truly (and infinitely) "free" software-but they also often accelerate end use and vendor support. The other potential downside for BSD licenses is that they can allow for "forking" - or many different proprietary flavors and associated licenses that can scatter the focus of the collective open source movement in question.

Recently, the Globus Alliance announced that it had adopted the BSD-style Apache 2.0 license (APL2) for the Globus Toolkit. APL2 already governs the many software distros from the Apache Software Foundation, and its terms have been carefully crafted to address issues that are important for enterprise adoption, such as grants of royalty free patent rights from any contributors. It has become widely trusted and accepted by enterprise users.

We chose this BSD-style license because we believe that vendor incorporation of Globus Toolkit code into their proprietary offerings is a key to enterprise adoption. IBM's Grid Toolbox, Sun's Grid Engine and Nortel Network's Dynamic Resource Allocation Controller (DRAC) are examples of early Grid products that use the Globus Toolkit. The APL2 license allows these vendors to use Globus Toolkit implementations of the open standards in their Grid products. Thus, those products are able to interoperate with other hardware and software resources in their customers' IT envrionments.

I believe that when vendors build proprietary Grid products on open source, everyone benefits. While the APL2 license does not require that vendors release modifications and extensions back to the community, I expect that the large vendors who have invested so heavily in the Grid to date understand the ultimate value of contributing back, and will continue to do so in the future. Thus, competition between proprietary products yields both better solutions for end users and higher quality in the underlying open source.

Grid pioneer Ian Foster is a board member at the Globus Consortium, a vendor-neutral, nonprofit organization promoting the open-source Globus Toolkit in the enterprise. He can be reached at foster@mcs.anl.gov.

close window