FAQ about AGPL

Overview¶

Pleasanter Community Edition is open source software (OSS) published under the GNU Affero General Public License v3 (GNU AGPLv3). AGPL v3 is a copyleft license based on GPL v3. It has in common with the GPL that an obligation to disclose the source code arises when you modify the software, but it has the important characteristic that the same obligation also applies when you provide the software as a service over a network (AGPL §13). Because of this provision, a business that runs a modified version on a server and provides it to end users is also subject to the disclosure of the source code.

When you use Pleasanter as an in-house business system, or use it as it is without modification, an obligation to disclose the source code does not generally arise. On the other hand, when you provide a service to parties outside your company after modifying it, the obligations of AGPLv3 may apply. If you are considering embedding it in your own product or service, or commercial use, consider the commercial license provided by Implem Inc.

This FAQ organises the questions we receive about AGPLv3 and shows the thinking and the answers of Implem Inc. It also summarises general FAQs about the AGPL.

FAQ about the AGPL of Pleasanter¶

Q1. Does an obligation to disclose arise for the business logic and the design written in scripts, server scripts and styles?¶

I added my own business logic and design using Script, Server Script and Styles, which are standard functions of Pleasanter. Are these also affected by the AGPL, so that I have to publish the source code?

A1.¶

No, no obligation to disclose arises. Script, Server Script and Styles, which you set from the screen, are not a modification of the source code of Pleasanter itself but are treated as "data" processed on Pleasanter. Therefore, the code and know-how of your own company written with them are not subject to the constraint of the AGPL (the obligation to disclose the source code), and you can safely use and provide them while keeping them private.

Q2. Is a system constrained by the AGPL when it links with Pleasanter through the API?¶

We link data by calling the API of Pleasanter from our own external system. Is our own system constrained by the AGPL?

A2.¶

No, it is not constrained. When independent systems exchange data through a standard network communication protocol such as a REST API, that does not amount to "modification" or to a "derivative work" (such as static linking). Therefore, the AGPL does not extend to an external system that links through the API.

Q3. In what cases does an obligation to disclose the source code arise?¶

In what cases does the disclosure obligation of the AGPL arise?

A3.¶

It arises when you directly rewrite the "source code of Pleasanter itself (the core system written in C# and so on)" or extend its functions (for example by building in your own plugin), and then provide that system as a service to third parties over a network (for example as SaaS). In that case, an obligation arises to publish the source code of the whole of Pleasanter, including the parts you modified, to the users under the AGPL.

FAQ about the AGPL¶

Q1. What kind of license is the AGPL (GNU Affero General Public License)?¶

A1.¶

The AGPL is a copyleft open source license based on the GPL (GNU General Public License). Its greatest characteristic is that it is designed so that an obligation to disclose and provide the source code to users arises even when you modify the software and provide it as a service over a network (for example as SaaS).

Q2. What are the main differences between the GPL and the AGPL?¶

A2.¶

Under the conventional GPL, an obligation to disclose the source code arises only when you "distribute" the binary of the software, physically or by download or similar means. Therefore, merely running the software on a server and providing its functions over a network (SaaS) did not give rise to a disclosure obligation. The AGPL addresses this, and differs in that it imposes an obligation to provide the modified source code to users even when the software is used over a network.

Q3. Why was the AGPL created? (What is the "SaaS loophole"?)¶

A3.¶

With the spread of cloud computing, the "SaaS loophole", in which some service providers and cloud vendors modified GPL software, ran it on their servers, and profited from it without publishing the source code to the community, became a problem. The AGPL was created to close this loophole and to encourage companies that provide software as a service to give back to the community (to share the source code).

Q4. Why do some companies tend to be wary of using AGPL software?¶

A4.¶

Because if a company integrates its own proprietary code with AGPL code and provides it over a network, an obligation to disclose may arise even for its own proprietary code under the terms of the AGPL.

Q5. Is there a way to use AGPL software safely in your own product?¶

A5.¶

It is recommended to draw a clear boundary (technical and logical isolation) between the AGPL component and your own proprietary code. Specifically, there are approaches such as running the AGPL software in an independent container (for example Docker) and communicating with it only through a network API, and making use of the sidecar pattern. This reduces the risk of being regarded as legally "combined" (a derivative work) and prevents the license from extending to your own code.

Q6. Is it possible to use AGPL software commercially?¶

A6.¶

Yes, it is. The AGPL is an open source license and does not itself prohibit commercial use of the software. However, when you build it into your own commercial SaaS or similar and provide it over a network, and you have modified the software, you need to comply with the obligation to disclose to users the source code including the parts you modified.

Q7. What is a "dual license"? How does it relate to the AGPL?¶

A7.¶

A dual license is a scheme in which the same software is provided under several different license forms. Many OSS companies provide their software free of charge under the AGPL to encourage open source collaboration, while providing a paid "commercial license" for companies that do not want to publish their own proprietary code. This lets the developer secure revenue while keeping the ideals of open source.

Q8. What risks are there if you violate the terms of the AGPL?¶

A8.¶

A license violation is regarded as copyright infringement and carries serious legal risks such as claims for damages, suspension of shipment of the product, and injunctions against providing the service. There is also a business risk that, if unintended inclusion of AGPL code in your own product is discovered during the due diligence of an M&A (merger or acquisition), the value of the intellectual property is significantly impaired or the acquisition itself falls through.

Update Information¶