开源法律、政策与实践（第2版）

版权信息

书名：开源法律、政策与实践（第2版）

ISBN：978-7-115-66368-9

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版  权

编  著 [英] 阿曼达·布罗克（Amanda Brock）

译    木兰开源社区

责任编辑 秦 健

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

版 权 声 明

Open Source Law, Policy and Practice, Second Edition was originally published in English in 2022. This translation is published by arrangement with Oxford University Press. Posts & Telecom Press, Co. LTD. is solely responsible for this translation from the original work and Oxford University Press shall have no liability for any errors, omissions or inaccuracies or ambiguities in such translation or for any losses caused by reliance thereon.

本书中文简体字版由Oxford University Press授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。

版权所有，侵权必究。

内容提要

本书深入探讨了开源软件涉及的法律、政策及实践等内容。首先，本书从哲学、方法论、商业视角及社区和治理等不同维度对开源进行了阐释；其次，介绍了与开源相关的版权、合同和许可证、供应链、软件物料清单、审计、估价和交易、商标、专利、开源软件标准、出口管制及安全、实践及治理等议题；再次，从经济学、开源模式和应用等方面说明开源开发的商业模式；最后，介绍了与开源相关的技术和产品，如区块链、开源硬件等内容。

本书适合对开源感兴趣的读者、IT从业人员以及致力于开源健康发展的人士阅读和参考。

中文版序

当我向我曾经的教授（本书第1版的编辑）提出有必要出版第2版时，他告诉我：“那就去编写吧。”本书便是那次“编写”的成果。如今看到它被译成中文并正式出版，我深感欣喜。

我的开源职业生涯始于2008年初，当时我以总法律顾问的身份加入了Ubuntu操作系统的商业赞助商Canonical公司。最初，我只是签订了一份为期3个月的合同，负责搭建Canonical公司的法律体系，但这一工作最终延续了5年，其间我领导这家在开源领域非常重要的公司的全球法律事务。坦率地说，我在这里找到了一群志同道合的人，并深深爱上了开源的价值观——协作、贡献以及技术的民主化。

在Canonical公司工作期间，我结识了许多开源工程师与开发者，也认识了全球开源法律界的同行。我们人数不多，彼此熟悉，以协作的方式共事，共享治理经验，并共同推进法律项目。这种氛围充分体现了开源精神，在法律界实属罕见。

理解开源法律问题的细节至关重要。准确把握这些细节，是开源持续成功的关键。倘若缺乏这种理解，开源可能会昙花一现，因为对开源许可证的违背会引发滥用、“伪开源”等问题，最终导致开源走向失败，并使采用率下降。

特别感谢Andrew Katz、Carlo Piano和Malcolm Bain。在我初涉开源法律事务时，他们不遗余力地指导我，帮助我理解其中的各种挑战。

自我们着手编写第2版以来，世界已发生了巨变：数字化不仅向平台化与云化演进，开源自身也在不断进步。如今，超过90%的软件依赖开源。开源的普及速度之快，得益于GitHub、GitLab等协作平台的兴起。这些平台不仅促进了开发者之间的协作，还为开源软件包的大规模采用铺平了道路：在当今高度数字化的世界中，工程师们可以直接将开源组件引入其所在组织，只需遵循标准的开源许可证，而无须再经过法务、财务或采购的层层审批——正是这些审批流程在过去许多年里阻碍了开源在企业中的广泛应用。这种大规模采用反过来又催生了事实上的行业标准。

开源关乎人与代码。从最简明的法律定义来看，开源指的是源代码依据符合“开源定义”的许可证公开共享。代码需要许可证才能实现共享——这种共享应当是自由流动的，其许可条款必须允许任何人出于任何目的（在法律允许范围内）使用该代码，不得施加任何商业性、伦理性或国家层面的限制。围绕软件的知识产权许可对开源至关重要，而法律层面的理解在其中发挥了举足轻重的作用。

开源的采用速度迅猛，但遗憾的是，人们对它的理解未能与之同步。误解与“伪开源”现象正在损害开源生态，而这些乱象之所以能够发生，正是因为开源本身的复杂性。要确保开源软件项目的成功，就必须重视其治理结构和技术规范，并对开源的诸多细微之处及其维护方式进行精心管理。这种细致入微的关注，对于实现良好治理的开源项目以及保障其未来的可持续发展，都至关重要。

开源的成功远不止于满足法律层面的要求，还必须重视最佳实践、社区建设，以及如何有效接纳贡献，以确保项目的良好治理。用户也应回馈社区——这不仅能帮助他们提升技能、扩大影响力，也有助于保障项目的长期存续。

开源本身并不是一种商业模式，这与专有软件不同：专有软件天然包含成本结构和收入来源。若要将开源成果商业化，就必须在开源许可之外另行构建配套的商业模式。然而，开源成果的商业化之路往往充满挑战，因为开源本质上意味着将你的创新成果无偿提供给竞争对手使用。本书不仅探讨了开源所面临的法律挑战，也深入剖析了其商业化路径及企业内部对开源的管理策略。

在过去十年中，我们见证了开源以前所未有的速度被广泛采用，如今它已成为数字基础设施的常态，并已步入主流。

开源构成了我们数字经济和公共部门的基础设施。这一基础设施是国际协作社区数十年持续贡献与服务的结晶——他们将成果无偿赠予全世界，以增进人类共同福祉。今天，开源所体现的协作式创新与迭代开发模式，不仅对软件至关重要，也日益成为人工智能发展的核心动力。我们将在第3版中探讨与人工智能相关的法律议题……

对我来说，编写本书是我所热爱的工作。本书英文版篇幅超过600页，而中文版的内容更加精炼，令我十分钦佩。我衷心感谢所有辛勤付出的翻译和审校人员，正是他们的努力促成了本书中文版的问世。我将于2025年12月在COSCon大会期间赴北京参加新书发布活动。

Amanda Brock

2025年伦敦

序  言

开源是当今世界创新驱动的重要力量之一。实际上，开源不仅是一种促进跨部门、跨行业个人协作的社会运动，也是推动创新的持久模式。在这种模式下，软件的开发不再局限于企业的孤岛，因为这种模式存在创新产出的上限。开源模式通过汇聚不同背景和经验的人，共同创造出简洁而实用的代码，这些代码的产出是传统模式难以实现的。

开源模式最初主要吸引了西欧和美国的追随者，大约在2000年，日本和韩国的公司与个人开发者开始积极参与开源软件项目。在过去的8到10年中，中国的公司及个人开发者也开始加入这一行列。事实上，随着对开源重要性的认识不断加深，全球各地的参与者都加入了由Apache软件基金会、Eclipse基金会、Linux基金会等组织管理的开源软件项目。这些组织都是为提供专业的项目管理，并确保重要代码有效发布而出现的。这些组织发布的代码可以自由使用，使用户能够以低成本的方式生产创新产品。

随着开源软件在信息技术、电信、电子、移动通信、计算、交通、能源、金融服务、金融科技、大数据、物联网等领域的不断发展和普及，各领域对精通开源法律知识的顾问的需求变得十分迫切。在开源软件项目社区的技术合作达到前所未有的水平时，版权、商标和专利方面的律师也一直在由欧洲自由软件基金会、Linux基金会和开放发明网络等组织管理与维护的网络中工作。他们通过《法律技术与社会》（前身为《自由与开源软件法律评论》）等杂志，分享优秀实践案例，不断增强整个开源社区的法律能力。

开源软件项目，如本书探讨的软件项目数据交换（Software Project Data Exchange，SPDX）和OpenChain，已经成为ISO发布的标准。这些标准旨在实现内容管理和流程规范，确保版权合规成为综合治理计划的一部分。随着版权合规需求逐渐旺盛，软件合规工具公司开始出现，以进一步支持积极的版权合规工作。

在专利领域，开放发明网络管理着一个由全球最大、最重要的专利持有公司组成的3700人的网络。该网络不断发展壮大，致力于交叉许可彼此在Linux操作系统核心功能和邻近开源功能上的专利，并在此过程中预先承担专利侵权诉讼。此外，IBM公司、微软公司和Linux基金会已与开放发明网络联合成立了统一专利开源区，旨在降低专利主张实体给更广泛的开源社区带来的专利风险。

在开源技术和法律界中，协作是一个反复出现的主题。个人和组织聚集在一起，共同创造出前所未有的新事物和创新。广大律师认识到有必要建立一个社区来保护和培育作为开源技术开发基础的社会运动的完整性。他们通力合作，在Linux操作系统和开源项目功能的核心部分实现版权合规和专利风险降低，并慷慨地分享自己的知识。

归根结底，开源关乎机会和义务。整个开源社区都清楚地认识到，要想通过参与开源项目来享受合作带来的好处，就必须承担遵守法律行为准则和社会规范的义务。

Keith Bergelt

开放发明网络首席执行官

作者简介

Amanda Brock

英国开放技术（包括开源软件、开放硬件和开放数据）商业组织OpenUK首席执行官，开放源代码促进会董事会成员，英国内阁办公室开放标准委员会成员，英国计算机学会首届影响力委员会成员，KDE、Planet Crust、可持续数字基础设施联盟和Mimoto咨询委员会成员，Creative Crieff和GeekZone慈善机构理事，开放发明网络欧洲代表。Amanda在2022年获得了英国“法律界女性、影响力和权力”终身成就奖，并在2021年和2022年被《计算机周刊》列入“最具影响力女性”和“英国科技领袖”长名单。作为一名拥有25年工作经验的律师，她曾担任联合国技术创新实验室开源和知识产权咨询小组主席、OASIS开放项目和英国政府能源部门数字化特别工作组咨询委员会成员。同时，她还为Beamery和Everseen等多家初创公司提供咨询服务。Amanda拥有格拉斯哥大学、纽约大学、伦敦大学玛丽女王学院和韦斯特菲尔德学院的法学学位，是英国第一批学习互联网法的学生之一。她拥有25年的法律工作经验，其中近20年在不同行业的公司工作，专注于技术领域。自1999年起，她成为互联网服务提供商Freeserve公司的首位律师，并作为团队的一员推动了该公司的上市。她于早期加入Canonical公司，担任总法律顾问，从2008年开始组建并领导全球法律团队。Amanda经常在国际会议中发表主题演讲，并定期为科技媒体撰写文章。

Malcolm Bain

英语律师和西班牙语律师，常驻巴塞罗那。过去的20年中，他一直从事信息和通信技术方面的法律工作，专注于开源和开放内容项目。他曾为大学、政府、行业和初创公司提供知识产权战略、管理和许可方面的咨询，并参加了许多关于开源和开放数据法律的会议与研讨会。他是欧洲自由软件基金会和加泰罗尼亚自由软件商业协会成员。

Miriam Belhausen

鸿鹄律师事务所合伙人。专门从事技术、软件、数字媒体、版权、数据和数据保护法方面的工作，尤其关注开源软件、开放数据和开放硬件的合作开发。她曾是欧洲自由软件基金会法律网络顾问委员会成员，并参与了德国多起开源软件诉讼案。在日常工作中，她经常与客户合作制订开源许可合规计划，并就与开源相关的问题提供建议。

Knut Blind

拥有加拿大布洛克大学学士学位和弗莱堡大学经济学博士学位。1996年，他加入了弗劳恩霍夫协会。目前，他是位于德国卡尔斯鲁厄的弗劳恩霍夫系统和创新研究所“创新和监管”部门的负责人。2006年4月，他被任命为柏林工业大学经济与管理学院的创新经济学教授。2008年至2016年，他还担任了鹿特丹伊拉斯姆斯大学管理学院的标准化教授。

Mirko Böhm

KDE、开放发明网络、开放源代码促进会等组织管理的多个项目的开源软件贡献者。他是柏林工业大学开源软件客座讲师和研究员，Qt认证专家及培训师，并且是开放论坛学院研究员。他在梅赛德斯-奔驰公司领导软件工程项目，并在那里应用了其作为企业家、企业经理和软件开发人员的丰富经验。

Michael Cheng

Dapper Labs公司副总裁，负责企业的并购和知识产权事务。在此之前，Michael是Meta（原Facebook）公司的产品经理，代表公司处理开源领域的投资事宜。他曾是Linux基金会董事会成员、ML Commons财务主管、机密计算联盟董事会成员、城市计算基金会董事会成员、OpenChain董事会成员、开放发明网络技术咨询委员会成员和Magma Foundation董事会主席。

Pamela S. Chestek

北卡罗来纳州罗利市切斯特克法律事务所的负责人。她为创意社区提供开源软件、品牌和营销事务方面的咨询服务。在重返私人执业前，她曾在鞋类、服装和高科技公司担任内勤职位，并担任兼职法学教授，讲授与商标法和不正当竞争法相关的课程。她在美国加利福尼亚州、康涅狄格州、哥伦比亚特区、马萨诸塞州、纽约州和北卡罗来纳州获得执业许可，并获得了北卡罗来纳州法律专业化委员会的商标法认证。

Mishi Choudhary

技术律师。《开放》杂志赞誉她为“自由开放互联网的新兴法律监护人”。她是纽约软件自由法律中心法律总监及莫格伦律师事务所合伙人。她曾担任世界上许多重要自由软件开发商和非营利分销商的主要法律代表。她为世界各地的科技初创公司及成熟企业提供开源软件授权和战略方面的咨询服务。2010年，她创立了SFLC.In。在她的领导下，SFLC.In已成为代表印度互联网用户和自由软件开发者权利的首要非营利组织。

Shane Coughlan

通信、安全和业务发展方面的专家。他的专业成就包括通过OpenChain项目建立世界上最大的开源治理社区，带领授权团队将开放发明网络提升为历史上最大的专利非侵犯性社区，并建立了首个全球开源法律专家网络。他是第一份致力于介绍开源法律的期刊的创刊人和第一本介绍开源法律的图书的创作者。目前，他领导着OpenChain项目，并担任World Mobile和Asylum Labs的顾问。

Toby Crick

Bristows律师事务所技术部门合伙人，负责商业、技术和外包协议的咨询与谈判事务。他尤其擅长与客户合作，帮助他们管理和构建复杂的交易；他在数字化转型项目方面的工作及在受监管环境中管理开源软件的经验得到广泛认可。他是英国计算机和法律协会理事，并在ITechLaw、伦敦大学学院（在那里他教授开源软件）和伦敦大学玛丽女王学院等组织教授信息技术、电子商务、云计算、敏捷软件开发和外包等课程。

Richard Fontana

Red Hat公司高级商务法律顾问。他专门处理与软件开发有关的法律事务，重点关注开源方向。他曾任开放源代码促进会董事会董事。Richard之前是惠普公司云计算和开源高级总监及副总法律顾问，也是软件自由法律中心法律顾问。在职业生涯早期，他曾从事知识产权和反垄断法方面的工作。他毕业于密歇根大学法学院（获法学博士学位）、耶鲁大学（获计算机科学硕士学位）和卫斯理安大学（获历史文学学士学位）。

Ross Gardler

在开源软件领域工作近25年，参与了众多项目，重点是建立健康的协作环境，为多个领域的开放创新创造机会。他曾担任Apache软件基金会主席多年，目前是OASIS Open董事会成员，负责推动快速的开源软件创新，并通过缓慢但更加精确的标准流程确保稳定的互操作性。目前他在微软公司工作，致力于促进Azure中Linux操作系统工作负载的增长。

Andrew Katz

英国执业律师，专注于开放技术领域的工作超过25年。他在泰晤士河谷的Moorcrofts律师事务所领导技术团队，曾为世界各地的企业、政府、非政府组织和基金会提供开放许可与治理方面的咨询服务。他是欧洲核子研究中心开放硬件许可证的共同作者，同时也是伦敦大学玛丽女王学院和谢菲尔德大学访问研究员。他经常发表演讲，并撰写了许多关于开放技术的文章。他是欧盟委员会“2021年开源软件和硬件对欧盟经济影响”报告中开放硬件部分的主要作者。他曾根据GPL编写并发布软件。

Jilayne Lovejoy

美国律师和社区领袖，曾在多个与开源相关的社区中担任内部职务。作为SPDX法律团队的负责人之一，她主要负责维护SPDX许可列表，并与其他合著者共同撰写了《FINOS开源许可证合规手册》，这是一本人机可读的开放许可合规手册。目前，她是Red Hat公司的产品顾问。在此之前，她曾担任Canonical公司的法律顾问和ARM公司的首席开源顾问，其间推动了与开源相关的流程改进，包括组建ARM开源办公室并担任主席。

P. McCoy Smith

美国俄勒冈州波特兰市Lex Pan Law公司（一家提供全面服务的技术和知识产权服务律师事务所）和Opsequio公司（一家开源咨询公司）的创始律师。他曾在一家财富50强的跨国科技公司担任了20年的知识产权律师，其间负责管理开源法律政策。此前，他在纽约市的一家律师事务所担任了8年的专利诉讼律师和检察官，并在美国专利及商标局担任了3年的专利审查员。他毕业于科罗拉多州立大学（获荣誉工程博士学位）、约翰斯·霍普金斯大学（获文学硕士学位）和弗吉尼亚大学（获法律学士学位）。他还担任《开放法律、技术与社会》杂志的编委。他拥有美国俄勒冈州、加利福尼亚州和纽约州的执业律师资格，并可在美国专利及商标局和加拿大知识产权局申请专利与商标。

Iain G. Mitchell KC

苏格兰和英国律师协会成员，在《钱伯斯年鉴》和《法律500强》的商业诉讼、知识产权和信息技术法领域排名领先。他是苏格兰计算机和法律学会主席，英国律师协会信息技术委员会专家，以及该委员会监控工作组的前任主席。他是英格兰和威尔士律师协会信息技术小组成员、OpenUK法律小组成员，以及明斯特大学信息技术法的荣誉讲师。他是《开放法律、技术与社会》杂志的联合编辑。

Cristian Parrino

一位技术人员出身的社会企业家和可持续发展顾问。他是OpenUK首席可持续发展官，专注于开放技术与社会价值的交叉应用。他还担任儿童癌症慈善机构Azaylia基金会首席执行官，以及公民科学慈善机构Earthwatch Europe和青年气候行动慈善机构InterClimate Network董事会理事。此前，他是初创公司Greengame联合创始人兼首席执行官，并曾任Canonical公司移动和在线服务副总裁。

Carlo Piana

意大利执业律师，开源软件倡导者。他曾担任欧洲自由软件基金会总法律顾问，并与Samba团队一起代表该基金会参与了多起重要的反垄断案件，以确保个人计算机和互联网市场的互操作性自由。2022年，他当选为开放源代码促进会董事会成员，并成为Eclipse Oniro工作组指导委员会成员。他还参与了意大利第一起被报道的GPL执行案件。他是Array（一家精品IT律师事务所）创始成员，并且是OpenChain合伙人。

Mark Radcliffe

欧华律师事务所硅谷办公室高级合伙人，区块链和数字资产部门联席合伙人。他在开源事务方面提供了超过20年的咨询服务，涵盖从双重许可模式的开发到Sun Microsystems Solaris操作系统的开源化等项目，并无偿担任开源计划和Apache软件基金会的外部总法律顾问。他把这些经验应用到区块链和NFT问题上。他还撰写了许多关于开源法律问题的文章，并做了大量演讲。

Nithya A. Ruff

亚马逊开源项目办公室负责人。她在亚马逊内部推动开源文化的发展和协调，并与外部社区开展合作。在加入亚马逊之前，她创建并发展了康卡斯特公司和西部数据公司的开源项目办公室。在过去的5年中，Nithya一直是Linux基金会董事会成员，并在2019年当选该基金会董事会主席。她积极践行Linux基金会的使命，即构建基于开放协作的可持续生态系统。她热衷于为技术领域的新人和多元化的人才打开大门，并经常就此发表演讲和撰写文章。她毕业于北达科他州立大学，获得计算机科学硕士学位，并在罗切斯特大学西蒙商学院获得工商管理硕士学位。

Karen Sandler

