一场围绕 Unix 归属的老案子又被推回台前。The Register 把它称作“僵尸诉讼”：每隔几年就重新出现一次。2026 年 6 月 22 日，美国第二巡回上诉法院就 Xinuos 诉 IBM 一案举行在线听证，核心问题仍然是那句拖了二十三年的老问题：Unix 到底是谁的？
对普通开发者来说，这听起来像法律史。但它真正提醒我们的，是一个更工程化的问题：当一个系统、接口、源码、商标和商业授权横跨几十年、几家公司、几代产品时，技术资产边界如果没有被持续记录，迟早会变成组织级风险。
从 Project Monterey 看技术合作的长期尾巴
这条线索可以追到 1998 年的 Project Monterey。当时 IBM 等公司围绕 Unix 相关技术展开合作。二十多年后，争议仍能围绕“谁拥有 Unix、谁能主张哪些权利、哪些代码或商业行为受到限制”继续发酵。
这里的重点不是判断案件输赢，而是理解技术合作的结构性问题：
- 操作系统、编译器、数据库、中间件这类基础软件，生命周期常常超过公司组织架构。
- 授权协议、合作备忘录、代码贡献记录、商标使用权，可能分别落在不同法律文件里。
- 后续产品可能继承老代码、老接口、老 ABI、老文档，工程上“能跑”不等于权利边界清楚。
- 收购、改名、剥离业务线之后，团队记忆会消失，但合同义务不会自动消失。
Unix 的特殊性还在于：它既是技术谱系，也是商业资产、商标、接口规范和生态符号。争议一旦发生，讨论对象往往不是一个 Git 仓库，而是一串历史关系。
“谁的 Unix”为什么会变成工程问题
开发团队通常更关心 Linux、BSD、AIX、Solaris、macOS、POSIX 兼容性这些实际对象，而不是抽象的 Unix 所有权。但在企业软件里，边界会以更具体的方式出现。
比如：
- 你的产品文档写了“Unix compatible”，这句话是技术描述、营销话术，还是商标使用？
- 你的构建脚本依赖某个商业 Unix SDK，授权是否允许 CI、容器镜像和外包团队使用？
- 你的代码从老产品迁移而来，里面是否混入了第三方示例代码、头文件、测试集？
- 你发布的是源码、二进制、设备固件，还是 SaaS 服务？不同交付形态会触发不同义务。
这些问题不需要等到诉讼才处理。成熟团队会把它们变成可审计的工程流程：依赖清单、许可证扫描、来源记录、发布前检查、商标用语审阅。
可以这样实践：给仓库加一个最小许可证巡检
下面这个例子不是案件事实，而是一个可以直接改造的工程做法：在仓库里快速扫描常见许可证、可疑 Unix 商标用语，以及可能需要人工复核的老式版权头。
新建 license_audit.py：
#!/usr/bin/env python3
from pathlib import Path
import re
ROOT = Path(".")
SKIP_DIRS = {".git", "node_modules", "venv", ".venv", "dist", "build", "target"}
TEXT_EXTS = {
".c", ".h", ".cc", ".cpp", ".hpp", ".py", ".go", ".rs", ".java",
".js", ".ts", ".sh", ".md", ".txt", ".yml", ".yaml", ".cmake"
}
PATTERNS = {
"unix_marketing_claim": re.compile(r"\b(UNIX|Unix)\s+(compatible|certified|system|platform)\b", re.I),
"copyright_header": re.compile(r"copyright\s*\(c\)|copyright", re.I),
"license_hint": re.compile(r"\b(GPL|LGPL|AGPL|MIT License|Apache License|BSD License|Proprietary)\b", re.I),
"third_party_hint": re.compile(r"\b(third[- ]party|derived from|based on|originally from)\b", re.I),
}
def should_scan(path: Path) -> bool:
if any(part in SKIP_DIRS for part in path.parts):
return False
return path.is_file() and path.suffix.lower() in TEXT_EXTS
def main() -> int:
findings = []
for path in ROOT.rglob("*"):
if not should_scan(path):
continue
try:
lines = path.read_text(errors="ignore").splitlines()
except OSError:
continue
for lineno, line in enumerate(lines, start=1):
for name, pattern in PATTERNS.items():
if pattern.search(line):
findings.append((str(path), lineno, name, line.strip()[:160]))
if not findings:
print("No license or Unix wording findings.")
return 0
for path, lineno, name, text in findings:
print(f"{path}:{lineno}: {name}: {text}")
print(f"\nReview {len(findings)} findings before release.")
return 1
if __name__ == "__main__":
raise SystemExit(main())
运行：
chmod +x license_audit.py
./license_audit.py
如果你想把它放进 CI，可以用 GitHub Actions 做一个轻量门禁：
name: license-audit
on:
pull_request:
push:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Scan license and Unix wording hints
run: python3 license_audit.py
这不是法律意见，也不能替代专业的 SBOM、SCA 或法务审查。它的价值在于把“以后再说”的风险提前暴露出来，尤其适合老代码迁移、并购后仓库整理、商业版发布前检查。
代码之外，还要记录“为什么能用”
许可证扫描只能回答“文件里写了什么”。更关键的问题是“我们为什么有权使用它”。这类信息通常不在源码里，需要单独维护。
可以为关键组件建立一份简单的 THIRD_PARTY.md：
# Third-party and Legacy Component Register
| Component | Source | License / Contract | Used In | Owner | Review Date | Notes |
|---|---|---|---|---|---|---|
| example-lib | upstream release | Apache-2.0 | agent service | platform team | 2026-06-30 | Keep NOTICE file in distribution |
| legacy-unix-adapter | internal archive | internal migration approval | compatibility layer | runtime team | 2026-06-30 | Do not publish source without legal review |
真正有用的不是表格本身，而是让团队能回答几个朴素问题：
- 这个组件从哪里来？
- 谁批准过？
- 允许源码分发、二进制分发、SaaS 使用、客户现场部署吗？
- 是否有 NOTICE、署名、开源披露、商标用语限制？
- 如果产品改名、拆分或卖给另一家公司，授权还能不能延续？
Unix 争议之所以能拖这么久，正说明基础技术资产不会因为“大家都知道”就自动变清楚。工程团队最怕的不是复杂，而是复杂没有记录。
采用建议：别等法务来救火
这类历史诉讼给开发团队的启发很直接：把知识产权边界当作发布质量的一部分，而不是合同柜里的附件。
一个现实的检查清单可以这样定：
- 新依赖进入主干前，记录许可证和来源。
- 发布包生成 SBOM，并保存对应版本。
- 文档中的“Unix”“POSIX”“compatible”“certified”等词汇进入发布审阅。
- 老仓库迁移时，单独标记未知来源文件和历史版权头。
- 商业合作、并购、产品拆分时，让工程负责人参与资产清点。
- 对关键基础组件保留合同、邮件批准、贡献记录和发布说明的索引。
Xinuos 诉 IBM 这类案件离多数团队很远，但它暴露的工程教训很近：代码会复用，产品会改名，公司会重组，只有清楚的来源和授权记录能跟上时间。二十多年后还在争“谁拥有 Unix”，对工程组织来说就是一句提醒：今天没写下来的边界，明天可能就要靠法庭解释。