I see that many Julia packages do not have a license header like “# SPDX-License-Identifier: MIT” in their source files, often also do not have a copyright notice in the README.md file.
Example: GitHub - JuliaControl/ControlSystems.jl: A Control Systems Toolbox for Julia
Is this something that is suggested to do in packages or not?
I personally always only specify that in the LICENSE file. Adding a header to every file would be very repetitive? I even forget to update the date in that one file, so editing all files on new-years (sure could be done with search&replace) is too much work for me.
Also the readme is in the same folder as the license file, so I never felt it is useful to repeat that.
Our university requires that the copyright is clear, in particular in projects where multiple people (like students and staff) contribute. Often files in a project are contributed by different people. So for now I add like:
# Copyright (c) 2020, 2021, 2022, 2024 Uwe Fechner
# SPDX-License-Identifier: MIT
to the top of each file in the src folder.
And in the README.md I write:
# Copyright
See the copyright notices in the source files, and the list of authors in `AUTHORS.md`.
You can read the requirements for packages in the General registry here: GitHub - JuliaRegistries/General: The official registry of general Julia packages
In short packages must have an open source license, which in most cases is found in a LICENSE.md file. This is also verified by the automerge script for every registered version.
Should it be a file “LICENSE” or “LICENSE.md”?
Yes.
(If you follow the link you can read
“License file” refers to the plain text file named
LICENSE.md,LICENSE,COPYING, or something similar.
)
It is usually recommended to add a license header to every source file. This makes it clear that the file belongs to a project with well-defined license. The LICENSE file alone doesn’t imply that the code in a different source file shared by someone is following the license. It also helps in PRs because contributors need to be explicit that their contribution follows the license terms whenever they create a new source file not present in the project.
The OSI has further recommendations:
If your university requires this, I suppose that’s what you have to do. I don’t think anybody else needs to be doing it though. It’s just boilerplate noise, and (IANAL) I don’t think it carries any legal meaning.
Unless there are very distinct parts of a software that are written exclusively by separate groups of people, tracking copyright for individual files and people seems murky to me, legally and practically. If someone adds a function to a file that someone else created, why would they obtain a personal copyright over the existing code? What if they refactor an existing function created by someone else? Adding “authors” to source code files does make sense in order to keep track of who is responsible for particular components, as in, who is the person to ask about code in this file, or who should review PRs. I would think it carries little if any legal meaning.
But again, if your university requires it, best to make them happy, even if their rules make no sense.
Well, my package KiteModels.jl is a collection of kite models, and most of them are written by different people. So it makes sense to give a different copyright to different files. It might be useful if a student can say “I created this model, you can find it in this file” if he applies for a job, and if you can see that in the header of the file.
In that situation, sure! I’m not sure if it carries very much legal weight, but it’s certainly a nice way to ensure attribution. There’s nothing wrong with what you’re doing. But I wouldn’t say every project should start boilerplate copyright notices in every file, as a general rule.
If I evaluated someone for a job position I would rather want to see the PR than the copyright header. That might provide additional information about how they deal with review critique etc.
I think your idea of attribution is a very good one!
I personally prefer to do that a bit more “visibly” maybe by having a specific contributions list in a dedicated section in the docs – that is then even more visible than (just) in the code. But sure that is also just a matter of taste maybe.
I don’t know the specifics of the legislation where you operate, but in many countries employers own the copyright of intellectual properties produced by employees during their work, so legally the copyright should be attributed to the university, not the individual.
Is this good enough? KiteModels.jl/AUTHORS.md at main · ufechner7/KiteModels.jl · GitHub
Sure, that also looks good 
Well, as you can read in the README.md file:
Technische Universiteit Delft hereby disclaims all copyright interest in the package “KiteModels.jl” (models for airborne wind energy systems) written by the Author(s).
Prof.dr. H.G.C. (Henri) Werij, Dean of Aerospace Engineering, Technische Universiteit Delft.
Furthermore, most of the work on this code I did before re-joining TU Delft.
In the specific case of git and GitHub, tracking different licenses and authors manually on a per-file basis actually makes things more complicated and muddier.
If your repository just has a single license, then it’s clear how that works and attribution is handled through git itself.
My packages have only one license, the MIT license, but different authors. And while git handles the details of who committed what, writing on a high level student A contributed model A and researcher B contributed model B, I think it makes sense.
I don’t think the usual practice is to track individual contributors for every source file (unless that file was copied over from some other project), just to give a brief comment that the file belongs to such-and-such project copyrighted by so-and-so and others, and that it is under license X with a pointer to the license file.
It’s true that a lot of large organizations (GNU, Mozilla, etc.) do this as a matter of course, AFAICT not because it’s necessarily legally essential but more as a precaution in case a file gets copied to some other project, and it’s easier to just make a blanket coding standard than decide whether to include a copyright header on a file-by-file basis.
FWIW, here is a blog post by a lawyer (from the Creative Commons project and other prominent orgs) on the topic: On the Importance of Per-File License Information – Luis Villa: Open Tech and Policy
For my own part, I sometimes do it, but for smaller projects I’m often lazy about it and just use a single LICENSE file.
So it basically comes down to not having any real legal relevance, but simply that
[O]ur goal is to pass on any important IP information that might be useful … in the place(s) [downstream licensees] are most likely to find it.
and
I review a lot of different codebases these days, and files get separated from their parent projects and directories all the time. And then you have to use fairly complex (and often expensive) tools to do what should be a simple task – figure out what the license is.
Without any examples given in the blog post, I find that statement highly questionable. With open source development (and Julia open source development in particular) being so centered around GitHub, I would say GitHub’s UI exposes standardized LICENSE files as clearly as one could possibly want. I think that’s absolutely, 100% the place where anyone is most likely to find it. I lack the imagination to see how files get separated from their repo in any realistic scenario of an open-source Julia project. I don’t know that “complex” or “expensive” tools one would have to use to figure out what the license is. As things are in 2025, it feels like a trivial task. The blog post is from 2012, so it might be a bit “outdated” – things have gotten a lot more standardized since 2012.
Of course, anyone can make their own determination of that. Personally, If I were to add any copyright notice to individual files at all, I would limit it to a single line, certainly not the whole multi-paragraph license notice.