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)?

  • 2
    Thank you for asking, and thank you for already having done some research yourself (too few people do that). It is not entirely clear to me how close and intimate the REST API calls will be. There is likely no b/w answer to your question, but you might want to have a look at the GPL FAQ, and you might be able to build your API in a way to allow what you plan to do. May 20, 2022 at 8:56
  • Thanks. The backend plugins would extend the backend to add DB tables and REST resources. The frontend plugins would add web pages to the frontend. Your comment sounds like the plugins are separated from the app by the API, or maybe I'm misunderstanding.
    – Jérôme
    May 20, 2022 at 9:49
  • It is difficult for me to come to a definitive assessment of your situation. You will have to judge yourself. There is another part of the Q&A you might be interested in: gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface , you might want to add this, just to be on the safe side. May 20, 2022 at 13:39

1 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.

  • Thanks for this. We now have a solid ground for internal discussions about license choice. The Linux example is relevant indeed. Totally agree about crayon licenses, although I didn't elaborate on this in the OP.
    – Jérôme
    May 23, 2022 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.