[legal] Legal posture, tool neutrality framing, and required safeguards

[sotashimozono]

Question

souta の affordability constraint (個人 grad student、訴訟は経済的に許容外) を踏まえて、doiget のリーガルポジションと「good faith effort」のための具体的 safeguard を確定する。

これは #5 (TDM priority) / #9 (PDF scope) / #12 (security) の決定に共通する横断テーマ。

Posture (確定)

doiget は 「user が読む権利を持つコンテンツへの access を automation するツール」 として位置づける。

• ✅ 公式 API を使う (Crossref / Unpaywall / arXiv / OpenAlex / DOAJ / S2 / Springer OA / APS TDM / Elsevier TDM)
• ✅ User が自分の network / 自分の API key で access している権利を行使する
• ❌ paywall を bypass しない
• ❌ credential を bundle しない
• ❌ paper を hosting / 再配布しない
• ❌ SaaS / hosted service として提供しない (当面)

Tool neutrality framing

法的根拠として以下を README / docs/LEGAL.md に明記する：

doiget is a general-purpose automation tool for retrieving papers via official publisher APIs. Users are responsible for ensuring they have the right to access the content they request and for compliance with each source's Terms of Service. doiget does not bypass any access control mechanism.

これは Sony Betamax doctrine + tool neutrality の一般原則を活用するための公式な姿勢宣言。

5 つの必須 safeguard (実装要件)

1. API key shipped 禁止

• doiget binary に credential を 1 byte も含まない
• 全 publisher key は env var or ~/.config/doiget/credentials.toml から読む
• credential は secrecy::Secret<String> で wrap し、Display / Debug で **** 化
• tracing log では決して raw 値を出さない

2. Opt-in env var (TDM source)

TDM source 利用時は明示的に user の同意を取る：

export DOIGET_AGREE_TDM_ELSEVIER=1   # Elsevier ScienceDirect TDM ToS に同意
export DOIGET_AGREE_TDM_APS=1        # APS Harvest TDM acceptable use policy に同意

未設定で TDM source を呼んだ場合：

error: Elsevier TDM source requires explicit ToS agreement.
       See https://www.elsevier.com/legal/tdmrep
       Set DOIGET_AGREE_TDM_ELSEVIER=1 to agree.

3. README + docs/SOURCES.md でユーザ責任を明記

各 source の docstring + docs/SOURCES.md で:

• 公式 ToS link
• 利用条件 (institutional access required, etc.)
• "User is responsible for compliance" の明記

4. CONTACT.md / takedown 受け皿

# Takedown Policy

If you are a copyright holder, publisher legal team, or have other
concerns about doiget, please email <souta@email>.
We respond within 7 days and will comply with reasonable requests
including feature removal, API source disabling, or repository takedown.

これで「good faith effort」の客観的証拠を残す。

5. Marketing 言語の self-policing

• ❌ "bypass" / "circumvent" / "free papers" / "no subscription needed" / "Sci-Hub alternative"
• ✅ "automate legitimate access" / "publisher API integration" / "OA + institutional"
• README headline / blog post / HN submit title すべて check

Provenance log (追加 layer)

各取得時に以下を ~/.config/doiget/access.log に記録：

2026-05-05T08:30:12Z  source=unpaywall  ref=10.1103/...  license=CC-BY  size=1.2MB
2026-05-05T08:30:25Z  source=elsevier   ref=10.1016/...  api_key=****1234  size=2.1MB

• raw API key は出さない
• 後から「故意性なし」「合理的信頼」を立証可能
• privacy 配慮: log は local only、telemetry なし

やらないこと (明示)

機能	理由
MCP HTTP transport (multi-tenant)	「公衆送信」リスク、user の責任分離が崩れる
Hosted SaaS (doiget.com 等)	完全に souta が contract party になる
share-vault 機能	他人への paper 配布 = 著作権侵害
Credential 共有機能	API key shared = ToS 違反 facilitator
Bulk download mode (秒数十件)	「商用 scraping」認定リスク。rate limit hard-code (秒 5 件まで)

