In our plans for the AGPL-licensed Solidground tool suite there are a range of extensibility points, and a plugin architecture that facilitates 3rd-party service integration.
We should know in detail the various licensing aspects to take into account for each of these. On one hand we want as much as possible to be AGPL-licensed, enriching the ecosystem. While for 3rd-party services we want to leave the option open to publish them for integration under different licenses.
On the Fedi I posed the following in response to Drew Devault’s small licensing quiz:
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 also interested for their project Platypush, a modular automation platform:
Platypush falls exactly in this bracket - a lean core that supports hundreds of integrations around it, which may rely on 3rd-party libraries or frameworks released under all kinds of licenses. A specific integration/script may be released under a proprietary license too, if that’s what the developer wants, although probably distributed outside of the main repo.
For this reason (and also because in the IoT space you have a lot of non-FOSS solutions) I released Platypush under MIT years ago, assuming that the more liberal the license, the lower the chances of friction when bringing in more integrations. But I’ve never felt comfortable about this decision.
If it is indeed the case that plugins/integrations can be released under non-GPL licenses and still leverage the GPL core, then I’d be more than happy to change the license to AGPL - and spin off the integrations that directly or indirectly rely on conflicting licenses in a contrib repo. I know that this isn’t possible with stricter licenses (like the SSPL recently adopted by Redis), which usually state that all applications and services that use products released under that license must also comply to the terms of the SSPL license, but I’ve always wondered where GPL sits on this.
Jan Wildeboer answers based on experience at Redhat with the issue:
The TL;DR: WRT GPL it is all about dsitribution, not runtime. So you can add other licenses in plugins/libraries on your installation to your hearts desire with no problem. But as soon as you distribute the whole package with at least one non-GPL plugin/library, you hit the limits. The whole distribution must be GPL or compatible.
This creates a loophole, where you use non-GPL compatible code, say, in a webservice. As you only run but not distribute the software, it’s fine. If you want to close this loophole, that’s what AGPL does. Now if you run a web service that is AGPL but uses a plugin that NOT (A)GPL or compatible, you are hitting the limits. AGPL demands that the whole thing must be available to any user. HTH 2/2 (IANAL, but 20 years at Red Hat and well versed with license stuff) .
So I guess that as a developer of an open framework that supports all kind of integrations with all kind of licenses I may have two choices:
Leave everything as it is (MIT license so I don’t bump against the problem of redistributing GPL code with incompatible licenses).
Extract the plugins that use different license schemes, or are built on top of products/libraries with incompatible licenses, into separate packages/repos under different licenses (or maybe a contrib repo under MIT/BSD), while the core + the open integrations can then be distributed under GPL.
It sounds like AGPL wouldn’t be a reasonable option either way though. My understanding is that an architecture along the lines of “clone/install the open core, then copy the contrib submodules inside of the same repo and run the whole thing together” wouldn’t be compatible with AGPL, because I’m actually mixing projects with difference licenses at runtime and providing them as a service.
Overall, a product like Platypush is very similar in terms of architecture and plugin ecosystem to HomeAssistant. Which, from what I can see, is actually released under Apache license. So I guess that the “pick a liberal license to minimize friction” is a common practice with this kind of software…
To which Jan answers:
Yes. But you can always dual-license to help your users with their different approaches. GPL+MIT or GPL+BSD for example.