GNU Affero General Public License:
Risks and Opportunities

By:  Paul H. Arne^[1],[2]

The GNU Affero General Public License[3] (“AGPL”) is a special license in the family of open source licenses, creating risks and opportunities that do not exist with most other open source licenses.  For a significant period of time after the introduction of this license in late 2007,[4] the use of this license was fairly limited.  Even though the use of the AGPL is fairly limited in proportion to other open source licenses, its use is now sufficiently prevalent that attorneys may come in contact with this license.  This article will examine (i) the history of the development of this license, (ii) portions of the operative language and its meaning, (iii) the potential problems to businesses that come in contact with this license, and (iv) examples of how the AGPL can be used effectively in business.

A Brief History

One of the true game-changing innovations in the software industry wasn’t software at all:  it was the publication of the GNU General Public License (“GPL”), Version 2, in 1989.  The GPL helped spur the creation of a new paradigm for creating useful software and is a significant — maybe the most significant — development in the history of the open source movement.

After more than a decade of use, various issues associated with the use and interpretation of GPL v. 2 had arisen.  These issues included the need to adapt the GPL to a less U.S. law-centric version, to respond to the rise of software patents, to address the use of open source with “appliances” that didn’t look like computers (such as digital video recorders), and to consider the rise of digital rights management (“DRM”) technologies and business models that used DRM.  As a result of these and other issues, the keepers of the GPL, the Free Software Foundation, decided to embark on a prodigious process of revising the GPL.

A part of the debate in connection with the development of the new version of the GPL was the result of the increase in throughput that was becoming available over the Internet.  As more and more data could be driven through the pipes of the Internet, it had become possible to offer the functionality of software to users where the actual software was housed on a server that was not physically close by.  Various implementations of this phenomenon are now known as software as a service (“SAAS”) and cloud computing, among other names.[5]

A fundamental purpose of the Free Software Foundation and the GPL in particular is to make software available for analysis, modification and distribution to those who use it.  Generally speaking, the GPL accomplishes this by using the exclusive licenses available under copyright law, specifically the exclusive rights of the copyright holder to create derivative works and to distribute copies, to require those who wanted to exercise those rights to also offer the source code to any recipient of the software for a nominal fee and to prohibit significant limitations on the right of that user to further modify and distribute the code.  This use of the exclusive rights under copyright law to prevent a licensee from using its exclusive rights under copyright is sometimes known as “copyleft.”

Because the copyleft features of the GPL are triggered by distribution, many in the open source community perceived business models that provide software on a SAAS basis as a fundamental and growing challenge to the open source movement.  While SAAS implementations allow the use of the functionality of software, it does not normally result in the distribution of the software itself.  Therefore, the functionality of software licensed under the GPL could be made available to users without being required to provide source code, modify the code, or allow further distribution.

By the time the new version of the GPL was being discussed, a number of technology companies had organized their technology offerings around the premise that software licensed under the GPL and provided on a SAAS basis would not be “burdened” with the GPL’s copyleft requirements.  The Free Software Foundation was faced with two opposing camps:  (i) those who would not support continuing use of the GPL if copyleft requirements existed for software provided on a SAAS basis, and (ii) those who viewed the absence of copyleft requirements for software provided on a SAAS basis as an affront to the basic underpinnings of the open source movement.

The compromise to these opposing positions was the development of a new, separate license:  the AGPL.  Those who want to require copyleft for software provided on a SAAS basis could use the AGPL.  Those who did not could use the new GPL v. 3.

The Reach of the AGPL

For a significant period of time after the AGPL was released, very few software programs utilized this license.  That is beginning to change.  On a widely known website for open source projects, SourceForge.net, the five most popular software packages licensed under AGPL were downloaded over 19,000 times in the week that this article was prepared.  There were 670 software packages that were licensed under the AGPL.  While these numbers pale in comparison to other open source licenses,[6] the use of AGPL is prevalent enough that lawyers who are faced with software issues from time to time have some risk that they will be faced with the AGPL in their practices.

Operative Provisions of the AGPL

Other than the language in the Preamble, the words used in the AGPL and the GPL v. 3 are identical until Section 13.  Section 13 provides in part (bracketed language is commentary of this author):

Notwithstanding any other provision of this License, if you modify the Program [i.e., the software program licensed under the AGPL], your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