律师，专注于道德技术的非营利组织软件自由保护协会（Software Freedom Conservancy，SFC）的执行董事。她因倡导软件自由是一个生死攸关的问题而被称为“机器人律师”。她参与共同制订了一项名为Outreachy的实习计划，旨在帮助那些科技领域的弱势群体。她是哥伦比亚大学法学院的法律讲师。在加入SFC之前，Karen是GNOME基金会的执行董事。在此之前，她是软件自由法律中心的总法律顾问。她在哥伦比亚大学法学院获得了法学博士学位。

Charles-H Schulz

法国技术专家，自由软件和开放标准的倡导者。作为OpenOffice.org项目的长期贡献者，他帮助欧洲从仅有少数几个社区发展成为拥有100多个不同规模的社区和团队。他还通过自己联合创建的Ars Aperta公司为OpenDocument Format标准的开发和采用作出贡献。作为OASIS联盟的前董事，他参与了欧洲层面的各种数字公共政策辩论。他是Document基金会（LibreOff ice项目的总部）的创始成员和前董事之一。他在政府网络安全领域工作多年，现为开放信息安全基金会董事会成员，同时也是XCP-ng管理程序的主要开发商Vates公司的首席战略官。

Kate Stewart

SPDX创始人之一，现任规范协调员。加入Linux基金会后，她启动了ELISA和Zephyr项目，并为其他嵌入式项目提供支持。她在软件行业拥有超过30年的工作经验，曾在软件开发、架构和产品管理方面担任多种职务，主要工作集中在工具和嵌入式生态系统方面，并与国际团队合作。她通过与安全、安保和许可合规社区的合作，积极推动嵌入式开源项目的发展。

Nikolaus Thumm

博士，瑞士苏黎世联邦理工学院董事会高级科学顾问和柏林工业大学副教授。他曾在欧盟委员会工作，负责制订有关标准化、标准必要专利、许可和开源的工作计划。2013年以前，他是欧洲专利局的首席经济学家。他曾担任联合国保护和实施知识产权促进投资咨询小组的主席。他领导了多项国际研究活动，并在标准化、专利和知识产权保护领域发表了多部著作。

Ian Walden

博士，伦敦大学玛丽女王学院信息与通信法教授和商业法研究中心主任。他的著作包括《媒体法律与实践》（2009年）、《自由与开源软件》（2013年）、《计算机犯罪和数字调查 第2版》（2016年）和《电信法律法规 第5版》（2018年）。他曾担任得克萨斯大学、墨尔本大学和鲁汶大学的客座教授。他曾参与世界银行、欧盟委员会、欧洲委员会、英联邦等组织的法律改革项目。Ian是欧盟委员会的“国家级专家”（1995—1996年），互联网观察基金会董事会成员和理事（2004—2009年），英国儿童互联网安全委员会执行委员会成员（2010—2012年），新闻投诉委员会成员（2009—2014年），RUSI独立监督审查委员会成员（2014—2015年），电话付费服务管理局法规裁决委员会成员（2016—2021年），欧盟委员会支持适用GDPR专家组成员（2017—2021年）及泽西岛竞争监管局非执行委员会成员（2020年至今）。Ian是贝克·麦肯锡律师事务所的律师和顾问。Ian领导了伦敦大学玛丽女王学院的qLegal计划，并且是云法律项目的首席研究员。

Stephen Walli

Azure首席技术官办公室开源生态系统团队的首席项目经理。他在标准化和开源项目方面有超过30年的工作经验。他是Eclipse基金会董事会成员和Eclipse SDV工作组主席，并担任机密计算联盟（Linux基金会）主席。他还是约翰斯·霍普金斯大学的兼职教师，教授开源软件工程。同时，他还是IEEE开源软件项目治理推荐实践标准工作组主席。

木兰开源社区翻译工作组

组   长：杨丽蕴

副 组 长：王 伟  金耀辉  王 旭  王 庆  耿航航

翻译组成员：边思康  陈 行  丁 蔚  高 丰  辜凌云  李成双  李 鸣

      李智琪  刘冕宸  孙振华  王荷舒  王玉茂  夏小雅 于 昕

      张春阳  周子茗  朱效璋

审校组成员：卫剑钒 郁志强 黄子祎 适 兕 金 红 游 兰 曾 星

特别感谢（排名不分先后）

中国电子技术标准化研究院

北京大学

华东师范大学

上海交通大学

开放原子开源基金会

深圳市腾讯计算机系统有限公司

蚂蚁科技集团股份有限公司

英特尔亚太研发有限公司

北京抖音科技有限公司

开放数据中国

中国移动通信研究院

卫sir说（公众号）

稀际科技（北京）有限责任公司

X-lab开放实验室

上海白玉兰开源开放研究院

“源译识”开源翻译公益项目

香港理工大学

刘 硕

李欣博

陶 冶

倪嘉琦

缩略语

第1章 开源：哲学、方法论与商业——有态度地使用法律

作者：Ian Walden；译者：王旭；审校者：边思康

1.1 导言

软件占据了我们所知的信息与通信技术（Information and Communications Technology，ICT）产业的大部分。软件一般有两种形式——源代码与目标代码。源代码通常是计算机程序被编写时的样子，之后，它们被编译成计算机可以理解的目标代码，从而在处理器上执行。这些目标代码可能是和硬件彼此独立的，也可能直接集成在硬件中，后者也就是所谓的固件。从结构上说，不同时代的编程语言有不同的抽象层次。一般来说，软件是无法轻易地从目标代码再变回源代码的，这有效地限制了目标代码的可用之处（对于解释性语言，也可以对源代码进行混淆，也就是说，虽然计算机仍然可以执行，但是很难被人理解）。所以，“传统的”商业化专有软件以目标代码而非源代码的形式来分发，这使得其他人难以修改该软件。

自由与开源软件运动（统称为“开源”）颠覆了这种传统的行业模式，它允许用户访问源代码。对源代码的访问，有利于用户在未来对软件进行二次开发，包括修改已有代码和加入新代码，进而使得用户个人或公众从中受益成为可能。促进对软件的“开源”访问的人的动机是有很大差异的，既有政治、哲学与伦理方面的目的，也有可能是单纯的实用主义。在接纳并审视这些内容的同时，本书的编写立场尽量保持中立，以便把“开源”现象作为一种法律概念来理解和分析。

开源的核心事实，也是写作本书的依据，在于知识产权法，特别是版权法，构成了源代码控制权有效成立的先决条件。版权法是实现开放性目标的主要法律工具，尽管在软件供应链的不同环节中也可以通过一些私法来发挥作用。这种对版权法的依存关系引起了一些支持“开放”的哲学家的担忧，毕竟原本对自由与开源软件运动的一个初衷恰恰是要终结用以保护软件产权的版权制度[1]。

[1]　 Eben Moglen，“Anarchism Triumphant:Free Software and the Death of Copyright”，N. Elkin- Koren和N.W. Netanel编，The Commodification of Information。

本书探讨了开源现象的各种政策、法律和商业问题。我们的出发点是：“开源”是各种用户和社区的简称，它们之间的差异和相似之处同样巨大。共同点是依赖并使用法律和法律机制来管理他们编写、使用和分发的源代码。

本章主要讨论3个问题。首先，介绍本书探讨的主体——开源，以及与其相关的背景和后续各章要研究和分析的各个话题；其次，审视版权法与开源之间的关系，分别从理论和实践的角度寻找一致之处和矛盾点，以及那些在法律上尚不确定的地方；最后，研究诉诸私法来达到目的与使用公共法律（后称公法）制度的不同之处——有态度地使用法律。

1.2 软件的法律适用

在开始分析软件开发人员和社区如何使用开源之前，有必要根据知识产权法和更广泛的法律框架，从一般的角度考虑软件的法律适用问题。

开源支持者利用私法机制，即许可证〔许可证的法律性质可能是各种各样的，可以是合同，也可以是纯粹许可证（无管控许可），这将在第3章中进一步讨论〕[2]和合同，在版权、专利和合同法等既定公法框架内运作，以实现特定的预期结果。在本书讨论的范围中，“公法”的概念有别于国家与公民之间关系的传统概念，在这里，它包括管理法域内和法域之间人与人之间关系的法律制度[3]。这些制度不仅赋予私法机制法律效力和可执行性，而且直接干预以影响这些机制的使用，例如禁止某些做法，并对某些行为作出具有威慑性的规定。

[2]　 在本章中，我们以非特定的方式使用“许可证”这个术语。

[3]　 这包括监管和司法立法，以及国际和欧盟法律。

本书通篇强调了公法将如何对待某个特定行业实践（如开源社区的实践）存在的不确定性。这些不确定性包括：软件应被视为商品还是服务，什么构成“修改”，软件的使用受合同还是受裸许可的约束，以及该机制的结果是导致所有权的转移还是仅获得使用权。这些问题有时可以通过法律规定或司法解释得到解答，但常常会引起更多的疑问。私法文书本身可能会有意或无意地包含超出公法认可或可接受范围的条款，但没有受到质疑也没有执行过，或者有些条款会被不同的人或群体通过逻辑推断或价值观倾向来给出不同的解释[4]。总的来说，此类法律上的不确定性可能会对ICT行业的技术和商业创新与发展产生负面影响。因此，本书的目的之一是试图解决围绕开源的一些不确定性问题。

[4]　 M. Herman和J. Montague，“The Elephant in the Room: Patent Value and FOSS”。

在计算机技术发展的早期，软件是与硬件一起免费分发的，只有当软件从其运行的硬件中解放出来时，它才独立成为一种商品[5]。随着软件作为独立物品出现，知识产权法中的哪种制度最适合保护软件的问题便出现了。3种主要的可能性是：（1）专利法，因为它的出发点在于保护工商业；（2）版权法，因为软件本身是一种书面表达形式；（3）建立一些针对软件的独特特征的特殊制度[6]。此外，保密法和商业秘密法也被考虑到了（本章稍后探讨）。版权法最终赢得了这场争论，计算机程序被接受为“文学作品”的一种形式，尽管一些法域采用了一套独特的规则来解决涉及软件的某些独特问题。

[5]　 M. Schellekens，“Free and Open Source Software: An Answer to Commodification?”，L. Guibault和B. Hugenholtz编，The Future of the Public Domain: Identifying the Commons in Information Law。

[6]　 参见WIPO于1977年通过的Model Provisions on the Protection of Computer Software。

其实，什么是“软件”或“计算机程序”往往并不是那么明确[7]。如前所述，软件通常有两种表达形式——源代码和目标代码，后者是前者的“翻译”，但它们都是可被保护的主体。与其他法律领域一样，有些法域试图在法律中定义这一概念，有些法域将这一概念扩展到源代码和目标代码之外的其他主体，而另一些法域则将其留给法院，由法院根据已有法律的标准用法进行解释[8]，欧洲法院（European Court of Justice，ECJ）在SAS Institute Inc.诉World Programming LTD案中对该术语的范围进行了解释，认为“计算机程序”不包含程序的功能、编程语言或数据文件格式，尽管后两者本身也可能是受版权保护的作品。在不保护程序功能的情况下，法律限制了版权法的适用范围，支持将软件作为一种工具进行“开放”处理。虽然法院区分了计算机程序和编写计算机程序的编程语言，但后者现在通常也以计算机程序的形式出现，并且已经有许多开源编程语言，如Python和Ruby，它们本身就是根据开源许可证分发的[9]。

[7]　 在本章中，“软件”和“计算机程序”这两个术语将交叉使用。

[8]　 例如1988年的Copyright Designs and Patents Act （简称CDPA）。

[9]　 将源代码翻译成目标代码的编译器同样是软件，并且是由开源的编译器实现的，例如Open64。

随着软件行业不断发展和这些不确定性继续存在，软件开发人员倾向于依赖商业秘密法和合同法作为保护其劳动成果的首选机制。随着版权制度的明确和加强，从20世纪80年代中期到最近，软件行业一直依赖版权法和许可证作为管理其软件资产的主要手段。然而，版权法的限制让人们转而将专利法视为保护和利用其软件的一种替代策略。这些法律机制得到技术手段的加强，通过这些手段使权利所有人能够进一步控制其作品的使用。

从版权制度的运作来看，软件行业仍然存在法律上的不确定性：首先是版权法的一般不确定性，例如“使用例外”的范围；其次是将一般规则应用于软件的具体细节，例如软件可以被视为作品集、作品汇编或数据库；最后是一些源于软件行业的独特规则，例如反编译权和版权对应用程序接口（Application Programming Interface，API）的适用性[10]。在软件环境中，“什么行为构成了复制”这个问题给版权法带来了挑战，特别是在“非逐字的”复制方面。代码可以使用不同的编程语言编写，这就使得一个人可以实质上复制另一部作品的内在“结构、顺序和组织”或其呈现出的“外观和感觉”[11]，而无须复制其表达形式。在某些情况下，这种做法被认为构成侵权，而在另一些情况下，法院认为，思想和表达之间发生了合并，使主体无法被保护[12]。当前的行业发展也可能导致从依赖版权法和专利法转向依赖合同法和商业秘密法。云计算和软件即服务（Software as a Service，SaaS）成为常态，应用程序能够通过网络访问，这意味着服务提供商不再需要为用户提供他们使用的程序的源代码或目标代码（参见第9章）。

[10]　 参见Oracle America, Inc.诉Google, Inc.（2012）案。

[11]　 C. Millard，“Copyright in Information Technology and Data”。

[12]　 Millard，“Copyright in Information Technology and Data”。

关于计算机程序的专利问题，争论从未休止，美国和欧洲对这个问题的态度截然相反。由于大多数开源许可证来自对软件专利保护持自由态度的美国，这就导致这些许可证不得不越来越多地将时间和精力用于解决专利问题，以确保继续保持“开放”目标。与其他形式的知识产权相比，开源社区中的许多人更加反感专利。有些公共运动试图阻止或终止软件专利，但在版权保护方面并没有过类似的运动[13]。因此，在与开源相关的一些领域，例如标准化方面，有争议的辩论往往主要出于对专利的反对，而不是出于对版权的反对（参见第11章）。

[13]　 海盗党（多个国家都有名为海盗党的政党。另外，海盗也有盗版的含义。这些政党都倾向于极端的无政府主义。——译者注）一直在倡导大幅削减版权条款，而且是针对所有版权物的，并不仅仅是针对软件。但由于他们的提案涉及软件，因此Richard Stallman（自由软件基金会创始人）站出来反对这些提案，他赞成要么为自由软件保留更长的版权条款，要么设立软件相关的专门的权利，以确保GPL风格的Copyleft继续有效。

此外，关于版权领域的争议点还有技术本身作为控制软件使用和滥用的机制。技术保护措施（Technological Protection Measures，TPM），从“电子狗”到内容加密，乃至数字版权管理（Digital Rights Management，DRM）技术，随着软件行业的发展而出现。它们成为权利所有人手中日益强大的工具，用以阻止同样规模化、产业化发展的侵权行为。在1996年的《世界知识产权组织条约》中，这些技术得到国际版权法的承认和保护，并且在各国法律中相关的侵权经常可以构成刑事犯罪。而开源的支持者（特别是支持自由软件运动的人）一直尖锐批评TPM/DRM技术以及将这些技术用于限制最终用户的行为，特别是当这些技术的控制范围在某些情况下已经超过版权法授予权利所有人的权利时。在欧洲，决策者已经开始正视这种担忧，他们着手将TPM置于法律控制之下，以限制其滥用。虽然这些条款因为范围狭窄、过于复杂、偏向权利所有人而受到严重的批评，但它们确实代表了开源支持者在某种意义上的胜利。

与通过知识产权法对软件进行治理不同，软件的开发、向用户提供以及作为资产进行买卖几乎是所有现代商业活动的组成部分。这些活动一般通过各方（无论是企业、消费者还是公共管理部门）之间的协议来管理，这些协议要么并非知识产权许可条款，要么把知识产权许可条款作为其中的一部分。虽然此类协议主要由一方或另一方制定或双方通过谈判达成，但国家法律的某些强制性规则将影响这些协议，事实上也会导致不确定性的产生。与最初对软件应适用哪种知识产权制度的争议一样，欧洲和美国一直在争论如何将软件供应合同定性为商品或服务的销售，或两者兼而有之，或自成一类，以及这一定性对用户权利与利益及供应商义务的影响[14]。例如，欧洲消费者保护规则规定，供应商有义务提供有关软件和“数字内容”（包括计算机程序）之间互操作性的任何可用信息。

[14]　参见St Albans City & DC诉International Computers LTD案及The Mayor and Burgesses of the London Borough of Southwark诉IBM UK LTD案。

1.3 开源哲学与开源政策

虽然本书分析了开源社区和其他机构（如政府）如何使用公法和私法，但显然有必要首先阐释为什么会这样使用法律：使用这些手段的诉求是什么。毫无疑问，原因是多种多样的。有些人追求和支持开源的出发点是社会对待信息和知识的基本哲学观念，而另一些人则更加务实，他们认为开源是为用户创造更好的软件或降低成本的一种手段（详见第2章）。

如果“开源”只是一种开发方法，那么它不会招致那些来自专有软件社区的攻击，反之亦然。即使在开源支持者群体中，其哲学基础也有天壤之别，Richard Stallman曾提出有争议的观点：“开源是一种开发方法。自由软件是一种社会运动。”开源也被描述为“一种递归的慈善事业”[15]，因为参与的开发人员投入时间和精力来编写代码，然后捐赠给项目社区，受益者也成为贡献者。在实践中Copyleft许可证经常要求向创建原始开源软件的社区进行回馈[16]。这可以被视为对开发脱离此类慈善行为（也就是改变主意）的法律限制。

[15]　 George Finney，“The Evolution of GPLv3 and Contributor Agreements in Open Source Software”，Journal of Technology Law and Policy。

[16]　 从技术上说，Copyleft许可证（如GPL系列）确保了在分发软件时，其源代码以相同的许可证提供给接收者。这种分发行为（以及接收源代码的权利）可以私下进行。值得注意的是，并没有哪个主流的Copyleft许可证强制要求向社区回馈（包括GPL系列，这也是GPLv3如此复杂，以确保私下分发权得到保留的部分原因）。尽管如此，任何私下接受GPL代码的分发接收者都有权向社区贡献源代码及相关修改，只要他们愿意这样做。进一步的常见开发实践（例如，使用公开访问的基于Git的上游代码仓库服务，如GitHub和GitLab），意味着对社区的贡献是理所当然的，除非他们的分叉项目不再与上游同步更新。

开源领域的一个最新发展动向是故意发布不受任何许可约束的公开代码模块[17]。这种行为背后的一个哲学动机是拒绝任何官僚治理架构，即使是那些让版权法支持开源所必需的。正如一位评论家所指出的：现在的年轻开发人员都在关注发布后开源软件（Post Open Source Software，POSS），完全不在乎许可证及其治理。这有可能反映了占主导地位的代码托管平台GitHub不需要许可证和缺乏管理的问题。GitHub试图纠正这一不足，通过公告明确地表示，没有许可证意味着代码并不是开源的。

[17]　 Simon Phipps，“GitHub Needs to Take Open Source Seriously”。

正如本章后面关于公共领域的讨论那样，版权法不能轻易被忽视！

虽然这些观点可能只代表一小部分开发者社区，但也可能反映了“原生数字化”一代正在进入软件行业的情况，他们中的许多人是在一个表面上没有版权的环境中长大的，对于他们，任何东西都可以从网上某个地方获得。

分析推动人们参与自由与开源软件运动的不同信仰和动机超出了本章的讨论范围。然而，鉴于该运动对知识产权法，特别是版权法的依赖，接下来的各节将探讨一些与开源社区相关的版权法的哲学层面，包括促进言论自由、保护作品的可溯源性和完整性，以及其与公共领域的关系。1.3.4小节将从哲学层面转向政策研究，考察政府如何将开源纳入公共政策计划，以实现其一系列目标。

1.3.1 言论自由

