AGPL and plugin architectures

Recently in reply to @ddevault’s fedi “Licensing Quiz”, I asked about AGPL Core + Plugins licensing:

Where I’m unsure (and need to do more homework still) is software that has plugin architectures / 3rd-party extensibility options.

Here too different people say very different things.

Suppose AGPL base project, and plugins loaded at runtime based on binaries dopped in a /plugins folder… under what conditions should they also be AGPL?

Eg. Hashicorp go-plugin uses gRPC. Plugins can be any license I assume. Or does dependency on base plugin interface prevent that?

Fabio Manganiello, developer of Platypush also struggled with this licensing question. Despite an answer by Jan Wildeboer I still have questions, and also feel the issue of licensing around extensibility is less clear in general.

Now, I’m perfectly happy to develop plugins in AGPL, same as the chosen license for the base project. At the same time others may use the software only if their plugins can be permissively licensed. And these plugins still add value to the ecosystem as a whole, might be incorporated by other AGPL licensed works.

I checked a bit online, and my understanding now is that:

  • Dependency on data structures in the base project means adopting AGPL.
  • You might define an exception to the license wrt its plugin API’s.
    • Described in section 7 “Additional Terms”, may be removed in derivative works.

Based on this… if you first wrote a permissively licensed SDK that has common code and API interface definitions, and both sides - base and plugins - implementing that, this may serve as a “proxy” and allow different plugin licenses. Not sure though.

Also suppose a service-oriented event-driven architecture (EDA). Plugins (services) would be entirely self-contained / decouple, having no direct dependencies on other services. They fire events that are picked up elsewhere. Communicating over open protocols.


Notes

This Stackoverflow question deals with a similar situation. Answered for GPL case, not AGPL…

GNU project says:

First, the general plug-in architecture design should closely tie the plug-in to the original code, such that the plug-in and the base program are parts of one extended program. For GCC, for example, plug-ins receive and modify GCC’s internal data structures, and so clearly form an extended program with the base GCC.

Note that for code that is explicitly linked at compile time an exception can be added to the license, which can mention the API to restrict the exception to. Linux kernel source does this with the Linux syscall note.