Open Source Ripe for the Taking

As I write this column, Oracle has just acquired the open-source company Sleepycat and its embedded database, Berkeley DB. By the time you read this, it's quite possible that Oracle will have acquired even more open-source companies.

There has been plenty of discussion about the effects of Oracle's Sleepycat acquisition on the database market and on MySQL specifically. But I wonder about the impact these acquisitions will have on open-source software and open-source licensing as a whole.

Oracle isn't the first major commercial software company to buy open-source products: IBM and Novell, just to name two, have been doing it for years.

However, Oracle has a well-earned reputation as a company that acquires to remove competition. Many people have speculated that one goal of the Sleepycat acquisition is to damage the increasingly popular MySQL open-source database, as MySQL relies on Berkeley DB and InnoBase (acquired by Oracle in October) for its transaction engine.

While some in the open-source community see these acquisitions as validation of open-source software, there are many who fear what will happen in the future. These fears may well be valid, as the notion of "open source" isn't as cut and dried as it once was.

Click here to read about Oracle's acquisition of Sleepycat.

When you say "open source," many people tend to think of applications running free through the proverbial plains, with no way to control them. However, companies such as Sleepycat, MySQL and JBoss have figured out how to make money from open source, mainly by employing most of the top developers of an application and by providing high-level support options that big enterprise customers expect.

Many of these companies also have both standard open-source and commercial licenses for their products, which is the case with MySQL. Users of the commercial version of MySQL are now worried about the licensing of the Berkeley DB and InnoBase code that MySQL uses.

Some in the open-source community don't worry about these acquisitions, saying, "Hey, these products are open source already, and that can't be changed." However, if a company like Oracle wants to alter licensing for future versions of products attained through acquisitions, it is free to do so.

Then people will say, "That's OK, we'll fork the code to make sure there is always a free, open-source version of the product." This is possible, although you'll need coders intimately familiar with the product to pull it off. And most of those coders will have been employed by the open-source company that got acquired, which means they are now employees of the major commercial company that did the acquiring.

I guess these developers could quit and go back to open-source coding, but I would not be surprised if they were forced to sign a noncompete agreement that includes a promise not to build competing open-source products.

Of course, there's a chance that none of that will happen. Oracle could mean what it says—that it just wants to offer more options and increase its ability to gain revenue through support and services. The acquired products may stay fully open and never be used against other open-source products.

But the situation brings up the bigger question of whether a company can really be open source. From a business perspective, these open-source companies make a lot of sense, as they allow enterprises to use open-source products without having to sacrifice solid support options.

But, from the perspective of those who use open-source software because it is free from constraints, these company-based open-source products could start to become a lot less attractive.

By locking up so much of the expertise and code base of an open-source product, these companies have essentially made it possible to acquire an open-source product.

Those who want to ensure that their open-source software stays free from constraints may want to start moving to community-based, rather than company-based, applications.

After all, you can buy a company, but you can't buy a community (although someone, somewhere is probably trying to figure out how).

Labs Director Jim Rapoza can be reached at jim_rapoza@ziffdavis.com.

Check out eWEEK.com's for the latest open-source news, reviews and analysis.