关于自由软件运动，最常被引用的口号之一是强调free software（自由软件）中的free是free speech（言论自由）中的自由，而非free beer（免费啤酒）中的免费。为了实现这种言论自由，在自由软件运动中版权法被用来促进重用任何被改动的内容，并防止这种重用被限制在一个过小的范围内。选择Copyleft一词是为了表示版权的最初目标被自由地颠倒了：将版权（copyright）中的right（权利，右边）转向其反面（left，左边）。这一做法暗示了版权与言论自由之间的对立关系。那些把“合理使用”和“公平交易”等版权的法定辩护看作协调言论自由与版权的机制的人也认同这一观点[18]。

[18]　 Patrick Masiyakurima，“The Free Speech Benefits of Fair Dealing Defences”，P. Torremans编，Intellectual Property and Human Rights。

然而，事实并不总是这样的。这并不是看待版权和言论自由之间关系的唯一方式。正如美国最高法院早在1985年所指出的：“不应该忘记的是，制宪者希望版权本身成为捍卫言论自由的动力。通过确立言论的具有市场价值的权利，版权为创造和传播思想提供了经济激励。”[19]这里，版权被视为通过授予排他性经济权利来支持言论自由。这些权利显然也排除了某些类型的言论，但这个逻辑依然成立，只要版权作为“对创新的激励”的总体效果大于限制的效果，最终结果是有益的，版权法就可以被称为支持言论自由的工具[20]。此外，有人认为，版权的目的不应被视为对创造力和社会分配机制的刺激，而应被视为“确认作者作为言论发表者的固有尊严”的手段，这里，侵权行为被视为强迫他人输出言论，而抗辩则被视为促进他人的沟通[21]。无论你更接纳哪种观点，版权对言论自由的这种亦敌亦友的“悖论”一直是争论的主题。

[19]　 参见Harper & Row Publishers, Inc.诉Nation Enterprises（1985）案。而在Eldred诉Ashcrof（2003）案中，美国最高法院指出，“版权的目的是促进言论自由的创建和出版”。

[20]　 从正面看关于这两者的权衡，参见R. A. Cass和K. N. Hylton，Laws of Creation；而从反面看关于这两者的权衡，参见M . Boldrin和DK Levine，Against Intellectual Property。

[21]　 A. Drassinower，“Copyright Infringement as Compelled Speech”，Lever编，New Frontiers in the Philosophy of Intellectual Property。

人们普遍认为，近几十年来，版权作为约束因素的地位已发生变化。随着信息经济的兴起，版权已成为保护无形信息资产经济价值的核心。随着版权在经济上的重要性与日俱增，要求扩大和加强版权制度的呼声也日益高涨。更高的普及度，加上更大的权利和更有效的劝阻性的制裁措施，引发了许多利用版权来压制政治、艺术和商业言论的例子[22]。

[22]　 N. W. Netanel，Copyright’s Paradox。

言论自由是大多数法律制度明确承认的一项权利。在一些法域，特别是美国，与隐私等其他权利相比，言论自由被赋予了更高的地位。在欧洲，言论自由被赋予与其他权利，如财产权（包含知识产权）同等的地位。与版权一样，言论自由也不是绝对的，其范围是有限的，通常需要与其他受保护的权利和价值观进行权衡。

源代码在言论自由和版权制度下被视为一种受保护的表达形式。虽然在版权法下它与文学作品相似，但在权利视角下将其视为一种表达形式时，处理方式会依据具体情况有很大差异。当试图限制源代码的分发时，将源代码等同于言论的行为可能会受到司法审查。例如，在20世纪90年代，各国政府试图根据出口管制规则限制加密软件的出口，认为此类代码具有民用和军用的“双重用途”。虽然出口管制（见第12章）早已存在，但传统上针对的是实体物品而不是无形信息。在试图为数字时代更新这些规则时，它们不可避免地与言论自由权发生冲突。在Bernstein诉US Department of State案中，美国上诉法院裁定，加密软件的源代码是第一修正案保护下的表达性言论，并且现行的限制规则作为一种更为严格的约束方式，违反了该修正案给予的保护。相反，在Universal City Studios, Inc.诉Corley案中，法院认为，禁止网站所有人发布允许解密电影的源代码或将链接指向此类代码的禁令是合理的言论限制措施。

然而，当版权和言论自由因法律制度的不同而出现严重差异时，私法机制在界定和执行各方权利和义务方面扮演了重要角色。合同和许可证作为版权的工具，而不是言论自由的工具，赋予了版权成为一种强大的工具，既在所有权所有人手中，现在也在那些促进和保护开源、“开放”和“自由文化”的人手中[23]。虽然私法通常被视为任何法律制度的基础层面，但它能够直接针对个人，这是从宪法到法律规定的“更高”层级通常无法做到的。人们被强制性地（这个强制是个比喻而不是字面意义上的强制）“同意”合同条款，这意味着被许可人必定被告知这些许可条款。告知与同意不仅是公法对私法安排有效性和可执行性的要求，它们也是吸引个人参与到他人权益中的方法，即使这种方法并不总是有效的。可以说，正是通过版权法的私法工具，开源社区能够重申版权作为“言论自由动力”的历史角色。

[23]　 James Boyle，The Public Domain: Enclosing the Commons of the Mind，以及L. Lessig，Free Culture。

1.3.2 精神权利

从某种程度上说，由于对开源的支持往往受到道德和伦理的驱动，因此版权法中的精神权利制度自然值得我们关注。正如Välimäki所指出的，“看待开源的一种方法是通过它如何促进作者控制其个人创作的完整性和署名权的原始理想”。[24]本小节将考察精神权利与开源方法之间的密切关系。

[24]　 M. Välimäki，The Rise of Open Source Licensing。

虽然版权主要与经济权利有关，但《伯尔尼公约》也赋予作者对其作品的某些精神权利，这些通常包括署名权或创作身份权及保护作品完整权。

这些精神权利与作者的经济权利无关，甚至在上述经济权利转让后，作者仍有权主张作品的作者身份，并有权反对对其作品的任何歪曲、篡改或其他修改，以及其他损害其荣誉或声誉的行为。

精神权利反映了一种起源于欧洲大陆国家的信念，即作者对作品拥有“超越一般商业利益动机”的权利[25]。虽然《伯尔尼公约》承认了精神权利，但精神权利的处理在不同法域之间有着显著的不同[26]。英美法系国家通常制定最少的成文制度，例如，美国版权法采用最狭义的法定概念。与之相对应，在大陆法系国家，精神权利往往比《伯尔尼公约》规定得更为广泛。

[25]　 M. T. Sundara Rajan，“Moral Rights in Information Technology: A New Kind of ‘Personal Right’”，International Journal of Law and Information Technology。

[26]　 Elizabeth Adeney，The Moral Rights of Authors and Performers: An International and Comparative Analysis。

精神权利独立于版权授予的经济权利，是不可剥夺的，通常也无法转让给他人，尽管它们通常可以被放弃[27]。这种独立性导致创作者的权利与版权作品所有人的权利之间存在分歧。这种分歧可能会给开源软件项目的治理带来一定的问题，因为某些合作创作者可能会对拥有版权并通过开源许可证行使控制权的实体来主张他们的精神权利。

[27]　 参见CDPA。放弃精神权利并不总是被允许的，例如在法国就不可以。

虽然署名权必须由作者通过某种方式主张，即让其他人了解，但是，在很多版权体系中，署名权通过这样一种推定关系得以增强——作品的署名作者即版权的所有人。开源许可证明确支持署名权，特别是在再分发行为方面，通常要求在源代码、原始软件包或相关文档的副本中都保留所有版权声明。

至于修改，精神权利和开源之间的相互关系就变得复杂了。历史上，精神权利的一部分是原著的完整性，开源在这里的一个争议点是它破坏了作者及其作品的完整性之间的这种传统联系[28]。不过，完整性权利的范围仅限于那些“损害”作者荣誉或声誉的修改或其他行为。非偏见修改，如衍生作品或“改编”，并不构成对完整性权利的侵犯，尽管这里仍可能有署名权问题。在英美法系中，侵权诉讼中的举证责任通常由原告（即作者）承担，通过令人信服的证据，向法院证明修改其作品会造成伤害[29]。而在大陆法系中，法院则更倾向于尊重原告作者对作品构成贬损的主观意见[30]。这种贬损可能与作品内容本身有关，例如对代码的改写，也可能涉及对代码的滥用，例如将代码纳入声名狼藉的应用程序中，例如病毒。前者很少引起索赔，因为如果改写的代码质量差，以致可能会损害原始作者的声誉，这样的代码不太可能被社区接受，这得益于开源社区的同行评审性质的控制机制。虽然基于滥用的行为可能会超出作品授予的“非歧视性使用权”的限制范围，但这种限制本身的滥用也会增加对言论自由权进行过分干涉的可能性，而言论自由权是开源运动的核心要素。因此，损害完整性权利更类似于诽谤，诽谤既被视为侵犯个人隐私权的一个方面，也被视为言论自由权的例外[31]，而不是类似于版权控制范式的“管理修改”的机制[32]。

[28]　 Severine Dusollier，“Open Source and Copyleft: Authorship Reconsidered?”，Columbia Journal of Law & the Arts。

[29]　 参见Confetti Records诉Warner Music UK LTD（2003）案。

[30]　 Ian Eagles和Louise Longdin，“Technological Creativity and Moral Rights: A Comparative Perspective”，International Journal of Law and Information Technology 。

[31]　 H. Fenwick和G. Phillipson，Media Freedom under the Human Rights Act。

[32]　 G. Vetter，“The Collaborative Integrity of Open Source Software”，Utah Law Review。

软件的精神权利是否具有特殊性因法域不同而异。大多数法域并不加区别，有些法域调整了软件的权利，而根据英国法律，计算机程序则明确不受精神权利制度的约束。这种豁免在《伯尔尼公约》或其他国际版权文书中没有明文规定，也没有被其他法域采纳[33]。将计算机程序排除在道德权利制度之外的一个原因是希望“程序员可以在已有程序的基础上进一步改进”。因此，精神权利特别是完整性保护被视为技术进步和发展的潜在障碍。然而，这一论点似乎同样适用于能够控制信息使用的所有形式的权利而不仅仅是软件的精神权利。这里给出的另一个原因则是基于这样一种观点，即道德权利不适用于技术或功能性作品，而只适用于“艺术创作”或言论作品。这种论点似乎否认了可以通过计算机程序来表达言论，也否认了承认和赞美“优雅的”编程技术和解决方案的独特文化的存在。对此，欧盟委员会的论点是“对于精神权利是否适用于具有技术或工商业性质的，通过持续修改而产生的，集体创作的作品，是严重存疑的”。这里，除了对技术性、功能性作品的精神权利持保留态度以外，也关注了作品在创作过程当中的集体创新性质，以及对作品进行修改的范围，而这些都是开源社区的共同特征（当然，有些封闭或专有软件开发体系也具有这些特征）。在这种情况下，署名权和完整性权利如何有效运作呢？

[33]　 《与贸易有关的知识产权协议》（简称《TRIPS协议》）明确规定，《伯尔尼公约》规定的精神权利并不赋予《TRIPS协议》规定的权利或义务（第9条第1款）。

关于合作作品的署名，这个问题在性质上与版权法下适用于“联合作者身份”的问题没有什么显著不同，事实上，一些精神权利条款已经考虑到类似问题。另外，虽然署名权本身可能无法转让，但可以委托给其他实体来行使权利，这样，可以为开源社区与用户提供更多的确定性。

在持续修改方面，对所谓“贬损性修改”的明确评判标准可能用于防止对完整性权利的过度主张。事实上，与开源许可证中的专利报复条款类似，任何希望主张其完整性权利的人都必须首先确保他自己所提交的所有代码在开发过程中不会受到同样的完整性权利追索，这可能也是这类权利的一个评判标准。又或者，我们可以重塑这种完整性的概念，把个人向社区的汇编作品的贡献排除在保护范围之外，而把无论是通过技术手段还是法律手段对作品的“开放性”的破坏作为侵权行为。

开放源代码促进会（Open Source Initiative，OSI）是开源定义（Open Source Definition，OSD）的维护者。根据OSD，开源许可证中的代码完整性条款需要满足以下要求。

4.作者源代码的完整性

如果许可证限制分发修改过的源代码，则必须允许在分发的同时包含补丁文件，从而可以在代码构建时应用补丁所包含的修改。许可证必须明确允许分发由修改后的源代码构建的软件。但许可证可以要求派生作品必须更改名称或版本号，以区别于原始软件。

这些要求既保护了用户的知情权，让他们知道在使用谁的代码，又保护了作者的名誉。尽管OSI的内容是通过知识共享—署名许可证发布的，但是，其中并没有直接涉及署名权。不过，提供给用户的这种知情权也可以认为是署名权的一种体现。所有由OSI批准的符合OSD的许可证都将这种权利视为一种义务，要求保留作者的署名信息。

知识共享许可证族并不是为代码设计的，在这一方面它们明确指出，许可证的授权并不影响作品的精神权利。相比之下，欧洲公共许可证（European Union Public Licence，EUPL）要求许可人放弃其精神权利，不过仅仅是在“为了使许可证规定的经济权利的许可生效”的情况下才需要放弃。开放数据库许可证（Open Database Licence，ODL）则要求许可人“尽可能”放弃所有精神权利或同意不主张此类权利。在法律不允许上述两种操作时，ODL模糊地表示“作者可以保留对数据库某些方面的精神权利”，但没有具体说明这些方面是什么。GNU通用公共许可证（General Public License，GPL）没有提及精神权利，这也是因为它源自并不关注精神权利的美国。

有人认为，数字时代精神权利应该被重铸，而不是被放弃或避而不谈[34]。也有人建议，目标代码和源代码的精神权利应该被区分对待，特别是当前者生成视听作品时。如果精神权利可以作为一类知识产权得到重新强化，那它会对开源社区会产生什么影响？与大多数法律问题一样，在不同情况下，后果可能大相径庭！正如Ginsburg所指出的，数字时代的精神权利应该“通过在传递的副本中添加更多信息，还是通过控制副本本身来实现？”如前所述，署名权似乎与开源运动的理念完全一致，前提是需要加强通常在代码头注中声明的集体归属感。而在修改方面，我们可能需要对传统精神权利的概念进行重新定义，以适应开源时代的不断发展和变化。

[34]　 Jane Ginsburg，“Have Moral Rights Come of (Digital) Age in the United States”，Cardoza Arts & Entertainment Law Journal。

1.3.3 公共领域

既然开源社区的核心理念是广泛且自由地提供源代码，那么这引出了一个问题：为什么不将源代码直接放在公共领域（public domain），而要使用版权法作为工具来达到相同的目的？

“公共领域”信息这一概念在知识产权法中具有与“处于公开状态的信息”不同的特殊含义[35]。至少在一种情况下，“开源”一词在法律中被当作是公开可访问的信息的同义词，而不仅仅指软件。而“公共领域”作品则是不受任何知识产权保护的，它是信息的另一种状态。一些文献有时会混淆这两种概念。例如，Schellekens指出，历史上，在软件成为商品之前，它们“属于公共领域”，这错误地将当时软件的自由（free）状态（无论是“言论自由”中的“自由”，还是“免费啤酒”中的“免费”）等同于“没有知识产权保护”中的“没有”（对应的单词还是free）[36]。而Boldrin和Levine在相关著作中将开源运动描述为“放弃了其知识垄断”[37]，这种说法暗示着弃用知识产权法，而不是重新定义它们。

[35]　 L. Guibault和B. Hugenholtz，The Future of the Public Domain: Identifying the Commons in Information Law。

[36]　 Schellekens，“Free and Open Source Software: An Answer to Commodification?’”。

[37]　 Boldrin和Levine，Against Intellectual Property。

事实上，出于各种原因，某些东西本来就不受知识产权法保护。首先，与特定作品相关的知识产权可能会过期。例如，文学作品的版权在作者去世后的50到70年后失效[38]。不同类型的知识产权和不同的法域存在不同的时限，永久性保护也是有可能的[39]。

[38]　 《伯尔尼公约》规定的版权时效是50年，而英国版权法规定的版权时效是70年。

[39]　 对于商业秘密，只要它还是秘密就仍然有效；对于商标，只要一直维持注册并且仍有其独特性，也一直有效；对于数据库，如果对内容持续进行投资或有实质性更改就仍然有效。

其次，某些类型的信息可能不是可保护的主体，不能拥有某种知识产权。例如，根据欧洲专利法，“计算机程序”不能被视为专利发明。而根据美国版权法，美国政府的作品不受版权保护。版权只保护表达的具体形式，而不保护产生该表达的基本思想和原则。因此，想法不在国际和各国版权制度的保护范围内。根据欧洲联盟法律对计算机软件方面的规定，要保护想法可能需要特定的法律规定。

此外，与公共领域不同，知识产权制度中还存在例外。知识产权的例外是指，权利本身仍然存在于信息中，但在某些特定情况下，权利所有人是不能行使权利的。例如，欧洲法律针对软件的知识产权允许设置了若干例外，它允许用户合法地将软件用于备份或纠错。还特别规定，允许用户获取被保护的信息，“在独立地编写其他程序来达到互操作性的必要情况下”，这个条款的设定是为了刺激软件市场上的竞争。

对例外的使用是非常广泛的，例如美国的“合理使用”概念或欧洲法律下特别严格地列出的使用场景或用途。版权例外在许多法域仍存在政治争议性，相关辩论主要围绕着什么构成了具有竞争关系的各种公共利益的平衡，以及控制权与访问权之间的平衡。在这些争论点中，一部分就是关于公共领域的合理范围，尽管版权例外确实属于版权管理的范畴。

最后，公共领域作品也不同于孤儿作品，虽然孤儿作品无法识别版权所有人，但这些作品仍然是受到版权保护的，不能随意使用。在软件行业中，孤儿作品还有一种变种，即所谓的被放弃的软件。这些软件仍然受版权保护，但是作者已经没有兴趣再去维护这些代码，不再提供支持或其他输入，也对保护其版权不受侵害的行为不感兴趣[40]。放弃的原因各不相同，例如，版权所有人倒闭就是其中之一。

[40]　 Dennis Khong，“Orphan Works, Abandonware and the Missing Mark for Copyrighted Goods”，International Journal of Law and Information Technology。

回到开头，我们问开源为什么不把源代码直接放在公共领域。这产生了两个问题：首先，适用的知识产权制度是否允许权利所有人将受保护主体放到公共领域，换句话说，能不能摆脱法律对源代码的保护？其次，如果源代码可以被放到公共领域，那么，这种状态的变化，即一个人放弃了对后续他人使用代码的控制权，又意味着什么呢？

对于第一个问题，知识共享许可证CC0在《公共领域贡献》中提到“许多法律制度都禁止权利所有人放弃法律自动赋予他们的权利，特别是精神权利，即使这些作者非常了解这一举动的意义后仍然执意放弃权利，并将他们的作品贡献到公共领域。”美国版权法承认放弃的概念，这可以用于对侵权索赔的辩护——它要求被告证明版权所有人打算放弃他对作品的权利，并公开以表明这种意图的方式行事。虽然这对孤儿作品来说并不容易，但这种意图在开源环境中可以通过将作品贡献给公众的某些说明中被很轻易地读出。在英国版权法中，并不存在类似的放弃原则[41]。而欧洲民法法域通常不接受该原则[42]。

[41]　 Philip Johnson，“'Dedicating' Copyright to the Public Domain”，Modern Law Review。另外参见Copinger and Skone James on Copyright。

[42]　 Emily Hudson和Robert Burrell，“Abandonment, Copyright and Orphaned Works: What Does It Mean to Take the Proprietary Nature of Intellectual Property Rights Seriously?”，Melbourne University Law Review。

这种放弃版权的困难性和其他知识产权形成了鲜明的对比，特别是注册权、专利和商标，另外，之前讨论的精神权利也是如此。除了对放弃的法定承认以外，专利也受到社区实践的影响，例如，防御性开放就可能破坏专利申请时所需的保密性。

