006.LICENSE能不能不写

在 eBPF 程序中，**char LICENSE[] SEC("license") = "GPL";****
不是语法必需，但在绝大多数“有用的 eBPF 程序里是事实上的必需”。**

下面我从内核规则 → 能力限制 → 实战经验三层把这句话彻底讲清楚。

---

一、这个 LICENSE 到底是什么？

char LICENSE[] SEC("license") = "GPL";

它的本质

• 放进 ELF 的一个特殊 section：.license
• 内核在 load eBPF 程序时会读取它
• 用来判断：
  👉 你是否声明“GPL-compatible”

---

二、如果没有这个 LICENSE 会怎样？

情况 1：你什么都没写（最常见）

libbpf: load bpf program failed: Permission denied

或者 verifier log 里出现类似：

cannot call GPL-only function from non-GPL program

原因

• 内核默认认为：non-GPL
• 自动限制你能用的 helper

---

三、GPL vs Non-GPL：能力差异（非常关键）

1️⃣ 如果你写了 "GPL"

char LICENSE[] SEC("license") = "GPL";

你可以使用：

能力	是否允许
bpf_probe_read_kernel()	✅
bpf_probe_read_user()	✅
bpf_get_current_task()	✅
bpf_override_return()	✅
kprobe / uprobe	✅
fentry / fexit	✅

---

2️⃣ 如果你写了 "MIT" / "BSD" / 或不写

char LICENSE[] SEC("license") = "MIT";

你会 被禁止使用大量 helper：

helper	结果
bpf_probe_read_kernel()	❌ verifier 拒绝
bpf_get_current_task()	❌
部分 tracing helper	❌

👉 内核强行降级你的 eBPF 权限

---

四、为什么内核要这么干？（设计逻辑）

一句话就够：

**eBPF 程序在内核态执行，
**Linux 内核只允许“GPL 兼容代码”使用最危险的能力。

这是 Linux 内核的法律 + 技术双重约束。

---

五、哪些场景“理论上可以不写 LICENSE”？（但不推荐）

⚠️ 极少数情况

• 极简 XDP
• 只用 map + return
• 不用任何 GPL-only helper

例如：

SEC("xdp")
int xdp_pass(struct xdp_md *ctx)
{
    return XDP_PASS;
}

➡️ 这种程序不写 LICENSE 也可能加载成功

---

六、你现在这类程序（mem.bpf.c）能不能不写？

不能。

你现在做的是：

• uprobe / uretprobe
• bpf_printk
• bpf_get_current_pid_tgid
• 未来一定会用：
  • bpf_probe_read_user
  • bpf_get_current_task
  • 栈追踪

👉 100% 需要 GPL

---

七、工程实践里的“铁律”（你可以直接当课程结论）

凡是 tracing / kprobe / uprobe / fentry 的 eBPF 程序，
**LICENSE = "GPL"** 是默认模板的一部分。

---

八、常见误区澄清

❌ 误区 1：写了 GPL 就“污染代码”

错。

• 这是 声明 eBPF 程序的 license
• 不影响用户态程序
• 不影响你的整个项目 license

---

❌ 误区 2：不写也能跑，就没必要写

错。

• 内核版本不同
• helper 使用一旦升级就炸

---

九、推荐你统一使用的标准模板（直接抄）

char LICENSE[] SEC("license") = "GPL";

你甚至可以在课里说一句非常有“记忆点”的话：

**这是 eBPF 程序的“身份证”，
**没它，你进不了内核的核心区域。