No replies to this topic

[Brito]

This text is part of a book entitled “50 shades of GPL” that I am writing from scratch. The goal is to describe the nuances, interpretations and perspectives behind the analysis of GPL compliance. It is written with focus on software developers writing closed-source software that would like to integrate or interact with GPL components. The text is made available to public for gathering feedback. If you think that something is wrong or missing, let’s discuss.
 
:)
 
Comments, improvements and corrections are welcome. Good opportunity to share your experiences too. I will be placing the name of the people behind each relevant contribution.
 
My thanks in advance!
 
————-
The concept of “intimacy” in GPL is likely one of the most controversial and ambiguous points of this license. It is not described in any of the GPL editions. However, “intimacy” is described directly on the Free Software Foundation website at the FAQ page:
 
“Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. ”

http://www.gnu.org/l...MereAggregation

 
This FAQ entry is often used when defending the compliance or not of a given GPL component being used inside a closed-source product. It is stronger than the plain definition of linking to GPL component, this FAQ states the permission for a closed-source product to interact with a GPL component only up to a certain level.

What is the “value” of this level and how can we measure it? The value “depends”. Meaning that you will need to evaluate the context of everything involved and then do your best effort not to be caught red-handed in “intimate” interactions with GPL software.

How can we solve this problem?

As with any IPR matter you should start with your own investigation about the matter. As example, you can ask yourself the following questions:

1. Is GPL really the applicable license to this software?
2. Who are the authors, where is the website?
3. Since how long have these authors been developing the GPL software?
4. Is this GPL software associated to any commercial services/products/company?

The first question might sound redundant but what might happen sometimes is that any evaluation made in the past can sometimes induce everyone in error. Unless you have already checked the license terms in the past for the same product (and version) by yourself, you should really do this kind of check-up to be sure that no mistake exists.

When checking the applicable license terms, there are some simple methods that can be used:

1. Use a license database such as OpenLogic from http://olex.openlogic.com
2. Google for “abc license” where abc is the name of the software and look into the references
3. Look on the licenses mentioned on the public repository such as SourceForge or GoogleCode. Often also found on GitHub at the project introduction page
4. Look directly on the source code for the licensing information

These options should bring a wealth of information in regards to the applicable licenses. Hopefully they will all agree on the same direction about the license terms, if they don’t then this might indicate that at some point in time they have changed or that multiple licenses are applicable but only a few are referred. As a point of rule, you should be careful about the version number of the open source software. Per time the license version (and/or license terms) will change across different releases of the same software.

Once the license terms were confirmed. Time to learn about the authors and web references as mentioned on the questions 2 and 3 from our list, which by now you should have already visited to discover the license terms. There is usually a story to tell behind each open source product. Why there are people developing it; to whom it is intended; what problems and fights happened in the past. The merge of these details should bring to surface the reasons why the software exists in the first place. What you should be looking to understand is their vision about Free Software and how open they are to the idea of allowing the integration of their GPL’ed work inside a closed-source program.

If the GPL software is closely associated to a commercial exploration of any kind (say as e.g. MySQL), then the odds that the GPL author has a favorable understanding for “intimacy” that endorses the adoption of his software within a closed-source product will decline sharply.

For some software authors, “intimacy” is defined by “how far your closed-source system depends on my GPL software component”.

If your closed-source system has requirements (such as security) that are fulfilled exclusively by a GPL component, then exist grounds to effectively state that your system “depends” on GPL software even if no direct linking or connection exists because the principle of an “intimate” connection was proven.

This “intimacy” concept raises a fairly ambiguous situation. There are some possible options to consider:

a) Contact the author of the GPL component; explain the context where his work is being used inside your software product. Ask him if he considers your usage as compliant with the GPL terms of his work. Record the answer and include this justification on the final documentation

B) Remove the software component from your product, replace with an alternative way

c) Don’t contact the author, justify that no linking of any kind occurs and hope that nobody sends a letter one day complaining how you circumvented the spirit of Free Software

To ease understanding the above options, let’s go through the rationale behind each one.

Option a) opens the path to direct dialog with the author. It opens the way for the author to understand how you are using his software and to report back if he considers your usage as falling under the definition of derivative work or not.

The author’s opinion is important, don’t forget that only the IPR holder of the software (typically the author) can take you to a court of law for transgressing the GPL compliance. Therefore, his opinion on the matter should be seriously considered. Even without a legal process involved, it is this same author that will be feel impaired in case you do not incorporate his work in a correct manner. Therefore, do expect that this same author becomes the most vocal person demonstrating publicly his personal disagreement about your own understanding of GPL compliance. Given the impact of social media over the Internet, this might very well turn into a wild fire that burns your public credibility (either as a single person, company or group).

Option B) will likely become the least favorite option by the development team and management layers. It costs time, costs money and for the involved engineers will be truly disappointing to re-engineer something that was already solved before (and probably better) with open source software. This is the scenario where open source is a great match from a technical perspective but a risk too high to bear from a legal standpoint. Replacing the component brings losses to your side on a short term but solves a legal headache/risk on the longer term. Imagine the cost of ignoring this risk as more parts of the closed source system begin to depend on the open source component and the impact of this risk after the whole software is made available to the public or other companies.

This brings us to the last option c) that I personally don’t recommend because then your product becomes part of a “German roulette”. I’m introducing this term since Germany was the first country in the world where GPL has become admissible as a valid license agreement between two parties. The odds of escaping such a legal situation with GPL are pretty much the same as playing “Russian roulette”. Sometimes you might be lucky, suddenly you don’t.

Sticking to a plain justification that “it’s ok, it is not linked” will not suffice. Business people tend to neglect that they are dealing with “Free Software” and that this software is not really “free” to do whatever a business needs. It is necessary to understand the ethics and spirit behind this special kind of open source software, which is particularly designed not to make life any easier for those who pursue closed-source developments. If you’re closing your ears to all these things and repeating aloud several times “it is not linked”, “it is not linked”, “it is not linked”, “…”, then you will soon find yourself defending repeating these same arguments on a court of law where the judge won’t likely be so supportive of “business” goals.

TL;DR: Communication is key. If sufficient doubt exists, contact the software authors to get their opinion. If not possible, replace the software. If you ignore all these things then you risk serious problems in the future.
 
Click to reply and view full article