Commentary

Serdar Yegulalp
 

Closing The Open Source ASP Loophole

What is to be done about companies who use open source software to create something derived from open source, but provide it as a Web service and don't contribute their changes back to the community?  Aren't they violating the spirit, if not the letter, of the open source agreement?  I don't think so, for a variety of reasons.

What is to be done about companies who use open source software to create something derived from open source, but provide it as a Web service and don't contribute their changes back to the community?  Aren't they violating the spirit, if not the letter, of the open source agreement?  I don't think so, for a variety of reasons.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

It's a topic that a number of other folks already have weighed in on -- Matt Asay and Gordon Haff at CNET, for instance -- and there's a lot of hesitancy about whether or not this is the monster issue it might be.  Here's my take.

The first is the notion of such outfits "not giving anything back".  Sure, a closed source Web service has its drawbacks -- you can't see how it runs, or take it and build a derivative work on it from the inside out.  But if said service has APIs that can be accessed by third parties, then you get the next best thing -- something that can be re-used and mashed up.  That sounds like a form of giving back that shouldn't be underrated; look at how much is being done with such things by the broad mass of people, many of whom have probably never heard the term "open source."

Still, there's also the problem of impermanence.  If I provide a closed source Web service, open APIs or not, who's to say I won't be around in five years?  Wouldn't it be best to give back in a way that is a little more durable?  This is probably the toughest issue of the bunch, because it plugs right into something else that open source does best: it allows software to survive calamity.  If you create a great Web service and it evaporates because you can't pay your hosting bills, and you don't choose to release the innovations you made, haven't you deprived the community of some great work?

Here's where the assertions become particularly hard to swallow.  In order for this to be true, you have to assume that the great work in question couldn't have been done by anyone else.  Perhaps, then, the best response to a closed source Web service built on open source software is to create something like what you see, and in a way that does give back, instead of singling out the original creators for vilification.  Sure, it's a duplication of effort, but it wouldn't be the first time that happened.

Fabrizio Capobianco (he of the open source mobile messaging app Funambol) has his own answer to these issues.  He drafted his own modified version of the GPL, the Honest Public License, which specifically spells out that code shared with the public in the form of a service also has to be given back to the community.  A good idea for folks moving forward, but what about the mass of GPLv2 software out there which will probably not be relicensed anytime soon?

A lot of this seems to come down to what people feel is the real spirit of the open source agreement -- mainly, that freeloading (specifically, this kind of freeloading) should not be tolerated.  I have the feeling that any licensing agreement for open source, no matter how tightly worded, is always going to have some kind of workaround or end run.  We might as well deal with it as gracefully as we can, and the exact method is always going to come down to each one of us individually.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links