另一种贡献到公共领域的方法是向全世界授予许可，可以不受任何限制地使用。然而，除非有禁止反言的约束，否则此类许可仍然是可以撤销的[43]。这种撤销能力使得社区可以在代码被不正当使用时作出回应，但相关的复杂性和法律上的不确定性对于此类操作是有很大限制的。

[43]　此外，可能会使用更复杂的机制，例如版权所有人执行契约投票，或与另一方签订合同，根据该合同，许可授予“所有人”作为第三方受益人。

对于第二个问题，一种可能是有人将公共领域的代码作为一部分合并到另一个作品中，从而将这些代码重新私有化，并在新的版权所有人的条款下进行授权。因此，在这种情况下，将作品交给公共领域等于失去了对代码的控制，事实上这破坏了开源运动的（保持开放的）目的。

1.3.4 开源政策

作为一个有较强政治性的计算领域，开源不可避免地引起了政治家和决策者的关注。从历史上看，美国和欧洲的政治家一直都是知识产权的坚定支持者，而且确实存在加强已有知识产权规则的趋势，以适应在快速发展的数字化浪潮中转向基于服务的、信息化为主导的经济转型的需求。

然而，由于种种原因，政府也越来越被开源所吸引。首先，作为ICT的用户，公共部门希望通过这些技术来让政府运作更高效、更节约，然而现实常常难以如愿。人们希望借助开源带来的技术和成本优势来扭转这一局面。其次，人们希望刺激国民经济中的创新，而大家普遍认同开源有助于实现这一目标。接下来，主导某些软件市场的参与者来自国外，特别是经常来自美国，这引起了人们对于本国竞争参与者的担忧，采用开源软件可以缓解这一担忧[44]。最后，在透明度方面，如关于信息自由的立法，开放政府的趋势与开源的概念和开源的“透明化流程”有异曲同工之处。

[44]　 Hal Varian和Carl Shapiro，Linux Adoption in the Public Sector: An Economic Analysis。

国际组织已经接受了开源。联合国教科文组织明确指出，开源可以在联合国的千年发展目标的实现道路上扮演重要角色。而根据战略与国际研究中心（Center for Strategic and International Studies，CSIS）对2002年到2010年各国家、地区或地方政府颁布的开源相关政策的调研，可以将这些政策分为以下4类。

• 与研发相关的举措：例如鼓励建立开源社区。

• 推广和咨询：提升社区用户（尤其是公共部门）对开源的了解。

• 为开源提供优惠待遇。

• 强制要求公共部门使用开源技术或软件。

其中，后两项政策是公共部门直接提升开源采用率的相关举措。近几年，提升开源软件的使用率是最为普遍的开源政策，另一项对欧洲推进开源的努力的调研也证实了这一点[45]。

[45]　 Stefano Comino、Fabio Manenti和Alessandro Rossi，“On the Role of Public Policies Supporting Free/Open Source Software”，K. St Amant和B. Still编，Handbook of Research on Open Source Software。

通常，这些优惠待遇与开源相关的IT设备采购相关（引入偏好），具体操作包括从对开源相关设备的优先采购到直接对开源相关设备给予金融补贴。在一些法域，开源也被作为公共部门自研代码的首选分发方式（输出偏好）。例如，2007年，欧盟委员会批准了“欧盟公共许可证”，以此作为欧洲法律要求下的软件分发的私法安排。然而，与研发相关的举措一样，让“开放性”开发的或被资助的软件使用特定许可证条款常常也是有争议的，尤其是在使用Copyleft风格的许可证而非更宽松的许可证的时候[46]。

[46]　 Lawrence Lessig，“Open Source Baselines: Compare to What?”，R. W. Hahn编，Government Policy Toward Open Source Software。

政府有多种促进开源的手段，特别是公共采购计算机程序和制定“开放”标准政策（详见第21章）。前者是需求侧竞争手段，其基础是公共部门的购买力；后者可以通过增强设备、软件和数据之间的互操作性来提升供给侧竞争力。开源不等同于“免费”，因为在标准和专利领域确实存在付费问题（参见第16章），其中的一个热点话题是现有的特许使用费或者强制性的免费版权授权机制是否符合公平、合理且非歧视性（Fair，Reasonable，and Non-Discriminatory，FRAND）原则，以及它们是否会导致市场失灵，从而证明政府干预的合理性[47]。

[47]　 M.Välimäki和V. Oksanen，“Patents on Compatibility Standards and Open Source—Do Patent Law Exceptions and Royalty-Free Requirements Make Sense?”。

有人指出，采用支持开源的国家政策的一个因素是反美主义。CSIS认为，开源政策的趋势可能会影响专有软件市场的发展。例如，2006年和2007年Windows Vista操作系统的推出及由此产生的批评和负面新闻，与当时发布开源政策数量的增加明显具有相关性。然而，可以看到，像微软这样的公司已经从10年前的反开源立场转变为成为当今开源的最大贡献者之一。这至少可以部分地归因于Kubernetes和更具有互操作性的云原生软件的兴起，这些软件支撑着当今的云计算和平台经济。此外，借助GitHub和其他软件托管平台，开源软件的采用量也得到大幅增加。

在具体实施方面，研发和咨询相关的政策通常是通过行政部门的决策产生的，这一般需要较少的政治成本。与之相对应，推进开源采纳，特别是强制性采纳要求，往往需要更长的法律路径，通过立法或监管措施来实施。事实上，强制采纳提案通常是由国家或地方的立法机构提出的，这增加了其在政治与法律层面被挑战的可能性。CSIS调查显示，强制采纳举措的未通过率是高于通过率的。

支持开源的政策不可避免地引起了争议，并引起了软件及更广泛的ICT行业的反应，一般持有更多专有权的人更反对开源社区。学术界人士也担心，这些开源支持政策可能会变成“秘密产业政策”[48]。在某种程度上，这个问题与其他领域，特别是公共基础设施领域，所争论的问题类似——什么是实现开放竞争市场的最佳方法：建立一个“公平竞争环境”是否需要某种形式的优惠或歧视性措施，以便克服既有的市场结构障碍？

[48]　 Josh Lerner和Mark Schankerman，The Co-Mingled Code。

1.4 “开放”的具体对象

虽然在前面的内容中我们探讨了开源背后的哲学和政治层面的问题，但还没有说到开源的“开”字到底开了什么。抽象地说，从正面讲，可以将“开放”定义为一个用户被允许使用、修改和分享某些东西，就像自由软件基金会（Free Software Foundation，FSF）的4种自由中明确指出的（见第2章）。同时，“开放”也可以从反面来定义，防止某些行为和行使某些控制，在OSI的OSD中就可以看到这样的例子。“开放”常常等同于可获得性和透明度。源代码应该可以被其他人进行审查，以便辨别包含其设计构想和功能的思想与原则，并对其进行同行审阅，而无须通过与计算机程序交互的方式来进行黑盒分析。虽然“自由”（free）和“开放”（open）在开源的语境里常常被认为并没有多大区别，不过，其实免费（free）在很大程度上影响着可获得性，所以在某种意义上也意味着开放。开放还意味着选择和行为自由，便于采纳、部署和使用，并且停用和替换也是“开放”的一部分。通用性同样也是开放的特征之一，它常常与标准化和互操作性相关联，是软件行业的主要问题之一，本书后面也会再次讨论这个问题。

开源运动依赖于许可证、版权和专利法，以便让其他人能够使用源代码，特别是其修改和再分发版本。虽然“使用”显然是一个泛泛的说法，同时也是数字环境中“复制”的同义词，但实际上，许可证中的关键内容都聚焦在修改和再分发问题上。通常许可人关心被许可人的两种代码使用行为：被许可人会把代码再分发到哪里，或者他会如何修改代码后再分发。许可人希望被许可人可以以相同的方式许可更下游的用户，这种自由抑或约束完全取决于你的立场。

所有这些使用形式，无论是修改还是再分发，都会引起原作者的担忧。与许多法律领域一样，无论是在国家层面还是在多个法域的相互作用中，版权制度中使用的术语的确切含义都存在一些不确定性或分歧。用于叙述法律和司法解释的语言总是充满了历史和文化的意义。因此，私法机制就要成为解释这种不确定性的工具，要么是在已有框架的基础上填补空白，要么创造一种替代的话语体系。自由软件运动，特别是GPL，采用了后一种方法，其使用的术语和定义的概念都刻意地与版权法中常见的术语和概念进行区分。

我们知道，多年来，不同法域在其各自的版权法中使用了相同的词汇来表达含义并不完全一致的概念。于是我们引入了这些新术语，以便在任何地方都可以更准确地解释许可证所表达的意图。我们在许可证中直接定义这些术语，而不依赖于任何已有的版权法律框架。

这种将开源从国家和版权法偏见中解放出来的尝试，虽然有意将其置于公法制度的管辖之下，但这显然给开发人员和用户带来了挑战和不确定性。开源社区内部因此而产生的讨论，有时甚至是十分激烈的争论，便是这一现象的明证。

在后面内容中，还将介绍版权法中的修改和再分发概念，以及开源社区对这些概念的理解和相关争论。尽管各国的版权法在实质上是一致的，但各自独特的规定使得全面覆盖所有法域变得不可能。因此，我们分析的重点是美国、英国和欧盟的版权法。

1.4.1 修改

修改源代码是版权所有人的专有权利[49]。然而，什么构成修改其实并不那么明确，不同法域的术语和范围也各不相同。修改源代码的行为通常会涉及复制行为，这其实引发了另一个问题——这些看起来截然不同的权利其实并不可分。然而，人们（尤其在开源社区）普遍认为，这种区别是非常重要的[50]。因此，我们有必要在开源语境中再次探讨这个概念。

[49]　 注意，在欧盟这项权利与针对其他类型作品的权利并不一致。

[50]　 Lothar Determann，“Dangerous Liaisons-Software Combinations as Derivative Works? Distribution, Installation, and Execution of Linked Programs under Copyright Law, and the GPL”，Berkeley Technology Law Journal。

由于大多数开源许可证起源于美国，因此我们先从被广泛使用的“衍生作品”这个术语开始。它在法律上的定义如下。

基于一个或多个已有作品的作品，包括翻译、编曲、编剧、增加虚构故事、改编成电影、录音、艺术改编、删节、压缩，或任何其他重制、转换、适配作品的形式。这些编辑修订、注释、制作或其他修改作为一个整体，成为一个新的有著作权的原创作品，称为“衍生作品”。

这是《伯尔尼公约》给出的完整定义。根据英国法律，受到限制的行为是“适配”（adaption）。这个术语在计算机领域有特定含义，指“程序的一个重新调整或修改版本，或是一个翻译版本（使之可以运行于一个特定的环境中）”。这个概念源自欧盟法律。然而，“适配”的范围明显小于美国法律中的“衍生”概念，这使得美国的许可证在应用于英国法律背景时会产生不确定性。

根据美国法律，衍生作品也被赋予新的版权保护。尽管作为衍生作品，它必定大量复制了原作的元素，但同时它也要对原作作出不少于最低限度的内容贡献[51]。衍生作品同时也要与那些仅仅从一个作品中获得一些想法而独立创作的原创作品区分开。创作衍生作品需要获得原作者的授权，这是开源许可证的授权的一部分，但获得授权的同时需要遵从诸如保持署名或回馈等要求。当然，有些许可证默认版权所有人拒绝授权创作衍生作品。如果发生了违反许可条件的情况，衍生作品的授权会被撤回。在这种情况下，衍生作品的作者将不能再分发包含原作品的整个作品，但（理论上）还可以继续分发其个人贡献的部分。因此，衍生作品可以被认为是介于联合作品（joint work）和汇编作品（collective work）之间的某种形式。联合作品被视为一个不可分割的整体（详见1.5节），而在汇编作品中，可以从整体所有权中独立分拆出单独部分的所有权。

[51]　 Melville Nimmer和David Nimmer，Nimmer on Copyright。

在软件语境中，关注的焦点在于不同贡献者所编写的组件的源代码之间的交互性质。一组代码贡献是否基于现有作品？如果是，那么这些贡献的代码内容是否足够丰富且具有原创性，从而可以被视为衍生作品？如果不是，那么这些贡献的代码是否有足够的原创性并能构成独立的原创作品，并与其他此类作品组合形成汇编作品？

在开源社区中，一个处于激烈争论漩涡中心的概念是“链接”（Linking），尤其是当开源软件与私有软件发生交互之后引发的法律后果，这种争论甚至已经蔓延到开源社区之外。链接是程序间的一种正常关系或行为，通常涉及一个程序和所谓的“库代码”之间的交互，这些库包含了一些通用例程，可以被多个独立的程序复用。宽泛地讲，两个链接在一起的组件可以通过静态或动态两种方式交互，这是由计算机程序的作者来决定的。一般认为静态链接构成了衍生作品，而动态链接则不构成。

在开源文献中，“链接”这个概念经常用来表达不同的行为，通过这些行为不同的代码片段可以进行交互、相互操作或者“耦合”。此外，其他有关的行为还包括远程过程调用（Remote Procedure Call，RPC）、系统调用及插件机制。当两段采用不同授权方式的代码（无论是开源还是私有的授权）发生这些交互时，事情变得复杂起来，因为最终的作品在版权法中有可能被认为是衍生作品或类似的概念。因此，对于最终的作品可以采用什么许可证，乃至这个作品对于原始作品的任一部分的许可证是否构成了侵权，都产生了不确定性。就算是在开源社区内部，因为许可证之间的不兼容性，并不是所有的代码修改都是可行的。把两段开源代码组合成第三段并不总是可能的（参见第3章和第4章）。如果贡献的原始作品采用了Copyleft许可证（如GPLv2），那么最终作品很可能也必须遵循这个Copyleft许可证，否则该修改会违反许可证，并不再享有修改的授权。所以，Copyleft许可证的一个后果是通过对许可证的采用或者是否应该采用许可证的这种不确定性来引发版权法的作用，从而使人们采取了很多特别设计的方法，以最大限度地减少代码交互所带来的法律风险。

甚至有人专门开发和部署硬件控制机制，以限制Copyleft许可证的运作有效性。数码录像机制造商TiVo在其设备中使用了Linux操作系统和GNU软件，但通过启用数字签名，这样，修改源代码之后就会因为没有合法签名而无法在设备上运行。这种方法在开源社区引发了重大争议，一些人，尤其是FSF，认为这种做法（称为TiVoisation）完全不可接受，而另一些人，如Linus Torvalds，则认为这种商业性行为无可厚非。

和很多法律问题一样，这些不确定性问题取决于一系列因素，包括但不限于这些交互的技术本身、引起这些代码变更的人、这些变更发生的法域，以及代码所使用的许可证。首先，所有的计算机代码都被设计成在某种程度上与其他东西进行交互，无论是其他代码、硬件，还是其他元素。所以，仅仅是发生交互或互操作不足以使结果成为作品或衍生作品。受版权保护的作品可以相互作用，但仍保持其独特性和彼此的可分离性，它们都可以是独立的版权作品。这些作品可以一起使用，或作为一个软件包再分发，但在集体合作作品或复合作品中保持彼此的独立性，这也被称为“纯粹的聚合”。其次，收到聚合作品的用户也可以以个人使用为目的创作衍生作品，但不再进一步分发。这意味着最终用户的行为可能和处于中间位置的再分发者不同，因为许可条件仅由修改和再分发行为触发。再次，这种互动发生地的法域内的版权法可能会从广义或狭义上来解释衍生作品的构成要件，其判断可能会和相邻的其他法域不同。最后，尽管根据版权或合同分析，任何许可证的措辞都有可能无法通过司法审查，但是被授权人一般还是应该对许可证的措辞给予应有的重视，这可能在一些很重要的方面和所在的司法框架有所不同，特别是在它对“什么构成修改”这方面使用更宽泛的解释的情况下。例如，GPLv2不仅管辖衍生作品，还要管辖“全部或部分包含”GPLv2许可代码的作品，这似乎包含了汇编作品。在汇编作品中，受版权保护的作品之间的交互可能已经是最小化的了。

1.4.2 分发

根据WIPO Copyright Treaty（1996），分发权也被视为作者的专有权利：“文学和艺术作品的作者应享有通过销售或其他转让所有权的方式，向公众发布他们创作的原始作品或副本的专有权利。”根据欧盟法律，向公众分发计算机程序是授予权利所有人的专有权之一。

虽然原始作品和副本都涉及分发行为，但这种行为仅在涉及复制的时候才会产生。根据传统的版权原则，复制即再分发。如果没有制作更多副本，那么版权所有人的分发行为会受到“首次销售”或“用尽”原则的限制。这种学说的历史依据是，版权所有人应该为每一个复制品获得报酬，而不是在销售链下游所产生的额外经济价值[52]。虽然这个限制中提到的是“销售”，但实际上它适用于任何版权转让的情况，无论是否涉及营利行为。在欧盟，这一学说还被用作促进单一市场的发展，防止市场分裂[53]，这与美国的应用方式完全不同。

[52]　 根据欧盟的相关法律，这种报酬也应该是“适当”的，而不是“尽可能高的报酬”，参考 Football Association Premier League LTD 等诉QC Leisure 等案，以及Murphy诉Media Protection Services LTD（2012）案。

[53]　 这一原则仅限于欧洲经济区内的分销，不适用于国际。

在美国，法院和有关部门均裁定，用尽原则不适用于“数字作品”。此外，法院还特别就软件许可问题作出裁定，认为当版权所有人明确表示用户是被许可人，限制用户转让许可的权利，并限制软件的使用时，首次销售原则不适用。这些原则可以适用于软件交易，但仅适用于那些没有成功建立起授权/被授权关系就将软件的所有权进行转移的情况[54]。在没有证据表明用户接受协议或行为约束的情况下，例如所谓的拆封、标签或单方许可，都可能不被视为有强制效力的合同。这同样涉及开源许可是否可以被视为合同的问题（详见第3章）。

[54]　 参见UMG Recordings, Inc.诉Augusto（2011）案，其中涉及物理CD上的数字内容的分发。另见SoftMan Products Covp诉Adobe Systems, Inc.（2001）案。

根据欧盟法律，用尽原则明确适用于计算机程序，虽然近年来这种适用性被限制在实体拷贝上。欧洲法院在UsedSoft GmbH诉Oracle International Corp.（2012）案中打破了这一限制。在该案中，Oracle允许从网站免费下载其客户端—服务器架构软件，但使用时需要获得授权。Oracle提供了最多允许25个用户使用的团体许可证，但如果有更多人使用，就需要再购买一个25人的许可证。UsedSoft从Oracle的客户那里获得了这些团体用户许可，并将未使用的用户许可出售给他人，Oracle认为这是一种侵权行为。法院认为，当将软件的副本交付用户，无论是通过DVD这样的有形介质还是网络下载配合无限期的授权的方式，就用尽原则而言，都构成了“首次销售”[55]。判决援引欧盟法务官的意见——若刻意将合同区分为授权和销售，让后者适用于用尽原则而前者不适用，就违反了这个原则的本意。此前，人们曾普遍认为提供下载本身是一种“向公众传播”的行为，是授予权利人的一种排他性权利，不适用用尽原则。然而，法院认为，因为下载副本和许可授权而导致的所有权转让或“销售”让该行为属于分发权范围。

[55]　 Oracle公司的许可证声明这种授权是不可转移的，但法院认定其无效。

这个判决的一个影响是，它鼓励许可方将其分发方式从“销售”模式转向“租赁”订阅模式，这也迎合了软件行业向SaaS和云计算方向发展的趋势（详见第9章）。然而，对于开源社区，云本身可以被视为一种用于限制用户修改他们所使用和依赖的软件的自由的机制，是一种束缚而不是解放。

