开源不是把代码扔出去就行了¶
我们在决定开源时问的第一个问题不是"用哪个协议"，而是"这份东西是什么"。
我们有两类完全不同的产出：一类是白纸黑字的制度、教程、手册、愿景——这些都是文档。另一类是 qtadmin、qtcloud 这些真正在跑代码的系统。
把这两类东西塞进同一个协议里，就像让说明书和发动机用同一套质检标准——要么说明书过于死板，要么发动机约束太少。
所以我们定了一个简单的规则：文档用 CC-BY-4.0，软件用 Apache 2.0。
文档为什么是 CC-BY？¶
CC 协议族里最常用的有四个：CC0、CC-BY、CC-BY-SA、CC-BY-NC。我们依次排除了三个。
CC0 是"放弃全部权利"。听起来很自由，但这意味着任何人拿了我们的章程和手册之后可以声称这是自己写的，不用标注来源。我们的第二大脑依赖署名做传播——别人看不到"量潮"两个字，就不知道这套标准是谁制定的，提 issue、交 PR、招人、合作这些通道全断了。CC0 是砍掉自己的名片。
CC-BY-SA 要求"相同方式共享"——你改了我们的东西也必须用同样的协议放出去。这个传染性对商业客户是劝退信号。一个企业想用我们的标准做内部文档，还要纠结自己内部的文本需要不需要也开源，他就不用了。
CC-BY-NC 限制商用。这和我们"让市场接受我们的标准"直接矛盾。如果一个合作方看了我们的标准觉得好，但因为商用限制不能用，我们的标准就只是一份自娱自乐的内部文件。
CC-BY 是唯一满足全部诉求的选项：允许商用、允许改编、仅要求署名。这是 CC 协议里门槛最低的那道坎，刚好也是我们需要的。
软件为什么是 Apache 2.0？¶
软件侧的逻辑类似，但多了一层考量：专利。
我们作为一家技术公司，软件产品的核心价值有一部分在专利上。MIT 协议只有版权授权，对专利只字未提。这意味着如果我们开源了某个数据处理方法，别人拿去用完全没问题，但如果用着用着反过来诉我们专利侵权，我们在 MIT 协议下几乎没有武器自卫。
Apache 2.0 有一条明确的专利授权条款：贡献者授予使用者永久、免费的专利许可。同时，如果使用者起诉贡献者专利侵权，授权自动终止。这是双向保护——我们保护使用者，使用者也承担了对等义务。
GPL 的问题在于强传染性。用了 GPL 代码的项目必须整体以 GPL 开源。绝大多数商业客户的第一反应是"不能用"。我们的标准要进市场，Apache 2.0 是业界能接受的最重的那条线。
还有 LGPL，但 LGPL 解决的是库的传染问题——如果你只链接不修改，可以不公开代码。这对 Qt、GCC 这种基础设施是合理的妥协，但我们的软件是完整应用，不是第三方库，LGPL 的让步对我们没有实际好处，却保留着修改后必须开源的传染性，同样劝退商业客户。
至于为什么不用 MIT 和 BSD——Apache 2.0、MIT、BSD 在宽松性上几乎一样，Apache 只比 MIT 和 BSD 多了一份专利授权。在一个专利诉讼风险真实存在的市场里，这份补充不是"多余"，是"必要"。
署名不是法律义务，是商业策略¶
很多人把署名当成"白干了还要帮别人打广告"的负担。我们恰好相反——署名是我们最便宜的品牌投放。
我们的客户不是在街上看到广告来的。学术圈和高新科技企业的获客链路是：有人用了你的教程→推荐给同行→同行看到署名→找到你。去掉署名，链路断裂，你就等着"酒香不怕巷子深"，在巷子里饿死。
署名也是防御。曾经有同行走过来跟我们说，“这个东西跟我们做的很像”。如果协议里有署名，这话就说不出口了——真有署名就不像，没署名才能像。
署名还是人才入口。学生在网上学数据分析，翻到我们的开源教程，看到"量潮科技"四个字，搜到我们的仓库——这是一条不需要 HR 筛选的招聘管线。他已经在用我们的标准工作了，已经交过 PR 了，已经证明过自己了。
选择本身也是一种经营¶
不能说我们选了最优解，只能说我们在所有选项里找了一个当前约束下最适合的。
如果将来发现 CC-BY 不够用，我们可能会微调。如果 Apache 2.0 的某些条款在某个市场里产生了阻力，我们也要面对。协议是写给未来的，不是写给现在的。
但至少今天，我们想清楚了为什么这么选，而不是"别人都用这个所以我也用"。