Correcting the Record on Dual Licensing

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

When Paul Brown wrote up his “Email-Only Press Policy” entry last week, I certainly understood the thinking. It’s one of the reasons that I actually prefer, in many circumstances, to conduct interviews by IM. That said, I thought the policy would be overkill in my particular situation, as I’m blessed to work with some good reporters that respect my comments and the context that they’re delivered in. After reading Eric Lai’s recent piece in ComputerWorld, however, I have to say that I’m considering instituting a similar policy for reporters I haven’t worked with before.

I’d never met Eric before, but exchanged emails during the MySQL show and ended up having a pleasant twenty minute or so conversation in the press room at the conference. We discussed RedMonk and our background, various open source subjects, the conference itself, and – very briefly – Google’s MySQL patch.

When asked whether or not this patch would be incorporated back into the mainline MySQL codebase, my answer was simple: “I don’t know.” As indeed I did not, not having to spoken to anyone on either the Google or MySQL sides of that particular equation. Explaining my uncertainty in more detail, however, required further explanation of the dual-license model under which MySQL (and many an open source project)operates.

The short version of my explanation went something like this: in layman’s terms (I know there are exceptions and gray cases), there are two basic models for open source development. Single-entity development, as I’ve referred to it (feel free to come up with a better name), and what Simon would call co-development.

In the first model, a single entity such as MySQL is responsible for the overwhelming majority of all development on a given codebase. Anything they don’t produce themselves, they license. Very often this is practiced in conjunction with the dual-license model; because MySQL is responsible for virtually all of the development of the core code, they own or have licensed appropriately all of the involved IP. As such, they’re free to issue commercial licenses to those who would cannot or choose not to comply with the terms of the open source license – the GPL, in this case.

In the second model, multiple entities collaborate on a given piece of code, each contributing under the same terms to the overall project itself. The canonical example of this style of development is Linux, to which firms and individuals alike contribute to the betterment of the overall project. Because there is no one single “owner” of the IP involved in co-developed projects, the dual-license model is not an option: you can’t uniquely license, after all, what you don’t own.

Contributing code back to projects under either model is an involved process – contrary to what some of our less educated legislators might understand about how Linux in particular is developed. There are always IP licensing and ownership issues to consider; governance is never a simple subject. The combination of single-entity development and dual licensing does impose additional restrictions on what code can and cannot be accepted, but as several firms prove on a continuing basis, it’s a model that has legs.

In his piece, Lai quotes me as characterizing the “attitude” that restricts contributions as “schizophrenic.” Forgetting the fact that I would never call the dual-licensing model schizophrenic, I’d take exception to the notion that this is an “attitude” of MySQL’s. It’s a manifestation of the business model they operate under – no more, no less. There are certainly some who’ve contended that the model is less than “pure” open source, but as has been well documented in the past, I’ve never been one of them. It’s just another approach, as far as I’m concerned: one that has been demonstrated to work well under certain conditions.

He goes on to imply that I view the dual-licensing approach as fundamentally flawed, saying:

The problem for MySQL, according to O’Grady, lies in its dual licensing model, which lets users take the software under either the open-source GPL license or a full commercial license. Some of MySQL’s customers don’t want to use the GPL because it requires them to donate any changes they make to the software back to the community.

This has made it tricky for commercial software companies, for instance, that have tweaked and embedded a version of MySQL inside their applications.

To get around that, MySQL could sell its database using a regular commercial license. However, that puts pressure on MySQL to ensure that none of the code in the product is plagiarized from another application or otherwise infringes on any copyrights.

The easiest way for MySQL and any firm to do this is to employ the developers writing the code. Even buying the code from outside developers can be tricky and raises concerns among end users of open-source software that they may be unwittingly violating copyrights. That’s a drum that Microsoft Corp. has been beating lately in respect to Linux.

