Trademark and the Tempest

Of the four core legal intellectual property protections, trademarks haven’t received the least attention from the open source community – that title belongs to trade secrets. Relative to copyright and patents, however, trademarks have been paid far more limited attention, historically. It’s not that they’ve been ignored. As has been noted elsewhere, there are specialists that have devoted decades to thought and study around the practice.

But the industry has typically handled them via common consensus rather than explicit legal mechanisms as it has for, say, copyright. For this reason alone, the announcement of the Open Usage Commons (OUC) this week by Google was an interesting development for those who follow the structures that underlie and gird open source ecosystems the world over. Setting the real and legitimate questions of control, execution and implementation aside for a moment, if the question is whether trademark should be elevated towards a similar status with its copyright and patent counterparts, at least, the answer here at least is clear.

The most obvious justification is that trademarks have been a brushfire of an issue for open source historically. Never elevated into a legitimate crisis, but igniting without warning every so often and leaving collateral damage like Iceweasel in their wake. From Canonical to Mozilla to Red Hat, trademark has been a chronic issue, an issue that would presumably benefit from some explicit clarification whether or not one believes the OUC is the appropriate mechanism to provide it.

Perhaps more important than flareups, however, is the potential for trademark to usurp copyright as the legal fulcrum on which commercialization hangs. The value of a mark – for technology providers, or any other industry for that matter – is obviously not a new development. It’s not even new for open source; Red Hat’s value and subsequent $34B valuation were around its brand, because its source code was – after its early years, at least – publicly available. As Steven J. Vaughan-Nichols quotes then Red Hat’s deputy general counsel and secretary Mark Webbink saying in 2004, “In the open-source economy, it’s the Red Hat brand, as well as its service, that carries value.”

But these lessons have not, in general, been widely absorbed. A large number of commercial open source organizations still operate in a fashion consistent with a copyright – read source code – centric strategy, rather than a Red Hat style mark-based approach. The most obvious example of this was the trend in recent years – now thankfully appearing to be paused – to attempt to address business model issues with hybrid, open source-like licenses that violated the core tenets of the open source definition. The costs of this approach – both hard in real dollars as well as soft in good will and public relations – only make sense if the core assumption is that the fundamental value of a commercial organization’s product lies in the lines of code it, or potentially third parties, has written.

The value of a trademark, on the other hand, has been made more obvious in recent years. First, the potential downside to a lack of control over a mark was evident in the case of Elasticsearch. Originally released in 2010, the project proved immensely popular and spawned its own commercial entity, now called Elastic. Five years after its creation, however, AWS spun up its own instantiation – an instantiation that it called AWS Elasticsearch. Four years later, the acrimony over this use of the mark led to a lawsuit for trademark infringement, among other things.

Conversely, Chef has taken a different path. Rather than attempt to isolate and outlaw a subset of use cases through complicated, norms-violating licensing machinations, the company instead is turning away from licensing as a commercial trigger in favor of trademarks. Implicit in that statement, of course, is an assertion that the value of the software lies less in the source than the mark.

Combined, then, we have an environment in which trademarks have been both a historical issue – if chronic rather than acute – as well as an emerging commercial focal point. Against that backdrop, then, catalyzing a broader industry discussion on trademarks that would shift it from a specialized consideration to fundamental plank of open source projects would seem a useful exercise.

This was the opportunity in front of the Open Usage Commons recently announced by Google. It is, in brief, a home for open source project trademarks – nothing more and nothing less. It offers none of the governance that is table stakes for traditional open source foundations, and has narrowly circumscribed its purview.

The opportunity to put the focus squarely and solely on trademark, however, was lost when Google decided to include Istio among the initial projects housed in the foundation. As such, predictably, discussions of the foundation have been colored by impressions of Google’s stewardship of and behavior around the Istio project. In many cases, perhaps the majority of cases, discussions of the OUC devolve into a referendum on Istio rather than the trademark foundation. Specifically, whether the project should be moved to the CNCF as entities like IBM or Tetrate explicitly or implicitly respectively call for, or whether its future lies elsewhere, as Google is signaling that it does.

