2

Has anyone tried to separately license their repository (e.g. Git) from the code that it holds? How did it go? (Sorry about the open-ended nature of the question.)

Corollary to this question: what is the legal status of repositories? Typically, projects do not articulate the copyright and license status of the repository objects. The LICENSE files and copyright headers refer to the content, but are mum about the version control meta-data. I don't think I've ever seen the licensing documents in a FOSS project say anything about the status of, say, the bodies of commit messages.

For instance, a developer could claim claim that all the commit log messages and other meta-data, such as the names of branches and the shape of the object graph, are proprietary. In essence, that the whole repository object as such is not free.

Thus replicating the directory (with git clone, or any other means) would be forbidden. Or various other rules: e.g. the developer could impose that clones of the repository are allowed, but may not be publicly hosted or redistributed. Outside contributors of the project might be required to assign copyright, to the project, of any commit message text.

Yet, a tarball made of a source code baseline using git archive (or a web front end thereof) could be freely licensed, e.g. BSD, MIT. It would contain a free LICENSE file and other files with copyright headers pointing to or reiterating that license.

This could be used as a tactic for discouraging forking, unofficial mirrors (particularly on hosting sites the developer disagrees with) hostile project takeovers and such.

What experience is there with this sort of positioning?

Improve this question
2
  • 6
    Why go through all these hoops when you could just not make your VCS public in the first place?
    – Philip Kendall
    Commented Oct 14, 2023 at 13:09
  • 1
    Some licensing approaches discuss "contributions", not just the resulting software. For example, the Developer Certificate of Origin as used in Linux, or the Apache-2 license.
    – amon
    Commented Oct 14, 2023 at 15:23

1 Answer 1

Reset to default
-1

Technically, commits and other settings in a GIT repository are just files contained in the .git directory. From the moment you add the license, all files are licensed under that license, but since the license also covers .git files, there is a chance that it applies retroactively to all changes to the repository.

This is a tricky topic, but you can assume that if someone provides a tarball or other licensed archive and that archive contains a .git directory, then if you can extract the changes from those files, these changes may be licensed under that license.

Some licenses, as mentioned in the comments, include the description "contribution", which may support the thesis. Additionally, some licenses mention "accompanied documentation", which may suggest that the commit descriptions are documentation, but this is also one interpretation.

This is not legal advice

Improve this answer
8
  • 1
    "From the moment you add the license, all files are licensed under that license" This is wrong, at least for some licenses - e.g. the GPL requires (or at least very strongly suggests) that the header be added to the top of each file intended to be covered.
    – Philip Kendall
    Commented Oct 19, 2023 at 10:39
  • File headers are just a recommendation from the FSF. License is license. Header is helpful when you distribute particular files without other files or when you use some files in another project. This prevents forgetting about the license.
    – Maniues
    Commented Oct 19, 2023 at 10:44
  • OK, so in your opinion, unless something is stated otherwise, the COPYING or LICENSE file you get when you do a (non-bare) git clone covers the meta-data. Fair enough; but part of my question is: has there been a practice anywhere of revoking that license. Saying, no, the LICENSE is only for the content, not the .git objects.
    – Kaz
    Commented Oct 19, 2023 at 18:00
  • I don't think so, but after a quick analysis, metadata are files that are part of the repository. This is an interesting legal case. On GitHub, when you enter the license file, the description is "this repository" and not "this code" or something similar. I know it doesn't mean anything, but it's an interesting topic to discuss with someone more competent, e.g. lawyers from the FSF or other organizations.
    – Maniues
    Commented Oct 19, 2023 at 18:10
  • I think we have another question and answer on Open Source SE where the exact opposite analysis was concluded -- see opensource.stackexchange.com/questions/1475/… In practice I don't see how it would be possible that a commit of a license at some point could really be retroactive to the older commits. And to me this is enough to imply that the .git directory contents can't automatically be assumed to be included in the license -- since that would lead to a contradiction (i.e. possibility of retroactive license changing).
    – Brandin
    Commented Oct 20, 2023 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.