使用许可来最大限度地促进开源软件生态系统的创新(演讲文字实录)

视频原地址：（https://www.youtube.com/watch?v=rCF3TA92vCc），演讲时间是2023年5月。

开场白与自我介绍

非常荣幸能够在今天和大家在一起，就我个人而言，我非常喜欢我今天要分享的主题，这也是我亲历的主题，它非常的吸引人，也让人感觉充满了希望，非常高兴能够和大家分享这个主题，我将从最基础的内容讲起，因为我和人们探讨时，经常会遇到对开源的理解有着不同层次的人们，那么最安全有效的做法就是从基础聊起。当然，在开始之前，我也对大家有所了解，主办方也希望我能够从基础讲起。另外，今天我也有一个大胆的想法，那就是改变大家对可能性假设的改变，这通常说的是人们根本不相信开源能有啥成就，而我要分享的则是开源的运作方式，一些企业正在做的事情，开源每天都在全球范围内进行协作，我希望大家能够认真的思考这些合作如何在各个行业和生态系统中大规模的发生，这就是我今天的目标，确实是比较大的一个目标，

很多种不同的方式讲述开源

我不可能将开源的所有故事都讲完，确实时间有限，那些相当重要的故事，例如Richard Stallman 还是必须要讲的。提供源代码对于保障公民权利是相当重要的，他们认为，拒绝提供源代码意味着你无法访问信息，你也无法管理自己的数据，无法修复有缺陷的软件，Richard 长期以来一直认为，不能提供软件源代码的决定是人类犯的极大的错误，这是一个关于自由和代码自由的讨论，GPL 被设计为保护自由的强大且重要的许可，但是这也不是我今天要讲的故事。

我今天要分享的是另外一个故事，见演示文稿中的大象，类似于盲人摸象，人们往往只能接触到开源的一部分，就试图去描述整体的开源，我今天要分享的也只是局部，一个特别的故事，当然这个故事在现实中正在真实的发生。我要讲述的是一个关于全球协作的故事，这些协作对于我们这个星球上至关重要资源的使用，起着关键的优化作用，这个故事告诉我们，那些我们最为基础的系统是如何工作的。我在想，今天所分享的内容对于在座的大多数，听完之后，会了解全球协作的开源故事背后的强大和威胁，以及这个系统是如何运转的知识，开源对于我们这个星球是多么宝贵的资源，尤其是在人类的危机时刻。

这个故事并不是我自己想要的，或者说是杜撰的，而是真实的发生过的。这里举一个Linux基金会的一些数据，给大家形成一个初步的印象。或许大家一提开源，头脑中显示的就是几个人在周末的车库里吃着比萨，写着代码的样子，其实不是的，真实的开源是公司之间的协作，商业公司为了开发项目投入了相当的资源，以下数据来自于Linux基金会2022年的年度报告。

• 827，000名开发者为开源做出了贡献，比去年上升了12%；
• 全球共有17，000家公司为Linux基金会旗下项目有参与；当你参加Linux基金会的日常会议时，你就明白参与者不止美国人，而是跨文化的来自全球各地的参与者；
• 平均每周发布5200行代码，比去年上升了13%；
• 如果只考虑全球的平均工资的话，这些代码需话费260亿美元；
• 项目的构建达到了320万次，这对于开发者来说是一个相当大的数字了。

这是迄今为止世界上规模最大的全球分布式工程劳动力，这个数量级是前所未有的。我们每天的工作和生活都得依赖于他们构建和维护的软件。例如我们现在所进行的在线会议，就依赖于Linux和他们所构建的开源程序，我们这个世界的每个政府机构都在使用开源软件，所有的这些并非我个人臆想，而是当下正在发生的，而且也是其它正在运行的程序也是在这个全球协作的环境中产生的。

商业公司做这些是为哪般？

让我们从一个故事开始，一位年轻的女士被安排做开源相关工作，她的同事告诉她，公司总是让女士们做一些慈善的工作。这具有非常的典型，人们惯性的认为，开源是一件善事！他们这么做是出于“开明的自利”，我把这称为“共享经济学”。想想看，当年我们需要道路、桥梁等基础设施时，资源并不足以让每个人各建各的，于是大家合力修建共用设施——从卡车挡泥板宽度到路网标准，都曾长期诉讼，但最终成型，因为企业需要道路来开展自己的业务。

