computerwoche.de

Archiv

Law and order on the open-source range

05.12.2005
Years ago, when Charlie Brenner encountered open-source technology, he saw a great opportunity, but he also saw some danger. Free, effective source code was great, but Brenner recognized that there would be added complexity in managing what he calls "the Wild West environment" of open-source licensing, primarily licenses that force you to turn your own private code into open-source if you violate their provisions.

"We don't want to have our proprietary code dragged into the public domain," says the vice president of the Fidelity Center for Applied Technology at Boston-based Fidelity Investments.

Still, Brenner and others argue that the value of open-source tools greatly outweighs the extra hoops the licensing structures force you to jump through. They've learned that you should start jumping through the hoops before coding begins by establishing a written development process when open-source is involved. Next, you should design, code and test applications in ways that let you use open-source tools while complying with the extra layer of licensing complexity.

"People move to the complexity issue too fast," insists Eben Moglen, chairman of the Software Freedom Law Center in New York and a key contributor to the update in progress to the GNU General Public License (GPL), which is said to cover at least 70% of the 100,000-plus open-source projects listed on SourceForce.net. He argues that the primary objective of open-source licensing is "to protect users' rights."

True, but that protection comes at a price for IT because, like it or not, open-source licensing does add complexity to any application development effort. So much so that some CIOs raise barriers against open-source software. It's one of the major reasons why Robert Urwiler, CIO at Macromedia Inc. in San Francisco, says, "It's an uphill battle for open-source to get in through my door."

Before letting open-source inside your company, there are a few simple things to know. There are two general types of open-source licenses: permissive and coercive. The first, exemplified by the BSD or MIT licenses, puts no restrictions on whether you distribute the open-source software outside your organization, modify the code or combine it with your code -- the three cardinal sins covered by coercive licenses, says Mike Olson, CEO of Sleepycat Software Inc. in Lincoln, Mass. He acknowledges that his own Sleepycat license as well as the GPL on which it was based are good examples of coercive licenses.