In Part 1 of this essay, I discussed three learning points I'd gained from my encounters with faculty-developed software in my work as a technology transfer officer at an academic medical research institution. Those points were as follows:
Patents aren't a necessary prerequisite for commercializing software
Be deliberate in your use of third-party code
If you are going to release your source code publicly, consider doing it under a restrictive open source license
When I finished writing it, I knew I had more to say on the topic. You can read Part 1 here. Below is my continuation.
4 - Figuring out the ‘thing’ that’s going to be licensed
An important part of handing off a software-based technology from university to private industry is to first figure out exactly what is being handed off. This can be tricky! I’ve discovered that software, as a commercial asset, can take many forms. The licensing professional can bring a lot of clarity to the negotiations by making sure both the faculty inventor and the licensee have a clear understanding of exactly what is going to be handed over from one party to another in the commercial transaction.
Source Code:
The most obvious licensing scenario for software is where a faculty member has written a computer program, and a company wants to license that program as written (i.e., the source code). The terms of the license will depend on how the company intends to use it; i.e., the royalty terms will be pretty different depending on whether: 1) the software will be used purely in internal operations, 2) the company will use the software as an enabler of services it will be providing, 3) the source code will be incorporated into a larger codebase being developed by the company, 4) the company will be selling the compiled binary (i.e., the object code) of that software to end users as a standalone product, 5) the compiled binary will be incorporated into a hardware product that the company will be selling, etc. (I’m sure there are other types of scenarios I haven’t covered above).
Since the source code can be edited, modified, and further improved by the licensee, the licensor and licensee will need to figure out how such future modifications will impact the financial and other terms of the license agreement.
Object Code:
If the licensee is amenable to it, it’s worth considering the option of licensing only the compiled binary (i.e., the object code) of the software. In this way, the source code of the software can be kept proprietary by the university and faculty member. Also, because software can no longer be edited once it’s in the form of a compiled binary, the terms and conditions for an object code-only license are generally simpler than those that include the source code because you eliminate the need for adding (potentially complicated) provisions for dealing with how the ownership status of the software, or the royalties, will be affected by future improvements that the licensee will make to the software after receiving it.
Utility Patent:
If the software constitutes the embodiment of a patent-eligible invention, the university may decide to pursue a utility patent for the software. In such a case, when that software will be licensed to a company, that license will likely contain two components: a license for the software’s source code (and/or object code), and a license to the patent rights.
Design Patent:
If the faculty member who developed the software put in a lot of effort into making an effective and easy-to-use user interface for it, it could be that this interface comprises significant value that is separate from, and adds to, the useful function(s) that the software performs. In such a case, it may be worth considering pursuing a design patent for it. Some useful articles on this topic can be found here, here, and here.
5 - Internal adoption of a software solution as a measure of its licensability
When a new software tool is disclosed to our office, nothing makes me more excited than when the faculty member tells me that, not only is it fully developed, it is already being actively used by others within their department. This is because such internal adoption provides two distinct signals: 1) the software tool is already deployment-ready, and 2) there is likely to be a market out there for that product.
Having said that, it’s entirely possible that a highly effective and internally adopted solution might prove to be challenging to license. As I’d mentioned in Part 1, the commercial value of software often comes from companies being willing to pay money to access a ready-made solution for a particular task when doing so will be cheaper than having an internal software development team create its own code with identical functionality. If it turns out that the software solution in question was constructed in such a way that its function is dependent on, say, a variety of idiosyncratic features of the university’s IT system and/or on being run on outdated or overly specific computing platforms, an otherwise fantastic solution may turn out to be extremely difficult for the licensee to adopt without significant extra work. Similar challenges would also arise if a fully developed software solution created by a faculty member for internal use is discovered prior to licensing that it contains extensive integration of third-party code that was obtained under restrictive open-source licenses (See Part 1, “Be deliberate in your use of third-party code”). As a rule of thumb, the more a software solution created by a faculty member possesses that “plug-and-play” quality (i.e., able to be put to use by the commercial licensee with minimum additional work), the greater the commercial value it can command.
Faculty-created software solutions generally arise either because the creation of such tools is an explicit component of their research program or because they are created out of the faculty member’s need to solve certain problems that arise within their research (or, if at a medical research institution, clinical) operations. In either case, commercializing such tools are - and should be! - of secondary concern. The primary mission of any academic institution is the creation and dissemination of new knowledge. The commercialization of IP assets (including software) should very much remain a secondary goal that is pursued only for the purpose of amplifying and supporting that primary mission.
Having said that, if a faculty member is developing software within their research with an explicit intention to eventually pursue its commercial development (up to and including building a startup around it), checking in with their university’s technology transfer office early on in the process can only help.
------------------------------
I realize I didn’t get a chance to touch on some of the fascinating learning points I’ve gained from my encounter with AI/ML projects so far. More to come, hopefully!
Comments
Post a Comment