What's in a name? Tin Can, Experience and the Tea Party

On Friday I was at e-Assessment Scotland, getting ready for Fiona Leteney's closing keynote "Anyone need a Can Opener?" when I tweeted:

Getting ready for the #easc13 session on the Experience API adlnet.gov/tla/experience… - anyone got an experience opener?

I tweeted this because I wanted to ensure that the twitter-savvy audience at #easc13 understood that there is an issue with the name of the API and that, in my opinion, it is important. Fiona followed up on twitter and, I tried to put this in to 140 characters but it just wouldn't fit. Before I go on though, a couple of disclaimers...

This blog post represents my personal views, not the views of my employer or of any other organization with which I may be affiliated. In the interests of full disclosure, I work for Questionmark who have presented work related to this API at previous conferencess, including at DevLearn. Also, I'm not a lawyer! I am interested in the world of open source and in some of the legal issues that new technology throws up, particularly when they relate to intellectual property law.

So What's in a name?

The title of @fionaleteney's talk clearly makes reference to the "Tin Can API" but she did touch on the naming issue in the presentation and introduced the newer "Experience API" name with the observation that "Tin Can" is likely to remain the recognisable brand.

Many people in the community probably think the name doesn't matter and that arguing over a name is an unimportant distraction. Indeed, it all feels a bit like the Monty Python film, The Life of Brian, in which followers argue over whether the shoe or the gourd is the correct symbol to represent their community. I believe it is important, in short because I don't think an API like this can succeed if it gets this type of thing wrong. The argument goes like this:

1. The purpose of the API is to make it easier for activity statements to flow between the tools that generate or initially record activities and tools that aggregate this information.
2. Therefore, the API is essentially an interoperability specification that will be more successful if a wide range of tools adopt it.
3. To get a wide range of tools you need a wide range of tool suppliers to invest in adding support.
4. To get a wide range of suppliers to invest you need a level playing field and trust within the supplier community
5. To get trust, you need good stewardship of the API.

I've honed in on one particular prerequisite for success here. There are plenty of other challenges that an API like this faces, including other issues related to IP law. After the session one delegate expressed concern about the ownership of information communicated using the API, and I have heard privacy issues voiced too. These are important things to get right, even more reason not to distract the suppliers' legal teams with branding issues when they should be advising their clients on how to use the API to improve the learner's experience from the right side of the law.

You'll have had your tea

One aspect of good stewardship for an API is the branding. In practice, that means control of the trademarks associated with an API. To people in the technology world this often translates directly into domain names but that is only one way in which trademarks are used. What about Google Ad words? Google has a policy for that. And don't forget logos.

Of course, the big guns of the IT world get this type of thing sorted out before they even embark on a joint project but legal issues are often the last thing a small learning technology community thinks about. We're all well meaning, what could possibly go wrong? Why doesn't everyone trust me? What do you mean, I'm not allowed to team up with a small group of my competitors to gain an advantage over the rest of the marketplace? And so on... I have to thank Ed Walker for drawing my attention to the importance of getting this type of thing right when he was in his role as CEO of the IMS Global Learning consortium. He was particularly clear on the last point.

Thinking of Ed brings me (via Boston) to an interesting article about a similar problem in a very different domain. In Trademarking the Tea Party, an article from 2010, Beth Hutchens touches on an issue which resonates with the problem experienced by the Experience API community. In this case, during a dispute over the identity of a political movement one group seeks trademark protection for the Tea Party name and all the other groups cry foul!

The problem is that the Tea Party is more of a conglomerate of different groups of people based loosely around a set of common goals, and not a collective. This could be problematic in gaining trademark protection.

This could well describe the sort of informal grouping that tends to build up around an API. The author goes on to say...

It makes sense to have at least some sort of structure to keep squabbles like this from coming up in the future.

The suggested solution is set yourselves up as a collective movement with a distinctive name so that you can register a collective mark. As with anything law related, it makes sense to put a little work in up-front to ensure you don't have to spend a lot of time later figuring out who (if anyone) has the right to say how the name can and can't be used. The rest of the article is worth a read by the way, if only for its use of the word antidisestablishmentarianism in a justifiable context. But more seriously, it is a great introduction for normal people on what a collective trademark is.

Kicking the Can

To understand why the naming thing has become an issue for this API it is best to read the discussion We Call It Tan Can. There are two issues being debated here so it is a bit confusing.

1. Which is the better name: Experience API or Tin Can API? - this blog post isn't about this question, for what it's worth I voted for Experience API but I could live with Tin Can if we got the second issue straight.
2. What is the appropriate legal way for the community to manage and control use of the API's name?

It is clear that the community recognises the problem. The team that originally led the development of the API registered a trademark with a view to handing it over to the project sponsor, the ADL. ADL is part of the US government and it seems like handing a trademark to a government department has turned out to be trickier than expected. The US Government does have a succinct page on the issue of government owned IP though: Copyright and Other Rights Pertaining to U.S. Government Works. On this page it makes it clear that you can't use a government owned trademark without permission (no big surprise there) and clears up the confusion of which bits of government IP are in the public domain and which aren't. (An issue which has fascinating implications for the makers of model aircraft, but we digress.)

In the above thread, Mike Rustici goes on to say:

Since we're on the topic of trademarks, another significant issue to consider in this debate is the fact that "experience api" is not trademarked. If ADL is unable or unwilling to secure one, that is very problematic for the future of this spec.
...
Anybody could claim to support or own "experience api" rendering the spec (or at least the label) meaningless.

So who should own the mark? The ADL seems to be struggling to take ownership and, even it did, how would it determine the rules under which permission should be granted to members of the API community? If one member abused the mark, would the US government pursue them on behalf of the other members? It isn't clear that the ADL has the desire to fill this role on their behalf.

Let's take the very particular issue of domain names, though Google Adwords do raise similar concerns. Policies like ICANN's Unified Domain Name Dispute Resolution Policy make it clear that trademarks are an important part of determining whether complaints will be upheld. So if the API's name was owned by a neutral party would that group invoke the policy to ensure that names like experienceapi.com or tincanapi.com were used in a way that ensures there will be no confusion? You'd hope so. Right now, both tincanapi.com and experienceapi.com point to basically the same site controlled by just one member of the community and are used to promote their services over and above those of other community members. As far as this blog post is concerned, both names are problematic now.

With the benefit of Experience

It's no surprise that people have had this type of problem before and that there are legal patterns that a community can follow to help ensure that their IP, including any trademarks, have the sort of stewardship which helps attract members and build the community. Creating a new membership organization just for this API would seem onerous but the problem with choosing an existing one is that they'll have already established a way of dealing with the IP and it is unlikely to be a perfect match. Still, this seems to be the solution being explored by ADL, quoting again from the main thread: Plans are already being made to transfer ownership of the spec to an open standards body - this can't come too soon.

One final word of caution here. One of the grim duties that falls on the owner of a trademark is to ensure that it is being upheld and is not just becoming a generic term for a bunch of similar products from a variety of suppliers (hoover, biro etc). I recall the magazine Private Eye getting letters from lawyers when they used the word Portakabin in one of their articles. If confusion takes over around this API then none of the marks will be enforceable and we'll have to start all over again.