在开源许可证框架下，再分发不仅涉及代码的复制，还包括了接受者可以接受代码的条件，要么要求在整个再分发链条中都保持原始权利（Copyleft），要么允许对后续用户适用其他的，或许是更严格的权利限制。人们常常使用“传染性”一词来描述某些开源许可证的运作方式，这些许可证就是所谓的Copyleft，它们通过在软件再分发链条中传递义务[56]。所有的商业协议确实都会在某种意义上确保上下游之间的权利义务彼此匹配，但Copyleft的“互惠”这一描述源自许可证天然的自执行特质，这种特质更依赖于版权法而非合同（有时这种属性也被称为“传染性”，但开源社区一般避免使用这个贬义词）。“传染性”在法律领域的另一个例子是某些出口管制措施，它们适用于特定应用，例如设备中的加密模块，但可以使整个产品都受到管制制度的约束，或者说是“被感染”。

[56]　 Andrés Guadamuz Gonzalez，“Viral Contracts or Unenforceable Documents? Contractual Validity of Copyleft Licences”，European Intellectual Property Review。

虽然“分发”权在版权制度中普遍存在，但出于对其在不同法域中管辖范围不同的担忧，FSF在GPL中使用了专门的术语“转运”（convey），其定义是“一个作品以任何传播方式，让对方接收到或再生成一个副本，即转运。而如果仅仅是用户通过网络和程序产生交互，但没有给对方传播软件的副本，则不构成转运。”这个定义的后一部分对云计算的上下文来说非常重要，详情请参见第9章。

在国际、地区和国家的版权法规中，分发的概念经常受到“向公众”这个词的左右，这意味着有可能以非公开的方式提供作品副本。在开源开发背景下，理解公开和非公开两者的边界显然是重要的。接收作品的实际人数当然也是一个考虑因素，但并不如提供作品副本的方式更有决定性——“重要的是给予公众一个一般性的获取机会”[57]。欧洲法院在Sociedad General de Autores y Editores de Espana（SGAE）诉Rafael Hotels SL案中针对向公众传播作品的权利指出，“以公众可以访问到的方式向公众提供作品就足够了”。这对开源项目的管理方式有潜在的影响，因为参与的限制条件越严格，参与者之间的代码分发不构成代码分发权利的行使的观点越强烈，这在某些许可证下可能会产生后果。反过来说，严格的成员限制与开源倡导的开放协作模式是背道而驰的。

[57]　 Sam Ricketson和Jane Ginsburg，International Copyright and Neighbouring Rights。

在GPLv3中，“转运”这个概念不再拥有“向公众”这个设定，这就引发了一个问题——虽然某些形式的分发本身并不违反版权法，但是不是仍然可能违反许可证？例如，在开发环境中，代码可能会分发给社区或论坛中的参与者，这些参与者超出了单个组织的范围，或者是演示代码会提供给某些选定的客户，以便基于保密协议进行测试。这种受限的分发似乎不是“对公众”，但它可能会导致违反GPLv3，因为“其他”方已经接收到副本。GPLv3确实规定了可以向“其他人”转运，但仅限于他们“完全代表你，在你的指导和控制下”执行的情况，这可以认定是分发的非公开性。然而，它还指出，此类转运仅允许出于“让他们专门为你进行修改，或为你提供运行这些作品的便利”的目的，这涉及雇主/雇员、委托人/代理人或客户/供应商这样的关系，但并不一定涵盖社区内分发或“测试”的场景（另见第9章，了解转运在云环境中的应用）。

由于源代码及其附带文档的分发是用户的核心义务，因此，不可避免地出现了关于这一义务是否已经正确履行的争议，特别是在零售产品场景中[58]。代码可能随产品的相关介质一同发布，也可以通过网络下载的方式提供给最终用户。在两种情况下，尤其是后一种情况下，可能存在代码的可用性或提供代码的方式是否足够透明以满足许可证要求的不确定性。这些问题类似于法律领域内对通知要求的讨论，例如合同条款的合并及可用性（如反编译义务）。零售产品经常会在营销、设计等方面产生问题，尤其是品牌问题。

[58]　 参见Welte诉D-Link Deutschland GmbH（2006）案。

与修改类似，围绕分发这个概念产生的特定法律后果引发了关注，无论我们是否想看到这样的后果，注意力就会不可避免地集中在该术语的含义上，在许多法律领域中，这为争论和辩论留下了足够的空间。解释这种争论的传统场所是法院，虽然迄今为止可以直接适用的案例还很少。许可人可以尝试起草适当且足够精确的条款来解决不确定性，但在如此快速发展的环境下，这的确是一项非常复杂的任务。

1.5 开源作为一种开发方法论

和早期相比，软件开发或者说软件工程已经取得了长足的进步，随着处理能力的增强和编程语言的进步，开发人员已经可以开发出极为复杂的系统。这种复杂性的增加意味着源代码的开发需要更加规范化的开发流程，以便充分满足用户的需求、实现设计目标，并为最终产品提供完善的验证测试。随着这些领域的发展，软件工程正变得越来越专业化，以构建开发人员可以取得或满足的资质和标准。已有的各种标准和开发方法可以用来管理软件生命周期的各个阶段，从而提高源代码质量[59]。例如“瀑布”模型、螺旋模型和敏捷开发等方法。其中，敏捷开发是开源社区中采用最广泛的方法（详见第7章）。

[59]　 ISO/ IEC 12207: 2008，Systems and Software Engineering-Software Life Cycle Processes。目前该标准已废止。——编辑注

正如OSI所指出的，开源本身也可以被视为一种开发方法。

开源是一种通过分布式同行评审和公开透明来驱动的软件开发手段。开源的期许在于更好的质量、更高的可靠性、更大的灵活性、更低的成本，以及对被垄断型供应商绑架的终结。

1.6 开源商业

一个不断重现的主题是，接纳那些开源运动背后的哲学与政治思想，但同时从非政治化的视角看待开源，也就是说，任何组织都需要面对开源这个现实存在，并据此调整自己的商业策略和行为。

对开源的感知肯定是显而易见的，但组织和个人一样，会对那些不太了解或者看起来有困惑的事情产生视而不见的倾向。根据作者的经验，虽然开源的存在、发展和应用广为人知，但对于使用开源及其良好的治理手段的法律影响的相关知识和不确定性的了解仍然相当欠缺。

在对开源有所感知之后，要采取恰当的行动，应考虑开源如何对组织内部和外部产生影响，这涉及供应商、合作伙伴和客户。内部考量包括规范员工对项目的贡献和开源的使用；而外部考量则包括在尽职调查程序中对开源进行审计（详见第8章）。大多数组织思考的关键问题是管理风险并保护其资产，这统称为监护（curation）措施。

借助所谓的混合策略，可以通过多种方式使用开源来创造经济价值[60]。这种商业模式的多样性也反映了ICT生态系统本身的复杂性（详见第16章）。

[60]　 R. van Wendel de Joode、H. de Bruijn和M. van Eeten，“Living Apart Together: Hybrid Business Strategies on the Edge of the Commons”，Protecting the Virtual Commons。

1.7 开源的法律后果

正如本书通篇所讨论的那样，开源社区依赖版权法和合同法，以及或多或少的专利法和商标法来规范代码的用户的行为。因此，如果用户不遵守许可条款或基本的法律义务，权利所有人或其他利益相关者可能会依法对代码的用户采取强制行动。事实上，无论是基于私法还是公法，执法或其现实威胁和风险都必须被视为任何有效法律制度的重要组成部分，尽管对执法的恐惧不应成为法律被尊重的主要原因[61]。

[61]　 Chris Reed，Making Laws for Cyberspace。

知识产权法提供了一系列针对侵权行为的民事和刑事制裁措施。本书将在介绍知识产权时全面探讨这些措施。根据侵权行为被定性为版权或合同性质[62]，不同的制裁措施产生了开源许可证在执行层面的另一层不确定性[63]。

[62]　 在美国，参见MDY Industries诉Blizzard Entertainment（2010）案。法院认为，违约并不包含必要的“在条件和授权人之间的专有权利的关联”。

[63]　 Robert Gomulkiewicz，“Enforcement of Open Source Licenses: The MDY Trio’s Inconvenient Complications”，Yale Journal of Law and Technology。

执法行动也可能是由其他相关的法律制度引发的，例如旨在防止对最终用户进行欺诈的消费者保护法。其中，一个例子是所谓的“订阅陷阱”，当网站在提供的开源软件中包含高昂的隐藏费用时，在德国可能构成刑事犯罪。

除了开源权利人对代码用户的法律行为以外，权利人之间也可能产生纠纷，无论涉及开源软件还是专有软件。考虑到与诉讼相关的风险和成本，潜在的被告通常会采取一系列旨在减轻此类风险的战略性知识产权管理措施，包括技术上的“迂回设计”到知识产权的防御性收购等（详见第6章）。

1.8 开放的未来

本章探讨了许多与开源相关的行为特征，这些特征带来了法律上的不确定性，对开源软件的支持者和用户造成损害。其中包括大多数开源许可证中使用的源自美国版权法的语言，当这些许可证应用于其他法域时，这些语言可能在关键方面会有所不同。一些开源许可证包含的条款是为解决某些社区的具体问题和需求而起草的，但许多根据该许可证发布的代码的用户可能不熟悉这些条款，而且这些条款也可能未经法院检验。开源社区中的合作工作机制对许多人来说也是陌生的，因此经常被忽视或管理不善，并为法律的应用增加了复杂性。

随着时间的推移，某些趋势也可能会削弱当前开源许可证的影响力，尤其对于Copyleft哲学的追求。就市场而言，向云计算的转变意味着软件分发在SaaS环境中变得不那么重要，只被局限在有物理设备访问的操作环境中。同时，不断发展的版权法受到司法判决和立法改革的影响，可能会越来越多地限制其在软件领域的应用，从而降低其作为约束制度的效力。从技术角度来看，使用越来越复杂的技术来限制受不同许可证约束的软件组件之间交互，也有可能减少Copyleft许可证的传染性影响。

本章试图避免对开源作出规范性陈述，认识到并尊重那些提倡捍卫和使用开源的人所追求的哲学、伦理或政治目标。此外，我们的重点在于分析公法制度，特别是版权法，如何与开源软件相互作用，促进或限制开源支持者的愿望，以及私法安排如何被用来实现特定的结果，有时甚至是为了超越公法的判断。所有迹象都表明，开源的开发和使用正在大幅增加，这可能会导致更多关于开源的语言定义和法律运作的司法考量，有望减少不确定性领域。然而，更不可预测的是，政府和立法者是否会因开源的兴起而重新审视并调整公法领域，以适应软件在社会和经济中的关键作用和独特特征。

第2章 以演进的视角看社区和治理

作者：Ross Gardler和Stephen R. Walli；译者：王玉茂；审校者：张欣然

2.1 协作与社区

“自从你有了篝火，我想坐在篝火旁，我们就知道了社区是如何运作的。”[64]这句话揭示了关于人类及其建立的社会极其成功的一个简单道理。自开始编写软件以来，人们就在协作开发软件，这种协作可以追溯到普林斯顿大学冯·诺伊曼团队早期开发可编程计算机的工作。编写优秀的软件是一项艰苦的努力。在过去的70年中，计算机编程和软件工程领域的所有投资，本质上都是为了用更少的“代码”编写出更多、更好的软件。开发人员在社区中协作，这既是开源背后的理念，也很可能是迄今为止人类社会最有效的软件重用策略。

[64]　 Stephen Walli，“What Does an Adult Look Like in Your Community”。

为了理解这个理念，我们需要梳理软件共享的历史，版权和许可的本质，以及这些社区是如何形成、组织和治理的。通过这样做，我们才能更好地理解开源对经济和商业的影响。

2.2 从知识资产到知识产权

创建复杂的软件是一项智力上的挑战。然而，从20世纪50年代到70年代，软件通常由计算机厂商开发，并与计算机硬件捆绑销售。计算机硬件本身的成本远超为其开发配套软件的成本。

在这一时期，计算机厂商开始组织各种会议，这些会议逐渐成为这一领域的重要组成部分，并为推广软件及其相关理念和实践提供了机会与平台。例如，自20世纪50年代起举办的IBM会议实际上被称为SHARE。数字设备计算机用户协会（Digital Equipment Computer Users Society，DECUS）是围绕数字设备公司的计算机而成立的用户协会。当AT&T贝尔实验室开始分享早期UNIX操作系统的磁带时，高级计算系统协会（USENIX）也随之诞生，这使得开发人员或用户能够在这个平台上交流软件工具和实践。

到了1980年，一切都变了。美国国会将版权法应用于计算机软件。这是历史上首次通过法规保护代码作者的权利。这将在第3章中详细讨论。

发行商将作者的创作推向大众是需要承担成本的，而版权法为他们提供了保护其投资的法律框架。然而，一旦将版权法应用于软件，原本可以在（由一群志趣相投的用户自发构建的）社群中自由分享的知识资产转变为受知识产权保护的资产，并被纳入受保护的分销系统中。

自版权首次应用于软件之后的40年间，计算机硬件的成本急剧下降，而计算机软件的成本和复杂性则呈指数级增长。这一时期，计算机硬件、编程语言和操作系统都实现了标准化（既包括技术上的事实标准，也涵盖了法律层面的严格规范）。借助硬件、软件和协议标准的发展，互联网和万维网技术使得数字分发变得更加便捷。软件不再通过印刷媒体来传播。取而代之的是以数字方式通过网络跨越地理界限进行分发和更新，并且逐步趋向免费。这些趋势共同促成了一个丰富而充满活力的计算机软件业，它脱离了计算机硬件，并得到蓬勃发展。

2.3 知识产权与产业规模

构建计算机程序来解决问题是一项智力活动。如果我们为自己写一个计算机程序以解决某个问题，那么我们既需要掌握如何通过算法解决问题的能力，也需要掌握用代码实现解决方案以便硬件能够执行的知识。但是，如果我们构建了一个计算机程序，并与10个朋友分享，那么需要额外的工作来确保可以将软件打包并交付给他们。如果朋友的数量增加到100个，则需要做更多的工作来“维护”软件包。与所有的工程作业一样，当一个工件的用户数量增加时，我们需要更成熟的实践和流程来高效地管理工作，以便大规模地构建、打包、分发和支持该工件。

多年来，软件公司在这些大规模工程实践方面变得极其高效。从20世纪80年代到90年代，一直到进入新千年，随着软件产业的发展，软件公司一直在销售受版权保护的软件产品。无论这种定价是基于许可费、技术支持合同，还是演变成持续订阅模式，在某种程度上都无关紧要。重要的是，它为企业带来了切实的收益。在此期间，企业和政府的IT部门开发了大量的定制软件，因为许多问题不一定能通过购买一款软件便可以“开箱即用”来解决。软件公司的产品经理和企业IT经理熟练地应用“自行开发还是购买”的分析逻辑，以决定何种情境下采用最合适的策略。

2.4 版权的早期实验

这种对立（购买与定制软件解决方案）正是开源软件和自由软件赖以生存与发展的基础。尽管将版权应用于计算机软件意味着需要通过许可证来授权并定义软件的使用条款，但代码共享与协作的理念依然延续了下来。正如软件公司制定商业或专有许可协议来为其客户定义使用条款一样，希望继续共享和协作的开发人员也需要制定许可协议，以允许第三方能使用和基于他们的作品/代码进行协作，因为代码同样受到版权的约束。

为了实现这样的协作，从20世纪八九十年代开始，人们进行了以下几次许可协议的实验。

• MIT的Athena是DEC、惠普、IBM及其他相关公司的研究人员联合开发的实验项目，他们开发了X11窗口系统和Kerberos。这是MIT/X11许可实验的开端。

• 自由软件伦理规范的萌芽始于20世纪80年代早期，并由此催生了Copyleft理念、用户对软件的权利及GNU公共许可证等思想。（我们将在本章的后续部分中进一步讨论软件自由与伦理规范的相关问题。）

• 加州大学伯克利分校计算机科学研究小组发起了伯克利软件套装（Berkeley Software Distribution，BSD）项目，该项目促成了BSD许可证及其变体的出现，而这些变体随后被应用于其他合作项目中，如早期的Apache Web服务器项目。

• 基于艺术许可证授权的Perl编程语言项目形成了一个庞大的由开发人员和系统管理员组成的社区，他们基于Perl编程语言和工具进行共享与协作。

直到20世纪90年代末，软件行业才将这些早期的软件许可证视为“开源许可证”，但在长达18年的过渡期中，由于版权制度对许可证的需求，开发人员和软件公司依然通过早期的软件许可证共享代码，就像他们曾经尝验的那样。他们不仅尝试共享代码本身，而且尝试围绕代码许可证进行协作，就像他们在1980年之前的30年间所做的分享一样，而那之后版权开始应用于代码。

2.5 工程经济模式的开端

在深入讨论社区和治理问题之前，需要理解的最后一个难题是一个经济学问题。时至今日，人们仍然在思考能否在宏观层面将开源软件看作一种经济模式。他们之所以如此质疑，是因为开源软件是由开发人员以零成本免费分发的。以这种方式来看，这里并没有明显的经济模式。

提供另一个视角的一种简单方法是，考虑在一家公司的软件解决方案中使用有许可证的开源软件。每位IT经理和软件产品经理都熟悉“自行开发与购买”的分析方法，这也正是把软件的获取方式作为解决问题的一个思路。

然而，对于自由授权和协作开发的软件项目，在构建和购买之外还有第三种选择——借用与共享。

关于这方面，请参考以下案例。

20世纪90年代末，在一家小型初创公司[65]中，工程团队需要控制他们的编译器环境，以便基于Windows NT操作系统横跨3个架构（IA-32、DEC Alpha和MIPS）构建内核级软件。而微软公司提供的编译器不能满足这个需求。如果单纯购买Intel公司提供的编译器，并不能解决其他两种计算架构的问题。构建或购买的选项并不能满足这家初创公司的需求。

[65]　 作者（Walli），作为软件系统的研发副总裁，1995年至1999年基于Windows NT操作系统构建了一个UNIX前端。这提供了一个关于为改进产品而围绕GCC套件进行成本分析和决策的直观例子。该项目的大部分功能基于自由授权开发，属于合作开发的软件项目。在接下来的几年中，这些项目尚未被称为“开源”。

• GCC套件提供了一个解决方案。这个合作项目成熟且持续维护，支持所需的全部3种计算架构。

• 雇佣每位编译工程师需要投入约10万美元，而在第一年内，该公司就从GCC项目[66]中获得了1000万美元的收益，因为它解决了跨3种计算架构的需求问题。

[66]　 如果采用比较成本模型（COCOMO）进行估算，那么1997年的项目规模约为750 000行代码（Lines-of-Code，LoC）。虽然每个软件开发人员都可以将LoC作为软件价值的严格衡量标准来阐述问题，但随着时间的推移，LoC作为一个有趣的相对衡量标准，可以用于与直接工资和合同成本进行比较。

• 然而，现在这家初创公司主要依赖于一个从GCC项目上游分叉的定制版本。这意味着他们无法轻松获得上游的补丁修复、性能优化和新功能。

• 于是，这家公司额外花费了4万美元请GCC的维护者把他们对GCC的修改回馈到上游GCC项目的主线中。

• 这意味着，在GCC项目的下一个发布版本中，这家初创公司将能够以最小的集成成本直接使用该版本，因为他们的更改已经合并到GCC主项目中，同时也能直接获得社区中所有新的改进内容。

• 将新的GCC版本集成到他们产品中的成本约为每个主要版本1万美元。在新版本开发的18个月中，广泛参与GCC社区会为该项目增加500万美元的新价值。这比他们18个月中获得的价值高出3个数量级。

通过“借用与共享”，可以在自行开发与购买之外进行额外的对比分析。

仅仅依赖于借用是不足的。软件处于不断变化与发展之中，上下游之间随时可能进行错误修复，特别是在一个充满活力的社区环境中。例如，把软件使用过程中所需的任何更改进行共享，并将这些更改补充回借用的软件中，然后将其合并到上游社区或项目中，这样才能够确保在上游软件演进的基础上更容易获得最新的和更完善的功能。

