How can an AGPL web application allow proprietary plugins?

Question

We are developing a web application (REST API backend + frontend, both Python/Flask if that matters).

We want to distribute it as a free software and we'd prefer a GPL license over a less restrictive MIT/Apache license so that other users share their improvements / modifications.

Since the application runs on a server (SaaS), we chose the AGPL licence so that users modifying the software to provide a service with it are required to share their modifications.

We want both backend and frontend to provide a plugin interface. Plugins inherit a base plugin class which is merely an empty shell with placeholder attributes, but also core objects, such as objects responsible for database and authorization layers, so that plugins can add model entities / database tables. I guess this means the plugins are derivative work of the core (this is discussed in this question).

We would like to allow proprietary plugins. What are our options?

Is there such thing as a LAGPL (lesser affero) licence? I guess we could make it up but I'd rather stick to existing licences. Besides, if it doesn't exist, there must be a good reason and perhaps my assumptions are incorrect.

Did I miss something obvious?

---

Another way to put it is:

We want to allow derivative works to be proprietary (the main use case being plugins) but ideally we'd like people modifying core functions to share their modifications.

If we pick the LGPL license, and since the application runs on a server, therefore can be used to provide a service while being installed on provider server, not client computer, does this mean the service provider will be able to do any modifications to the core without being affected by the GPL clause (because it is not Affero)?

Answer 1

There is, to my knowledge, no such thing as the Lesser AGPL, and trying to invent one on the fly is probably not a good idea. But the Linux kernel has an interesting GPL exemption that may be relevant here.

It's fully documented in the kernel source, but the practical upshot is that the kernel rightsholders have made it clear that programs that use the kernel via normal system calls aren't considered derivative works, and therefore don't need to adhere to the kernel's GPL licence. This exemption has been around for many years, is well-understood and often-used (there are many non-GPL kernel modules out there), and it hasn't caused problems during its lifetime.

If you were to finalise and document your plugin API (which is a good idea anyway) you could do the same thing yourself, and make it clear that any program using the documented plugin API wasn't considered a derivative work and therefore didn't have to honour the core work's AGPL with respect to its own code. You would need to make sure that contributors to your core application recognised the advertised exemption, so that your core application could still honour that exemption, but a simple CLA is no bad thing anyway.