Open-source software is great, but proceed with caution. Done well, and with a properly thought-out strategy, it can be a powerful arsenal in your toolset. But done wrong, it can be a security risk and a giant waste of time, energy, and resources. Everyone, from developers all the way up to the C-suite, needs to understand the key concepts related to open-source licensing. I’ve noticed a surprising lack of understanding, with basic (often false) assumptions being made.
Sixty-five percent of companies are contributing to open-source projects, and more than 55 percent are leveraging open source within their production environments. But that doesn’t mean open source is the right choice for every organization or every project. While the use of open source conveys many benefits, too often developers don’t understand some key concepts related to open-source licenses. If you make false assumptions about licensing, you will suffer the consequences, such as inadvertently agreeing to disclose your proprietary code or explaining your actions in court.
Understand what you are in for with open-source licensing
There are three things you should be aware of when using open source:
- What license you’re dealing with
- The nuances of mixing different licenses
- Whether the source is really “open”
Let’s explore these in more detail.
1. Know what license you’re dealing with
Many people assume that open source is a single entity and that all things open source operate under a single rule of law. This is not the case. There are currently over 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 GPL (GNU General Public License); and the Apache License. There are different versions of these licenses, but to keep things simple, we’ll ignore the complexities of those versions.
These licenses represent two radically different models of open source. The GPL falls under a classification called “Copyleft Licenses.” Simply put, if you change/enhance the source code of a GPL-licensed project, you must give back all those changes. Think of it as reciprocity: I gave you some source code to start you off; all I ask is you give me back your changes and we all win. The Linux kernel is the most famous open-source project licensed under the GPL. If you’re not willing to contribute back your work, this license is not for you.
The MIT and Apache licenses are the polar opposite and are classified as “permissive” licenses. The MIT license is the most permissive, so as long as they keep the MIT copyright message, users can do whatever they want with the code, including making modifications. In most cases with the MIT and Apache licenses, you can modify the code as you wish, and you don’t have to give your changes back if you don’t want to. The penalty is that you’re stuck supporting your own version forever. But, if you contribute your changes back (as you would with the GPL), the idea is that everybody wins, since there’s still 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’t take GPL-licensed code and mix it with MIT- or Apache-licensed code.
It can get even more complex from there. For example, if you mix code whose licenses have contradictory 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’d think
Most new open-source projects are licensed under an Apache license, but the permissiveness of the Apache license allows vendors to play tricks—and most of them do. When you license code under the GPL, you are required by that license to supply the source code with it. The Apache license doesn’t carry the same requirement. Thus, one of the tricks vendors play is to say, “We’re open source,” but the version of the source code that is publicly available may be 12 to 18 months behind the version that the vendor is actually shipping, which might be proprietary or available for purchase only and not yet available as open source.
Key considerations when dealing with open-source software
When dealing with open-source software, you must consult early and often with your attorneys for legal guidance. Beyond that, the two most important things are brand association and code check-in privileges.
1. Maintain your brand
Users of open source tend to associate one vendor with a specific open-source project, e.g., Datastax with Cassandra, or Mesosphere with Mesos. If you use that open source in your own project, people may assume that your software is somehow connected with the associated vendor’s product. As a consequence, you might find that you’re missing out on sales leads because customers researching your product land on the wrong company’s web page. In a few cases, certain projects are able to support two or more companies/brands, such as Cloudera and HortonWorks for Hadoop. While this does happen, it is generally the exception. It is possible to break the brand association, but it is very difficult.
2. See who controls the code check-in 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 a part of the open-source project. If a single vendor employs all of the developers that have complete check-in control to all aspects of an open-source project, then it’s about the same as being proprietary. This is getting more common these days, and as the BDFL moniker suggests, you are at their mercy if you need to make changes to the source.
Users of open-source software rarely understand this. They simply want open source because they perceive it as costing less and offering protection from vendor lock-in. But the reality is that even with open source, it’s highly unlikely they’d ever be able to support the software themselves without access to the current version of the source code—leaving them just as locked in. Of course, we can debate whether it would be cheaper.
Do your homework before committing to any software
Open source is not one thing. It is a complex array of things with many nuances to contend with. Just as you would do research and make calculations about the costs and benefits of a paid product, make sure you put the same rigor into choosing open-source options. Pay attention to the license model for the open-source software you’re considering before you commit. Consult your attorneys, think about brand ownership and association, and also consider who has check-in privileges.
This article originally appeared on TechBeacon.