Open source software is great, but proceed with caution. Done well and with a well thought out strategy, this can be a powerful arsenal in your tool set. But done incorrectly, it can be a security risk and a huge waste of time, energy and resources. Everyone, from developers to the C suite, needs to understand the key concepts related to open source licensing. I noticed a surprise lack of understanding, with basic assumptions (often wrong).
Sixty-five percent of companies contribute to open source projects, and more than 55% use open source in their production environments. Corn it doesn’t mean open source is the right choice for every organization or project. Although there are many benefits to using open source, too often developers fail to understand some key concepts related to open source licensing. If you make false assumptions about licenses, you will suffer the consequences, such as inadvertently agreeing to release your proprietary code or explaining your actions in court.
Understand what awaits you with open source licenses
There are three things you need to be aware of when using open source:
- What license are you dealing with
- The nuances of mixing different licenses
- If the source is really “open”
Let’s explore them in more detail.
1. Know what license you are dealing with
Many people assume that open source is a single entity and that everything open source operates under one rule of law. This is not the case. There are currently more 70 different open source licenses, and each has its own quirks and nuances. The good news is that only three licenses are used by the vast majority of open source software. They are the MIT license, the LPG (GNU General Public License); and the apache Licence. There are different versions of these licenses, but to keep things simple we will ignore the complexity of these versions.
These licenses represent two radically different models from open sources. The GPL falls under a classification called “Copyleft Licenses”. Simply put, if you modify/improve the source code of a GPL-licensed project, you must make all these changes. Think of it as reciprocity: I gave you source code to get you started; all I ask is that you return your edits to me and we all win. The Linux kernel is the most famous open source project under the GPL license. If you are not willing to contribute your work, this license is not for you.
The MIT and Apache licenses are the opposite and are classified as “permissive” licenses. The MIT license is the most permissive, so as long as they retain the MIT copyright message, users can do whatever they want with the code, including making changes. In most cases, with the MIT and Apache licenses, you can modify the code however you want, and you don’t have to submit your changes if you don’t want to. The penalty is that you’re stuck supporting your own version forever. But, if you make your changes (as you would with the GPL), the idea is that everyone wins, since there is always only one master version.
2. Mixing and matching gets complicated fast
In some cases, you can mix and match code associated with different open source licenses, but it can get complicated very quickly. For example, you can take MIT or Apache licensed code and mix it with GPL licensed code; but you can not take GPL licensed code and mix it with MIT or Apache licensed code.
It can even become more complex from there. For example, if you mix code whose licenses have conflicting requirements, it can sometimes make it impossible to create new software without violating the requirements of at least one of the licenses.
3. Not always as “open” as you might think
Most new open source projects are licensed under the Apache license, but the permissiveness of the Apache license allows vendors to play tricks, and most of them do. When you obtain GPL-licensed code, you are required by that license to provide the source code with it. The Apache license does not have the same requirement. So one of the tricks the vendors play is to say, “We’re open source,” but the publicly available version of the source code may be 12 to 18 months behind the version the vendor actually offers, which may be proprietary or available for purchase only and not yet available in open source.
Key Considerations When Using Open Source Software
When dealing with open source software, you should consult your attorneys early and often for legal advice. Beyond that, the two most important things are brand association and code registration privileges.
1. Maintain your brand
Open source users tend to associate a vendor with a specific open source project, for example, Data tax with CassandraWhere Mesosphere with My bones. If you use this open source in your own project, people may assume that your software is somehow related to the associated vendor’s product. As a result, you might find that you’re missing out on leads because customers searching for your product land on the wrong business webpage. In a few cases, some projects may support two or more companies/brands, such as Cloudera and HortonWorks for HadoopName. Although it does happen, it’s usually the exception. It is possible to break the brand association, but it is very difficult.
2. See who controls code recording privileges
The open source community has a term, BDFL, or “Benevolent Dictator for Life”. This is the person who has control over the source code of all or part of the open-source project. If a single vendor employs all the developers who have complete control over all aspects of an open source project, that’s pretty much tantamount to ownership. It’s becoming more and more common these days and, as the BDFL moniker suggests, you’re at their mercy if you need to make changes to the source.
Open source software users rarely understand this. They simply want open source because they perceive it to be cheaper and provides protection against vendor lock-in. But the reality is that even with open source, it’s very unlikely that they’ll be able to support the software themselves without access to the current version of the source code, which leaves them equally locked in. Of course, we can wonder if it would be cheaper.
Do your homework before committing to software
Open source is not a thing. It’s a complex set of things with many nuances to manage. Just as you would research and calculate the costs and benefits of a paid product, be sure to put the same rigor into choosing open source options. Pay attention to the licensing model of the open source software you are considering before committing. Consult with your attorneys, consider trademark ownership and association, and also consider who has registration privileges.