Funambol on AGPL and the ASP Loophole

Lora Bentley

Lora Bentley spoke with Fabrizio Capobianco, CEO, Funambol.

 

Bentley: When Funambol first released software, it was released under your own license - the Honest Public License. How does the AGPL differ from the HPL?
Capobianco: The HPL essentially added one paragraph to the GPL v2 license, to address the ASP loophole. AGPLv3 does the same thing to the GPL v3 license i.e., it is based on the more recent GPL v3 rather than HPL being based on the older GPL v2. But conceptually, both licenses were intended to address the ASP loophole. Funambol was involved in the definition of AGPLv3, switched to it as soon as it was released, and had it OSI-approved.

 

Bentley: Why did the company find it necessary to change licenses? In other words, why move to the AGPL and see it through the OSI approval process?
Capobianco: When Funambol introduced the HPL, we said right from the beginning that as soon as there was an OSI-approved version of the license that addressed the ASP loophole, we would switch to it. This is because there is a concern about the proliferation of too many different yet similar open source licenses confusing people. So that is why we pushed to have the AGPLv3 approved by the OSI and why we switched to it the second it became OSI approved, because the world really does have quite a few different open source licenses and by virtue of using an OSI approved license, it cuts down on the number of proprietary vendor-written licenses.

 

Bentley: How do you respond to those in the media or other industry observers who say the AGPL doesn't adequately address the ASP Loophole?
Capobianco: I believe the discussion in the media is not if the AGPL adequately addresses the ASP Loophole. That is a given. It does. The question is if closing the ASP Loophole will be a benefit for open source in general or not, or if the AGPL will limit adoption of open source software by enterprises. I personally do not think there is an issue. Enterprises are not affected by the ASP Loophole, because it is targeted to people running software as a service to the public. Enterprises that run services internally do not have to expose their changes to the public. It is a non-issue.

 

Bentley: Some say that rather than requiring service providers to contribute the code that builds on open source back to the community, the community should simply work to create something like what the proprietary service provider is offering. What do you think of that approach?
Capobianco: I believe the best approach is dual-licensing. Having an open source project that is AGPL and forces service providers to decide if they want to behave as good open source citizens (returning the modifications on the code) or if they prefer to keep their intellectual property for themselves, therefore licensing a commercial version of the same code. It is a model that made MySQL one of the most successful open source projects, but also a one billion dollar company with many enterprises very happy to have great code and no open source requirements.



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


 

Resource centers

Business Intelligence

Business performance information for strategic and operational decision-making

SOA

SOA uses interoperable services grouped around business processes to ease data integration

Data Warehousing

Data warehousing helps companies make sense of their operational data