Dealing with Patents in Software Licenses, Part II
Last month I wrote about different categories of software patents and their effects on open-source and free-software licenses. I left the final category, licensee patents, for this follow-up article. This category is more subtle than the previous two. Here, we are dealing with a licensee's own patents or, perhaps even more important for derivative works, the patents of downstream sublicensees of the open-source software. Licensors sometimes include a patent-retaliation clause in their licenses to help defend themselves against infringement claims. In essence, a patent-retaliation clause says that if a licensee (or a downstream sublicensee) sues the software licensor for patent infringement, the license to the software terminates; a licensee or sublicensee can't both use the software and also sue the licensor for patent infringement.
One open-source software licensor justified its use of a patent-retaliation clause this way: “Maintaining the defensive use of patents will minimize unfairness.”
There are two general forms of a patent-retaliation clause. The first, a so-called weak patent-retaliation clause, says something like this: if you take a license for my software, and you later assert your patent against me relating to this software, then your license for my software is terminated. The same patent-retaliation clause usually applies to your sublicensees; if one of your sublicensees sues your licensor for patent infringement, your sublicensee's license to the software is terminated.
I personally support weak patent-retaliation clauses in licenses because I think they fairly balance the interests of the licensor and licensee. Licensees and their sublicensees should not be able to benefit from free and open-source software, while at the same time forcing the licensor to pay royalties for patents embodied in that very software.
A so-called strong patent-retaliation clause says something like this: if you take a license for my software, and you later assert your patent against me relating to anything at all, then your license to my software is terminated. Again, this patent-retaliation clause also usually applies to your sublicensees.
I personally believe that strong patent-retaliation clauses harm the Open Source community far more than they help licensors, because companies with large patent portfolios will resist adopting open-source software if the software licenses effectively allow licensors to infringe the licensees' (or sublicensees') other unrelated patents with impunity. Indeed, as a licensee of open-source software, you may find that a strong patent-retaliation clause inhibits your ability to disseminate derivative works. Your downstream sublicensees may refuse to accept such a virus that affects their ability to enforce their unrelated patents against your licensor.
Apple is an example of a company that insists upon including strong patent-retaliation clauses in its licenses. If a licensee adopts certain Apple software, the licensee's use of that Apple software is conditioned upon the licensee not suing Apple for patent infringement in any other matter. So to the extent that Apple's software becomes widely used, perhaps even indispensable, in a licensee's company, Apple can now infringe any of that licensee's other patents without fear of an infringement suit. A company with a large patent portfolio might be reluctant to adopt Apple software if it means, in effect, permitting Apple to use all of its other patents. In fact, I probably would warn any client of mine to consider avoiding Apple's open-source software for that very reason.
I used the terms weak and strong to describe the two forms of a patent-retaliation clause, but those terms may convey, in common usage, the wrong idea. I don't mean weak in the sense of lacking strength, energy or vigor. And I don't mean strong in the sense of either physical power or economic or financial robustness. Rather, what I intend to convey is the degree of pressure that can be exerted by the licensor to defend his or her interests against a licensee. A weak patent-retaliation clause only can be asserted in limited circumstances for a relatively small set of patent challenges. A strong patent-retaliation clause, on the other hand, can pressure a licensee to refrain from a patent challenge even for unrelated patents.
Whether you license your software to others or take licenses to software for your own use, you should make sure that you can live with any patent-retaliation clause you find in the license. If, as a licensee, you don't have (or intend to have) any patents that you can assert in retaliation, you may be able to live with either of the patent-retaliation clauses. On the other hand, if you intend to sublicense your derivative works, consider what form of patent-retaliation clause your sublicensees can accept. And as a licensor, consider how you later may be able to respond to a patent threat. Consider including a patent-retaliation clause if you need to use your software to help defend yourself against your licensee's patents.
Legal advice must be provided in the course of an attorney-client relationship specifically with reference to all the facts of a particular situation and the law of your jurisdiction. Even though an attorney wrote this article, the information in this article must not be relied upon as a substitute for obtaining specific legal advice from a licensed attorney.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- Designing Electronics with Linux
- What's the tweeting protocol?
- Kernel Problem
2 hours 16 min ago
- BASH script to log IPs on public web server
6 hours 43 min ago
10 hours 19 min ago
- Reply to comment | Linux Journal
10 hours 51 min ago
- All the articles you talked
13 hours 15 min ago
- All the articles you talked
13 hours 18 min ago
- All the articles you talked
13 hours 19 min ago
17 hours 44 min ago
- Keeping track of IP address
19 hours 35 min ago
- Roll your own dynamic dns
1 day 48 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?