基础设施与独特的商业差异化价值之间有清晰分界。对操作系统也是如此。IBM 曾同时维护 35 多个操作系统，客户却根本不关心操作系统本身，而只关心跑在上面的应用。IBM 把最顶尖的人才分散在 35 条战线，而非聚焦单一系统。此时，微软在桌面端占据主导，IBM 要与之争锋，最佳方式就是让整个行业共同打磨一个开放操作系统——Linux。

后来微软也加入 Linux 基金会并签署专利承诺，如今已是 Linux 的重磅贡献者和受益者。这个故事说明：把“基础设施”与“客户真正关心的差异化”分开，把稀缺的天才开发者集中到后者，是最优资源配置。

当大家共同维护一套操作系统时，安全更新、漏洞修复的成本被分摊，开源从“可拿走的原材料”变成“共同维护的公共资源”。企业不再各起炉灶，而是直接回归上游项目，使用并影响主线代码——前提是项目方向符合自身需求。如此共享开发，成本远低于闭门重写；且全球能写操作系统内核的人才寥寥，企业 HR 也把“ upstream 参与”当成吸引顶尖工程师的卖点。

此外，这种模式直面“依赖与脆弱”。1979 年我入行时，公司都想“自成孤岛”；如今供应链交织，谁也离不开谁。疫情让所有人领教了断链之痛，而开源协作正是正视并管理这些依赖的方法：通过透明、共享、共治，把脆弱点摊在阳光下，一起解决。

速度与创新机会最终压倒了所有唱衰者——“代码来源不明”“律师反对”等声音曾络绎不绝，但开源不仅成了，而且比预期快得多。我想再次强调：企业投身开源，是出于开明的自利；只要围绕正确激励设计社区，大家就会自愿做“对的事”，结果证明，这些“对的事”也确实行得通。

如何构建参与的架构？如何建立信任？

那么，你如何构建“参与架构”（architecture of participation）？这是蒂姆·奥莱利（Tim O’Reilly）早在开源旅程初期就提出的金句：搭一个框架，把人们聚到一起，并让他们在其中成功——这件事绝不简单。而它的根基只有两个字：信任。如果参与者担心日后会被“坑”，担心别人占便宜，就没人愿意加入。因此，你必须在协作环境里内置“中立”与“完全透明”。

1. 中立：用“老”许可证
- 选择一条已获广泛采用的成熟开源许可证。
- 律师总能挑出“百万个理由”去改它，但社区把它当公共资产——不改。
- 举例：Apache 许可证人人认得；公司法务一听“Apache”就知道意味着什么。
- 若只改三个词，哪怕改得再好，也会立刻引发猜疑：“是不是有人想暗地占便宜？”
- 所以，用标准许可证=瞬间确立中立与公平。

2. 完全透明：不签 NDA
- 传统企业动辄让你签 NDA，连什么算机密都说不清；开源项目不签 NDA，也没有保密义务。
- 来自不同公司的开发者每天交换想法；若几年后有人指控“你当年那点子我用了”，根本没法自证清白。
- 因此，所有信息同时对所有人完全开放，任何人随时可查代码、邮件、会议记录—— secrecy zero，才能建立信任。

3. 不谈判、零定制
- 早年间启动一个项目要先花几个月让各家律师对齐合同、改条款；现在几小时就能上线。
- 只要有人甩出“自定义协议”要求单独谈，基本会被直接请出会议室——谁搞特殊，谁就可能占便宜。
- 标准许可证 + 标准治理文件（含责任限制条款）= 项目能“秒开”。

4. 责任限制是“命门”
- 英国正有一桩与比特币相关的案子，试图让开源贡献者承担连带责任；若得逞，灾难性的。
- “共享经济学”建立在许可证里的免责条款之上；公司才敢放心参与，而不用担心被反诉。

5. 全球参与：别动标准文本
- 一旦改英文原版，就得再翻译成几十种语言；各国参与者又得重新审。
- 用旧文档，大家早已翻好、审好、用惯，全球同条款，零摩擦。

6. 开发者民主：让干活的人说了算
- 我们常谈律师，却忽视真正写代码的人。决策权必须交给懂技术、亲手干活的开发者。
- 故事：一位白天在公司上班、夜里贡献 Linux 的程序员被问：“为何下班还敲代码？”
– 白天：贸易展下周开幕，领导逼我发半成品，bug 成堆；营销部拍脑袋要功能，技术不可行也得下周二上线。
– 夜里：Linux 社区只发“准备好”的代码，彼此尊重，追求优雅，可维护几十年。
– “你觉得哪边不正常？”

