Sorry for the pun in the title – I couldn’t resist.
Earlier this week I came across an article from the UK-based site (and magazine?) Legal Week about legal issues and open source software: “Law In Business: Open Source of Confusion.”
Yikes – it’s almost 2007, and the legal profession is still spreading FUD about open source?
To me the telling point is this sentence: “ Given the relative newness of the OSS concept, it can sometimes be difficult to pinpoint where the dangers of using OSS lie.” The implied clause is that while they may be difficult to pinpoint, we’re certain that there are dangers in there somewhere.
Of course there are legal dangers in using OSS – defined broadly enough. There are also legal dangers of engaging in any kind of software development, or usage, or partaking in any kind of contract, or forming any kind of relationship with any other entity, legally formalized or not.
It’s the focus on the dangers of OSS in particular, as though commercially licensed software had no dangers, that I find misleading. When did a major legal publication run a series on “The Dangers of Commercial Software Use”? Has one ever? What about “the hidden costs of proprietary license agreements”?
The article starts with the basic notion that, while open source software sounds “too good to be true,” that in truth “the reality is more complicated.” More complicated how, exactly? Well first of all, open source software “is still protected by copyright and licensed.”
And how does that cause difficulty? Apparently because there are too many different licenses: “It is the proliferation of different licenses for OSS that can create problems for business using or adapting open source applications or code.”
Two problems here:
First, commercial applications also have license proliferation – in fact, every shrink wrap piece of software you buy has its own license, or EULA. (Applications for which enterprises purchase company-wide licenses are even worse – generally usage terms are subject to negotiation and discussion, and every instance of the application has a different “license” than every other instance.)
Second, the differences between the licenses aren’t really all that complex. Much of the license proliferation has been so-called “vanity” licenses, wherein the project founder creates a license just like an existing OSI license but named after the author: the Eckman 1.0 license, for example.
Most of the differences come down to terms regarding re-distribution, which for most users of open source software is never an issue.
The article says that “some [licenses], such as [the] Mozilla [Public License], require that any modification to the code should be made publicly available.”
But this just isn’t true – what the Mozilla Public License does say, in v1.1, is that code which was acquired under the MPL, and is being redistributed, must remain under the MPL. In fact, the MPL was designed to allow AOL to release Netscape 6 as a proprietary application based on (as a derivative work) the Mozilla codebase.
Even the GPL (v2) doesn’t say I have to release every change I make to any source code back to the community. What it does say is that if I intend to distribute works based on GPL code, those derivative works must be distributed under the same terms, i.e., under the GPL.
“To illustrate the variety of open source approaches,” the article continues, “some OSS licenses permit users to inspect the code but not to modify it.”
What licenses would those be?: “those issued by proprietary developers such as Microsoft.” Which, of course, aren’t open source licenses at all, but “shared source” licenses designed to confuse people into thinking they are open source licenses.
The article also trots out the old chestnut about viral infection:
For instance, some licences, including the current version of the GPL, require that all derivative works must “in turn” be licensed under the GPL  a rather difficult concept to accept if you have just funded extensive bespoke adaptation that could potentially give you an edge over your competitors.
Now, if you are funding bespoke adaptations of GPL based software with the intent of distributing that software, you should be wary. (But then can adaptation of an existing GPL project really be said to be “bespoke” since it is based on existing code?).
If you create a custom application based on some commercial components, and intend to distribute your solution without negotiating the appropriate license (a license to redistribute is generally quite different from a license to use) from the appropriate parties, you’d be in the same difficulty, because you’d be violating a license agreement.
If, on the other hand, you’re adapting software for your use, and not distributing it, you do not have to release source code. You might want to, so that your adaptations may benefit from ongoing maintenance and improvement provided by the community, but that’s a whole separate topic.
The article also brings up the whole SCO suit, managing to acknowledge that “SCO’s argument looks weak” but that the suit was nevertheless very expensive for those sued. (Of course, your commercial vendor may also sue you over license counting issues, but that doesn’t come up – nor does the continual cross-litigation between commercial vendors over IP issues).
Patents are also mentioned, and despite saying that “this will almost certainly be a problem for the proprietary vendors as well” the article manages to link “patent problems” and “open source” together.
Finally, the article addresses the issue of support:
As far as aftersales care is concerned, although some companies provide comprehensive support for the mainstream software, such as their own distributions of Linux, many open source products often have limited or no technical support.
While I’m certain that there are projects in existence which have no commercial support options, the reality is that enterprises looking for support have many options – including places like Optaros, where I work, but also organizations like SpikeSource, and traditional vendors like IBM, Unisys, HP, etc. If there is a problem here it is the abundance of options – not a lack of them.
Besides, who said the “support” from commercial vendors is so great?
Most enterprises I know with heavily negotiated service contracts from commercial vendors end up very frustrated – in proprietary software you have very limited support options since access to the code is very tightly controlled – in open source software you have competition for support, since many competent organizations can provide support for the same sets of applications.
Ultimately, the conclusion returns to a sane, if conservative, tone: “prudent CIOs will be aware of where open source code has been used in their company . . .an understanding of which licences apply where and how these licences constrain use [and] . . . a full appreciation of the old maxim: there really is no such thing as a free lunch.”
In other words, you have to know what software is being used, under what licenses, and at what costs (acquisition, maintenance, support). Just as you did in the days before open source licensing.
What was the “source of confusion” again?
- The fact that open source licenses grant you opportunities proprietary licenses do not (the ability to view, modify, and with certain restrictions in some cases even redistribute source code)?
- The fact that there are a handful or variations in open source licenses with respect to source code distribution and attribution? (As opposed to the endless variety of proprietary licenses and EULAs?)
- The fact that vendors can compete to support open source applications and enterprises can potentially consider self-support, an option not available in most proprietary applications?
I’m all for enterprises having strategic understandings of their use of open source, just as they should have detailed understandings of their contracts with commercial software providers.
That understanding has to begin, however, with some basic factual information about specific projects, specific open source licenses, and specific usage scenarios, not vague fear, uncertainty and doubt.
