tecosystems

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.