I wrote yesterday about Eben Moglen's upcoming OSBC keynote. It's clearly intended to be a shot over the bow of both proprietary and BSD-style licensing. And that's fine, as we have a wide range of perspectives represented at OSBC.
Gianugo replied to the post, arguing
This is a perfect example of what’s wrong with Open Source nowadays. I keep hearing the argument that GPL is the best way to avoid your competitor to run away with your code, and I just can’t stop thinking how this is the correct answer to the wrong question. First of all, in Open Source (or should I say Open Development?) there shouldn’t be such thing as “your” code: commons-based peer production of software is all about sharing technology, and build value upon it.Code is just part of the game: ultimately, what you definitely don’t want to happen is your competitor running away with your value, and there is much more to value then just code. Your competitor can run away with your code just fine, even in the GPL world, but this isn’t going to make a substantial harm to your business: Unbreakable Linux anyone?
Well said, and very true. The problem, however, is that many see this additional value as not being very open, either. Joel West insightfully wonders whether such open source strategies (like Red Hat Enterprise Linux) are "open" at all.
The Red Hat business model has always been about creating switching costs — getting buyers to adopt and find “sticky” the Red Hat implementation rather than embracing a truly open (and thus commoditized) open standard. Red Hat Exchange they have added vertical integration as well: a one-stop shopping for support for a wide range of open source packages. This seems to be in competition with IBM, which might seem strange since in 1999 IBM put them on the map. OTOH, Microsoft and Intel didn’t pay a price for ingratitude, either.In our research on Linux adoption [PDF], Jason Dedrick & I found that Red Hat buyers ascribed an option value (in the sense of a stock option) to the possibility of getting an alternate supplier for Linux — something they obviously didn’t have with Windows. But if this is an option that is never exercised — or from a practical standpoint, can’t be exercised due to “stickiness” around the service offering — how is Red Hat’s business model different from Microsoft’s? Other than they only have to pay for roughly 13% of their R&D instead of 100%?
Good points, Joel and Gianugo. To both points, I'd say "the bits are free, the service need not be," as Michael Tiemann express it. This is the sort of business model that Gianugo - a developer on Apache projects - believes in, but which Joel questions as truly "open." It's a business model I heartily endorse.
It is not my job to ensure my customer can easily leave every bit of value I provide. I open my code under a license that ensures perpetual freedom of that code, which forces me to provide ancillary services to provide extra value around that code. (Alan, this is what our partners and customers gained from Alfresco's move to the GPL, in response to your nice rebuttal to an earlier post). If these services become sticky, in Joel's terminology, that's a fault I'm happy to have (though I take his point, and believe he was talking about much more than support services when he refers to Red Hat's "stickiness").
So, where does this leave BSD/Apache-licensed code? As I've written before, I'm a big proponent of the GPL. Others are equally voiciferous for BSD. I have no problem with BSD-style community development - I think it's fantastic. But what I reject is BSD-style corporate development, because I've yet to see anyone in the corporate space that trumpets BSD that doesn't, in the same breath, trumpet their proprietary add-ons to BSD-licensed software.
Some argue, as Allison has, that people that pick on these "hybrid source" companies that it's because we simply prefer GPL over BSD. This completely misses the point, as my/others' frustration with these so-called BSD companies is not with their BSD code...it's with all the other code they ship. The code that actually makes them money. As Dave Dargo persuasively writes:It's interesting that some say that BSD doesn't require EnterpriseDB to publish their source code. But, BSD doesn't prevent them from publishing their source code either. For that matter, there's nothing preventing Oracle from publishing their source code save their desire to be a closed-source, proprietary product.
Let's see, the Oracle code that executes PL/SQL is closed and proprietary. The EnterpriseDB code that executes PL/SQL is closed and proprietary. It seems to me that EnterpriseDB is more akin to Oracle than it is to PostgreSQL, the base upon which it is built.
It's great that EnterpriseDB contributes back to PostgreSQL, but that's not the raison d' etre of their business. Their business is selling proprietary solutions to compete against Oracle. Those solutions consist of closed-source software and that makes them a closed-source company.Again, I have no qualms with BSD/Apache-licensed code. Quite the opposite. But I do have qualms with companies hiding behind the BSD/Apache label when their business, unlike Gianugo's, isn't about free and open source software. It's about proprietary software add-ons, which is what IBM and others have been about.
Is this any worse than closing off the services the surround free and open source code, as per Joel's and Gianugo's complaints above? I think it is.
Also, it's important to remember that no matter the handwringing that goes into the GPL as not being open enough or leading to walled gardens, these concerns have been raised before. In fact, back in 2001/2002 I wrote this paper for Larry Lessig as part of my Stanford Law work [PDF] that suggested that the GPL, far from hurting the adoption of software like Linux, has actually helped it:
At the heart of Microsoft’s attacks on Linux is its derision of the General Public License (“GPL”), the source of Linux’s phenomenal growth in the server market, as well as the likely cause of its frustrated progress on the client-side of the OS market. At once Linux’s greatest strength and weakness, the GPL has proven to be a constant thorn in the side of Linux’s market acceptance. As the argument goes, through restrictive license terms that require all derivative works to be open sourced, the GPL effectively kills the ability to earn a competitive rate of return from designing GPL code, in turn diminishing the pool of developers willing to write GPL software. Though the GPL may well be enforceable in a court of law, it seems doomed to unenforceability in the court of economic viability. Unfortunately, history is increasingly unkind to this interpretation of the GPL. A year ago, Mundie and the Microsoft crew were correct in their assessment, because a year ago the world was listening. This paper will show that the world has, in fact, changed, and that the GPL, now increasingly understood (and hence, less feared), is driving Linux onto every “embedded” device and server in the world.
I believe the GPL was instrumental in making Linux the community and corporate success that it is. Is it a necessary precondition? No. We have a range of successful Apache projects, among others, that would suggest that BSD/Apache-style licensing is important, too.
So, I suppose at the end of the day it's what you can build a business with. For me, that's the GPL. For you...?