First and foremost, let me immediately start saying that this article is not legal advice, but it’s my attempt to explain in a simple way the problems connected to software licensing: in case of emergency, call a lawyer 🙂
Many people think that because you can download a piece of software without paying a fee it means that such software is free. But if something is freely available, it does not mean that the same thing is free to use. Some development teams have the expectation that, when including a software component in their own customised system, it simply becomes “part of it” inheriting their licensing model: this is simply not true.
Imagine, for example, that you are building a new revolutionary car, all electric, and self-driving! You will need a lot of software to make that happen, and certainly, you do not want to code everything from scratch. So you start first assembling some basic components, an operating system (Linux), some basic tools (BusyBox), some software from other vendors and then you finally write your magic code. Sounds familiar? Anybody said “Tesla” in the audience? And what happens when a competitor discovers that you are using open source software with a certain license (GPL) and asks you to provide them with your code, the valuable code you wrote… well, they can lawfully do so and you will have to comply! And so that’s what happened, and forced Tesla to start releasing its software on public repositories. But please, without leaving the car making business, see also BMW who handed over its i3 car code to a random guy, who immediately published it on GitHub.
Thankfully, not all open source licenses are so harsh. Read our blog: Open Source Licensing- The Weirder the Better, to see some more light hearted component’s conditions of use.
It’s important to understand the restrictions you face when you decide to use an opensource component. Even one single component with the wrong license can impose a restriction on all your source code.
- you may be forced to release your code under the same license. If you use a component licensed for example under GPL or AGPL (or even LGPL in case of derivative work), all your software will have to be released with the same license.
- you may be forced to release to the public your source code. If you use a component licensed for example under MPL or GPL, you will have to provide all your code in a human-readable format upon request (distribution of obfuscated code is not compliant).
- you may not be allowed to distribute your software commercially. Licenses like the Oracle BCLA will prevent that, and you can easily be sued (and you will most certainly lose).
But wait, what about the code that does not have any license? For sure I can use it without problems, right? And the answer is again a resounding no! Under current law, copyright extends for the life of the author plus 70 years (and sometimes 120 years after its creation), and the creator (or his/her dynasty) can simply sue you for using it. Unless a piece of code includes a license, do not use it.
If you decide to not comply with a license, or you are simply unaware of the problem (this would be the most common case) you face two main risks.
First, you are in actual violation of contractual obligations. This can lead to a long case in court that, if you are lucky, you settle outside court, with money transferred. There are a lot of examples of that, with payments that go up to $100K (please see an incomplete list here), so I really think you should not discount this risk, also because in some cases, firms preferred to file for bankruptcy in order to avoid bigger losses.
Second, you may be in violation of statutory law, a corporate liability that may become also a personal liability. Corporate Criminal Responsibility derived from copyright crimes can also be extended to labour law, in case it can be demonstrated that the responsible was not carrying out his duties properly.
First and foremost you need to be aware of the problem. If you read this article until this point, you now probably are, so we can safely assume you are onboard with this point.
Now, assuming your company is building software, you need to make sure that all components your development team is using, and end up being part of the final product, are accounted for in terms of licensing. Remember: one single component in your chain can influence the whole system.
You will need then to create policies to allow/disallow certain licenses to be used and enforce them across your development teams. The best solution would be an automated one, which automatically detects violations and blocks unwanted releases.
Similarly, if you are looking to assign a license to your own proprietary code, read our blog: Which Open Source License is For You for an introduction to the world of open source licensing.
Meterian to the rescue!
Meterian, among others, provides an elegant mitigation for this problem, which is also affordable and efficient. By placing Meterian in your development pipeline you can have continuous reporting about the licenses used by your software so that you can make sure you are not exposed to the risks explained before. Please have a look at one of our reports.
When Meterian is included in your development pipeline, policies can also be enforced so that the presence of certain licenses will stop the build to progress further, preventing the product to be shipped to the final customers.
Make sure to get in touch if you want to learn more!
8 thoughts on “How the wrong license can harm your business”
[…] bottom, you will find our licensing section, that will tell you if any of your components are using a non-business friendly license. But what about the middle section, […]
[…] that developers do not write. And, by the way, it also checks component licences, but this is for another blog post […]
[…] How the wrong license can harm your business […]
[…] always know what licences are tied to the software they are using to avoid an IP breach. Read our ‘How the wrong license can harm your business’ blog post, if you haven’t […]
[…] How a license can harm a businesslearn about the mechanisms that drove Tesla and IBM to release in opensource some of their software in order to fulfill compliance requirements in licensing […]
[…] We hope this quick read has shed some light on the world of license compliance management. Whilst it may be confusing at first, it is worth taking the time to pick the right license for you and your project to best publish your software and display your innovation. For more information on potential risks associated with license compliance, see our past blog: ‘How the wrong license can harm your business’. […]
[…] 8 Bossola, Bruno. “How the wrong license can harm your business”. Meterian, 22 May 2019 https://blog.meterian.com/2019/05/22/how-the-wrong-license-can-harm-your-business/ […]
[…] open-source components and license compliance is a very complex task, you can read an explanation in this article. However, in this instance and based on the SFC analysis, an entire open-source licensed platform […]