Open Source Software and University Intellectual Property Policies

The problem

The following question was emailed to me by Jim Fowler:

“I’m a professor at Ohio State and I sit on the committee which is drafting a new IP policy for faculty work.

I’d like the new policy to support faculty contributions to open source software projects. I am very impressed with what you’ve done to recommend open source licensing on NSF funded projects; such language is indeed a great way to get universities to support such licenses.

Are there universities that have done a good job of facilitating open source licenses in their IP policy?  Is there sample language somewhere for this?  It seems that being able to point the tech transfer office lawyers to ‘peer institutions’ is very convincing, so if I could find an institution that is doing the right thing, that could be very helpful.”


This seemed like an interesting question and one that was worth some effort to investigate, through personal emails, twitter, and an email to the Science of Science Policy mailing list.

Overall, the discussions lead me to summarize that university IP policies and technology transfer offices seem to be most concerned about money, rather than transferring technology or knowledge in the form of artifacts. There seem to be two common, interrelated themes:

  1. If someone is going to make money off work done by the university, the university should get a cut.  This leads to policies that either make open source difficult or require non-commercial use.
  2. If there is no money to be made,  the university is happy with open source, but mostly doesn’t help to make it happen.  Either the creators must state that the work cannot be commercialized, or again, a license that forbids commercial use is required.

At most universities, there is a large difference between how the university sees software and publications.  Software is something of potential monetary value.  Publications are a mark of scientific output and prestige.  This is not true of all universities.

In my opinion, until software is seen as a scientific output, worthy of recognition, the situation will not change.  On the other hand, if it does change, in addition to benefiting the universities, it would also benefit those who develop software (and other artifacts) in the university system, such as in promotion and tenure.  (Note that this discrepancy between papers and other artifacts has previously been recognized as problematic by the National Academies, at least for computer scientists.)

Detailed responses

Some more detailed responses (lightly edited) follow:

James Howison replied:

I’m working on a research agenda on the “other direction” of technology transfer; rather than commercialization, I’m focusing on transfer of originally grant funded work to community support models, including open source software development. There are a ton of differences between successfully running a grant-funded project and successfully running a community-supported open project (software or otherwise); the transition is as complicated and interesting as commercialization. Happily we know a decent amount about the end point (open source organization and online communities), so the research is on the transitions. I describe this in a work in progress paper I’m presenting at the Information School’s conference:

I’ve chatted with a few people in, or dealing with, technology transfer offices and sometimes it’s like talking to corporate people about open source in the late 1990s. There is sometimes real opposition to it and, often, a shrug that it’s probably fine for things with no monetary potential. The idea that open code can be the basis of an ecosystem that brings reputation, funding and, indeed, profit, to the University seems a fair distance away. But I’d love to chat with tech transfer (or VP research types) who see succeeding at open source as a strategic goal worthy of university support.

In answer to the specific question, these resources might be useful. The UK has some of the best resources in these areas: There’s also the UK Scientific Software Sustainability Institute Looking through things there, I’m not seeing anything specifically about University IP policies, but I’ll ping them on Twitter and see if anything comes up.

In response, the OSS Watch folks tweeted about a national (UK) software survey they’ve done a few times, which has sections on ICT related to procurement and staff contributions to open source software, though this survey is aimed at IT directors, and as such, it probably underrepresents faculty contributions.

Martin Kenney, an editor of Research Policy, says that:

My impression is that there are few controls on professorial decision-making on software release. Research Policy has not published any articles that directly addresses this issue, but it would be a great research project for someone in science policy.

Shane Greenstein and Frank Nagle have written a great article on “digital dark matter,” digital goods and services that are non-pecuniary and effectively limitless, and serve as inputs into production, for example, some software released from universities.

My book “Public Universities and Regional Development: Insights from the University of California” discusses UCB EECS and the unstated policies there.

A mailing list participant mentioned:

There is a Software Interest Group at the Association of University Technology Managers (AUTM), and a component of the discussions at that group is on open source software. There is also a Software Course hosted every other year by AUTM.

At the 2015 AUTM meeting, there was a panel on “Open Innovation” that included discussion of the specific nature of technology transfer.  Most parties in the audience seemed quite supportive of open source. But there aren’t many tech transfer folks deeply engaged in it because there are many things that they could focus on, and managing open source projects is no easier than managing things that get more credit in the tech transfer metrics.

Software, most especially open source software, is not as widely understood, much less supported by, tech transfer.  But there are many who are knowledgeable & supportive – just not the majority.

James Herbsleb said about Carnegie Mellon:

I don’t know of reports or studies but I have some personal experience here at CMU that might be interesting. Our IP policy doesn’t mention open source but the university is fairly friendly to some open source licenses such as some BSD and GLP licenses, primarily because they do not have patent implications. The university abhors Apache 2.0 (which I’m told by my friends at Google is by far the most popular open source license overall), because it has the following provision:

