Commentary

Serdar Yegulalp
 

Suing Over Open Source

After hearing about the developers of BusyBox reaching a settlement with a vendor that violated the GPL, and reading colleague Paul McDougall's post about a possible need for an open source compliance officer in IT departments, I couldn't help but think: Is the open source moment headed for an overly litigious future?  Right now I don't think it is, but there are ways that could change.

After hearing about the developers of BusyBox reaching a settlement with a vendor that violated the GPL, and reading colleague Paul McDougall's post about a possible need for an open source compliance officer in IT departments, I couldn't help but think: Is the open source moment headed for an overly litigious future?  Right now I don't think it is, but there are ways that could change.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

As open source gains momentum and adherents, and its advocates become that much more influential and powerful, a fearful observer could paint a scenario in which open source licenses are indeed vigorously defended in court, where GPL violators are sued routinely -- and people grow that much more hesitant to use open source for fear of getting sued for using it incorrectly.

What people are worried about, I think, is whether or not expanded legal enforcement of the GPL will have a chilling effect on open source adoption -- whether companies will think twice about making use of OSS because of things like this, and whether they will think the GPL is worth bothering with vs. just buying something and being done with it. They don't want to feel like they will be punished for trying something new and potentially useful, and perceptions mean a lot more in this world than you might think.

Most people who use GPLed software -- just use it, as is -- are never going to be put into a situation where they can be sued. If you're just using it on your own, then it's yours to do with as you see fit. If you redistribute it, however, that's where the terms of the contract come into play: Any changes you make have to also be passed along, in the form of the complete source code. A company that's just using Apache and MySQL and Perl in its Internet-facing Web servers doesn't need to worry about the GPL if it's not attempting to modify and then redistribute anything in the first place.

The problem I sense here is, again, not one of procedure but of image. Open source advocates probably do not want to be seen as lawsuit-happy, and as of right now I don't believe such a perception exists in any measure. They do want to protect the work they've done, though, and make it clear that their license isn't a frivolity or a gentleman's agreement, but rather a legally binding entity. I think as long as there is a continued sense that legal action comes last -- and that people understand that a given open source vendor is falling back on a lawsuit as a last-stand measure -- this won't be a problem. But it should fall to the developers to make it as easy as possible for a potential vendor to know how to use their product properly, and not leave vendors to simply guess and find out (too late) they guessed wrong.

The BusyBox "Hall of Shame" page, which lists all the folks who've used BusyBox and violated the terms of the licensing agreement, has a clear and unambiguous statement that anyone who wants to use the product properly is welcome to contact BusyBox to clarify how to do this. "Nobody wants to be sued, and Erik [Andersen, the key BusyBox developer] certainly would prefer to spend his time doing better things than sue people. But he will sue if forced to do so to maintain compliance."  And, indeed, he has.


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