Who Owns Software?
Hi, Gerald.
Faculty Member A contacted me regarding the process by which Company B might obtain Graduate Student C's software.
OK, so here's my question:
The question is whether Graduate Student C owns this, or whether UW has an ownership claim. NOTE that I'm not trying to assert a claim -- I'm just trying to be sure I understand the rationale.
Let's suppose that Graduate Student C wrote the code himself, and that he made minimal use of UW resources, and that it was part of his thesis research, and that the thesis research was federally funded.
My impression is that if there were "patentable ideas," then UW would have a claim, because of the federal funding. Is this right?
But I assume that "code" is different than "ideas" (e.g., copyright vs. patent), and that Graduate Student C would own the code, so if we agree that the "ideas" are pretty minimal and what we've got here is mostly "code," then it's Graduate Student C's to do with as he likes.
Is this correct?
Would it be any different if Graduate Student C were a faculty member rather than a student?
Ed --
You are correct about student ownership of software under these circumstances.
The UW copyright policy assumes personal ownership of copyrights unless special circumstances prevail. Those circumstances include works commissioned in writing for related compensation, works prepared under funding arrangements that require University ownership, and works prepared making significant uncompensated use of University service centers (and presumably other resources). If a staff programmer provided code to Student C, or he built off code prepared by someone working on an industry-sponsored grant, then we would likely find special circumstances.
The standard patent rights clause at 37 CFR 401.14 comes into play when there is a funding arrangement with the Government. The Government actually has the claim on patent rights, but allows the University to elect title in the rights instead, on the condition that the University file patents, seek commercial licensees, and favor US companies and especially US small businesses.
If at any point Graduate Student C is named as an inventor or co-inventor on a patent application involving this work, the federal government and/or the University would have a claim on the patent rights. Students need to be aware of this situation, if a company to which they transfer software starts thinking patent rights. Any letter confirming UW has no rights in the code should make clear UW or a federal agency may have an interest in patent rights.
In the case where there are patent rights, the code then often becomes an instance of the best mode of practicing an invention, and in those cases, we may request ownership of copyrights as part of supporting the patent application (in which the code or parts of it may need to be provided) and in the overall commercialization effort. So the code and patent rights are not necessarily totally separate. But copyright and patent are.
In this particular case, the situation is simplified because Graduate Student C is graduating. If a graduate student owns code personally, and while in the middle of his or her graduate program licenses or sells the code (or sells consulting time directly tied to the code) to industry and continues to develop the code using University resources (funding, equipment, space, collaboration), then it would appear to me that this is a potential misuse of University resources, as the student is now essentially using University resources to incubate or operate a software company while getting academic space and credit for it. In such a case, I would think it reasonable that the student take one of three actions: (1) work through the University to commercialize, (2) refrain from commercial transactions involving the code altogether while at the University, or (3) keep the code out of the University and not make it a continuing part of his or her academic work.
If the student is at the end of his or her academic program, then there is little or no prospect for continuing work at the University that would make use of University resources, and so long as there are no special circumstances, it makes sense that the student be permitted to own and control the codes he or she has developed, even if they have huge commercial value, and go after industry arrangements. This was the case with Webcrawler, for instance.
One path of analysis for faculty developers is that if they are continuing to develop the software in the University, then they should choose to work through the University for Ethics Law reasons, even if the IP policy taken in isolation might allow an outcome where they would own rights personally.
This would appear to apply even if they dedicate the rights to the public domain but offer personal consulting services, since if it is in their power to make the dedication of rights, then they are participating in a transaction involving the state that they then benefit from personally by selling their consulting services. That the dedication to the public domain allows *others* to also provide consulting services related to the software does not change the analysis with regard to their own personal benefit, and may not mitigate a claim of intent to cause a loss to the state and private gain.
If faculty developers select an alternative, such as not using University resources for work they want to benefit from privately, then there is a question as to whether they are parking valuable ideas outside of the University and therefore not contributing to the best of their ability to the University research and instruction programs.
If faculty developers refrain from using University resources and continue to develop innovations having economic benefit to them, then they raise the prospect among colleagues and the public that any unprotected idea or research material may well be appropriated for private gain in the outside operation, potentially leading to an increasingly legalistic, protective, if not covert or paranoid, work environment. On the face of it, this would not be a desirable outcome.