The Open Source Software ("OSS") community was founded on the notion that any party can use, modify and further distribute OSS, so long as that party contributes back to the OSS community the human-readable "source code" of any changes/ enhancements made to the software. Unfortunately, the Free Software Foundation's ("FSF")1recent efforts to revise the leading OSS license (called the GNU General Public License ("GPL")) have eroded this core "share-and-share-alike" principle. More specifically, the FSF's failure to fix a legal glitch in the GPL called the "ASP Loophole," and its treatment of certain OSS developers more favorably than others in terms of which of their OSS enhancements they are asked to contribute back to the OSS community, have relegated certain OSS developers to second-class status and have (along with other FSF missteps) caused dissension and division within the OSS community.
Closing The ASP Loophole - Or Not!
When the FSF initiated the process to revise the GPLv2 in 2005, many in the OSS community, including Linus Torvalds, a key contributor to the Linux operating system,2opposed this revision as unnecessary. The FSF ignored these protests and pressed forward, largely because of its myopic focus on using GPLv3 to prevent the growing number of licensing arrangements between OSS and proprietary software vendors, such as the recent collaboration between Novell and Microsoft.3As described in our previous article, this is just another example of how the FSF's ideological extremism has worked to the detriment of its OSS "constituents" and harmed the IT community generally.4
Notwithstanding their concern over the underlying motivation for the revisions, many of those initial opponents of GPLv3 believed that the FSF's unyielding push to revise GPLv2 at least presented a long-overdue opportunity to address one key issue of growing concern for the broader OSS community - the so-called "ASP Loophole." Unfortunately for them, this was to be an opportunity lost.
What Is The "ASP Loophole?"
An OSS developer may, through a "copyleft"5license like the GPL, give every person who receives a copy of the software permission to use, reproduce, modify and distribute the software to others, so long as the source code of any modification is contributed back to the OSS community for further use, copying and modification by others.6
The GPLv2 was written before the existence of the application service provider ("ASP") model, or, as it is now more commonly known, software as a service ("SaaS").7SaaS is a software application delivery model whereby a vendor develops a web-native software application and hosts and operates the application for use by its customers over the Internet. Popular examples of SaaS applications include Google DOCs8and Salesforce.com's customer relationship management applications.9The ASP Loophole "is the ability of running GPLv2 software as a service (SaaS) without returning any changes to the community, because distribution of software as a service might not technically be considered distribution of software (therefore circumventing the copyleft clause that made open source what it is today)."10
Google, for example, has drawn exceedingly from the collective efforts of the OSS community and built a multi-billion-dollar business upon GPLv2-licensed code using an SaaS model. But due to the ASP Loophole, it has not been required to share its most significant improvements with the OSS community. While such actions do not technically violate the GPLv2 and are understandable from a profit-seeking company like Google that has many shareholders and employees to think about, they also run contrary to the core share-and-share-alike principle noted above and which the FSF continues to apply - at least when it comes to certain OSS developers as described below.
Yet, despite the considerable pressure from the OSS community, the FSF chose not to close the ASP Loophole in GPLv3.11Why would the FSF fail to do so, particularly with respect to SaaS, which many believe will be an increasingly important business model for software use in the future?12Most likely, because the FSF needed all the support it could get during the GPLv3 drafting process - including from Google and other powerful OSS developers/users - particularly since several of the other changes to GPLv2 that the FSF was trying to achieve were not in the best interests of either the OSS community or IT users in general.13
Certainly, it is ironic, if not hypocritical, for the FSF to have designed the GPLv3 with the express purpose of impeding cooperation between OSS and proprietary software vendors, but also to have left untouched the ASP Loophole that contradicts its core share-and-share-alike philosophy and that harms OSS developers.
Some OSS Developers AreMore Equal
In the wake of its failure to close the ASP Loophole, the FSF has discriminated among various OSS developers regarding the application of copyleft restrictions and expectations. On the one hand, the FSF and its legal arm - the Software Freedom Law Center ("SFLC") run by Eben Moglen - have aggressively pursued and even sued certain companies, including very small OSS developers, for failure to comply with the copyleft principles of the GPL. For example, on September 20, 2007, the SFLC filed an enforcement action on behalf of the creators of BusyBox, a set of Unix utilities licensed under GPLv2, against Monsoon Multimedia, Inc., alleging copyright infringement for distribution without making source code available as required by GPLv2. The parties have since settled, but the terms of the settlement impose significant costs and burdens on the OSS developers, including a requirement to appoint an open-source compliance officer.14
On the other hand, Moglen and the FSF have told Google that, with respect to copyleft requirements for the SaaS environment, all that remains are the "ethical and community responsibilities to return at least those modifications that are not critical to [Google's] business and that are of general value to the community ."15Moglen sounded a similar theme in a recent speech he gave to Google employees, in which he stated:
"I see no sign in the near term of any desire to drive the copyleft commons in the direction of restrictions upon use by [SaaS] providers."16
"Where generally useful changes are made to copylefted software, the balance of equities should shift in the direction of public disclosure and re-contribution of those mods where there is no business purpose - no matter how little or large - to compel holding on ...."17
The above quotes are telling, for they reveal that the FSF and its principal advocates have postulated and applied a new test for contributing back modifications by certain OSS developers. Under this test, only where the OSS modifications are "not critical to the provider's SaaS business and are of general value to the community," or where "there is no business purpose to compel the SaaS provider to hold on to the modifications," would the SaaS provider need to consider contributing back. But this new set of rules is nowhere applied to traditional, non -SaaS OSS developers/users, who continue to be subject to the full complement of copyleft restrictions in the GPL.
A Word About The GNU "Affero" GPL
Last year, the FSF also released version 3 of the GNU "Affero" General Public License ("GNU AGPLv3"), a license that requires service providers to contribute back the source code for their applications that users interact with over a network such as the Web. While some may suggest that with the GNU AGPLv3 the FSF did in fact close the ASP Loophole, such a suggestion belies reality. The Affero license has been freely available for use for six years,18yet according to various OSS experts, "[t]he Affero licence is irrelevant because most GPL developers won't use it."19Moreover, a separate niche license like the GNU AGPLv3 can easily be targeted by corporate users to discourage its use. Indeed, the FSF specifically endorsed this possibility: "People who want to avoid code with this requirement can just blacklist the [GNU AGPLv3], and not have to worry about a list of additional requirements."20Finally, the FSF has recently acknowledged that "[w]hile [the GNU AGPLv3] is a helpful option for developers concerned about this use case, it doesn't guarantee users' freedom."21
Conclusion
In its refusal to close the ASP Loophole in the GPLv3 and its disparate treatment of different OSS developers on this issue, the FSF betrayed its own core share-and-share-alike principle and, in the process, has harmed the OSS programmers who support and abide by this principle. On one level, this behavior by the FSF was perfectly predictable: Saddled with ongoing allegiance to an overly restrictive and business-unfriendly GPL to begin with, this latest FSF action may simply highlight "the poor long term prospects of ideologies that deny the value of intellectual property rights."22Viewed differently, perhaps the FSF's preferential treatment of certain OSS developers stems more from its desire to ally with powerful entities like Google to help upend the proprietary software model and certain industry players like Microsoft in particular. Either way, one thing is clear: The FSF can no longer be viewed as the mouthpiece for the OSS community.23The FSF is not OSS, and vice versa. Rather, with every passing episode, the disconnect between the two comes into sharper focus.
1 The FSF is a non-profit corporation, founded in 1985, dedicated to promoting the right to use, copy, modify, and redistribute computer programs. See http://www.fsf.org/.
2 See http://www.informationweek.com/showArticle. jhtml?articleID=198002077.
3 See Andrew Orlowski, Moglen: "How We'll Kill the Microsoft-Novell Deal, " available at http://www.channelregister.co.uk/2006/11/20/eben_moglen_on_microsoft_novell/.
4 See Francis M. Buono & McLean Sieverding, "GPL Version 3: The Perils of Ideological Extremism," les Nouvelles, Volume XLII No. 3 (Sept. 2007), at 471-77 (noting that many OSS developers do not share the FSF's hostility to pro-consumer arrangements that enable the co-existence of OSS and proprietary software).
5 See http://en.wikipedia.org/wiki/Copyleft.
6 While the GPL is the most widely used OSS license, there are actually 60 OSS licenses approved by the Open Source Initiative. See http://www.opensource. org/licenses/alphabetical. Some "non-copyleft" OSS licenses - also referred to as "BSD-style" licenses (see http://en.wikipedia.org/wiki/BSD_license) - are relatively simple licenses that grant the right to use and modify the software, provided that the user includes a copyright attribution as specified by the author. Such OSS licenses are deemed to be more business-friendly, in that they allow licensees to modify and redistribute the software's source code as part of a commercial product subject to standard commercial licensing terms. Although at first glance one might think that the ability to incorporate BSD-style licensed code into commercial products would reduce the incentive to release code under such a license (as others could charge for it), in fact there are many business models for which this licensing approach makes sense. Indeed, Yahoo! contributes a lot of code to BSD-licensed projects. See, e.g ., http://sourceforge. net/projects/yui (BSD license used for Yahoo! User Interface Library hosted at Sourceforge).
7 See http://en.wikipedia.org/wiki/Software_as_a _Service.
9 See http://www.salesforce.com/.
10 See http://www.funambol.com/blog/capo/2007/ 03/gplv3-fsf-dropped-balls.html (emphasis added).
11 See http://www.fsf.org/blogs/licensing/2007-03-29-gplv3-saas/view?searchterm=asp.
12 See http://weblog.infoworld.com/openresource/ archives/2007/03/gplv3_goes_weak.html.
13 See http://www.linux-mag.com/id/3017; http:// radar.oreilly.com/archives/2007/07/the-gpl-and-software-as-a-serv.html.
14 See http://www.news.com/8301-13580_3-9808378-39.html. The FSF and/or the SFLC have also sued other OSS developers and users - often smaller, resource-challenged entities - for various other technical violations of the GPL. See, e.g., Andersen et al. v. Xterasys Corp., No. 07-CV-10455 (S.D.N.Y. 2007); Andersen et al. v. High-Gain Antennas, No. 07-CV-10456 (S.D.N.Y. 2007); and Andersen et al. v. Verizon, No. 1:07-cv-11070 (S.D.N.Y. 2007).
15 See http://www.cio.com/article/112050/Google_ Must_Share_Code_GPL_Author_Says (emphasis added).
16 See video of Moglen speech at http://www.youtube. com/watch?v=s70GazHTONU, at the 19:07 mark.
17 See id . at the 23:37 mark (emphasis added).
18 See http://en.wikipedia.org/wiki/Affero_General_ Public_License.
19 See http://weblog.ipcentral.info/archives/2007/04/ tony_healy_on_g.html; http://radar.oreilly.com/ archives/2007/07/the-gpl-and-software-as-a-serv.html .
20 http://www.fsf.org/blogs/licensing/2007-03-29-gplv3-saas. This blacklisting has already occurred in the marketplace. For example, despite requests by OSS developers, Google has refused to allow use of the GNU AGPLv3 for code posted to code.google.com, citing the license's "very little market share." See http://groups.google.com/group/google-code-hosting/browse_thread/thread/1714c5c0ef5d9f9f/7d59a938d295bb8f.
21 In fairness to the FSF, it apparently did recently organize a "summit" among "a small group of free software activists, thinkers, and scholars to identify the important questions that network services raise for free software and to start probing answers." See http://www.fsf.org/news/FreedomForWebServices. It is not clear what, if anything, will come of this effort, but it is no doubt in response to the dissatisfaction among OSS constituents noted herein.
22 See http://weblog.ipcentral.info/archives/2007/ 04/tony_healy_on_g.html.
23 See, e.g., http://www.linux.com/feature/115650 (describing dissension among OSS proponents with GPLv3, both substantively and in terms of the non-transparent process used for its updating).
Published May 1, 2008.
