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 t
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 observ