By Heather Meeker
Open source software has been around long enough that most people understand the basics. But commercial open source–COSS–is a different animal, and it’s one that universities, and the researchers who work for them, are only beginning to absorb.1 Open source has its roots in academic collaboration, so it dovetails perfectly with the mission of universities to promote free exchange of ideas. But many universities have not yet fully absorbed the world where so-called “soft IP”–in software, data and machine learning modes–rivals the value of patented IP–in widgets, medical devices, pharmaceuticals, and industrial processes. Today’s top research universities are catching up, but many still have a lot to learn about how to participate in the wave of COSS innovation. Likewise, many researchers have little experience in how to monetize innovation that is built around open source software. Both could benefit from a better understanding about how to leverage open source to create prosperity for academic innovators and the public institutions that support them.
The University Dilemma
The main challenge for universities is that COSS entrepreneurship is a bad fit for traditional technology transfer protocols. A typical university tech transfer process is handled via an OTL (Office of Technology Licensing). In this process, the OTL gathers invention disclosures from researchers, decides whether to pursue patents on the disclosed inventions, and if it pursues a patent, licenses the patent to private companies on a royalty-bearing basis. This model assumes that the only kind of monetizable IP is a patent. It still works pretty well for biotech and hardware. But it works poorly for software, data, and AI, and it fails almost completely for open source software.
Researchers, on the other hand, are swimming in a sea of open source licensing. Most of them use open source heavily in their research, and many of them produce software that they want to share by releasing it under open source licenses. Moreover, many scholarly publications now require authors to make any software or data underlying academic papers available under open source licenses. Open source licensing is today’s currency of academic exchange.
So, universities and researchers are operating in different worlds.
This disconnect is a product of historical misalignment. Fifty years ago, universities generally did not claim an interest in copyrightable works created by their researchers. They could have done so, under copyright’s work-made-for-hire doctrine,2 but they usually waived those rights, either expressly or in practice. Researchers, and their universities, expand their reputation by publishing in scientific journals. The papers written by researchers about their research are copyrightable works. Universities had no interest in laying claim to copyrights in scholarly papers. They freely allowed, and in fact encouraged, their researchers to publish, without any compensation to the university.
Then, starting about 30 years ago, rights in software suddenly became quite valuable. The same happened eventually with data and machine learning models. In parallel, during the initial technology boom of Silicon Valley during the 1980s, OTLs became significant revenue centers. Universities realized that, in order to participate in the good fortune of software startups that grew from university research, they needed to assert their rights in software copyright as well. So, over the last few decades, universities adjusted to capture this additional revenue, creating IP policies for use of software developed at university expense.
This expanded the scope of OTL licensing to software, but the process of licensing driven by invention disclosure mostly remained the same. The conflicts that resulted were structural. Patents claim discrete, identifiable inventions, but software development is incremental and distributed. Software patents can be hard to identify and very expensive to enforce. Moreover, starting in the 1990s, researchers in the software area developed a cultural aversion to software patents, and became less than cooperative in helping their universities seek software patents.
When open source gained ascendancy in the early 2000s, the interests of universities and researchers became even more skewed. Releasing open source code is effective to share knowledge and establish reputation in key software areas like infrastructure, security, and cryptography. Researchers developed more and more interest in making open source releases. In response, many universities developed policies for open source releases, but unfortunately, many did not adjust their licensing process. Researchers became frustrated, as OTLs tried to fit a square peg into a round hole. OTLs knew that much of the innovation in their institutions was eluding their grasp–in part because researchers began to ignore the OTL for software innovation, and make open source releases without the university’s knowledge or approval.
Without intervention, this state of affairs could not improve. Incremental changes in OTL policy were not working. The inventions-and-exclusive-license model contradicts the very nature of an open source license, which is non-exclusive by definition. Running royalties didn’t work; it is nearly impossible to track use of open source software to calculate them. And then there’s the compatibility question; university IP terms needed to work with the upstream open source licenses of the projects their researchers were integrating into their work.
What’s The Solution?
None of this is anyone’s fault. It’s the product of institutional structures built for a different era of technology transfer, and a sea change in what kind of technology is valuable. But it means that universities that want to support COSS entrepreneurship need to actively build bridges. So, how do they go about it?
First, the solution may be closer than you think. Aside from the OTL, many universities already have OSPOs (Open Source Program Offices), and entrepreneurship programs. These programs were created to promote open source innovation, and they speak the same language as the researchers. But there are still two challenges: All of the groups at each university need to collaborate with each other, and researchers need education on how to structure COSS businesses.
Some universities have adjusted by substituting equity for royalties. This is not an simple solution, because investors in startups dislike equity grants only a little less than they dislike running royalties. But moving away from running royalties in technology transfer can help smooth the process aligning the interests of researchers and universities for open source software. Other universities have tried “all-you-can-eat” flat fees, or fees only based on business milestones such as GA product releases, funding rounds or acquisitions.
What Do Researchers Need to Know About COSS?
There are also challenges on the other side of the equation. Researchers, many of whom have spent a career relying on grant funding, often have little experience planning out pricing and business models for private enterprise. As a consequence, they can have unrealistic expectations about how to turn open source software development into a business. After all, open source software is, by definition, free of charge, so the techniques for making money with it are not intuitive. This confusion is not unique to university researchers; many developers struggle to plan out a path to revenue and profit by developing open source software. That’s where education about COSS comes in. It’s a big topic, but here are the basics.
Open source software licensing is a licensing model: the rules under which software is used, and the sharing development model it enables. Commercial open source software (COSS) is a business model: how you make money with software you’ve released under an open source license. These are two different paradigms that interact, but don’t overlap.
Successful COSS companies have figured out how to mesh the two, but it is not easy. There are many COSS business strategies. Let’s start with the model that is most obvious, but not the most common or successful: technical support and professional services. In this model, the developer gives away the software, but makes money selling professional services like support and custom development. That’s a great business model for a small development shop, or sponsored research. But it won’t attract outside capital. That kind of model is human-resource intensive, so it doesn’t enjoy economies of scale. Private capital demands economies of scale, because private investors expect returns of 10x or more on their investments, due to the risk involved.
The most successful business models tend toward SaaS and hosted offerings, open core (where the base software is free and enterprise features are paid), dual licensing, and others. Most successful COSS companies use some combination of these. These models require planning and license strategy, as well as keen attention to branding and community participation.
License Choice Is Tactical, Not Strategic
When developers start to think about COSS, their first question is usually: What license should I choose? But the right first question is: What business model will I use? Once you’ve answered that, license choice is usually obvious. In part, that’s because there are very few serious choices. There are really only six open source licenses worth considering for most COSS projects: AGPL, GPL, LGPL, Mozilla Public License, MIT, BSD, and Apache 2.0. Choosing an off-brand license, or worse, writing your own, is not a good strategy. The FOSS ecosystem knows these six licenses. Their lawyers know them. Potential customers and contributors know them. A licensor deviates from them at its own risk.
In fact, perhaps counterintuitively, most COSS businesses choose permissive licenses like Apache 2.0, MIT or BSD. License choice is always a trade-off between adoption and control. The more control you exercise by imposing conditions on use of the software, the more friction you will impose on potential adopters. The aim of most COSS businesses is to maximize adoption of their free software offerings, so permissive choices are the most popular.
One other thing worth noting: there’s a growing world of “source available” licenses–BUSL, Polyform, the Elastic license, FSL–that are not precisely open source, but are often combined with COSS models. They impose license limitations, like non-commercial or evaluation only. These can be useful tools, but by choosing them instead of a true open source license, you will be giving up in community goodwill and creating friction that might prevent adoption.
The Inevitable AI Discussion
Finally, a word on AI, because no technology conversation today can avoid it. Licensing for AI is different from licensing for algorithmic software. AI models are not source code, which means some open source licenses can’t function quite the way they do in software; you can’t really “share the source code” of a trained model in any meaningful way. The AI artifact ecosystem is fragmented: weights, training code, training data, UI, monitoring and filtering tools, and orchestration layers all raise distinct licensing questions. Standardization is coming, but it hasn’t arrived yet. Bespoke “open source” licenses used by projects like Llama are not actually open source under the traditional definition. RAIL licenses, which impose ethical restrictions, are neither open source nor very popular. For now, Apache 2.0 and MIT are the dominant choices, supplemented by Creative Commons for data. But these choices are band-aids, because these licenses are written for software, not model weights or data. Expect a great deal of development in this area in the coming years.
For COSS to work for universities and researchers, both sides need to learn more about how COSS works, and develop realistic paths to productivity.
If you want to learn more about how to make COSS work for academic projects, feel free to contact us at Chinstrap Community. One of our workshops, COSS on Campus, is aimed specifically at university staff and researchers. All our resources are free of charge. Learn more at chinstrap.community .
- In this article, I refer to researchers, professors, lecturers and grad students–anyone employed in a university setting–as researchers. I also refer to universities, research institutions, national laboratories, and other public institutions as universities. The principles here apply largely equally to most persons and institutions involved in a public technology transfer process. ↩︎
- This doctrine holds that copyrightable works produced in the course of employment belong to the employer. It is a somewhat complex doctrine, but there is more information here: https://copyright.gov/circs/circ30.pdf ↩︎
Leave a Reply