Is an AGPL License the Right Choice for Your Open Source Projects?

It’s common for developers to think software licensing requirements are the express responsibility of the legal department. With so many open source components available and the implications of the licensing requirements, every developer should have at least a general understanding of what these licenses are and how each can affect their software.

Considering the downstream implications a project can run into, every team needs to review all license requirements for their software. Before releasing any updated or modified software, organizations need to conduct a complete license compliance audit, and doing this during every stage of the project can avoid issues in the future. One license teams should look into is the GNU Affero General Public License (AGPL).

What is AGPL?

Before discussing the AGPL license, it’s important to understand where it comes from. In 1988, Richard Stallman wrote his General Public License (GPL) aimed at enshrining the rights of creators to keep their software open source at all times. GPL is currently in its third version (GPLv3) due to issues with the previous text that created some loopholes.

As part of GPLv3, the Free Software Foundation (FSF) provided two additional types of licenses, namely the Lesser General Public License (LGPLv3) and the Affero General Public License (AGPLv3). The AGPL version of the General Public License aims to enforce full copyleft rights on all software that use it.

What are the advantages and disadvantages of the AGPL license?

In the standard GPL license, the reciprocity clause comes into effect whenever a developer releases software. The copyleft principle intends to make all of the source code available to the wider open source community. With AGPL, software teams can ensure all changes to the codebase becomes available to the public, even on server-side applications.

Determining whether the AGPL 3.0, LGPL 3.0, or standard GPL 3.0 will suit the team best depends on the final intent of the software. Copyleft licenses are ideal for developers that want to ensure all subsequent changes become available to the community, while permissible licenses like the MIT license gives them more freedom to make modifications proprietary in the future.

Some of the advantages of the AGPL include:

• Forces teams to consider their licensing philosophy early in the project and live with their decision.

• Ensures that any code snippet developed by the open source community stays available and prevents others from repackaging and selling open-source software.

The disadvantages of the AGPL are:

• Puts some teams off open-source packages as it forces all other code to become GPLed software.

• Some view it as excessive as any module in any dependent package that uses AGPL makes all other software subject to similar restrictions.

• Removes the choice for teams to make software proprietary in the future.

Can companies use AGPL software?

Although anyone can use the AGPL V3 license, it’s not popular with organizations. The restrictions placed on any subsequent versions of AGPL software make it difficult to adopt when there are competing commercial interests.

Most companies prefer to use permissive licenses that give them the freedom to use open source components and still turn their version of the software into a commercial product in the future, as opposed to when they use a copyleft license like AGPL.

What is a copyleft license?

Copyleft licenses enforce a principle first supported by Stallman in his GNU manifesto. In the 1960s, it was common for developers to openly share all source code that helped others, creating a sense of community and collaboration. By the 1980s, this trend fell out of favor as organizations started applying copyrights on their source code. Copyleft is the opposite of copyright, enforcing the rights to use, modify, and redistribute any source code that has a copyleft license like the GPL.

Can you use AGPL with closed source applications?

The AGPL V3 license is a strong copyleft license that enforces open source on all components derived from any previous work. It closes the server-side loophole, where the source code isn’t made available if the software isn’t released. AGPL defines a user as anyone who accesses the server-side application if it is public-facing. For applications that reside inside the organization’s network, AGPL does not trigger the release of the source code.

Is AGPLv3 license compatible with GPLv3?

Users who combine work under the GPLv3 license with AGPL software can retain the rights of the GPLv3 license on the unmodified work. Any modified versions of the GPLv3 work will have to use the AGPLv3 license.

AGPL due to its radical open source licensing is currently only used in less than 1% of open source projects.

Establish effective license compliance management with Snyk

For teams that need to maintain effective control over their license compliance, Snyk can help. Our developer-first license management tool gives users a clear view of packages and dependencies in their codebase. By helping developers understand and manage license compliance, this tool helps prevent the project from running into any unforeseen issues in the future. Ensuring that all components derived from open-source work are compatible with the company’s licensing requirements is possible with Snyk’s license compliance management solution.

To see how Snyk can help your teams manage AGPL Version 3 licenses,schedule a demo or start your free trial today.