Which Open Source License Should you be Using?

Your Open Source License 101 course (assuming you manage developers in an enterprise). I've written last week about the acquisition of Jitsi by Atlassian. It has spurred some comments around open source licensing, so I decided to write this post. This way, there's more room for more licensing related comments.

If you are looking for a good overview of open source licenses and what they mean, then the best resource I've found is Smashing Magazine's explanation. What I want to touch are some business aspects of these licenses, and what my past 10 years or so in the commercial software business have taught me. - To begin with, open source is great. It reduces the time it takes to develop a product these days, and frankly, I don't believe there are any more products or services that don't rely on open source. While it is essential, you can't really use open source in a business setting without understanding its implications.

Why would you want to use open source?

1. Because it is reduces time to market and the effort required
2. Because if the module you use is used by many, it is probably robust (but not necessarily)

Why would you want to refrain from using open source?

1. Because you may need to open up your own project/product/service to the world, which leaves you exposed
2. Because there might not be a support contract option attached to it

What are the licenses that are out there?

• Open source licenses come in different shapes and sizes
• The most common ones today are known as AGPL (Affero), GPL, LGPL, APL (Apache), MIT and BSD
• From a business perspective, for the adopter of the license:
  • AGPL is bad. Don't touch it with a ten foot pole
  • GPL is bad if you sell a product. Not so bad if you want to sell "as a service"
  • LPGL is somewhat fine, assuming you treat the module you use as a standalone process
  • APL, MIT and BSD are great for your health
• You can categorize open source licenses into permissive and non-permissive licenses
  • AGPL, GPL and LGPL will be considered non-permissive, as they require you to contribute back to the community (I know we're all hippies these days with open source, but we're also running a business)
  • APL, MIT and BSD are considered permissive, where the most you need to do is maintain the copyright notice "somewhere" and indicate your use of the module in question. You are not asked to contribute back
• Most businesses with a clear open source policy will tend to approve open source modules with a permissive license and either reject or require a special approval (and longer scrutiny) of open source modules with non-permissive licenses
• Most popular projects in recent years have tended to go with APL, MIT or BSD
  • Google's WebRTC is BSD
  • Ericsson's OpenWebRTC is BSD
  • Hadoop (popular Big Data project) is APL
• Where AGPL, GPL or LGPL are used AND the project is popular, there is usually one of two options:
  • A dual licensing scheme, where paying customers are granted a commercial license in replacement of the open source one
  • The project is targeted at the web itself, where running "as a service" is the norm. Wordpress, for example, uses GPL and is still hugely popular
• There is no single way of interpreting many of the open source licences
  • Don't trust me? Read the debates around GPL in Wordpress, Themes, Plugins and derivative works
  • This ambiguity means that a business may not be able to use a non-permissive license without exposing itself in some way to future litigation

Why are non-permissive licences bad for you?

There are many reasons why selecting a module with a non-permissive license doesn't work in your favor - again - I am speaking about a business with commercial aspirations:

• Non-permissive licenses exposes you to litigation. If it is found out that you have used open source in your product, but haven't complied with its license, you may be asked to give your source code away to the public:
  • There's a know story about Cisco and Linksys routers that forced Cisco in 2003 to open source its Linksys WRT54G stack
  • In 2009 Cisco settled in court, yet again, around open source use in its Linksys routers
• There are strict rules about what you have to comply when you use a non-permissive license
  • These rules may be a hassle - setting up an external repository of the code, maintaining it and its versions, making sure it is up to date, etc.
  • Developers may not be aware of all these rules, and miss some of them - opening you up to litigation again
• You may not want to expose the work you are doing with this module
  • You might have optimizations in it that you want to save for yourself
  • There might be calls you make to some internals you use that you don't want exposed
  • You may need to integrate the module directly to another module with a conflicting license (GPL for example, doesn't play nicely with commercial licenses)
• If in the future someone will want to acquire you, this exposure will be factored into your price (i.e - reducing your price against the effort of getting rid of the open source module in question)
• These pieces of open source modules require administrative care and attention (=overhead)

So what do you do?

• If you are going to use open source (and you are), make sure you put a policy in place
• Make sure that policy is worked out with the help of a lawyer who understands open source (most of them don't)
• Make the procedures as simple as possible
• Document every piece of open source code used in your product and service - you'll need it in the future
• Think of using commercial tools that scan for open source code. Palamida and Black Duck are examples of such tools

Me not a lawyer

Just as a clear disclaimer: I am not a lawyer. What I know of this is by being responsible for open source policies in a business unit who sold software tools, working with lawyers about open source issues and a few due diligence projects I've been taking part of (both as an acquirer and as a potential acquisition). Talk to a lawyer if you want to get confused further about this.