Timeline for Open code, closed repo?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 25, 2023 at 8:14 | comment | added | Maniues | @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 | |
| Oct 24, 2023 at 7:31 | comment | added | Brandin | @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. | |
| Oct 20, 2023 at 10:42 | comment | added | Maniues | 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. | |
| Oct 20, 2023 at 6:10 | comment | added | Brandin | 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). | |
| Oct 19, 2023 at 18:10 | comment | added | Maniues | 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. | |
| Oct 19, 2023 at 18:00 | comment | added | Kaz | 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. | |
| Oct 19, 2023 at 10:44 | comment | added | Maniues | 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. | |
| Oct 19, 2023 at 10:39 | comment | added | Philip Kendall | "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. | |
| Oct 19, 2023 at 9:54 | history | answered | Maniues | CC BY-SA 4.0 |