awesome-mac: CC0 in the repository, CC-BY-SA-4.0 in the npm package

The repository declares CC0 and package.json declares CC-BY-SA-4.0

The single most consequential detail in the tree is a contradiction between two files. GitHub shows the repository under CC0-1.0, a public domain dedication with no conditions attached. The package manifest declares its own licence field as CC-BY-SA-4.0, which requires attribution and imposes share-alike on adaptations. Both statements are about the same body of work: a curated list of other people's software. Nothing in either file explains the difference, and there is no note saying which one governs the compiled JSON that npm actually serves, since that artefact is the only thing the package publishes. The consequence is concrete for anyone who forks, translates or republishes. CC0 would let you do all of that silently; CC-BY-SA-4.0 would require credit and would oblige you to license your adaptation the same way. You cannot infer the answer from the more prominent file, so ask the maintainer before you redistribute.

The Dockerfile copies a prebuilt folder and cites a .dockerignore that is not in the tree

The container is three meaningful lines long, and it contains no build step at all:

# https://lipanski.com/posts/smallest-docker-image-static-website
# https://github.com/lipanski/docker-static-website
FROM lipanski/docker-static-website:latest

# Copy the static website
# Use the .dockerignore file to control what ends up inside the image!
COPY ./dist .

Everything about the image is decided before the Dockerfile starts. The base is a third party static site image pinned to a floating latest tag, the only content copied is the dist folder, and the folder it copies is committed to the repository rather than produced inside the image. So the image cannot rebuild the list, cannot regenerate the site and cannot notice that the Markdown changed; it republishes whatever dist held when somebody built it. The comment about the .dockerignore is the sharper problem, because no such file appears among the top level entries, where .gitignore, .gitattributes, .travis.yml and .codex are all present. So the instruction that controls what ends up inside the image points at a file that is not there, which means the copy rule is doing whatever the default behaviour is rather than what the author described.

App links resolve through a redirect service with a numeric id, not the vendor's address

Read an entry link closely and the destination is not what you would guess. The links in the header block run through a maslink path on the author's own pages domain with a bare numeric identifier, such as an id value of 6743495172 for one menu bar utility, and a handful of the entries go to a different host on the author's site or to a GitHub repository instead. The effect is that the curated list does not hand you the vendor's canonical address. It hands you an indirection whose mapping is a number, which means the destination can be changed without the list changing, the final URL is invisible until you click, and a dead vendor page cannot be diagnosed from the Markdown alone. That is a reasonable design for tracking, and a poor one for archiving, so if you are mirroring this list into something you intend to keep, resolve every redirect once and store the real address alongside the source.

Five icons encode four different questions, and only one of them is licensing

The legend at the top of the list defines five markers, and they are not one axis. Open-Source Software means open source, and clicking the icon takes you to the item's repository. Freeware means free to use, or free under a personal licence, which is a statement about price and a loophole in one line. App Store means an App Store hyperlink, which is a distribution channel and says nothing about the licence. Native App means native app, which is a property of the binary rather than a permission. Awesome List means a hyperlink to a corresponding awesome list for the item, so some rows are not applications at all but pointers to other collections. The consequence is that the icons cannot be used as filters. Sorting by open source gives you a licence question, sorting by native gives you an implementation question, and sorting by awesome list gives you a question about whether there is anything to install. Read the legend, then read the individual entry.

A shopping site and an app storefront sit in the sponsor block above the list

The first thing on the page is not the list. A sponsor block occupies the top, and among the entries is a site selling selected software at what it calls best deals, reached through a link carrying a campaign identifier in its query string, alongside a storefront offering more than sixty native Mac applications that run locally, a screen recording tool, and a free IP address lookup. So the header a reader meets before any category is a mix of two informational links and two commercial ones, and nothing marks the boundary. This is a sponsorship arrangement rather than a curation problem, and the list itself is not compromised by it. The consequence is for the reader who is skimming: the page opens with commerce, the commerce is visually adjacent to the curation, and a reader who assumes everything above the categories is editorial has assumed wrong on the first screen.

The npm package publishes four JSON files and nothing else

The package manifest is precise about what ships. The files field lists four artefacts, one per language, all inside dist, and the exports map routes the root specifier plus the ko, ja and zh subpaths, each with an import, a require and a default condition pointing at the corresponding JSON, and adds package.json as an explicit subpath. The main and module fields both point at the English JSON, and the manifest is an ES module. Two consequences follow. First, a consumer gets data and nothing else: there is no schema, no types and no version constant inside the JSON, so a change in the generator's output shape is invisible until your parser meets it. Second, the four language builds are separate files rather than one file with translations, so a consumer who wants Chinese and English has to fetch and merge two exports and decide for itself which field wins when they disagree.

The published package is a build output, and it is months behind the repository

The scripts show how little of this repository is the list itself. Building the documentation is idoc, the JSON is produced by a script in the build directory named ast, the feed comes from another script in the same directory, and the start script chains the documentation build with the JSON generation. A watch mode runs idoc with the watch flag. So the Markdown is the source, the site and the JSON are generated from it, and everything in dist is an artefact. The release history makes the cost of that explicit. Versions 1.11.0, 2.0.0 and 2.1.0 were tagged on 2025-12-18, 2026-03-12 and 2026-03-30, while the repository is not archived and took its most recent push on 2026-09-29. Anything added to the list in the months since the last tag exists in the repository and on the site, and not in the package, so a tool pinned to [email protected] is reading a list from March.

Editorial conclusion

Use awesome-mac as a discovery index and read the icon legend before you trust an entry, because the five badges answer four different questions and only one of them is about licensing. Do not build a toolchain on the npm package without checking its age: the last tagged release is 2.1.0 from 2026-03-30 while the repository took a push on 2026-09-29, so the compiled JSON is behind the list. Settle the licence question yourself before redistributing anything derived from it, since CC0 and CC-BY-SA-4.0 are declared in two different files, and expect links to resolve through a redirect service rather than to the vendor page you expect.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes