apostrophecms / apostrophecms/apostrophe

packages/launder has no LICENSE file, unlike its sibling packages, so launder@1.7.1 ships without licence text

Closed Beginner friendly
#5,588 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
4.6k
Forks
650
Avg merge
19h 21m
Merged PRs (30d)
23

Description

Hi, and thanks for maintaining `launder` — we depend on it as a runtime dependency.

While auditing third-party licences across our repositories, `launder@1.7.1` was the one package we could not close documentarily. It looks like a per-package omission in the monorepo rather than a licensing decision, since almost every sibling package does carry a licence file.

### What we observe

`packages/launder/package.json` declares the licence on the default branch and in the published artifact:

```json
{ "name": "launder", "version": "1.7.1", "license": "MIT" }
```

But there is no licence **text** to go with it:

| Where we looked | Result |
| --- | --- |
| `packages/launder/` on the default branch | no `LICENSE`, `LICENSE.md`, `COPYING` or `NOTICE` |
| `packages/launder/` at tag `launder@1.7.1` (commit `e9b0ab0849a5dfea0f75335fbdf99b5c6bf9e4b3`) | same |
| `launder@1.7.1` tarball contents | same — only `index.js`, `package.json`, `README.md`, `CHANGELOG.md`, `eslint.config.js`, `test/`, `logos/`, `.travis.yml` |
| `README.md` | no licence section |

Tarball identity verified against the registry: `sha1 ef7155ab0c3ddec2323089c961d2e9a249aa5b0d`, `sha512-mU6WRz5EusL9ZZuiZ5SO4Y6C0P9PAUR9iwdb6bzj4KDihm28DiHFw+/yk9DBH4f+Pv1wuzQ4e2jV3oQ7mkIqvw==`.

### The contrast that suggests it is an oversight

Most sibling packages in the same monorepo do ship a licence file — for example `packages/anchors/LICENSE.md`, `packages/blog/LICENSE.md`, `packages/event/LICENSE.md`, `packages/form/LICENSE.md`, `packages/vite/LICENSE.md`, plus `packages/sanitize-html/LICENSE`, `packages/random-words/LICENSE` and `packages/uploadfs/LICENSE`. `packages/launder` appears to be one of the few without one.

### Why the manifest field alone is not enough downstream

The MIT grant lives in its text, together with the copyright line. An SPDX identifier in `package.json` records the choice but carries neither the grant nor the copyright holder, so consumers who need to satisfy the attribution requirement have nothing to attribute, and automated compliance tooling reports the package as undetermined. This matters more for `launder` than for a dev-only package, because it is a runtime dependency that ships in downstream distributions.

We did see the earlier licensing work in #13, #2220 and #3195; this seems to be a package the monorepo split left behind rather than anything those covered.

### Suggested fix

Adding `packages/launder/LICENSE.md` with the same MIT text and copyright line your other packages use would close it. npm includes `LICENSE`/`LICENSE.md` in published tarballs by default, so the next release would carry it with no packaging change.

Glad to open a PR that copies the text from an existing sibling package if that is welcome — just tell us which package you consider the canonical template.

No urgency: we are recording this as a documented residual item, not a blocker, and we are not asserting any non-compliance on your part.

---

Filed by Claude (Anthropic), acting on behalf of and reviewed by the maintainer of the auditing organisation. Findings above were gathered from the public npm registry and the GitHub REST API only.

Contributor guide

Open the contributing guide

Research direction

Start by comparing packages/launder/package.json with an existing sibling LICENSE.md such as packages/anchors/LICENSE.md or packages/blog/LICENSE.md. Add packages/launder/LICENSE.md using the repository's MIT text and copyright line, then verify the file is present in the package for the next published tarball.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
documentation
Issue type
Documentation
Difficulty
1/5
Estimated time
Under an hour
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
90/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.