Mistakes made and addressed

Sunday, November 10th, 2013

Occasionally we make mistakes. When we do it’s appropriate to apologise, address them, and take steps to ensure they don’t happen again.

Last week, someone at Canonical made a mistake in sending the wrong response to a trademark issue out of the range of responses we usually take. That has been addressed, and steps are being taken to reduce the likelihood of a future repeat.

By way of background, there are a number of trademarks around the Ubuntu name and logo which we are required to “enforce” or risk losing them altogether. In normal companies, the rule is that nobody else gets to use your logo. In Canonical, we have a policy that says that there are lots of cases where people DO get to use our name and logo; this is because our policy takes the internet-friendly view that communities need to have rights to a name if they want to feel like they are part of something; we go even further and explicitly allow the use of our name for elements of satire and mirth around Ubuntu. Every country has different rules about trademarks and free speech, we have a global policy that is more generous than most jurisdictions by default.

We do have to “enforce” those trademarks, or we lose them. That means:

  • we have an email address, trademarks@ubuntu.com, where people can request permission to use the name and logo
  • we actively monitor, mostly using standard services, use of the name and logo
  • we aim to ensure that every use of the name and logo is supported by a “license” or grant of permission

As you can imagine, that is a lot of work. A lot of what we find out there is fine, fun, harmless or constructive. Sometimes however it’s pretty nasty: we have had OEMs forging Ubuntu certifications to meet requirements for government tenders, for example.

In order to make the amount of correspondence manageable, we have a range of standard templates for correspondence. They range from the “we see you, what you are doing is fine, here is a license to use the name and logo which you need to have, no need for further correspondence”, through “please make sure you state you are speaking for yourself and not on behalf of the company or the product”, to the “please do not use the logo without permission, which we are not granting unless you actually certify those machines”, and “please do not use Ubuntu in that domain to pretend you are part of the project when you are not”.

Last week, the less-than-a-month-at-Canonical new guy sent out the toughest template letter to the folks behind a “sucks” site. Now, that was not a decision based on policy or guidance; as I said, Canonical’s trademark policy is unusually generous relative to corporate norms in explicitly allowing for this sort of usage. It was a mistake, and there is no question that the various people in the line of responsibility know and agree that it was a mistake. It was no different, however, than a bug in a line of code, which I think most developers would agree happens to the best of us. It just happened to be, in that analogy, a zero-day remote root bug.

The internets went wild, Wired picked a headline accusing Canonical of a campaign to suppress critics, Debian started arguing about whether it should remove all references to the distro-that-shall-not-be-named but then decided to argue about whether it should enforce its own trademarks which lead to an argument about… oh never mind. The point is, people are judging Canonical over this, which is fine and correct in my view, because I am judging Canonical over this too.

Here’s how I’m judging Canonical. Your framework may vary, but I think this is quite a defensible one.

Judge the policy. In this case Canonical has a trademark policy that enables community members to use the marks (good) and allows for satire and sucks sites even in jurisdictions where the local law does not (great!). Failing to have a policy would not be a bonus point in this review :)

Judge the execution of the policy. Canonical does the work needed to maintain the marks; it monitors and responds to requests and notifications around the marks (good). In this case, the wrong action was taken Рa new employee was clearly not properly briefed about policy and sensitivities in a key audience for the company (bad).

Judge the response to the incident. Within hours of the publication of a response to our letter, the CEO, COO and legal team reviewed the decision, corrected the action and addressed the matter publicly. I apologised the moment I was made aware of the incident. And I’m reassured that the team in question is taking steps in training and process to minimise the risk of a recurrence.

For those carrying pitchforks and torches on this issue, ask yourself if that would be appropriate to a bug in a line of code in one of many thousands of changes being made monthly by a large team. No? Think about it.

 

On another, more personal note, I made a mistake myself when I used the label “open source tea party” to refer to the vocal non-technical critics of work that Canonical does. That was unnecessary and quite possibly equally offensive to members of the real Tea Party (hi there!) and the people with vocal non-technical criticism of work that Canonical does (hello there!).

For the record, technical critique of open source software is part of what makes open source software so good. It is welcome and appreciated very much at Canonical; getting reviews and feedback and suggestions for improvement from smart people who care is part of why we enjoy writing open source software. There isn’t anything in what I said to suggest that I don’t welcome such technical feedback, but some assumed I was rejecting all feedback including technical commentary. I was not – I was talking about criticism of software which does not centre on the software itself, but rather on some combination of the motivations of the people who wrote it, or the particular free ¬†software license under which it is published, or the policies of the company, or the nationality of the company behind it. Unless critique is focused on improving the software in question it is pretty much a waste of the time of the people who are trying to improve the software in question. That waste of time is what I had in mind with the comment; nevertheless, it was a thoughtless use of an irrelevant label. Please accept my apologies if you have been a vocal non-technical critic of Canonical’s software and felt offended by the label.

Healing old wounds

Monday, August 2nd, 2010

Greg, thank you for your sincere and gracious apology.

When one cares deeply about something, criticism hurts so much more. And the free software world is loaded with caring, which is why our differences can so easily become vitriolic.

All of us that work on free software share the belief that our work has meaning far beyond the actual technology we produce. We are working to achieve goals that transcend the merits of the specific products we build: putting software freedom on a firm economic footing means that it can realistically become the de facto standard way that the software world works, carried forward by powerful forces of investment and return and less dependent on what feels like the heroic efforts of relatively few software outsiders swimming against the tide.

Red Hat’s success in proving a viable business model around a distribution was a very significant milestone in that quest, for all of us. I don’t mean to diminish that achievement when I point out that it’s come at the cost of dividing the world into those that buy RHEL, and those that can’t or won’t. Red Hat’s success is well deserved, and our work at Canonical is not in any sense motivated by desire to take that away. Red Hat is here to stay, there will always be a market for the product, and as a result, we all have the reassurance that our contributions can find a sustainable path into the hands of at least part of the world’s population.

Canonical’s mission is to expand the options, to find out if it’s possible to have a sustainable platform without that dividing line. We know that our quest would not be possible without your pioneering, but we don’t feel that’s riding on anybody’s coat-tails. We feel we have to break new ground, do new things, add new ingredients, and all of that is a substantial contribution in turn. But we don’t do it because we think Red Hat is “wrong”, and we don’t expect it to take anything away from Red Hat at all. We do it to add to the options, not to replace them.

We should start every discussion in free software with a mutual reminder of the fact that we have far more in common than we have differences, that individual successes enrich all of us far more in our open commons-based economy than they would in a traditional proprietary one, that it’s better for us to find a way to encourage others to continue to participate even if they aren’t necessarily chasing exactly the same bugs that we are, than to chastise them for thinking differently.

On that note, let’s shake hands.

Mark