🌐 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. 🙌