While he’s correctly understood my belief that the inability to more easily accept external contributions – as might be the case in co-development scenarios – is the drawback to the model, he’s missing the larger context to the remarks. Context which recognizes that despite this limitation, there are substantial business benefits to such an approach. Just as there are drawbacks and advantages to the co-development model. Given his interest in the subject, maybe we can get Simon to lead a session exploring the pro’s and con’s of co-development vs single-entity development at RedMonkOne.

Anyhow, I will not speculate on the motivation behind this (mis)use of my comments, except to state for the record that I feel both misquoted and misrepresented in the article. As I told one individual that contacted me on Friday, surprised by my “remarks”, it’s pieces like this that make me happy I have a blog. I know a bit about how Schilling felt, I think.

One last important note, as MySQL’s a customer of ours. This isn’t a matter of us criticizing a customer in public: we do that all the time, and will continue to. As an example, here‘s a piece I wrote just last Monday heavily criticizing IBM, one our patrons – i.e. largest customers. We’ve been very fortunate to have customers that value truth over fiction, and recognize that a RedMonk that spews only honeyed words is a RedMonk of extremely limited value. What I object to, rather, is having my comments co-opted in an attack on an aspect of a business model that I clearly have no objection to. It is both natural and understandable that writers have their own agendas and mission; all I ask is that my words not be subverted to serve that agenda if they’re not aligned.

In the meantime, I’ll give Paul’s policy some more thought.


  1. that sucks. good clarification. i am sure the team at MySQL and anyone in your community more broadly that saw the offending article were wondering WTF?! the thought of you describing dual license as schizophrenic is pretty funny.

  2. Perhaps you’d like to try Dave Winer’s policy. I ran into it on the PressThink blog at http://journalism.nyu.edu/pubzone/weblogs/pressthink/2007/05/01/when_fairness_r.html

    Rutenberg’s article made me wish I had followed, in this instance, blogger Dave Winer’s policy. When asked for a phone or e-mail interview, he usually declines. “If you have a few questions, send them along, and if I have something to say, I’ll write a blog post, which of course you’re free to quote,” he said last week. Responding to Winer, and to this event with Jason Calacanis and Wired magazine, Jeff Jarvis wrote: “The interview is outmoded and needs to be rethought.”

  3. Hi Stephen – I just saw this blog entry. I can only plead mea culpa for what is a mutual misunderstanding and some poor writing on my part, not a particular agenda on my part and certainly not to misquote you.
    My recollection was that I asked you whether it was “schizophrenic” for MySQL to accept bug fixes and also so strongly encourage partners to create storage engines, while going it alone on core database development.
    The point I was driving at and which I think you basically agreed with was that to a techie reader not particularly versed in the details of open-source licensing, it might appear contradictory for MySQL to encourage outsiders to help build the storage engines, which no other well-known DBMS encourages or allows, and yet be historically closed re: code for the core database.
    The paragraph that begins, “While MySQL has welcomed bug fixes…” was trying to explain that.
    Unfortunately, you’re right, a subsequent sentence, which begins, “The problem, according to O’Grady…” does appear to make you criticize the dual-licensing model in general, which is not right. I’ve asked my editor to change it from “problem” to “issue”.
    I consider RedMonk an excellent firm and both you and James to be very sharp, so I hope this doesn’t preclude future conversations.
    P.S. personally, I have no objection to e-mail or IM intvus.

  4. […] talk about what open source in a SaaS world, single-entity vs. multi-entity open source production, and then the horrors of learning object orientations by way of the perltoot page. Tags: saas, […]

  5. […] GPL, the rights granted by it to the users cannot be removed legally; with the notable exception of dual license scenarios which may act to remove the restrictions for the licensing entity. For all other […]

  6. […] those of you unfamiliar with the intricasies of the dual licensing practice, here’s a quick description. In dual licensing, …a single entity such as MySQL is responsible for the overwhelming […]

  7. […] while MySQL has long been the standards bearer for this approach – and the economic model that accompanies it – it’s not apparent that that approach will be indefinitely […]

Leave a Reply

Your email address will not be published. Required fields are marked *