Skip to main content
Home News Managing Academic Software Projects for Licensing

Managing Academic Software Projects for Licensing

by David Chang Villacreses, MSc

Disclaimer: David Chang Villacreses is not a lawyer. This document does not include and is not intended to include any legal advice for any purpose whatsoever, and has been written for informational purposes only. When in doubt about best practices on software licensing, please consult your institution’s legal team and intellectual property licensing office.

Headshot of David Chang Villacreses smiling directly at the camera, wearing a black suit jacket, white shirt, and dark red tie.
David Chang Villacreses is the Associate Director of Digital Innovations Licensing at Duke University.

When Duke innovators come to our office with invention ideas like medical devices, material formulations, or pharmaceutical compounds, both the inventors and our licensing managers are usually on the same page how to proceed: applying for a patent. But for digital innovations, the path forward can fork and loop in different ways – and a patent-based strategy may not always be the best way to go.

When developing software innovations in academic settings, the various components assembled into these projects can be encapsulated under different types of Intellectual Property (IP), depending on each project. The types of IP often used to manage software inventions include: 


Patents are a grant made by a government to confer its owner a limited monopoly to block the use, making, and selling of an invention. In practice, patents are a mechanism to control others’ use of the invention as described under such patent’s claims within a territory. 

For software inventions, patents have become increasingly difficult to achieve. For example, the use of a well-known machine learning algorithm in a new context is generally not enough to be patentable in the US.

IP licensing managers need to be strategic regarding when and how to protect a software invention. For example, if a method is very rapidly evolving, and the claims would become obsolete by the time the patent is issued, or soon after, it may not always be strategic to file a patent for said method.

Another example includes software systems running entirely in the cloud or behind closed doors. If it proves too challenging to detect and confirm infringement of a patent’s claims, patent-based protection strategies may not be worth pursuing.


Copyrights protect tangible outputs of human creativity and are evaluated differently from patent rights. This means that only a modicum of originality needs to exist for copyrights to protect a work of authorship. 

Copyrights are automatically protected, meaning that as soon as authors create or produce a copyrighted work, the copyrights for such works can be licensed in much the same way patents are licensed.

In copyright law, software codebases are viewed as literary work. Similarly, annotated datasets, simulation phantoms, or creative compilations of data are examples of digital innovations that can be protectable under copyrights.

When managing copyrighted works, your licensing office will often want to understand any joint ownership and authorship considerations, as well as strategize if and how derivative works should or should not be allowed.

Best practices when developing software

After submitting a disclosure with a licensing office, said office’s software or digital licensing teams will often look at any third-party dependencies that the authors have used or incorporated. For example, the licensing office may request a list of the open-source libraries, devkits, or other third-party software dependencies that were used in creating the software being disclosed to better understand the licensing strategy for the asset. 

Though each software asset must be supported on a case-by-case basis, and your licensing office can help your team create a licensing strategy for each project, the following best practices and considerations are advisable regarding software inventions:

  • When developing the code, be mindful of how each open-source license can affect your codebase.
    1. For example, incorporating code shared under permissive licenses when including open-source libraries (i.e., MIT, BSD), and avoiding including copyleft licenses (i.e., GPLv2, GPLv3).
      1. When you merge permissively shared code into your codebase, you can use the permissive code for any purpose. 
      2. When you merge copylefted code into your codebase, you will need to share your code under the broadest compatible copyleft license you included. This is why copyleft licenses are often called “viral”.
  • When the project is close to completion, file an invention disclosure with your licensing office where all authors and contributors are listed on the form.
    1. The licensing office will help strategize toward a license aligned with the team’s vision. This includes open, custom, and hybrid licensing mechanisms.
    2. This will also allow the licensing office to codify the software project in its internal database and reference it in future agreements (i.e., confidentiality agreements, licenses, research licenses, etc.).
  • If openly sharing code, it’s strongly encouraged to steer away from subjecting your codebase to open-source licenses that include language that may affect patents related to your code. The copyleft GPLv3 and permissive Apache 2.0 are examples of open-source licenses that university licensing offices generally avoid releasing code under.
    1. The Apache 2.0 and GPLv3 licenses give recipients, now and later, a royalty-free license to the code as well as to any patents the licensor owns or controls that may be related to that code. This poses the risk of inadvertently granting licenses to patents made by the team for other projects, or even other patents made by unrelated teams within the institution, should they have some common theme. 

Please note: each step (development, completion, sharing of code) may have differing strategies, and not all software projects can or should be open-sourced.

Considerations for open sourcing software

It is strongly encouraged to always consult with your institution’s IP licensing office before making any decision to make your codebase openly available. That said, there are various options to open source your code:

  • Using an “open-source-software” (OSS) license. These are licenses approved by the Open Source Initiative foundation at
    1. There is a gamut of OSS licenses, including “permissive” (i.e., MIT, Apache 2.0, BSD, etc.) and “copyleft” (i.e., GPLv2, GPLv3, LGPL, Affero GPL, Mozilla GPL, etc.).
    2. When selecting an open-source software license, licensing offices often discourage using GPLv3, LGPLv3, or Apache 2.0 licenses, or any licenses that include patent-affecting language.
    3. It is important to note that non Open Source Initiative licenses, such as the many Creative Commons license tiers, exist. There are often suited for non-software copyrighted works. 
  • Sharing your codebase under a hybrid licensing scheme
    1. This means that the code is made available under an open-source license for non-commercial use, and a license with your university’s licensing office for commercial use.
      1. GPLv2 is generally the license many academic licensing offices may encourage using for open sourcing code if a hybrid licensing model is decided. GPLv2 is a copyleft license that forces recipients to share the code combined under the same license.
  • Creating a custom license in collaboration with your university’s licensing office for your project.

Why rely on a technology transfer office?

When evaluating how you would like to make your software invention available to the public, consulting your institution’s technology transfer office is strongly advised. In most cases, the university owns copyrighted software and materials done in the context of research projects, especially when funded by the government or industry.

Your institution’s technology transfer office can provide a strategic assessment of:

  • Reviewing the list of authors and confirming any joint ownership issues.
  • Reviewing the funding source(s) and determining sponsorship obligations, if any.
  • Evaluating third-party dependencies or materials used to assemble your invention, and if any of these dependencies can affect your licensing and/or commercialization strategy.
  • Reviewing any IP considerations associated with a project’s funding sources.
  • Navigating joint ownership considerations, as well as any agreements that may be needed, to cleanly manage projects that have been developed in collaboration with other institutions.
  • Determining which licensing scheme works best for your project, considering the team’s vision as well as future and related projects.
  • Verifying and providing language as well as guidance when sharing code or data alongside your publications.
  • Evaluating foreign law considerations when sharing data or software.

We wish you success in your digital innovation journey, regardless of your institution. But if you are at Duke University, please do reach out to the Digital Innovations team at the Office for Translation & Commercialization.

Have Questions?

Please contact us or subscribe for more opportunities

Stay in Touch with Us