October 2007

"Most companies will likely find it acceptable to use open source in some form, but just what form that is can vary greatly from company to company. Which licenses are acceptable is one of the things that companies commonly evaluate ... more often than not they come to similar conclusions."

Jason Haislmaier, Holme, Roberts & Owen LLP

Studies show that most open source projects are licensed under the General Public License (GPL) and it is estimated that over 75% of open source projects are licensed under either the GPL or the LGPL (Lesser GPL). Yet, it has been my company's experience that the open source software used by our enterprise customers is primarily Apache licensed software. This article examines several factors which may shed some light on this disparity, including the issues raised by enterprise customers and the software product selection process used by OpenLogic.

Open Source Licensing Issues

When enterprises consider using Open Source Software (OSS) they are often concerned about legal issues. They already know the software is of good quality and has the features they need because their technicians have tested it and are actively asking permission to use the software in production. Before allowing its use, enterprises want to make sure that they are legally allowed to use the OSS, that it won't jeopardize their own software, and that nobody will sue them for using it.

Common concerns cited by enterprises regarding open source licenses include:

  • they are relatively new, and therefore an unknown
  • they are mostly written by developers instead of attorneys, so they don't use standard, and well understood, legalese
  • the meaning of the term "derivative work" isn't clear when applied to software; until very recently, few had been tested in court so it was anybody's guess as to how they'd be interpreted by the courts
  • any dispute resulting in a court case is expensive, regardless of whether you are right or not

How Enterprises Manage Licenses

When encountered with legal worries about OSS, what do enterprises do? They ask their attorneys to review the license. Initially this can seem overwhelming as the OSI has approved over 50 licenses as meeting the open source definition and there are many more licenses that haven't been approved. Fortunately, a few licenses, GPL, LGPL, BSD and Apache, are used by most projects.

Enterprises typically review all of the licenses that they use, even for a small one-off application. So while the majority of software might be released under a couple of licenses, those additional licenses still create a lot of work for enterprise attorneys.

For that reason, enterprises often create OSS policies that explicitly state which licenses are allowed and for which use. An example policy may allow GPL licensed software for use within the company but may not allow its use in products shipped to customers.

Here are some of the best practices I have seen enterprises use when it comes to open source licensing:

  • creating an open source policy that clearly defines which licenses may be used; very few companies approve a license for general use as how the software is used can change license compliance
  • creating an open source review board that reviews and either approves or rejects every use of OSS, taking the license into account
  • requiring an attorney, either as part of or separate from the review board process, to review the license of any OSS being evaluated for use
  • keeping a central repository of all of the OSS that is approved for use within their company restricting how software can be used
  • identifying an open source champion or "go to" person for all OSS questions
  • when acquiring another company, auditing that company's OSS usage and policy before the acquisition
  • tracking the OSS it uses for license changes

That last point is important as projects sometimes change the license when they release a new version of their software. For example, when the Apache Foundation moved from the Apache License 1.1 to the Apache License 2.0, they added an anti-patent clause stating cases where users could not sue the creators of the Apache software. I've seen projects move from a non copyleft to a copyleft license, or from a license containing no anti-patent clauses to a license containing a strong anti-patent clause. These changes can have major implications for enterprises depending on how they are using the software. Many enterprises also research indemnification options as insurance against liability in possible future legal suits. Enterprises realize that not only are there potential legal issues around OSS, there often is no "throat to choke"; they need to explicitly ask for indemnification for OSS. Due to the scarcity of test cases in the courts, enterprises often want more indemnification for open source software than for the proprietary software they use.

A good policy comes from the realization that you can't eliminate all risk; policies are about mitigating, not eliminating risk.

Licenses Used by Our Enterprises Customers

OpenLogic provides over 300 customer requested, certified, supported, indemnified, and updated OSS packages to enterprises. We were curious as to which licenses applied to the software our customers most commonly used. We initially assumed the GPL, as the majority of OSS is licensed under the GPL, but decided to check our database of software. Of the 300 OSS packages in our certified library, only 29% are licensed under the GPL or LGPL and 35% are licensed under the Apache license.

It gets even more interesting if you look at just the top 20 most used software. After sorting our library by number of customers using the OSS package, I took the top 20, grouped them by license and found that:

  • 75% were Apache licensed
  • 20% were licensed under the GPL or LGPL
  • 20% used the CPL, Eclipse, Perl, or BSD licenses

There are several points to keep in mind when interpreting these results:

  • the percentages add up to more than 100% as several software packages were dual licensed
  • OpenLogic provides software not already included in major Linux distributions; these numbers do not reflect the GPL licensed kernel or any included software packages which tend to be GPL licensed
  • most results rely on SourceForge data which does not include much of the software used by enterprises such as Apache, Firefox, and OpenOffice

An overview of the OpenLogic software certification process is needed to determine if it introduces any licensing bias. In order to be added to the Certified Library, an OSS product is assessed against several criteria. The software should:

  • have broad adoption based on market research
  • provide features required by enterprise customers
  • have equivalents to provide companies with other open source alternatives
  • be requested by enterprises

In addition, each software undergoes five assessments which validate its viability, license, functionality, support, and technical configuration.

Possible Interpretations

So now the interesting question becomes: are our results coincidence or cause and effect? Are enterprises, or the OpenLogic selection process, consciously choosing Apache licensed software over GPL licensed software, or is there some other phenomenon at work?

Enterprises may prefer the Apache license over the GPL due to the fear that they will unintentionally have to open source their software. This fear is a common myth; any enterprise required to license software under the GPL could just stop using and distributing the GPL licensed software. In all of my conversations with enterprises, I've only run into one that had "an absolutely no GPL software" policy, although several of them have a "no GPL except Linux" policy. But many attorneys I speak to prefer Apache licensed software over GPL licensed software.

The Apache Foundation produces very high quality software. While anybody can create a new project on SourceForge with no review or vetting, creating a project on Apache.org requires following a rigorous process. Finally, many enterprises are doing Java development and many of the Apache projects, like Struts and Tomcat, are geared towards the Java developer.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!