In other words, if one allows software licensed under the AGPL to be accessed over the Internet as a service, without distributing a copy of it to anyone, the source code of the software must be offered to those who access the functionality.

Perils of the AGPL

From at least this attorney’s perspective, the AGPL presents problems in two contexts.  First, the use of software subject to the AGPL can negatively impact a business when its IT professionals ignore or blithely discount the importance of the actual terms of the open source licenses for the technology they use.  Because the AGPL is the only open source license that is widely in use that requires an offer to provide source code to those who use the software on a SAAS basis, “normal” albeit uninformed IT expectations regarding the requirements of open source licenses may not be consistent with the actual requirements of the AGPL.  Not all companies have procedures and processes in place to vet computer code before it is used.  When AGPL code is used as a part of a software program that is intended by the business to be proprietary, the consequences can be very negative to the business.

Second, the AGPL can be problematical when the business model or expectations change in a way that is inconsistent with the requirements of the AGPL.  This is a potential problem especially in the context of an acquisition.  For example, if an acquiror company with a SAAS product wants to extend that software through the purchase of technology or of a target company with technology, the target’s use of software licensed under the AGPL can be a deal killer.  The absence of appropriate diligence to identify whether AGPL code is used can be a career limiting move for any attorney or business development person tasked with due diligence.

Strategic Uses of AGPL

Certain business models lend themselves to the use of the AGPL.   Here are a few examples.

A company (“Developer”) is involved in dual sourcing — releasing software under an open source license while also offering to license the software under a proprietary license.  This business strategy can be appropriate in many situations.  The release of the software using an open source license for free or a greatly reduced cost allows a potential licensee to try the software with little risk.  If the licensee later desires to receive services that are not available with the open source license, such as error correction services, training, implementation services, and even operation of the software on the licensee’s behalf on the Developer’s servers, then the licensee can approach the Developer for a proprietary license.  One of the needs of the Developer is to avoid having a third party take the open source product and use it to compete with the Developer, in essence getting a free head start in developing a competing product.  Normally, the Developer can prevent this kind of competition by licensing the open source product using the GPL or LGPL.[7]  However, if the product can be effectively provided as a service, under a SAAS model, the use of the GPL or LGPL will not prevent a competitor using the open sourced software competitively against the Developer.  Use of the AGPL closes that loophole in the business model.

Expanding the example above, the AGPL should be at least considered for use with any software product in any business model that has a strategic reason for developing and supporting an open source product licensed under an open source license having copyleft features.[8]

Conclusion

As with many things in life, Sir Francis Bacon’s famous aphorism, “Knowledge is Power,” applies to the AGPL.  The presence of the AGPL will cause anxiety for attorneys who practice in this area.[9]  Nevertheless, the AGPL is a tool that, properly used, can be very useful in helping certain companies achieve their business objectives.

[1] Paul is the co-chair of the Technology Group of Morris, Manning & Martin, L.L.P. He is also the founder of the firm’s open source practice group. This article does not create an attorney/client relationship with you and does not provide specific legal advice to you or your company. Certain legal concepts have not been fully developed and certain legal issues have been stated as fact for which arguments can be made to the contrary, due to space constraints. It is provided for educational purposes only.

[2] Copyright © Paul H. Arne, 2010. All rights reserved.

[3] Specifically, Version 3 of the GNU Affero General Public License, promulgated by the Free Software Foundation.  There is an earlier open source license known as the Affero General Public License that was not published by the Free Software Foundation, which is not addressed in this article.

[4] The official date of the AGPL is November 19, 2007.

[5] For ease of discussion, in this article all such remote offerings of software functionality are referred to as SAAS.

[6] At the time the information on SourceForge.net was checked for this article there were over 3.5 million downloads of open source software that day and there were over 270,000 software projects available on SourceForge.net.  The most popular open source software, 7-Zip, had been downloaded over 112 million times over the life of that software.

[7] The Lesser General Public License, also promulgated by the Free Software Foundation and, for this purpose, having similar characteristics to the GPL.

[8] In addition to the GPL and LGPL (and AGPL), these licenses include the Mozilla Public License, Common Development and Distribution License, the Common Public License, and the Eclipse Public License.

[9] Especially when first evaluating open source use for a client and in M&A activities.