如果可以免费借用软件并且其质量足够高，这样做显然是有道理的。然而，始终存在的一个问题是：为什么首先要创建这样一个组件项目，还要做额外的工作来构建和管理一个围绕免费项目的社区？要找到这个问题的答案，我们可以参考Eric von Hippel自20世纪80年代以来对创新模式的研究。

Hippel首先研究了帆板冲浪社区。虽然帆板这个领域有许多制造商，Windsurfer是占主导地位的品牌，但这些公司无一例外地没有在新帆板技术的研发上投入巨资。相反，社区内有一群充满活力的帆板“黑客”，他们通过切割、钻孔、黏合等方式试验帆板、帆桁、桅杆和船帆。这些公司很乐意退居幕后，观察和学习，而不一定要犯代价高昂的错误，将不成功或不能吸引大众想象力的实验品推向市场。走在前沿的帆板爱好者对创办公司不感兴趣，他们乐于分享自己的创新和想法，接受赞助，成为教练、顾问和培训师，享受技术最前沿的生活方式。

Hippel通过深入研究发现，这些创新模式同样适用于其他领域。最终他将研究扩展至软件领域，并将成果直接应用于开源领域。虽然人们可以从这项研究中获得对创新模式的支持，但我们必须记住，软件商业化是在版权制度确立之后才逐渐形成的。在版权出现之前，软件开发社区使用的是原始的协作和共享模式。

2.6 开源——一种共享的生产方式

开源包含很多东西，如软件许可、生产和分发模式。作为一种许可和分发机制，开源提供的条款允许用户自由使用受版权保护的代码。然而，正如我们已经看到的那样，对于那些注重自身利益的用户，将他们对代码所做的每一行更改回馈到上游原生项目中是非常有利的。

作为一种生产方式，开源通过高效的协作来降低生产成本，所有参与者共同分摊创作成本。开源允许个人将其拥有的专业和有价值的知识与其他可能具有同样技能的人分享。他们的贡献换回的是改进后的软件。贡献的经济回报很容易被证实，因为仅一个小的贡献（相对于整个项目）就能换回免费提供的更完整的解决方案。

开源允许在市场上有潜在竞争关系的个人和组织在软件组件和系统上无缝协作，这些组件和系统一旦创建，就很容易通过共享来避免重复劳动和投资，并有可能通过多样化的协作来实现更优质的产出。这种软件的无限制分发会促进形成一个更大的用户生态系统，这反过来又增加了潜在合作者的数量，有利于进一步降低生产成本。

在许多开源项目中可以看到这种生产模式的有效性。例如，Apache Hadoop项目是Google公司的MapReduce算法的一个实现。Hadoop包含了来自同行业的多家公司的重要贡献。参与者包括大型软件公司，如微软、Facebook、Twitter和LinkedIn，以及中小型企业、大学和政府组织，甚至还有一些个人参与其中。所有这些参与者，无论规模大小，都为Hadoop软件的生产和维护作出贡献。大多数人的贡献是为了降低成本并提高软件质量，这形成了Hadoop独特商业模式的核心逻辑；而少数人的贡献更多的是出于个人原因，例如职业发展。

为了使这种生产模式有效运作，每个参与者都必须能够获得比他们的贡献更多的价值。参与者还必须感到他们的未来是受到保护的，也就是他们的贡献不会被现在或将来的其他合作者滥用。以社区为基础的开发模式、基于互联网的现代协作工具和开源许可证的组合，可以确保这种协作的可能性。当然，他们还必须建立允许在反垄断和自由竞争的机制范围内进行协作的组织架构。

2.7 开源文化

在阅读有关开源的文章时，人们经常会看到“自由软件或开源软件社区”。顾名思义，理论上应该有一个围绕纯正开源精神而形成的统一社区。然而，现实中并没有这样的社区，就像没有“专有软件社区”一样。相反，围绕特定的软件项目、许可模式和开发模式形成了许多不同的社区，以解决特定需求。这些社区虽然不是这个大一统“开源社区”的一部分，但它们可能以一种或多种方式与其他子社区相关联。基于各种原因，这些不同的社区聚合在一起。接下来我们将探讨形成这种聚合的一些常见原因。

聚合型社区平台可以简化跨项目的公共管理。例如，开源项目的知识产权和基础设施都可以通过中心化平台集中管理。这种聚合型开源项目平台有很多，例如.NET Foundation提供知识产权管理服务，而GitHub和GitLab则是提供开源项目托管的基础设施平台。正常情况下，这种公共的托管服务并不会形成一个跨所有项目的统一开源社区。

此外，项目也可能通过共享专业的社区管理服务而聚合在一起。这种社区的一个例子是Apache软件基金会（Apache Software Foundation，ASF）。在ASF的治理模式中，影响力无法通过购买获得。对于ASF，唯一被认可的价值是社区成员之间卓有成效的互动和参与。这为参与者提供了一个可以公开协作的中立空间。在这样的平台项目群中，跨项目的协作可能性更大，但这是治理模式和知识产权管理标准化的副产品，而不是社区本身的要求。ASF以Apache Way的运作管理方式而闻名，“人优先于代码”的理念强调了社区成员的重要性。

有一种社区结构可以增强跨项目协作的效果。当多个组织共同参与某些共享软件项目的开发时，这种结构显得尤为有用。为了在一定程度上强化合作，合作伙伴可能会选择一种模式，在这种模式中，宏观影响力被视为对遵守参与规则的奖励。这些规则可能涉及也可能不涉及对软件代码的直接生产性贡献。与纯粹的社区模式相比，这种环境的设计不那么中立，但它们仍然不能由单个参与者控制。OpenInfra基金会就是这样的一个组织，其中三分之二的董事会席位基本上是通过“付费”获得的，而剩下的三分之一则是活跃社区的代表，无论他们的财务贡献如何。在这类集群中，各项目之间的协作水平很高，因为开源社区对于要构建什么样的产品有明确的战略。

在打破“开源社区”神话的过程中，我们需要明白，协作的主要驱动力是受益于单个社区项目的产出，而不是团结在一个通用的开源旗帜下的社区群体。在这种情形下，开源只不过是一种生产方式。然而，还有一种社区类型，通常称为自由软件社区。

自由软件社区认为，开源社区及其关注的开源开发的生产方式并不那么重要。比起“开源软件”，这个社区的成员更喜欢“自由软件”这个术语，因为他们关心的是提供和保护软件，尊重用户运行、复制、分发、研究、更改和改进软件的自由。自由软件社区以自由软件基金会为核心。该基金会为自由软件提供合规平台，也为倡导者和支持者提供必要的伦理规范支持。

尽管自由软件的伦理规范十分重要，但务实的开源参与者往往觉得它们言过其实。在确定自由软件的伦理规范的重要性后，我们仍继续使用“开源”一词来描述那些以许可方式既被视为开源软件也被视为自由软件的程序。当我们希望区分软件知识产权和软件自由所倡导的伦理规范时，将使用“自由软件”一词。

可以看出，虽然不存在大一统的“开源社区”，但有许多基于开源的子社区。这些社区通过以下一个或多个特征联系在一起。

• 共享知识产权管理的法律组织架构。

• 共享项目基础设施（如网站、版本控制系统、邮件列表等）。

• 采用共同商定的协作软件开发模式。

• 需要一个中立的协作空间。

• 共享通用的软件解决方案。

• 基于共享的软件组件增强协作。

• 对软件自由的伦理信仰（如同言论自由一样）。

• 协作筹集资金或资源支持。

2.8 促进合作的许可证

所有这些社区的一个共同特征是对其合作产出应用开源许可证。对版权法的创造性运用催生了Copyleft的概念和一系列许可证，它们既可以保护每个参与者创造的知识产权，又允许不受限制地分发代码。目前，可供选择的开源许可证有许多种，第3章将对此进行深入讨论。

一个开源项目选择什么样的许可证，就会产生对应的开源社区，也将有对应的开源开发和生产模式。开源许可证的选择对社区类型和生产模式有重要的影响，并会在社区后续的发展中发挥意想不到的重要作用。正如我们所看到的，早期的许可证都是围绕合作中的个体开展的尝试，但随着越来越多的个人和公司的参与，人们发现这些许可证能带来更广泛的适用性和显著的利益。

其中一类许可通常被称为互惠版权或Copyleft，它从法律上强制要求发布对代码的更改，即包含原始代码的衍生作品。这类许可可能会对一些商业模式产生影响，例如基于开源代码构建的闭源、专有的衍生作品，但同时又能确保任何第三方都不能滥用开源开发模式（只使用开源项目的输出而不开源发布对它们的更改，详见第3章）。在提出Copyleft概念时，其创造者Richard Stallman把版权的双重作用发挥得淋漓尽致：一方面保护用户免于侵权风险，另一方面防止使用者拒绝回馈上游。

在许可证族谱中，处于族谱另一端的是宽松型许可证。这类许可证允许再生产者/分发商采用任何商业模式，包括基于开源共享代码创建闭源、专有衍生品（详见第3章）。使用这些许可证的项目需要通过经济和社区压力来鼓励贡献。因此，使用宽松型许可证的项目需要一个构建良好的社区治理模式，以促进持续发展与贡献。

理论上，所有社区项目都可以通过版权许可框架共享，这意味着不同的项目可以共享其成果，并在定义的社区内相互贡献产品代码。遗憾的是，事情并没有这么简单。由于一些许可证之间的不兼容性（这些许可证旨在防止自由软件的非自由衍生品的产生），这样的重用并不总是可行的。总之，宽松型许可证下的代码可以被Copyleft许可的代码引用，但反过来并不总是可行的。当我们引入“部分”或“弱”Copyleft的概念时，这种情况会变得更加复杂。“部分Copyleft”许可只要求对自由软件的修改部分互惠共享，并允许在专有产品中嵌入这部分代码。在某些情况下，“部分Copyleft”自由软件可以包含于采用宽松型许可证的开源软件中。关于开源许可兼容性的详细讨论超出了本章的范围，这方面的内容将在第3章中介绍。在此，我们有必要承认这一问题的存在，因为许可证的选择显然会影响社区如何以及何时共享代码，并在一定程度上影响社区自身的生态。

当通过使用兼容的许可证促进跨项目的共享时，可以在代码生产周期中立即带来益处。[67]通过在无差异软件的生产过程中共享资源，软件公司能够降低成本并提高产品的质量。所谓“无差异软件”，指的是那些不以参与者的所有权作为唯一标识的“集市”软件，无论这些参与者是否提供软件、服务或通过使用软件产生过其他产出。

[67]　 Dirk Riehle，“The Economic Motivation of Open Source Sofware: Stakeholder Perspectives”，IEEE Computer。

无论选择何种许可证，并非所有开源软件社区都是开放且协作的。许可证保证了每个人在使用软件代码方面享有一定的权利，但它对所采用的开发模式只字未提。在某些情况下，软件的所有人可能会选择一种封闭的开发模式，在这种模式下，只有极少数人能够参与到软件开发的决策过程中。这可能会影响潜在用户决定是否使用该软件，进而影响第三方为软件生产作出贡献的可能性。

开源项目所采用的开发模式及其许可证类型共同影响了其对应的开源社区类型。这反过来又会影响那些生产或消费项目组件的公司创造收入或节省成本的机会。我们将在第15章和第16章中对这些经济和商业模式进行更全面的探讨。在本章后面的内容中，我们将再次讨论这些问题，但首先我们需要深入探讨影响社区治理架构和许可证选择背后的政治和伦理规范。

2.9 开源的政治和伦理规范

截至目前，我们已经研究了开源作为一种生产方式的地位和作用。在这种生产方式中，知识产权许可模式决定了共享项目产出如何对外公开。我们曾经指出，这只是开源讨论的一部分，还需要考虑同样重要的政治和伦理规范。“自由软件”这一术语体现了这些讨论的核心精神。但在这些讨论中，“开源”也未必能排除在外，因为所有的开源软件本质上都是自由软件。

“自由软件”这一概念是由FSF提出的，它的出现早于“开源软件”一词。对于某些人，“自由软件”是首选术语，他们不希望将自己与“开源”一词联系在一起，因为“开源”已经变得与“特定的方法论、哲学观、价值观以及许可证接受标准”紧密相连。

自由软件绝不能与“免费软件”混淆，后者是指可以免费获得但不提供源代码的软件。免费软件没有提供我们在自由软件中看到的那些与代码共享相关的效益，而这正是自由软件的一大核心优势。也就是说，虽然免费软件的成本为零，用户却无法根据自身的具体需求对软件代码进行定制或修改。此外，由于缺乏源代码，用户也无法分享他们的经验，以进一步降低开发和软件维护的成本。

由于免费软件的重点是没有许可证，因此无须支付许可费用。自由软件被认为是一种社会运动，它采用了特定的知识产权许可方法，而开源更像是一种软件开发运动，它使用了框架相似的知识产权许可模式。对于自由软件运动，非自由软件被视为一个社会问题，而开源运动则提供了一个次优解决方案。虽然这两个社群在一些基本原则上存在分歧，但在实操层面，它们大体一致。本节介绍的是这两种运动在基本原则上的不同之处。

此外，免费软件与公共源代码（public source）或共享软件（shareware）也有区别，尽管后两者拥有公开可用的源代码，但它们缺乏正式认可的许可证来授予他人以自由或开源方式使用代码的权利，因此其代码所有权仍然是私有的。

2.10 自由软件的定义

“自由软件”是指尊重用户自由的社区性软件。它赋予了每个人运行、复制、分发、研究、修改和改进软件的权利。这些自由确保用户（集体或个人）能够按照自己的意愿控制程序及其功能。FSF认为，当用户无法控制程序时，程序就会反过来控制用户。这会导致“非自由”软件有机会成为“不公正权利的工具”，就像我们偶尔看到的那样。因此，自由软件关注的是自由本身，而不是价格：“自由”是指“言论自由”，而不是指“免费啤酒”。

为了明确一款软件是否属于自由软件，FSF定义了4种基本自由。要被视为自由软件，其发布和使用条款必须满足以下4项要求。

• 按照使用者的意愿，以任何目的运行程序的自由（自由度0）。

• 研究程序的运行方式并对其进行修改，使其按照使用者的意愿进行计算的自由（自由度1）。

• 重新分发副本以帮助他人的自由（自由度2）。

• 向他人分发修改后的版本副本的自由（自由度3）。

值得注意的是，这4种自由中并未包含限制商业活动的内容。事实上，这4种自由确保了商业使用、开发和发行的可能性。另外，修改软件的自由并不意味着第三方必须接受你的修改。软件改动的价值评估是主观的，而这4种自由并不会在“是否接受修改或如何进行修改”上提供任何指导。它们只是确保用户有权进行修改并重新分发修改。

自由软件许可可能要求对已修改的产品进行名称和品牌的变更，以避免原生的商标被应用于修改后的版本（详见第9章）。只要这些要求不是苛刻的，就不会被视为对用户修改权利的限制（详见第24章）。这一规定是为了使第三方能够在他们的软件版本中创造价值，从而产生能够支持软件进一步开发的资金流。

2.11 开源定义

我们已经看到，自由软件的4种自由集中体现了社会对软件自由的需求。尽管开源运动认为非自由软件不是理想的解决方案，但它用更务实的态度来对待自由软件，不再强调软件自由的价值要求，而是更认可协作的重要性。我们还应看到，尽管自由软件运动与开源运动在动机上有所不同，但它们在大多数实操方面的建议一致。

与FSF对应的开源运动组织是OSI。OSI制定了OSD，其中细化了开源许可证必须满足的如下10个要素。

1. 自由再分发

不得有任何限制阻止软件单独或与其他软件聚合之后进行分发。这包括不要求支付版税或其他费用。不过，与自由软件一样，这并不意味着开源是完全非商业化的。

2. 源代码

软件发行版必须包含源代码形式。这使得普通开发人员可以基于源代码重新构建与发行版一致的软件版本。

3. 衍生作品

许可证必须允许衍生作品可以在与原始软件相同的条款下分发。注意，这一要求并不包括与开源软件一起发布的其他软件，仅限于开源软件本身的衍生品。

4. 保持原生源代码的完整性

如果对修改后的源代码的分发有限制，那么必须允许分发“补丁”文件，以便开发人员能复用任何修改。除了品牌所有权不能分享以外，针对修改后的源代码构建的二进制文件的分发不允许有任何限制。

5. 不歧视个人或团体

许可证必须对所有个人和团体一视同仁。

6. 不歧视工作领域

许可证必须对所有类型的使用完全平等。

7. 许可证的分发

每个收到程序副本的人都应享有并履行许可证所赋予的权利和义务。

8. 许可证不得针对特定产品

许可证应该是通用的，不能仅基于特定的软件发布形式或特定产品的一部分生效。

9. 许可证不得限制其他软件

许可证不得影响与被许可软件一起分发的其他软件。

10. 许可证必须是技术中立的

许可证的任何条款都不应依赖于特定的技术或接口风格。

仔细比较OSI的10个开源定义要素和自由软件的4种自由，就会发现它们是兼容的。任何符合OSD的软件也满足成为自由软件的要求，反之亦然。正如我们前面讨论的，这两种运动的主要区别是哲学意义上的，自由软件运动是由社会需求驱动的，而开源运动是由实用主义驱动的。不同的动机产生了不同的用户类型，即每种模式都能以最适合的方式服务于各自类型的用户，但如今，这种区分在很大程度上变得不那么紧要了。

2.12 开放源代码促进会——一个务实的社区

开放源代码促进会（OSI）是一个非营利机构，成立于1998年，致力于推广开源软件理念，寻求在开源社区不同派别的支持者之间搭建沟通的桥梁。OSI将开源定义为“一种通过分布式同行评审和公开透明开发流程来驱动的软件开发手段，开源的期许在于更好的质量、更高的可靠性、更大的灵活性、更低的成本，以及对被垄断型供应商绑架的终结”。

OSI之所以使用术语“开源”而不是“自由软件”，因为后者已经与一个专注政治和哲学议题的群体联系在一起。OSI试图更注重于软件协作开发中的实用价值及其商业潜力。虽然OSI的倡导动机与FSF的动机大不相同，但两者最终都在推动自由软件和开源软件的发展方面达到了类似的效果。

作为一个开源标准化组织，OSI负责维护OSD及其相关商标，从而构建一种信任关系，使开发人员、用户、公司和政府能够围绕这一关系更放心地进行开源合作。如果要使用OSI商标，那么软件必须在OSI审查和批准符合OSD的许可证下分发。

OSI的使命是定义参与者可以基于自由软件和开源软件进行公开合作的条款，这比FSF仅严格界定自由软件的使命或仅构建宽松许可的开源软件的使命更为复杂（见2.14节关于ASF的案例研究）。OSI希望驱动生产落地和商业变现，在此过程中，要衡量所有加入者的利益并统一共同的立场显得非常困难。

由于各方难以达成广泛共识，因此出现了一个旨在促进开放合作的基金会本身却是一个封闭组织的怪诞局面。由于OSI的治理细则明确了无会员（通过赞助获得治理决策权）制度，因此所有的权利都归属于理事会。理事会由5到21人组成，每个人都是由现有的理事会选举产生的。2022年理事会有9名成员。这个制度在保障OSI完成OSD和相关许可证批准程序等艰巨任务上尚属适用，但要支撑基金会更进一步发挥作用和产生重大影响，则显得力不从心。

2008年，基金会试图对组织管理进行改革。OSI理事会邀请了50个人加入“初创会员”小组，其中42人同意加入。这个小组通过私人邮件列表开展工作，小组成员的会员身份从未公开。然而，这个小组在推动OSI组织管理变革方面并没有取得明显进展。

