A colleague recently wrote me an email with some good news: their research group was about to release its first open-source code from their research. They were thinking to use the MIT license and had a question: who should be named in the copyright notice—the authors, the authors plus GW, or just GW?
I suspect many researchers have paused at that same line in a license file. You and your team have written the code, made some documentation, and are ready to share it with your community. Now filling that first line on the license notice feels like a test about copyright and university policy.
This short post is your starting point. If you have questions, reach out to your OSPO!
Ordinary scholarly work belongs to its creators
GW's Copyright Policy (like many universities in the US) supports author ownership of ordinary, independently initiated scholarship, including software. It also protects instructional materials and student academic work; students retain rights to their theses and dissertations, granting the university a nonexclusive dissemination license.
The policy's “Substantial Use” clause often causes confusion. It has two triggers: resource use outside normal faculty responsibilities or a student's academic program; or faculty use of resources not ordinarily available to virtually all comparable faculty in the same school or department. It sets no dollar or computing-hours threshold.
My reading: using ordinary university computers, office space, or labs for research or coursework does not itself make GW an owner. Exceptional faculty access can trigger the clause, but even then, university-requested, directed, or appropriately approved use need not require faculty transfer absent a specific copyright agreement.
For ordinary faculty research code and student coursework, put the creators in the copyright notice. Separate exceptions concern student employment duties, faculty work specially commissioned through a written agreement, and sponsored agreements allocating copyright elsewhere. However, funding alone does not transfer ownership. For mixed student roles, the policy considers the activity and favors individual rights when doubt remains.
This is the useful starting point for a conversation with the OSPO. A researcher should be able to describe the actual work—course project, dissertation research, a job assignment—and get help with the particular issue, rather than being handed a list of policies to decipher.
Copyright is separate from patent rights, and GW’s policies leave some questions about research software unresolved. The university is currently reviewing its patent policy, and the OSPO is studying what the proposed changes would mean for software sharing. See the note below.
MIT is a fine license. I usually choose BSD-3-Clause.
If you want others to use your research software, adapt it, and build on it with few restrictions, a standard permissive license is a good starting point. MIT and BSD-3-Clause licenses both serve that purpose, including for commercial reuse.
I would not ask a colleague who has chosen an MIT license to start over, but my own preference is BSD-3-Clause. It spells out notice-preservation requirements for source and binary redistributions and expressly prohibits using the copyright holder's or contributors' names to imply endorsement without permission. MIT requires preservation of its copyright and permission notices in copies or substantial portions of the software. You can read the short MIT and BSD-3-Clause licenses for yourself.
In an older presentation, I emphasized the ambiguity of MIT's phrase “substantial portions.” I still prefer BSD's wording, but I would explain the distinction more carefully today. Neither license guarantees academic citation whenever someone uses your software. Preserving a copyright notice and crediting a research contribution are different things.
For scholarly credit, make the request easy to follow. Add a
CITATION.cff file in the code repository, identify the people who contributed, and provide a citation for the software release. GitHub can display a “Cite this repository” link using that file. I would keep the standard license intact and put citation guidance alongside it.
Add a CITATION.cff file to the root of your repository: a short plain-text file listing the authors, title, version, and DOI that others should cite. GitHub reads it and adds a "Cite this repository" button with ready-made APA and BibTeX entries, and Zenodo uses it when archiving your releases. The free online tool cffinit will generate one for you in a few minutes.
Above all, discuss with your co-authors early on, and always add a license the moment you share the code in a public repository. And if you find code in the wild without a license, you need to assume it is "all rights reserved" and don't use it!
Commit to open source in the proposal
For years, I have taken another practical step: I write explicitly in funding proposals that the project's software will be released as open source. This has given me considerable peace of mind. Sharing the software is part of the research I propose to do, and the university engages in that commitment before the project begins.
For NSF awards, there is a concrete basis for this approach. The Proposal and Award Policies and Procedures Guide expressly includes the proposal referenced in the award notice among the documents composing the award. When the university accepts that award, the referenced proposal is part of it. Other sponsors' incorporation rules and any negotiated changes need to be considered, so I would not claim that every sentence in every funded proposal automatically becomes an award obligation.
Still, an explicit release commitment gives you a documented basis for expecting the university to support the promised sharing. It remains useful even where the university owns rights: the institution can arrange the release it has committed to deliver. The promise does not itself transfer ownership or give a PI authority to license someone else's rights.
Be specific. Name the license where feasible, identify the repository, and say when releases will happen. For example:
Software developed under this project will be released as open-source software under the BSD-3-Clause license in a public version-controlled repository. Releases supporting publications will be archived and made available no later than publication. Third-party components will retain their applicable licenses.
Include the commitment in the narrative and the applicable software or data-management plan. At award setup, you may wish to point the sponsored-projects office to that paragraph and ask it to confirm that the accepted scope retains the commitment and to record who will authorize any university-owned contributions. That is a concrete issue to resolve early, while everyone is planning how the project will succeed.
For me, releasing research software is part of doing the research. Other people should be able to inspect the methods, reproduce the results, and try something I never thought of. A clear license, an accurate copyright notice, and an explicit promise to share help make that possible.
A note on university policy:
GW has proposed changes to its Patents and Tangible Research Materials Policy. The OSPO is currently studying the draft and considering submitting comments before the October 26, 2026 deadline, including on how the policy can support open-source research software. The proposal is still under consultation; it is not the current policy. Read the consultation announcement.