“3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. . . . .”

So the university is afraid that licensing under Apache 2.0 will cause them to lose related, patented, intellectual property, or to violate exclusive patent agreements that may already be in place with respect to related technology. Businesses interested in the software want the patent protection of the Apache 2.0, of course.

Copyright licenses are also bound up with product warranties, as you can see from this mandatory disclaimer found in the BSD 2-Clause license:


Kathy Ku wrote about Stanford:

Stanford doesn’t have any policy that addresses open source in particular although they are working on a “copyright” booklet that will mention open source. Their patent policy has this provision that could easily apply to open source:

1. The inventors, acting collectively where there is more than one, are free to place their inventions in the public domain if they believe that would be in the best interest of technology transfer and if doing so is not in violation of the terms of any agreements that supported or related to the work.

There is some guidance about this on Stanford’s Office of Technology Licensing website, including an open source primer that says software can be open sourced by: the faculty, as long as doing so does not conflict with any Stanford obligations; students and post-doctoral scholars, with faculty permission; research staff, with faculty permission; staff, with the appropriate departmental approval.

There’s also a 2004 article from Kathy at Stanford: Software Licensing in the University Environment

Regarding the University of Oregon, Chuck Williams pointed out:

… the University of Oregon has a great spinout, ParaTools, that works in the supercomputing stack and is anchored in BSD software provided by UO. We recognized the importance of reputation and the linkage that we now have in several countries where ParaTools operates, as well as international meetings that have been hosted in Eugene, Oregon because of these connections.

and Sameer Shende agreed:

The University of Oregon’s Innovation Partnership Services team helps manage our IP policies, open-source licenses, and external NDAs with other companies. We have open-sourced the TAU Performance System(R) under a BSD-style license and made the source code available.

Chris Hill wrote about George Mason:

Copyright Policy

Part II (A)(1)(a)(iv): Patentable works. The university generally holds copyright in a traditional work that is also patentable, including patentable software, when the university has a claim to ownership of the patent.  The Vice President or that officer’s designee claims and disclaims copyright ownership in such a work on behalf of the university by providing notice to all creators.

The university makes no claim of ownership of the copyright or the patent in copyrightable and patentable software if (1) the university does not hold copyright under either of the exceptions in this Part II (A)(1)(a)(i) or (ii), and (2) all known creators and inventors of  the software agree to make it available under an open source license that meets the requirements of The Open Source Definition, Version 1.9, of the Open Source Initiative. The Vice President may update the requirements for an open source license under this policy.

Patent Policy

Part II (A)(2)(e):  Open source software. The university makes no claim of ownership of copyrightable and patentable software if (1) the university does not hold copyright in the work, and (2) all known creators and inventors of the software agree to make it available under an open source license that meets the requirements of The Open Source Definition, Version 1.9, of the Open Source Initiative. The Vice President may update the requirements for an open source license under this policy.

For your information, when we revised the patent and copyright policies a decade ago, they replaced very rudimentary statements that were completely inadequate.  We drew from the policies of a dozen or more institutions, both private and public, including UVA, VTech, Penn State, UNC, Columbia, MIT, and Stanford.

Gerald Barnett provided a large amount of information:

  • I expect you will find that university copyright policies generally approve of open source distributions, while university patent policies express concern and expect disclosure and management through a formal university process, as if software is like any other invention.
  • In contrast to George Mason’s policy (see above), here is guidance for researchers from Georgia Tech, making it clear that open source comes within the scope of inventions, under the heading “Protecting the Innovation.”

Open Source, know-how, and scholarly works are intellectual property for which Georgia Tech is less concerned about statutory protection.

Open Source generally refers to software that is freely distributed in source code form. While all Open Source carries copyright protection in the same way that other software does, seeking patent protection precludes the use of Open Source licenses. Georgia Tech was one of the original seven university signatories of IBM’s Open Collaboration Research Principles. Provided that George Tech does not have a contractual obligation to the contrary, Open Source is a potentially effective and efficient means of disseminating research results. Learn more about Open Source at the Open Source Initiative.

  • UCLA publishes an on-line open source software policy. It is essentially a letter from the supervisor of the IP program warning of pitfalls in open source licensing and announcing an effort to “develop an UCLA policy on OSS”:

Open Source Software is licensed. Non-compliance entails serious ethical, legal and financial risks. Thus, UCLA’s use of any OSS product must comply with the terms of that license. Some OSS licenses contain terms and conditions that are not acceptable for use with UCLA projects.

  • The Free Software Foundation has long published advice to university software developers:

