The tainting effect, explained

When lawyers talk about the GNU General Public License, they talk about it having a “viral nature” or “tainting effect”, which isn’t very flattering. Executives are often left with the impression that the GPL is like a litigious leper, spoiling all intellectual property it touches and turning it into free stuff. Executives don’t like their stuff being free. They want people to pay for stuff.

In what is possibly the clearest clarification of GPL’s tainting effect is tackled by a posting written by paralegal Pamela Jones of Groklaw fame. Basically, yes, if you are a programmer and you use GNU licensed code in a program you are writing and releasing to the public, your program must be released under the GNU GPL as well. This means also releasing the program’s source code.

For example, you are free to sell a GPL’ed program for fun and profit. The caveat is, you have to provide the source code, and you cannot stop someone else from selling the same thing.

The GPL is, however, non-exclusive. If you are the sole creator of a program, you can provide a free GPL version of your program + source code, and then turn around and sell an enhanced “Deluxe” version under a commercial license. And you don’t have to give out your code for the Deluxe version.

The tainting effect is misunderstood, sometimes even by intellectual property management. It actually only applies to specific cases of program distribution. For example, if you are just user of a GPL’ed program, the GPL does nothing to restrict your movements. You can copy or sell it as much as you please. That is the beauty of public licenses; while commercial EULAs are full of “do nots”, public licenses let users do whatever they wish.

The tainting effect only manifests itself if you, as a programmer, physically merge your code with that of source code licensed under the GPL. A proprietary program and GPL’ed program can sit on the same CD, without any fear of tainting. This is known as “aggregation”. A proprietary program can also intimately interact with a GPL’ed program, and retain its IP rights. For example, videocard drivers, traditionally chockfull of highly sensitive code, can run on Linux without fear of having their source code revealed.

You can even take a GPL program back to your organization, modify it, and be under no obligation to make your changes public, as long as you keep everything internal. You would only have to apply the GPL rules of distribution should you decide to distribute or sell the compiled code to the world at large.

In any case, even if your product has been tainted with GPL code, it does not mean you’re doomed. You still have a way out. You can consult with the Free Software Foundation, remove the GPL code and replace it with your own, and continue on your merry way. The FSF are often quite accomodating as long as your organization honestly made a mistake.

Incidentally, while about 85% of all open source software are licensed under the GPL, including Linux and The Gimp (which released Version 2.0 this week!), the GNU GPL is by no means the end-all and be-all of public licensing. Many open source programs such as Mozilla, OpenOffice and Apache operate under their own specially-designed public licenses which offer substantially more protection to a developer’s IP rights.