Open source is one of the most amazing parts of software development and the technology industry in general. As a leading custom software development company, we have worked with open-source software in countless projects and this has helped us deliver high-quality applications every time. However, we’ve also found that many of our clients are not particularly familiar with what open source is, how open source licensing works, and how they can protect their intellectual property.
In response, here’s a compilation of some of the most frequently asked questions we get here at FullStack Labs when it comes to open source software and intellectual property rights. Let’s get started.
#1 Can I use open source code in my app?
Today, nearly all software development projects use open source software to accelerate development and get access to high-quality, peer-reviewed technology. After all, open source code is, by definition, publicly-accessible software that is eligible to be modified and shared by third parties.
As a client outsourcing software development, you can use open source software in any project as long as you comply with the licensing requirements (which are often pretty lenient; more on that later). And of course, it goes without saying that the IP for the source code of the open source software is still owned by the original developers.
So yes, you can use open source software in your app. In fact, that’s why open source software exists in the first place: so that people and companies all over the world can create better tech faster and easier.
#2 Can I use open source software and proprietary software in the same project?
It’s not rare to hear about organizations that are nervous to use open source because they fear losing their IP rights to the open source code owner or getting themselves into a vulnerable legal position. However, that’s not really the way things work with open source software.
For starters, open source projects exist on a spectrum. Just like there are projects that release 100% of their source code to the open source community, like Python and Go, there are also companies that use a combination of open source code and proprietary code, like Dropbox and Adobe. And there are also those who use 100% closed-source code. Most businesses today choose to be somewhere in the middle of the spectrum.
Why? Simply because using open source doesn’t have to be an either-or decision. Today, it is entirely possible to support open source, keep your app’s IP rights safe, and get the best of both worlds.
#3 How do open source developers protect their IP?
To protect their IP rights, open source developers use copyleft licenses. As you can imagine, copyright is the opposite of copyleft. The former is used to protect IP from being copied or distributed, and the latter is used to ensure that open source IP is copied and distributed following certain requirements.
Copyleft can be enforced weakly or strongly depending on the license.
- Weak copyleft: Copyleft is called “weak” when the open source software’s license only affects the original work and allows relicensing under different licenses. Sometimes, copyleft can be as weak as to allow relicensing under closed-source licenses.
- Strong copyleft: Copyleft is called “strong” when the source code must maintain the exact same license or when it can only be relicensed under other strong copyleft licenses. This often includes all future versions of the software, derived work, or any work linked to the source code.
Similarly, copyleft licenses can be classified according to their level of permissiveness, which can either be strict or permissive. The difference between the two is quite simple: strict licenses cannot be mixed with closed-source or permissive licenses, while permissive licenses can.
#4 How do I compare open source licenses?
As of 2021, there are over 80 licenses approved by the Open Source Initiative (OSI). For most use cases, it is recommended to compare them according to the uses they allow or prohibit and additional conditions like:
- Type of copyleft
- Level of permissiveness
- Obligation to add copyright or copyleft notices
- Patent granting to licensees
- Distribution and user rights
#5 How can I evaluate the risk of using software with different open source licenses?
The risk of implementing any open source licensed work can be determined based on the permissiveness of the license. The MIT, MPL, and GPL licenses are great examples we can use to cover the length of the permissiveness spectrum.
Permissive: Massachusetts Institute of Technology License (MIT)
Just like most permissive licenses, the MIT license (also known as the X11 license) doesn’t really impose any limiting conditions. It is used by industry-leading projects like Ruby on Rails, React, Node.js, and the .NET Core. Here are its characteristics:
- Weak: The license only affects the original work and derivations can be relicensed.
- Permissive: There are no restrictions as long as you keep the copyright notice when distributing new versions of the software.
- No warranties: The licensed software disclaims any implied warranties.
- Simple: This license is short and to the point. Most developers prefer it because of its simple implementation.
Semi-Permissive: Mozilla Public License (MPL)
The MPL license sits in the middle of the permissiveness spectrum since it shares similarities with both the MIT and GPL licenses. As you may imagine, the MPL is used by Mozilla Firefox and other Mozilla software, but it has also been used by companies like Adobe and Sun Microsystems. The following characteristics apply to the MPL 2.0, which is the current version of the license as of the publication date of this article.
- Weak: The license only affects the original work.
- Semi-permissive: Source code can be used along with software with any other type of license, including closed-source licenses. However, any individual files licensed with the MPL must remain open source and be made freely available.
- Non-viral: Mixing licensed work with other licenses is allowed as long as they don’t conflict with each other.
Restrictive: General Public License (GPL)
A few years ago, the GPL was the most used open source license in the market, but the popularization of permissive licenses has taken attention away from it. It was created by the Free Software Foundation (FSF) and it is used by the Linux Kernel and the GNU Compiler Collection. Currently, there is GPL v2 (1991) and GPL v3 (2007). These are their general characteristics:
- Strong: Licensed work can not be relicensed.
- Strict: Prohibits closed-source derivatives and mixing with permissive licenses.
- Viral: Any work linked to licensed software forces the entire product to be relicensed under the GPL.
- Embracing: Licensed software may embrace other open source software with compatible licenses, as long as the end result is relicensed with a GPL.
#6 Can open source software have multiple licenses?
Yes, open source software can have multiple licenses as long as the licenses don’t conflict with each other. For example, if you want to upgrade an app with a GPL, you can add MPL software to it and relicense the entire thing under GPL. Following the licensing restrictions, the MPL software will be double-licensed under GPL and MPL.
However, this is most common when merging permissive licenses with other permissive licenses or with restrictive licenses with merging exceptions. In strange cases, you can also combine code with different restrictive licenses, but this normally means that the final application cannot be redistributed, as the licensing restrictions will not be compatible with each other. Conflicts like these can only be resolved if the owners of the open source programs agree on changing the license or adding exceptions to it.
#7 What about unlicensed work? Can I use that?
It’s not hard to find unlicensed repositories on GitHub and, if you like the project, it might be tempting to fork it and use it for your own purposes. However, this is not recommended under any circumstances. Even if the source code has no publicly available license, you run the risk of being sued for using it.
So no, do not use unlicensed software. It is always best to be fully aware of what you’re getting into and what kind of restrictions (if any) you will be dealing with.
Conclusion
Avoiding IP and litigation risks when using open source software is pretty simple. Most licenses in this field are quite permissive and even the restrictive ones tend to have a few exceptions. That said, do not underestimate open source licenses under any circumstances. “Weak” copyleft is still copyleft and you must comply with any of its restrictions, as lenient as they may be.
If you’re looking for a truly no-risk approach, then working with a nearshore software development company is the way to go. The expert software developers at FullStack Labs know all about open source software licenses and we will help you determine whether or not a license can interfere with your product goals. Contact us today.
