Sunday, April 01, 2007
ASP loophole: what if the FSF got it right?It is Sunday, the weather is nice and my rage against the last draft of GPLv3 is gone. Now I can analyze the FSF move on the ASP loophole from a different angle.
I exchanged a few emails with Brett Smith of the FSF, after my blog was posted. He also wrote a comment on the FSF site about the issue. The feeling I have is they were forced to drop the ball, but they have a clear strategy in mind to get it back. If that works, they will achieve what the movement needs, in a very subtle way.
In essence, the strategy of the FSF is simple (I am paraphrasing here, nobody said these exact words to me):
- FACT: we simply could not get GPLv3 out with the ASP provision or it would have been DOA. It is hard to disagree...
- TRICK: we are creating another specific license that includes the ASP provision (AGPLv2) and we added in GPLv3 that the two will be compatible. The end result is license proliferation, but not license incompatibility which is the key issue.
- GOAL: GET AGPL TO BE THE REAL NEXT GPL
People will talk about GPLv3, but if they can get enough notoriety for AGPLv2 and projects will start moving to it (as they should, you DO NOT WANT someone to run your code as a service, make modification and not giving back to your project, it is plain stupid), they will have reached their goal.
So, what is my next move? Working on AGPL to make it the best possible license. I always said that HPL was a stop-gap. If AGPL has what I need and it is generic enough, we should all switch to it (including Alfresco, SugarCRM, Zimbra, Compiere, OpenBravo and so on) and make it THE license.
Things I do not like about AGPLv1, which forced me to create HPL:
- The provision to close the ASP loophole is insane. It requires you to create a service in your product to allow your users to suck down the source code. What if your users access your service from a terminal in the library? Licenses should not force implementations. In HPL, we just say "if you give this to the public, everything else applies". That is, you have to give the world access to the source code. How you do it, I do not care. Enforceability is not the key element. You should trust your community. Looking at Brett's post, I have the feeling the FSF is going in the right direction.
- I do not like the fact that AGPL is Affero branded. It is a vanity license. I do not know anything about Affero Inc. but that it is a corporation. Corporations tend to cater to their needs (rightly so). I would rather have a generic license managed by the FSF. Called AGPL where A stands for ASP. "The GPL for ASP". Just perfect. Unfortunately, the FSF wants to make AGPLv2 backward compatible with AGLPv1 (BTW, is anybody using it?), therefore they might be stuck with the Affero name. It would be a mistake, but manageable from a marketing standpoint.
- AGPLv1 is not OSI-approved. The OSI is an important element of the ecosystem. AGPLv2 (and GPLv3, for that matter) must be OSI approved. I am sure this could be done quickly.
Posted by Fabrizio at 11:18
Thanks for all the great opinionated commentary on GPL and SaaS issues -- it's been really helpful for me. I'm writing a pair of web applications which I'd like to open source, and I'd like a license which would force folks who make improvements on the code, and then host the application for others, to make their code available. Basically, I want the HPL or, when it's ready, AGPLv2.
So, my question is this: If I want to release my code under an open source license tomorrow, which license should I use? Will one existing, legally vetted license have the easiest/clearest 'upgrade' path to "AGPLv2" or "GPL for ASP" of whatever it ends up bing called?
Comment Posted at 18:46
good question... The safest way for upward compatibility would probably be to use Affero GPL v1, although it has a stupid requirement you need to code and QA... If you do not want to do that, go with HPL.