开源社区没空搞营销，只认技术真相；直白、粗鲁，却写出让自己骄傲并维护数十年的优雅代码——这正是它们成功的根本原因。

故事的启发

那么，这个故事跟你们有什么关系？——正如我先前所说，地球上最宝贵的资源之一，就是那些懂得我们彼此依赖的复杂系统如何运转的人。他们大多受雇于各大公司与机构，而当危机降临时，这些组织往往并不愿意把自家专家放出来救急；第一反应是怕担责任，而且没人替他们的参与算过一笔清晰的商业账。

让我举一例，每次想起都让我难过：我曾读《科学美国人》关于“深水地平线”（Deepwater Horizon）井喷的深度报道。文章提到，出事时只有几家原承包商在场，大家不信任他们——“井就是他们造的，我们真敢照他们的方案去堵吗？”政府介入后，却发现没人懂深水井长什么样、该怎么修。报道指出：那些原本可能懂行、能判断方案是否靠谱、能加速抢险的其他油服公司，全都往后缩，没人往前站。结果油柱喷了几个月。真正的专业知识不在政府，而在那些退避三舍的公司；他们不知怎样才能合法、安全地把懂井的人派出来。全球懂那口井的人，大概不超过几百，可他们都被锁在合同和顾虑里。

所以我想提醒你们：今天共建全球软件基础设施的企业协作生态，正是一份“参与架构”的样板间——它让稀缺专家无需逐家公司谈判、无需一次次谈责任限制、谈保密协议，就能即时汇聚、即时开工。如果能把这套“共享—免责—透明”机制复制到其他关键领域，下次再遇深水井、电网、疫苗或供应链危机时，我们就不必看着油喷几个月却束手无策。Ken，幻灯片内容就这些；现在我把屏幕共享关掉，很高兴继续聊你想深入的话题。

问答环节

问题：阿黛尔·斯图尔特（Adele Stewart）提了个问题：除了软件开源，还有没有其他“开放治理”系统？有没有已经成型或正在萌芽、遵循类似“贡献式协作”原则的例子？

最长的成熟样本——标准组织
- 它们历史悠久，但最初围绕“专利”而非“即时协作”设计，体系不同，可借鉴甚多。
- Linux Foundation 几年内就变成地球上最大的“标准机构”之一，正是把开源的开放协作方法套用到标准制定：统一条款、开发者秒级结社、快速形成规范社区。
- 开源许可证本身不太适合标准文档（规范≠代码），但“聚到一起”的那套做法已被标准界大量吸收。

老毛病——先谈 IP 再谈事
- 很多行业仍把“商业秘密、知识产权”谈判置于首位：不先把 IP 理清，就寸步难行。
- 我 1979 年进 IBM 时，做过一份 460 页的半导体联合开发协议，连人员编制都写死；等签完字，技术规格已过时——如今“过时”不是几个月，而是发布当天就落后。

速度把优先级翻了个个儿
- 软件领域若因“有没有授权”而踌躇，窗口期瞬间关闭。
- 我常讲：开源是互联网泡沫唯一永久的受益者。泡沫前，大家担心“代码谁写的、有没有风险”；泡沫一来，最大风险变成错过机会，其他顾虑顿时失色。
- 泡沫破了，但“不用现成开源资源就赶不上”这一心态再也没扭回来。

结论
现有协作体（标准组织、科研联盟、行业共同体）都可作为“开放治理”雏形，只是必须把：
1. 时间轴——从“年”缩到“天”；
2. 优先级——从“先锁 IP”改成“先跑起来再合规”。

把这两件事扳过来，就能在更多领域复制“参与即贡献、贡献即互惠”的开源式治理。

问题：“算法专利的难易程度”到底会给开源生态带来什么影响？——这涉及在“商业秘密”与“开源快速迭代”之间如何权衡，也关系到“软件/算法难以获得专利”时，到底走保密还是走开放。你们很多人在做面向医疗的新型机器学习应用：预测算法、读 X 光、临床决策支持等等，市面上模型一大堆，该怎么选方向？

我先退一步，从软件史的源头说起，再回来看当下环境。

1. 1967 年“IBM 解绑”——软件业诞生

   • 此前 IBM 买硬件送软件，没人关心 IP。
     
   • 美国司法部以“搭售”起诉 IBM，IBM 索性把软件拆出来单独标价，软件产业由此出现。
     
   • 当时共识：软件＝数学＝算法，不能专利；商标只管品牌，剩给行业的只有“商业秘密 + 版权”。
     
   • 连“目标代码是否受版权保护”都要打官司（Apple v. Franklin 等），IBM 反而乐见其成：轻量级版权即可，别让第三方靠代码卡我客户脖子。