Alas, many university administrators have a grasping attitude towards software (and towards science); they see programs as opportunities for income, not as opportunities to contribute to human knowledge. Free software developers have been coping with this tendency for almost 20 years.

  • Charles Williams and I briefly discuss the policy issues of software in the context of university patent management in chapter four of Developing University-Industry Relations, ed. by Robert Miller and Bernard Le Boeuf.

Gerald also pointed me to the Research Enterprise Blog

Regarding the University of Texas, Robert van de Geijn pointed out:

The University of Texas is very generous when it comes to sharing royalties.  1/3-1/2 of royalties go to the inventors.  As a result, if an inventor indicates it is in the best interest of the university to open source, that is simply taken at face value, because the inventor has more to gain (relatively speaking) than does the university.  Strictly speaking, an inventor does have to declare the invention, regardless of the decision to open source or not to open source.

And Gerald Barnett added:

The University of Texas has long had a practice of supporting open source distributions. That support stemmed from the work of Georgia Harper in the Office of General Counsel in support of copyright management, and from having for some time a director of technology licensing with a strong background in computer science. See UT’s Office of Technology Commercialization Licensing information and Open Source Toolkit (2009).

Maxine Brown wrote about the University of Illinois at Chicago:

We just tell them [UIC] that we want to distribute our code as open source. As long as we disclose to the university, and as long as we have a statement that downloads are not to be used for commercial use, we get their blessing.

Wolfgang Bangerth had an experience with Texas A&M that he thinks might be typical of other universities:

8 or 9 years back, I had a conversation with our IP office about the way we distribute software. They were entirely unprepared for the question — what they typically deal with is biomedical and engineering things. Open Source Software had simply never been on their mind. In the end, we agreed that I would be allowed to distribute software under an open source license, and the reasoning was:

1/ The commercial market is likely small and would require significant expenses in marketing and providing support.

2/ The university is better off making the code open source because that might attract research funding from funding agencies and (possibly) industry, as well as citations and other forms of intangible benefits to the university, etc. In the case of our software, that has certainly panned out, both financially and reputation-wise.

I thought that latter reasoning actually makes a lot of sense. I had never heard anyone talk in these terms, but I think it’s a totally legitimate way for universities to think, and I think it’s worth putting into the box of arguments for people when they talk to their IP offices — there are more ways for universities to benefit than just to sell or license technology.

William Stein at University of Washington points out that funding agencies can impact how this plays out. Specifically, the copyright conditions in grant ageements that go through our sponsored research office become legally binding on the university, faculty, staff and students. Thus a PI putting such a open source statement in a grant ensures they have the right to later release that code as open source (the “gamble” of course, is that they *must* release it open source, even if they don’t want to).


Some work by the author was supported by the National Science Foundation (NSF) while working at the Foundation; any opinion, finding, and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the NSF.

Comments are welcome

