| name | licensing |
| description | MANDATORY - Check dependency licenses before importing. Covers license compatibility (MIT, Apache, BSD, GPL), adding dependencies, bundled assets, writing original code, copyright. Triggers on go get, import, add dependency, license check, copy code. Use when this capability is needed. |
| metadata | {"author":"air-gapped"} |
Licensing
This project is MIT licensed.
Compatible Dependency Licenses
Before adding a dependency, check its license. These are compatible with MIT:
| License | Compatible | Notes |
|---|
| MIT | Yes | Same license, no issues |
| BSD-2-Clause | Yes | Permissive |
| BSD-3-Clause | Yes | Permissive |
| ISC | Yes | Permissive (like MIT) |
| Apache-2.0 | Yes | Permissive + patent grant |
| 0BSD | Yes | Public domain equivalent |
| Unlicense | Yes | Public domain |
| CC0 | Yes | Public domain |
| MPL-2.0 | Yes | Weak copyleft, file-level (compatible but adds obligations) |
Use With Caution
| License | Notes |
|---|
| LGPL-2.1/3.0 | Technically compatible for Go (static linking debate), but prefer alternatives |
| GPL-3.0 / AGPL-3.0 | Technically compatible (you can use GPL code in an MIT project, but the combined work's distribution terms get complicated). Prefer MIT/Apache/BSD alternatives to keep things simple. |
Incompatible (DO NOT USE)
| License | Why |
|---|
| SSPL | Not OSI-approved, incompatible |
| BSL | Business Source License, time-delayed open source |
| Proprietary | Obviously incompatible |
| CC-BY-NC | Non-commercial restriction |
| Commons Clause | Commercial restriction |
| No license | Treat as proprietary — do not use |
Checking Dependency Licenses
Go Dependencies
go-licenses report ./... 2>/dev/null
go list -m -json all | jq -r '.Path'
Before Adding a Dependency
- Check the LICENSE file in the repo
- Verify it's in the compatible list above
- If unclear, check SPDX identifier: https://spdx.org/licenses/
Planned Dependencies
Key dependencies and their licenses:
github.com/yuin/goldmark — MIT ✓github.com/yuin/goldmark-highlighting — MIT ✓go.abhg.dev/goldmark/mermaid — MIT ✓github.com/alecthomas/chroma/v2 — MIT ✓
Writing Original Code
The Rule
Learn from other projects. Write your own code.
When studying how another project implements something:
- Understand the concept — What problem does it solve? What's the approach?
- Close the source — Don't have it open while writing
- Write from understanding — Implement based on your mental model
- Make it better — Your version should be at least as good, preferably superior
What's NOT Allowed
func ParseConfig(data []byte) (*Config, error) {
}
func ParseConfiguration(input []byte) (*Configuration, error) {
}
What IS Allowed
func RewriteRelativeURLs(doc []byte, baseURL string) []byte {
}
Gray Areas
| Situation | Guidance |
|---|
| Standard patterns (middleware, handlers) | OK — these are universal idioms |
| Algorithm from a paper/spec | OK — implement the spec, not someone's code |
| Small utility (max, min, clamp) | OK — too simple to be copyrightable |
| Copied struct layout | Risky — restructure based on your needs |
| Copied test cases | Risky — write your own test scenarios |
When In Doubt
- Can you explain it without looking at the source?
- Would your implementation differ if you'd never seen theirs?
- Are you copying structure or just learning a concept?
If yes to all three, you're probably fine.
Bundled Assets
Static assets embedded in the binary must have compatible licenses.
Current bundled assets:
- mermaid.js — MIT
- github-markdown-css — MIT
When adding bundled assets:
- Verify license compatibility
- Note version in Makefile (pinned with SHA-256 verification)
License Headers
Go files do not require license headers — the root LICENSE file covers everything. Optional header for key files:
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