2. 源码保密时代与斯托曼的反击

   • 厂商策略：只给二进制，源码留作“支持锁”；连界面截图都被宣称为商业秘密。
     
   • Richard Stallman 正是在“源码被收回”的刺激下发起自由软件运动——“先给我源码，否则我修不了 bug”。
     
   • 时至今日，保密逻辑已大面积瓦解：客户要的是功能与互操作性，不是神秘代码；系统必须即插即用，封闭反而寸步难行。

3. 版权 → 相对温和

   • 几十年看下来，软件版权诉讼极少，因为版权只保护“表达”而非功能，绕开容易。

4. 专利 → 律师的盛宴，产业的泥潭

   • 1980-2014 年算法/软件专利闸门大开，规则却前后矛盾、边界模糊。
     
   • 受益者：私募股权（PE）——低价收购成捆专利，养“诉讼工厂”赚钱（Unified Patent 的报告显示 PE 资金占比惊人）。
     
   • 典型困境：完成同一件任务可能有 50 种算法，业界最终只用一种；偏偏有人拿到这条“通行路径”的专利，就能威胁整个代码库重写。
     
   • 对基础设施层：算法专利 = 高额摩擦；对真正差异化技术：专利或许合理。
     

5. 医疗 ML 的现状与趋势

   • 纯算法层面：Alice/Mayo 判例后，抽象预测模型很难拿到专利（尤其仅涉及数学、统计步骤）。
     
   • 落地到“具体医疗装置或诊疗流程”——例如特定 CT 机图像增强 + 模型训练 + 剂量优化——则仍可能获得相对稳固的专利，但审查重点放在“如何与硬件协同、产生新的技术效果”，而非单纯算法。
     
   • 开源 VS 保密：
     – 若核心壁垒是数据质量、临床验证、监管合规，走开源（MIT、Apache 2.0 等）可快速吸引医院、器械商合作，形成事实标准；
     – 若确有硬件级创新（新型探测器、造影剂、激光调制），可针对“装置/方法”申请专利，同时把纯软件实现以开源形式发布，既保留差异化又避免专利地雷。
     
   • 速度窗口：医疗 AI 监管路径（FDA、CE、NMPA）迭代极快，错过首批证 = 错过市场，过度纠结专利而延迟验证、延迟开源，反而易被竞品抢先。

6. 平衡策略

   • 基础设施层（通用模型框架、数据格式、训练流水线）→ 开源 + 社区治理，降低全行业摩擦；
     
   • 差异化层（专有传感器、靶向造影剂、个体化治疗硬件）→ 专利/商业秘密组合，保护真正技术创新；
     
   • 算法专利风险缓解：
     – 公开防御性披露（Defensive Publication），阻止他人专利圈地；
     – 加入 OIN、LOT Network 等专利互保组织；
     – 使用宽松开源许可证（Apache 2.0、GPL-3.0 的专利 retaliation 条款）（注：原文可能有误，GPL-3.0 有专利报复条款，但 Apache 2.0 也有明确的专利授权条款。）
     – 对核心算法做多实现、多路径备份，确保一旦某条路径被专利卡死，可快速切换到替代方案。

简言之：
- 纯算法越来越难以获得强而稳定的专利，试图靠保密又会被开源生态甩在身后；
- 真正可专利的是“算法 + 具体医疗硬件/流程”所形成的新技术效果；
- 把基础设施捐给开源社区，把硬件级差异化留在专利里，再配合防御性披露和专利互保，就是当下最主流的权衡路径。

问题：这个问题来自我们知识产权办公室的Monica Jang： “我很喜欢 do-cracy 这个概念。在一所高度行政化、比如与HMS（哈佛医学院）关联的医院里，你觉得该怎样推进这样的使命？”

—— 咱们应该一起吃个午饭，我能给你讲一箩筐。听起来可能跑题，其实完全切题：

1. 先看清“会议室里的操作系统人”
   谈技术决策时，总有几个人全程沉默——他们脑子里在跑一台“操作系统”：你把开发流程一问，他们就开始逐层调度、寻址、上下文切换。可传统会议不等他们，十五个不懂操作系统的人已经把话题岔到五十个方向去了。

