pakeplus declares MIT and then says its front-end source is no longer open

The licence says MIT and the same page says the front-end code is closed

The licensing position in this repository is contradictory, and the contradiction is stated on the front page rather than buried.

The sponsors section describes the project as MIT-licensed open source whose development is funded by backers. A licence file sits at the top of the tree.

Above that, a notice says something quite different. Because individuals have used the project to package illegal software, the front-end code will no longer be open source. It adds that if such behaviour is found again, all code in the project will cease to be open source.

So the front end, which is the part of this project that is actually the product, has been withdrawn from the source distribution. What remains open is the desktop shell, the packaging logic and the documentation. The user interface is a compiled artefact you install.

The stated reason is abuse, and closing the source is a proportionate response to it in the author's view. But it changes what MIT means here in practice: an MIT licence over a codebase you cannot read is a statement about the files that remain, not a guarantee you can inspect what you are running.

The consequence is that you cannot audit this tool before you run it. If that matters for your use, stop here.

Cloud packaging puts your build in a repository anyone can see and stars a repo you did not ask for

The token-based packaging path has two side effects stated in a long parenthetical warning, and both matter more than the token itself.

The first is that using a GitHub token with this project automatically stars the repository, and that compilation results are counted as success or failure to improve the project and gather feedback. That is opt-out only in the sense that local packaging avoids it.

The second is more serious. The packaged resources are stored in your own open source repository on GitHub, and the warning says it can be viewed by anyone. The same sentence restricts packaging to personal use and says it should not be disseminated or used for commercial purposes.

So the cloud path takes your application, builds it, pushes the artefacts into your own public GitHub repository, and asks that you not use the result commercially. That is a strange arrangement for a tool whose selling point is turning your project into an app.

The instruction that follows is to follow the platform's usage guidelines or bear the consequences, which is an acknowledgement that the arrangement sits close to the line.

The consequence is direct: do not use the token path for anything commercial, internal, or confidential. Use local packaging, which needs no token at all.

Two routes to a build, and one of them is the only one with no token

Packaging comes in two forms, and the front page describes both as first-class options.

The token route uses GitHub Actions for cloud-based automatic packaging, which is what removes the need to install a native toolchain locally. You supply a token, and the build happens remotely.

The local route runs on your machine with no token and, the features list says, takes about thirty seconds and needs no dependent environment installed.

There is also a third capability that is separate from both: packaging a static build. You can drop in a compiled distribution folder or a single HTML file from a Vue or React project and get a client app out of it.

The static build path is the most interesting of the three because it needs neither a hosted site nor a token. It is the case where you already have a build output and want a shell around it.

So the practical guidance is inverted from what the marketing suggests. The token route exists to remove installation friction, and it is the route with the privacy and licence constraints. The local route is both the most private and the one that needs the least from you.

The size claim appears twice with two different numbers

The project leads with a size number, and a second size number appears nearby.

The repository description and the title line both say applications under five megabytes. The features list repeats it, claiming roughly twenty times smaller than Electron and ten times faster, with the size in parentheses.

Then the introductory paragraph says something different: that there is no need to install complex dependencies and PacBao itself is only about ten megabytes.

The ten-megabyte figure describes PacBao itself; the five-megabyte figure describes the apps it produces.

The consequence is that treat the size figure as an order of magnitude rather than a specification. The architectural claim behind it is the sound part: the desktop build is a Rust binary using Tauri rather than a bundled browser runtime, which is why it can be small at all. What that costs in practice depends entirely on what you are wrapping.

If size is a hard requirement for you, build your target and measure it rather than believing either number.

The environment template ships with payment endpoints pointing at the source host

The example environment file at the top of the repository is a template with placeholder values, and some of the placeholders are pointed at the wrong kind of address.

It defines the GitHub domain, a token prefix and a cloud function token address. Then it defines payment integration settings: a domain, a merchant identifier and a signing key, for three separate payment providers.

Every one of those payment domains is set to the same address as the GitHub host. Every merchant identifier is the same four-digit number, and every signing key is the same four-character string. An analytics identifier is the same number again, as is the upstream user field.

This is a scaffold, not a configuration. The values are obviously not real credentials and are not meant to be.

What it tells you is that the client build has payment and analytics integrations compiled into it as environment variables, and that whoever deploys the web version is expected to supply real values. If you run the browser version from someone else's deployment, their values are the ones in play.

So treat anything you run in a browser as running on the deployer's configuration, and check the analytics and payment settings before you do. The desktop application you build locally is a different artefact from the web one, and the front page says so.

A Python requirements file with 2022 pins sits in a Tauri and TypeScript project

There is a Python dependency file at the top of this repository, and it does not belong to the application.

It lists five packages with exact pins: a certificate bundle from 2022, a character set normaliser, an internationalised domain name library, an HTTP client at 2.28.1 and a URL library at 1.26.12.

Nothing else in the tree suggests Python. The declared primary language is HTML. The desktop shell is Rust, with a src-tauri directory. The interface is Vue with TypeScript, built by Vite, with a lockfile and workspace file for pnpm. The build scripts in the manifest are Tauri, Vite and VitePress invocations, plus one that runs a Node script to create an icon.

So this file belongs to a helper script, a release automation helper or an abandoned experiment. Its pins are old enough that they predate the current versions of everything they name.

The consequence is small but real for anyone auditing dependencies: a scanner will find a Python project inside a Rust and TypeScript one, with an outdated HTTP client, and you will have to work out whether that code path is reachable before you decide it matters.

Also present is a separate notes file at the top level, and a fastlane directory, which is the usual sign of iOS release automation.

The name is spelled three ways across the repository and its own links

If you arrive at this project from a search result, the name you search for may not be the name on the files, and following the wrong link wastes time.

The repository is named for one product. The heading on the front page pairs two names together with a separator, presenting them as one project. The introductory paragraph uses the second name. The feature list uses it throughout. Meanwhile the build scripts, the workspace files and the lockfile all use the first name in lowercase.

The language links at the top are worse. The Japanese link does not point to a Japanese file in this repository. It points to a discussions page on a differently named repository.

There is one Chinese readme file (README_ZH.md), one Japanese (README_JP.md), and the default English readme.

So the practical consequence is that the package in package.json is named pakeplus and marked private, which means it will never appear in a public registry.

Editorial conclusion

This fits someone with a small web project who wants a desktop or mobile shell around it in a few minutes and does not want to install a native toolchain, and the local packaging path is the one to use since it needs no token. Two things to accept first. You cannot read the front-end source, by the project's own statement, so you are trusting a binary whose main code you cannot audit. And the cloud path publishes your build into a repository anyone can view while auto-starring the upstream project, so it is wrong for anything commercial or confidential. Local packaging avoids both. If you need an auditable shell, this is not the tool.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Sjj1024/PakePlus on GitHub