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

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud // Software as a Service
05:45 PM
Connect Directly

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

Advocates are concerned SaaS providers will transform but not contribute their innovations back to the community.

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?

InformationWeek Reports

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.


We explain how to drive a software-as-a-service initiative beyond the most common tools.
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."

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
11 Things IT Professionals Wish They Knew Earlier in Their Careers
Lisa Morgan, Freelance Writer,  4/6/2021
Time to Shift Your Job Search Out of Neutral
Jessica Davis, Senior Editor, Enterprise Apps,  3/31/2021
Does Identity Hinder Hybrid-Cloud and Multi-Cloud Adoption?
Joao-Pierre S. Ruth, Senior Writer,  4/1/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Successful Strategies for Digital Transformation
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll