Codex / AI 時代のソフトウェア権利・license・商用化を一つの証拠系で決める

Executive Summary

商用化判断の単位は repository や package 名ではない。 seller、exact release candidate / artifact hash、実際の利用・配布形態、対象地域・顧客との約束、そこへ入る全 asset を一つの commercialization_rights_contract_id / contract_version で固定する。同じ dependency でも server 内だけで使う、browser へ送る、顧客へ binary / source を渡す、改変して network service に使う場合では確認事項が変わる。
inventory、provenance、権利根拠、義務履行を分ける。 SBOM、lockfile、package metadata、model card、AI provider の規約、build provenance は有力な証拠だが、ownership、著作物性、非侵害、license compatibility、商標 clearance を単独では証明しない。declared と人が根拠を確認した concluded を混ぜず、missing、custom、NOASSERTION 相当を合格へ丸めない。
AI output の帰属条項は第三者権利の clearance ではない。 provider と利用者の間で output の権利を移す条項があっても、著作権が成立すること、独自であること、他者の code・素材・商標を侵害しないことまでは保証しない。input を使う権利、exact terms version、生成物 hash、人の変更、類似・出典 review を別に残す。
最初の action は fully synthetic な14日間の commercialization rehearsal である。 exact candidate の asset graph を作り、権利判断を専門家へ渡せる粒度にし、NOTICE・帰属表示・source offer 等の reviewed obligation を clean build へ束縛する。結論は NEXT_RELEASE_PROPOSAL_ONLY とし、live 公開、license 変更、権利主張、相手への連絡は別承認にする。

基準日: 2026-08-03
対象: Codex 等の生成 AI を使い、hosted Web app、API、browser extension、mobile / desktop client、self-hosted package、SDK を一人または小規模で作る technical founder
判断単位: seller / rightsholder × exact source and release candidate × artifact digest × use / modification / distribution mode × jurisdiction / customer promise × asset and obligation snapshot

この章は product、engineering、economics、証拠管理の一般教材であり、法律その他の個別助言ではない。著作権、特許、商標、営業秘密、契約、OSS / model / data license の結論は、素材、版、組合せ、利用・配布方法、地域、当事者、契約時点で変わる。重要または曖昧な判断は、実行日時点の原文と適切な専門家へ確認する。

本文・付属物の product、asset、hash、金額、件数、判定、事故はすべて fully synthetic であり、実績、法律判断、license compatibility 表、benchmark ではない。公開物や生成 AI prompt へ、未公開 code、契約書、customer data、credential、法務相談内容を無許可で入れない。

この章は「作れた」から「この形で売れる」までを受け持つ

既存章は必要な部品を持つが、exact release の商用化権利までは結んでいない。本章は各正本を上書きせず、release candidate ごとの inbound rights → obligation → outbound promise → commercialization decision だけを接続する。

正本	既存章が受け持つ問い	本章が追加する接続
05章	dependency、supply chain、AI coding、build / release	lockfile・SBOM・生成差分を exact artifact の権利証拠へ結ぶ
06章	日本の著作権・商標・契約・privacy の共通入口	個別 asset、権利根拠、利用形態、義務履行を fail closed にする
13章	`change_id`、artifact、review、release evidence	Codex が追加した dependency・snippet・output の provenance gate を足す
18章	contractor / partner の契約、知財、責任	contribution 単位の authorship、pre-existing asset、譲渡 / 許諾を release へ束縛する
22章	model / runtime の配置、品質、原価、fallback	model・weight・runtime・data の利用条件を deployment path ごとに分ける
24章	exact candidate をこの形で利用・配布・販売できるか	`STOP / PAUSE / UNKNOWN / REMEDIATE / PROPOSE_BOUNDED_RELEASE` を証拠から決める

実務へ移す付属物は次の二つである。

software rights / provenance 14書式: scope、asset inventory、first-party / contributor、dependency、AI output、model / data / media、reviewed determination、obligation fulfillment、brand / secret、incident、economics、Codex handoff を複製する。
SQLite companion: fully synthetic fixture で9種のfail-closed条件、exact candidate / evidence binding、Form12 control、独立review、署名ref、proposal-only authorityを検査し、AI assignmentやsummary fieldによる短絡も拒むdisposableな参考実装。license 原文を自動解釈せず、実artifactのhash再計算やinventory completenessの証明もしない。

exact commercialization contract を先に凍結する

同じ commit でも build flag、vendored file、model、font、generated asset、配布先が違えば別 candidate になり得る。最初に次を固定する。

commercialization_rights_contract_id / contract_version:
decision owner / independent reviewer / legal escalation owner:
source snapshot checked_at / next_recheck_at:

seller / contracting entity / claimed rightsholder:
product / offer / customer promise:
source commit / tree digest / clean-build receipt:
release candidate / artifact digest / SBOM digest:

use mode: internal tool | hosted service | browser-delivered | mobile/desktop
          | extension | API/SDK | binary | source | self-hosted | marketplace
modification / linking / bundling / model hosting / fine-tuning facts:
jurisdiction / storefront / customer / channel:

asset inclusion cutoff / late-asset policy:
license and provider-terms snapshot cutoff:
required attribution / NOTICE / source / source-offer / disclosure delivery path:

acceptable evidence / UNKNOWN rule / specialist trigger:
maximum license fee / replacement time / support-tail / claim exposure:
rollback / replacement / takedown owner:
candidate action / claim cap: NEXT_RELEASE_PROPOSAL_ONLY

commercialization_rights_contract_id は records を join する stable key であって、権利の存在や許諾を作るものではない。contract version が変わったら、古い approval を新 candidate へ継承しない。

asset graph は code 以外を先に漏らす

「自分の repo だから自分の product」という理解では不足する。一つの画面や API response にも異なる権利と契約が重なる。

asset class	exact identity	必要な問い	よくある誤認
first-party source / schema / prompt / docs	file / commit / author / date	誰が創作し、どの主体が利用・許諾できるか	自分の laptop にあるから会社資産
direct / transitive dependency	ecosystem / name / version / integrity / path	何を、どの形で、どこへ含めるか。reviewed license と義務は何か	direct package だけ見ればよい
copied snippet / vendored file / generated code	exact bytes / source / output hash / diff	出典、条件、実質的類似、変更、権利根拠は何か	短い、検索で出た、AI が出したから自由
model / weights / runtime / API	provider / model / revision / endpoint / terms	commercial use、host / modify / redistribute、input / output、制約は何か	weight を取得できれば open source
training / fine-tuning / eval / retrieval data	dataset / record class / provenance / consent / license	収集・利用・再配布・削除・privacy の根拠は別々にあるか	internet で読めるから学習・再配布できる
font / icon / image / audio / video / copy	exact file / creator / source / revision	Web embedding、加工、広告、再配布、credit の範囲は何か	無料 download は商用自由
contractor / customer / partner contribution	contributor / deliverable / agreement / acceptance	pre-existing asset、新規成果、譲渡、許諾、再許諾、人格権対応は何か	納品・支払済みなら全部取得済み
brand / domain / product name	sign / logo / class / territory / search date	他者の商標等と衝突しないか。自社はどう保護するか	domain や会社名が取れれば使用可能
trade secret / confidential know-how	information class / owner / control / disclosure	秘密管理、access、外部共有権限、返却・削除はあるか	`.gitignore` なら営業秘密になる

一つの asset に複数 class が重なる場合は、一行へ潰さず relation を張る。例えば contractor が AI で作った icon は、contribution agreement、provider terms、input 素材、output、商標・著作権、font / asset license を別々に確認する。

四層を飛ばさず、UNKNOWN を保存する

権利系の release gate は次の四層で作る。

Identity / inventory: exact bytes、version、digest、source、candidate 内の到達経路を特定した。
Provenance / authority evidence: author、rightsholder、license text、agreement、provider terms、receipt 等を取得した。
Reviewed determination: exact use / distribution に対し、誰がどの根拠で利用可能性と義務を判断したかを記録した。
Fulfillment / release binding: required notice、source、attribution、offer、customer term、artifact を履行し、exact digest へ結んだ。

FOUND は ALLOWED ではなく、ALLOWED は FULFILLED ではない。evidence の欠落はゼロでも NOT_APPLICABLE でもなく UNKNOWN にする。NOT_APPLICABLE には適用外と判断した owner、根拠、scope、checked_at が必要である。

SBOM、SPDX、SLSA、registry metadata の責任境界を守る

SBOM は inventory、SPDX は交換形式である

SPDX 3.0.1 の license expressionは AND、OR、WITH、LicenseRef を表現できる。AND と OR を一つの文字列へ平坦化せず、括弧と例外を保存する。SPDX Licensing modelは、artifact 内で宣言された license と、調査から得た objective な conclusion を分ける。missing と NOASSERTION 相当も同じではない。

したがって、最低でも次を別 field にする。

declared_license_expression:
declared_evidence_source / digest:
concluded_license_expression:
conclusion_basis / reviewer / reviewed_at:
unresolved_license_refs:
exact use / distribution facts:
obligation determination / specialist escalation:

SBOM は「何が入った可能性があるか」を調べる starting point であり、次を単独では証明しない。

source が真正で完全であること
runtime download、container base、font、model、copy、external API 等が全て含まれること
license text の解釈、組合せの compatibility、特許・商標・営業秘密
NOTICE、source、attribution 等を実際に正しい recipient へ届けたこと

build provenance は rights provenance ではない

SLSA v1.2は source / build supply chain の段階的な security guarantee と provenance を扱う。正しい source と build へ追跡可能な artifact であることは重要だが、その source を利用・配布する権利までは作らない。

GitHub dependency graph / dependency reviewも manifest、lockfile、submitted dependency 等から version、license、vulnerability の差分を見せる補助証拠である。registry metadata が空、誤り、custom なら人の review へ送り、scan が green だから商用化可能とはしない。

OpenChain ISO/IEC 5230は quality open-source license compliance program の要件を与える。一方、OpenChain 自身も individual license の法的解釈を提供するものではないと説明する。OpenChain FAQ

license 名でなく exact use / distribution trigger を review する

同じ asset でも、事実関係が違えば determination は変わる。次の matrix は結論表ではなく、review へ渡す fact sheet である。

use / delivery fact	記録すること	review で確認する例
hosted server 内だけで実行	artifact、改変、interaction、顧客へ届く部分	distribution / network 条項がどう適用されるか
browser へ JS / WASM / font を送る	exact delivered bytes、source map、license bundle	copies / substantial portions、attribution、source 等
mobile / desktop / extension / binary	bundle、store、installer、更新経路	notice、source、relink / installation information、store terms
SDK / source / self-hosted package	recipient、format、dependency、docs	sublicense、redistribution、source offer、NOTICE、patent terms
dependency を改変・結合	diff、link / IPC / process boundary、generated files	derivative / combined-work analysis と義務範囲
model を host / fine-tune / redistribute	model revision、adapter、weight、runtime、data	field-of-use、commercial use、redistribution、acceptable use、data duty
customer / partner へ成果を譲渡・許諾	deliverable、background IP、territory、term	自社が再利用・再許諾できる範囲、第三者 asset carve-out

代表的な原文から「何を読めるか」だけを取る

MIT Licenseは利用・複製・改変・配布・sublicense・販売を広く許し、copyright notice と permission notice を copies または substantial portions に含める条件を置く一方、明示の patent grant は置いていない。ゆえに「permissive = 義務なし」「permissive なら patent も同じ条件」と短絡しない。
Apache License 2.0は contributor が許諾できる範囲の明示的 patent license を含み、一定の patent litigation を提起した場合の patent license termination も定める。Section 4 は改変表示、license copy、notice 等を扱う。upstream に NOTICE があるか、何をどこへ残すかを exact distribution で review する。
GNU AGPLv3 Section 13は、Program を改変し network 越しに利用者と interaction させる場合に、Corresponding Source を無償で取得する機会を network 経由で提供する条件を扱う。これを他条項・他licenseにある source delivery や written offer と一つの SOURCE_OFFER へ潰さない。単語 AGPL だけで全 hosted service を禁止とも安全とも判定せず、exact program、改変、結合、interaction、access method を専門家と確認する。
OSI Approved Licensesは Open Source Definition に適合する license の一覧である。source が見える、無料である、商用制限付きであることだけでは open source と呼べない。source-available は別 category として扱う。

license 条文を SQL や agent prompt へ universal rule として hard-code しない。machine gate が強制するのは、exact identity、reviewed determination、期限、必要な fulfillment、reviewer authority、candidate binding である。

inbound rights と outbound license は別の decision である

inbound: 自分が使える根拠を作る

first-party code でも、個人、法人、前職、共同開発、customer-funded work、contractor、contest / accelerator、大学等の関与で rightsholder が変わり得る。最低限、author、creation context、employment / engagement、pre-existing asset、agreement、assignment / license、territory、term、sublicense、third-party material を分ける。

日本の著作権法第15条に基づく法人等の著作者性を検討する場合は、法人等の発意、業務従事者、職務上作成、契約・勤務規則等の別段の定めを記録し、プログラム以外では法人等名義の公表要件も分けて確認する。会社の repository にある、会社の機器で作った、報酬を払った、という一事実だけで COMPANY_OWNED にしない。

日本の著作権法第61条は著作権の全部・一部の譲渡を認め、同条2項は第27条・第28条の権利を譲渡目的として特掲しない場合に譲渡者へ留保されたものと推定する。同法59条では著作者人格権は著作者の一身に専属し、譲渡できない。契約に「成果物は発注者に帰属」とだけ書いて、翻案・二次的著作物、人格権の取扱い、background asset、OSS、AI output まで解決したと扱わない。文化庁の著作権契約マニュアルも参考にし、非行使条項を含む個別scopeの有効性・相当性は専門家へ確認する。

Developer Certificate of Origin 1.1 は contribution を提出する権限等についての certification であり、その名称だけで著作権譲渡と扱わない。CLA も標題ではなく、assertion、license、assignment、対象 contribution、適用版を原文から分ける。PR merge、納品、支払は技術・取引事実であり、それだけで欠けた legal effect を作らない。

outbound: 自社が何を誰へ許すかを選ぶ

自社に権利がある範囲だけを license できる。dependency、model、font、customer data、秘密情報を、自社の LICENSE 一枚で上書きできない。

model	顧客へ渡すもの	revenue hook の例	主な設計課題
`CLOSED`	hosted service / proprietary binary、限定 license	subscription、usage、enterprise contract	vendor trust、exit / export、source escrow の要否
`SOURCE_AVAILABLE`	source を独自制約付きで閲覧・利用	hosted premium、commercial license	open source と誤表示しない、制約の明確化
`PERMISSIVE_OSS`	OSI-approved permissive terms の component	hosting、support、integration、brand	fork differentiation、notice、trademark policy
`COPYLEFT_OSS`	reciprocal terms の component	hosted service、support、dual licensing	inbound right、contribution policy、obligation scope
`DUAL_LICENSE`	同じ first-party asset を複数条件で提供	paid commercial exception / proprietary license	全 contribution を両条件で許諾できる chain
`OPEN_CORE`	core と proprietary service / module を分離	managed hosting、enterprise control、operations	境界の誠実さ、dependency / API / trademark policy

個人開発で扱いやすい出発点は、product code、public SDK、protocol / schema、docs、examples、model / data、brand を asset ごとに分けることである。全部を閉じる、全部を開く、license を後で決める、の三択にしない。公開が distribution と認知を増やしても、buyer、paid job、support capacity、hosting advantage がなければ自動で売上にはならない。

AI 生成物は provider contract、input、output、第三者権利を分ける

provider との帰属だけを一段目に置く

OpenAI の current business terms では、当事者間では customer が input の権利を保持し、適用法で認められる範囲で OpenAI が持つ output の権利がある場合は customer へ譲渡される構造と、output が unique とは限らないこと、input への権利と output の評価・利用に customer responsibility があることが分かれている。OpenAI Services Agreement 個人向け terms、business / API agreement、service-specific terms、地域、effective date は異なり得るため、実際に適用された document と version を保存する。OpenAI policies

したがって次の短絡を禁止する。

provider assigned output rights
  != output is copyrightable
  != output is unique
  != output does not resemble third-party material
  != input was authorized
  != every intended commercial use is permitted
  != indemnity applies to this facts pattern

AI feature / code generation ごとに全 prompt を永久保存する必要はない。秘密・個人情報を増やさず、判断に必要な最小限を残す。

provider / product / account terms class / terms version / checked_at:
task and intended commercial use:
input rights categories / prohibited or confidential inputs:
output hash / accepted ranges / human-authored changes:
new dependencies / copied identifiers / citation or source candidates:
similarity / license / trademark review trigger and result:
reviewer / candidate digest / retention-delete rule:

model が citation、source link、license hint を返しても、それ自体を権利根拠にしない。exact source を開き、authoritative text と artifact bytes を確認する。AI output に広い既存 code と一致する断片、固有のコメント、ブランド、架空 license が見つかったら UNKNOWN または PAUSE へ戻す。

model、data、素材を「code license」の付録にしない

model / weights / runtime

Open Source AI Definition 1.0は、use、study、modify、share の自由と、変更に適した形として data information、training / inference code、parameters を要求する。weights を download できる、repository に open と書かれている、model card に license field があるだけで Open Source AI と断定しない。

Hugging Face model cardsの metadata は license、datasets、base model 等を示せるが、publisher が記入した discovery evidence である。exact repository revision、license file、base / adapter / runtime / tokenizer、upstream terms、commercial / field-of-use restrictions、provider acceptable-use termsを別に取る。

data

data には copyright だけでなく、privacy、confidentiality、database / contract、customer instruction、sector rule 等が重なり得る。次を別 determination にする。

collection / receipt: 取得してよいか
storage / transfer: どこへ、誰が、何日保持できるか
product use: retrieval、fine-tuning、eval、analytics、support 等に使えるか
output / derivative use: model、index、aggregate、screenshot、report を提供できるか
redistribution: raw / transformed data を第三者へ渡せるか
deletion / withdrawal: source 削除や customer request を何へ伝播させるか

日本の文化庁「AIと著作権」は、著作権法30条の4を含む考え方と、developer / provider / user 向けのチェックリスト＆ガイダンスを公開する。同条は「享受を目的としない利用」を必要な限度で認めつつ、著作権者の利益を不当に害する場合を除外する。学習、retrieval、生成、公開の全行為を「AIだから自由」と一括しない。

creative asset

Creative Commons licensesは BY、SA、NC、ND 等の条件を組み合わせる。NC は主として commercial advantage や monetary compensation を意図・指向する利用を許さず、実際の目的・文脈による分類が必要である。ND は adapted material の共有を許さない。credit、license link、change indication、share-alike 等を exact asset と delivery surface へ結ぶ。stock site、icon pack、font、music library の独自規約は CC や code license と同じとは限らない。

asset を thumbnail にした、小さくした、CSS で埋め込んだ、AI で加工した、customer が upload した、というだけで原権利の確認を省かない。customer content には利用規約上の license scope、takedown、export、termination 後の保持も必要である。

brand、trademark、trade secret を release の外へ追い出さない

名前の search は clearance ではない

J-PlatPatでは trademark を keyword、classification 等で検索できる。候補名、表記・読み・図形、指定商品 / 役務、類似群、territory、search query、検索日を記録する。ただし preliminary search は登録可能性、非侵害、海外使用、common-law 等の clearance を保証しない。domain、法人名、app-store 名、social handle の取得可否も別である。

product naming の順序は次にする。

候補を複数作り、公開前に preliminary search する。
target market、goods / services、表記・読み、ロゴを専門家へ渡せるようにする。
採用・出願・使用開始・更新・watch の owner と期限を決める。
dependency や open-source project の trademark policy を license と分けて守る。

秘密は「非公開」だけで成立させない

経済産業省の営業秘密管理指針は、営業秘密の要件として秘密管理性、有用性、非公知性を説明する。repo visibility だけでなく、情報 class、owner、access、秘密表示、contract、device / log、AI / vendor 共有、退職・契約終了時の回収 / 削除を管理する。

