This checklist is for reducing avoidable open-source risk before publishing code or tagging a release.
It is a practical checklist, not legal advice.
Before publishing, confirm all of the following:
- the code was written by you, or you clearly have the right to publish it
- no files were copied from an employer, client, paid course, closed-source plugin, or private repository without permission
- no third-party snippets were pasted in without checking their license
- no screenshots, icons, logos, or demo assets are included unless you have redistribution rights
If you are uncertain about ownership, do not publish that material yet.
- keep a detectable
LICENSEfile in the repository root - make sure the license choice matches your actual intent
- do not add code from sources whose license conflicts with this repository
Current project choice:
MIT, which is permissive and requires preservation of copyright and license notices
Check for:
- API keys
- passwords
- tokens
- SSH keys
.envvalues- internal server addresses
- personal data
- customer data
If any such data was ever committed, removing it from the latest commit is not always enough; treat it as leaked and rotate it where applicable.
Before release, review whether the repository contains:
- vendored third-party source code
- copied documentation text
- copied screenshots or design assets
- bundled binaries
If yes, document the source and license, and add notices if required.
If not, keep it that way unless you are ready to maintain a third-party notices file.
Avoid:
- using another company's logo, icon, or branding unless their terms allow it
- naming that suggests official affiliation when none exists
- screenshots that expose someone else's private or proprietary UI without permission
For this project, the safe default is descriptive wording and your own branding only.
Before publishing, confirm the repository does not contain:
- infringing code or assets
- unauthorized license keys or license bypass material
- malware, attack tooling without a legitimate dual-use context, or abuse infrastructure
- private personal information
- deceptive or misleading project claims
To reduce future disputes:
- keep
CONTRIBUTING.md - keep
SECURITY.md - keep
CODE_OF_CONDUCT.md - review external pull requests for ownership, licensing, and secrets, not only correctness
- reject contributions when provenance is unclear
Keep public claims accurate:
- do not promise security properties you have not actually implemented
- do not promise production readiness if the project is still MVP-grade
- do not imply official support, certification, or partnership unless that is real
Before each public release, do this quick pass:
- run
git statusand confirm no accidental files are included - review changed files for private data, copied material, and local paths
- run
.\gradlew.bat buildPlugin - verify
LICENSE,README,CONTRIBUTING.md, andSECURITY.mdare present - if anything about ownership or license is unclear, stop and resolve that first
Pause the release and get legal or organizational confirmation if any of these are true:
- the code was written during paid employment and ownership is unclear
- you copied code or assets from somewhere but do not know the license
- the repo includes customer, employer, or internal company information
- a takedown, trademark complaint, or formal legal notice arrives
- you are unsure whether a dependency or asset can be redistributed