Wenpai open-source project's infrastructure components must steer clear of AGPL software.

Let’s analyze and compare the differences between GPL and AGPL software. Regarding commercial applications, if I wish to use it in company projects and operations, which software license do you think is more suitable, considering two scenarios:

  1. Licensing for software we develop ourselves;
  2. Licensing for open-source software used in our infrastructure;

GPL vs AGPL Core Differences

GPL (GNU General Public License)

  • Obligations triggered by “distribution”: You only need to provide source code when you distribute the software.
  • Unrestricted internal use: Internal company use or modification of GPL software does not require making the source code public.
  • “SaaS loophole”: Providing services over a network is not considered distribution, so source code does not need to be made public.

AGPL (GNU Affero General Public License)

  • Network use also triggers obligations: Providing services over a network is also considered “distribution”.
  • Plugs the SaaS loophole: Even if you don’t distribute the software, you must provide the source code as long as you allow users to access it over a network.
  • Broader coverage: Almost any form of use may trigger open-source obligations.

Recommendations for Commercial Applications

1. Choosing a License for Self-Developed Software

Situations where GPL is suitable:

  • You want the software to be widely adopted and contributed to.
  • Your primary revenue model is through software licensing or support services.
  • You don’t mind others providing SaaS services based on your software.

Situations where AGPL is suitable:

  • You want to prevent cloud service providers from “free-riding”.
  • You desire stronger copyleft protection.
  • Your primary revenue model is SaaS/cloud-based, and you don’t want competitors directly using your code.

Business Advice: If your business model is SaaS/cloud services, the AGPL can better protect your commercial interests.

2. Using Open-Source Software for Infrastructure

Using GPL software:

  • Lower risk: Internal use typically does not require making source code public.
  • Watch for distribution: If you need to distribute a product containing GPL components, you must open-source it.

Using AGPL software:

  • Higher risk: Providing network services may require making related code modifications public.
  • Evaluate carefully: May expose core business logic.

Business Advice:

  • For infrastructure software, prioritize permissive licenses like MIT, Apache, etc.
  • If AGPL software must be used, ensure a thorough legal risk assessment.
  • Consider commercial licensing as an alternative.

Summary Recommendations

  • Self-developed software: Choose based on your business model. SaaS/cloud businesses lean towards AGPL; traditional software businesses can opt for GPL.
  • Infrastructure: Try to avoid AGPL. Use GPL cautiously, carefully evaluating distribution scenarios. Prefer permissive licenses.

First, the software must be capable of serving as a SaaS foundation for AGPL adoption to be necessary. For the Wenpai project, WordPress’s GPL license presents no issues, and it offers greater flexibility for commercial collaborations.

AGPL software mandates open-sourcing any modifications made, which severely limits enterprises and clients requiring customization. The Wenpai open-source project’s infrastructure software must phase out the use of AGPL software within the next year or two.

A pure GPL licensing form will facilitate subsequent business development.