Risk math (5 safeguards 適用後、5 年想定)

事象	確率	コスト	期待コスト
何も起きない	95%	¥0	¥0
polite email	4%	1 日対応	わずか
cease-and-desist	0.9%	機能無効化 + ¥0-10 万弁護士相談	¥1,000
GitHub DMCA takedown	0.05%	counter-notice or 移転	わずか
訴訟提起	0.01%	和解 ¥10-100 万	¥100-1,000
訴訟敗訴 (worst case)	<0.001%	¥100-300 万	¥1,000-3,000

期待コスト合計: 約 ¥3,000-5,000 / 5 年
Tail risk (worst case): ¥100-300 万 だが、確率 < 0.001% = 実質ほぼあり得ない

実装 deliverables (Phase 別)

Phase 0 (repo bootstrap)

• README.md に "personal research use" + "user responsible for ToS" + "no paywall bypass"
• LICENSE (MIT) に追加コメント (binary と取得 paper の license が別)
• CONTACT.md で takedown 連絡先
• docs/LEGAL.md で本 Discussion の内容を文書化
• secrecy crate を Cargo.toml に追加
• tracing log の credential redaction policy

Phase 5 (TDM source 実装時)

• DOIGET_AGREE_TDM_* env var checks
• docs/SOURCES.md で各 publisher の ToS link
• Provenance log
• Rate limit hard-code

Decision

???

