It’s very common for developers to want to use open-source libraries and frameworks: open-source software is freely available, often robust and flexible, and using these tools makes the developer’s program easier to create when everything doesn’t need to be built from scratch.
However, some open source libraries and frameworks are distributed under particular licences that are specifically designed to prevent developers from bundling them into closed-source software. It’s important to understand how different types of open-source and free software licences work, and how you can use them in your proprietary software product.
Using code licenced under free software licences to build proprietary software is an easy way to quickly create what you want to build. Some software licences are specifically designed to prevent people from doing this type of activity, such as the GNU General Public Licence (GNU GPL). This type of licence is also known as a “viral” licence, because the terms of the GNU GPL spread to any code that you use it with. This means that you cannot use a GPL library in a non-GPL program, as once you use a GPL library, the whole program is required to be licensed under the GPL.
Other free software licences may be more permissive. For example, the Mozilla Public Licence (MPL) allows MPL source code to be used with other files that are covered by a different licence, including proprietary licences. However, the files that were originally licensed under the MPL must remain under the MPL and must be made freely available in source form.
On the other hand, you have completely open licences, such as the MIT licence and the BSD licence. These licences allow anyone to use the code in any way, including as part of proprietary software, and have no restrictions that require any part of the software to be licenced under the same terms as the original code that was used.
Other licences are designed to work together; for example, the MPL allows the code to be partly licenced under the MPL and partly licensed under the GNU GPL.
When you want to use a free software library or framework for building a proprietary product, it’s important to examine exactly which free software licence the library or framework is distributed under. It may not seem important, but different licences can have huge differences.
Now let’s take a look at what this means for the copyright of your software.
Partly, it depends on how you structure your software, and which exact licence the open-source library is covered by. So, for example if you used something covered by the GNU GPL, you would not be able to copyright and share your program under a proprietary licence. Let’s take a look.
Here’s an example from the GNU GPL. It shows that using open-source products under this licence cannot be integrated into a proprietary product without the entire product needing to be shared as open-source under the GNU GPL:
Clause 5 covers programs where the source code (licensed under GPL) has been modified. Source code means the original text of the code that the programmer wrote for the program or modifications to function. Source code is like the blueprint for the program, created by the programmer. The GNU GPL also includes another clause for if you want to share non-source code:
Non-source code (object code) is what the programmer’s code is turned into to be able to be ‘read’ by the computer. You can share the program in its computer-readable form if you meet the above conditions under clause 6 of the GNU GPL. One of the main ways that you can do this is that you can provide the corresponding source code on a durable physical medium for the purchaser. For example, you could provide a copy of your program to users, and a CD with the source code on it.
On the other hand, if you use a more permissive licence like the MIT Licence, published by the Open Source Initiative, you can copyright your product and share it in its entirety under a proprietary licence; there’s no need to share the MIT-licenced part under the MIT licence. Take a look at the terms of the MIT licence here:
You can see that the licence gives permission for the person to “deal in the Software without restriction”, which is very permissive and completely open.
Now let’s take a look about how to actually cover this in your legal documents.
If you use a licence that requires all of its terms to be passed on, you simply repeat that licence as your licence agreement. Have a look at this example from Audacity:
You can see that as Audacity is licensed under the GNU GPL, they have simply stated that the GNU GPL applies as the licence for Audacity.
If you need to include open-source software licence terms as part of a broader proprietary licence, here’s an example from Apple, that shows how they do it, under the Apple Public Source Licence:
Apple provides a list of all public-source components of MacOS for developers and students to view the code. The Apple Public Source Licence is one that allows free software components to be interlinked with proprietary software, and as such is not compatible with products that also use components licensed under the GNU GPL.
If you want to use something covered by a stricter licence, like the GNU GPL, you can use the GNU GPL library as part of a plugin that connects with your primary proprietary software. As long as you ensure that the plugin is not dynamically linked, you can share your software under a proprietary licence and distribute the plugin under the free licence.
Some licences mean that the original creator won’t be held liable for the open-source parts of the code you use. For example, the MIT licence is very permissive, but disclaims all liability and does not include warranties.
This means that if you use free software libraries, and something goes wrong with the code that causes your customer loss, you are still liable, not the original creator of the library. This of course depends on the exact terms of the free software licence, but many do disclaim liability in this way.
Here’s an example from the MIT Licence:
You can see that the software is provided “as is”, with no warranties, and a complete exclusion of liability.
The Mozilla Public Licence is also similar, in that it heavily disclaims any warranties and purports to limit all liability for software covered by the Mozilla Public Licence:
The Mozilla Public Licence clause is more extensive, but essentially conveys the same message as the MIT Licence disclaimer.
It’s definitely possible to use an open-source library with closed-source software, as long as you use a library that is distributed under an appropriate licence, and pass on any licence terms in the same way. Make sure that you review the terms of the licence your open-source library is under before you use it, so that you can be sure you can distribute your software the way you want to.
Flexera, a demonstrated leader in software installation, open source, software scanning, and software monetization has acquired ...
No one likes to be audited. On its own, the word “audit” implies wrongdoing or, at the least, carelessness. Opening the books ...