🌐 Translation: Translated from Korean.

Open Source Project Pre-Release Checklist: From Project Organization to License Compliance

TL;DR



  • Problem: Scattered files + license violation risk before GitHub release
  • Solution: Project structure reorganization + Apache-2.0 attribution
  • Result: 22 files organized (history preserved), perfect license compliance

1. Beginning: “Almost Violated License While Going Public”

The moment I was about to publish my WordPress automation blog project on GitHub, I discovered a critical issue.

Situation:

  • 16 .md files scattered in the root directory
  • 3 workflow files copied from another open source project
  • No attribution β†’ Apache-2.0 license violation risk

“If I publish this as is, there could be legal issues…”

2. Phase 1: Project Structure Organization

2.1 Problem: Scattered .md Files

blog/
β”œβ”€β”€ README.md
β”œβ”€β”€ CLAUDE.md
β”œβ”€β”€ WORKFLOW-GUIDE.md
β”œβ”€β”€ WRITING-CHECKLIST.md
β”œβ”€β”€ TRANSLATION-PATTERNS.md
β”œβ”€β”€ POLYLANG-AUTO-LINK-SPEC.md
β”œβ”€β”€ TRANSLATION-PROJECT-SUMMARY.md
β”œβ”€β”€ WORK_LOG.md
β”œβ”€β”€ create-prd.md
β”œβ”€β”€ generate-tasks.md
β”œβ”€β”€ process-task-list.md
β”œβ”€β”€ ... (more .md files)

Why is this a problem?

  • Unclear which files are important
  • Users struggle to understand the project
  • Collaboration and maintenance become inconvenient

2.2 Solution: Designing docs/ Hierarchy

Goal: Clean root, systematic documentation

blog/
β”œβ”€β”€ README.md              # Project overview
β”œβ”€β”€ CLAUDE.md              # Claude Code work guide
β”œβ”€β”€ CHANGELOG.md           # Change log
β”œβ”€β”€ ISSUES.md              # Issue tracking
β”‚
└── docs/                  # All documentation here
    β”œβ”€β”€ guides/            # User guides
    β”‚   β”œβ”€β”€ WORKFLOW-GUIDE.md
    β”‚   β”œβ”€β”€ WRITING-CHECKLIST.md
    β”‚   └── TRANSLATION-PATTERNS.md
    β”œβ”€β”€ specs/             # Technical specs
    β”‚   └── POLYLANG-AUTO-LINK-SPEC.md
    β”œβ”€β”€ archive/           # Completed work documents
    β”‚   β”œβ”€β”€ prds/
    β”‚   └── tasks/
    └── prompts/           # AI prompt templates

2.3 Execution: Preserving History with git mv

Key Tip: Use git mv instead of mv!

# ❌ Wrong way: History loss
mv WORKFLOW-GUIDE.md docs/guides/

# βœ… Right way: History preserved
git mv WORKFLOW-GUIDE.md docs/guides/

Why is this important?

  • git mv preserves the file’s entire change history
  • You can track history even after moving with git log --follow
  • When collaborating, you can know “who wrote this code and why”

Actual Work:

# 1. Create docs/ subdirectories
mkdir -p docs/guides docs/specs docs/archive/prds docs/archive/tasks docs/prompts

# 2. Move guide files
git mv WORKFLOW-GUIDE.md docs/guides/
git mv WRITING-CHECKLIST.md docs/guides/
git mv TRANSLATION-PATTERNS.md docs/guides/

# 3. Move spec files
git mv POLYLANG-AUTO-LINK-SPEC.md docs/specs/

# 4. Archive completed work documents
git mv TRANSLATION-PROJECT-SUMMARY.md docs/archive/
git mv WORK_LOG.md docs/archive/
git mv tasks/9.0-prd-auto-translation-system.md docs/archive/prds/
git mv tasks/tasks-9.0-prd-auto-translation-system.md docs/archive/tasks/

# 5. Move entire prompts/ folder
git mv prompts docs/

Result: 22 files organized (100% history preserved)

2.4 README.md Update

Added project structure section for immediate user understanding:

## πŸ“‚ Project Structure

blog/
β”œβ”€β”€ packages/ # Source code (TypeScript, monorepo)
β”‚ β”œβ”€β”€ cli/ # CLI tool (user interface)
β”‚ β”œβ”€β”€ core/ # Core logic (WordPress API, translation, images)
β”‚ └── shared/ # Shared types and utilities
β”‚
β”œβ”€β”€ content/ # Blog content (markdown)
β”‚ β”œβ”€β”€ posts/ # Blog posts (ko/, en/)
β”‚ β”œβ”€β”€ pages/ # Static pages
β”‚ └── templates/ # Post templates
β”‚
β”œβ”€β”€ docs/ # Project documentation
β”‚ β”œβ”€β”€ guides/ # User guides
β”‚ β”œβ”€β”€ specs/ # Technical specs
β”‚ β”œβ”€β”€ archive/ # Completed work documents
β”‚ └── prompts/ # AI prompt templates
β”‚
└── README.md # This file