8 thoughts on “Open Source Software and University Intellectual Property Policies”

    1. I completely agree, but don’t feel that I have the right background to do this. If someone else does, please either suggest some text I can add to the blog, add a comment here, or write it somewhere else and I will link to it.


  1. Fantastic blog, Dan. Much more going on than I knew about and lots to follow up, great round up.

    There seems to be some confusion about the possibility of an “open source” license that is only for non-commercial activity. It may well be an appropriate idea sometimes, but it is (AFAICS) a “No Discrimination Against Fields of Endeavor” that violates the OSI definition of open source. So that’s going to cause lots of confusion. Of course just because it violates OSI’s definition doesn’t make it necessarily bad or inappropriate, just confusing.

    That confusion might potentially undermine the impact of releasing a piece of software in source code form, planning to build the University’s reputation and form the basis for grants, publications etc. That’s mainly because it could make the code incompatible with other open source code and because many kinds of potential contributors might be unhappy with the restriction.

    So it’s a strategic trade-off: do you seek to build a flourishing open community around the code (and reap reputation, impact, and resources indirectly), or do you wish to hope to hook a commercial user, while not directly blocking academic research users from using the software (but risking limiting that to use and not to building a classic open project).

    btw, looks like Gerald Barnett could do the Bayh-Dole analysis, if I judge the content of the blog that you linked correctly.


  2. We handle software as a separate disclosure from an invention disclosure to get at that Bayh-Dole issue. Most software does not fall under Bayh-Dole. No invention….. just copyright. Some software may have patentable elements, in which case, a lab would file an invention disclosure and that would be evaluated and reported to the cognizant federal agency under Bayh-Dole regs.


  3. I have worked extensively with Bayh-Dole and university open source software.

    The Bayh-Dole Act requires federal agencies to use a standard patent rights clause in funding agreements with universities, nonprofits, and small businesses. The patent rights clauses are not set out in the law but rather in the implementing regulations. Each time a university receives federal funds in the form of a grant, contract, or cooperative agreement, a federal funding agreement is created that includes a standard patent rights clause. For federal grants, the funding agreement is at 2 CFR 215 and the IP clauses are sections 36 and 37. That’s how Bayh-Dole gets to universities–universities formally agree to terms in federal contracts. Bayh-Dole *does not apply to universities directly*.

    As part of the standard patent rights clause (at 37 CFR 401.14(a)(f)(2)), universities agree to require written agreements of research and technical personnel to disclose patentable inventions, sign paperwork to allow patent applications to be filed, and sign paperwork to establish the government’s rights in inventions they make–either assignment or a non-exclusive license. Universities as a general practice do not comply with this requirement and instead demand assignment of inventions to the university.

    Bayh-Dole has nothing to do with work that is not patentable and nothing to do with work that is outside the “planned and committed” activities under a grant. Thus, if inventive software is not in the RFP or the proposal or the statement of work, then it’s not part of the planned and committed activities. See 37 CFR 401.1 for the full discussion of scope. The regulations anticipate that contractors will attempt to exclude inventions from standard patent rights clause obligations. Instead, as a general practice, university licensing officers aim to *expand* the scope. Doing so gives them (so they argue) claim to ownership of a wider range of inventions “by operation of federal law.” The Supreme Court in Stanford v Roche threw out the universities’ interpretation of the law, but the universities for the most part only made their claims on inventions (and most anything else) even more demanding.

    The provisions of the standard patent rights clause do not require a university to take ownership of federally supported inventions, or to file patent applications (a university can choose not to file), and if a university does file patent applications, the university is not obligated to license, commercialize, or make money on the patents. The standard throughout Bayh-Dole, its regulations, and the standard patent rights clause is “practical application”–the invention is being “utilized” and its “benefits are available to the public on reasonable terms” (see the definition at 37 CFR 401.2(e)).

    Clearly, open source is entirely consistent with Bayh-Dole. A university may obtain patents on federally supported inventions embodied in code and deploy the code under a compliant open source license–Apache 2.0, for instance, or Eclipse or GPL 3.0.

    If the university does not take ownership of a federally supported invention, then the regulations permit the federal agency to allow the inventors to retain ownership under 37 CFR 401.9. The inventors have still have obligations, but not nearly so many as those imposed on universities–those drafting the regulations apparently distrusted university involvement! 401.9 does not even require the inventors to file patent applications, though an agency could add that requirement as a special condition. Of course, if the inventors do not assign their invention-in-code to an organization that has as a primary function the management of inventions, then the federal agency can request assignment of the invention to the government. So inventors of code-based inventions need to have a talk with their program officers before making a decision about patents.

    If the code does not embody a patentable invention, then for federal grants to universities 2 CFR 215.36(a) and (c)-(e) control–copyright and data rights. Neither is incompatible with open source software distribution, regardless of whether the university ends up claiming copyrights in the code. Section 36(e) is especially interesting for open source, as is section 37. Section 36(e) requires the university to use the property (“intangible assets”–including copyrights and patents) for the “originally-authorized purpose.” Section 37 goes further: if the university claims to acquire inventions from researchers supported by federal funds as a *condition of employment*, then the university is acquiring the rights to patent applications and patents *with federal funds obtained under the funding agreement*. Section 37 requires the property “to be held in trust by the recipient [i.e., the university] as a trustee for the beneficiaries of the project or program under which the property as acquired or improved.” If a grant proposal includes an expectation of open source distribution, the university, if it becomes the owner of patents or copyrights in the code, is obligated by the funding agreement to support that open source distribution. As a matter of general practice, however, university licensing personnel ignore these provisions.

    In short, Bayh-Dole formally is a non-issue for open source.

    The NIH, for instance, has various guidelines on sharing research tools and data that are highly consistent with open source: “exclusive licenses for research tools . . . should generally be avoided except in cases where the licensee undertakes to make the research tool widely available to researchers through unrestricted sale, or the licensor retains rights to make the research tool widely available” (from NIH’s Principles and Guidelines for …Disseminating Biomedical Research Resources”).

    All the complications attributable to Bayh-Dole come from university patent licensing practice. These practices are often supported by university patent policy demands that licensing personnel have drafted with claims that federal law requires institutional ownership and efforts to “commercialize” the inventions. Commercialization (again, in general practice) means exclusive licensing to an established company, and if not to an established company, then to speculative monopolist investors, and if they won’t play, then to shell startups in the hope that in the future speculative monopolists will appear to buy the shell companies. Typical university exclusive licenses forbid open source distribution of the licensed code.

    University licensing practice, not Bayh-Dole, is the cork in the keg of open source, exchange of research ideas expressed in code or digital data, collaboration, public access, common platforms, and further code development.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s