This is the second paper in the series, The Open Source Monopoly. The goal of the series is to expose a trend in open source that is leading to the creation of a new breed of 'effective' monopolies by commercial open source companies.
Introduction
This article expands upon my previous paper, "The Open Source Monopoly". In it, I laid out the premise that commercial open source (COS) companies of the likes of Red Hat, MySQL and JBoss are examples of a new trend in the open source movement. In this trend, which I call the "Commercial Model" of open source, these companies have positioned themselves to be the de facto "names" in the open source movement. While this may be seen as a natural evolution of the marketplace, I believe that it violates the true spirit of open source, a spirit based in freedom, artistic expression and technological innovations. The result of this trend is what I am calling an effective monopoly, one in which a select group of brand name open source companies dominate the industry. Thanks to this monopoly, open source is ending up less the revolution it was intended to be and more an opportunity for the industry at large to redefine old practices under new terms.
In this paper, I wish to explore the different economic models used by commercial open source companies. Specifically, we can distinguish various strategies that these companies use, what I call the "Dual License Strategy", the "Cell Phone Strategy" and the "Ecosystem Strategy".
The Dual Licensing Strategy
Dual licensing is the technique whereby a COS company develops software that is called "open source" because the company makes its source code freely available. However, since the company owns the copyright to the software source code, it is able to distribute the software under two different licenses: one open source, one commercial. The open source license, typically the GNU General Public License or GPL, allows you to take the software code, modify it, redistribute it or incorporate it into another project - all usually subject to various restrictions. For example, under the GPL you cannot redistribute the GPL'd software in unmodified or modified form, nor any other project that uses all or part of the GPL'd software, unless you too use the GPL license. This means that you cannot take the GPL'd code, create your own brand of software with it, and then sell it for profit. Of course, if you want to do that, the company conveniently offers you its commercial license.
Dual licensing is used in various forms by such companies as Trolltech, Sleepycat, MySQL and Red Hat. It is precisely this trend that I see to be so dangerous to the spirit of open source. In my opinion, this dual licensing model amounts to a hijacking of the open source movement in which the "open source" nature of the company is used as bait to an increasingly receptive marketplace.
Naturally, this opinion is not without opposition. One of the favorite arguments of its opponents is that the code is truly free and within the spirit of open source because you can always fork your own version under a license such as the GPL. Many open source proponents therefore welcome and even encourage dual licensing because they see in that the continued development of their movement.
In order to understand how this is incorrect, we have to look at this from the perspective of these COS companies. Suppose you are starting such a company. Your mission is to make money from open source software. What you need is an economic model in which you can take something free and convince people to pay for it. In a brand name-driven culture, there is only one solution: you need to create and successfully market a brand name.
Creating a brand name in the open source world is not necessarily a matter of producing a quality product (though it might be). It requires a balance between gaining the support of the open source development community and getting your message in front of corporate IT decision makers. To the open source community you need to present yourself as a benevolent guardian of the true spirit of open source. After all, you need their support and even more importantly, their work. To potential clients, you need to present an image of trust by selling a concept, a name.
The dual licensing model allows you to achieve both ends (at least so far). With the open source license you guarantee yourself a user base among the community of developers. You may even set up a specific development community around your product so that developers can actively participate in the evolution of your product. On the other hand, the commercial license gives you a way to make money, increase your marketing budget and move into a position of dominance in the marketplace.
Let's look at an example. Red Hat Inc. distributes two versions of Linux: a commercial version, Red Hat Enterprise Linux (RHEL), and an open source version, Fedora. Originally a free download (and called simply "Red Hat"), the RHEL line was created in 2002 and currently costs anywhere from $349 to $2,499 per server. RHEL is positioned to attract companies who want to move to Linux and want the promise of enterprise-level performance and support. On the other hand, the open source licensed Fedora version is free for anyone to download but is not supported and changes more often. The hope was that the Fedora project could attract a development community which would enable innovations to feed into the RHEL version.
Not every one was happy with Red Hat's dual licensing scheme when it came out. Organizations that had invested in a Red Hat platform found that they now faced unexpected licensing fees. Since RHEL sources could be obtained for free, however, new Linux variants started showing up that were built from those sources. One of the best known is White Box Linux which was created by a Louisiana public library that didn't want to move to RHEL and start paying licensing fees. Instead, they took the RHEL source RPMs (SRPMs) and created their own distribution. (Apparently, they can continue to maintain compatibility with RHEL until 2008 when RedHat will stop releasing errata SRPMs for RHEL.)
You might think that I've just proved the point of those who say that the ability to fork RHEL keeps it open in the spirit of open source. Look at it from RedHat's perspective, though. They get community involvement and support for their commercial product. In fact, they recently announced a series of changes to their process aimed as increasing developer participation in Fedora and enabling community changes to Fedora to feed more easily into the RHEL. Free work to make their commercial product better. In exchange, all they have to do is post their source RPMs as free downloads.
Here's the key though. The fact that anyone can fork a distribution off RHEL does not have any serious affect on their market share. Don't think that Wall Street companies are going to be looking at alternatives to RHEL. They would never consider the likes of White Box Linux, Tao Linux, CentOS and others, let alone even find them. They want a brand name they can trust. And RedHat has successfully positioned themselves to be that brand name. Unless we see a radical shift in the industry, the market penetration of all RHEL derivatives will never amount to more than a tiny fraction of total Linux installations.
Giving source code away is not a huge risk for companies following the dual licensing strategy. In exchange for becoming a brand name in the open source world, they allow a certain percentage of people to use their software for free. However, they are not concerned with that percentage of people - their sights are on the growing open source conversions being contemplated in IT organizations around the world. That is their market. It is not the odd developer or odd company that is willing to work with the source code.
Whereas Red Hat Inc. offers one product under the commercial license and another under an open source license, other companies offer two different licenses for the same product. Such is the case with MySQL AB which has been in the dual licensing business for a while. It's flagship database product can be downloaded for free under the terms of the GPL or can be used commercially under the commercial license.
Which license you choose basically comes down to the interpretation of the GPL. For example, if you want to distribute MySQL (or its drivers) with a non-GPL application, you need a commercial license. This applies not only if you actually distribute MySQL, but if "as part of utilizing your application, the end-user must download a copy of MySQL". It is also recommended by MySQL that you need a commercial license if you "distribute MySQL Software within your organization". Finally, there is a special clause that allows you to distribute MySQL client libraries with Free/Libre and Open Source Software (FLOSS) applications under the terms of the "FLOSS License Exception".
The interesting thing about MySQL and the GPL is that there is a certain amount of interpretation at work. What exactly does it mean to "distribute MySQL Software within your organization"? There is no text in the GPL itself that covers the situation. In fact, the Free Software Foundation (FSF) FAQ on the GPL notes that you are actually free to release GPL'd software internally within your organization.
There are plenty of those who say that GPL is GPL and so as long as you stay with its terms MySQL has no legal claims on your use of it. However, it is quite valid to ask whether MySQL AB could be attempting to restrict the GPL beyond the generally accepted terms of the license. There are some gray areas in GPL itself, particularly when it comes to communication between software components via standard protocols. But even if MySQL AB itself respects the generally accepted interpretation of the GPL, it is not beyond the realm of possibility that another dual-licensing company will not. The key question is whether organizations that use software from a dual-licensing company under the terms of GPL will someday find themselves in a difficult situation. There is no code of honor when a profit must be made.
JBoss and the "Cell Phone Strategy"
When it comes to a company like JBoss, it might appear that the dual licensing strategy is impossible, since individual contributors and not JBoss owns the copyright to the source code. Currently, the revenue model for JBoss is built around support of their products. However, it has already been pointed out that this model is not viable in the long run (especially for capitalizing on the $10M venture capital investment it received last year). The fact is that JBoss is going after the market share enjoyed by BEA, just like Red Hat is targeting Sun's market. You can't beat BEA by support contracts alone: you need a better revenue model. And JBoss execs don't rule it out. Marc Fleury, for example, admits about dual licensing that "on new layers it may make sense".
Although a very small company, JBoss has been extremely successfully in establishing their name in the J2EE and middleware world. With the JBoss Enterprise Middleware System (JEMS), the company now has its sights set on becoming the de facto choice for non-proprietary middleware. They have also become heavily involved in the new EJB 3.0 specification and the future of J2EE in general. The question again comes down to strategy. It is a possibility, in my opinion, that some generation (or "layer") of JEMS will eventually become a commercial product. JBoss is certainly keeping that option open. I also have misgivings when they are actively recruiting leading open source developers like Remy Maucherat of Apache Tomcat fame. Does this foretell a day when formerly open source developers will be creating code under the JBoss copyright?
Regardless of the possibility of dual licensing, I believe JBoss' true strategy is what I call the "Cell Phone Model". A while ago, cellular phone companies realized that if they gave away cell phones in exchange for contract agreements, they would have greater success among consumers then if they sold them. And the market has proved them right. Most Americans now own cell phones or, more correctly, they own a contract on one. By giving away a disposable product that has in itself little long-term value, the cellular companies have guaranteed themselves an ongoing revenue stream that far exceeds anything they could get from actual sales. I believe this is also true of JBoss.
While open source products are hardly disposable, they cost little to make if open source volunteers are doing all the work. In the case of JBoss, they have a seemingly vibrant development community working for free under their management. While not all members of that community will agree with this portrayal, consider the facts. JBoss takes a free product, wraps it up in very good marketing (remember, they have venture capital to spend) and uses it to go after domination of the middleware industry. What part of this do the open source developers see? The satisfaction of knowing they are helping create a popular product? The individual freedom to download and use JBoss on their own? Certainly they latter is of great benefit to some, but not quite on the same level as the benefits that JBoss hope to enjoy.
The difference between JBoss Inc. and the likes of Verizon is that the latter makes you sign a contract for your "free" phone. JBoss does no such thing. But as I have been showing in these papers, it is the effect of these business practices that we have to consider. The reason why companies are turning to JBoss and their middleware products is precisely because of the support options. While there is no such thing as required support, any kind of large-scale IT organization using JBoss products is almost always going to buy support (like the French "Direction Generale des Impots", for example). While the majority of JBoss downloads are by individuals or small organizations that won't utilize support, they are not the real market.
"They would never do that"
If there is one argument I find to be particularly naive, it is that "they would never do that". In various discussions about JBoss, I've heard that a few times. The naivete comes from a lack of understanding how economics works. I've been involved in startup companies and met with venture capitalists. Venture capitalists are not interested in the ideals of open source but only a specific rate of return on their investment. If they don't get that, they either lose interest or use their voting power to change corporate direction. This isn't any grand and dire prediction, it is an everyday fact.
To those who believe that GPL and the spirit of open source protects the movement from any sort of hijacking, let me point out that it is only the motives of those that control the money that really matter. Today, it is the investors that matter most. Tomorrow, it will also be the companies that buy out the open source companies of today. Idealism is no match for a lucrative buyout deal - just look at PeopleSoft and Oracle. As I asked before, what happens when a company like HP, IBM or even BEA buys JBoss?
The Ecosystem Strategy
The "Ecosystem Strategy" is one in which a COS company creates a network of partners or preferred independent software vendors (ISVs). The goal of this network or "ecosystem" (the new hot buzzword) is to create a lock-in of sorts. This is hardly new - companies like HP, Sun and IBM have been doing it for years as a way of creating an effective monopoly. Nor is it incompatible with the other strategies already mentioned - in a way, it complements them.
Let's look at Red Hat Inc. again. Oracle is one of their major partners. What this means is that the two companies work closely to insure that their software plays well together. If you are a big company wanting to run Oracle on Linux, you'll therefore be more likely to choose Red Hat with its Oracle integration. You won't be likely to choose White Box Linux, Debian, Mandrake, FreeBSD or any other such variant from a non-profit organization.
The strategy here is to take an open source product and use it as the core of a real or contrived infrastructure. An operating system is probably the easiest thing to use as the center of an infrastructure. In speaking of Solaris 10, for example, Sun president Jonathan Schwartz rhapsodizes:
Together, Sun and SAP are going to drive business solutions across the entirety of our SPARC and x86/Opteron platform customers. This is really the final brick in the wall for us with partners - Oracle, Veritas, BEA, CA, EMC, Sybase, Siebel and now SAP. That's a fantastic list (and there are hundreds of others who've also signed on). It takes an ecosystem to raise an OS, and volume to attract partners.
Then we read from Red Hat Inc. that:
Red Hat brings together industry leaders to build an ecosystem around Linux and open source technology.
By empowering a complex network of hundreds of leading hardware, software and service provider vendors, Red Hat is returning the power of choice and openness to partners and their customers to build a certified, open source solution.
And from JBoss:
The JBoss Partner Program was created to build a network of service delivery, software, and technology partners that could enhance the proliferation and quality of deployments based on JBoss Inc. products. Today, the JBoss Partner network has grown to over 60 authorized partners including IT industry heavyweights such as CA, HP, Novell, and Unisys.
Let me be very clear here. There is nothing wrong with partnering with software companies providing true value in technology. True value to me means enabling business functions in the most efficient and cost-effective way possible. It does not mean a layered network of complex software in which one depends on another until you find yourself wondering what the point was in the first place. When I read the above quotes, I know I'm being sold a concept, not a tool that enables me to fulfill specific business needs. I use open source software in order to run my business more efficiently. I do not need "solutions" or "ecosystems" in order to achieve this.
What good is open source software anyway?
As shown in "The Open Source Monopoly", the only requirement for being officially called "open source" is that your source code is in some way freely available for download, use, modification and redistribution. Not all open source licenses grant the same freedoms, but the general idea is the same. It is myopic to think, however, that just because a COS company allows you to download its source code for free means that the true promise of open source is being lived out.
It all comes back to strategy. For COS companies, open source is part of a strategy, not a life philosophy. Look at it again from their perspective. They have gained a leadership place in a new industry. In return, they make their source code available. Does that bother them? It is just a marketing move. Sure, people will download the source code, compile it and use. Some will redistribute it for free. But compared to the tremendous success that companies like Red Hat Inc. have had in penetrating corporate IT departments, putting code on the Internet is a small price indeed.
It is precisely because of the true spirit of open source that companies like RedHat, MySQL and JBoss now enjoy a rapidly growing reputation among IT departments. Why are companies and organizations all over the world even aware of open source? Because of the efforts of thousands of developers who believed that with a bit of ingenuity they could turn out better quality software than the proprietary options available. And software that costs basically nothing and could therefore save corporations hundreds of thousands of dollars. Some of these people were developers and others users. Together, they built projects and introduced companies all over the world to the benefits of those projects. Apache is the number one web server on the Internet, and it owes all of its success to the many rogue developers that took the initiative to build a viable open source proof-of-concept for their management. As more and more IT management saw how well open source software like the Apache web server performed, the more they considered where else the movement might benefit them. That is the power of an idea.
I don't deny the likes of Red Hat Inc., MySQL AB, Trolltech or Sleepycat the right to make money. Nor do I deny their right to produce a product and compete in an open market to be the best at what they do. I am a capitalist, after all. And I even like some of their products, like Berkeley DB. But I also believe in honesty and truth. I do not think they have the right to call themselves "open source" just because their source code is freely available. I realize that this is the technical definition, but I don't think the technical definition is what the pioneers of the open source movement understand it to be. These people did what they did precisely because they believed that they could circumvent the monopolies and lock-in of the proprietary options that increasingly frustrated them.
Put another way, commercial open source companies have forgotten the origins of the open source movement. To them, open source means little more than using a marketing term in exchange for publishing their source code on the web. In fact, Michael Olson of Sleepycat practically admitted as much. When I hear them talk about open source, I hear buzzwords designed to appeal to Fortune 500 decision makers. I get the feeling that they see hard-core open source developers as a bunch of strange and socially inept geeks whose intentions they vaguely suspect but whose impact they feel will be negligible. Take a look at a quote from JBoss' Marc Fleury:
We think we're inventing the new open source. It's not the pony-tailed faction on the communist fringe. There needs to be professionalism and credibility. There needs to be sales and marketing, and all the things that make a business.
I think this speaks of a growing split in open source, one in which commercial open source companies are the professionals, and the open source developers that created the movement in the first place are communists. Like political communists, the latter are supposed to get old and end up in a retirement home for dying Marxists. In other words, the open source idealists are being marginalized and relegated to a place so they stay out of the way of the suited professionals hurrying to their meetings with Wall Street companies.
I don't think so. In the next article in this series, I will address this marginalization of open source in more detail. While I see this as a trend, it need not be inevitable. I will show how, with the proper approach, the open source movement can stay alive and well and faithful to its origins.
-----------------------------------------------------------------------------
The economics of commercial open source is Part 2 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies. Part 3, Openstructure: A Call for Open Source Reform presents a challenge for changing this trend.
This article was first published on 1/19/05.
References (in order of appearance)
1.. Trolltech Home Page. http://www.trolltech.com
2.. Sleepycat Software Home Page. http://www.sleepycat.com
3.. MySQL AB Home Page. http://www.mysql.com
4.. Red Hat Inc. Home Page. http://www.redhat.com
5.. White Box Linux Project Home Page. http://www.whiteboxlinux.org
6.. CentOS Home Page. http://www.centos.org
7.. The open source MySQL license can be found at http://www.mysql.com/company/legal/licensing/opensource-license.html. The commercial MySQL license is at http://www.mysql.com/company/legal/licensing/commercial-license.html. The FLOSS License Exception text is at http://www.mysql.com/company/legal/licensing/foss-exception.html.
8.. GNU General Public License. http://www.gnu.org/licenses/licenses.html#GPL. The GPL FAQ is at http://www.fsf.org/licenses/gpl-faq.html.
9.. JBoss Inc. Home Page. http://www.jboss.org
10.. The reference to the JBoss venture capital investment comes from "JBoss Goes Corporate For Credibility" by David Rubinstein: http://www.sdtimes.com/news/098/story1.htm.
11.. The Jonathan Schwartz quote comes from his weblog for 11/16/04. http://blogs.sun.com/roller/page/jonathan/20041203
12.. The Red Hat quote comes from http://www.redhat.com/truthhappens/index.html and http://www.redhat.com/solutions/partners/.
13.. The JBoss quote comes from http://www.jboss.org/partners/index.
14.. The quote from Marc Fleury comes from http://www.computerworld.co.nz/news.nsf/UNID/DE4C7332CF834397CC256E87006892D6.
Introduction
This article expands upon my previous paper, "The Open Source Monopoly". In it, I laid out the premise that commercial open source (COS) companies of the likes of Red Hat, MySQL and JBoss are examples of a new trend in the open source movement. In this trend, which I call the "Commercial Model" of open source, these companies have positioned themselves to be the de facto "names" in the open source movement. While this may be seen as a natural evolution of the marketplace, I believe that it violates the true spirit of open source, a spirit based in freedom, artistic expression and technological innovations. The result of this trend is what I am calling an effective monopoly, one in which a select group of brand name open source companies dominate the industry. Thanks to this monopoly, open source is ending up less the revolution it was intended to be and more an opportunity for the industry at large to redefine old practices under new terms.
In this paper, I wish to explore the different economic models used by commercial open source companies. Specifically, we can distinguish various strategies that these companies use, what I call the "Dual License Strategy", the "Cell Phone Strategy" and the "Ecosystem Strategy".
The Dual Licensing Strategy
Dual licensing is the technique whereby a COS company develops software that is called "open source" because the company makes its source code freely available. However, since the company owns the copyright to the software source code, it is able to distribute the software under two different licenses: one open source, one commercial. The open source license, typically the GNU General Public License or GPL, allows you to take the software code, modify it, redistribute it or incorporate it into another project - all usually subject to various restrictions. For example, under the GPL you cannot redistribute the GPL'd software in unmodified or modified form, nor any other project that uses all or part of the GPL'd software, unless you too use the GPL license. This means that you cannot take the GPL'd code, create your own brand of software with it, and then sell it for profit. Of course, if you want to do that, the company conveniently offers you its commercial license.
Dual licensing is used in various forms by such companies as Trolltech, Sleepycat, MySQL and Red Hat. It is precisely this trend that I see to be so dangerous to the spirit of open source. In my opinion, this dual licensing model amounts to a hijacking of the open source movement in which the "open source" nature of the company is used as bait to an increasingly receptive marketplace.
Naturally, this opinion is not without opposition. One of the favorite arguments of its opponents is that the code is truly free and within the spirit of open source because you can always fork your own version under a license such as the GPL. Many open source proponents therefore welcome and even encourage dual licensing because they see in that the continued development of their movement.
In order to understand how this is incorrect, we have to look at this from the perspective of these COS companies. Suppose you are starting such a company. Your mission is to make money from open source software. What you need is an economic model in which you can take something free and convince people to pay for it. In a brand name-driven culture, there is only one solution: you need to create and successfully market a brand name.
Creating a brand name in the open source world is not necessarily a matter of producing a quality product (though it might be). It requires a balance between gaining the support of the open source development community and getting your message in front of corporate IT decision makers. To the open source community you need to present yourself as a benevolent guardian of the true spirit of open source. After all, you need their support and even more importantly, their work. To potential clients, you need to present an image of trust by selling a concept, a name.
The dual licensing model allows you to achieve both ends (at least so far). With the open source license you guarantee yourself a user base among the community of developers. You may even set up a specific development community around your product so that developers can actively participate in the evolution of your product. On the other hand, the commercial license gives you a way to make money, increase your marketing budget and move into a position of dominance in the marketplace.
Let's look at an example. Red Hat Inc. distributes two versions of Linux: a commercial version, Red Hat Enterprise Linux (RHEL), and an open source version, Fedora. Originally a free download (and called simply "Red Hat"), the RHEL line was created in 2002 and currently costs anywhere from $349 to $2,499 per server. RHEL is positioned to attract companies who want to move to Linux and want the promise of enterprise-level performance and support. On the other hand, the open source licensed Fedora version is free for anyone to download but is not supported and changes more often. The hope was that the Fedora project could attract a development community which would enable innovations to feed into the RHEL version.
Not every one was happy with Red Hat's dual licensing scheme when it came out. Organizations that had invested in a Red Hat platform found that they now faced unexpected licensing fees. Since RHEL sources could be obtained for free, however, new Linux variants started showing up that were built from those sources. One of the best known is White Box Linux which was created by a Louisiana public library that didn't want to move to RHEL and start paying licensing fees. Instead, they took the RHEL source RPMs (SRPMs) and created their own distribution. (Apparently, they can continue to maintain compatibility with RHEL until 2008 when RedHat will stop releasing errata SRPMs for RHEL.)
You might think that I've just proved the point of those who say that the ability to fork RHEL keeps it open in the spirit of open source. Look at it from RedHat's perspective, though. They get community involvement and support for their commercial product. In fact, they recently announced a series of changes to their process aimed as increasing developer participation in Fedora and enabling community changes to Fedora to feed more easily into the RHEL. Free work to make their commercial product better. In exchange, all they have to do is post their source RPMs as free downloads.
Here's the key though. The fact that anyone can fork a distribution off RHEL does not have any serious affect on their market share. Don't think that Wall Street companies are going to be looking at alternatives to RHEL. They would never consider the likes of White Box Linux, Tao Linux, CentOS and others, let alone even find them. They want a brand name they can trust. And RedHat has successfully positioned themselves to be that brand name. Unless we see a radical shift in the industry, the market penetration of all RHEL derivatives will never amount to more than a tiny fraction of total Linux installations.
Giving source code away is not a huge risk for companies following the dual licensing strategy. In exchange for becoming a brand name in the open source world, they allow a certain percentage of people to use their software for free. However, they are not concerned with that percentage of people - their sights are on the growing open source conversions being contemplated in IT organizations around the world. That is their market. It is not the odd developer or odd company that is willing to work with the source code.
Whereas Red Hat Inc. offers one product under the commercial license and another under an open source license, other companies offer two different licenses for the same product. Such is the case with MySQL AB which has been in the dual licensing business for a while. It's flagship database product can be downloaded for free under the terms of the GPL or can be used commercially under the commercial license.
Which license you choose basically comes down to the interpretation of the GPL. For example, if you want to distribute MySQL (or its drivers) with a non-GPL application, you need a commercial license. This applies not only if you actually distribute MySQL, but if "as part of utilizing your application, the end-user must download a copy of MySQL". It is also recommended by MySQL that you need a commercial license if you "distribute MySQL Software within your organization". Finally, there is a special clause that allows you to distribute MySQL client libraries with Free/Libre and Open Source Software (FLOSS) applications under the terms of the "FLOSS License Exception".
The interesting thing about MySQL and the GPL is that there is a certain amount of interpretation at work. What exactly does it mean to "distribute MySQL Software within your organization"? There is no text in the GPL itself that covers the situation. In fact, the Free Software Foundation (FSF) FAQ on the GPL notes that you are actually free to release GPL'd software internally within your organization.
There are plenty of those who say that GPL is GPL and so as long as you stay with its terms MySQL has no legal claims on your use of it. However, it is quite valid to ask whether MySQL AB could be attempting to restrict the GPL beyond the generally accepted terms of the license. There are some gray areas in GPL itself, particularly when it comes to communication between software components via standard protocols. But even if MySQL AB itself respects the generally accepted interpretation of the GPL, it is not beyond the realm of possibility that another dual-licensing company will not. The key question is whether organizations that use software from a dual-licensing company under the terms of GPL will someday find themselves in a difficult situation. There is no code of honor when a profit must be made.
JBoss and the "Cell Phone Strategy"
When it comes to a company like JBoss, it might appear that the dual licensing strategy is impossible, since individual contributors and not JBoss owns the copyright to the source code. Currently, the revenue model for JBoss is built around support of their products. However, it has already been pointed out that this model is not viable in the long run (especially for capitalizing on the $10M venture capital investment it received last year). The fact is that JBoss is going after the market share enjoyed by BEA, just like Red Hat is targeting Sun's market. You can't beat BEA by support contracts alone: you need a better revenue model. And JBoss execs don't rule it out. Marc Fleury, for example, admits about dual licensing that "on new layers it may make sense".
Although a very small company, JBoss has been extremely successfully in establishing their name in the J2EE and middleware world. With the JBoss Enterprise Middleware System (JEMS), the company now has its sights set on becoming the de facto choice for non-proprietary middleware. They have also become heavily involved in the new EJB 3.0 specification and the future of J2EE in general. The question again comes down to strategy. It is a possibility, in my opinion, that some generation (or "layer") of JEMS will eventually become a commercial product. JBoss is certainly keeping that option open. I also have misgivings when they are actively recruiting leading open source developers like Remy Maucherat of Apache Tomcat fame. Does this foretell a day when formerly open source developers will be creating code under the JBoss copyright?
Regardless of the possibility of dual licensing, I believe JBoss' true strategy is what I call the "Cell Phone Model". A while ago, cellular phone companies realized that if they gave away cell phones in exchange for contract agreements, they would have greater success among consumers then if they sold them. And the market has proved them right. Most Americans now own cell phones or, more correctly, they own a contract on one. By giving away a disposable product that has in itself little long-term value, the cellular companies have guaranteed themselves an ongoing revenue stream that far exceeds anything they could get from actual sales. I believe this is also true of JBoss.
While open source products are hardly disposable, they cost little to make if open source volunteers are doing all the work. In the case of JBoss, they have a seemingly vibrant development community working for free under their management. While not all members of that community will agree with this portrayal, consider the facts. JBoss takes a free product, wraps it up in very good marketing (remember, they have venture capital to spend) and uses it to go after domination of the middleware industry. What part of this do the open source developers see? The satisfaction of knowing they are helping create a popular product? The individual freedom to download and use JBoss on their own? Certainly they latter is of great benefit to some, but not quite on the same level as the benefits that JBoss hope to enjoy.
The difference between JBoss Inc. and the likes of Verizon is that the latter makes you sign a contract for your "free" phone. JBoss does no such thing. But as I have been showing in these papers, it is the effect of these business practices that we have to consider. The reason why companies are turning to JBoss and their middleware products is precisely because of the support options. While there is no such thing as required support, any kind of large-scale IT organization using JBoss products is almost always going to buy support (like the French "Direction Generale des Impots", for example). While the majority of JBoss downloads are by individuals or small organizations that won't utilize support, they are not the real market.
"They would never do that"
If there is one argument I find to be particularly naive, it is that "they would never do that". In various discussions about JBoss, I've heard that a few times. The naivete comes from a lack of understanding how economics works. I've been involved in startup companies and met with venture capitalists. Venture capitalists are not interested in the ideals of open source but only a specific rate of return on their investment. If they don't get that, they either lose interest or use their voting power to change corporate direction. This isn't any grand and dire prediction, it is an everyday fact.
To those who believe that GPL and the spirit of open source protects the movement from any sort of hijacking, let me point out that it is only the motives of those that control the money that really matter. Today, it is the investors that matter most. Tomorrow, it will also be the companies that buy out the open source companies of today. Idealism is no match for a lucrative buyout deal - just look at PeopleSoft and Oracle. As I asked before, what happens when a company like HP, IBM or even BEA buys JBoss?
The Ecosystem Strategy
The "Ecosystem Strategy" is one in which a COS company creates a network of partners or preferred independent software vendors (ISVs). The goal of this network or "ecosystem" (the new hot buzzword) is to create a lock-in of sorts. This is hardly new - companies like HP, Sun and IBM have been doing it for years as a way of creating an effective monopoly. Nor is it incompatible with the other strategies already mentioned - in a way, it complements them.
Let's look at Red Hat Inc. again. Oracle is one of their major partners. What this means is that the two companies work closely to insure that their software plays well together. If you are a big company wanting to run Oracle on Linux, you'll therefore be more likely to choose Red Hat with its Oracle integration. You won't be likely to choose White Box Linux, Debian, Mandrake, FreeBSD or any other such variant from a non-profit organization.
The strategy here is to take an open source product and use it as the core of a real or contrived infrastructure. An operating system is probably the easiest thing to use as the center of an infrastructure. In speaking of Solaris 10, for example, Sun president Jonathan Schwartz rhapsodizes:
Together, Sun and SAP are going to drive business solutions across the entirety of our SPARC and x86/Opteron platform customers. This is really the final brick in the wall for us with partners - Oracle, Veritas, BEA, CA, EMC, Sybase, Siebel and now SAP. That's a fantastic list (and there are hundreds of others who've also signed on). It takes an ecosystem to raise an OS, and volume to attract partners.
Then we read from Red Hat Inc. that:
Red Hat brings together industry leaders to build an ecosystem around Linux and open source technology.
By empowering a complex network of hundreds of leading hardware, software and service provider vendors, Red Hat is returning the power of choice and openness to partners and their customers to build a certified, open source solution.
And from JBoss:
The JBoss Partner Program was created to build a network of service delivery, software, and technology partners that could enhance the proliferation and quality of deployments based on JBoss Inc. products. Today, the JBoss Partner network has grown to over 60 authorized partners including IT industry heavyweights such as CA, HP, Novell, and Unisys.
Let me be very clear here. There is nothing wrong with partnering with software companies providing true value in technology. True value to me means enabling business functions in the most efficient and cost-effective way possible. It does not mean a layered network of complex software in which one depends on another until you find yourself wondering what the point was in the first place. When I read the above quotes, I know I'm being sold a concept, not a tool that enables me to fulfill specific business needs. I use open source software in order to run my business more efficiently. I do not need "solutions" or "ecosystems" in order to achieve this.
What good is open source software anyway?
As shown in "The Open Source Monopoly", the only requirement for being officially called "open source" is that your source code is in some way freely available for download, use, modification and redistribution. Not all open source licenses grant the same freedoms, but the general idea is the same. It is myopic to think, however, that just because a COS company allows you to download its source code for free means that the true promise of open source is being lived out.
It all comes back to strategy. For COS companies, open source is part of a strategy, not a life philosophy. Look at it again from their perspective. They have gained a leadership place in a new industry. In return, they make their source code available. Does that bother them? It is just a marketing move. Sure, people will download the source code, compile it and use. Some will redistribute it for free. But compared to the tremendous success that companies like Red Hat Inc. have had in penetrating corporate IT departments, putting code on the Internet is a small price indeed.
It is precisely because of the true spirit of open source that companies like RedHat, MySQL and JBoss now enjoy a rapidly growing reputation among IT departments. Why are companies and organizations all over the world even aware of open source? Because of the efforts of thousands of developers who believed that with a bit of ingenuity they could turn out better quality software than the proprietary options available. And software that costs basically nothing and could therefore save corporations hundreds of thousands of dollars. Some of these people were developers and others users. Together, they built projects and introduced companies all over the world to the benefits of those projects. Apache is the number one web server on the Internet, and it owes all of its success to the many rogue developers that took the initiative to build a viable open source proof-of-concept for their management. As more and more IT management saw how well open source software like the Apache web server performed, the more they considered where else the movement might benefit them. That is the power of an idea.
I don't deny the likes of Red Hat Inc., MySQL AB, Trolltech or Sleepycat the right to make money. Nor do I deny their right to produce a product and compete in an open market to be the best at what they do. I am a capitalist, after all. And I even like some of their products, like Berkeley DB. But I also believe in honesty and truth. I do not think they have the right to call themselves "open source" just because their source code is freely available. I realize that this is the technical definition, but I don't think the technical definition is what the pioneers of the open source movement understand it to be. These people did what they did precisely because they believed that they could circumvent the monopolies and lock-in of the proprietary options that increasingly frustrated them.
Put another way, commercial open source companies have forgotten the origins of the open source movement. To them, open source means little more than using a marketing term in exchange for publishing their source code on the web. In fact, Michael Olson of Sleepycat practically admitted as much. When I hear them talk about open source, I hear buzzwords designed to appeal to Fortune 500 decision makers. I get the feeling that they see hard-core open source developers as a bunch of strange and socially inept geeks whose intentions they vaguely suspect but whose impact they feel will be negligible. Take a look at a quote from JBoss' Marc Fleury:
We think we're inventing the new open source. It's not the pony-tailed faction on the communist fringe. There needs to be professionalism and credibility. There needs to be sales and marketing, and all the things that make a business.
I think this speaks of a growing split in open source, one in which commercial open source companies are the professionals, and the open source developers that created the movement in the first place are communists. Like political communists, the latter are supposed to get old and end up in a retirement home for dying Marxists. In other words, the open source idealists are being marginalized and relegated to a place so they stay out of the way of the suited professionals hurrying to their meetings with Wall Street companies.
I don't think so. In the next article in this series, I will address this marginalization of open source in more detail. While I see this as a trend, it need not be inevitable. I will show how, with the proper approach, the open source movement can stay alive and well and faithful to its origins.
-----------------------------------------------------------------------------
The economics of commercial open source is Part 2 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies. Part 3, Openstructure: A Call for Open Source Reform presents a challenge for changing this trend.
This article was first published on 1/19/05.
References (in order of appearance)
1.. Trolltech Home Page. http://www.trolltech.com
2.. Sleepycat Software Home Page. http://www.sleepycat.com
3.. MySQL AB Home Page. http://www.mysql.com
4.. Red Hat Inc. Home Page. http://www.redhat.com
5.. White Box Linux Project Home Page. http://www.whiteboxlinux.org
6.. CentOS Home Page. http://www.centos.org
7.. The open source MySQL license can be found at http://www.mysql.com/company/legal/licensing/opensource-license.html. The commercial MySQL license is at http://www.mysql.com/company/legal/licensing/commercial-license.html. The FLOSS License Exception text is at http://www.mysql.com/company/legal/licensing/foss-exception.html.
8.. GNU General Public License. http://www.gnu.org/licenses/licenses.html#GPL. The GPL FAQ is at http://www.fsf.org/licenses/gpl-faq.html.
9.. JBoss Inc. Home Page. http://www.jboss.org
10.. The reference to the JBoss venture capital investment comes from "JBoss Goes Corporate For Credibility" by David Rubinstein: http://www.sdtimes.com/news/098/story1.htm.
11.. The Jonathan Schwartz quote comes from his weblog for 11/16/04. http://blogs.sun.com/roller/page/jonathan/20041203
12.. The Red Hat quote comes from http://www.redhat.com/truthhappens/index.html and http://www.redhat.com/solutions/partners/.
13.. The JBoss quote comes from http://www.jboss.org/partners/index.
14.. The quote from Marc Fleury comes from http://www.computerworld.co.nz/news.nsf/UNID/DE4C7332CF834397CC256E87006892D6.
Comments