A client this week asked me to help him with a source code license. What started as a simple request with crafting a paragraph inevitably grew due to the concept of “blocking intellectual property.” While I would argue that the document is still “simple” in structure, for the non-initiated it now probably looks like the Sunday crosswords in legalese, and without the results key.
Blocking IP is what may happen when a license to source code gets tangled in its own terminology. The reason why this occurs is that it is easy to forget that software can be legally protected under different forms of intellectual property rights. Let’s think of this as separate buckets of Lego® pieces: the bucket of copyrights contains different pieces than those in the patent bucket, the trade secret bucket and even the trademark bucket. But I may need all of these pieces for my Lego® creation, i.e., the license to the software.
The trickiest bucket can be that of the patent rights, because a patent (and this is what tends to be forgotten) does not give the right to make or do anything. A patent gives the patent-holder the right to exclude others from making that which the patent protects. In other words, having a patent does not give the proverbial little Troll under the bridge the right to cross the bridge, but it allows the Troll to stop all others from crossing that specific bridge. If the Troll gives you a patent license, you can cross the bridge if you want to, but not because you have a right to cross, but because the license gives you the right to cross that particular bridge without being bothered by the Troll.
Now, let’s imagine that the patent is not for the crossing but for the building of the bridge. What if you realize after crossing the bridge that putting guardrails in the bridge will make it safer and easier to cross? You may find yourself the holder of an improvement patent. However, the guardrails cannot stand on their own, by definition they are an improvement on the Troll’s patent, so you still need the Troll’s permission to be able to make and commercialize the bridge on which your guardrails stand. Likewise, if the Troll develops his own version of guardrails, you as the owner of the guardrail patent can stop (“exclude”) the Troll from building and selling guardrails. So this is what Blocking IP means: without the Troll’s permission for the underlying bridge you don’t get to sell guardrails and without your permission, the Troll does not get to put guardrails in any bridge.
When licensing source code it is customary to give the right to build upon and expand the code. This is usually done by giving the licensee the right to create Derivative Works. But this is a Lego piece picked from the bucket of Copyrights. This does not address the right to “an Improvement”, which is a piece from the bucket of Patent Rights. In other words, the described license does nothing to avoid the potential problem of Blocking IP, because it is only choosing pieces from the Copyright bucket. When choosing pieces from the Patent bucket, the licensor and the licensee can follow different avenues for not blocking each other, the most common are (i) granting each other prospective licenses in all future improvements; or (ii) adding a non-assert clause to the contract, where they promise not to assert claims of infringement against each other.
There are cons and pros to either avenue, depending if you are licensor or licensee and depending if your license is non-exclusive or vice-versa, but that is a matter ought to be explored in another blog entry.