oss-checklist

name	oss-checklist
description	Use when validating an open source project launch readiness or verifying license compatibility — provides a comprehensive OSS launch checklist, license compatibility matrix, and community health file inventory. Extends the open-source-launcher harness and can be used standalone. Also triggers on: re-run, update, revise, supplement.
metadata	{"category":"harness","harness":"30-open-source-launcher","agent_type":"general-purpose"}

OSS Checklist — Launch Readiness and License Reference

A comprehensive reference for open source launch readiness, license compatibility, and community health standards used by the open-source-launcher harness agents.

OSS Launch Readiness Checklist

Repository Hygiene

• Repository name is lowercase, hyphenated, and memorable
• Description field filled in on GitHub repository page
• Topics/tags added (language, framework, use case)
• main or trunk set as default branch (not master for new projects)
• .gitignore covers OS files, IDE files, build artifacts, secrets
• .editorconfig present for consistent editor settings

License and Legal

• LICENSE file present at repository root (not just a badge)
• SPDX identifier in package.json, pyproject.toml, Cargo.toml, or equivalent
• Copyright header in source files (if license requires)
• CLA bot or DCO configured if project requires signed contributions
• Third-party license notices in NOTICES or ATTRIBUTION file (Apache 2.0 requirement)
• Patent grant language included (Apache 2.0 covers this; MIT does not)

Documentation

• README.md has quickstart working end-to-end (tested by maintainer)
• CONTRIBUTING.md present with local dev setup
• CODE_OF_CONDUCT.md present with enforcement contact
• SECURITY.md present with responsible disclosure process
• CHANGELOG.md present (auto-generated by semantic-release/changesets acceptable)
• API documentation generated or linked
• GOVERNANCE.md present if project has multiple maintainers

CI/CD

• CI workflow runs on push and PR
• CI passes on fresh clone with documented setup steps
• Release workflow automates version bump and CHANGELOG
• Dependabot or Renovate configured for dependency updates
• Security scanning (CodeQL, Dependabot alerts) enabled
• Required secrets documented and configured in repository settings

Community Infrastructure

• Issue templates for bug reports and feature requests
• PR template with checklist
• At least 5 good first issue labeled tickets with full context
• help wanted label applied to issues maintainers want community help on
• GitHub Discussions enabled and categories configured
• Branch protection on main (require PR, require status checks)
• CODEOWNERS file configured for auto-review assignment

Launch Preparation

• Launch blog post / announcement drafted
• Demo GIF or screenshot ready for social posts
• Initial version tag (v0.1.0 or v1.0.0) created
• All CI badges in README show green
• Package published to registry (npm, PyPI, crates.io) with correct metadata
• Repository public (not private/internal)

---

License Compatibility Matrix

Quick Reference: Can I use dependency X in a project licensed as Y?

Dependency License →	MIT	Apache 2.0	LGPL 2.1	GPL 2.0	GPL 3.0	MPL 2.0	Proprietary
My project: MIT	✅	✅	⚠️ (LGPL may flow)	❌	❌	⚠️ (file-level)	❌
My project: Apache 2.0	✅	✅	⚠️	❌	✅ (GPL3 compat)	✅	❌
My project: GPL 2.0	✅	⚠️ (clause 7 conflict)	✅	✅	❌	⚠️	❌
My project: GPL 3.0	✅	✅	✅	⚠️	✅	✅	❌
My project: MPL 2.0	✅	✅	⚠️	❌	⚠️	✅	❌

Legend:

• ✅ Compatible — can be used without restriction
• ⚠️ Conditional — compatible with specific constraints; review details
• ❌ Incompatible — cannot be combined in a distribution without legal risk

License TLDR Summaries

License	Can	Cannot	Must
MIT	Use commercially, modify, distribute, sublicense	Hold liable	Keep copyright notice
Apache 2.0	Use commercially, modify, distribute, patent use	Hold liable, use trademarks	Keep copyright, state changes, include NOTICE file
GPL 2.0	Use commercially, modify, distribute	Sublicense, distribute as closed source	Distribute source code, keep GPL license, disclose changes
GPL 3.0	Use commercially, modify, distribute, patent use	Sublicense, distribute as closed source, add DRM	Distribute source code, keep GPL license
LGPL 2.1	Use commercially in proprietary products (via dynamic linking), modify library	Distribute modified LGPL library as closed source	Provide LGPL library source, allow relinking
MPL 2.0	Use commercially, modify, distribute	Hold liable	Keep copyright, disclose source of MPL files, keep MPL license
ISC	Use commercially, modify, distribute	Hold liable	Keep copyright notice
BSD 2-Clause	Use commercially, modify, distribute	Hold liable	Keep copyright notice
BSD 3-Clause	Use commercially, modify, distribute	Hold liable, use project name for promotion	Keep copyright notice
AGPL 3.0	Use, modify	Use in SaaS without disclosing source	Distribute source to network users
CC0	Do anything	(none)	(none — public domain dedication)

Dependency License Audit Workflow

# Node.js / npm
npx license-checker --summary
npx license-checker --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Python / pip
pip-licenses --format=markdown --with-urls

# Go modules
go-licenses report ./...

# Rust / Cargo
cargo-license --json

# Java / Maven
mvn license:third-party-report

---

GitHub Community Health Files Reference

GitHub displays a community health score in the Insights → Community tab based on these files:

File	Location	GitHub Health Check	Purpose
README.md	Root	✅ Required	Project overview
LICENSE	Root	✅ Required	Legal terms
CONTRIBUTING.md	Root or .github/	✅	Contribution guide
CODE_OF_CONDUCT.md	Root or .github/	✅	Behavior standards
SECURITY.md	Root or .github/	✅	Vulnerability reporting
SUPPORT.md	Root or .github/	✅	Where to get help
ISSUE_TEMPLATE/	.github/	✅	Structured issue forms
pull_request_template.md	.github/	✅	PR checklist
CODEOWNERS	Root or .github/	—	Auto-assign reviewers
FUNDING.yml	.github/	—	Sponsor links
CHANGELOG.md	Root	—	Version history
GOVERNANCE.md	Root or .github/	—	Decision-making rules
ROADMAP.md	Root or .github/	—	Future plans

---

Semantic Versioning Quick Reference

MAJOR.MINOR.PATCH[-prerelease][+build]

1.0.0        — First stable release
1.0.1        — Patch: backward-compatible bug fix
1.1.0        — Minor: backward-compatible new feature
2.0.0        — Major: breaking change
1.0.0-alpha  — Pre-release (not stable)
1.0.0-rc.1   — Release candidate
0.x.y        — Pre-1.0: public API not stable; anything may change

Conventional Commits → SemVer mapping:

• fix: → PATCH
• feat: → MINOR
• feat!: or BREAKING CHANGE: footer → MAJOR
• docs:, chore:, ci:, test:, style: → no release