Over the last two decades, open source software has become a pervasive part of the IT landscape. The Linux operating system, the Firefox browser, the Apache web server, the GNU compiler suite and the X11 windowing system are all well-established – and, many would argue, indispensable. Of course, enterprises and organizations of all types are enticed by the prospect of changing, improving and even distributing a “found” resource to suit their needs and those of the potential markets they target.

Yet the basic concept remains subject to a good deal of misunderstanding. The name “open source” itself is a bit misleading, because it’s not open in all senses.  Open source software is neither freeware nor public-domain. Although most open source is free, not all freeware is open source. For example, Adobe Reader doesn’t cost anything, but it’s not distributed as source code. Open source software is not public domain software either. The copyrights for public domain software have been donated to the public – an exceedingly rare occurrence. Open source software, on the other hand, has a rights holder who retains and maintains the software under terms of a license.

Personally, I love the open source notion, and I’ve written open source software myself. My simulation system (SimH) is open source, under a standard permissive license. Though open source has its benefits, it also has its pitfalls. Engineers and software developers who want to use it need to understand both sides of the equation.

As I mentioned previously, open source software is not free software. If I take on an open source package for a product or a services project, I am responsible for the package’s upkeep: validating it, integrating it, testing it and supporting it. Open source software comes with no guarantees. In fact, many companies have built their businesses on providing paid integration, testing, and support for “free” open source packages.

The bottom line is that, one way or another, open source software costs money. It’s just a question of whether I pay someone to do the validation, integration, testing and support, or whether I pay an engineer to do the work for me. I’m not saying that open source software is not a great deal because it does reduces development time and cost, but it most definitely is not free.

Another drawback to open source software is that it may come without warranties or indemnities. It’s my problem if I deploy an package for my company and it doesn’t work as advertised or contains bugs or malware. The author of the package typically cannot be held responsible. This is an important issue when it comes to government contracts, for which your company can face unlimited liability if its offerings malfunction.

The critical risk of open source software is that a variety of strings are often attached. The philosophical roots of open source lie with the Free Software Foundation (FSF), which advocates that software end-users should be free to use, study, share (copy) and modify software as they like. The FSF’s distinctive concept is copyleft (rather than copyright), which seeks to ensure that open source software does not become part of a proprietary, closed source package. Thus, some open source software severely limits what the end-user can do.

This brings me to the knotty problem of open source licenses.

The English biologist JBS Haldane is said to have remarked that God must have an inordinate fondness for beetles, because He made so many species. Well, computer engineers clearly have an inordinate fondness for open source licenses, because there are hundreds, and they continue to proliferate. Broadly speaking, those licenses fall into four categories:

  1. Permissive (or “do what you like”) licenses allow an end-user to do almost anything, including incorporate the open source package into a proprietary, closed source package. They typically have just two conditions: you must reproduce the original author’s copyright; and you cannot sue the author under any circumstances. Examples include the MIT license, the BSD license, and the Apache license. My SimH system is licensed this way, so you can turn it into a commercial product if you want, but you can’t sue me, no matter what goes wrong.
  2. Semi-restrictive (aka “use but don’t touch”) licenses allow an end-user to deploy the open source package freely but restrict the end-user’s ability to make source changes and keep them proprietary. The best known example is the Lesser General Public License (LGPL), which is used for the GNU compiler’s run-time libraries. Users can link to these libraries without compromising their intellectual property, but any changes to the libraries themselves must be published in source form.
  3. Restrictive (licenses (aka “viral” or “entangling”) licenses require that end-user modifications to the open source package, or even new code that links to the package, be published as open source. The most famous of these is the General Public License (GPL), which is used for Linux. The GPL severely limits the end-user’s ability to maintain his or her intellectual property. Even the degree of distance needed to avoid “entanglement” is unclear. Most authorities believe that running in a separate address space suffices, but this has never been tested in court.
  4. Hybrid licenses. Many companies have their own open source licenses. While some are identical to standard permissive licenses, others may restrict access to source code for viewing or reference purposes. All require case-by-case review.

Because open source licensing is so complex, having a legal department to define a review process for products or projects is helpful. The first, critical step in this process is for the project team to understand the implications of adopting an open source package. When a company licenses commercial software, the vendor makes certain guarantees about the software package’s capabilities and provides certain forms of support, or even indemnification, if the software malfunctions. While there are support agreements for some of the major open source packages, many come “as is.” The adopting project team must take responsibility for making sure that the open source package works as specified, continues to work as the project evolves, and is fully supported by a third party.

Second, management must be both informed about and supportive of the decision to use an open source package. Because open source may carry short-term testing and integration implications, and long-term support obligations, the hidden risks and costs of “free” software must be explicitly included in the project schedule and expense estimates. Thus, management approval and support for the decision are required.

Third, the open source deployment must be reviewed and approved by the legal department, which often provides a website detailing the process and providing an overall tracking form. Typically, this form is used to track the proposed open source deployment through all its review stages. Once a license has been preapproved, the legal department can authorize non-modifying use of standard open source packages such as Linux. However, any other use of open source software with restrictive licenses must be reviewed on a case-by-case basis. Previous approval of a restrictively licensed package for a particular use case does not imply approval for other use cases.

Beyond the approval process, use of open source software places other obligations on the engineering team. Virtually every open source license requires inclusion of the license text if the open source software is redistributed. Some have restrictions on the use of the package name for advertising or in documentation. It’s up to the engineering team to understand the fine points of the license and to maintain compliance with its terms for the life of the product or services offering.