一度 public repo、package、screenshot、demo、prompt、support ticket へ出した情報を、後から label だけで秘密へ戻せると仮定しない。open-source strategy と trade-secret strategy は同じ asset へ同時に置かず、公開前に境界を決める。

商用化 economics は rights veto の後に比較する

権利がない、義務を履行できない、重大な不明がある候補を、期待利益で平均して release しない。まず veto、次に feasible な候補同士の economics を比較する。

matured rights-clean recurring contribution
  = authoritative settled recurring consideration
  - refund / credit / dispute / claim-related payment
  - variable infra / AI / data / distribution cost
  - license / royalty / attribution-delivery cost
  - compliance review / source fulfillment / support-tail cost
  - actual replacement / remediation / takedown cost
  - allocated founder time at the predeclared shadow rate

これは management metric であり、会計利益、課税所得、損害賠償見込みではない。未確定の legal exposure を恣意的な確率で小さくしない。claim がないことを clearance の証拠にせず、avoided lawsuit を売上へ加えない。

完全架空例: 同じ顧客価値を出す二つの feasible candidate を比較する。A は年間 license 料120,000円、履行・support 30時間、B は置換開発50時間、追加 infra 月3,000円とする。founder-time shadow rate を4,000円、12か月の成熟後 settled contribution を両方720,000円と仮定する。

A = 720,000 - 120,000 - (30 * 4,000) = 480,000円
B = 720,000 - (50 * 4,000) - (3,000 * 12) = 484,000円

B が架空 horizon で4,000円高くても、品質、移行事故、更新性、support tail の不明があれば優位とはいえない。逆に A が高利益でも、license scope が intended distribution を許さないと reviewed されたなら比較対象から外す。この数値は price、工数、license 選択の推奨値ではない。

decision は veto と work order を分ける

final state と remediation action を同じ enum にしない。

final state	意味	次の行動
`STOP`	権利なし、unreviewed custom terms、wrong candidate / hash、broken chain、prohibited use、無権限 disclosure 等	candidate を出さず、保存・連絡範囲を専門家と決める
`PAUSE`	claim / hold、相反する指示、レビュー・署名等の terminal control 不成立	release を凍結し、隔離・replacement・review
`UNKNOWN`	identity、terms、license、authority、obligation、scope が未確定	不明を明示し、取得・専門家相談・代替比較
`REMEDIATE`	use は可能と reviewed されたが、NOTICE、source、credit、契約等が未完了	exact owner / due_at / receipt を持つ work order
`PROPOSE_BOUNDED_RELEASE`	exact candidate、scope、期限、fulfillment が揃った	bounded route を別の release authority へ提案する。公開権限は生じない

WRONG_HASH は STOP / STOP_AND_REMEDIATE、CLAIM_OR_HOLD は PAUSE / PAUSE_AND_ESCALATE、UNKNOWN_LICENSE や STALE_EVIDENCE は UNKNOWN / HOLD_FOR_EVIDENCE、許可済み利用の未履行義務は REMEDIATE / FULFILL_OBLIGATIONS とする。ほかの work order は REPLACE / ISOLATE / SEEK_LICENSE / SEEK_ASSIGNMENT / RENAME / REMOVE_SECRET / ESCALATE_SPECIALIST 等にする。全 asset の veto を revenue score で相殺せず、最も強い未解決 state を candidate decision に上げる。

approval は次の全てに束縛する。

commercialization_rights_contract_id / version
source commit / artifact digest / SBOM digest
asset set cutoff / reviewed determination set digest
fulfilled-obligation receipt set digest
use / modification / distribution / jurisdiction scope
provider terms / license snapshots and expiry-recheck
approver / approved_at / expires_at
NEXT_RELEASE_PROPOSAL_ONLY

late dependency、new font、model revision、build flag、distribution route、customer promise、terms change が入ったら approval を invalidate し、差分だけでなく affected chain を再計算する。

14日間の fully synthetic commercialization rehearsal

