Fear and loathing and open core

Bradley M Kuhn published an interest blog post at the weekend explaining why he believes Canonical is about to go down the open core licensing route and heavily criticising the company for doing so.

My take on the post is that it is the worst kind of Daily Mail-esque fear mongering and innuendo. Not only does Bradley lack any evidence for his claim, the evidence he presents completely undermines his argument and distracts attention from what could be a very important point about copyright assignment.

The premise? Mark Shuttleworth has admitted that he plans to follow the open core licensing strategy with Canonical.

The evidence? Mark praises the strategy Trolltech took of selling proprietary licenses.

The problem? Trolltech did not follow the open core licensing strategy. Neither did MySQL, which Bradley suggests inspired Trollech’s strategy.

Both MySQL and Trolltech utilised a dual licensing strategy, which means that the same code base is available under on open source license or a closed source license (also known as “selling exceptions”. This is not open core licensing, although it is related since open core sees vendors dual licensing and offering extensions only available in the closed license version.

A significant difference between dual licensing and open core is that Richard Stallman has explained why, in his opinion, it is okay to sell exceptions to GPL code via a dual licensing strategy. In fact one of the examples he uses is… Trolltech.

So Trolltech is not open core. Or is it? Perhaps it depends on how you define it. Bradley has claimed, at least twice, that there is no agreed definition of open core.

If that were true you could forgive his confusion, but it clearly not. In fact the term open core was delivered fully packaged with a specific definition, courtesy of Andrew Lampitt. As I previously noted, you have to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.

Since Mark’s comments about Trolltech are the only evidence put forward that Canonical is going open core I’m not going to debate that any further.

It is worth considering a couple of other claims Bradley makes, however – such as the idea that Nokia abandoned Trolltech’s business model. It is pretty clear that a company like Nokia has very different motivations and business drivers compared to a company like Trolltech. A strategy that works for Nokia does not mean the strategy that worked for Trolltech was wrong.

However, it is worth noting that in fact Qt business continues to operate the dual licensing strategy. What has happened is that the company has added a new LGPL option and launched a public repository for the software and abandoned the previous requirement for copyright assignment.

This is not a change in business strategy – this is a change in the licensing, development and copyright strategies. Just because Nokia is in a position to open up the development project to encourage more collaborative development (which I agree is a beneficial arrangement for everyone) does not mean that Trolltech’s closed development strategy wasn’t successful.

Undoubtedly Trolltech’s insistence on copyright assignment limited its outside contributions, but copyright assignment does not equal open core, despite Bradley’s insistence that there is “no other plausible & logical conclusion”.

We saw a similar reaction last month in reaction to Diaspora’s copyright assignment policy. However, open core is by no means the only possibility. Dual licensing is another. And as we have seen that comes with RMS’s own seal of approval… except where it results in a version of the code that is only available as closed source (such as open core).

Richard Stallman’s advice on that issue is to “insist that the contribution agreement require that software versions including your contributions be available to the public under a free software license. This will allow the developer to sell exceptions, but prevent it from using your contributions in software that is only available under a proprietary license.”

This is good advice for any developer concerned about open core, and this is the message that gets lost amid Bradley’s anti-open core agenda.

It is absolutely fair to ask why Canonical demands copyright assignment, but to insists that the only reason that they do so is because they are going open core, especially on such flimsy and misleading evidence, is scaremongering and distracts attention from the real issue – which is copyright assignment.

It should be noted, incidentally, that Bradley and Mark have some previous when it comes to copyright assignment, which was also, I believe, caused by confusion rather than malice.

See also this poston the difference between copyright assignment and participation agreements.

Tags: , , , , , , , , , , , , , , , , , , , ,

11 comments ↓

#1 William Chambers on 10.18.10 at 2:06 pm

Thanks for the rational article. It’s great to see an arguement based on ‘facts’ rather then pure opinion, speculation and reading between the lines.

#2 Patrick on 10.19.10 at 7:52 pm

I completely agree, William.

A nice, clear rebuttal of a specious and thin collection of claims.

Also, Matthew, thanks for the links to the very interesting articles

#3 Matthew Aslett on 10.20.10 at 2:47 am

Thanks Patrick, and thanks for redirecting Sankar and Jesse

#4 Sankar on 10.18.10 at 2:30 pm

I see Mr. Kuhn and Canonical having some disagreements. I am a simple developer who does not want to get into much legal discussions. So, please answer in one word, for the following two questions:

1) Will Canonical use my open-source contributed patch to make a proprietary service / product ?

2) Can Canonical make a public announcement confirming the answer to above question ?

Thanks.

#5 Patrick on 10.19.10 at 7:44 pm

Sankar,
You are asking someone who doesn’t purport to speak for Canonical to provide definitive answers as if they have the authority to do so.
I would suggest you put your questions to Canonical.

#6 Jesse Weinstein on 10.19.10 at 3:41 am

I’m a current user of Ubuntu, and hope to continue being one — but I’m disturbed by the sort of claims I’ve been hearing.

I’d also echo what Sankar is asking, in slightly different terms. Will Canonical add language to their contributor agreement similar to that used by the FSF and numerous other organizations, binding Canonical to release the work that the contributor added to under a free license? It’s a simple matter of reciprocity with your developers, guaranteeing that they won’t be taken advantage of.

Until that’s done, all the noise about “fear mongering and innuendo” looks disturbingly like blowing smoke and putting up mirrors.

#7 Jesse Weinstein on 10.19.10 at 8:32 pm

I’m sorry, I mis-read the author of this blog, Matthew Aslett, as Matt Asay, the COO of Canonical. I’ll make my requests to him, then. Sigh, this is why I shouldn’t post late at night. 😉

#8 Matthew Aslett on 10.20.10 at 2:49 am

No problem Jesse – one area I do agree with Bradley on is that I don’t understand why Canonical can’t or won’t provide an answer to the question you raised

#9 Adam Williamson on 10.21.10 at 11:59 am

“Since Mark’s comments about Trolltech are the only evidence put forward that Canonical is going open core I’m not going to debate that any further.”

You seem to have missed the point about Jane Silber trying to talk the GNOME Foundation into requiring copyright assignment, and the questioning of the point of Canonical’s ‘Project Harmony’, an attempt to get projects to ‘harmonize’ their contributor agreements, despite the fact that existing agreements vary significantly for perfectly valid reasons.

#10 Matthew Aslett on 10.21.10 at 12:09 pm

I haven’t missed the point, I think that’s a different point entirely. If Bradley had focused on that instead of baseless accusations about open core strategies I wouldn’t have written this post at all.

#11 451 CAOS Theory » Ultimate CAOS: top 10 posts of 2010 on 12.16.10 at 9:55 am

[…] Fear and loathing and open core October: Bradley M Kuhn claims that Canonical is about to go open core. We examined the (lack of) […]