In the “GPL intimacy” writings we mentioned how common it gets that the excuse “it’s ok, it is not linked” is adopted for justifying the usage of a given GPL software inside a closed-source product. Now we expand on this argument to look deeper about what it is involved and which consequences you should be aware about.

Basically, the “it’s ok, it is not linked” justification surfaces when company A develops software for company B. On most cases, it will happen around a meeting room filled with people where someone from company B asks about the GPL compliance for some of the components. The answer from person in company A will be a proud and simple “it’s ok, it is not linked”.

In some variations, you will find this kind of answer written inside an excel sheet or through an email discussion where this principle remains the same: “It’s ok, GPL only applies to linking scenarios”.

Without any doubt in mind I must say this is a very bad situation. If you are from company B (receiving the software) then you should really question yourself about the legitimacy of these claims from company A (developing the software for you). The goal of company A is to deliver a given software product under a specific set of technical and legal requirements that is restricted by costs of time and money. Licensing compliance is not typically a design feature, it is too typically seen as a burden to bear.

Don’t forget that company A saves money and speeds up their delivery when adopting open source software for things that they don’t need to develop in-house. Some of this software that is already available somewhere in the Internet will eventually be GPL. The big problem is that after you (as company B) receive the final product and sign the acceptance contract from company A, then you (as company B) also become responsible for whatever comes next.

If your aim is to keep full control over the result as a closed-source result that you want to distribute to other parties then the “it’s ok, it is not linked” type of answer should raise a red flag that the other party did not performed a serious and competent analysis of the GPL compliance for third-party software on their product.

This is a problem to you (as company B, receiving the software). Even if the development contract specifies that company A (developing the software) is still responsible for any legal consequence of non-compliance, the bottom point is that it will be your company seen as the “bad guy” by end-users and industry. And if company A is so “straightforward” in handing this situation, expect a complicated process to receive a compensatory retribution from their side to cover your loss (if ever).

To save yourself the trouble, please don’t buy into “it’s ok, it’s not linked” kind of justifications.

This kind of argument is quickly disarmed by the Free Software authors who might later oppose the way how their software was integrated within your application. The justifications for using GPL software should be tailored individually for each component, taking into the account the context where they are used. If you need an analogy then “no shoe fits all sizes” is valid for compliance analysis.

It is easy to fall into the temptation of assigning the same justification for all GPL components inside a software product, a mere copy & paste on the documentation that fits them all. However, this kind of work is plain trash (pardon my sincerity) from a licensing compliance point of view. In fact, it can even work to damage your efforts to prove that a competent handling of the licensing compliance took place. Copy & paste actions are not a sound licensing practice. Probably acceptable for a business person only interested in immediate profit, certainly not suited for an engineer from whom is expected a careful analysis of these situations.

Indeed, the task of proper justifications is a an intensive effort. It is not easy to write a custom justification for each component. The good part is that most of this work can be saved as research applicable for future use in other products. You get to know better the open source components and quite often they are re-used across the same organization. A trained expert on this matter can ensure that the documentation explaining the usage of these open source components is performed efficiently (and consistently), avoiding the copy/paste pitfall and addressing the need of a responsible organization to provide relevant justifications for the third party software.


TL;DR: Just raise your arm every time you hear “it’s ok, it’s not linked” in regards to GPL. Make sure that you get a truly relevant justification. Saves you headaches in the future.