日	作業	exit evidence
1	一つの架空 product と candidate、use / distribution を固定	contract v1、scope、owner、claim cap
2	clean build、tree / artifact digest、lockfile、SBOM を取得	reproducible receipt と差分0
3–4	code、dependency、snippet、model、data、media、brand、secret を inventory	asset graph、missing = UNKNOWN
5	first-party / contractor / customer contribution chain を作る	author / agreement / background asset map
6	AI provider / model / registry / source terms を exact version で保存	terms snapshot、checked_at、recheck
7–8	exact use facts を specialist-ready fact sheet にし、reviewed determination を記録	declared / concluded、basis、reviewer
9–10	reviewed obligation を synthetic release bundle へ履行	LICENSE / NOTICE / source / credit receipts
11	copied / generated output と new dependency delta を独立 review	accepted ranges、similarity / source disposition
12	brand preliminary search と secret disclosure path を点検	query log、non-clearance label、access map
13	stale / wrong-hash / unknown / late-asset negative probes	expected fail-closed receipts
14	economics と veto を別に集計し、独立 reviewer が判断	`STOP / PAUSE / UNKNOWN / REMEDIATE / PROPOSE_BOUNDED_RELEASE`

14日では legal clearance、非侵害、長期的な claim absence、全 transitive asset の完全性を証明できない。目的は、実 product の秘密を公開せずに証拠構造と fail-closed gate を rehearsal することである。

Codex を権利判断者でなく evidence producer として使う

repository rule

AGENTS.md には、曖昧な法律結論でなく機械的 invariant を置く。

## Commercialization-rights gate

- New dependency, vendored/generated file, model, dataset, font, icon, image,
  audio, copied snippet, provider SDK, and outbound license change must update
  the asset manifest and state exact source/version/digest.
- Missing, custom, unparseable, conflicting, or stale license/terms metadata is
  UNKNOWN; never infer approval from popularity, registry metadata, or scan green.
- Keep declared license separate from human-reviewed concluded license.
- Do not infer legal compatibility. Bind reviewed obligations and fulfillment
  receipts to the exact release artifact and distribution mode.
- AI-provider output assignment is not proof of copyrightability, uniqueness,
  input authority, or non-infringement.
- Never place secrets, customer data, private contracts, or credentials in prompts
  or public evidence. Actions are NEXT_RELEASE_PROPOSAL_ONLY.

bounded task prompt

Goal:
  Build the asset/provenance evidence for candidate <id>; do not decide the law.

Context:
  exact source commit, artifact digest, distribution/use facts, manifest schema,
  approved source locations, current terms cutoff.

Constraints:
  read-only discovery first; no package publish, license change, rights-holder
  contact, takedown, public disclosure, or live release. Do not upload private code
  or contracts. Mark missing/custom/conflicting/stale as UNKNOWN.

Done when:
  every included asset has identity/source/digest/class; declared and concluded
  fields are separate; reviewed obligations have owner/due/receipt; clean build and
  negative probes bind to the exact artifact; reviewer receives a diff and unknowns.

Codex が package manifest や repository を探索することは有用だが、absence を証明しにくい。runtime fetch、dynamic import、container、build plugin、copy-pasted code、font / image、model download、customer-provided asset を別 probe にする。agent が書いた license appears compatible は conclusion ではなく、review queue の note である。

claim、takedown、license incident は証拠を壊さず処理する

claim や takedown request を受けたら、無視も即時 admission も自動化しない。

authenticity、deadline、channel、affected asset / candidate を記録する。
source、artifact、terms、license、agreement、prompt/output metadata、release receipt を immutable snapshot にする。
affected distribution を PAUSE し、必要なら isolate / feature flag / rollback / replacement を準備する。
customer safety、security、data retention、contractual notice を別に評価する。
reply、counter-notice、settlement、public statement は専門家と authority owner が決める。
replacement 後も old download、container、cache、store、customer self-hosted copy、support tail を追う。

「消したから終わり」ではなく、誰へ何が既に渡ったかを event spine で閉じる。incident cost は 21章の cash / reserve と、15章の closeout responsibility へ渡す。

Recommendations

優先順位は次の通り。

