Package Policy and Acceptable Use
What may be published through the mc registry, what may not, how a problem is reported, and how long an answer takes. The registry hosts metadata and points at code that lives on a public forge; the rules below are about both.
1. What may be published
- Code you wrote, or code you are licensed to redistribute, in a public repository on an allowed forge.
- With a licence in the repository. The registry does not choose one for you and does not change yours; a package with no licence file at all leaves every consumer guessing, and the package page says so.
- With a description that matches what the code does.
2. What may not be published
- Malware. Code whose purpose is to damage, exfiltrate, mine, ransom, hide itself, or take control of a machine or an account that runs or builds it. This includes a package that behaves differently when it detects it is being analysed.
- Credential harvesting. Reading environment variables, key files, tokens or browser storage and sending them anywhere, at build time or at run time.
- Build-time surprises. Code that reaches the network, writes outside its own tree, or executes a downloaded artefact while a consumer is merely compiling it.
- Someone else's code presented as yours, or any publication that breaches a licence, a trademark or a patent.
- Illegal content, content that infringes privacy, and material that is unlawful in Brazil.
- Deliberate confusion: names, descriptions or metadata built to be mistaken for another project, for the mc toolchain, or for the registry itself.
3. Names and squatting
- First registration wins, and a name is never renamed or recycled (Terms, section 5).
- Squatting -- registering names with no intention of publishing under them, registering in bulk, or registering a name in order to sell it or to block someone -- is a breach, and such names are reclaimed.
- Typosquatting -- a name one keystroke away from a popular package, published with unrelated or hostile content -- is treated as malware.
- Names matching
mc*orminicompiler*are reserved for the administrator, because they would look official. - A name may be transferred when both parties ask, or when one party shows it holds the source repository the name points at. Write to legal@minicompiler.dev.
- An abandoned package -- source repository gone, no release in two years, no answer from its owner in 30 days -- may be transferred to a maintainer who asks for it. Its published versions are never altered; the new owner publishes new ones.
4. What validation does and does not prove
Every version is compiled and run inside a sandbox with no network, no view of the host filesystem and named limits on time, memory and processes. A version publishes only if that run succeeds, and the report is shown to the registrant and on the package page.
That is a reproducibility and containment check, not a security review. The registry may also show an automated analysis beside a package -- an inventory of what the code reaches for, a rule-based risk note, and, later, a natural-language summary written by a small local model. The analysis is never the gate. Publication and refusal are decided by the sandbox and by the written rules on this page; the analysis is a dated opinion shown beside the deterministic facts, and a reader can see both. Nothing here is a warranty about a package (Terms, section 10).
5. Reporting a package
Choose the road that fits:
- A vulnerability in a package -- report it to the package's own maintainer first, through its repository. If the package is unmaintained or the maintainer does not answer, write to security@minicompiler.dev and an advisory can be attached to the affected versions.
- Malware, a stolen package, a squatted name, an unlawful package -- the report form on the package page, when you are signed in, or legal@minicompiler.dev.
- A copyright or trademark claim, or a data-protection order -- legal@minicompiler.dev. Include the package and version, the material and the right you hold, your contact details, a statement that the claim is made in good faith, and a signature. A knowingly false claim has consequences of its own.
- A vulnerability in the registry or in the compiler -- the security policy.
6. What happens then, and how fast
| Step | Time |
|---|---|
| Acknowledgement that the report arrived | 3 business days |
| Decision on an ordinary report (squatting, licence, description) | 10 business days |
| Decision on a credible malware report | 24 hours, and immediately where the evidence is plain |
| Action on a valid legal order | as the order requires |
| Notice to the affected maintainer | with the action, or as soon after it as the situation allows |
These are targets for a service run by one person without charge, not contractual guarantees.
7. What can be done about a package
- Advisory -- a dated note attached to one or more versions and shown on the package page and in the index. Nothing is removed.
- Yank -- new projects stop picking the version; a lock file that pins it keeps resolving. The maintainer can do this without asking anyone.
- Delist -- the version leaves the index. Reserved for legal takedowns and for malware, recorded with the reason and the reference of the order.
- Disable a repository -- it disappears from the list and the search and accepts no new versions; what is already published keeps serving, because immutability is a promise to consumers, unless the takedown covers it too.
- Suspend an account -- it can no longer sign in, register or publish. Versions already published stay.
8. Appeals
If you think a decision is wrong, reply to legal@minicompiler.dev with the package, the version and your reasons. Decisions are reviewed by a person, not by an automated system, and a decision taken on the strength of an automated analysis alone is reviewed on request as a matter of course.
9. Mirroring and automated access
The registry index is a tree of static files and mirroring it is welcome; fetch it politely and cache it. The dynamic pages carry rate limits, and going around them -- many addresses, distributed scraping -- is a breach of the Terms.
10. Changes to this policy
This document carries a version, which is its effective date. When it changes you are asked to read and accept the new version the next time you sign in, and the acceptance is recorded.
Change log
- 2026-09-06 -- first version, effective from the day the login opened.