I am writing this essay to support those of you who are confused about why some of the technologists keep going on and on about Intellectual Property Rights (IPR). First of all, what the heck is it? Why does it matter? How does it work? Why should we get it figured out “now” rather than later?
IPR and the tone of worry around it confused me early on in 2005 when I was just getting started leading the Internet Identity Workshop. At that first workshop, a session had been called by Johannes Ernst, who at the time had created a protocol he called LID, Lightweight IDentity, to support people using a URL they had control of to do authentication (i.e., to prove they were the owner of that URL). He called a session with the other URL-based/URL-like identity authentication protocols in the room — OpenID (when it was a LiveJournal thing), Sxip and XRI. These formed into what they called YADIS — yet another digital identity system. After they began working on it … they decided OpenID was the best name of the bunch so they called it that.
At the time they kept worrying about how they could collaborate and they sensed that they needed to have IPR dealt with, but I couldn’t understand what they were going on about. This small thing delayed them working together for a long time. They literally had to spin up a new organization, get new bylaws developed and get everyone to join and sign off on the IPR regime before they could formally talk together about how to get all work to align and come up with one protocol.
Why couldn’t they just talk together and build something? Why did they need an organization and a structure and agreements? They had met at IIW just fine and talked…but what was different when it came to formally collaborating and writing something together?
Without an IPR agreement in place, many bad things could happen that would necessitate lawyers, after which all the well-meaning people’s work could be lost. What you are saying? Lawyers and lost causes…it all sounds so dramatic.
Introduction to IP
So, where to begin. There are several different forms taken by intellectual property, and almost all of them come into play here with their own rights structures.
Patents — A patent is a form of right granted by a given government to an inventor or their successor-in-title in a given jurisdiction, giving the owner the right to exclude others from making, using, selling, offering to sell, and importing an invention for a limited period of time, in exchange for the public disclosure of the invention.
Copyright — A copyright gives the creator of an original work exclusive rights to it, usually for a limited time. Copyright may apply to a wide range of creative, intellectual, or artistic forms, or “works”.
Trademarks — A trademark is a recognizable sign, design or expression which distinguishes products or services of a particular trader from similar products or services of other traders.
Organizations of all types work together to create all three of these types of intellectual property. When employees join companies or contractors work for them, they generally sign agreements that say the work they do for hire for the company is owned by the company (not the individual people doing it), so even within organizations there are explicit systems for managing intellectual property rights.
Corporations file paperwork with the relevant government(s) to be granted patents and trademarks. They might also file for specific copyrights, but these rarely have to be filed in advance to be exerted.
Collaborating around IP
So given that IPR exists, how do you manage it when you are working together in technical communities to define specifications that are open and to collaborate on open source code. There are slightly different considerations for each, and these require different IPR regimes before companies feel safe collaborating. This post centers on specification and we will talk about the difference between Open Source and Open Standards in an upcoming article.
Let’s start with a protocol or a specification that you want to be “open”, meaning that after it is done, anyone can use it (i.e., anyone can create code that speaks the protocol). Anyone who had patents that are included in the protocol can not charge licence fees for usage of the protocol. (Nit: Some technical organizations charge a fee for the text of the specifications as a dues structure to sustain the sponsoring organization, but this is not to be conflated with licensing, since the implementation of the specification is licence fee free.) Examples of open protocols include the e-mail protocols SMTP and POP, and web protocols HTTP and HTTPS.
Companies working in technology have various things under patent. To make the space for collaboration safe for everyone, they want an organizational boundary in place that can require everyone to agree upfront (i.e., before they contribute to a specification) that they will not go after anyone who implements the standards for violating a patent they have that is included in the mechanics of the specification.
In plain language, this means that even if they hold patents related to the work being done collaboratively, they agree going forward not to charge users of the resulting, collaboratively-designed specification or protocol for the use of ideas that went into the process that are covered by patents.
If you just have a group of companies collaborating on a project without an IPR boundary or “membrane” that filters out potential future patent problems, today’s goodwill between participants is little guarantee.
There is a lot of diversity in the category of future patent problems. Someone who was contributing without declaring that they hold a patent related to the work can claim they had a patent later (years after the specification is finished) and seek payment from everyone using/implementing the standard, claiming licensing rights or even lost revenue on ideas they legally own.
This sucks and it has happened before. Because this has happened before…companies are smart and they will not implement a standard that doesn’t have the sign-off from everyone who created the standard so they don’t have to deal with the future risk of being sued by one of the creators.
If work happened to be created outside an IPR framework, but at a later time everyone who created it retroactively agrees to an IPR regime, then others will be able to use it without fear. That might sound reassuring, but “everyone” is doing a lot of work in that sentence. The process of retroactively finding all the companies and individuals who contributed, particularly if work was done remotely by an open-source community including pseudonymous or volunteer members, and then having all of them and their employers’ legal counsel sign off on any post-facto agreement is very time-consuming and there is always the risk that someone won’t sign or that you can’t find one of the past contributors.
Furthermore, “significant contribution” can be difficult to define, and even more difficult to prove or disprove, so the list of parties included in “everyone” can be difficult to pin down. For this reason, guests and listeners on standards calls are often admonished not to say anything “too specific” or concrete about specific solutions to problems discussed, as those could be considered significant contributions that changed the course of the collective conversation and solutions produced by it. The tension between openness of conversations and IPR protection it is best to read the IPR agreement, and if needed get legal opinion about how you/your company can contribute if you want to.
Another hazard against which collaboration needs to be protected is that ideas discussed or generated in a working group or other collaborative context can be “taken,” i.e., patented, by any listener or observer. In fact, patents can sometimes be obtained quite quickly in other jurisdictions, or exerted retroactively to the time of first filing, so an idea can effectively be patented the day it is first discussed in any collaborative context that does not require its participants to waive all patenting rights. This kind of waiver can be daunting to for-profit participants, but it also supports collaboration of the most productive kind.
This balance is usually struck by agreeing very explicitly and in granular detail about the exact scope of a group and waiving patent rights to the resulting specification (While retaining the right to the patents for usage outside the specification), while censuring discussion beyond it.Some companies are more sensitive than others about this and really want to make sure all the pieces of a potential implementation are covered by IPR, including implementation details a little further from the working core of the code like schemata, data dictionaries, and other semantics. In the decentralized identity space, this includes not just identities and data structures but also credentials, data flows, architectural designs, etc..
Read all posted signs before jumping in deep water
Before you can contribute to an open standards working group, it is important that you always disclose (and in some cases release) any patents that might conflict with the scope of the working group. This is why the scope of working groups is defined in a charter, and why its so important to have participants adopt the charter.
It is also why it is risky to have a vague or open-ended scope, since people won’t know if their existing IP is relevant or not. Furthermore, if the working group later decides to reinterpret the scope in a way that impacts the IP of existing members, this can cause real problems, as it becomes very difficult to distinguish which ideas down the road would or would not have been arrived at without the earlier participation of the parties that did not yet know they had a patent conflict. Substantial changes in scope are generally cause to close the group and recharter a new one, to minimize this kind of legal ambiguity.
Participating actively in the scoping discussions is the best way to get a rich and multidimensional understanding of the boundaries of a given charter’s scope, and discussing with trusted (and tech-savvy) counsel is a close second. When in doubt, ask a lawyer — we are in the ideas business, after all.
Hopefully this quick introduction made clear why starting a working group (or even joining one!) is such a complex deliberative process — and gave you the tools to navigate it for yourself.