Section 6 of the GNU Public License (GPL) version 2 states, in part, that “[y]ou may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” Naturally, the first thought that may come to one’s mind is: any condition that may cause the recipient to not exercise their GPL granted rights is a ‘restriction’.
However, is a condition that incentivizes a recipient from not exercising their GPL rights a restriction? Thus, a question is posed, can a developer incentivize a user to not exercise their GPL granted rights by refusing future services or versions of the software if such rights are exercised? To answer this question we need to delve a little deeper.
A Long Recognized Right to Do or Refuse Business
It is well established that a business has the right to choose its business partners as long as it does not infringe on rights granted by the US Constitution (e.g., equal protection, gender bias, etc.). A fundamental freedom and right —to do, or to refuse, business with another— was first recognized by the U.S. Supreme Court in United States v. Trans-Missouri Freight Association. In that case, a number of railroad companies had formed an organization to regulate prices. In the context of an alleged antitrust violation, the Court recognized that “a trader or manufacturer …[that] carries on an entirely private business, and can sell to whom he pleases; … he may cease to do any business whenever his choice lies in that direction… .” 166 U.S. 290, 320-21 (1897) [overruled on other grounds].
Some twenty years later, the Supreme Court had to address this issue again in another antitrust violation case, United States v. Colgate Co., 250 U.S. 300 (1919). In that case the Court found no antitrust violation by a manufacturer who refused to do future trade dealings with dealers who failed to adhere to the manufacturer’s policy. The Court held that no one could “restrict the long recognized right of trader or manufacturer engaged in an entirely private business, freely to exercise his own independent discretion as to parties with whom he will deal.”
This right was reaffirmed again by the Court in Monsanto Co. v. Spray-Rite Service Corp. 465 U.S. 752 (1984) (“A manufacturer of course generally has a right to deal, or refuse to deal, with whomever it likes, as long as it does so independently. ” Id. at 761, citing Colgate, supra).
Needless to state, American jurisprudence has long recognized that a person has a right to conduct, or to refuse, business with another even if it results in anti-competitive behavior in violation of the Sherman Act. Regardless of what the so-called open source experts may have claimed, this right, and the exercise thereof, is well settled and does not invite any disputed question of law by itself.
The Next Question
Given that the law recognizes a merchant’s right to do or refuse to do business with another, therefore, the next question is whether the GPL explicitly states that the developer has to give up such a right? Why? Because the GPL is a contract and a contract requires an agreement—a binding understanding between the parties—legally called the “meeting of the minds.” In other words, if the license or contract has terms that can be considered vague, ambiguous, or unclear, the law deems such conditions as unenforceable. This is so, because there can be no ‘meeting of the minds’ between the parties when a term or condition invites multiple interpretations.
The GNU Public License (GPL) Version 2
At this point, it is important that the reader understands the GPL, the rights it takes from the developer, as well as the rights it grants to the recipient of the software.
Just to recap, the GPL is an open source software agreement that governs how a software can be copied, distributed, and modified. The GPL requires that any software released under it needs to be distributed with its source code (that is, the code written by the developer) and that the recipient of the code has the freedom to further modify, copy, or redistribute the software. The GPL defines a “Program”, as any “work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.”
To enforce these provisions, section 6 of the GPL, in part, states that the licensee “may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” Since the GPL is a legally binding contract—and a contract requires an agreement between the parties—to release the software under the GPL, the software developer affirmatively agrees to the terms of the license. Section 0 of the GPL requires that the developer affirmatively grants the rights under the GPL by including a notice within the software stating that “it may be distributed under the terms of this General Public License.” This affirmative step clearly shows the developer’s intent to release the software under the terms and conditions of the GPL and abide by what is reasonably understood from within the four corners of the agreement.
Requirements of the GPL
Therefore, the developer understands that if they redistribute a software program under the GPL, they need to satisfy the following conditions:
(i) provide the source code
(ii) understand that they have granted the recipient permission to modify, copy, or redistribute the code,
(iii) do not impose any restriction on the recipient from modifying, copying, or redistributing the code, and
(iv) provide a notice that the software is being released under the GPL.
Clearly, the GPL does not expressly state that a developer ‘cannot exercise their right to refuse business with another for any reason’. There is no such explicit statement within the four corners of the GPL.
Now you may wonder, wouldn’t denying future business, only because one decided to distribute the software, be considered as a restriction under (iii) above?
Let’s address section 6 of the GPL!
Can a Developer Refuse to Do Future Business With a User Who Exercises Their GPL Rights?
Can section 6 restrict or limit a developer’s freedom to choose their future patrons simply because the software is released under the GPL? To determine the answer of this question, the legal boundary of the GPL must be considered in light of a developer’s inherent and well recognized right to refuse to do future business with the recipient of the software.
The Legal Boundary of Section 6 of the GPL
The GPL defines the “Program” as works that are limited to any work or portion of the software that has been released under GPL and affirmatively has the ‘released under the GPL’ notice on it. It stands to reason that the GPL only applies to works which the developer intends to provide to the recipient. Since, there is no explicit clause in the GPL that infringes or limits the developer’s right to deny future services, the developer can deny future services/versions if a recipient decides to exercise their GPL granted rights.
If the GPL intended to limit the developer’s inherent right to refuse service when a recipient exercised their GPL rights, it would have explicitly stated so—without any vagueness, implication, or ambiguity. However, section 6 of the GPL, at best, creates vagueness and ambiguity; it fails to clarify what is considered as a “further restriction.” In other words, it invites multiple interpretations. One could argue that perhaps the creator of the GPL was shortsighted and did not foresee this unintended consequence. Therefore, legally speaking, section 6 of the GPL fails to provide satisfactory ‘meeting of the minds’ in which the developer is supposed to understand that ‘further restriction’ also includes giving up their right to determine their future business partners.
Arguably, if the GPL explicitly (or implicitly) limited one’s right to choose their future business partners, Red Hat would have failed to become a multi-billion dollar, New York Stock Exchange listed, company since their business model started by refusing support to anyone who exercised their GPL rights. As succinctly stated by renowned GPL expert and free software activist, Bradley Kuhn :
The question comes down to whether or not telling someone ‘your money’s no good here, I don’t want to provide services to you anymore’ is a ‘further restriction’. I’m not persuaded that it’s a ‘further restriction’. I agree it’s an unfortunate consequence, but if we interpreted the GPL to say that you were required to keep someone as a customer no matter what they did, that would be an unreasonable interpretation.
In fact, those who would disgaree with Bradley Kuhn are themselves inviting multiple interpretations. Thus, even if “further restriction” was supposed to include a meaning that a developer could not deny future service to a recepient who exercised their GPL rights, since it has resulted in multiple interpretations, there can be no meeting of the minds, and thus the condition becomes unenforceable.
To summarize, it can be easily proven that the GPL does not explicitly limit a developer’s right to choose its future business partners. Further, those who disagree tend to hurt their own cause by inviting multiple interpretations, rendering the condition unenforceable.
The GPL Guarantees the Recipient’s Freedom to Share Software
While the developer cannot prevent the recipient from modifying, copying, or redistributing the software already in the recipient’s possession, the recipient has no affirmative right to demand or expect future service from the developer simply because they have the current version in their possession.
So What Recourse Does the Recipient Have? What About the Recipient’s Right to Freely Share the Software?
As stated in the preamble of the GPL, “General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.”
By denying future service or versions the developer does not infringe on the freedoms and rights granted by the GPL. Denying future service/versions is not a denial of, or a demand to surrender, GPL granted rights.Therefore, the recipient of the software should feel free to distribute the software, ‘fork’ it, create an alternative repository, and/or provide their own support. Just don’t expect the original developer to keep on providing services or support.
While it is within the right of the original developer to stop distributing future versions to the recipient who decided to create a fork of the code, he or she cannot prevent the recipient from exercising their GPL granted rights to freely share the software already provided to them.
Remember: The freedom to distribute the software is a right granted by the GPL, and a choice of the recipient to exercise anytime.
Conclusion
Since a developer has the freedom to engage, or not engage, with another, it stands to reason they should feel free to impose a condition related to future services contingent on how the user exercises their existing GPL rights. While such a condition may seem as a “further restriction” prohibited by section 6 of the GPL, it is not within the four corners of the agreement. Despite a future services condition, the recipient of the software still has all the rights granted by the GPL and legally no one can stop them from exercising such rights. However, the developer’s exercise of their right and freedom to do business with any entity of their choosing is an inherent right recognized by American jurisprudence. Neither the developer nor the GPL permits infringing on this right.