3.5 Commercializing/Licensing Software

3.5.1 Sources of Software

Software was generally unexplored in university commercialization until recently. It can be found in research labs in STEM departments, of course. It is also a tool used in non-STEM departments such as a computer center for the humanities and arts departments, or the music faculty. Commercializable software can be administrative software which drives the university’s student registration process. Another example in the United States is Blackboard, a campus course platform founded in late 1996 by Cornell University students Stephen Gilfus and Daniel Cane. Student-created software apps are also present on campus but may or may not be covered by the institutional IP Policy.

3.5.2 IP Protection for Software

There are essentially four types of IP rights relevant to software: patents, copyrights, trade secrets and trademarks. Trade secrets are valuable proprietary information (such as lab processes, “know-how” or “show-how,” where the protection is from one party having the information while the other does not, and can only receive it under a written contract’. Trademarks are discussed thoroughly in Section 2.3.4 of Track II (Mid-level TTP), Topic 3: The Full Spectrum of IP Protection Tools.

3.5.3 Importance of Authors and the Extent of Useful Documentation

The “author(s)” of the software is/are the original creator(s) of the code and the author(s) owns the copyright to the software. In the United States, software created under research grants or during university employment is considered to be a “work for hire” under U.S. copyright law so the academic institution (the university) is considered the author of the software. Readers are directed to the IP policies of their institution.

Documentation for non-commercial/research campus software is dependent on the authors and is usually of uneven consistency, when it exists. But what exists needs to be found and stored in a permanent external file for later, possibly commercial use.

3.5.4 Types of Software

3.5.4.1 Open Source

Open Source software is not a “type of software” but is a list of rules for handling the software. Some software has source code that only the person, team, or organization who created it—and maintains exclusive control over it—can modify. This is called “proprietary” or “closed source” software.

Open source software in which source code is released under a license that grants users the rights to use, study, change, and distribute the software, documentation, etc. to anyone and for any purpose, but requests written attribution back to the original authors. One type of open source license excludes commercial use. Another type does not.

Public domain software is software that has been formally placed in the public domain: in other words, there is absolutely no retained ownership such as for copyrights, trademarks, or patents. Software in the public domain can be modified, distributed or sold even without any attribution by anyone; this is unlike the common case of software under exclusive copyright rights, where software licenses grant limited usage rights.

These rules are complex, and it can be easy to assume that open source means “free” software, or that dedicating the software to the public domain means it cannot be used for commercial purposes— neither of which are true. Once the reader has learned the rules in their country, the material should become quite straightforward to understand and use.

3.5.4.2 Standalone vs. Embedded Software

The main difference between embedded software and standalone application software is that the former is usually tied to a specific device, serving as the Operating System (OS) itself, with restrictions tied to that device’s specifications, so updates and additions are strictly controlled, whereas standalone application software provides the functionality for a specific result and is usually not tied to a specific device.

3.5.4.3 Standalone: Student Apps

Many universities have IP policies that do not allow the institution to take any proprietary interest in student-created software. The exception is if the software was created while the student was an employee, say in a research or teaching lab.

3.5.4.4 Standalone: Research Tool Apps Covered by IP Policy for Employees

A Florida State University example details a mapping method that takes defined physical measurements of fruit flies’ wings and provides information about the genetics of the fly without harming it. Since the researcher agreed there would be at most a dozen users, the TTO allowed the software and instructions to be posted on the researcher’s website with interpretation information in return for attribution to the researcher, and no fee would be charged (at the request of the researcher).

3.5.5 Embedded: Software as a Piece of an Invention or IP

In this case, the software is created and embedded in other software on a chip or as part of the device/computer OS. The commercial manufacturer of the device running the software may be interested in your software modification, if it increases performance features.

3.5.6 Software Commercialized Like a Patent Protected Invention

To commercialize software like IP, one must document the software and its authors, then find a product developer who will create a robust product, support it and offer non-exclusive licenses. 

The royalty/compensation may be structured as a flat fee of so many dollars per installation or user.

Such a developer may use the software architecture to rewrite the software in a more robust, easier to use manner. In this case, the owner may reflect this by limiting the length of the license to so many units or so many months/years. Next-generation software created by the researchers may be offered to keep the new product current with ongoing compensation.

It is worth noting that the legal strength of a software patent is very actively debated currently in the United States because of recent Supreme Court cases (e.g., Alice).

3.5.7 A Different View: University of Washington Software Commercialization

In the middle of Seattle’s unique booming software industry in the 1980’s, UW created an experimental software collaboration program to increase the use of UW software within companies and take advantage of this environment. IT uses were prominent, but software used by the life science community was also needed. Rather than seek exclusive Licensees as in the case of a patented invention, UW software evangelist Gerry Barnett saw software IP as “a tool to construct a teaching relationship.” His commercialization/distribution program offered nonexclusive licenses for software that was not destined to be big moneymakers. 

The approach resulted in getting more companies and organizations engaged with more research groups on campus, creating new opportunities for collaboration and for user group interactions.

The program offered software for $2,000 per copy, then upgrades and updates at a similar price. It saved the company time and money and embedded the use of the software internally which served as a magnet for future generations of the software.

Over time, it brought in as much as $6 million/year from licenses and other commercialization strategies during Barnett’s tenure, while earning a reputation for openness and collegiality in Seattle’s booming software industry. UW researchers had a high regard for the program and its collaborative and nonexclusive aspects.

3.5.8 Unique Issues

Often there are multiple authors who created/refined the software over several years, some of whom have left the lab. These authors must be attributed and recorded.

If the software accrues profits, there should be a written mechanism to handle distribution of compensation to the authors. In complex cases, compensation may be distributed in some fixed, equal amounts while the remaining sum is placed in an account for use by current lab personnel to handle special travel, equipment, etc.

Much laboratory/research software is dependent upon the authors for explanatory documentation, leading to obvious problems for later users. This is an issue the TTO staff should address but cannot solve.