LICENSE body is not the canonical Apache 2.0 text — §2 omits the sublicense, public display and public performance grants

Documentation Location

LICENSE

Type of Documentation Issue

Other

What is wrong with the documentation?

The LICENSE file differs from the canonical Apache License 2.0 text in ways that change the operative terms. This is separate from the licensing-history question in #126 and the placeholder question in #102 — both of those were about which license applies and who holds the copyright. This is about the wording of the license body itself, which as far as I can tell nobody has diffed. In #126 the reporter looked at the placeholders and the commit sequence and concluded "the license itself remains valid".

The most consequential difference is in Section 2, Grant of Copyright License. At main (7afc7c1), LICENSE:68-70 reads:

      copyright license to use, reproduce, modify, distribute, and otherwise
      transfer the Work as part of a Derivative Work.

Canonical Apache 2.0 reads:

      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

So the rights to sublicense, publicly display and publicly perform do not appear in the grant, and distribution reads as conditioned on the Work being part of a Derivative Work. Sublicensing in particular is what downstream redistributors and packagers rely on.

Three further edits to operative text:

• Section 9 is retitled "Accepting Warranty or Support" (canonical: "Accepting Warranty or Additional Liability") and rewritten, dropping the "While redistributing the Work or Derivative Works thereof" framing.
• The "Work" definition in Section 1 carries a sentence with no counterpart in Apache 2.0: "(The copyright notice requirement does not apply to derivative works of the License holder.)"
• Section 3 says "the Work and derivative works thereof" in lowercase, where Section 1 defines "Derivative Works" as a capitalised term. The lowercase phrase is undefined.

Smaller drift in the same direction: the "Source" and "Object" definitions are missing the word form; "NOTICE file" for "NOTICE text file"; "copyright notice" for "copyright statement"; "based upon" for "based on". A normalised diff of the whole file against the canonical text shows 71 differing lines.

To reproduce:

curl -s https://www.apache.org/licenses/LICENSE-2.0.txt -o /tmp/apache.txt
diff <(sed 's/[[:space:]]*$//' LICENSE) <(sed -n '/^ *Apache License$/,$p' /tmp/apache.txt | sed 's/[[:space:]]*$//')

https://www.apache.org/licenses/LICENSE-2.0.txt and gh api /licenses/apache-2.0 agree with each other byte-for-byte apart from one leading newline, so either works as the reference.

One practical consequence: because the text matches no known license, GitHub's detector reports the repository as NOASSERTION / "Other" rather than apache-2.0, so automated license scanners downstream see the project as unlicensed.

$ gh api repos/BeehiveInnovations/pal-mcp-server --jq .license
{"key":"other","name":"Other","spdx_id":"NOASSERTION","url":null}

Suggested Improvement

Replace the body of LICENSE with the canonical text, leaving the APPENDIX template unfilled (Copyright [yyyy] [name of copyright owner]) — the APPENDIX is instructions for applying the license to source files, and an unfilled template is what GitHub's detector expects. The attribution added in 9079d06 can move to a NOTICE file, which is the shape the ASF's apply-license guide recommends and what #126 also suggested.

This looks like it would restore the stated intent rather than change it. git log --follow -- LICENSE shows the wording arrived already in this form with ed989b4 ("Apache 2.0 license", 2025-06-13); no later commit touched the body, and 9079d06 changed only the three APPENDIX lines. That is the same window described in #126 as edits made from a mobile device while travelling, and a non-canonical paste fits that account.

Happy to open a PR with the canonical text and a NOTICE if that is useful — it is a single-file replacement.

Target Audience

Existing users (upgrading/troubleshooting)

For disclosure: I maintain a fork (laurigates/pal-mcp-server) and found this while adding a license badge there — the badge would not resolve, which led back to the file. I have corrected it downstream. I am not making a legal determination here, only reporting that the shipped text differs from canonical Apache 2.0 in clauses that grant rights.