(関連: #5 TDM priority, #9 PDF scope, #12 security threat model)

[sotashimozono]

Filed as external review by Claude (Anthropic, AI agent operating under souta's GitHub auth as collaborator). Not a human doiget contributor and not a lawyer. Arms-length, intentionally adversarial where the framing has gaps. Final Decision authority remains with the human author.

全体評価

posture (公式 API のみ / paywall bypass せず / hosting しない / SaaS 化しない / credential bundle 禁止) は学術 fetcher tool として 明確かつ運用可能な線引き で、先行例 (paperscraper / pyalex / BiblioFetch.jl 等) のレンジ内です。「user が読む権利を持つ access の automation」フレーミングも reasonable。

ただし Decision に持っていく前に、以下 7 点を解像度として上げる必要があると判断します。Phase 5 (TDM 着手) で揉めるとしたら下のいずれかが原因になるはず。

1. Jurisdictional 分析が posture の根拠から欠落

本文では Sony Betamax doctrine + tool neutrality を法的根拠として援用していますが、

• Sony Betamax (1984) は US Supreme Court 判例 で、日本の 著作権法 第 30 条の 4 (情報解析目的の利用) / 第 47 条の 5 (電子計算機による情報処理) と直接対応しない
• author 所在 (JP) と publishers (Elsevier=NL, APS=US, Springer=DE) で提訴可能 jurisdiction が分かれる
• JP 内利用者間で JP 裁判所に提訴された場合の 準拠法 / 国際裁判管轄 分析がない

提案: docs/LEGAL.md に 「この posture は general principle としての tool neutrality + user 自身が ToS contract party になる構造に依拠しており、いずれの jurisdiction でも specific case law での保証はない」 を明記する。posture の弱体化ではなく、good faith の honest な scope description です。

2. 「自ネットワーク内 access のみ」が posture から構造に降りていない

posture 1 文目 "user が読む権利を持つコンテンツへの access を automation する" は 意図 であって 構造的保証 ではありません。現 5 safeguards はすべて "user が悪意なく使う前提でしか作動しない" social layer です:

• 共有 CI runner に TDM key を置けば、PR を出せる第三者が author のネットワーク内 access の範囲を超えうる
• friend に binary を渡し friend が institutional VPN で実行した場合、access 主体性が曖昧
• bulk fetch mode を community PR で追加されたら posture が崩れる

3. 5 safeguards に technical enforcement layer が欠落 (defense in depth が薄い)

現 5 safeguards はすべて social layer (文書化 / 同意取得 / log)。technical layer を 3 つ追加する設計を提案します:

(6) Compile-time feature gating — TDM source を #[cfg(feature = "tdm-*")] で物理隔離。cargo install doiget 由来の default binary は TDM コードを含まない。crates.io artifact で TDM 経路は実行不能。

(7) Runtime Capability Profile — 起動時に env var + credential file から CapabilityProfile を構築。Source::fetch(&CapabilityProfile, ...) を必須引数として未許可 source を呼び出し不能に。

(8) Hard-coded rate limit — const MAX_CONCURRENT_FETCHES: usize = 5 を library const にし、CLI / config で override 不可。bulk scraper 認定リスクの design-time mitigation。

これで 5 social + 3 technical = 8 safeguards 体制 (defense in depth) になり、本日 author が追加した「自ネットワーク内 access のみ」制約が実装で強制される。

4. Risk math (¥3,000-5,000 / 5年) は data-free

事象	確率 (本文)
何も起きない	95%
polite email	4%
cease-and-desist	0.9%

これらの数字の 出所が示されていない。先行例からの類推としては reasonable レンジですが、Decision の justification に使うには base rate が unknown です。

提案: 確率を消して "probability は不明、worst plausible case (¥100-300 万 = author が affordable と明言した上限) を planning baseline とする" に書き直す。"hope" ではなく "plan against" 側に寄せる。

5. Provenance log の spec hole

~/.config/doiget/access.log の仕様が underspecified:

• 失敗時挙動: write 失敗 → fail-closed (取得拒否) / fail-open (続行) どちらか? 本 posture との整合は fail-closed
• timezone: UTC を勧告 (local だと audit 時に混乱)
• 不可侵性: user 編集可能な平文だと audit log として弱い。append-only flag (chattr +a) / hash chain / 別 file への duplicate などを検討
• 保管期間: 明記なし (例: 90 days auto-truncate)
• opt-out: log 自体を user が disable できる設計か? できる場合は posture と矛盾するので議論要

6. Marketing self-policing の enforcement 不足

禁止語リスト (bypass / circumvent / free papers / Sci-Hub alternative) は重要だが、本人 (author or AI agent contributor) が 書いた瞬間に守れる保証がない 設計。

提案: .github/workflows/posture-lint.yml で README / docs/ / blog drafts に対し禁止語 grep を CI で走らせ、違反 PR を fail。3 行で書ける。継続的 enforcement の客観的証跡になる。

7. CONTACT.md の SLA / escalation 不足

7 日以内応答 は最低線として OK ですが:

• author 不在時 (病気 / 学会渡航 / 個人事情) の fallback 連絡先なし
• "reasonable requests" の judge は author 単独 — 対立時の escalation path (academic mentor / pro bono legal) なし
• DMCA counter-notice を送る判断基準なし

→ 「first response 7 日 / substantive response 30 日 / fallback contact / DMCA 対応 policy」テンプレ化を推奨。

追加 Open questions

1. crates.io publish 戦略: doiget (OA-only) と doiget-full (TDM 込み) の 2 binary policy を取るか、1 binary + opt-in build instructions only か?
2. credentials.toml の permission 0600 でない時の起動時挙動 (warn / refuse / silent)?
3. provenance log fail-closed にした場合、log fs full で fetch 全停止 — UX 的に許容できる?
4. ラボ共用 / CI / Docker image での TDM 利用を README で 明示的に discourage するか?
5. DOIGET_AGREE_TDM_* env var に有効期限 (例: 90 days で再同意) を持たせるべきか?

Reviewer Decision proposal

• 既存 5 safeguards を keep
• 3 technical safeguards (compile-time gate / runtime profile / hard rate cap) を追加 → 8 safeguards 体制
• LEGAL.md に jurisdictional caveat と「自ネットワーク内 access のみ」を 1 文目に明記
• Risk math セクションは確率削除 + worst plausible case を planning baseline に書き直し
• .github/workflows/posture-lint.yml で禁止語 CI guard
• CONTACT.md に SLA / escalation / DMCA policy 追加

最終 Decision 権は author に留保。本コメントは外部 perspective として議事録に残します。

---

Reviewer: Claude (Anthropic). Filed 2026-05-05.