到了2012年，OSI启动了一个向会员治理架构过渡的计划。把“政府认可的慈善机构及非营利行业协会和学术机构”纳入一个免费的附属会员计划中。个人也可以缴纳少量会费成为“个人会员”。此外，过渡计划的第三阶段是邀请企业会员加入，但截至2022年这一设想尚未实施。至本书撰写时（2022年年底），这些会员类型仍未正式写入章程，并且对OSI的影响也未产生正面效果。

需要注意的是，由于OSI的工作成果并不能直接促进大多数商业化自由与开源软件公司的产品和服务的发展，因此基金会发现难以充分调动志愿者的积极性来作出重要贡献。OSI希望通过引入会员制度来获取更多资金支持，从而寻求更高的效能。例如，目前理事会希望在“专门、长期的有组织的布道和宣传”上获得资源支持，包括常设工作人员（或）组织职位等措施。

2.13 实用主义与伦理道德

开源运动的核心在于为软件生产者提供最大的灵活性。也就是说，软件生产者可以自由地做任何他们想做的事情，包括生产包含开源软件的非自由软件。另外，自由软件运动通过确保所有软件都支持4种自由（由FSF定义）来保护最终用户的自由。

当软件生产者选择只生产自由和开源软件时，用户便享有了这4种自由。然而，当软件生产者选择在专有（非自由）软件中包含开源软件时，这些自由至少会部分丧失。

开源运动接受了软件生产者将会继续生产专有软件这样一种现状。因此，开源运动的宗旨定位于确保所有软件生产者都可以基于开源软件进行合作，无论他们的产品所采用的许可策略如何。由于软件行业的很大一部分是构建在生产力稀缺的假象之上的（软件生产者通过限制性的许可类型来构建生产力稀缺假象），这种现状可能被视为一种必要的妥协。

尽管开源运动接受这种妥协的立场，但并不认为这种情况是理所当然的。10年前，本书第1版的本章作者还认为专有软件将会占据主导地位。随着数字化转型的脚步加快，越来越多的开发人员采用开源软件作为开发的基本要素，开源软件在代码库中的占比高达90%。开源运动的实用主义者意识到这种变化并鼓励软件生产者明确区分开源软件与专有软件之间的界限。

正是这种自行决定界限的能力提高了软件生产者参与开源项目时的灵活性。然而，如果没有互惠互利的开源贡献许可协议或Copyleft类的许可要求来确保开源软件的衍生品也是自由软件，开发协作的驱动力就不那么明显了。那么，是什么阻止了软件生产者从开源软件中受益但不为其作出贡献呢？

尽管无限制地共享和分发开源软件不会产生直接的财务成本，但选择不共享工作成果回馈社区的软件生产者也会付出代价。例如，开源软件的某个用户可能会构建一款与该软件的其他用户直接竞争的闭源产品，这种行为可能会损害那些选择开放合作的用户的业务利益。然而，就这种情况而言，拒绝开放合作的用户将承担其产品内所用软件的全部维护成本，而选择开放合作的伙伴将可以分摊软件维护成本。对于那些曾经背离最终又回到开源代码主分支的用户，他们背离的时间越长，积累的与维护相关的成本就越高。因此，随着时间的推移，合作带来的经济压力也会逐渐增加。

更为务实的开源运动支持者指出，基于生态经济学上的合作动力，随着时间的推移，越来越多的软件将自然而然地成为开源项目的一部分。虽然自由软件运动的支持者承认这一点，但是他们坚持认为，应该通过确保所有分发的软件必须遵循自由软件协议许可的方式来加速这一进程。

2.14 Apache软件基金会

ASF是一个极具影响力的开源组织。它不仅拥有开源领域内众多重要的开源软件项目，而且在孕育成功软件方面拥有悠久的历史。它提供了一个样例：一个拥有宽松型开源许可证的组织能够使用户优先选择使用开源软件，而以开源社区为中心的开发模式则可以确保所有参与者对项目发展规划具有平等的影响力。

在本节中，我们将看到这种成功背后的原因，这归功于初创者的努力，他们定义了一种尽可能包容的生产方式。例如，与FSF不同，ASF关注的是软件生产的手段，而不是对软件自由的法律保护。对于许多人，这不是一种理想的方式，但基于Apache超过356个的开源项目目录，这种方式已经被证明是成功且可复制的。

1995年2月，一个由8人组成的小组创立了Apache Group。此前，他们一直独立维护一套属于公共领域的NCSA万维网络服务器项目，但这个项目曾经一度中断。他们一直在分享开发思路和会议记录，并认为围绕这种小组合作，最好能建立一定程度的法律保护和一定数量的组织架构。于是，Apache许可证V1.0顺势而出，这是一个允许第三方以任何他们希望的方式使用代码的许可证。虽然组织结构是非正式的，但它为小组内部的协调和决策提供了一种手段。

到1999年，该小组已发展了21名成员，并吸引了一家跨国公司的注意，该公司希望在其主流产品中使用Apache Group的软件。然而，这家公司的律师担心许可证背后缺乏法律架构支撑。对此，解决办法是创建一家总部设在美国的公共慈善基金会（根据《美国税收法典》设立）。该基金会的使命是“为Apache社区的开源软件项目提供支持”。Apache项目的特点是协作、基于共识的开发过程、开放且务实的软件许可方式，以及创建领域内高质量软件的愿景。也许比愿景更重要的是ASF的标语“我们不仅仅是共享服务器资源的一组项目，我们还是一个由开发人员和用户组成的社区”。

这种对“由开发人员和用户组成的社区”的重视体现在ASF的章程及其旗下项目许可证的方方面面。ASF的运作只有一个简单的目标：确保社区中的项目开发人员能够专注于他们最擅长的事情——为所有利益相关者生产软件。ASF旨在为这些开发人员提供社会的、法律的和技术的基础设施支撑。

ASF非常强调协作的社会性。所有Apache项目都采用一种通常被称为Apache Way的开发模式。这是一种透明、开放且基于精英治理的模式，它定义了一套所有Apache项目都要遵守的细则。这些细则确保了在适当的管理框架下处理社区知识产权和贡献。熟悉Apache项目的人都知道，与项目管理的其他方面相比，社区的发展往往更受重视。例如，通过在所有项目中使用标准许可证，减少了与知识产权相关的法务管理成本，从而显著降低了单个项目遭遇法务问题的可能性。

ASF这类社区工作最重要的一个方面是持续推动确保平等对待所有成员。因此，ASF不为软件开发付费。所有对Apache项目作出贡献的人都被视为志愿者。这意味着项目内部不存在层级的管理架构，没有任何个人的意见会被认为比其他人的更重要。这是一个基于精英管理和共识决策的过程，章程中对此有清晰明确的规定，并且应用效率之高令人惊讶。这种志愿者之间的平等对ASF极其重要，并受到大力保护。正是这种平等允许任何人，无论他们拥有多少资源，都能以有意义的方式作出贡献，同时也能保护他们的贡献免受潜在的滥用。

ASF从经济学的角度论证了将贡献回馈给基金会在战略上是正确且合适的。也就是说，如果ASF软件的用户选择修改Apache代码而不将其贡献回上游，将会导致额外的维护开销，而这种开销对其他贡献回上游的用户是不存在的。这意味着竞争对手能够通过积极参与社区，利用较低的开发和维护成本进入市场，并从中受益。在很多情况下，这种成本优势可以使他们的产品在市场上更具竞争力。

传统上，Apache项目聚焦基础设施组件的开发，它们更容易以衍生产品形式被重用而产生边际效应。然而，在2011年，该基金会以Apache OpenOff ice的形式创建了第一个重要的终端用户项目。这套生产工具的目标是打造一款多功能的套件产品，以供安装和使用。这款面向终端用户的产品在ASF上的成功证明，Apache模式也适用于基础设施项目之外的软件开发。

ASF创建了一种架构，该架构能成功且可复制地生产开源软件，并为现代商业带来巨大价值。Apache软件广泛应用于大型互联网商务网站、社交网络、航天飞行器与控制中心、政府机构、学校、银行，甚至儿童玩具。很难想象有哪台计算机没有嵌入Apache软件。所有这些成就都是通过提供一个真正中立的合作空间来实现的，这一空间由开源许可证支持，并采用了一种既高效又公平对待所有参与者的精英管理的、自下而上的决策模式。

2.15 开源治理

OSI将开源描述为“一种通过分布式同行评审和公开透明开发流程来驱动的软件开发手段”。需要注意的是，这个定义并没有提到许可证。尽管如此，没有人会质疑开源许可证的重要性。一旦版权应用于计算机软件，需要遵循4种自由或由OSI/OSD批准并定义的许可证。然而，开源的意义远不止于许可证。

为了充分挖掘开源（或项目部分开源）作为开发方法的潜力，我们还需要考虑“治理模式”，即如何管理项目。一个清晰的治理模式可以确保所有贡献者理解如何参与，明确他们的期望是什么，以及对他们作为贡献者的权益受到哪些保护。也就是说，它界定了参与和决策的规则。

开源许可证提供了一个合作的法律框架，而治理模式为这种协作提供了社交/沟通的框架。开源许可证和透明治理的结合是开源成功的原因。那么，什么是优秀的治理模式呢？

2.16 人与过程

开源治理模式不需要，实际上也不应该是一份试图涵盖所有可能场景的复杂文档。随着时间的推移，治理模式会逐渐演变为一系列文档的集合，确保即使在社区成员发生变动的情况下，项目的工作完成度和持续性也能得到保障。它可能从几个流程开始，并随着项目的成长而发展。它以一种流程记录的方式将社区文化传递给新成员。它可以防止项目因机构知识固化在少数成员的头脑中而陷入僵局。它是涵盖最常见社区作业流程的指导性文档，仅此而已。此类作业流程的样例如下。

• 如何提交一个bug。

• 如何建立一个新的功能特性。

• 如何发起一个补丁提交或拉取请求。

• 如何决策软件项目新版本中包含的功能特性。

• 如何构建软件项目的新版本。

社区治理流程的制定者应该认识到，书面规则既可以是使能型的，也可以是约束型的。这些规则赋予了作业流程可预测性和可重复性，但同时也可能引发社区对变革的抵制，甚至对急需做出改变的需求视而不见。社区治理的目标是营造一种环境，使成员能够长期自在地为项目作出贡献。社区治理流程应该通过自发的演进而向前发展。

事实上，大多数软件开发人员希望能够以高效的方式完成任务。在社区主导的开源项目中尤其如此。因此，一个好的治理模式不仅可以增加灵活性，还能够强化精英个体在具体活动中的领导力，以及预防乃至偶然解决冲突。

然而，这反过来也会带来问题。许多人认为在一个自我指导、自下而上的协作环境中工作很有挑战性。这时领导力就该派上用场了。在开源项目中，领导的角色不是传统的指挥与控制，而是授权他人并共同实现目标。

针对社区主导的开源项目，人们普遍担忧的一个问题是它们可能会迅速陷入无政府状态，因为它们采用的是自下而上、无领导的协调方式。在自下而上的自由和自上而下的强控制之间找到恰当的平衡是很难的。而这也正是治理模式发挥作用的地方。它为协作提供了社会学框架。它赋予那些只想把事情做好的个体以权利并提供了解决社区死锁/僵局的机制。

开源许可证只是治理模式很小的一部分。正如我们前面所讨论的，一些许可证在法律上强制要求共享修改后的代码，而另一些则依赖于经济和社会压力来促动代码共享。选择正确的许可证和合适的项目治理模式对于开源项目的成功至关重要。理解开源项目在社会治理方面必须做出的某些选择非常重要。

2.17节和2.18节概述了社区中常见的两种治理模式的例子。这两种模式似乎截然不同。第一种模式是仁慈的独裁者治理模式，在这种模式下单个个体拥有绝对的权威；第二种模式是精英治理模式，该模式基于价值的贡献来分配领导权威。一旦理解了这两种“极端”，就会发现，在实践中，它们并不像最初看起来那样不同。

2.17 仁慈的独裁者治理模式

仁慈的独裁者（Benevolent Dictator，BD）是指在开源项目决策过程中拥有完全控制权的个人。其中，Linus Torvalds也许是最为人熟知的“仁慈的独裁者”。担任BD并非易事，需要具备科技外交能力、社区建设技能，以及对项目各个方面深入的技术理解，加之非比寻常的热情和奉献精神。然而，正如Linus在Linux 内核项目中所表现的那样，这种模式卓有成效。

BD模式在很大程度上基于这样一个事实：开源许可协议允许任何人获取开源代码并创建自己的分支或项目。这意味着，尽管领导者可以完全控制自己的项目，但他们仍然需要努力确保满足社区的需求。如果做不到这一点，则可能导致社区分化，因为反对者会基于相同的代码建立自己的项目，而社区也会随着不同的代码库分支而分化。因此，一位希望构建充满活力的社区项目的BD必须确保每个决策都能得到尽可能多的社区成员的理解和支持。因此，科技外交能力、调解能力和有效的沟通只是BD所需软技能中的3项。

尽管从技术角度来看，BD通常具备非常高的技术造诣，但他们未必是每一项技术决策的最佳人选。一位优秀的BD能够认识到这一点，并会积极寻求在社区最有经验成员们的指导下，由各方共同作出决策。当社区无法达成共识时，BD将会干预并作出他认为最合适的决策。通过这种方式，可以避免项目因过度犹豫而陷入停滞。

因此，BD的工作是解决社区内的争议，并确保项目能以协调一致的方式推进。反过来，社区各方也会通过积极参与和贡献社区来影响BD的决策。因此，BD模式具有一定的灵活性和扩展性，因为在大多数情况下，社区的发展并不依赖于BD的直接干预。

通常，BD是自封的，他们通常是项目的发起人或其指定的继任者。许多时候，BD的角色与独裁无关，更多的与领导力和科技外交能力有关。关键是确保随着项目的成长，合适的人（那些赞同BD的愿景的人）能够被公认为社区领袖。在一个项目中没有跟随者或没有持续跟随者的BD很快就会发现这个项目已经分叉，他们也被夺权了。

2.18 精英治理模式

在中心化的治理模式中，单个人对贡献进行把关往往会成为瓶颈。精英治理模式识别到了这一点，并提供了一种明确的机制来应对这一挑战。通过这种机制，个人可以获得对项目的直接影响力。获得影响力的过程与通过工作地位、经验能力或财务捐赠来获得“权利”的方式截然不同。在精英治理模式下，任何以积极方式作出贡献的人都能获得同等的权利。这种以贡献为尺度来衡量并赋予个体权利的过程非常有效。此外，它将摩擦降至最低，因为它使人认识到权利和影响力是稀缺资源。新加入者被视为需要帮助的志愿者，而不是想要攫取稀缺资源的竞争者。真正的精英治理模式不存在其他模式中常见的对贡献进行人为筛选的情况。这种人为筛选的一个例子是用现金而不是技术贡献来换取影响力。这种非人为的筛选机制可以吸引尽可能多的贡献者，他们为了一个共同的目标而凝聚在社区中。如果管理得当，这个过程会创造一个生态系统，在这里，每个人，无论其在项目外的关系如何，都可以开展合作。然而，因为没有明确的领导者，所以需要一套明确的规则来支撑社区运作。如果参与规则不够明确，通常会导致一种结果：这种模式看起来更像是自上而下的领导模式，而不是自下而上的社区模式。

精英治理模式通常是无领导的。也就是说，在任何一个特定情境中，最有能力引领的人将会成为事实上的领导者。人们通过行动而不是权利来领导他人；他们并不比其他参与者拥有更多的权利。这种安排通常会让新加入者认为，由于无法作出决策，项目将不可避免地陷入停滞。然而，在一个健康的精英治理模式中，即使是那些缺乏经验的成员也可能通过实际贡献推动既定目标的实现。由于所有工作都是公开进行的，因此那些经验丰富（但时间较少）的成员可以提供反馈意见。如果反馈被接纳，则将被识别为有价值的工作，并被包含在最终的产出中。幸运的是，在软件开发领域，绝大多数决策错误都比较容易修正。只要及时发现并纠正错误，就可以以最低代价完成调整。因此，软件项目中的大多数决策都是通过一个被称为“懒人共识”的过程作出的。在这个过程中，社区天然地假设任何具有优秀品质的人都会带着良好的愿景去采取行动。社区快速地审查所有的行动，如果有必要，会提出反对意见并进行讨论和采取相应措施。万一无法达成共识，可以有针对性地制定冲突解决方案。

在开展工作之前，那些潜在的有争议的行动可能会被提交给社区进行反馈和批准。这样做能够在工作实施前确保成员达成共识，从而减少“回滚”次数。由于积极参与者已经熟悉如何达成共识，因此不需要制定硬性规则来管理这一过程，只需要确保所有行动及其动机完全透明。

2.19 许可证选择和知识产权管理对治理模式的影响

仁慈的独裁者治理模式展现的是一种组织架构简洁、运作高效的工作模式，但其缺点在于只有在找到合适的领导者时才能体现优势。同样地，精英治理模式虽然不依赖于单一项目领导者，但它带来了更复杂的运作架构，需要加强治理流程。

仁慈的独裁者治理模式的一个潜在缺点是，它要求社区完全信任一个核心人物，无论是当前还是未来。对于许多人，这种对核心人物的依赖会给项目带来风险，因为个人状况或利益相关者的目标会发生变化。而在精英治理模式中，贡献者不需要将信任寄托在个人身上，但他们至少需要积极地监督社区动态，以确保这些动态与自身的目标保持一致。开源许可框架允许任何社区成员“分叉”项目，并将其转化为自己的项目，这在某种程度上保护了社区。但是，在精英治理模式下，开源许可证的选择及对贡献者知识产权的处理方案可能对社区成员的信心产生重大影响。

作为许可证选择、知识产权管理和项目治理之间相互作用的一个例子，我们考虑这样一个场景：通过采用Copyleft许可协议，并结合贡献者版权授权转让机制，开源项目的法律控制权得以中心化。需要注意的是，获得对开源项目的完全控制权并不困难。BD在社区项目的决策过程中实施了这种完全控制权。当开源项目的法律和社区控制权都被专制化之后，就有可能出现与社区利益相悖的行为。在极端情况下，这将意味着版权所有人可以将社区未来所有的开发成果变为专有，而第三方贡献者却仍然受限于Copyleft开源许可的原始约束。因此，那些掌握中心化决策机制并以Copyleft许可项目“所有人”身份行事的人可能从中获取巨大的潜在利益。

为了将风险降至最低，人们可以寻求不同的方式来管理第三方贡献的版权。例如，与其将所有权集中在一个可能被收购的组织中，不如将其托管给一个合适的非营利机构。这可以确保社区安全地保管所有贡献，例如，没有人能从非营利版权的所有人手中购买版权资产。或者，人们可以从一开始就避免把版权所有权集中化。具体做法是，只需贡献者能够对自己的贡献授予重用许可，而不是一开始就将版权授权转让给一个集中的所有人。在这种情况下，代码的重新授权需要得到所有贡献者的许可。

通过采用宽松型许可证而不是Copyleft/保护性许可证，也可以将社区领导者未来进行闭源开发的可能性降至最低。这并不妨碍基于开源的专有衍生品的构建，但这意味着所有社区成员都拥有这样做的权利。但是，在这种情况下，问题已经从法律层面转移到社会层面。正如我们在前面的章节中所看到的，需要仔细权衡开源软件的实用主义与自由软件的道德伦理标准之间的精妙关系。

表2.1呈现了基于不同许可证和版权所有权组合下的多种项目治理类型的概览。值得注意的是，还有第三种许可类型，即“部分Copyleft”，表中并没有提及。常见的“部分Copyleft”许可是GNU宽通用公共许可证（LGPL）。该许可证要求旗下的任何衍生品都应基于LGPL守则发布，即它是Copyleft/保护性许可的。然而，与完整Copyleft许可证不同（如GPL），LGPL允许其代码可以未经修改地包含在专有产品中。为了简化讨论，本节并未涵盖这种许可证类型。这样处理的合理之处在于，FSF本身也不建议把“部分Copyleft”许可证作为常规选项（尽管事实上FSF是LGPL的作者）。第3章将深入讨论授权许可并在第4章中介绍实际应用。

