Thoughts on dual licensing and contrib agreements

photo by kwc

There’s been a lot of chatter lately about dual licensing in open source and its much-maligned companion the contributor license agreement. Since my last two community management gigs involved dual licensing and CLAs, I have a few thoughts on the subject.

These tools certainly make it harder to build a community. As Brian Aker pointed out in Drizzle, Licensing, Having Honest Conversations with your Community:

How do you have an honest conversation with someone where you say “yes, I will need the work you did for free, to be assigned over to me, so that I can make money on it”?

It’s not hard to understand that argument. As anyone who has ever tried to build a community will tell you, contributors don’t grow on trees. It’s a lot of hard work getting a community excited and motivated to work on your project. Having a single-minded focus on the thought process of your contributor community is probably the only way to build a community of any size or consequence.

From the perspective of the potential contributor, being asked for a contribution agreement by the project sponsor is really pushing it. The sponsor is already receiving hours, or maybe even days or weeks worth of free labor. Asking the contributor to sign a seemingly one-sided agreement is asking too much. Most open source contributors probably don’t have a lawyer on retainer (except for the employees of companies big enough to have legal staff), and few lawyers probably understand the benefit of signing these things.

photo from Butte-Silver Bow Public Library

So, that’s the view from the contributor side, but what about the project sponsor? I’m sure there’s at least as many views as there are project sponsors, but let me try to paint a general picture. When a corporate entity invests in creating a new piece of software, they’re adding an asset to their balance sheet that they’ve got complete freedom to do with what they want. One thing they can do is release the source code under an open source license, which we all celebrate as a great thing. They lose resale value, but they don’t lose the ability to relicense it. Even if there is no intention to ever relicense that code, the mere ability to do so adds to the balance sheet of a company. For example, I really doubt that MySQL Inc would have sold for $1 billion had the company not had exclusive ownership of the MySQL database. It’s doubtful Nokia would have forked over $153 million for Trolltech had Trolltech already licensed Qt under LGPL.

Contributors who balk at contribution agreements probably don’t fully understand how companies arrive at their decision to insist on them, and so ascribe it to malice or big company stupidity, when in fact it’s probably neither.

Open source projects of all stripes rarely get big, tangible features they truly lust after as outside contributions. Those big features are generally developed as separate projects. Instead, they get lots of small patches and improvements as outside contributions.

Taken individually, each patch is valuable, but not a game changer. So, for any one of these patches, as a sponsor of the project, the tradeoff between taking that one patch versus forever losing the ability to relicense the source code is no brainer. As in “no, don’t take the patch”. If the contributor can be convinced to relicense the patch, great, but otherwise, forget it.

While it may be possible to argue that the cumulative value of the delta between those patches one gets with a contributor agreement versus those that one would have gotten without requiring one is worth it over time, it’s very difficult to know what that delta is. Since that number is almost certainly unknowable, so is the benefit. And therein lies the rub.

Many of the arguments against having contribution agreements seem to be rooted in the idea that the patch contributor is the one who is being the most altruistic, and that the original provider of the source is the one who should be grateful. While it’s absolutely true that the one receiving the patch should be grateful, it’s important to understand that there’s a mutual exchange of value occuring. The contributor is partly avoiding the fate of needing to keep a downstream fork in sync with an ever changing upstream. Moreover, as was discovered in the Debian/OpenSSH fiasco, it’s often the case that the upstream has a valuable service to provide in merely saying “ur doing it rong”.

This is all my longwinded way of saying that potential contributors shouldn’t walk away from a project solely because the project requires contributor agreements. Projects can have very good reasons for needing them, and there can be substantial value in a good working relationship with these providers.

That’s not to say I’m in love with contribution agreements and the dual licensing model. They bring with them all of the problems that Brian and others describe. It’s way more work explaining to your community the need for contribution agreements and GPL licensing than it is to just do away with them and run a more community-oriented project. However, it’s one of the few ways that the open source community has proven worthy of significant financial investment and payoff, so we shouldn’t be too eager to cast it aside.

The only good reason to cast it aside is if there are better models out there, which Stephen O’Grady suggests there might be. Here’s the pitch:

But what if open source vendors could leverage their primary strength – distribution – more effectively as a direct revenue stream? I’ve been predicting for three years or so that they would do just that, via data aggregation and analytics. The alignment of customer and vendor goals is better in this model than in virtually any other. The simplest example of this model outside of open source is Google, who provides users with search at no cost, receiving in return massive volumes of data which they monetize both directly (contextual ad placement) and indirectly (algorithmic improvement, machine learning, intelligence for product planning strategy, etc). Why couldn’t software vendors employ a similar model, trading free software for user generated telemetry data? The answer is, they can. SpiceWorks, for one, is doing just that now, quite successfully, albeit not with open source software.

I agree this is a pretty neat trick if you can pull it off. I think Google, for one, is big enough to pull it off. But I also don’t think its an accident that Stephen had to resort to mentioning a closed-source vendor (SpiceWorks) to make his point. The problem with using open source with this type of strategy is that your downstream distributors can cut you out of the loop, stripping out key revenue and data generating tethers back to the mothership, as Canonical recently did with Firefox. Since Ubuntu users don’t represent a huge portion of Firefox’s user base, it’s probably not that big of a deal for Mozilla, but just imagine what would happen to Mozilla’s revenues if Microsoft started distributing Firefox rewired to point to Bing.

photo from Archie McPhee Seattle

The only real leverage that an upstream producer of open source software has in this case is withholding their trademark, and we all know how much the community loves that.

As I said before, open source contributors aren’t easy to attract to projects. They don’t grow on trees. Then again, neither do compelling, commercially-competitive open source applications. Since we’ve established we can’t plant orchards of contributor and application provider trees to get a lot of both, let’s make sure we’re brokering good deals for both sides to attract many more of both.