2. 让“代码先行”代替“口才优先”
   开源社区很少靠线下脑暴，而是“code first”：

   • 你先写，再提交评审；
     
   • 不会有人靠语速、职级或PPT美工占上风；
     
   • 哪怕初版粗糙，也是真实可运行的东西。

3. 把医院行政流程拆成“可编译模块”

   • 别先写460页发展规划，先拿一个小流程（比如伦理审查表单、数据采集脚本）写成“可运行原型”；
     
   • 扔到内部GitLab，让麻醉科、放射科、IT合规部各自提PR（Pull Request）；
     
   • 每行修改留痕、可回滚——行政人员也能看见“谁在哪个commit里改了哪句条款”，比Word修订模式更透明。

4. 用“最小可合并行政指令”取代“完美终稿”
   医院怕出错？设定短迭代：两周一个“最小可用政策块”，先上线、再迭代。代码review里能@法务、@伦理、@数据安全，各方并行审，而不是串行排队等签字。

5. 给沉默的“操作系统人”异步发言权

   • 重要决策先开issue，静候48小时，让内向专家书面留言；
     
   • 再开同步会，会上只读总结+快速拍板——防止“嗓门大”碾压“技术深”。

一句话：让行政流程像代码一样被版本化、被测试、被持续集成。先写“hello world”级别的医院治理脚本，跑通后再加功能——这比连开十轮PPT汇报更能推进使命。

提问来自 Gergana Savova： “您能否再深挖一下 Coinbase（应为 Tulip Trading）那起诉讼？一旦败诉，对开源社区可能带来什么具体后果？”

——没错，大家现在最担心的就是Tulip Trading 案（别被名字骗了，背后资金实力雄厚）。这不是同类案件的第一起，却是“砸钱最多”的一次。开源领域历来诉讼极少：当年 GPL 系列案我们大获全胜，也出现过几起专利索赔，但数量仍算凤毛麟角。

关键风险点：

1. 个人开发者
   很多顶级开发者无偿贡献；他们付不起律师费，也指望许可证里的免责条款保护自己。如果法院突然说“你提交一行代码就得为整盘代码负责”，最优秀的那批人会率先退出。

2. 企业参与者
   一旦判例把“无限连带责任”扣到最大赞助商头上，项目维护者会瞬间作鸟兽散——“ parade of horribles（灾难大游行）”场景不难想象：

   • 大公司法务立即喊停新贡献；
     
   • 已发布代码被要求召回或重签免责；
     
   • 社区 fork 成无数“闭源孤岛”。

3. 免责声明被首次挑战
   Apache、MIT、GPL 里的“NO WARRANTY / 有限责任”条款过去从未被实质挑战，大家也就默认安全。若 Tulip Trading 案确立“人人对自己提交的每一比特永久负责”，共享经济学基础将被连根拔起。

4. 诉讼生意链
   真到了“署名=无限赔”那一天，PE 基金（私募股权）会批量收购旧专利+旧 commit，专门找高市值公司“敲竹杠”——和解费成了唯一目标，技术迭代反而停滞。

5. 法官的“技术理解”缺口
   外界很容易从朴素正义观出发：
   “你写的你就该负责！”
   但若真把传统商品责任逻辑套在开源协作上，全球基础设施可能一夜退回到 1990 年代的封闭许可证时代。

所以，我确实担心。过往不少看似凶险的案子最终都以“合理方式”和解，希望本次法官也能花时间搞懂生态逻辑。否则，一旦打开“人人无限责任”的潘多拉盒子，开源共享将迅速终结，那会是整个技术界的悲剧。

问题

关于作者

Karen Copenhaver 是一位知识产权律师，因其在开源许可和商业模式方面的工作而闻名。Copenhaver 是 Linux 基金会的法律顾问，她的指导用于支持大型企业内部采用 Linux 和开源技术。

关于译者

「开源之道」·适兕

「发现开源三部曲」（《开源之迷》，《开源之道》《开源之思》。）、《开源之史》作者，「开源之道：致力于开源相关思想、知识和价值的探究、推动」主创，Linux基金会亚太区开源布道者，TODO Ambassadors & OSPOlogyLive China Organizer，OSPO Group 联合发起人。

「开源之道」·窄廊

来自于大语言模型的 Chat，如DeepSeek R1、Gemini 2.0 Flash thinking expermental、ChatGPT 4o、Grok3、甚至整合类应用 Monica等， 「开源之道」·窄廊 负责对话、提出问题、对回答进行反馈等操作。