How Globus picked its open-source license

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 10 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 (that later 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. Some vendors were contributing funding and code and experimenting with commercial-level grid products built upon the open-source code. Enterprise end users, particularly in the financial services industry, were beta-testing the tool kit. 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 with sometimes conflicting priorities and visions. This is the price of success for a widely adopted open-source effort.

Recently, I participated with my colleagues in the drudgery of sorting through countless open-source licenses to choose the one we felt would best meet the interests of the Globus Toolkit community at large. It wasn't 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 professional 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, but the two predominant ones are the BSD and GPL licenses. Both 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 licenses has its 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 GPL software.

A major upside for BSD is that it's 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 software. 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-user 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 License Version 2.0 for the Globus Toolkit. APL2 already governs the many software distributions 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 Microsystems Inc.'s Grid Engine and Nortel Networks Ltd.'s Dynamic Resource Allocation Controller 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 environments.

I believe that when vendors build proprietary grid products on open-source, everyone benefits. While the APL2 license doesn't require that vendors release modifications and extensions back to the community, I expect that the large vendors who have invested so heavily in 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 code.

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.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon