Having never had any experience in software development when I entered the world of academic technology transfer back in 2013, I never expected to learn so much in the intervening years about software licensing and commercialization. It turns out that, even working in technology transfer at a medical institution, I encounter a surprising number of software-based technologies. Furthermore, with the recent rise in the use of AI/ML applications in biomedical research, the frequency at which I am presented with software in my work is only increasing.
Below is my first attempt at summarizing what I have learned thus far in managing software assets within an academic technology transfer setting. None of what I write here should be viewed as constituting legal advice. Furthermore, if you are an academic researcher, you should most definitely rely on the guidance you receive from your own institution’s own technology transfer office when navigating these waters! However, I’m sharing my observations in a general manner because I feel what I have to share could be useful for a fairly wide audience.
Here are the main learning points I have gained:
1 - Patents aren't a necessary prerequisite for commercializing software
Software can readily be commercially licensed without patent protection.
Software automatically has copyright rights associated with it because, like an article or a book, it comprises a work of authorship. Copyright is a form of intellectual property in and of itself.
If a faculty member or a lab has written code performing certain commercially useful operations that demonstrably works, then companies are willing to pay money to access it simply because, on balance, obtaining that piece of ready-to-use code will be cheaper than having an internal software development team create its own code with identical functionality.
A simple thought experiment: let’s imagine that, to recreate an already-working piece of code that an academic lab has created, a company expects it will need to dedicate a team of three software engineers and a project manager on the task for six months. Even such a relatively simple project could easily cost a company a few hundred thousand dollars, in which case simply licensing the already-written code from the university for a sum that is lower than the expected cost in salary + benefits (not to mention other operational costs and the value of the time saved in getting that code now rather than in six months’ time!) would make a lot of sense. This might likely hold true even if that same lab has already published a paper providing a high-level description of the computational approach they took in writing this software. This type of value that is represented by already-written software, based on the labor costs and time costs of recreating it, exists independently of patent protection.
2 - Be deliberate in your use of third-party code
If you, as a researcher at a university or other non-profit research organization, are taking advantage of publicly available third-party software when creating your own software, be sure to keep a complete record of all such pieces of software (including libraries) that you incorporate into your project - not just what it is, but the license terms under which you obtained it. This is true not just for any proprietary software that you incorporate into your project, but it’s also true for any open source software you include in your codebase as well. Open source software is free to use, but they are often provided under licensing terms that are unfavorable for commercial development - most notably what is known as “copyleft” requirements.
The commerializability of software is most easily maintained if you avoid the use and incorporation of third-party open-source software. However, if you’re going to use open-source software, be sure to only use those that are made available under open-source licenses that do not contain copyleft requirements. Such licenses are often referred to as “permissive" licenses - the BSD, Apache, and MIT licenses are probably the most notable and widely used examples. Here is a convenient list of the most common permissive open source licenses, maintained by tldrlegal.com. Here is a useful blog post comparing and contrasting the BSD, Apache, and MIT licenses, which serves as a great general discussion on the topic of permissive open-source licenses.
In contradistinction to “permissive” licenses, open-source licenses that contain copyleft provisions are typically referred to as “restrictive” licenses. Probably the most illustrative example of such restrictive open-source licenses is the various flavors of the GNU General Public License (known as “GPL”) developed and supported by the Free Software Foundation, an organization founded by Richard Stallman (the history of his original GNU Project can be found here).
3 - If you are going to release your source code publicly, consider doing it under a restrictive open source license
Generally, the best way to preserve the commercial value of software is to not publicly release its source code. However, as an academic researcher, there likely are a variety of reasons that would lead you to seek to publicly release the source code of the software projects you and your team create. It could be that the terms of your grant funding may obligate you to release the source code for your software creations under an open-source license. It’s also possible that, as you seek publication of your work in a peer-reviewed journal, the journal’s editors may require (or otherwise suggest) that any software serving as the foundation of your manuscript be released open-source. It could also be that you, as an academician, may personally feel passionate about making sure all of the fruits of your labor are maximally shared open-source for public benefit as a matter of principle.
Regardless of the motivation, if you are interested in preserving some degree of commercial potential for software whose source code you choose to release open-source, it can be highly advantageous to do so under a restrictive, rather than a permissive, open-source license, e.g., making sure to release it under a license containing copyleft provisions, such as the GPL. This is because copyleft obligations attached to publicly available source code are generally anathema to commercial software developers, who usually depend on the ability to keep the source code of their software projects proprietary in order to be able to charge for their software-based products and services.
The commercial undesirability of incorporating source code tied to copyleft obligations leads to two distinct - but interrelated - advantages of releasing your source code under a restrictive open-source license:
Even while making your source code available to fellow academic researchers and to non-commercial enthusiasts, it minimizes the likelihood that your source code will be commercially exploited without your and your university’s consent.
If a commercial entity desires to incorporate the source code you created into their proprietary codebase, it would first need to first license it separately under a commercial license for that same source code. Such an approach is known as dual licensing.
Chances are, your university’s technology transfer office will have standard guidance to offer on how its faculty members should approach the open-source licensing of the software they create. And they should be able to help you think through how to navigate the various incentives and obligations for engaging in the open-source sharing of your software creations while simultaneously preserving the potential for commercial development and dissemination should such opportunity arise.
-------------------------
There’s more I’d like to write on this topic, including 1) the distinction between source code and object code, and how they can be separately licensed, and 2) some of the unique licensing considerations that arise when dealing with AI/ML applications. But I think what I’ve written thus far makes for a good stopping point. More to come, hopefully!
-Isamu Hartman
© 2021 Isamu Hartman.
Comments
Post a Comment