SaaS Could Gum Up Open Source's Code-Sharing Model

There's a debate brewing over what to do if companies offer open source code in a software-as-a service model, then duck their obligation to contribute changes back to the community.

The risk involves a company taking a product based on open source code, significantly modifying it, and using it as the foundation for selling a service over the Web. Technically, SaaS doesn't distribute code to end users, so the provider isn't required to contribute code changes to the community at large, the way Red Hat must when it resells its version of Linux.

Google's the cause for much of the worry, since it's known to have built its Internet services empire using open source. Yet this question could reach well beyond Web companies. Do we include online banking or Internet stock-trading companies that rely on servers running heavily customized Linux?

Some open source advocates consider this a huge threat, and that such use in SaaS violates the spirit, if not the letter, of open source and must be stopped. I disagree, for a variety of reasons.

The first is the faulty notion that companies providing services over the Web aren't giving anything back. Sure, a closed Web service has its drawbacks. We can't see how it runs, or take it and build a derivative work on it from the inside out. But if the services have APIs that can be accessed by third parties, we get the next best thing--something that can be reused. It's a form of giving back that shouldn't be underrated; look at how much is being done with map mashups, for example.

Still, there's a big problem of impermanence. A company that provides a Web service, open APIs or not, might go bust or lose interest in the service. If that service is contributed to a community, it's more durable. This is the toughest issue, because it plugs into something open source does best: letting software survive calamity.

This argument assumes, however, that no one can replicate that work. Instead of vilifying the creators, the best response to a closed source Web service built on open source software is to create something like that service that does give back. A duplication of effort, surely, but it wouldn't be the first time that happened.

A MORE 'HONEST' APPROACH

DIG DEEPER

SaaS BEYOND CRM

We explain how to drive a software-as-a-service initiative beyond the most common tools.

Download this InformationWeek Report

>> See all our Reports <<

To address this problem, Fabrizio Capobianco, CEO of open source mobile messaging company Funambol, drafted a modified version of the General Public License. Capobianco predicts that most software--open source included--will be run as services. Called the Honest Public License, his alternative license requires code shared as a service to be given back to the community. There's now a revised GPL that addresses SaaS--the AGPLv3--so Capobianco has adopted that for his software. Google, for one, resists AGPLv3 because it believes multiple licenses hurt open source adoption.

A key distinction in this debate is between transforming software and simply building with it. It would be a gross misinterpretation to say that anything built on a Web site with, say, the open source scripting language PHP is open source. Wrong, of course, but we've seen how fast fear and misinformation about open source can spread. The point is to make sure people who transform projects, especially those who use them for commercial ventures, aren't freeloading.

The best response to someone creating a closed Web service from something open is to create something similar, if not better, and open it up. But if you're just now creating something new that lends itself to being reworked as a service, the Honest Public License or the AGPLv3 might make sense, at least until the more mainstream GPL deals with the SaaS loophole. There's nothing wrong with adopting, pre-emptively, a protective measure against something like SaaS that may indeed be "unstoppable."