It is surprising to see that exists such a significant disconnection between the legal and technical fields on this matter. I’m not just referring to lawyers, I’m including engineers and managers as well. It is a human characteristic to interpret facts in regards to compliance licensing under a view that will be more inclined to support the needs of a given perspective which can be of legal, technical or management flavor. Somehow, a consensus needs to be found between everyone involved.

Without a connection to the context where the compliance analysis takes place, it is a problematic scenario when (for example) a manager inquires a legal team to evaluate the licensing implications of using a given software component without providing the gritty details of how it will be used. To some extent it is possible to provide an answer that holds no hesitation between a plain “yes” or “no”. The problem is that we also find different shades of gray where the answer is neither a solid “yes” nor a simple “no”. These are the situations where the only reply considered as fully correct will be the famous “it depends”. For such cases, you will invariably get different answers depending on how many lawyers you consulted and how well you were capable of providing the relevant technical context about what is being evaluated.

Last but not least, there are two other important facts to consider that are often neglected. The first one is that regardless of any legal opinion provided by a lawyer, the end result can only be decided by a judge in the court of law as the last decision point. To make matters worse, the same case at an extreme situation may well pass through different judges in different countries with different rulings altogether, quite honestly this just depends on who’s copyright you’re trespassing.

The second fact is the public opinion and heart that are also a concerning part of this matter. A voice of opinion holds typically no legal authority to force (legal) actions but it will certainly make a damage on the public opinion through the social networking channels and hurt the image for the company or organization that you represent. Does it really matter much that one has the financial muscle for winning cases in court, while society simply sees your group as a big bully that is non-compliant from an ethical point of view? Somehow, a balanced approach is required. It is necessary to adopt sound ethical principles that build mutual benefit on the long run.

When you decide asking for a legal opinion, there are some points you should keep in mind that will (seriously) help the lawyer to provide an informed answer:

• Give context. Explain how you are planning to use a GPL component, which requirements or functionality of the system is provided by this component
• Be specific. Don’t just ask questions like “can we use Red Hat?” and go deeper to provide the lawyer with specific details about what exactly you are using that is GPL. For example, “Inside Red Hat 5 we use GNU Tar, is this ok?”

These two points seem quite simple, but in fact they are too often overlooked. People usually look for an answer as if the understanding of a given license is the same for all cases and understood in the same manner by all involved parties. It is not. For example, what may be considered as a correct and safe procedure for a specific situation, will likely not be possible for a completely different software or context. Using a GPL tool to decompress files is one thing, using several scripts based on GPL tools to decompress the same files and perform other system actions becomes a different thing, even when both share the same license terms and binaries. The problem is called “context” and this is what really counts when considering compliance to a given set of license terms.

And when asked to be specific, it is something easier said than done. Rare times it is an easy task of providing accurate information. This requires creating documentation and investigating on the source code level which components are truly being used (or not) by a given software product. When using legal opinion, one can later use this output (when it is favorable to our side) as defense argument in court, saying that a given lawyer group has analyzed and sanctioned software components A, B and C as “ok” for a given context when later someone tries to prove otherwise. Still, legal opinions can be discredited if the technical facts show that these legal opinions were not grounded to a realistic understanding of the software system. Therefore, it is not really a sound strategy to only support your justifications on a legal basis, it is necessary to be technically accurate, specific and prove beyond doubt that all possible efforts were made to ensure compliance.

From recurring experience I can say it is bad news when you actually feel that need for consulting a legal opinion about compliance when using a given open source component. My friend, this means you are already in a situation of high risk. Should be seen as a red flag. A mental note to yourself as warning that when a situation becomes too ambiguous and fuzzy to be clearly justified, then it should probably be avoided as a safe precaution for the future. Remember that a legal opinion is just that, an opinion. An opposing party will seek lawyer opinion too, their opinion will be going against yours.

It is indeed a problematic point that more often than not, legal opinion is only sought as last mean of resort to justify compliance issues. It is not sought early enough in the process of development when there was still some time to prevent the chance of these ambiguous situations occurring in the first place, more time to prepare a strategy. The result that follows is invariably an attempt of trying to “clean” things in the background and in the meanwhile deny that anything is wrong. Well, this whole mentality and approach for handling of a software project is a problem on its own, let alone the Free Software compliance and technical issues that need to be dealt as well.

I should note that on this article I am biased towards a perspective of addressing non-compliance risks and that my perspective does not (always) match the needs or priorities from a business perspective. From the business side, it does happen the case where doesn’t exist budget for re-engineering a part of the system or we simply have no other options from a technical perspective. These are the cases where a less than perfect approach is required, where risks need to be measured and defensive measures taken. Never easy to find a balance.

In either case, whenever confronted with the need of choosing a legal team, please consider legal professionals with an engineering background, they do exist. The reason is simple, an engineer is more likely to have experience with the architectural details and language of software engineering to understand how software works on a deeper level. Therefore this person will likely be more comfortable in adapting himself to the context and go beyond the strict interpretation of license terms to a level where he actively works with engineers to define a feasible compliance strategy.

There is a much different dynamic between having someone on the legal side that is limited to a simple “yes” or “no” when compared to someone who says “no, because it is used on this way and becomes a deep dependency on your system”. This is where skilled expertise is required, this is how sound compliance justifications are brought to place.

 

TL;DR: Legal opinions vary. Even if “legally” possible, ask yourself if the usage of a given software under GPL “sounds” ethically correct to you. If you don’t have a sound reply that raised consensus, congratulations because you just entered the gray area of compliance. Expect dragons and trolls later ahead or avoid using that software component if you can.