AGPL becoming acceptable to software developers?
There’s a recent article/interview on Linux.com with Funambol’s CEO about the desirability of AGPL for software that may be used by a service. For clarification the Affero Gnu Public License (AGPLv3) closes the infamous “ASP loophole” and says that just having your software embedded in a service accessed only over the Internet (e.g. embedded in web site or application) still constitutes distribution.
In the interview Fabrizio Capobianco recommends to other FOSS software creators use of this license. Makes sense as its essentially his creation deriving from their own one-off “Honest Public License”. As the creators of an enabling software platform ourselves we obviously have a bit of a bias and would be happy to see this succeed and become acceptable to software developers.
It turns out that since our core product, Rhodes, requires a download we don’t have to worry as much about the “ASP loophole” in the GPL. All apps that are written with Rhodes trigger a “distribution” under standard GPLv3 when users use them. So for our core product Rhodes, even with standard GPLv3, any mobile developer that wants to use it without open sourcing their own solution, they need to work out a commercial license with us. We feel fortunuate that GPLv3 works so well for us in this regard.
However, we have several enabling server-based services coming out: an OTA provisioning service (aka an “app vending machine”) and a device capabilities service in addition to our RhoSync mobile sync server. Here we will have the same problem that Funambol and many other open source companies had: use of these server components by a developer in their website or service is not redistribution. That is, these services are server-based components that facilitate developer’s mobile apps (whether or not those apps are written with Rhodes). We will have our own hosted instances of these services. But we will also allow and encourage developers to have their own instances of them. Use of our services in those situations does NOT constitute redistribution under standard GPLv3 (or GPLv2 for that matter). So if our developer customers were accepting AGPL that would be a good thing for our services. But AGPL is still fairly new, and we want maximum developer adoption. So for our server-based services we will still license them under GPLv3 until we see some very prominent and widely used developer tools using AGPL.
