Use one of the more standard forms of the Apache-2.0 license file #1943
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This uses the standard Apache-2.0 license file, available for download from https://www.apache.org/licenses/LICENSE-2.0.txt, as `LICENSE-APACHE`. The license text itself is unchanged, but this fixes the broken license appendix. The appendix is expressly not part of the licese terms, so probably nothing very bad would happen due to it, but it is better either to have the appendix, or to omit it entirely, than to have only some fragments of it. At the very beginning, gitoxide was licensed under only the MIT license. Early on, all contributors agreed to dual-license gitoxide under the MIT license and the Apache-2.0 license (#8), and an Apache-2.0 license file was added (ea353eb). The standard Apache-2.0 license file ends in an appendix that describes the usual way of explicitly applying it to code, which contains placeholders which are meant to be substituted if the boilerplate code is copied elsewhere, but not in the license file appendix itself. However, in ea353eb, the placeholders were substituted in the appendix in the license file itself, and the more instructional portion of the appendix was removed. This modification to the appendix, which created an unusual license file, may have been done in order to put the copyright notice somewhere where it would be specifically associated with the Apache-2.0 license option. After all, the boilerplate text wasn't (and intentionally continues not to be) used as a header in source code files as the appendix suggests. But this carried two problems: 1. It was potentially confusing with respect to the significance of that text, since it was not present anywhere a copyright notice would be expected, and came after "END OF TERMS AND CONDITIONS". 2. It had the potential to confuse tooling that processed licenses. One specific case of (2) is known, described in 76ae5d6 (GitoxideLabs#1232) where the license file was changed to remove it. (The MIT license file was also changed to remove the copyright notice, but it is unlikely that the MIT license file contributed to tooling problems, since the copyright line is expected in an MIT license file and is typically present.) That left fragments of the appendix in the Apache-2.0 license file, which no longer even attempts to give any information more specific than that which is present in the licese terms themselves. There are two good ways to fix the problem. One of them is to use the standard version of the Apache-2.0 license file, with the full original appendix with instructions and unsubstituted placeholders intact. That approach is followed here, since adding the missing pieces of the standard appendix makes clear what the current nonstandard fragment is from. (The other approach is to remove the appendix altogether, which is fine to do since it is expressly not part of the license terms, and which seems to be fairly popularly done among Rust projects. We may end up going with that, but for clarity it's not done just yet.)
This removes the appendix from the Apache-2.0 license file. The license terms themselves are of course not modified. The license terms end in "END OF TERMS AND CONDITIONS", which is retained, and the appendix that follows it is removed. This follows the practice in most or all of the repositories owned by the Rust organization of using the Apache-2.0 license without the appendix, on the grounds that it is confusing to keep it, as the procedure described in the appendix for indicating that source code is licensed Apache-2.0 is not actually followed in those repositories: individual source code files are not being given Apache-2.0 license headers. Note that this is merely an issue of confusion; the appendix is not part of the terms of the license, and no permission or limitation depends on whether it is included. See rust-lang/rust#67734 for details. Note that the license text itself must of course not be changed. But this does not change it: the appendix, while it was part of the license file, is expressly not part of the terms of the license.
|
Thanks a lot, I absolutely appreciate your help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We currently have a nonstandard Apache-2.0 license file. The license terms and conditions themselves, including the exact text of them, are standard, fortunately, and always have been--and this PR makes sure not to change that.
This traces the history of how the appendix text (the text after "END OF TERMS AND CONDITIONS") has taken various non-ideal forms, and shows two approaches that I believe are preferable to what we have now, choosing one:
I don't actually prefer the second option. I think they are about equally good, with the first option possibly being slightly better in that it uses the exact Apache-2.0 license file that one can download from the official site presenting the license. (This is also the same as the choosealicense.com version, except that version omits the blank line at the very beginning of the file.) But I think either approach is somewhat preferable to the current situation.
If we go with the first option, as I actually slightly prefer, then the second commit can be dropped. If we go with the second option, then I suggest keeping both commits rather than squashing them, since the first one readily establishes in the diff that the nonstandard trailing text in
LICENSE-APACHEcame from the standard appendix.Review
It seems to me that the changes here are not very contentious. Nonetheless, I do not want to make any change to a license file without review. Furthermore, there is the question of which approach to take.
I recommend consulting the commit messages for details before allowing this to be merged (or before deciding whether to merge it or which of the two approaches to take). I say this because, although the commit messages are of course not legal documents, people may look at them in the history to understand what happened with the licenses. I would be happy to revise or rewrite them if requested.
Most of the interesting information in this pull request is in the c66814f commit message. This pull request description mostly does not duplicate it.
Outscoped
In this PR I have made only changes that strictly improve clarity and that do not modify or appear to modify any license obligations.
As detailed in the c66814f commit message, part of the history prior to this PR had involved removing a copyright line from the Apache-2.0 license. This was a copyright line where no actual copyright line was expected nor present in any standard Apache-2.0 license file, and which seems to have caused problems with tooling (#1232). However, the copyright line at the top of the MIT license file was also removed along with it. That removal should possibly be undone.
It is extremely common that the MIT license carry a copyright line, so it is unlikely that removing it was helpful. (Any tooling used at scale that would break on it would presumably incur thousands of other breakages too. Even if not, the responsibility would be in the tool with the bug.) Also, there are some problems that can arise from removing the copyright line from the MIT license. One such problem, even if all copyright holders agree that it may be removed, is that the license stops making sense because "The above copyright notice" has no referent.
The practice of removing it can be seen in some other Rust projects, and I suspect that the practice may be rooted in the erstwhile removal of the copyright notice in the MIT license file of the rust-lang/rust repository. But that was corrected in rust-lang/rust@f9c1699 (rust-lang/rust#133461), and the rust-lang/rust MIT license file again carries a copyright notice.