Software as inevitable part of R&D
These days more and more R&D involves a software element. Inventions arising from R&D have certain implementations or modes of implementation which are software driven. Aside from the software code in general, the algorithms which drive specific inventive functions in these software or software/hardware implementations may be valuable intellectual property.
The value could be captured either via (i) protection as a trade secret, (ii) protection as a literary copyright in source code and binary code instances or (iii) by patent. When the source code is part of microchip implementation for a product, there is a further potential for capture of value by invoking the more obscure intellectual property rights such as topography rights and mask rights. Each of these confer on the holder certain monopoly rights under their distinct and specific statutory frameworks.
Universities involved in R&D and IP Rights
Universities will fight to protect their ‘academic freedom’ and preserve their rights to publication of academic papers but such freedom can usually be accommodated relatively easily, regardless of IP ownership questions. Tension may arise in the timing of publication where patent applications are involved but otherwise the public service mandate of government and public university should be broadly aligned.
Government and R&D
In certain, typically defense related, research programs where certain information and data may be categorized as official secret, the public and open motivations behind government regulation of IP ownership or so-called ‘march-in’ rights, might be suspended to accommodate what may be seen as national security imperatives.
As a rule though, open and publicly available fits well with the ethos of government owned, government funded or government contracted research. Open source both as a general philosophy and in its narrower application to software code would largely negate the need for regulation either under the Bayh-Dole Act (patents) or the DFAR and FAR standard clauses (data rights and copyrights).
Critical R&D scenarios
Interests do often collide and tensions do invariably come to the surface when either:
A. US Government Agencies contract with corporate entities through various forms of competitive funding or grant programs; or
B. Public or private universities and national research laboratories engage in collaborative R&D with one or more industry partners without government funding; or
C. Universities and their industry partners are collaborating under the framework of a research program, wholly or partially funded by government money.
In all cases, where the research program gives rise to a software-driven invention which is first conceived during the term of the collaboration (this includes improvements on existing inventions), there is the option under the Bayh-Dole Act for either the university or the industry partner to take title in any patents granted, the latter scenario being subject to the government’s march-in rights where the patent holder has not taken effective steps to bring the patented product or patented method to market/industrial usage.
If the decision of the party or parties carrying out the R&D project is to place all of the associated code, including the code for the software algorithms themselves under an open source license, the regulations of Bayh-Dole Act have limited practical application. Anyone inside or outside of government can distribute the software without restriction as long as they comply with the relevant OSS license. This is the essence of OSS and FOSS licenses. Only those few licenses that expressly prohibit the granting of a patent license when the software is redistributed pose difficulties in this regard.
IP developed during the R&D project
Things get a good deal more complicated when software code under proprietary licenses are involved. Even in a B2B collaboration context, there can be major differences in the way in which the collaboration partners view ownership of the arising IP rights. Very often there are conflicting ideas about the respective contributions made to the existing state of the technology, whether in a patent sense or a software coding sense. These rights, often referred to in contracts as the “foreground IP rights” are often bitterly contested and no less so when there is a university partner involved.
The problem is exacerbated by the fact that patent law does not allow for joint patents even when there may be joint inventors and the question of unified or joint ownership in copyright is dependent on underlying facts and circumstances, which may be extremely hard to deduce and apply.
IP existing prior to the R&D project
But it does not end there. Typically, there will be elements of a software implementation which either party might justly claim pre-existed the beginning of the collaborative effort. If these elements are for example proprietary libraries that are crucial to the particular application being developed, an additional layer of licensing (or maybe cross-licensing) comes into play. These pre-existing rights are often referred to as “background IP rights”.
It would be tempting, certainly, in the context of public/private collaborations to think that open sourcing the entirety of software code derived from the project would be a straightforward work around for these complexities but some words of caution. Unless your project is coding from scratch, it may be an uphill battle to ensure that all packages and sub-packages, with their respective libraries and dependencies are clean, both in terms of proprietary elements and in terms of OSS license compatibilities.
Where the public and private entities are both contributing significantly to the software build, both will need adequate assurances that future releases from the project repository will be useful for their purposes. This might mean taking extra precautions in the selection of a mutually acceptable license for the project software and also a mutually acceptable entity for the custodianship of the copyright to facilitate sub-licensing and enforcement.
Copyright Ownership
Last but not least, consider the structures of the university. Copyright ownership and transfers of copyright are not so easy to manage within the context of a university. Faculty members may be on equal footing with employees of corporations when it comes to the work for hire doctrine. Undergraduates, graduate students and PhD students and even post docs may not be. The line will be drawn somewhere along the spectrum. Fellowships and visiting positions bring yet another set of questions into the mix.
Besides, from the point of view of industry partners in particular, since the R&D is rarely starting from scratch, the existence of trade secret information whether contained in software code or otherwise will almost always give them pause for thought in deciding whether or not to open source.
FAR / DFAR Regulation
If this is not enough, the FAR and DFAR regulations add another layer of complexity into publicly funded projects. Tracking the regulatory provisions around the government’s use of foreground and background rights in data and information is in itself a daunting proposition. Software forms a specific sub-set with its own specific rules and regulations, which further complicates the situation. This is a topic which is fully deserving of a separate article.
Your mOSS team
Leave a Reply