表2.1 不同许可证和版权所有权组合下的多种项目治理类型

许可证选择与项目治理之间的诸多错综复杂的关系超出了本章的讨论范围。我们在这里的意图是通过一些例证，简单地强调两者之间的相互关系。当你继续阅读本书时，会发现开源软件开发的法律模型和社会模型之间存在更多的交叉依赖关系。

2.20 行为准则的兴起

在过去十年间，一种治理思潮逐渐兴起并得到广泛传播：开源项目应具备行为准则或遵循规范。这股潮流可能是多个行业治理理念在开源社区的体现。

在过去几十年间，我们见证了越来越多的公司开始制定这样的行为准则。这些准则有时以商业行为准则或商业道德标准的形式出现，并常常围绕“信任”或“诚信”的主题构建。优秀的领导者深知，在与员工、客户或合作伙伴建立关系时，设立愿景和期望的重要性。

大量研究和各行各业的共识表明：多元化的团队为公司的长期发展创造了更多价值，并对公司的价值观产生显著影响。虽然早期的研究可能仅局限于探讨性别多元化带来的影响，但近期的研究已经以更精准的方式证实了多元化团队对价值观的影响。由于软件开发是一个由男性占主导地位的行业，因此早期的软件协作也表现出了一定的不平衡性。

由于这些社区以在线形式开展运作，因此交流与协作通常依赖于电子邮件分发列表、在线论坛和聊天室。在没有公司负责管理这些沟通平台的情况下，加上许多沟通平台允许参与者完全匿名，很多讨论可能会演变为个人胜负欲的争辩，变得咄咄逼人，甚至涉及人身攻击。即使参与者彼此熟悉，依然存在许多记录在案的讨论事故，相关的谈话风格会直接变得生硬到无礼。这样糟糕的行为可能会对项目产生持久的影响。一个真实的案例表明，虽然行为恶劣的参与者最终会被驱逐出社区，但社区的整体参与度因此下降了20%，且再也没有恢复。[68]

[68]　 D. Berholz，“Assholes are Ruining Your Project ”。

开源项目的支持组织成为第一批支持行为准则的地方，因为组织者鼓励更多元化的参与者加入，并将这种风格贯彻到项目运营中。一些早期的项目运营者也意识到，在更新项目团队成员——替换退休成员、引入新成员时，需要更加多元化的参与者，包括项目的维护者。如今，运作良好的开源项目通常都会采纳一套行为准则。非营利组织也鼓励其下属的开源项目制定并遵循这样的行为准则。

贡献者公约被公认为一个良好的行为准则样本。从2014年起，就有组织在维护该文件并发布新版本。它的更新通常反映了开源社区的新动态，并且该公约自身以开源项目的形式运作（采用基于文档的知识共享许可——CC许可）。

随着越来越多的项目采用这样的行为准则，相关的最佳实践也在不断涌现。一个有趣的案例发生在2008年，当时在一个已经拥有行为准则的大型社区中，他们没有关于如何处理报告的行为准则违规事件的政策。面对突发情况，该项目的主要组织者迅速行动，在几天时间内制定了相关政策，以便能够快速且果断地处理出现的问题。

2.21 开源的商业价值

在开源社区的运营和治理方面，我们研究了协作共建社区和自由授权共享的模式。关于这些模式在商业环境中的应用和论证将会在第16章中详细阐述。宏观上，企业在开源软件的应用上主要采用两种模式：一种是作为开源软件的消费者参与，另一种则是作为开源软件的生产者参与。不难看到，一家在软件投资组合上涉猎广泛的企业兼有这两种模式。随着时间的推移，许多公司会经历从消费者转变为生产者或贡献者的转变，这一过程将在第19章中进一步讨论。

在本章前面的GCC例子中，通过“借用与共享”的概念，我们看到了消费开源项目背后的简单经济学原理。这是快速获取价值的一个途径，但随着时间的推移，企业要为软件组件的工程开发和维护投入资源。这种方式也是创新的重要来源。Red Hat公司及其Linux企业发行版便是最好例证之一，尤其是通过其Fedora社区发布项目。Red Hat公司在Linux内核社区的适度投资产生了巨大的收益。

Kubernetes项目是现代开源合作的一个杰出范例。通过将Kubernetes项目组件引入到他们的产品和服务中并销售给客户，许多公司不仅消费了开源项目，而且促进了Kubernetes项目不断演进和发展，使其社区充满活力。这个开源项目是由Google公司发起的。Google公司围绕该项目投资并构建一个充满活力、多样化的社区生态系统。该项目的知识产权由非营利组织云原生计算基金会（Cloud Native Computing Foundation，CNCF）中立持有，从而给其他合作伙伴和项目成员以信任感：项目所有权和信息管理处于一个公平的竞争环境。许多企业利用Kubernetes的组件来构建自己的编排服务，并在其中加入自有的网络和存储、管理门户和计费服务系统。CNCF和Kubernetes作为开源领域的优秀案例，已经成为当今云计算的重要支柱之一。

如今，围绕Kubernetes的产品估值已达到数万亿美元，而基于CNCF云原生项目的投资则高达数百亿美元。通过这种方式，Linux操作系统成为当今大部分服务器市场的核心，而Kubernetes也占据了云基础设施的大部分市场份额，它们不仅创建了社区，而且创建了生态系统。

项目与产品之间的区别是关键所在。Mårten Mickos担任MySQL公司首席执行官（Chief Executive Off icer，CEO）时提出了以下观点。

社区有时间，但没有钱；而客户有钱，却没时间。社区项目不等同于客户产品。与开源项目合作的公司需要知道什么时候与社区成员互动，什么时候与客户沟通。这两者基于不同的目标和衡量，因此对话和交流的方式也截然不同。

当一家公司或公共机构开源自己的软件组件代码时，需要深思熟虑。宏观上，一家主要通过软件开发向客户提供解决方案的公司通常会构建以下3种类型的软件。

• 软件开发环境和工具：用于构建面向客户的服务和产品的软件工具。

• 附属产品/增值服务：支撑公司的核心产品和服务的软件，可构建更丰富的客户体验，并增加产品和服务的黏性。

• 核心竞争力：公司为客户提供解决方案的核心软件部分，有时也被称为独家供应商产品。

投资建设围绕“开发环境和工具”类型项目的社区可以轻松带来不菲的回报。一个典型例子是Netflix开发的Spinnaker——一个持续集成/持续交付（Continuous Integration/Continuous Deployment，CI/CD）开发作业流平台项目。Spinnaker与Netflix的核心业务（即向客户提供流媒体视频服务）毫不相干，其核心价值是使能软件开发。通过更广泛的共享和使用，Spinnaker创建了一套软件工具集和问题解决方案套件；用户在新的环境中对Spinnaker进行压力测试并将问题和需求回馈给社区，这种方式成为创新的重要来源。社区既可以作为文化输出的窗口，也是领域驱动设计中问题域（包括客户需求和痛点）的收集和调研平台，促进了成员的自我筛选和招募过程变得更顺畅。但公司几乎不需要承担任何风险或责任，因此建立一个社区的价值是显而易见的。

“附属产品/增值服务”类型项目的一个典型例子是微软的Azure CLI。它是一个为用户使用/管理微软公司的Azure云服务提供命令行接口的开源项目，从而让用户不再依赖Azure的portal管理页面来使用/管理云服务。通过投资构建这样一个社区，企业可以实现深度的合作伙伴参与和客户共创，使得伙伴和客户更加认可微软公司的核心技术，并增强了与微软公司产品的黏性。你可以在很多公司的大型项目中看到这样的案例，如微软公司的VS Code和.NET Core，以及RedHat公司的OpenShift。

主导开源项目的公司在社区建设方面需要的是长期且持续的投入，并根据预期回报增加投资，这种基于社区的投资要锚定在核心产品和服务上。在当今世界，个人开发者可能不再倾向于购买软件，但数据中心的运营部署需要构建在可靠的和广泛使用的可信赖的软件产品上。

围绕公司对客户的核心价值，通过基于OSI定义的许可证发布开源软件项目（并可能构建开源社区），需要在开源方面有深入的实践和丰富的经验。这使得企业能够将客户解决方案中“软件”本身的价值和客户感知到的解决方案的价值区分开。30年来，Red Hat公司在这方面做得非常出色。大约10年前，Red Hat公司从“让Red Hat Linux成为最好的Linux发行版”的竞争中抽身，转向“让Red Hat Enterprise Linux（RHEL）成为数据中心中适配Intel服务器的最具性价比的UNIX”的定位，以应对市场的转变，并向云服务或平台转型。随着客户的需求变化，Red Hat公司的Linux操作系统不再是安装在本地的操作系统（或预置操作系统）。在这个新场景下，关于Linux操作系统作为一个自由授权项目的开放性价值与RHEL作为付费产品的商业价值之间，用户并没有产生任何争议。

同样，Red Hat公司精心管理其旗下的商标和品牌。它为企业版和社区版的品牌选择了截然不同的发展路线，以确保客户能清晰地理解商业产品交付的价值是不同于社区版本的。虽然在社区项目中使用公司品牌而不是商业产品的做法可能会进一步导致客户和社区成员的混淆，但是仍然有一些公司在创建开源作品/项目时使用了和商业产品相同的品牌，这在处理商标及其对应的品牌价值上带来了挑战。详见第9章关于商标和第16章关于商业模式的讨论。

Theodore Levitt的一段话可以很好地描述这种挑战：“人们不想买一个四分之一英寸[69]的钻头。他们只要想要一个四分之一英寸的孔！”你需要确保你能理解客户的痛点并提供解决方案，并能讲清楚解决方案本身的价值而不是其包含的软件的价值，这样你才能够基于对客户的核心价值主张而拥有一个健康的开源项目。

[69]　 1英寸等于2.54cm。

管理公司主导的开源社区并保证它健康运转可能是一项挑战。项目的开发环境和工具链很容易归入工程部门的管辖范围之内。附属增值项目需要跟产品对齐并达成一致。核心项目关系到公司的生死。公司经常在附属增值项目和核心项目上犯错，认为从社区项目成员到付费产品客户之间存在某种自然的转化率。

这种错误认知可能源自对Geoffrey Moore的鸿沟隐喻的误解。[70]Geoffrey Moore的模型强调：在技术采用的钟形曲线上，最先进产品的首批客户与较为保守、风险规避性较高的大多数早期客户之间有一条鸿沟。他提出了一系列跨越“鸿沟”的策略。一些公司试图通过开源其解决方案的核心代码来吸引新技术的早期用户。

[70]　 G. Moore，Crossing the Chasm,Third Edition。

然而，早期项目用户的问题在于他们并不是客户。他们贡献宝贵的时间（但根据Mickos的说法，他们“没有钱”）来验证项目技术，却没有提供面向客户的有价值的解决方案。事实上，早期经验丰富的社区成员可能很乐意用自己的时间来解决技术问题，但他们永远不会成为客户。此外，他们还有可能进一步混淆公司的实际客户和合作伙伴。试图向这些社区成员推销产品只会激怒他们。当然，一些早期客户可能会出现在项目社区中，以验证技术（作为项目），并利用项目社区早期的投入来解决自己的问题，然后对购买产品产生兴趣，但如果软件公司不知道如何创建有效途径来将社区成员与客户分开，这将令所有人头痛。

建立在公司核心价值主张之上的开源项目经常会面临一些尴尬的社区动态。本章前面关于社区建设和治理的所有讨论都假定了社区初创者想要建立一个平等社区（所有参与者都是平等的）的诚意，即使这个社区的治理模式是仁慈的独裁者模式。拥有核心价值主张项目的公司可能很难在价值的判断上将产品特性与开源项目功能区分开。这些公司拥有项目资产的大部分所有权，并需要推动业务增长。

• 如果公司试图围绕基础功能运营开源项目，但通过出售“企业版”功能（有时被称为开放核心业务模式）进行商业获益，往往会遇到潜在的合作伙伴和成熟的终端用户试图将企业版的功能特性贡献到开源项目中，而不仅仅是成为正式的合作伙伴或付费客户。

• 合作伙伴希望基于共同投资、共同营销和共同销售的模式建立合作关系。他们通常不满足于仅为OSI许可下的项目作出贡献，因为这样做只会让持有该项目的公司获得主要利益。

• 竞争对手和潜在合作伙伴可以直接使用基于OSI许可证的项目技术/代码来全面支撑他们的客户，而无须与项目发起人建立共同发展和利益分享的合作伙伴关系。

• 竞争对手和潜在合作伙伴可以基于许可授权的开源项目代码在产品和服务中进一步推出自己的特色功能，以增强竞争力。

• 考虑到短期投资回报的风险，投资人也可能会促使公司在选择附属增值类开源项目和核心功能开源类项目上采用上述策略。面对这种情况，社区可能会通过抗议和分叉作为回应，就像2021年初Elastic所经历的那样，这将成为不可避免的结果。

如果拥有开源项目的公司试图过于严苛地限制社区讨论，而社区成员又没有真正参与项目贡献，那么这可能向客户传递这样的信息：企业的解决方案为客户提供了开放代码库和开放创新权益，但不是以共享源代码或公开代码的方式开源。

如果公司已经投资建立了一个充满活力的社区，过度限制可能会引起社区中意见领袖的不满。如果这些限制措施施加的压力过大，公司就有可能面临社区成员分裂出独立分叉的风险。在过去25年间，基于项目的开源社区鲜少因压力过大而分裂，但如果社区内外压力条件激发到一定程度，分裂就会发生，2021年Elastic事件便是这种情况的一个例子。

近年来，一些依赖于开源项目作为其核心解决方案的公司感受到了紧张感和压力。这导致这些公司不得不用非OSI框架的许可证重新授权软件。他们的投资人失望地呼吁重新评估OSD。OSI基于这一领域的持续确定性的需要，对这种重新评估需求非常坚决地说“不”。

还有一种鲜为人知的开源替代方案——采用共享源代码或公开源代码的方法。从本质上看，这些替代方案没有开源许可，只有专有许可，而且也不太可能建立社区或从中受益。尽管在过去几年间，这些观念得到一些发展，但2021年Elastic转向专有服务器端公共许可证（Server-Side Public Licence，SSPL）表明这种方法并未取得真正的效果，这可能是因为缺乏开发者社区的参与。此外，这些替代方案似乎不太可能真正获得动力并向前发展。

创建软件开发环境类或附属/增值服务类的开源项目是连接合作伙伴和客户，在工程领域开展联合共创的强大工具。公司在发布此类开源项目时，需要慎重考虑如何传达项目的核心价值主张以及后续的发展规划。这些问题将在第16章中详细讨论。

所有这些都可以归结为一个简单的观点，即开源项目是获取价值和激发创新的强大工具，社区参与是保护和增长投资的好方法。但归根结底，软件公司仍然需要持续运营开源业务。这一点可通过对上市公司的公开招股书的简单对比得出结论。

Red Hat公司在2019年的年报中表示其毛利率为84.91%，相比之下，专有解决方案的领先供应商微软公司截至2022年6月30日的年报显示其毛利率为64.4%。苹果公司是由专有软件支持的领先硬件供应商，在同一时期的年报中表示其毛利率为43.31%，与此同时，软件服务提供商Google公司在年报中表示其毛利率为56.75%。所有这些公司都使用开源软件并为其作出贡献。尽管上述公司的产品都能在开源许可的框架下获得，但只有其中一家公司被认为是真正意义上的开源软件企业——Red Hat公司。因此，即使在商业策略中将开源作为核心策略需要经过仔细考量，但它的价值是显而易见的。

2.22 开源非营利组织

在本章中，我们已经讨论了一些非营利组织的角色和贡献。这些组织通过提供有价值的组织架构和基础设施来支撑开源项目和社区成功运作，并使开源项目在后续商业应用中取得巨大成功。从历史的角度看，每一个开源组织的建立都是应时应势的结果，都是为了应对当时特定挑战而进行的实验。随着开源组织遍地开花，进行一次全面的审视显得尤为重要。我们坚信，理解这些非营利组织的架构和作用，将会产生更好的洞见。

成功的开源项目社区致力于构建一个项目引流通道，以吸引用户、开发人员（其中许多人会根据自身的需要进行技术尝试，而不是去开源社区作出贡献）进入，并最终希望激励开发人员成为社区贡献者。社区贡献是成功开源项目的生命线。

然而，当项目发展到一定阶段后，公司希望成为项目的用户和贡献者时，在参与社区项目的过程中，其对风险管理的关注度要远高于开源许可的框架下的项目的临时参与者。与此同时，随着项目的推进，项目维护者的责任也随之增加。这两个因素限制了项目的成长空间。而非营利组织的法律架构可以有效地缓解这些问题。

• 非营利组织的组织框架消除了社区项目的维护者和知识产权所有人的个人责任。

• 非营利组织用中立的方式优化了以版权和商标为核心的知识产权管理。

通过解决这些挑战，具有较高风险管理需求的公司可以把开源项目组件转化为面向客户的产品和解决方案，并回馈这些开源项目。这样不仅扩大了用户和贡献者的范围，也可能扩展了维护者的群体。根据开源项目的性质及其在产品中的使用情况，在扩展贡献者群体时，可以通过引入全职开发者来实现这一目标。

这个过程并没有创造新的市场，但它能扩大项目社区的影响力，并吸引更多的参与者加入。非营利组织可以确保代码库的安全性和可信赖度，进而助力形成市场。从市场设计的角度看，非营利组织可以使市场空间变得更大、更安全。

非营利组织拥有银行账户，可以签订合同（例如组织会议等），可以提供标准化的基础设施服务，还可以提供知识信息的传递和培训服务。从市场设计的角度看，非营利组织可以让信息在所有项目参与者（用户、贡献者、维护者）之间自由流通。

在过去20年间，一类作为会员机构设立的非营利组织模式出现了，它允许公司级别的会员联合投资支持使用开源许可证的项目。这类组织不仅为增长提供了服务，还为消息传递提供了平台，同时为企业提供反垄断保护。这些将在第18章中详细探讨。

所有这些听起来都像是对开源项目的巨大促进，但仍然有以下一些事项需要考量。

• 工作需要一步步落实。同样地，一个开源项目的成功与否取决于参与者是否愿意为之工作，非营利组织也是如此。

• 建立法律框架和基础财务服务是有成本的。需要有一群基金赞助者来投资创建和运营非营利组织。

• 增长依赖于健康的项目。非营利组织无法改善不健康的社区文化氛围。事实上，无论这种文化健康与否，非营利组织都会放大现有的文化特征。

• 如果由公司主导的开源项目被纳入一个非营利组织框架，并且在社区管理和项目及产品定位上存在冲突，那么非营利组织解决不了这种文化上的不匹配问题。

事实上，一则消息可能会使多个项目陷入困境。非营利组织成员经常在组织内部围绕项目创建一套信息传递体系。对于非营利组织，构建这样的信息平台比支持专有项目更加关键。

非营利组织是开源生态系统中重要的一部分，理解它们的功能和局限性十分重要，这些将在第18章中进一步讨论。

2.23 小结

我们在开源软件中看到的这种协作模式并不是一个新概念。早在人类捍卫自己领地的时代，就已经存在为了个人和团体的利益而形成的协作理念。虽然专有软件团队可以选择超越其组织边界进行合作，但在这些案例中，共享是个例外而不是规则。

相反，开源软件社区和商业团队默认将共享置于核心位置。这是因为软件复制并不消耗稀缺资源。此外，参与开源社区的公司认识到，由于其大部分产品可以标准化，因此能够以最低成本与合作伙伴共享，从而有机会降低企业业务的初始生产成本和持续维护费用。

这种软件生产模式成功的基础是采用开源许可证。这种许可证保护每个参与者免受不公正利用，确保所有贡献者都处于平等的地位。为了做到这一点，人们需要仔细考虑所选择的许可证，并确保软件在选定的许可证下发布。第3章将详细探讨开源许可证的作用。