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?

Kaz
  • 544
  • 3
  • 10
  • 6
    Why go through all these hoops when you could just not make your VCS public in the first place? – Philip Kendall Oct 14 '23 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 Oct 14 '23 at 15:23

1 Answers1

-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

Maniues
  • 870
  • 3
  • 12
  • 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 Oct 19 '23 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 Oct 19 '23 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 Oct 19 '23 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 Oct 19 '23 at 18:10
  • I think we have another question and answer on Open Source SE where the exact opposite analysis was concluded -- see https://opensource.stackexchange.com/questions/1475/is-a-license-bound-to-a-commit 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 Oct 20 '23 at 06:10
  • Of course, I agree with the statement that a new license for new code, old license for old code. But... there are loopholes, and this might be one of them. If commits are files in the repository, and adding a license in parent directory covers files in the repository, why wouldn't the license cover commits? And thus act retrospectively? What we do here is answer legal questions related to Open Source. Arguing about such things is a matter of interpretation and should be considered by the lawyer, or preferably the entire team. – Maniues Oct 20 '23 at 10:42
  • @Maniues Why do you assume that a license file added to a particular parent directory automatically applies to all subdirectories? I don't recall seeing a LICENSE file that specified that kind of wording. In any case, this "problem" is unique to Git -- if one really wanted, he could rearrange the repo so that at the top of the repo there is an empty directory (i.e. nothing but the hidden .git directory) and then in some subdirectory of that, he could store the code proper, the LICENSE file, etc. Because of the way Git works, such subdirectories would be free of this pesky .git/ directory. – Brandin Oct 24 '23 at 07:31
  • @Brandin Because it is a (de facto ) standard. Projects that use alternative licensing usually explicitly put information about that in COPYRIGHT or LICENSE file or use license in particular file – Maniues Oct 25 '23 at 08:14