The secret sauce of software licenses: it may be bitter.

Friendly disclaimer.

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 :)

The problem.

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.

The restrictions.

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.

1. 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.
2. 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).
3. 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.

The risks.

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 payment 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.

Solutions.

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.

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 to 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!