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.

Open source license challenges

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

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 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.


Rahul Sadafule says:
April 28, 2015

I was wondering Tsahi if above analysis will change based on open source usage context for e.g. using in mobile client app vs using for mobile app back-end (PHP/Python etc). As even in back-end world (scripting such as PHP, DBs: MySQL, Frameworks e.g. Zend) there is so much of open-source used.

    Tsahi Levent-Levi says:
    April 28, 2015

    iOS is limiting when it comes to GPL I am told. Something to do with the App Store rules developers need to abide with. Not sure if that’s true or an urban legend.

    In general, it is easier to deal with non-permissive licenses on the server side – especially if what you sell in the end is a service and not something that gets installed somewhere else.

      Lennie says:
      April 29, 2015

      Looking back at this article the GPL forces more freedom for the software it is covered under because it does not allow more strict rules to applied. But the Apple store does have extra restrictions:

      I believe it eventually got solved in some way because I think VLC is in the appstore at this time. But I have no interest to look it up right now to find out how this is now done.

Lennie says:
April 29, 2015

There is a much more important reason that projects like WebRTC use the BSD-like license.

It is because they are trying to establish a standard, you want the reference implementation to be available for as many people as possible to include in their commercial closed-source applications.

For example, the creators of the GPL license, the FSF, also advised the developers from Xiph.org to use the BSD license for their OGG-codec-libraries many years ago to make sure the OGG-codec can be used by as many as possible. For example at that time many game developers used ogg for their sound files.

Tip: I think the Github also has a useful site:

    Tsahi Levent-Levi says:
    April 29, 2015

    Thanks Lennie.

    The selection of a license as someone who is writing the module is indeed important. I tried taking the view here of the person who needs to decide if he wants to adopt a module and how the license of that module affects the decision.

Sergio Garcia Murillo says:
April 29, 2015

Regarding AGPL, GPL and LGPL I think you got it wrong.

The main differences between them is that LGPL allows you to link against non-GPL code, GPL forces any linked code to be GPL, and AGPL forces any “used” code (linked, via network apis, etc) to be GPL.

Been GPL *just* means tha you have to make available the the source code to anyone that you provide the binary to whenever they request it. You don’t have to make it public, or contribute back to the project any change you make at all. As you say, AGPL would force you to make the source code avaiable to anyone using your service.

    Tsahi Levent-Levi says:
    April 29, 2015

    Thanks Sergio.

    From my own experience dealing with these licenses and talking to lawyers the main problem is that opinions vary as to what they mean – what linking pertains, what you need to offer and to whom. This makes these licenses problematic.

    As a quick question – does the fact that I am providing a GPL module in binary form to individual X means that if individual Y asks me for the source code is entitled to receive it? The answer is most probably yes, which ends up diluting a lot of the technological advantage vendors believe they have.

      Sergio Garcia Murillo says:
      April 29, 2015

      Talking with lawyers is not pleasant anytime! 😉

      According to the GPL v2, it is quite clear: (TL;DR yes, you need to provide also to third parties if requested)

      3. You may copy and distribute the Program [..] in object code or executable [..] provided that you also do one of the following:

      a) Accompany it with the complete corresponding machine-readable source code [..]

      b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

      So you either provide the source code alongside with the binary to your customer, or allow any third party to request a copy of it. But being precise, it do not force you to contribute back or make any change public. Not that it makes GPL any more business friendly thought.. 😉