3. Phase 2: Apache-2.0 License Compliance

3.1 Problem: Missing Attribution

While reviewing the project, I made a critical discovery:

# .gitignore
create-prd.md          # ← Copied from another repository
generate-tasks.md      # ← Copied from another repository
process-task-list.md   # ← Copied from another repository

Original Source: ai-dev-tasks
License: Apache-2.0
Problem: No attribution β†’ License violation!

3.2 Apache-2.0 License Requirements

Apache-2.0 is a permissive license, but it has several obligations:

3 Mandatory Requirements:

  1. βœ… Original copyright notice
  2. βœ… License notice
  3. βœ… Modifications notice

Optional:



  • Provide NOTICE file (recommended)
  • Patent use notice (if applicable)

3.3 Solution: Adding Attribution Headers

Added attribution headers at the top of each file:

<!--
Original source: https://github.com/snarktank/ai-dev-tasks
Copyright: Original authors of ai-dev-tasks
License: Apache-2.0 (https://www.apache.org/licenses/LICENSE-2.0)

Modified by: idongho for Korean blog automation project
Modifications:
  - Added AskUserQuestion tool integration for Claude Code interactive interface
  - Adapted PRD template for Korean blog automation workflow
  - Enhanced clarifying questions process with structured options
-->

# Rule: Generating a Product Requirements Document (PRD)
...

Added to 3 files:

  • create-prd.md – PRD generation guide
  • generate-tasks.md – Task generation guide
  • process-task-list.md – Task management guide

3.4 Adding Credits Section to README.md

Added Credits section above the license section:

## πŸ“œ Credits

This project uses workflow templates from [ai-dev-tasks](https://github.com/snarktank/ai-dev-tasks) licensed under Apache-2.0.

**Modified files**:
- `create-prd.md` - PRD generation guide adapted for Korean blog automation with AskUserQuestion tool integration
- `generate-tasks.md` - Task generation guide with enhanced testing requirements
- `process-task-list.md` - Task management guide with strengthened test execution policy

Original license: [Apache-2.0](https://github.com/snarktank/ai-dev-tasks/blob/main/LICENSE)

3.5 Commit and Push

git add README.md
git commit -m "docs: Apache-2.0 λΌμ΄μ„ μŠ€ attribution μΆ”κ°€

- README.md에 Credits μ„Ήμ…˜ μΆ”κ°€
- ai-dev-tasks μ €μž₯μ†Œ 좜처 λͺ…μ‹œ 및 μˆ˜μ • 파일 λͺ©λ‘ μž‘μ„±
- 둜컬 μ›Œν¬ν”Œλ‘œμš° 파일 3κ°œμ— attribution 헀더 μΆ”κ°€

원본 좜처: https://github.com/snarktank/ai-dev-tasks
λΌμ΄μ„ μŠ€: Apache-2.0"

git push

4. Pre-GitHub Release Checklist

πŸ“‹ Project Organization

  • Keep only essential files in root directory (README, LICENSE, etc.)
  • Design docs/ hierarchy (guides/, specs/, archive/)
  • Move files with git mv (preserve history)
  • Add project structure section to README.md
  • Update .gitignore (sensitive information, personal files)

πŸ“œ License Compliance

  • List all open source libraries/code used
  • Check each license requirement (MIT, Apache-2.0, GPL, etc.)
  • Add attribution headers (Apache-2.0, GPL)
  • Add Credits section to README.md
  • Create LICENSE file (your project license)

πŸ”’ Security

  • Verify .env file is in .gitignore
  • Remove API keys and passwords
  • Check Git history for sensitive information
  • Provide .env.example file

πŸ“ Documentation

  • Write README.md (installation, usage, contribution guide)
  • Write CHANGELOG.md
  • Write CONTRIBUTING.md (collaboration guide)
  • Add comments to code

5. Lessons Learned

5.1 The Importance of git mv

Before:

mv old.md new.md
git add new.md

β†’ Git recognizes it as a new file, history lost

After:

git mv old.md new.md

β†’ Git recognizes it as a move, history preserved

Verification:

git log --follow new.md  # Shows history before the move too

5.2 License Compliance is a Legal Obligation

Not “I’ll do it later” but do it right from the start.

  • Apache-2.0: attribution + modification notice
  • MIT: copyright notice
  • GPL: source code disclosure obligation

5.3 Project Structure is the Beginning of Collaboration

Clean structure = Low entry barrier = More contributors

βœ… Good structure: Users understand within 5 minutes
❌ Bad structure: Users struggle for 30 minutes

6. Next Steps

βœ… Completed:

  • Project structure organization (22 files)
  • Apache-2.0 license compliance
  • README.md update

🚧 In Progress:

  • Writing CONTRIBUTING.md
  • Setting up GitHub Actions CI/CD
  • Adding issue templates

References

Open Source Licenses

Git Best Practices

Project Structure

Did you find this post helpful?

If you’re preparing to release a GitHub project, use this checklist to safely publish without license violations!

Please leave any questions or suggestions in the comments. πŸ™Œ