For those unfamiliar with the controversy behind Istio, the short version is that it is an open source service mesh project, one launched by Google, IBM and Lyft three years ago and has since seen contributions from the likes of Cisco and VMware. Determining precisely what has happened since the project was jointly founded depends on which party is relating the events, but the basic facts are straightforward. While the project was not immediately housed within a foundation, the reporting suggests – and is validated by IBM’s public statements – that the expectation was that it would be eventually. By multiple accounts, however, Google – which had a controlling number of seats on the project – appeared to unilaterally decide against this course of action, just as it did with Knative. Later it backtracked on the decision to not send Istio to a foundation – possibly in response to substantial customer objections – but the foundation Istio was sent to was not the one anyone, including the other corporate Istio contributors, expected.

Setting aside discussion of the merits of a foundation in terms of advancing projects, inarguably Google’s behavior with respect to both the Istio decision individually and in combination with its Knative directive have cost the company politically. It’s united would be collaborators of Google against the company publicly in some cases, but more problematically, privately. These private conversations, notably, have directly considered the so-called nuclear option of forking one or both projects.

Importantly, none of this macro-level controversy was a Machiavellian, back-channel affair. Public criticism of Google’s stance here has been as common as it has been public, whether from the press or from members of organizations that have contributed to the project.

Which means that Google was aware of the controversy around Istio and selected it as a headline project for the OUC anyway.

There are a few different ways to interpret that statement. If you’re inclined to give Google the benefit of the doubt, Istio is effectively a strategy tax on the genuine concerns with trademark that Google is attempting to address in the OUC. If you’re more cynical about their intentions, Angular and Gerritt become collateral damage in a wider war being waged around the Istio project.

In either event, the situation is unfortunate and unnecessary. Given trademark’s rising importance, it would be useful to have conversations centered on strictly that subject and the foundation built to tackle it, because the questions around the OUC are many. For example:

• Given the ownership by Google, LLC in the filing paperwork, is the organization truly independent and if so, how can this be assured?
• When will the board membership be extended and diversified? Allison Randal is very good, known and trusted, and her involvement here carries a great deal of weight as it should. But she’s also just one individual.
• What is Google’s commitment to this long term? Besides its reputation for being overly willing to deprecate projects generally, this isn’t the first time Google has spun up a major initiative to address an issue it perceived with open source, and not all of those projects survived.
• What are the licensing terms and how will the mechanics of housing trademarks for externally housed projects work?
• What is the OUC’s response to Pamela Chestek’s naked licensing and abandonment concerns?
• Will the market see the need for this in the way that Google does?

Instead, however, the OUC has ignited dozens of threads of commentary around Istio, Kubernetes and the CNCF – threads of commentary that, while important and legitimate in their own right, represent distractions from the very issue the OUC was ostensibly created to address.

It’s easy to imagine a world in which Google announces the OUC without Istio, a world in which the current discussion centers around the merits of separating trademark ownership from traditional concerns such as project governance and the specific foundation-driven approach Google took to same.

But that’s not the world we live in.

In his impeccable account of 1776, the year the groundwork for the country that came to be known as the United States was laid, the historian David McCullough talked about how one of George Washington’s greatest strengths as a general was his ability to see the field for what it was, not what he wished it to be.

That being an approach worth emulating, it is probably time to welcome and commend Google for shining a brighter light on trademark as an area of necessary attention while bitterly lamenting its decision to hopelessly muddy the waters by launching with a project so besieged with controversy.

Disclosure: AWS, CNCF, Elastic, Google, IBM, Mozilla, Red Hat and VMware are RedMonk clients. Canonical, Chef, Cisco, Lyft and Tetrate are not currently customers.