Copyright & Licensing

Copyright: Limitless Labs Inc
Contact: legal@dayprotocol.com · contribute@dayprotocol.com

1. Why this matters (Superform lesson)

Superform’s trust stack was not only “code on GitHub”:

Piece	Superform
Copyright owner	Explicit (e.g. ZeroPoint Labs Inc. on BSL)
License	v1 BSL 1.1 (prod use restricted until change date) → later GPL; v2 Apache 2.0
Audits	Published under versioned trees
SECURITY.md	Known issues + scope

Without who owns copyright + what license applies, open-sourcing contracts is fuzzy and weakens the “immutable core” story.

2. Copyright ≠ license

Concept	What it does
Copyright	Who owns the work (default: author / employer / company). Exists automatically; registration optional (US) but helps enforcement.
License	What others may do with the work (use, fork, commercial, etc.).
Trademark	Name/logo (DAY, DAY wordmark) — separate from code copyright.
Patent	Optional; Apache 2.0 has patent grant language.

You need both: clear copyright holder on every public file, and a LICENSE for each published package version.

3. Recommended copyright holder

Pick one legal owner for DAY software (and stick to it in headers):

Option	When
A. Operating company (e.g. DAY Inc. / GEN entity)	Preferred for fundraising, employment, OSS
B. Individual (mav)	Fine for early private repo; migrate to company before public launch
C. Split (core company · site/agency contractor)	Only with written assignment of copyright

Rule: All contributions (employees, contractors, agents) should sign a CLA or employment IP assignment so the holder is clean before public core.

Action for mav: name the legal entity that will appear as Copyright (c) YEAR <Entity>.
Placeholder used in this repo until set: Limitless Labs / update to entity.

4. License strategy (aligned with Superform + open core)

4.1 Suggested split

Artifact	Suggested license	Rationale
Move core (fee, withdraw, harvest invariants) at launch	Apache 2.0 or BSL 1.1 → Apache after N years	Trust + optional fork delay (Superform v1 BSL, v2 Apache)
Adapter interfaces + mocks	Apache 2.0	Max agent adoption
SDK (`@dayprotocol/sdk`)	Apache 2.0	Standard for libraries
Schemas / docs (constitution)	CC-BY-4.0 or Apache 2.0	Docs often CC-BY; code Apache
Site / brand assets (DAY.svg, marketing)	All rights reserved or separate brand license	Don’t put logo under Apache by accident
Private keepers / ranking / XEL glue	Proprietary (no public LICENSE)	Moat

4.2 Superform-style timeline (if BSL chosen)

Publish core under BSL 1.1
  → non-production use OK; production restricted
  → Change Date = publish date + 2 years (or shorter)
  → Change License = Apache-2.0

If max trust / agent ecosystem is priority → Apache 2.0 from first public tag.

5. What to put in the repo (checklist)

Root of every public package

LICENSE              # full license text
NOTICE               # copyright holders + third-party notices
SECURITY.md          # how to report vulns; known issues
COPYRIGHT            # optional one-liner owner statement

Source file header (Move / TS / JS)

// Copyright (c) 2026 <ENTITY>. All rights reserved.

or for BSL:

// Copyright (c) 2026 <ENTITY>.

Brand / site

site/public/day.svg and brand guidelines: not Apache by default
Add BRAND_LICENSE.md: “DAY wordmark © ENTITY; no trademark license granted by code license.”

Third-party

Proto Mono / Blur-adjacent fonts: confirm license before shipping public (self-hosted fonts need redistribution rights)
Superform: patterns only — never copy their Solidity into Day under a mismatched license
Chain logos (Sui/Solana/Base): follow each foundation’s brand kit

6. Copyright notice for DAY (template)

Until entity is finalized, use in docs and headers:

Copyright (c) 2026 Limitless Labs.
All rights reserved unless otherwise indicated in LICENSE.

When entity is known, replace with legal name, e.g.:

Copyright (c) 2026 <Legal Entity Name>.

Year: use first publication year; for ongoing work 2026 or 2026-present.

7. Site / product legal pages (dayprotocol.com)

Separate from open-source LICENSE:

Page	Purpose
`/legal/terms`	Product ToS (Auto Yield use, risk, no custody promises carefully worded)
`/legal/privacy`	Privacy policy
`/legal/risk`	Smart contract / yield / bridge risk disclosure
Footer	© 2026 DAY · links to terms + docs

8. Open-source publish sequence (with copyright)

Choose entity name + file formation if needed
IP assignment from individuals/contractors → entity
Add LICENSE + NOTICE + SPDX headers on the freeze tag
External audit of that tag / package id
Open public repo or open-source path under dayprotocol/*
Docs page: copyright owner, license, package ids, audit PDFs

Never open “floating main” without headers/LICENSE.

9. Decisions for mav (fill in)

#	Decision	Options
1	Copyright owner legal name	Limitless Labs (locked)
2	Core license at first public tag	Apache 2.0 / BSL-1.1 / other
3	If BSL, change period	1y / 2y / other
4	SDK license	Apache 2.0 (recommended)
5	Brand assets	All rights reserved (recommended)
6	Public repo name	`dayprotocol/day` or `dayprotocol/core`

10. Bottom line

Yes — you need copyright hygiene as much as versioning.

Copyright = who owns DAY code and brand
License = what the world can do with each versioned package
Superform model = named licensor + clear license per generation + audits

Version freeze + copyright holder + LICENSE on the same git tag as the immutable Move package = the trust package we ship.