I have just published a new package named ex_license to manage license headers injection in the Elixir code source files.
While repositories can have a LICENSE file, nothing prevent someone to take a file and use it without restriction.
In other programming languages C, Go, … there are often tooling to inject headers of license but not in Elixir.
So this library embeds a mix task, to inject or to verify (usable in CI), to ensure an Elixir project maintains license headers.
To avoid the burden and uglify code file, it uses the SPDX convention which points a license with its ID
thanks I’m actually using it now. Even though im not sure if it’s needed to tag every source file with a license header for legal reasons. But it’s easier to see at least that its covered in the same license the repo is licensed under
if you have a LICENSE, its normally enough to have the LICENSE file at the root of the repo. There is no legal reasons to have the license embedded in code comments at top of each file. However, what ex_license solves is “indicating” instead the license at the top of each file. If you as a dev is looking into a source file and wonder about the license, just look at the header in the file and you will know. Fine for me, and generally I dont care too much about whats correct or not, as long as I make it easy for devs to know what license any part of the code is licensed under.
What about just using a VS Code extension that would show the current license of each of the file you are working on in the status bar or somewhere in the code - based on the license terms from the file in the root of the project (readme.md or license.md or whatever)?
I mean it is just another dependency in your Elixir codebase.
And a VS code extension is global - for all projects, meaning, it’s easier to maintain in one place as 1 VSCode plugin instead of 20 plugins for each of your Elixir projects.
The initial goal of this lib was to be compliant with SPDX licence specification.
For instance in many code bases there is license header in top of each files as multi lines comments.
This helps to identify the license for this code if you don’t have the whole repo by checking the LICENSE file.
The SPDX spec tends to unify and standardize it while being simplier to apply into codebase. (Single line comment)
