In the last installment, I covered some of the strategy and organizational concerns around developing an impactful tech innovation. This week, we’re getting into some nitty-gritty details: intellectual property and licensing strategy. IP strategy is usually money-driven, but if you are developing for impact, this requires a different type of stewardship. The fundamental reason is this: when you put an innovation into practice, you take on the entire business process behind it. If this is not your organization’s purpose, you will need to take a different approach. There is a reason to try as hard as possible to get your licensing model right from the start: the space is highly litigious, and lawsuits become a financial, organizational, and emotional drain–another way good ideas fail rather than on the merits.
First, let’s talk about the basics of the types of intellectual property you might develop within the technology space: software and data. Software is usually automatically protected by copyright, which applies to the code as written. A competitor can reimplement the same features as long as they do not copy the exact code. Software or parts of software can be patented for broader protections, but the process is typically costly, slow, and sometimes limited by jurisdiction. Data is often not copyrightable in the U.S. (fun fact: this was decided in Feist v. Rural Telephone, a dispute over whether it is possible to copyright the phonebook, in which my in-laws were the printers), but the E.U. does allow it. In the U.S., data is protected only by contractual agreements like terms of use. In both cases, before disclosure, an invention or data can be protected as a trade secret. Take this with a grain of salt: as I have mentioned, I am not a lawyer.
Second, I think of developing and exploiting intellectual property as related but separate processes. If your organization is going to exploit the technology and data it develops, your organization will need to take on the business processes that support it. To put it simply, you will probably need to hire and manage software engineers. There is no way to have your cake and eat it: technology tools and datasets are not a way to generate revenue with no substantial overhead. In fact, many for-profit technology companies fail, even without mission-driven programming making up part of the organization’s budget. The impact move is often to license to an organization that already operates, rather than trying to own the whole chain. The fear that someone undeserving might profit from it is the wrong thing to optimize against. Instead look for win-wins where your method or data can be used fruitfully, and partner!
Let’s look at an example we are probably all familiar with: UPenn owned one of the foundational patents that underlies mRNA vaccine technology created by scientists Katalin Karikó and Drew Weissman. The research was funded by the U.S. government, which allows funding recipients to own and commercialize IP they develop–an outflow of their open innovation strategy codified in the Bayh-Dole act of 1980. Penn licensed the technology through a chain of agreements. Penn, as the originator of the patent, would receive royalties without taking on any of the massive manufacturing operations that would be required to commercialize such an in-demand product. The result was by far the most rapid and impactful vaccine launch in human history. There are some aspects of this that are worth calling out: Pfizer and Moderna each developed a similar competitor product that depended on overlapping licenses, and in both cases there is still ongoing litigation over the intellectual property.
Taken together, this leaves us with the following lessons:
Partnering with an established operator can be the fastest and most effective path to impact;
An innovation does not have to be completely novel, and, in fact, most are not;
Patents add a layer of legal complexity and cost that rarely make them the right first step for protecting an impact innovation, unless like a university, the cost and know-how is already part of institutional overhead.
Your core decision revolves around the question: does commercializing your innovation help or hurt your intended impact? If it would help or is neutral to the impact outcome, license permissively and consider partnerships with a player that is already operating at scale. If it would hurt your impact goals, choose a protective license that prohibits it, but only if you are prepared to staff the enforcement and contracting overhead. There are tradeoffs you will have to own, which you will do by seeking win-win arrangements. Your best chance of attracting a high-quality partnership is by providing steadiness and clarity from the start, which you will gain from having a clear view of your path to impact.
If you decide to license, here are some of the key decisions you will have before you:
Should the license be exclusive (only the licensee can practice it, and you may not be able to use it), sole (you and the licensee can practice it), or non-exclusive (you may make several licensing agreements)? Is it sublicensable?
What is the term and territorial scope of the license: perpetual, worldwide, or limited?
What rights does the licensee have to create derivative works or redistribute the property?
In my experience, when optimizing for impact, it is best to be as generous as you can with most terms while still preserving your own rights to use the IP yourself and to enter into new partnerships that may further your impact. From the licensee’s perspective, they are going to need to invest work and organizational energy into integrating and supporting your innovation, so they are optimizing for avoiding renegotiation and litigation, so they are looking for long or indefinite terms and relatively permissive rights over practice and derivative work. Your unique situation may be different, of course.
One of the most common questions I get about licensing and integrating works of technology is around the benefits and drawbacks of open-source licensing. In my experience, there are some social impact missions for which open-source licensing is ideologically aligned (missions around transparency or knowledge dissemination, for example), and some for which it may be a nice-to-have. Releasing something open source, however, is not a shortcut to impact if the stakeholders you want to influence do not adopt it. You will still have to pour work into adoption, just as if you had chosen a less permissive licensing model because changing the way people behave means disrupting their previous plans. It also does not preclude you from generating revenue or partnerships. As I mentioned in Part 3, many civil society organizations do just that, releasing their data or technology open source and creating revenue-generating commercial agreements for dependable professional delivery. In some cases, however, openness can interfere with an impact mission, something I most often see when a problem may take months to resolve or when it requires very sensitive data (such as data that describes victims of crimes).
I think of the tradeoffs in licensing decisions as generally grip-versus-reach, but even a permissive open source licensing model does not guarantee reach. Real impact is achieved when you are able to answer the question, “How do I get this into the hands of the people who can make it matter?” Being generous with an idea is not how you lose it, it’s how you make it real.
Choosing the right license structure can get you in the door, but the next challenge becomes fitting in within the world you are trying to enter. In part 5, I will discuss integrating with existing standards and incumbent software platforms to expand your options for reach.
From xkcd, who is obviously also not a lawyer, https://xkcd.com/827/