The Apache Software Foundation turned 15 yesterday, and its primary application the Apache Server Project turned 20 last month. According to its press release, half of the Internet is now powered by Apache products. Open source software has never been as mainstream as it is today, with thousands (likely more?) of different kinds of open source licenses and software modules available to software developers. Black Duck Software, a leading open source software risk management company, released a study of the most common open source licenses.

Open source software is sort of the misunderstood kid with freckles among technology companies (and I can relate) because many IT attorneys fear it, developers love it, and most other people in these companies don’t know whether to love or hate it. I think most companies would be crazy not to use some open source. However, just like the time you bought those “health” magnets on late night television, a little bit of initial research can go a long way before you start throwing open source into everything.

So why the controversy on open source software? Well, open source software tends to have oddly worded license agreements, require you to insert specific attributions and can threaten to open your software for public use if you aren’t careful. On the flip side, there are a lot of benefits from using mainstream open source software, which is community supported:

  • large support community
  • free or low cost
  • designed to be interoperable with other software
  • modifiable
  • up-to-date
  • easier to debug (or already debugged)
  • better annotated
  • easier for new employees to understand
  • reliable

Of course, there are a few significant, but manageable risks. The risks are:

  • some open source requires you to hand over your source code to licensees
  • if you violate an open source license you can get in just as much trouble as a commercial software license
  • not all open source software has been vetted and you often can’t vet it without testing it yourself
  • If you aren’t paying attention, your developers will completely riddle your software with it (both good kinds and bad)
  • It all comes “as is”

Many companies actually discover the weirdness around open source when they go to sell their company, and the buyer insists on a Black Duck or similar vendor review to prove what is in the software. These companies regularly audit all of the software in a company or a product to see who put what in there. You might be surprised what they find.

Not all companies have the same open source risks. For example, cloud/SAAS providers tend to have much lower risk than companies distributing copies of software. This is because most open source software licenses impose additional requirements at the point that you provide a copy of your software to a customer.

For example, the GPL License (version 2.0) requires licensors who distribute software derived from GPL software to license their modifications under the same license, without restrictions and to distribute source code with it. This means that when you transfer code to a customer, you can no longer restrict its usage. By contrast, when you license GPL (version 2.0) software for use in a cloud service, and you never share the actual code with a third party, the GPL (version 2.0) license really only requires that you annotate your changes.

The Apache License (version 2.0) is actually one of the more developer-friendly open source licenses. It allows developers to distribute revised versions of Apache software and attach their own custom terms and restrictions to the revised software.

The MIT license is another popular one, which has minimal restrictions.

Some other day we’ll get into more detail about the other requirements of these licenses.

Consider an organized approach to approving open source software in your business.

  1. Determine all the ways you use/license software (i.e., do your customers download it, use your software through an internet browser, is there a mix of downloaded apps and services?)
  2. Select 3-4 open source licenses that are compatible with your distribution model and authorize use only software under those licenses (just to keep it manageable)
  3. Create specific rules for your developers about how requirements for testing/approving open source software before it can be live in your programs
  4. Be intentional about the open source software you select and incorporate into your programs (it shouldn’t just be a shortcut)
  5. Prohibit all other types of open source licenses without management approval
  6. At significant company/product milestones consider performing a software code audit to determine what has crept into your software

I think the upside to open source software far outweighs the downside. The important part is simply understanding what you have and familiarizing yourself with the required licenses and the security risks associated with the particular open source software you select.

If you are interested in the history of open source software — explained using Legos:

Happy birthday Apache!

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.