exact release candidate と delivery facts を固定する。 source tree、artifact、SBOM、browser / binary / source / model delivery を同一視しない。
asset class を code の外へ広げる。 generated / copied output、model、data、font、image、contractor、brand、secret を inventory に入れる。
declared、concluded、fulfilled を分ける。 scanner の表示を legal conclusion にせず、reviewer、根拠、期限、scope を保存する。
AI provider terms を versioned evidence にする。 assignment、input responsibility、similar output、service-specific terms、indemnity exclusions を必要な粒度で分ける。
outbound strategy を asset ごとに選ぶ。 product、SDK、protocol、docs、examples、model / data、brand を一枚の LICENSE で上書きしない。
CI は unknown と drift を止める。 人の法律判断を自動化せず、wrong hash、late asset、stale terms、missing fulfillment を機械で fail closed にする。
最初は synthetic rehearsal に留める。 real contract、private code、customer data を public artifact や prompt に出さず、next release proposal だけを作る。

Further questions

実 product へ進む前に、少なくとも次を答える。

主な delivery は hosted SaaS だけか、browser code、SDK、extension、mobile / desktop、self-hosted source / binary もあるか。
法人化前後、前職、共同創業、外注、customer-funded work をまたぐ first-party asset はあるか。
Codex output、copied snippet、generated image / copy をどの単位で追跡できるか。
model / API / dataset / font / icon / media の exact revision と applicable terms を再構成できるか。
public SDK / protocol / core を開くことで distribution が増えるか。buyer は hosting、support、integration、enterprise control のどれへ払うか。
trademark を先に保護すべき product / territory はどこか。公開予定の know-how と秘密に残す asset の境界は何か。
NOTICE、source、attribution、license copy を実 recipient が取得できることを、どの test で証明するか。
claim 時に何時間で distribution を止め、replacement、customer communication、support tail を担当できるか。

Caveats

一次資料も版、地域、language、service、customer class により変わる。URL だけでなく effective date、取得日時、document digest、applicable account / product を保存する。
package / model metadata、SBOM、model card、scanner、AI answer、preliminary trademark search は discovery evidence であり、法的 clearance ではない。
この章は license compatibility matrix、patent freedom-to-operate、国際商標調査、AI学習の適法性を一律に判定しない。重要な候補は弁護士、弁理士、税務・会計等の適切な専門家へ渡す。
open source、source-available、public domain、free-to-use、royalty-free、commercial-use-allowed は同義ではない。
権利が不明な asset を消せば過去 distribution まで消えるわけではない。artifact、recipient、cache、store、customer copy、support obligation を追う。
privacy / security 合格は IP 合格でなく、IP 合格も privacy / security 合格ではない。各 veto を独立に維持する。

最終チェックリスト

Scope / identity

commercialization_rights_contract_id / contract_version、seller、candidate、use / distribution、jurisdiction を固定した
source commit、artifact digest、SBOM digest、clean-build receipt が一致する
late asset、build flag、model / terms change が approval を invalidate する

Asset / provenance

direct / transitive dependency、vendored / copied / generated code を含む
model / weights / runtime、data、font / icon / image / audio / copy を含む
first-party、contractor、customer / partner contribution と background asset を分けた
brand / trademark と trade-secret disclosure を code license から分けた

Determination / fulfillment

declared と concluded license、根拠、reviewer、reviewed_at、scope を分けた
missing / custom / conflict / stale / NOASSERTION 相当を UNKNOWN にした
exact use / distribution facts で reviewed obligation を決めた
license copy、NOTICE、attribution、source / offer 等を exact artifact へ束縛した
SBOM、SLSA、registry / model metadata を legal conclusion として使っていない

AI / data

applicable provider terms version、input authority、output hash、人の変更を残した
output assignment を著作物性、unique、非侵害の証明にしていない
training / eval / retrieval / customer data の取得・利用・再配布・削除を分けた
private code、契約、customer data、credential を無許可で prompt / public evidence へ出していない

Decision / operation

STOP > PAUSE > UNKNOWN > REMEDIATE > PROPOSE_BOUNDED_RELEASE の veto を守る
economics は feasible candidate の比較だけに使い、rights veto を相殺しない
claim / takedown の evidence preserve、pause、replace、reply authority がある
action は NEXT_RELEASE_PROPOSAL_ONLY で、live release / license change は別承認である