提升企业开源开发有效性和影响力的路线图

2024年2月21日 · 阅读需 64 分钟

提升企业开源开发有效性和影响力的路线图

2023 2月

Ibrahim Haddad 博士

战略计划副总裁（AI 和数据）

序言：Jessica Murillo，IBM 副总裁兼交付实践负责人

Foreword..................................3

Introduction................................5

Hire developers from the project’s community........................... 7

Support and allocate time for upstream contributions........... 7

Create a mentorship program..........................................................8

Offer training.........................................................................9

Participate in and host open source events.................................9

Provide a flexible IT infrastructure .................................................9

Track developer code contributions ............................................. 10

Identify focus areas with a broad impact................................... 10

Foster internal collaboration.............................................. 10

Implement inner sourcing practices ..............................................11

Recommendations and lessons learned......................................12

Be patient.............................................................................12

Embrace a flexible IT infrastructure ..................................................12

Adopt proper success metrics...........................................................12

Use a lightweight approval process ....................................................12

Share information........................................................12

Make strategic contributions .......................................................13

Partner with product teams..........................................................13

Grow open source talent....................................................14

Conclusion.............................................................. 15

Acknowledgments.........................................................17

Feedback........................................................................17

Linux Foundation resources .............................................17

About the author.................................................... 18

Foreword

序言

“In real open source, you have the right to control your own destiny.” – LINUS TORVALDS, CREATOR OF THE LINUX KERNEL

“在真正的开源中，你有权掌握自己的命运。”

-- LINUS TORVALDS，Linux 内核的创始人

A lot has changed in the past 20 years since technology companies, like IBM, began their open source journey. In the first 10 years, enterprises started by contributing to open source projects to help fill their needs; they made strategic investments in technology, collaboration and communities and built an entirely new ecosystem. In the next 10 years, we saw the emergence of hyperscale cloud providers and Fortune 500 companies that shifted from being passive consumers to proactive participants in open source communities. This heightened collaboration spurred even faster innovation.

过去 20 年间，自 IBM 等科技公司开启开源之旅后，发生了许多变化。在最初的 10 年里，企业开始通过贡献开源项目来满足自身需求；他们对技术、协作和社区进行战略性投资，建立了全新的生态系统。接下来的 10 年，我们看到了超大规模云提供商和财富 500 强公司的出现，它们从被动的消费者转变为开源社区积极的参与者。这种加强的合作推动了更快的创新。

We have learned that companies who only participate in open source on an ad-hoc basis cannot achieve long-term success. The key is for companies to take a more structured, enterprise approach, putting open source at the core of their technology strategy. To truly benefit from the open source community model, each contributor is responsible for making the necessary investments in those communities. This includes providing open source developers from your company with the proper tooling, training, and mentoring to become strong community contributors and grow into leaders. It means we need to work together to solve not only the problems that scratch our own itch, but by broadening the scope of influence and focusing our time and talent to improve the code base and remediate issues in open source software if they arise. That is what it means to be a good member of an open source community.

我们已经深刻意识到，仅仅偶尔参与开源项目的企业无法获得长期成功。关键在于企业采用更具结构化、更具企业化的方法，将开源置于其技术战略的核心。为了真正从开源社区模式中获益，每个贡献者都应该对这些社区进行必要的投资。这包括为来自贵公司的开源开发人员提供合适的工具、培训和指导，帮助他们成为强大社区贡献者并成长为领导者。这意味着我们需要齐心协力，不仅要解决自己迫切的问题，还要拓宽影响范围，将我们的时间和才能投入到改善开源软件代码库和修复出现的漏洞上。这才是成为一个优秀开源社区成员的真正含义。

This document provides an overview and step by step guide for companies to engage in open source development, no matter where you are on your journey.

本文档为企业参与开源开发提供了概述和分步指南，适合于在开源路上的每一家企业。

JESSICA MURILLO

IBM 副总裁兼交付实践负责人


Be patient and seek out influential peers when growing your domain expertise, open source methodology, and working practices.	Practice and encourage an open and collaborative mindset when implementing open source infrastructure.	Adopt IT infrastructure that is flexible and supportive of open source development.
在发展领域专业知识、开源方法和工作实践的同时，要有耐心并寻找有影响力的同行。	在实施开源基础架构的过程中，实践并鼓励开放和协作的思维模式。	采用灵活且支持开源开发的 IT 基础设施。
Track success through specifically designed metrics for an open source environment.	Follow a lightweight and tailored approach to source code contribution approvals.	Share information across divisions and foster internal collaborations for successful implementation of innersource practices.
通过专门为开源环境设计的指标来跟踪成功。	遵循轻量级和量身定制的方法来批准源代码贡献。	跨部门共享信息并促进内部协作以成功实施内部资源实践。
Contribute strategically to projects that are commonly used across products and services to remain essential, justifiable, and fundable.	Allocate time for open source developers to meet upstream responsibilities, especially if they are maintainers.	Partner with product teams on upstream code development that helps reduce their technical debt.
为产品和服务中常用的项目做出战略性贡献，以保持其必要性、合理性和可资助性。	为开源开发人员（尤其是维护人员）分配时间来履行上游职责。	与产品团队合作进行上游代码开发，帮助减少他们的技术债务。
Develop open source talent internally, and encourage involvement in open source from developers across the organization.	Create a mentorship program to support the growth of junior developers and increase the quality and quantity of code accepted in open source projects.	Participate in and host open source events to build developer networks, participate in technical discussions, and increase visibility.
在企业内部培养开源人才，并鼓励整个企业的开发人员参与开源。	创建一个导师计划以支持初级开发人员的成长，并提高开源项目中接受的代码的质量和数量。	参与和主持开源活动以建立开发者网络、参与技术讨论并提高知名度。

Introduction

介绍

Corporate participation in open source has reached an all-time high and continues to grow as organizations realize the value of consuming and contributing to open source projects (FIGURE 1). In addition, the nature of corporate (also called enterprise) participation continues to evolve as organizations increasingly discover that open sourcing proprietary technologies can create new sources of value and more robust product ecosystems.

随着企业逐渐意识到消费和贡献开源项目的价值，企业对开源项目的参与程度达到了历史最高水平，并仍然在持续增长（图1）。此外，随着组织越来越多地发现，开源专有技术可以创造新的价值来源和更强大的产品生态体系，公司（也称为企业）参与的性质也在不断演变。

Enterprise open source development has challenges, which we discussed in detail in "A Deep Dive into Open Source Program Offices: Structure, Roles, Responsibilities, and Challenges."

企业开源开发存在挑战，我们在 “深入了解开源程序办公室：结构、角色、职责和挑战” 有详细的讨论。

The enterprise open source journey is challenging (FIGURE 2), and an organization needs to address this to build its open source leadership. If the organization has a clear plan to implement internal practices and address those known challenges, the journey becomes easier. For instance, the Linux Kernel is the largest collaborative software project in the world, and getting involved in the development process can be overwhelming.

企业开源之旅充满挑战（图 2），但企业需要解决这一问题，以建立其开源领导力。如果组织有一个明确的计划，来实施内部实践并解决这些已知的挑战，那么开源之旅会变得更容易。例如，Linux内核是全球最大的协作软件项目，参与开发的过程是超级难的。

If you are one of the organizations that rely on the Linux Kernel for their products and services, investing time and resources into improving your internal development abilities, contributions process, and syncing your development with the upstream project can pay off immensely in the long run.

如果您是依赖 Linux 内核提供产品和服务的企业之一，那么投入时间和资源提高你们企业的内部开发能力、贡献过程，并将企业的开发与上游项目同步，长远来看可以带来巨额的回报。

Fortunately, since so many organizations and individuals have been successful at contributing to the Linux Kernel, there is a clear path to improve your own Linux Kernel contributions and aim for a leadership role.

幸运的是，由于如此多的组织和个人已经成功地为 Linux 内核做出了贡献，因此有一条清晰的路线，可以改进您自己对 Linux 内核的贡献，并起到领导者的作用。

FIGURE 1

图1

OPEN SOURCE STRATEGIC IMPACT

开源战略影响

Accelerates the development of open solutions
Provides an implementation to an open standard
加速开源项目解决方案的开发
提供开放标准的实现
Commoditizes a market
Reduces the process of nonstrategic software assets
Provides an implementation to an open standard
Shares development costs
使市场商品化
减少非战略软件资产的处理流程
提供开放标准的实现
分摊开发成本
Drives demand by building an ecosystem for products and services
通过构建产品和服务生态系统来驱动需求
Partners with others
Engages customers
Strengthens relationships with common goals
与他人合作
吸引客户
通过共同目标加强关系

Several factors drive and motivate participation in open source projects:

推动和激励参与开源项目的几个因素：

Reducing the amount of work needed from product teams
减少产品团队所需的工作量
Minimizing the cost to maintain source code and internal software branches
最大限度地降低维护源代码和内部软件分支的成本
Improving code quality
提高代码质量
Supporting faster development cycles
支持更快的开发周期
Producing more stable code to serve as the base for products
生成更稳定的代码作为产品的基础
Improving the organization's reputation in critical open source communities
提高组织在关键性开源社区中的声誉

Organizations often upstream modifications to open source projects, which is a fundamental aspect of the open source methodology. Following this approach, enterprise developers submit internal changes to the open source project for evaluation for acceptance into the main development tree. This process achieves several technical and nontechnical benefits for the enterprise due to such contributions (see FIGURE 3).

组织经常对上游开源项目进行修改，这是开源方法论的一个基本方面。遵循此方法，企业开发人员向开源项目提交内部更改以进行评估，以便加入到主开发树中。由于这些贡献，该流程为企业带来了多项技术和非技术的利益。（请参阅图 3**）。

This report covers several practices enterprises can adopt to help grow their footprint in open source projects.

本报告涵盖了企业可以采用的几种做法，以帮助扩大他们在开源项目中的足迹。

FIGURE 2

CHALLENGES ENTERPRISES FACE AS PART OF INSTITUTIONALIZING OPEN SOURCE DEVELOPMENT PRACTICES

图2

企业在推行开源开发实践时面临的挑战

Culture 文化	Operations 运营	Tools 工具	Continuity 连续性	Education 教育
Development model 开发模型	Governance 治理	IT infrastructure IT基础设施	Strategy 战略	Executive education 高管教育
Collaboration 协作	Usage 使用	Development tools 开发工具	Projects 项目	Knowledge transfer 知识转移
Transparency 透明度	Compliance 合规性	Metric tracking 度量跟踪	Priorities 优先级	Technical training 技术培训
Meritocracy 精英主义	Contribution 贡献	Knowledge sharing 知识共享	Funding 资金	Compliance training 合规培训
Team formation 团队组建	Approvals 批准	Code reuse 代码重用	Executive support 高管支持	Mentorship programs 导师计划
Hiring practices 招聘实践	Policies 政策	Software composition analysis 软件组合分析
Success metrics 成功指标	Processes 流程	tool adoption 工具选择

Hire developers from the project's community

从项目社区雇佣开发人员

This critical step allows your organization to gain skills and recognition immediately. Hiring two or three people is a great start toward making a noticeable impact on a large project, such as the Linux Kernel, attracting further hires and allowing enough resources to mentor existing junior developers.

这一关键步骤可以让你的组织立刻提升技能、获得认可。想对一个大型项目（例如Linux 内核）产生明显的影响，雇佣两三个人是一个很好的开始，这样可以吸引更多的员工，并有足够的资源来指导已有的初级开发人员。

It is crucial to align corporate interests with individual interests.

让个人兴趣与公司利益保持一致非常重要。

It will be hard to motivate a senior open source developer to work on a given project when their interests do not match those of their employers. For instance, a memory management expert may not be interested in working on file systems; therefore, finding a match in interests is critical.

当高级开源开发人员的兴趣与雇主的兴趣不匹配时，会很难激励他们参与特定的项目。例如一位内存管理专家可能对文件处理系统的工作根本不感兴趣；因此，找到兴趣的匹配点是至关重要的。

Support and allocate time for upstream contributions

支持并分配时间用于上游贡献

The core principle for hiring open source developers is to support an organization's open source strategy, development, and upstream activities; however, in most cases, there is the expectation that open source developers will need to be available to support product teams due to their expertise and influence in their respective open source projects. It is also common for product teams to exercise their influence in an attempt to hijack the time of the open source developers by having them work on product development as much as possible. If this happens, many open source developers will head to the door, seeking new opportunities that allows them to work on their upstream project before an organization realizes what just happened.

雇用开源开发人员的核心原则是支持该组织的开源战略、开发和上游活动；然而，在大多数情况下，由于开源开发人员在各自开源项目中的专业知识和影响力，人们期望他们能够支持产品团队。产品团队利用开源开发人员的影响力，试图抢夺开源开发人员的时间、让其尽可能多地参与产品开发，这也很常见。如果发生这种情况，许多开源开发人员会直奔门口离开，去寻求容许他们在上游项目上工作的新机会，此时这个组织可能还未意识到发生了什么。

FIGURE 3

图3

BENEFITS OF UPSTREAMING CODE

上游代码的好处

Lower maintenance efforts for internally managed code, i.e., minimizes technical debt.
减少内部管理代码的维护工作，即最大限度地减少技术债务。
Upstreamed code becomes visible to others and receives peer review and feedback, leading to improvements.
上游的代码对其他人可见，接收同行评审和反馈，进而可以优化改进。
Upstream contributions provide stability to the project. They send a signal that the project is useful and important, which helps attract new contributors.
上游贡献为项目提供了稳定性。它们发出了一个重要信号，表明该项目有用的且重要，这有助于吸引新的贡献者。
Builds a positive relationship between the contributing organization and the project community.
在贡献组织和项目社区之间建立积极正向的关系。
Upstreaming code is an effective way to provide technical leadership and influence the project.
上游代码是提供技术领导力和影响项目的有效方法。
Upstreaming contributes to easier compliance and improved security due to centralizing code in upstream repos.
由于将代码集中在上游项目仓库中，有助于更轻松地遵从代码合规，提高安全性。
Upstream contributions are an effective means of ensuring stability in a company's software supply chain.
上游贡献是保护公司软件供应链稳定的有效手段。
Helps organizations recruit talent from projects and retain their own developers by engaging them with the open source innovation engine.
帮助组织从项目中招募人才，同时通过让组织现有的开放人员参与开源创新引擎来吸引留住他们。

Therefore, creating and maintaining a separation of upstream work and product work is essential. In other words, a followed practice is to provide open source developers with guaranteed time to meet their upstream aspirations and responsibilities, especially if they are maintainers. For junior developers, or other internal developers using open source in product components, such interactions with the upstream community will increase their language, communication, and technical skills. In the absence of such an upstream time guarantee, it is easy for these team members to become an extension of product teams, resulting in their upstream focus drying up in favor of product development.

因此，隔离上游工作和产品工作是必不可少的。换句话说，一个可遵循的做法，是为开源开发人员提供有保证的时间，来满足他们的上游意愿和责任，尤其是当他们担任项目维护者时。对于初级开发人员，或者其他在产品组件中使用开源的内部开发人员，与上游社区的这种互动将提高他们的语言、沟通和技术能力。如果无法保证上游开发时间的情况下，这些团队成员很容易成为产品团队的延伸，导致他们的上游投入枯竭转而支持产品开发。

Create a mentorship program

创建导师计划

Set up a mentorship program where senior, experienced open source developers mentor junior, less experienced developers. Typically, a mentorship program runs for three to six months, during which the mentor supervises the mentee's work, assigns tasks, and ensures proper results. The mentor also conducts code reviews and provides feedback on anything the mentee produces before the mentee pushes the code to the upstream project.

建立一个导师计划，让资深的、有经验的开源开发人员来引导初级的、经验较少的开发人员。通常情况下，导师计划持续3至6个月，在此期间，导师将监督学员的工作，分配任务，并确保适当的结果。在学员将代码推送到上游项目之前，导师也会进行代码审查并对学员的产出内容提供反馈。

This exercise aims to increase the number of developers contributing code to the upstream project and improve individual effectiveness by increasing the quality of code and the percentage of code accepted into the upstream project. In general, four to five mentees should work with a given mentor, and, ideally, they should work in the same area as the mentor to make code reviews more efficient.

这种练习的目的，是通过提高代码质量和上游项目接受代码的比例，来提升为上游项目贡献代码的开发人员数量和个人效率。一般来说，4到5名学员与一位指定的导师一起工作，理想情况下，他们应该与导师在同一领域工作，这样可以让代码审查更高效。

Formalize open source human resources tracking & performance metrics

正式制定开源人力资源跟踪和绩效指标

Mature open source organizations almost always have an open source developer track in their HR system. So, individuals hired as open source developers have a good sense of how their careers will progress within the organization. Additionally, organizations often need to adjust their performance-based bonuses and metrics to include goals related to open source development work. Closed source developers' performance metrics are often different from those of open source developers. For example, if an open source developer advocates for the implementation of a given feature, successfully gathers interest, and volunteers to write the code, how would they be rated, especially if they may not have written a single line of code?

所有成熟的开源组织，在他们的HR系统中几乎都有一个开源开发人员赛道。这样被雇用为开源开发人员的个人，就非常清楚他们在组织内的职业发展。此外，组织往往需要调整其基于绩效的奖金和指标，以包含与开源开发工作相关的指标。闭源开发人员的绩效指标通常与开源开发人员的绩效指标不同。例如，如果一个开源开发人员倡导实现一个特定的功能，成功地吸引到社区兴趣，并有志愿者们自愿编写代码，那么他们将如何被评价，特别是如果他们自己可能没有编写一行代码的话？

Finally, organizations should allow a work-from-home (WFH) policy for open source developers regardless of the general corporate policy. During COVID-19, we witnessed organizations institute WFH policies to allow employees to be productive while under quarantine. It was a fascinating experiment for WFH policies, as organizations continued to operate, innovate, and produce, even though most of their employees worked from home. A WFH policy is almost mandatory in the open source world because open source developers are located worldwide, making hiring and retaining them easier.

最后，组织应该忽略常规的公司政策，允许开源开发人员远程办公。在COVID-19期间，我们目睹了各组织制定的远程办公政策，让员工在隔离期间保持高效产出。对于远程办公政策来说，这是一次引人入胜的实验，尽管他们的大多数员工都在家远程办公，但组织仍继续运营、创新和生产。在开源世界，远程办公政策几乎是强制性的，因为开源开发人员遍布全球，使得招聘和留住他们变得更加容易。

Offer training

提供培训

It is only possible for organizations to hire some of the senior and most expert developers. They are always looking for ways to increase the competence of their developers in a given technical domain; therefore, in addition to specialized training, organizations need to offer training on the open source development model and the basic concepts of open source legal compliance.

组织只可能聘任一些高级的、专家级的开发人员。他们总是在寻找方法来提升开发者在特定领域的能力。因此，在专业化培训之外，组织还需要开展关于开源开发模型和开源合规基本概念的培训。

Sample training courses include:

举例来说，培训课程包括：

An open source development methodology course that teaches staff new to open source how open source development works and how to get best engaged with the project community
开源开发方法论课程：向刚接触开源的员工讲授开源开发的工作原理，以及如何更好地参与项目社区；
An open source compliance course that teaches staff the basics of compliance principles and open source licensing. The course often includes modules covering the organization's policy and process.
开源合规课程，教导员工遵循开源原则和开源许可的基础知识。该课程通常涵盖了组织政策和流程的内容。

The Linux Foundation offers several technical training courses specific to open source technologies and several nontechnical courses, such as this free online open source compliance training for developers.

Linux基金会提供了一些针对开放源码的技术培训课程和非技术课程，例如上述面向开发人员的开源合规免费在线课程nontechnical courses。

Participate in and host open source events

参与并主持开源活动

Mature open source organizations support and encourage their developers to host, attend, and participate in open source conferences and events, including local community meetups, hackathons, and summits. Such participation helps open source developers connect personally with their peers, build relationships, and participate in technical discussions that guide the direction of the respective open source projects.

成熟的开源组织会对支持并鼓励自己的开发人员主持、参加和参与开源会议和活动，包括本地社区聚会、黑客马拉松和峰会。这种参与有助于开源开发人员与他们的同行建立个人联系，打造关系圈，参与并指导与各自开源项目有关的技术讨论。

As an organization that uses and adopts open source software, it is highly recommended to facilitate for your open source developers the process of attending and presenting at open source events. You can also sponsor big and small events to increase external visibility within the open source global community or simply target events tailored for specific open source projects. As a bonus benefit, such events are also great venues to look for talent.

作为使用开源软件的组织，强烈建议为开源开发人员提供便利，让其参加开源活动并进行演示。也可以赞助大大小小的活动，以提升在全球化开源社区中的知名度，亦或者针对特定开源项目量身定制活动。作为额外的惊喜，此类活动也是发现人才的好去处。

Provide a flexible IT infrastructure

提供灵活的IT基础设施

Provide a flexible IT infrastructure that allows open source developers to communicate and work with the open source and Linux Kernel communities without any challenges. Additionally, set up an internal IT infrastructure that matches the tools used externally to help bridge the gap between internal teams and the Kernel community or any other open source project community for that purpose.

提供灵活的IT基础设施，使开源开发人员能够毫无阻碍地与开源社区和Linux内核社区进行交流和合作。此外，建立一个与外部使用的工具相匹配的内部IT基础设施，以减少内部团队与内核社区或任何其他开源项目社区之间的距离感。

Open source development uses three primary domains of IT services: knowledge sharing (wikis, collaborative editing platforms, and public websites), communication and problem solving (mailing lists, forums, and real-time chat), and code development and distribution (code repositories and bug tracking). Making some or all of these tools available internally properly supports open source development. However, this might conflict with existing organization-wide IT policies. If so, it is vital to resolve these conflicts and allow open source developers to use familiar tools.

开源开发使用IT服务的三个主要务领域: 知识共享(wiki、协作编辑平台和公共网站)，沟通和解决问题(邮件列表、论坛和实时聊天)，以及代码开发和分发(代码存储库和bug跟踪)。在内部提供这些工具的部分或全部，能为开源开发提供适当的支持。然而，这可能与组织现行的整体IT策略相冲突。如果出现这种情况，应重点解决这些冲突，并允许开源开发人员使用熟悉的工具。

Track developer code contributions

跟踪开发人员的代码贡献

Create an internal system to keep track of developer contributions and impact. Contributions can include upstream development, supporting product teams, knowledge transfer (mentoring, training), visibility (publications, talks), launching new open source projects, and establishing internal collaboration projects with other teams or groups.

搭建一个内部系统来跟踪开发人员的贡献和影响。贡献可以包括上游开发、支持产品团队、知识转移(指导、培训)、知名度(出版物、演讲)、启动新的开源项目，以及与其他团队或小组建立内部协作项目。

With this data, you can compare contributions from various internal development teams to identify where source code contributions are coming from.

根据这些数据，我们就可以把来自不同内部开发团队的贡献进行比较，以确定源代码贡献的来源。

For instance, you can use these metrics to compare your performance to other organizations involved in the Kernel ecosystem. This approach helps better inform you about the overall developer ecosystem for the project. In addition, these metrics provide a much better idea of your strengths and weaknesses and can help inform your overall development strategy.

例如，我们可以利用这些参数，与Kernel生态系统中的其他组织进行性能方面的比较。这种方法可以帮助我们更好地了解项目开发人员的整体生态系统。还可以更好地了解自身的优势和不足，从而影响整体开发战略。

Identify focus areas with a broad impact

确定具有广泛影响的重点领域

Contribute to and focus on areas that benefit more than one business unit or more than one product. This contribution model, driven by the criticality of software components, allows you to provide value and show return on investment across multiple business units, increasing your chances for more funding and support.

致力并专注于能让多个业务单元或多个产品受益的领域。这个基于软件重要性驱动的贡献模型，可以帮助我们提供价值并掌握横跨数个业务单元的投资回报，从而有机会获得更多资金和支持。

Foster internal collaboration

促进内部协作

Create collaboration projects with other business units that use the specific open source projects in their products. These collaborations can take one or more of many forms:

与其他在产品中使用特定开源项目的业务单元创建协作项目。这些合作可以采取一种或多种形式:

Deliver training to their developers.
为开发人员提供培训。
Run a workshop on a specific topic or problem.
举办针对特定主题或问题的研讨会。
Develop new functionality.
开发新功能。
Troubleshoot and resolve issues and bugs.
排除以及解决问题和 bug 。
Upstream existing code for which they lack resources.
对缺乏资源的代码向上溯源。
Help get them off an old fork and onto a mainline version.
帮助他们从一个旧的分支到一个主线版本。

These collaborations aim to help the product teams understand their needs and fulfill their product goals via open source enablement.

这些协作旨在帮助产品团队理解他们的需求，并通过开放源代码实现其产品目标。

Implement inner sourcing practices

落地内源实践

Inner sourcing is the application of open source methodologies to development projects inside the organization. The goal is to incubate the same capabilities within the enterprise as those in the open source community and to foster new employee-toemployee relationships that are cross-functional and touch on multiple product domains.

内源是开源方法论在组织内部开发项目的实际应用。其目的是在企业内部孵化出与开源社区一样的能力，以此来促进跨职能并且涉及多产品领域之间员工与员工之间的协作。

FIGURE 4

图4

BENEFITS OF ADOPTING INNERSOURCE PRACTICES IN THE ENTERPRISE

在企业采用内部开源实践的好处

Releases cadency faster
更快的发布周期
Improves source code quality
提高源代码质量
Increases motivation
增加动力
Increases internal information sharing
增加内部信息共享
Reduces costs of development
降低开发成本
Increases internal collaboration
增加内部协作
Increases morale, retention
提高士气，提高员工留存率
Increases internal communication
增加内部沟通

Open source principles work well on large-scale projects distributed across an enterprise. Many Fortune 500 organizations have adopted them externally and internally for the same reasons: faster releases, improved quality, increased innovation and communications, information sharing, reduced costs, greater and more effective collaboration, and increased employee morale and retention.

开源原则适用于企业内部大规模分布式项目的研发。很多财富 500 强企业在内外部采用开源都是基于同一个原因：加快发布、提高质量、增强创新与交流、信息共享、降低成本、更好及更有效地协作以及提高员工士气和留存率。

Inner sourcing prepares organizations to work effectively with external open source communities. It encourages employees to interact with colleagues elsewhere and with external community members without switching contexts. In addition, new employees familiar with this development model may integrate more quickly into established workflows. Finally, business partners are probably already using many of these development practices, so when an organization adopts inner sourcing practices, it is also strengthening its integration with the commercial ecosystem.

内源使组织能够与外部开源社区有效合作。它鼓励员工和其他地方的同事以及外部社区成员互动，而且无需切换上下文。除此之外，熟悉这种研发模式的新员工可以更快速的融入到既定的工作流程中。最后，企业的业务合作伙伴可能已经在使用其中的许多开发实践，因此，当一个组织采用内部采购实践时，它也在加强与商业生态系统的集成。

Recommendations and lessons learned

建议和经验教训分享

Be patient

保持耐心

It takes considerable time to grow internal open source expertise. The goal from an enterprise perspective is to find people with enough peer recognition to be influential in the community. There are typically three pillars to this: domain expertise, open source methodology, and working practices.

培养内部开源专业知识需要相当长的时间。从企业的角度来看，目标是找到在社区中具有足够同行认可的人，能够在其中产生影响力。通常有三个支柱：领域专业知识、开源方法论和工作实践。

Shift to a more collaborative environment

转向更协作的环境

Internal organization dynamics must be favorable to open source efforts. Implementing these practices requires a shift from traditional software development practices to a more open and collaborative mindset. As an open source leader inside your organization, you will face several challenges in funding resources, justifying ROI, getting upstream focus, etc. These often require a major shift in mindset and a lot of education up the command chain.

内部组织动态必须有利于开源工作。遵循这些实践需要从传统的软件开发转向更加开放和协作的心态。作为组织内的开源领导者，您将面临一些挑战，诸如寻找资金来源、证明投资回报率、获得上游关注等。这通常需要在思维方式上进行重大转变，并在指挥链上进行大量教育。

Embrace a flexible IT infrastructure

拥抱灵活的IT基础设施

These open source practices require an IT infrastructure free from many limiting IT policies and a computing environment that supports open source development.

这些开源实践要求有一个摆脱许多限制性IT政策的IT基础设施，以及支持开源开发的计算环境。

Adopt proper success metrics

采用适当的成功度量指标

Proper open source metrics drive the desired development behavior. Unfortunately, the traditional metrics often used in product organizations only apply in the context of open source development. For example, we have had multiple instances of the upstream implementation of desired functionality because of OSG developers that lobby for support from the community.

适当的开源度量指标推动期望的开发行为。不幸的是，在产品组织中通常使用的传统度量指标，只适用于开源开发的环境。例如，由于OSG开发人员游说社区支持，我们已经有了多个所需功能的上游实现实例。。

In this case, the number of changesets or lines of code does not matter as much, as the technical leadership team members provide to get code upstream and reduce our downstream maintenance efforts. The metrics we track account for things like this.

在这种情况下，变更集或代码行数并不那么重要，因为技术领导团队成员提供的是将代码上游化，以减少我们的下游维护工作。我们跟踪的度量指标需要涵盖这些方面。

Use a lightweight approval process

使用轻量级的批准流程

Organizations have transitioned from highly complex and cumbersome policies to a more straightforward approach for receiving, reviewing, and approving source code contributions. Dedicated open source teams often receive blanket approval to contribute to open source projects. This is not the case for other groups, which need different approval levels depending on the nature of the contributed code (e.g., simple bug fixes, code to improve existing functionality, code that offers new functionality, or starting a new project). This is a function of the balance between all parties involved: legal, engineering, and open source.

组织已经从高度复杂和繁琐的政策过渡到了对源代码贡献的更为简单的方法，包括接收、审查和批准。专门的开源团队通常获得全面批准，可以为开源项目做出贡献。对其他团队来说，情况并非如此，它们需要根据贡献代码的性质（例如，简单的错误修复、改进现有功能的代码、提供新功能的代码或启动新项目的代码）获得不同的批准级别。这取决于所有参与方之间的平衡：法务、工程和开源。

共享信息

The organization must share information and priorities across different divisions. To illustrate this, assume you are on an open source team and request to support the implementation of a driver, but you cannot access the hardware manual and instructions. This situation sounds a bit like playing darts with the lights off; therefore, information sharing is critical to successful internal collaborations between the open source teams and everyone else.

组织必须在不同部门之间分享信息和优先事项。为了说明这一点，假设您在一个开源团队中，并请求支持驱动程序的实现，但您无法访问硬件手册和说明书。这种情况听起来有点像在灯光熄灭的情况下玩飞镖；因此，信息共享对于开源团队与其他人之间的内部协作至关重要。

Make strategic contributions

进行战略性贡献

Focus your contributions on upstream projects that would directly benefit the organization's strategy and products. In open source development, it is easy to get carried away by hopping between different exciting projects. However, in an enterprise setting where the open source group is a cost center, your driving force should be to focus on open source projects that support product development. Open source teams often perform a yearly review of the product portfolio they support and focus their involvement on open source projects commonly used across as many products as possible. Such a methodology drives priorities and is a great way to remain focused on what's essential, justifiable, and fundable.

将您的贡献重点放在能够直接有利于组织战略和产品的上游项目上。在开源开发中，很容易在激动人心的不同项目之间跳跃而得意忘形。然而，在一个企业环境中，开源团队是一个成本中心，您的驱动力应该是专注于支持产品开发的开源项目。开源团队通常会对其支持的产品组合进行年度审查，并将他们的参与重点放在尽可能多的产品常用的开源项目上。这种方法可以推动优先事项，并且是一种有效方法，使企业专注于重要的、可证明的和可资助的事情。

Partner with product teams

与产品团队合作

Be the upstream partner for product teams; they often feel like they are working inside a pressure cooker, especially in a consumer electronics environment. They often seem understaffed, need more critical resources to support parallel upstream development, and are under constant pressure for feature delivery within tight schedules. In such an environment, it is easy to overlook the benefit of upstreaming in favor of short-term time savings, which can, unfortunately, lead to technical debt that has a higher cost in the long term.

成为产品团队的上游合作伙伴；他们经常感觉自己好像在高压锅内工作，尤其是在消费电子产品环境中。他们常常显得人手不足，需要更多的关键资源来支持并行上游开发，并在紧张的时间表内承担着持续的功能交付压力。在这种环境中，很容易忽视上游化的好处，而倾向于短期节省时间，不幸的是，这可能导致长期成本更高的技术债务。

Open source teams can help by being a partner that focuses on delivering the necessary code upstream, reducing this technical debt.

开源团队可以转变为专注于向上游交付必要代码，成为产品团队的合作伙伴，从而减少这种技术债务。

FIGURE 5

图5

RECOMMENDED PRACTICES FOR CONTRIBUTING TO OPEN SOURCE PROJECTS 为开源项目做贡献的推荐实践

Design & implement with upstreaming in mind to increase the likelihood of patch acceptance.
设计和实现时考虑上游，以增加补丁被接受的可能性。
Ensure the contribution improves or introduces functionality that is useful for a broad base of users.
确保贡献改进或引入对广泛用户有用的功能。
Stay involved in upstream development post merging with the upstream project.
在与上游项目合并后，保持参与上游开发。
Document the code to make it easier to understand and to lower the barrier for new contributors.
做好代码相关的文档，使其更容易理解，并降低新贡献者加入的门槛。
Upstream for the right reasons.
以正确的原因将代码上游化
Upstreaming is not a code retirement strategy.
上游化不是一种代码退休策略。
Listen to feedback, and act upon it---rework the code based on the peer review process.
倾听反馈，并根据同行评审过程重塑代码。
Follow proper coding style, and secure code guidelines.
遵循适当的编码风格和安全代码指南。
Follow the processes set by the project for submitting code, new features, etc.
遵循项目设置的流程提交代码、新功能等

Grow open source talent

发展开源人才

Grow open source talent in specific technology areas relevant to your products. Hiring a few resources from outside the organization is easy, but this approach has several limitations. The alternative approach is to convert your existing developers into open source contributors via training on the technical domain and open source methodology. You can then pair these developers with a mentor to further expand their skills.

培养与产品相关的特定技术领域的开源人才。从组织外部聘请一些资源很容易，但这种方法有局限性。替代方法是通过在技术领域和开源方法的培训，将现有开发人员转化为开源贡献者。然后，将这些开发人员与导师配对，以进一步扩展他们的技能。

Encourage developers outside the open source team to learn from and contribute to the open source community. We provide as much help as we can with upstream code contributions.

鼓励开源团队之外的开发人员向开源社区学习并做出贡献。尽力提供上游代码贡献方面的帮助。

Still, we need more resources and sometimes need a deeper understanding of products that might be necessary to identify where we can adequately upstream code. Better involvement in the open source community from teams outside our own allows us to get more critical code upstream and improves our ability to interact with the community.

尽管如此，我们仍然需要更多的资源，有时需要对产品有更深入的了解，这样才能确定将产品的哪些部分进行上游化。外部的团队可以更好地参与开源社区，使我们能够获得更关键的上游代码，并提高我们与社区互动的能力。

Conclusion

总结

You must earn open source leadership, but you can lose it through a lack of participation. Regular, ongoing participation and contribution are the only ways to ensure your organization maintains open source leadership.

你必须赢得开源领导力，但你可能会因为缺乏参与而失去它。定期、持续的参与和贡献是确保组织保持开源领导力的唯一方法。

Hopefully, this paper makes the task of improving your enterprise's open source practices more manageable. Following some of the recommended practices will go a long way toward developing internal open source expertise. You can leverage this expertise to improve your products and services and reduce the cost of code maintenance. Many organizations have had considerable success through the use of these strategies.

希望本文能使提升您的企业开源实践的任务变得更加可控。遵循这些推荐的实践将对发展内部开源专业技能大有裨益。您可以利用这些专业知识来改进您的产品和服务，并降低代码维护成本。许多组织通过使用这些战略取得了相当大的成功。

FIGURE 6 图6

MASTERING OPEN SOURCE SOFTWARE

掌握开源软件

Master open source software requires you to mastering the three critical Cs:

掌握开源软件需要你掌握三个关键C：

Consumption
消费
Establish internal infrastructure to enable proper practices for open source software consumption: policy, process, checklists, and training.
建立内部基础设施，以支持开源软件使用的正确做法：政策、流程、检查表和培训。
Compliance
合规
Enable open source compliance practices within your development process to ensure proper fulfillment of open source license obligations once products ship.
在企业的开发过程中启用开源合规实践，以确保在产品发货后正确履行开源许可义务。
Contribution
贡献
Enable your developers to engage within open source projects via a policy and a lightweight process and access to legal support. Provide training on open source development models and best practices.
使企业的开发人员能够通过政策和轻量级的流程参与开源项目，并获得法律支持。提供关于开源开发模式和最佳实践的培训。

FIGURE 7

图7

TOP 10 TIPS FOR MASTERING:

十大窍门掌握：

OPEN SOURCE CONSUMPTION

开源消费

How can you build a healthy environment for open source consumption within your organization? And how can you get ready for the next phase (i.e., becoming a contributor)?

您如何在组织内部建立一个健康的开源消费环境？您如何为下一阶段做好准备（即成为贡献者）？

1. Establish a policy and process to guide open source usage.
1. 建立一个政策和流程来指导开源使用。
1. Set up a team to oversee approvals for all open source usage.
1. 建立一个团队来监督所有开源使用的批准。
1. Understand your open source product strategy and core values.
1. 了解您的开源产品战略和核心价值观。
1. Provide the enabling IT infrastructure and tooling.
1. 提供支持的IT基础设施和工具。
1. Setup an open source license compliance program.
1. 建立一个开源许可合规计划。
1. Offer training to your staff and manager.
1. 为您的员工和经理提供培训。
1. Track everything, measure, improve, and communicate.
1. 跟踪一切，衡量，改进和沟通。
1. Adopt open source practices for your internal development.
1. 采用开源实践进行内部开发。
1. Identify incoming open source code through your software suppliers.
1. 通过软件供应商识别传入的开源代码。
1. Identify key open source projects, and start contributing to them.
1. 识别关键的开源项目，并开始为它们做贡献。

FIGURE 8

图8

ELEVEN TIPS FOR MASTERING:

11个需掌握的技巧：

OPEN SOURCE CONTRIBUTIONS

开源贡献

How can you build a healthy environment for open source contributions within your organization?

如何在组织内为开源贡献构建一个健康的环境？

1. Establish a policy and process to guide open source contributions.
1. 建立一个政策和流程来指导开源贡献。
1. Set up a team to oversee approvals for all open source contributions.
1. 成立一个团队来管理所有开源贡献的审批。
1. Focus contributions in the areas that will enable your technologies.
1. 将贡献集中在能够使能您的技术的领域。
1. Provide the needed IT infrastructure and tooling for contributors.
1. 为贡献者提供所需的IT基础设施和工具。
1. Offer training to your staff on contribution best practices.
1. 为您的员工提供关于开源贡献最佳实践的培训。
1. Track contributions, measure impact, improve, and communicate.
1. 跟踪贡献、衡量影响、改进和沟通。
1. Establish a mentorship program to train less experienced developers.
1. 建立一个导师计划，培训经验不足的开发人员。
1. Provide contributions guidelines, How-To's, Do's and Don'ts.
1. 提供贡献指南，讲清楚如何做，可以做什么以及不可以做什么。
1. Make open source legal support accessible to developers.
1. 让开发者可以获得开源法律支持。
1. Hire from the open source communities you value the most.
1. 从你最看重的开源社区招聘。
1. Always follow community processes / practices of specific projects.
1. 始终遵循具体项目的社区流程/实践。

Acknowledgments

致谢

The author would like to express his sincere appreciation to his Linux Foundation colleagues Hilary Carter, Jason Perlow, Melissa Schmidt, Jessica Murillo and Barry Hall for their valuable reviews and feedback. This report has benefited immensely from their experiences, reviews, and contributions.

作者在此对Linux基金会同事Hilary Carter、Jason Perlow、Melissa Schmidt、 Jessica Murillo和Barry Hall的宝贵评论和反馈表示衷心的感谢。从他们的经验、评审和贡献中，本报告受益匪浅。

Feedback

反馈

The author apologizes in advance for any spelling errors or possible errors and is grateful to receive corrections and suggestions for improvements.

作者对任何拼写错误或可能出现的错误提前道歉，并非常感激能收到更正和改进建议。

Linux Foundation resources

Linux基金会资源

• E-book: A Deep Dive into Open Source Program Offices: Structure, Roles, Responsibilities, and Challenges • E-book: A Guide to Enterprise Open Source • E-book: Open Source Compliance in the Enterprise • E-book: Open Source Audits in Merger and Acquisition Transactions • Linux Foundation Open Source Best Practices for the Enterprise Guides • Linux Foundation Open Source Compliance Program • TODO Group • The Software Package Data Exchange® • Linux Foundation Training & Certification • Linux Foundation Events

twitter.com/linuxfoundation [facebook.com/TheLinuxFoundation] linkedin.com/company/the-linux-foundation [youtube.com/user/TheLinuxFoundation]

About the author

关于作者

Dr. Ibrahim Haddad is the vice president of strategic programs at the Linux Foundation. He focuses on facilitating a vendor-neutral environment for advancing the open source AI platform. Haddad leads the Linux Foundation AI & Data Foundation and the PyTorch Foundation. His work and the work of both foundations support companies, developers, and the open source community in identifying and contributing to the technological projects that address industry and technology challenges for the benefit of all participants. Throughout his career, Haddad held technology and portfolio management roles at Ericsson Research, the Open Source Development Labs, Motorola, Palm, Hewlett-Packard, Samsung Research, and the Linux Foundation. He graduated with honors from Concordia University (Montréal, Canada) with a Ph.D. in computer science. He is fluent in Arabic, English, and French.

Ibrahim Haddad博士是Linux基金会战略项目副总裁。他致力于促进一个供应商中立的环境来推进开源AI平台发展，他是LF AI& Data基金会和PyTorch基金会的执行总监，他的工作以及这两个基金会的工作是为企业、开发人员和开源社区提供支持，以解决行业和技术挑战的项目做出贡献，让所有参与者受益。在他的职业生涯中，Haddad曾在爱立信研发、开源开发实验室、摩托罗拉、Palm、惠普、三星和Linux基金会担任技术和项目组合管理职位。他以优异成绩毕业于康考迪亚大学（加拿大蒙特利尔），获得计算机科学博士学位。他精通阿拉伯语、英语和法语。

@ibrahimhaddad @IbrahimAtLinux IbrahimAtLinux.com Latest fun project: Tux NFT Club

[@ibrahimhaddad] [@IbrahimAtLinux] [IbrahimAtLinux.com] 最新的兴趣项目: Tux NFT俱乐部

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration and provides insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

成立于2021年的 Linux基金会研究，致力于探索不断扩大的开源协作规模，并提供对新兴技术趋势、最佳实践和开源项目的全球影响的洞察。通过利用项目数据库和网络，以及对定量和定性分析的最佳实践的承诺，Linux 基金会研究中心正在创建开源洞察基础库，以造福于世界各地的组织。

This report is licensed under the Creative Commons Attribution-No Derivatives 4.0 International Public License.

本报告采用CC BY-ND 4.0国际公共许可证授权。

To reference the work, please cite as follows: Ibrahim Haddad, Ph.D., "A Road Map to Improve the Effectiveness and Impact of Enterprise Open Source Development," Foreword by Jessica Murillo, The Linux Foundation, February 2023.

如需参考该文，请引用以下内容：Ibrahim Haddad博士， "提升企业开源开发有效性和影响力的路线图“，前言：Jessica Murillo，Linux基金会，2023年2月。

解决开源软件中的网络安全挑战

2023年6月30日 · 阅读需 142 分钟

赵振华

吴昊

李昌华

解决开源软件中的网络安全挑战

The current state of open source software security and methods to address and improve your cybersecurity posture

开源软件安全和方法的现状以及解决并改善您的网络安全状况的方法

In Partnership With:

联合出品：

Cover

Open source software (OSS) has become an integral part of the technology landscape, as inseparable from the digital machinery of modern society as bridges and highways are from global transportation infrastructure. According to one report, typically 70% to 90% of a modern application stack consists of pre-existing OSS, from the operating system to the cloud container to the cryptography and networking functions, sometimes up to the very application running your enterprise or website. Thanks to copyright licenses that encourage no-charge re-use, remixing, and redistribution, OSS encourages even the most dogged of competitors to work together to address common challenges, saving money by avoiding duplication of effort, moving faster to innovate upon new ideas and adopt emerging standards.

开源软件（OSS）已成为技术领域不可或缺的一部分，就像桥梁和高速公路是全球交通基础设施施密不可分一样，已经和现代社会的数字机器紧密结合在一起。据报告显示，现代应用程序栈通常由 70％至 90％的现有开源软件组成，从操作系统到云容器，再到加密和网络功能，甚至是支撑企业或网站运行的应用程序本身。由于版权许可证鼓励免费重复使用、重新混合和重新分发，开源软件鼓励企业合作共同解决共同的挑战，即使是最激烈的竞争对手，也可通过避免重复工作来节省资金，并更快地创新和采用新兴标准。

However, this ubiquity and flexibility can come at a price. While OSS generally has an excellent reputation for security, the communities behind those works can vary significantly in their application of development practices and techniques to reduce the risk of defects in the code, or to respond quickly and safely when one is discovered by others. Often, developers trying to decide what OSS to use have difficulty determining which ones are more likely to be secure than others based on objective criteria. Enterprises often don't have a well-managed inventory of the software assets they use, with enough granular detail, to know when or if they're vulnerable to known defects, and when or how to upgrade. Even those enterprises willing to invest in increasing the security of the OSS they use often don't know where to make those investments, nor their urgency relative to other priorities.

然而，这种普遍性和灵活性是有代价的。虽然开源软件通常在安全方面享有盛誉，但这些作品背后的社区在降低代码缺陷风险中的应用开发实践和技术，或在他人发现缺陷时快速安全响应方面可能存在很大差异。通常情况下，试图决定使用哪种开源软件的开发人员很难根据客观标准确定哪些开源软件比其他开源软件更安全。企业通常没有对其使用的软件资产进行良好管理的清单，没有足够详细的细节来了解它们何时或是否易受已知缺陷的影响，以及何时或如何升级。即使那些愿意投资增强其使用的开源软件安全性的企业，也经常不知道在哪些方面进行投资，以及这相对于其他优先事项的紧迫性。

However, fighting security issues at their upstream source - trying to catch them earlier in the development process, or even reduce the chances of their occurrence at all - remains a critical need. We are also seeing new attacks that focus less on vulnerabilities in code, and more on the supply chain itself - from rogue software that uses "typosquatting on package names to insert itself unexpectedly into a developer's dependency tree, to attacks on software build and distribution services, to developers turning their one-person projects into "protest-ware" with likely unintended consequences.

然而，在上游源头上解决安全问题 - 试图在开发过程的早期发现它们，甚至减少它们发生的机会 - 仍然是一个关键的需求。我们也看到了新的攻击，它们较少关注代码中的漏洞，而更多地关注供应链本身 - 从使用“包名称上的域名仿冒将自己意外插入开发人员的依赖树”的流氓软件，到对软件构建和分发服务的攻击，再到开发人员将他们的单人项目变成可能会产生意想不到的后果“抗议软件”。

To address the urgent need for better security practices, tools, and techniques in the open source software ecosystem, a collection of deeply invested organizations came together in 2020 to form the Open Source Security Foundation (OpenSSF), and chose to house that effort at the Linux Foundation. This public effort has grown to include hundreds of active participants across dozens of different public initiatives housed under 7 working groups, with funding and partnership from over 75 different organizations, and reaching millions of OSS developers. This report presents analysis that we intend to use to help support that effort. You can see a complete copy of my prepared testimony at: Testimony to the US House Committee on Science and Technology - Open Source Security Foundation (openssf.org).

为了满足开源软件生态系统中对更好的安全实践、工具和技术的迫切需求，一系列深度投资的组织在 2020 年聚集在一起，成立了开源安全基金会（OpenSSF），并选择将这项工作设在 Linux 基金会。这项公共努力已经发展到包括数十个不同公共计划的数百名积极参与者，这些计划位于7个工作组下，来自超过75个不同组织的资金和合作伙伴关系，并覆盖了数百万个开源软件开发者。本报告介绍了我们打算用来帮助支持这项工作的分析。您可以在以下位置查看我准备的证词的完整副本：美国众议院科学和技术委员会的证词 - 开源安全基金会（openssf.org）。

Brian Behlendorf

布赖恩·贝伦多夫

General Manager, Open Source Security Foundation

总经理，开源安全基金会

The Linux Foundation

Linux 基金会

Info Graphic


5.1 Average number of outstanding, critical vulnerabilities in an application. Ranges between 2.6 and 9.5 based on programming language.	24% of organizations are confident in the security of their direct dependencies.	59% of organizations report their OSS is somewhat or highly secure.
5.1 平均每个应用程序存在的重要漏洞数量。根据编程语言的不同，重要漏洞数量的范围在 2.6 到 9.5 之间。	24% 的组织对它们的直接依赖的安全性感到有信心。	59％的组织报告称，他们的开源软件在一定程度上或高度安全。
68.8 Average dependencies per project. Ranges between 25 and 174 based on programming language.	18% of organizations are confident in the security of their transitive dependencies.	SCA and SAST tools are the #1 and #2 tools used to address security concerns.
68.8 每个项目的平均依赖项。根据编程语言的不同，依赖项的数量在25到174之间变化。	18% 的企业对其传递依赖项的安全性感到有信心。	软件组成分析（SCA）和静态应用程序安全测试（SAST）工具是解决安全顾虑使用的排名第一和第二的工具。
97.8 Average number of days it takes to fix a vulnerability.	49% of organizations have a security policy that addresses OSS.	73% of organizations are searching for best practices to improve their software security.
97.8 平均修复漏洞所需的天数。	49% 的组织拥有涵盖开源软件安全的安全策略。	73% 的组织正在寻找提高软件安全性的最佳实践。
Increased incentives by employer is the #1 approach to improving OSS resourcing.	More intelligent tools are the #1 way organizations intend to improve supply chain security.	11% Average increase to an organization’s security
score in 2022.
雇主提供更多的激励措施是改善开源软件资源配置的第一途径。	更加智能的工具是组织机构试图提高供应链安全性的第一选择。	11% 组织在2022年的安全分数平均提高百分比

Introduction

介绍

Open source software (OSS) has had a tremendous impact on the development and distribution of the software we depend on today. Through its collaborative and open way of both developing and sharing software components, OSS has served as a key engine for innovation and encouraged the widespread reuse and sharing of core software components. Today, nearly all applications are composed of components dependent upon other components, creating a supply chain that involves hundreds of components and multitiered dependencies.

开源软件 (OSS) 对我们今天所依赖的软件的开发和分发产生了巨大影响。通过其开发和共享软件组件的协作和开放方式，开源软件已成为创新的关键引擎，并鼓励核心软件组件的广泛重用和共享。如今，几乎所有应用程序都由依赖于其他组件的组件组成，从而形成了一个涉及数百个组件和多层依赖项的供应链。

Organizations of all sizes are heavily reliant on software, and much of that software supply chain consists of open source software components. Because of this, open source software has cybersecurity implications: the software supply chain is an attractive entry point for people and organizations interested in theft, disruption, or exploitation for economic or political gain. The attack surface today is changing from those in traditional cybersecurity threat models. Defects in small libraries that are widely used across the software ecosystem can cause systemic risk, as we've seen with incidents such as Log4shell.

各种规模的组织都严重依赖软件，其中大部分的软件供应链包含开源软件组件。正因为如此，开源软件具有网络安全的影响：软件供应链是入侵者利用进行盗窃、破坏或为了经济或政治利益而开发的一个有吸引力的入口点。如今，攻击面正在从传统的网络安全威胁模型中改变。在整个软件生态系统中广泛使用的小型库中的缺陷可能会导致系统性风险，正如我们在 Log4shell 等事件中所见到的那样。

Security challenges

安全挑战

Addressing the security of open source software components requires a different approach from traditional approaches of securing proprietary, vendor-supported software. The more loosely structured and community focused nature of OSS development presents a more challenging environment for addressing software security. The distribution of OSS projects is bookended by a small number of large visible projects (like the Linux kernel and Kubernetes) to a very large number of small projects. Smaller projects typically have fewer contributors and resources, and are therefore more likely to adopt a minimalist approach to development and security.

解决开源软件组件的安全问题需要与保护专有、供应商支持软件的传统方法不同的方法。开源软件的开发结构更加松散和以社区为重心，这种性质使得解决软件安全问题变得更具挑战性。开源软件项目的发布范围从少数几个大型可见项目（如Linux内核和Kubernetes）到非常多的小型项目。小型项目通常具有更少的贡献者和资源，因此更有可能采用简单的方法来对待开发和安全。

The tremendous benefits and prevalence of OSS in organizational software, combined with the vulnerability of the OSS software supply chain, puts us at a crossroads. Organizations and companies that use open source software need to become more aware of what dependencies they are using, proactively and regularly monitoring all components for usability, trustworthiness, and vulnerabilities. Ultimately, open source software is a two-way street: consumers of open source software must contribute back to the OSS communities to ensure the health and viability of the dependencies they rely on. Merely using open source software, without contributing back, is not enough. What is required is both to 1) incorporate the nature of OSS dependencies into standard cybersecurity and development practices and 2) contribute back to the OSS communities that organizations rely on.

开源软件在组织软件中所带来的巨大好处和普及性，加上开源软件供应链的脆弱性，让我们处于一个十字路口。使用开源软件的组织和公司需要更加了解它们所使用的依赖项，积极地和定期地监控所有组件的可用性、可信性和漏洞。最终，使用开源软件与回馈开源社区应该是一种互惠互利的关系：开源软件的消费者必须向开源软件社区做出贡献，以确保他们依赖的依赖项的健康和可行性。仅仅使用开源软件而不进行贡献是不够的。需要的是将开源软件依赖项的性质纳入标准的网络安全和开发实践中，并向组织依赖的开源软件社区做出贡献。

Research approach

研究方法

This report focuses on OSS security perspectives and how to improve OSS security and sustainability.

本报告的关注点在开源软件安全，以及如何改善开源软件的安全性和可持续性。

Research began in March 2022 with fifteen interviews of open source software maintainers and cybersecurity experts. These qualitative interviews helped to shape the scope of the research and the design of the quantitative survey instrument.

研究始于 2022 年 3 月，进行了 15 次开源软件维护者和网络安全专家的访谈。这些定性访谈有助于塑造研究范围和设计定量调查工具。

A worldwide survey was fielded in April 2022, targeting the following roles:

Individuals who contribute to, use, or administer Oss
Maintainers, core contributors, and occasional contributors to OSS
Developers of proprietary software to use OSS
Individuals with a strong focus on software supply chain security

2022 年 4 月，针对以下角色进行了一次全球调查：

贡献、使用或管理开源软件的个人
开源软件的维护者、核心贡献者和偶尔的贡献者
使用开源软件的专有软件开发人员
强烈关注软件供应链安全的个人

The survey included four sections:

Screening questions and demographics
OSS security perspectives. Sample size is 539 and margin of error (MoE) is +/- 3.6% at a 90% confidence level.
OSS best practices for secure software development. Sample size is 72. Only OSS maintainer and core contributors were invited to complete this section of the survey. Because of the technical detail that was characteristic of this section, it was not addressed as part of this report and instead will be discussed in a separate report to be published in 2022 Q3.
Improving OSS security. Sample size is 433 and margin of err (MoE) is +/-4.0% at a 90% confidence level.

该调查包括四个部分：

筛选问题和人口统计学信息
开源软件安全视角。样本量为 539，置信度水平为 90%，误差率(MoE)为 +/- 3.6%
为安全软件开发提供最佳实践。样本量为 72，只邀请了开源软件维护者和核心贡献者完成本部分的调查。由于这一部分的技术细节较多，本报告没有对其进行讨论，将在2022年三季度发表的另一份报告中进行讨论。
改进开源软件安全。样本量为 433，置信度水平为 90%，误差率(MoE)为 +/- 4.0%。

For more information about this research approach and sample demographics, see the methodology section of this paper. The data provided by Snyk is based on over 1.3 million projects and was collected from April 1, 2021 until March 31, 2022. Snyk's efforts were primarily focused on understanding how five key languages/ecosystems (.Net, Go, Java, JavaScript, and Python) are influencing the complexity of the software supply chain. This data was gathered from the use of Snyk Open Source, a static code analysis (SCA) tool free to use for individuals and open source maintainers.

更多有关此研究方法和样本统计信息的信息，请参阅本文的方法部分。 Snyk 提供的数据基于超过 130 万个项目，采集周期为 2021 年 4 月 1 日至 2022 年 3 月 31 日。Snyk 的工作主要集中在了解五种关键语言 / 生态系统（.Net、Go、Java、JavaScript 和 Python）如何影响软件供应链的复杂性上。这些数据是通过使用 Snyk 开源工具收集的，该工具是一个静态代码分析（SCA）工具，供个人和开源维护人员免费使用。

Open source software security perspectives

开源软件安全观点

Initial questions in this survey were designed to understand organizational commitment to security that covers OSS development and use and beliefs about the security of the OSS and its dependencies in use. Responses to these questions suggest that organizations collectively have been slow to make software security a priority.

该调查的初始问题旨在了解组织在涵盖开源软件开发和使用方面的安全承诺以及对正在使用的开源软件及其依赖性安全性的信念。对这些问题的回答表明，组织在使软件安全成为优先事项方面进展缓慢。

Many organizations do not have a security policy that covers OSS

许多组织没有涵盖开源软件的安全政策

One of the most startling findings of this research, as shown in Figure 1, is that only 49% of organizations have a security policy that covers OSS development or use. 34% of organizations indicate that they do not have a security policy for OSS development and usage, and 17% of respondents were not sure if their organization had a plan or not. If we prorate this 17% based on the existing distribution of responses, the number of organizations with a security policy covering OSS rises from 49% to 59%, and those without a policy rise from 34% to 41%.

这项研究最惊人的发现之一是，如图 1 所示，只有 49％的组织拥有涵盖开源软件开发或使用的安全策略。34％的组织表示，他们没有开源软件开发和使用的安全策略，17％的受访者不确定他们的组织是否有计划。如果将这17％根据现有的回答分布来按比例分配，则拥有涵盖开源软件的安全策略的组织数量从49％上升到59％，而没有策略的组织则从34％上升到41％。

Figure 1: Organizations with a security policy covering OSS

图1：有涵盖开源软件的安全政策的组织

Do you have an open source security policy in place for open source development or usage? (select one)

您是否已为开源软件的开发或使用制定了开源安全政策？（请选择一项）

Yes：
是

No：
否

Total：
不知道（英文应该是错了，坐标轴上是Don't know）

Having a security policy covering OSS indicates that you have a security action plan that includes the many OSS components in use. Without a software security policy, organizations may expose themselves to a significant amount of financial and reputational risk because they may not be evaluating software before its inclusion and/or may not be prepared for the inevitable updates due to software vulnerabilities (OSS or not).

拥有涵盖开源软件的安全策略表示您拥有包含许多使用的开源软件组件的安全行动计划。如果没有软件安全策略，组织可能会面临相当大的财务和声誉风险，因为他们可能没有在将软件包含进项目之前进行评估，或者可能没有为由于软件漏洞（无论是开源软件还是其他软件）而不可避免的更新做好准备。

Note that we intentionally did not have any special requirements on how the security policy covering OSS was stated. Some organizations have a single policy on software, and then only have specific statements for OSS in the relatively few cases where OSS would be sensibly different. This would be an application of the so-called "Hellekson's Law" ("a more specific policy can be improved for the general case by removing delimiters that narrow the policy scope, "e.g., deleting "open source" from an "open source software" policy typically improves it). For our purposes this is fine. We simply let the respondents identify whatever applied to their organization.

请注意，我们有意没有对涵盖开源软件的安全策略有任何特殊要求。一些组织只有一个关于软件的策略，然后仅在开源软件有相对少的情况下才有特定的声明。这是所谓的“Hellekson 定律”的应用（“通过删除缩小策略范围的分隔符，例如，从“开源软件”策略中删除“开源”，可以改进通用情况下的更具体策略）。对于我们的研究目的来说，这是可以接受的。我们只是让受访者确定他们所在组织适用的情况。

The one benefit of the distribution shown in Figure 1 is that we can statistically compare and contrast the characteristics of organizations with a security policy against those without one. Understanding these comparative differences helps us describe the OSS security journey that organizations are on.

图 1 所示的分布的一个好处是，我们可以对拥有安全策略的组织与没有安全策略的组织进行统计学比较和对比。了解这些比较差异有助于我们描述组织在开源软件安全方面的旅程。

Small organizations shoulder disproportionate OSS security risk

小型组织承担着不成比例的开源软件安全风险

This survey included organizations of various sizes (based on the number of worldwide employees). The survey sample was distributed by organization size as follows: small organizations (44%, 1-499 employees), medium organizations (20%, 500-4,000 employees), large organizations (35%, 5,000+ employees), and 1% don’t know or are not sure.

本次调查涵盖了各种规模的组织（根据全球员工人数划分）。调查样本按组织规模分布如下：小型组织（44％，1-499 名员工），中型组织（20％，500-4,000 名员工），大型组织（35％，5,000 名及以上员工），1％不知道或不确定。

The measure of security policy covering OSS by organizational size is shown in Figure 2. Immediately noticeable is the difference in distributions between organizations with 1-499 employees and those with 500 employees or more. Just 41% of small organizations have an OSS security policy, compared to 56%-57% of larger organizations. This significant difference indicates that small organizations behave differently than larger organizations when it comes to OSS security policy adoption.

按组织规模衡量涵盖开源软件的安全政策的情况如图 2 所示。立即显着的是，1-499 名员工的小型组织和 500 名员工以上的组织之间的分布差异。只有 41% 的小型组织拥有开源软件安全政策，而大型组织的开源软件安全政策采用率在 56%-57% 之间。这个显著的差异表明，小型组织在开源软件安全政策采用方面的行为与大型组织不同。

Figure 2: A distribution of OSS security policy by organization size

图 2：按组织规模分布的开源软件安全策略

Do you have an open source security policy in place for open source development or usage? (select one) by Enterprise size

您是否有针对开源软件开发或使用的开源安全策略？按企业规模（选择一项）


Yes: 
是

No: 
否

Don't know: 
不知道

1 to 499 Emp: 
员工数 1～499

500 to 4999 Emp: 
员工数 500~4999

5000+ Emp: 
员工数 5000+

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

One reason that small organizations are OSS security challenged is economies of size. Small organizations have small IT staff and budgets, and the functional needs of the business often take precedence so that the business can remain competitive. Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices.

小型组织开源软件安全面临挑战的原因之一是规模经济。小型组织拥有较少的 IT 人员和预算，业务的功能需求通常具有优先性，以使业务能够保持竞争力。缺乏资源和时间是组织未能解决开源软件安全最佳实践的主要原因。

While it is disappointing that 44% of small organizations do not have an OSS security policy, an additional concern is that close to 30% of larger organizations also do not have an OSS security policy. Small organizations can rationalize increased financial, reputational, and legal risk, but this becomes tenuous for medium organizations and insupportable for large organizations with 5000+ employees. Medium and large organizations likewise complain about not enough having resources or time to address OSS security needs. Surprisingly, a lack of awareness about security best practices is more often identified by large organizations as a reason for not attending to OSS security needs than lack of time.

虽然令人失望的是，44% 的小型组织没有开源软件安全策略，但更令人担忧的是，接近 30% 的大型组织也没有开源软件安全策略。小型组织可以理性地解释为增加财务、声誉和法律风险，但对于 5000 多名员工的中型和大型组织来说，这变得岌岌可危。中型和大型组织同样抱怨没有足够的资源或时间来应对开源软件安全需求。令人惊讶的是，大型组织更常常将缺乏安全最佳实践的意识视为不关注开源软件安全需求的原因，而不是时间不足。

Many Organizations score poorly on OSS security

许多组织在开源软件安全方面得分低

We asked organizations how secure their open source software is today. Responses to this question are shown in Figure 3. Overall, 59% of organizations feel their OSS is either somewhat secure or highly secure. For organizations with an OSS security policy, this value rises to 70%. It falls to 45% for organizations without a security policy.

我们询问了组织关于他们的开源软件安全性的评估。这个问题的回答如图 3 所示。总体而言，59% 的组织认为他们的开源软件在某种程度上是安全的或者非常安全的。对于有开源软件安全策略的组织，这个比例上升到了 70%。而对于没有安全策略的组织，这个比例则下降到了 45%。

Figure 3: OSS security today

图 3：当今的开源软件安全情况

How secure is your open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?

您的开源软件今天有多安全？按您是否有一个用于开源开发或使用的开源安全策略进行分组（选择一项）

65
Weighted Avg of responses
Score range: 0 -100

65
回答的加权平均分
分数范围：0～100

Yes：
是

No：
否

Total：
综合

Highly Insecure：
非常不安全

Somewhat Insecure：
有些不安全

Neither Insecure or Secure：
中性

Somewhat Secure：
有些安全

Highly Secure：
非常安全

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

A simple weighted average of all responses shows a composite score of 65 for all organizations, which is a poor grade. Organizations with an OSS security policy score a 70, and organizations without a policy score a 58.

简单的加权平均所有回答的分数显示，所有组织的综合分数为 65 分，这是一个不好的分数。拥有开源软件安全策略的组织得分为 70 分，而没有策略的组织得分为 58 分。

The secure development of OSs is also at risk

开发或使用开源软件的安全问题同样存在风险

Similarly, Figure 4 shows how secure the process for developing or using OSS is today. Using the same responses shown in Figure 3, the results are nearly identical. Across all organizations, 59% believe that their development processes are somewhat secure or highly secure. This value rises to 73% for organizations with an OSS security policy and falls to 47% for organizations without.

同样，图 4 展示了开发或使用开源软件的过程的安全性。使用图 3 中展示的相同回答，结果几乎相同。在所有组织中，59% 的人认为他们的开发过程是相对安全或高度安全的。对于拥有 OSS 安全策略的组织，这个值升至 73%，而对于没有安全策略的组织，则下降至 47%。

Figure 4: Security of OSS development and use today

图 4：如今的开源软件开发和使用的安全性

How secure is your process for developing or using open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?

您是否已经针对开源开发或使用实施了开源安全策略？（选择一项）按照您是否对开源开发或使用实施了安全策略，您认为您目前的开源软件开发或使用流程有多安全？（选择一项）

65
Weighted Avg of responses
Score range: 0 -100

65
回答的加权平均分
分数范围：0～100

Yes：
是

No：
否

Total：
综合

Highly Insecure：
非常不安全

Somewhat Insecure：
有些不安全

Neither Insecure or Secure：
中性

Somewhat Secure：
有些安全

Highly Secure：
非常安全

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

The similarity of this distribution when compared to Figure 4 also yields a weighted average of 65 and organizations with the security policy score 71 and organizations without a policy 58.

与图 4 相比，这个分布的相似性也产生了一个加权平均值为 65，安全策略得分为 71，没有策略的组织得分为 58。

Across organizations, there is a belief that the security of OSS development and use will improve to a weighted average score of 72 by the end of 2022 and 77 by the end of 2023. Later in this report, you will see that an organizational cornerstone of their OSS security strategy is for the vendor community to provide security tools with greater intelligence. Other key elements of their OSS security strategy include a more complete understanding of best practices for secure software development and greater CI/ CD automation to eliminate manual actions and opportunities that expose the pipeline to security risks.

跨组织而言，人们认为到 2022 年底，OSS 开发和使用的安全性将提高到加权平均分数为 72，到 2023 年底将提高到 77。在本报告的后面部分，您将看到，组织制定的 OSS 安全策略的基石是让供应商社区提供更具智能的安全工具。他们的 OSS 安全策略的其他关键要素包括更全面地了解安全软件开发的最佳实践，并实现更多的 CI / CD 自动化以消除手动操作和可能导致安全风险的机会。

Who drives OSS security policies?

谁推动了开源软件安全策略？

Figure 5 superficially creates a conundrum: how do organizations without a top-down OSS security policy have people responsible for defining OSS security policy? Additionally. not having an OSS security policy doesn't mean that groups aren't addressing OSS security in ad hoe ways.

图 5 表面上制造了一个难题：没有由上而下的开源软件安全策略的组织如何有负责定义开源软件安全策略的人？此外，没有开源软件安全策略并不意味着各组没有以临时方式解决开源软件安全问题。

Across organizations, just 31% vest responsibility for defining an OSS security policy in the hands of a CIS and/or security team. The second leading choice of multiple teams at 16% suggests that instead of policy being established by a CIS, it evolves across the Software Development Life Cycle (SDLC) based on the focus of the team. Because a security focus should exist across the CI/CD pipeline, multiple teams are needed to implement OSS security policy. Reliance on open source maintainers at 13% overall can be workable 1f the maintainers are either part of the organization or known to the organization - but it sdems recklessly optimistic to put trust in OSS projects with unknon provenance.

跨组织而言，仅有 31% 的组织将定义 OSS 安全策略的责任归属于 CIS（计算机信息安全）和 / 或安全团队。16% 的多个团队作为第二选择表明，政策的制定不是由 CIS 确定的，而是根据团队的重点在软件开发生命周期 (SDLC) 中逐步形成。由于在 CI/CD 管道中应存在安全重点，因此需要多个团队来实施 OSS 安全策略。总体上依赖于开源维护者的 13% 可能是可行的，前提是维护者要么是组织的一部分，要么已知于组织，但是如果信任来源未知的 OSS 项目，这种做法似乎过于乐观。

Figure 5: Responsibility for OSS security policies
Who is responsible for defining your open source security policy? (select one) by Do you have an open source security policy in place for open source development or usage?

图5：开源安全策略的责任
谁负责制定您的开源安全策略？（选择一项）按您是否有适用于开源开发或使用的开源安全策略？

Yes：
是

No：
否

Total：
综合

Security team and /or CISO：
安全团队/CISO

Multiple teams：
多个团队

Open source maintainers：
开源维护者

No one：
没有人

Developer or care contributor：
开发人员或贡献者

Operations or Bite Reliability Engineers (SREs)：
运维或可靠性工程师（SREs）

Contributors from other teams：
其他团队的贡献者

Don’t Know：
不知道

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

The percentages in Figure 5 are especially revealing. Across organizations with an OSS security policy, 80% vest the definition of an OSS security policy with the CISO/security team, multiple teams, or open source maintainers. This contrasts with organizations without an OSS security policy where 40% of these same groups are involved with OSS security in some capacity.

在图 5 中的百分比特别说明了问题。在有开源安全策略的组织中，80％的组织将开源安全策略的定义授予CISO/安全团队、多个团队或开源维护人员。这与没有开源安全策略的组织形成对比, 在没有开源安全策略的组织中，同样的团队有40％以某种方式参与开源安全。

Perhaps one positive indicator in Figure 5 is that only 30% of organizations without an OSS security policy admit that no one is addressing OSS security. This means that 70% of these organizations are addressing OSS security in part through ad hoc means, suggesting that organizations without an OSS security policy are not completely adrift and have some grassroots activities to address OSS security needs.

或许在图 5 中令人欣慰的一个指标是，仅有 30% 的没有开源安全策略的组织承认没有人在处理开源安全。这意味着 70% 的这些组织通过一些临时手段部分地解决了开源安全问题，表明没有开源安全策略的组织并非完全漂泊无助，有一些基层活动来解决开源安全需求。

Organizations are not effectively managing the security of their dependencies

组织未能有效地管理其依赖项的安全性

Dependencies are a characteristic of modern development. Direct dependencies are typically components or services called directly by your code. Indirect or transitive dependencies are essentially dependencies of your dependencies (in typically many tiers).

依赖项是现代开发的一个特征。直接依赖通常是被你的代码直接调用的组件或服务。间接或传递依赖实际上是您依赖的依赖（通常是多个层次）的依赖。

Vulnerabilities exist in component code for many reasons. Contributing factors include the programming language used, the CI/CD process in use, the education and skill of the developer in developing secure software, and the scope of testing. Complicating matters is that vulnerability management is not a perfect science. Vulnerability scanning normally identifies many false positives based on the information available to the scanning tool. Conversely, an actual vulnerability in a component may not matter if the code linked to the vulnerability is never executed and/or will only provide trusted data to the vulnerable code.

组件代码存在漏洞的原因有很多。其中的因素包括使用的编程语言、使用的 CI/CD 过程、开发人员在开发安全软件方面的教育和技能以及测试的范围。复杂化问题的是，漏洞管理并不是一门完美的科学。漏洞扫描通常会基于扫描工具可用的信息识别出很多误报。相反，如果与漏洞相关的代码从未被执行，或者只会向漏洞代码提供可信数据，那么组件中的实际漏洞可能就不重要了。

What is known is that organizations are not well-positioned to manage their vulnerabilities. Only one response in Figure 6 indicates that organizations are confident in the security of their direct dependencies.

已知的是，组织机构无法很好地管理它们的漏洞。在图6中，只有一个回答表明组织机构对其直接依赖项的安全性感到有信心。

Figure 6: Vulnerability concerns across direct dependencies
图 6：对直接依赖项的漏洞担忧

How concerned are you that the direct dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?
你对软件所依赖的直接依赖项可能是恶意或受到攻击有多担忧？（选择一个）你是否已经为开源开发或使用制定了开源安全策略？

Yes：
是

No：
否

Total：
综合

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

Direct dependencies are easy to track but we struggle with indirect dependencies
直接依赖项易于跟踪，但我们难以处理间接依赖项

We don’t have good controls to address this & it concerns me
我们没有好的控制措施来解决这个问题，这让我感到担忧

We have strong controls & I’m confident in the security of our direct dependencies
我们有强有力的控制措施，我对我们的直接依赖关系的安全性感到有信心

We don’t have good controls to address this but it doesn’t concern me
我们没有好的控制措施来解决这个问题，但我并不担心

Don’t Know：
不知道

Across all organizations, only 24% have confidence in the security of their direct dependencies. This value rises to 36% for organizations that have an OSS security policy but falls to just 9% of organizations without such a security policy. Organizations reporting that dependencies are easy to track (37%) may be correct in understanding their dependencies, but this doesn't mean that these dependencies are collectively secure.

所有组织中，只有 24% 的组织对其直接依赖项的安全性感到有信心。对于有开源安全策略的组织，这个值上升到 36％，但对于没有安全策略的组织，这个值只有 9％。报告依赖项项易于跟踪的组织（37％）可能正确地理解了它们的依赖项，但这并不意味着这些依赖项总体上是安全的。

Snyk - Dependencies drive complexity

Snyk - 依赖关系驱动复杂性

Dependencies are one of the key components driving much of the conversation about the software supply chain. Professionals in both development and security teams are increasingly aware that securing their enterprise does not depend entirely on their organization. Instead, we are having to look further and further, down the rabbit hole of "Where did this code come from?" It's hard enough to understand where everything originated when you're trying to test code written in-house. When you add dependencies two, three, or more levels deep, it becomes daunting to even consider the problem.

依赖项是推动软件供应链讨论的关键组成部分之一。开发和安全团队的专业人员越来越意识到，保护他们的企业并不完全依赖于他们的组织。相反，我们不得不越来越深入地查看“这段代码来自哪里？”的问题。当您尝试测试内部编写的代码时，了解所有代码的起源已经很难了。当您添加两个、三个或更深层次的依赖项时，甚至考虑这个问题都变得令人生畏。

The libraries we call in our code, the code snippets we pull from the internet, and the tools we include in container configurations are all examples of direct dependencies. In each of these cases we are relying on third-party code explicitly to fulfill a specific need or purpose.

直接依赖项是我们在代码中调用的库、从互联网获取的代码片段以及包含在容器配置中的工具等。在这些情况下，我们明确地依赖第三方代码来满足特定的需求或目的。

Measuring the number of dependencies per project, therefore, makes a good starting point for understanding how complex the problem of tracking dependencies really is. As shown in Figure 7, the average number of dependencies per project stretches from Python, with 25 dependencies per project, to JavaScript's 173 per project.

因此，衡量每个项目的依赖关系数量是了解跟踪依赖关系问题的复杂性的好起点。如图 7 所示，每个项目的平均项数量从 Python 的 25 个到 JavaScript 的 173 个不等。

Does that mean JavaScript is inherently more complex than .Net (49 dependencies), Go (56 dependencies), or Java (40 dependencies)? Not necessarily. In the case of JavaScript, each dependency often has a single purpose and small scope, rather than a library that fulfills multiple purposes with a large scope.

这是否意味着 JavaScript 本质上比 .Net（49 个依赖项）、Go（56 个依赖项）或 Java（40 个依赖项）更复杂？不一定。在 JavaScript 的情况下，每个依赖项通常只有一个目的和小的范围，而不是一个具有大范围的多个目的的库。

Neither approach is more or less secure than the other but knowing which dependencies you rely on (and how trustworthy they are) is an important part of vulnerability management. Sadly, only 24% of the respondents in this survey felt they had strong controls in place to handle the security of their dependencies.

这两种方法都不比另一种更安全，但了解你依赖的依赖项（以及它们的可信度）是漏洞管理的重要组成部分。不幸的是，在此次调查中，只有 24% 的受访者认为他们已经采取了强有力的措施来处理其依赖项的安全性。

Figure 7: Average dependency count per project by language
图 7：按语言每个项目的平均依赖项数量

（下面几个编程语言不翻译）
.Net
Go
Java
JavaScript
Python

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022年开源供应链安全调查。

Average dependencies per project
平均每个项目的依赖项数量

Recent efforts by the US Government to encourage, and even mandate, organizations to create a Software Bill of Materials (SBOM) is evidence of how important it is to have a handle on dependencies. Tracking direct dependencies is a significant issue by itself. Indirect, or transitive, dependencies mark the real start of complexity. Each of the libraries referenced in a project incorporates additional code to perform its own function, and each of those third-party libraries may rely on other libraries as well. Organizations who want a complete accounting of their transitive dependencies should be requiring SBOMs from their suppliers and investing in tools to consume these SBOMs.

美国政府最近鼓励甚至强制要求组织创建软件清单（SBOM）的努力，证明了掌握依赖项关系的重要性。追踪直接依赖项本身就是一个重大问题。而间接或传递性依赖项才是复杂性的真正开始。每个在项目中引用的库都会包含额外的代码来执行其自身的功能，而每个这样的第三方库可能也依赖于其他库。想要完整记录传递依赖关系的组织应该要求其供应商提供 SBOM，并投资于消费这些 SBOM 的工具。

Figure 8 is patterned directly after Figure 6, except that it focuses on transitive dependencies. Transitive dependencies are objectively more difficult to evaluate as the level of dependency increases. The result is that fewer organizations believe that their transitive dependencies are secure

图 8 直接复制了图 6 的结构，不过它专注于间接依赖项。随着依赖程度的增加，间接依赖项的评估变得更加困难，因此，越来越少的组织认为它们的间接依赖项是安全的。

Figure 8: Vulnerability concerns across transitive dependencie
图 8：跨传递依赖项的漏洞问题

How concerned are you that the indirect (transitive) dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?
您担心您的软件间接（传递）依赖项可能存在恶意或被攻击的风险吗？ （选择一项） 您是否为开源开发或使用制定了开源安全策略？

Figure 8 shows that just 18% of organizations are confident in the security of their transitive dependencies. Once again, this value rises to 27% for organizations that have an OSS security policy but plummets to just 5% for organizations without a security policy.

图 8 显示，只有18%的组织对其传递依赖项的安全性有信心。同样，这个值对于制定了开源安全策略的组织上升至27％，但对于没有安全策略的组织则下降至5％。

A recent discussion with David A. Wheeler, a leading authority on OSS security, yielded this insight, "I think many organizations often don't update their OSS software, even when the older version of the OSS has widely-known vulnerabilities. That's not unique to OSS, many organizations also often don't update old versions of proprietary software with widely-known vulnerabilities

与开源软件（OSS）安全方面的权威专家大卫·A·惠勒（David A. Wheeler）的最近一次讨论得出了这样的见解：“我认为许多组织经常不更新他们的开源软件，即使旧版本的开源已经被广泛知晓的漏洞所影响。这不仅仅是开源的问题，许多组织也经常不更新旧版本的专有软件，而这些软件也有广泛已知的漏洞。”

Snyk - Dependency creates vulnerability

Snyk - 依赖关系创建了漏洞

How many vulnerabilities are there in my project? We estimated this by totaling known vulnerabilities in a particular project combined with the known vulnerabilities of its dependencies (presuming that the vulnerabilities in the dependencies were exploitable). The Net projects in our data had 23 vulnerabilities per project on average, with Go at 34, Java at 90, JavaScript having 47, and Python at 36. This covers both errors introduced in development and vulnerabilities in transitive dependencies. According to Snyk's data, approximately 40% of all vulnerabilities are from these transitive dependencies. We further broke down the count of vulnerabilities per project in Figure 9 to highlight the effect of severity by language.

我的项目中有多少漏洞？我们通过汇总一个特定项目中已知的漏洞以及其依赖项的已知漏洞数量来估计。假设依赖项中的漏洞是可利用的。我们的数据中，.Net 项目平均有 23 个漏洞，Go 项目有 34 个漏洞，Java 项目有 90 个漏洞，JavaScript 项目有 47 个漏洞，Python 项目有 36 个漏洞。这包括开发中引入的错误和传递依赖项中的漏洞。根据 Snyk 的数据，大约 40% 的漏洞来自这些传递依赖项。我们在图 9 中进一步分解了每个语言的漏洞计数，以凸显严重性的影响。

A large part of the value of SCA tools is finding where vulnerabilities are being introduced by the use of known bad libraries. Is your code incorporating an older version of a library with known vulnerabilities? Is the package still maintained or is it abandoned? Did you accidentally get a library pretending to be the one you actually wanted? These are just a few of the potential issues that could get a package flagged.

SCA 工具的很大一部分价值在于发现由于使用已知存在漏洞的库所引入的漏洞。您的代码是否正在使用一个存在已知漏洞的旧版库？该软件包是否仍在维护中或已被放弃？您是否意外获取了一个假冒您实际需要的库？这些也只是可能会导致软件包被标记的一些潜在问题。

Knowing the number of vulnerabilities in your own project helps you understand how your efforts compare to global numbers. Organizations that see data far different from the baseline number of vulnerabilities in a project can investigate the causes of a disparity. It could be as simple as different ways of measuring the same metric. On the other hand, the difference in numbers could indicate poor coding practices or a large number of old libraries being part of a standard. Without policies and standards that require vulnerability tracking, you may never know.

了解自己项目中漏洞的数量有助于了解自己的努力与全球数据相比的情况。看到与项目中基线漏洞数量迥然不同的数据的组织可以调查差异的原因。这可能只是衡量同一指标的不同方法。另一方面，数字的差异可能表明糟糕的编程实践或大量的旧库作为标准的一部分。如果没有要求跟踪漏洞的政策和标准，您可能永远不会知道。

Figure 9: Average count of vulnerabilities by language and severity

图 9：按语言和严重程度划分的平均漏洞数量

Vulnerability Severity
漏洞严重程度

Critical：
严重

High：
高危

Medium：
中危

Low：
低危

（编程语言不翻译）
.Net
Go
Java
JavaScript
Python

Source: 2022 Snyk user data.
来源：2022年 Snyk 用户数据。

Tracking vulnerabilities introduced by transitive dependencies is one of the hardest challenges in DevOps today. Think about a project that has fifty dependencies; if the average project has five critical vulnerabilities, just the first level of dependencies could lead to 200+ critical vulnerabilities. Each layer down expands the problem dramatically. Luckily, most vulnerabilities are tightly constrained by the factors needed to exploit them.

跟踪由传递依赖引入的漏洞是当今 DevOps 面临的最大挑战之一。考虑一个有 50 个依赖项的项目；如果平均每个项目有 5 个严重漏洞，那么仅第一级依赖关系就可能导致 200 多个严重漏洞。每一层依赖都会大大扩大问题的规模。幸运的是，大多数漏洞都受到利用所需因素的严格限制。

How organizations are addressing and prioritizing their cybersecurity needs

组织如何解决和优先考虑其网络安全需求

A key finding of this research is that security, as it applies to OSS, is a rapidly evolving domain. Each of the primary threat vectors (source threats, build threats, and dependency threats) identified in the SLSA (Supply Chain Levels for Software Artifacts) model will require multiple actions on the part of most organizations to address. However, because OSS security is also rapidly evolving, increased functionality and tool consolidation should help reduce the complexity that organizations face in addressing software supply chain security needs.

该研究的一个关键发现是，与开源软件(OSS)相关的安全性是一个快速发展的领域。SLSA（软件工件供应链级别）模型中确定的每个主要威胁向量（源威胁、构建威胁和依赖威胁）都需要大多数组织采取多个行动来应对。然而，由于开源软件的安全性也在快速发展，增加功能和工具整合应该有助于减少组织在应对软件供应链安全需求方面面临的复杂性。

This section of the report describes how organizations are addressing how vulnerabilities in code are found, how security of OSS components is evaluated, what security-focused tools are being used, and what security-related activities are most important.

本报告的这一部分描述了组织如何解决代码中的漏洞如何被发现，如何评估开源组件的安全性，使用了哪些专注于安全的工具，以及哪些与安全相关的活动最为重要。

Figure 10: Finding vulnerabilities in your dependencies
How do you find out about vulnerabilities in your dependencies? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图表 10：发现依赖项中的漏洞
您如何了解依赖项中的漏洞？（选择所有适用项）按照您是否有针对开放源代码开发或使用的安全策略进行筛选。

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Industry vulnerability notifications
行业漏洞通知

Automated monitoring of packages for known vulnerabilites
自动监测已知漏洞的软件包

Notifications form package maintainers
来自软件包维护者的通知

Industy blogs and news site
行业博客和新闻网站

Through an external security audit
通过外部安全审计

We find out when they are exploited in the wild
我们发现了漏洞当它们在外面被利用了

Trust groups
信任的群体

Hackers
黑客

Don’t Know
不知道

Organizational approaches to identifying vulnerabilities in dependencies

组织内识别依赖漏洞的方法

A common question in addressing OSS security is how to comprehensively identify vulnerabilities across your dependencies. Figure 10 shows that there are four commonly used techniques to identify vulnerabilities. The leading approach practiced by 53% of organizations is to subscribe to one or more vulnerability catalogs from CISA (US-CERT), NIST (NVD), MITRE (CVE), security product & service vendors, and/or catalog aggregators (like FIRST) that aggregate content from leading worldwide sources. These subscriptions have the advantage of pushing vulnerability notifications to their subscribers.

在处理开放源代码软件（OSS）安全问题时，一个常见的问题是如何全面地识别依赖关系中的漏洞。图10显示了四种常用的识别漏洞的技术。53%的组织采用的主要方法是订阅来自CISA（美国国家信息安全局），NIST（美国国家标准与技术研究所），MITRE（通用漏洞披露系统）以及安全产品和服务供应商和/或目录聚合器（例如FIRST）的一个或多个漏洞目录，这些目录汇集了来自全球领先的信息源的内容。这些订阅的优点是向其订阅者推送漏洞通知。

The second leading approach is automated monitoring — or scanning of packages for known vulnerabilities — and is practiced by 49% of organizations. One challenge with this approach is that it’s often difficult to map vulnerability reports to the component(s) containing the vulnerabilities. For example, there may be a vulnerability reported in some component foo, but often there are many components and forks named foo so users often can’t be confident when a report is relevant. While it’s a best practice to scan code formulaically based on time, changes to the code base and the identification of relevant vulnerabilities, a comprehensive approach to this technique is still on the horizon.

第二个主要方法是自动化监控或扫描已知漏洞的软件包。这种方法被49%的组织所采用。这种方法的一个挑战是，往往很难将漏洞报告映射到包含漏洞的组件上。例如，可能会报告某个组件foo中存在漏洞，但通常有许多命名为foo的组件和分支，因此用户经常无法确定报告的相关性。虽然根据时间、代码库的更改和相关漏洞的识别来公式化地扫描代码是最佳实践，但是这种技术的全面方法仍然需要探索。

Notifications from package maintainers are leveraged by 47% of organizations and can provide a conduit to keep packages updated when supported by maintainers. Industry blogs and news sites are used by 43% of organizations and can facilitate the timely delivery of information for a better sense of importance.

软件包维护者的通知被47%的组织所利用，当维护者支持时，可以提供更新软件包的渠道。行业博客和新闻网站被43%的组织使用，可以促进及时传递信息，以获得更好的重要性感知。

Snyk - How long will it take to fix?

Snyk - 需要多长时间来修复？

Once a vulnerability has been identified, the next logical question is “How long is this going to take to fix?” The answer is all too often, “I don’t know. It’s complicated.” Unsurprisingly, the question becomes even more complex when we apply it to the software supply chain. Our dependence on third-party code, especially transitive dependencies, often make that question difficult or impossible to answer.

一旦发现漏洞，下一个合理的问题是“修复需要多长时间?” 答案往往是：“我不知道。这很复杂。” 不出所料，当我们将其应用于软件供应链时，这个问题变得更加复杂。我们对第三方代码的依赖，尤其是传递依赖，经常使得这个问题难以或不可能回答。

Looking at the average time to fix by language in Figure 11, we see that Snyk’s data shows that Go has the best time to fix at 49 days, while .Net is the obvious laggard at 148 days to fix a vulnerability. While some maintainers might be able to fix vulnerabilities in days or hours, there have been a few vulnerabilities that took years to remediate.

观察图 11 中按语言分组的平均修复时间，我们可以看到 Snyk 的数据显示 Go 语言具有最佳的修复时间，为 49 天，而 .Net 则是明显的落后者，需要 148 天来修复漏洞。虽然一些维护者可能能够在几天或几小时内修复漏洞，但也有一些漏洞需要数年时间才能修复。

Figure 11:
Average time to fix by language

图 11：
按语言修复漏洞的平均时间

（坐标轴编程语言不翻译）

Source: 2022 Snyk user data.
来源：2022 年 Snyk 用户数据。

We expect that popularity and awareness influence the time to fix. A popular project is more likely to attract other collaborators, and additional collaborators can speed up incident response time. In addition, if a project is popular, awareness by users (including via technical press news) is likely to be larger.

我们预计受欢迎程度和意识会影响修复时间。一个受欢迎的项目更有可能吸引其他协作者，而额外的协作者可以加快事件响应时间。此外，如果一个项目很受欢迎，用户（包括通过技术新闻媒体）的关注度可能会更高。

A popular project can affect a significant portion of all projects. As an example, the Spring Framework library is found in 9% of all Java projects. The team responsible for Spring Framework responded quickly to fix the Spring4Shell remote code execution vulnerability when it was identified in the spring of 2022. But what if that vulnerability had existed in a less responsive yet popular package?

一个受欢迎的项目可能影响所有项目的重要部分。例如，Spring 框架库在所有 Java 项目中都有 9％的使用率。当在 2022 年春季发现 Spring4Shell 远程代码执行漏洞时，负责 Spring 框架的团队迅速做出了修复。但如果该漏洞存在于一个反应较慢但受欢迎的软件包中会怎样呢？

Figure 12: Finding vulnerabilities in your code
How do you find out about security vulnerabilities in your code? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图 12：发现代码中的安全漏洞
如何发现您的代码中的安全漏洞？（选择所有适用项）根据您是否制定了开放源代码安全策略来决定。

We find them in CI when a SAST tool runs
我们在 CI 中运行 SAST 工具时发现它们

We find them when using Software Composition Analysis (SCA) tools or services
我们在使用软件构成分析（SCA）工具或服务时发现它们

We find them in our IDE using an extension for static code analysis
我们在 IDE 中使用静态代码分析扩展程序时发现它们

They get identified during peer review
它们在同行评审期间被识别

Publication in the National Vulnerability Database
发布到国家漏洞数据库

We use a command-line tool to detect them
我们使用命令行工具检测它们

Through an external security audit
通过外部安全审计

We find out when they are exploited in the wild
我们在它们被实际利用时发现

Bug bounties help disclose them
赏金计划有助于披露它们

We don’t
我们不知道

Other
其他

Don’t Know
不知道

Organizational approaches to identifying vulnerabilities in code

组织内识别代码漏洞的方法

Finding security vulnerabilities in code requires multiple approaches, much like finding vulnerabilities in dependencies. Figure 12 identifies the leading ways that developers find security vulnerabilities. The leading approach used by 39% of organizations, of the options included in the survey, is to use a SAST (Static Application Security Testing) tool. SAST tools are immensely useful during development because they can be configured to run automatically as part of a CI (continuous integration) process and can often identify specific line(s) of code responsible for a vulnerability.

发现代码中的安全漏洞需要多种方法，就像发现依赖项中的漏洞一样。图表 12 显示了开发人员发现安全漏洞的主要方式。在调查包括的选项中，39% 的组织使用 SAST（静态应用程序安全测试）工具，这是最常用的方法。SAST 工具在开发过程中非常有用，因为它们可以配置为作为 CI（持续集成）过程的一部分自动运行，并且通常可以确定负责漏洞的具体代码行。

The second leading approach practiced by 33% of organizations, among the survey options, is to use an SCA (software composition analysis) tool. Use of these tools can be automated, and they typically address manifest scanning and binary scanning to identify known security vulnerabilities, licensing issues, or quality problems. While this capability is more closely associated with finding vulnerabilities in dependencies, including SCA in the build process helps OSS security activities to shift left.

第二个主要方法是SCA（软件构成分析）工具，SCA工具被在调查选项中的33%中的组织使用。使用这些工具可以自动化，并且通常涉及清单扫描和二进制扫描，以识别已知的安全漏洞、许可问题或质量问题。虽然这种能力更与发现依赖项中的漏洞密切相关，但将SCA纳入构建流程有助于将开源软件的安全活动向左移动。

Finally, a SAST tool can be used within an IDE providing the developer with a more immediate, hands-on, and configurable approach to manual security testing. What this approach lacks in automation is more than compensated for in direct and timely developer involvement. Figure 12 shows that 30% of organizations leverage this approach.

最后，SAST工具可以在集成开发环境（IDE）中使用，为开发人员提供更直接、及时和可配置的手动安全测试方法。虽然这种方法缺乏自动化，但直接且及时的开发人员参与可以弥补这一不足。图12显示，30% 的组织利用这种方法。

Although just 29% of organizations use peer review to help identify vulnerabilities in code, peer review and a reliance on multifunctional teams is a best practice and cornerstone of agile development.

尽管只有29%的组织利用同行评审来帮助发现代码漏洞，但同行评审和依赖于多功能团队是敏捷开发的最佳实践和基石。

Although this particular survey question did not offer tool choices other than SCA and SAST, Figure 14 does and confirms the leading popularity of SCA and SAST tools.

尽管此项调查问题未提供除SCA和SAST之外的工具选择, 但图14提供了其他工具的流行度, 并确认了SCA和SAST工具的领先流行度。

Snyk - Dependencies in the real world

Snyk - 现实中的依赖关系

When talking about direct and transitive vulnerabilities, the actual pervasiveness of transitive vulnerabilities is easy to overlook or dismiss. As observed earlier, nearly 40% of the vulnerabilities we detect originate in third-party code. Two examples of recent, high profile vulnerabilities, Log4Shell and Spring4Shell, give us an opportunity to compare the nature of direct vs. transitive dependencies in the real world.

当谈到直接和传递性漏洞时，我们容易忽视或忽略传递性漏洞的实际普遍性。正如先前观察到的，检测到的近40％的漏洞源于第三方代码。最近出现的两个备受关注的漏洞 “Log4Shell” 和 “Spring4Shell” 为我们提供了比较现实世界中直接依赖和传递性依赖性质的机会。

Last Christmas, Log4Shell was the bane of security teams and developers across the globe. The log4j-core project has been used extensively to enable logging in millions of projects. Because of this, nearly 52% of the vulnerabilities we detected were present because of a direct dependency on the log4j-core code base. (It’s important to note that we counted direct dependencies first, so a project with both direct and indirect dependencies would be counted as direct.)

去年圣诞节，Log4Shell 是全球安全团队和开发人员的噩梦。log4j-core 项目已被广泛使用，在数百万项目中启用日志记录功能。由于这个原因，我们发现的近52％的漏洞存在于直接依赖 log4j-core 代码库的项目中。（需要注意的是，我们首先计算直接依赖项，因此既有直接依赖项又有间接依赖项的项目将被视为直接依赖项。）

In contrast to Log4j, over 90% of the Spring Framework core was transitive, called by code one layer or more removed from the developer. The Spring Framework can be described as the ‘plumbing of enterprise applications’, which helps explain why it’s a transitive dependency so often. This is a very common example of how vulnerable code gets incorporated into projects, and why it’s important to track transitive vulnerabilities.

与 Log4j 相比，超过90％的Spring框架核心是传递性的，Spring框架由代码调用而距离开发人员一层或更多层。Spring 框架可以被描述为“企业应用程序的管道”，这有助于解释为什么它经常是一个传递性依赖项。这是一个非常常见的漏洞代码被纳入项目的例子，也是为什么跟踪传递性漏洞很重要的原因。

Prerequisites to using OSS

使用开源软件的前提条件

Using open source components can help to reduce cost, speed time to market, and free staff up to engage in more innovation and value- added activities. There is no “right way” to evaluate the security of OSS packages, but Figure 13 indicates that on average organizations use three of the approaches listed.

使用开源组件可以降低成本，加速产品进入市场的时间，以及释放员工从事更多的创新和增值活动。虽然评估开源软件包的安全性没有“正确的方法”，但是图 13 表明了组织平均使用列出的三种方法。

The most common approach used by 44% of organizations is to have developers examine source code. A review of source code can speak volumes about the quality of the code, which is highly correlated with its security.

最常见方法是让开发人员检查源代码，该方法被44%的组织机构所采用。对源代码的审查可以充分说明代码的质量，这与其安全性高度相关。

A second approach relied on by 40% of organizations is to assess the community that supports the project or component. An active community and an organized approach to contribution and maintainership are seen as positive signs for a project.

第二种方法是评估支持项目或组件的社区，该方法被40%的组织机构所依赖。一个活跃的社区和有组织的贡献和维护方法被视为项目的积极信号。

The third most popular strategy, observed at 36% of organizations, is using third-party tools to help developers find and vet components.

第三种最受欢迎的策略，在36% 的组织中观察到，是使用第三方工具来帮助开发人员查找和审核组件。

A variety of additional manual activities are used by organizations, including reviewing the frequency of releases/ commits (35%), analysis of registry/package manager information (33%), and reviewing usage statistics such as repository ratings or download statistics (30%). These help establish the viability and commitment of the community to the component.

组织使用各种额外的人工活动，包括查看发布/提交的频率（35%），分析注册表/包管理器信息（33%），以及查看使用情况统计信息，例如存储库评级或下载统计信息（30%）。这些有助于建立社区对该组件的可行性和承诺。

Figure 13: Reviewing the security of OSS packages
图 13：审查开源软件包的安全性

How do you check the security of the open source packages that you use? (select all that apply)
你如何检查你使用的开源软件包的安全性？（选择所有适用项）

Source: 2022 Open Source SupplyChainSecuritySurvey.
来源：2022 年开源供应链安全调查。

We use tools to examine its source code
我们使用工具检查其源代码

We check that the project has an active community
我们检查该项目是否有一个活跃的社区

We use a tool like Snyk Advisor, Libaries.io, or similar tools to serach for open source packages
我们使用像 Snyk Advisor、Libraries.io 或类似的工具搜索开源包

We look at the frequency of releases/ commits/ etc.
我们查看发布 / 提交等的频率

We use the information in the registry or package manager
我们使用注册表或包管理器中的信息

We look at repository ratings or package downloads statitics
我们查看存储库评级或软件包下载统计信息

We manaually review/ inspect its source code
我们手动检查其源代码

We check  that the project has a responsible disclosure policy (such as a SECURITY.md)
我们检查该项目是否有负责任的披露策略（例如 SECURITY.md）

We ask others if they believe the security of the project is adequate
我们询问其他人是否认为该项目的安全性足够

We don’t check it
我们不检查它

Don’t Know
不知道

Using multiple security testing tools is an OSS best practice

使用多个安全测试工具是开源软件的最佳实践

On average, organizations in the study used between two and three security testing tools. Using third-party tools can significantly improve your OSS security posture because of their scope, scalability, automation potential, and coverage across the SDLC. As budgets, resources, and time allows; using more tools can be advantageous since they all add value in different ways.

平均而言，研究中的组织使用了两到三种安全测试工具。使用第三方工具可以显著改善您的 OSS 安全状况，因为它们的范围、可扩展性、自动化潜力和覆盖整个 SDLC。在预算、资源和时间允许的情况下, 使用更多工具可能是有利的，因为它们都以不同的方式增加价值。

Figure 14 shows that preference is higher for SCA tools (47%) than for any other tool category. The ability of SCA tools to identify vulnerabilities and license compliance across an organization’s portfolio of components and dependencies, in a highly automated way, is immensely valuable.

图 14 显示，对 SCA 工具的偏好高于任何其他工具类别（47%）。SCA 工具在高度自动化的方式下，可以识别组织组件和依赖项组合中的漏洞和许可证合规性，这是极其有价值的。

Figure 14: Security tools in use when developing OSS

图 14：在开发 OSS 时使用的安全工具

What security tools do you regularly use when developing open source software? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

在开发开源软件时，您定期使用哪些安全工具？（选择所有适用项）您是否针对开源开发或使用制定了开源安全策略？

Software Composition Analysis (SCA) tools
软件组件分析工具（SCA）

Static Application Secuirty Testing (SAST) tools
静态应用程序安全性测试 (SAST) 工具

Infrastructure as Code (IaC) tools
基础设施即代码 (IaC) 工具

Web Applications Scanners
Web 应用程序扫描器

Security Test Cases in software quality testing
软件质量测试中的安全测试用例

Infrastructure as Code scanners
基础设施即代码扫描器

Fuzz Testing tools
模糊测试工具

Threat modeling tools
威胁建模工具

Cloud Secruity Posture Mgmt (CSPM)
云安全姿态管理（CSPM）

Other
其他

Don’t Know
不知道

Other than SCA tools, additional choices become complex based on the organization’s approach to DevOps and preferences regarding security testing. SAST tools (37%), IaC tools (36%), and web application scanners (32%) all effectively compete for developer and security team attention. Web application scanners and fuzz testing tools together make up the dynamic application security testing (DAST) tool domain. Realistically, the use of both SAST and DAST tools makes sense because both help organizations find vulnerabilities. However, IaC tools are invaluable in helping to script and automate CI/CD activities, eliminating many of the manual and ad hoc activities that consume time that could be better spent elsewhere.

除了 SCA 工具之外，根据组织的 DevOps 方法和安全测试偏好，其他选择会变得复杂。SAST 工具（37%）、IaC 工具（36%）和 Web 应用程序扫描程序（32%）都有效地争夺了开发人员和安全团队的注意力。Web 应用程序扫描程序和模糊测试工具共同构成了动态应用程序安全测试（DAST）工具域。实际上，同时使用 SAST 和 DAST 工具是有意义的，因为两者都可以帮助组织发现漏洞。但是，IaC 工具在帮助编写脚本和自动化 CI/CD 活动方面非常宝贵，消除了许多耗时的手动和临时活动，省下的时间可以更好地花在其他地方。

An honorable mention goes out to the remaining tools on the list. Some of these tools are relatively new, but each of them offers a unique value proposition that adds value to improving OSS security.

我们还要向剩下的工具表示敬意。这些工具中有些是相对较新的，但它们每一个都有独特的价值主张，为提升开源软件安全增添了价值。

Examining the tool use profiles of organizations with a security policy versus those without provides an overview of where organizations often start their OSS security journey, and what this journey looks like as it matures.

分析具有安全策略和没有安全策略的组织在使用工具方面的差异，可以提供有关组织开始和成熟过程中的开源软件安全旅程的概述。

The most important ways to improve OSS security

提升开源软件安全最重要的方法

The data in Figure 15 is likely the most important collection of key findings in this report. When asked which of the following activities are important to improving the security of OSS, organizations were permitted to give multiple responses.

图 15 中的数据可能是本报告中最重要的关键发现集合。当被问及以下哪些活动对提高开放源码软件的安全性很重要时，允许各组织作出多重回答。

The most important activity — confirmed by 59% of organizations — identified a desire to have vendors add increased intelligence to, and to be responsible for, security tooling. There are two ways to interpret what this means. The first is that end user organizations view the vendor community as a force multiplier, because more intelligent tools can ease the burden on developers or security professionals in exchange for licensing fees. Organizations and vendors both perceive this as a win-win scenario assuming competitive market dynamics. An alternative way to interpret this is that end-user organizations are struggling to understand how to address security concerns and welcome the opportunity to share/grant this responsibility to vendors and service providers who have more extensive expertise.

最重要的活动，得到59%的组织证实，确定了让供应商增加安全工具智能并负责安全工具的愿望。有两种方法可以解释这意味着什么。第一种解释是，最终用户组织将供应商社区视为力量倍增器，因为更智能的工具可以减轻开发人员或安全专业人员的负担，以换取许可费。假设市场动态竞争激烈，组织和供应商都认为这是一个双赢的局面。另一种解释方式是，最终用户组织正在努力了解如何解决安全问题，并乐于与具有更广泛专业知识的供应商和服务提供商共享 / 授权这种责任。

Another way to look at this is that end user organizations have scarce resources, and more intelligent tools are expected to provide higher value in a transparent way (meaning having no or inconsequential impact on developer productivity). This is the most seamless way to improve software security without material changes to process models.

另一种看待这个问题的方式是，终端用户组织资源有限，更加智能的工具预计以透明的方式提供更高的价值，意味着对开发人员生产率没有或者只有微不足道的影响。这是在不对过程模型进行重大更改的情况下提高软件安全性的最无缝方法。

The second most important activity is to source comprehensive best practices/certifications for secure software development (cited by 52% of organizations). The strong interest by end user organizations in best practices for secure software development is exciting to see. This suggests that these organizations are invested in understanding how to address OSS security. The good news is that there are already several trusted sources who can address this need:

There are a variety of sources to identify best practices/ certifications for evaluating projects themselves. This includes the OpenSSF Best Practices badge, the OpenSSF Scorecards project, the CNCF paper on best practices for supply chain security, and SLSA (https://slsa.dev)
This also suggests an interest in encouraging developers to learn best practices & acquire certifications. The good news is that these are available. For example, OpenSSF’s developing secure software (LFD121) provides both a training course and certification of completion for individuals who pass the final exam. This course is sponsored by the OpenSSF which is part of the Linux Foundation.

第二个最重要的活动是为安全软件开发提供全面的最佳实践/认证（52%的组织引用）。最终用户组织对安全软件开发最佳实践的浓厚兴趣令人兴奋。这表明这些组织在了解如何解决开放源码软件安全问题方面进行了投资。好消息是，已经有几个值得信赖的来源可以满足这一需求：

有多种来源可以确定评估项目本身的最佳实践/认证。这包括OpenSSF最佳实践徽章，OpenSSF记分卡项目，CNCF关于供应链安全最佳实践的文件和SLSA（https://slsa.dev）。
这也表明鼓励开发人员学习最佳实践和获得认证的兴趣。好消息是这些都可用。例如，OpenSSF 的安全软件开发（LFD121）提供培训课程和通过期末考试获得认证的个人证书。该课程由 OpenSSF 赞助，是 Linux 基金会的一部分。

Figure 15: Activities for improving the security of open source software

图 15：改善开源软件安全的活动

Which of the following activities are important to improving the security of the open source software supply chain? (select all that apply)

以下哪些活动对于改善开源软件供应链的安全性很重要？（选择所有适用项）


Added intelligence to existing software security tools (SAST, DAST, SCA, SBOMs, IaC scanners, CSPM)
增加软件安全工具的智能化（SAST，DAST，SCA，SBOM，IaC 扫描程序，CSPM）

Comprehens ive best practices/ certification for secure software development
全面的安全软件开发最佳实践 / 认证

More automation to eliminate pathways to compromise security and reduce developer fatigue
更多自动化以消除威胁安全的途径并减轻开发人员的负担

Security audits
安全审计

Increased incentives by employers to contribute to open source projects
雇主提供更多的激励鼓励员工参与开源项目

Peer review of source code
源代码的同行评审

Required use of MFA by developers and releasers
要求开发人员和发布者使用多因素认证

Vulnerability reporting system that is low-touch and low-latency
低成本、低延迟的漏洞报告系统

Identification of mission-critical software to be hardened against attack
识别需要加强防攻击的关键软件

Cryptographic signatures
使用加密签名

Use standardization to reduce the complexity and difficulty in addressing open source software security
标准化以减少处理开源软件安全性的复杂性和难度

Use of memory safe programming languages
使用内存安全编程语言

Verification through the use of reproducible builds
通过使用可重现构建来验证

Use of SBOMs
使用 SBOMs

Globally unique identification of specific software components/ releases
全球唯一标识特定软件组件 / 发布版本

Other
其他

Don't know or not sure
不知道或不确定

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

In third place for most popular activities around secure software development, we see a tie between increased automation to reduce attack surfaces and security audits, which were cited by 49% of organizations. The use of IaC tools can provide a reliable path to increased automation of CI CD activities. These tools have proven to be popular across organizations in this survey, and in the right hands, they can be extremely effective. Security audits are also a valuable way to gauge the current state of security for some or all of the organization’s applications. However, security audits — as measured through the eyes of maintainers who participated in the survey — were not valued nearly as highly. While security audits can be invaluable at comprehensively assessing an organization’s security risks, the organization must be positioned to act upon the findings of that audit — which seems a bridge too far for organizations without a security policy. However, note that there were only 72 maintainers participating in this survey, and 78% of them had not participated in an external security audit. It’s possible that security audits are so rare that few software developers have experienced them (and thus can only guess about their advantages).

最受欢迎的安全软件开发活动，增加自动化以减少攻击面和安全审计并列第三，这两项活动被 49% 的组织提到。使用基础架构即代码（IaC）工具可以提供可靠的路径来增加 CI CD 活动的自动化。

这些工具在本次调查中已被证明受到组织的欢迎，在正确的使用下可以非常有效。安全审计也是衡量组织某些或所有应用程序当前安全状态的有价值方式。但是，从参加调查的维护者的角度来衡量安全审计，它们的价值远不如前两项。虽然安全审计可以全面评估组织的安全风险，但组织必须有能力对审计结果进行行动 - 这对于没有安全策略的组织来说似乎过于困难。但请注意，本次调查只有 72 名维护者参加，其中 78％的人没有参加过外部安全审计。安全审计可能非常罕见，以至于很少有软件开发人员经历过它们（因此只能猜测它们的优势）。

Increased incentives by employers to encourage OSS contributions by employees were identified by 41% of organizations. While this is a fantastic idea and would tremendously help create a closed-loop environment for OSS, this point will be discussed in more detail in the next section of this paper.

41%的组织认为雇主为鼓励雇员贡献开放源码软件而采取的激励措施有所增加。虽然这是一个绝妙的主意，并且将极大地帮助创建开源软件的闭环环境，但本文的下一节将更详细地讨论这一点。

The IT industry must take a more active rol to improve OSS securit and sustainability

IT 行业必须承担更积极的角色，以改善开源软件的安全性和可持续性

Open source software has thrived as an alternative engine of innovation for organizations and developers alike. The pervasive use of OSS is testimony to the impact that it has had on the IT industry. However, OSS security and quality requires a full lifecycle commitment which creates additional investments in resources, time, and developers when compared to current practice. This section of the report introduces a variety of OSS security and sustainability challenges and solicits advice from organizations on how to address them.

开源软件作为组织和开发人员等的替代创新引擎而蓬勃发展。开源软件的广泛使用证明了它对 IT 行业的影响。然而，开源软件的安全性和质量需要完整生命周期的承诺，与当前实践相比，这会导致在资源、时间和开发人员方面产生额外的投资。报告的这一部分介绍了各种开源软件安全和可持续性挑战，并征求组织关于如何解决这些挑战的建议。

Improving the security of oss development

改进开源软件开发的安全性

Organizations and developers are no strangers to the importance of best practices for secure software development. The significance of best practices for OSS development was initially voiced in Figure 15 as the 2nd most important activity for improving OSS security. Best practices have been voiced again by 73% of organizations in Figure 16 as the leading way IT industry organizations can improve the security of OSS development. IT industry organizations (such as the Linux Foundation) have taken this responsibility seriously and are delivering best practices content across a variety of channels.

通过提供最佳实践来改善开源软件开发的安全性，这再次表明了最佳实践的重要性。IT 行业组织（例如 Linux 基金会）已经认真对待这一责任，并通过多种渠道提供最佳实践内容。组织和开发人员对安全软件开发最佳实践的重要性并不陌生。在图 15 中，开源软件开发最佳实践的重要性最初被表述为提高开源软件安全性的第二重要活动。图 16 中，73% 的组织再次表示最佳实践是 IT 行业组织提高开源软件开发安全性的主要方式。 IT 行业组织（如 Linux 基金会）认真对待这一责任，并通过各种渠道提供最佳实践内容。

The 2nd leading improvement, identified by 61% of organizations, is providing tools for analyzing and remediating security vulnerabilities in OSS components. This need is being addressed as part of the OpenSSF’s open source Software Security Mobilization Plan. This plan was released at the Open Source Software Security Summit II in Washington DC on May 12-13, 2022. This plan is available at https://openssf.org/oss-security-mobilization-plan/.

第二个主要改进是为分析和修复开源软件组件的安全漏洞提供工具，61% 的组织认可这一点。这个需求正在 OpenSSF 的开源软件安全动员计划中得到解决。该计划于 2022 年 5 月 12 日至 13日在华盛顿特区举行的 “开源软件安全峰会 II” 上发布。该计划可在 https://openssf.org/oss-security-mobilization-plan/ 获取。

Figure 16: How organizations can improve the security of OSS development

图 16：IT 行业组织可以如何提高开源软件开发的安全性

What are some of the ways that IT Industry Organizations could improve the security of developing open source software? (select all that apply)

以下哪些方法是 IT 行业组织可以提高开源软件开发安全性的方法？（选择所有适用项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Define best practices for secure software development
定义安全软件开发的最佳实践

Provide tools for analyzing and remediating security vulnerabilities of the top 500 open source components
提供分析和修复前 500 个开源组件的安全漏洞的工具

Provide more training in secure and memory safe programming for the broader open source software community
为更广泛的开源软件社区提供更多的安全和内存安全编程培训

Provide funds to support maintainers for analyzing and remediating security vulnerabilities of the top 500 open source code components
为支持分析和修复前 500 个开源代码组件的维护者提供资金

More formal processes for evaluating the security of incoming software
更正式的流程来评估入站软件的安全性

Provide funds to more nascent projects that show significant potential
为显示出重大潜力的新兴项目提供资金支持

Other (please specify)
其他（请具体说明）

Don't know or not sure
不知道或不确定

The 3rd ranked improvement identified in Figure 16 by 53% of organizations is to provide more training in secure and memory safe programming. Sadly, many software developers have not been trained on how to develop secure software. As noted earlier, there are some courses available today, including one from the OpenSSF, and there is interest in expanding these courses further. Virtually all languages are memory safe by default. C, C++, and Assembly are the only remaining languages in common use that are not memory safe by default. Training courses and books on alternative programming languages are readily available.

在图 16 中被 53% 的组织认可的改进方法是提供更多安全和内存安全编程方面的培训，该方法是排名第三的改进建议。不幸的是，许多软件开发人员并没有接受过如何开发安全软件的培训。正如前面提到的，今天已经有一些课程可用，包括来自 OpenSSF 的课程，并且有兴趣进一步扩展这些课程。几乎所有语言默认情况下都是内存安全的。默认情况下，几乎所有语言都是内存安全的。C、C++ 和汇编是常用的唯一默认不内存安全的语言。关于替代编程语言的培训课程和书籍随时可用。

Improving open source software resourcing

改进开源软件资源分配

OSS resourcing is a growing challenge because of the need to improve the security and quality of OSS components. The Open Source Software Security Mobilization Plan, put forward by the OpenSSF, aims to address the following:

Secure OSS production. Focus on preventing security defects and vulnerabilities in code and open source packages in the färst place.
Improving vulnerability discovery and remediation. Improving the process for finding defects and fixing them.
Shorten ecosystem patching response time. Shorten the response time for distributing and implementing fixes.

开放源码软件的资源资源是一个日益严峻的挑战，因为需要提高开放源码软件组件的安全性和质量。OpenSSF提出的开源软件安全动员计划旨在解决以下问题：

安全的的开源软件生产。专注于防止代码和开源包中的安全缺陷和漏洞。
改进漏洞发现和修复。改进发现缺陷并修复缺陷的过程。
缩短生态系统补丁响应时间。缩短分发和实施修补程序的响应时间。

This plan is estimated to cost in the vicinity of $70 million to $110 million per year and is designed to provide a blueprint and services including education, training, tools, and processes to secure the top OSS projects. While this plan will provide a useful model for OSS projects in general, there are millions of ongoihg OSS projects. How will funding for many of these projects be accomplished?

这个计划的预计成本大约为每年 7,000 万至 1.1 亿美元，旨在提供一个蓝图和服务，包括教育、培训、工具和流程，以保障顶级开源项目的安全。虽然这个计划将为一般的开源项目提供有用的模型，但仍有数百万正在进行的开源项目需要资金支持。那么这些项目的资金来源将是如何解决的呢？

Figure 17 addresses this dilemma. The leading response shared by 63% of organizations suggests that employers should provide or increase an incentive to contributors of meaningful OSS projects. If end-user organizations elected to "give back" to the oss communities they depend on, it would attract more contributors and improve the security and quality of those OSS components.

图 17 解决了这个困境。63% 的组织表示，最重要的反应是雇主应该提供或增加对有意义的开源软件项目贡献者的激励。如果最终用户组织选择 “回馈” 他们依赖的开源软件社区，它将吸引更多的贡献者，提高这些开源软件组件的安全性和质量。

Figure 17: The most important ways to improve OSS resourcing
图 17：提高开源软件资源的最重要方式

What are the three most important ways that open source project resourcing can be improved? (select all that apply)
什么是改进开源项目资源的三个最重要的方法？（选择所有适用的选项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Employers should provide or increase an incentive to contributors for meaningful contribution to open source projects including dependencies
雇主应该提供或增加对做出有意义的开源项目贡献者的奖励，包括其依赖项

Industry adoption of standards for interoperability across tools to make it less painful for developers to build pipelines and workflows
行业应采用跨工具的互操作性标准，以减少开发人员构建管道和工作流程的痛苦

Cloud service providers should sponsor free or deeply discounted tools and services to open source projects
云服务提供商应为开源项目赞助免费或深度折扣的工具和服务

Employers should give contributors access to security analysis tools they're used to using at work
雇主应给予贡献者使用其在工作中熟悉的安全分析工具的权限

Employers should contribute to a Linux Foundation fund that redirects 100% of this fund to open source projects of merit
雇主应向 Linux 基金会基金捐赠资金，将该基金的 100％重新分配给有价值的开源项目

Other
其他

Don't know or not sure
不确定或不确定

Industry adoption of standards for interoperability across tools and discounted resources provided by CSPs (Cloud Service Providers) to OSS projects resonate across 51% of organizations in this study. Interoperability concerns were frustrating and are a characteristic of immature markets. The fragmented nature of today's software security markets suggests that consolidation will occur and help address this problem although the timeframe is unknown.

该研究显示，51％的组织对行业采用工具间互操作性标准以及CSP（云服务提供商）提供的折扣资源产生共鸣。互操作性问题令人沮丧，是不成熟市场的一个特征。当今软件安全市场的分散性表明，尽管时间框架不确定，但整合将发生并有助于解决这个问题。

The concept of cloud service providers providing support for secure OSS development is intriguing. Having access to a portfolio of tools adept at secure software development at deeply discounted prices would be a win for developers. It could also be a win for CSPs as an on-ramp to more conventionally priced runtime services. However, whether this idea has been vetted with CSPs is unknown as is their overall receptivity to the idea.

云服务提供商为安全的开源软件开发提供支持的概念令人感兴趣。以深度折扣价格获得一系列适用于安全软件开发的工具组合对于开发者来说是一种胜利。对于云服务提供商而言，它也可能是一个通向更常规价格的运行时服务的入口。然而，该想法是否已经经过了云服务提供商的审查，以及云服务提供商对该想法的整体接受程度尚不清楚。

44% of developers at organizations also embrace having their employer establish a sandbox for developing OSS projects using the same tools they are already familiar with. This is also an intriguing idea and would qualify as yet another perk provided by an employer to their employees who contribute to material OSS projects.

44% 的组织开发人员赞同让雇主建立一个沙箱，使用他们已经熟悉的相同工具进行开源软件项目的开发。这也是一个有趣的想法，可以作为雇主提供给为重要的OSS项目做出贡献的员工的另一个福利。

Although the ideas presented as responses in Figure 17 are speculative, they all reflect the realization that secure OSS development will require additional investment which needs to be provided by the community that benefits from the value derived from OSS.

尽管图 17 中呈现的想法都是推测性的，但它们都反映了这样一个认识：安全的开源软件开发需要额外的投资，而这些投资需要由受益于开放源码软件价值的社区提供。

Snyk - Broken Containers

Snyk - 损坏的容器

Vulnerability management is complicated enough to start with, but the advent of containers, virtual machine images, IaC, and microservices complicate it even further. While many organizations are still improving how to handle vulnerabilities in their own code, and starting to examine direct and transitive dependencies in depth, fixing the vulnerabilities introduced by containers is still a struggle. Container images (among other constructs) are often "black boxes" that organizations do not examine further.

漏洞管理本来就很复杂，但容器、虚拟机镜像、IaC 和微服务的出现使得漏洞管理更加复杂化。虽然许多组织仍在改进如何处理其自己的代码中的漏洞，并开始深入研究直接和传递依赖项，但修复由容器引入的漏洞仍然很困难。容器镜像（以及其他构造）通常是组织不进一步检查的“黑匣子”。

Returning to our examples of recent vulnerabilities, as of the time of this writing, only 8% of container projects with Spring Framework dependencies have fully remediated the Spring4Shell vulnerability. In contrast, Log4Shell has been resolved in nearly 25% of all containers.

回到我们最近漏洞的示例，截至本文撰写时，只有 8% 的容器项目使用 Spring Framework 依赖项已经完全解决了 Spring4Shell 漏洞。相比之下，几乎 25% 的容器已经解决了 Log4Shell 漏洞。

Because containers can be ephemeral, the act of creating and destroying containers provides an opportunity for implementing updates that could occur rapidly and significantly improve existing vulnerability dynamics. Changing the code in one container configuration could potentially result in hundreds of updated containers. The flip side is that one container configuration forgotten or missed can also easily result in the same number continuing to be vulnerable. This later challenge is one readily resolved through the use of SBOMs.

由于容器可以是短暂的，创建和销毁容器的过程为实施更新提供了机会，这些更新可能会快速地显著改善现有的漏洞动态。在一个容器配置中更改代码可能会导致数百个更新后的容器。另一方面，如果一个容器配置被遗忘或错过，同样数量的容器也很容易继续存在漏洞。后面的这种挑战可以通过使用SBOMs轻松解决。

Improving OSs sustainability

提高开源软件的可持续性

OSS sustainability is an important topic for anyone who depends on OSS. For small OSS projects maintained by a single person, challenges exist. Sustainability requires continuity over time. To achieve this requires the successful ability to transfer maintainer responsibilities to additional maintainers.

对于任何依赖于开源软件的人来说，开源软件的可持续性是一个重要的话题。对于由单个人维护的小型开源软件项目，存在一些挑战。可持续性需要长时间的连续性。要实现这一点，需要成功地将维护者的职责转移给其他维护者。

Figure 18 helps prioritize key activities to help address OSS sustainability. Across organizations, 64% report that maintainers should plan for their own retirement by bringing new maintainers into the project. This is the preferred path forward but requires attention to nontechnical activities focused on process and communication. Adding a second maintainer to a project and transferring responsibility from the original maintainer are likely to be some of the most difficult activities a project must overcome.

图 18 有助于优先考虑能帮助解决开源软件的可持续性的关键活动。在各个组织中，64% 报告称维护者应该通过引入新的维护者来规划自己的退休计划。这是未来的首选方案，但需要关注流程和沟通等非技术活动。向项目添加第二个维护者并从原始维护者转移责任可能是项目必须克服的一些最困难的活动之一。

Recognizing the challenges of transferring project responsibility, 58% of organizations believe that if a project reaches its end of life the retiring maintainer should clearly identify on the repo that the software is no longer being maintained.

认识到转移项目责任的挑战，58%的组织认为，如果项目到达其生命周期的终点，退休维护者应该在代码库中清楚地标识出软件不再得到维护。

An alternative path for transferring maintainership responsibility is to find a foundation or IT industry organization that will create a new home for the project. 55% of organizations endorsed this path forward although it may prove to be nearly as complex as independently finding a new maintainer.

转移维护责任的另一种选择是寻找一个基金会或IT行业组织，为项目创建一个新的家。55% 的组织支持这种前进的方式，尽管它可能证明几乎与独立寻找新的维护者一样复杂。

Figure 18: Improving OSS sustainability How should open source software sustainability be addressed if the maintainer(s) on a project decide to retire? (select all that apply)

图 18：提高 OSS 的可持续性如果项目的维护者决定退休，应如何解决开源软件的可持续性问题？（选择所有适用项）

Source: 2022 Open Source Supply Chain Security Survey.
来源：2022 年开源供应链安全调查。

Encourage retiring maintainers to request and add new maintainers to the project
鼓励退役维护者请求并添加新的项目维护者

Encourage retiring maintainers to clearly identify on the repo that the software is no longer being maintained
鼓励退役维护者明确在存储库上标识软件不再维护

Look for ways to transition the project to an independent foundation
寻找将项目转移到独立基金会的方式

Look for ways to transition the project to a large scale user of the project
寻找将项目转移到大规模项目用户的方式

Look for ways to raise funding to encourage the current maintainer to continue
寻找筹集资金的方法，以鼓励当前维护者继续维护

Other
其他

Don't know or not sure
不确定或不清楚

Conclusions and recommendations

结论和建议

Too many organizations are not prepared to address OSS security needs

太多组织没有准备好应对开源软件安全需求

Across the 500+ organizations participating in this OpenSSF survey, at least 34% did not have an OSS security policy in place (Figure 1). The percentage of organizations without a security policy is likely to be around 40% after prorating those respondents who didn't know the status of an OSS security policy for their employer. OSS use is pervasive across end-user organizations and IT vendors/service providers (who somewhat evenly comprise our sample) and the 60/40 yes/no split on having an OSS security policy persists across virtually all 22 industries represented in our sample. This indicates that not having an OSS security policy is not specific to certain industries or organization types but instead is widely found across business environments.

在参与本次 OpenSSF 调查的 500 多个组织中，至少有 34％没有制定开源软件（OSS）安全策略（图 1）。在按比例计算那些不知道其雇主的 OSS 安全策略状况的受访者后，没有安全策略的组织比例可能达到 40％左右。OSS 在终端用户组织和 IT 供应商 / 服务提供商中普及（它们在样本中几乎均衡），而在我们样本中代表的几乎所有 22 个行业中，60/40 的有 / 无 OSS 安全策略分布均存在。这表明，没有 OSS 安全策略不是特定于某些行业或组织类型，而是广泛存在于商业环境中。

Small organizations must prioritize developing an OSS security

小型组织必须优先考虑制定开源软件安全政策

In the wake of numerous high-profile attacks across the software supply chain over the last several years, this finding is disappointing. Every organization needs to have a CISO and OSPO (open source Program Office) or a person or persons vested with key CIS and OSPO responsibilities. We recognize that small organizations with less than 500 people were significantly more likely to not have an OSS security policy (Figure 2). Small organizations, therefore, need to prioritize and limit their CISO and OSPO agenda so it can be achievable with a partial FT. Once key CISO and OSPO capabilities are resident in the organization an OSS security policy will follow.

在过去几年中，软件供应链中发生了许多备受瞩目的攻击，这一发现令人失望。每个组织都需要有一位 CISO（首席信息安全官）和 OSPO（开源项目办公室）或一位或多位负责关键 CIS 和 OSPO 职责的人员。我们认识到，少于 500 人的小型组织更有可能没有开源软件安全策略（图 2）。因此，小型组织需要优先考虑并限制其 CISO 和 OSPO 议程，以使其成为部分全职任务。一旦关键的 CISO 和 OSPO 能力在组织中得到了落实，OSS 安全策略就会随之而来。

Using additional security tools is a leading way to improve osS security

使用更多的安全工具是提高开源软件安全性的一种主要方式

There are at least 10 tool categories that have a focus on addressing OSS security. Organizations on average use 2.8 security tool categories among the survey options. SCA and SAST tools are the leading tools used to address OSS security among those options (Figure 14). The use of IaC tools (which indirectly address security) and web application scanners (part of the DAST category) round out the portfolio that many organizations use.

至少有 10 个工具类别专注于解决开源软件安全问题。在调查选项中，组织平均使用 2.8 个安全工具类别。软件组成分析（SCA）和静态应用程序安全测试（SAST）工具是解决开源软件安全问题中最常用的工具（见图 14）。使用 IaC 工具（间接解决安全问题）和 Web 应用程序扫描器（动态应用程序安全测试 DAST 类别的一部分）是许多组织使用的其他工具。

The security tools market has numerous tool categories because the overall domain extends from source code management through build, package, delivery, and deployment. This is basically the entire software lifecycle. Software security must be managed across each step and accomplishing all of this with just two or three tool categories is not feasible. Therefore, organizations should take a closer look at adjacent and complementary security tools markets and determine where incremental tools can add the most value.

安全工具市场拥有众多的工具类别，因为整个领域从源代码管理到构建、打包、交付和部署都有涉及，基本上涵盖了整个软件生命周期。必须在每个步骤上管理软件安全性，但仅使用两到三个工具类别来完成所有这些工作是不可行的。因此，组织应该仔细研究相邻和互补的安全工具市场，并确定增量工具可以在哪些方面增加最大价值。

Figure 14 also shows that organizations with an OSS security policy have a higher frequency of security tool use than those organizations without an OSS security policy. This same dynamic is in place based on organizational size where large organizations have a higher frequency of security tool use than small organizations. Security tool use is therefore one of the most obvious and powerful ways to improve your OSS security posture.

图 14 还显示，具有开源软件安全策略的组织比没有开源软件安全策略的组织更频繁地使用安全工具。同样，大型组织比小型组织使用安全工具的频率更高。因此，使用安全工具是改善开源软件安全状况的最明显和最强大的方法之一。

Collaborate with vendors to create more intelligent security tools

与供应商合作创建更智能的安全工具

Adding greater intelligence to existing software security tools is viewed by organizations as one of the most important ways to improve OSS security across the supply chain (Figure 15). While tool vendors may see this more as business as usual, tool users see this as a critical requirement to empower existing resources. Because most end-user organizations are resource constrained in IT, a critical objective is to find ways that existing developers can be more productive without adding to their workload. Increased tool intelligence and automation are examples of how to improve software security in a way nearly transparent to developers.

对于组织来说，将现有软件安全工具加强智能化是提高整个供应链中的开源软件（OSS）安全性的最重要途径之一（图 15）。虽然工具供应商可能认为这是日常工作，但工具用户认为这是赋予现有资源的关键要求。由于大多数终端用户组织在 IT 方面受到资源限制，因此一个关键目标是找到在不增加工作量的情况下提高现有开发人员工作效率的方法。增强工具的智能化和自动化就是如何在几乎不影响开发人员的情况下提高软件安全性的例子。

Implementing best practices for secure software development is the other leading way to improve OSS security

实施安全软件开发的最佳实践是改善开源软件安全的另一种主要途径

Understanding best practices for secure software development is identified repeatedly as the leading or a leading way to improve the security of the open source software supply chain (Figures 15 and 16). A primary reason why there is so much interest in best practices is that developing secure software encompasses the entire breadth of the software lifecycle. At each waypoint, from source code management, build services, and packaging to software delivery and deployment there are numerous best practices that need to be followed. This includes literally hundreds of best practices. The Linux Foundation has developed an outstanding free course and certification on developing secure software (LFD121) which can be found on OpenSSF.org.

理解安全软件开发的最佳实践是提高开源软件供应链安全的主要或领先方法之一，这在图 15 和 16 中被反复提到。人们对最佳实践如此感兴趣的一个主要原因是，开发安全软件涵盖了软件生命周期的整个广度。在每个航点，从源代码管理、构建服务和打包到软件交付和部署，都需要遵循许多最佳实践。这包括数百种最佳实践。Linux基金会开发了一个关于开发安全软件（LFD121）的优秀免费课程和认证，可以在 OpenSSF.org 上找到。

Use automation to reduce your attack surface

使用自动化减少攻击面

Infrastructure as Code (IaC) tools provide a way to script manual activities so that they can be automated (Figure 15). Reducing or eliminating manual command line-driven CI/CD activities provides fewer ways for developers to skirt policy, bend rules, make mistakes, and expose CI/CD activities to external threats. Use of IaC tools and lad scanners provides organizations with a way to streamline and automate CI/CD activities while simultaneously eliminating some threat vectors, While there will always be use cases for manual intervention by developers, minimizing the need for this is a best practice.

基础设施即代码（IaC）工具提供了一种脚本手动活动的方式，使它们可以自动化（图 15）。减少或消除手动命令行驱动的 CI/CD 活动为开发人员提供了更少的方法来绕过策略、改变规则、犯错误以及将 CI/CD 活动暴露给外部威胁。使用 IaC 工具和漏洞扫描工具为组织提供了一种简化和自动化 CI/CD 活动的方式，同时消除了某些威胁向量。虽然开发人员总是会有手动干预的用例，但最小化对此的需求是最佳实践。

Consumers of open source software should give back to the Communities that support them

开源软件的消费者应该回馈支持他们的社区

The introduction to this paper mentioned that open source software is at a crossroads. Those open source projects that experience significant growth must evolve from their modest and somewhat informal origin to address a more demanding and security conscious community of users. This transition does not come easily because it requires increased resources, time, processes, and security. The use of open source software has often been a one-way street where users see significant benefit with minimal cost or investment. In order for larger open source projects to meet user expectations it will be important for organizations to give back and close the loop to improve open source software sustainability. Employers need to provide additional incentives to employees who have material maintainer or core contributor open source roles or responsibilities. This would also serve to encourage a higher level of participation by developers in open source projects to ensure the flow of new talent.

本文的介绍提到，开源软件正处于十字路口。那些经历了显著增长的开源项目必须从其谦逊且有些非正式的起源中发展出来，以应对更苛刻、更注重安全的用户社区。这个转变并不容易，因为它需要增加资源、时间、流程和安全方面的投入。使用开源软件通常是单向的，用户可以在最小的成本或投资下获得显著的利益。为了满足用户的期望，较大的开源项目需要回馈和关闭循环，以提高开源软件的可持续性。雇主需要为那些有实质性维护者或核心贡献者开源角色或责任的员工提供额外的激励。这也将有助于鼓励开发人员更高级别地参与开源项目，以确保新人才的流动。

Methodology

方法

The objective of this research was to understand the following:

The current state of open source software security
Security practices across the open source software supply chain
Secure development practices
How the security and sustainability of open source software can be improved

本研究的目的是了解以下内容：

开源软件安全的当前状态
开源软件供应链中的安全实践
安全开发实践
如何改善开源软件的安全性和可持续性

This research project was initiated in 2022 01 at the request of the OpenSSF. The primary research vehicle would be a survey of OSS developers, maintainers, core contributors, and security professionals. However, the research was preceded by interviews with fifteen OSS maintainers and security subject matter experts. These qualitative interviews were performed to ensure that the survey included key security topics important to the OSS community.

该研究项目应 OpenSSF 的要求于 2022 年 1 月启动。主要的研究工具将是对开源软件开发人员，维护者，核心贡献者和安全专业人员的调查。然而，在研究之前，对十五名开放源码软件维护者和安全主题专家进行了访谈。进行这些定性访谈是为了确保调查包括对开放源码软件社区很重要的关键安全主题。

Interviews occurred in March 2022 and the survey was fielded in April 2022. Data was analyzed and this report was drafted as well as peer reviewed in May 2022.

访谈在 2022 年 3 月进行，调查在 2022 年 4 月进行。于2022 年 5 月进行了数据分析，起草了本报告并进行了同行评审。

All Figures in this survey include results that are rounded to the nearest whole integer percent value. Therefore, totals for segmentation data may not always add to 100%.

本调查中的所有图表结果均按最接近的整数百分比值四舍五入。因此，分段数据的总和可能不总是 100%。

This was a long survey with an average time to complete of 20+ minutes. The completion rate for this survey was under 50%. This explains why there is some variation in the sample size for the above segmentation variables.

本调查为长篇问卷，平均完成时间超过 20 分钟。本次调查的完成率不足 50%。这就解释了上述分段变量样本大小存在一定变异性的原因。

Compretensstive screening enteria were to ensure respondents wouildi have a thigh probability of being able to answer all survey questions. Screening criteria included involvement im open source software, experience in the development or use of open source software, employed or looking for employment, and respondents who self-identify as a real person.

为确保受访者有可能回答所有调查问题，采用了综合筛选标准。筛选标准包括参与开源软件、开源软件的开发或使用经验、在职或寻找工作以及自我确认为真实人士的受访者。

The qualitative dimension of this project included in-depth interviews with selected individuals across industries and in federal cybersecurity policy development or involvement with maintaining open source software.

该项目的定性维度包括对各行各业的选定人士的深入访谈，涵盖了联邦网络安全政策的制定者或参与维护开源软件维护的个人。

About the Authors

关于作者

Stephen Hendrick

斯蒂芬·亨德里克

Stephen Hendrick is Vice President of research at the Linux Foundation where he is the principal investigator on a variety of research projects core to the Linux Foundation's understanding of how open source software is an engine of innovation for producers and consumers of information technology. Steve specializes in primary research techniques developed over 30 years as a software industry analyst. Steve is a subject matter expert in application development and deployment topics including DevOps, application management, and decision analytics. Steve brings experience in a variety of quantitative and qualitative research techniques that enable deep insight into market dynamics and has pioneered research across many application development and deployment domains. Steve has authored over 1,000 publications and provided market guidance through syndicated research and custom consulting to the world's leading software vendors and high-profile startups.

斯蒂芬·亨德里克是 Linux 基金会的研究副总裁，他是许多研究项目的首席调查员，这些项目对 Linux 基金会了解开源软件如何成为信息技术生产者和消费者创新引擎至关重要。亨德里克先生专注于基于 30 多年软件行业分析师开发的主要研究技术。他是应用开发和部署主题的领域专家，包括 DevOps、应用程序管理和决策分析。亨德里克先生拥有多种定量和定性研究技术的经验，能够深入洞察市场动态，并在许多应用程序开发和部署领域开创了研究。亨德里克先生已经撰写了超过 1000 篇出版物，并通过综合研究和定制咨询向世界领先的软件供应商和高知名度的初创企业提供市场指导。

Martin Mckeay

马丁·麦基

Martin Mckeay is Snyk's Senior Editorial Research Manager, where he works with teams across the company to build reports that increase the knowledge base of security professionals and developers. With over twenty years as a security professional, Martin started his career in help desk operations, continuously building to more complex and diverse roles over the years. Over the last seven years, Martin has developed the skills to turn data into intelligence and translate 'geek speak' into language understandable by mere mortals.

马丁·麦基是 Snyk 的高级编辑研究经理，他与公司各个团队合作，制作报告，以增加安全专业人员和开发人员的知识库。马丁在安全专业方面已经有超过 20 年的经验，他的职业生涯始于帮助台运营，多年来不断发展到更复杂和多样化的角色。在过去的七年中，马丁已经开发了将数据转化为情报的技能，并将 “极客语言” 翻译成普通人可以理解的语言。

Acknowledgements

致谢

This document was authored with the support and collaboration of the following individuals and organizations: Stephen Augustus (Cisco), Brian Behlendorf (Linux Foundation), Hilary Carter (Linux Foundation), Randall Degges (Snyk), Brian Demers, Michael Dolan (Linux Foundation), Kim Lewandowski (Chainguard), Oleg Nenashev (Dynatrace), Mike Milinkovich (Eclipse Foundation), Megan Moore (Synk), Nick O'Leary (FlowForge), Christina Oliviero (Linux Foundation), Ashwin Ramaswami (Plaintext Group), Clark Roundy (Eclipse Foundation), Jed Salazar (Chainguard), Melissa Schmidt (Linux Foundation), Robert Scholte (Apache), Micah Silverman (Snyk), Daniel Stenberg (WolfSSL), Kate Stewart (Linux Foundation), Liran Tal (Synk), Adolfo Garcia Veytia (Chainguard), Derek Weeks (Linux Foundation), David A. Wheeler (Linux Foundation), Sarah Wills (Snyk).

本文档得到以下个人和组织的支持和合作：Stephen Augustus（思科）、Brian Behlendorf（Linux 基金会）、Hilary Carter（Linux 基金会）、Randall Degges（Snyk）、Brian Demers、Michael Dolan（Linux 基金会）、Kim Lewandowski（Chainguard）、Oleg Nenashev（Dynatrace）、Mike Milinkovich（Eclipse 基金会）、Megan Moore（Synk）、Nick O'Leary（FlowForge）、Christina Oliviero（Linux 基金会）、Ashwin Ramaswami（Plaintext Group）、Clark Roundy（Eclipse 基金会）、Jed Salazar（Chainguard）、Melissa Schmidt（Linux 基金会）、Robert Scholte（Apache）、Micah Silverman（Snyk）、Daniel Stenberg（WolfSSL）、Kate Stewart（Linux 基金会）、Liran Tal（Synk）、Adolfo Garcia Veytia（Chainguard）、Derek Weeks（Linux 基金会）、David A. Wheeler（Linux 基金会）和 Sarah Wills（Snyk）。

Disclaimer

免责声明

This report is provided "as is." The Linux Foundation and its authors, contributors, and sponsors expressly disclaim any warranties (express, Implied, or otherwise), including implied warranties of merchantability, noninfringement, fitness for a particular purpose, or title, related to this report. In no event will the Linux Foundation and its authors, contributors, and sponsors be liable to any other party for lost profits or any form of indirect, special, incidental, or consequential damages of any character from any causes of action of any kind with respect to this report, whether based on breach of contract, tort (including negligence), or otherwise, and whether they have been advised of the possibility of such damage. Sponsorship of the creation of this report does not constitute an endorsement of its findings by any of its sponsors.

本报告按“原样”提供。Linux 基金会及其作者、贡献者和赞助商明确声明不提供任何形式的保证，包括但不限于对本报告的适销性、非侵权性、特定用途适用性或标题的默示保证。在任何情况下，Linux 基金会及其作者、贡献者和赞助商均不对任何其他方因与本报告有关的任何形式的间接、特殊、偶然或后果性损害负责，无论是基于合同违约、侵权（包括疏忽）还是其他原因，并且无论他们是否已被告知可能出现此类损害。赞助本报告的创建不构成任何赞助商对其调查结果的认可。

Back Cover


Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

成立于 2021 年的 Linux 基金会研究院探究开源合作不断扩大的规模，提供对新兴技术趋势、最佳实践和开源项目的全球影响的洞察。通过利用项目数据库和网络，并致力于量化和定性方法的最佳实践，Linux 基金会研究院正在创建开源洞见的去处，以造福全球组织。

Copyright 2022 The Linux Foundation
This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.
版权所有 2022 Linux 基金会
本报告受到 知识共享 署名-禁止演绎 4.0 国际公共许可证的许可。

To reference this work, please cite as follows: Stephen Hendrick and Martin Mckeay, “Addressing Cybersecurity Challenges in open source Software,” foreword by Brian Behlendorf, Linux Foundation and Snyk, June 2022

请通过以下格式以引用本文：
斯蒂芬·亨德里克和马丁·麦基，“应对开源软件中的网络安全挑战”，前言由 布莱恩·贝伦多夫 所著，Linux 基金会和 Snyk，2022 年 6 月

Snyk is a developer-first security company that helps software-driven businesses develop fast and build securely. Snyk provides a platform to secure all of the critical components of today’s cloud native application development. Snyk is securing the industry leaders such as Google, Salesforce, Asos, BBC, and Asurion. For more information or to get started with Snyk for free, visit https://snyk.io.

Snyk 是一家以开发人员为先的安全公司，帮助以软件为驱动的企业快速开发和安全构建。Snyk 提供一个平台来保护当今云原生应用程序开发的所有关键组件。Snyk 正在保护行业领袖，如 Google，Salesforce，Asos，BBC 和 Asurion。有关更多信息或免费开始使用 Snyk，请访问 https://snyk.io。

开源世界的导师关系 —— 探索导师计划的内涵、经济和职业价值

2023年6月30日 · 阅读需 125 分钟

Front Cover

Mentorship in Open Source

Exploring the Intrinsic, Economic, and Career Value of Mentorship Programs

开源世界的导师关系

探索导师计划的内涵、经济和职业价值

January 2023

2023 年 1 月

Jason Perlow, Editorial Director,

The Linux Foundation

Jason Perlow，编辑部主任，

Linux 基金会

Foreword by Julia Lawall, Senior Scientist, French National Research Institute for Digital Science and Technology (Inria-Paris)

前言作者 Julia Lawall

法国国家数字科学技术研究所（Inria-Paris）高级科学家

In partnership with 合作作者

Contents 目录

Foreword..........................................................................................3
Infographic: LFX Mentorship program...............................................................4
About the LFX Mentorship program study............................................................5
Introduction: The problem that mentorship aims to solve ..........................................6
The roots of mentorship programs in academia......................................................8
The history of mentorships in open source and the technology industry.............................9
The genesis of mentorship at the LF...............................................................9
Mentorships and their impact on succession and diversity within open source.......................11
  Improving diversity.............................................................................11
  A learning experience for mentees (and mentors).................................................12
  Confidence building.............................................................................13
  Community building through mentorship...........................................................15
Mentorship program challenges ....................................................................16
Career benefits of mentorship programs ...........................................................18
Conclusions ......................................................................................22
  Actionable insights ............................................................................22
Final thoughts....................................................................................23
Methodology ......................................................................................24
Demographics......................................................................................24
About the author..................................................................................25
Acknowledgments...................................................................................25

前言............................................................................3
信息图：LFX 导师计划..............................................................4
关于 LFX 导师计划的研究...........................................................5
概述：导师计划希望解决的问题 .......................................................6
导师计划的学术依据................................................................8
开源界与技术界的导师关系历史........................................................9
LF 导师关系的起源.................................................................9
导师关系及其对开源演进和多样性的影响.................................................11
  改善多样性.....................................................................11
  学员（及导师）的学习经历.........................................................12
  建立信心......................................................................13
  通过导师关系建立社区............................................................15
导师计划的挑战 ..................................................................16
导师计划的职业价值 ...............................................................18
结论 ..........................................................................22
  可操作的见解 ....................................................................22
最后的思考.......................................................................23
方法论 .........................................................................24
人口统计学......................................................................24
关于作者........................................................................25
致谢............................................................................25

Foreword

前言

The ability to create software is a magical thing. Out of nothing, only an idea, one can construct one’s own world as an object that performs some useful function, entertains, etc. Contributing to open source software provides the opportunity to take this to the next level, allowing the individual to contribute to something of interest to people worldwide. Nevertheless, different open source projects have different coding styles, standards of communication, preferred development tools, etc., and, to facilitate the development process, legitimately expect contributors to conform to a myriad of conventions that are not always written down. This is where mentorship comes in.

软件开发是一件很神奇的事情。只要有一个想法，一个人就可以从零开始，为自己的世界构建一个能执行某些功能的、娱乐性的工具。为开源软件做贡献，提供了一个新的机会，使得个人能为世界各地的人们感兴趣的事情做出贡献，可以将其提升到一个更高的水平。尽管如此，不同的开源项目有不同的编码风格、通信标准、偏好的开发工具等，并且为了促进开发过程，很希望贡献者能够遵守一些约定，而这些约定并不总是用文字写下来了。这就是导师关系的用武之地。

I have been involved in mentorship as a mentor for LFX, GSoC, and Outreachy and as a coordinator for the Linux kernel for Outreachy. Interns come to these programs with all different levels of coding skills and learn how they can contribute to software that today has become the foundation of all computing. The chance to work with a mentor provides the chance to explore ideas in a safe space, where the mentor can head off potential problems in algorithm design, coding style, and communication. In exchange, the mentor can ensure that the mentee is exposed to all of the information that the mentor would like a potential contributor to have. As the mentor and mentee in remote mentoring programs such as LFX and Outreachy often come from different countries and cultures, participating in such programs is also a wonderful way to learn more about the world.

我作为 LFX、GSoC 和 Outreachy 的导师，以及 Outreachy 的 Linux 内核的协调员，曾多次参与导师计划。当初有着不同级别的编码技能的实习生，参与到这些项目中，并学习如何为开源软件做出贡献，这些软件如今已成为所有的计算基础。与导师一起工作，提供了在安全空间中探索想法的机会，导师指导学生解决算法设计、编码风格和沟通方面的各种潜在问题。作为交换，导师可以确保学员接触到潜在贡献者能拥有的所有信息。由于 LFX 和 Outreachy 等远程指导项目的导师和学员通常来自不同的国家，拥有不同的文化，参与此类项目也是了解世界的绝妙方式。

Today, many of the mentees I have worked with have interesting jobs in the industry, while some have diverted to further studies. For some, the internship was one of many steps on the way to their current accomplishments, while for others, the internship represented a rupture in their career, from a position that they were not satisfied with to one that they found more rewarding. Some continue to do work related to the Linux kernel, others explore other directions, and some unexpectedly found their Linux kernel experience applicable in a different area. I am immensely proud of all of them. Mentorship is incredibly rewarding for the mentees, the mentors, and the organizations that benefit from the mentee’s contributions. I would like to thank the various organizations that make these internship programs possible.

今天，与我共事过的许多学员都在该行业找到了有趣的工作，而有些则转行继续深造。对于一些人来说，实习是他们获得当前成就的众多步骤之一，而对于另一些人来说，实习代表着他们职业生涯的断裂，从他们不满意的职位到他们认为更有价值的职位。一些人继续从事与 Linux 内核相关的工作，另一些人探索其他方向，还有一些人意外地发现他们的 Linux 内核经验适用于不同的领域。我为他们所有人感到无比自豪。对于学员、导师和受益于导师计划的组织来说，辅导学员是令人难以置信的回报。我要感谢让这些导师计划成为可能的各种组织。

Julia Lawall

Senior Scientist, French National Research Institute for Digital Science and Technology (Inria-Paris)

Julia Lawall

法国国家数字科学技术研究所（Inria-Paris）高级科学家

Infographic: LFX Mentorship program

FX导师计划

Front Cover


Mentorship creates opportunities for a healthy succession of open source project contributions and leadership.	Mentorship encourages greater equity and accessibility for underrepresented groups to engage in open source projects.	87% of mentees are students, 86% already participate in open source, and 88% are involved in IT broadly.
导师计划为开源项目建设及社区领导力的良性迭代进行了支撑和创造了机会	导师计划鼓励弱势群体参与开源项目，以保障开源项目的公平性和可及性。	87% 的辅导对象是学生，86% 已经参与了开源，88% 或多或少的涉及和使用IT技术。
67% of mentees had never been paid for their open source involvement prior to beginning the mentorship.	Before completing the progam, 64% of mentees lacked some degree of confidence in their ability to engage in open source.	69% of mentees have seen their career advance because of mentorship, with 47% saying that the program helped them get a job.
在接触导师计划之前，67% 的学员从未因参与开源而获得过报酬。	在完成指导之前，64% 的辅导对象对他们参与开源的能力缺乏一定程度的信心。	69% 的辅导对象因为指导而看到了他们的职业发展，47% 的人表示该计划帮助他们找到了工作。
67% of employed mentees report an increase in their income after the program.	52% of the mentees who are now employed are getting paid for their open source involvement.	99% of former mentees recommend the program to others, and everyone involved says that the program was beneficial.
67% 的在职辅导对象表示他们的收入在参与该计划学习和指导后有所增加。	52% 的在职辅导对象因参与开源项目而获得报酬。	99% 的前学员向其他人推荐了该计划，所有参与人员都表示该计划受益匪浅。
90% of mentees have increased confidence in their ability to contribute to open source compared to before they started the program.	85% of mentees are or are willing to continue contributing to the project they were involved in after mentorship.	One of the program’s challenges is recruiting mentees with the essential skills for open source development.
与开始该计划之前相比，90% 的辅导对象对自己为开源做出贡献的能力更有信心。	85% 的辅导对象正在或愿意在接受指导后继续为他们参与的项目做出贡献。	该计划的挑战之一是招募具备开源开发基本技能的学员。

About the LFX Mentorship program study

Linux Foundation (LF) Mentorship helps build diverse communities of developers to address long-term project sustainability issues.
LF Research assessed the effectiveness of the effort in addressing these issues and the career and economic benefits for mentees.
The findings in this report are based on a survey of 100 graduates of the 2020 and 2021 LF Mentorship program.

关于 LFX 导师计划研究

Linux基金会(以下简称LF)导师计划帮助建立多样化社区的开发人员，指导长期项目的可持续性问题。
LF 研究并评估了解决这些问题的有效性以及学员的职业和经济利益。
本报告的调查结果基于对 2020 年和 2021 年 LF 导师计划的 100 名毕业生的调查。

Introduction: The problem that mentorship aims to solve

简介：导师计划旨在解决的问题

Why is it necessary to have open source and LF mentorship programs?

为什么开源与LF导师计划是有必要的？

Open source communities face a two-fold problem: building diverse communities of developers and leadership succession. Mentorship programs help to solve the problem of ensuring robust succession and growth, where many new contributors become part of the community. Just as we require offspring as a human species to guar- antee the health and continuation of our legacy and culture long after the current generation is a living memory, new entrants enable open source to breathe new life and continuity into our communities.

开源社区面临两个方面的问题：建设多元化的开发者社区，以及领导力继承。导师计划有助于解决不断有新的贡献者参与的情况下，如何保障稳健的继承性以及社区成长的问题。就像我们需要作为人类物种的后代来保证我们的文化和遗产在当前这一代人成为鲜活记忆之后很长一段时间内可以持续影响和延续一样，社区的新晋成员能为我们的社区持续的注入新的活力和延续性。

We invest in our communities as beneficiaries of our open source legacy by giving new developers access to knowledge and expe- rience from more experienced participants. By helping new developers to begin, mentors can help ensure that the community continues to grow and thrive long after the founders of these projects cease their direct involvement.

我们通过让新晋的开发者从更有经验的参与者那里的获取知识和经验，作为开源遗产的受益者再投资于我们的社区中。通过协助新的开发者，导师可以协助并保证社区在项目创始人停止直接参与后很长一段时间内可以持续发展壮大。

Investing in our future by providing access to generational knowledge is not the only reason mentorship programs exist. We also wish to foster underrepresented groups—whether women, members of the LGBTQ+ community, people with disabilities, or non-native English speakers—to improve diversity within our communities. Shuah Khan, an open source fellow and Linux kernel maintainer, explains the grounding philosophy of the mentorship program, highlighting the importance of increasing diversity in open source communities, including the Linux kernel:

“The end goal was to have a healthy and sustainable kernel community with diverse viewpoints. Diverse communities are healthy and thriving. Having a different viewpoint in the development process keeps them healthy and relevant and serves the needs of people globally. So, improving diversity and opening up the kernel community of people of different socioeconomic backgrounds was a huge component.”

通过代代相传的知识来投资我们的未来发展并不是导师计划存在的唯一原因。我们还希望培养一些代表性不足的群体——无论是女性、LGBTQ+ 社区成员、残疾人还是非英语母语人士——以改善我们社区的多样性。开源研究员和 Linux 内核维护者 Shuah Khan 解释了导师计划的基本理念，强调了增加开源社区多样性的重要性，包括 Linux 内核：

“我们的最终目标是拥有一个有包容不同观点、健康且可持续的内核社区。多元化的社区代表健康和繁荣。在开发过程中拥有不同的观点可以使社区保持健康和活力，并满足所有人的需求。因此，提高多样性和吸纳不同社会经济背景的人，是社区健康发展的一个重要组成部分。“

“Open source software is the backbone of a lot of our world infrastructure in financial, healthcare, telecommunications, you name it—critical internet infrastructure. So, as a result, keeping these communities healthy for the long term is paramount to keeping this infrastructure working.” —SHUAH KHAN, OPEN SOURCE FELLOW AND LINUX KERNEL MAINTAINER

“开源软件是我们世界上许多金融、医疗、电信等领域基础设施的支柱——关键的互联网基础设施。因此，保持这些社区的长期健康发展对于保持这些基础设施的运转至关重要。” —SHUAH KHAN，开源研究员和 Linux 内核维护者

It’s no secret that the open source community and surrounding culture are historically male-dominated. The LF is actively trying to remedy this by involving and engaging members of underrepresented minority communities, including those less economically advantaged.

众所周知，开源社区和周边文化历来由男性主导。 LF 正在积极尝试通过让代表性不足的群体社区的成员参与进来，包括那些经济条件较差的人，来改变这个现状。

Figure 1	图 1
2022 LFX MENTEE APPLICATIONS BY ECONOMIC STATU	2022年LFX申请学员的经济状况
What group or class do you identify with?	你属于跟他组或者等级？
10.6% Prefer not to answer	10.5% 不想回答
19.7% Working Class	19.7% 工薪阶层
0.4% Upper class	0.4% 上等收入
16.9% Upper middle class	16.9% 中上等收入
52.4% Lower middle class	52.4% 中下等收入

An analysis of LFX Mentorship applicant data in FIGURE 1shows that 72% identify as belonging to the middle class.

图1中 LFX 导师计划的申请人数据分析表明，72%的人来自中产阶级。

Khan, who directs the LFX Mentorship program, states that addressing diversity within the open source community is a complex societal issue involving equitable access to resources and opportunities.

LFX导师计划的Khan指出，解决开源社区多样性的问题是一个复杂的社会问题，它涉及了获得资源和机会的公平性。

She says, “It is an issue of people not having equitable access to resources. We have to do our part to make those resources available to people equitably so that they are easier to access, easier for people to self- learn, and thus more accessible for people to get involved in open source and break down barriers. These barriers are based on your background, the language you speak, and also your financial situation and various other reasons.”*

她说，“这个问题涉及到人们无法公平的获取资源。我们必须要尽一份力量，让大家可以更容易的获得和学习，能公平的使用这些资源，打破障碍参与到开源社区中来。这些障碍通常是人们的背景、语言、财务状况和其他原因。”

Providing this kind of access means recognizing these barriers and tailoring services to respect the needs of diverse communities. This can take the form of offering paid mentorships in some instances and free mentorships in others. Khan explains,

提供对导师计划有差异的访问意味着确实存在这些障碍，并调整了对应的服务以尊重不同社区的需求。比如通过在某些情况下提供付费指导和在其他情况下提供免费指导的形式。 Khan解释说，

“The goal here is to ask, how do we make it easier for people to overcome those barriers? Can we give these folks a little lift by providing resources like free training, free webinars, and paid mentorships? We have added unpaid mentorships because not everyone wants to or can get paid to access this program, as they know our program is a limited resource, and unpaid or credit-only helps us scale it without the funding constraints. So, we try to make it accessible to different needs, career transitions, etc. Our unpaid programs are well received, and we can increase the number of mentees per project.”

“这里，我们需要回答，如何让人们更容易克服这些障碍？能否通过提供免费培训、免费网络研讨会和付费指导等资源来帮助这些人？我们增加了无偿指导，因为导师计划是一种有限的资源，不是每个人都免费的，也不是每个人都希望通过导师计划赚钱，无偿的帮助我们在没有资金限制的情况下扩展它。因此，我们试图让它满足不同的需求，比如职业转型等。我们的无偿项目很受欢迎，在每个项目中的也可以增加学员人数。”

“The problem we are trying to fix is a sustainable maintenance cycle. Bringing more people into open source is part of it, but there are many more steps.” —KATE STEWART, VICE PRESIDENT OF DEPENDABLE SYSTEMS, THE LINUX FOUNDATION

“我们试图解决是对项目周期性维护的可持续性。让更多人参与开源是其中的一部分，但还有很多其他方面。” —KATE STEWART，Linux 基金会副总裁

It is clear that without bringing in these diverse groups of people, open source culture becomes stagnant, putting our projects at risk in terms of their ability to retain talent and inspire new developers to join them as maintainers or core contributors.

很明显，如果不引入这些不同的人群，开源文化就会停滞不前，使我们的项目在留住人才和激励新开发者作为维护者或核心贡献者的吸引力方面面临风险。

Angela Brown, SVP and GM of events at the LF, explains the value of DEI initiatives from the perspective of acquiring talent. She says,

LF 高级副总裁兼活动总经理 Angela Brown 从获取人才的角度解释了 DEI 计划的价值。她说，

“We have all these companies that desperately need open source talent, both now and in the coming years. How do we get people prepared for that? Diversity is a big aspect because that is where you’ll find a lot of this talent since these are previously overlooked groups.”

“我们拥有所有这些迫切需要开源人才的公司，无论是现在还是未来几年。我们如何让人们为此做好准备？多样性是一个很大的方面，这是会发现很多这种人才的地方，他们也是之前被忽略的群体。”

Not only does a lack of diversity hurt the acquisition and retention of talent, but it also translates to attracting fewer developers and is detrimental to code maintenance prospects for those projects. One mentee from the Kubernetes project discussed how mentorship and other DEI programs could help introduce under- represented perspectives into code development to the advantage of the project. As they explained,

缺乏多样性不仅会影响人才的获取和保留，导致更少的开发者的转化，最终不利于这些项目的代码维护。 Kubernetes 项目的一名学员讨论了导师计划和其他 DEI 计划如何帮助将少数派建议引入代码开发，从而使项目受益。他们如此解释，

“Greater representation from these groups introduces different people with different mindsets looking at a project, so when there’s a problem, we can have various approaches to it, which will help it get solved even faster.”

“这些群体的代表性更强，可以让不同的人以不同的心态看待一个项目，所以当出现问题时，我们可以有不同的方法来解决它，这将有助于更快地解决问题。”

The roots of mentorship programs in academia

导师计划的根源

Mentorship programs, specifically for fostering professional communities in the open source realm, have existed in the technology industry for about 17 years, with scholarly publications providing the basis for these programs dating back almost four decades.

在技术行业内，专门为开源领域培养社区方面专业人才的导师计划已经存在了大约 17 年，学术出版物为其奠定了近 40 年的基础。

These works are used to teach Semesters of Code, an evolving undergraduate curriculum that is being taught to computer science students at Johns Hopkins University on open source software engineering by adjunct faculty member Stephen Walli, who is a principal program manager at Microsoft’s Azure Office of the CTO, a board member of the Eclipse Foundation, and a member of the LF Research Advisory Board.

这些学术出版物用于半学年的代码学习课程，这是一门随着技术变化不断更新的本科课程，由兼职教员 Stephen Walli 向约翰霍普金斯大学计算机科学专业的学生讲解开源软件工程，他是微软 Azure 办公软件的 CTO，Eclipse 基金会的董事会成员，以及 LF 研究顾问委员会的成员。

Per Walli, the realization of the importance of mentorship programs began in the late 1980s with the research of Jean Lave, a social anthropologist at the University of California, Irvine, who introduced the concept of learning as participation in ongoing communities of practice. This challenged the conventional theories of learning and education, even to this day.

Per Walli 意识到导师计划的重要性始于 80 年代后期，当时加州大学尔湾分校的社会人类学家 Jean Lave 的研究引入了实习的概念，即参与正在发展中的实践社区。这挑战了传统的学习和教育理论，直到今天。

Her first work, Cognition in Practice: Mind, Mathematics and Culture in Everyday Life (1988), was a treatise about how ordinary people can do mathematical work in their everyday lives without even realizing it. Her second book, authored with Etienne Wenger, Situated Learning: Legitimate Peripheral Participation (1991), was much more influential in education. In this book, Lave and Wenger proposed the theory that learning is a matter of legitimate peripheral participation in communities of practice.

她的第一部作品《实践中的认知：日常生活中的思维、数学和文化》（1988 年）是一篇关于普通人如何在日常生活中不知不觉地使用到数学的论文。她与 Etienne Wenger 合着的第二本书《情境学习：合法的边缘参与》 (1991) 在教育领域影响更大。在这本书中，Lave 和 Wenger 提出了这样一个理论，即学习是在实践的社区群体中有合法边缘参与的认知过程。

According to Lave and Wenger, learning is not something that only happens in the classroom; it is a process that occurs through social interaction in everyday life. A community of practice is a group of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.

根据 Lave 和 Wenger 的理论，学习不仅仅是发生在课堂上的事情；而是一个通过日常生活中的社会互动发生的过程。实践社区是一群人，他们对所做的事情有共同的关注或热情，并在定期沟通经验，交流如何做可以学习得更好。

For example, when children are born, they enter communities of practice, such as their family, and begin to learn the skills and practices of those communities. As they grow older, they move into new communities of practice, such as their peer groups, and continue to learn the skills and practices associated with those communities.

举个例子，一个孩子出生，在一个家庭中生活，就像融入一个实践的社区一样，开始学习家庭里的技能和作法。随着年龄的增长，他们进入一些新的环境，例如他们的同龄人群体，又继续学习与这些社区相关的技能和作法。

“My open source journey started with a question from a mentor in a workplace mentoring session. The question was, ‘what are you waiting for?’” —SHUAH KHAN, OPEN SOURCE FELLOW AND LINUX KERNEL MAINTAINER

“我的开源之旅始于一位导师在职场辅导会议上提出的问题。问题是，‘你还在等什么？’” —SHUAH KHAN，开源研究员和 Linux 内核维护者

The situated learning theory describes the drivers of peripheral participation in communities of practice and is very helpful in understanding how people learn in the workplace. Many companies have started mentorship programs based on this theory to help employees learn the skills and practices they need to succeed in their jobs.

情境学习理论描述了外部环境在实践社区中具有一定的驱动因素，这对于理解人们如何在工作场所中学习非常有帮助。许多公司已经开始根据这一理论开展导师计划，以帮助员工学习在工作中取得成功所需的技能和作法。

Mentorship programs have also been beneficial in other settings, such as schools. In a school setting, mentorship programs allow students to learn from more experienced students or teachers. These programs can also help students develop relationships with adults who can provide support and guidance.

导师计划在学校等其他环境中也大有裨益。在学校环境中，导师计划引导学生向更有经验的学生或老师学习。这些计划还可以帮助学生与可以提供支持和指导的成年人建立关系。

In work settings, mentorship programs allow employees to learn from their experienced peers as a learning pathway for career transition and advancing skills in their areas of interest.

而在工作环境中，导师计划允许员工向经验丰富的同事学习，作为职业转型和提升对感兴趣领域技能学习的途径。

The history of mentorships in open source and the technology industry

开源和技术领域的导师制历史

Open source mentorships date back to 2005 with the introduction of Google’s Summer of Code, a program the company has run for the last 17 years. It targets college students and provides a stipend (of $1,500 to $6,600, depending on size and location) to work on an open source project. The program has expanded to include high school, postsecondary, and graduate students. Similarly, Google’s Code-In, targeted at 13 to 17-year-olds, ran from 2010 to 2019. Beyond Google, other companies are releasing technology industry mentorship programs, such as Microsoft, IBM, Amazon, Meta, and Red Hat. As with Summer of Code, these programs are typically 12 weeks long and take place during the summer. They are open to students at least 18 years of age who have completed one year of college.

开源导师制可以追溯到 2005 年，当时谷歌推出了 “谷歌的代码之夏”，该公司在过去 17 年中一直在运行该计划。它面向大学生并提供津贴（根据规模和地点，提供1,500 美元到 6,600 美元）以从事开源项目。该计划已扩大到包括高中生、大专生和研究生。同样，谷歌的 “谷歌Code-In” 项目针对 13 至 17 岁的人群，从 2010 年持续到 2019 年。除了谷歌，其他公司也在发布技术行业指导计划，例如微软、IBM、亚马逊、Meta 和红帽。与”谷歌代码之夏”一样，这些项目通常为期 12 周，并在夏季向年满 18 岁且已完成一年大学学业的学生开放。

Microsoft Student Partners is a global program that helps students learn about technology, build their technical skills, and connect with other students. The program provides students access to Microsoft products, technologies, and programs.
Microsoft Student Partners 是一项全球计划，可帮助学生了解技术、培养技术技能并与其他学生联动。该计划使学生能够访问 Microsoft 产品、技术和程序。
The IBM Pathfinder Mentoring Program pairs IBM engineers, designers, and business professionals with university students in the same discipline and enables those students to receive personalized career guidance.
IBM Pathfinder Mentoring Program 将 IBM 工程师、设计师和业务专家与同一学科的大学生配对，使这些学生能够获得个性化的职业指导。
The Amazon Mentorship Program is a 12-week program that helps prepare participants for a career in software development. The program includes weekly lectures, coding challenges, and project work. Participants also can shadow Amazon software engineers and attend social events.
亚马逊导师计划旨在帮助参与者为软件开发职业做好准备，为期12周。该计划包括每周讲座、编码挑战和具体项目工作。参与者还可以跟随亚马逊软件工程师参加社交活动。
Meta University is a program for undergraduate and graduate students interested in pursuing a career in software engineering. The program includes coursework, internships, and research opportunities.
Meta大学是一个面向有兴趣从事软件工程职业的本科生和研究生的项目。该计划包括课程作业、实习和研究机会。
Red Hat Mentorships is a program that helps students learn about open source software development. The program provides participants access to Red Hat products, technologies, and programs.
Red Hat Mentorships 是一个帮助学生了解开源软件开发的计划。该计划为参与者提供红帽产品、技术和程序的访问权限。

Nonprofit organizations like the Apache Software Foundation and the GNOME Foundation also offer mentorship programs.

Apache 软件基金会和 GNOME 基金会等非营利组织也提供导师计划。

The Apache Software Foundation offers a 12-week mentorship program for students who want to contribute to Apache projects.**
Apache 软件基金会为想要为 Apache 项目做出贡献的学生提供为期 12 周的导师计划。**
The Software Freedom Conservancy Outreachy program provides internships for people from groups traditionally underrepresented in free and open source software, such as LGBTQ+. Outreachy does not require prior college attendance, only 18 years of age, to qualify for a mentorship.Marina Zhurakhinskaya, a Ukrainian software developer and prominent FOSS advocate, who lost her long battle with cancer in June of 2022, founded the program.
Software Freedom Conservancy Outreachy 计划为传统上在自由和开源软件中代表性不足的群体的人们提供实习机会，例如 LGBTQ+(彩虹族)。 Outreachy(外延计划) 不需要事先上过大学，只需要满足18 岁就有资格获得指导。Marina Zhurakhinskaya创立了该计划，她是乌克兰的软件开发人员和著名FOSS 倡导者，她在 2022 年 6 月与癌症的长期斗争中离世。

The genesis of mentorship at the LF

LF 导师制的起源

The idea of mentorship at the LF initially came about to bring maintainers into the fold for its Linux kernel project. As with many open source projects, the kernel’s developer population has grown organically—it is not a traditional hire and talent placement scenario. The need to replace developers over time is crucial to the stability and longevity of the project, and mentorship is one way to achieve this. The organization decided to become more intentional about how it could help new developers get up to speed and become productive members of the open source community.

LF 的指导思想最初是为了拉动开发者参与其 Linux 内核项目的维护。与许多开源项目一样，内核的开发人员数量已经实现了自然增长——不依赖传统的招聘方式。随着时间的推移，开发者更迭对于项目的稳定性和成长性至关重要，而导师制度是实现这一目标的一种方式。因此，组织决定更加专注于如何帮助新开发者加快成为开源社区高效产出的成员。

The pilot mentorship program launched within the kernel community in 2019 had a few simple objectives: to help new developers feel welcome, learn the ropes, and accept their first code contributions. Khan identified these objectives and the goal of increasing diversity. She says,

“We identified three reasons for starting the program: diversity, community health, and sustainability. You have to inject new talent and bring in people, new developers that can take over at some point from the aging maintainer population and step into these important roles. So, we felt that the best approach at the time would be having these developers trained by maintainer experts in those areas.”

2019 年在内核社区内启动的试点导师计划有几个简单的目标：让新的开发者有归属感、摸到门道并接受他们的第一个代码贡献。 Khan说，

“我们确定了启动该计划的三个原因：多样性、社区健康和可持续性。必须注入新的人才并引入新的开发人员，他们可以在某个时候接替退休的维护人员并担任这些重要角色。因此，我们认为最好的方法是让这些开发人员接受这些维护专家的培训。”

Khan looked at previous examples of mentorship programs at other open source organizations and wanted to broaden mentorships outside of their student-centric focus by inviting industry professionals into the program. This also required unique accommodations that similar programs only previously had. Khan adds,

“I talked to people running mentorship programs at the time, such as Outreachy and Google Summer of Code, and how they viewed the shortcomings of those programs. One part that came up as a big thing was that it would be helpful to have it as a part- time program; thus, we added that early on. We also decided not to restrict it to students because career transition is very important. And I chose to run three sessions, spring, summer, and fall, like a college or university, so that it would be accessible to people globally.

Khan 查看了其他开源组织以前的导师计划案例，并希望通过邀请产业界的专业人士加入该计划来扩大之前以学生为重点的指导。这也是需要单独进行协调，之前并无先例。 Khan补充道，

“我与当时运行导师计划的人进行了交谈，例如 Outreachy 和 Google Summer of Code的相应人员，以及他们如何看待这些计划的缺点。把该计划作为一个兼职项目是个很好的事情；因此，我们很早就添加了这一点。我们还决定不将其仅限于学生，因为职业转型非常重要。我选择举办春季、夏季和秋季三个课程，就像学院或大学一样，以便所有的人都可以使用它。

So, for example, the spring session is probably the one that people from the southern hemisphere could participate in because it is their summer. The summer session would be for other people and students. For others, they could fit into a three-month or six-month program.”

例如，春季班可能是南半球的人可以参加，因为那是他们的夏天。暑期班是为其他人和学生准备的。对于其他人，他们可以参加为期三个月或六个月的课程。”

“Marina Zhurakhinskaya left an amazing legacy of initiatives to lift people up and change the lives of many. Marina’s passing is a big loss to the open source community and people working toward equity in open source.” —SHUAH KHAN, LFX MENTORSHIP PROGRAM LEAD

“Marina Zhurakhinskaya留下了一系列让人惊叹的举措，来提升人们的境遇并改变许多人的生活。Marina的离世对于开源社区和致力于开源平等的人们来说是一个巨大的损失。” —SHUAH KHAN, LFX导师计划负责人

Another approach to attract industry professionals was opening the program to anyone, regardless of employment status. As Khan explains,

另一种吸引产业界专业人士的方法是向任何人开放该计划，无论其就业状况如何。 Khan解释：

“We don’t require applicants to be unemployed; they can be fully employed, part-time, or of any kind of status. We simply say if you can spend 20 to 40 hours a week learning and advancing your skills, you’re welcome to apply to our program.” “我们不要求申请人脱产；他们可以是全职、兼职或任何身份。我们只是说，如果你每周能花 20 到 40 个小时学习和提高你的技能，欢迎你申请我们的项目。”

Khan also explains why they chose not to restrict participants based on demographics:

Khan 还解释了为什么他们选择不根据人口统计的数据来限制参与者：

“Other programs restrict their mentorships to students only or women and LGBTQ+. Some of these are 100% diverse in their population, which is excellent. However, they are fishing from a smaller pond to begin with, which purposefully restricts the size of their addressable communities and programs. We didn’t want to do that; we’re open to everyone.”

“其他项目将他们的指导仅限于学生或女性和 LGBTQ+。其中一些在其人口中 100% 多样化，这非常好。然而，他们面向比较垂直的人群，这刻意的限制了对应的社区和项目的规模。我们不想那样做；我们向所有人开放。”

The program, now known officially as LFX Mentorships, has since been expanded beyond the Linux kernel to include other open source projects under the LF umbrella, such as Cloud Native Computing Foundation (CNCF), Hyperledger, Open Mainframe Project, ELISA, Zephyr, RISC-V, and Automotive Grade Linux. (FIGURE 2)

该计划现在正式称为 LFX Mentorships，此后已扩展到 Linux 内核之外，包括 LF 旗下的其他开源项目，例如云原生基金会 (CNCF)、Hyperledger、Open Mainframe Project、ELISA、Zephyr、RISC -V 和AGL等社区和项目。（图 2）

LFX Mentorships are fully matriculated; once a mentee has completed the program, they have “graduated” and are not eligible for additional mentorship for the program to provide opportunities for others. However, the possibility exists of becoming a mentor in the future. Several graduated mentees have been helping as co-mentors, sharing their experiences and realizing that mentoring is rewarding and a continuous learning path.

LFX导师计划是完全制定的；一旦学员完成了该计划，他们将“毕业”，并不再有资格获得额外的导师计划，以便为其他人提供机会。然而，未来有可能成为导师。一些毕业的学员已经作为合作导师提供帮助，分享他们的经验，并意识到导师工作是有益且持续学习的道路。

Figure 2	图 2
LFX MENTORSHIP PROGRAM MENTEES’ PROJECTS	LFX导师计划学员项目
What was the name of the mentorship project you worked on?	你参与的辅导项目是什么名字？
CNCF projects	CNCF 项目
Linux kernel bug fixing	Linux 内核错误修复
Open Mainframe	开放主机
Hyperledger and blockchain projects	超级账本和区块链项目
Other	其他

Mentorships and their impact on succession and diversity within open source

导师制及其对开源项目内的继承和多样性的影响

Improving diversity

提高了多样性

Ensuring project health is not just about attracting new developers to replace the old; it's also about improving diversity in the open source community to make it more representative of the world. The code submitted to the projects themselves reflects this, where different perspectives worldwide contribute unique features that make the project relevant on a broader scale. Khan provides an example of this from the perspective of energy conservation. She says,

确保项目健康不仅仅是吸引新的开发人员取代旧的开发人员；它还涉及改善开源社区的多样性，使其更具世界代表性。提交给项目本身的代码反映了这一点，世界各地的不同观点贡献了独特的特点，使项目在更大范围内具有相关性。Khan从节能的角度举了一个例子。她说，

“We have kernel patches to improve power management on devices to help users from places like Africa and Southeast Asia, where they don't have as widespread access to charging infrastructure (for their laptops and mobile phones) as the rest of the world. They might not even have 24/7 electricity, which might be a luxury. California residents now realize they need backups with the wildfires they have been experiencing recently. So, these patches help conserve energy so that applications aren’t power hogs; this is critical to companies that sell products in these areas of the world. Different viewpoints come from diverse experiences, and open source software expresses their needs. We call this scratching our own itch, which results in unique features that benefit us all. That’s where diversity of thought comes into play.”

“我们用内核补丁来改善设备的电源管理，以帮助来自非洲和东南亚等地的用户，在这些地方，他们无法像世界的其他地区那样方便地访问充电的基础设施（用于给他们的笔记本电脑和手机充电）。他们甚至可能没有24小时/7天的全天候电力，这可能是一种奢侈。加州居民现在意识到，他们需要备份电力，以应对最近遭遇的野火。因此，这些补丁有助于节约能源，使应用程序不再那么耗电；这对于在世界上这些地区销售产品的公司来说至关重要。不同的观点来自不同的经历，开源软件表达了他们的需求。我们称此为“挠痒痒”，每个人都有自己的痒处，这会产生有益于我们所有人的独特功能。这就是思想多样性发挥作用的地方。”

Although the program is open to everyone by design, the LF has focused on getting more women and other underrepresented groups involved in LFX Mentorship programs.

尽管该计划在设计上向所有人开放，但LF一直专注于让更多的女性和其他代表性不足的群体参与LFX导师计划。

“We are trying to reach out to groups historically underrepresented within the open source community,” said Khan. “We did a big push, for example, to Black colleges and Hispanic colleges in the summer of 2021 to raise awareness, as a part-time program, to give them the flexibility to work from anywhere, and we are expanding that globally. We don’t require participants to be just students, either. When we say we are inclusive, we don’t say this will be just for women, LGBTQ+, or any particular denomination or group. We say this applies to anybody who wants to get involved with open source but does not know how to get started. So far, these are how our efforts have been, and we’ve seen more women participate. But it could be better. We have consistently improved our numbers since the program's inception in 2019. Our participation from women sits at 20% compared to 17% in 2019.”

Khan说：“我们正在试图接触那些在开源社区中历史上代表性不足的群体。” “例如，我们在2021年夏天大力推动黑人学院和西班牙裔学院提高认识，参加一项兼职计划，让他们能够灵活地在任何地方工作，我们正在向全球扩展这一点。我们也不要求参与者只是学生。当我们说我们具有包容性的时候，我们并不是说这将只针对女性、LGBTQ+或任何其他的特定教派或群体。我们认为，这适用于任何想加入开源但不知道如何开始的人。到目前为止，这就是我们所做的努力，而且我们看到更多的女性参与其中。但这可能会更好。自2019年该计划启动以来，我们的人数一直在不断提高。与2019年的17%相比，我们的女性参与率提高到了20%。

Kate Stewart, vice president of dependable systems at the LF, is passionate about bringing new talent and participants into open source projects. In fact, mentorship programs have been instrumental in recruiting new maintainers and advancing projects without direct funding, such as SPDX (Software Package Data Exchange). According to Stewart, “My involvement in mentorship programs began with the SPDX side from the Google Summer of Code. Way back when the project started, this was the only way we were able to make forward progress on some of our tools.”

LF可靠系统副总裁Kate Stewart热衷于将新的人才和参与者引入开源项目。事实上，在没有直接资金资助的情况下，导师计划有助于招募新的维护人员和推进项目发展，例如SPDX（软件包数据交换）。根据Stewart的说法，“从Google编程之夏开始，我参与SPDX项目的导师计划。早在项目开始时，这是我们能够在某些工具上取得进展的唯一途径。”

“One big reason it’s fulfilling is that this makes a difference in people’s lives. That little bit of encouragement, that little bit of lift, and having access to a mentor they can talk to and ask, is my patch good?”

“它令人满意的一个重要原因是，它改变了人们的生活。一点点的鼓励，一点点的提升，还有一个可以交谈的导师，可以询问我的补丁好吗？”

A learning experience for mentees (and mentors)

学员（和导师）的一次学习经历

Mentorship programs can be helpful for both the mentee and the mentor. Mentees can benefit from having someone to look up to and learn from. As Khan notes, mentors can benefit from the satisfaction of helping others grow and develop and introduce them to new approaches to software development. She adds,

导师计划对学员和导师都有帮助。有一个值得仰望和学习的导师，可以使学员受益。正如Khan所指出的，导师可以从帮助他人成长和发展的满足感中获益，也可以从学员那里了解软件开发的新方法。她补充说，

“Mentors could be locked into a way of doing things, as they have been in their role as maintainers for a very long time. So, when somebody new comes in and tries something new, you look at that new approach and go, oh! That makes sense; that’s another way to do things. So, the mentors themselves learn from mentoring. When I’m looking at patches for analysis sent from mentees who are fixing bugs, I am looking at different parts of the kernel that I am not familiar with in some cases. And sometimes, I need to go deep and understand what I am looking at before I can answer the questions from mentees in these areas, so it’s beneficial to me.”

“导师可能会形成了一种固定的做事方式，因为他们担任维护者的角色已经很长时间了。所以，当有新人进来尝试新事务时，你看到那种新方法有效，会很吃惊！这是有道理的; 是另一种做事的方式。所以，导师自己也会从指导中学习进步。当我查看分析学员提交的修复bug的补丁时，我同时也会查看到内核的不同部分，这些部分在某些情况下我并不熟悉。有时，对于学员提出的某些领域的问题，我需要深入分析才能回答，这对我来说也是受益的过程。”

The design of the kernel’s mentorship program helps new developers familiarize themselves with the kernel development process and provide them with guidance and support from more experienced developers. The program is also open to established developers who want to contribute to the kernel but need help with the process. Working with an experienced maintainer can inspire mentees to become maintainers themselves. As one mentee told us,

内核导师计划的设计目的，是帮助新开发人员熟悉内核的开发过程，并为他们提供更有经验的开发人员的指导和支持。该计划也还面向那些想要为内核做出贡献，但需要帮助的成熟开发人员。与经验丰富的维护人员一起工作，可以激励学员成为维护人员。正如一位学员告诉我们的那样，

“Due to the mentorship program, I was able to understand the mindset of the maintainers … and I would happily take the responsibility of maintaining a project if anyone offers me the opportunity.”

“由于导师计划，我能够理解维护人员的心态......如果有人给我机会，我很乐意承担维护项目的责任。”

Mentors can teach new developers about the culture and customs of the open source community, as well as the technical aspects of working on open source projects. They may offer guidance and support while also being a source of inspiration for innovative concepts. In addition, mentorship programs can help build relationships between people of different ages, experiences, and backgrounds. Khan explains,

导师可以向新开发人员传授开源社区的文化和习俗，以及从事开源项目的技术方面的知识。他们可以提供指导和支持，同时也是创新概念的灵感来源。此外，导师计划可以帮助不同年龄、经历和背景的人之间建立关系。Khan解释说，

“One big reason it’s fulfilling is that this makes a difference in people’s lives. That little bit of encouragement, that little bit of lift, and having access to a mentor they can talk to and ask, is my patch good? Or is my communication good on this email list? Or even how we can help them respond to an upstream email conversation. As a mentor, I might ask that they pose specific questions upstream for effective communication. Or the mentee might say to me that the maintainer hasn’t responded to their patch. I can then say, as a mentor, give them more time to respond. Having someone who can watch over you and be an advocate is a big help when you are getting started in open source; it makes you more confident in understanding how the communication dynamic works.”

“它令人满意的一个重要原因是，它改变了人们的生活。一点点的鼓励，一点点的提升，还有一个可以交谈的导师，可以询问我的补丁好吗？或者我在这个电子邮件列表中的沟通是否良好？甚至我们可以帮助他们回复上游的邮件问话。作为导师，我可能会要求他们提出具体问题，以便进行有效的沟通。也许学员可能会告诉我，维护者还没有对他们的补丁做出回应。作为导师我可以说，给他们多一点的时间来回应。当一个人刚开始接触开源项目时，如果有人可以在一旁监督并给与指导是一个很大的帮助；这会让你更有信心去了解项目运作的动态方式。”

"You have to understand the technical skills to be an effective maintainer, but you also have to have a lot more social intelligence. Code is easy. People are hard.Maintainership is about people management."

“要成为一个有效的维护者，你必须理解技术技能，但你还必须具备更多的社交智能。代码很简单，但人们很难处理。维护工作涉及到与人的管理。”

As Kate Stewart says, a maintainer requires a unique combination of technical skills and relationship management.

正如Kate Stewart所说，项目的维护者需要兼具技术能力和关系管理能力。

“There is a recognition that the maintainership tasks are different than the coding tasks. Many people like to code, but this is a different set of skills. You have to understand the technical skills to be an effective maintainer, but you also have to have a lot more social intelligence. Code is easy. People are hard. Maintainership is about people management.”

“人们意识到，维护任务与编码任务不同。许多人喜欢编码，但维护任务需要一套不同的技能。你必须了解技术技能，才能成为一名有效的维护人员，但你还必须拥有更多的社交智慧。管理代码很简单。维护好人员很难。维护工作是关于人员管理的。”

Mentorship can also be a fulfilling experience for retired people who can pass on their expertise to the next generation of programmers to stay active in the technology industry. Stewart discusses the individuals she recruits in former executive roles at major corporations to act as mentors:

对于退休人员来说，导师计划也是一种充实的体验，他们可以将自己的专业知识传授给下一代的程序员，让他们在科技行业保持活跃。Stewart讨论了她在大公司的前高管职位中招募的担任导师的人员：

“Many experienced people are retiring—so how do we keep them engaged? These folks have a lot of skills, so how do they pass them on, and how can it become something they enjoy doing? A friend of mine is a couple of years older than me, and he retired from NXP. He’s sitting around at home, puttering around. And I am saying to myself, how can I lure him into working on some open source projects? It’s rewarding and effective for people who have had a full career, don’t want to do a full-time job, but still want to keep their hand in things and be effective.”

“许多有经验的人都要退休了，我们如何让他们参与进来呢？这些人有很多技能，如何传承，如何让他们继续做喜欢的事情？我的一个朋友比我大几岁，他从NXP退休了。他闲坐在家里，到处闲逛。我在想，怎样才能吸引他从事一些开源项目呢？这些人已经有了完整的职业生涯，不想做全职工作，但仍然希望自己动手做事并保持高效，加入开源项目是有益的，也是有效的。”

Confidence building

构建信心

While any community needs some form of guidance and support for its members, this is especially true in the open source world. The development of open source software presents unique challenges. Volunteers often develop it, and they may not have professional experience. This also influences their desire to engage in open source in the first place, as expressed by 100 LFX Mentorship mentees surveyed in 2022. FIGURE 3 shows almost two-thirds of mentees lacked some confidence in their ability to engage in open source before they joined the program.

任何社区都需要为其成员提供某种形式的指导和支持，在开源世界中尤其如此。开源软件的开发带来了独特的挑战。志愿者经常编程，但他们可能没有专业的开源项目经验。这也影响了他们参与开源项目的愿望，正如2022年接受调查的曾经参与LFX导师计划的100名学员所表达的那样。图3显示，近三分之二的学员在加入LFX之前对他们参与开源项目的能力缺乏信心。

Figure 3	图 3
CONFIDENCE OF MENTEES IN CONTRIBUTING TO OPEN SOURCE PROJECTS BEFORE MENTORSHIP PROGRAM	在参加导师计划之前，学员对开源项目做出贡献的信心
Before the mentorship program, which of the following best describes your level of confidence with respect to engaging in open source?	参加导师计划之前，以下哪项最能描述您对参与开源项目的信心程度？
Not confident	不自信
Somewhat confident	有一些自信
Confident	自信
Very confident	非常自信
Extremely confident	极其自信

One of the positive outcomes of surveying mentees was the reported increase in confidence that mentorship programs create. FIGURE 4 shows that 90% of mentees report increased confidence compared to their level before starting the program.

据报告，对学员进行调查的一个积极结果是，导师计划使他们的信心有所增加。图4显示，90%的学员表示，与开始该计划之前的水平相比，他们的信心提高了。

Figure 4	图 4
MENTEE CONFIDENCE IN CONTRIBUTING TO OPEN SOURCE PROJECTS AFTER MENTORSHIP	在完成导师计划之后，学员对开源项目做出贡献的信心
After completing the mentorship program, which of the following best describes your level of confidence with respect to engaging in open source?	在完成指导计划后，以下哪项最能描述您对参与开源的信心程度？
Prefer not to answer	不想回答
Stayed the same	保持一致
Decreased	降低了
Decreased significantly	极大地降低了
Increased	提升了
Increased significantly	提升幅度很大

Qualitative interviews confirmed these results. One mentee interviewed from the Linux kernel project said they decided to join the program to level up their technical skills but also gained confidence in communicating with the community for help and advice. They explained,

定性访谈证实了这些结果。采访了一位来自Linux内核项目学员表示，他们决定加入导师计划是为了提升自己的技术技能，但同时也获得了与社区沟通以寻求帮助和建议的信心。他们解释说，

“I found that the kernel community was extremely patient with me… as I dealt with the fact that I need to accept help, suggestions, and advice.”

“我发现内核社区对我非常耐心......我接受了我需要帮助、给与建议和给与忠告的事实。”

Another mentee from CNCF shared a similar reflection on their increased confidence because of the program:

另一位来自CNCF的学员，分享了他们因该导师计划而增强信心的类似经验：

“I believe my ability to explain myself or to present myself has increased … now, whenever I face a problem, I just publicly go on Slack, and I just say I’m facing issues.”

“我确信，在解释或展示自己的作品方面，我的能力有所提高......现在，每当我遇到问题时，我都会去上Slack，说明我遇到了什么问题。”

Mentorship can provide these individuals with the skills and knowledge to succeed. Khan elaborates,

导师制可以为这些人提供成功所需的技能和知识。Khan详细说明，

“Mentees are getting direct access to experts in those projects and benefiting from the experience of maintainers. They get a one-on-one meeting with the maintainers and experts. They can bounce ideas off of mentors before submitting their upstream contributions. That’s a huge confidence-building factor.

“学员们可以直接接触这些项目的专家，并从维护人员的经验中受益。他们与这些维护人员和专家进行一对一的会谈。在提交代码贡献之前，他们可以征求导师的意见。这是一个巨大的建立信心的因素。

So, for example, with the 13 mentees I mentored this last summer, some of the questions they asked me were interesting, such as, was our community open? If we send patches, will you review them? And they ask other development questions, such as the length of the development processes of particular vendors, the ideal time to send patches, how long it takes for a maintainer to review the patches, etc. All of these are questions that come up in one-on-one conversations. They have to sort through a lot of information as part of being a contributor to an open source project, and sifting through that is hard for them. So, when they have one-on-one relationships with mentors, it helps.”

例如，去年夏天我指导了13名学员，他们问我的一些问题很有趣，例如，我们的社区是否开放？如果我们发送补丁，你会审查它们吗？他们还问了一些其他的开发问题，例如特定需求的开发过程的有多长、提交补丁的理想时间、维护人员审查补丁需要多长时间等。所有这些问题都是在一对一的对话中出现的。作为一个开源项目的贡献者，他们必须整理大量的信息，而筛选这些信息对他们来说很困难。因此，当他们与导师建立一对一的关系之后，导师会提供很多指导。”

Community building through mentorship

基于导师计划构建的社区

“ After graduating from the program, I went on to start my own open source projects in the JuliaLang community. ... I was confident enough that I could start working on my own project to attract open source contributions someday.”

“从该项目毕业后，我在JuliaLang社区开启了自己的开源项目......我有足够的信心，有朝一日我可以开始自己的项目，吸引开源参与者贡献。”

Mentorship can also help to foster a sense of community within the open source world. By providing guidance and support, mentors can help to create an environment where people feel welcome and valued. This, in turn, can encourage more people to participate in open source projects, which can only serve to improve the quality of the software produced. As one mentee told us,

导师计划还有助于在开源世界中培养社区意识。通过提供指导和支持，导师可以帮助营造一种氛围环境，让参与者感到受欢迎和受到重视。这反过来又可以鼓励更多的人参与开源项目，这种良性循环非常有助于提高软件的质量。正如一位学员告诉我们的那样，

“Apart from the technical skills I picked up from my mentorship project, I also learned the art of communicating technical ideas with like-minded people … I could convey my ideas properly, and even though I was just expecting clarifications on what I should not implement, I received a lot of support from the community to kickstart my first open source project.”

“除了从导师计划项目中学到的技术技能外，我还学会了如何与志同道合的人交流技术想法......我可以恰当地传达我的想法，即使我只是想澄清不应该归我实施的内容，我也依然得到了社区的大力支持，因此我启动了第一个开源项目。”

When thinking about how mentorship programs benefit open source, it’s important to consider other intangibles in addition to bringing in new developer blood and how they address diversity issues. Khan states it’s not simply a balance sheet:

在衡量导师计划对开源项目的意义时，除了引入新的开发人员血液以及他们带来的多样性问题之外，还必须考虑其他的无形资产。Khan说这不仅仅是一份资产负债表：

“Bringing in new developers and training them is obvious, right? When new developers come in, they bring in a new point of view, injecting relevant new ideas like when companies hire new people.

“引入新的开发人员并对他们进行培训，这是显而易见的，对吧？当新的开发人员参与时，他们会带来新的观点，注入新的想法，就像公司雇用新人一样。

Similarly, teaching open source philosophy and the importance of open source early on, in the early part of their careers, will be beneficial to them. It’s also beneficial to have more trained open source developers—they come in and already understand the ecosystem, and part of our training helps them understand that ecosystem. All of that is beneficial—it all comes back to the question of the benefits of open source in the first place. So, it’s hard to prove the bottom line. Training and mentoring new developers are part of that bottom line—all this time and money I spend is not a balance sheet. It’s an intangible benefit that you cannot prove. Yes, it’s beneficial, but you cannot put a dollar amount on it.”

同样，在他们职业生涯的早期，尽早传授开源的哲学和开源的重要性，对他们是非常有益的。让更多训练有素的开源开发人员参与进来，也是有益的，他们有的进来时已经对开源生态系统有所了解，而我们的部分培训可以更进一步帮助他们了解该生态系统。所有这些都是有益的，这一切都回到了开源的好处这个问题上。因此，很难证明开源的盈亏状况。培训和指导新的开发人员代表盈亏的一部分，我花费的所有时间和金钱都不是资产负债表的最终表示。这是无法证明的无形利益。是的，它是有益的，但你没法在资产负债表上加上一笔，哪怕是一美元。”

By completing the mentorship program, mentees are subject to the inner workings of creating and maintaining open source projects. This exposure inspires them to continue contributing to projects. As one mentee said, “I have been actively contributing to open-source ever since.” Another mentee shared how their experience supporting a new project during the program made them confident in starting their own projects:

完成导师计划项目后，学员将参与到创建和维护开源项目的内部工作。这种接触将激励他们继续为此项目做出贡献。正如一位学员所说，“从那以后，我一直在积极地为开源做出贡献。” 另一位学员做了分享，说明他们在项目期间所获得的经验，如何让他们对开启的一个新项目充满了信心：

“After graduating from the program, I went on to start my own open source projects in the JuliaLang community. I had seen the ins and outs of project ideation to the completion of an industry- grade software feature. I was confident enough that I could start working on my own project to attract open source contributions someday.”

“从该项目毕业后，我在JuliaLang社区开启了自己的开源项目。我已经了解了从构思项目到打造行业级别软件功能的来龙去脉。我有足够的信心，有朝一日我可以开始自己的项目，吸引开源参与者贡献。”

The LFX Mentorship program can claim a high success rate as to the disposition of mentees toward open source contribution post-graduation. Eighty-five percent of mentees are or are willing to continue contributing to the project they were involved in after mentorship, as illustrated in FIGURE 5.

LFX导师计划在学员毕业后对开源贡献的影响方面，具有很高的成功率。如图5所示，85%的学员正在或愿意在接受指导后，继续为他们参与的项目做贡献。

Figure 5	图 5
DISPOSITION OF LFX MENTORSHIP PROGRAM MENTEES TOWARD CONTINUING OPEN SOURCE CONTRIBUTION POSTGRADUATION	LFX导师计划学员对毕业后持续开源贡献的意向
Are you willing to contribute to the project you were mentored in?	你愿意为你所指导的项目做出贡献吗？
Yes, and I have been since completing my mentorship	是的，自从完成我的导师计划以来我一直在做贡献
Yes, I would be willing to continue contributing to the project	是的，我愿意继续为该项目做出贡献
No, I am currently unable to commit time to the project	不，我目前无法为该项目投入时间
No, the project no longer overlaps with the work I do	不，该项目不再与我所做的工作有交集
No, there are other reasons I can't continue working on this project	不，还有其他原因我不能继续从事这个项目
Prefer not to answer	不想回答

Mentorship program challenges

导师计划的挑战

"Financial incentives are not effective motivators for open source developers in general."

"一般来说, 对于开源开发人员，经济激励并不是有效的激励因素。"

While mentorship programs can help bring underrepresented groups into the field of software engineering and help refresh the maintainer population, there is still room for improvement.

虽然导师计划可以帮助将代表性不足的群体带入软件工程领域，并对维护人员群体的更新有所助力，但仍有改进的余地。

While the LFX Mentorship program has thousands of applicants every year, the selection process weeds out many people who cannot commit to the program. For one, the programs can be time-consuming and require considerable commitment from participants. In many ways, LFX Mentorship participation as a mentee and mentor follows the self-selection model of open source participation. Even more problematic is the need to get more mentors involved; a lack of mentors can lead to frustration and discouragement for the mentees.

虽然LFX导师计划每年都有成千上万的申请者，但选拔过程淘汰了许多无法参与该计划的人。一方面，这些计划可能很耗时，并且需要参与者做出相当大的承诺。在许多方面，LFX导师参与计划包含受训者和导师，他们需要遵循参与开源的自我选择模式。更大的问题是需要让更多的导师参与进来；导师的缺席会导致受指导者感到挫败和沮丧。

To encourage more mentors to join these programs, Kate Stewart would like to see more recognition and incentives for the mentors themselves.

为了鼓励更多的导师加入这些项目，Kate Stewart希望看到对导师本身的更多认可和激励。

"One of our biggest challenges for mentorship is, how do we get to scale? The scientific work has illustrated that people don’t stick around once they are there—some do, and some don’t. So, we have maintainer burnout. So, the question is, how do you get the people who have been mentored to do the next generation of mentoring so we can scale up instead of everything falling on the maintainers?

“我们在指导方面面临的最大挑战之一是，我们如何扩大规模？科学研究表明，人们不会甘于现状，各有取舍。所以，我们会有维护者惰性。那么问题来了，你如何让接受过指导的人继续参与指导下一代，从而帮助我们扩大规模，而不是一切责任都落在维护者身上？

Motivating graduates to co-mentor is proving to be successful. Some graduates view the opportunity to co-mentor with an experienced mentor as an opportunity to learn and something they can show as an achievement. Financial incentives are not effective motivators for open source developers in general."

事实证明，激励毕业生担任共同导师是成功的。一些毕业生认为与经验丰富的导师共同指导也是他们学习的机会，同样利于他们展示自己的成就。一般对于开源开发人员来说，经济激励并不是有效的激励因素。”

"Most of our funding goes to diversity. Many recipients of event travel funding are women from all over the world, so it gives us a more diverse set of people participating in our events compared with what we see in the mentorship program."

“我们的大部分资金得到了多元化的使用。许多活动的差旅资助收益者都是来自世界各地的女性，因此与我们在导师计划中看到的相比，它让参与我们活动的人更加多样化。”

Mentorship programs can help bring underrepresented groups into the field of software engineering, but they face significant challenges in attracting diverse participants and ensuring they have a rewarding experience once involved. Adequate training and support for mentors and mentees can help address these challenges. Additional resources can make it easier for everyone involved to get the most out of the experience. In addition, by connecting individuals from different backgrounds and experiences, mentorship programs can help create a more diverse and inclusive community within software engineering.

导师计划可以帮助将代表性不足的群体带入软件工程领域，但他们在吸引不同的参与者并确保他们一旦参与后获得有益的经验方面面临重大挑战。对导师和受训者的充分培训和支持可以帮助应对这些挑战。额外的资源可以让所有相关人员更轻松地充分利用他们的经验。此外，通过将来自不同背景和经验的个人联系起来，导师计划可以帮助在软件工程中创建一个更加多样化和包容的社区。

Some of this support can come in the form of funding. Angela Brown, SVP and GM of events at the LF, discussed the value of funding an individual’s participation in a program or event. She offers travel funding to early career professionals to attend open source events within her portfolio. When reviewing the demo graphics of those who have previously received funding, she notes,

其中一些支持可以以资金的形式提供。 LF的高级副总裁兼活动总经理Angela Brown讨论了资助个人参与计划或活动的价值。她为早期职业专业人士提供差旅资金，以参加她投资组合中的开源活动。在审查那些先前获得资助的人的demo图形时，她指出，

"Most of our funding goes to diversity. Many recipients of event travel funding are women from all over the world, so it gives us a more diverse set of people participating in our events compared with what we see in the mentorship program."

“我们的大部分资金得到了多元化的使用。许多活动的差旅资助收益者都是来自世界各地的女性，因此与我们在导师计划中看到的相比，它让参与我们活动的人更加多样化。”

Diversity funding is one way to encourage greater representation in the network of early-career open source developers and expose them to more career opportunities within and outside of the mentorship program.

多元化资助是鼓励早期职业开源开发人员在网络中有更多代表性并让他们在指导计划内外获得更多职业机会的一种方式。

But while training and other resources within mentorship programs can help improve the programs themselves, there are also fundamental problems attracting individuals into mentorship programs due to the limited supply of interdisciplinary software developers trained in embedded systems and software engineering regardless of gender, identity, or socioeconomic background.

但是，尽管导师计划中的培训和其他资源可以帮助改进计划本身，但由于受过嵌入式系统和软件工程培训的跨学科软件开发人员供应有限，无论性别、身份或社会经济背景状况如何，吸引个人参与指导计划也存在根本性问题。

This makes it challenging to find qualified individuals willing to participate as mentors and mentees. In addition, many potential mentees may be reluctant to join a program because they do not have the necessary skills or experience.

这使得很难找到愿意作为导师和参与受训的合格人员。此外，许多潜在的学员可能不愿意加入某个项目，因为他们不具备必要的技能或经验。

The problem is not necessarily a lack of technology professionals. A rebound in the percentage of computer science and information degrees conferred by U.S. universities followed a period of decline, accounting for almost 5% of all degrees in 2020, according to the National Center for Education Statistics.¹ According to the U.S. Bureau of Labor Statistics, the expectation is that employment for all computer and math-related jobs will grow 15% over the next decade.²

问题不一定是缺乏技术专业人员。根据美国国家教育统计中心的数据，美国大学授予的计算机科学和信息技术学位比例在经历了一段时间的下降后出现反弹，2020年占所有学位的近5%。¹ 根据美国劳工统计局的数据，预计所有计算机和数学相关工作的就业人数在未来十年内将增长 15%。²

Instead, it is a question of a skill sets gap. Many of these prospective open source developers do not live in geographies where the required skills are taught in educational institutions.

相反，这是一个技能差距的问题。许多这些潜在的开源开发人员并不居住在教育机构教授所需技能的地区。

These limiting factors have led to a disproportionate underrepresentation of mentees from those parts of the world. Seventy-six percent of respondents to the survey indicated that they lived in the Asia-Pacific region, whereas 14% said they lived in EMEA. Only 10% said they lived in the Americas. (See the Demographics section.)

这些限制因素导致来自世界这些地区的受训者比例过低。76%的调查受访者表示他们住在亚太地区，而14%的人表示他们住在EMEA（欧洲、中东和非洲）。只有10%的人表示他们住在美洲。（请参阅人口统计部分。）

Career benefits of mentorship programs

导师计划的职业福利

In addition to improving community health by fostering diversity and cultivating a new generation of open source developers within these projects, mentorship programs can have a transformative economic impact on mentees' lives after they graduate.

通过这些项目可以促进多样性和培养新一代开源开发者以改善社区健康，除此之外，导师计划还可以对学员毕业后的生活产生变革性的经济影响。

Receiving compensation and being able to cover living expenses is a key concern for mentees when contributing to open source projects. FIGURE 6 shows that two-thirds of LFX Mentorship mentees had no prior experience getting paid for their open source involvement before beginning the mentorship.

在为开源项目做出贡献时，是否可以获得足以支付生活费用的报酬，是学员关注的一个关键问题。图6显示，在参加LFX导师计划的学员中，有三分之二的人表示，在此之前没有通过参与开源项目而获得报酬的经历。

The lack of compensation is partially due to many mentorship program applicants still needing to fully enter the professional world. Per FIGURE 7, before joining the mentorship program, 85% were students; after completing the program, 63% of former mentees had at least a part-time job.

缺乏酬劳的部分原因是，许多参加导师计划的申请人要求完全进入专业领域。根据图7，85%的申请人在加入导师计划之前还是学生；而63%的学员完成该项目后获得至少一份兼职工作。

Regarding overall compensation before and after graduation, 67% of those employed and willing to discuss the subject saw their incomes increase after graduation from the mentorship program. (FIGURE 8).

关于毕业前和毕业后的总体薪酬，67%的就业者和愿意讨论该话题的人表示，其收入自导师计划毕业后有所增加（图8）。

Mentorship programs can also create new and increased career opportunities for mentees. Participating in a mentorship program can give mentees access to resources and knowledge that are difficult to find elsewhere. After graduation, many mentees find that they have a more extensive network of contacts in their chosen field, which can lead to better job opportunities.

导师计划也可以为学员创造更多新的职业机会。参加导师计划可以让学员获得其他地方难以接触到的资源和知识。毕业后，许多学员发现，在所选领域，他们拥有更广泛的人脉网络，这可以带来更好的工作机会。

Mentors often have a wealth of experience and can provide mentees with valuable advice on which direction to take in their careers. The connection to such an experienced individual is often invaluable for a young professional.

导师通常有丰富的经验，可以为学员提供关于职业发展方向的宝贵建议。与这样一个经验丰富的人建立联系，对于一个年轻的技术人员来说往往是无价的。

Mentors are often well-respected members of the industry and can provide mentees with recommendations or introductions that can help them get the job they want. As FIGURE 9 shows, 69% of LFX Mentorship mentees have seen their career advance or new career opportunities emerge due to participating in the mentorship program.

导师通常是受到行业同仁尊敬的专家，可以为学员提供推荐或引荐，帮助他们找到心仪的工作。如图9所示，参加LFX导师计划的学员中，有69%因此获得了职业提升或新的职业机会。

Figure 6	图6
COMPENSATION OF MENTEES BEFORE BEGINNING THE LFX MENTORSHIP PROGRAM	参加LFX导师计划前的学员薪酬
Before the mentorship program, did you receive financial compensation for your contributions to open source projects?	在参加导师计划项目前，你收到过开源项目贡献的经济补偿吗？
Prefer not to answer	不想回答
No, I did not receive financial compensation	不，我未曾收到过经济补偿
Yes, but not enough to cover my living expenses	是的，但不足以满足我的生活开支
Yes, enough to cover my living expenses	是的，且足以满足我的生活开支
Yes, my compensation was more than enough to cover my living expenses	是的，且薪酬在支付生活开支后有结余

FIGURE 7	图7
EMPLOYMENT STATUS OF LFX MENTORSHIP PROGRAM MENTEES POSTGRADUATION	参加LFX导师计划项目的学员毕业后的就业状况
Before and after completing the mentorship program, what best describes your involvement in open source technology projects?	在完成导师计划项目之前和之后，哪一个最能描述您参与开源技术项目的状态？
Before mentorship	导师计划前
After mentorship	导师计划后
Full-time student	全日制学生
Part-time student	非全日制学生
Salaried employee	带薪职工
Working full time above minimum wage	高于最低工资的全职工作
Working part time	兼职工作
Vounteer(full or part time)	志愿者（全职或兼职）
Others	其他

Figure 8	图8
CHANGES IN INCOME LEVELS OF LFX MENTORSHIP PROGRAM GRADUATES	LFX导师计划项目毕业后的收入级别变化
If currently employed, has your income increased following your participation in a mentorship program?	如果目前受雇，在参与导师计划项目后你的收入是否增加？
Prefer not to answer	不想回答
No	没有
Yes	是的

Figure 9	图9
NEW CAREER OPPORTUNITIES FOR LFX MENTORSHIP PROGRAM GRADUATES	LFX导师计划毕业后的新职业机会
Did your mentorship program help you to advance your career (e.g., you received a promotion, a raise, or found a new job with greater opportunities)?	你的导师计划是否有助于你的职业发展（例如，使你获得了晋升、加薪或找到了机会更大的新工作）？
Yes, my career has advanced	是的，我的职业有所进步
Not yet	还没有
Not yet, but I have new oppotunities to do so because I was a mentee	还没有，但是因为我曾是学员，我有新的职业发展机会
No, I have not been able to advance my carrer	不，我的职业发展没有进步

Figure 10	图10
DISPOSITION OF LFX MENTORSHIP PROGRAM GRADUATES ON THE IMPACT OF THEIR EMPLOYMENT STATUS	LFX导师计划毕业生的就业情况，导师计划对其就业的影响
Did your mentorship program help you to find a new job? When did you complete your mentorship program?	你的导师计划是否帮助你找到了一份新工作？你什么时候完成导师计划的？
Yes	是的
No, but I am looking for a job	还没有，但我正在找新工作
No, I am not looking for a job	还没有，我没在找工作
No, I was already employed	不，我已经就业了
Prefer not to answer	不想回答

FIGURE 11	图11
LFX MENTORSHIP MENTEES COMPENSATED AND UNCOMPENSATED PARTICIPATION IN OPEN SOURCE PROJECTS PRE- AND POSTGRADUATION	LFX导师制学员在毕业前和毕业后有偿和无偿参与开源项目
Before and after completing the mentorship program, what best describes your involvement in open source technology projects? Are you currently employed?	在完成导师计划之前和之后，哪一个最能描述您参与开源技术项目的状态？您当前是否就业？
Before mentorship	导师计划前
After mentorship	导师计划后
After mentorship and currently employed	导师计划后且当前已就业
Volunteer in OSS	开源软件志愿者
Observing OSS projects	观察开源软件项目中
Working full time in OSS	全职投入开源软件项目
Working part time in OSS	兼职投入开源软件项目
Not partcipate in OSS	没有参与开源软件项目

“The project clarified my vision of where I would like to take my career and where I would like to go within the mainframe. The vision that I have right now is because of that project.”

“该项目明确了我的职业规划，以及我希望在大型机行业里走向何方。我现在的职业愿景就是源于参加过的这个项目。”

Employment is often a gauge of career advancement, and 47% said that the program helped them get a job. (FIGURE 10) 就业往往是职业发展的一个衡量标准，47%的人表示该计划帮助他们找到了工作。（图10）

For those LFX Mentorship program graduates who have jobs, how does this relate to being compensated for open source work? FIGURE 11 shows that over half of those employed receive payment for their open source involvement.

参加LFX导师计划项目毕业后有工作的人，他们的薪酬与开源工作的报酬有什么关系？图11显示，超过一半的员工因参与开源活动而获得报酬。

The LFX Mentorship program clearly changes the lives of its mentees. FIGURE 12 shows that 58% of participants believe the program had a significant or transformative impact on their careers. One mentee interviewed by the Open Mainframe Project told us,

LFX导师计划显然改变了学员的生活。图12显示，58%的参与者认为该计划对他们的职业生涯产生了重大或变革性影响。Open Mainframe项目采访的一位学员告诉我们，

“The project clarified my vision of where I would like to take my career and where I would like to go within the mainframe. The vision that I have right now is because of that project.”

“该项目明确了我的职业规划，以及我希望在大型机行业里走向何方。我现在的职业愿景就是源于参加过的这个项目。”

But perhaps the most astonishing part of the LFX Mentorship program is the level of satisfaction among its graduates. FIGURE 13 illustrates that 99% of former mentees would recommend the program to others, and everyone involved acknowledges that the program was beneficial.

LFX导师计划最令人惊讶的数据也许是毕业生的满意度。图13显示，99%的前学员会向其他人推荐该计划，所有参与的人都承认该计划是有益的。

Figure 12	图12
PERCEIVED VALUE IN THE BENEFITS OF THE LFX MENTORSHIP PROGRAM AMONG GRADUATED MENTEES	毕业学员对LFX导师计划的益处的价值感受
What statement below best describes the benefit you derived from your mentorship program? (select all that apply)	以下哪项陈述最能描述您从导师计划中获得的收益？（选择所有适用项）
Completing the program provides me useful experiences and references	完成该计划为我提供了有用的经验和参考
I see significant benefit from the program in helping me find and succeed in future jobs	我认为该计划在帮助我找到未来工作并取得成功方面有很大的帮助
Completing the program was transformative to my career and employment opportunities	完成该计划对我的职业生涯和就业机会产生了变革性影响
I see some benefit from the program in helping me find and succeed in future jobs	我认为该计划在帮助我找到未来工作并取得成功方面有一些好处
I see significant benefit to my current job	我认为对我当前工作有巨大好处
I see some benefit to my current job	我认为对我当前工作有一些好处
I didn't see any benifit	我没有发现任何好处
58% of participants believe the program had both a significant and transformative impact on their careers.	58%的参与者相信导师计划对他们的职业生涯产生了巨大的和变革性的影响

Figure 13	图13
DISPOSITION OF LFX MENTORSHIP PROGRAM GRADUATES REGARDING THE OVERALL BENEFIT	LFX导师计划毕业生的总体收益分布
Would you recommend the mentorship program to others?	你会向他人推荐导师计划吗？
Prefer not to answer	不想回答
No	不
Yes	是的

Conclusion

结论

Despite ongoing challenges with scale, mentorship programs, including LFX Mentorship, help college and university students and young professionals gain experience with open source software development, which advances their careers and helps to build a healthy and diverse community of new contributors and maintainers across LF and open source projects.

尽管在规模方面存在持续的挑战，但包括LFX导师在内的导师计划帮助大学生和年轻专业人员获得开源软件开发的经验，这将促进他们的职业发展，并有助于在LF和开源项目中建立一个由新的贡献者和维护者组成的健康、多样化的社区。

The three primary takeaways from the study are:

LFX Mentorship participants had prior involvement in open source and IT from a student’s perspective but lacked confidence and work experience. Their confidence improved after participation.
Mentees find employment and increased income after the conclusion of the mentorship, and they frequently receive payment for their contributions to open source.
The mentorship program is helping build a confident, diverse community of open source developers.

该研究的三个主要结论是：

LFX导师制参与者从学生的角度出发，他们曾参与过开源和IT项目，但缺乏信心以及工作经验；参与后，他们的信心有所提高。
辅导结束后，学生们找到了工作，收入也增加了，他们经常收到报酬感谢他们对开源的贡献。
导师计划有助于建立一个自信、多元化的开源开发者社区。

Actionable insights

可操作的见解

The LFX Mentorship program is making our project communities more diverse, helping mentees find jobs, and demonstrating overall value, but where do we go to improve scale?

LFX导师计划正在使我们的项目社区更加多样化，帮助学员找到工作，并展示整体的价值，但我们该如何扩大规模呢？

Educate multiple stakeholders on the program's successes

在项目成功方面对多个干系方进行宣传教育

LF projects that have invested in LFX Mentorships should be proud of their impact and aware of their return on investment for future funding consideration. Those projects that do not have mentorships in place and are unsure whether a mentorship program will benefit them at their current state of development need only to look to the example set by projects such as the Linux kernel, CNCF, ELISA, Hyperledger, and Open Mainframe—each is devoting significant resources to this effort for the outcomes this report identifies. Additionally, we request our member companies to encourage and promote mentoring by allowing their employees to mentor.

已投入LFX导师的LF项目应为其影响感到自豪，并了解其投资回报，以供未来资金考虑。那些没有导师的项目，并且不确定导师制计划在当前的发展状态下是否会使他们受益，他们只需要看看Linux内核、CNCF、ELISA、Hyperledger和Open Mainframe等项目所树立的榜样，每个项目都在为本报告确定的结果投入大量资源。此外，我们通过让我们的成员公司员工自行指导的方式，使成员公司鼓励指导、和提高指导水平。

Encourage continued financial support from the open source community

鼓励开源社区延续资金支持

An investment in mentorship is an investment in the future health of open source projects. The financial incentive offered to mentees to join the program meets a fundamental need for people at the outset of their careers. Similarly, it may be worth exploring ways to compensate mentors who invest significant time, which may comprise a combination of financial reward with support in the form of human resources, tooling, and other nonfinancial benefits.

对导师的投资是对开源项目未来健康状况的投资。向学员提供的加入该计划的经济激励满足了人们在职业生涯初期的基本需求。同样，值得探索的是如何补偿投入大量时间的导师，这可能包括财务奖励与人力资源、工具和其他非财务利益形式的支持的组合。

As member and partner organizations benefit heavily from the open source projects themselves, they should view funding mentorship as an investment in their own software’s sustainability, increasing the likelihood of a steady stream of future talent that is trained on the platforms they use. An example of this is the recently launched LFX Mentorship Showcase, which allows graduating mentees of the LFX Mentorship program to showcase the work they completed during their session term and connect with prospective employers from our member companies.

由于成员和合作伙伴组织从开源项目本身中受益匪浅，因此他们应该将资助导师关系视为对自己软件可持续性的投资，从而增加在他们使用的平台上培训稳定未来人才的可能性。这方面的一个例子是最近推出的LFX导师展示会，它允许LFX导师计划的毕业生展示他们在课程期间完成的工作，并与我们成员公司的潜在雇主进行联络。

Address geographic barriers that the report identifies

解决报告中定位到的地理阻隔

As Southeast Asian participants represent more than 70% of the LFX Mentorship program, this is a powerful indicator that we need to understand the reasons for the gap and improve the geographic makeup of the mentee population in other regions, such as North America and Europe.

目前东南亚参与者占LFX导师计划的70%以上，这是一个强烈的信号，我们需要了解这种差距的原因，并改善其他地区（如北美和欧洲）学员人口的地理组成。

Use tooling for productivity to help maintainers mentor without burnout

使用工具提高生产力，以帮助维护人员在指导过程中避免倦怠

The amount of time that mentors invest directly with their mentees is significant, so the more we can use tools to create a “one-to-many” type of paradigm will improve the program’s scalability. Examples of this are in play, such as the 15-minute “Speed Mentorships” recently tested at Open Source Summit North America 2022 and LF Live: Mentorship, a series of webinars held for remote learning that can be attended on demand.

导师与学员直接投入的时间非常长，因此我们越能使用工具来创建“一对多”类型的范例，就越能提高项目的可扩展性。这方面的例子正在进行，例如最近在2022年北美开源峰会上测试的15-minute “Speed Mentorships”和LF Live: Mentorship，这是一系列为远程学习举办的网络研讨会，可根据需要参加。

Final Thoughts

最后的感想

The LFX Mentorship program is clearly a success, and we should be doing all that we can to encourage more investment in this valuable initiative. By educating stakeholders on the successes of mentorship programs, seeking donations and funding from among our members and partners, addressing geographic barriers, and using tooling for productivity, we can ensure the longevity of the program and also create a more diverse, confident open source developer community for the long term. By leveraging the power of mentorships, we can continue to improve our open source projects and ensure they remain vibrant for years to come.

LFX导师计划显然是成功的，我们应该尽一切努力鼓励更多的投资于这项宝贵的计划。通过对参与方进行导师计划取得成功的宣传教育，从我们的成员和合作伙伴中寻求捐款和资金，解决地理障碍，并使用工具提高生产力，我们可以确保计划的持久性，并长期创建一个更多元、更自信的开源开发者社区。通过利用导师制的力量，我们可以继续改进我们的开源项目，并确保它们在未来几年保持活力。

We would like to thank our mentors for volunteering their time to share their valuable experience in formal mentoring programs and in hosting LF Live Webinars

我们要感谢我们的导师自愿抽出时间分享他们在正式指导计划和举办LF Live网络研讨会方面的宝贵经验。

Methodology

研究方法

The completion of a survey of graduates of the LF Mentorship program took place from January through March 2022.
After eliminating duplicate and incomplete records, this analysis is based on 74 participants who came from the 2021 mentorship class, with the remainder completing the program in 2020.
For N = 100, the margin of error is +/- 8.2% @ 90%.
After the completion of the initial survey, more than 20 mentees provided additional qualitative feedback.
Percentage values may not add exactly to 100% due to rounding
2022年1月至3月完成了LF导师计划毕业生调查。
在消除重复和不完整的记录后，本分析基于来自2021辅导的74名课程参与者，其余学生将于2020年完成课程。
对于N=100，误差范围为+/-8.2%@90%。
初始调查完成后，20多名学员提供了额外的定性反馈。
由于进行了取整运算，百分比值可能无法精确增加到100%

Demographics

统计数据特征

A survey of 100 graduates of the 2020 and 2021 LF Mentorship programs yielded the results. Three-quarters of the respondents lived in an Asian country during their mentorship, and 82% were 18–24 years old. Of those currently employed, 69% work in the information technology industry.

对2020年和2021 LF导师计划的100名毕业生进行的调查得出了结果。四分之三的受访者在担任导师期间生活在亚洲国家，82%的受访者年龄在18-24岁。在目前就业的人中，69%在信息技术行业工作。

Figure 14
SELECTED DEMOGRAPHICS OF THE 2022 LF MENTORSHIP SURVEY	2022年LF导师调查的选定人口统计
Mentorship class	指导班级
Location during mentorship	指导期间所在位置
Americas	美洲
EMEA	欧洲、中东和非洲
Asia Pacific	亚洲太平洋
Age	年龄
Industry of employment	就业行业
Other industries	其他行业
Information Technology (IT vendor or sevice provider)	信息技术（IT 厂商或服务提供商）

About the author

关于作者

Jason Perlow is a veteran of the information technology industry with over 25 years of experience as an independent consultant for the financial sector and a systems architect, technology strategist, and technical writer at Unisys, IBM, Dimension Data, and Microsoft. Jason led the 8th, 9th, and 10th annual LF Jobs Reports. He co-authored the 2021 State of Open Source in Financial Services research and, as editorial director, is the lead content writer, editor, and manager for LF Projects, LF Research, and Linux.com. In 1999, Jason was the founding senior technology editor of Linux Magazine, where he led coverage of the formation of the LF and has had an op-ed technology column on ZDNET, covering enterprise technology since 2008.

Jason Perlow是信息技术行业的资深人士，拥有超过25年的金融行业独立顾问经验，也是Unisys、IBM、Dimension Data和Microsoft的系统架构师、技术策略师和技术作家。Jason领导了第8、第9和第10届LF年度工作报告。他与人合著了《2021金融服务研究中的开放源码状态》（State of Open Source in Financial Services research），作为编辑总监，他是LF Projects、LF research和Linux.com的主要内容撰写人、编辑和经理。1999年，Jason是Linux Magazine的创始高级技术编辑，他在该杂志上领导了LF的形成报道，并在ZDNET上开设了op-ed技术专栏，自2008年起涵盖企业技术。

Acknowledgments

致谢

作者希望感谢我们的赞助商，CNCF、Hyperledger基金会、安全应用程序中启用Linux（ELISA）项目、开放大型机项目和开源安全基金会（OpenSSF）对本研究的支持。特别感谢LF的同事Shuah Khan、Kate Stewart和Angela Brown的见解；Hilary Carter、Lawrence Hecht、Steve Hendrick、Anna Hermansen、Christina Oliviero和Melissa Schmidt提供定量分析和运营支持；以及参加本次调查的所有LFX导师，尤其是本次研究的受访者。

Note

注释

This report has been updated since its original release on 01.16.23. This second version, released on 01.19.23, corrects errors found in the original text and graphics.

本报告自2013年1月16日首次发布以来已进行了更新。当前为第二个版，发布于2023年1月19日，修正了原始文本和图形中的错误。

Backcover

Mentorship

Invest in building a stronger and more diverse community of qualified developers and engineers. LFX Mentorship makes it easy to sponsor and help train the next generation of open source developers by serving the key needs of the community. The program received 10,700 applications, accepted 600+ applicants, and paid $1.5M in stipends. Since its inception in 2019, LFX Mentorship Programs have trained 414 new developers. Several of our graduates are now gainfully employed and continuing to contribute to open source projects. We strongly believe in and are committed to providing learning pathways for new developers of all backgrounds.

投资于建设一个更强大和多样化的合格开发人员和工程师社区。LFX Mentorship通过满足社区的关键需求，为赞助和帮助培训下一代开源开发人员提供了便利。该计划收到了10,700份申请，接受了600多名申请人，并支付了150万美元的津贴。自2019年成立以来，LFX Mentorship计划已经培训了414名新的开发人员。我们的一些毕业生现在已经稳定就业，并继续为开源项目做出贡献。我们坚信并致力于为所有背景的新开发人员提供学习路径。

LF Research

Founded in 2021, LF Research explores the growing scale of open source collaboration and provides insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks and a commitment to best practices in quantitative and qualitative methodologies, LF Research is creating the go-to library for open source insights for the benefit of organizations the world over.

LF研究院成立于2021年，探索不断扩大的开源合作规模，并提供新兴技术趋势、最佳实践和开源项目的全球影响力的见解。通过利用项目数据库和网络，并致力于定量和定性方法论的最佳实践，LF研究正在为全球组织打造一座开源见解的图书馆，以造福全球。

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License. To reference the work, please cite Jason Perlow, “Mentorship in Open Source,” foreword by Julia Lawall, The Linux Foundation, January 2023.

此报告受创作共用许可证Attribution-NoDerivatives 4.0 International Public License保护。在引用这项工作时，请引用Jason Perlow的“开源中的导师制”，由Julia Lawall撰写的前言，The Linux Foundation，2023年1月发布。

CNCF

The CNCF, part of the LF, hosts critical components of the global technology infrastructure, including Kubernetes, Prometheus, and Envoy. CNCF brings together the industry’s top developers, end users, and vendors and runs the world’s largest open source developer conferences. For more information, please visit www.cncf.io.

CNCF（云原生计算基金会）是 LF（Linux 基金会）的一部分，承载着全球技术基础设施的关键组件，其中包括 Kubernetes、Prometheus 和 Envoy。CNCF 聚集了行业顶尖的开发者、最终用户和供应商，并举办全球最大的开源开发者大会。欲了解更多信息，请访问 www.cncf.io。

ELISA

The ELISA project aims to make it easier for companies to build and certify Linux-based safety-critical applications— systems whose failure could result in loss of human life, significant property damage, or environmental damage. ELISA members are working together to define and maintain a common set of tools and processes to help companies demonstrate that a specific Linux-based system meets the necessary safety requirements for certification. Launched in February 2019, ELISA works with Linux kernel and safety communities to agree on what to consider when using Linux in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.

ELISA项目旨在帮助企业更轻松地构建和认证基于Linux的安全关键应用程序- 这些系统的故障可能导致人员生命的丧失、重大财产损失或环境破坏。ELISA成员共同努力，定义并维护一套通用的工具和流程，帮助企业证明特定的基于Linux的系统满足必要的安全认证要求。ELISA于2019年2月推出，与Linux内核和安全社区合作，以就在安全关键系统中使用Linux时要考虑的内容达成一致。该项目有几个专门的工作组，专注于为系统集成商提供资源，以进行定性和定量分析其系统的应用和使用。

Hyperledger

Hyperledger Foundation is an open source community focused on developing a suite of stable frameworks, tools, and libraries for enterprise-grade blockchain deployments. It is a global collaboration hosted by The LF and includes leaders in finance, banking, the Internet of things, supply chains, manufacturing, and technology. Built under technical governance and open collaboration, individual developers, service, and solution providers, government associations, corporate members, and end users are all invited to participate in developing and promoting these game-changing technologies.

Hyperledger Foundation（超级账本基金会）是一个致力于开发稳定框架、工具和库以适用于企业级区块链部署的开源社区。它是由LF（Linux Foundation）托管的全球合作项目，包括金融、银行、物联网、供应链、制造业和技术领域的领导者。在技术治理和开放合作的基础上构建，鼓励个人开发者、服务和解决方案提供商、政府协会、企业会员和终端用户参与开发和推广这些具有改变游戏规则的技术。

Training and Certification

The LF’s training program features courses developed and taught by expert instructors, many of whom are wellrespected professionals in the open source community. Our certification team performs comprehensive industry and job analyses to ensure every professional certification program we offer meets our exceedingly high standards. Led by our outstanding customer success team, we deliver responsive support and customized training solutions to enable individual and business to successes.

LF的培训计划包括由专家讲师开发和教授的课程，其中很多人在开源社区中拥有很高的声誉。我们的认证团队会进行全面的行业和工作分析，以确保我们提供的每个专业认证计划都满足我们极高的标准。在我们出色的客户成功团队的带领下，我们提供响应迅速的支持和定制培训解决方案，以促使个人和企业的成功。

Open Mainframe

The Open Mainframe Project was founded in 2015 as a focal point for deploying and using Linux and open source in a mainframe computing environment. With a vision of open source on the mainframe as the standard for enterprise-class systems and applications, the project’s mission is to build community and adoption of open source on the mainframe by eliminating barriers to open source adoption on the mainframe, demonstrating value of the mainframe on technical and business levels, and strengthening collaboration points and resources for the community to thrive. Open Mainframe Project is home to more than 22+ projects and working groups, including ADE, Ambitus, ATOM, CBT Tape, COBOL Check, COBOL Programming Course, COBOL Working Group, ConsoleZ, Feilong, GenevaERS, Linux Distributions Working Group, Mainframe Open Education, Mentorship, Polycephaly, Software Discovery Tool, TerseDecompress, Tessia, Zowe, and Zorow.

开放大型计算机项目（Open Mainframe Project）成立于2015年，旨在成为在大型计算机环境中部署和使用Linux和开源的焦点。该项目的愿景是将开源在大型计算机上作为企业级系统和应用的标准，其使命是通过消除在大型计算机上采用开源的障碍，展示大型计算机在技术和业务层面的价值，以及加强合作关系和资源，推动大型计算机上开源的社区建设和采用。开放大型计算机项目拥有22多个项目和工作组，包括ADE、Ambitus、ATOM、CBT Tape、COBOL Check、COBOL编程课程、COBOL工作组、ConsoleZ、Feilong、GenevaERS、Linux发行版工作组、大型计算机开放教育、导师计划、Polycephaly、软件发现工具、TerseDecompress、Tessia、Zowe和Zorow等。

OpenSSF

The OpenSSF is a cross-industry organization that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF commits to collaboration and working both upstream and with existing communities to advance open source security for all.

OpenSSF是一个跨行业组织，汇集了行业中最重要的开源安全倡议以及支持它们的个人和企业。OpenSSF致力于合作，并在上游和现有社区之间共同推动开源安全的发展。

National Center for Education Statistics. 2022. Undergraduate Degree Fields. Condition of Education. U.S. Department of Education, Institute of Education Sciences. Retrieved 11/23/2022, from (https://nces.ed.gov/programs/coe/indicator/cta). ↩ ↩²
U.S. Bureau of Labor Statistics. 2022. “Computer and Information Technology Occupations: Occupational Outlook Handbook”. Retrieved 11/23/2022, from (https://www.bls.gov/ooh/computer-and-information-technology/home.htm). ↩ ↩²

OSPO 的商业价值 —— 探索为什么组织创建、维持、扩大开源项目办公室

2023年6月28日 · 阅读需 122 分钟

Front Cover

OSPO 的商业价值

An Exploration of Why Organizations Create, Sustain, and Expand Open Source Program Offices (OSPOs)

探索为什么组织创建、维持、扩大开源项目办公室（OSPOs）

MARCH 2023

Emily Omier, Positioning & Messaging Consultant, Emily Omier Consulting

Chris Aniszczyk, CTO, Cloud Native Computing Foundation

Ana Jiménez Santamaría, OSPO Program Manager, TODO Group

With forewords by Georg Kunz, Open Source Manager, Ericsson, Leslie Hawthorn, Sr. Manager, Red Hat OSPO and Kimberly Craven, Sr. Director, Red Hat OSPO, Office of the CTO

2023年3月

Emily Omier，Emily Omir咨询公司定位与信息顾问

Chris Aniszczyk，云原生计算基金会首席技术官

Ana Jiménez Santamaría，OSPO 项目经理，TODO工作组

爱立信开源经理Georg Kunz、Red Hat OSPO高级经理Leslie Hawthorn和首席技术官办公室Red Hat OSPO高级总监Kimberly Craven作序

Forewords ............................................................................................................................................3
Introduction.........................................................................................................................................7
Why do we care about how OSPOs contribute to the business? ................................................................................7
Common threads in unique stories ...................................................................................................................................7
Methodology ..........................................................................................................................................................................8
Organization profiles and the relationship with open source......................................................................................8
What can OSPOs do for organizations?.........................................................................................11
The reasons behind starting an OSPO............................................................................................................................11
The OSPO journey.............................................................................................................................16
Overcoming internal obstacles: Culture and education ..............................................................................................16
A strategic relationship with open source ......................................................................................................................17
The different hats of an OSPO .......................................................................................................18
The Counselor ......................................................................................................................................................................18
The Facilitator.......................................................................................................................................................................18
Ensuring OSPO sustainability............................................................................................................................................18
Measuring an OSPO’s success.........................................................................................................19
Common OSPO KPIs ...........................................................................................................................................................19
The KPI search..................................................................................................................................................................... 20
Conclusion..........................................................................................................................................21
What’s coming in the future? ............................................................................................................................................21
Future research....................................................................................................................................................................21
About the authors .............................................................................................................................................................. 22

序 ................................................................................3
简介............................7
为何我们关注OSPOs的商业贡献？ ..................................7
独特故事的共同脉络 ................................................7
方法论 .............................................................8
组织简介以及其与开源的关系..................................................................8
OSPOs可以为组织做什么？...........................................11
开启一个OSPO的原因......................................................................11
OSPO之旅........................................16
克服内部阻碍：文化和教育 ..............................................16
与开源之间的战略关系 ...................................17
OSPO的不同角色 ..................................18
顾问 .................................18
推动者........................................18
确保OSPO的可持续性.........................................................18
评估一个OSPO的成功..................................................19
常见的OSPO KPIs ..........................................................19
KPI搜索................................................................. 20
结论....................................................21
展望未来 ......................................................21
后续研究....................................................................21
关于作者 ..................................................................... 22

Forewords

序

Open source software continues to transform how entire industries create and use software. Across industries, systems built to a large degree or even entirely from open source software components that communicate via open APIs are replacing proprietary and closed software stacks. Based on collaboration and joint development, open source software has become a fundamental means for driving innovation, fostering technology adoption, and openly sharing knowledge.

开源软件继续改变着整个行业创建和使用软件的方式。在各个行业中，在很大程度上甚至完全由通过开放API沟通的开源软件组件构建的系统正在取代专有和封闭的软件堆栈。基于协作和联合开发，开源软件已成为推动创新、促进技术采用和公开共享知识的基本手段。

While the high-level advantages of open source software are undeniable, it is unfortunately far from simple and straightforward for organizations to leverage those in practice. As the usage of open source software in organizations proliferates and matures, many realize the need for establishing a structured approach to working with open source software. Initially, this need typically emerges from license compliance concerns, but it quickly grows way beyond compliance alone, eventually encompassing business strategy aspects as well.

尽管开源软件的顶层优势是不可否认的，但不幸的是，组织在实践中使用它们远非这么简单直接的事情。随着开源软件在组织中的使用激增和成熟，许多人意识到需要建立一种结构化的方法来使用开源软件。最初，这种需求通常源于许可证合规性问题，但它很快就远远超出了合规性本身，最终也涵盖了商业战略方面。

This report compiles the results of a survey among open source advocates from Open Source Program Offices (OSPOs) across various companies and universities. It provides a broad insight into the motivation behind forming OSPOs and the concrete business value of OSPOs to their respective organizations.

本报告汇集了来自不同公司和大学的开源项目办公室（OSPO）的开源倡导者的调查结果。它为形成OSPO背后的动机以及OSPOs对其各自组织的具体商业价值提供了广泛的视角。

It turns out that, just like open source software itself, OSPOs come in all sorts of shapes and forms. However, irrespective of the concrete implementation of an OSPO, the survey shows that across organizations, the key business value of OSPOs converges toward the same fundamental goals: to establish a framework for an organization’s way of working with open source software and to ensure that open source software is leveraged strategically and well aligned with an organization’s business goals. An OSPO’s responsibilities thereby range from formalizing processes and transforming an organization’s culture to guiding the creation and execution of a long-term open source strategy.

事实证明，就像开源软件本身一样，OSPO有各种各样的形态和方式。然而，无论OSPO的具体实施情况如何，调查显示，在各个组织中，OSPO的关键业务价值指向了相同的基本目标：为组织使用开源软件的方式建立一个框架，并确保开源软件在战略上得到利用，并与组织的业务目标保持一致。因此，OSPO的职责范围从正式化流程和转变组织文化到指导长期开源战略的创建和执行。

Building on the core principles of open source software— collaboration and knowledge sharing—the contributors to this report aim to provide a helpful source of information. It targets both open source champions in organizations who are currently on the journey of establishing an OSPO as well as open source leaders of existing OSPOs, enabling them to clearly define, measure, and communicate the business value of an OSPO.

基于开源软件协作和知识共享的核心原则，本报告的撰稿人旨在提供有用的信息来源。它既针对目前正在建立OSPO的组织中的开源拥护者，也针对现有OSPO的开源领导者，使他们能够清楚地定义、衡量和传达OSPO的商业价值。

Georg Kunz

Open Source Manager, Ericsson

Georg Kunz

爱立信开源经理

As open source software has achieved ubiquity in the technology arena, more organizations are realizing the benefits of working with open source projects and the communities that build them. To harness this strategic potential of open source, direct investment into engaging with project communities is no longer a nice to have but a requirement. OSPOs, once largely extant only at large technology-focused firms, have proliferated across industries as a locus for starting, standardizing, and scaling an organization’s approach to open source.

随着开源软件在技术领域的普及，越来越多的组织正在意识到与开源项目和构建这些项目的社区合作的好处。为了利用开源的这种战略潜力，直接投资参与项目社区不再是一件好事，而是一种要求。OSPO曾经主要只存在于以技术为重点的大型公司，现在已经在各个行业激增，成为启动、标准化和扩展组织开源方法的场所。

In just the past five years, we have seen OSPOs crop up in the fields of automotive, entertainment, financial services, manufacturing, and even within academia and government bodies. Having an OSPO and accompanying dedicated resources to focus a company’s open source strategy creates a framework for harnessing the best possible outcomes for all players involved. Organizations have a clearer view of the software landscape upon which their businesses depend, maintainers of key software projects have a more direct line into organizations using their works, and external would-be collaborators have a welcoming and well-understood entry point to negotiating with the business.

在过去的五年里，我们看到OSPO在汽车、娱乐、金融服务、制造业领域，甚至在学术界和政府机构中涌现。拥有一个OSPO和相应的专用资源来专注于公司的开源战略，为所有参与者创造了一个利用最佳结果的框架。组织对其业务所依赖的软件环境有了更清晰的了解，关键软件项目的维护者可以更直接地进入使用其作品的组织，外部潜在合作者在与业务谈判时有一个受欢迎且广为人知的切入点。

In this report, you will hear from OSPO leaders across a variety of sectors who will share their journey building open source consumption, contribution, and community engagement strategies for their businesses. You will also learn that each OSPO’s goals, success metrics, and approaches to engagement vary depending upon the drivers for establishing the OSPO, an organization’s maturity level with their open source practice, and how internal champions for the OSPO’s work support its growth and strategy. No OSPO is exactly like another, even as they share many common responsibilities.

在本报告中，您将听到来自各个行业的OSPO领导人的发言，他们将分享他们为企业建立开源消费、贡献和社区参与战略的历程。您还将了解到，每个OSPO的目标、成功指标和参与方法都有所不同，这取决于建立OSPO的驱动因素、组织在开源实践方面的成熟度水平，以及OSPO工作的内部支持者如何支持其发展和战略。没有一个OSPO与另一个完全相同，尽管它们有许多共同的责任。

Across our combined 30+ years of experience working in open source, the common thread we’ve seen that unites all OSPOs is their deep value in enabling collaboration and co-creation, whether that’s internally amongst different software teams or competitors working together in an upstream community. OSPOs are one of the few teams with a clear mandate for bi-directional advocacy, both within the organization— establishing norms for engaging with open source projects and championing open source best practices—and externally to the organization, ensuring that a company’s actions in a particular community both serve business goals and advance the technical state of the art for all players.

在我们30多年的开源工作经验中，我们看到的将所有OSPO团结在一起的共同点是，无论是在不同的软件团队内部，还是在上游社区中合作的竞争对手之间，它们在实现协作和共同创建方面都有着深刻的价值。OSPO是少数几个明确授权双向倡导的团队之一，无论是在组织内部，还是在组织外部，都要建立参与开源项目和倡导开源最佳实践的规范，确保公司在特定社区的行动既有助于实现商业目标，又能提高所有参与者的技术水平。

It is precisely because of the flexibility and bi-directional nature of the OSPO’s mission that these groups can be the foundational strategic lynchpin of a business’s technology approach. OSPOs have the freedom to explore and support innovations for the business and to define how this engagement will work to best satisfy the objectives of all players, from engineering talent to business executives to the open source project community itself. OSPOs act as the conduit and connective tissue between each group of stakeholders, diplomatically ensuring the interests of all parties are heard and considered, and negotiating for the best possible outcomes for all parties collaborating and co-creating together.

正是由于OSPO使命的灵活性和双向性，这些团体可以成为企业技术方法的基本战略关键。OSPO可以自由探索和支持业务创新，并定义这种参与将如何最好地满足所有参与者的目标，从工程人才到企业高管，再到开源项目社区本身。OSPO充当每组利益相关者之间的管道和连接组织，在外交上确保各方的利益得到倾听和考虑，并为各方合作和共同创造尽可能好的结果进行谈判。

It is this inward and outward-facing service mission that is the real magic of the OSPO. In this role, the successful OSPO acts as a diplomat for its organization in the wider world, charged with representing the needs of the business to the community and the community’s needs to the business. OSPOs have a unique role to play as stewards of industry-wide best practices, a locus of collaboration and co-creation, and a conduit for change agency as their company evolves in the ever-changing market landscape.

正是这种内向和外向的服务使命才是OSPO真正的魔力。在这一角色中，成功的OSPO作为其组织在更广泛世界的外交官，负责代表社区对企业的需求和企业对社区的需求。随着公司在不断变化的市场格局中的发展，OSPOs作为全行业最佳实践的管理者、合作和共同创造的场所以及变革机构的渠道，可以发挥独特的作用。

For those who have worked in the open source space for the past decades, or for readers who are early in their open source journeys, this whitepaper will present key areas of challenge and opportunity for the OSPO, shared from senior OSPO leaders across a variety of industries. Wherever you may be in your OSPO journey, from having one lone staffer who focuses on open source software license compliance to having a long-established open source strategy, we hope you will find this research valuable in examining the business value of OSPOs for your enterprise. As you examine the findings from open source leaders in a variety of industries, we hope you will see yourself in their journeys and be inspired. We look forward to your organization joining the community of OSPO practitioners contributing to the very foundations of open source practice: how we work together, what we do together, and how we all can derive mutual benefit.

对于那些在过去几十年中一直在开源领域工作的人，或者处于开源之旅早期的读者，本白皮书将介绍OSPO面临的挑战和机遇的关键领域，并由各个行业的OSPO高级领导人分享。无论您身处OSPO之旅哪个阶段，从拥有一名专注于开源软件许可证合规性的员工，到拥有一个长期建立的开源策略，我们希望您能发现这项研究对检验OSPO对您的企业的商业价值有价值。当你审视各个行业开源领导者的发现时，我们希望你能在他们的旅程中看到自己，并受到启发。我们期待您的组织加入OSPO从业者的社区，为开源实践的基础做出贡献：我们如何合作，我们一起做什么，以及我们如何获得互利。

Kimberly Craven

Sr. Director, Red Hat Open Source Program Office, Office of the CTO

Kimberly Craven

首席技术官办公室，Red Hat开源项目办公室，高级主任

Leslie Hawthorn

Sr. Manager, Red Hat Open Source Program Office

Leslie Hawthorn

Red Hat开源项目办公室，高级经理

The Business Value of the OSPO


OSPOs are built to help students and researchers create and advance open source projects for widespread use	OSPOs are used to produce knowledge for social good through open access to research	OSPOs drive compliance, standardization, reputation, knowledge sharing, development speed, security, and sustainability
ACADEMIC OSPO VALUE	ACADEMIC OSPO MOTIVATION	BUSINESS OSPO VALUE
Many OSPOs start by cleaning up past ad-hoc open source efforts	The most common internal OSPO challenges include culture, education, defining and measuring success	The top KPIs that OSPOs measure include sustaining contributors and project success
MINIMUM VIABLE OSPO	OSPO CHALLENGES	OSPO MEASUREMENT
Tracking project health – including commits, maintainers, and contributor activity and diversity –is essential for sustainability	OSPOs can help to turn projects from cost centers to profit centers	The most common OSPO skill sets include counselor, facilitator, environmentalist, and advocate
OSPO MEASUREMENT	BUSINESS OSPO SUSTAINABILITY	OSPO ROLES

OSPO 的商业价值


建设 OSPO 旨在帮助学生和研究人员创建并推进开源项目，使其被广泛应用	通过开放研究，OSPO 可以用于创造社会公益知识	OSPO 推动企业的合规性、标准化、声誉、知识共享、开发效率、安全性和可持续性
OSPO 对学术的价值	OSPO 的学术动机	OSPO 对企业的价值
许多 OSPO 项目始于清理过去的临时性的开源工作	最常见的内部 OSPO 挑战包括文化、教育，以及对 OSPO 的定义和成功的度量	度量 OSPO 的首要 KPI 包括持续贡献者人数和项目成功与否
最小可行的 OSPO	OSPO 的挑战	OSPO 的度量方式
跟踪项目的健康度 – 包括代码提交者、维护者以及贡献者的活跃情况和多元性 –这对可持续发展至关重要	OSPO 可以帮助企业，将项目从成本中心转变为利润中心	最常见的 OSPO 技能分工包括顾问、推动者、环境保护者, 以及布道者
OSPO 度量方式	企业 OSPO 的可持续性	OSPO 的角色

Introduction

介绍

Why do we care about how OSPOs contribute to the business?

我们为什么关心OSPO如何为业务提供助力？

A well-designed OSPO is the center of competency for an organization’s open source operations and structure.

对一个组织的开源运营和结构来说，一个设计良好的开源项目办公室(OSPO)是核心竞争力。

Why do we need to understand how OSPOs contribute to business goals? Whether it’s to advocate for creating a new OSPO, continue funding the OSPO, or even expand the OSPO, champions will ultimately have to connect the dots between the OSPO and business objectives. Whether in a for-profit business or not-for- profit university, no initiative that can’t be connected to outcomes that matter to the organization is likely to get greenlighted in the first place, nor survive if they can’t make a business case for their existence.

为什么我们需要了解OSPO如何对业务目标提供助力？无论是为了倡导创建新的OSPO、继续为OSPO提供资金支持，还是为了扩大OSPO，支持者最终必须将OSPO与业务目标联系起来。无论是在营利性企业还是非营利性大学，如果一项提议不能与组织关心的结果联系起来，很可能首先就不会得到批准。如果不能为它们的存在提出商业理由，它们也无法生存下去。

“OSPOs as a whole need to be nimble, they need to be always ready for the next change,” said Suzanne Ambiel, director of open source marketing and strategy at VMware. “They need to adapt to the business because they’re serving the business as well as the community. As the business changes and morphs, the OSPO needs to do so as well ... It’s really important that an OSPO be very connected to the business and the business strategy.”

”整个OSPO需要保持敏捷性，始终准备着应对下一个变化“，VMware开源营销和战略主管Suzanne Ambiel表示。”他们需要适应业务，因为他们同时服务于业务和社区。随着业务的变化和发展，OSPO也需要进行相应的调整……一个OSPO与业务和业务战略紧密相连是非常重要的。“

Though OSPOs are generally—but not always—located under the chief technology officer (CTO) and include many software engineers, interest in open source and how a company relates to open source is by no means limited to the engineering department. As we found in interviewing OSPO leaders for this report, the OSPO champions in many organizations were executives who saw both opportunities and, in some cases, potential threats from open source that their companies needed to address strategically. In doing this research, we hope to better understand why open source matters strategically to companies and how OSPOs help organizations proactively manage both the opportunities and threats to their particular business from open source.

虽然OSPO通常（但并非总是）隶属于首席技术官(CTO)，并且由许多软件工程师组成，但并不是只有工程部门才对开源及公司如何与开源相关联感兴趣。正如我们在采访本报告的OSPO领导者时发现的，许多组织中的OSPO倡导者是高管，他们看到了开源带来的机会，也看到了某些情况下开源所带来的潜在威胁，他们的公司需要从战略层面解决好这些问题。通过进行这项研究，我们希望更好地理解为什么开源对公司具有战略意义，以及OSPO如何帮助组织积极管理开源给其特定业务所带来的机遇和威胁。

Hiro Fukuchi, senior alliance manager at Sony, gave an example of this executive interest: The OSPO organized a virtual event with an external expert that the company publicized, and many executives from both Japan and the United States attended.

索尼公司高级联盟经理Hiro Fukuchi举出了一个这种高管对开源有兴趣的案例：OSPO组织了一场虚拟活动，并邀请了一位外部专家参加，该公司对此进行了宣传后，来自日本和美国的许多高管都参加了这次活动。

Common threads in unique stories

独特故事中的共同线索

One of the challenges in conducting this research is that while there are certainly common threads, not only is each OSPO unique, but the stories behind their creation in the first place and how they contribute to the organization’s larger goals are also unique. So while we can certainly make some generalizations about why OSPOs matter, who tends to champion them, and how the business value of the OSPO tends to evolve, no two organizations are really alike.

进行这项研究的一个挑战是，虽然肯定存在共同的线索，但每个OSPO都是独特的，而且它们在第一次创建时的故事以及它们如何为组织的更大目标提供助力也都是独特的。因此，尽管我们肯定可以对OSPO的重要性、谁倾向于支持它们以及OSPO的业务价值如何发展做出一些概括，但真正的情况是没有两个组织是完全相同的。

“I was reading the Linux Foundation report that came out a couple of days ago, talking about the different OSPO structures,” said Christine Abernathy, senior director of open source at F5. “What I’ve learned is that they’re not all the same.” Just as OSPOs are all structured differently, there is a lot of diversity in their stated goals and the stories of how they came to be.1

“我正在阅读几天前发布的Linux基金会报告，该报告谈到了不同的OSPO结构”，F5的开源高级总监Christine Abernathy说。“我所学到的是，它们并不都是相同的。”正如OSPO结构都各不相同，它们的既定目标和它们如何成立的故事也存在很多差异。[^1]

[^1] https://www.linuxfoundation.org/research/a-deep-dive-into-open-source-program-offices

Methodology

研究方法

For this report, we interviewed 12 OSPO leaders from Europe, Asia, and North America in a variety of industries, including two public universities. All the OSPO leaders interviewed are active in the TODO group. Here are the questions we started with:

为了撰写这份报告，我们采访了来自欧洲、亚洲和北美各行各业（包括两所公立大学）的12位OSPO领导者。所有接受采访的OSPO领导者都活跃在TODO小组中。以下是我们的起始问题：

How many team members were on the OSPO at launch? How many are there now?
在启动OSPO时，团队成员有多少人？现在有多少人？
What are the rough salary ranges for team members in the OSPO?
OSPO团队成员的大致薪资范围是多少？
What background do OSPO team members come from (e.g., engineering, legal, marketing)?
OSPO团队成员是什么背景（例如：工程、法律、市场营销）？
What’s your industry?
你在什么行业？
Where is the OSPO located in the organization (e.g.,engineering, legal, marketing)?
OSPO在组织中属于哪个部门（例如：工程、法律、市场营销）？
Who was the initial champion for the OSPO?
谁是最初的OSPO倡导者？
How did the champion(s) sell the OSPO internally? What did they say the value of the OSPO would be?
倡导者如何在内部推广OSPO？他们说OSPO的价值是什么？
What outcomes or KPIs were set for the OSPO when it was initially started?
在最初启动OSPO时，设置了怎样的目标或KPI？
How has your understanding of the value of an OSPO, and the specific outcome you expect from your OSPO, changed over time?
随着时间的推移，你对OSPO的价值的理解以及你期望从OSPO获得的具体结果发生了怎样的变化？
Do you expect to get the same business value out of your OSPO in the next five years, or do you expect the value of the OSPO to change?
你是否期望在未来五年内从你的OSPO获得相同的商业价值，还是你期望OSPO的价值会发生变化？
What metrics / measurements were collected to track your progress toward those outcomes? How have these metrics changed over time?
你收集了哪些指标/测量结果来跟踪你朝着这些结果的进展？这些指标随着时间的变化发生了怎样的改变？
What KPIs does your OSPO work toward now? How do you evaluate the OSPO’s success?
你的OSPO现在正努力实现哪些KPI？你如何评估OSPO的成功？

Organization profiles and the relationship with open source

组织概况及其与开源的关系

An organization’s relationship with open source, and therefore the value that it will get from an OSPO, does seem to depend on what type of company it is. Organizations that are fundamentally technology companies—whose revenue comes from selling hardware or software—experience both different opportunities and threats from open source than organizations whose revenue comes from selling furniture.

组织与开源的关系，以及它因此将从OSPO获得的价值，似乎取决于它是什么类型的公司。本质上是技术公司的组织——其收入来自于销售硬件或软件——从开源中获得的机会和受到的威胁与收入来自于销售家具的组织有所不同。

Technology companies

技术公司

For perhaps obvious reasons, companies whose revenue comes from selling hardware or software see the most direct relationship between open source and their business, and the OSPO is a critical part of managing that relationship.

因为种种显而易见的原因，从销售硬件或软件中获得收益的公司最直接地感受到开源和它们业务之间的关系，OSPO是管理这种关系的关键部分。

“Pat Gelsinger, our CEO at the time,” said Ambiel, referring to who was one of the OSPO champions at VMware. “He’s the one who really leaned in and said, ‘We need to build an OPSO, we need to act with strategic intent.’”

“我们当时的CEO是Pat Gelsinger”，Ambiel指的是VMware的一个OSPO倡导者。“他是真正投入的人，他说，‘我们需要建立一个OSPO，我们需要根据战略意图来行动。’”

The need for technology companies to approach open source strategically is a core reason they all gave for forming an OSPO. And while there was often executive involvement, it would be wrong to characterize OSPOs as a purely top-down initiative or one pushed by management on an unwilling team of engineers. Often individual open source enthusiasts within the companies would push for a more formalized relationship with open source at the same time that executives pushed for a more strategic approach. Creating an OSPO was the obvious next step to meet both stakeholders’ needs.

技术公司需要从战略上对待开源是他们组建OSPO的核心原因。虽然经常有高管参与其中，但不能将OSPO视为纯粹的自上而下的计划，或者是一个由管理层强行推动不情愿参与的工程师形成的团队。通常，在公司内部有一些开源个人爱好者会推动更正式的开源关系，与此同时高管们则推行更具战略性的方法。创建OSPO显然是满足利益双方需求的下一步。

Open source wasn’t new at any of the companies we spoke with. They had all been using open source internally for years—and often had even open sourced internal projects in the past—but they were becoming increasingly aware of how open source developers can be part of the adoption curve for their own products, and as a result, how important a decent reputation in the open source ecosystem can be.

在我们采访的所有公司中，开源并不是什么新鲜事。它们一直在内部使用开源——并且通常甚至过去已经开源过内部项目——但它们越来越意识到，开源开发人员可以成为其产品使用曲线的一部分。因此，在开源生态系统中拥有良好的声誉非常重要。

“F5’s business has been moving from primarily hardware to software as a service,” said Abernathy. “A lot of the people who make purchasing decisions like to ‘try before they buy.’ These could be software developers who gravitate toward open source or even companies and governments who want to see your code in the open so that they can check the vulnerabilities.” So in the case of F5, open source is becoming important not just to how the company makes products but also to sales and marketing efforts. The OSPO is necessary to make sure F5 can leverage open source strategically and make informed decisions in situations where open source is relevant.

“F5的业务正在从主要的硬件转向软件即服务”，Abernathy说，“许多决定购买的人喜欢‘试用后再购买’。他们可能是倾向于开源的软件开发人员，甚至是希望在开放环境中查看代码以检查漏洞的公司和政府人员。” 因此，在F5这种情况下，开源不仅对公司的产品制造方式至关重要，也对销售和营销工作至关重要。为了确保F5能够战略性地利用开源，并在与开源相关的情况下做出明智的决策，OSPO是必要的。

Abernathy, who previously worked in the open source office at Facebook (now Meta), outlined the difference between open source at a place like Facebook and a company like F5. “At Facebook, open source is important,” she said. “But not, like, in terms of revenue. They’re not building an open source product .... So here, it’s easier to start thinking about the ROI of open source in a more direct and meaningful way.”

之前在Facebook（现在是Meta）的开源办公室工作的Abernathy概述了在Facebook和F5这样的公司中的开源之间的区别。“在Facebook，开源很重要”，她说，“但不是在收入方面。他们没有构建开源产品……所以在这里，更容易开始以更直接和有意义的方式考虑开源的投资回报。”

In the case of F5, a major trigger for creating the OSPO was the acquisition of open source company Nginx in 2019. The acquisition meant that the Nginx team both joined F5 and became another voice pushing for an OSPO, which also increased the strategic importance of open source.

在F5这种情况下，创建OSPO的一个主要诱因是在2019年收购了开源公司Nginx。这次收购意味着Nginx团队加入了F5，并成为另一个推动OSPO的声音，增加了开源的战略重要性。

For companies like Aiven, whose core business is tightly related to an open source project or projects, a formalized and strategic approach to open source is perhaps even more critical—but something they still often lack without an OSPO. Josep Prat, open source engineering director at Aiven, said that even given the strategic importance of open source, there was always tension between a need to ship product features and a need to contribute back to open source. When there was an expectation for engineers to contribute to open source in addition to all their other responsibilities, open source contributions would always take a back seat. Because of this tension, Aiven’s executive team decided very early on that there should be a dedicated OSPO whose sole job was to contribute to open source and manage the relationship with the open source communities.

对于Aiven这样核心业务与一个或多个开源项目紧密相关的公司来说，正式地、战略性地走向开源的途径可能更为关键，但通常在没有OSPO的情况下他们仍然缺少这个途径。Aiven的开源工程总监Josep Prat表示，尽管开源的战略重要性很高，但在推出产品功能和回馈开源这两个需求之间总是存在紧张关系。当期望工程师除了履行所有其他职责之外，还要为开源做出贡献时，开源贡献总是被放在次要位置。因此，Aiven的高管团队很早就决定应该有一个专门的OSPO，其唯一的工作就是为开源做出贡献，并管理与开源社区的关系。

In no way is it only open source companies or startups who feel like open source is of massive strategic importance. Chris Xie, head of open source strategy at Futurewei, the U.S.-based research and development arm of Huawei, stated that the company has been aware of both the threat and opportunities from open source for more than two decades, and the OSPO is part of how the company approaches both the threats and opportunities from open source.

并不仅仅是开源公司或初创企业认为开源具有重大战略意义。华为美国研发部门未来维（Futurewei）的开源战略负责人Chris Xie表示，20多年来，公司一直清楚开源带来的威胁和机遇，而OSPO是公司应对开源威胁和机遇的举措之一。

End user companies

终端用户公司

After the pure technology companies, there are the tech-forward companies who want to emulate many of what they see happening at pure technology companies, especially in terms of software development. These are companies that get their revenue from something other than selling hardware or software, and who wouldn’t say that building either is particularly core to their business. However, technology is critical to their business operations, and they share a desire to be perceived as a technology company as a means to attract top talent and create new revenue streams. One pattern that appears among these companies is that the OSPO and contributing to open source and releasing open source projects are all part of an effort to change the perception of the company as well as to improve the organization’s ability to deliver high-quality software, faster.

在纯技术公司之后，是那些希望效仿纯技术公司做法（尤其是在软件开发方面）的前沿技术企业。这些公司的收入不是来源于销售硬件或软件，而且他们也不会说构建硬件或软件是他们特别核心的业务。然而，技术对他们的业务运营至关重要，他们希望被视为技术公司，以吸引顶尖人才和创造新的收入来源。这些公司之间出现的一个模式是，OSPO、为开源做贡献和发布开源项目都是为改变公司形象以及提升组织能够更快地交付高质量软件的能力而做出的努力的一部分。

“Spotify has been using and creating open source since the very beginning, but at the same time, we didn’t approach it in a strategic way or consider how it created value for the company,” said Per Ploug, OSPO lead at Spotify. “It is critical for us that open source work is elevated to the same level as internal work, so we consider why we do it and how it brings value, so we ensure our engineers invest their time in projects which have impact.”

“从一开始起，Spotify就一直在使用和创建开源软件，但同时，我们并没有从战略的角度看待它，也没有考虑它如何为公司创造价值，”Spotify的OSPO负责人Per Ploug表示，“对我们来说，将开源工作提升到与内部工作同等的水平是至关重要的，因此我们会考虑为什么要这样做以及它如何带来价值，从而确保我们的工程师将时间投入到具有影响力的项目中。”

Read Spotify’s End User Journey Report as an example of how the company’s open source contributions have benefited themselves and projects they care about.

阅读Spotify的《最终用户旅程报告》，就可以了解该公司的开源贡献如何让他们自己和他们关心的项目受益。

In Spotify’s case, the most visible example of this new approach is Backstage, the company’s big bet on building a commercial offering on top of the successful open source project they donated to the CNCF in 2020. Spotify intends to make their investment into Backstage more self-sustainable and to ensure they stay engaged in the open source community long term. Right now, they have more than 40 people working on Backstage. We have very ambitious plans for Backstage, which include a commercial strategy that can both fund those ambitions and result in a better end product for everyone. The goal is to move open source from a cost center to a profit center.

在Spotify的案例中，这种新做法最显著的例子是Backstage，这是该公司在一个成功的开源项目基础上大胆建立的商业产品，而这个开源项目是由该公司在2020年捐赠给CNCF的。Spotify打算让他们对Backstage的投资更加可持续，并确保他们长期参与开源社区。目前，他们有40多人在开发Backstage。我们为Backstage制定了雄心勃勃的计划，其中包括一项商业策略，既可以为这些雄心提供资金，又能为每个人带来更好的最终产品。其目标是将开源从成本中心转变为利润中心。

“Wayfair is a tech company, and it takes the continuous work of many technologists across numerous disciplines to support our operations and growth,” said Natali Vlatko, global lead, OSPO at Wayfair. “In chats with our former CTO, I stressed that the easiest way for us to genuinely and authentically live that mindset is to build technical products. The surefire way to do that is to build open source and invest back into the open source ecosystem.”

“Wayfair是一家技术公司，需要许多不同领域的大量技术人员持续工作来支持我们的运营和增长，”Wayfair的OSPO全球负责人Natali Vlatko说，“在与我们的前任CTO交谈中，我强调过，对我们来说，真正、真实地实现这种理念的最简单方法就是构建技术产品。确保做到这一点的方法是构建开源并回馈开源生态系统。”

While becoming more tech-company-like is certainly a goal for these companies, it remains a means to an end. In some cases, the ends are clear, and it is often being able to hire the best talent as well as improve the quality of the engineering work in-house. Sometimes, though, even these companies start out believing that open source matters but are unable to articulate exactly why or how open source contributes to engineering or business objectives. The establishment of the OSPO helps them clarify how open source is already benefiting the company and determine how to get even more value from open source.

尽管变得更像技术公司肯定是这些公司的目标，但它仍然是达到目的的手段。在某些情况下，目的是明确的，通常是为了能够聘请最好的人才以及提高内部工程工作的质量。但有时，即使这些公司开始相信开源很重要，却无法清楚地阐明开源为什么会或如何为工程或业务目标提供助力。OSPO的建立有助于他们澄清开源是如何使公司受益的，并确定如何从开源中获得更多价值。

“They had a couple of open source projects that didn’t go anywhere,” said Duane O’Brien, director of open source at Indeed, about what was going on at the company before he joined. No one thought they were massive successes. “I don’t think they had a clear picture of what success meant for themselves,” he said.

“他们有一些开源项目没有得到推广，”Indeed的开源主管Duane O’Brien提到他加入之前公司的情况时说。没有人认为它们是非常成功的项目。他说：“我认为他们对自己的成功没有清晰的认识。”

Universities

大学

For universities, the value of open source and the related value of an OSPO to oversee the relationship between open source and researchers at the university is different from for-profit companies. However, they often see open source as a way to further the university’s mission—an opportunity that until very recently was largely missed. “They don’t really have a history of being engaged in open source,” said Carlos Maltzahn, director of the Center for Research in Open Source Software at the University of California Santa Cruz. As a matter of fact, he said, while there have been successful open source projects that have originated at a university, in many cases, it’s been a personal project of an individual student or researcher because most universities have little to no support for turning research products into high-impact open source contributions. That’s something he’d like to change and sees the OSPO as a way to support students and researchers who create open source projects and help more projects cross the chasm from a graduate student research project to something used in the wider ecosystem.

对于大学而言，开源的价值和OSPO管理开源和大学研究人员之间关系的相关价值与营利性公司不同。然而，他们通常把开源看作是进一步推进大学使命的一种方式——这是直到最近才被广泛认识到的机遇。“他们真的没有参与开源的历史”，加利福尼亚大学圣克鲁兹分校开源软件研究中心的主任Carlos Maltzahn说。事实上，他说，虽然有一些成功的开源项目起源于大学，但在许多情况下，这是学生或研究人员的个人项目，因为大多数大学几乎没有任何资源支持可以把研究成果转化为具有重大影响力的开源贡献。他希望改变这种情况，他将OSPO视为支持创建开源项目的学生和研究人员的方式，以帮助更多项目跨越鸿沟，从研究生的研究项目到更广泛的生态系统中的应用。

For Jesus Gonzalez-Barahona, professor at Universidad Rey Juan Carlos in Madrid and head of their open knowledge efforts, open source fits into the larger mission related to expanding access to knowledge. “In all of Europe, especially in Spain, universities are rediscovering this idea that we need to produce knowledge for society,” he said. Open source software, but also open access to research, is a way to fulfill this mission.

对于作为马德里的胡安·卡洛斯国王大学的教授和他们开放知识项目负责人的Jesus Gonzalez-Barahona而言，开源符合与扩大知识获取途径相关的更大使命。他说:“在整个欧洲，特别是在西班牙，大学正在重新发现我们需要为社会生产知识的这个想法。” 开源软件，以及研究的开放获取，是实现这一使命的方式。

What can OSPOs do for organizations?

OSPO 可以为企业提供什么？

The reasons behind starting an OSPO

启动 OSPO 项目的理由与动机

As we look at the value that an OSPO provides, there are two distinct phases. The first phase is the reason behind the OSPO’s creation. The second phase relates to the value that the organization sees as the OSPO matures. In this section, we will address the reasons organizations had for starting the OSPO in the first place and address how the value evolves in a later section. In nearly all cases, there were multiple reasons for starting an OSPO, just as there are multiple reasons for maintaining and expanding the OSPO as it matures. While there can be educational and social reasons for starting and maintaining an OSPO, this report focuses primarily on the business-related reasons behind having an OSPO, as we have focused the research primarily on for-profit organizations.

我们可以从两个不同的阶段，来审视OSPO所带来的价值，第一阶段是成立OSPO项目的原因，第二阶段是在OSPO成熟时，企业所看到的价值。在本节中，我们将首先讨论组织机构启动OSPO的原因，并在后面的部分中讨论价值如何演变。在多数情况下，启动OSPO的原因很复杂，正如随着OSPO成熟时，维持和扩展OSPO有多种原因一样。虽然启动和维护OSPO项目可能有教育和社会的原因，但本报告主要关注拥有OSPO项目背后的商业相关因素，因为我们的研究主要集中在营利性组织上。

Compliance

合规性

The most fundamental reason that organizations start an OSPO is because they are aware that their engineers are using open source, but they don’t know if they’re complying with the projects’ licenses. “Open source is unavoidable,” said Cornelius Schumacher, open source steward at DB Systel, the digital partner of Deutsche Bahn.

组织启动OSPO的最根本原因，是因为他们知道自己的工程师正在使用开源，但不确定他们是否遵守了项目的许可规则。 “开源是不可避免的，”德国铁路（Deutsche Bahn）数字合作伙伴DB Systel的开源项目管理员Cornelius Schumacher说。

“Open source is unavoidable”

“开源是不可避免的”

Given this reality, DB Systel needed to make an organized, centralized effort to ensure that the company complied with open source license requirements as well as managed potential security issues. “Risk management was not the only reason [for creating the OSPO], but certainly an important part of the decision,” he said. Because new open source projects are being downloaded and used every day, especially in a large organization, the OSPO’s role is less about conducting a compliance audit and more about putting technology and processes in place to ensure developers are aware of which licenses are or are not acceptable so that it’s easier to conduct compliance audits when necessary.

鉴于这一事实，DB Systel需要进行有组织的集中努力，以确保公司遵守开源许可要求，并管理潜在的安全问题。 “风险管理不是（创建 OSPO）的唯一原因，但肯定是决策的重要组成部分，”他说。由于每天都有下载和使用新的开源项目，特别是在大型组织中，OSPO的作用与其说是进行合规性审查，不如说是实施技术和流程，以确保开发人员了解哪些许可证可以接受，哪些不可接受，以便在必要时更容易进行合规审查。

Building standardized processes around open source

围绕开源构建标准化流程

Related to the compliance issue, there was often also a need to move from an ad hoc way of using open source projects to a more standardized process. “Right now we have too much sprawl across our open source dependencies,” Ploug said. Part of the rationale for creating the OSPO was to streamline those dependencies to avoid having multiple projects that accomplish the same things.

与合规性问题相关，通常还需要从使用开源项目的临时方式转变为更标准化的流程。Ploug说：“现在我们的开源项目依赖规模过于庞大。” 创建OSPO的一部分原因是要简化这些依赖关系，以避免有多个项目执行相同的事情。

“Right now we have too much sprawl across our open source dependencies”

“现在我们的开源依赖规模过于庞大”

This would make many aspects of open source management easier, from license compliance auditing to security to investing strategically in open source projects that are important to the company’s core process.

这使开源项目管理在许多方面变得更加容易，从许可证的合规性审计到安全性，再到对公司核心流程至关重要的开源项目进行战略性投资。

In addition to building standardized processes around how engineers can use open source, there’s also a need to create standard processes about how engineers can contribute to open source projects or even create their own projects. In many organizations, these decisions had previously been made between an individual engineer and their manager, the result of which is a blend of approaches and a lack of certainty about what is acceptable.

除了围绕工程师如何使用开源项目以构建标准化流程之外，还需要创建标准流程，规范工程师如何为开源项目做出贡献甚至创建自己的项目。在许多组织中，以前只是由个别工程师和他们的经理之间做出决定就行，其结果是各种方法的混合，不确定最终会出现什么样的结果，以及这个结果是否可以接受。

Often part of an OSPO’s initial mandate is to create policies about both consuming and contributing to open source that are distributed throughout the engineering organization. The goal is to eliminate bottlenecks and confusion for engineers both in using and contributing back to open source.

OSPO的初始任务的一部分，通常是制定关于使用和贡献开源的政策，这些政策贯穿于整个工程团队中。其目标是消除工程师在使用和贡献开源方面的瓶颈和困惑。

Improving an organization’s reputation

提升组织的声誉

Improving an organization’s reputation in the open source ecosystem is an important motivator for many companies to create an OSPO.

提升组织在开源生态系统中的声誉是许多公司创建OSPO的重要动力。

“Our goal was to not only be more strategic and act with intent but also to elevate our reputation in the open source community— to be perceived as and accepted as a responsible, positive contributor to the open source ecosystem,” said Ambiel, of VMware.

“我们的目标不仅是让公司更具战略性，有目的地采取行动，还要提升我们在开源社区中的声誉，努力成为为开源生态系统负责任的、积极的贡献者。”VMware 的Ambiel说。

This is particularly important because if a company shows up to a project without any kind of pre-existing relationship and suddenly needs a new feature, or a bug fixed, that request won’t likely be a priority. Whereas if the company has been consistently investing in being part of the community, when they need something, the community may be more likely to prioritize it.

这一点尤其重要，因为如果一家公司之前没有参与过某个开源项目，就贸然使用它，并且突然需要一个新功能或修复一个bug，那么该请求可能不会作为开源项目的优先事项。然而如果公司一直致力于成为该社区的一部分，那么当他们需要某些东西时，社区就可能会优先考虑。

“We need to employ people who have commit rights,” said Prat, of Aiven, referring to commit rights on the projects Aiven is built around. The only way to get that is through continual investment in the project, which is why Aiven created an OSPO to ensure the company, and the individuals it employs, are active in the community.

Aiven的Prat说：“我们需要雇用拥有提交权限的人”。他指的是围绕Aiven的项目的提交权。实现这一目标的唯一方法是通过对该项目的持续投资，这就是Aiven创建OSPO的原因，以确保公司及其雇用的个人在社区中活跃。

An OSPO is also a way to share knowledge about how to approach open source. To even be part of the conversation about what it means to use open source strategically, a company probably needs to establish an OSPO. According to Fukuchi, this knowledge sharing is a big part of the value Sony gets from its OSPO.

OSPO也是一种分享如何使用开源知识的方式。关于战略性地使用开源意味着什么，一家公司想要参与这类话题的讨论，需要建立自己的OSPO。根据Fukuchi的说法，这种知识共享的方式，是索尼从OSPO获得的价值的重要组成部分。

Who starts the OSPOs?

谁启动了OSPO项目

While we associate open source with a grassroots effort from individual engineers, the overwhelming trend in the interviews was the support for OSPOs at the executive level. In the case of large technology companies, like VMware and Futurewei, the OSPO champion was the CEO. “The CEO realized, oh, open source is not just about technology,” said Xie, from Futurewei. “It is about business. So they had open source moved into the Chief Strategy Office, which is where we’re now.”

Even in more grassroots initiatives, high-level buy-in is common. “I went to our former CTO with that idea myself,” said Vlatko, of Wayfair. “He was very supportive and said, ‘Yes, go ahead’ but also was very realistic in the sense of I cannot guide you, I’m not an expert. And I said, ‘That’s okay. I’m the expert.’” The obvious takeaway is that in many companies, a strategic relationship with open source is a high-level business concern, not just a technical problem that a group of engineers should solve.

虽然我们将开源项目与个别工程师的基层努力联系在一起，但采访中的一个重要趋势是管理层对OSPO的支持。如对VMware和Futurewei等大型科技公司而言，OSPO的冠军是CEO。 “CEO 意识到，开源不仅仅与技术有关，”来自Futurewei的Xie说。 “这是关于商业的。因此他们将开源的管理转移到首席战略办公室，这就是我们现在所在的部门。” 即使在较为基层的倡议中，高层的支持也很常见。 Wayfair的Vlatko说：“我亲自向我们的前任首席技术官提出了这个想法” 。他非常支持并说，“好的，请继续吧，但现实是我不能指导你，因为我不是专家。" 我说：“没关系，我是专家”。显而易见的是，在许多公司里，与开源的战略关系是一个高级业务问题，而不仅仅是一组工程师应该解决的技术问题。

Improving an organization’s reputation is ultimately about being able to work productively with others in the industry as well as being part of the conversation about the direction of key projects. “Growing our reputation allows us to be in larger market conversations in the tech world, where we can then have an impact on products and solutions that are important to us,” said Vlatko, of Wayfair.

提高组织的声誉，最终是为了能够与业内其他人进行富有成效的合作，并成为关于关键项目方向的对话的参与者。Wayfair的Vlatko说：“不断提高我们的声誉，使我们能够在科技界参与更大规模的市场对话，这会对我们的重要的产品和解决方案产生影响。”

Expanding access to open knowledge

扩大对开放知识的访问与获取

For universities, an OSPO is a way to increase the impact of research and make it more accessible or useful to the wider community, as well as a way to improve students’ access to knowledge.

对于大学来说，OSPO是一种增加研究影响力的方式，使其更容易被广泛的社区所接受或使用，也是方便学生获取知识的一种方式。

“If you have students engaged with reproducing the results, there have already been studies that show that there is a huge, much better learning effect compared to just reading papers.”

“已经有研究表明，相比于仅仅阅读论文，让学生参与研究重现结果，学习效果要好得多。”

“It’s a huge difference whether a student can just read a paper, or they can look at the paper, then go on to an associated public git repository and have all the information there to reproduce the experiment,” said Maltzahn, of UC Santa Cruz. “If you have students engaged with reproducing the results, there have already been studies that show that there is a huge, much better learning effect compared to just reading papers.” This is important for student retention. Many students leave computer science prematurely because they get too frustrated by the steep learning curve of getting brittle experimental systems to work in computing environments even experts don’t fully understand. Incorporating the practicality of open source into how students learn and reducing the frustration they experience can help them be successful with computer science in the short term and software development in the long term.

加州大学圣克鲁斯分校的Maltzahn说：“相对于只让学生阅读一篇论文来说，如果不仅可以查看论文，还可以访问相关的公共git代码库，在那里获得更多信息来重现实验，这两种方式的结果差异很大” 。 “已经有研究表明，与仅仅阅读论文相比，让学生参与重现结果，学习效果要好得多”。这对于留住学生很重要。许多学生过早地离开了计算机科学，因为他们对陡峭的学习曲线感到非常沮丧，因为要在脆弱的实验环境中工作，而有时候这些环境连专家都不能完全理解。将开源的实用性融入学生的学习方式，减少他们的挫败感，可以帮助他们在短期内获得学习计算机科学的成功，在长期内获得软件开发的成功。

Improving development velocity

加快开发的速度

No one starts building a product by creating an operating system—nothing would ever get built.

没有人构建产品的第一步是创建操作系统，这样的话什么都做不出来。

“There are parts of our products that consist almost entirely of open source software, and that is a fundamental change in the long history of Ericsson,” said Georg Kunz, open source manager at Ericsson.

爱立信开源经理Georg Kunz说：“我们一些产品几乎完全由开源软件组成，这是爱立信悠久历史中的一个根本性变化。”

Not only does an OSPO bring order to how the company is consuming open source projects, but it can also provide guidance about which projects to use.

OSPO不仅可以规范公司使用开源项目的行为秩序，还会提供使用哪些项目的相关指导意见。

Improve access to talent

改善获取人才的渠道

There are two ways that open source improves access to talent. The most obvious way is by allowing organizations to hire higher caliber engineers, either by improving their general reputation in the open source world or even by creating their own open source projects and hiring from the pool of people who become active in those projects’ communities. “My boss and executive sponsor want to know that we have a healthy relationship with the open source community because we need to hire from it,” said O’Brien, of Indeed.

开源提供两种方式以改善企业对人才的获取。最显而易见的方式是，让企业雇用更高水平的工程师，比如提升企业在开源世界的声誉，或企业自己创建开源项目，从项目社区的活跃人群中招聘。Indeed的O'Brien说：“我的老板和公司赞助商，他们想知道我们与开源社区有着健康的关系，因为我们需要从中招聘人才” 。

“One of the biggest challenges we have— like other IT companies—is finding people to do all the software work”

“与其他IT公司一样，我们面临的最大挑战之一，是寻找人员来完成所有软件工作”

The other way an OSPO, and the strategic approach to open source that comes with it, can improve access to talent is by creating open source projects that solve an organization’s problems, particularly when solving problems that are common in many organizations, and solving them doesn’t provide any competitive advantage. “One of the biggest challenges we have—like other IT companies— is finding people to do all the software work,” said Schumacher, of DB Systel. If the company can create an open source project and collaborate with others in the industry, it can leverage tech talent without having to hire more people.

OSPO以及随之而来的开源战略方法为改善获取人才提供了另一种方式，创建开源项目来解决企业的问题，尤其是解决许多企业中常见的问题，解决这些问题并不会提供任何竞争优势。“与其他IT公司一样，我们面临的最大挑战之一，是寻找人员来完成所有软件工作，” DB Systel的Schumacher说。如果公司可以创建一个开源项目并与业内其他企业合作，就可以共享技术人才而无需雇用更多的人。

According to Schumacher, encouraging engineers to both use and contribute to open source is also one way to make them happy and less likely to leave. Similarly, encouraging more engineers to create open source projects and do more work in the open is a way to upskill the workforce you already have.

根据Schumacher的说法，鼓励工程师使用开源，并为开源做出贡献，也是让他们开心并不太可能离开公司的一种方式。同样，鼓励更多工程师创建开源项目并在开放环境中做更多工作，也是提高现有员工技能的一种方式。

“If we are showing our code externally, if we’re showing our technical prowess externally, there is a certain kind of element of needing to put your best foot forward,” said Vlatko, of Wayfair. She says that as Wayfair has encouraged people to work more in the open, they’ve seen code quality and general adherence to best practices improve.

Wayfair的Vlatko说：“如果我们向外展示我们的代码，向外展示我们的技术实力，那么就需要全力以赴。” 她说，由于Wayfair鼓励人们更多地参与开源工作，他们已经看到代码质量有所提高，也开始普遍遵守最佳实践原则。

Mitigating risks

降低风险

There are different risks from open source, and a formal OSPO can help mitigate all of them. One reason to formalize the OSPO structure is that one or two engineers are fulfilling an OSPO-like role but without the title or structure. This is what happened at Ericsson. “We basically had a one-person OSPO,” said Kunz. “He took care of everything, mostly focused on compliance, as many OSPOs start out doing. But obviously, that’s not sustainable. This guy should not get run over by a bus.”

开源会面临对不同的风险，正式的OSPO可以帮助降低这些风险。将OSPO组织结构正式化的原因之一是，一两个工程师正在履行类似OSPO的角色，但没有头衔或组织架构。这就是在爱立信发生的事情。“我们基本上只有一个人的OSPO，”Kunz 说。 “他负责一切，主要关注合规性，正如许多OSPO刚开始做的那样。但显然，这是不可持续的，万一这家伙被公共汽车撞倒了呢？”

Creating the OSPO formalizes what has often happened in an ad hoc way, reducing the reliance on tribal knowledge and lowering the risk that the departure of a single critical person could put the company at risk of legal issues, security incidents, or just being left out of the open source conversation.

创建OSPO以一种特别的方式，将经常发生的事情正式化了，减少了对部落知识的依赖，并降低了单个关键人物的离职使公司面临的法律问题、安全事件或被开源对话排除在外的风险。

Security

安全性

Ensuring a company is staying as secure as possible—and particularly understanding the software bill of materials going into both internal and external applications—was a recurrent theme about how the OSPO provides value.

确保公司尽可能保持安全，尤其是了解进入公司内部和外部的应用程序的软件材料清单，是关于OSPO如何提供价值的一个反复出现的主题。

“We cannot develop our own security framework without being in tune with what’s being developed collaboratively in the community”

“如果不与社区中协作开发的内容保持一致，我们就无法开发出自己的安全框架”

However, the examples were on a strategic, rather than strict implementation, level. “We cannot develop our own security framework without being in tune with what’s being developed collaboratively in the community,” said O’Brien, from Indeed. “Then you take that, and you apply that across every domain.”

然而，这些例子是在战略层面，而不是严格的实施层面。 “如果不与社区中协作开发的内容保持一致，我们就无法开发出自己的安全框架，”来自Indeed的 O'Brien 说。 “然后你会把它应用到每个领域。”

“By design, it’s a distributed problem,” said Kunz, of Ericsson, about software supply chain security. “It’s not the best engineer who will solve this problem, and you can’t solve this problem with an internal process.” It’s something that requires working with others throughout the industry and the open source ecosystem. An OSPO gives organizations a way to do that, even if the OSPO is not ultimately responsible for implementing security processes. They do share best practices and facilitate collaboration among open source communities, industry actors, foundations, and other stakeholders to lift all security boats.

爱立信的Kunz在谈到软件供应链安全时说：“从设计上讲，这是一个分布式问题”。 “不是由最好的工程师来解决这个问题，也无法通过内部流程来解决这个问题。”这需要与整个行业和开源生态系统中的其他人合作。OSPO为组织提供了一种方法来解决这一问题，即使OSPO最终并不负责实施安全流程。OSPO组织可以分享最佳实践，并促进开源社区、行业参与者、基金会和其他利益相关者之间的协作，以提升所有的安全性。

Security is also a reason why organizations want to be involved and respected community members in projects that are strategically important to them. This allows them to be part of the behind-the-scenes conversations not only about any new features in the pipeline but also to learn about any potential security issues first.

安全性也是组织希望参与，并尊重社区成员参与对其具有战略意义的项目的原因之一。这使他们能够参与幕后对话，不仅涉及协作中的任何新功能，而且还可以提前了解任何潜在的安全问题。

Who’s in the OSPO?

OSPO 成员

The majority of OSPO leaders we spoke to had a software engineering background, but the work most of them do on a day-to-day basis is often not related to writing code. Instead, there are elements of internal communication, strategic planning, analysis, event planning, and collaboration with external organizations, which include open source communities, foundations, and other industry peers.

我们采访过的大多数OSPO领导者都有软件工程背景，但他们中的大多数人的日常工作通常与编写代码无关。取而代之的是内部沟通、战略规划、分析、活动规划以及与外部组织的合作，包括开源社区、基金会和其他行业同行。

In most cases, OSPO team members, and especially OSPO leaders, were senior engineers or at the management level. In companies with very structured salary bands, the OSPO leadership and team members would be toward the top of the salary ladder.

在大多数情况下，OSPO团队成员，尤其是OSPO领导人，都是高级工程师或管理层。在薪资范围非常结构化的公司中，OSPO领导层和团队成员将处于薪资阶梯的顶端。考虑到OSPO启动时，对许多组织来说，遵守法律是非常重要的，但值得注意的是，大多数OSPO都可以获得OSPO内部或外部的法律专业知识。没有一个受访者认为，应该扩大法律的作用，或者他们需要额外的法律专业知识。

Given the importance of legal compliance for many organizations when the OSPO starts, it is notable that most OSPOs had access to legal expertise, either inside or outside the OSPO. However, none of the interviewees felt that there should be an expansion of the role of legal or that they needed additional legal expertise.

鉴于许多组织在开设开源计划办公室（OSPO）时對法律合规的重要性，值得注意的是大部分OSPO都能够获得法律专业知识，无论是OSPO内部还是外部。然而，采访对象中没有人认为需要扩大法律角色或获得额外的法律专业知识。

Sustainability

可持续性

Sometimes open source projects are abandoned, and that can be bad if you depend on them. “If we have a strong dependency on a single maintainer in Norway, then you should probably do something about the relationship with that person to make sure they stay engaged, either by ensuring that our developers spend time on the projects or by sending some money,” said Ploug, of Spotify. An OSPO both helps identify the risk—otherwise, the fact that it is a single maintainer could be unknown—and identify the best way to mitigate that risk.

开源项目有时也会被放弃，如果你依赖它们，那可能会很糟糕。”Spotify的Ploug说：“如果我们非常依赖挪威的某个项目维护人员，那么可能需要维持与他的关系，以确保他的参与，要么让我们的开发人员花时间维护项目，要么寄钱给他。OSPO既有助于识别风险（比如，你可能都不知道某个项目只有一个人维护）——也能识别减轻该风险的最佳方法。

This precise issue is what led O’Brien, at Indeed, to create the FOSS contributor fund, which is a way for Indeed to financially support maintainers of projects it depends on. The program’s goal is to support maintainers who are at high risk of burnout as a way to mitigate the risk that the project will end up abandoned.

正是这个问题，促使Indeed的O’Brien创建了FOSS 贡献者基金，这是Indeed为其所依赖项目的维护者提供财务支持的一种方式。该计划的目标是支持那些极有可能精疲力竭的项目维护人员，以减少项目最终被放弃的风险。

The OSPO journey

OSPO之旅

The first step for many OSPOs, before they can begin to address more strategic concerns, is what many OSPO leaders described as cleaning up the mess of open source, recovering from years of ad hoc approaches to consuming and contributing to open source.

许多OSPO在解决更战略性的问题之前，第一步是清理开源混乱局面，纠正多年来随意使用开源和为开源做贡献的方式，这是许多OSPO领导者所描述的问题。

“We’ve had 10 years of publishing projects without a longer-term plan or formalized ownership,” said Ploug, of Spotify. The OSPO is currently going through all the projects that the company has created, figuring out who owns them—and making sure that ownership is assigned to a team, not an individual. There is also a process of determining which projects can be shut down, which requires confirming that there is no internal use.

“10年来，我们一直在发布项目，但却没有更长期的计划或正式的所有权”，Spotify的Ploug说。OSPO目前正在审查公司创建的所有项目，弄清楚谁拥有它们——确保所有权归属于一个团队，而不是个人。还有一个确定哪些项目可以关闭的流程，这需要确认内部没有在使用这些项目。

Other work that OSPOs often tackle initially is finite and can, at some point, be finished, such as the initial question about which licenses can or cannot be used. Usually, the OSPO can work with the legal team to figure out what is or is not acceptable, but once there is a decision, it doesn’t need revisiting and becomes a matter of communicating to the entire organization what licenses are acceptable in which scenarios.

OSPO最初经常处理的其他工作是有限的，某些情况下可以处理好一些初始问题，比如哪些许可证可以使用、哪些不行。通常，OSPO可以与法务团队合作，确定哪些是可接受的、哪些不是，而一旦做出决定，就不需要再次讨论，而是变成了一个与整个组织沟通的问题，即在哪些场景中可以接受哪些许可证。

But what do organizations do once they have already organized their internal projects, developed frameworks for how to use and contribute to open source, and sufficiently addressed compliance?

但是，当组织已经组织好了其内部项目，制定了如何使用开源和为开源做贡献的框架，并能充分解决合规问题时，它们该做什么呢？

Overcoming internal obstacles: Culture and education

克服内部障碍：文化和教育

Once an OSPO has developed policies around using and contributing to open source, a common next step is to spread the word internally. This is not a trivial consideration, especially given that many OSPOs are only a handful of people in an organization with thousands or even tens of thousands of engineers. This internal communication role of the OSPO also goes back to one trigger for creating the OSPO in the first place: a large number of queries coming from software engineers about how to relate to open source.

一旦一个OSPO制定了关于使用开源和为开源做贡献的政策，通常要做的下一步是在内部传播这个信息。这不是容易考虑的事，特别是在许多OSPO只有寥寥数人而他们所处的组织有数千甚至数万名工程师的情况下。OSPO的这种内部沟通角色也可以追溯到最初创建OSPO的一个诱因：来自软件工程师关于如何了解开源的大量咨询。

“When we are talking about contributing to open source software, in the beginning, the question we started with was, ‘are we even allowed to do that?’” said Schumacher, from DB Systel. People just did not know what parameters there were about using, and especially around contributing back to, open source. If one of the first-level goals of an OSPO is to figure out what those parameters are, the secondary goal is to make sure that there is a dissemination of knowledge throughout the organization.

“当我们谈论为开源软件做贡献时，一开始我们要解决的问题是：‘我们是否被允许这样做？’”来自DB Systel的Schumacher说。人们不知道使用开源软件的规范是什么，特别是关于向开源软件做贡献的规范。如果OSPO的第一层目标是确定这些规范，那么第二层目标就是确保在整个组织中传播这些知识。

According to Vlatko, from Wayfair, after setting up an organizational structure in GitHub and figuring out the license types that were acceptable for use, there was an educational campaign to ensure that information was widely known across the organization.

据Wayfair的Vlatko所说，他们在GitHub上设置组织结构并确定了可接受使用的许可证类型后，进行了一项教育活动，以确保该信息在组织内得到广泛传播。

But aside from preemptively answering engineers’ questions about interacting with open source, there is an even larger shift in how people think about open source. “The question has changed a bit from whether or not to do open source to how to do open source strategically,” said Schumacher. “What I’m seeing now, after some time, is that we are looking more into the strategic part of how you can leverage open source, for example, in collaborations with external companies.”

但是除了预先回答工程师有关与开源互动的问题之外，人们对开源的看法发生了更大的变化。“问题已经从是否做开源转变为如何战略性地做开源”，Schumacher说，“在一段时间后，我现在看到的是我们正在更深入地研究如何战略性地利用开源，例如与外部公司合作。”

Even though open source is everywhere, not all organizations have the culture around open source that they want, and opinions about open source are far from universally positive. Some people, from individual contributors to managers and executives, have had bad experiences with open source software or open source communities at some point in their careers, and convincing those people to embrace open source is part of the OSPO’s challenge.

尽管开源无处不在，但并非所有组织都拥有他们想要的开源文化，对于开源的看法也远非普遍积极。有些人，无论是个人贡献者、经理还是高管，在职业生涯的某个阶段都曾经历过与开源软件或开源社区相关的负面经历，说服这些人拥抱开源是OSPO面临的挑战之一。

“We want to create a cultural mind shift and grow the community around open source,” said Abernathy, at F5. This will be a major driver in helping the company play a larger role in the open source ecosystem. In a real sense, OSPOs seek to improve open source’s reputation within the organization just as much as the organization’s reputation within the open source ecosystem.

“我们希望促进文化思维的转变并扩大开源社区”，F5公司的Abernathy说。这将成为帮助公司在开源生态系统中发挥更大作用的重要驱动力。从实质上讲，OSPO试图提升开源在组织内部的声誉，这跟提升组织在开源生态系统内部的声誉一样重要。

A strategic relationship with open source

与开源的战略关系

There is no doubt that the strategic importance of open source varies depending on the type of company. For a company like Futurewei, open source alternatives to the “black box” solutions it sells are a fundamental threat to the company’s ability to generate revenue. “And how you deal with this as a business, not a technology decision,” said Xie.

毫无疑问，开源的战略重要性因公司类型而异。对于像Futurewei这样的公司来说，开源解决方案可以代替其销售的“黑盒”解决方案，这是一个根本性的威胁，可能影响其创收能力。“怎样解决这个问题是一项商业决策，而不是技术决策”，谢先生说。

In a similar vein, VMware’s Ambiel stated, “At the end of the day, what does VMware do? We sell software. So, our open source investments need to align with our business aspirations.” The OSPO is there to make sure that happens.

同样的，VMware的Ambiel表示，“归根结底，VMware是做什么的？我们销售软件。因此，我们的开源投资需要与我们的业务愿景保持一致。” OSPO的作用就是确保这一点。

At Spotify, there’s an ambition to spin out the company’s two most successful open source projects into separate business units that will launch commercial products based on the projects, turning the project from a cost center to a profit center. Part of the OSPO’s role at Spotify is to help identify and launch new projects that could potentially become new business units and support them in a way that increases the likelihood of success. THE BUSINESS VALUE OF THE OSPO 17

在Spotify，他们希望将公司最成功的两个开源项目分拆成单独的业务单元，基于这些项目推出商业产品，将项目从成本中心变成利润中心。OSPO在Spotify的角色之一是帮助识别和推出可能成为新业务单元的新项目，并以增加成功可能性的方式支持它们。

The different hats of an OSPO

开源办公室的不同角色

The Counselor

顾问

Sometimes a strategic approach just means stepping back and taking the time to think through some of the hard questions about what type of engagement model is right for any particular project or how involved the organization should be in each project. There is also the question of when it makes sense to contribute to an existing project versus creating a new project. An OSPO that is having these strategy-level conversations will be able to provide guidelines to engineers so that engineers do not have to consider the business implications of different open source engagement models every time they try to solve a problem.

战略方法有时候仅仅意味着后退一步，花时间思考那些关于特定项目哪种参与模式是对的或者组织应该在每个项目中参与到什么程度等困难的问题。这在考虑是向已经存在的项目贡献还是新建一个项目时也是一个问题。有战略层对话的开源办公室能够为工程师提供指点，以便工程师每次尝试解决问题时不需考虑不同开源参与模式对业务的影响。

The Facilitator

促进者

The OSPO also plays a sort of translation role between engineering teams and business interests regarding open source. “How do we ensure that engineers keep having the time to do this, that they can actually prove that it makes sense from a business perspective?” said Abernathy, about how communicating the business value of open source is part of the OSPO’s job at F5. These strategic questions are not always top of mind when the OSPO is first created, especially at less tech-focused companies where open source doesn’t present a direct threat to revenue. But even those companies eventually see that using open source well is about more than mitigating license compliance risk. “Now we are also looking into more cases where it makes sense from a strategic point of view to leverage open source for our own projects or in collaborations with other parties,” said Schumacher, even though he does not think these strategic concerns were as important when the OSPO was initially set up.

开源办公室还在开源相关的工程团队和业务利益之间扮演着一种翻译角色。“我们怎么确保工程师有足够的时间做这些，他们实际上可以从商业的角度证明好处是什么” Abernathy说，如何传达开源的商业价值是 F5 开源办公室工作的一部分。这些开源战略问题并不总是在开源办公室创建时就要考虑的首要问题，特别是开源对收入没有直接威胁的技术不是重心的公司。但是，即使是这些公司最终也会看到良好地使用开源也不仅仅是为了缓和许可证合规风险。“现在我们在更多的情况下研究利用开源为我们自己的项目或者与他方合作的战略意义。” Schumacher 说，即使他不认为这些战略考虑在设立开源办公室时就很重要。

Ensuring OSPO sustainability

确保开源办公室的可持续性

Continuity is an ongoing challenge for organizations as they adapt to changes in the business, the competitive landscape, and the larger technological ecosystem. According to “A Deep Dive on OSPOs,” a Linux Foundation whitepaper, OSPOs need to establish a clear, easy reporting process and ensure lines of communication stay open with all the stakeholders. This is important for maintaining internal support for the OSPO, which is critical to ensuring that the organization continues to follow its agreed-upon open source strategy and is able to work sustainability on open source projects and priorities.¹

连续性对组织来说是持续的挑战，因为它们要适应业务，竞争环境和更大的技术生态。根据 Linux 基金会的白皮书《深入开源办公室》，开源办公室需要建立清晰、简单的汇报流程，并确保与所有利益相关方保持沟通渠道畅通。维护开源办公室内部支持对于确保组织继续按照其商定的开源战略和能够在开源项目和优先事项上至关重要。¹

Measuring an OSPO’s success

衡量 OSPO 的成功

“When I interviewed for this role, I asked how we’re going to measure success,” Prat said. “They said ‘we don’t know yet.’”

“在我面试这个职位时，我问到我们如何衡量成功”，Prat 说，“他们说‘我们还不知道。’”

This pattern of uncertainty came up often in interviews—that an executive leader championed an OSPO with the understanding that open source is important and that the company needed to take practical, tactical steps to ensure compliance and security, while also figuring out how to engage strategically along the way. In many cases, they did not really know what that looked like, and part of the OSPO’s initial mandate was to figure out what success would look like and how to measure their own progress.

这种不确定的状况在访谈中经常出现 —— 一位高层领导支持 OSPO 并且明白，开源很重要，公司需要采取切实可行的战术行动来确保合规性和安全性，同时也要弄清楚如何在这一过程中进行战略性的参与。在许多情况下，他们真的不知道成功是什么样的，而 OSPO 最初的任务之一是弄清楚成功时的样子以及如何衡量自己的进展。

There were some metrics interviewees talked about using to measure engagement with open source but then ultimately rejected. Pull requests (PRs), for example, are too diverse to provide meaningful information—a PR could be a typo fix or a major feature. Measuring hours worked on open source also did not seem right because it does not measure impact.

受访者提到了一些衡量开源参与度的指标，但最终没有采纳。例如，提交请求（PR）多种多样，无法提供有意义的信息 —— 一个PR可能是一个拼写错误修复或主要功能。衡量开源工作时间似乎也不正确，因为它不能衡量影响。

Deciding what to measure is fairly high-stakes and strategic, part of why the OSPO leaders themselves took on the task of figuring it out. Human nature is to optimize for the things we know we’re being evaluated on, and interviewees talked about the importance of choosing metrics that will encourage engineers throughout the organization to be better open source citizens. Often the metrics applied initially changed as the OSPO matured. For example, at Indeed, there was an initial focus on growing contributors and measuring how many people make open source contributions in any given quarter. After a while, however, they started focusing on growing what they called “sustaining contributors,” who are people that make repeated contributions to the same project—to projects that are strategically important to Indeed. This is because it is easier for maintainers to get five contributions from one person than five contributions from five people, and the larger goal is to make things easier for maintainers.

决定衡量什么是相当高风险的和战略性的，这也是 OSPO 领导者自己承担这项任务的原因之一。人类的本性是针对我们所知道的正在评估的东西进行优化，受访者谈到了选择指标的重要性，这些指标将鼓励整个组织的工程师成为更好的开源世界公民。通常，最初应用的指标会随着 OSPO 的成熟而发生变化。例如，在 Indeed，最初的重点是不断增长的贡献者，以及衡量在任意一个季度有多少人做出开源贡献。然而，过了一段时间，他们开始专注于培养他们所说的“持续贡献者”，即那些对同一项目做出持续贡献的人，这些项目对 Indeed 具有重要的战略意义。这是因为维护人员从1个人那里获得5个贡献，比从5个人那里获得5个贡献更容易，更大的目标是让维护人员更轻松。

Oftentimes, it is simply difficult to quantify what matters about an OSPO’s performance in numbers. “My personal measure of success is to continue to elevate VMware’s reputation and leadership in open source,” said Ambiel. “And the measures of success I have for that are fairly qualitative.” She talked about perception studies, share of voice, and times when the community organically shared VMware’s story or contributions. Individually, those metrics might be squishy, but together they “add up to a body of work that says we’re making progress.”

通常情况下，很难用数字来量化 OSPO 的绩效。Ambiel 说：“我个人衡量成功的标准是继续提升 VMware 在开源领域的声誉和领导力。”，“我对成功的衡量标准是相当定性的。”她谈到了认知研究、声量份额，以及社区有机地分享 VMware 的故事或贡献的次数。单独来看这些指标可能不太可靠，但综合起来看，它们“加起来构成了整体的工作，表明我们正在取得进展。”

Common OSPO KPIs

常见的 OSPO KPI

So, what did the OSPOs end up measuring once they had time to consider what metrics encouraged good behavior and were truly aligned with the OSPO’s goals?

那么，一旦 OSPO 有时间考虑哪些指标鼓励了正向的行为并真正符合 OSPO 的目标，他们最终会衡量什么呢？

Sustaining contributors: The number of people in the organization who make regular, repeat contributions to the same project, assuming those projects are strategically important to the organization

持续贡献者： 则指组织中定期、多次为同一项目做出贡献的人数，假设这些项目对组织具有战略意义。

The success of projects released: The external participation and impact of projects the organization releases. O’Brien gave the example of a project Indeed released that the CNCF Sandbox accepted as a measure of huge success. Maltzahn, from UC Santa Cruz, mentioned the importance of measuring not just the projects released, but how successful they became at attracting a broader following outside the university and whether they would be viable long term without the continuing involvement of the university.

已发布项目的成功： 组织已发布项目的外部参与度和影响。O’Brien 举了一个例子， Indeed 发布的一个项目被 CNCF Sandbox 接受了，这就可以作为一个巨大成功的衡量标准。来自加州大学圣克鲁斯分校的 Maltzahn 提到，不仅要衡量发布的项目的重要性，还要衡量这些项目在吸引大学之外更广泛的追随者方面取得了多大的成功，以及如果没有大学的持续参与，这些项目是否长期发展下去。

The reputation of open source internally: Do people even know the OSPO exists? Do they know what the parameters the OSPO has established around how to consume open source, contribute to existing projects, and / or create a new project? Many companies track these internal awareness metrics, as a large part of their role is internal communications.

开源的内部声誉： 人们真的知道 OSPO 的存在吗？他们知道 OSPO 围绕如何使用开源、为现有项目做出贡献和/或创建新项目制定了哪些指标吗？许多公司跟踪这些内部认知指标，因为其很大一部分职责是内部沟通。

The reputation of the organization among the open source community: For the many companies who established an OSPO as a way to improve the organization’s reputation among the larger open source ecosystem, they often track reputation and awareness metrics, such as social media mentions, the number of job applicants who mention the company’s involvement in open source, or the number of employees speaking at open source-related conferences. Some do surveys of developers run by third parties and ask reputation-related questions.

该组织在开源社区的声誉： 对于许多建立 OSPO 以提高该组织在更大的开源生态中的声誉的公司来说，他们通常会跟踪声誉和知名度指标，如社交媒体提及、提及该公司参与开源的求职者数量，或者在开源相关会议上发言的员工人数。一些人通过第三方对开发者进行调研，并提出与声誉相关的问题。

Reducing friction for developers: In addition to tracking how aware the internal team is of policies, OSPOs often track how much friction they create for those developers. If a human needs to approve a request to contribute, for example, how long does it take?

减少开发人员的摩擦： 除了跟踪内部团队对政策的了解程度外，OSPO 还经常跟踪他们给开发人员制造了多少摩擦。例如，如果一个人申请批准贡献，需要多长时间完成？

**Tracking project health: **Tracking the percentage of projects the organization depends on that are “healthy.” Determining a project’s health would often involve tracking the number of active contributors, the frequency of commits, the number of maintainers, and other metrics, including having users and contributors from many different organizations.

跟踪项目健康状况： 跟踪组织所依赖的“健康”项目的百分比。确定项目的健康状况通常包括跟踪活跃贡献者的数量、提交频率、维护者的数量和其他指标，包括来自许多不同组织的用户和贡献者。

External collaboration: How many partners is the OSPO actively collaborating with? This can take the form of participation in joint ventures or sponsored programs, particularly among universities, or being actively engaged in open source foundations and industry groups. Other examples of active, external collaborations include participation in conferences as speakers, delegates, or sponsors, as well as engaging in the research development process, as many of the interviewees in this report have demonstrated.

外部合作： OSPO 与多少合作伙伴积极合作？这可以采取参与联合投资或赞助项目的形式，特别是在高校之间，也可以积极参与开源基金会和行业团体。积极的外部合作的其他例子包括作为发言人、代表或赞助商参加会议，以及参与研发过程，就像本报告中的许多受访者所展示的那样。

There are also joint projects to determine the best metrics to track: The TODO Group and CHAOSS created the OSPO metrics working group ² to help develop better metrics for OSPOs to measure their own success.

也有一些联合项目来确定要跟踪的最佳指标： TODO 小组和 CHAOSS 创建了 OSPO 指标工作组²，以帮助为 OSPO 制定更好的指标，衡量其自身的成功。

The KPI search

KPI 探索

Many OSPO leaders stressed that talking about quantitative metrics is not only difficult but can lead to misleading conclusions. Many OSPOs just do not have very measurable goals. “Our goals for the team are relatively high level,” said Kunz, from Ericsson.

许多 OSPO 负责人强调，谈论定量指标不仅困难，而且可能导致误导性结论。许多 OSPO 没有非常量化的目标。爱立信的 Kunz 表示：“我们团队的目标相对较高。”

“I would say we step away from numbers,” said Ambiel, from VMware. “Numbers don’t tell the story and can be misleading in open source.”

VMware 的 Ambiel 表示：“我认为我们要远离数字”，“数字并不能说明问题，而且在开源中可能会产生误导。”

Part of the danger in focusing on numbers, Ambiel said, is that the ultimate goal of the OSPO is to push the company to be a better citizen in the open source ecosystem—and being a good citizen is never-ending. “There isn’t a metric where you can say, okay, I’m done. Check that off,” she said. “You can always lean in; you’re always trying to be better.”

Ambiel 说，关注数字的部分危险在于，OSPO 的最终目标是推动公司在开源生态中成为一个更好的公民，成为一个好公民是没有尽头的。她说：“没有一个指标可以让你说，好吧，我搞定了，检查一下”，“你总是可以更进一步，你总是可以努力变得更好。”

There can also be problems with timespans. “Every company tries to measure things in three-month timespans,” said Prat, from Aiven. But an open source maintainer does not care that you need to meet your quarterly goals for accepted contributions; they do not arrange open source projects around quarterly goals or fiscal years.

时间跨度也可能是个问题。“每家公司都试图在三个月的时间跨度内进行衡量，”来自 Aiven 的 Prat 说。但是一个开源维护者并不关心你是否需要达到接受贡献的季度目标；他们不会围绕季度目标或财年安排来计划开源项目。

There was also a sense that OSPOs are continually evolving and, therefore, the right KPIs to track are also constantly evolving. “We are now searching for that good KPI because our activities are changing, and the status quo has changed, so we need to adjust KPIs,” Fukuchi said.

还有一种感觉是，OSPO 正在不断发展，因此，所要跟踪的合适的 KPI 也在不断发展。Fukuchi 说：“我们现在正寻找好的 KPI，因为我们的活动正在变化，现状也发生了变化，所以我们需要调整 KPI。”

For further reading about OSPO Maturity models, check out these resources here:

OSPO Maturity Model (Whitepaper)

OSPO Maturity Model (Repo)

OSPO Maturity Model (Open Source Blog Article Explained)

进一步了解 OSPO 成熟度模型，请参考以下资源：

OSPO 成熟度模型 (白皮书)

OSPO 成熟度模型 (仓库)

OSPO 成熟度模型 (开源博客文章解读)

Conclusion

结论

What’s coming in the future?

展望未来

On one point, there was absolute agreement among all interviewees: OPSOs will continue to evolve in the future. In particular, the more established an OPSO is, the more it can think strategically and help the entire organization develop a more strategic, thoughtful approach to open source. What they do not need or expect is more focus on legal and compliance—that is a checkbox that most interviewees feel is more like the bare minimum and that they have got it covered already.

有一点是所有受访者都达成了绝对的一致：OSPO 未来将会持续发展。特别是，OSPO 越是成熟，就越能进行战略思考，并帮助整个组织制定一种更具战略意义、更深思熟虑的开源策略。他们并不需要也不期望更多地关注法律合规性，这是一种检查项，但大多数受访者认为这更像是一个最低要求，并且他们已经覆盖了这一方面。

Several interviewees spoke about expecting OSPOs to play a larger role in influencing which technologies and projects their companies adopt in the future. There was also a hope that OSPOs will be able to dive deeper into the dependency chain to better understand which projects they depend on, even if it is two or three levels down, and track the health of those projects (and contribute where necessary). Others talked about building out automated platforms to handle some of the tasks that are now manual, like approving a request to contribute to a project.

几位受访者谈到，希望 OSPO 在影响其公司未来采用的技术和项目方面发挥更大的作用。也有人希望 OSPO 能够更深入地研究依赖关系链，更好地了解他们所依赖的项目，哪怕只是两三级依赖的项目，并跟踪这些项目的健康状况（以及在必要时做出贡献）。其他人谈到了构建自动化平台来处理一些当前手动执行的任务，比如批准贡献项目的申请。

“The OSPO needs to work on a strategy, set it up, and then bring the R&D folks on board to do the right thing,” said Kunz. The OSPO, Kunz and many others believe, should be working on vision and strategy and making sure they’re working with the right people throughout the company to turn that vision into reality.

Kunz 说：“OSPO 需要基于一项战略来开展工作，建立战略并让研发人员参与进来做正确的事情。”。Kunz 及其他许多人认为，OSPO 应该致力于愿景和战略，并确保他们与整个公司的合适人选合作，将愿景变为现实。

Ultimately, part of the OSPO’s role is to have these conversations about open source, OSPOs, and the business value it delivers. That is part of open source evangelism, which is already part of many OSPOs’ mission. “I think an important part of that is really making people understand the business value,” said Schumacher.

归根结底，OSPO 的部分职责是就开源、OSPO 及其提供的商业价值进行对话。这是开源布道的一部分，也已经是许多 OSPO 使命的一部分。Schumacher 说：“我认为这其中很重要的一个部分是让人们真正理解商业价值。”。

That is not always easy because open source does not always translate neatly to the things business leaders think about, but it’s important. Business leaders often know that open source is important, but they need an OSPO to help them understand why and then use that knowledge to get even more value out of open source.

这通常并不容易，因为开源并不总是能很好地转化为商业领袖的所思所想，但这很重要。商业领袖通常知道开源很重要，但他们需要一个 OSPO 来帮助他们理解为什么，然后利用这些知识从开源中获得更多价值。

Future research

后续研究

In this report, we have focused on the value of the OSPO in private institutions. One area of future research we would like to explore is how OSPOs provide value to governments, from municipalities to supra-national organizations. We would also like to do research that explores the role and the value of OSPOs exclusively at institutions of higher learning. If you have any thoughts about either subject or would like to share your insights, contact us at research@linuxfoundation.org.

本报告中，我们重点关注了 OSPO 在私营机构中的价值。我们未来想探索的研究领域之一是 OSPO 如何为政府提供价值，从市政部门到超大型国家组织。我们还想做一些研究，专门探讨 OSPO 在高等院校的作用和价值。如果您对这两个主题有任何想法或想分享您的见解，请联系我们 research@linuxfoundation.org 。

About the authors

关于作者

Emily Omier helps open source startups accelerate community and revenue growth with better positioning and messaging for both open source projects and commercial offerings.

Emily Omier通过为开源项目和商业产品提供更好的定位和信息，帮助开源初创公司加速社区和收入增长。

Ana Jiménez Santamaría is the OSPO Program Manager at the TODO Group, a Linux Foundation project that brings together OSPO practitioners to collaborate on developing best practices, tools, and educational resources to drive successful Open Source Offices within organizations. Ana has a strong background in Open Source, DevRel, Community Health Analytics and InnerSource. She previously worked at Bitergia, a software development analytics firm, where she completed her MSc in Data Science. Her thesis focused on measuring the success of Developer Relations in Open Source communities. For more details on her thesis work, check out: https:// anajimenezsantamaria.gitlab.io/. With her commitment to open source education, Ana is dedicated to helping organizations and individuals build healthy connections in the Open Source ecosystem. You can find Ana on Mastodon, LinkedIn, and Youtube.

Ana Jiménez Santamaría是TODO Group的OSPO项目经理，TODO Group是一个Linux基金会项目，将OSPO从业者聚集在一起，共同开发最佳实践、工具和教育资源，以推动在组织内建设一个成功的开源办公室。Ana在开源、技术布道、社区健康分析和内部开源方面有着丰富的背景。她之前在软件开发分析公司Bitergia工作，在那里完成了数据科学硕士学位。她的论文专注于衡量开源社区中开发者关系。有关她的论文工作的更多详细信息，请访问：https://anajimenezsantamaria.gitlab.io/ 。Ana致力于开源教育，致力于帮助组织和个人在开源生态系统中建立健康的联系。你可以在Mastodon、领英和Youtube上找到Ana。

Chris Aniszczyk is an open source technologist with a passion for building a better world through open collaboration. He’s currently a CTO at the Linux Foundation focused on developer experience and running the Cloud Native Computing Foundation (CNCF). In a previous life, he created the Twitter open source program and led their open source efforts. Also, for many years he served on the Eclipse Foundation’s Board of Directors representing the maintainer community and the Java Community Process (JCP) Executive Committee. Furthermore, he’s a partner at Capital Factory where he focuses on mentoring, advising and investing in open source and infrastructure focused startups.

Chris Aniszczyk是一位开源技术专家，他热衷于通过开放合作建设一个更美好的世界。他目前是Linux基金会的首席技术官，专注于开发人员经验和云原生计算基金会（CNCF）的运营。在之前的职业生涯中，他创建了Twitter开源项目，并领导了他们的开源工作。此外，他代表维护者社区和Java社区过程（JCP）执行委员会，在Eclipse基金会董事会任职多年。此外，他还是Capital Factory的合伙人，专注于指导、建议和投资开源和基础设施创业公司。

twitter.com/linuxfoundation

facebook.com/TheLinuxFoundation

linkedin.com/company/the-linux-foundation

youtube.com/user/TheLinuxFoundation

twitter.com/todogroup

github.com/todogroup

linkedin.com/company/todo-group

mastodon.world/@todogroup

TODO is a global community of OSPO practitioners from diverse sectors and regions. Its General Members include representatives from 90+ organizations with extensive experience in running successful open source programs. TODO aims to foster collaboration on best practices, tools, and guidance for managing open source projects through OSPOs.

TODO是一个由来自不同部门和地区的OSPO从业者组成的全球社区。其全体成员包括来自90多个组织的代表，他们在成功运行开源项目方面具有丰富的经验。TODO旨在促进通过OSPO管理开源项目的最佳实践、工具和指导方面的合作。

By sharing experiences and developing common tooling, TODO seeks to improve OSPO adoption and education. Explore TODO’s ongoing initiatives like OSPOlogy and active working groups, and check out the OSPO landscape, OSPO 101 training modules, and TODO Guides to learn more.

通过分享经验和开发通用工具，TODO寻求改善OSPO的采用和教育情况。搜索TODO正在进行的行动，如OSPOlogy和活跃的工作组，并查看OSPO全景图、OSPO 101培训模块和TODO指南以了解更多信息。

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to repository for open source insights for the benefit of organizations the world over.

Linux基金会研究院成立于2021年，已在探究开源合作规模的日益扩大，并提供了对新兴技术趋势、最佳实践以及开源项目全球影响的见解。通过利用项目数据库和网络，以及对定量和定性方法论最佳实践的承诺，Linux基金会研究院正在为世界各地的组织创建开源见解的首选存储库。

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

本报告根据CC BY-ND 4.0 License许可证获得许可。

To reference this work, please cite as follows: Emily Omier, Chris Aniszczyk, and Ana Jiménez Santamaría, “The Business Value of the OSPO: An Exploration of Why Organizations Create, Sustain, and Expand Open Source Program Offices (OSPOs),” forewords by Georg Kunz, Leslie Hawthorn, and Kimberly Craven, The Linux Foundation, March 2023.

引用本文时请注明以下内容：Emily Omier、Chris Aniszczyk和Ana Jiménez Santamaría，“OSPO的商业价值：探索组织为什么创建、维持和扩展开源项目办公室（OSPO）”，Linux基金会，2023年3月Georg Kunz、Leslie Hawthorn和Kimberly Craven 所著的前言。

助力全球协作——开源代码的领导者如何面对分裂的挑战

2023年3月26日 · 阅读需 216 分钟

助力全球协作

How Open Source Leaders Are Confronting the Challenges of Fragmentation

开源代码的领导者如何面对分裂的挑战

January 2023

2023年1月

Anthony D. Williams, DEEP Centre Inc.

Foreword by

前言：

Yue Chen, Head of Technology Strategy, Futurewei Technologies, Inc.

Chris Xie, Head of Open Source Strategy, Futurewei Technologies, Inc.

In partnership with

联合


Fragmentation is a double-edged sword, where attempting to solve fragmentation challenges could hurt innovation and competition. 分裂是一把双刃剑，试图解决分裂挑战可能会损害创新和竞争。	There is considerable heterogeneity in the software landscape when it comes to fragmentation: Some domains are highly fragmented, and some are highly consolidated. 在软件领域，关于分裂问题存在相当大的异质性：某些领域高度分裂，而某些领域高度整合。	The principal downsides of fragmentation include increased costs and complexity for consumers and vendors of open source solutions. 碎片化的主要缺点包括增加了开源软件解决方案的消费者和供应商的成本和复杂性。
Once firmly rooted in the United States and Western Europe, today’s open source community is increasingly global and cosmopolitan. 如今的开源社区已经从最初的美国和西欧扎根开始，变得越来越全球化和国际化。	Language, culture, and geopolitics remain barriers to participation in open source communities. 语言、文化和地缘政治仍然是参与开源社区的障碍。	Diversity and inclusion are critical to building a robust open source talent pool. 多样性和包容性对于建立强大的开源人才库至关重要。
Techno-nationalism poses a severe threat to open source collaboration, with geopolitical tensions creating regional silos in global innovation communities. 技术民族主义对于开源合作构成严重威胁，地缘政治紧张局势在全球创新社区中产生了区域性壁垒。	Transparent open source development protocols are the best antidote for techno-nationalism. 透明的开源开发协议是对技术民族主义最好的解药。	The creation of new open source projects has seen a comparable increase in the number of new foundations. 新开源项目的创建看到了新基金会数量的相应增加。
Ecosystem leaders want foundations to do more to align open source projects that have similar objectives. 生态系统领袖希望基金会在更好地协调具有相似目标的开源项目方面做出更多努力。	Securing and safeguarding critical open source infrastructure should be a focal point for collaboration. 保障关键的开源基础设施的安全应该成为协作的重点。	The need for enhanced collaboration extends to a range of Internet governance issues, including cybersecurity, intellectual property, and antitrust. 加强协作的需要涵盖了一系列互联网治理问题，包括网络安全、知识产权和反垄断等。

Foreword

前言

Starting in the late 1960s as a way to share computer software, open source has become one of the most influential global collaborations representing the collective sum of humanity's knowledge due to its fundamental values of equal access, community-driven development, transparency, and inclusiveness.

自20世纪60年代末期开始作为共享计算机软件的一种方式，开源已经成为全球最有影响力的协作之一，代表着人类知识的集体总和，因为它具有平等获取、社区驱动发展、透明度和包容性等基本价值观。

In the recent past, open source has faced numerous challenges regarding security, sustainability, and legal and license compliance. Owing much to their resiliency, open source communities have collectively worked together in each instance to tackle these issues.

最近，开源面临着许多关于安全性、可持续性以及法律和许可证合规性的挑战。由于其韧性，开源社区在每个实例中共同努力解决这些问题。

But there is a newfound concern. Software fragmentation, politicization, weaponization, and techno-nation- alism could negatively impact open source as a collaborative framework and knowledge base for humanity; As such, these could broadly undermine the original spirit of open source innovation.

但是现在有一个新的问题。软件的分裂、政治化、武器化和技术民族主义可能会对开源作为人类协作框架和知识库产生负面影响；因此，这些可能广泛破坏开源创新的原始精神。

This report represents an open source practitioner's view of these challenges through extensive interviews, validating how global communities can work together to navigate complexities so that the open source mission as a global knowledge base and collaboration platform for humanity remains intact.

本报告代表了开源从业者对这些挑战的观点，通过广泛的采访，验证了全球社区如何共同努力解决复杂问题，以确保开源使命作为人类全球知识库和协作平台保持完整。

We express our sincere gratitude to Hilary Carter of Linux Foundation Research and Anthony D. Williams of DEEP Centre Inc., who shared our vision for this research topic and worked diligently from ideation to fruition. We also thank the many partners who participated and contributed to this research. We trust that this report will serve as a resource for all curious about the power of open source, inspiring participants worldwide to become active contributors to open source projects.

我们向 Linux 基金会研究院（Linux Foundation Research）的Hilary Carter和DEEP Centre Inc.的Anthony D. Williams表示真诚的感谢，他们分享了我们对这个研究课题的愿景，并从构思到实现一直勤奋工作。我们还感谢许多参与和贡献这项研究的合作伙伴。我们相信这份报告将成为所有对开源力量感到好奇的人的资源，鼓舞世界各地的参与者成为开源项目的积极贡献者。

Yue Chen, Head of Technology Strategy

Yue Chen，技术战略主管, Futurewei Technologies, Inc.

Chris Xie, Head of Open Source Strategy Futurewei Technologies, Inc.

Chris Xie，开源战略主管, Futurewei Technologies, Inc.

Executive Summary

执行摘要

Over two decades, the open source community has grown immensely. In 2000, there were a handful of high-profile open source projects and a small number of companies and organiza- tions to help steer the community's evolution. Today, the global open source ecosystem consists of millions of projects and an equally large and regionally diverse constellation of participants.

在二十多年的时间里，开源社区已经成长为一个庞大的生态系统。在2000年，只有几个知名的开源项目和一些公司和组织来帮助引导社区的发展。今天，全球开源生态系统包括数百万个项目和同样庞大和地区多样的参与者。

Growing global participation in open source software (OSS) is a testament to the ecosystem's success. However, the proliferation of open source projects and organizations also raises a vital question: Is fragmentation in the open source community impeding its progress?

开源软件（OSS）全球参与的增长证明了该生态系统的成功。然而，开源项目和组织的增多也引发了一个重要的问题：开源社区中的分裂是否妨碍了其进展？

This report draws on interviews with open source leaders to examine fragmentation in the open source ecosystem and investigate why it occurs, where it is beneficial, where it is problematic, and what key stakeholders are doing to confront the challenges of fragmentation. Specifically, the report examines three domains where fragmentation poses challenges: the development of open source solutions, the integration of diverse contributors from various regions of the world, and the governance of open source communities, including the role of foundations in safeguarding critical open source infrastructure.

本报告基于对开源领袖的采访，探讨开源生态系统的分裂，并调查其产生的原因、何时有益、何时有问题，以及主要利益相关者为应对分裂带来的挑战所做的努力。具体而言，该报告研究了3个领域中分裂带来的挑战：开源解决方案的开发、来自世界各地不同贡献者的集成，以及开源社区的治理，包括基金会在保障关键开源基础设施中的作用。

The key findings from the research are as follows:

研究的主要发现如下：

Fragmentation is a double-edged sword. While open source leaders acknowledge some fragmentation-related challenges in developing open source solutions, they argue that a decentralized ecosystem will always have an inherent degree of fragmentation and duplication. Moreover, the freedom to independently modify open source code produces a diversity of approaches to solving problems and generates superior solutions. While fragmentation can sometimes result in an inefficient allocation of resources, open source leaders caution that efforts to reduce fragmentation could stifle competition and innovation. In other words, solving the frag- mentation problem risks killing the open source goose that laid the golden egg.
There is considerable heterogeneity in the software land- scape when it comes to fragmentation. Ecosystem leaders observe that some domains are highly consolidated, whereas others are highly fragmented. Typically, fragmentation follows a maturity curve, where fragmentation is highest in the early stages of a technology's development and then consolidation increases over time. Examples of consolidated domains include operating systems (Linux), web servers (Apache), and web browsers (Chrome). Fragmented fields include embedded devices, machine learning, and blockchain.
The principal downsides of fragmentation include increased costs and complexity for consumers and vendors of open source solutions. Several open source leaders argued that the explosion of projects on GitHub signals an abundance of duplication and risks a diffusion of the community's resources. For vendors, the proliferation of competing projects places a more significant burden on their capacity to support customers. However, end users of open source solutions maintain that the proliferation of projects makes it more challenging to identify, test, and deploy suit- able code libraries. Fragmentation can also reduce the open source effect of having a large community collaborate around a shared platform or standard. Finally, the most unhealthy or disruptive forks are those implemented for non-technical objectives, specifically for techno-nationalist reasons.
Once firmly rooted in the United States and Western Europe, today's open source community is increasingly global and cosmopolitan. China, for example, is a signifi- cant consumer of and contributor to open source technol- ogies. Not only do nearly 90% of Chinese firms use open source technologies, but Chinese users are also the second most prolific group on GitHub after users from the United States.¹ However, China is not alone. Many emerging economies contain large communities of open source developers, including India, Russia, Korea, and Ukraine. For low- and middle-income countries, engagement with open source communities is giving rise to new entrepreneurial ventures and accelerating the pace of economic development.
Language, culture, and geopolitics remain barriers to participation in open source communities. While open source is flourishing globally, open source project leaders outside of North America point to language, culture, and geopolitics as genuine obstacles to their ability to maximize the participation of talented developers. Although the open source community is increasingly international, several leaders argue that organizations headquartered in the United States have outsized influence in shaping most open source projects. Open source leaders fear that a failure to address diversity and inclusion issues will curtail the open source community's access to talent and ingenuity.
Diversity and inclusion are critical to building a robust open source talent pool. The challenges of integrating different languages and cultures into open source communities are not new problems, and there is considerable confidence in the ecosystem's capacity to foster global inclusion. However, open source leaders agree that the community can do more to promote global inclusion. For example, interviewees underlined the need to invest in rapid machine translation capabilities for project communications. Leaders also discussed the importance of promoting open source norms, taming the industry's macho "bro" culture, and fostering professionalism in community dialogues and decision-making.
Techno-nationalism poses a severe threat to open source collaboration. Over the past decade, the United States and China have introduced increasingly stringent measures to restrict the transfer of critical innovations beyond national borders. Meanwhile, the war between Russia and Ukraine has heightened geopolitical tensions and made the security of technology supply chains a policy imperative. Numerous inter- viewees cited evidence that geopolitical tensions are creating national or regional silos in global innovation communities. Many open source leaders worry that rising protectionist measures could restrict the distribution of open source code and undermine the community's unfettered approach to inter- national collaboration.
Transparent open source development protocols are the best antidote for techno-nationalism. To counter techno- nationalism, open source communities must alleviate fears that national interests or malicious actors could taint or corrupt open source projects. Ecosystem leaders see reputation frame- works with enhanced peer review and third-party audits as a means to instill trust in the software development process. Interviewees also called for open source foundations and proj- ects to position themselves as impartial actors and neutral homes for collaboration. They argue that establishing neutral, inclusive, and transparent structures for cooperation will not only broaden participation but can also reduce incentives for ecosystem participants to create parallel efforts along national or regional lines.
The creation of new open source projects has seen a commensurate increase in the number of new founda- tions. One empirical study found over 100 active entities across a wide range of open source projects. Ecosystem leaders say the proliferation of new foundations and initia- tives is leading to a growing sense of engagement over- load and vendor fatigue, with some enterprises choosing to be more selective about how and where they engage. However, as open source becomes increasingly global, many ecosystem leaders welcome the creation of new open source organizations around the world. For example, stakeholders recognize that some regional or sector-based foundations can more effectively cater to the needs of their unique constituents.
Ecosystem leaders want foundations to do more to align open source projects. Open source foundations are reluctant to play a lead role in identifying and championing winning open source projects, arguing that picking winners is a marketplace function. However, leaders do see a need for better project curation and want foundations and other ecosystem participants to make greater efforts to align projects with similar objectives. To accomplish this, foundations need to enlist skilled community managers with the experience and know-how to compel diverse stakeholders to forge alignment around shared goals. Leaders also called for foundations to bring similar projects under a shared umbrella to eliminate duplication, economize on overhead, and reduce so-called "vendor fatigue."
Securing and safeguarding critical open source infra- structure should be a focal point for collaboration. All ecosystem leaders agree that building trust and confidence in OSS and supporting the ongoing maintenance of critical open source infrastructure are urgent imperatives. Decentralized innovation is producing a remarkable tapestry of open source components that are being widely deployed to support the digital economy. However, leaders observe that maintaining these disparate components is a complex challenge that requires a transparent and coordinated approach and a more significant deployment of funding and resources from the principal beneficiaries of open source infrastructure.
The need for enhanced collaboration extends to a range of Internet governance issues. Several ecosystem leaders argued that the open source community has not been as influential or assertive in technology policy dialogues as it should be. They maintain that the absence of a coordinated open source response to such issues has left the playing field open to domination by larger, better-resourced entities. Many would like joint efforts to advance open source advo- cacy on Internet governance issues, including cybersecu- rity, intellectual property, privacy, and antitrust. Ecosystem leaders say greater alignment on policy issues among open source foundations would be helpful, along with the creation of open source program offices (OSPOs) in the public sector to facilitate engagement.

分裂是一把双刃剑。 虽然开源领袖们承认开发开源解决方案存在一些与分裂相关的挑战，但他们认为分裂的生态系统总会具有固有程度的分裂和重复。此外，独立修改开源代码的自由产生了各种解决问题的方法和更优秀的解决方案。尽管分裂有时可能导致资源分配的低效，但开源领袖们警告说，减少分裂的努力可能会扼杀竞争和创新。换句话说，解决分裂问题会冒杀死孵出金蛋的开源鹅的风险。
在软件领域，分裂的情况千差万别。 生态系统领导者观察到，有些领域高度集中，而有些则高度分裂。通常，分裂遵循成熟度曲线，即技术发展的早期阶段分裂最高，然后随着时间的推移，集中度会增加。集中的领域包括操作系统（Linux）、Web 服务器（Apache）和 Web 浏览器（Chrome）。分裂的领域包括嵌入式设备、机器学习和区块链。
分裂的主要缺点是增加了开源解决方案的消费者和供应商的成本和复杂性。 几位开源领袖认为，GitHub 上项目的爆炸式增长标志着资源的过度复制和社区的扩散风险。对于供应商而言，竞争项目的繁多会对其支持客户的能力造成更大的负担。然而，开源解决方案的最终用户认为，项目的增多使得确定、测试和部署合适的代码库更加困难。分裂也可能降低开源社区围绕共享平台或标准进行大规模协作的效果。最后，实现非技术目标的分支，特别是为技术民族主义原因而实现的分支，是最不健康或具有破坏性的分支。
如今的开源社区已越来越全球化和国际化，而不再是早期在美国和西欧扎根的社区。 例如，中国是开源技术的重要消费者和贡献者。几乎90%的中国公司使用开源技术，而中国用户也是继美国之后GitHub上贡献最多的用户。¹ 然而，中国并不是唯一的例子，许多新兴经济体都有庞大的开源开发者社区，包括印度、俄罗斯、韩国和乌克兰。对于低收入和中等收入国家来说，与开源社区的接触正在催生新的企业家精神，并加速经济发展的步伐。
语言、文化和地缘政治仍然是参与开源社区的障碍。 虽然开源技术在全球范围内蓬勃发展，但北美以外的开源项目领导者指出语言、文化和地缘政治确实是影响他们最大化吸引才华横溢的开发者参与的障碍。虽然开源社区越来越国际化，但一些领导者认为总部位于美国的组织在塑造大多数开源项目方面具有不可忽视的影响力。开源领导者担心，如果不能解决多样性和包容性问题，将会限制开源社区获取人才和创新的能力。
多样性和包容性对于建立强大的开源人才库至关重要。 将不同语言和文化融入开源社区的挑战并不是新问题，生态系统有很大信心能够促进全球包容性。然而，开源领导者认为社区可以采取更多措施促进全球包容性。例如，受访者强调需要投资快速机器翻译能力，以进行项目通信。领导者还讨论了在社区对话和决策中促进开源规范、遏制该行业的兄弟文化，并培养专业素养的重要性。
技术民族主义对开源合作构成严重威胁。 过去十年，美国和中国引入了越来越严格的措施，以限制关键创新技术的跨国转移。与此同时，俄罗斯和乌克兰之间的战争加剧了地缘政治紧张局势，并使技术供应链的安全成为政策必须。许多受访者引用证据表明，地缘政治紧张局势正在在全球创新社区中创造国家或地区的信息孤岛。许多开源领袖担心，日益保护主义的措施可能会限制开源代码的分发，并破坏社区对国际合作的无拘束态度。
透明的开源开发协议是技术民族主义的最佳解药。 为了对抗技术民族主义，开源社区必须缓解人们对于国家利益或恶意行为可能玷污或破坏开源项目的担忧。生态系统领袖认为，通过增强同行评审和第三方审计的声誉框架可以建立对软件开发过程的信任。受访者还呼吁开源基金会和项目定位为公正的参与者和协作的中立家园。他们认为，建立中立、包容和透明的合作结构不仅可以扩大参与范围，还可以减少生态系统参与者在国家或地区范围内创建并行努力的动机。
新开源项目的创立使得新基金会的数量相应增加。 一项实证研究发现，有100多个活跃的实体涵盖了广泛的开源项目。生态系统领袖表示，新基金会和新举措的不断增加正在导致日益增加的参与负担和供应商疲劳，一些企业更加谨慎地选择他们参与的方式和位置。然而，随着开源变得越来越全球化，许多生态系统领袖欢迎在世界各地创建新的开源组织。例如，利益相关者认识到，一些地区或行业基础的基金会可以更有效地满足其独特的成员需求。
生态系统领袖希望基金会在协调开源项目方面发挥更大的作用。 开源基金会不愿意在识别和支持优胜劣汰的开源项目方面发挥领导作用，他们认为选择胜者是市场功能。然而，领袖们认为需要更好的项目策划，希望基金会和其他生态系统参与者更加努力地将项目与相似的目标对齐。为此，基金会需要招募有经验和知识的熟练社区经理人，促使不同的利益相关者围绕共同目标形成对齐。领袖们还呼吁基金会将类似的项目纳入共享伞下，以消除重复，节省开支，并减少所谓的“供应商疲劳”。
保护和维护关键的开源基础设施应该是合作的重点。 所有生态系统领袖都认为，建立对开源软件的信任和信心，支持关键开源基础设施的持续维护是紧迫的任务。分散的创新正在产生一个非常广泛的开源组件网络，这些组件被广泛地部署以支持数字经济。然而，领袖们观察到，维护这些不同的组件是一个复杂的挑战，需要透明和协调的方法，以及来自开源基础设施的主要受益者的更大的资金和资源的投入。
需要增强的协作范围包括一系列互联网治理问题。 几位生态系统领袖认为，开源社区在技术政策对话中的影响力或主张力还不够强。他们认为缺乏一个协调的开源响应机制使得更大、更有资源的实体主导了这个领域。许多人希望共同努力推进开源在互联网治理问题上的倡导，包括网络安全、知识产权、隐私和反垄断等问题。生态系统领袖表示，在开源基金会之间加强政策问题的对齐，以及在公共部门设立开源办公室（OSPOs）以促进参与，将会有所帮助。

Introduction

简介

开源社区已经成长了二十多年。在2000年，只有少数几个备受关注的开源项目和一些公司和组织帮助引导社区的发展。如今，全球开源生态系统包含了数以百万计的项目和同样庞大且具有地区多样性的参与者群体。

Nothing underlines the open source community's growth and global reach like GitHub. In 2010, the social coding platform hosted roughly 100,000 users and 1 million code repositories.² As of October 2022, GitHub hosts 83 million developers, 4 million organizations, and over 200 million open source code repositories.³ Some 74% of its global user base resides outside of the United States, with a significant increase in the share of developers based in Asia, Latin America, and Eastern Europe. Meanwhile, several breakthrough OSS innovations have come from places such as Japan (Ruby), Finland (Linux), and South Africa (Ubuntu).

没有什么能够像GitHub一样突显出开源社区的增长和全球影响力。在2010年，这个社交代码平台托管了大约100,000个用户和1百万个代码库。² 截至2022年10月，GitHub托管了8300万开发者、400万组织和超过2亿个开源代码仓库。³ 其中全球用户群体中有74%来自美国以外，而亚洲、拉美和东欧的开发者人数占比有显著增长。同时，许多突破性的开源软件创新来自于日本（Ruby）、芬兰（Linux）和南非（Ubuntu）等地。

Growing global participation in OSS is a testament to the ecosystem's success. However, the proliferation of open source projects and organizations also raises a vital question: Is fragmentation in the open source community impeding its progress?

开源软件（OSS）在全球范围内的日益增长证明了生态系统的成功。然而，开源项目和组织的不断增多也引发了一个至关重要的问题：开源社区的分裂是否妨碍了它的发展？

On the surface, the open source community's recent track record would suggest otherwise. After all, two-plus decades of open collaboration have resulted in a potent array of reusable software components and fostered unrivaled innovation and creativity in the digital economy. One recent estimate (and most others) suggests that 70% to 90% of most modern application stacks consist of OSS, from operating systems to cryptography and networking functions to the enterprise applications running mission-critical operations for global corporations.⁴

表面上看，开源社区最近的记录似乎表明情况并非如此。毕竟，二十多年的开放合作已经产生了大量可重用的软件组件，并在数字经济中促进了无与伦比的创新和创造力。一项最近的估计（以及其他大多数估计）表明，现代应用程序栈的70%至90%由 OSS 组成，从操作系统到加密和网络功能再到运行全球公司的关键业务操作的企业应用程序。⁴

On the flip side, open source ecosystem leaders are raising legitimate questions and concerns about whether fragmentation in the community could undermine several essential functions vital to a sustainable and thriving ecosystem. For example, consider the fol- lowing three domains:

另一方面，开源生态系统的领导者正在提出合理的问题和关切，即社区的分裂是否会削弱对于可持续和繁荣的生态系统至关重要的几个基本功能。例如，考虑以下三个领域：

Innovation and collaboration

创新和协作

The freedom to see, modify, and distribute code has always been the open source community's central tenet, along with the community's decentralized production model, which frequently results in hundreds and sometimes thousands of independent contributors collaborating to build and refine open source code libraries. Even the most ardent of competitors often work together to address shared challenges, thereby avoiding the duplication of effort while moving faster to develop and adopt emerging standards and innovations.

自由地查看、修改和分发代码一直是开源社区的核心理念，与社区分散的生产模式一起，这经常导致数百甚至数千个独立的贡献者合作构建和改进开源代码库。即使是最热烈的竞争对手也经常共同解决共同的挑战，从而避免了重复劳动，同时更快地开发和采用新兴的标准和创新。

The potency of the open source model notwithstanding, the stag- gering existence of 200-million-plus projects on GitHub has stirred a debate. Some open source leaders say the continued proliferation of new projects and coordinating bodies creates healthy compe- tition between rival approaches, and competition drives innova- tion. Other participants argue that the explosion of projects signals an abundance of duplication and risks a diffusion of the community's resources. To what extent could increasing fragmentation in software development efforts create inefficiencies and clutter in the marketplace for open source solutions? And if fragmentation is indeed a problem in some domains, what steps should the community take to align its projects, talent, and resources?

尽管开源模式的潜力无法否认，但在GitHub上存在超过2亿个项目的现状引发了一场辩论。一些开源领袖表示，新项目和协调机构的持续增长在竞争对手之间创建了健康的竞争，而竞争推动了创新。其他参与者则认为项目的爆炸性增长意味着重复的过度和风险扩散社区的资源。在软件开发努力中，增加的分裂在开放源码解决方案市场中会产生低效和杂乱的情况吗？如果在某些领域确实存在分裂问题，社区应该采取哪些步骤来协调其项目、人才和资源？

Global inclusion

全球包容性

While open source is flourishing globally, open source project leaders outside of North America point to language, culture, and geopolitics as genuine obstacles to their ability to maximize the participation of talented developers. At the same time, rising global trade tensions and political conflict risk politicizing decision-making and participation in open source development communities. Rising techno-nationalism, for example, has the world's advanced economies engaged in a high-stakes contest to reign supreme in key technological domains. Could techno-nationalist policies balkanize OSS development into regional silos and frustrate efforts to foster greater inclusion and deepen the community's talent pool? Or could open source be the key to avoiding balkanization across technology? As the scope and diversity of the community increase, how can open source project leaders integrate diverse participants and successfully promulgate open source norms, ethics, and best practices?

虽然开源在全球范围内蓬勃发展，但北美以外的开源项目领导人指出，语言、文化和地缘政治是影响他们最大化吸引有才华的开发者参与的真正障碍。同时，全球贸易紧张局势和政治冲突的上升可能会将决策和参与开源开发社区的行为政治化。例如，崛起的技术民族主义让世界上先进的经济体在关键技术领域上进行高风险竞赛。技术民族主义政策会不会将OSS发展分割成区域性孤立，从而阻碍扩大包容性和加深社区的人才池？或者，开源是否是避免技术上的分裂的关键？随着社区的范围和多样性增加，开源项目领导者如何整合不同的参与者并成功地传播开源规范、伦理和最佳实践？

Open source governance

开源治理

Good governance is increasingly paramount as OSS becomes a vital component of critical digital infrastructure. For example, quickly identifying and rectifying security vulnerabilities requires timely and effective coordination across the globally decentralized open source community. Several open source foundations have stepped in to help steward new initiatives designed to address the ecosystem's vulnerabilities. However, the population of new open source foundations continues to multiply, raising concerns about the impact of organizational silos on cosystem governance. Are smaller, more focused organizations more efficient and effective in addressing narrower mandates defined by specific industries, regions, and application spaces? Or will the continued proliferation of projects and organizations impede efforts to create global stan- dards, address security vulnerabilities, and promote the adoption of open source solutions?

随着OSS成为关键数字基础设施的重要组成部分，良好的治理变得越来越重要。例如，快速识别和纠正安全漏洞需要全球分散的开源社区进行及时有效的协调。几个开源基金会已经介入，帮助管理旨在解决该生态系统漏洞的新举措。然而，新的开源基金会数量继续增加，引发了对组织壁垒对生态系统治理的影响的担忧。更小、更专注的组织是否更有效率和更有效地处理由特定行业、地区和应用领域定义的狭窄任务？还是继续项目和组织的增加会妨碍全球标准的制定、处理安全漏洞并促进开源解决方案的采用？

本报告借助开源领袖的访谈，探讨了开源生态系统中的分裂，并研究了它发生的原因、它在哪里是有益的、在哪里是有问题的以及关键利益相关者在应对分裂挑战方面所做的工作。

Section 2 of the report discusses the benefits and potential pitfalls of fragmentation in the development of open source code.
Section 3 examines the internationalization of open source and highlights the tools and methods project leaders are deploying to overcome potential barriers to participation in open source communities.
Section 4 assesses the implications of techno-nationalism for open source collaboration and proposes strategies for reducing the risks of regional balkanization.
Section 5 provides stakeholder reflections on the state of open source governance and identifies several priorities for increased collaboration between open source foundations.
Section 6 provides a summary of key findings and recommendations.
报告的第二部分讨论了开源代码开发中分裂的利弊。
第三部分审查了开源的国际化，并强调了项目领导者为克服参与开源社区的潜在障碍而采用的工具和方法。
第四部分评估了技术民族主义对开源协作的影响，并提出了减少区域分裂风险的策略。
第五部分提供了利益相关者对开源治理状况的反思，并确定了增加开源基金会之间合作的几个优先事项。
第六部分提供了关键发现和建议的摘要。

Enabling Innovation and Collaboration

促成创新与协作

In a study of fragmentation in OSS ecosystems, Professor Christopher Yoo at the University of Pennsylvania Law School posits that the inherent freedom of action that characterizes OSS development creates the potential for excessive fragmentation. Excessive frag- mentation, Yoo alleges, creates a host of challenges for the open source community. As Yoo put it:

宾夕法尼亚大学法学院的 Christopher Yoo 教授在一项关于开源软件生态系统分裂的研究中提出，开源软件开发所特有的行动自由创造了过度分裂的可能性。Yoo 称，过度的分裂会给开源社区带来一系列的挑战。以下为原文：

"On the one hand, users' freedom to customize software is integral to the open source movement... On the other hand, infinite flexibility creates costs for the open source community by requiring the diffusion of effort and the duplication of work across multiple projects. Fragmentation also harms device manufacturers and app developers by limiting interoperability and by requiring them to adapt their products for what are now separate platforms."⁵

“一方面，用户定制软件的自由是开源的组成部分。另一方面，无限的灵活性要求在多个项目中分散精力和重复工作，这样会给开源社区带来成本。分裂也损害了设备制造商和应用程序开发人员，因为它限制了互操作性，并要求他们为现在的独立平台调整其产品。”⁵

Yoo's research refers principally to the problem of forking in open source development projects. He argues that the most extreme form of fragmentation occurs when a contributor to an open source project customizes the community's source code to the extent that it is no longer fully interoperable with the rest of the project. The result is to divide the system into two distinct and incompatible versions. Given the economic inefficiencies that ensue, Yoo concludes that "some constraints on the flexibility of open source are thus inevitable."⁶

Yoo 研究的内容主要是指开源开发项目中的复刻问题。他认为，当一个开源项目的贡献者将社区的源代码修改到不再能与项目的其他部分完全互通的程度时，就会出现最极端的分裂形式。最终的结果是将系统分为两个不同的、不兼容的版本。鉴于随之而来的经济效率低下，Yoo 总结为："因此，对开源的灵活性的一些限制是不可避免的。"⁶

In discussing fragmentation with open source leaders, a starting point for many is the recognition that forking and duplication are inevitable and often desirable consequences of a decentralized ecosystem.

在与开源领袖讨论分裂问题时，许多人的出发点是承认复刻和重复是不可避免的，而这往往是去中心化生态系统中不可避免的结果。

Decentralization, several argued, is not necessarily an optimal design for efficiency, but it is a powerful engine for innovation. "The whole open source world is a testament to the power of decentralization," said Rod Beckstrom, former CEO of ICANN and director of the U.S. National Cybersecurity Center. "One conse- quence of decentralization is overlap and redundancy. You cannot end the overlap without central control. You can evolve or nudge a decentralized system, but there is no means to control it."

一些人认为，去中心化不一定是效率最佳的设计，但它能推动创新。ICANN 前 CEO、美国国家网络安全中心主任 Rod Beckstrom 说："整个开源世界证明了去中心化的力量"。"去中心化的一个后果是重叠和冗余。如果没有中央控制，就无法避免重叠。你可以发展或推动一个去中心化的系统，但没有办法控制它。"

Moreover, most participants of the study are comfortable with the reality that a decentralized open source ecosystem will always feature some inherent degree of disorder. As Mark Surman, presi- dent of the Mozilla Foundation, put it, "The point of open source is that it's decentralized. The ability to gather a set of people to col- laborate around a particular problem or domain has always been the challenge and opportunity of open source. Can we pool our resources in a way that we can get enough value back out from the resources that I am putting in? The freedom to convene and collaborate means you will never have perfect order."

此外，大多数研究的参与者都认为去中心化的开源生态系统总是具有一些内在的无序程度。正如 Mozilla 基金会主席 Mark Surman 所说："开源的意义在于去中心化。聚集一群人围绕一个特定的问题或领域进行合作的能力，一直是开源的挑战和机遇。我们能否以一种方式汇集我们的资源，使我们能够从我投入的资源中获得足够的价值回报？召集和协作的自由意味着你永远不会有完美的秩序"。

More fundamentally, open source leaders argue that forking is part of the standard workflow for open source projects and an essential aspect of how software systems evolve and improve over time. "In good forks, you take a code library and address a problem that the community has not previously addressed," said Tim Bird, a senior software engineer with Sony Mobile Communications. "Developers split off to address the new problem and eventually come back together to reintegrate the new code into the larger ecosystem." In practice, Jim Zemlin, executive director of the Linux Foundation, points to several reasons to fragment or fork a component, such as addressing a significant technical problem or solving security issues.

更为根本的是，开源领导者认为，复刻（fork）是开源项目标准工作流程的一部分，也是开源项目随着时间推移而演变和改进的一个重要方式。Sony 移动通信公司的高级软件工程师 Tim Bird 说：”在优秀的复刻库中，你可以利用一个代码库，解决一个社区以前没有解决的问题“。“开发者分开来解决新的问题，并最终回到一起，将新的代码重新整合到更大的生态系统中”。在实践中，Linux 基金会的执行董事 Jim Zemlin 指出了分割或复刻一个组件的几个原因，如解决一个重要的技术问题或解决安全问题。

The freedom to independently experiment with an existing code library is especially beneficial when developers go off to try new ideas, add new features, and explore new use cases for OSS. "The codebases get stronger and stronger as a result," said Mike Dolan of the Linux Foundation, "because developers address their specific use cases without breaking things for everybody else." He adds, "The key part is that developers bring those new fragments back into the core upstream open source project."

当开发者去尝试新的理念，增加新的功能，探索开源软件的新用例时，独立实验现有代码库的自由尤其有益。"代码库因此变得越来越强大，"Linux 基金会的 Mike Dolan 说，"因为开发者解决了他们特定的用例，而没有破坏其他人的东西。" 他补充说："关键的部分是，开发人员将这些新的片段带回核心的上游开源项目中。"

Ultimately, ecosystem leaders agree that decentralized collaboration has resulted in a remarkable tapestry of independent open source components that developers can put together to do something bigger and more useful. "We have a huge variety of software to choose from now," said Bird. "In many ways, we are in the golden age of open source." Jim Zemlin amplifies this point, noting that a typical software package has 4,000 to 5,000 open source components. "The availability of lots of reusable components dramatically increases the efficiency of software development and speeds time to market," said Zemlin. "Enterprises can innovate around the edges. They don't have to build everything from scratch. The availability of reusable components also prevents a lot of fragmentation because everyone is drawing from the same code libraries. Nobody is taking the Linux kernel and creating a new version."

最终，生态系统的领导者们一致认为，去中心化的合作导致了独立的开源组件的非凡织锦，开发者可以把它们放在一起做一些更大、更有用的事情。“我们现在有大量的软件可供选择。”Bird说。“在许多方面，我们正处于开源的黄金时代。” Jim Zemlin 放大了这一点，他指出，一个典型的软件包有 4000 到 5000 个开源组件。Zemlin 说：”大量可重复使用的组件的可用性极大地提高了软件开发的效率，并加快了上市时间”。“企业可以在边缘地带进行创新。他们不必从头开始建立一切。可重复使用的组件的可用性也防止了大量的分裂，因为每个人都是从相同的代码库中提取的。没有人拿着 Linux 内核去创造一个新的版本”。

Even when fragmentation produces overlap and redundancy, open source leaders warn that attempts to control or curtail the freedom inherent in open source development could be more harmful than the fragmentation itself. "Fragmentation is the inno- vation engine," said Mike Milinkovich, executive director of the Eclipse Foundation. "Developers must be allowed to foster new ideas and projects. Anything that brings a draconian order to the production side of the equation is doomed to fail."

即使分裂产生了重叠和冗余，开源领导人警告说，试图控制或削减开源开发中固有的自由，可能比分裂本身危害更大。"分裂是创新的引擎，" Eclipse 基金会的执行董事 Mike Milinkovich 说。"必须允许开发者培养新的想法和项目。任何给生产方面带来严格限制令的东西都是注定要失败的。"

"Over time, competition between rival approaches gives way to increasing consolidation as market forces separate the winners from the losers."

“随着时间推移，市场将赢家和输家区分开来，竞争对手之间也开始进行合作。”

Fragmentation across the software landscape

软件环境中的分裂

Open source leaders concede that fragmentation is not a grave problem in the open source ecosystem but part of the essential life cycle in how the community develops software. Fragmentation is not only normal but largely healthy as well. As Astor Nummelin Carlberg, executive director of OpenForum Europe, put it, "The resilience of the system increases when there are competing alter- natives. Competition can also drive innovation. The distributed nature of open source produces a diversity of thought and differ- ent approaches to solving problems."

开源领导者承认，分裂并不是开放源码生态系统的一个严重问题，而是社区开发软件的基本生命周期的一部分。分裂不仅是正常的，而且在很大程度上也是健康的。正如欧洲开放论坛的执行董事 Astor Nummelin Carlberg 所说，"当有竞争性的替代方案时，系统的恢复能力就会增加。竞争也可以推动创新。开源的分布式性质产生了思想的多样性和解决问题的不同方法"。

However, looking across the software landscape, there is considerable heterogeneity in the degree of fragmentation, and leaders suggest that not all of it is desirable. Some domains are highly consolidated, while others feature a multiplicity of different software packages. Typically, the level of fragmentation follows a maturity curve where experimentation (and thus some inherent duplication of effort) is highest in the early stages of developing applications for a given domain. Over time, competition between rival approaches gives way to increasing consolidation as market forces separate the winners from the losers.

然而，纵观整个软件领域，分裂程度有相当大的异质性，而且领导者认为并非所有的分裂都是可取的。领导人表示，并非所有的分裂都是可取的。一些领域是高度整合的，而另一些领域则有许多不同的软件包。通常情况下，分裂程度遵循一个成熟度曲线。在为一个特定领域开发应用的早期阶段，实验（以及一些固有的重复工作）的分裂程度是最高的。随着时间推移，市场将赢家和输家区分开来，竞争对手之间也开始进行合作。

Several open source leaders point to Linux as a quintessential example of healthy consolidation. "Linux has been around for 32 years," said Alan Clark of the CTO Office at SUSE. "It's very mature. Sometimes you get new community distributions of Linux, but they occupy particular niches. In short, we see creativity around the edges, with developers incorporating their innovations into the main kernel."

一些开源的领导人指出，Linux 是一个典型的健康整合的例子。”Linux 已经存在了 32 年。“ SUSE 公司 CTO 办公室的 Alan Clark 说。“它是非常成熟的。有时你会得到新的 Linux 社区发行版，而他们也占据了一席之地。简而言之，我们看到了边缘的创造力，开发者们将他们的创新融入到主内核中"。

Jerry Cuomo, an IBM fellow and VP and CTO of Technology & Consulting, adds that the open source community's ability to foster broad participation in developing and using shared platforms has been enormously beneficial. "Linux has been inviting for diverse col- laboration for decades, but it also invites fierce competition," said Cuomo. "You can contribute your piece to the kernel and then pull in proprietary components to compete with other vendors. The key to its success is the architecture and heavy-handed prescription about keeping people focused on the core Linux kernel. The Apache web server is another example of this. There is only one Apache server, and the Web wouldn't be the same without it."

IBM 研究员、技术与咨询部副总裁兼首席技术官 Jerry Cuomo 补充说，开源社区促进广泛参与开发和使用共享平台的能力为很多人提供了帮助。“几十年来，Linux 一直在吸引各种各样的合作，但它也引发了激烈的竞争，”Cuomo 说，"你可以把你的那部分贡献给内核，然后拉进专有组件，与其他供应商竞争。其成功的关键是架构和关于让人们专注于核心 Linux 内核的重磅规定。Apache 网络服务器就是一个例子。如果只有 Apache 服务器，网络就不可能是现在这个样子了。

Several leaders argued that, in some domains, too much consoli- dation is a more significant concern than too much fragmentation. "In the core areas where open source is prominent, do we have the opposite problem?" asks Mark Surman of the Mozilla Foundation. "Is open source too concentrated? And when is concentration okay? There's a big difference between the collaborative mainte- nance of an open standard and the dominance of a single product. In browsers, you could argue that we need more fragmentation, not less. Look at Google's Chrome. It dominates the market."

几位领导人认为，在某些领域，过多的合并比过多的分裂更令人担忧。"在开源突出的核心领域，我们是否有相反的问题？"Mozilla 基金会的 Mark Surman 问道。”开源代码是否过于集中？什么时候集中是好的呢？开放标准的合作性维护和单一产品的主导地位之间有很大区别。在浏览器方面，你可以说我们需要更多的分裂，而不是更少。比如谷歌的 Chrome 浏览器，现在已经主导了市场。“

By contrast, fragmentation is prominent in domains that are earlier in the maturity cycle and where open source is less established. "Look at various aspects of AI," said Surman. "It's still early days.

相比之下，在成熟周期较早、开放源码建立较少的领域，分裂现象十分突出。"看看人工智能的各个方面，" Surman 说。"这仍然是早期的事情。

There are many players. Perhaps there is some fragmentation in machine learning frameworks. But it should be up to the market to decide which solutions, standards, and products will prevail."

也许在机器学习框架中存在一些分裂现象。但应该由市场来决定哪些解决方案、标准和产品会占上风"。

Where else do open source leaders see challenges with fragmenta- tion? As Tim Bird of Sony put it, "If you don't see the fragmentation, you are not looking very hard. Just look at a range of stacks. There is way too much software that does similar things. It becomes a burden. Both the consumer electronics and automotive industries have issues. Fragmentation in graphic APIs is very painful. There are no standards. Everyone is doing their own thing."

开源领袖们还在哪里看到了分裂的挑战？Sony 的 Tim Bird 指出，”如果认真看，就会看到分裂。看看现在已有的东西就知道了。有太多的软件在做类似的事情，这成为了一种负担。消费电子和汽车行业都有问题。图形 API 的分裂没有标准，这是非常痛苦的。每个人都各自为战。“

Both Bird and Clark describe the embedded device space as rife with fragmentation. "In embedded electronics, there is a natural tendency to fragment," said Bird. "It is different from the desktop and enterprise software space. To conserve resources, you tighten down the screws and build software solutions that are highly customized to the manufacturer's hardware. For example, the television stack is very different across different manufacturers. Developers code the software close to the metal to optimize performance. That causes a lot of fragmentation."

Bird 和 Clark 都说嵌入式设备领域充斥着分裂的现象。”在嵌入式电子产品中，有一个自然的趋势，就是将其分裂。“ Bird 说到。”它与桌面和企业软件领域不同。为了节约资源，你拧紧螺丝，建立高度定制的软件解决方案，以适应制造商的硬件。例如，不同制造商的电视零件是非常不同的。开发者为了优化性能而尽可能地使用底层语言去开发软件。这导致了大量的分裂。“

Gabriele Columbro of FINOS and Linux Foundation Europe, on the other hand, calls blockchain one of the most fragmented domains. "There are too many foundations, platforms, standards, and currencies," said Columbro. "Many players call themselves open source but not openly governed. The result is a proliferation of forks. You don't get consolidation when you don't have clear and transparent governance."

另一方面，FINOS 和欧洲 Linux 基金会的 Gabriele Columbro 称区块链是最分裂的领域之一。”已经有太多的基金会、平台、标准和货币“，Columbro 说。许多项目自称是开源的，但没有开放的管理。其结果是复刻的泛滥。当你没有明确和透明的管理时，你的项目就不会发展。

Fragmentation challenges and solutions

分裂的挑战和解决方案

"Open source is reducing fragmentation, not causing it."

”开源正在减少分裂，而不是导致分裂。“

Several leaders consulted for the study see what they describe as problematic instances of fragmentation in the development of open source solutions. So, what are the potential costs to the ecosystem? The principal downsides of fragmentation are increased cost and complexity for consumers and vendors of open source solutions. Fragmentation can also reduce the open source effect of having a large community collaborate around a shared platform or standard, resulting in a less efficient deployment of resources.

接受调研的几位领导人看到了他们所描述的开源解决方案发展中存在的分裂问题的实例。那么，生态系统的潜在成本是什么？分裂的主要坏处是增加了消费者和开源解决方案供应商的成本和复杂性。分裂也会降低开源的效果，让一个庞大的社区围绕一个共享的平台或标准进行合作，导致资源部署的效率降低。

For vendors, the proliferation of competing projects places a more significant burden on their capacity to support customers. "The disadvantage of fragmentation is that it increases costs and causes vendors to deploy more resources," said Alan Clark of SUSE. "You must track what is going on, assess the efficacy of different approaches, and sometimes you have to support multiple solu- tions for your customers. The duplication of effort equals more resources and more cost. And then it creates a challenge around standards and compatibility issues."

对于供应商来说，竞争项目的激增给他们带来了更大的压力。”分裂增加了成本，导致供应商部署更多的资源”，SUSE 的 Alan Clark 说。你必须跟踪正在发生的事情，评估不同方法的功效，有时你必须为你的客户支持多种解决方案。重复的努力意味着更多的资源和更多的成本。继而，它又会引发标准和兼容性问题。

"Without open source, the redundancy and fragmentation just happen behind closed doors with lots of individual proprietary projects." - STORMY PETERS

“如果没有开源，大量的独立项目都会闭门造车，导致冗余和分裂。”- STORMY PETERS

On the other hand, end users of open source solutions maintain that the proliferation of projects makes it more challenging to identify, test, and deploy suitable code libraries. Tim Bird of Sony, for example, argues that fragmentation in the software environ- ment adds time and cost to the development process for device manufacturers. "We look for open source code libraries to tackle particular problems," said Bird, "but when the open source projects proliferate, it requires a lot of research and customization to find a library that is suitable for our needs." Maintenance is another challenge, according to Bird. "When new forks emerge, it splits the community and results in fewer developers on each fork to fix bugs or address security concerns. Fragmentation creates duplica- tion of effort. We lose the open source effect."

另一方面，开源解决方案的终端用户坚持认为，项目的激增使得识别、测试和部署合适的代码库更具挑战性。例如，Sony 的 Tim Bird 认为，软件环境的分裂给设备制造商的开发过程增加了时间和成本。Bird 说，“我们通过寻找开源代码库来解决特定的问题，但当开源项目激增时，需要大量的研究和修改来找到适合我们需求的库。”Bird 表示维护项目也是一个难题。“当新的复刻库出现时，它分裂了社区，导致每个复刻库上修复错误或解决安全问题的开发人员减少。”

According to Jerry Cuomo of IBM, fragmentation can create addi- tional inefficiencies in the marketplace for solutions. "For open source to work well on the business side, you need a healthy eco- system of competing solutions that orbit around shared platforms," said Cuomo. "An enterprise that uses open source needs to know that the vendor will support its solution. Can I trust it? Is it secure? What if the vendor lets you down? What do you do?" Cuomo and others note that enterprises can freely move from vendor to vendor when the vendors work around a shared platform. "They can go for better prices and better solutions," said Cuomo. "It creates healthy competition and lowers lock-in and switching costs for enterprise users. Non-fragmented ecosystems create an open economy. When it's fragmented, you don't have that as much."

据 IBM 的 Jerry Cuomo 说，分裂会造成额外的损失。“要使开源在商业方面运作良好，你需要一个由围绕共享平台的竞争性解决方案组成的健康的生态系统，”Cuomo 说到，“使用开放源码的企业需要知道，供应商将支持其解决方案。他值得信任吗？是不是安全的？如果供应商不支持怎么办？等等。”Cuomo 等人指出，当供应商基于共享平台工作时，企业可以自由地从一个供应商转移到另一个供应商。“他们可以去争取更好的价格和更好的解决方案。”Cuomo 说，“它创造了良性竞争，降低了企业用户的锁定和转换成本。非分裂的生态系统创造了一个开放的经济当它是分裂的时候，你就不会有那么多。”

For the broader ecosystem of contributors to open source solu- tions, there is an argument that duplication and redundancy rep- resent an inefficient deployment of the community's resources. "On the one hand, you can argue that overlapping or redundant efforts are a waste of talent and resources," said Astor Nummelin Carlberg of OpenForum Europe. "On the other hand, we also see gaps in the marketplace, with competing projects in high-demand areas and less focus on critical areas that demand attention."

对于更广泛的开源解决方案的贡献者的生态系统来说，有一种说法是，重复和冗余代表了社区资源的低效部署。“一方面，你可以说重叠或多余的工作是对人才和资源的一种浪费。”欧洲开放论坛的 Astor Nummelin Carlberg 说到，“另一方面，我们也看到了市场上的差距，在高需求的领域有竞争性的项目，而对需要关注的关键领域的关注则较少。”

In the final analysis, fragmentation is a double-edged sword. On the one hand, the software ecosystem needs healthy competition between rival ideas and approaches. Nobody consulted for the study wants to reduce fragmentation at the expense of competi- tion and innovation. Moreover, looking across the entire software landscape, there is a solid case to be made that open source is reducing fragmentation, not causing it. As Stormy Peters of GitHub put it, "Without open source, the redundancy and fragmentation just happen behind closed doors with lots of individual propri- etary projects."

On the other hand, leaders acknowledge that a decentralized open source ecosystem will inevitably produce duplicate projects and, thus, some inefficiencies for vendors and other partici- pants. "For a company like SUSE and other vendors," said Clark, "duplication creates a challenge because we need to be selective regarding which projects we will support. Which projects offer the most robust solution and a supportable future? Which solu- tions are the most relevant to our customers?"

归根结底，分裂是一把双刃剑。一方面，软件生态系统需要对手的想法和方法之间的良性竞争。接受调研的人都不希望以牺牲竞争和创新为代价来减少分裂。此外，纵观整个软件领域，有充分的理由证明，开源正在减少分裂，而不是导致分裂。正如 GitHub 的 Stormy Peters 所说，“如果没有开源，大量的独立项目都会闭门造车，导致冗余和分裂。”另一方面，领导人承认，一个去中心化的开源生态系统将不可避免地产生重复的项目，因此，对供应商和其他参与者来说，会有一些低效的问题。Clark 说，“对于像 SUSE 和其他供应商这样的公司来说，重复给我们带来了挑战，因为我们需要甄别支持哪些项目。哪些项目提供最稳定的解决方案，在未来能一直支持？哪些解决方案最适合我们的客户？”

Some enterprise leaders suggested that open source foundations could intervene in fragmented domains by helping to identify and champion winning solutions. However, foundation leaders pushed back on this idea, asserting that market forces rather than founda- tions should determine the winners. "We help competitors, suppli- ers, and customers all work together and build things in a neutral forum," said Mike Dolan of the Linux Foundation. "And, in an open forum where anybody can participate, people vote by showing up. If they show up with their developers, resources, and buying power, those projects can become de facto standards. That's how the tech industry picks winners."

一些企业领导人建议，开源基金会可以通过帮助识别和支持成功的解决方案来干预分裂领域。然而，基金会领导人对这一想法进行了反驳，声称最后的赢家应该由市场力量而不是基金会决定。“我们帮助竞争者、供应商和客户一起工作，并在一个中立的论坛上进行工作。”Linux 基金会的 Mike Dolan 说到，“在一个开放的论坛里，大家用脚投票。如果开发人员、资源和购买力等都集中向了某些项目，那么这些项目可以成为事实上的标准。这就是科技行业的竞争的方式。”

Most open source leaders agree that when the ecosystem follows open source principles, the fragmentation and duplication of effort get resolved over time. "We want to see different ideas in a new space, and we want them to try them out in rapid succession," said Mike Milinkovich of Eclipse. "Open source is the best way to do that.

You do not want to corral that innovation; we want to encourage it. Competition will determine the winners and losers. Over time, projects will consolidate, and the ecosystem can move forward."

大多数开源领袖都同意，当生态系统遵循开源原则时，分裂和重复工作会随着时间的推移得到解决。“我们希望在一个新的空间里看到不同的想法，并希望他们迅速地尝试这些想法。”Eclipse 的 Mike Milinkovich 说到，“开源是最好的方式。你不应该紧固创新，而是应该鼓励创新。赢家和输家通过竞争决出。随着时间的推移，项目将得到发展，而生态系统也可以向前发展。”

Open source leaders also insist that intelligent project design can go a long way toward reducing unnecessary fragmenta- tion. Establishing neutral, inclusive, and transparent structures for collaboration will broaden the tent and reduce incentives to create parallel efforts. "When we launch a project, we do it in a way that says this is going to be neutral," said Mike Dolan of the Linux Foundation. He points to Kubernetes, where Google went to great lengths to distribute control over the project and reassure other contributors that Google was ready and willing to collabo- rate. "Google could have open sourced Kubernetes and kept all the maintainer control," said Dolan. "Instead, they handed off key parts of the codebase to other companies and leaders who proved very capable of doing it. In doing so, Google got broad buy-in and helped make Kubernetes the de facto standard for the industry."

开放源码的领导者还坚持认为，明智的项目设计可以在很大程度上减少不必要的分裂现象。建立中立、包容和透明的协作关系，会让我们未来的路更宽，也可以减少重复劳动。“当我们启动一个项目时，我们应该让它成为中立的。”Linux 基金会的 Mike Dolan 说到。他指出，在 Kubernetes 中，谷歌花了很大力气来分配对项目的控制权，并向其他贡献者保证，谷歌已经准备好并愿意进行合作。Dolan 说，“谷歌本可以将 Kubernetes 开源，并保持所有维护者的控制权。但我们（没有这么做，而是）把代码库的关键部分交给了其他公司和领导人，事实证明他们非常有能力做到这一点。这样做以后，谷歌得到了广泛的支持，并使 Kubernetes 成为了行业的事实标准。”

Promoting Global Inclusion

促进全球包容

Once firmly rooted in the United States, today's open source community is increasingly global and cosmopolitan. China, for example, has become a significant consumer of and contributor to open source technologies. Not only do nearly 90% of Chinese firms use open source technologies⁷, Chinese users are the second most prolific group on GitHub after users from the United States.⁸

曾经在美国根深蒂固的开源社区，今天正变得越来越全球化和国际化。例如，中国已经成为开源技术的重要消费者和贡献者。不仅近90%的中国公司使用开源技术⁷，中国用户是 GitHub 上仅次于美国用户的第二大用户群体。⁸

With China intent on boosting its software prowess, Chinese participation in open source will increase dramatically in the years ahead. China's Ministry of Industry and Information Technology (MIIT) has expressed concerns about its domestic software indus- try's international competitiveness and sees deeper participation in international open source projects as a means to place itself on an equal footing with global players⁹. Among the plans to improve the state of homegrown software, the MIIT is investing in a series of software parks, implementing additional policy supports, and creating two or three open source foundations or communities to bolster China's international influence.

随着中国致力于提升其软件实力，中国在开源领域的参与度将在未来几年大幅增加。中国工业和信息化部（MIIT）对其国内软件产业的国际竞争力表示担忧，并将更深入地参与国际开源项目视为一种手段，使其与全球玩家处于平等地位⁹。工信部正在投资一系列软件园区，实施额外的政策支持，并创建两三个开源基金会或社区，以增强中国的国际影响力。

"A global open collaboration orchestrated by an effective foundation is arguably the best way to reduce fragmentation and promote international cooperation."

“一个由高效基金会策划的全球开源协作可以说是减少分裂和促进国际合作的最佳方式”

Chinese technology leaders have already initiated and championed several prominent open source projects. Alibaba, for example, has one of China's most robust open source talent pools. An active participant in RISC-V, the global open source semiconduc- tor community, the e-commerce giant recently took the bold step of open sourcing its semiconductor design development via the OpenXuantie project. ¹⁰ In another example, Baidu launched Apollo in 2017, which has since evolved into one of the world's leading open source solutions for autonomous vehicles.¹¹ Baidu is lever- aging driverless technology in its Apollo Go robotaxi service. The autonomous taxi service currently operates in five Chinese cities, but the company plans to expand Apollo Go to 65 cities by 2025 and then 100 cities by 2030.¹²

中国技术领袖已经发起并支持了几个著名的开源项目。例如，阿里巴巴拥有中国最强大的开源人才库之一。作为 RISC-V（全球开源半导体制造商社区）的积极参与者，这家电子商务巨头最近采取了大胆的步骤，通过 OpenXuantie 项目对其半导体设计开发进行开源。¹⁰ 在另一个例子中，百度于2017年推出了 Apollo，此后，Apollo 已发展成为全球领先的自动驾驶汽车开源解决方案之一。¹¹ 百度正在其 Apollo Go 机器人出租车服务中利用无人驾驶技术。自动驾驶出租车服务目前在中国五个城市运营，但该公司计划到2025年将 Apollo Go 扩展到65个城市，然后到2030年扩展到100个城市。¹²

China is a prominent example of the globalization of OSS. However, many emerging economies contain large communities of open source developers, including India, Russia, Korea, and Ukraine. Harvard Business School researchers Nataliya Langburd Wright, Frank Nagle, and Shane Greenstein observe in a recent study that "Just like their counterparts in developed economies, programmers around the globe employ open source tools, speak the vocabulary of open source, and interact with open source libraries."¹³ Engagement with OSS communities, in turn, is giving rise to new entrepreneurial ventures and accelerating the pace of economic development. Wright, Nagle, and Greenstein conclude that "[OSS] represents an opportunity for low- and middle-in- come countries to reach the technological frontier more quickly than if they needed to develop such software from scratch or obtain it from costly sources..."¹⁴

中国是开放源码软件全球化的一个突出例子。然而，许多新兴经济体包含大量开源开发者，包括印度、俄罗斯、韩国和乌克兰。哈佛商学院（Harvard Business School）的研究人员 Nataliya Langburd Wright、Frank Nagle和Shane Greenstein在最近的一项研究中观察到，“与发达经济体的同行一样，全球各地的程序员使用开源工具，使用开源词汇，并与开源库互动。”，¹³ 正在催生新的创业企业，加快经济发展步伐。Wright、Nagle和Greenstein总结道，“OSS为中低收入国家提供了一个机会使其可以更快抵达技术前沿，相比从头开始开发此类软件或从昂贵的来源获得此类软件……” ¹⁴

Calista Redmond, CEO of RISC-V, argues that a global open collabo- ration orchestrated by an effective foundation is arguably the best way to reduce fragmentation and promote international coopera- tion. "Collaboration on open standards and software has proven throughout history that alignment to a shared collective model reduces the temptation and economic feasibility for ecosystem participants to take a proprietary approach to common building blocks," said Redmond. "We are creating a strong foundation with a global community where roughly one-third of our members are in NA, one-third in AMEA, and one-third in APAC."

RISC-V 首席执行官Calista Redmond认为，由一个有效的基金会组织的全球开放合作可以说是减少分裂和促进国际合作的最佳方式。Redmond 表示：“在开放标准和软件上的合作在整个历史上都证明，与共享的集体模型相一致，可以减少生态系统参与者对共同构建块采取专有方法的诱惑和经济可行性。”。“我们正在建立一个强大的全球社区基础，其中约三分之一的成员在北美，三分之一在欧洲、中东和非洲，三分一在亚太地区。”

"It's easier to collaborate globally now," said Redmond. "We have the technology to support globally distributed teams." Redmond points to growing global participation in RISC-V's technical working groups. Today, RISC-V has 65+ working groups. Redmond said there could be 80 by the end of 2022. "Now we are starting to ship actual products in a variety of vertical markets, including automo- tive, industrials, transportation, and aerospace. It's a remarkable time. We are building a robust ecosystem across workloads, from embedded to enterprise, and accomplishing in five or six years what it took earlier microprocessor architectures 20 years to do."

Redmond 说：“现在全球合作更容易了。”。“我们拥有支持全球分布式团队的技术。” Redmond 还指出，RISC-V 技术工作组的全球参与度越来越高。如今，RISC-V 拥有65个以上的工作组。雷德蒙表示，到2022年底可能会有80人。“现在，我们开始在各种垂直市场销售实际产品，包括汽车、工业、运输和航空航天。这是一个了不起的时刻。我们正在构建一个从嵌入式到企业级的跨工作负载的强大生态系统，并在五到六年内完成了早期微处理器架构20年才能完成的任务。”

The barriers to global participation

全球参与的障碍

"The hegemony of North American participants can overshadow open source projects that originated in other parts of the world."

“北美参与者的霸权可能会使起源于世界其他地区的开源项目黯然失色。”

Open source leaders consulted for the study agree that global participation in open source is on the rise. However, there is also broad recognition that a failure to eliminate several formidable barriers to full participation could result in regional fragmenta- tion in the open source ecosystem. For example, leaders point to language, culture, and geopolitics as ongoing challenges. There also remains a prevalent sense that companies and foundations headquartered in the United States have outsized influence in shaping most open source projects.

为这项研究咨询的开源领袖一致认为，全球对开源的参与正在增加。然而，人们也普遍认识到，如果不能消除充分参与的几个巨大障碍，可能会导致开源生态系统的区域分裂。例如，领导人将语言、文化和地缘政治视为持续的挑战。人们还普遍认为，总部设在美国的公司和基金会在塑造大多数开源项目方面具有巨大的影响力。

Among the first challenges raised by interviewees is the tech industry's long history of systemic discrimination, including its deeply entrenched sexism and its dismal record on diversity and inclusion. Interviewees suggest that open source communities are not immune to these challenges, despite the community's efforts to address them. "Some parts of the open source world still feel like old school 'bro' culture," said Mark Surman of the Mozilla Foundation. "That's a big issue in a world where diversity of thought and experience are key assets."

受访者提出的首要挑战之一是科技行业长期存在的系统性歧视，包括根深蒂固的性别歧视，以及在多样性和包容性方面的糟糕记录。受访者表示，尽管社区努力应对这些挑战，但开源社区并不能幸免。Mozilla 基金会的 Mark Surman 表示：“开源世界的一些地方仍然感觉像是老派的‘兄弟’文化。”。“在一个思想和经验多样性是关键资产的世界，这是一个大问题。”

Open source leaders fear that a failure to address the open source community's "bro" culture will curtail its access to talent and ingenuity. "The people who don't feel welcomed will build technology in other ways," said Surman. "Unfortunately, that could mean that the best talent will build proprietary technology because they don't have the time and resources to contribute for free."

开源领袖担心，如果不能解决开源社区的“兄弟”文化，将限制其获取人才和创造力的机会。Surman 说：“那些感觉不受欢迎的人会以其他方式构建技术。”。“不幸的是，这可能意味着最优秀的人才将建立专有技术，因为他们没有时间和资源免费贡献。”

Ramon Roche, general manager of the DroneCode Foundation, argues that another cultural barrier to global participation is the lack of acceptance of open source methods and principles in some regions. "In Latin America, we still lack validation that open source is a key component of success and a valid way to produce software," said Roche. "Managers and decision-makers don't understand how the open source community works, and develop- ers often fight uphill battles to contribute to open source efforts."

DroneCode 基金会总经理 Ramon Roche 认为，阻碍全球参与的另一个文化障碍是在某些地区缺乏对开源方法和原则的接受。Roche 表示：“在拉丁美洲，我们仍然缺乏对开源是成功的关键组成部分和生产软件的有效途径的验证。”。“管理者和决策者不了解开源社区是如何运作的，开发人员经常为了为开源工作做出贡献而进行艰苦的斗争。”

When Roche started creating open source code for drones 10 years ago in Mexico, he struggled to find a vibrant open source community locally and lacked the know-how to build one from scratch. "There was nowhere to go for support or help," said Roche. "Most of the open source organizations are based in North America. The estab- lished tech players like Google, Meta, and Microsoft, and the people that work there, control what is going on. They lead steering commit- tees as well. You need to finance your seat or be a maintainer or top contributor to be visible and influential in the community."

10年前，当 Roche 在墨西哥开始为无人机创建开源代码时，他很难在当地找到一个充满活力的开源社区，并且缺乏从头开始构建开源社区的诀窍。“没有地方可以寻求支持或帮助，” Roche 说。“大多数开源组织都设在北美。像谷歌、Meta 和微软这样的老牌科技公司，以及在那里工作的人，控制着正在发生的事情。他们还领导着指导委员会。你需要为自己的席位提供资金，或者成为维护者或最高贡献者，才能在社区中有影响力。”

Reflecting on the Japanese experience, Noriaki Fukuyasu, VP of Japan Operations at the Linux Foundation, says the pace of innova- tion is slower than in North America, and enterprise IT managers are less comfortable with open source. "We have fewer engineers on the user side driving innovation," said Fukuyasu. "They prefer what they perceive to be the more stable, proprietary solutions, and their reticence to experiment is slowing down transformation."

北美参与者的霸权反过来也会掩盖源自世界其他地区的开源项目。Roche 表示：“拉丁美洲的开发者和软件初创公司希望看到更多人承认我们的存在。”。“拉丁美洲的项目常常被忽视。如果你积极寻找它们，整个大陆都有社区和公司，但它们却位于开源社区的核心之外。”

The hegemony of North American participants, in turn, can over- shadow open source projects that originated in other parts of the world. "Latin American developers and software startups would like to see more acknowledgment that we exist," said Roche. "Projects in Latin America are often overlooked. If you actively look for them, there are communities and companies across the conti- nent, but they sit outside the core of the open source community."

Linux 基金会日本运营副总裁 Noriaki Fukuyasu 在反思日本的经验时表示，创新的步伐比北美慢，企业IT经理对开源不太满意。Fukuyasu 表示：“我们在用户端推动创新的工程师更少。”。“他们更喜欢他们认为更稳定、更专有的解决方案，他们对实验的沉默正在减缓转型。”

Even when Japanese enterprises adopt OSS, they are less likely to contribute their modifications back into the upstream code. "They use open source, but they tend to modify locally," said Fukuyasu. "They rarely apply the new patches, even though the patches and fixes exist." Fukuyasu attributes the dearth of engagement to the fact that Japanese enterprises outsource much of their IT manage- ment to external vendors. "They don't see open source as a core competence and, as a result, the community of open source devel- opers is quite small relative to the United States."

即使当日本企业采用 OSS 时，他们也不太可能将其修改贡献回上游代码。Fukuyasu 说：“他们使用开源，但倾向于在本地进行修改。”。“他们很少应用新的修补程序，即使修补程序和修复程序存在。” Fukuyasu 将缺乏参与归因于日本企业将大部分IT管理外包给外部供应商的事实。“他们不认为开源是一项核心能力，因此，与美国相比，开源开发者的社区相当小。”

For the community of open source developers in Japan, it can take time to adjust to open source norms. "Culturally, people are not comfortable showing off their thoughts in public forums, online chats, and mailing lists," said Fukuyasu. "Language is also a big issue. For example, delaying the translation of project mate- rials when launching a new project can significantly slow down adoption by the Japanese community."

对于日本的开源社区开发者来说，适应开放源码规范可能需要时间。Fukuyasu 说：“从文化上讲，人们不愿意在公共论坛、在线聊天和邮件列表中炫耀自己的想法。”。“语言也是一个大问题。例如，在启动一个新项目时，推迟项目材料的翻译可能会大大减缓日本社区的采用。”

The building blocks for global inclusion

全球包容的基石

"The scale of the challenge is much larger now because of growing participation." - JIM ZEMLIN

“由于越来越多的参与，现在挑战的规模要大得多。”-JIM ZEMLIN

Creating a more equitable balance of power and promoting global inclusion are critical to the future of open source, especially its talent pool. So, what can the open source community do to avoid fragmentation along regional and cultural fault lines? Key sugges- tions include championing diversity and inclusion, investing in better translation, fostering professionalism, educating participants about open source norms, and using in-person events to build trust.

创造更公平的力量平衡和促进全球包容对于开源的未来至关重要，尤其是对其人才库而言。那么，开源社区可以做些什么来避免地区和文化断层的分裂？关键建议包括倡导多样性和包容性，投资于更好的翻译，培养专业精神，教育参与者了解开源规范，以及利用面对面活动建立信任。

Open source leaders say that policies and practices that foster diversity and inclusion are vital starting points. "It's not only about gender," said Alan Clark of SUSE. "Diversity is also about being aware of the different cultures within our global developer community and ensuring that community methods are inclusive." Clark says collaboration is part of the DNA at SUSE and claims that executives have made efforts to understand and adapt the company's pro- cesses to the unique cultural dynamics in different regions of the world. "Diversity is increasingly key to building a strong talent pool. You can bring in new perspectives and insights. That integration of global perspectives has made open source more successful."

开源领袖表示，促进多样性和包容性的政策和做法是至关重要的起点。SUSE的 Alan Clark 表示：“这不仅仅关乎性别。”。“多样性也意味着了解我们全球开发者社区中的不同文化，并确保社区方法具有包容性。” Clark 表示，合作是SUSE DNA的一部分，并声称高管们已经努力了解并调整公司的流程，以适应世界不同地区的独特文化动态。“多元化越来越成为建立强大人才库的关键。你可以引入新的观点和见解。这种全球视角的融合使开源更加成功。”

Jim Zemlin of the Linux Foundation argues that open source projects should also have DEI requirements but that policies alone are insufficient. "Having a set of collective cultural norms is key," said Zemlin. "But the scale of the challenge is much larger now because of growing participation from around the world." Zemlin points out that social coding platforms can help identify challenges in integrating diverse participation by measuring the form and nature of collaboration. "In 2022, project leaders and open source companies can measure every digital engagement touchpoint. Are there small voices and loud voices? Are you successfully onboard- ing new developers? How long does it take for individuals to con- tribute to discussions actively?"

Linux基金会的Jim Zemlin 认为，开源项目也应该有DEI要求，但仅靠政策是不够的。Zemlin 说：“有一套集体文化规范是关键。”。Zemlin 指出，社交编码平台可以通过衡量协作的形式和性质，帮助识别整合不同参与的挑战。“2022年，项目负责人和开源公司可以衡量每一个数字参与接触点。是否有小的声音和大的声音？您是否成功地加入了新的开发人员？个人需要多长时间才能积极参与讨论？”

Digital engagement data can inform decision-making. Then it's up to leaders to foster a project ethic and culture that attracts diverse participants. "What people miss is the aspect of highly skilled individual leadership," said Zemlin. "You need a technical subject matter expert with the human qualities to lead. And not just people but also the companies who are participating. Pulling these diverse international networks together takes a lot of capability."

数字参与的数据可以为决策提供信息。然后由领导者来培养吸引不同参与者的项目伦理准则和文化。Zemlin 说：“人们怀念的是高度熟练的个人领导力。”。“你需要一个具有人类素质的技术主题专家来领导。不仅是人，还包括参与其中的公司。将这些多样化的国际网络拉到一起需要很多能力。”

An essential task for project leaders is taming the macho "bro" culture that pervades today's tech world. "We insist on a profes- sional culture," said Mike Milinkovich of Eclipse. "To increase inclu- sion, you must focus on professionalism in your dialogue and behavior. Keeping things professional helps smooth cultural differ- ences around conflict resolution and project communication."

项目领导者的一项基本任务是驯服当今科技界弥漫的男子汉“兄弟”文化。“我们坚持职业文化，”Eclipse的 Mike Milinkovich 说。“为了提高包容性，你必须在对话和行为中注重专业性。保持专业性有助于消除冲突解决和项目沟通方面的文化差异。”

"Rapid translation is the key to fostering greater engagement." - NORIYAKI FUKUYASU

“快速翻译是促进更多参与的关键。”-NORIYAKI FUKUYASU

At the operational level, open source leaders are also address- ing language translation challenges. English may be the lingua franca of the software world, but project leaders outside of North America insist that translating project communications into native languages drives broader participation. For example, Ramon Roche of the DroneCode Foundation claims that translation and language are genuine barriers in Latin America and has experi- enced the same challenges in engaging developers from Asia. "Asian communities have been eager adopters of our open source solutions for drones," said Roche. "We found that although they were using our software, they were not contributing very much back. So we hired a bilingual community manager, and she helped us reach those communities. We translated our materials into Korean and Chinese and have seen a large influx of new users." In addition to translating project materials, DroneCode started using popular messaging tools such as WeChat and then went to work translating its user interfaces. "Our Chinese membership picked up significantly once we organized a community to help with the user interface translation efforts," said Roche. "Companies that used to clone our work are now active participants."

在运营层面，开源领导者也在应对语言翻译挑战。英语可能是软件世界的通用语言，但北美以外的项目负责人坚持认为，将项目沟通翻译成母语可以促进更广泛的参与。例如，DroneCode基金会的 Ramon Roche 声称，翻译和语言在拉丁美洲是真正的障碍，在吸引来自亚洲的开发人员方面也遇到了同样的挑战。 Roche 表示：“亚洲社区一直积极采用我们的无人机开源解决方案。”。“我们发现，虽然他们在使用我们的软件，但他们并没有做出太多贡献。所以我们聘请了一位双语社区经理，她帮助我们接触这些社区。我们将我们的材料翻译成韩语和中文，并看到了大量新用户的涌入。”除了翻译项目材料，DroneCode开始使用微信等流行的消息传递工具，然后开始翻译其用户界面。 Roche 表示：“一旦我们组织了一个社区来帮助用户界面翻译工作，我们的中国会员数量就大大增加了。”。“过去克隆我们工作的公司现在是积极的参与者。”

Manual translation is time-consuming and expensive, so open source leaders see machine translation as the future. Linux Foundation Japan, for example, is working with Japanese institutes to implement machine translation systems that will speed up the translations of project materials and user interfaces. "Rapid trans- lation is the key to fostering greater engagement," said Noriaki Fukuyasu. "We are working on it 24/7. The scale of the translation challenge has exceeded what can be done by human resources."

人工翻译耗时且昂贵，因此开源领导者将机器翻译视为未来。例如，日本 Linux 基金会正在与日本研究所合作，实施机器翻译系统，以加快项目材料和用户界面的翻译速度。Noriaki Fukuyasu 表示：“快速翻译是培养更大参与度的关键。”。“我们正在全天候工作。翻译挑战的规模已经超过了人力资源所能完成的任务。"

Fukuyasu and others also argue that the return of in-person events in the post-COVID-19 era will expand the person-to-person connec- tions required to solidify trust in the community. "Japanese people are generally reluctant to contribute until they have had an oppor- tunity to meet the people they are working with," said Fukuyasu. He explains that events build trust by allowing developers to establish a rapport with project maintainers. "COVID-19 put a hold on our Linux Foundation gatherings, but we are eager to get that going again to foster those international connections."

Fukuyasu 和其他人也认为，新冠肺炎后个人活动的回归将扩大巩固社区信任所需的人与人之间的联系。Fukuyasu 说：“日本人通常不愿意做出贡献，除非他们有机会与他们合作的人见面。”。他解释说，事件通过允许开发人员与项目维护人员建立密切关系来建立信任。“新冠肺炎病毒（COVID-19）暂时阻止了我们的 Linux 基金会集会，但我们渴望再次推动这一进程，以促进这些国际联系。”

Transcending Techno-Nationalism

超越技术民族主义

While global participation in open source is increasing dramat- ically, the rise of techno-nationalism is pulling in the opposite direction. The competition for national technological superiority is such that ecosystem leaders worry that geopolitical tensions could undermine the international collaboration on which the open source software community depends.

尽管全球对开源的参与在急剧增加，但技术民族主义的兴起却朝着相反的方向发展。国家技术优势的竞争使得生态系统领导人担心地缘政治紧张可能会破坏开源软件社区所依赖的国际合作。

For decades, technology has driven increased interconnectivity and global commerce. Yet, today, investments in technology and innovation are becoming inextricably bound up in geopolitical rivalries. In short, geopolitical rivals are engaged in an increasingly high-stakes contest to reign supreme in the technological sectors thought likely to dominate the 21st century, from robotics and arti- ficial intelligence (AI) to the industrial Internet and advanced telecommunications networks.

几十年来，技术推动了互联性和全球商业的增长。然而，今天，技术和创新投资正与地缘政治竞争密不可分。简而言之，地缘政治竞争对手正在进行一场日益激烈的竞争，以在被认为可能主导21世纪的技术领域中占据主导地位，从机器人和人工智能（AI）到工业互联网和先进的远程通信网络。

Alex Capri of the National University of Singapore defines tech-no-nationalism as "a mercantilist behavior that links a nation's tech capabilities and enterprise with issues of national security, economic prosperity, and social stability."¹⁵ This new brand of techno-nationalism has seen countries worldwide move to restrict the transfer of critical innovations beyond national borders, believing that doing so will spur national economic growth and foster domestic competitive advantages. As a case in point, Capri cites "the steady progression of export controls on tangible, hard technology, followed by restrictions on data access and usage, and, most recently, new controls ... that will impede the free movement and development of human capital."

新加坡国立大学（National University of Singapore）的 Alex Capri 将技术民族主义定义为“将一个国家的技术能力和事业与国家安全、经济繁荣和社会稳定问题联系起来的重商主义行为”。¹⁵ 这一新的技术民族主义标志着世界各国开始限制关键创新在国界之外的转移，相信这样做将刺激国家经济增长，并培育国内竞争优势。作为一个例子， Capri 引用了“有形硬技术出口管制的稳步推进，随之而来的是对数据访问和使用的限制，以及最近的新管制……这将阻碍人力资本的自由流动和发展。”

Some public and private sector leaders believe that borderless technologies will transcend these nationalist tendencies and drive increased interconnectivity in the years ahead, just as they have in the two decades prior. For example, at a recent meeting of the World Economic Forum, Jayraj Nair, chief technology officer of IT services company Wipro, argued that technology will only acceler- ate globalization. "As far as technology is concerned, the scaling of AI, or 5G, or blockchain, any of these technologies will increase the velocity [of globalization]," said Nair. "In fact, the velocity will only exponentially escalate."¹⁶

一些公共和私营部门领导人认为，无边界技术将超越这些民族主义倾向，并在未来几年推动互联互通，就像二十年前一样。例如，在世界经济论坛最近的一次会议上，IT服务公司 Wipro 的首席技术官 Jayraj Nair 认为，技术只会加速全球化。Nair 表示：“就技术而言，人工智能、5G或区块链的规模化，这些技术中的任何一项都将提高全球化的速度。”。“事实上，速度只会呈指数级增长。”¹⁶

Other observers are less sanguine and forecast a new era of deglobalization due to the increased geopolitical tensions and the rise of protectionist measures deployed by various nations. In 2019, for example, Beijing took aim at American technology companies by ordering its government agencies and public institutions to stop using foreign-made computers and software. More recently, Washington broadened the scope of the advanced technologies covered by its export control regulations to include semiconduc- tors. In addition to stemming the flow of critical technologies, Washington is also pursuing a worldwide campaign to block the adoption of 5G wireless technology developed by Chinese telecom giant Huawei. ¹⁷ The net effect of these measures is a decoupling of strategic rivals from global supply chains, digital platforms, and knowledge networks.

其他观察人士则不那么乐观，他们预测，由于地缘政治紧张局势加剧，以及各国采取的保护主义措施增多，将进入一个新的去极端化时代。例如，2019年，北京命令其政府机构和公共机构停止使用外国制造的计算机和软件，以此打击美国科技公司。最近，华盛顿扩大了其出口管制条例所涵盖的先进技术的范围，将半导体制造商包括在内。除了阻止关键技术的流动，华盛顿还在全球范围内开展运动，阻止采用中国电信巨头华为开发的5G无线技术。¹⁷ 这些措施的净效果是战略竞争对手与全球供应链、数字平台和知识网络脱钩。

Will techno-nationalism balkanize open source?

技术民族主义会阻碍开源事业吗？

How will techno-nationalism impact collaborative, knowledge-in- tensive activities such as the creation of OSS? Consultations for this study revealed a spectrum of opinions. On one end of the spectrum are those who think that techno-nationalism is fundamentally changing how global innovation networks operate by inserting political considerations into otherwise technical decisions about who participates, on what terms, and to what ends. Several indi- viduals consulted for the study pointed to concrete examples in which geopolitical tensions resulted in national or regional silos.

技术民族主义将如何影响诸如开源软件的创建等知识紧张的合作性活动？这项研究的咨询揭示了一系列意见。另一方面，有人认为技术民族主义正在从根本上改变全球创新网络的运作方式，将政治因素纳入到其他技术决策中，比如谁参与、参与的条件和目的。为研究咨询的几个个人指出了地缘政治紧张导致国家或地区孤立的具体例子。

Others see techno-nationalism as more of a looming threat than a real obstacle to open source collaboration at present. All agreed, however, that techno-nationalism poses a danger to global cooper- ation and that open source communities should commit to politi- cal neutrality.

其他人则认为，技术民族主义更多地是一种迫在眉睫的威胁，而不是目前开源合作的真正障碍。然而，所有人都同意，技术民族主义对全球合作构成危险，开源社区应致力于政治中立。

"Code review in OSS is about improving the code quality and building trust between developers," said Han Xiao, the Berlin-based founder of Jina AI, a commercial OSS company. "Adding politics to the code review will hurt both and eventually roll back the open source movement in China." ¹⁸ Xiao identified the creation of Gitee, a state-backed Chinese competitor to the international code repository platform GitHub, as a clear sign of nationalist prerogatives trumping the open source community's predilection for unencumbered global collaboration. Gitee has become a backup plan of sorts for Chinese organizations concerned the U.S. might someday change its laws in an attempt to exclude Chinese participants from open source codebases. That is a highly unlikely scenario, given that open source is publicly available and that it is impossible to block any one country's access, but it has factored into backup plans.

“OSS 中的代码审查是为了提高代码质量，建立开发者之间的信任，”商业 OSS 公司 Jina AI 的创始人 Han Xiao 表示。“在代码审查中加入政治因素将损害这两者，并最终使中国的开源运动倒退。”¹⁸ Xiao 认为，国家支持的中国国际代码库平台GitHub的竞争对手Gitee的创建，是民族主义特权战胜开源社区偏好无阻碍全球合作的明显标志。Gitee已经成为一些中国组织的备份计划，他们担心美国有朝一日可能会改变法律，试图将中国参与者排除在开源代码库之外。鉴于开源是公开的，不可能阻止任何一个国家的访问，但这已经成为备份计划的一部分，这是极不可能的情况。

"Geopolitical conflicts and tensions are fragmenting the open source community around national interests."

“地缘政治冲突和紧张局势正在围绕国家利益分裂开源社区。”

Rebecca Arcesati, an analyst at the Mercator Institute for China Studies, also sees Gitee and similar homegrown Chinese alter- natives to foreign-owned platforms as part of a broader attempt by the Chinese government to lessen the country's reliance on American tech giants and insulate the domestic open source com- munity from risks arising from geopolitical tensions. Arcesati argues most Chinese developers don't want to be cut off from global open source networks and are circumspect about China's direction. "The more Beijing tries to nationalize open source and create an indigenous ecosystem, the less eager developers will be to participate in what they perceive to be government-led open source projects," said Arcesati.¹⁹

墨卡托中国研究所（Mercator Institute for China Studies）的分析师 Rebecca Arcesati 也认为，Gitee和类似的中国土生土长的外资平台是中国政府更广泛努力的一部分，目的是减少该国对美国科技巨头的依赖，并使国内开源社区免受地缘政治紧张局势带来的风险。Arcesati 认为，大多数中国开发者不想与全球开源网络隔绝，对中国的发展方向持谨慎态度。Arcesati 表示：“北京方面越是试图将开源国有化，创建本土生态系统，开发商就越不愿意参与他们认为是政府主导的开源项目。”。¹⁹

Peixin Hou, chief software architect and community director for Open Source of Huawei, is another of those who see evidence that geopolitical conflicts and tensions are fragmenting the open source community around national interests. He says Chinese users and developers of OSS are concerned that the U.S. government might expand its trade restrictions into the open source world, which would be harmful to both sides and eventually undermine collabo- rative innovation between nations.

华为开源首席软件架构师兼社区总监Peixin Hou是另一位看到地缘政治冲突和紧张局势正在围绕国家利益分裂开源社区的人。他表示，OSS 的中国用户和开发者担心美国政府可能会将其贸易限制扩大到开源世界，这将对双方都有害，并最终破坏国家间的合作创新。

Hou and others voiced concerns that forks could emerge in key software platforms to enable national economies to control aspects of the technology domestically. And then there is the risk that techno-nationalism could diminish the global open source talent pool. "Developers in China have concerns," said Hou. "Will contributors from certain countries be discriminated against when they participate in open source projects? Could concerns about national security lead developers to reduce their participation if geopolitical tensions escalate further?" Hou worries that tech- no-nationalism runs the risk of excluding a significant source of talent and ingenuity. "The trust between developers and open source communities has traditionally depended upon the contri- butions of individual developers instead of his or her country of origin or organizational affiliation, but is this going to change?" asks Hou.

Hou 和其他人表示担心，关键软件可能会出现分叉, 从而使国家经济能够在国内控制技术的各个方面。此外，还有技术民族主义可能会削弱全球开源人才库的风险。“中国的开发商有担忧，” Hou 说。“当某些国家的贡献者参与开源项目时，他们会受到歧视吗？对国家安全的担忧会导致开发者减少他们的参与吗？如果地缘政治紧张局势进一步升级？”侯担心，技术民族主义可能会排除一个重要的人才和创造力来源。“开发人员和开源社区之间的信任传统上取决于单个开发人员的贡献，而不是其原籍国或组织从属关系，但这会改变吗？” Hou 问。

The ongoing conflict between Russia and Ukraine has also raised alarm bells for some open source projects. Ramon Roche of the DroneCode Foundation says the war in Ukraine has changed everything. "Drones are being widely deployed in the conflict," said Roche, "and that brings the security and safety of the supply chains into critical focus." Roche says the U.S. and European coun- tries only want drones developed by trusted manufacturers. "They also want to ensure that foreign entities are not embedding mali- cious code in the open source systems for the drones."

俄罗斯和乌克兰之间持续的冲突也给一些开源项目敲响了警钟。DroneCode基金会的 Ramon Roche 表示，乌克兰战争改变了一切。“无人机在冲突中被广泛部署，” Roche 表示，“这将供应链的安全和保障纳入了至关重要的重点。” Roche 表示美国和欧洲国家只希望无人机由值得信赖的制造商开发。“他们还希望确保外国实体不会在无人机的开源系统中嵌入恶意代码。”

"Europeans see open source as an opportunity to enhance digital autonomy and sovereignty and lessen their dependence on US tech giants." - ASTOR NUMMELIN-CARLBERG

“欧洲人将开源视为增强数字自主性和主权、减少对美国科技巨头依赖的机会。”-ASTOR NUMMELIN-CARLBERG

For years, the DroneCode Foundation worked closely with Chinese developers. As of now, Roche says end users from certain regions can't use software or hardware developed by Chinese compa- nies. "We want open collaboration," said Roche. "We don't want to exclude any developers. They can make valuable contributions, and they can be totally innocuous. Unfortunately, we also have a big Russian community that has completely stopped contributing. We don't even talk now. We had active contributors. We had com- panies doing research and development in the drone space. They are now completely out of the loop."

多年来，DroneCode基金会与中国开发者密切合作。到目前为止， Roche 表示，某些地区的终端用户不能使用中国公司开发的软件或硬件。 Roche 表示：“我们希望开放合作。”。“我们不想排斥任何开发者。他们可以做出有价值的贡献，而且可以是完全无害的。不幸的是，我们还有一个俄罗斯大社区，已经完全停止了贡献。我们现在甚至都不谈。我们有积极的贡献者。我们有一些公司在无人机领域进行研究和开发。他们现在完全脱离了圈子。”

Astor Nummelin Carlberg of OpenForum Europe claims techno-nationalism is also rearing its head in Europe. "The issue of exclud- ing companies and other participants from standards bodies and open source projects based on nationality has become quite contentious," said Carlberg. He notes that there have been cases where European companies have been unwilling to participate in international open source projects in which Chinese compa- nies are also present because of the perceived legal uncertainties and the risk of a policy backlash at home. At the same time, he sees European policymakers attempting to insert national objec- tives into open source projects. "Europeans see open source as an opportunity to enhance digital autonomy and sovereignty and lessen their dependence on U.S. tech giants," said Carlberg. As a result, "European countries often push for greater European par- ticipation in standards bodies, and there are discussions around the creation of uniquely open source projects and foundations."

OpenForum Europe的Astor Nummelin Carlberg声称，技术民族主义也在欧洲抬头。Carlberg 说：“将公司和其他参与者排除在标准机构和基于国籍的开源项目之外的问题已经变得非常有争议。”。他指出，由于法律上的不确定性和国内政策反弹的风险，欧洲公司一直不愿参与中国公司参与的国际开源项目。与此同时，他看到欧洲决策者试图将国家目标纳入开源项目。Carlberg 表示：“欧洲人将开源视为增强数字自主性和主权、减少对美国科技巨头依赖的机会。”。因此，“欧洲国家经常推动欧洲在标准机构中的参与，并围绕创建独特的开源项目和基金会展开讨论。”

Tackling techno-nationalism with transparency and trust

以透明度和信任应对技术民族主义

Despite widespread concerns, there is considerable confidence among open source leaders that transparent open source protocols can help the community transcend techno-nationalist tendencies.

尽管存在广泛的担忧，但开源领袖们仍有相当大的信心，认为透明的开源协议可以帮助社区超越技术民族主义倾向。

Alan Clark of SUSE says he sees the risks of techno-nationalism. "It's hard to counter it," he said. "However, the solution is to be open. You can alleviate many concerns about the subversion of code to national interests or other agendas by being open and transparent with your communications and recording all your decisions and how you arrived at those decisions. We need OSS development to transcend national interests. Otherwise, we risk real fragmentation."

SUSE的Alan Clark 克表示，他看到了技术民族主义的风险。“很难对抗，”他说。“然而，解决方案是开放的。你可以通过公开透明的沟通和记录你的所有决定以及你如何做出这些决定，来缓解人们对代码颠覆国家利益或其他议程的担忧。我们需要开源软件的开发，以超越国家利益。否则，我们面临真正的分裂风险。”

Chris Aniszczyk, chief technology officer of the Linux Foundation, notes that mature OSPOs are increasingly helping their organizations navigate project politics and overcome any proclivities toward techno-nationalism. Aniszczyk argues that OSPOs can help organizations "understand and navigate project politics, such as maintaining a neutral stance when multiple influential actors are attempting to steer a project or illuminating the latent political considerations of community members." He suggests that "OSPOs can help companies maintain a neutral posture on techno-nationalism and bridge political differences by cultivating personal and working relationships that transcend national boundaries and political realms. Increasingly, this value extends to the work of foundations and nonprofits, as those realms become important neutral spaces in open source."²⁰

Linux基金会的首席技术官 Chris Aniszczyk 指出，成熟的OSPO（开源办公室）越来越能帮助他们的组织应对项目政治并克服任何倾向于技术民族主义的倾向。Aniszczyk认为，OSPO可以帮助组织“理解和应对项目政治，例如在多个有影响力的参与者试图引导一个项目时保持中立立场，或揭示社区成员的潜在政治考虑。”他建议，“ OSPO 可以通过培养跨越国界和政治领域的个人和工作关系，帮助公司保持技术民族主义上的中立立场并弥合政治分歧。越来越多地，这个价值观延伸到基金会和非营利组织的工作，因为这些领域成为开源中重要的中立空间。”²⁰

"The open source community is a great stage for track two diplomacy." - ROD BECKSTROM

“开源社区是第二轨道外交的绝佳舞台。”-ROD BECKSTROM

Ramon Roche of the DroneCode Foundation agrees that transpar- ent protocols are the key to ensuring that open source projects operate without geopolitical tensions influencing how and when they engage with talented developers**.** "If your infrastructure is secure, and you have robust processes for testing and deploying new software, then you can trust the source code no matter where it comes from," said Roche.

DroneCode基金会的 Ramon Roche 同意，透明协议是确保开源项目在不受地缘政治紧张局势影响的情况下运行的关键。“如果您的基础设施是安全的，并且您拥有测试和部署新软件的强大流程，那么无论源代码来自何处，您都可以信任源代码。” Roche 说。

Rod Beckstrom goes even further, suggesting that open source communities could provide informal bridges to help reconcile geo- political tensions. "Look at science and its rapid progression on so many fronts," said Beckstrom. "The progress continues despite the politics and the tensions between the U.S. and China." He expects open source will follow a similar trajectory to other scientific dis- ciplines. "In fact, the open source community is a great stage for track two diplomacy," said Beckstrom. "We need to build mutual trust and respect. Open source collaboration provides an opportu- nity for informal networking and relationship building."

Rod Beckstrom 更进一步，他建议开源社区可以提供非正式的桥梁，帮助调和地缘政治紧张局势。 Beckstrom 说：“看看科学及其在许多方面的快速发展。”。“尽管美国和中国之间存在政治和紧张关系，但进展仍在继续。”他预计开源将遵循与其他科学学科类似的轨迹。 Beckstrom 说：“事实上，开源社区是第二轨道外交的绝佳舞台。”。“我们需要建立互信和尊重。开源协作为非正式网络和建立关系提供了机会。”

In the end, open source leaders agree that countries that close off collaboration at national borders will be less successful than those that embrace global cooperation and its benefits. "Fragmentation due to techno-nationalist imperatives is inherently misguided," said Jim Zemlin. "Policymakers are the ones creating these tensions. Many don't even realize that they are giving up the good stuff because of a lack of trust, including faster times to market and the ability to leverage a much larger developer community."

最终，开源领导人一致认为，在国家边界上关闭合作的国家将比那些接受全球合作及其利益的国家更不成功。Jim Zemlin 表示：“由于技术民族主义的要求而导致的分裂本质上是错误的。”。“政策制定者是制造这些紧张局势的人。许多人甚至没有意识到，由于缺乏信任，他们正在放弃好东西，包括更快的上市时间和利用更大的开发商社区的能力。”

Breaking Down the Governance Silos

突破治理壁垒

Most of the early open source projects, including Linux and Apache, grew out of the voluntary efforts of a small but dispersed group of individuals. As the projects gained commercial traction, concerned stakeholders came together to create nonprofit orga- nizations that could provide the legal and economic infrastructure for ongoing community collaboration and make projects such as Linux less dependent on the individuals who initiated them. The resulting OSS foundations, including the Linux Foundation, the Apache Software Foundation, and others, are now integral to the open source ecosystem.

大多数早期开源项目，包括Linux和Apache，都是通过少数分散的个人自发努力而发展起来的。随着项目获得商业吸引力，相应的利益相关者聚集在一起创建了非营利组织，能够为正在进行的社区合作提供法律支持和经济基础，并减少诸如Linux这些项目对发起人个体的依赖。由此产生的OSS基金会，例如Linux基金会、Apache软件基金会等，如今都成为了开源生态系统的组成部分。

The creation of new open source projects has seen a commensurate increase in the number of new foundations. Javier Cánovas of the Universitat Oberta de Catalunya recently led an empirical study of open source foundations and found over 100 active entities across a wide range of open source projects.²¹ As Cánovas observes:

伴随着新开源项目的创建，新基金会的数量也有了相应的增加。加泰罗尼亚开放大学（the Universitat Oberta de Catalunya）的Javier Cánovas最近领导了一项关于开源基金会的实证研究，并在众多开源项目中发现了超过100个活跃的实体。²¹ Cánovas经过观察得出：

"The survival of an OSS project largely depends on its ability to retain developers, onboard new ones (i.e., newcomers), and create a community of users who promote its adoption and use. As these projects grow, developers tend to organize and build communities. Still, many lack formal governance models to structure and manage the (potentially large) community around them (and the challenges this implies). Support to deal with all kinds of organizational decisions (including legal and economic aspects) is a huge concern for all projects at this stage."

“一个OSS项目的存续在很大程度上取决于它是否有能力留下开发者、吸收新的开发人员（即新人），以及创建一个帮助其被采纳和使用的用户社区。随着这些项目的发展，开发者倾向于社区的组织和构建。尽管如此，许多公司仍然缺乏正式的治理模型来构建和管理其（可能很大的）外延社区（以及其中的挑战）。对执行各种组织决策（包括法律和经济方面）的支持是这个阶段所有项目的一大焦点。”

While mandates vary from organization to organization, foun- dations typically set the stage for collaboration on open source projects. The roles include building tools and processes to enable collaborative development, hosting a structured gover- nance process for steering the evolution of open source projects, handling legal issues (particularly around intellectual property licensing, trademarks, and patents), and engaging with policymak- ers and regulators. Many foundations also play a role in educa- tion, training, and marketing. Across these domains, foundations provide a legal entity to hire staff and raise funds to pay for activi- ties that benefit the community.

虽然各个组织的授权有所不同，但基金会通常会为开源项目的合作奠定基础。其作用包括构建可以支持开发的工具和流程，主持结构化的治理流程以指导开源项目的发展，处理法律事务（特别是关于知识产权许可、商标和专利的问题），以及与决策者和监管者进行沟通。许多基金会还在教育、培训和营销方面发挥作用。在这些领域中，基金会提供了一个法人实体来雇佣员工和筹集经费去资助有益于社区的活动。

The sheer number of foundations identified in Cánovas' empirical study raises a question as to whether the governance of OSS is now too diffuse to enable sufficient progress on the challenges facing the community. For example, has the proliferation of founda- tions created a crowded field that could ultimately impede efforts to develop global standards, address security vulnerabilities, and promote the adoption of open source solutions? And does a crowded field make it more difficult for interested stakeholders to determine how and where to allocate their time and resources?

实证研究过程中，Cánovas在确定基金会的实际数量时提出了一个问题，即当前的 OSS 治理是否过于分散，以至于无法在社区面临的挑战上取得足够的进展。例如，基金会的激增是否创造了一片红海，最终可能阻碍全球标准的制定、安全漏洞的解决和促进采用开源解决方案的努力？一个拥挤的领域是否会让感兴趣的利益相关者更难决定如何以及在哪里分配他们的时间和资源。

Several open source leaders consulted for the study agreed that the proliferation of open source foundations and projects has become problematic. They worry, for example, that the flurry of new open source projects and associations for narrow verticals will pull key stakeholders in too many directions. As one inter- viewee put it, "Quite frankly, none of the participants has a clue how to do open source. It is disconcerting. The probability of success is very low. Their scope is too narrowly focused. They don't understand that open source is a unique discipline they don't have the skills to master."

为该研究提供咨询的几位开源领导者一致认为，开源基金会和项目的激增已经成为问题。举例来说，他们担心新的开源项目和针对狭窄垂直领域的协会将把重要的利益相关者拉向过多的方向。正如一位受访者所言，“坦率地讲，没有一个参与者知道如何做开源。这让人感到不安。成功的希望渺茫。这些人的局限太狭窄了。他们不明白开源是一门独特的学科，并没有掌握相关技能。”

The proliferation of new foundations has already led some enter- prises to be more selective about how and where they engage. For example, Deborah Bryant, formerly of Red Hat, notes that her OSPO was spending more time re-evaluating the firm's participation in software foundations on a regular cadence to "ensure that [Red Hat was] getting a return on its investment."²²

新基金会的激增已经导致一些企业在参与方式和领域上更加挑剔。例如，曾受雇于红帽公司的Deborah Bryant表示，她的 OSPO 正在耗费更多时间来定期重新评估公司对软件基金会的参与，以“确保（红帽）从投资中获得回报”。²²

"As vendors, we must determine which foundations and projects our customers care about. It's time consuming." - ALAN CLARKE

“作为供应商，我们必须确定我们的客户关心哪些基金会和项目。这是一件很耗时的事情。” ——ALAN CLARKE

Meanwhile, Alan Clarke of SUSE acknowledges that foundations are businesses and that they ultimately compete for members and revenues. But the imperative to increase memberships and revenues by launching new projects creates what he and others describe as "vendor fatigue" and "engagement overload." "Foundations create projects to address the sexy spaces in hopes that doing so will boost memberships and revenues," said Clark. "The result may be multiple different approaches to the same problem, and you get fragmented solutions. Then, as vendors, we must determine which founda- tions and projects our customers care about. Which projects will address the real market needs, and which will be successful? It's time-consuming."

与此同时，来自SUSE的Alan Clarke承认，基金会也是企业，他们最终所争夺的是会员和收益。但是，通过推出新项目来增加会员数量和收益的必然性，导致了大家所说的“卖方疲劳”和“用户参与过载”。Clark 表示：“基金会通过创建项目来提高吸引力，并希望借此增加会员数量和收益。”“结果可能是同一问题出现多种不同的解决方法，你会得到分裂的解决方案。因此，作为供应商，我们必须确定客户所关心的是哪些基金会和项目。哪些项目将满足真正的市场需求，哪些项目将获得成功？这是一件很耗时的事情。”

Nevertheless, some argued that creating new OSS foundations is justified if they can mobilize more efficiently and effectively to address narrower mandates defined by specific industries, regions, and application spaces. "Policymakers realize that open source is a vital part of the innovation economy," said Mike Milinkovich of the Eclipse Foundation. "To protect the future prosperity of their citizens, they need to understand and participate in open source. Inevitably there will be verticals and jurisdictions where stakehold- ers take solace from working with organizations that speak their language and have similar norms and legal frameworks."

尽管如此，一些人仍然坚信，如果能够更有效地动员新的 OSS 基金会来解决由特定行业、地区和应用空间定义的更垂直赛道，那么创建新的OSS基金会是合理的。“决策者意识到开源是经济创新的重要组成部分，”Eclipse基金会的Mike Milinkovich表示。“为了保护公民未来的繁荣，他们需要理解和参与开源。不可避免地，在某些领域和司法范围内，利益相关者会通过与说自己语言、拥有类似规范和法律框架的组织合作中获得安慰。”

Until recently, most of the OSS foundations were California-based organizations. However, as open source becomes increasingly global, many ecosystem leaders concede that the present and future gov- ernance of open source communities can't be located solely in California. "Sometimes you need specialized expertise or capabilities to address the needs of a particular vertical or region," said Jim Zemlin of the Linux Foundation. "For example, the E.U. is working on technology sovereignty and seeking to harness open source to lessen the influence of U.S. tech giants. If you want to access E.U. grant funding to contribute to relevant projects, you need European experts, and your organization must also be incorporated in the E.U." To that end, the Linux Foundation launched a European branch (Linux Foundation Europe) in September 2022 to strengthen its part- nerships with European constituencies and provide an on-ramp for European projects and companies seeking to harness open source solutions in the public and private sectors. ²³

到如今，大多数OSS基金会都设在了加利福尼亚。然而，随着开源变得越来越全球化，许多生态系统领导者都承认，开源社区目前和未来的治理将不会仅仅局限于加州。Linux基金会的Jim Zemlin表示:“有时你需要特定的专业知识或能力来满足特定垂直领域或地区的需求。”“例如，欧盟正在致力于技术主权，并试图利用开源来削弱美国科技巨头的影响力。如果你在相关项目上希望获得欧盟的资助，那么就需要聘用欧洲专家，你的组织也必须在欧盟国家注册。”鉴于此，Linux基金会于2022年9月成立了欧洲分支机构（Linux基金会欧洲），以加强与欧洲资助者的合作关系，并为寻求在公共和私营部门利用开源解决方案的欧洲项目和公司提供一个窗口。²³

In this sense, Milinkovich and Zemlin agree that one could inter- pret the creation of regional associations as a sign of success rather than a failure of global collaboration. They point to China, which is on the record as wanting to be an influential player in open source with its own associations and projects. "The European Commission may do the same," said Milinkovich. "These regional associations may be unsuccessful, but hopefully give rise to a com- petition of ideas."

从这个意义上讲，Milinkovich 与 Zemlin 都认为，人们可以把区域性协会的创立看作是全球合作成功的标志，而不是失败的标志。他们以中国为例，中方公开表示希望通过自己的协会和项目成为开源领域具有影响力的参与者。Milinkovich 说:“欧盟委员会可能也会效仿。“这些区域性协会不一定会取得成功，但非常有希望引导一场思维的竞赛。”

"All stakeholders consulted for the study agree that improved collaboration between open source foundations is required to address the ecosystem's challenges."

“参与这项研究的所有利益相关者一致认为，为了应对生态系统的挑战，需要改进开源基金会之间的合作。”

Whatever their feelings on the proliferation of new foundations and initiatives, all stakeholders consulted for the study agree that improved collaboration between open source foundations is required to address the ecosystem's challenges. Indeed, with modern tools, open source leaders see few excuses for not working together to address issues of shared concern. "The foundations should be insisting on open and broad collaboration to limit the duplication of effort," said Alan Clark of SUSE. "We need to find a way to align the projects. In fact, the projects themselves need to follow open source methods. The design and development pro- cesses should be transparent. The meetings and records should be open. The discussions and decision-making should be well docu- mented. In other words, the initiatives that foundations lead should be truly open source projects," said Clark.

无论对新基金会和新项目的激增抱有什么样的看法，所有参与研究的利益相关者都已经意识到，为了应对生态系统的挑战，需要改进开源基金会之间的合作。事实上，通过使用现代化工具，开源领袖们几乎没有了不想通过合作方式来解决共同关心问题的借口。SUSE的 Alan Clark 认为：“各个基金会应当坚持开放和广泛的合作，以规避重复工作。”“我们需要找到一种方法来协调这些项目。事实上，项目本身需要遵循开源方法。设计和开发过程应该是透明的。会议和记录要予以公开。讨论和决策应该有很好的文件记录。换句话说，基金会领导的项目应该是真正的开源项目。”

Mike Dolan of the Linux Foundation also sees an opportunity for larger open source foundations to provide an umbrella for smaller projects, reducing overlap and economizing on overhead and other resources. "We might launch five projects in a quarter. GitHub is launching 5,000 new projects a day," said Dolan. The challenge is that each has a unique set of stakeholders who want a neutral, growing project that enables new cost savings or market opportunities---and they want to work on them together. Foundations enable them to work together in a structured way. Dolan argues that it is difficult in many instances to curtail the creation of new projects. However, he sees a role for foundations in helping to align efforts and streamline operations. "This innova- tion is happening with or without us," said Dolan, "so what we're trying to do is to concentrate on a few projects that matter and provide an umbrella structure for projects with shared objectives to come together."

Linux基金会的 Mike Dolan 也分析了大型开源基金会为小型项目提供护佑的机遇：减少重叠，节约开销和其他资源。“我们可能会在一个季度推出五个项目。GitHub 每天推出5000个新项目，”Dolan 这样说。其中的挑战在于，每个公司都有一组独特的利益相关者，他们想要一个中立的、持续发展的项目，以实现新的成本节约或市场机会——他们想共同奋斗。基金会使他们能够以一种结构化的方式并肩协作。Dolan 认为，在许多情况下，限制新项目的创建是很困难的。不过，他看到了基金会在帮助协调各方努力和简化运营方面的作用。Dolan 表示：“不管有没有我们，这种创新都会发生，所以我们正在努力做的是专注于几个重要的项目，并为有共同目标的项目提供一个保护框架。”

Maintaining critical open source infrastructure

关键开源基础设施维护

One area urgently calling for increased collaboration is securing and safeguarding the vast patchwork of critical open source com- ponents. Decentralized innovation has produced a remarkable tapestry of open source components, and their deployment have widely supported the digital economy. However, maintaining the disparate components is a complex challenge that requires a transparent and coordinated approach and more significant funding and resources from organizations that draw value from open source infrastructure.

如果说哪个领域迫切需要加强合作，那无疑是海量关键开源组件的安全和保护。大量的开源组件在去中心化创新的过程中产生，它们的部署已经对数字经济提供了广泛支持。然而，对不同组件的维护也是一项复杂的挑战，需要采取透明和同步的方式，并向那些在开源基础设施中获益组织申请更多的资金和资源。

Cybercriminals and other malevolent networks are ramping up their attacks, making cybersecurity essential to safeguarding the global economy and defending critical infrastructure. As a result, industries and governments have invested considerable sums in correcting the frequent security issues plaguing proprietary software. However, the recent Log4Shell software vulnerabili- ties highlight the need for a commensurate effort to protect open source tools, which are just as critical and often more ubiquitous than their proprietary counterparts.

网络犯罪分子和其他恶意网络行为正在不断加大攻击力度，网络安全对于保护全球经济和保护关键基础设施变得至关重要。因此，行业和政府都投入了大量资金来治理那些频发的困扰专有软件的安全问题。然而，最近的Log4Shell软件漏洞突出表明，开源工具的保护也需要付出相应的努力，这些工具与专有工具一样重要，而且往往更普及。

Open source components are embedded in numerous pieces of critical infrastructure that provide the underpinnings for global commerce, from power grids, shipping, and transportation to electronic commerce and finance. Understanding which compo- nents are most widely used and most vulnerable to exploitation is crucial for the continued health of the open source ecosystem and the broader digital economy. As Jim Zemlin, executive director of the Linux Foundation, explains, "Hundreds of thousands of OSS packages are in production applications throughout the supply chain. Understanding what we need to be assessing for vulnera- bilities is the first step for ensuring long-term security and sus- tainability of OSS."²⁴ However, as the Laboratory for Innovation Science at Harvard points out, "it is difficult to fully understand the health and security of OSS because 1) OSS, by design, is distrib- uted in nature, so there is no central authority to ensure quality and maintenance, and 2) because OSS can be freely copied and modified, it is unclear how much OSS, and precisely what types of OSS, are most widely used."²⁵

许多关键基础设施中都嵌入了分裂开源组件，这些基础设施为全球商业提供的基础服务从电网、物流和交通直到电子商务和金融。了解哪些组件使用最广泛、最容易被利用，对于开源生态系统和更广泛数字经济的持续健康至关重要。正如Linux基金会执行董事Jim Zemlin所阐述的，“在整个供应链中，有数十万个 OSS 软件包处于应用程序的研发中。明确了解哪些漏洞需要评估，是确保OSS长期安全和可持续发展的首要任务。”²⁴ 然而，正如哈佛大学创新科学实验室所持的态度，“很难完全了解开源软件的健康和安全程度，因为：（1）从设计上讲，开源软件本质上是分布式的，没有一个权威中枢对其质量和维护进行保证；（2）因为开源软件可以自由复制和修改，目前尚不清楚有多少开源软件，或者更确切地说，哪种类型的开源软件被广泛使用。”²⁵

Tracking the proliferation of OSS and monitoring potential vulnera- bilities are complex tasks. Just as vexing, however, is the challenge of maintaining the vast number of critical OSS components in use today. As Kent Walker, Alphabet's president of global affairs, points out, "[In most cases] there's no official resource allocation and few formal requirements or standards for maintaining the security of critical open source code."²⁶ While high-profile projects, such as Linux, have active communities and receive regular attention, other projects are infrequently updated and have few watchers.

跟踪OSS的增长和监测潜在的漏洞是一项复杂的任务。然而同样令人烦恼的，是当下大量关键OSS组件投入使用的挑战。正如Alphabet的全球事务总裁Kent Walker所指出的一样，“在大多数情况下，没有官方的资源分配，很少有正式的规范或标准来保证关键开源代码的安全性。”²⁶“尽管Linux等高调的项目有活跃的社区并时刻被关注，但其他项目却不能经常更新，也很少有人注意。”

"Open source infrastructure is the classic small pieces, loosely joined with lots of independent components developed by small maintainers who are not necessarily compensated for their work," said Mark Surman. As the ecosystem addresses its sustainabil- ity challenges, Surman advises, "It is vital to remember that open source is a tremendous accelerator of innovation and the digital economy. It's not realistic to consolidate it all. So how can we ensure longevity? Are there ways to compensate those maintain- ers? Could we have a Patreon for open source components?"

Mark Surman认为：“开源基础设施是典型分裂，众多由小规模维护人员开发的独立组件被连接在一起，而这些维护人员的工作不一定会享受报酬。”在生态系统应对可持续性发展挑战的问题上，他建议到：“一定要牢记，开源是创新和数字经济的巨大加速器。全部加固是不现实的。那么，我们如何才能青春永驻呢?有补偿这些维护者的办法吗？我们也可以拥有一个Patreon来支持开源组件吗?”

In the absence of a distributed compensation and resourcing model, organizations such as the newly created Open Source Security Foundation (OpenSSF) will play a vital role in identifying critical com- ponents, assessing vulnerabilities, and establishing new commu- nity-based processes and standards for regular maintenance and testing. "The OpenSSF is an industry effort with a roving SWAT team," said Jim Zemlin. "They will identify the abandoned projects and then shore them up. The scorecard and SLSA frameworks we are working on are key to this. We can use these frameworks to identify the vulnerable components, including all the dependencies in the ecosystem, and then target resources to those unsupported or under-resourced areas."

在分散补偿和资源分配模型不足的情况下，一些像开源安全基金会（OpenSSF）之类新兴组织将在识别关键组件、评估漏洞和新建基于社区的定期维护和测试过程和标准等方面发挥至关重要的作用。 Jim Zemlin认为：“OpenSSF是一整个行业努力的成果，它拥有一个流动的SWAT小组。”“他们识别出一些即将中止的项目，然后予以支持。我们正在开发的记分卡和SLSA框架是其中的关键。我们可以使用这些框架来识别脆弱的组件，包括生态系统中所有的依赖项，然后让资源向到那些不受支持或资源不足的领域倾斜。”

"Many leaders consulted for the study would also like to see large enterprises and other significant beneficiaries pitching in to help sustain a thriving open source ecosystem."

“为这项研究提供咨询的许多领导者也希望大型企业和其他显著受益者参与其中，助力维持一个蓬勃发展的开源生态系统。”

In 2022, DARPA, the U.S. military's research arm, weighed in on the matter with a multi-million-dollar effort, over 18 months, to help identify malicious actors and prevent them from corrupting critical open source infrastructure. DARPA notes that much of the U.S. Department of Defense's computing infrastructure rests on a foun- dation of OSS. DARPA's so-called "Social Cyber" program will harness AI "to detect and counteract any malicious campaigns to submit flawed code, launch influence operations, sabotage development, or even take control of open-source projects." Part of the effort involves scouring through millions of lines of code to detect vulnerabilities. DARPA will also analyze social interactions on mailing lists and other forums to gain insight into the community of software developers who write, fix, implement, and influence that code. DARPA hopes that sentiment analysis deployed at scale will allow researchers to identify trustworthy contributors and the individuals and groups that justify extra vigilance.²⁷ However, the countereffect is that devel- opers and open source advocates see any government monitoring as potentially harmful and intrusive. Programs like this could lead to backlash from the same project communities that governments intend to support.

2022年，美国军方研究机构DARPA耗时18个月、耗资数百万美元，对恶意行为的识别工作进行支持，并阻止其破坏关键开源基础设施。DARPA 指出，美国国防部的大部分计算基础设施都基于OSS。DARPA 所谓的“社交网络”项目将利用人工智能“检测和抵消各种恶意行为，诸如提交有缺陷的代码，发起影响行动，破坏开发，甚至控制开源项目。”这些工作中有一部分就包括在数百万行代码中检测漏洞。DARPA 还将分析邮件列表和其他论坛上的社交互动，以深入了解编写、修复、实现和影响代码的软件开发社区。DARPA希望大规模部署的情绪分析可以帮助研究人员识别可信的贡献者，以及需要加以警惕的个人和团体。²⁷ 然而事与愿违，开发人员和开源倡导者都认为任何政府监控都带有潜在的危害性和入侵性。这种项目可能会在政府计划支持的项目社区中引起反弹。

Stormy Peters says GitHub is also trying to make it easier for devel- opers to make their software more secure by providing a free and open database of vulnerability information and enabling private vul- nerability reporting. However, many leaders consulted for the study would also like to see large enterprises and other significant benefi- ciaries pitching in to help sustain a thriving open source ecosystem.

Stormy Peters 表示，GitHub 还试图通过提供免费开放的漏洞信息数据库和授权定制漏洞报告，让开发人员更容易提高软件安全性能。然而，为该研究提供咨询的许多领导者也希望看到大型企业和其他重要受益者参与进来，共同为开源生态系统的蓬勃发展提供帮助。

"Technology consumers, especially the enterprises, have had a free ride for far too long," said Mike Milinkovich of Eclipse. "Some vendors include open source components in the products they use, yet enterprises rarely give anything back to the communities they rely upon for their application development. The sustainabil- ity problems are related to the lack of money and resources to do all the things that must be done." Peters agrees that the absence of funding for small project maintainers is a problem and notes that GitHub is also working on tools to help companies contribute finan- cial resources to maintaining critical infrastructure components.

Eclipse的Mike Milinkovich认为：“消费型科技，尤其是在企业中，搭了太长时间的便车。”“一些供应商在产品中包含开源组件，但很少向他们所依赖的应用程序开发社区提供任何回馈。可持续发展问题与缺乏资金、资源去处理那些必要的事情息息相关。”Peters也认可小型项目维护者缺乏资金已经成为问题，并指出GitHub也在致力于开发一些工具，帮助企业贡献经费资源来维护关键基础设施组件。

Milinkovich, Zemlin, Peters, and others claim that software vendors and enterprise users have received the memo that they need to engage in the communities from which they are drawing benefits. "It is time to recalibrate their engagement in light of where they get the code and what they need to do to ensure the code is properly main- tained and sustainable," said Milinkovich. "In the end, there is no free lunch." Zemlin points to Google (one of Alphabet's subsidiaries) as one of several good enterprise stewards that have stepped up to help make code libraries bulletproof.

Milinkovich、Zemlin、Peters等人声称，软件供应商和企业用户已经收到了一份备忘录，他们需要参与社区活动，以便从中获益。Milinkovich说:“这是一个恰当的时机，可以根据他们获得代码的渠道、采取何种措施来确保代码得到适当维护和可持续发展，来重新调整他们的参与程度。”“总之，天下没有免费的午餐。”Zemlin指出，谷歌（Alphabet的子公司之一）是几个优秀的企业管理者之一，他们已经开始帮助强化代码库。

In 2020, for example, more than 10% of Alphabet's full-time employ- ees (approximately 15,000) actively contributed to open source projects.²⁸ In addition to managing its own open source code repos- itories, Alphabet employees contribute to a vast pool of external projects and actively participate in boosting the security and sus- tainability of open source and its supply chain. In a significant sign of progress, hundreds of prominent enterprise and consumer tech- nology firms, ranging from Amazon to VMware, have established OSPOs and dedicate comparable proportions of their workforce to developing and maintaining open source projects.²⁸

例如，在2020年，超过10%的Alphabet全职员工（约15，000人）积极地为开源项目做出贡献。²⁸ 除了管理自己的开源代码库外，Alphabet的员工在大量的外部项目中做出了贡献，并积极参与提高开源及其供应链的安全性和可持续性。从亚马逊到VMware，数百家著名的企业和消费科技公司已经建立了 OSPO，并将相当比例的人力用于开发和维护开源项目，这是一个显著的进步现象。²⁹

Ultimately, Zemlin and others would prefer that the ecosystem address the sustainability challenge publicly, transparently, and collaboratively. "The complexity of the modern supply chain is such that we need a transparent and coordinated approach," said Zemlin. "We need coordinated disclosure of potential vulnerabili- ties. We need free training for maintainers of critical projects. We need regular auditing of specific projects. And in some cases, we need to augment the talent pool available to do the heavy lifting on maintaining critical components."

从源头上，Zemlin等人都更希望生态系统能够公开、透明、合作地应对可持续性挑战。Zemlin说:“现代供应链非常复杂，我们需要一种透明和协作的方法。”“我们需要协调一致地披露潜在的漏洞。我们需要为关键项目的维护人员提供免费培训。我们需要对具体项目进行定期审计。有的时候，我们还需要扩充可用的人才库，以完成维护关键组件的繁重工作。”

With so much at stake, Rod Beckstrom crystallizes the sense of urgency to act. "Global reliability is key," said Beckstrom, who spent much of his time as CEO of ICANN and director of the National Cybersecurity Center wrestling with the thorny issues of Internet governance and cybersecurity. "The market has to step in. Operation Global Blackout from Anonymous was a credible threat. The system is vulnerable, and we need to look closely at the central points of failure. That said, I don't worry too much about the open source systems. The ecosystem is rife with shep- herds and custodians. Open source has added tremendous value to human life. Some people will try to break it. Those efforts will likely fail. Bottom-up will win."

时不我待，Rod Beckstrom深知形势已经迫在眉睫。Beckstro在担任ICANN首席执行官和国家网络安全中心主任期间，耗费大量时间解决互联网治理和网络安全的棘手问题。他呼吁道：“关键是全球化可靠性。” “市场必须介入。来自匿名者的全球封锁行动是对可信化的威胁。这个系统是脆弱的，我们需要密切关注故障的中心点。实际上，我不太担心开源系统。生态系统中到处都是牧羊人和监护人。开源为人们生活带来巨大的价值。有人试图打破它，而这些努力很可能会失败。自下而上才能笑到最后。”

Increasing collaboration on technology policy and regulation

强化在科技政策和监管方面的合作

"The foundations would be much stronger if they worked together." - ALAN CLARKE

“如果他们齐心协力，基础会更加牢固。” ——ALAN CLARKE

Beyond cybersecurity, open source leaders consulted for the study point to a host of other Internet policy issues on which they argue there could be improved collaboration. For example, in critical matters such as intellectual property, privacy, and anti- trust, there is a widely shared view that the open source commu- nity has not been as influential or assertive in technology policy dialogues as it should.

除了网络安全之外，为这项研究提供咨询的开源领导者还指出了许多其他互联网政策问题，他们认为在这些问题上可以改善合作方式。例如，在知识产权、隐私和反垄断等关键问题上，人们普遍认为，开源社区在技术政策对话中没有发挥应有的影响力或判断力。

"Educating politicians can be an uphill battle," said Rod Beckstrom. "They don't always understand the complexities and nuances of Internet infrastructure and the related policy issues. But there is no shortage of critical policy issues where the open source view is needed, including patent issues, privacy, cybersecurity, antitrust, and beneficial AI."

Rod Beckstrom 称：“对政治家进行教育可能会是一场艰苦的战斗。”“他们并不总是理解互联网基础设施和相关政策问题的复杂性和细微差别。但在关键的政策问题上，也不缺乏开源观点，包括专利问题、隐私、网络安全、反垄断和有益的人工智能。”

The absence of a coordinated open source response to such issues has left the playing field open to domination by larger, better-resourced entities. "The big tech players with deep pockets and teams of lobbyists have tended to dominate the policy and regulatory conversations," said Alan Clark of SUSE. Clark says the open source community has been reactive rather than active on most policy issues. He and others would like to see open source foundations come together to propose new policies around security, transparency, privacy, and other pertinent matters. "The foundations would be much stronger if they worked together," said Clark. "The open source point of view is especially relevant today. We need an open source approach to solving global problems."

对上述问题缺乏配套的开源响应，导致竞争环境被规模更大、资源更好的实体所统治。SUSE的Alan Clark 表示：“拥有雄厚财力和游说团队的大型科技公司往往主导着政策和监管对话。”Clark 说，开源社区在大多数政策问题上一直处于被动位置而非主动。他和其他人希望看到开源基金会联合起来，围绕安全、透明、隐私和其他相关问题提出新的政策。Clark 认为：“如果大家合作起来，基础会更加牢固。”“开源的观点在今天尤为重要。我们需要一种开源的方法来解决全球性问题。”

Mike Milinkovich of Eclipse calls the relative absence of open source foundations in crucial policy debates a "sin of omission." "We are not a set of stakeholders that policymakers and politicians are accustomed to dealing with." However, Milinkovich also concedes that the current state of collaboration among open source foun- dations is "abysmal and almost non-existent." "Just looking after our own communities is hard enough," said Milinkovich. "Engaging with our peers is difficult. We don't have a good venue to do it. We also compete for members and projects. The bottom line is that we need to grow up and collaborate."

Eclipse 的 Mike Milinkovich 称，在关键政策辩论过程中，开源基金会的相对缺席是一种“疏忽之罪”。“我们是不政策制定者和政治家习惯于打交道的那种利益相关者。”然而，Milinkovich也承认，目前开源基金会之间的合作状态“糟糕透顶，几乎没有”。Milinkovich 说：“光是照料我们自己的社区就已经很难了。”“与同行交流很困难。我们没有一个合适的地点。我们还竞争会员和项目。唯独底线是需要成长和合作。”

"We need a repeatale and trustable process that achieves public policy goals through open source innovation." - GABRIELE COLUMBRO

“我们需要一个可复现、可信赖的流程，从而通过开源创新实现公共政策目标。” ——GABRIELE COLUMBRO

Jim Zemlin agrees that the foundations don't have a stellar track record of collaboration. However, he points out that open source is on the radar in the wake of the Log4Shell vulnerabilities. "Going forward, we have an opportunity to be much more influential in guiding the evolution of the Internet," said Zemlin. Mike Dolan adds that much of the behind-the-scenes work the Linux Foundation does may not be visible because it is not set up or resourced to be a full-time government education organization. "We do not have government education staff sitting full time in Washington, or Brussels, or Beijing, or Tokyo," said Dolan, "but we are here to protect the ability of open source communities to collaborate and thrive. We channel our members, brands, and capabilities into those efforts. I think it's been quite effective. Open source com- munities have been active since 1990, and, in that time, there has been no policy that killed open source. The reality is that we have big defenders. Microsoft, IBM, Red Hat, Google, Oracle, Intel, and others are equipped to stand up to the U.S. government if they try to do something that threatens the open source collaboration underpinning multi-billion dollar businesses they can't just walk away from."

Jim Zemlin 也认为，这些基金会在合作方面没有出彩的历史。然而，他同时指出，随着Log4Shell漏洞的出现，开源正在受到关注。Zemlin 说：“展望未来，我们有机会在引导互联网发展方面发挥更大的影响力。” Mike Dolan 补充到，Linux 基金会所做的许多幕后工作可能不为人所知，因为它不是一个全职的政府教育组织。“我们没有在华盛顿、布鲁塞尔、北京或东京从事全职工作的政府教育人员，” Dolan 说，“但我们在这里是为了保护开源社区合作和繁荣发展的能力。我们将会员、品牌和能力输送到这些努力之中。我认为这很有效。开源社区自1990年以来一直很活跃，并且从那时起，没有任何政策会扼杀开源。实际上我们有强大的守护者。微软、IBM、红帽、谷歌、甲骨文、英特尔和其他公司都有能力对抗美国政府，如果政府试图做一些事情，威胁到支持数十亿美元业务的开源合作，这些企业就不能坐视不管。”

Beckstrom argues that the open source community could increase its policy influence through lightweight coordination. "Convene a regular meeting circle of top foundation leaders," said Beckstrom. "Create a dialogue among the leaders, and identify the shared issues on which the ecosystem could collectively assert its voice. Then create a circle of the chief legal counsels. There could be a benefit from further collaboration between the policy leads."

Beckstrom认为，开源社区可以通过轻量级协调来增强其政策影响力。Beckstrom说：“召集顶级基金会领导者的定期会议。在领导者之间创建对话，并确定生态系统可以共同发声的共同问题。然后创建首席法律顾问的圈子。政策领域的进一步协作可能会带来益处。”

Astor Nummelin Carlberg of OpenForum Europe notes that there are challenges on the governmental side as well. "In Europe, we work with the European Commission around issues ranging from product safety to cybersecurity to privacy," said Carlberg. "However, many policies and regulations in those domains are still driven by national bodies. It requires a lot of resources and staffing to participate in policy deliberations across so many individual nation-states." Carlberg argues that creating OSPOs at the national level could provide an interface for discussions around policy and regulation and notes that France has built one and Germany is in the process of doing so. "We won't have a coherent voice if we work company-by-company and foundation-by-foundation."

OpenForum Europe的Astor Nummelin Carlberg指出，政府方面也存在挑战。Carlberg说：“在欧洲，我们与欧洲委员会合作解决从产品安全到网络安全和隐私等一系列问题。然而，许多政策和法规在这些领域仍然由国家机构推动。参与许多单独的国家政策讨论需要大量的资源和人员配备。” Carlberg认为，在国家层面创建OSPO可以为政策和法规讨论提供接口，并指出法国已经建立了一个OSPO，德国正在进行这样的工作。Carlberg表示：“如果我们逐个公司和基金会开展工作，我们将没有一个连贯的声音。”

More broadly, there is a global opportunity for the OSS community to position itself as a rich source of solutions for public policy issues. "The biggest frontier for open source is in the public sphere," said Gabriele Columbro of FINOS and Linux Foundation Europe. "The Linux Foundation has perfected its governance models for enabling collaboration with corporations and individuals. We need a similar model and pattern of engagement with the public sector." Columbro points to digital public services, healthcare, education, and climate change as significant opportunity spaces for open source solutions. "We need a repeatable and trustable process that achieves public policy goals through open source innovation."

进一步讲，OSS社区有一个全球化的机会，可以将自己定位成为公共政策问题解决方案的丰富来源。FINOS 和 Linux 欧洲基金会的Gabriele Columbro 说:“开源最大的前沿是在公共领域。”“Linux 基金会已经完善了与公司及个人合作的治理模型。我们需要与公共机构建立类似的合作模式。”Columbro 指出，数字公共服务、医疗保健、教育和气候变化是开源解决方案的重要机会领域。”“我们需要一个可重复和可信赖的过程，通过开源创新来实现公共政策目标。”

Conclusion

结论

In its purest form, OSS development is a way of producing software that relies entirely on self-organizing communities of individuals who come together voluntarily to work on a software project. However, most successful OSS communities mix elements of hierarchy and self-organization and rely on meritocratic principles of organiza- tion. In other words, the most skilled and experienced community members provide leadership and help integrate contributions from the community.

在其最纯粹的形式中，开源软件开发是一种完全依靠自我组织的个人社区自愿聚集在一起工作的方式。然而，大多数成功的开源社区都混合了等级制度和自我组织的元素，并依赖于组织的精英主义原则。换句话说，最有技能和经验的社区成员提供领导，并帮助整合社区的贡献。

This combination of decentralized innovation and effective leadership is integral to the long-term viability and success of open source projects. As Professor Christopher Yoo put it, "Success of an open source project depends on inspiring a community of people willing to work on it. In a real sense, an open source leader's authority depends on the existence of followers. In a world where all contributions are voluntary, and the community is always free to exit the community by forking the project, leaders' ability to retain their positions depends largely on their responsiveness to the needs of those led. These needs include providing fast feedback, serving as an effective moderator of technical disputes and personality conflicts, and realistic interim and long-term goals."³⁰

这种分散式创新和有效的领导力的结合对于开源项目的长期生存能力和成功至关重要。正如 Christopher Yoo 教授所说：“开源项目的成功取决于激发一群愿意为之工作的人的社区。从某种意义上说，开源领导者的权威性取决于追随者的存在。在所有贡献都是自愿的、社区始终可以通过分叉项目自由退出的世界中，领导者保留其职位的能力在很大程度上取决于他们对被领导者需求的反应性。这些需求包括提供快速反馈、作为技术争议和个性冲突的有效调解者、以及制定现实的中期和长期目标。” ³⁰

The Linux ecosystem provides an excellent example of how leader- ship and strong governance can reduce fragmentation. In the early days of Linux, Linus Torvalds' role as the project leader was instru- mental in averting the risk of fragmentation and project forking.

Linux生态系统提供了一个极好的例子，说明领导力和强有力的治理可以减少分裂。在Linux的早期，Linus Torvalds作为项目领导者的角色对避免分裂和项目分叉的风险起了重要作用。

Torvalds' status as Linux's creator made him the natural person to exercise authority over the community. When required, Torvalds did not hesitate to take action to prevent significant forks from emerging. However, he bolstered his authority by taking great care to document and justify his decisions. His dedication and sound judgment in managing the community fostered considerable goodwill, as did his deft touch in handling community politics and interpersonal dynamics. Ultimately, that transparency also enabled Linus to delegate decisionmaking for the codebase to core maintainers, who have over decades grown to be the core engine of contribution to and maintenance of the modern Linux kernel.

Torvalds 作为 Linux 的创始人，天然地成为行使社区权威的人。在需要时，Torvalds毫不犹豫地采取行动，防止出现重大分叉。然而，他通过认真记录和证明自己的决策来增强自己的权威性。他在管理社区方面的奉献精神和明智的判断力，培养了相当多的善意，他在处理社区政治和人际动态方面的娴熟手法也赢得了赞誉。最终，这种透明度也使Linus能够将代码库的决策委托给核心维护人员，他们在几十年的时间里成为现代Linux内核贡献和维护的核心引擎。

As Professor Yoo concludes, "To say that open source projects require a type of leadership that is somewhat different from the leadership that characterizes commercial companies that produce proprietary software is not to say that they need no leadership at all. On the contrary, ensuring that an open source platform does not fragment depends on the presence of an actor with sufficient authority to resolve disputes and to steer the platform in a beneficial direction."³¹

正如 Yoo 教授所总结的：“说开源项目需要的领导方式与生产专有软件的商业公司的领导方式有所不同，并不意味着它们不需要领导。相反，确保开源平台不会分裂取决于一个具有足够权威来解决争端并将平台引导到有益方向的行动者的存在。”³¹

In discussions for the study, open source leaders offered several additional concrete recommendations to address some of the pain points described in this report. We divide the recommendations into two broad categories: a) managing fragmentation in the development and governance of open source solutions and b) confronting techno-nationalism and fostering global inclusion.

在研究讨论中，开源领袖提供了几个额外的具体建议，以解决本报告中描述的一些痛点。我们将这些建议分为两大类：a) 管理开源解决方案的开发和治理中的分裂，b) 应对技术民族主义并促进全球包容。

Managing fragmentation

管理分裂

The recommendations for managing fragmentation in the development and governance of open source solutions include forging greater alignment between open source projects, strengthening inter-foundation collaboration, and harnessing open source maturity models to help identify robust code libraries and components.

管理开源解决方案开发和治理中的分裂的建议包括加强开源项目之间的协调，加强基金会间的合作，利用开源成熟度模型来帮助识别稳健的代码库和组件。

HARNESS MATURITY MODELS

利用成熟度模型

While open source leaders acknowledge some fragmentation-related challenges, they warn that "solving" the fragmentation problem risks killing the goose that laid the golden egg. "When people perceive fragmentation, they often look at it from a consumer point of view," said Mike Milinkovich of the Eclipse Foundation. "They see a broad landscape of possible solutions and wonder what is safe, what is supported, and what is sustainable." Rather than "solving fragmentation," Milinkovich and others suggest that an open source maturity model would make it easier to identify robust code libraries and components and thus focus the community's efforts. As Mike Dolan put it, "The proliferation of open source projects is not necessarily bad. It just means that there are many options out there. It also means that we need better filters to make it easy for developers and end users to discover the little modules that do things that are useful for them."

虽然开源领袖们承认了一些与分裂相关的挑战，但他们警告说，“解决”分裂问题可能会毁掉下金蛋的鹅。 “当人们看到分裂时，他们通常会从消费者的角度来看待它，” Eclipse基金会的Mike Milinkovich说道，“他们看到了许多可能的解决方案，想知道什么是安全的，什么是得到支持的，什么是可持续的。” Milinkovich和其他人建议，与其“解决分裂”，不如采用开源成熟度模型来更容易地识别出稳健的代码库和组件，从而集中社区的努力。正如Mike Dolan所说，“开源项目的扩散不一定是坏事，这只是意味着有很多选择。这也意味着我们需要更好的过滤器，以便开发人员和最终用户可以发现对他们有用的小模块。”

ENLIST SKILLED COMMUNITY MANAGERS

征召熟练的社区经理

If effective leadership is integral to successful open source projects, then skilled community managers are the foot soldiers for building high-performing collaboration networks.

如果有效的领导是成功的开源项目的不可或缺的一部分，那么有技能的社区经理是构建高效协作网络的步兵。

Unfortunately, in a world dominated by proprietary technologies, few people understand how to create and grow an open source ecosystem. However, Calista Redmond of RISC-V points out that technologists are adapting to a new way of working as open stan- dards increasingly overtake proprietary approaches. "Ethernet is a great example," said Redmond, "where proprietary approaches are now nearly nonexistent." Redmond and her colleagues have built the RISC-V community from scratch to become the world's most popular open and widely used microprocessor instruction set architecture standard. Along the way, RISC-V encountered numerous concerns about forking, especially when companies in the ecosystem identified missing pieces and had the temptation to develop proprietary solutions.

不幸的是，在一个被专有技术主导的世界里，很少有人了解如何创建和发展开源生态系统。然而，RISC-V 的 Calista Redmond 指出，随着开放标准逐渐取代专有方法，技术人员正在适应新的工作方式。“以太网就是一个很好的例子，”Redmond说，“在那里，专有方法现在几乎不存在了。”Redmond 和她的同事们从零开始建立了RISC-V社区，成为了全球最受欢迎的开放式和广泛使用的微处理器指令集架构标准。在此过程中，RISC-V 遇到了许多关于分叉的问题，特别是当生态系统中的公司发现缺失的部分并有诱惑开发专有解决方案时。

To avoid fragmentation in the community, Redmond and her team work hard to gather participants and align efforts on the missing pieces. "We have to run really fast to catch up with our community," said Redmond. "It's a different skill set. Most people have built proprietary strongholds. We need people who know how to orchestrate true collaboration. Our CTO comes from Sun Microsystems, where he was responsible for Solaris. He is very community-oriented. You need to find those people with the skills for ecosystem leadership."

为了避免社区的分裂，Redmond 和她的团队努力汇集参与者，并协调努力解决缺失的部分。Redmond 说，“我们必须跟上我们的社区。”这需要不同的技能。大多数人都建立了专有领地，我们需要那些知道如何协调真正协作的人。我们的首席技术官来自 Sun Microsystems，在那里他负责Solaris。他非常注重社区。你需要找到那些具备生态系统领导技能的人。

ALIGN OPEN SOURCE PROJECTS AROUND SHARED GOALS

将开源项目围绕共同目标进行整合

Open source foundations are reluctant to play a lead role in identi- fying and championing winning open source projects, arguing that picking winners is a marketplace function. However, leaders do see a need for better project curation and want foundations and other ecosystem participants to make greater efforts to align projects with similar objectives. "We nurture multiple projects, and some- times they overlap," said Gabriele Columbro, general manager of Linux Foundation Europe. "But the most mature foundations have a project life cycle where they can help coalesce efforts and even consolidate projects." Columbro says that survival of the fittest, or "open source Darwinism," will usually dictate which projects are ultimately sustainable. However, he and other open source leaders agree that bringing similar projects under a shared umbrella can eliminate duplication, economize overhead, and reduce so-called "vendor fatigue." In some instances, foundations could also do a better job killing or archiving projects. "We are very good at bringing projects in," said Columbro. "But it's equally important we do a great job cycling projects through the life cycle and shelving projects when necessary."

开源基金会不愿扮演识别和推广优胜开源项目的主导角色，他们认为挑选优胜者是市场的职能。然而，领导人们认为需要更好的项目筛选，并希望基金会和其他生态系统参与者在更好地将项目与相似目标对齐方面做出更大努力。Linux基金会欧洲的总经理 Gabriele Columbro 表示：“我们培养多个项目，有时它们会重叠。但最成熟的基金会都有一个项目生命周期，在那里他们可以帮助凝聚努力，甚至整合项目。” Columbro 说，适者生存或“开源达尔文主义”通常决定哪些项目最终是可持续的。然而，他和其他开源领导人都同意，将类似的项目纳入一个共享的伞下可以消除重复、节约开销并减少所谓的“供应商疲劳”。在某些情况下，基金会还可以更好地关闭或归档项目。Columbro 说：“我们很擅长引入项目。但同样重要的是，我们要在适当的时候将项目引导通过生命周期，并对其进行归档。”

STRENGTHEN INTER-FOUNDATION COLLABORATION ON ECOSYSTEM CHALLENGES

加强基金会间在生态系统挑战方面的合作

The need for enhanced collaboration between open source projects and foundations extends to other priorities for the ecosys- tem, including joint efforts to advance open source advocacy on a range of Internet governance issues. Mark Surman of the Mozilla Foundation said foundation leaders could leverage the communi- ty's shared values as a starting point for collaboration. "The open source community is united by core values such as independence, decentralization, public assets, and public benefits," said Surman. "In essence, we agree on the vital role of the commons." The next step is to convene the foundation leaders and work together to identify shared policy goals. "What are possible threads of unity, and to what ends should we pull them?" asks Surman.

加强开源项目和基金会之间的协作需要在生态系统的其他优先事项方面，包括联合努力推进一系列互联网治理问题的开源倡导工作。Mozilla 基金会的 Mark Surman 表示，基金会领导人可以利用社区的共同价值观作为合作的起点。“开源社区的核心价值观，如独立性、去中心化、公共资产和公共利益，使我们团结在一起，” Surman 说。“实际上，我们都认同公共资源的重要作用。”下一步是召集基金会领导人并共同努力，以确定共享政策目标。“我们可以找到哪些团结的纽带，并达到什么目的呢？”Surman问道。

One goal that all ecosystem leaders agree on is the need to build trust and confidence in OSS and support the ongoing maintenance of critical open source infrastructure. "The cybersecurity order from the White House has put the ecosystem on notice," said Jerry Cuomo of IBM. "Now, the stewards of open source need to step up. It would be huge if the community had a shared ledger and audit system where we could demonstrate that the software is robust and secure. We need a transparent, ecosystem-wide view of our vulnerabilities, and we need to be able to predict potential problems. That's an OSS service that the community can trust."

所有生态系统领导者都同意一个目标，即需要建立对开源软件的信任和信心，并支持关键开源基础设施的持续维护。 "来自白宫的网络安全令让生态系统警觉起来，" IBM 的 Jerry Cuomo 表示。 "现在，开源软件的管理者需要站出来。如果社区拥有一个共享的分类账和审计系统，能够证明软件是强大和安全的，那将是巨大的。我们需要一个透明、全生态系统范围内的漏洞视图，并且我们需要能够预测潜在问题。这是社区可以信任的开源软件服务。"

Open source security and sustainability are top of mind, but eco- system leaders point to various policy issues on which open source foundations could find common ground. "The foundations should do more to educate policymakers and work on shared issues such as data security, intellectual property, antitrust, and privacy, among other things," said Peixin Hou of Huawei. "We urgently need global action on these issues."

开源安全和可持续性是当前的主要问题，但是生态系统领导者指出，开源基金会可以在数据安全、知识产权、反垄断和隐私等共同关注的政策问题上找到共同点。 "基金会应该更多地教育决策者，共同解决诸如数据安全、知识产权、反垄断和隐私等问题，" 华为的 Peixin Hou 表示。 "我们迫切需要全球性的行动来解决这些问题。"

Confronting techno-nationalism and fostering global inclusion

应对技术民族主义和促进全球包容

The recommendations for confronting techno-nationalism and fostering global inclusion include positioning foundations as neutral actors, building reputation frameworks and audit systems for open source code, and creating tools and protocols for inte- grating diverse contributors into open source communities.

应对技术民族主义和促进全球包容的建议包括将基金会定位为中立的参与者、建立针对开源代码的声誉框架和审计系统，以及创建整合多元贡献者到开源社区的工具和协议。

BUILD REPUTATION FRAMEWORKS

建立声誉框架

Adherence to transparent and secure development protocols is, ultimately, the best antidote to fears that national interests could taint or even corrupt open source projects. "To counter the tech- no-nationalism, we need to instill trust in the software develop- ment process," said Jim Zemlin. For example, Zemlin proposes the creation of reputation frameworks with better peer review and third-party audits. "We need trust networks that are transparent and scalable enough to work across open source communities," said Zemlin. "You can think of it as a liquidity of trust. Where you are from and whom you work for are not as relevant as knowing that your work is trustworthy and high-quality. It's the code that is vital. So we need a reputation framework for the codebase."

遵循透明和安全的开发协议，最终是消除国家利益可能玷污或甚至破坏开源项目的最佳解决方案。"为了抵制技术民族主义，我们需要在软件开发过程中建立信任,"Jim Zemlin 说。例如，Zemlin 建议创建具有更好的同行评审和第三方审计的声誉框架。"我们需要透明和可扩展到所有开源社区的信任网络，" Zemlin说。"你来自哪里，以及你为谁工作并不重要，知道你的工作是值得信任和高质量的才是重要的。所以我们需要针对代码库的声誉框架。"

POSITION FOUNDATIONS AND PROJECTS AS NEUTRAL ACTORS

将基金会和项目定位为中立参与者

In addition to reputation frameworks, positioning open source foundations and projects as impartial actors is critical to creating a neutral home for global collaboration. Establishing neutral, inclusive, and transparent structures for collaboration will not only broaden participation but can also reduce incentives for ecosystem participants to create parallel efforts. Reflecting on his work at ICANN, Rod Beckstrom said his number-one job was building a neutral zone in the domain name system that holds the Internet together. "We did everything we could to bring China and Russia into the tent," said Beckstrom. "We were doing it for the global community. Otherwise, we are starting from a position of mistrust." Likewise, building confidence in ICANN's protocols and decision-making process was critical to creating a produc- tive relationship with countries that were suspicious of American dominance of Internet governance. "As long as the system works openly and fairly, everyone can participate," said Beckstrom. "The Internet is a global infrastructure---it must remain neutral. It's to the benefit of the world."

除了声誉框架之外，将开源基金会和项目定位为公正的参与者对于创建全球合作的中立家园至关重要。建立中立、包容和透明的合作结构不仅可以扩大参与度，还可以减少生态系统参与者创建平行努力的动机。在回顾他在 ICANN 的工作时，Rod Beckstrom 说他的首要工作是在维持互联网的域名系统中建立一个中立区域。"我们尽了一切努力将中国和俄罗斯纳入帐篷，" Beckstrom说。"我们为全球社区而这么做。否则，我们将从不信任的立场开始。"同样，建立对 ICANN 协议和决策过程的信心对于与对美国互联网治理主导怀有怀疑态度的国家建立富有成效的关系至关重要。"只要系统公开、公正，每个人都可以参与，" Beckstrom 说。"互联网是全球基础设施——必须保持中立。这对世界有利。"

EDUCATE POLICYMAKERS ABOUT THE DOWNSIDES OF TECHNO-NATIONALISM

教育决策者有关技术民族主义的弊端

To combat techno-nationalism, ecosystem leaders must convince policymakers that restricting the transfer of critical innovations across national borders is paradoxical and self-defeating in a world where cross-border collaborations are the backbone of countless innovation communities. Calista Redmond and others argue that open source and global standards provide a superior path for both local and global economic growth because global collaboration leads to global markets with long-term strategic importance. “Every country has a home-team bias, but the growing techno-nationalism is a major concern,” said Redmond. “We need to educate the community and the policymakers about the downsides of techno-nationalism. Countries can fund companies and initiatives locally, but they must participate globally. Countries won’t be successful if they close off collaboration at national borders.” Columbro even adopted that perspective as a motto to define the mission of Linux Foundation Europe: “Collaborate locally, innovate globally.”

为了应对技术民族主义，生态系统领袖必须说服政策制定者，限制跨国界传递关键创新是矛盾和自我毁灭的，因为跨国界合作是无数创新社区的支柱。Calista Redmond 和其他人认为，开源和全球标准为本地和全球经济增长提供了更优越的道路，因为全球合作导致具有长期战略重要性的全球市场。Redmond 表示：“每个国家都有一种本土偏见，但不断增长的技术民族主义是一个重大问题。我们需要教育社区和政策制定者关于技术民族主义的不利因素。国家可以在本地资助公司和计划，但必须全球参与。如果关闭国家边界上的合作，国家就不会成功。” Columbro 甚至将这一观点作为 Linux 基金会欧洲定义使命的座右铭：“本地合作，全球创新。”

CREATE THE CONDITIONS TO INTEGRATE DIVERSE CONTRIBUTORS

创造条件以整合不同贡献者

The challenges of integrating different languages and cultures into open source communities are not new problems, and there is considerable confidence in the ecosystem's capacity to foster global inclusion. As Stormy Peters at GitHub explains, "The open source community has been integrating diversity for a long time. We have people contributing from across Europe, Asia, Africa, and South America. We have always understood the importance of international networks and communications, even more than the corporate community. We have leveraged asynchronous commu- nications to address the fact that users in some regions had less Internet bandwidth."

将不同语言和文化融入开源社区的挑战并不是新问题，生态系统在促进全球包容方面有相当的信心。正如 GitHub 的Stormy Peters所解释的那样，“开源社区一直在整合多样性。我们有来自欧洲、亚洲、非洲和南美的贡献者。我们一直理解国际网络和通信的重要性，甚至比企业社区更重要。我们利用异步通信来解决一些地区用户的互联网带宽较低的问题。”

The sheer number of people that GitHub and other organizations are onboarding into the global open source community provides proof of the ecosystem's progress in integrating diverse contributors. "We have proven that open source projects can operate globally," said Peters. "We are working effectively across regions and in multiple languages. We are creating OSPOs to structure the engagement of companies and organizations with the open source community."

GitHub 和其他组织吸纳到全球开源社区的人数之多，证明了这个生态系统在整合不同贡献者方面取得了进展。“我们已经证明开源项目可以在全球范围内运作，” Peters 表示。“我们在跨区域和多语言方面的合作非常有效。我们正在创建 OSPO 来规范公司和组织与开源社区的互动。”

Open source leaders agree, however, that the community can do more to promote global inclusion. For example, open source leaders underlined the need to invest in rapid machine translation capabilities for project communications. Open source leaders also discussed the importance of promoting open source norms, taming the industry's macho "bro" culture, and fostering professionalism in community dialogues and decision-making. Finally, collaboration platforms such as GitHub can enable open source communities to integrate diverse contributions at scale. Key advances in the GitHub platform include new tools to improve collaboration, translate mate- rials, and monitor the productivity and engagement of community members. "We believe we have the tools to bring open source col- laboration to a new level," said Peters.

然而，开源领导人们认为社区可以做更多来促进全球包容。例如，开源领导人强调了投资于快速机器翻译能力以进行项目通信的必要性。开源领导人还讨论了在社区对话和决策中促进开源规范、驯服行业的“兄弟文化”和培养专业精神的重要性。最后，GitHub 等协作平台可以使开源社区在规模上整合多样化的贡献。GitHub 平台的关键进展包括新工具来改进协作、翻译材料以及监测社区成员的生产力和参与度。“我们相信我们有工具可以将开源协作提升到一个新的水平，” Peters 说道。

Final thoughts

总结

By any yardstick, OSS is wildly successful. Hundreds of millions of users of set-top boxes, smart fridges, and other home appli- ances use OSS, and billions of people use it indirectly whenever they access Google, Facebook, or the myriad of other apps and websites. Whether you drive a Tesla, Toyota, or Mercedes, chances are very high it's running Linux and open source in the back- ground.³² So too are the supercomputers that power everything from advanced climate models to AI-enabled drug discovery and other scientific pursuits, such as astronomy, meteorology, and nuclear physics.³³

无论用什么标准来衡量，开源软件系统都非常成功。数亿用户使用机顶盒、智能冰箱和其他家用电器使用 OSS，而数十亿人在访问Google、Facebook 或无数其他应用程序和网站时也在间接使用 OSS。无论你开特斯拉、丰田还是奔驰，它背后很有可能都在运行Linux和开源软件。³² 超级计算机也是如此，它们为从先进气候模型到支持AI药物发现和其他科学研究（如天文学、气象学和核物理学）的一切提供动力。³³

The global open source community powering these innovations is encountering some inevitable fragmentation. Some of the frag- mentation in software development is essential to how the open source community functions. A globally decentralized ecosystem may produce some overlap, but its constant churn of incremen- tal innovation and improvement has yielded a vast reservoir of software building blocks for the digital economy.

支持这些创新的全球开源社区遇到了一些不可避免的分化。软件开发中的一些分化对于开源社区的运作至关重要。全球分裂的生态系统可能会产生一些重叠，但其不断的渐进式创新和改进已经产生了一个庞大的软件构建块库，为数字经济提供支持。

In other instances, fragmentation in the community is creating needless redundancy, driving up costs and complexity for producers and consumers alike. Worst of all, intensifying techno- nationalism could introduce new geopolitical fault lines, disrupting the free flow of ideas and restricting the community's access to talented developers.

在其他情况下，社区的分化正在创造不必要的冗余，增加生产者和消费者的成本和复杂性。最糟糕的是，日益加剧的技术民族主义可能会引入新的地缘政治断层，扰乱思想的自由流动，并限制社区获取才华横溢的开发人员的能力。

Now it is up to the community of developers, public and private sector organizations, companies, foundations, and beyond to continue to push for global collaboration. The open source commu- nity is larger, more diverse, and more capable than ever, but its progress is not forever inevitable. It is incumbent upon the commu- nity's leaders to take the necessary steps to continue these trendlines into the future.

现在，推动全球合作的责任在于开发者社区、公共和私营部门组织、公司、基金会等等。开源社区比以往任何时候都更加庞大、多样化和能力强大，但其进步并非永远不可避免。社区的领导者有责任采取必要的步骤，将这些趋势延续到未来。

About the Author

关于作者

Anthony is the founder and president of the DEEP Centre and an internationally recognized authority on the digital revolution, innovation, and creativity in business and society. He is co-au- thor (with Don Tapscott) of the groundbreaking bestseller Wikinomics and its follow-up Macrowikinomics: New Solutions for a Connected Planet.

Anthony 是 DEEP Centre 的创始人和总裁，是商业和社会中数字革命、创新和创造力的国际公认权威人士。他与Don Tapscott 合著了划时代的畅销书《维基经济学》及其续集《大维基经济学：连接星球的新解决方案》。

Among other appointments, Anthony serves as a research director with the Blockchain Research Institute, an expert advisor to the Markle Foundation's Initiative for America's Economic Future, and a senior fellow with the Lisbon Council in Brussels. Anthony was recently a committee member of the National Research Council's Committee on Science for the EPA's Future, a visiting fellow with the Munk School of Global Affairs at the University of Toronto, and chief advisor to Brazil's Free Education Project. His work on technol- ogy and innovation has been featured in publications such as the Harvard Business Review, the Huffington Post and The Globe and Mail.

除了其他职务外， Anthony 还担任区块链研究所的研究主任，马克尔基金会美国经济未来计划的专家顾问，以及位于布鲁塞尔的里斯本理事会的高级研究员。 Anthony 最近是美国国家研究委员会“未来环保科学委员会”的委员、多伦多大学蒙克全球事务学院的访问学者以及巴西自由教育项目的首席顾问。他的技术和创新工作曾在《哈佛商业评论》、《赫芬顿邮报》和《环球邮报》等出版物中受到关注。

Endnotes

脚注

Futurewei maintains ongoing, in-depth collaboration with forward-thinking companies worldwide.

Futurewei 与全球前瞻性公司保持着持续深入的合作关系。

We pursue openness in research and development (R&D) by embracing an open innovation model and striving to share ideas and knowledge with technology communities to create new business opportunities.

我们通过采用开放式创新模式和努力与技术社区分享想法和知识以创建新的业务机会来追求研究和开发中的开放性。

Our vision is Shaping the Future Toward a Fully Connected, Intelligent World.
Our mission is Developing Innovations to Benefit an Intelligent and Digital Society via Open Source, Standardization, and Collaboration within Ecosystems.
我们的愿景是“引领未来走向完全连接的智能世界。”
我们的使命是“通过开放源代码、标准化和生态系统内的协作开发创新，造福智能数字社会。”

Our experts have actively engaged in standards programs for the past two decades. Through this work, we participate in developing next- generation wireless technologies and networks and building open ecosystems through open application platforms for ICT systems.

我们的专家已经积极参与标准化计划已有二十年。通过这项工作，我们参与开发下一代无线技术和网络，并通过开放应用平台为ICT系统建立开放的生态系统。

www.futurewei.com

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

Linux 基金会研究成立于2021年，探索了开源协作的不断扩大规模，提供有关新兴技术趋势、最佳实践和开源项目的全球影响的见解。通过利用项目数据库和网络，以及承诺采用数量和质量方法的最佳实践，Linux 基金会研究正在为全球组织创建开源洞察的权威库。

twitter.com/linuxfoundation

facebook.com/TheLinuxFoundation

linkedin.com/company/the-linux-foundation

youtube.com/user/TheLinuxFoundation

github.com/LF-Engineering

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

本报告采用知识共享署名-禁止演绎 4.0 国际公共许可证授权。

To reference the work, please cite as follows: Anthony Williams, "Enabling Global Collaboration: How Open Source Leaders Are Confronting the Challenges of Fragmentation," The Linux Foundation, January, 2023.

引用本文，请使用以下格式：Anthony Williams，“Enabling Global Collaboration: How Open Source Leaders Are Confronting the Challenges of Fragmentation，”The Linux Foundation，2023年1月。

Copyleft和GNU通用公共许可证：全面教程和指南

2023年3月25日 · 阅读需 986 分钟

Copyleft和GNU通用公共许可证：全面教程和指南

The copyright holders grant the freedom to copy, modify, convey, adapt, and/or redistribute this work (except Appendices [B][--E]) under the terms of the Creative Commons Attribution Share Alike 4.0 International License. A copy of that license is available at (https://creativecommons.org/licenses/by-sa/4.0/legalcode).

版权持有者授予自由复制，修改，传播，适应和/或重新分发本作品（除附录B--E外），根据知识共享署名相同4.0国际许可协议的条款。该许可证的副本可在https://creativecommons.org/licenses/by-sa/4.0/legalcode找到。

Appendices [B--E] include copies of the texts of various licenses published by the FSF, and they are all licensed under the license, "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.". However, those who seek to make modified versions of those licenses should note the explanation given in the GPL FAQ.

附录B--E包括由FSF发表的各种许可证的文本副本，它们都在许可证下许可，“每个人都被允许复制和分发本许可证文件的逐字副本，但不允许更改。”但是，那些试图制作修改版本的许可证的人应注意GPL FAQ中给出的解释。

As a public, collaborative project, this Guide is primarily composed of the many contributions received via its public contribution process. Please review its Git logs for full documentation of all contributions, and Appendix [A] contains a list of third-party works from which some material herein was adapted.

作为公共协作项目，本指南主要由通过其公共贡献过程接收到的许多贡献组成。请查看其Git日志以获取所有贡献的完整文档，附录A包含了一些本文所述材料的第三方作品列表。

The most recent version is available online at (https://copyleft.org/guide/>. Patches are indeed welcome to this material. Sources can be found in the Git repository at (https://k.copyleft.org/guide/>.

PREFACE

前言

This tutorial is the culmination of nearly a decade of studying and writing about software freedom licensing and the GPL. Each part of this tutorial is a course unto itself, educating the reader on a myriad of topics from the deep details of the GPLv2 and GPLv3, common business models in the copyleft licensing area (both the friendly and unfriendly kind), best practices for compliance with the GPL, for engineers, managers, and lawyers, as well as real-world case studies of GPL enforcement matters.

这篇教程是近十年来关于自由软件许可和GPL的研究和写作的总结。本教程的每一部分都是一个独立的课程，向读者介绍了许多主题，包括GPLv2和GPLv3的深入细节、copyleft许可证领域常见的商业模式（友好和不友好的类型）、工程师、经理和律师遵守GPL的最佳实践，以及GPL执法事项的实际案例研究。

It is unlikely that all the information herein is necessary to learn all at once, and therefore this tutorial likely serves best as a reference book. The material herein has been used as the basis for numerous live tutorials and discussion groups since 2002, and the materials have been periodically updated. They likely stand on their own as excellent reference material.

一次性学习所有的信息是不太可能的，因此本教程最好作为参考书使用。自2002年以来，这些材料已经被用作许多现场教程和讨论小组的基础，并且这些材料定期更新。它们可能作为优秀的参考材料独立存在。

However, if you are reading these course materials without attending a live tutorial session, please note that this material is merely a summary of the highlights of the various CLE and other tutorial courses based on this material. Please be aware that during the actual courses, class discussion and presentation supplements this printed curriculum. Simply reading this material is not equivalent to attending a course.

但是，如果你在没有参加现场教程的情况下阅读这些课程材料，请注意，这些材料仅是基于这些材料的各种CLE和其他教程课程的亮点摘要。请注意，在实际课程中，课堂讨论和演示会补充这个印刷课程。仅仅阅读这些材料是不能等同于参加课程的。

第一部分：GNU GPL 及相关许可证的详细分析

This part of the tutorial gives a comprehensive explanation of the most popular Free Software copyright license, the GNU General Public License ("GNU GPL", or sometimes just "GPL") -- both version 2 ("GPLv2") and version 3 ("GPLv3") -- and teaches lawyers, software developers, managers and business people how to use the GPL (and GPL'd software) successfully both as a community-building "Constitution" for a software project, and to incorporate copylefted software into a new Free Software business and in existing, successful enterprises.

本教程的这一部分对最流行的自由软件版权许可证，即GNU通用公共许可证（“GNU GPL”，有时简称为“GPL”）——第2版（“GPLv2”）和第3版（“GPLv3”）——进行了全面的解释，引导律师、软件开发人员、管理人员和业务人员如何成功地使用GPL（以及GPL软件），将其作为软件项目的社区建设“章程”，并将著佐权(copylefted)的软件合并到新的自由软件业务和现有的成功企业中。

To benefit from this part of the tutorial, readers should have a general familiarity with software development processes. A basic understanding of how copyright law applies to software is also helpful. The tutorial is of most interest to lawyers, software developers and managers who run or advise software businesses that modify and/or redistribute software under the terms of the GNU GPL (or who wish to do so in the future), and those who wish to make use of existing GPL'd software in their enterprise.

为了从教程的这一部分中受益，读者应该对软件开发过程有一个大致的了解。对版权法如何适用于软件的基本理解也很有帮助。本教程最感兴趣的是律师、软件开发人员和管理人员，他们经营软件业务，建议根据GNU GPL条款修改和/或重新分发软件（或希望在将来这样做），还有那些希望在他们的企业中使用已有的GPL软件的人。

Upon completion of this part of the tutorial, readers can expect to have learned the following:

看完本教程的这一部分后，读者可以期望学到以下内容：

The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.
The differences between GPLv2 and GPLv3.
The redistribution options under the GPLv2 and GPLv3.
The obligations when modifying GPLv2'd or GPLv3'd software.
How to build a plan for proper and successful compliance with the GPL.
The business advantages that the GPL provides.
The most common business models used in conjunction with the GPL.
How existing GPL'd software can be used in existing enterprises.
The basics of LGPLv2.1 and LGPLv3, and how they differ from the GPLv2 and GPLv3, respectively.
The basics to begin understanding the complexities regarding derivative and combined works of software.
GNU GPLv2和GPLv3中各种术语，目的是捍卫自由；
GPLv2和GPLv3的区别；
基于GPLv2和GPLv3的再分发选项；
修改GPLv2或GPLv3软件时应遵循的义务；
如何制定计划以正确且成功地遵守GPL协议；
GPL提供的业务优势；
与GPL结合使用的最常见的商业模式；
企业如何使用已有的GPL软件；
LGPLv2.1和LGPLv3的基础知识，以及它们分别与GPLv2和GPLv3的区别；
开始了解有关软件的衍生和组合作品的复杂性的基础知识。

CHAPTER 1 WHAT IS SOFTWARE FREEDOM?

第一章什么是软件自由？

Study of the GNU General Public License (herein, abbreviated as GNU GPL or just GPL) must begin by first considering the broader world of software freedom. The GPL was not created in a vacuum. Rather, it was created to embody and defend a set of principles that were set forth at the founding of the GNU Project and the Free Software Foundation (FSF) -- the preeminent organization that upholds, defends and promotes the philosophy of software freedom. A prerequisite for understanding both of the popular versions of the GPL (GPLv2 and GPLv3) and their terms and conditions is a basic understanding of the principles behind them. The GPL family of licenses are unlike nearly all other software licenses in that they are designed to defend and uphold these principles.

研究GNU通用公共许可证（此处缩写为GNU GPL或简称GPL）必须首先考虑更广泛的软件自由世界。 GPL不是凭空产生的，它是为了体现和捍卫在GNU项目和自由软件基金会 (FSF) 成立时提出的一系列原则而创建的，FSF是一个维护、捍卫和促进软件自由哲学的卓越组织。理解GPL的两个流行版本（GPLv2 和 GPLv3）及其条款和条件的先决条件是对它们背后的原则有基本的理解。GPL系列许可证与几乎所有其他的软件许可证不同，因为它们旨在捍卫和维护这些原则。

1.1 The Free Software Definition

1.1 自由软件的定义

The Free Software Definition is set forth in full on FSF's website at http://fsf.org/philosophy/free-sw.html. This section presents an abbreviated version that will focus on the parts that are most pertinent to the GPL.

自由软件定义在FSF的网站 http://fsf.org/philosophy/free-sw.html 上有完整的阐述。本节提供一个缩略版，将重点放在与GPL最密切的部分。

A particular user has software freedom with respect to a particular program if that user has the following freedoms:

如果某个特定用户具有以下自由，则这个用户就具有与特定程序相关的软件自由：

The freedom to run the program, for any purpose.
The freedom to study how the program works, and modify it
The freedom to redistribute copies.
The freedom to distribute copies of modified versions to others.
出于任何目的执行程序的自由；
了解程序的运行机制，可以随意修改的自由；
随意分发软件副本的自由；
将修改后的软件副本分发给他人的自由。

The focus on "a particular user" is particularly pertinent here. It is not uncommon for a subset of a specific program's user base to have these freedoms, while other users of the same version the program have none or only some of these freedoms. Section [12.2] talks in detail about how this can unfortunately happen even if a program is released under the GPL.

对“特定用户”的关注在这里尤为重要。某个特定程序的用户群的一部分人拥有这些自由的情况并不少见，而同一版本程序的其他用户则没有或只有其中的一部分自由。第 12.2 章节详细讨论了这种情况，即使程序是基于GPL发布的。

Many people refer to software with these freedoms as "Open Source." Besides having a different political focus from those who call such software by the name "Free Software"¹, those who call the software "Open Source" are often focused on a side issue. Specifically, user access to the source code of a program is a prerequisite to make use of the freedom to modify. However, the important issue is what freedoms are granted in the license that applies to that source code.

许多人将具有这些自由的软件称为“开源”。除了与那些将此类软件称为“自由软件” ¹ 的人有着不同的政治关注点之外，将软件称为“开源”的人通常关注的是一个次要问题。具体来说，用户访问程序的源代码是实现修改自由的先决条件。然而，重要的问题是在适用于该源代码的许可证中授予了哪些自由。

Software freedom is only complete when no restrictions are imposed on how these freedoms are exercised. Specifically, users and programmers can exercise these freedoms noncommercially or commercially. Licenses that grant these freedoms for noncommercial activities but prohibit them for commercial activities are considered non-free. The Open Source Initiative (OSI ) (the arbiter of what is considered "Open Source") also regards such licenses as inconsistent with its "Open Source Definition".

只有当如何行使这些自由没有任何限制时，软件自由才是完整的。具体而言，用户和程序员可以非商业或商业的方式行使这些自由。那些仅限于非商业活动的一些自由，但禁止商业活动自由的许可，被认为是非自由的。开源促进会(OSI)（被认为是“开源”的仲裁者）也认为此类许可证与其“开源定义”不一致。

In general, software for which any of these freedoms are restricted in any way is called "nonfree" software. Some use the term "proprietary software" more or less interchangeably with "nonfree software". The FSF published a useful explanation of various types of software and how they relate to one another.

一般来说，以任何方式限制自由的软件被称为“非自由”软件。有些人或多或少地将“专有软件”一词与“非自由软件”互换使用。 FSF发布了一份有用的对各种类型的软件以及它们之间的相互关系的解释

Keep in mind that none of the terms "software freedom", "open source" and "free software" are known to be trademarked or otherwise legally restricted by any organization in any jurisdiction. As such, it's quite common that these terms are abused and misused by parties who wish to bank on the popularity of software freedom. When one considers using, modifying or redistributing a software package that purports to be Open Source or Free Software, one must verify that the license grants software freedom.

请记住，“软件自由”、“开源”和“免费软件”等术语均未被任何司法管辖区的任何组织注册商标，或以其他方式限制使用。这些术语被某些机构滥用和误用是很常见的现象，因为他们希望扩大软件自由的普及度。当考虑使用、修改或重新分发声称是开源或自由软件的软件包时，必须验证许可证是否授予软件自由。

Furthermore, throughout this text, we generally prefer the term "software freedom", as this is the least ambiguous term available to describe software that meets the Free Software Definition. For example, it is well known and often discussed that the adjective "free" has two unrelated meanings in English: "free as in freedom" and "free as in price". Meanwhile, the term "open source" is even more confusing, because it appears to refer only to the "freedom to study", which is merely a subset of one of the four freedoms.

此外，在本文中，我们通常更喜欢“软件自由”一词，因为在那些描述符合自由软件定义的软件的一堆术语中，它的歧义最小。例如，大家经常讨论的英文中的形容词“自由”，它有两个不相关的含义：“使用的自由”和“价格的免费”。同时，“开源”一词更令人困惑，因为它似乎仅指“学习的自由”，这仅仅是四个自由中的一个。

The remainder of this section considers each of each component of software freedom in detail.

本节的其余部分将详细考虑软件自由的每个组成部分。

1.1.1 The Freedom to Run

1.1.1 执行程序的自由

The first tenet of software freedom is the user's fully unfettered right to run the program. The software's license must permit any conceivable use of the software. Perhaps, for example, the user has discovered an innovative use for a particular program, one that the programmer never could have predicted. Such a use must not be restricted.

软件自由的首要原则是用户拥有完全不受限制地执行该程序的权利。该软件的许可证必须允许用户以任意方式使用软件。例如，也许用户发现了针对一个特定场景的创新用途，这个场景可能是程序员从未预料到的。不得限制此类用途。

It was once rare that this freedom was restricted by even proprietary software; but such is quite common today. Most End User License Agreements (EULAs) that cover most proprietary software typically restrict some types of uses. Such restrictions of any kind are an unacceptable restriction on software freedom.

曾经很少有使用软件的自由受到限制的情况，在专有软件中也很少见；但现在却很普遍。大多数基于最终用户许可协议（EULAs）的专有软件，通常限制某些类型的用途。任何这些形式的限制对软件自由来说，都是不可接受的。

1.1.2 The Freedom to Change and Modify

1.1.2 更改和修改程序的自由

Perhaps the most useful right of software freedom is the users' right to change, modify and adapt the software to suit their needs. Access to the source code and related build and installation scripts are an essential part of this freedom. Without the source code, and the ability to build and install the binary applications from that source, users cannot effectively exercise this freedom.

软件自由的最有用的权利也许是用户拥有根据自己的需求更改、修改和调整软件的权利。对源代码以及相关的构建和安装脚本的访问权限，是该自由的重要组成部分。如果没有源代码，以及基于该源码构建和安装二进制应用程序的脚本，用户就无法有效地行使这种自由。

Programmers directly benefit from this freedom. However, this freedom remains important to users who are not programmers. While it may seem counterintuitive at first, non-programmer users often exercise this freedom indirectly in both commercial and noncommercial settings. For example, users often seek noncommercial help with the software on email lists and in user groups. To make use of such help they must either have the freedom to recruit programmers who might altruistically assist them to modify their software, or to at least follow rote instructions to make basic modifications themselves.

程序员是这种自由的直接受益者。但是，这种自由对于非程序员的用户来说也很重要。虽然看起来似乎有点违反直觉，但非程序员用户通常在商业和非商业环境中，间接行使这种自由。例如，用户经常在电子邮件列表和用户群组中需求软件上的非商业性帮助。为了能够使用这种便利，必须允许他们自由地招募可能会免费帮助他们修改软件的程序员，或者允许他们按照使用说明可以自己进行基本的修改。

More commonly, users also exercise this freedom commercially. Each user, or group of users, may hire anyone they wish in a competitive free market to modify and change the software. This means that companies have a right to hire anyone they wish to modify their Free Software. Additionally, such companies may contract with other companies to commission software modifications.

更常见的是，用户还可以在商业上行使这种自由。每个用户或一组用户都可以在竞争激烈的自由市场中，雇用他们希望的任何人来修改和更改软件。这意味着公司有权雇用任何愿意修改其免费软件的人。此外，公司可以与其他公司签订合同，委托进行软件修改。

1.1.3 复制和分享软件的自由

Users share Free Software in a variety of ways. Software freedom advocates work to eliminate a fundamental ethical dilemma of the software age: choosing between obeying a software license and friendship (by giving away a copy of a program to your friend who likes the software you are using). Licenses that respect software freedom, therefore, permit altruistic sharing of software among friends.

用户以多种方式分享自由软件。软件自由倡导者致力于消除软件时代的一个基本道德困境：在遵守软件许可和友谊之间做出选择（当你的朋友喜欢你正在使用的软件时，赠送一份程序副本给他）。因此，尊重软件自由的许可证允许在朋友之间无私地分享软件。

The commercial environment also benefits from this freedom. Commercial sharing includes selling copies of Free Software: that is, Free Software can be distributed for any monetary price to anyone. Those who redistribute Free Software commercially also have the freedom to selectively distribute (i.e., you can pick your customers) and to set prices at any level that redistributor sees fit.

商业环境也得益于这种自由。商业共享包括出售自由软件的副本：也就是说，可以用任何货币价格将自由软件分发给其他人。那些以商业方式重新分发自由软件的人，也可以有选择地自由分发（如可以选择你自己的客户），并可以自行设置合适的价格水平。

Of course, most people get copies of Free Software very cheaply (and sometimes without charge). The competitive free market of Free Software tends to keep prices low and reasonable. However, if someone is willing to pay billions of dollars for one copy of the GNU Compiler Collection, such a sale is completely permitted.

当然，大多数人都可以非常便宜地获得自由软件的副本（有时甚至是免费的）。竞争激烈的自由软件市场倾向于保持低价和合理的价格。但是如果真有人愿意花费数十亿美元购买一份GNU编译集，这也是完全允许的。

Another common instance of commercial sharing is service-oriented distribution. For example, some distribution vendors provide immediate security and upgrade distribution via a special network service. Such distribution is not necessarily contradictory with software freedom.

商业共享的另一个常见方式是面向服务的分发。例如，一些分发供应商通过特殊的网络服务提供即时安全和升级服务。这种分发方式不一定与软件自由相矛盾。

(Section [12.2] of this tutorial talks in detail about some common Free Software business models that take advantage of the freedom to share commercially.)

（本教程的第12.2章部分详细讨论了一些常见的利用商业实现自由软件的自由共享的业务模式。）

1.1.4 分享改进的自由

The freedom to modify and improve is somewhat empty without the freedom to share those improvements. The software freedom community is built on the pillar of altruistic sharing of improved Free Software. Historically it was typical for a Free Software project to sprout a mailing list where improvements would be shared freely among members of the development community. ² Such noncommercial sharing is the primary reason that Free Software thrives.

如果没有分享改进的自由，修改和改进的自由多少有点空洞。软件自由社区建立在无私共享改进的自由软件的基础上。从历史上看，自由软件项目的典型做法是建立一个邮件列表，开发社区的成员可以在其中免费分享改进的内容。² 这种非商业性质的共享方式是自由软件蓬勃发展的主要原因。

Commercial sharing of modified Free Software is equally important. For commercial support to exist in a competitive free market, all developers -- from single-person contractors to large software companies -- must have the freedom to market their services as augmenters of Free Software. All forms of such service marketing must be equally available to all.

修改后的自由软件的商业共享同样重要。为了在竞争激烈的自由市场中提供商业支持，所有的开发人员——从个人承包商到大型软件公司——都应该可以自由地将他们的服务作为自由软件的补充进行销售。这种形式的服务营销必须对所有人一视同仁。

For example, selling support services for Free Software is fully permitted. Companies and individuals can offer themselves as "the place to call" when software fails or does not function properly. For such a service to be meaningful, the entity offering that service needs the right to modify and improve the software for the customer to correct any problems that are beyond mere user error.

例如，销售免费软件的支持服务是完全允许的。当软件出现故障或无法正常运行时，公司和个人可以将自己作为“呼叫客服”。为了使此类服务有意义，提供该服务的实体需要有权为客户修改和改进软件，以纠正任何超出用户错误的问题。

Software freedom licenses also permit any entity to distribute modified versions of Free Software. Most Free Software programs have a "standard version" that is made available from the primary developers of the software. However, all who have the software have the "freedom to fork" -- that is, make available nontrivial modified versions of the software on a permanent or semi-permanent basis. Such freedom is central to vibrant developer and user interaction.

软件自由许可证还允许任何实体分发自由软件的修改版本。大多数自由软件程序都有一个“标准版本”，可以从软件的主要开发人员那里获得。然而，所有拥有该软件的人都有“分叉自由”——也就是说，可以永久或半永久地提供软件的重要修订版本。这种自由是充满活力的开发人员和用户交互的核心。

Companies and individuals have the right to make true value-added versions of Free Software. They may use freedom to share improvements to distribute distinct versions of Free Software with different functionality and features. Furthermore, this freedom can be exercised to serve a disenfranchised subset of the user community. If the developers of the standard version refuse to serve the needs of some of the software's users, other entities have the right to create a long- or short-lived fork to serve that sub-community.

公司和个人有权制作的自由软件的增值版本。他们可以自由地改进，并分享具有不同功能和特性的自由软件版本。此外，这种自由可以用来服务于被剥夺权力的用户群体。如果标准版本的开发人员拒绝满足某些软件用户的需求，则其他实体有权创建一个长期或短期的分支，提供服务满足于这些软件用户。

1.2 How Does Software Become Free?

1.2 软件是如何变得自由的？

The previous section set forth key freedoms and rights that are referred to as "software freedom". This section discusses the licensing mechanisms used to enable software freedom. These licensing mechanisms were ultimately created as a community-oriented "answer" to the existing proprietary software licensing mechanisms. Thus, first, consider carefully why proprietary software exists in the first place.

上一节阐述了被称为“软件自由”的一些关键自由和权利。本节讨论用于实现软件自由的许可机制。这些许可机制被看作是将现有专有软件许可机制转变为面向社区机制的“答案”所在。因此，首先要仔细考虑为什么会有专有软件存在。

The primary legal regime that applies to software is copyright law. Proprietary software exists at all only because copyright law governs software.³ Copyright law, with respect to software, typically governs copying, modifying, and redistributing that software (For details of this in the USA, see §106 and §117 of Title17 of the United States Code).⁴ By law (in the USA and in most other jurisdictions), the copyright holder (most typically,the author) of the work controls how others may copy, modify and/or distribute the work. For proprietary software, these controls are used to prohibit these activities. In addition, proprietary software distributors further impede modification in a practical sense by distributing only binary code and keeping the source code of the software secret.

适用于软件的主要法律制度是版权法。专有软件的存在完全是因为版权法对软件的管理规定。³关于软件的版权法，主要是对软件的复制、修改和再发行的管理规定（有关美国的详细信息，请参阅《美国法典》第17篇的§106和§117）。⁴ 根据法律（在美国和大多数其他司法管辖区），作品的版权持有者（通常是作者本人）可以控制其他人如何复制、修改和/或分发作品。专有软件的这些控制行为禁止了软件的相关操作。此外，专有软件分销商只发行二进制可执行代码，严格保密源代码，这也进一步阻碍了实际意义上的代码修改。

Copyright is not a natural state, it is a legal construction. In the USA, the Constitution permits, but does not require, the creation of copyright law as federal legislation. Software, since it is an "original work of authorship fixed in any tangible medium of expression ... from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device" (as stated in 17 USC § 102), is thus covered by the statute, and is copyrighted by default.

版权不是一种自然状态，它是一种法律结构。在美国，宪法允许但不要求将版权法作为联邦立法。软件，因为它是“固定在任何有形表达媒介中的原创作品……可以直接或借助机器/设备从中感知、复制或以其他方式传播”（如《美国法典》第17篇第§102章节所述)，因此受法规保护，默认情况下受版权保护。

However, software, in its natural state without copyright, is Free Software. In an imaginary world with no copyright, the rules would be different. In this world, when you received a copy of a program's source code, there would be no default legal system to restrict you from sharing it with others, making modifications, or redistributing those modified versions.⁵

但是，在没有版权的自然状态下，软件是自由软件。在没有版权的虚拟世界中，规则会有所不同。在虚拟世界上，当你收到一个程序的源代码副本时，不会有默认的法律制度来限制你与他人共享、进行修改或重新分发这些修改后的版本。⁵

Software in the real world is copyrighted by default and is automatically covered by that legal system. However, it is possible to move software out of the domain of the copyright system. A copyright holder can often disclaim their copyright. (For example, under USA copyright law it is possible for a copyright holder to engage in conduct resulting in abandonment of copyright.) If copyright is disclaimed, the software is effectively no longer restricted by copyright law. Software not restricted by copyright is in the "public domain."

1.2.1 Public Domain Software

1.2.1 公共领域软件

In the USA and other countries that are parties to the Berne Convention on Copyright, software is copyrighted automatically by the author when she fixes the software in a tangible medium. In the software world, this usually means typing the source code of the software into a file.

在美国和其他加入《伯尔尼版权公约》的国家，当作者将软件固定在有形介质中时，软件自动受到版权保护。在软件世界中，这通常意味着将软件的源代码输入到文件中。

Imagine if authors could truly disclaim those default controls of copyright law. If so, the software is in the public domain --- no longer covered by copyright. Since copyright law is the construction allowing for most restrictions on software (i.e., prohibition of copying, modification, and redistribution), removing the software from the copyright system usually yields software freedom for its users.

想象一下，如果作者真的放弃了版权法的默认控制。如果是这样，该软件就属于公共领域 --- 不再受版权保护。由于版权法是允许对软件进行操作限制（如禁止复制、修改和重新分发）的结构定义，因此从版权系统中删除软件通常会为其用户带来软件自由。

Carefully note that software truly in the public domain is not licensed in any way. It is confusing to say software is "licensed for the public domain," or any phrase that implies the copyright holder gave express permission to take actions governed by copyright law.

Copyright holders who state that they are releasing their code into the public domain are effectively renouncing copyright controls on the work. The law gave the copyright holders exclusive controls over the work, and they chose to waive those controls. Software that is, in this sense, in the public domain is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in Section [1.1] are all granted because there is no legal system in play to take them away.

Admittedly, a discussion of public domain software is an oversimplified example. Because copyright controls are usually automatically granted and because, in some jurisdictions, some copyright controls cannot be waived (see Section [1.2.4] for further discussion), many copyright holders sometimes incorrectly believe a work has been placed in the public domain. Second, due to aggressive lobbying by the entertainment industry, the "exclusive Right" of copyright, that was supposed to only exist for "Limited Times" according to the USA Constitution, appears to be infinite: simply purchased on the installment plan rather than in whole. Thus, we must assume no works of software will fall into the public domain merely due to the passage of time.

诚然，对公共领域软件的讨论是一个过于简单化的例子。因为版权控制通常是自动授予的，并且在某些司法管辖区，某些版权控制不能被放弃（请参考第 [1.2.4] 节（#non-usa-copyright-regimes）以了解进一步的讨论），许多版权所有者有时会错误地认为作品已经发布到了公共领域。其次，由于娱乐业的积极游说，根据美国宪法规定，版权的“专有权”本应仅存在于“有限时间”，但看起来似乎是无限的：只是分期付款购买，而不是全部购买。因此，我们必须假设没有任何软件作品会因为时间的流逝而落入公共领域。

Nevertheless, under USA law it is likely that the typical disclaimers of copyright or public domain dedications we see in the Free Software world would be interpreted by courts as copyright abandonment, leading to a situation in which the user effectively receives a maximum grant of copyright freedoms, similar to a maximally-permissive Free Software license.

然而，根据美国法律，我们在自由软件世界中看到的典型的版权免责声明，或公共领域专有申明，可能会被法院解释为放弃版权，从而授予了用户实际上最大程度的版权自由，类似于最大程度的自由软件许可证。

The best example of software known to truly be in the public domain is software that is published by the USA government. Under 17 USC 101 105, all works published by the USA Government are not copyrightable in the USA.

目前所知的真正属于公共领域的软件最好的例子，是由美国政府发布的软件。根据《美国法典》第17章101-105，在美国，美国政府出版的所有作品均不受版权保护。

1.2.2 Why Copyright Free Software?

1.2.2 为什么需要版权自由的软件？

If simply disclaiming copyright on software yields Free Software, then it stands to reason that putting software into the public domain is the easiest and most straightforward way to produce Free Software. Indeed, some major Free Software projects have chosen this method for making their software Free. However, most of the Free Software in existence is copyrighted. In most cases (particularly in those of FSF and the GNU Project), this was done due to very careful planning.

假如只是放弃了对软件的版权就产生了自由软件，那么将软件发布到公共领域是产生自由软件最简单和最直接的方式，这看起来是理所当然的。事实上，一些主要的自由软件项目已经选择了这种方法来使他们的软件成为自由软件。然而，现存的大多数自由软件是受版权保护的。在大多数情况下（特别是在FSF和GNU项目中），这些项目的规划都非常仔细。

Software released into the public domain does grant freedom to those users who receive the standard versions on which the original author disclaimed copyright. However, since the work is not copyrighted, any nontrivial modification made to the work is fully copyrightable.

当原作者将作品发布到公共领域以否认版权时，就将软件自由授予了那些已经收到标准版本的用户。虽然原作品不受版权保护，但对原作品所做的任何重要修改都是受版权保护的。

Free Software released into the public domain initially is Free, and perhaps some who modify the software choose to place their work into the public domain as well. However, over time, some entities will choose to proprietarize their modified versions. The public domain body of software feeds the proprietary software. The public commons disappears, because fewer and fewer entities have an incentive to contribute back to the commons. They know that any of their competitors can proprietarize their enhancements. Over time, almost no interesting work is left in the public domain, because nearly all new work is done by proprietarization.

起初，发布到公共领域的自由软件是自由的，一些修改软件的人也会选择将他们的作品发布到公共领域。然而，随着时间的推移，一些实体选择将其修改后的版本专有化。公共领域的软件主体为专有软件提供了支持。随着越来越少的实体有动力回馈公共领域，公共资源就消失了。他们知道，任何竞争对手都可以将自己的增强功能专有化。随着时间的推移，公共领域几乎不会留下任何有趣的项目，因为几乎所有的新项目都是由专有化的实体完成的。

A legal mechanism is needed to redress this problem. FSF was in fact originally created primarily as a legal entity to defend software freedom, and that work of defending software freedom is a substantial part of its work today. Specifically because of this "embrace, proprietarize and extend" cycle, FSF made a conscious choice to copyright its Free Software, and then license it under "copyleft" terms. Many, including the developers of the kernel named Linux, have chosen to follow this paradigm.

因此，需要一个法律机制来解决这个问题。事实上，FSF最初主要是作为一个捍卫软件自由的法律实体而创建的，而捍卫软件自由是其现在工作的重要组成部分。特别是由于这种“拥抱、专有化和扩展”的循环，FSF有意识地选择对其自由软件进行版权保护，然后根据“copyleft”条款对其进行许可。许多人，包括Linux内核的开发人员，都选择遵循这种模式。

Copyleft is a strategy of utilizing copyright law to pursue the policy goal of fostering and encouraging the equal and inalienable right to copy, share, modify and improve creative works of authorship. Copyleft (as a general term) describes any method that utilizes the copyright system to achieve the aforementioned goal. Copyleft as a concept is usually implemented in the details of a specific copyright license, such as the [GNU General Public License (GPL)] and the Creative Commons Attribution Share Alike License (the latter of which is the license of this work itself). Copyright holders of creative work can unilaterally implement these licenses for their own works to build communities that collaboratively share and improve those copylefted creative works.

Copyleft是一种利用版权法来实现政策目标的策略，意在促进和鼓励平等和不可剥夺的复制、共享、修改和改进原创作品的权利。Copyleft（作为一个通用术语）描述了利用版权系统实现上述目标的一些方法。Copyleft作为一个概念，通常在特定版权许可证的细节中体现，例如[GNU 通用公共许可 (GPL)] 和（Creative Commons Attribution Share Alike License）知识共享署名共享类似许可（后者是这个项目本身的许可证）。创意作品的版权持有者可以单方面为自己的作品实施这些许可，建立社区，共同分享和改进这些copyleft的创意作品。

Copyleft uses functional parts of the copyright system to achieve an unusual result (legal protection for free sharing). Copyleft modifies, or "hacks" copyright law, which is usually employed to strengthen the rights of authors or publishers, to strengthen instead the rights of users. Thus, Copyleft is a legal strategy and mechanism to defend, uphold and propagate software freedom. The basic technique of copyleft is as follows: copyright the software, license it under terms that give all the software freedoms, but use the copyright law controls to ensure that all who receive a copy of the software have equal rights and freedom. In essence, copyleft grants freedom, but forbids others to forbid that freedom to anyone else along the distribution and modification chains.

Copyleft使用版权系统的功能部分来实现一个不同寻常的结果（免费共享的法律保护）。Copyleft修改或“破解”版权法以加强用户的权利，而版权法通常用于加强作者或出版商的权利。因此，Copyleft是一种捍卫、支持和传播软件自由的法律策略和机制。Copyleft的基本原则为：对软件进行版权保护，在赋予所有软件自由的条款下颁发软件许可证，但使用版权法控制，以确保所有获得软件副本的人都享有平等的权利和自由。本质上，copyleft赋予用户自由，也禁止某些用户的垄断行为，即通过控制软件的分发和修改的后续链条限制其他人的软件自由。

Copyleft's "reciprocity" or "share and share alike" rule protects both developers, who avoid facing a "prioritized" competitor of their project, and users, who can be sure that they will have all four software freedoms --- not only in the present version of the program they use, but in all its future improved versions. Copyleft is a general concept. Much like ideas for what a computer might do must be implemented by a program that actually does the job, so too must copyleft be implemented in some concrete legal structure. "Share and share alike" is a phrase that is used often enough to explain the concept behind copyleft, but to actually make it work in the real world, a true implementation in legal text must exist, written as a "copyright license". The GPL implements the concept of copyleft for software-oriented and other functional works of a technical nature. The "CC BY SA" license implements copyleft for works of textual, musical and visual authorship, such as this tutorial.

Copyleft的“互惠”或“共享和类似共享”的原则同时保护了开发者和用户，开发者可以避免面对他们项目的“优先”竞争对手，用户可以确保他们将拥有所有的四种软件自由——不仅限于当前他们使用的程序版本，也包括未来的所有改进版本中。Copyleft是一个笼统的概念。就像计算机可以做什么的想法必须由一个实际执行该任务的程序实现一样，copyleft也必须在某些具体的法律结构中实现。“共享和类似共享”这个短语经常被用来解释copyleft背后的概念，但要真正让它在现实世界中发挥作用，必须有一个真正的法律文本实现，即“版权许可”。GPL为面向软件和其他技术性质的功能性作品实现了copyleft的概念。 “CC BY SA”许可证为文本、音乐和视觉作者的作品提供了copyleft版权保护，例如本教程。

Copyleft advocates often distinguish between the concept of a "strong copyleft" or a "weak copyleft". However, "strong vs. weak" copyleft is not a dichotomy, it's a spectrum. The strongest copylefts strive to the exclusive rights that copyright grants to authors as extensively as possible to maximize software freedom.

Copyleft倡导者经常区分“强copyleft”或“弱copyleft”的概念。然而，“强与弱”copyleft并不是二分法原则，而是一个范围。最强的copyleft版权力图授予作者尽可能广泛的专有权，以最大限度地提高软件自由度。

As a copyleft gets "weaker", the copyleft license typically makes "trade offs" that might impede software freedom, but reach other tactic goals for the community of users and developers of the work.

随着copyleft变得“微弱”，copyleft许可证可能会做一些"权衡"，可能会阻碍软件自由，但会实现用户和项目开发者社区的其他策略目标。

In other words, strong copyleft licenses place the more requirements on how "the work" is licensed. The unit of copyright law is "the work". In that sense, the "work" referenced by the licenses is anything that can be copyrighted or will be subject to the terms of copyright law. Strong copyleft licenses exercise their scope fully. Anything which is "a work" or a "work based on a work" licensed under a strong copyleft is subject to its requirements, including the requirement of complete, corresponding source code ⁶. Thus, copyleft licenses, particularly strong ones, seek to ensure the same license covers every version of "work based on the work", as recognized by local copyright law, and thereby achieve the specific strategic policy aim of ensuring software freedom for all users, developers, authors, and readers who encounter the copylefted work.

换句话说，较强的copyleft许可对“作品”的许可方式提出了更高的要求。是以“作品”为单位进行版权法认定的。从这个意义上说，许可证所指的“作品”是任何可以受版权保护或受版权法条款约束的东西。较强的copyleft许可证充分发挥了其作用。任何基于较强的copyleft许可的“作品”或“基于作品的作品”都必须遵守其要求，包括所有相应的源代码 ⁶。因此，copyleft许可证，特别是较强的许可证，旨在确保相同的许可证涵盖当地版权法认可的“基于作品的作品”的所有版本，从而确保实现与当前copyleft版权作品相关的所有用户、开发者、作者和读者的软件自由的特定战略目标。

1.2.3 Software and Non-Copyright Legal Regimes

1.2.3 软件和非版权法律制度

The use, modification and distribution of software, like many endeavors, simultaneously interacts with multiple different legal regimes. As was noted early via footnotes, copyright is merely the most common way to restrict users' rights to copy, share, modify and/or redistribute software. However, proprietary software licenses typically use every mechanism available to subjugate users. For example:

与许多努力一样，软件的使用、修改和分发同时与多种不同的法律制度相互制约。正如早期通过脚注指出的那样，版权只是限制用户复制、共享、修改和/或重新分发软件的最常见的方式。但是专有软件许可证通常会使用所有各种机制来控制用户。例如：

Unfortunately, despite much effort by many in the software freedom community to end patents that read on software (i.e., patents on computational ideas), they still exist. As such, a software program might otherwise seem to be unrestricted, but a patent might read on the software and ruin everything for its users.⁷
软件自由社区中的人做了很多努力，希望能终止通过读取软件内容生成专利的行为（即跟软件思想相关的专利），但还是未能成功。因此，一个软件程序可能看起来不受限制，但有些人可能会读取该软件并生成专利，进而毁掉其他用户的一切。⁷

Digital Restrictions Management (usually called DRM ) is often used to impose technological restrictions on users' ability to exercise software freedom that they might otherwise be granted.⁸ The simplest (and perhaps oldest) form of DRM, of course, is separating software source code (read by humans), from their compiled binaries (read only by computers). Furthermore, 17 USC 1201 often prohibits users legally from circumventing some of these DRM systems.

虽然授予了软件自由，但数字限制管理（也被称为DRM）通常对用户行使软件自由的能力施加技术限制。⁸最简单的（也是最古老的）DRM的形式，是将软件源代码（人类可阅读的）与编译的二进制文件（仅由计算机读取）分开。此外，《美国法典》第17篇第§102章节通常从法律层面禁止用户规避DRM系统中的一些。

Most EULAs also include a contractual agreement that bind users further by forcing them to agree to a contractual, prohibitive software license before ever even using the software.

大多数EULA协议还包括一份用户合同，强制用户在使用软件之前同意合同性的、禁止性的软件许可来进一步约束用户。

Thus, most proprietary software restricts users via multiple interlocking legal and technological means. Any license that truly respect the software freedom of all users must not only grant appropriate copyright permissions, but also prevent restrictions from other legal and technological means like those listed above.

所以，大多数专有软件会通过多种相互关联的法律和技术手段来限制用户。任何真正尊重用户软件自由的许可证，不仅必须授予适当的版权许可，还必须防止上述其他法律和技术手段的限制。

1.2.4 Non-USA Copyright Regimes

1.2.4 美国之外的版权制度

Generally speaking, copyright law operates similarly enough in countries that have signed the Berne Convention on Copyright, and software freedom licenses have generally taken advantage of this international standardization of copyright law. However, copyright law does differ from country to country, and commonly, software freedom licenses like the GPL must be considered under the copyright law in the jurisdiction where any licensing dispute occurs.

一般来说，在签署了《伯尔尼版权公约》的国家中，版权法的运作非常相似，软件自由许可通常采用了国际标准化的版权法。然而，不同国家的版权法确实有所不同，通常像GPL这样的软件自由许可，必须在发生许可纠纷的司法管辖区，根据版权法予以考虑。

Those who are most familiar with the USA's system of copyright often are surprised to learn that there are certain copyright controls that cannot be waived nor disclaimed. Specifically, many copyright regimes outside the USA recognize a concept of moral rights of authors. Typically, moral rights are fully compatible with respecting software freedom, as they are usually centered around controls that software freedom licenses generally respect, such as the right of an authors to require proper attribution for their work.

那些最熟悉美国版权制度的人通常会惊讶地发现，有些版权控制既不能放弃也不能否认。具体来说，美国以外的许多版权制度都承认作者的道德权利概念。通常，道德权利与尊重软件自由完全兼容，因为道德权利通常是以软件自由许可所允许的控制为中心，例如作者要求对其作品进行适当归属的权利。

1.3 A Community of Equality

1.3 平等的社区

The previous section described the principles of software freedom, a brief introduction to mechanisms that typically block these freedoms, and the simplest ways that copyright holders might grant those freedoms to their users for their copyrighted works of software. The previous section also introduced the idea of copyleft : a licensing mechanism to use copyright to not only grant software freedom to users, but also to uphold those rights against those who might seek to curtail them.

Copyleft, as defined in [1.2.2,] is a general term for this mechanism. The remainder of this text will discuss details of various real-world implementations of copyleft --most notably, the GPL.

如[第1.2.2节]的Copyleft定义，它是该机制的一个通用术语。本书的其他章节将会讨论现实世界中copyleft的一些实现方式 -- 最值得注意的就是GPL。

This discussion begins first with some general explanation of what the GPL is able to do in software development communities. After that brief discussion in this section, deeper discussion of how GPL accomplishes this in practice follows in the next chapter.

讨论首先会解释GPL在软件开发社区中的作用。本节只进行简短讨论，下一章将深入讨论GPL如何在实践中实现这一点。

Simply put, though, the GPL ultimately creates a community of equality for both business and noncommercial users.

不过，简单来说，最终GPL为商业用户及非商业用户创建了一个平等的社区。

1.3.1 The Noncommercial Community

1.3.1 非商业社区

A GPL'd code base becomes a center of a vibrant development and user community. Traditionally, volunteers, operating noncommercially out of keen interest or "scratch an itch" motivations, produce initial versions of a GPL'd system. Because of the efficient distribution channels of the Internet, any useful GPL'd system is adopted quickly by noncommercial users.

GPL的代码库已经成为充满活力的开发者和用户社区的中心。一般来说，出于浓厚的兴趣爱好或“试一把”的动机，志愿者会以非商业的方式制作一个GPL系统的初始版本。由于互联网的高效分发渠道，任何有用的GPL系统都会很快被非商业用户所采用。

Fundamentally, the early release and quick distribution of the software gives birth to a thriving noncommercial community. Users and developers begin sharing bug reports and bug fixes across a shared intellectual commons. Users can trust the developers, because they know that if the developers fail to address their needs or abandon the project, the GPL ensures that someone else has the right to pick up development. Developers know that the users cannot redistribute their software without passing along the rights granted by the GPL, so they are assured that every one of their users is treated equally.

从根本上来说，软件的早期发布和快速分发催生了一个繁荣的非商业社区。用户和开发人员都在知识共享的社区中分享错误报告和修复补丁。用户非常信任开发人员，因为他们知道如果开发人员不能满足他们的需求或放弃项目，GPL协议能确保其他人有权接手并持续开发。开发人员知道，如果将GPL的权利授予用户，用户就没法二次分发他们的软件，因此他们需要确信每一位用户受到平等对待。

Because of the symmetry and fairness inherent in GPL'd distribution, nearly every GPL'd package in existence has a vibrant noncommercial user and developer base.

就是因为GPL分发协议的对称性和公平性，几乎每个GPL项目都拥有一个活跃的非商业用户和开发者群体。

1.3.2 The Commercial Community

1.3.2 商业群体

By the same token, nearly all established GPL'd software systems have a vibrant commercial community. Nearly every GPL'd system that has gained wide adoption from noncommercial users and developers eventually begins to fuel a commercial system around that software.

同样，几乎所有已建立的GPL软件系统都有一个充满活力的商业社区。每个获得非商业用户和开发人员拥护的GPL系统，最终几乎都开始围绕该软件为商业系统提供动力。

For example, consider the Samba file server system that allows Unix-like systems (including GNU/Linux) to serve files to Microsoft Windows systems. Two graduate students originally developed Samba in their spare time and it was deployed noncommercially in academic environments.⁹ However, very soon for-profit companies discovered that the software could work for them as well, and their system administrators began to use it in place of Microsoft Windows NT file-servers. This served to lower the cost of running such servers by orders of magnitude. There was suddenly room in Windows file-server budgets to hire contractors to improve Samba. Some of the first people hired to do such work were those same two graduate students who originally developed the software.

例如，以Samba文件服务器系统为例，它允许类Unix系统（如GNU/Linux）向微软的Windows系统提供文件服务。Samb最初是由两名研究生在业余时间开发的，并在学术环境中部署，并未商业化。⁹ 之后很快商业公司就发现了该软件也适用于他们，公司的系统管理员开始使用它取代了微软的Windows NT文件服务器。这有助于将此类服务器的运行成本降低几个数量级。Windows文件服务器就有了多的预算空间，可以雇用承包商来改进Samba。最早受雇从事这项工作的正是最初开发该软件的两名研究生。

The noncommercial users, however, were not concerned when these two fellows began collecting paychecks off of their GPL'd work. They knew that because of the nature of the GPL that improvements that were distributed in the commercial environment could easily be folded back into the standard version. Companies are not permitted to proprietarize Samba, so the noncommercial users, and even other commercial users are safe in the knowledge that the software freedom ensured by the GPL will remain protected.

当那两位学生开始从他们的GPL工作中获取报酬时，非商业用户也并不担心。他们知道，由于GPL的性质，在商业环境中实现的改进会很快地融入到标准版本。不允许任何公司将Samba私有化，非商业用户、其他商业用户都知道，GPL协议会确保软件自由将继续受到保护。

Commercial developers also work in concert with noncommercial developers. Those two now-long-since graduated students continue to contribute to Samba altruistically, but also get paid work doing it. Priorities change when a client is in the mix, but all the code is contributed back to the standard version. Meanwhile, many other individuals have gotten involved noncommercially as developers, because they want to "cut their teeth on Free Software," or because the problems interest them. When they get good at it, perhaps they will move on to another project, or perhaps they will become commercial developers of the software themselves.

商业开发商也会与非商业开发商合作。那两位已经毕业了的学生继续无私地为Samba做出贡献，但同时也获得了报酬。当有客户参与其中时，优先级会发生变化，但所有的代码都会回馈给标准版本。与此同时，许多其他人也作为开发者参与了非商业活动，因为他们想“在自由软件上小试牛刀”，或者是他们对这些问题感兴趣。当他们擅长编程时，也许会转向另一个项目，或者他们自己可能会成为软件的商业开发人员。

No party is a threat to another in the GPL software scenario because everyone is on equal ground. The GPL protects rights of the commercial and noncommercial contributors and users equally. The GPL creates trust, because it is a level playing field for all.

在GPL软件场景中，任何一方都不会对另外一方构成威胁，因为每个人都是平等的。GPL协议平等地保护了商业和非商业贡献者和用户的权利。GPL协议创造信任，因为它位所有人提供了公平的竞争环境。

1.3.3 Law Analogy

1.3.3 法律类比

In his introduction to Stallman's Free Software, Free Society, Lawrence Lessig draws an interesting analogy between the law and Free Software. He argues that the laws of a free society must be protected much like the GPL protects software. So that I might do true justice to Lessig's argument, I quote it verbatim:

在介绍Stellman的《自由软件、自由社会》时，Lawrence Lessig在法律和自由软件之间做了一个有趣的类比。他认为自由社会的法律也需要受到保护，就像GPL协议保护软件一样。为了能真正公正地对待Lessig的论点，我逐字引用了它：

A "free society" is regulated by law. But there are limits that any free society places on this regulation through law: No society that kept its laws secret could ever be called free. No government that hid its regulations from the regulated could ever stand in our tradition. Law controls. But it does so justly only when visibly. And law is visible only when its terms are knowable and controllable by those it regulates, or by the agents of those it regulates (lawyers, legislatures).

“自由社会”是受法律规范的。但是任何自由社会都通过法律对这种规定施加了限制：任何对法律保密的社会都不能被称为自由。任何向受监管者隐藏其法规的政府都无法立足于我们的传统。法律控制。但只有在显而易见的情况下，它才会这样做。法律只有在其条款可被监管者或监管者的代理人（律师、立法机关）知晓和控制时才是可见的。

This condition on law extends beyond the work of a legislature. Think about the practice of law in American courts. Lawyers are hired by their clients to advance their clients' interests. Sometimes that interest is advanced through litigation. In the course of this litigation, lawyers write briefs. These briefs in turn affect opinions written by judges. These opinions decide who wins a particular case, or whether a certain law can stand consistently with a constitution.

这种法律条件超出了立法机关的工作范围。想想美国法院的法律实践。律师受雇于他们的客户，目的是促进他们客户的利益。有时，这种利益是通过法律诉讼来推进的。在此诉讼过程中，律师撰写简报。这些简报反过来会影响法官撰写的意见。这些意见决定了在某一案件中谁会获胜，或者某项法律是否能够与宪法保持一致。

All the material in this process is free in the sense that Stallman means. Legal briefs are open and free for others to use. The arguments are transparent (which is different from saying they are good), and the reasoning can be taken without the permission of the original lawyers. The opinions they produce can be quoted in later briefs. They can be copied and integrated into another brief or opinion. The "source code" for American law is by design, and by principle, open and free for anyone to take. And take lawyers do---for it is a measure of a great brief that it achieves its creativity through the reuse of what happened before. The source is free; creativity and an economy is built upon it.

正如Stallman所说，这个过程中的所有材料都是免费的。法律简报是公开的，可供他人免费使用。论据透明（这不同于说它们是好的），无需原律师许可即可取证。他们提出的意见可以在以后的简报中引用。可以将它们复制并整合到另一份简报或意见中。美国法律的“源代码”在设计上和原则上都是开放的，任何人都可以免费使用。以律师的做法为例——因为这是一个伟大的简报的衡量标准，它通过重用以前的案例来实现其创造力。来源是免费的；创造力和经济是建立在它之上的。

This economy of free code (and here I mean free legal code) doesn't starve lawyers. Law firms have enough incentive to produce great briefs even though the stuff they build can be taken and copied by anyone else. The lawyer is a craftsman; his or her product is public. Yet the crafting is not charity. Lawyers get paid; the public doesn't demand such work without price. Instead this economy flourishes, with later work added to the earlier.

这种免费代码经济（这里我指的是免费法律代码）不会让律师挨饿。律师事务所有足够的动力来制作出色的简报，即使他们制作的东西可以被其他任何人拿走和复制。律师是工匠；他或她的简报是公开的。然而，手工艺品不是慈善。律师得到报酬；公众不会要求律师无偿工作。取而代之的是，这种经济会蓬勃发展，后期的工作会逐渐添加到早期的工作中。

We could imagine a legal practice that was different --- briefs and arguments that were kept secret; rulings that announced a result but not the reasoning. Laws that were kept by the police but published to no one else. Regulation that operated without explaining its rule.

我们可以想象一种不同的法律实践——保持简报和论据的保密性；宣布结果但不宣布推理的裁决。警察遵守的法律，但不向其他人公开。没有解释规则的相关规定。

We could imagine this society, but we could not imagine calling it "free." Whether or not the incentives in such a society would be better or more efficiently allocated, such a society could not be known as free. The ideals of freedom, of life within a free society, demand more than efficient application. Instead, openness and transparency are the constraints within which a legal system gets built, not options to be added if convenient to the leaders. Life governed by software code should be no less.

我们可以想象这样的社会，但我们无法假装称它为“自由”。无论这个社会中的激励是否会得到更好或更有效的分配，这样的社会都不能被称为自由。自由的理想，自由社会中的生活，需要的不仅仅是有效的应用。相反，公开和透明是建立法律体系的约束条件，而不是领导者需要时可以随意添加的选项。由软件代码支配的生活应该不会少。

Code writing is not litigation. It is better, richer, more productive. But the law is an obvious instance of how creativity and incentives do not depend upon perfect control over the products created. Like jazz, or novels, or architecture, the law gets built upon the work that went before. This adding and changing is what creativity always is. And a free society is one that assures that its most important resources remain free in just this sense.[^10^]

代码编写不是法律诉讼。它更好、更丰富、更有生产力。但创造力和激励是不依赖于对所创造产品的完美与否的，法律就是一个明显的例子。就像爵士乐、小说或建筑一样，法律是建立在之前的作品之上的。这种添加和改变就是创造力的本质所在。一个自由的社会就是确保其最重要的资源在某种意义上保持免费。¹⁰

In essence, lawyers are paid to service the shared commons of legal infrastructure. Few citizens defend themselves in court or write their own briefs (even though they are legally permitted to do so) because everyone would prefer to have an expert do that job.

从本质上讲，律师是为法律基础设施的公共服务而工作的。很少有公民在法庭上为自己辩护或撰写自己的案情简报（即使法律允许他们这样做），每个人都更愿意让专家来做这项工作。

The Free Software economy is a market ripe for experts. It functions similarly to other well established professional fields like the law. The GPL, in turn, serves as the legal scaffolding that permits the creation of this vibrant commercial and noncommercial Free Software economy.

对于专家来说，自由软件经济是一个成熟的市场。它的功能类似于法律等其他成熟的专业领域。反过来，GPL协议又是一个法律脚手架，允许创建这个充满活力的商业和非商业的自由软件经济。

CHAPTER 2 A TALE OF TWO COPYLEFT LICENSES

第2章两个著佐权许可证的故事

While determining the proper methodology and criteria to yield an accurate count remains difficult, the GPL is generally considered one of the most widely used Free Software licenses. For most of its history --- for 16 years from June 1991 to June 2007 --- there was really only one version of the GPL, version 2.

尽管还没办法选择适当的方法和标准给出准确统计，但GPL是公认最广泛使用的自由软件许可证之一。在它大部分历史（从1991年6月到2007年6月的16年）中，GPL实际上只有一个版本，即第二版。

However, the GPL had both earlier versions before version 2, and, more well known, a revision to version

然而，GPL既有第二版之前的早期版本，也有更知名的第三版修订版。

Historical Motivations for the General Public License

2.1 通用公共许可证的历史动因

The earliest license to grant software freedom was likely the Berkeley Software Distribution ("BSD") license. This license is typical of what are often called lax, highly permissive licenses. Not unlike software in the public domain, these non-copyleft licenses (usually) grant software freedom to users, but they do not go to any effort to uphold that software freedom for users. The so-called "downstream" (those who receive the software and then build new things based on that software) can restrict the software and distribute further.

最早的授予软件自由的许可证可能是伯克利软件分发（Berkeley Software Distribution，“BSD”）许可证。这个许可证是典型的、高度宽松的许可证，通常被称为“宽松许可证”。与公共领域的软件不一样，这些非著佐权许可证（通常）将软件自由授予用户，但它们并不为用户维护这种软件自由。所谓的 "下游"（那些收到软件后在该软件基础上添砖加瓦的人）可以限制该软件进一步分发。

The GNU's Not Unix ("GNU") project, which Richard M. Stallman ("RMS") founded in 1984 to make a complete Unix-compatible operating system implementation that assured software freedom for all. However, RMS saw that using a license that gave but did not assure software freedom would be counter to the goals of the GNU Project. RMS invented "copyleft" as an answer to that problem, and began using various copyleft licenses for the early GNU Project programs.¹

为了实现对完全兼容Unix的操作系统的应用、保证所有人的软件自由，Richard M. Stallman（RMS）于1984年创建“GUN Not Unix（GNU）”项目。然而，RMS发现使用许可证可以赋予却不能保证软件自由，这可能与GUN项目的目标背道而驰。于是RMS发明了“著佐权”来解决这个问题，并且开始在早期GNU项目程序中使用各种形式的著佐权许可证。¹

Proto-GPLs And Their Impact

2.2 原始GPL及其影响

The earliest copyleft licenses were specific to various GNU programs. For example, The Emacs General Public License was likely the first copyleft license ever published. Interesting to note that even this earliest copyleft license contains a version of the well-known GPL copyleft clause:

最早的著佐权许可证是专门针对各种GNU程序的。例如，Emacs通用公共许可证可能是有史以来发布的第一个著佐权许可证。有趣的是，即使是这个最早的著佐权许可证也包含了著名的GPL著佐权条款的一个版本：

You may modify your copy or copies of GNU Emacs . . . provided that you also . . . cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of GNU Emacs or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement.

你可以修改你的GNU Emacs副本……如果你也……使你的任何全部或部分包含GNU Emacs或作为其衍生作品分发或发布的作品的整体，以与本许可协议中包含的条款相同的条款免费授权给所有第三方。

This simply stated clause is the fundamental innovation of copyleft. Specifically, copyleft uses the copy- right holders' controls on permission to modify the work to add a conditional requirement. Namely, downstream users may only have permission to modify the work if they pass along the same permissions on the modified version that came originally to them.

这个阐述简明的条款是著佐权的根本创新。具体来说，著佐权通过著作权所有者对修改作品的权限的控制，增加了一个条件，即：

下游用户只有在将他们最初被赋予的修改版本的权限传递给他人时，才可能拥有修改作品的权限。

These original program-specific proto-GPLs give an interesting window into the central ideas and devel- opment of copyleft. In particular, reviewing them shows how the text of the GPL we know has evolved to address more of the issues discussed earlier in § [1.2.3.]

这些起初特定于程序的原始GPL提供了一个了解著佐权的中心思想和发展的有趣窗口。此外，仔细研究它们可以看到我们熟悉的GPL文本是如何逐步演变以解决前面 [1.2.3.] 节中讨论过的更多问题的。

The GNU General Public License, Version 1

2.3 GNU通用公共许可证，第一版

In January 1989, the FSF announced that the GPL had been converted into a "subroutine" that could be reused not just for all FSF-copyrighted programs, but also by anyone else. As the FSF claimed in its announcement of the GPLv1:²

1989年1月，FSF宣布GPL已经被转换成为一个“子例程”，不仅可以被所有受FSF著作权保护的程序重复使用，还可以被任何其他人重复使用。正如FSF在GPLv1的公告中所宣称的那样：²

To make it easier to copyleft programs, we have been improving on the legalbol architecture of the General Public License to produce a new version that serves as a general-purpose subroutine: it can apply to any program without modification, no matter who is publishing it.

为了使著佐权程序更方便使用，我们一直在改进通用公共许可证的法律体系结构，以便产生一个可以作为通用子例程的新版本：无论由谁发布，它都适用于任何程序而无需修改。

This, like many inventive ideas, seems somewhat obvious in retrospect. But, the FSF had some bright people and access to good lawyers when it started. It took almost five years from the first copyleft licenses to get to a generalized, reusable GPLv1. In the context and mindset of the 1980s, this is not surprising. The idea of reusable licensing infrastructure was not only uncommon, it was virtually nonexistent! Even the early BSD licenses were simply copied and rewritten slightly for each new use.³ The GPLv1's innovation of reusable licensing infrastructure, an obvious fact today, was indeed a novel invention for its day.⁴

这一点，就像许多具有创造性的想法一样，回想起来似乎是显而易见的。但是，FSF在成立之初拥有一些人才，也能接触到优秀的律师。从第一个著佐权许可证到形成通用的、可重复使用的GPLv1，花了将近五年的时间。在20世纪80年代的背景和思维模式下，这并不奇怪。可重复使用基础许可的想法不仅不常见，而且几乎不存在！即使是早期的BSD许可证也只是通过简单地复制和改写来适应每个新用途。³GPLv1对可重复使用基础许可的创新，在今天是显而易见的事实，在当时确实是一项新颖的发明。⁴

The GNU General Public License, Version 2

2.4 GNU通用公共许可证，第二版

The GPLv2 was released two and a half years after GPLv1, and over the following sixteen years, it became the standard for copyleft licensing until the release of GPLv3 in 2007 (discussed in more detail in the next section).

GPLv2比GPLv1晚两年半发布，在接下来的16年里，它成为了著佐权许可的标准，直到2007年GPLv3发布(下一节将详细讨论)。

While this tutorial does not discuss the terms of GPLv1 in detail, it is worth noting below the three key changes that GPLv2 brought:

虽然本指南不详细讨论GPLv1的条款，但GPLv2带来的三个关键变化值得一提：

Software patents and their danger are explicitly mentioned, inspiring (in part) the addition of GPLv2 §§5--7. (These sections are discussed in detail in §7.2, §7.3 and §7.5 of this tutorial.) 软件专利及其风险被明确提及，(在一定程度上)激发了GPLv2 §§5-7的加入。(这些部分将在本指南的§7.2、§7.3和§7.5中详细讨论。)
GPLv2 §2's copyleft terms are expanded to more explicitly discuss the issue of combined works. (GPLv2 *§*2 is discussed in detail in § 5.1 in this tutorial).
GPLv2 §2的著佐权术语得到了扩展，可以更明确地讨论组合作品的问题。(GPLv2 §2将在本指南的§5.1中详细讨论)。
GPLv2 §3 includes more detailed requirements, including the phrase "the scripts used to control compi- lation and installation of the executable", which is a central component of current GPLv2 enforcement. (GPLv2 §3 is discussed in detail in §5.2 in this tutorial).
GPLv2 §3包含了更详细的需求，包括短语“用于控制可执行文件的编译和安装的脚本”，这是当前GPLv2实施的核心组件。(GPLv2 §3将在本指南的§5.2中详细讨论)。

The next chapter discusses GPLv2 in full detail, and readers who wish to dive into the section-by-section discussion of the GPL should jump ahead now to that chapter. However, the most interesting fact to note here is how GPLv2 was published with little fanfare and limited commentary. This contrasts greatly with the creation of GPLv3.

下一章将详细讨论GPLv2，希望深入了解GPL逐节讨论的读者现在可以跳到那一章。然而，这里要指出的最有趣的事实是，GPLv2是如何在没有大肆宣传和有限报道的情况下发布的。这与GPLv3的诞生形成了鲜明对比。

The GNU General Public License, Version 3

2.5 GNU通用公共许可证，第三版

RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups during that era about new text of that license. However, rampant violations of the GPL required more immediate attention of FSF's licensing staff, and as such, much of the early 2000's was spent doing GPL enforcement work.⁵ In 2006, FSF began in earnest drafting work for GPLv3.

RMS在2002年年中开始起草GPLv2.2, FSF在那个时期组织了一些讨论小组，讨论该许可证的新文本。然而，猖獗的GPL侵权行为需要FSF的授权人员更加及时的关注，因此，2000年早期的大部分时间都花在了GPL的实施工作上。5 2006年，FSF正式开始GPLv3的起草工作。

The GPLv3 process began in earnest in January 2006. It became clear that many provisions of the GPL could benefit from modification to fit new circumstances and to reflect what the entire community learned from experience with version 2. Given the scale of revision it seems proper to approach the work through public discussion in a transparent and accessible manner.

GPLv3的进程于2006年1月正式开始。很明显，GPL的许多条款可以从修改中完善，以适应新的情况并反映出整个社区从第二版的经验中得到的教训。考虑到修订的规模，似乎以透明和可访问的方式通过公开讨论来处理工作是合适的。

The GPLv3 process continued through June 2007, culminating in publication of GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC Runtime Library Exception on 27 January 2009.

GPLv3进程一直持续到2007年6月，最终于2007年6月29日发布了GPLv3和LGPLv3，并于2007年11月19日发布了AGPLv3，以及于2009年1月27日发布了GCC运行时库异常。

All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3 and two discussion drafts of AGPLv3 were published and discussed. Ultimately, FSF remained the final arbiter and publisher of the licenses, and RMS himself their primary author, but input was sought from many parties, and these licenses do admittedly look and read more like legislation as a result. Nevertheless, all of the "v3" group are substantially better and improved licenses.

总共发布并讨论了四份GPLv3讨论草案、两份LGPLv3讨论草案和两份AGPLv3讨论草案。最终，FSF仍然是许可证的最终仲裁者和出版方，RMS自己是许可证的主要作者，但是征求了许多人士的意见，因此这些许可证确实看起来和读起来更像立法。尽管如此，整个“v3”组都有了很大的改进，成为了更好的许可证。

GPLv3 and its terms are discussed in detail in Chapter [9.]

GPLv3及其术语将在第[9]章中详细讨论。

The Innovation of Optional "Or Any Later" Version

2.6 可选“或任何后来”版本的创新

An interesting fact of all GPL licenses is that there are ultimately multiple choices for use of the license. The FSF is the primary steward of GPL (as discussed later in §8.1 and §9.17). However, those who wish to license works under GPL are not required to automatically accept changes made by the FSF for their own copyrighted works.

所有GPL许可证的一个有趣的事实是：最终有多种使用许可证的选择。FSF是GPL的主要管理者（稍后将在*§8.1 和§*9.17).中讨论）。然而，那些希望在GPL下授权作品的人不需要自动接受FSF对他们自己受著作权保护的作品所做的更改。

Each licensor may chose three different methods of licensing, as follows:

每个许可人可以选择以下三种不同的许可方式：

explicitly name a single version of GPL for their work (usually indicated in shorthand by saying the license is "GPLvX-only"), or
为他们的作品明确指定一个GPL版本（一般用“仅限GPLvX”这样的简写来表示），或者
name no version of the GPL, thus they allow their downstream recipients to select any version of the GPL they choose (usually indicated in shorthand by saying the license is simply "GPL"), or
不指定GPL的任何版本，这样他们允许下游接收者任意选择GPL的任何版本（一般只简称许可证是“GPL”），或者
name a specific version of GPL and give downstream recipients the option to choose that version "or any later version as published by the FSF" (usually indicated by saying the license is "GPLvX-or-later")⁶
指定一个特定的GPL版本，并让下游接收者选择该版本“或由FSF发布的任何更高版本”（一般会说许可证是“GPLvX或更高版本”）。[^6^]

Oddly, this flexibility has received (in the opinion of the authors, undue) criticism, primarily because of the complex and oft-debated notion of "license compatibility" (which is explained in detail in 9.10). Copyleft licenses are generally incompatible with each other, because the details of how they implement copyleft differs. Specifically, copyleft works only because of its requirement that downstream licensors use the same license for combined and modified works. As such, software licensed under the terms of "GPLv2- only" cannot be combined with works licensed "GPLv3-or-later". This is admittedly a frustrating outcome.

奇怪的是，这种灵活性受到了（在作者看来是不适当的）批评，主要是因为“许可证兼容性”（x 9.10中有详细解释）的复杂性以及对其概念的争论不断。著佐权许可证通常彼此不兼容，因为履行著佐权的细节不同。具体来说，著佐权生效的唯一条件是它要求下游许可方对合并和修改的作品使用相同许可。因此，在“仅限GPLv2”条款下授权的软件不能与使用“GPLv3或更高版本”许可的作品结合。诚然，这是一个令人沮丧的结果。

Other copyleft licenses that appeared after GPL, such as the Creative Commons "Attribution-Share Alike" licenses, the Eclipse Public License and the Mozilla Public License require all copyright holders choosing to use any version of those licenses to automatically allow use of their copyrighted works under new versions.[^7^] Of course, Creative Commons, the Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally served as excellent stewards of their licenses. Copyright holders using those licenses seems to find it acceptable to fully delegate all future licensing decisions for their copyrights to these organizations without a second thought.

在GPL之后出现的其他著佐权许可证，如知识共享“署名-相同方式共享”许可证、Eclipse公共许可证和Mozilla公共许可证要求所有选择使用这些许可证的任何版本的著作权所有者自动允许在新版本下使用其受著作权保护的作品。7 当然，知识共享组织、Eclipse基金会和Mozilla基金会（像FSF一样）通常都是他们自己的许可证的优秀管理员。使用这些许可证的著作权所有者似乎发现可以毫不犹豫地将其著作权的所有未来许可决策完全委托给这些组织。

However, note that FSF gives herein the control of copyright holders to decide whether or not to implicitly trust the FSF in its work of drafting future GPL versions. The FSF, for its part, does encourage copyright holders to chose by default "GPLvX-or-later" (where X is the most recent version of the GPL published by the FSF). However, the FSF does not mandate that a choice to use any GPL requires a copyright holder ceding its authority for future licensing decisions to the FSF. In fact, the FSF considered this possibility for GPLv3 and chose not to do so, instead opting for the third-party steward designation clause discussed in Section 9.17.

但是请注意，FSF在此赋予了著作权所有者决策权，他们可以决定是否在起草未来GPL版本的工作中绝对信任FSF。就FSF而言，它确实鼓励著作权所有者默认选择“GPLvX或更高版本”（其中X是FSF发布的GPL的最新版本）。然而，FSF并没有强制要求选择使用任何GPL需要著作权所有者将其未来许可决策的权力交给FSF。事实上，FSF考虑了GPLv3的这种可能性却选择不这样做，而是选择了9.17.节中讨论的第三方管理指定条款。

Complexities of Two Simultaneously Popular Copylefts

2.7 两个著佐权同时普遍使用的复杂性

Obviously most GPL advocates would prefer widespread migration to GPLv3, and many newly formed projects who seek a copyleft license tend to choose a GPLv3-based license. However, many existing copylefted projects continue with GPLv2-only or GPLv2-or-later as their default license.

显然，大多数GPL倡导者更倾向于广泛迁移至GPLv3，而且许多新成立的项目在挑选著佐权许可证时倾向于选择基于GPLv3的许可证。然而，许多现有受著佐权保护的项目仍继续使用“仅限GPLv2”或“GPLv2或更高版本”作为默认许可证。

While GPLv3 introduces many improvements --- many of which were designed to increase adoption by for-profit companies --- GPLv2 remains a widely used and extremely popular license. The GPLv2 is, no doubt, a good and useful license.

虽然GPLv3引入了许多改进——其中许多改进旨在促进营利性公司的采用——GPLv2仍是一个被广泛使用和非常受欢迎的许可证。毫无疑问，GPLv2是一个优秀且实用的许可证。

However, unlike GPLv1 before it, GPLv2 remains an integral part of the copyleft licensing infrastructure. As such, those who seek to have expertise in current topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of licenses.

然而，与之前的GPLv1不同的是，GPLv2仍然是著佐权基础许可中不可分割的一部分。因此，那些希望在当前著佐权许可相关的话题方面拥有专业知识的人需要同时研究GPLv2和GPLv3系列许可证。

Furthermore, GPLv3 is more easily understood by first studying GPLv2. This is not only because of their chronological order, but also because much of the discussion material available for GPLv3 tends to talk about GPLv3 in contrast to GPLv2. As such, a strong understanding of GPLv2 helps in understanding most of the third-party material found regarding GPLv3. Thus, the following chapter begins a deep discussion of GPLv2.

此外，先研究GPLv2会更容易理解GPLv3。这不仅是因为它们的时间顺序，还因为许多关于GPLv3的可用讨论材料倾向于将GPLv3与GPLv2进行对比。因此，对GPLv2的深刻理解有助于理解大多数关于GPLv3的第三方材料。因此，下一章开始深入讨论GPLv2。

CHAPTER 3 RUNNING SOFTWARE AND VERBATIM COPYING

第3章运行软件与逐字复制

This chapter begins the deep discussion of the details of the terms of GPLv2. In this chapter, we consider the first two sections: GPLv2 §§0--2. These are the straightforward sections of the GPL that define the simplest rights that the user receives.

本章开始深入讨论GPLv2条款的细节。在本章中，我们将考虑前两个部分：GPLv2 第0-2条。这些是GPL中简单明了的部分，定义了用户获得的最单纯的权利。

3.1 GPLv2 §0: Freedom to Run

3.1 GPLv2 §0：自由运行

GPLv2 §0, the opening section of GPLv2, sets forth that copyright law governs the work. It specifically points out that it is the "copyright holder" who decides if a work is licensed under its terms and explains how the copyright holder might indicate this fact.

GPLv2 §0——GPLv2的开篇部分阐述了作品受著作权法管辖。该部分特别指出由“著作权所有者”决定作品是否根据其条款进行许可，并解释了著作权所有者如何表明这一事实。

A bit more subtly, GPLv2 §0 makes an inference that copyright law is the only system that can restrict the software. Specifically, it states:

更微妙的一点是，GPLv2 §0推断著作权法是唯一可以限制软件的系统。具体来说，它指出:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.

本许可证对除复制、分发和修改外的其他活动无效；它们超出了其适用范围。

In essence, the license governs only those activities, and all other activities are unrestricted, provided that no other agreements trump GPLv2 (which they cannot; see Sections 7.3 and 7.5). This is very important, because the Free Software community heavily supports users' rights to "fair use" and "unregulated use" of copyrighted material. GPLv2 asserts through this clause that it supports users' rights to fair and unregulated uses.

本质上，许可证只管理这些活动，所有其他活动都是不受限制的，如果没有其他协议限制GPLv2（这是不可能的；参见第7.3和7.5).节）。这是非常重要的，因为自由软件社区大力支持用户享有对受著作权保护的材料的“合理使用”和“不受管制的使用”的权利。GPLv2通过这一条款声明它支持用户公平和不受管制的使用权利。

Fair use (called "fair dealing" in some jurisdictions) of copyrighted material is an established legal doctrine that permits certain activities regardless of whether copyright law would otherwise restrict those activities. Discussion of the various types of fair use activity are beyond the scope of this tutorial. However, one important example of fair use is the right to quote portions of the text in a larger work so as to criticize or suggest changes. This fair use right is commonly used on mailing lists when discussing potential improvements or changes to Free Software.

对受著作权保护的材料的合理使用（在某些司法管辖区称为“公平交易”）是一种既定的法律原则，允许进行某些活动而不管著作权法是否会限制这些活动。关于各种类型的合理使用活动的讨论超出了本指南的范围。然而，合理使用的一个重要典型是有权在较大的作品中引用文本的部分内容，以便进行批评或提出修改建议。当讨论自由软件的潜在改进或变化时，这种合理使用权在邮件列表中会被经常使用。

Fair use is a doctrine established by the courts or by statute. By contrast, unregulated uses are those that are not covered by the statue nor determined by a court to be covered, but are common and enjoyed by many users. An example of unregulated use is reading a printout of the program's source code like an instruction book for the purpose of learning how to be a better programmer. The right to read something that you have access to is and should remain unregulated and unrestricted.

合理使用是由法院或法令确立的原则。相比之下，不受管制的使用是指那些不受法令保护也不在法院管辖范围内、但很常见且深受广大用户喜爱的使用方式。它的一个例子是：为了学习如何成为一个更好的程序员，像阅读说明书一样阅读程序源代码的打印资料。阅读你能读到的东西的权利是且应该保持不受监管和限制的。

Thus, the GPLv2 protects users' fair and unregulated use rights precisely by not attempting to cover them. Furthermore, the GPLv2 ensures the freedom to run specifically by stating the following:

因此，GPLv2正是通过不试图包含它们来保护用户的公平和不受监管的使用权。此外，GPLv2通过声明以下内容确保了运行的自由：

"The act of running the Program is not restricted."

“运行程序的行为不受限制。”

Thus, users are explicitly given the freedom to run by GPLv2 §0.

因此，用户明确地获得了使用GPLv2 §0运行的自由。

The bulk of GPLv2 §0 not yet discussed gives definitions for other terms used throughout. The only one worth discussing in detail is "work based on the Program". The reason this definition is particularly interesting is not for the definition itself, which is rather straightforward, but because it clears up a common misconception about the GPL.

尚未讨论的大部分GPLv2 §0给出了贯穿始终的其他术语的定义。唯一值得详细讨论的是“基于程序的作品”。这个定义之所以特别有趣不是因为这个相当简明的定义本身，而是因为它澄清了关于GPL的一个常见误解。

The GPL is often mistakenly criticized because it fails to give a definition of "derivative work" or "com- bined work". In fact, it would be incorrect and problematic if the GPL attempted to define these terms. A copyright license, in fact, has no control over the rules of copyright themselves. Such rules are the domain of copyright law and the courts --- not the licenses that utilize those systems.

GPL经常被错误地批评，因为它没有给出“衍生作品”或“组合作品”的定义。事实上，如果GPL试图定义这些术语，才是不正确且有问题的。著作权许可证实际上并不能控制著作权规则本身。这样的规则属于著作权法和法院（而不是使用这些系统的许可证）的管辖范围。

Copyright law as a whole does not propose clear and straightforward guidelines for identifying the deriva- tive and/or combined works of software. However, no copyright license --- not even the GNU GPL --- can be blamed for this. Legislators and court opinions must give us guidance in borderline cases. Meanwhile, lawyers will likely based their conclusions on the application of rules made in the context of literary or artistic copyright to the different context of computer programming and by analyzing the (somewhat limited) case law and guidance available from various sources. (Chapter [14.1] discusses this issue in depth.)

著作权法整体并没有就识别软件的衍生作品和/或组合作品提出明确而直接的指导方针。然而，没有著作权许可证——甚至GNU GPL——才应该对此负责。立法者和法院必须在边界模糊的案件中为我们提供指导。与此同时，律师们可能会根据文学或艺术著作权背景下制定的规则在计算机编程的不同背景下的应用情况，以及通过分析（有限的）案例法和各种渠道获得的指导来得出结论。（第[14.1]节深入讨论了这个问题。）

3.2 GPLv2 §1: Verbatim Copying

3.2 GPLv2 §1：逐字复制

GPLv2 §1 covers the matter of redistributing the source code of a program exactly as it was received. This section is quite straightforward. However, there are a few details worth noting here.

GPLv2 第1条涵盖了重新完整分发程序源代码的问题。这部分相当简单明了。但有一些细节值得一提。

The phrase "in any medium" is important. This, for example, gives the freedom to publish a book that is the printed copy of the program's source code. It also allows for changes in the medium of distribution. Some vendors may ship Free Software on a CD, but others may place it right on the hard drive of a pre-installed computer. Any such redistribution media is allowed.

“在任何媒介中”这句话很重要。举个例子，它交出了将程序源代码的打印副本作为一本书出版的自由。它还允许更改分发媒介。一些厂商可能以CD的形式推出自由软件，但其他厂商可能将其直接置入预装计算机的硬盘驱动器中。任何这样的重新分发媒体都是允许的。

Preservation of copyright notice and license notifications are mentioned specifically in GPLv2 *§*1. These are in some ways the most important part of the redistribution, which is why they are mentioned by name. GPL always strives to make it abundantly clear to anyone who receives the software what its license is. The goal is to make sure users know their rights and freedoms under GPL, and to leave no reason that users might be surprised the software is GPL'd. Thus throughout the GPL, there are specific references to the importance of notifying others down the distribution chain that they have rights under GPL.

GPLv2 §1中特别提到著作权通知和许可证通知的保存。在某种程度上，这些是重新分发作品中最重要的部分，这就是提及它们的原因。GPL一直在努力让收到软件的人都清楚地知道它的许可证是什么。我们的目标是确保用户知道他们在GPL限制下的权利和自由，没有理由让用户对软件使用GPL感到惊讶。因此，整个GPL中都有专门提到通知分发链下游的其他人他们拥有GPL限制下的权利的重要性。

GPL disclaims all warranties that legally can be disclaimed (which is discussed later in sections 8.3 and 8.4). Users generally rarely expect their software comes with any warranties, since typically all EULAs and other Free Software licenses disclaim warranties too. However, since many local laws require "consipi- cous" warranty disclaimers, GPLv2 1 explicitly mentions the importance of keeping warranty disclaimers in tact upon redistribution.

GPL放弃所有法律上可以放弃的担保（这将在后面的8.3节和8.4).节中讨论）。用户通常很少期望他们的软件附带任何担保，因为通常所有的EULA和其他自由软件许可证也都放弃担保。然而，由于许多地方法律要求“明显的”免责声明，GPLv2 *§*1明确提到在重新分发时完整保留免责声明的重要性。

Note finally that GPLv2 §1 creates groundwork for the important defense of commercial freedom. GPLv2 §1 clearly states that in the case of verbatim copies, one may make money. Re-distributors are fully permitted to charge for the re-distribution of copies of Free Software. In addition, they may provide the warranty protection that the GPL disclaims as an additional service for a fee. (See Section [12.2] for more discussion on making a profit from Free Software redistribution.)

最后请注意，GPLv2 §1为捍卫商业自由奠定了基础。GPLv2 §1明确指出在逐字复制的情况下可以赚钱。重新分发者对自由软件副本的重新分发版进行收费是完全允许的。此外，他们还可以提供GPL拒绝的担保，将其作为附加服务进行收费。（有关从自由软件重新分发中获利的更多讨论，请参见第[12.2]节。）

CHAPTER 4 DERIVATIVE WORKS: STATUTE AND CASE LAW

第四章衍生作品：法规和案例法

As described in the [earlier general discussion of copylef]t, strong copyleft licenses such as the GPL seek to uphold software freedom via the copyright system. This principle often causes theoretical or speculative dispute among lawyers, because "the work" --- the primary unit of consideration under most copyright rules -- is not a unit of computer programming. In order to determine whether a "routine" an "object", a "function", a "library" or any other unit of software is part of one "work" when combined with other GPL'd code, we must ask a question that copyright law will not directly answer in the same technical terms.

如前面关于copyleft的一般讨论所述，像GPL这样的强制copyleft许可证通过版权系统来维护软件自由。这一原则经常引起律师之间的理论或推测性争议，因为在大多数版权规则下，“作品”——最主要的考虑单位——并不是计算机编程的一个单位。为了确定一个“程序”，一个“对象”，一个“函数”，一个“库”或任何其他软件单位，当与其他GPL代码组合时是否是一个“作品”，我们必须提出一个版权法直接无法用同样的技术术语回答的问题。

Therefore, this chapter digresses from discussion of GPL's exact text to consider the matter of combined and/or derivative works --- a concept that we must understand fully before considering GPLv2 2--3. At least under USA copyright law, The GPL, and Free Software licensing in general, relies critically on the concept of "derivative work" since software that is "independent," (i.e., not "derivative") of Free Software need not abide by the terms of the applicable Free Software license. As much is required by 106 of the Copyright Act, 17 U.S.C. 106 (2002), and admitted by Free Software licenses, such as the GPL, which (as we have seen) states in GPLv2 0 that "a 'work based on the Program' means either the Program or any derivative work under copyright law." It is being a derivative work of Free Software that triggers the necessity to comply with the terms of the Free Software license under which the original work is distributed. Therefore, one is left to ask, just what is a "derivative work"? The answer to that question differs depending on which court is being asked.

因此，在考虑GPL的确切文本之前，本章偏离讨论合并和/或衍生作品的问题——这是一个我们必须完全理解的概念，才能考虑GPLv2 2-3。至少在美国版权法下，GPL和自由软件许可证的普遍使用，关键在于“衍生作品”的概念，因为独立于自由软件的软件（即不是“衍生”软件）不必遵守适用的自由软件许可证条款。这在版权法第106条、17 U.S.C. 106（2002）中被要求，并被自由软件许可证，如GPL所承认，GPLv2 0规定：“基于该程序的作品”指的是该程序或根据版权法的任何衍生作品。”只有成为自由软件的衍生作品才会触发需要遵守原始作品所分发的自由软件许可证条款的必要性。因此，人们不得不问，什么是“衍生作品”？这个问题的答案取决于被问的是哪个法院。

The analysis in this chapter sets forth the differing definitions of derivative work by the circuit courts. The broadest and most established definition of derivative work for software is the abstraction, filtration, and comparison test ("the AFC test") as created and developed by the Second Circuit. Some circuits, including the Ninth Circuit and the First Circuit, have either adopted narrower versions of the AFC test or have expressly rejected the AFC test in favor of a narrower standard. Further, several other circuits have yet to adopt any definition of derivative work for software.

本章分析了各个巡回法院对派生作品的不同定义。对于软件而言，最广泛和最成熟的派生作品定义是由第二巡回法院创造和发展的抽象、过滤和比较测试（“AFC测试”）。包括第九巡回法院和第一巡回法院在内的一些巡回法院已经采用了AFC测试的较窄版本，或明确拒绝了AFC测试，而采用了较窄的标准。此外，其他几个巡回法院还没有采用任何关于软件派生作品的定义。

As an introductory matter, it is important to note that literal copying of a significant portion of source code is not always sufficient to establish that a second work is a derivative work of an original program. Conversely, a second work can be a derivative work of an original program even though absolutely no copying of the literal source code of the original program has been made. This is the case because copyright protection does not always extend to all portions of a program's code, while, at the same time, it can extend beyond the literal code of a program to its non-literal aspects, such as its architecture, structure, sequence, organization, operational modules, and computer-user interface.

作为一个引言，需要注意的是，直接复制源代码的大部分并不总是足以证明第二个作品是原始程序的派生作品。相反，即使完全没有复制原始程序的字面源代码，第二个作品也可以是原始程序的派生作品。这是因为版权保护并不总是延伸到程序代码的所有部分，同时，它也可以超越程序的字面代码，涵盖程序的非字面方面，例如其结构、序列、组织、操作模块和计算机用户界面。

The Copyright Act

4.1 版权法

The copyright act is of little, if any, help in determining the definition of a derivative work of software. However, the applicable provisions do provide some, albeit quite cursory, guidance. Section 101 of the Copyright Act sets forth the following definitions:

版权法在确定软件衍生作品的定义方面没有多少帮助，然而，适用的规定确实提供了一些相当肤浅的指导。版权法第101条规定了以下定义：

A "computer program" is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.

“计算机程序”是一组语句或指令，直接或间接用于计算机，以实现某种结果。

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a "derivative work."

“衍生作品”是基于一个或多个现有作品的作品，例如翻译、音乐编排、戏剧化、虚构化、电影版本、录音、艺术复制、缩写、概括或任何其他形式，在其中一个作品可以被重构、转化或改编。由编辑修订、注释、阐述或其他修改组成的作品，如果整体上代表了一部独创性作品，则为“衍生作品”。

These are the only provisions in the Copyright Act relevant to the determination of what constitutes a derivative work of a computer program. Another provision of the Copyright Act that is also relevant to the definition of derivative work is § 102(b), which reads as follows:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

在任何情况下，对于作者原创的作品，版权保护都不会扩展到其中包含的任何思想、程序、流程、系统、操作方法、概念、原理或发现，无论其以何种形式被描述、解释、说明或体现在该作品中。

Therefore, before a court can ask whether one program is a derivative work of another program, it must be careful not to extend copyright protection to any ideas, procedures, processes, systems, methods of operation, concepts, principles, or discoveries contained in the original program. It is the implementation of this requirement to "strip out" unprotectable elements that serves as the most frequent issue over which courts disagree.

因此，在法院可以询问一个程序是否是另一个程序的衍生作品之前，必须小心不要将原始程序中包含的任何思想、程序、流程、系统、操作方法、概念、原理或发现扩展到版权保护范围之内。解决“剥离”不受保护元素的问题，是法院之间最常见的争议问题。

4.2 Abstraction, Filtration, Comparison Test

4.2 抽象、筛选、比较测试

As mentioned above, the AFC test for determining whether a computer program is a derivative work of an earlier program was created by the Second Circuit and has since been adopted in the Fifth, Tenth, and Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982 F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe, Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993); Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings, Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).

如上所述，用于确定计算机程序是否是早期程序的派生作品的AFC测试是由第二巡回法院创建的，自那时以来已被第五、第十和第十一巡回法院采纳。具体案例包括：Computer Associates Intl.，Inc. v. Altai，Inc.，982 F.2d 693（第二巡回法院1992年）；Engineering Dynamics，Inc. v. Structural Software，Inc.，26 F.3d 1335（第五巡回法院1994年）；Kepner-Tregoe，Inc. v. Leadership Software，Inc.，12 F.3d 527（第五巡回法院1994年）；Gates Rubber Co. v. Bando Chem. Indust.，Ltd.，9 F.3d 823（第十巡回法院1993年）；Mitel，Inc. v. Iqtel，Inc.，124 F.3d 1366（第十巡回法院1997年）；Bateman v. Mnemonics，Inc.，79 F.3d 1532（第十一巡回法院1996年）；以及Mitek Holdings，Inc. v. Arce Engineering Co.，Inc.，89 F.3d 1548（第十一巡回法院1996年）。

Under the AFC test, a court first abstracts from the original program its constituent structural parts. Then, the court filters from those structural parts all unprotectable portions, including incorporated ideas, expression that is necessarily incidental to those ideas, and elements that are taken from the public domain. Finally, the court compares any and all remaining kernels of creative expression to the structure of the second program to determine whether the software programs at issue are substantially similar so as to warrant a finding that one is the derivative work of the other.

在AFC测试中，法院首先从原始程序中抽象出其组成结构部分。然后，法院从这些结构部分中筛选出所有不可保护的部分，包括融入的想法、与这些想法必然有关的表达和从公共领域中获取的元素。最后，法院比较任何和所有剩余的创造性表达核心与第二个程序的结构，以确定所涉及的软件程序是否存在实质相似，从而认定其中一个是另一个的派生作品。

Often, the courts that apply the AFC test will perform a quick initial comparison between the entirety of the two programs at issue in order to help determine whether one is a derivative work of the other. Such a holistic comparison, although not a substitute for the full application of the AFC test, sometimes reveals a pattern of copying that is not otherwise obvious from the application of the AFC test when, as discussed below, only certain components of the original program are compared to the second program. If such a pattern is revealed by the quick initial comparison, the court is more likely to conclude that the second work is indeed a derivative of the original.

通常，应用AFC测试的法院将对所涉及的两个程序的整体进行快速的初步比较，以帮助确定其中一个是否是另一个的派生作品。虽然这种整体比较并不能代替对AFC测试的全面应用，但有时它可以显示出从原始程序的某些组件与第二个程序进行比较时并不明显的复制模式。如果快速的初步比较揭示了这样的模式，法院更有可能得出结论，即第二个作品确实是原作的派生作品。

4.2.1 Abstraction

4.2.１抽象化

The first step courts perform under the AFC test is separation of the work's ideas from its expression. In a process akin to reverse engineering, the courts dissect the original program to isolate each level of abstraction contained within it. Courts have stated that the abstractions step is particularly well suited for computer programs because it breaks down software in a way that mirrors the way it is typically created. However, the courts have also indicated that this step of the AFC test requires substantial guidance from experts, because it is extremely fact and situation specific.

根据 AFC 测试，法院执行的第一步是将作品的想法与表达方式分开。类似于反向工程的过程，法院解剖原始程序以隔离其中包含的每个抽象级别。法院表示，由于它以与软件通常创建方式相似的方式将软件分解，因此抽象化步骤特别适用于计算机程序。然而，法院还指出，AFC 测试的这一步骤需要专家的大量指导，因为它具有极其事实和情况的特定性。

By way of example, one set of abstraction levels is, in descending order of generality, as follows: the main purpose, system architecture, abstract data types, algorithms and data structures, source code, and object code. As this set of abstraction levels shows, during the abstraction step of the AFC test, the literal elements of the computer program, namely the source and object code, are defined as particular levels of abstraction. Further, the source and object code elements of a program are not the only elements capable of forming the basis for a finding that a second work is a derivative of the program. In some cases, in order to avoid a lengthy factual inquiry by the court, the owner of the copyright in the original work will submit its own list of what it believes to be the protected elements of the original program. In those situations, the court will forgo performing its own abstraction, and proceed to the second step of the AFC test.

例如，一个抽象级别集合按照从一般到具体的顺序如下：主要目的、系统架构、抽象数据类型、算法和数据结构、源代码和目标代码。正如这组抽象级别所示，在 AFC 测试的抽象化步骤中，计算机程序的字面元素，即源代码和目标代码，被定义为特定的抽象级别。此外，程序的源代码和目标代码元素并不是形成发现第二个作品是原始程序的衍生作品的唯一元素。在某些情况下，为了避免法院进行冗长的事实调查，原始作品的版权所有人将提交其自己的保护元素列表。在这种情况下，法院将放弃执行自己的抽象化，直接进行 AFC 测试的第二步骤。

4.2.2 Filtration

4.2.2 过滤

The most difficult and controversial part of the AFC test is the second step, which entails the filtration of protectable expression contained in the original program from any unprotectable elements nestled therein. In determining which elements of a program are unprotectable, courts employ a myriad of rules and procedures to sift from a program all the portions that are not eligible for copyright protection.

AFC测试中最具争议和难度的部分是第二步，涉及从原始程序中筛选出包含保护性表达的部分，并从中滤除任何非保护性的元素。在确定程序中哪些元素是不受保护的时，法院采用各种规则和程序来筛选出所有不符合版权保护资格的部分。

First, as set forth in 102(b) of the Copyright Act, any and all ideas embodied in the program are to be denied copyright protection. However, implementing this rule is not as easy as it first appears. The courts readily recognize the intrinsic difficulty in distinguishing between ideas and expression and that, given the varying nature of computer programs, doing so will be done on an ad hoc basis. The first step of the AFC test, the abstraction, exists precisely to assist in this endeavor by helping the court separate out all the individual elements of the program so that they can be independently analyzed for their expressive nature. A second rule applied by the courts in performing the filtration step of the AFC test is the doctrine of merger, which denies copyright protection to expression necessarily incidental to the idea being expressed. The reasoning behind this doctrine is that when there is only one way to express an idea, the idea and the expression merge, meaning that the expression cannot receive copyright protection due to the bar on copyright protection extending to ideas. In applying this doctrine, a court will ask whether the program's use of particular code or structure is necessary for the efficient implementation of a certain function or process. If so, then that particular code or structure is not protected by copyright and, as a result, it is filtered away from the remaining protectable expression.

首先，根据版权法第102（b）条款，程序中包含的所有想法都将被否认版权保护。然而，执行此规则并不像它最初看起来那么容易。法院充分认识到区分思想和表达之间的内在困难，鉴于计算机程序的多样性，这样做将是一个临时性的基础。 AFC测试的第一步——抽象，恰恰是为了帮助法院将程序的所有单独元素分离出来，以便可以独立地分析它们的表现性质。法院在执行AFC测试的过程中应用的第二个规则是合并原则，该原则否认与表达所表达的思想必然相关的表达的版权保护。这个原则的理由是，当只有一种表达思想的方式时，思想和表达合并，意味着由于版权保护不扩展到思想，表达不能获得版权保护。在应用这个原则时，法院将询问程序是否使用特定的代码或结构对某个功能或流程的高效实现是必需的。如果是，那么该特定代码或结构不受版权保护，因此从其余可保护表达式中过滤掉。

A third rule applied by the courts in performing the filtration step of the AFC test is the doctrine of scenes a faire, which denies copyright protection to elements of a computer program that are dictated by external factors. Such external factors can include:

法院在执行AFC测试的筛选步骤中应用的第三个规则是通用场景原则，该原则否认由外部因素决定的计算机程序的元素的版权保护。这些外部因素可以包括：

The mechanical specifications of the computer on which a particular program is intended to operate
Compatibility requirements of other programs with which a program is designed to operate in conjunc- tion
Computer manufacturers' design standards
Demands of the industry being serviced, and widely accepted programming practices within the computer industry
特定程序的计算机的机械规格
与设计为一起运行的其他程序的兼容性要求
计算机制造商的设计标准
所服务的行业的需求以及计算机行业内广泛接受的编程实践

Any code or structure of a program that was shaped predominantly in response to these factors is filtered out and not protected by copyright. Lastly, elements of a computer program are also to be filtered out if they were taken from the public domain or fail to have sufficient originality to merit copyright protection.

如果程序的任何代码或结构主要是针对这些因素而形成的，则会被过滤掉，并且不受版权保护。最后，如果计算机程序的元素来自公共领域或缺乏足够的原创性，也应该被过滤掉。

Portions of the source or object code of a computer program are rarely filtered out as unprotectable elements. However, some distinct parts of source and object code have been found unprotectable. For example, constants, the invariable integers comprising part of formulas used to perform calculations in a program, are unprotectable. Further, although common errors found in two programs can provide strong evidence of copying, they are not afforded any copyright protection over and above the protection given to the expression containing them.

计算机程序的源代码或目标代码的部分很少被过滤为不可保护元素。然而，有些源代码和目标代码的独特部分被发现是不可保护的。例如，常量，即组成程序中用于执行计算的公式的不变整数，是不可保护的。此外，虽然在两个程序中发现的常见错误可以提供复制的强有力证据，但它们不享有任何超出包含它们的表达所享有的版权保护。

4.2.3 Comparison

4.2.3 比较

The third and final step of the AFC test entails a comparison of the original program's remaining protectable expression to a second program. The issue will be whether any of the protected expression is copied in the second program and, if so, what relative importance the copied portion has with respect to the original program overall. The ultimate inquiry is whether there is "substantial" similarity between the protected elements of the original program and the potentially derivative work. The courts admit that this process is primarily qualitative rather than quantitative and is performed on a case-by-case basis. In essence, the comparison is an ad hoc determination of whether the protectable elements of the original program that are contained in the second work are significant or important parts of the original program. If so, then the second work is a derivative work of the first. If, however, the amount of protectable elements copied in the second work are so small as to be de minimis, then the second work is not a derivative work of the original.

AFC测试的第三个也是最后一个步骤是将原始程序剩余的可保护表达式与第二个程序进行比较。问题在于第二个程序中是否复制了任何受保护的表达式，如果有，复制部分在整个原始程序中的相对重要性是什么。最终的问题是原始程序的受保护元素与潜在的衍生作品之间是否存在“实质性”相似性。法院承认这个过程主要是定性而非定量的，是根据具体情况进行的。实质上，比较是一种临时决定，用于确定第二个作品中包含的原始程序可保护元素是否是原始程序的重要组成部分。如果是，那么第二个作品就是第一个作品的衍生作品。然而，如果第二个作品中复制的可保护元素数量非常少，以至于可以视为微不足道，则第二个作品不是原始作品的衍生作品。

4.3 Analytic Dissection Test

4.3 分析解剖测试

The Ninth Circuit has adopted the analytic dissection test to determine whether one program is a derivative work of another. Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic dissection test first considers whether there are substantial similarities in both the ideas and expressions of the two works at issue. Once the similar features are identified, analytic dissection is used to determine whether any of those similar features are protected by copyright. This step is the same as the filtration step in the AFC test. After identifying the copyrightable similar features of the works, the court then decides whether those features are entitled to "broad" or "thin" protection. "Thin" protection is given to non-copyrightable facts or ideas that are combined in a way that affords copyright protection only from their alignment and presentation, while "broad" protection is given to copyrightable expression itself. Depending on the degree of protection afforded, the court then sets the appropriate standard for a subjective comparison of the works to determine whether, as a whole, they are sufficiently similar to support a finding that one is a derivative work of the other. "Thin" protection requires the second work be virtually identical in order to be held a derivative work of an original, while "broad" protection requires only a "substantial similarity."

第九巡回上诉法院采用了分析解剖测试来确定一个程序是否是另一个程序的衍生作品。《苹果电脑公司诉微软公司》（Apple Computer, Inc. v. Microsoft Corp.）, 35 F.3d 1435 (9th Cir. 1994)。分析解剖测试首先考虑两个作品的观点和表达是否存在实质性的相似之处。一旦发现相似之处，就使用分析解剖来确定是否有任何受版权保护的相似之处。这一步与AFC测试中的过滤步骤相同。在确定了两个作品中受版权保护的相似之处后，法院将决定这些特征是否有“广泛”的或“薄弱”的保护。对于非版权保护的事实或观点，如果它们只是通过组合而获得版权保护，则只有其结构和表达方式才受到“薄弱”保护，而版权保护的表达方式本身则获得“广泛”保护。根据所享有的保护程度，法院随后确定了适当的标准来进行主观比较，以确定两个作品是否整体上足够相似，从而支持其中一个作品是另一个作品的衍生作品的结论。如果采用“薄弱”保护，第二个作品必须几乎完全相同才能被认为是原始作品的衍生作品；而如果采用“广泛”保护，则只需要存在“实质性相似性”。

4.4 No Protection for "Methods of Operation"

4.4 “操作方法”不受保护

The First Circuit has taken the position that the AFC test is inapplicable when the works in question relate to unprotectable elements set forth in 102(b). Their approach results in a much narrower definition of derivative work for software in comparison to other circuits. Specifically, the First Circuit holds that "method of operation," as used in 102(b) of the Copyright Act, refers to the means by which users operate computers. Lotus Development Corp. v. Borland Int'l., Inc., 49 F.3d 807 (1st Cir. 1995). In Lotus, the court held that a menu command hierarchy for a computer program was uncopyrightable because it did not merely explain and present the program's functional capabilities to the user, but also served as a method by which the program was operated and controlled. As a result, under the First Circuit's test, literal copying of a menu command hierarchy, or any other "method of operation," cannot form the basis for a determination that one work is a derivative of another. As a result, courts in the First Circuit that apply the AFC test do so only after applying a broad interpretation of 102(b) to filter out unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 683 F. Supp.2d 147, 154 (D. Mass. 2010).

第一巡回法院认为，当涉及到《版权法案》第102(b)条列出的不受保护元素时，AFC测试不适用于所讨论的作品。他们的方法相对于其他巡回法院的软件派生作品定义更为狭窄。具体来说，第一巡回法院认为，《版权法案》第102(b)条所使用的“操作方法”是指用户操作计算机的方式。在Lotus Development Corp. v. Borland Int'l., Inc.案中，法院认为，计算机程序的菜单命令层次结构是无法受版权保护的，因为它不仅仅是向用户解释和展示程序的功能能力，还作为控制程序操作的方法。因此，在第一巡回法院的测试中，菜单命令层次结构或其他“操作方法”的文字复制不能成为确定一部作品是否为另一部作品的派生作品的依据。因此，适用AFC测试的第一巡回法院在筛选出未受保护元素的广泛解释之后，才会适用该测试。例如，Real View, LLC v. 20-20 Technologies, Inc., 683 F. Supp.2d 147, 154 (D. Mass. 2010)案。

4.5 No Test Yet Adopted

4.5 尚未采用测试

Several circuits, most notably the Fourth and Seventh, have yet to declare their definition of derivative work and whether or not the AFC, Analytic Dissection, or some other test best fits their interpretation of copyright law. Therefore, uncertainty exists with respect to determining the extent to which a software program is a derivative work of another in those circuits. However, one may presume that they would give deference to the AFC test since it is by far the majority rule among those circuits that have a standard for defining a software derivative work.

几个巡回法院，尤其是第四和第七巡回法院，尚未宣布他们对派生作品的定义以及AFC测试、分析性解剖或其他测试是否最适合他们对版权法的解释。因此，在这些巡回法院中，仍然存在不确定性，无法确定软件程序在多大程度上是另一部作品的派生作品。然而，可以假定他们会尊重AFC测试，因为在那些已经有定义软件派生作品标准的巡回法院中，AFC测试明显占多数。

4.6 Cases Applying Software Derivative Work Analysis

4.6 应用于软件衍生作品分析的案例

In the preeminent case regarding the definition of a derivative work for software, Computer Associates v. Altai, the plaintiff alleged that its program, Adapter, which was used to handle the differences in operating system calls and services, was infringed by the defendant's competitive program, Oscar. About 30% of Oscar was literally the same code as that in Adapter. After the suit began, the defendant rewrote those portions of Oscar that contained Adapter code in order to produce a new version of Oscar that was functionally competitive with Adapter, without having any literal copies of its code. Feeling slighted still, the plaintiff alleged that even the second version of Oscar, despite having no literally copied code, also infringed its copyrights. In addressing that question, the Second Circuit promulgated the AFC test.

在关于软件衍生作品定义的权威案例Computer Associates v. Altai中，原告声称其用于处理操作系统调用和服务差异的程序Adapter被被告的竞争性程序Oscar侵犯了。 Oscar约30％的代码与Adapter的代码完全相同。诉讼开始后，被告重写了那些包含Adapter代码的Oscar部分，以产生一个新版本的Oscar，它在没有任何字面上的代码副本的情况下在功能上与Adapter竞争。尽管如此，原告声称，即使是Oscar的第二个版本，尽管没有任何文字上复制的代码，也侵犯了它的版权。在回答这个问题时，第二巡回法院颁布了AFC测试。

In abstracting the various levels of the program, the court noted a similarity between the two programs' parameter lists and macros. However, following the filtration step of the AFC test, only a handful of the lists and macros were protectable under copyright law because they were either in the public domain or required by functional demands on the program. With respect to the handful of parameter lists and macros that did qualify for copyright protection, after performing the comparison step of the AFC test, it was reasonable for the district court to conclude that they did not warrant a finding of infringement given their relatively minor contribution to the program as a whole. Likewise, the similarity between the organizational charts of the two programs was not substantial enough to support a finding of infringement because they were too simple and obvious to contain any original expression.

在抽象化程序的各个层面时，法院注意到两个程序的参数列表和宏之间的相似之处。然而，在AFC测试的过滤步骤之后，只有少数列表和宏受版权法保护，因为它们要么是公有领域的，要么是对程序的功能需求所必需的。对于少数符合版权保护的参数列表和宏，在执行AFC测试的比较步骤之后，地区法院认为它们并不值得被认定为侵犯，因为它们对整个程序的贡献相对较小。同样，两个程序组织图之间的相似之处也不足以支持侵权的发现，因为它们太简单和显而易见，不包含任何原创表达。

In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012), the Northern District of California District Court examined the question of whether the application program interfaces (APIs) asso- ciated with the Java programming language are entitled to copyright protection. While the court expressly declined to rule whether all APIs are free to use without license (872 F. Supp.2d 974 at 1002), the court held that the command structure and taxonomy of the APIs were not protectable under copyright law. Specifi- cally, the court characterized the command structure and taxonomy as both a "method of operation" (using an approach not dissimilar to the First Circuit's analysis in Lotus) and a "functional requirement for com- patibility" (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies), and thus unprotectable subject matter under 102(b).

在Oracle America v. Google案中，北加利福尼亚地区法院审查了与Java编程语言相关的应用程序接口（API）是否享有版权保护的问题。虽然法院明确拒绝裁定所有API是否可在未获许可的情况下免费使用，但法院认为API的命令结构和分类法不受版权法保护。具体而言，法院将命令结构和分类法表述为“操作方法”（采用类似于Lotus中第一巡回法院分析的方法）和“兼容性的功能要求”（使用Sega v. Accolade，977 F.2d 1510（9th Cir. 1992）和Sony Computer Ent. v. Connectix，203 F.3d 596（9th Cir. 2000）作为类比），因此是根据102(b)不受保护的主题。

Perhaps not surprisingly, there have been few other cases involving a highly detailed software derivative work analysis. Most often, cases involve clearer basis for decision, including frequent bad faith on the part of the defendant or over-aggressiveness on the part of the plaintiff.

也许不令人意外的是，很少有其他案例涉及高度详细的软件衍生作品分析。大多数情况下，案例涉及更明显的决策基础，包括被告的频繁恶意行为或原告的过度侵权行为。

4.7 How Much Do Derivative Works Matter?

4.7 派生作品有多重要？

It is certainly true that GPL intends for any work that is determined a "derivative work" under copyright law must be licensed as a whole under GPL, as will be discussed in the following chapter. However, as we finish up our discussion derivative works, we must note that preparation of a derivative work is by far not the only way to create a new work covered by GPL.

毫无疑问，GPL旨在确保任何在版权法下被认定为“衍生作品”的作品必须作为整体在GPL下进行许可，这将在下一章中讨论。然而，当我们结束对衍生作品的讨论时，必须指出制作衍生作品远不是创建GPL覆盖的新作品的唯一方式。

In fact, while derivative work preparation is perhaps the most exciting area of legal issues to consider, the more mundane ways to create a new work covered by GPL are much more common. For example, copyright statutes generally require permission from the copyright holder to grant explicit permission to modify a work in any manner. As discussed in the next chapter, the GPL does grant such permission, but requires the modified work must also be licensed under the terms of the GPL (and only GPL: see*§* 7.3 in this tutorial). Determining whether software was modified is a substantially easier analysis than the derivative work discussions and considerations in this chapter.

事实上，尽管制作衍生作品可能是考虑法律问题最令人兴奋的领域，但通过更为平凡的方式创建GPL覆盖的新作品则更为常见。例如，版权法通常要求获得版权持有人的许可，以明确许可对作品进行任何方式的修改。如下一章所讨论的，GPL确实授予了这种许可，但要求修改后的作品也必须根据GPL的条款进行许可（而且只能是GPL：参见本教程中的§7.3）。确定软件是否被修改是一项相对容易的分析，与本章关于衍生作品的讨论和考虑相比要简单得多。

The question of derivative works, when and how they are made, is undoubtedly an essential discussion in the interpretation and consideration of copyleft. That is why this chapter was included in this tutorial. However, as we return from this digression and resume discussion of the detailed text of the GPLv2, we must gain a sense of perspective: most GPL questions center around questions of modification and distribution, not preparation of derivative works. Derivative work preparation is ultimately a small subset of the types of modified versions of the software a developer might create, thus, while an excessive focus on derivative works indulges us in the more exciting areas of copyleft, we must keep a sense of perspective regarding their relative importance.

衍生作品的问题、它们何时以及如何制作，无疑是在解释和考虑版权公用原则方面的必要讨论。这就是为什么本教程包含了这一章的原因。然而，当我们从这一跑题中回到对GPLv2详细文本的讨论并继续讨论时，我们必须有一个全局的认识：大多数GPL问题都集中在修改和分发问题上，而不是制作衍生作品。制作衍生作品最终只是开发人员可能创建的软件修改版本类型的一小部分，因此，虽然过分关注衍生作品能使我们沉浸在版权公用原则更激动人心的领域中，但我们必须保持相对重要性的观念。

CHAPTER 5 MODIFIED SOURCE AND BINARY DISTRIBUTION

第5章修改源代码和二进制分发

In this chapter, we discuss the two core sections that define the rights and obligations for those who modify, improve, and/or redistribute GPL'd software. These sections, GPLv2 2--3, define the central core rights and requirements of GPLv2.

本章中，我们讨论了修改、改进和/或重新分发GPL软件的权利和义务的两个核心部分。这些部分，即GPLv2 2-3，定义了GPLv2的核心权利和要求。

5.1 GPLv2 第2条：分享和分享相同

For many, this is where the "magic" happens that defends software freedom upon redistribution. GPLv2 2 is the only place in GPLv2 that governs the modification controls of copyright law. If users distribute modified versions a GPLv2'd program, they must follow the terms of GPLv2 2 in making those changes. Thus, this sections ensures that the body of GPL'd software, as it continues and develops, remains Free as in freedom. To achieve that goal, GPLv2 2 first sets forth that the rights of redistribution of modified versions are the same as those for verbatim copying, as presented in GPLv2 1. Therefore, the details of charging money, keeping copyright notices intact, and other GPLv2 1 provisions are intact here as well. However, there are three additional requirements.

对于许多人来说，这就是“魔法”发生的地方，它在重新分发时保护了软件自由。GPLv2 2是在GPLv2中仅控制版权法修改控制的地方。如果用户分发了GPLv2'd程序的修改版本，他们必须遵循GPLv2 2的条款进行更改。因此，这些部分确保了GPL'd软件库随着其不断发展和发展，仍然保持自由。为了实现这个目标，GPLv2 2首先规定修改版本的重新分发权与逐字复制的重新分发权相同，就像GPLv2 1中所述的那样。因此，收费细节、版权声明完整性和其他GPLv2 1规定也在这里得到保留。但是，还有三个额外的要求。

5.1.1 The Simpler Parts of GPLv2 §2

5.1.1 GPLv2第2条简单部分

The first (GPLv2 2(a)) requires that modified files carry "prominent notices" explaining what changes were made and the date of such changes. This section does not prescribe some specific way of marking changes nor does it control the process of how changes are made. Primarily, GPLv2 2(a) seeks to ensure that those receiving modified versions know the history of changes to the software. For some users, it is important to know that they are using the standard version of program, because while there are many advantages to using a fork, there are a few disadvantages. Users should be informed about the historical context of the software version they use, so that they can make proper support choices. Finally, GPLv2 2(a) serves an academic purpose --- ensuring that future developers can use a diachronic approach to understand the software.

第一个（GPLv2 2（a））要求修改的文件要带有“重要通知”，解释了进行了哪些更改以及更改的日期。本节并未规定标记更改的某种特定方式，也不控制更改的过程。主要是为了确保接收修改版本的人知道软件的变更历史。对于某些用户，知道他们正在使用程序的标准版本很重要，因为虽然使用分支有很多优点，但也有一些缺点。用户应该了解他们使用的软件版本的历史背景，以便他们可以做出适当的支持选择。最后，GPLv2 2（a）具有学术目的 - 确保未来的开发人员可以使用历时的方法来理解软件。

GPLv2 2(c), a relatively simple section, requires that any program which (before modification) "normally reads commands interactively when run" and displays or prints legal information also display all copyright notices, warranty disclaimer, modification indications and a pointer to the license, even in modified versions. The requirement is relatively simple, and relates to an important policy goal of copyleft: downstream users should be informed of their rights. Its implications and details are straightforward and simple.

5.1.2 GPLv2 §2(b)

5.1.2 GPLv2 2(b)

Meanwhile, GPLv2 2(b) requires careful and extensive study. Its four short lines embody the some of the essential legal details of "share and share alike". These 46 words are considered by some to be the most worthy of careful scrutiny because they can be a source of great confusion when not properly understood. In considering GPLv2 2(b), first note the qualifier: it only applies to derivative, combined and/or modified works that "you distribute or publish". Despite years of education efforts on this matter, many still believe that modifiers of GPL'd software must publish or otherwise share their changes. On the contrary, GPLv2 2(b) does not apply if the changes are never distributed. Indeed, the freedom to make private, personal, unshared changes to software for personal use only should be protected and defended.¹¹

与此同时，GPLv2第2条(b)要求仔细而广泛的研究。它的四行简短文字包含了“共享及共享同类”的一些基本法律细节。这46个单词被一些人认为是最值得仔细审查的，因为当它们没有被正确理解时，它们可以成为极大的混淆源。在考虑GPLv2第2条(b)时，首先要注意限定语：它仅适用于您分发或发布的派生、组合和/或修改作品。尽管在这个问题上已经进行了多年的教育工作，但许多人仍然认为GPL'd软件的修改者必须发布或以其他方式分享他们的修改。相反，GPLv2第2条(b)不适用于从未分发的更改。事实上，应该保护和维护仅用于个人使用的私人、个人、未共享软件的更改的自由。¹¹

Next, we again encounter the same matter that appears in GPLv2 *§*0, in the following text:

接下来，我们再次遇到出现在GPLv2§0中的相同问题，如下所示：

"...that in whole or part contains or is derived from the Program or any part thereof."

"...包含或源自程序或其任何部分的全部或部分内容。"

Again, the GPL relies here on copyright law. If, under copyright law, the modified version "contains or is derived from" the GPL'd software, then the requirements of GPLv2 2(b) apply. The GPL invokes its control as a copyright license over the modification of the work in combination with its control over distribution of the work.

同样，GPL在这里依赖于版权法。如果根据版权法，修改版本“包含或源自”GPL的软件，则适用GPLv2第2条(b)的要求。GPL通过其对作品修改和分发的版权许可证的控制来调用其控制。

The final clause of GPLv2 2(b) describes what the licensee must do if she distributes or publishes a modified version of the work --- namely, the following:

GPLv2第2条(b)的最后一条款描述了许可证持有人在分发或发布作品的修改版本时必须执行的操作，即以下内容：

[The work must] be licensed as a whole at no charge to all third parties under the terms of this License.

作品必须作为一个整体在本许可证的条款下免费授权给所有第三方使用。

That is probably the most tightly-packed phrase in all of the GPL. Consider each subpart carefully.

这可能是GPL中最密集的短语。仔细考虑每个子部分。

The work "as a whole" is what is to be licensed. This is an important point that GPLv2 2 spends an entire paragraph explaining; thus this phrase is worthy of a lengthy discussion here. As a programmer modifies a software program, she generates new copyrighted material --- fixing expressions of ideas into the tangible medium of electronic file storage. That programmer is indeed the copyright holder of those new changes. However, those changes are part and parcel to the original work distributed to the programmer under GPL. Thus, the license of the original work affects the license of the new whole combined and/or derivative work.

"作为一个整体"的作品是需要被授权的。这是GPLv2 2节用整个段落解释的一个重要观点，因此这个短语在这里值得进行详细的讨论。当程序员修改一个软件程序时，她产生了新的版权材料——将思想的表达形式固定到电子文件存储的有形媒介中。那个程序员确实是这些新变化的版权持有人。然而，这些变化是与GPL下分发给程序员的原始作品紧密相关的。因此，原始作品的许可证影响新整个组合和/或派生作品的许可证。

It is certainly possible to take an existing independent work (called) and combine it with a GPL'd program (called ). The license of , when it is distributed as a separate and independent work, remains the prerogative of the copyright holder of . However, when is combined with , it produces a new work that is the combination of the two (called + ). The copyright of this combined work, + , is held by the original copyright holder of each of the two works.

当一个独立的作品（称为）与GPL的程序（称为）结合时，很可能出现的情况是：当作为一个单独和独立的作品分发时，其许可证仍然是版权持有人的专属权利。然而，当与一起组合时，它们产生了一个新的作品（称为），它是两个作品的组合。新作品 + 的版权由两个作品的原始版权持有人持有。

In this case, GPLv2 2 lays out the terms by which + may be distributed and copied. By default, under copyright law, the copyright holder of would not have been permitted to distribute + ; copyright law forbids it without the expressed permission of the copyright holder of . (Imagine, for a moment, if were a proprietary product --- would its copyright holders give you permission to create and distribute + without paying them a hefty sum?) The license of , the GPL, states the options for the copyright holder of who may want to create and distribute + . The GPL's pre-granted permission to create and distribute combined and/or derivative works, provided the terms of the GPL are upheld, goes far above and beyond the permissions that one would get with a typical work not covered by a copyleft license. Thus, to say that this condition is any way unreasonable is simply ludicrous.

在这种情况下，GPLv2 §2详细说明了可以分发和复制+的条款。根据版权法，默认情况下，不允许拥有者在未经许可的情况下分发+；版权法禁止这样做。（想象一下，如果是一个专有产品，其版权持有者会允许您创建和分发+而不支付他们巨额费用吗？）GPL，即版权协议，规定了可能希望创建和分发+的版权所有者的选项。在遵守GPL条款的情况下，预先授予创建和分发组合和/或派生作品的权限远远超出了未受到版权通用许可证保护的作品所能获得的许可权限。因此，认为这个条件在任何方面都是不合理的纯属荒谬。

The GPL recognizes what is outside its scope. When a programmer's work is "separate and independent" from any GPL'd program code with which it could be combined, then the obligations of copyleft do not extend to the work separately distributed. Thus, Far from attempting to extend copyleft beyond the scope of copyright, the licenses explicitly recognize.

GPL认识到超出其范围的事情。当程序员的工作与任何可以与之结合的GPL程序代码“独立且独立”时，版权义务不适用于单独分发的工作。因此，远非试图将通用许可证超出版权范围，这些许可证明确承认了超出其范围的事情。

Thus, GPL recognizes what is outside its scope. When a programmer's work is "separate and inde- pendent" from any GPL'd program code with which it could be combined, then copyleft obligations do not extend to the independent work separately distributed. Thus, far from attempting to extend copyleft beyond the scope of copyright, GPL explicitly limits the scope of copyleft to the scope of copyright.

因此，GPL认识到超出其范围的事情。当程序员的工作与任何可以与之结合的GPL程序代码“独立且独立”时，版权义务不适用于单独分发的工作。因此，远非试图将通用许可证超出版权范围，这些许可证明确限制了通用许可证的范围，以符合版权的范围。

GPL does not, however (as is sometimes suggested) distinguish "dynamic" from "static" linking of pro- gram code. It is occasionally suggested that a subroutine "dynamically" linked to GPL'd code is, by virtue of the linking alone, inherently outside the scope of copyleft on the main work. This is a misunderstanding. When two software components are joined together to make one work (whether a main and some library subroutines, two objects with their respective methods, or a program and a "plugin") the combination infringes the copyright on the components if the combination required copyright permission from the com- ponent copyright holders, as such permission was either not available or was available on terms that were not observed.

GPL并不区分程序代码的“动态”链接和“静态”链接，尽管有时会有这种说法。有时会建议将一个“动态”链接到GPL代码的子例程视为单独存在于版权保护范畴之外，仅仅由于链接本身。这是一种误解。当两个软件组件被连接在一起形成一个整体（无论是主要程序和一些库子例程、两个具有各自方法的对象还是程序和“插件”）时，如果组合需要从组件版权持有人获得版权许可，而此类许可证要么不可用，要么是在未遵守条款的情况下可用，那么该组合就会侵犯这些组件的版权。

In other words, when combining other software with GPL'd components, the only available permission is GPL. The combiner must observe and respect the GPL observed on the combination as a whole. It matters not if that combination is made with a linker before distribution of the executable, is made by the operating system in order to share libraries for execution efficiency at runtime, or results from runtime references in the language at runtime (as in Java programs).

换句话说，当将其他软件与GPL组件结合使用时，唯一可用的许可是GPL。组合者必须尊重并遵守GPL作为整体所遵守的规定。无论这种组合是在链接器在可执行文件分发之前进行的，还是由操作系统在运行时为了共享库而进行的，或者是由语言在运行时的运行时引用所导致的（如Java程序）。

The next phrase of note in GPLv2 2(b) is "licensed . . . at no charge." This phrase confuses many. The sloppy reader points out this as "a contradiction in GPL" because (in their confused view) that clause of GPLv2 2 says that re-distributors cannot charge for modified versions of GPL'd software, but GPLv2 1 says that they can. Avoid this confusion: the "at no charge" does not prohibit re-distributors from charging when performing the acts governed by copyright law,¹² but rather that they cannot charge a fee for the license itself. In other words, redistributors of (modified and unmodified) GPL'd works may charge any amount they choose for performing the modifications on contract or the act of transferring the copy to the customer, but they may not charge a separate licensing fee for the software.

GPLv2 2(b)中需要注意的下一句话是“免费授权”。这句话让很多人感到困惑。粗心的读者会指出这是“GPL中的矛盾”，因为（在他们混淆的观点中）GPLv2 2中的这一条款说，重新发布者不能为GPL软件的修改版本收费，而GPLv2 1却说他们可以。避免这种混淆： “免费”不是禁止重新发布者在执行受版权法约束的行为时收费，¹² 而是他们不能为软件本身收取单独的许可费用。换句话说，（修改和未修改的）GPL作品的重新发布者可以为执行合同上的修改或向客户传递副本的行为收取任意金额，但他们不能为软件收取单独的许可费。

GPLv2 2(b) further states that the software must "be licensed . . . to all third parties." This too yields some confusion, and feeds the misconception mentioned earlier --- that all modified versions must be made available to the public at large. However, the text here does not say that. Instead, it says that the licensing under terms of the GPL must extend to anyone who might, through the distribution chain, receive a copy of the software. Distribution to all third parties is not mandated here, but GPLv2 2(b) does require re- distributors to license the whole work in a way that extends to all third parties who may ultimately receive a copy of the software.

GPLv2 2(b)进一步规定软件必须“授权……给所有第三方使用。”这也导致了一些困惑，并滋生了前面提到的误解，即所有修改版本都必须向公众公开。然而，这里的文字并没有说到这一点。相反，它说授权必须延伸到通过分发渠道可能获得软件副本的任何人。这里并没有强制要求向所有第三方分发，但GPLv2 2(b)要求再分发者以一种方式授权整个作品，使其适用于最终可能接收到软件副本的所有第三方。

In summary, GPLv2 2(b) says what terms under which the third parties must receive this no-charge license. Namely, they receive it "under the terms of this License", the GPLv2. When an entity chooses to redistribute a work based on GPL'd software, the license of that whole work must be GPL and only GPL. In this manner, GPLv2 *§*2(b) dovetails nicely with GPLv2 *§*6 (as discussed in Section 7.3 of this tutorial).

总之，GPLv2 2(b)规定了第三方必须获得此无费许可证的条款。换句话说，他们获得的是“本许可证”的条款，即GPLv2。当一个实体选择基于GPL软件再分发作品时，整个作品的许可证必须是GPL，只能是GPL。通过这种方式，GPLv2 2(b)与GPLv2 第6条（如本教程的7.3部分所讨论的）紧密结合。

The final paragraph of GPLv2 2 is worth special mention. It is possible and quite common to aggregate various software programs together on one distribution medium. Computer manufacturers do this when they ship a pre-installed hard drive, and GNU/Linux distribution vendors do this to give a one-stop CD or URL for a complete operating system with necessary applications. The GPL very clearly permits such "mere aggregation" with programs under any license. Despite what you hear from its critics, the GPL is nothing like a virus, not only because the GPL is good for you and a virus is bad for you, but also because simple contact with a GPL'd code-base does not impact the license of other programs. A programmer must expend actual effort to cause a work to fall under the terms of the GPL. Redistributors are always welcome to simply ship GPL'd software alongside proprietary software or other unrelated Free Software, as long as the terms of GPL are adhered to for those packages that are truly GPL'd.

GPLv2第2节的最后一段值得特别提及。在一个分发介质上聚合各种软件程序是可能且很常见的。计算机制造商在出货时这样做，GNU/Linux发行商则提供一站式CD或URL以获取具有必要应用程序的完整操作系统。GPL非常明确地允许这种“纯聚合”与任何许可证下的程序一起使用。尽管你从批评者那里听到的不是这样，GPL与病毒完全不同，不仅因为GPL对你有益而病毒对你有害，而且因为与GPL的代码库的简单接触不会影响其他程序的许可证。程序员必须实际努力才能使一个作品适用于GPL的条款。再分发者总是欢迎将GPL软件与专有软件或其他无关的自由软件一起分发，只要真正使用GPL的软件包的条款遵守GPL即可。

5.1.3 Right to Private Modification

5.1.3 私有修改权

The issue of private modifications of GPLv2'd works deserves special attention. While these rights are clearly explicit in GPLv3 2 2 (see 9.4 of this tutorial for details), the permission to create private modifications is mostly implicit in GPLv2. Most notably, the requirements of GPLv2 2 (and GPLv2 3, which will be discussed next) are centered around two different copyright controls: both modification and distribution. As such, GPLv2 2's requirements need only be met when a modified version is distributed; one need not follow them for modified versions that are not distributed.¹³

对于 GPLv2 的作品进行私有修改的问题需要特别注意。虽然 GPLv3 2 2 中明确列出了这些权利（有关详情请参见本教程的 9.4 部分），但是在 GPLv2 中，创造私有修改的许可大多是暗含的。特别是，GPLv2 2（和将在下一节讨论的 GPLv2 3）的要求围绕两个不同的版权控制展开：修改和分发。因此，只有在分发修改版本时才需要遵守 GPLv2 2 的要求；对于未分发的修改版本，不需要遵守这些要求。¹³

However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other clauses of the license actually give explicit permission to make private modifications. Since modification of software is a control governed by copyright, a modifier needs permission from the copyright holder to engage in that activity.

然而，仔细阅读 GPLv2 的读者会注意到，与 GPLv3 不同，许可证的其他条款实际上没有明确允许进行私有修改的许可。由于软件修改是受版权控制的控制，因此修改者需要获得版权持有人的许可才能从事这项活动。

In practice, however, traditional GPLv2 interpretation has always assumed that blanket permission to create non-distributed modified versions was available, and the FSF has long opined that distribution of modified versions is never mandatory. This issue is one of many where GPLv3 clarifies in explicit text the implicit policy and intent that was solidified via long-standing interpretation of GPLv2.

然而，在实践中，传统的 GPLv2 解释一直假定拥有创造非分发修改版本的全面许可，而FSF 长期以来一直认为分发修改版本从来不是强制性的。这个问题是 GPLv3 明确文本阐明了长期解释 GPLv2 所确定的隐含政策和意图的众多问题之一。

5.2 GPLv2 §3: Producing Binaries

5.2 GPLv2 第3条：生成二进制文件

Software is a strange beast when compared to other copyrightable works. It is currently impossible to make a film or a book that can be truly obscured. Ultimately, the full text of a novel, even one written by William Faulkner, must be presented to the reader as words in some human-readable language so that they can enjoy the work. A film, even one directed by David Lynch, must be perceptible by human eyes and ears to have any value.

与其他可版权作品相比，软件是一种奇特的生物。目前还没有一种能真正被隐藏的电影或书籍。即使是威廉·福克纳写的小说全文也必须以某种人类可读的语言形式呈现给读者，以便他们能够享受这部作品。一部由大卫·林奇执导的电影也必须可被人类的眼睛和耳朵感知才有任何价值。

Software is not so. While the source code --- the human-readable representation of software --- is of keen interest to programmers, users and programmers alike cannot make the proper use of software in that human-readable form. Binary code --- the ones and zeros that the computer can understand --- must be predicable and attainable for the software to be fully useful. Without the binaries, be they in object or executable form, the software serves only the didactic purposes of computer science.

软件不同。尽管源代码是软件的人类可读表现形式，对程序员来说是非常重要的，但用户和程序员不能以这种人类可读的形式正确地使用软件。二进制代码，即计算机能够理解的一和零，必须是可预测且可获得的，才能充分发挥软件的作用。如果没有二进制文件，无论是目标文件还是可执行文件，该软件只能用于计算机科学的教学目的。

Under copyright law, binary representations of the software are simply modified versions (and/or deriva- tive works) of the source code. Applying a systematic process (i.e., "compilation"¹⁴) to a work of source code yields binary code. The binary code is now a new work of expression fixed in the tangible medium of electronic file storage.

根据版权法，软件的二进制表示只是源代码的修改版本（和/或派生作品）。将源代码作品应用一种系统的过程（即“编译”¹⁴）会产生二进制代码。现在，二进制代码是以电子文件存储为载体的新的表达形式。

Therefore, for GPL'd software to be useful, the GPL, since it governs the rules for creation of modified works, must grant permission for the generation of binaries. Furthermore, notwithstanding the relative popularity of source-based GNU/Linux distributions like Gentoo, users find it extremely convenient to receive distribution of binary software. Such distribution is the redistribution of modified works of the software's source code. GPLv2 3 addresses the matter of creation and distribution of binary versions.

因此，为了让GPL的软件有用，GPL必须授予生成二进制文件的许可，因为它管理修改作品的规则。此外，尽管基于源代码的GNU/Linux发行版（如Gentoo）相对受欢迎，用户发现接收二进制软件的分发非常方便。这种分发是软件源代码的修改作品的再分发。GPLv2 3解决了创建和分发二进制版本的问题。

Under GPLv2 3, binary versions may be created and distributed under the terms of GPLv2 1--2, so all the material previously discussed applies here. However, GPLv2 3 must go a bit further. Access to the software's source code is an incontestable prerequisite for the exercise of the fundamental freedoms to modify and improve the software. Making even the most trivial changes to a software program at the binary level is effectively impossible. GPLv2 3 must ensure that the binaries are never distributed without the source code, so that these freedoms are passed through the distribution chain.

根据GPLv2 3，可以在GPLv2 1-2的条款下创建和分发二进制版本，因此之前讨论的所有材料在这里都适用。但是，GPLv2 3必须更进一步。访问软件源代码是行使修改和改进软件的基本自由的必要条件。在二进制层面上进行最微小的更改实际上是不可能的。GPLv2 3必须确保二进制文件没有在未提供源代码的情况下进行分发，以便这些自由通过分发链传递。

GPLv2 3 permits distribution of binaries, and then offers three options for distribution of source code along with binaries. The most common and the least complicated is the option given under GPLv2 3(a).

GPLv2 3允许分发二进制文件，然后提供了三种选项，以便将源代码与二进制文件一起分发。最常见且最简单的选项是GPLv2 3(a)提供的选项。

GPLv2 3(a) offers the option to directly accompany the source code alongside the distribution of the binaries. This is by far the most convenient option for most distributors, because it means that the source- code provision obligations are fully completed at the time of binary distribution (more on that later).

GPLv2第3条(a)提供了在二进制文件分发的同时直接附带源代码的选择。这对于大多数分发者来说是最方便的选择，因为它意味着在二进制分发时完全完成了源代码提供义务（稍后将更详细地说明）。

5.2.1 Complete, Corresponding Source (CCS)

5.2.1 完整、对应的源代码（CCS）

Under GPLv2 3(a), the source code provided must be the "corresponding source code." Here "correspond- ing" primarily means that the source code provided must be that code used to produce the binaries being distributed. That source code must also be "complete". GPLv2 3's penultimate paragraph explains in de- tail what is meant by "complete". In essence, it is all the material that a programmer of average skill would need to actually use the source code to produce the binaries she has received. Complete source is required so that, if the licensee chooses, she should be able to exercise her freedoms to modify and redistribute changes. Without the complete source, it would not be possible to make changes that were actually directly derived from the version received.

在GPLv2 3(a)下，提供的源代码必须是“对应的源代码”。在这里，“对应的”主要意味着提供的源代码必须是用于生成所分发的二进制文件的代码。该源代码还必须是“完整的”。GPLv2 3的倒数第二段详细解释了“完整”的含义。实质上，它是程序员需要实际使用源代码来生成收到的二进制文件所需的所有材料。需要完整的源代码，以便许可证持有人选择时，可以行使修改和重新分发更改的自由。如果没有完整的源代码，就不可能制作实际上是直接源自所收到版本的更改。

Based on the appearance of those two words, GPL theorists will often refer to the source code required under the previsions of this section as "Complete, Corresponding Source", sometimes abbreviated as CCS. CCS is not a formal, defined term in GPLv2, but rather, GPL theorists coined the acronym CCS to embody not just the concepts of "complete" and "corresponding" as found in GPLv2, but the entirety of GPLv2's requirements for source code provisioning. In other words, GPL theorists might say: "the company provided some source, but it wasn't CCS", which would mean the source code failed in some ways to meet some term of GPLv2.

基于这两个词的出现，GPL理论家经常将此部分规定要求的源代码称为“完整、对应的源代码”，有时缩写为CCS。CCS不是GPLv2中的正式定义术语，而是GPL理论家创造出的缩写，它不仅代表了GPLv2中“完整”和“对应”的概念，而且代表了GPLv2对源代码提供的全部要求。换句话说，GPL理论家可能会说：“公司提供了一些源代码，但它不是CCS”，这意味着源代码在某些方面未能满足GPLv2的某些条款。

Indeed, CCS needs completely include not just that source which is directly translated by the compiler into object code, but other materials necessary to convert the source into equivalent binaries. Specifically, GPLv2 3 requires that the source code include "meta-material" like scripts, interface definitions, and other material that is used to "control compilation and installation" of the binaries. In this manner, those further down the distribution chain are assured that they have the unabated freedom to build their own modified works from the sources provided.

事实上，CCS必须完全包括不仅直接由编译器转换为目标代码的源代码，还包括将源代码转换为等效二进制文件所需的其他材料。具体而言，GPLv2 3要求源代码包括“元材料”，如脚本、接口定义和其他用于“控制编译和安装”二进制文件的材料。以这种方式，分销链中的下游用户可以确保他们可以从提供的源代码构建自己的修改作品，而没有受到任何限制。

This requirement is not merely of theoretical value. If you pay a high price for a copy of GPL'd binaries (which comes with CCS, of course), you have the freedom to redistribute that work at any fee you choose, or not at all. Sometimes, companies attempt a GPL-violating cozenage whereby they produce very specialized binaries (perhaps for an obscure architecture). They then give source code that does correspond, but withhold the "incantations" and build plans they used to make that source compile into the specialized binaries. Such distributions violate GPL, since the downstream users cannot effectively "control compilation and installation" of the binaries.

这个要求不仅仅具有理论价值。如果你花了高价购买了带有CCS的GPL二进制文件副本，你就有自由以任何你选择的费用重新分发该作品，或者根本不分发。有时，一些公司会尝试违反GPL的欺诈手段，他们会生产非常专业化的二进制文件（也许是针对某种不常见的架构），然后提供相应的源代码，但是却不提供他们用来将这个源代码编译成专业化二进制文件所需要的"咒语"和构建计划。这样的发行版违反了GPL，因为下游用户无法有效地"控制编译和安装"这些二进制文件。

5.2.2 Additional Source Provision Options

5.2.2 其他提供源代码的选项

Software distribution comes in many forms. Embedded manufacturers, for example, have the freedom to put GPL'd software into mobile devices with very tight memory and space constraints. In such cases, putting the source right alongside the binaries on the machine itself might not be an option. While it is recommended that this be the default way that people comply with GPL, the GPL does provide options when such distribution is unfeasible.

软件分发有多种形式。例如，嵌入式制造商可以自由地将GPL软件放入内存和空间非常有限的移动设备中。在这种情况下，将源代码放在机器上的二进制文件旁边可能不是一个选择。尽管建议这是人们遵守GPL的默认方式，但当这种分发不可行时，GPL确实提供了选项。

GPLv2 3, therefore, allows source code to be provided on any physical "medium customarily used for software interchange." By design, this phrase covers a broad spectrum --- the phrase seeks to pre-adapt to changes in technology. When GPLv2 was first published in June 1991, distribution on magnetic tape was still common, and CD was relatively new. By 2002, CD was the default. By 2007, DVD's were the default. Now, it's common to give software on USB drives and SD cards. This language in the license must adapt with changing technology.

因此，GPLv2 3允许在任何“用于软件交换的通常物理介质”上提供源代码。这个短语的设计旨在涵盖广泛的领域，它试图预先适应技术的变化。当GPLv2于1991年6月首次发布时，磁带分发仍然很常见，而CD则相对较新。到2002年，CD是默认选项。到2007年，DVD成为默认选项。现在，常见的做法是在USB驱动器和SD卡上提供软件。许可证中的这种语言必须随着技术的变化而适应。

Meanwhile, the binding created by the word "customarily" is key. Many incorrectly believe that dis- tributing binary on CD and source on the Internet is acceptable. In the corporate world in industrialized countries, it is indeed customary to simply download a CDs' worth of data quickly. However, even today in the USA, many computer users are not connected to the Internet, and most people connected to the Internet still have limited download speeds. Downloading CDs full of data is not customary for them in the least. In some cities in Africa, computers are becoming more common, but Internet connectivity is still available only at a few centralized locations. Thus, the "customs" here are normalized for a worldwide userbase. Simply providing source on the Internet --- while it is a kind, friendly and useful thing to do --- is not usually sufficient.

与此同时，“通常”一词所造成的约束是关键。许多人错误地认为在CD上分发二进制文件，在互联网上提供源代码是可以接受的。在工业化国家的公司世界中，只需快速下载一张CD的数据是很常见的。但是，即使是今天，在美国许多计算机用户仍未连接到互联网，大多数连接到互联网的人仍然具有有限的下载速度。对他们来说，下载充满数据的CD是一件非常不寻常的事情。在非洲的一些城市，计算机变得越来越普遍，但互联网连接仍然只在少数集中的位置可用。因此，这里的“惯例”是针对全球用户群的。仅仅在互联网上提供源代码——虽然这是一件善意和有用的事情——通常是不够的。

Note, however, a major exception to this rule, given by the last paragraph of GPLv2 3. If distribution of the binary files is made only on the Internet (i.e., "from a designated place"), then simply providing the source code right alongside the binaries in the same place is sufficient to comply with GPLv2 *§*3.

然而，GPLv2 3最后一段给出了一个主要例外。如果二进制文件的分发只是在互联网上进行（即“从指定的位置”），那么在同一位置直接提供源代码与二进制文件就足以符合GPLv2 §3的要求。

As is shown above, under GPLv2 3(a), embedded manufacturers can put the binaries on the device and ship the source code along on a CD. However, sometimes this turns out to be too costly. Including a CD with every device could prove too costly, and may practically (although not legally) prohibit using GPL'd software. For this situation and others like it, GPLv2*§* 3(b) is available.

如上所示，在GPLv2 3(a)下，嵌入式制造商可以将二进制文件放在设备上并将源代码放在CD上进行运输。然而，有时这种做法会被认为成本过高。为每个设备包含CD可能会过于昂贵，而且实际上可能（尽管法律上不允许）禁止使用GPL'd软件。对于这种情况和其他类似情况，GPLv2 § 3(b)是可用的。

GPLv2 3(b) allows a distributor of binaries to instead provide a written offer for source code alongside those binaries. This is useful in two specific ways. First, it may turn out that most users do not request the source, and thus the cost of producing the CDs is saved --- a financial and environmental windfall. In addition, along with a GPLv2 3(b) compliant offer for source, a binary distributor might choose to also give a URL for source code. Many who would otherwise need a CD with source might turn out to have those coveted high bandwidth connections, and are able to download the source instead --- again yielding environmental and financial windfalls.

GPLv2 3(b)允许二进制分发者提供书面源代码提供，而不是与这些二进制文件一起提供源代码。这有两个具体的用途。首先，可能大多数用户不请求源代码，因此节省了制作CD的成本 - 这是一笔财务和环境的收益。此外，与GPLv2 3(b)兼容的源代码提供书面提供，二进制分发者可能会选择为源代码也提供URL。许多其他需要源CD的人可能会发现拥有所需的高带宽连接，能够下载源代码，从而再次产生环境和财务收益。

However, note that regardless of how many users prefer to get the source online, GPLv2 3(b) does place lasting long-term obligations on the binary distributor. The binary distributor must be prepared to honor that offer for source for three years and ship it out (just as they would have had to do under GPLv2 3(a)) at a moment's notice when they receive such a request. There is real organizational cost here: support engineers must be trained how to route source requests, and source CD images for every release version for the last three years must be kept on hand to burn such CDs quickly. The requests might not even come from actual customers; the offer for source must be valid for "any third party".

但是，请注意，无论有多少用户喜欢在线获取源代码，GPLv2 3(b)都会对二进制分发者产生长期的持续义务。二进制分发者必须准备好在三年内执行源代码提供书面提供的义务，并在收到此类请求时立即运输（就像在GPLv2 3(a)下所必须做的那样）。这里确实存在实际的组织成本：支持工程师必须接受培训以了解如何路由源请求，并且必须保留过去三年每个发布版本的源CD映像以便快速刻录这些CD。这些请求甚至可能不是来自实际的客户；源代码提供书面提供必须对“任何第三方”有效。

That phrase is another place where some get confused --- thinking again that full public distribution of source is required. The offer for source must be valid for "any third party" because of the freedoms of redistribution granted by GPLv2 1--2. A company may ship a binary image and an offer for source to only one customer. However, under GPL, that customer has the right to redistribute that software to the world if she likes. When she does, that customer has an obligation to make sure that those who receive the software from her can exercise their freedoms under GPL --- including the freedom to modify, rebuild, and redistribute the source code.

这句话是另一个容易让人困惑的地方 —— 再次认为必须完全公开发布源代码。由于 GPLv2 1-2 授予的再分发自由，源代码的提供必须对“任何第三方”有效。一家公司可以向一个客户提供一个二进制映像和一个源代码的提供，但在 GPL 下，该客户有权将该软件重新分发给全世界，如果她愿意的话。当她这样做时，该客户有义务确保那些从她那里接收软件的人可以行使 GPL 下的自由权利，包括修改、重建和重新分发源代码。

GPLv2 3(c) is created to save her some trouble, because by itself GPLv2 3(b) would unfairly favor large companies. GPLv2 3(b) allows the separation of the binary software from the key tool that people can use to exercise their freedom. The GPL permits this separation because it is good for re-distributors, and those users who turn out not to need the source. However, to ensure equal rights for all software users, anyone along the distribution chain must have the right to get the source and exercise those freedoms that require it.

GPLv2 3(c) 的创建是为了节省她的一些麻烦，因为单独 GPLv2 3(b) 将不公平地偏向大公司。GPLv2 3(b) 允许将二进制软件与人们用于行使其自由的关键工具分离。GPL 允许这种分离，因为这对重新分发者和那些不需要源代码的用户是有益的。然而，为了确保所有软件用户的平等权利，沿着分发链的任何人都必须有权获取源代码并行使需要源代码的自由。

Meanwhile, GPLv2 3(b)'s compromise primarily benefits companies that distribute binary software commercially. Without GPLv2 3(c), that benefit would be at the detriment of the companies' customers; the burden of source code provision would be unfairly shifted to the companies' customers. A customer, who had received binaries with a GPLv2 3(b)-compliant offer, would be required under GPLv2 (sans GPLv2 3(c)) to acquire the source, merely to give a copy of the software to a friend who needed it. GPLv2 3(c) reshifts this burden to entity who benefits from GPLv2 3(b).

与此同时，GPLv2 3(b) 的妥协主要使得商业分发二进制软件的公司受益。如果没有 GPLv2 3(c)，这种利益将损害公司的客户；源代码提供的负担将不公平地转移到公司的客户身上。一个已收到 GPLv2 3(b)-兼容提供的二进制文件的客户，将根据 GPLv2 (不带 GPLv2 3(c)) 要求获取源代码，仅仅是为了将软件副本提供给需要的朋友。GPLv2 3(c) 将这个负担重新转移到从 GPLv2 3(b) 受益的实体身上。

GPLv2 3(c) allows those who undertake noncommercial distribution to simply pass along a GPLv2 3(b)- compliant source code offer. The customer who wishes to give a copy to her friend can now do so without provisioning the source, as long as she gives that offer to her friend. By contrast, if she wanted to go into business for herself selling CDs of that software, she would have to acquire the source and either comply via GPLv2 3(a), or write her own GPLv2 3(b)-compliant source offer.

GPLv2 3(c) 允许那些进行“非商业”分发的人简单地传递一个 GPLv2 3(b) —— 兼容的源代码提供。希望将副本交给她朋友的客户现在可以这样做，而无需提供源代码，只要她把这个提供转交给她的朋友即可。相比之下，如果她想自己开业，销售该软件的 CD，她将不得不获取源代码，并通过 GPLv2 3(a) 或编写自己的 GPLv2 3(b) —— 兼容的源代码提供来遵守 GPL。

This process is precisely the reason why a GPLv2 3(b) source offer must be valid for all third parties. At the time the offer is made, there is no way of knowing who might end up noncommercially receiving a copy of the software. Companies who choose to comply via GPLv2 3(b) must thus be prepared to honor all incoming source code requests. For this and the many other additional necessary complications under GPLv2 *§§*3(b--c), it is only rarely a better option than complying via GPLv2 *§*3(a).

这个过程正是 GPLv2 3(b) 源代码提供必须对所有第三方有效的原因。在提供源代码的时候，没有办法知道谁会非商业地获得软件的副本。因此，选择通过 GPLv2 3(b) 来遵守许可证的公司必须准备好满足所有源代码请求。因为在 GPLv2 §3(b-c) 下有许多其他必要的复杂程序，所以这种方式通常不如遵守 GPLv2 §3(a)。

CHAPTER 6 GPL'S IMPLIED PATENT GRANT

第6章 GPL的暗示专利授权

We digress again briefly from our section-by-section consideration of GPLv2 to consider the interaction between the terms of GPL and patent law. The GPLv2, despite being silent with respect to patents, actually confers on its licensees more rights to a licensor's patents than those licenses that purport to address the issue. This is the case because patent law, under the doctrine of implied license, gives to each distributee of a patented article a license from the distributor to practice any patent claims owned or held by the distributor that cover the distributed article. The implied license also extends to any patent claims owned or held by the distributor that cover "reasonably contemplated uses" of the patented article. To quote the Federal Circuit Court of Appeals, the highest court for patent cases other than the Supreme Court:

我们再次暂时跳出对GPLv2的逐段审查，来考虑GPL条款和专利法之间的互动关系。尽管GPLv2在专利方面保持沉默，但它实际上向其许可证持有人授予了比那些声称处理此问题的许可证更多的许可证权利。这是因为根据暗示许可证原则，专利法规定，专利的分发者向每个分销专利物品的受让人授予许可证，该许可证覆盖分销的物品。暗示许可证也扩展到分销者拥有或持有的任何专利要求，该要求涵盖专利物品的“合理预期使用”。引用联邦巡回上诉法院（非最高法院）的话：

Generally, when a seller sells a product without restriction, it in effect promises the purchaser that in exchange for the price paid, it will not interfere with the purchaser's full enjoyment of the product purchased. The buyer has an implied license under any patents of the seller that dominate the product or any uses of the product to which the parties might reasonably contemplate the product will be put.

通常情况下，当卖家无限制地销售产品时，它实际上向购买者承诺，在支付的价格的交换条件下，不会干扰购买者对所购买产品的完全享用。买方在销售者拥有专利的任何专利下拥有隐含许可证，该专利主导产品或产品可能合理预期的任何用途。

Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d 1445, 1451 (Fed. Cir. 1997).

Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp.， Inc.，123 F.3d 1445, 1451（Fed. Cir. 1997）。

Of course, Free Software is licensed, not sold, and there are indeed restrictions placed on the licensee, but those differences are not likely to prevent the application of the implied license doctrine to Free Software, because software licensed under the GPL grants the licensee the right to make, use, and sell the software, each of which are exclusive rights of a patent holder. Therefore, although the GPLv2 does not expressly grant the licensee the right to do those things under any patents the licensor may have that cover the software or its reasonably contemplated uses, by licensing the software under the GPLv2, the distributor impliedly licenses those patents to the GPLv2 licensee with respect to the GPLv2'd software.

当然，自由软件是许可，而不是销售，并且的确对许可证持有人施加了限制，但是这些差异不太可能阻止暗示许可证原则适用于自由软件，因为根据GPLv2许可的软件授予许可证持有人行使专利所有者的专属权利，即制作、使用和销售该软件。因此，尽管GPLv2没有明确授予许可证持有人使用其可能涵盖软件或其合理预期使用的任何专利的权利，但通过在GPLv2下许可软件，分销商对于GPLv2许可证持有人在GPLv2下许可有关GPLv2软件的这些专利授予了暗示许可证。

An interesting issue regarding this implied patent license of GPLv2'd software is what would be considered "uses of the [software] to which the parties might reasonably contemplate the product will be put." A clever advocate may argue that the implied license granted by GPLv2 is larger in scope than the express license in other Free Software licenses with express patent grants, in that the patent license clause of many of those other Free Software licenses are specifically limited to the patent claims covered by the code as licensed by the patentee.

关于 GPLv2 软件的这个暗示专利许可的一个有趣问题是，“当事方可能合理地预期产品将被用于的软件用途”。一个聪明的辩护人可能会主张，GPLv2 授予的暗示许可比其他明示专利授权的自由软件许可证的范围更广，因为许多其他自由软件许可证的专利许可条款特别限制了专利权人许可的代码所涵盖的专利权主张。

In contrast, a GPLv2 licensee, under the doctrine of implied patent license, is free to practice any patent claims held by the licensor that cover "reasonably contemplated uses" of the GPL'd code, which may very well include creation and distribution of modified works since the GPL's terms, under which the patented code is distributed, expressly permits such activity.

相比之下，GPLv2 授权人根据暗示专利许可原则可以自由实践授权人拥有的涵盖“合理预期用途”的专利权主张，这很可能包括创建和分发修改后的作品，因为 GPL 的条款明确允许这种活动，而该专利权主张覆盖了GPL的代码所涵盖的内容。

Further supporting this result is the Federal Circuit's pronouncement that the recipient of a patented article has, not only an implied license to make, use, and sell the article, but also an implied patent license to repair the article to enable it to function properly, Bottom Line Mgmt., Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the Federal Circuit extended that rule to include any future recipients of the patented article, not just the direct recipient from the distributor. This theory comports well with the idea of Free Software, whereby software is distributed among many entities within the community for the purpose of constant evolution and improvement. In this way, the law of implied patent license used by the GPLv2 ensures that the community mutually benefits from the licensing of patents to any single community member.

联邦巡回法院在 Bottom Line Mgmt.，Inc. v. Pan Man，Inc.，228 F.3d 1352（Fed. Cir. 2000）中进一步支持了这一结果，该法院宣称，专利物品的接收者不仅具有制造、使用和销售该物品的暗示许可，而且还具有修理该物品以使其正常运行的暗示专利许可，而这也适用于专利物品的任何未来接收者，而不仅仅是从分销商直接接收的接收者。这个理论与自由软件的思想相符，即将软件分发给社区中的许多实体，以实现不断的演进和改进。通过GPLv2使用的暗示专利许可法，确保社区从专利许可中共同受益。

Note that simply because GPLv2'd software has an implied patent license does not mean that any patents held by a distributor of GPLv2'd code become worthless. To the contrary, the patents are still valid and enforceable against either:

需要注意的是，仅因为 GPLv2 的软件具有暗示专利许可，并不意味着任何分发 GPLv2 软件的公司持有的专利就变得毫无价值。相反，这些专利仍然有效，并且可以针对以下任一方强制执行：

a. any software other than that licensed under the GPLv2 by the patent holder, and

b. any party that does not comply with the GPLv2 with respect to the licensed software.

a. 除了由专利持有人授权的GPLv2软件之外的任何软件；

b. 与许可软件有关的任何方不遵守GPLv2许可证。

For example, if Company has a patent on advanced Web browsing, but also licenses a Web browsing program under the GPLv2, then it cannot assert the patent against any party based on that party's use of Company 's GPL'd Web browsing software program, or on that party's creation and use of modified versions of that GPL'd program. However, if a party uses that program without complying with the GPLv2, then Company can assert both copyright infringement claims against the non-GPLv2-compliant party and infringement of the patent, because the implied patent license only extends to use of the software in accordance with the GPLv2. Further, if Company distributes a competitive advanced Web browsing program that is not a modified version of Company 's GPL'd Web browsing software program, Company is free to assert its patent against any user or distributor of that product. It is irrelevant whether Company 's program is also distributed under the GPLv2, as Company can not grant implied licenses to Company 's patent.

例如，如果一家公司拥有先进的Web浏览专利，但也根据GPLv2许可证授权了一个Web浏览程序，那么它就不能基于该方使用公司的GPLv2 Web浏览软件程序或者使用该程序的修改版本来主张专利权。然而，如果一方未遵守GPLv2使用了该程序，那么公司可以主张针对该非GPLv2兼容方的版权侵权索赔和专利侵权，因为暗示的专利许可仅限于按照GPLv2使用软件。此外，如果公司发布一款不是公司的GPLv2 Web浏览软件程序的改进版竞争性先进Web浏览程序，那么公司可以自由地针对该产品的任何用户或分销商主张其专利权。无论公司的程序是否也在GPLv2下发布，都是无关紧要的，因为公司不能授予对公司的专利的暗示许可证。

This result also reassures companies that they need not fear losing their proprietary value in patents to competitors through the GPLv2 implied patent license, as only those competitors who adopt and comply with the GPLv2's terms can benefit from the implied patent license. To continue the example above, Company does not receive a free ride on Company 's patent, as Company has not licensed-in and then redistributed Company A's advanced Web browser under the GPLv2. If Company does do that, however, Company still has not lost competitive advantage against Company , as Company must then, when it re-distributes Company 's program, grant an implied license to any of its patents that cover the program. Further, if Company relicenses an improved version of Company A's program, it must do so under the GPLv2, meaning that any patents it holds that cover the improved version are impliedly licensed to any licensee. As such, the only way Company can benefit from Company 's implied patent license, is if it, itself, distributes Company 's software program and grants an implied patent license to any of its patents that cover that program.

这个结果还让公司放心，它们不必担心通过GPLv2暗示专利许可证将专利的专有价值损失给竞争对手，因为只有那些采用并遵守GPLv2条款的竞争对手才能从暗示的专利许可证中受益。继续以上述例子，公司不会因为未将公司A的先进Web浏览器授权并再分发GPLv2而获得免费乘车。然而，如果公司这样做了，公司仍然没有失去对公司的竞争优势，因为当它重新分发公司的程序时，必须授予任何涵盖该程序的专利的暗示许可证。此外，如果公司重新授权改进版的公司A程序，那么它必须按照GPLv2这样做，这意味着它持有的覆盖改进版的任何专利都会被暗示地许可给任何许可证持有者。因此，公司获得公司的暗示专利许可证的唯一途径是，如果它本身分发公司的软件程序并向任何涵盖该程序的专利授予暗示专利许可证。

CHAPTER 7 DEFENDING FREEDOM ON MANY FRONTS

第7章在多个方面捍卫自由

Chapters [3] and [5] presented the core freedom-defending provisions of GPLv2, which are in GPLv2 0--3. GPLv2 4--7 of the GPLv2 are designed to ensure that GPLv2 0--3 are not infringed, are enforceable, are kept to the confines of copyright law but also not trumped by other copyright agreements or components of other entirely separate legal systems. In short, while GPLv2 *§§*0--3 are the parts of the license that defend the freedoms of users and programmers, GPLv2 *§§*4--7 are the parts of the license that keep the playing field clear so that §§ 0--3 can do their jobs.

第3章和第5章介绍了 GPLv2 的核心捍卫自由条款，即 GPLv2 第0-3条。GPLv2 的第4-7条旨在确保 GPLv2 第0-3条不被侵犯、可执行，并受到版权法的限制，但也不会被其他版权协议或完全独立的法律体系的组成部分所取代。简而言之，虽然 GPLv2 第0-3条是捍卫用户和程序员自由的许可证部分，但 GPLv2 第4-7条是保持竞争环境清晰的许可证部分，以便第0-3条可以发挥其作用。

7.1 GPLv2 §4: Termination on Violation

7.1 GPLv2 第4条：违规终止

GPLv2 4 is GPLv2's termination clause. Upon first examination, it seems strange that a license with the goal of defending users' and programmers' freedoms for perpetuity in an irrevocable way would have such a clause. However, upon further examination, the difference between irrevocability and this termination clause becomes clear. (See 7.4 for expanded discussion of GPLv2 irrevocability.)

GPLv2 4 是 GPLv2 的终止条款。初看起来，一个旨在永久且不可撤销地捍卫用户和程序员自由的许可证竟然有这样的条款，似乎有些奇怪。然而，进一步的研究表明，不可撤销和此终止条款之间的区别变得清晰了。（有关 GPLv2 不可撤销的更广泛讨论，请参见7.4。）

The GPL is irrevocable in the sense that once a copyright holder grants rights for someone to copy, modify and redistribute the software under terms of the GPL, they cannot later revoke that grant. Since the GPL has no provision allowing the copyright holder to take such a prerogative, the license is granted as long as the copyright remains in effect.¹⁵ The copyright holders have the right to relicense the same work under different licenses (see Section [12.2] of this tutorial), or to stop distributing the GPLv2'd version (assuming GPLv2 3(b) was never used), but they may not revoke the rights under GPLv2 already granted.

GPL是不可撤销的，因为一旦版权持有人授予他人在GPL条款下复制、修改和重新分发软件的权利，他们就不能撤回该授权。由于GPL没有允许版权持有人采取这种特权的规定，因此只要版权仍然有效，许可证就会被授予。¹⁵ 版权持有人有权在不同的许可证下重新许可同一作品（请参见本教程的第12.2节），或停止分发GPLv2版本（假设从未使用GPLv2 3(b)），但他们不能撤销已授予的GPLv2下的权利。

In fact, when an entity loses their right to copy, modify and distribute GPL'd software, it is because of their own actions, not that of the copyright holder. The copyright holder does not decide when GPLv2 4 termination occurs (if ever); rather, the actions of the licensee determine that.

实际上，当一个实体失去复制、修改和分发GPL软件的权利时，是因为他们自己的行为，而不是版权持有人的行为。版权持有人不决定GPLv2 4终止的时间（如果有的话），而是许可证持有人的行为决定。

Under copyright law, the GPL has granted various rights and freedoms to the licensee to perform specific types of copying, modification, and redistribution. By default, all other types of copying, modification, and redistribution are prohibited. GPLv2 4 says that if you undertake any of those other types (e.g., redistributing binary-only in violation of GPLv2 3), then all rights under the license --- even those otherwise permitted for those who have not violated --- terminate automatically.

根据版权法，GPL已经授予许可证持有人执行特定类型的复制、修改和重新分发的各种权利和自由。默认情况下，所有其他类型的复制、修改和重新分发都是禁止的。GPLv2 4规定，如果您进行任何这些其他类型的活动（例如，在违反GPLv2 3的情况下重新分发仅限二进制文件），那么所有许可证下的权利，即使是对于没有违反许可证的人，也会自动终止。

GPLv2 4 makes GPLv2 enforceable. If licensees fail to adhere to the license, then they are stuck without any permission under to engage in activities covered by copyright law. They must completely cease and desist from all copying, modification and distribution of the GPL'd software.

GPLv2 4使GPLv2可强制执行。如果许可证持有人未能遵守许可证，那么他们就没有任何在版权法下从事活动的许可。他们必须完全停止所有对GPL软件的复制、修改和分发。

At that point, violating licensees must gain the forgiveness of the copyright holders to have their rights restored. Alternatively, the violators could negotiate another agreement, separate from GPL, with the copyright holder. Both are common practice, although Chapter [13.3] explains further key differences between these two very different uses of GPL.

在那时，违反许可证的人必须得到版权持有人的谅解，才能恢复他们的权利。或者，违规者可以与版权持有人另行协商一份与GPL无关的协议。尽管这两种做法都很常见，但第13.3章进一步解释了这两种非常不同的GPL用途之间的关键差异。

7.2 GPLv2 §5: Acceptance, Copyright Style

7.2 GPLv2 第5条：接受、版权风格

GPLv2 5 brings us to perhaps the most fundamental misconception and common confusion about GPLv2. Because of the prevalence of proprietary software, most users, programmers, and lawyers alike tend to be more familiar with EULAs. EULAs are believed by their authors to be contracts, requiring formal agreement between the licensee and the software distributor to be valid. This has led to mechanisms like "shrink-wrap" and "click-wrap" as mechanisms to perform acceptance ceremonies with EULAs.

GPLv2 5 可能是关于 GPLv2 最基本的误解和常见混淆。由于专有软件的普及，大多数用户、程序员和律师都更熟悉使用许可协议（EULA）。 EULA 的作者认为它们是合同，需要许可人和软件分发商之间的正式协议才能有效。这导致了"缩小包装"和"点击包装"等机制来执行 EULA 的接受仪式。

The GPL does not need contract law to "transfer rights." Usually, no rights are transferred between parties. By contrast, the GPL is primarily a permission slip to undertake activities that would otherwise have been prohibited by copyright law. As such, GPL needs no acceptance ceremony; the licensee is not even required to accept the license.

However, without the GPL, the activities of copying, modifying and distributing the software would have otherwise been prohibited. So, the GPL says that you only accepted the license by undertaking activities that you would have otherwise been prohibited without your license under GPL. This is a certainly subtle point, and requires a mindset quite different from the contractual approach taken by EULA authors.

然而，如果没有 GPL，复制、修改和分发软件的活动本来是被禁止的。因此，GPL 表示，只有在进行原本在没有 GPL 许可下被禁止的活动时，你才接受了许可证。这是一个非常微妙的点，需要一种与 EULA 作者采取的合同方法截然不同的思维方式。

An interesting side benefit to GPLv2 5 is that the bulk of users of Free Software are not required to accept the license. Undertaking fair and unregulated use of the work, for example, does not bind you to the GPL, since you are not engaging in activity that is otherwise controlled by copyright law. Only when you engage in those activities that might have an impact on the freedom of others does license acceptance occur, and the terms begin to bind you to fair and equitable sharing of the software. In other words, the GPL only kicks in when it needs to for the sake of freedom.

GPLv2 5 的一个有趣的附带好处是，大部分自由软件的用户不需要接受许可证。例如，进行公正和不受限制的作品使用不会约束您使用 GPL，因为您并没有从事受版权法控制的活动。只有当您从事可能会影响他人自由的活动时，许可证才会生效，并开始将您与软件的公平和公正共享的条款绑定在一起。换句话说，GPL 只会在需要自由的情况下启动。

While GPL is by default a copyright license, it is certainly still possible to consider GPL as a contract as well. For example, some distributors chose to "wrap" their software in an acceptance ceremony to the GPL, and nothing in the GPL prohibits that use. Furthermore, the ruling in Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008) indicates that both copyright and contractual remedies may be sought by a copyright holder seeking to enforce a license designed to uphold software freedom.

虽然 GPL 默认是一个版权许可证，但当然仍然可以将 GPL 视为合同。例如，一些发行商选择在 GPL 接受仪式中"包装"他们的软件，而 GPL 中没有禁止这种用法。此外，在 Jacobsen v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008) 的裁决中表明，寻求执行旨在维护软件自由的许可证的版权持有人可以同时寻求版权和合同救济措施。

7.3 GPLv2 §6: GPL, My One and Only

7.3 GPLv2 第6条: GPL，唯一的版权许可证

A point that was glossed over in Section 7.1's discussion of GPLv2 4 was the irrevocable nature of the GPL. The GPLv2 is indeed irrevocable, and it is made so formally by GPLv2 6.

在第7.1节讨论GPLv2 4时忽略了一个重要的问题，那就是GPLv2的不可撤销性。GPLv2确实是不可撤销的，GPLv2 6正式规定了这一点。

The first sentence in GPLv2 6 ensures that as software propagates down the distribution chain, that each licensor can pass along the license to each new licensee. Under GPLv2 6, the act of distributing automatically grants a license from the original licensor to the next recipient. This creates a chain of grants that ensure that everyone in the distribution has rights under the GPLv2. In a mathematical sense, this bounds the bottom --- making sure that future licensees get no fewer rights than the licensee before.

GPLv2 6的第一句确保了在软件沿着分发链传播时，每个许可人都可以将许可证传递给每个新的许可人。根据GPLv2 6，分发的行为自动授予原始许可人到下一个收件人的许可证。这创造了一系列的许可授权，确保分发中的每个人都在GPLv2下享有权利。从数学上讲，这将底部限制在一定范围内，确保未来的许可人得到的权利不少于前一个许可人。

The second sentence of GPLv2 6 does the opposite; it bounds from the top. It prohibits any licensor along the distribution chain from placing additional restrictions on the user. In other words, no additional requirements may trump the rights and freedoms given by GPLv2.

GPLv2 6的第二句则相反，它从顶部限制。它禁止沿着分发链的任何许可人对用户施加额外的限制。换句话说，没有额外的要求可以凌驾于GPLv2所赋予的权利和自由之上。

The final sentence of GPLv2 6 makes it abundantly clear that no individual entity in the distribution chain is responsible for the compliance of any other. This is particularly important for noncommercial users who have passed along a source offer under GPLv2 3(c), as they cannot be assured that the issuer of the offer will honor their GPLv2 3 obligations.

GPLv2 6的最后一句明确表示，在分发链中，没有任何个人实体对其他人的合规性负责。这对于已根据GPLv2 3(c)传递源代码的非商业用户尤其重要，因为他们无法确保发出源代码的人会履行他们GPLv2 3的义务。

In short, GPLv2 6 says that your license for the software is your one and only copyright license allowing you to copy, modify and distribute the software.

简而言之，GPLv2 6表示，该软件的许可证是您唯一的版权许可证，允许您复制、修改和分发该软件。

GPLv2 §6 is GPLv2's "automatic down stream licensing" provision¹⁶. Each time you redistribute a GPL'd program, the recipient automatically receives a license from each original licensor to copy, distribute or mod- ify the program subject to the conditions of the license. The redistributor need not take any to ensure the downstream recipient's acceptance of the license terms. This places every copyright holder in the chain of descent of the code in legal privity, or direct relationship, with every downstream redistributor. Two legal effects follow. First, downstream parties who remain in compliance have valid permissions for all actions (including modification and redistribution) even if their immediate upstream supplier of the software has been terminated for license violation¹⁷. Downstream's licensed rights are not dependent on compliance of their upstream, because their licenses issue directly from the copyright holder. Second, automatic termi- nation cannot be cured by obtaining additional copies from an alternate supplier: the license permissions emanate only from the original licensors, and if they have automatically terminated permission, no act by any intermediate license holder can restore those terminated rights¹⁸.

GPLv2 §6是GPLv2的“自动下游许可证”条款¹⁶。每次您重新分发GPL授权的程序，接收方都会自动从每个原始许可证人那里获得许可证，以复制、分发或修改程序，但须遵守许可证的条件。再分发者无需采取任何措施来确保下游接收方接受许可证条款。这将每个代码下降链中的版权持有人置于法律特权或直接关系中，与每个下游再分发者有关。随之而来的是两个法律效果。首先，保持合规的下游方对于所有行为（包括修改和再分发），即使他们的软件直接上游供应商已因许可证违规而被终止，也具有有效的权限¹⁷。下游方的许可权不依赖于上游的合规性，因为他们的许可证直接来自版权持有人。其次，自动终止无法通过从备用供应商获取其他副本来解决：许可证权限仅来自原始许可证人，如果他们已自动终止许可证，则任何中间许可证持有人的行为都无法恢复已终止的权利¹⁸。

7.4 GPLv2 Irrevocability

7.4 GPLv2的不可撤销性

This section digresses briefly to examine the manner in which GPLv2 4--6 interact together to assure that the license grant is irrevocable. There are two legal theories why a contributor cannot terminate their license grant. First is an argument that the text of the GPL prevents it; second is that a contributor would be estopped from succeeding on an infringement claim for continued use of the code even if it wasn't removed.

这个章节简要地讨论了GPLv2 4-6是如何相互作用以确保许可证授权是不可撤销的。有两种法律理论可以解释为什么贡献者不能终止他们的许可证授权。第一个是GPL的文本阻止了它的发生，第二个是即使代码没有被删除，贡献者也无法成功地主张侵权。

7.4.1 The text of the GPLv2

7.4.1 GPLv2的文本

The GPLv2 have several provisions that, when taken together, can be construed as an irrevocable license from each contributor. First, the GPLv2 says "by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it" (GPLv2 5, emphasis added). A contributor by definition is modifying the code and therefore has agreed to all the terms in the GPLv2, which includes the web of mechanisms in the GPLv2 that ensure the code can be used by all.

GPLv2有几个规定，当它们放在一起时，可以被解释为每个贡献者提供了一个不可撤销的许可证。首先，GPLv2说，“通过修改或分发程序（或任何基于程序的工作），您表明接受本许可证以进行此类操作，以及为复制，分发或修改程序或基于它的工作的所有条款和条件”（GPLv2 5，重点强调）。按照定义，贡献者正在修改代码，因此同意了GPLv2中的所有条款，包括GPLv2中保证代码可以被所有人使用的机制。

More specifically, the downstream license grant says "the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions." (GPLv2 6). So in this step, the contributor has granted a license to the downstream, on the condition that the downstream complies with the license terms.

更具体地说，下游许可证授权说，“接收者自动从原始许可人那里获得许可证，以便根据这些条款和条件复制，分发或修改程序。”（GPLv2 6）。因此，在这一步中，贡献者已经授予了下游许可证，条件是下游用户遵守许可证条款。

That license granted to downstream is irrevocable, again provided that the downstream user complies with the license terms: "[P]arties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance" (GPLv2 4).

只要下游用户遵守许可证条款，向下游授予的许可证是不可撤销的：“只要这样的各方保持完全符合要求，从您处接收副本或权利的各方不会使其许可证终止”（GPLv2 4）。

Thus, anyone downstream of the contributor (which is anyone using the contributor's code), has an irrevocable license from the contributor. A contributor may claim to revoke their grant, and subsequently sue for copyright infringement, but a court would likely find the revocation was ineffective and the downstream user had a valid license defense to a claim of infringement.

因此，贡献者的任何下游方（也就是使用贡献者代码的任何人）都有一个不可撤销的许可证。贡献者可能声称撤回他们的授权，并随后对版权侵权提起诉讼，但法院很可能会发现撤销是无效的，下游用户有一个有效的许可证辩护权来反驳侵权指控。

Nevertheless, for purposes of argument, we will assume that for some reason the GPLv2 is not enforceable against the contributor¹⁹, or that the irrevocable license can be revoked²⁰. In that case, the application of promissory estoppel will likely mean that the contributor still cannot enforce their copyright against downstream users.

尽管如此，为了论证的目的，我们将假设某种原因导致 GPLv2 对贡献者不可执行¹⁹，或者可撤销的不可撤销许可证²⁰。在这种情况下，承诺诱导可能意味着贡献者仍然无法对下游用户执行其版权。

7.4.2 Promissory estoppel

7.4.2 承诺阻止

"Promissory estoppel" is a legal theory that says, under some circumstances, a promise is enforceable against the promisee even after the promisee tries to renege on the promise. The test for how and when promissory estoppel applies differs from state to state, but generally where there is a "promise which the promisor should reasonably expect to induce action or forbearance on the part of the promisee or a third person and which does induce such action or forbearance is binding if injustice can be avoided only by enforcement of the promise."²¹ Breaking it down, it is:

“承诺阻止”是一种法律理论，根据某些情况，即使承诺人试图食言，承诺也可以对承诺人生效。如何和何时应用承诺阻止的测试因州而异，但通常情况下，如果有“承诺能够合理预期促使承诺人或第三方采取行动或放弃采取行动的承诺，并且该承诺确实促使了这种行动或放弃采取行动，如果只有通过执行该承诺才能避免不公正，那么该承诺是具有约束力的。”²¹ 将其分解为以下几点：

where there is a clear and definite promise;
where the promisor has a reasonable expectation that the offer will induce action or forbearance on the part of the promisee;
which does induce actual and reasonable action or forbearance by the promisee; and
which causes a detriment which can only be avoided by the enforcement of the promise.
存在明确和明确的承诺；
承诺人有合理的期望，即提供将促使承诺人采取行动或放弃采取行动；
确实促使承诺人采取了实际和合理的行动或放弃采取行动；以及
引起只有通过执行承诺才能避免的不利影响。

In this case, the promisor is the contributor. This should be an easy standard to meet in any widely used software.

在这种情况下，承诺人是贡献者。在任何广泛使用的软件中，这应该是一个容易实现的标准。

The promise is contained in the GPL, which is a promise that one can continue to use the licensed software as long as the terms of the license are met.
A contributor knows that there is a broad user base and users consume the software relying on the grant in the GPL as assuring their continued ability to use the software (one might even say it is the sine qua non of the intent of the GPL).
Users do, in fact, rely on the promises in the GPL, as they ingest the software and base their businesses on their continued ability to use the software.
Whether the user will suffer detriment is case-specific, but using Linux, a software program that is often fundamental to the operation of a business, as an example, the loss of its use would have a significantly detrimental, perhaps even fatal, effect on the continued operation of the business.
承诺包含在GPL中，它承诺只要符合许可证条款，就可以继续使用许可的软件。
贡献者知道有广泛的用户群，用户使用许可证中的授权来保证他们继续使用软件（可以说这是GPL意图的不可或缺的组成部分）。
用户确实依赖GPL中的承诺，因为他们使用该软件，并基于其继续使用该软件来进行业务。
用户是否会遭受损失是具体情况而定，但以Linux为例，这是一种通常对企业运作至关重要的软件程序，其使用的丧失将对企业的持续运营产生显着的，甚至是致命的影响。

7.4.3 Conclusion

7.4.3 结论

Whether as a matter of a straightforward contractual obligation, or as a matter of promissory estoppel, a contributor's attempt to revoke a copyright license grant and then enforce their copyright against a user is highly unlikely to succeed.

无论作为明确的合同义务，还是作为承诺阻止的事项，贡献者试图撤销版权许可授权，然后对用户执行其版权的行为极不可能成功。

7.5 GPLv2 §7: "Give Software Liberty or Give It Death!"

7.5 GPLv2 第7条：“给软件自由或给它死亡！”

In essence, GPLv2 7 is a verbosely worded way of saying for non-copyright systems what GPLv2 6 says for copyright. If there exists any reason that a distributor knows of that would prohibit later licensees from exercising their full rights under GPL, then distribution is prohibited.

实质上，GPLv2 7是一种措辞繁琐的表述方式，用于针对非版权系统，表达GPLv2 6对版权所说的意思。如果存在任何一个分发者知道会禁止后续许可人行使其在GPL下的全部权利的原因，那么就禁止分发。

Originally, this was designed as the title of this section suggests --- as a last ditch effort to make sure that freedom was upheld. However, in modern times, it has come to give much more. Now that the body of GPL'd software is so large, patent holders who would want to be distributors of GPL'd software have a tough choice. They must choose between avoiding distribution of GPL'd software that exercises the teachings of their patents, or grant a royalty-free, irrevocable, non-exclusive license to those patents. Many companies have chosen the latter.

最初，这是设计成本节标题所示的——作为确保自由得到维护的最后努力。然而，在现代，它给予了更多的意义。现在，由于GPL软件库如此庞大，想要成为GPL软件的分发者的专利持有人面临艰难的选择。他们必须在避免分发行使其专利教导的GPL软件和授予这些专利的免费，不可撤销，非独占许可之间做出选择。许多公司选择了后者。

Wathen Distillery Co., 10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937). The term nevertheless can be a term of indefinite length where its continuing effect is tied to the conduct of the parties. Id.

Wathen Distillery Co.，10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937)。然而，这个术语可以是一个无限期限的术语，其持续影响与各方的行为有关。Id。

Thus, GPLv2 7 rarely gives software death by stopping its distribution. Instead, it is inspiring patent holders to share their patents in the same freedom-defending way that they share their copyrighted works.

因此，GPLv2 7很少会通过停止软件分发来导致软件的死亡。相反，它鼓励专利持有人以维护自由的方式分享他们的专利，就像他们分享版权作品一样。

7.6 GPLv2 §8: Excluding Problematic Jurisdictions

7.6 GPLv2 第8条: 排除问题管辖区

GPLv2 8 is rarely used by copyright holders. Its intention is that if a particular country, say Unfreedonia, grants particular patents or allows copyrighted interfaces (no country to our knowledge even permits those yet), that the GPLv2'd software can continue in free and unabated distribution in the countries where such controls do not exist.

GPLv2 8很少被版权持有人使用。它的意图是，如果某个国家，比如Unfreedonia，授予特定的专利或允许版权接口（目前没有任何国家允许这些），那么GPLv2软件可以在这些管辖区不存在这些控制的国家中自由、无障碍地分发。

As far as is currently known, GPLv2 8 has very rarely been formally used by copyright holders. Ad- mittedly, some have used GPLv2 8 to explain various odd special topics of distribution (usually related in some way to GPLv2 7). However, generally speaking, this section is not proven particularly useful in the more than two decades of GPLv2 history.

据目前所知，GPLv2 8很少被版权持有人正式使用。诚然，有些人使用GPLv2 8来解释分发的各种奇怪特殊话题（通常与GPLv2 7有关）。然而，一般来说，这个部分在GPLv2的二十多年历史中并没有被证明特别有用。

Meanwhile, despite many calls by the FSF (and others) for those licensors who explicitly use this section to come forward and explain their reasoning, no one ever did. Furthermore, research conducted during the GPLv3 drafting process found exactly one licensor who had invoked this section to add an explicit geographical distribution limitation, and the reasoning for that one invocation was not fitting with FSF's intended spirit of GPLv2 *§*8. As such, GPLv2 *§*8 was not included at all in GPLv3.

与此同时，尽管自由软件基金会（FSF）和其他人多次呼吁那些明确使用此部分的许可方来说明他们的理由，但没有人这样做。此外，在GPLv3起草过程中进行的研究发现，只有一个许可方曾引用此部分以添加明确的地理分布限制，而该引用的理由与FSF旨在实现的GPLv2 §8的精神不符。因此，GPLv2 §8在GPLv3中根本没有被包含进来。

CHAPTER 8 ODDS, ENDS, AND ABSOLUTELY NO WARRANTY

第8章杂项，保证和绝对无保证

GPLv2 0--7 constitute the freedom-defending terms of the GPLv2. The remainder of the GPLv2 handles administrivia and issues concerning warranties and liability.

GPLv2 0-7条款构成GPLv2的捍卫自由条款。GPLv2的其余部分处理行政事务和与保证和责任有关的问题。

8.1 GPLv2 §9: FSF as Stewards of GPL

8.1 GPLv2 第9条: FSF作为GPL的监管者

FSF reserves the exclusive right to publish future versions of the GPL; GPLv2 9 expresses this. While the stewardship of the copyrights on the body of GPL'd software around the world is shared among thousands of individuals and organizations, the license itself needs a single steward. Forking of the code is often regrettable but basically innocuous. Forking of licensing is disastrous.

FSF保留了发布GPL未来版本的独有权利; GPLv2 9表达了这一点。虽然全球GPL软件版权的管理权由数千个个人和组织共同分享，但许可证本身需要一个唯一的管理者。代码的分叉通常是令人遗憾但基本无害的。许可证的分叉是灾难性的。

(Chapter [2] discusses more about the various versions of GPL.)

（第2章更多地讨论了GPL的各个版本。）

8.2 GPLv2 §10: Relicensing Permitted

8.2 GPLv2 第10条: 允许重新许可

GPLv2 10 reminds the licensee of what is already implied by the nature of copyright law. Namely, the copyright holder of a particular software program has the prerogative to grant alternative agreements under separate copyright licenses.

GPLv2 10提醒许可证持有人，这已经隐含在版权法的性质中。即特定软件程序的版权持有人有权根据单独的版权许可证授予替代协议。

8.3 GPLv2 §11: No Warranty

8.3 GPLv2 第11条: 没有保证

Most warranty disclaimer language shouts at you. The Uniform Commercial Code 2-316, which most of the USA's states and commonwealths have adopted as their local law, allows disclaimers of warranty, provided that the disclaimer is "conspicuous". There is apparently general acceptance that all caps is the preferred way to make something conspicuous, and that has over decades worked its way into the voodoo tradition of warranty disclaimer writing.

大多数保证免责声明语言都在大声喊叫。美国大部分州和自治领地采用的《统一商业法典》第2-316条款允许免责声明，前提是声明是“显著的”。显然有一般认同，全部字母大写是使某物显著的首选方式，这几十年已经成为保证免责声明书写的巫术传统。

That said, there is admittedly some authority under USA law suggesting that conspicuousness can be established by capitalization and is absent when a disclaimer has the same typeface as the terms surrounding it (see Stevenson v. TRW, Inc., 987 F.2d 288, 296 (5th Cir. 1993)). While GPLv3's drafters doubted that such authority would apply to copyright licenses like the GPL, the FSF has nevertheless left warranty and related disclaimers in all caps throughout all versions of GPL.²²

尽管如此，美国法律中确实存在一些权威机构认为，通过大写字母可以确定显著性，并且当免责声明与周围条款具有相同字体时，显著性就不存在（见Stevenson v. TRW, Inc.，987 F.2d 288, 296（第5巡回法庭，1993年））。虽然GPLv3的起草者怀疑此类权威将适用于像GPL这样的版权许可证，但FSF仍然在GPL的所有版本中将保证和相关免责声明保留为全部大写字母。²²

Critics have occasionally questioned GPL's enforceability in some jurisdictions because its disclaimer of warranties is impermissibly broad. However, critics have generally failed to articulate specific precedents in their jurisdictions that would directly indicate a problem with GPL's warranty disclaimer. Meanwhile, Article 35 of the United Nations Convention on Contracts for the International Sale of Goods (often abbreviated "CISG", which many countries have adopted) permits the disclaimer of warranties, so jurisdictions adopting this treaty allow some form of warranty disclaimer²³. Nevertheless, to account for possible jurisdictional variances regarding this or any other issue, GPLv2 11 contains a jurisdictional savings provision, which states that it is to be interpreted only as broadly as allowed by applicable law. Such a provision ensures that both it, and the entire GPL, is enforceable in any jurisdiction, regardless of any particular law regarding the permissibility of certain warranty disclaimers.

批评者偶尔会质疑在某些司法管辖区内 GPL 的可执行性，因为其免责声明过于宽泛。然而，这些批评者通常未能明确阐述在其司法管辖区内存在直接指出 GPL 免责声明存在问题的具体先例。同时，联合国《国际货物销售合同公约》（常缩写为“CISG”）的第 35 条（许多国家已经采纳）允许免责声明，因此采用这个公约的司法管辖区允许某种形式的免责声明²³。尽管如此，为了考虑到可能存在的司法管辖区异同，GPLv2 第 11 条包含了一个司法管辖区的节省规定，规定它只能按适用法律所允许的范围来解释。这样的规定确保了它及整个 GPL 在任何司法管辖区都是可执行的，而不受特定法律关于某些免责声明是否允许的影响。

Finally, one important point to remember when reading GPLv2 *§*11 is that GPLv2 *§*1 permits the sale of warranty as an additional service, which GPLv2 *§*11 affirms.

最后，在阅读 GPLv2 §11 时需要记住的一点是，GPLv2 §1 允许销售保修作为额外服务，而 GPLv2 §11 亦予以确认。

8.4 GPLv2 §12: Limitation of Liability

8.4 GPLv2 第12条：责任限制

There are many types of warranties, and in some jurisdictions some of them cannot be disclaimed. Therefore, usually agreements will have both a warranty disclaimer and a limitation of liability, as we have in GPLv2 12. GPLv2 11 thus gets rid of all implied warranties that can legally be disavowed. GPLv2 12, in turn, limits the liability of the actor for any warranties that cannot legally be disclaimed in a particular jurisdiction.

有许多类型的保证，在某些司法管辖区，其中一些保证可能无法否认。因此，通常协议会既有保证免责声明，也有责任限制，正如 GPLv2 12 所规定的那样。GPLv2 11 因此消除了可以在法律上否认的所有默示保证。而 GPLv2 12 则限制了在特定司法管辖区无法法律上否认的任何保证的责任。

Again, some have argued the GPL is unenforceable in some jurisdictions because its limitation of liability is impermissibly broad. However, 12, just like its sister, GPLv2 11, contains a jurisdictional savings provision, which states that it is to be interpreted only as broadly as allowed by applicable law. As stated above, such a provision ensures that both GPLv2 12, and the entire GPL, is enforceable in any jurisdiction, regardless of any particular law regarding the permissibility of limiting liability.

同样，一些人认为 GPL 在某些司法管辖区是不可执行的，因为其责任限制过于广泛。然而，GPLv2 12 就像其姐妹 GPLv2 11 一样，包含了司法管辖区救济条款，规定其只能按适用法律所允许的程度来解释。如上所述，这样的条款确保了 GPLv2 12 和整个 GPL 在任何司法管辖区都是可执行的，无论特定法律是否允许限制责任。

So end the terms and conditions of the GNU General Public License.

这就是 GNU 通用公共许可证的条款和条件。

CHAPTER 9 GPL VERSION 3

第9章 GPL 第3版

This chapter discusses the text of GPLv3. Much of this material herein includes text that was adapted (with permission) from text that FSF originally published as part of the so-called "rationale documents" for the various discussion drafts of GPLv3.

本章讨论GPLv3的文本。本文中的大部分材料是从FSF（经许可）最初作为各种讨论草案的所谓“基本原理文件”的部分文本编写。

The FSF ran a somewhat public process to develop GPLv3, and it was the first attempt of its kind to develop a Free Software license this way. Ultimately, RMS was the primary author of GPLv3, but he listened to feedback from all sorts of individuals and even for-profit companies. Nevertheless, in attempting to understand GPLv3 after the fact, the materials available from the GPLv3 process have a somewhat "drinking from the firehose" effect. This chapter seeks to explain GPLv3 to newcomers, who perhaps are familiar with GPLv2 and who did not participate in the GPLv3 process.

FSF运行了一个公开的开发GPLv3的流程，这是首次尝试开发自由软件许可证的方法。最终，RMS是GPLv3的主要作者，但是他听取了各种个人甚至是营利性公司的反馈。然而，试图在事后理解GPLv3，有点像“就着消防栓喝水”的感觉。本章旨在向可能熟悉GPLv2，而未参与过GPLv3流程的新手解释GPLv3。

Those who wish to drink from the firehose and take a diachronic approach to GPLv3 study by reading the step-by-step public drafting process of the GPLv3 (which occurred from Monday 16 January 2006 through Monday 19 November 2007) should visit http://gplv3.fsf.org/.

那些希望通过阅读GPLv3起草过程（从2006年1月16日星期一到2007年11月19日星期一）对GPLv3研究采取历时方法的人应该访问 http://gplv3.fsf.org 。

Understanding GPLv3 As An Upgraded GPLv2

9.1 把GPLv3理解为GPLv2的升级版

Ultimately, GPLv2 and GPLv3 co-exist as active licenses in regular use. As discussed in Chapter [2] GPLv1 was never regularly used alongside GPLv2. However, given GPLv2's widespread popularity and existing longevity by the time GPLv3 was published, it is not surprising that some licensors still prefer GPLv2-only or GPLv2-or-later. GPLv3 gained major adoption by many projects, old and new, but many projects have not upgraded due to (in some cases) mere laziness and (in other cases) policy preference for some of GPLv2's terms and/or policy opposition to GPLv3's terms.

最终，GPLv2和GPLv3作为常规有效许可证共存。如第2章所述。GPL第1版从未与GPLv2一起常规使用。然而，鉴于GPLv2的广泛流行和GPLv3发布时的现有寿命，一些人许可人更喜欢采用仅GPLv2，或者，GPLv2或者后续版本就不足为奇了。

Given this "two GPLs world" is reality, it makes sense to consider GPLv3 in terms of how it differs from GPLv2. Also, most of the best GPL experts in the world must deal regularly with both licenses, and admittedly have decades of experience with GPLv2 while the most experience with GPLv3 that's possible is by definition less than a decade. These two factors usually cause even new students of GPL to start with GPLv2 and move on to GPLv3, and this tutorial follows that pattern.

鉴于这个“两个 GPL 世界”是现实，对 GPLv3 与 GPLv2 的区别来考虑它是有意义的。此外，世界上大多数最优秀的 GPL 专家必须定期处理这两个许可证，并且公认的是拥有数十年的 GPLv2 经验，理论上讲，最多的 GPLv3 经验可能不到10年。这两个因素通常甚至会导致 GPL 的新人不是从 GPLv2 开始，而是直接然后转向 GPLv3，本教程遵循这种模式。

Overall, the changes made in GPLv3 admittedly increased the complexity of the license. The FSF stated at the start of the GPLv3 process that they would have liked to oblige those who have asked for a simpler and shorter GPL. Ultimately, the FSF gave priority to making GPLv3 a better copyleft license in the spirit of past GPL's. Obsession for concision should never trump software freedom.

总的来说，GPLv3 中所做的更改无疑增加了许可证的复杂性。FSF 在 GPLv3 流程开始时表示，他们愿意帮助那些要求更简单、更短的 GPL 的人。最终，FSF 本着过去 GPL 的精神，优先考虑让 GPLv3 成为更好的 copyleft 许可证。对简洁的痴迷永远不应胜过软件自由。

The FSF had many different, important goals in seeking to upgrade to GPLv3. However, one important goal that is often lost in the discussion of policy minutia is a rather simple but important issue. Namely, FSF sought to assure that GPLv3 was more easily internationalized than GPLv2. In particular, the FSF sought to ease interpretation of GPL in other countries by replacement of USA-centric²⁴ copyright phrases and wording with neutral terminology rooted in description of behavior rather than specific statute. As can be seen in the section-by-section discussion of GPLv3 that follows, nearly every section had changes related to issues of internationalization.

FSF 在寻求升级到 GPLv3 方面有许多不同的重要目标。然而，在讨论政策细枝末节时经常遗漏的一个重要目标是一个相当简单但重要的问题。那就是，FSF 试图确保 GPLv3 比 GPLv2 更容易国际化。特别是，FSF 试图通过替换以美国为中心的 ²⁴ 版权术语来简化其他国家/地区对 GPL 的解释。以及植根于行为描述而非特定法规的中性术语措辞。从接下来对 GPLv3 的逐节讨论中可以看出，几乎每一节都有与国际化问题相关的更改。

GPLv3 §0: Giving In On "Defined Terms"

9.2 GPLv3 第0条：在“条款定义”上的让步

One of lawyers' most common complaints about GPLv2 is that defined terms in the document appear throughout. Most licenses define terms up-front. However, the GPL was always designed both as a document that should be easily understood both by lawyers and by software developers: it is a document designed to give freedom to software developers and users, and therefore it should be comprehensible to that constituency.

律师对 GPLv2 最常见的抱怨之一是文档中术语的定义贯穿始终。大多数许可证预先定义条款。然而，GPL 始终被设计成一个应该易于被律师和软件开发人员理解的文件：它是一个旨在为软件开发人员和用户提供自由的文件，因此它应该易于被这类用户所理解。

Interestingly enough, one coauthor of this tutorial who is both a lawyer and a developer pointed out that in law school, she understood defined terms more quickly than other law students precisely because of her programming background. For developers, having #define (in the C programming language) or other types of constants and/or macros that automatically expand in the place where they are used is second nature. As such, adding a defined terms section was not terribly problematic for developers, and thus GPLv3 adds one. Most of these defined terms are somewhat straightforward and bring forward better worded definitions from GPLv2. Herein, this tutorial discusses a few of the new ones.

有趣的是，本教程的一位合著者既是律师又是开发人员，她指出，在法学院，由于她的编程背景，她比其他法学院学生更快地理解术语的定义。对于开发人员来说，拥有 #define （在 C 编程语言中）或其他类型的常量和/或在使用它们的地方自动扩展的宏是第二天性。因此，添加一个术语的定义对开发人员来说并不是什么大问题，因此 GPLv3 也确实增加了新的定义。这些定义的术语中的大多数都有些直截了当，并从 GPLv2 中提出了更好的措辞定义。在此，本教程讨论的那些新增加的。

GPLv3 0 includes definitions of five new terms not found in any form in GPLv2: "modify" "covered work", "propagate", "convey", and "Appropriate Legal Notices".

GPLv3 第0条包括 GPLv2 中没有以任何形式出现的五个新术语的定义：“修改”、“涵盖的作品”、“传播”、“传达”和“适当的法律声明”。

Modify and the Work Based on the Program

9.2.1 基于程序的修改和工作

GPLv2 included a defined term, "work based on the Program", but also used the term "modify" and "based on" throughout the license. GPLv2's "work based on the Program" definition made use of a legal term of art, "derivative work", which is peculiar to USA copyright law.²⁵ GPLv2 always sought to cover all rights governed by relevant copyright law, in the USA and elsewhere. Even though differently-labeled concepts corresponding to the derivative work are recognized in all copyright law systems, these counterpart concepts might differ to some degree in scope and breadth from the USA derivative work. GPLv3 therefore internationalizes on this issue by removing GPLv2's references to derivative works and by providing a more globally useful definition. GPLv3 drops all reference to USA "derivative works" and returns to the base concept only: GPL covers the licensed work and all works where copyright permission from the licensed work's copyright holder.

GPLv2 包括一个术语“基于程序的作品”的定义，但在整个许可证中也使用了术语“修改”和“基于”。GPLv2 的“基于程序的作品”定义使用了美国版权法特有的艺术术语“衍生作品”²⁵。GPLv2 始终寻求涵盖美国相关版权法管辖的所有权利和其他地方。尽管与衍生作品相对应的不同标签概念在所有版权法体系中都得到认可，但这些对应概念可能在范围和广度上与美国衍生作品存在一定程度的差异。因此，GPLv3 通过删除 GPLv2 对衍生作品的引用并提供更具全球实用性的定义，使这个问题国际化。GPLv3 删除了所有对美国“衍生作品”的引用，并仅返回基本概念：GPL 涵盖许可作品和所有获得许可作品版权所有者版权许可的作品。

The new definitions returns to the common elements of copyright law. Copyright holders of works of software have the exclusive right to form new works by modification of the original --- a right that may be expressed in various ways in different legal systems. GPLv3 operates to grant this right to successive generations of users (particularly through the copyleft conditions set forth in GPLv3 5, as described later in this tutorial in its 9.8). Here in GPLv3 0, "modify" refers to basic copyright rights, and then this definition of "modify" is used to define "modified version of" and "work based on" as synonyms.

新定义回归版权法的共同要素。软件作品的版权持有者拥有通过修改原件形成新作品的专有权——这种权利在不同的法律体系中可能以不同的方式表达。GPLv3 将此权利授予连续几代用户（特别是通过 GPLv3 第5条中规定的 copyleft 条件，如本教程后面的 9.8 中所述）。这里在 GPLv3 第0条中，“修改”指的是基本版权，然后这个“修改”的定义用来定义“修改版本”和“基于”的同义词。

The Covered Work

9.2.2 涵盖的工作

GPLv3 uses a common license drafting technique of building upon simpler definitions to make complex ones. The Program is a defined term found throughout GPLv2, and the word "covered" and the phrase "covered by this license" are used in tandem with the Program in GPLv2, but not as part of a definition. GPLv3 offers a single term "covered work", which enables some of the wording in GPLv3 to be simpler and clearer than its GPLv2 counterparts.

GPLv3 使用一种通用的许可证起草技术，即在更简单的定义基础上构建复杂的定义。“本程序”是贯穿 GPLv2 的一个定义术语，“涵盖”一词和短语“受本许可证涵盖”在 GPLv2 中与“本程序”一起使用，但不作为定义的一部分。GPLv3 提供了一个单一的术语“涵盖的作品”，这使得 GPLv3 中的一些措辞比 GPLv2 对应的措辞更简单、更清晰。

Next, to avoid locking GPLv3 into specific copyright statues, the GPLv3 defines two terms that are otherwise exotic to the language of international copyright.

接下来，为了避免将 GPLv3 锁定在特定的版权法规中，GPLv3 定义了两个对国际版权语言来说陌生的术语。

Propagate

9.2.3 传播

To "propagate" a work covered by the license means any activity in a locale that requires permission of copyright holders in that locale's legal system. However, personal use or modification for personal use are activities explicitly excluded from "propagation" regardless of domestic copyright law.

The term "propagate" serves two purposes. First, "propagate" provides a simple and convenient means for distinguishing between the kinds of uses of a work that GPL imposes conditions on and the kinds of uses that GPL does not (for the most part) impose conditions on.

“传播”一词有两个目的。首先，“传播”提供了一种简单方便的方式来区分 GPL 施加条件的作品的使用类型和 GPL 不（在大多数情况下）施加条件的使用类型。

Second, "propagate" helps globalize GPL in its wording and effect: "derivative work" was in fact not the only term commonly used by local copyright statutes. A term like "distribute" (or its equivalent in languages other than English) is also used in several national copyright statutes. Practical experience with GPLv2 revealed the awkwardness of using the term "distribution" in a license intended for global use: the scope of "distribution" in the copyright context can differ from country to country. The GPL never necessarily intended the specific meaning of "distribution" that exists under USA (or any other country's) copyright law.

其次，“传播”有助于 GPL 在措辞和效果上的全球化：“衍生作品”实际上并不是当地版权法规常用的唯一术语。一些国家的版权法规中也使用了诸如“分发”（或英语以外的其他语言中的等效词）之类的术语。GPLv2 的实践经验揭示了在全球使用的许可证中使用术语“分发”的尴尬：版权上下文中的“分发”范围可能因国家/地区而异。GPL 未必意指美国（或任何其他国家/地区）版权法下存在的“分发”的特定含义。

Indeed, even within a single country and language, the term distribution may be ambiguous; as a legal term of art, distribution varies significantly in meaning among those countries that recognize it. For example, comments during GPLv3's drafting process indicated that in at least one country, distribution may not include network transfers of software but may include interdepartmental transfers of physical copies within an organization. Meanwhile, the copyright laws of many countries, as well as certain international copyright treaties, recognize "making available to the public" or "communication to the public" as one of the exclusive rights of copyright holders.

事实上，即使在单一的国家和语言中，术语分布也可能是模棱两可的；作为一个法律术语，分配在承认它的国家之间的含义差异很大。例如，GPLv3 起草过程中的评论表明，至少在一个国家/地区，分发可能不包括软件的网络传输，但可能包括组织内物理副本的部门间传输。同时，许多国家的版权法以及某些国际版权条约都承认“向公众提供”或“向公众传播”是版权人的专有权利之一。

Therefore, the GPLv3 defines the term "propagate" by reference to activities that require permission un- der "applicable copyright law", but excludes execution and private modification from the definition. GPLv3's definition also gives examples of activities that may be included within "propagation" but it also makes clear that, under the copyright laws of a given country, "propagation" may include other activities as well.

因此，GPLv3 通过引用根据“适用版权法”需要许可的活动来定义术语“传播”，但从定义中排除了执行和私人修改。GPLv3 的定义还给出了可能包含在“传播”范围内的活动示例，但它也明确指出，根据特定国家/地区的版权法，“传播”也可能包括其他活动。

Thus, propagation is defined by behavior, and not by categories drawn from some particular national copyright statute. This helps not only with internationalization, but also factually-based terminology aids in developers' and users' understanding of the GPL.

因此，传播是由行为定义的，而不是由某些特定国家版权法规中的类别定义的。这不仅有助于国际化，而且基于事实的术语有助于开发人员和用户理解 GPL。

As a further benefit, because "propagation" includes all exclusive rights granted under any particular copyright regime, the term automatically accounts for all exclusive rights under that regime.

作为进一步的好处，因为“传播”包括任何特定版权制度下授予的所有专有权，该术语自动说明该制度下的所有专有权。

Convey

9.2.4 传达

Next, GPLv3 defines a subset of propagate --- "convey". Conveying includes activities that constitute propagation of copies to others. As with the definition of propagate, GPLv3 thus addresses transfers of copies of software in behavioral rather than statutory terms. Any propagation that enables other parties to receive or make copies of the work, is called "conveying". Usually, conveying is the activity that triggers most of the other obligations of GPLv3.

接下来，GPLv3 定义了传播的一个子集——“传达”（convey）。传送包括构成向他人传播副本的活动。与传播的定义一样，GPLv3 因此以行为而非法定条款处理软件副本的传输。使其他方能够接收或复制作品的任何传播都称为“传送”。通常，传送是触发 GPLv3 的大部分其他义务的活动。

Appropriate Legal Notices

9.2.5 适当的法律声明

GPLv2 used the term "appropriate copyright notice and disclaimer of warranty" in two places, which is a rather bulky term. Also, experience with GPLv2 and other licenses that grant software freedom showed throughout the 1990s that the scope of types of notices that need preservation upon conveyance were more broad that merely the copyright notices. The Appropriate Legal Notice definition consolidates the material that GPLv2 traditionally required preserved into one definition.

Other Defined Terms

9.2.6 其他术语的定义

Note finally that not all defined terms in GPLv3 appear in GPLv3 0. Specifically, those defined terms that are confined in use to a single section are defined in the section in which they are used, and GPLv3 1 contains those definitions focused on source code. In this tutorial, those defined terms are discussed in the section where they are defined and/or used.

最后请注意，并不是所有 GPLv3 中定义的术语都出现在 GPLv3 第0条中。具体来说，那些被限制在单个部分中使用的定义术语在使用它们的部分中定义，而 GPLv3 条款一包含那些专注于源代码的定义。在本教程中，这些定义的术语将在定义和/或使用它们的部分进行讨论。

GPLv3 §1: Understanding CCS

9.3 GPLv3 第1条：理解CCS

Ensuring that users have the source code to the software they receive and the freedom to modify remains the paramount right embodied in the Free Software Definition (found in [1.1] of this tutorial). As such, GPLv3 1 is likely one of the most important sections of GPLv3, as it contains all the defined terms related to this important software freedom.

确保用户拥有他们收到的软件的源代码和修改的自由仍然是自由软件定义（参见本教程的 1.1 ）中体现的首要权利。因此，GPLv3 条款一可能是 GPLv3 最重要的部分之一，因为它包含与这一重要软件自由相关的所有定义条款。

9.3.1 Source Code Definition

9.3.1 源代码的定义

First, GPLv3 1 retains GPLv2's definition of "source code" and adds an explicit definition of "object code" as "any non-source version of a work". Object code is not restricted to a narrow technical meaning and is understood broadly to include any form of the work other than the preferred form for making modifications to it. Object code therefore includes any kind of transformed version of source code, such as bytecode or minified Javascript. The definition of object code also ensures that licensees cannot escape their obligations under the GPL by resorting to shrouded source or obfuscated programming.

首先，GPLv3 条款一保留了 GPLv2 对“源代码”的定义，并将“目标代码”明确定义为“作品的任何非源版本”。目标代码并不局限于狭义的技术含义，而是广义地理解为包括除对其进行修改的首选形式之外的任何形式的作品。因此，目标代码包括任何类型的源代码转换版本，例如字节码或缩小的 Javascript。目标代码的定义还确保被许可人无法通过诉诸隐藏源代码或混淆编程来逃避 GPL 规定的义务。

9.3.2 CCS Definition

9.3.2 CCS的定义

The definition of CCS,²⁶ or, as GPLv3 officially calls it, "Corresponding Source" in GPLv3 1 4 is possibly the most complex definition in the license.

CCS 的定义²⁶，或 GPLv3 官方称之为 GPLv3 条款一 4 中的“对应源”可能是许可证中最复杂的定义。

The CCS definition is broad so as to protect users' exercise of their rights under the GPL. The definition includes particular examples to remove any doubt that they are to be considered CCS. GPLv3 seeks to make it completely clear that a licensee cannot avoid complying with the requirements of the GPL by dynamically linking a subprogram component to the original version of a program. The examples also clarify that the shared libraries and dynamically linked subprograms that are included in Corresponding Source are those that the work is "specifically" designed to require, which clarifies that they do not include libraries invoked by the work that can be readily substituted by other existing implementations. While copyleft advocates never doubted this was required under GPLv2's definition of CCS, GPLv3 makes it abundantly clear with an extra example.

CCS 的定义很宽泛，以保护用户行使其在 GPL 下的权利。该定义包括特定示例，以消除对它们被视为 CCS 的任何疑问。GPLv3 力求完全清楚地表明，被许可人无法通过将子程序组件动态链接到程序的原始版本来避免遵守 GPL 的要求。这些示例还阐明了相应源代码中包含的共享库和动态链接的子程序是作品“专门”设计需要的那些，这阐明了它们不包括作品调用的库，这些库可以很容易地被其他人替换现有的实施。虽然 Copyleft 倡导者从不怀疑这是 GPLv2 对 CCS 的定义所要求的，但 GPLv3 通过一个额外的例子使其非常清楚。

The GPL, as always, seeks to ensure users are truly in a position to install and run their modified versions of the program; the CCS definition is designed to be expansive to ensure this software freedom. However, although the definition of CCS is expansive, it is not sufficient to protect users' freedoms in many circumstances. For example, a GPL'd program, or a modified version of such a program, might be locked- down and restricted. The requirements in GPLv3 6 (discussed in Section 9.9 of this tutorial) handle that issue. (Early drafts of GPLv3 included those requirements in the definition of CCS; however, given that the lock-down issue only comes up in distribution of object code, it is more logical to place those requirements with the parts of GPLv3 dealing directly with object code distribution).

GPL 一如既往地寻求确保用户真正能够安装和运行他们修改后的程序版本； CCS 定义旨在扩展以确保这种软件自由。然而，尽管 CCS 的定义很广泛，但在许多情况下不足以保护用户的自由。例如，GPL 程序或此类程序的修改版本可能会被锁定和限制。GPLv3 条款六中的要求（在本教程的第 9.9 节中讨论）解决了这个问题。（GPLv3 的早期草案在 CCS 的定义中包含了这些要求；然而，鉴于锁定问题只出现在目标代码的分发中，将这些要求放在 GPLv3 直接处理目标代码的部分中更为合乎逻辑分配）。

The penultimate paragraph in GPLv3 2 notes that GPLv3's CCS definition does not require source that can be automatically generated. Many code generators, preprocessors and take source code as input and sometimes even have output that is still source code. Source code should always be whatever the original programmer preferred to modify.

GPLv3 第2条中的倒数第二段指出 GPLv3 的 CCS 定义不需要可以自动生成的源。许多代码生成器、预处理器和将源代码作为输入，有时甚至输出仍然是源代码。源代码应该始终是原始程序员喜欢修改的任何内容。

GPLv3 1's final paragraph removes any ambiguity about what should be done on source-only distribu- tions. Specifically, the right to convey source code that does not compile, does not work, or otherwise is experimental in-progress work is fully permitted, provided that no object code form is conveyed as well. Indeed, when combined with the permissions in GPLv3 5, it is clear that if one conveys only source code, one can never be required to provide more than that. One always has the right to modify a source code work by deleting any part of it, and there can be no requirement that free software source code be a whole functioning program.

GPLv3 条款一的最后一段消除了关于应该在纯源代码发行版上做什么的任何歧义。具体而言，完全允许传输未编译、无法运行或处于实验性进行中工作的源代码的权利，前提是不传输任何目标代码形式。事实上，当结合 GPLv3 第5条中的许可时，很明显，如果一个人只传达源代码，就永远不会被要求提供更多。人们始终有权通过删除源代码作品的任何部分来修改源代码作品，并且可以不要求自由软件源代码是一个完整的功能程序。

9.3.3 The System Library Exception

9.3.3 系统库例外

The previous section skipped over one part of the CCS definition, the so-called system library exception. The "System Libraries" definition (and the "Standard Interface" and "Major Component" definitions, which it includes) are designed to permit certain distribution arrangements that are considered reasonable by copyleft advocates. The system library exception is designed to allow copylefted software to link with these libraries when prohibition of that linking would hurt software freedom more than it would hurt proprietary software. The system library exception has two parts. Part (a) rewords the GPLv2 exception for clarity replacing GPLv2's words "unless that component itself accompanies the executable" with "which is not part of the Major Component". The goal here is to not require disclosure of source code of certain libraries, such as necessary Microsoft Windows DLLs (which aren't part of Windows' kernel but accompany it) that are required for functioning of copylefted programs compiled for Windows.

上一节跳过了 CCS 定义的一部分，即所谓的系统库异常。“系统库”定义（以及其中包含的“标准接口”和“主要组件”定义）旨在允许 copyleft 倡导者认为合理的某些分发安排。系统库例外旨在允许 copylefted 软件与这些库链接，而禁止该链接对软件自由的伤害大于对专有软件的伤害。系统库异常有两部分。(a) 部分重写了 GPLv2 例外，以清楚地将 GPLv2 的措辞“除非该组件本身伴随可执行文件”替换为“它不是主要组件的一部分”。这里的目标是不要求公开某些库的源代码，例如必要的 Microsoft Windows DLL（它们不是 Windows 内核的一部分，但伴随它）是为 Windows 编译的 copylefted 程序运行所必需的。

However, in isolation, (a) would be too permissive, as it would sometimes allow distributors to evade important GPL requirements. Part (b) reigns in (a). Specifically, (b) specifies only a few functionalities that a system library may provide and still qualify for the exception. The goal is to ensure system libraries are truly adjunct to a major essential operating system component, compiler, or interpreter. The more low-level the functionality provided by the library, the more likely it is to be qualified for this exception.

但是，单独来看，(a) 过于宽容，因为它有时会允许发行商规避重要的 GPL 要求。(b) 部分优先于 (a) 部分。具体来说，(b) 仅指定了系统库可能提供的少数功能，并且仍然符合例外条件。目标是确保系统库真正附属于主要的基本操作系统组件、编译器或解释器。库提供的功能越低级，越有可能符合此异常。

Admittedly, the system library exception is a frequently discussed topic of obsessed GPL theorists. The amount that has been written on the system library exception (both the GPLv2 and GPLv3 versions of it), if included herein, could easily increase this section of the tutorial to a length greater than all the others.

诚然，系统库异常是痴迷于 GPL 的理论家经常讨论的话题。如果包含在系统库异常（它的 GPLv2 和 GPLv3 版本）上的数量，很容易将本教程的这一部分增加到比其他所有部分都长的长度。

Like any exception to the copyleft requirements of GPL, would-be GPL violators frequently look to the system library exception as a potential software freedom circumvention technique. When considering whether or not a library qualifies for the system library exception, here is a pragmatic thesis to consider, based on the combined decades of experience in GPL interpretation of this tutorial's authors: the harder and more strained the reader must study and read the system library exception, the more likely it is that the library in question does not qualify for it.

与 GPL 的 copyleft 要求的任何例外一样，潜在的 GPL 违反者经常将系统库例外视为潜在的软件自由规避技术。在考虑一个库是否符合系统库例外条件时，根据本教程作者数十年的 GPL 解释经验，这里有一个实用的论点需要考虑：读者必须越努力、越紧张地学习和阅读系统 library exception，有问题的图书馆越有可能不符合条件。

GPLv3 §2: Basic Permissions

9.4 GPLv3 第2条：基本权利

GPLv3 2 can roughly be considered as an equivalent to GPLv2 0 (discussed in 3.1 of this tutorial). However, the usual style of improvements found in GPLv3 are found here as well. For example, the first sentence of GPLv3 2 furthers the goal internationalization. Under the copyright laws of some countries, it may be necessary for a copyright license to include an explicit provision setting forth the duration of the rights being granted. In other countries, including the USA, such a provision is unnecessary but permissible. GPLv3 2 1 also acknowledges that licensees under the GPL enjoy rights of copyright fair use, or the equivalent under applicable law. These rights are compatible with, and not in conflict with, the freedoms that the GPL seeks to protect, and the GPL cannot and should not restrict them.

GPLv3 条款可以粗略地视为等同于 GPLv2 第0条（在本教程的 3.1 中讨论）。但是，这里也可以找到 GPLv3 中常见的改进方式。例如，GPLv3 条款二的第一句进一步推进了目标国际化。根据某些国家/地区的版权法，版权许可可能需要包括明确规定授予权利的期限。在包括美国在内的其他国家，这样的规定是不必要的，但却是允许的。GPLv3 条款二第1项还承认 GPL 下的被许可人享有版权合理使用权或适用法律下的同等权利。这些权利与自由相容而不冲突GPL 寻求保护的内容，而 GPL 不能也不应该限制它们。

However, note that (sadly to some copyleft advocates) the unlimited freedom to run is confined to the unmodified Program. This confinement is unfortunately necessary since Programs that do not qualify as a User Product in GPLv3 6 (see [9.9.2] in this tutorial) might have certain unfortunate restrictions on the freedom to run.²⁷

然而，请注意（对某些 copyleft 拥护者而言令人遗憾的是）无限的运行自由仅限于未修改的程序。不幸的是，这种限制是必要的，因为在 GPLv3 条款六中不符合用户产品资格的程序（请参阅本教程中的 9.9.2）可能对运行自由有某些不幸的限制²⁷。

GPLv3 2 2 distinguishes between activities of a licensee that are permitted without limitation and activities that trigger additional requirements. Specifically, GPLv3 2 2 guarantees the basic freedoms of privately modifying and running the program. While these basic freedoms were generally considered a standard part of users' rights under GPLv2 as well, the GPLv3 states them herein more explicitly. In other words, there is no direct analog to the first sentence of GPLv3 2 2 in GPLv2 (See [5.1.3] of this tutorial for more on this issue.)

GPLv3 第2条第2款区分被许可人允许但不限于的活动和触发额外要求的活动。具体来说，GPLv3 第2条第2款保证了私下修改和运行程序的基本自由。虽然这些基本自由通常也被视为 GPLv2 下用户权利的标准部分，但 GPLv3 在此更明确地说明了它们。换句话说，在 GPLv2 中没有直接模拟 GPLv3 条款二第2项的第一句（有关此问题的更多信息，请参见本教程的 5.1.3。）

Also, GPLv3 2 2 gives an explicit permission for a client to provide a copy of its modified software to a contractor exclusively for that contractor to modify it further, or run it, on behalf of the client. However, the client can only exercise this control over its own copyrighted changes to the GPL-covered program. The parts of the program it obtained from other contributors must be provided to the contractor with the usual GPL freedoms. Thus, GPLv3 permits users to convey covered works to contractors operating exclusively on the users' behalf, under the users' direction and control, and to require the contractors to keep the users' copyrighted changes confidential, but only if the contractor is limited to acting on the users' behalf (just as the users' employees would have to act).

此外，GPLv3 第2条第2款明确允许客户向承包商提供其修改后软件的副本，专供承包商代表客户进一步修改或运行。但是，客户只能对其自己对受 GPL 保护的程序的版权更改行使此控制权。它从其他贡献者那里获得的程序部分必须以通常的 GPL 自由提供给承包商。因此，GPLv3 允许用户将涵盖的作品传送给专门在代表用户，在用户的指导和控制下，并要求承包商对用户的受版权保护的更改保密，但前提是承包商仅限于代表用户行事（就像用户的员工会行动）。

The strict conditions in this "contractors provision" are needed so that it cannot be twisted to fit other activities, such as making a program available to downstream users or customers. By making the limits on this provision very narrow, GPLv3 ensures that, in all other cases, contractor gets the full freedoms of the GPL that they deserve.

需要此“承包商条款”中的严格条件，以使其不能被扭曲以适应其他活动，例如向下游用户或客户提供程序。GPLv3 使这一条款的限制非常狭窄，确保在所有其他情况下，承包商获得他们应得的 GPL 的全部自由。

The FSF was specifically asked to add this "contractors provisions" by large enterprise users of Free Software, who often contract with non-employee developers, working offsite, to make modifications intended for the user's private or internal use, and often arrange with other companies to operate their data centers. Whether GPLv2 permits these activities is not clear and may depend on variations in copyright law in different jurisdictions. The practices seem basically harmless, so FSF decided to make it clear they are permitted.

FSF 被自由软件的大型企业用户特别要求添加这个“承包商规定”，他们经常与非雇员开发人员签订合同，在异地工作，进行修改供用户私人或内部使用，并经常与其他公司安排运营他们的数据中心。GPLv2 是否允许这些活动尚不清楚，可能取决于不同司法管辖区版权法的变化。这些做法基本上看起来是无害的，因此 FSF 决定明确表示它们是允许的。

GPLv3 2's final paragraph includes an explicit prohibition of sublicensing. This provision ensures that GPL enforcement is always by the copyright holder. Usually, sublicensing is regarded as a practical convenience or necessity for the licensee, to avoid having to negotiate a license with each licensor in a chain of distribution. The GPL solves this problem in another way --- through its automatic licensing provision found in GPLv3 *§*10 (which is discussed in more detail in § 9.13 of this tutorial).

GPLv3's views on DRM and Device Lock-Down

9.5 GPLv3 对 DRM 和设备锁定的看法

The issues of DRM, device lock-down and encryption key disclosure were the most hotly debated during the GPLv3 process. FSF's views on this were sadly frequently misunderstood and, comparing the provisions related to these issues in the earliest drafts of GPLv3 to the final version of GPLv3 shows the FSF's willingness to compromise on tactical issues to reach the larger goal of software freedom.

DRM、设备锁定和加密密钥泄露等问题是 GPLv3 过程中争论最激烈的问题。遗憾的是，FSF 对此的看法经常被误解，将 GPLv3 最早草案中与这些问题相关的条款与 GPLv3 的最终版本进行比较，表明 FSF 愿意在战术问题上做出妥协，以实现更大的软件自由目标。

Specifically, GPLv3 introduced provisions that respond to the growing practice of distributing GPL- covered programs in devices that employ technical means to restrict users from installing and running modified versions. This practice thwarts the expectations of developers and users alike, because the right to modify is one of the core freedoms the GPL is designed to secure.

具体来说，GPLv3 引入了一些条款，以应对越来越多的在设备中分发 GPL 覆盖程序的做法，这些设备采用技术手段来限制用户安装和运行修改版本。这种做法违背了开发人员和用户的期望，因为修改权是 GPL 旨在保护的核心自由之一。

Technological measures to defeat users' rights. These measures are often described by such Orwellian phrases, such as "digital rights management," which actually means limitation or outright destruction of users' legal rights, or "trusted computing," which actually means selling people computers they cannot trust. However, these measures are alike in one basic respect. They all employ technical means to turn the system of copyright law (where the powers of the copyright holder are limited exceptions to general freedom) into a virtual prison, where everything not specifically permitted is utterly forbidden. This system of "para- copyright" was created well after GPLv2 was written --- initially through legislation in the USA and the EU, and later in other jurisdictions as well. This legislation creates serious civil or even criminal penalties to escape from these restrictions (commonly and aptly called "jail-breaking a device"), even where the purpose in doing so is to restore the users' legal rights that the technology wrongfully prevents them from exercising. GPLv2 did not address the use of technical measures to take back the rights that the GPL granted, because such measures did not exist in 1991, and would have been irrelevant to the forms in which software was then delivered to users. GPLv3 addresses these issues, particularly because copylefted software is ever more widely embedded in devices that impose technical limitations on the user's freedom to change it.

破坏用户权利的技术措施。这些措施通常用这样的奥威尔式短语来描述，例如“数字版权管理”实际上意味着限制或彻底破坏用户的合法权利，或者“可信计算”实际上意味着向人们出售他们不信任的计算机。然而，这些措施在一个基本方面是相似的。他们都采用技术手段将版权法体系（版权持有者的权力是一般自由的有限例外）变成虚拟监狱，凡是未明确允许的事情都被完全禁止。这种“副版权”系统是在编写 GPLv2 之后很久就创建的——最初是通过美国和欧盟的立法，后来也通过其他司法管辖区的立法。该立法规定了严重的民事甚至刑事处罚以逃避这些限制（通常被恰当地称为“越狱设备”），即使这样做的目的是恢复用户的合法权利，而该技术错误地阻止了他们使用。GPLv2 没有解决使用技术措施收回 GPL 授予的权利的问题，因为这些措施在 1991 年不存在，并且与当时向用户交付软件的形式无关。GPLv3 解决了这些问题，特别是因为 copylefted 软件永远是更广泛地嵌入到对用户更改它的自由施加技术限制的设备中。

However, FSF always made a clear distinction to avoid conflating these "lock-down" measures with legitimate applications that give users control, as by enabling them to choose higher levels of system or data security within their networks, or by allowing them to protect the security of their communications using keys they can generate or copy to other devices for sending or receiving messages. Such technologies present no obstacles to software freedom and the goals of copyleft.

然而，FSF 始终明确区分以避免将这些“锁定”措施与赋予用户控制权的合法应用程序混为一谈，例如通过使他们能够在其网络中选择更高级别的系统或数据安全，或通过允许他们保护使用他们可以生成或复制到其他设备以发送或接收消息的密钥来确保他们的通信安全。这些技术对软件自由和 copyleft 的目标没有任何障碍。

The public GPLv3 drafting process sought to balance these positions of copyleft advocates with various disparate views of the larger Free-Software-using community. Ultimately, FSF compromised to the GPLv3 3 and GPLv3 6 provisions that, taken together, are a minimalist set of terms sufficient to protect the software freedom against the threat of invasive para-copyright.

公共 GPLv3 起草过程试图平衡 copyleft 倡导者的这些立场与更大的自由软件使用社区的各种不同观点。最终，FSF 妥协于 GPLv3 第3条和第6条，这些条款合在一起是一组足以保护软件自由免受侵犯性准版权威胁的极简主义条款。

The compromises made were ultimately quite reasonable. The primary one is embodied in GPLv3*§*6's "User Product" definition (see [9.9.2] in this tutorial for details). Additionally, some readers of early GPLv3 drafts seem to have assumed GPLv3 contained a blanket prohibition on DRM; but it does not. In fact, no part of GPLv3 forbids DRM regarding non-GPL'd works; rather, GPLv3 forbids the use of DRM specifically to lock-down restrictions on users' ability to install modified versions of the GPL'd software itself, but again, only with regard to User Products.

做出的妥协最终是相当合理的。第一个体现在 GPLv3 第6条的“用户产品”定义（详见本教程9.9.2）。此外，一些早期 GPLv3 草案的读者似乎认为 GPLv3 包含对 DRM 的全面禁止；但事实并非如此。事实上，GPLv3 的任何部分都没有禁止对非 GPL 作品进行 DRM；相反，GPLv3 禁止使用 DRM，专门用于锁定限制用户安装 GPL 软件本身的修改版本的能力，但同样仅限于用户产品。

GPLv3 §3: What Hath DMCA Wrought

9.6 GPLv3 第三款：DMCA做了什么

As discussed in [1.2.3] of this tutorial, 17 USC 1201 and related sections²⁸ prohibits users from circumventing technological measures that implement DRM. Since this is part of copyright law and the GPL is primarily a copyright license, and since what the DMCA calls "circumvention" is simply "modifying the software" under the GPL, GPLv3 must disclaim that such anti-circumvention provisions are not applicable to the GPLv3'd software. GPLv3 3 shields users from being subjected to liability under anti-circumvention law for exercising their rights under the GPL, so far as the GPL can do so.

如本教程 1.2.3 中所述，17 USC 1201 和相关部²⁸禁止用户规避实施 DRM 的技术措施。由于这是版权法的一部分，而 GPL 主要是版权许可，而 DMCA 所说的“规避”只是 GPL 下的“修改软件”，因此 GPLv3 必须否认此类反规避条款不适用于 GPLv3 的软件。GPLv3 第三款保护用户在 GPL 允许的范围内行使他们在 GPL 项下的权利时免于承担反规避法规定的责任。

First, GPLv3 3 1 declares that no GPL'd program is part of an effective technological protection measure, regardless of what the program does. Early drafts of GPLv3 3 1 referred directly to the DMCA, but the final version instead includes instead an international legal reference to anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any similar laws. Lawyers outside the USA worried that a USA statutory reference could be read as indicating a choice for application of USA law to the license as a whole. While the FSF did not necessarily agree with that view, the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since several national anticircumvention laws were (or will likely be) structured more similarly to the anticircumvention provisions of the DMCA in their implementation of WIPO. Furthermore, the addition of "or similar laws" provides an appropriate catch-all.

首先，GPLv3 第3条第1款声明任何 GPL 程序都不是有效技术保护措施的一部分，无论该程序做什么。GPLv3 第3条第1款的早期草案直接引用了 DMCA，但最终版本反而包含了对根据 1996 年 WIPO 条约和任何类似法律颁布的反规避法的国际法律引用。美国境外的律师担心，美国法定参考可能被解读为表明选择将美国法律应用于整个许可。尽管 FSF 不一定同意该观点，但 FSF 还是决定参考 WIPO 条约而不是 DMCA，因为一些国家的反规避法律在实施中已经（或可能）在结构上更类似于 DMCA 的反规避条款产权组织。此外，添加“或类似法律”提供了适当的包罗万象。

GPLv3 3 2 states precisely that a conveying party waives the power to forbid circumvention of techno- logical measures only to the extent that such circumvention is accomplished through the exercise of GPL rights in the conveyed work. GPLv3 3 2 makes clear that the referenced "legal rights" are specifically rights arising under anticircumvention law. and refers to both the conveying party's rights and to third party rights, as in some cases the conveying party will also be the party legally empowered to enforce or invoke rights arising under anticircumvention law.

GPLv3 第3条第2款明确指出，仅当这种规避是通过在所传送的作品中行使 GPL 权利来实现时，传送方才放弃禁止规避技术措施的权力。GPLv3 第3条第2款明确指出，所引用的“合法权利”是根据反规避法产生的具体权利。并且指的是转让方的权利和第三方的权利，因为在某些情况下，转让方也将是依法有权执行或援引反规避法规定的权利的一方。

These disclaimers by each licensor of any intention to use GPL'd software to stringently control access to other copyrighted works should effectively prevent any private or public parties from invoking DMCA-like laws against users who escape technical restriction measures implemented by GPL'd software.

每个许可方的这些关于使用 GPL 软件严格控制对其他受版权保护作品的访问的意图的免责声明应该有效地防止任何私人或公共团体援引类似 DMCA 的法律来对付那些逃避 GPL 软件实施的技术限制措施的用户。

GPLv3 §4: Verbatim Copying

9.7 GPLv3 第4条：逐字复制

GPLv3 4 is a revision of GPLv2 1 (as discussed in 3.2 of this tutorial). There are almost no changes to this section from the GPLv2 1, other than to use the new defined terms.

GPLv3 第4条是 GPLv2 第1条的修订版（如本教程 3.2 中所述）。除了使用新定义的术语外，GPLv2 第1条的这一部分几乎没有变化。

The only notable change, of "a fee" to "any price or no price", is in the first sentence of GPLv3 4 2. The GPLv2 1 1 means that the GPL permits one to charge money for the distribution of software. Despite efforts by copyleft advocates to explain this in GPLv2 itself and in other documents, there are evidently some people who still believe that GPLv2 allows charging for services but not for selling copies of software and/or that the GPL requires downloads to be gratis. Perhaps this is because GPLv2 referred to charging a "fee"; the term "fee" is generally used in connection with services.

唯一值得注意的变化是 GPLv3 第4条第2款的第一句中将“收费”改为“任何价格或无价格”。GPLv2 第1条第1款表示 GPL 允许对软件分发收费。尽管 copyleft 拥护者努力在 GPLv2 本身和其他文档中解释这一点，但显然仍有一些人认为 GPLv2 允许对服务收费但不允许销售软件副本和/或 GPL 要求免费下载。也许这是因为 GPLv2 提到了收取“费用”； “费用”一词通常与服务相关。

GPLv2's wording also referred to "the physical act of transferring." The intention was to distinguish charging for transfers from attempts to impose licensing fees on all third parties. "Physical" might be read, however, as suggesting "distribution in a physical medium only".

GPLv2 的措辞还提到了“传输的物理行为”。目的是将转让收费与向所有第三方征收许可费的尝试区分开来。然而，“物理”可能被解读为暗示“仅在物理介质中分发”。

To address these two issues, GPLv3 says "price" in place of "fee," and removes the term "physical." GPLv3 *§*4 has also been revised from its corresponding section in GPLv2 in light of the GPLv3 *§*7 (see § 9.9.3 in this tutorial for more). Specifically, a distributor of verbatim copies of the program's source code must obey any existing additional terms that apply to parts of the program pursuant to GPLv3 *§*7. In addition, the distributor is required to keep intact all license notices, including notices of such additional terms.

为了解决这两个问题，GPLv3 用“价格”代替“费用”，并删除了“物理”一词。GPLv3 第4条也根据 GPLv3 第7条对 GPLv2 中的相应部分进行了修订（有关更多信息，请参见本教程的第 9.9.3 节）。具体来说，程序源代码的逐字副本的分发者必须遵守根据 GPLv3 适用于程序部分的任何现有附加条款。此外，经销商必须完整保留所有许可通知，包括此类附加条款的通知。

Finally, there is no harm in explicitly pointing out what ought to be obvious: that those who convey GPL-covered software may offer commercial services for the support of that software.

最后，明确指出应该显而易见的事情并没有什么害处：那些传送 GPL 软件的人可能会提供商业服务来支持该软件。

GPLv3 §5: Modified Source

9.8 GPLv3 第5条：修改源代码

GPLv3 5 is the rewrite of GPLv2 2, which was discussed in 5.1 of this tutorial. This section discusses the changes found in GPLv3 5 compared to GPLv2 2.

GPLv3 第5条是 GPLv2 第5条的重写，在本教程的 5.1 中讨论过。本节讨论 GPLv3 第5条与 GPLv2 第2条相比的变化。

GPLv3 5(a) still requires modified versions be marked with "relevant date", but no longer says "the date of any change". The best practice is to include the date of the latest and/or most significant changes and who made those. Of course, compared to its GPLv2 2(a), GPLv3 5(a) slightly relaxes the requirements regarding notice of changes to the program. In particular, the modified files themselves need no longer be marked. This reduces administrative burdens for developers of modified versions of GPL'd software.

GPLv3 5(a) 仍然要求修改版本标明“relevant date”，但不再写“date of any change”。最佳做法是包括最新和/或最重要更改的日期以及进行这些更改的人员。当然，与其 GPLv2 2(a) 相比，GPLv3 5(a) 稍微放宽了对程序变更通知的要求。特别是，修改后的文件本身不再需要标记。这减轻了 GPL 软件修改版本开发人员的管理负担。

GPLv3 5(b) is a new but simple provision. GPLv3 5(b) requires that the license text itself must be unmodified (except as permitted by GPLv3 7; see 9.9.3 in this tutorial). Furthermore, it removes any perceived conflict between the words "keep intact all notices" in GPLv3 4, since operating under GPLv3 5 still includes all the requirements of GPLv3 4 by reference.

GPLv3 5(b) 是一项新的但简单的规定。GPLv3 5(b) 要求许可证文本本身必须未经修改（除非 GPLv3 7 允许；请参阅本教程中的 9.9.3）。此外，它消除了 GPLv3 第4条中“保持所有通知完整”一词之间的任何明显冲突，因为在 GPLv3 第5条下运行仍然通过引用包含 GPLv3 第4条的所有要求。

GPLv3 5(c) is the primary source-code-related copyleft provision of GPL. (The object-code-related copy- left provisions are in GPLv3 6, discussed in 9.9 of this tutorial). Compared to GPLv2 2(b), GPLv3 5(c) states that the GPL applies to the whole of the work. Such was stated already in GPLv2 2(b), in "in whole or in part", but this simplified wording makes it clear it applies to the entire covered work.

GPLv3 第5条 c 项是 GPL 中与源代码相关的主要 copyleft 条款。（与目标代码相关的版权条款在 GPLv3 第六款中，在本教程的 9.9 中讨论）。与 GPLv2 2(b) 相比，GPLv3 第5条 c 项声明 GPL 适用于整个作品。GPLv2 2(b) 中已经以“全部或部分”的形式说明了这一点，但这种简化的措辞清楚地表明它适用于整个涵盖的作品。

Another change in GPLv3 5(c) is the removal of the words "at no charge," which was often is misunder- stood upon na¨ıve reading of in GPLv2 (b) (as discussed in 5.1.2 of this tutorial).

GPLv3 第5条 c 项的另一个变化是删除了“免费”一词，这在天真阅读 GPLv2 (b) 时经常被误解（如本教程的 5.1.2 中所述）。

Note that of GPLv2 2's penultimate and ante-penultimate paragraphs are now handled adequately by the definitions in GPLv3 0 and as such, have no direct analogs in GPLv3.

请注意，GPLv2 第2条的倒数第二个和倒数第二个段落现在已由 GPLv3 第0条中的定义充分处理，因此，在 GPLv3 中没有直接类似物。

GPLv2 2's final paragraph, however, is reworded and expanded into the final paragraph of GPLv3 5, which now also covers issues related to copyright compilations (but not compilations into object code --- that's in the next section!). The intent and scope is the same as was intended in GPLv2.

然而，GPLv2 第2条的最后一段被改写并扩展到 GPLv3 第5条的最后一段，现在还涵盖了与版权编译相关的问题（但不包括编译成目标代码——那是在下一节！）。意图和范围与 GPLv2 中的意图和范围相同。

GPLv3 §6: Non-Source and Corresponding Source

9.9 GPLv3 第6条：非源代码和对应源代码

GPLv3 6 states the compliance obligations for distributing "non-source forms" of a program (which means any form other than CCS). As noted in 9.2, "object code" in GPLv3 is defined broadly to mean any non-source version of a work, and thus includes not only binaries or executables, but also obfuscated, mini- mized, compressed or otherwise non-preferred forms for modification. Thus, GPLv3 6 clarifies and revises GPLv2 3. Indeed, GPLv3 6's CCS requirement under closely parallels the provisions of GPLv2 3, with changes designed to make compliant provisioning easier under contemporary technological conditions. Dis- tributors of GPLv3'd object code must provide access to the corresponding source code, in one of four specified ways.

GPLv3 第6条规定了分发程序“非源代码形式”（即 CCS 以外的任何形式）的合规义务。如 9.2 中所述，GPLv3 中的“目标代码”被广泛定义为作品的任何非源版本，因此不仅包括二进制文件或可执行文件，还包括混淆、最小化、压缩或其他非首选形式修改。因此，GPLv3 第六款澄清并修订了 GPLv2 第三款。事实上，GPLv3 第六款的 CCS 要求与 GPLv2 第三款的规定非常相似，其变化旨在使合规供应在当代技术条件下更容易。GPLv3 目标代码的分发者必须以四种指定方式之一提供对相应源代码的访问。

GPLv3 6(a--b) now apply specifically to distribution of object code in a physical product. Physical products include embedded systems, as well as physical software distribution media such as CDs. As in GPLv2 3 (discussed in 5.2 of this tutorial), the distribution of object code may either be accompanied by the machine-readable source code, or it may be accompanied by a valid written offer to provide the machine-readable source code. However, unlike in GPLv2, that offer cannot be exercised by any third party; rather, only those "who possess the object code" can exercise the offer. (Note that this is a substantial narrowing of requirements of offer fulfillment, and is a wonderful counterexample to dispute claims that the GPLv3 has more requirements than GPLv2.)

GPLv3 6(a–b) 现在专门适用于在物理产品中分发目标代码。物理产品包括嵌入式系统，以及物理软件分发介质，例如 CD。与 GPLv2 第3条（在本教程的 5.2 中讨论）一样，目标代码的分发可能伴随着机器可读的源代码，或者它可能伴随着提供机器可读源代码的有效书面报价。但是，与 GPLv2 不同的是，任何第三方都不能行使该要约；相反，只有那些“拥有目标代码”的人才能行使要约。（请注意，这是对要约履行要求的实质性缩小，并且是对 GPLv3 比 GPLv2 有更多要求的说法提出异议的一个很好的反例。）

GPLv3 6(b) further revises the requirements for the written offer to provide source code. As before, the offer must remain valid for at least three years. In addition, even after three years, a distributor of a product containing GPL'd object code must offer to provide source code for as long as the distributor also continues to offer spare parts or customer support for the product model. This is a reasonable and appropriate requirement; a distributor should be prepared to provide source code if he or she is prepared to provide support for other aspects of a physical product.

GPLv3 第六款(b) 进一步修改了对书面报价提供源代码的要求。和以前一样，要约必须至少保持3年有效。此外，即使在3年后，包含 GPL 目标代码的产品的分销商也必须提供源代码，只要该分销商还继续为该产品模型提供备件或客户支持。这是一个合理且适当的要求；如果分销商准备为物理产品的其他方面提供支持，则他或她应该准备好提供源代码。

GPLv3 6(a--b) clarifies that the medium for software interchange on which the machine-readable source code is provided must be a durable physical medium. GPLv3 6(b)(2), however, permits a distributor to instead offer to provide source code from a network server instead, which is yet another example GPLv3 looser in its requirements than GPLv2 (see [5.2.2] for details).

GPLv3 第6条(a–b) 阐明了提供机器可读源代码的软件交换介质必须是耐用的物理介质。然而，GPLv3 第6条(b)(2) 允许发行商转而提议从网络服务器提供源代码，这是 GPLv3 的要求比 GPLv2 宽松的另一个例子（详见 5.2.2）。

GPLv3 6(c) gives narrower permission than GPLv2 3(c). The "pass along" option for GPLv3 6(c)(1) offers is now available only for individual distribution of object code; moreover, such individual distribution can occur only "occasionally and noncommercially." A distributor cannot comply with the GPL merely by making object code available on a publicly-accessible network server accompanied by a copy of the written offer to provide source code received from an upstream distributor.

GPLv3 第6条（c）提供比 GPLv2 第3条（c）更窄的许可。GPLv3 第6条（c）(1) 所述的“传递”选项现在仅适用于目标代码的单独分发；此外，这种个人分发只能“偶尔且非商业性地”发生。分销商不能仅通过在可公开访问的网络服务器上提供目标代码并附上书面报价的副本以提供从上游分销商收到的源代码来遵守 GPL。

GPLv3 6(d) revises and improves GPLv2 3's final paragraph. When object code is provided by offering access to copy the code from a designated place (such as by enabling electronic access to a network server), the distributor must merely offer equivalent access to copy the source code "in the same way through the same place". This wording also permits a distributor to offer a third party access to both object code and source code on a single network portal or web page, even though the access may include links to different physical servers. For example, a downstream distributor may provide a link to an upstream distributor's server and arrange with the operator of that server to keep the source code available for copying for as long as the downstream distributor enables access to the object code. Thus, the obligation remains on the party distributing object code to point prominently ("next to" the object code download) to the third-party source code provisioning server, and to ensure that this third-party server remains in operation for required period. This codifies formally the typical historical interpretation of GPLv2.

GPLv3 第6条(d) 修改并改进了 GPLv2 第3条的最后一段。当通过提供从指定位置复制代码的访问权限（例如通过启用对网络服务器的电子访问权限）来提供目标代码时，分销商必须仅提供等效的访问权限以“以相同方式通过相同位置”复制源代码 ”。该措辞还允许分销商在单个网络门户或网页上向第三方提供对目标代码和源代码的访问权限，即使该访问权限可能包含指向不同物理服务器的链接。例如，下游分销商可以提供到上游分销商服务器的链接，并与该服务器的运营商安排，只要下游分销商能够访问目标代码，就可以保持源代码可供复制。因此，分发目标代码的一方仍有义务在显着位置（“目标代码下载旁边”）指向第三方源代码供应服务器，并确保该第三方服务器在规定的时间内保持运行。这正式编纂了 GPLv2 的典型历史解释。

Furthermore, under GPLv3 6(d), distributors may charge for the conveyed object code; however, those who pay to obtain the object code must be given equivalent and gratis access to obtain the CCS. (If distributors convey the object code gratis, distributors must likewise make CCS available without charge.) Those who do not obtain the object code from that distributors (perhaps because they choose not to pay the fee for object code) are outside the scope of the provision; distributors are under no specific obligation to give CCS to someone who has not purchased an object code download under GPLv3 *§*6(d). (Note: this does not change nor impact any obligations under GPLv3 *§*6(b)(2); GPLv3 *§*6(d) is a wholly different provision.)

此外，根据 GPLv3 第6条(d)，分销商可以对传送的目标代码收费；但是，那些为获得目标代码而付费的人必须获得同等的免费访问权限才能获得 CCS。（如果分销商免费提供目标代码，分销商必须同样免费提供 CCS。）那些没有从分销商那里获得目标代码的人（可能是因为他们选择不支付目标代码的费用）不在范围之内。条款; 分销商没有特定义务向未根据 GPLv3 第六款(d) 购买目标代码下载的人提供 CCS。（注意：这不会改变或影响 GPLv3 第6条(b)(2) 下的任何义务；GPLv3 第6条(d) 是完全不同的规定。）

9.9.1 GPLv3 第6条e款：点对点共享网络

GPLv3 6(e) allows provision of CCS via another server when the binary or other non-source form is dis- tributed by peer-to-peer protocols such as BitTorrent. Here the requirement is only that each peer be effectively informed of the location of the source code on a server as above.

当二进制或其他非源代码形式通过对等协议（如 BitTorrent）分发时，GPLv3 第6条(e) 允许通过另一台服务器提供 CCS。这里的要求只是像上面那样有效地通知每个对等方源代码在服务器上的位置。

GPLv3 really did require this addition, even though it adds complexity to a key section of GPL. In particular, Decentralized peer-to-peer file sharing present a challenge to the unidirectional view of distribution that is implicit in GPLv2 and initial drafts of GPLv3. Identification of an upstream/downstream link in BitTorrent distribution is neither straightforward nor reasonable; such distribution is multidirectional, cooperative and (somewhat) anonymous. In peer-to-peer distribution systems, participants act both as transmitters and recipients of blocks of a particular file, but they perceive the experience merely as users and receivers, and not as distributors in any conventional sense. At any given moment of time, most peers will not have the complete file.

GPLv3 确实需要添加这一内容，尽管它增加了 GPL 关键部分的复杂性。特别是，去中心化点对点文件共享对 GPLv2 和 GPLv3 初始草案中隐含的单向分发视图提出了挑战。在 BitTorrent 分发中识别上游/下游链接既不简单也不合理；这种分布是多向的、合作的和（有点）匿名的。在点对点分发系统中，参与者既充当特定文件块的发送者又充当接收者，但他们仅将体验视为用户和接收者，而不是任何传统意义上的分发者。在任何给定的时刻，大多数同行都不会拥有完整的文件。

Meanwhile, GPLv3 6(d) permits distribution of a work in object code form over a network, provided that the distributor offers equivalent access to copy the Corresponding Source Code "in the same way through the same place". This wording might be interpreted to permit peer-to-peer distribution of binaries if they are packaged together with the CCS, but such packaging is impractical, for at least three reasons. First, even if the CCS is packaged with the object code, it will only be available to a non-seeding peer at the end of the distribution process, but the peer will already have been providing parts of the binary to others in the network. Second, in practice, peer-to-peer forms of transmission are poorly suited means for distributing CCS. In large distributions, packaging CCS with the object code may result in a substantial increase in file size and transmission time. Third, in current practice, CCS packages themselves tend not to be transmitted through BitTorrent --- owing to reduced demand -- thus, there generally will be too few participants downloading the same source package at the same time to enable effective seeding and distribution.

同时，GPLv3 第6条(d) 允许通过网络以目标代码形式分发作品，前提是分发者提供同等访问权限以“以相同方式通过相同位置”复制相应的源代码。如果二进制文件与 CCS 打包在一起，则该措辞可能被解释为允许二进制文件的点对点分发，但至少出于三个原因，这种打包是不切实际的。首先，即使 CCS 与目标代码打包在一起，它也只能在分发过程结束时供非播种对等方使用，但对等方已经向网络中的其他人提供了部分二进制文件。其次，在实践中，点对点传输形式不太适合分发 CCS。在大型发行版中，将 CCS 与目标代码打包在一起可能会导致文件大小和传输时间大幅增加。第三，在目前的实践中，CCS 包本身往往不通过 BitTorrent 传输——由于需求减少——因此，通常同时下载相同源包的参与者太少，无法实现有效的播种和分配。

GPLv3 6(e) addresses these issues. If a licensee conveys such a work of object code using peer-to-peer transmission, that licensee is in compliance with GPLv3 6 if the licensee informs other peers where the object code and its CCS are publicly available at no charge under subsection GPLv3 6(d). The CCS therefore need not be provided through the peer-to-peer system that was used for providing the binary.

GPLv3 第6条(e) 解决了这些问题。如果被许可人使用点对点传输传送此类目标代码作品，如果被许可人根据 GPLv3 第6条通知其他同行目标代码及其 CCS 是免费公开可用的，则该被许可人符合 GPLv3 第6条（ d). 因此，不需要通过用于提供二进制文件的对等系统来提供 CCS。

Second, GPLv3 9 also clarifies that ancillary propagation of a covered work that occurs as part of the process of peer-to-peer file transmission does not require acceptance, just as mere receipt and execution of the Program does not require acceptance. Such ancillary propagation is permitted without limitation or further obligation.

其次，GPLv3 第9条还阐明了作为点对点文件传输过程的一部分发生的涵盖作品的辅助传播不需要接受，就像仅仅接收和执行程序不需要接受一样。这种辅助传播是允许的，没有限制或进一步的义务。

9.9.2 User Products, Installation Information and Device Lock-Down

9.9.2 用户产品、安装信息和设备锁定

As discussed in 9.5 of this tutorial, GPLv3 seeks to thwart technical measures such as signature checks in hardware to prevent modification of GPL'd software on a device.

正如本教程 9.5 中所讨论的，GPLv3 试图阻止技术措施，例如硬件中的签名检查，以防止在设备上修改 GPL 软件。

To address this issue, GPLv3 6 requires that parties distributing object code provide recipients with the source code through certain means. When those distributors pass on the CCS, they are also required to pass on any information or data necessary to install modified software on the particular device that included it. (This strategy is not unlike that used in LGPLv2.1 to enable users to link proprietary programs to modified libraries.)

为了解决这个问题，GPLv3 第6条要求分发目标代码的各方通过某种方式向接收者提供源代码。当这些分销商传递 CCS 时，他们还需要传递在包含它的特定设备上安装修改后的软件所需的任何信息或数据。（此策略与 LGPLv2.1 中使用的策略没有什么不同，使用户能够将专有程序链接到修改后的库。）

User Products

用户产品

The scope of these requirements is narrow. GPLv3 6 introduces the concept of a "User Product", which includes devices that are sold for personal, family, or household use. Distributors are only required to provide Installation Information when they convey object code in a User Product.

这些要求的范围很窄。GPLv3 第6条引入了“用户产品”的概念，其中包括为个人、家庭或家庭使用而销售的设备。当经销商在用户产品中传送目标代码时，他们只需要提供安装信息。

In brief, the right to convey object code in a defined class of "User Products," under certain circumstances, depends on providing whatever information is required to enable a recipient to replace the object code with a functioning modified version.

简而言之，在某些情况下，在定义的“用户产品”类别中传送目标代码的权利取决于提供使接收者能够使用功能修改版本替换目标代码所需的任何信息。

This was a compromise that was difficult for the FSF to agree to during the GPLv3 drafting process. However, companies and governments that use specialized or enterprise-level computer facilities reported that they actually want their systems not to be under their own control. Rather than agreeing to this as a concession, or bowing to pressure, they ask for this as a preference. It is not clear that the GPL should interfere here, since the main problem lies elsewhere.

这是 FSF 在 GPLv3 起草过程中难以同意的妥协。然而，使用专业或企业级计算机设施的公司和政府报告称，他们实际上希望自己的系统不受自己的控制。他们没有将此作为让步或屈服于压力而同意，而是将此视为一种偏好。不清楚 GPL 是否应该干预这里，因为主要问题在别处。尽管在任何情况下对修改施加技术障碍都是错误的，但受限设备在当今最实际关注的领域属于用户产品定义。大多数（如果不是全部）运行受 GPL 保护的程序的技术限制设备都是消费电子设备。此外，制造商和这些用户之间的影响力悬殊，使得用户很难以其微弱和无组织的市场力量拒绝技术限制。即使仅限于用户产品，该条款也解决了根本问题。

While imposing technical barriers to modification is wrong regardless of circumstances, the areas where restricted devices are of the greatest practical concern today fall within the User Product definition. Most, if not all, technically-restricted devices running GPL-covered programs are consumer electronics devices. Moreover, the disparity in clout between the manufacturers and these users makes it difficult for the users to reject technical restrictions through their weak and unorganized market power. Even limited to User Products, this provision addresses the fundamental problem.

无论情况如何，施加技术障碍都是错误的，但是当今，限制设备的实际关注的领域属于用户产品定义。大多数（如果不是全部）运行GPL程序的技术限制设备是消费电子设备。此外，制造商和这些用户之间的影响力差异使用户难以通过薄弱且无组织的市场能力拒绝技术限制。即使仅限于用户产品，此规定也解决了基本问题。

The core of the User Product definition is a subdefinition of "consumer product" adapted from the Magnuson-Moss Warranty Act, a federal consumer protection law in the USA found in 15 USC 2301: "any tangible personal property which is normally used for personal, family, or household purposes." The USA has had three decades of experience of liberal judicial and administrative interpretation of this definition in a manner favorable to consumer rights.[^6^] Ideally, this body of interpretation[^7^] will guide interpretation of the consumer product subdefinition in GPLv3 6, and this will hopefully provide a degree of legal certainty advantageous to device manufacturers and downstream licensees alike.

用户产品定义的核心是根据美国联邦消费者保护法 Magnuson-Moss 保修法改编的“消费品”的子定义，该法案载于 15 USC 2301：“任何通常用于个人、家庭或家庭目的。” 美国在以有利于消费者权利的方式对此定义进行自由司法和行政解释已有 30 年的经验²⁹。理想情况下，该解释体系³⁰将指导对 GPLv3 6 中消费品子定义的解释，并且这有望为设备制造商和下游被许可人提供一定程度的法律确定性。

One well-established interpretive principle under Magnuson-Moss is that ambiguities are resolved in favor of coverage. That is, in cases where it is not clear whether a product falls under the definition of consumer product, the product will be treated as a consumer product.³¹ Moreover, for a given product, "normally used" is understood to refer to the typical use of that type of product, rather than a particular use by a particular buyer. Products that are commonly used for personal as well as commercial purposes are consumer products, even if the person invoking rights is a commercial entity intending to use the product for commercial purposes.³² Even a small amount of "normal" personal use is enough to cause an entire product line to be treated as a consumer product under Magnuson-Moss.³³

Magnuson-Moss 下的一个公认的解释原则是解决歧义以支持覆盖。也就是说，在不清楚产品是否属于消费品定义的情况下，该产品将被视为消费品³¹。此外，对于给定的产品，“通常使用”被理解为是指该类型产品的典型用途，而不是特定用途一个特定的买家。通常用于个人和商业目的的产品是消费品，即使调用权利的人是打算将产品用于商业目的的商业实体³²。即使是少量的“正常”个人使用也足够了使整个产品线在 Magnuson-Moss 下被视为消费品³³。

However, Magnuson-Moss is not a perfect fit because in the area of components of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive. Depending on how such components are manufac- tured or sold, they may or may not be considered Magnuson-Moss consumer products.³⁴Therefore, GPLv3 defines User Products as a superset of consumer products that also includes "anything designed or sold for incorporation into a dwelling."

然而，Magnuson-Moss 并不是一个完美的选择，因为在住宅的组成部分，Magnuson-Moss 下的固定解释是包容性不足的。根据此类组件的制造或销售方式，它们可能被视为也可能不被视为 Magnuson-Moss 消费产品³⁴。因此，GPLv3 将用户产品定义为消费产品的超集，其中还包括“任何为公司设计或销售的产品” 住处。”

Thus, the three sentences in the center of GPLv3's User Product definition encapsulate the judicial and administrative principles established over the past three decades in the USA concerning the Magnuson-Moss consumer product definition. First, it states that doubtful cases are resolved in favor of coverage under the definition. Second, it indicates that the words "normally used" in the consumer product definition refer to a typical or common use of a class of product, and not the status of a particular user or expected or actual uses by a particular user. Third, it clearly states that the existence of substantial non-consumer uses of a product does not negate a determination that it is a consumer product, unless such non-consumer uses represent the only significant mode of use of that product.

因此，GPLv3 用户产品定义中心的三句话概括了美国过去三十年建立的关于 Magnuson-Moss 消费产品定义的司法和行政原则。首先，它声明疑似案件的解决有利于定义下的覆盖范围。其次，它表明消费品定义中的“通常使用”一词是指一类产品的典型或普遍使用，而不是特定用户的状态或特定用户的预期或实际使用。第三，它明确指出，产品的大量非消费者使用的存在并不能否定它是消费品的决定，除非这种非消费者使用代表了该产品的唯一重要使用方式。

It should be clear from these added sentences that it is the general mode of use of a product that determines objectively whether or not it is a consumer product. One could not escape the effects of the User Products provisions by labeling what is demonstrably a consumer product in ways that suggest it is "for professionals", for example.

从这些增加的句子中应该清楚，是产品的一般使用方式客观地决定了它是否是消费品。例如，通过以表明它是“专业人士”的方式标记明显是消费品的东西，无法逃避用户产品条款的影响。

Installation Information

安装信息

With the User Products definition complete, the "Installation Information" definition uses that to define what those receiving object code inside a User Product must receive.

随着用户产品定义的完成，“安装信息”定义使用它来定义用户产品中那些接收目标代码必须接收的内容。

Installation Information is information that is "required to install and execute modified versions of a covered work . . . from a modified version of its" CCS, in the same User Product for which the covered work is conveyed. GPLv3 provides guidance concerning how much information must be provided: it "must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made." For example, the information provided would be insufficient if it enabled a modified version to run only in a disabled fashion, solely because of the fact of modification (regardless of the actual nature of the modification). The information need not consist of cryptographic keys; Installation Information may be "any methods, procedures, authorization keys, or other information". Note that GPLv3 does not define "continued functioning" further. However, GPLv3 does provide some additional guidance concerning the scope of GPLv3-compliant action or inaction that distributors of technically-restricted User Products can take with respect to a downstream recipient who replaces the conveyed object code with a modified version. First of all, GPLv3 makes clear that GPLv3 implies no obligation "to continue to provide support service, warranty, or updates" for such a work.

安装信息是“安装和执行涵盖作品的修改版本所需的信息。……来自其修改版本”。CSS，在传达涵盖工作的同一用户产品中。GPLv3 提供了关于必须提供多少信息的指南：它“必须足以确保修改后的目标代码的继续运行在任何情况下都不会仅仅因为进行了修改而受到阻止或干扰。” 例如，如果仅仅因为修改的事实（不管修改的实际性质）使修改后的版本仅以禁用方式运行，那么所提供的信息将是不充分的。信息不需要包含密钥；安装信息可以是“任何方法、程序、授权密钥或其他信息”。请注意，GPLv3 没有进一步定义“持续运行”。但是，GPLv3 确实提供了一些额外的指导，涉及技术受限用户产品的分销商可以针对下游接收者采取的符合 GPLv3 的行动或不行动的范围，后者将所传送的目标代码替换为修改后的版本。首先，GPLv3 明确了 GPLv3 意味着不为此类作品“继续提供支持服务、保证或更新”的义务。

Second, most technically-restricted User Products are designed to communicate across networks. It is important for both users and network providers to know when denial of network access to devices running modified versions becomes a GPL violation. GPLv3 permits denial of access in two cases: "when the modification itself materially and adversely affects the operation of the network," and when the modification itself "violates the rules and protocols for communication across the network". The second case is deliberately drawn in general terms, and it serves as a foundation for reasonable enforcement policies that respect recipients' right to modify while recognizing the legitimate interests of network providers.

其次，大多数受技术限制的用户产品旨在跨网络通信。对于用户和网络提供商来说，了解拒绝对运行修改版本的设备进行网络访问何时会违反 GPL 非常重要。GPLv3 允许在两种情况下拒绝访问：“当修改本身对网络的运行产生重大不利影响时”，以及当修改本身“违反了网络通信的规则和协议时”。第二种情况是故意用笼统的术语来描述的，它是合理执行政策的基础，这些政策尊重接收者的修改权，同时承认网络提供者的合法利益。

Note that GPLv3 permits the practice of conveying object code in a mode not practically susceptible to modification by any party, such as code burned in ROM or embedded in silicon. The goal of the Installation Information requirement is to ensure the downstream licensee receives the real right to modify when the device manufacturer or some other party retains that right. Accordingly, GPLv3 6's ante-penultimate paragraph states that the requirement to provide Installation Information "does not apply if neither you nor any third party retains the ability to install modified object code on the User Product".

请注意，GPLv3 允许以一种实际上不易被任何一方修改的模式传送目标代码，例如在 ROM 中烧录或嵌入硅中的代码。安装信息要求的目标是确保下游被许可人在设备制造商或某些其他方保留修改权时获得真正的修改权。因此，GPLv3 第六款的倒数第二段规定，提供安装信息的要求“不适用，如果您或任何第三方都没有保留在用户产品上安装修改后的目标代码的能力”。

Finally, GPLv3 第六款makes it clear that there is also no requirement to provide warranty or support for the User Product itself.

9.9.3 GPLv3 §7: Additional Permissions

9.9.3 GPLv3 第7条：附加权限

The GPL is a statement of permissions, some of which have conditions. Additional terms --- terms that supplement those of the GPL --- may come to be placed on, or removed from, GPL-covered code in certain common ways. Copyleft licensing theorists have generally called those added terms "additional permissions" if they grant exceptions from the conditions of the GPL, and "additional requirements" if they add conditions to the basic permissions of the GPL. The treatment of additional permissions and additional requirements under GPLv3 is necessarily asymmetrical, because they do not raise the same interpretive issues; in particular, additional requirements, if allowed without careful limitation, could transform a GPL'd program into a non- free one.

GPL 是一种权限声明，其中一些是有条件的。附加条款——补充 GPL 条款的条款——可能会以某些常见的方式添加到 GPL 代码中，或从中删除。Copyleft 许可理论家通常将这些添加的条款称为“附加许可”，如果他们授予 GPL 条件的例外，如果他们将条件添加到 GPL 的基本许可，则称为“附加要求”。GPLv3 下对额外许可和额外要求的处理必然是不对称的，因为它们不会引发相同的解释问题；特别是，如果在没有仔细限制的情况下允许附加要求，可能会将 GPL 程序转换为非自由程序。

Due to the latter fear, historically, GPLv2 did not permit any additional requirements. However, over time, many copyright holders generally tolerated certain types of benign additional requirements merely through a "failure to enforce" estoppel-esque scenario. Therefore, GPLv3 allows for some specific limited requirement variations that GPLv2 technically prohibits.

由于后一种恐惧，从历史上看，GPLv2 不允许任何额外的要求。然而，随着时间的推移，许多版权持有者通常仅仅通过“未能执行”禁止反言式的场景来容忍某些类型的良性附加要求。因此，GPLv3 允许 GPLv2 在技术上禁止的一些特定的有限要求变化。

With these principles in the background, GPLv3 *§*7 answers the following questions:

在这些原则的背景下，GPLv3 第7条回答了以下问题：

How does the presence of additional terms on all or part of a GPL'd program affect users' rights?
GPL 程序的全部或部分附加条款的存在如何影响用户的权利？
When and how may a licensee add terms to code being distributed under the GPL?
被许可人何时以及如何向根据 GPL 分发的代码添加条款？
When may a licensee remove additional terms?
被许可人何时可以删除附加条款？

Additional permissions present the easier case. Since the mid-1990s, permissive exceptions often appeared alongside GPLv2 to allow combination with certain non-free code. Typically, downstream stream recipients could remove those exceptions and operate under pure GPLv2. Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2, and it permits relicensing under the GPL.

附加权限呈现更简单的情况。自 20 世纪 90 年代中期以来，宽容例外经常与 GPLv2 一起出现，以允许与某些非自由代码结合。通常，下游流接收者可以删除这些例外并在纯 GPLv2 下运行。同样，LGPLv2.1 本质上是 GPLv2 的许可变体，它允许在 GPL 下重新授权。

These practices are now generalized via GPLv3 7. A licensee may remove any additional permission from a covered work, whether it was placed by the original author or by an upstream distributor. A licensee may also add any kind of additional permission to any part of a work for which the licensee has, or can give, appropriate copyright permission. For example, if the licensee has written that part, the licensee is the copyright holder for that part and can therefore give additional permissions that are applicable to it. Alternatively, the part may have been written by someone else and licensed, with the additional permissions, to that licensee. Any additional permissions on that part are, in turn, removable by downstream recipients. As GPLv3 7 1 explains, the effect of an additional permission depends on whether the permission applies to the whole work or a part.

这些做法现在通过 GPLv3 第7条得到推广。被许可人可以从涵盖的作品中删除任何额外的许可，无论它是由原作者还是由上游分发者引入的。被许可人还可以对作品的任何部分添加任何类型的额外许可，而被许可人已对其拥有或可以给予适当的版权许可。例如，如果被许可人编写了该部分，则被许可人是该部分的版权所有者，因此可以授予适用于该部分的额外许可。或者，该部分可能是由其他人编写的，并以附加许可的形式许可给该被许可人。反过来，下游接收者可以删除该部分的任何其他权限。正如 GPLv3 第7条第1款所解释的那样，附加许可的效果取决于该许可是适用于整个作品还是部分作品。

Indeed, LGPLv3 is itself simply a list of additional permissions supplementing the terms of GPLv3. GPLv3 7 has thus provided the basis for recasting a formally complex license as an elegant set of added terms, without changing any of the fundamental features of the existing LGPL. LGPLv3 is thus a model for developers wishing to license their works under the GPL with permissive exceptions. The removability of additional permissions under GPLv3 7 does not alter any existing behavior of the LGPL since the LGPL has always allowed relicensing under the ordinary GPL.

事实上，LGPLv3 本身只是一个补充 GPLv3 条款的附加许可列表。因此，GPLv3 第7条为将形式上复杂的许可证重铸为一组优雅的附加条款提供了基础，而无需改变现有 LGPL 的任何基本特征。因此，LGPLv3 是希望根据 GPL 许可其作品的开发人员的模型，但有例外。GPLv3 第7条下附加许可的可移除性不会改变 LGPL 的任何现有行为，因为 LGPL 始终允许在普通 GPL 下重新许可。

GPLv3 §7: Understanding License Compatibility

9.10 GPLv3 第7条：理解许可证兼容性

A challenge that faced the Free Software community heavily through out the early 2000s was the proliferation of incompatible Free Software licenses. Of course, the GPL cannot possibly be compatible with all such licenses. However, GPLv3 contains provisions that are designed to reduce license incompatibility by making it easier for developers to combine code carrying non-GPL terms with GPL'd code.

在 2000 年代初期，自由软件社区面临的一个严峻挑战是不兼容的自由软件许可证的激增。当然，GPL 不可能兼容所有这些许可证。但是，GPLv3 包含旨在通过使开发人员更容易将带有非 GPL 条款的代码与 GPL 代码结合起来来减少许可证不兼容性的条款。

This license compatibility issue arises for three reasons. First, the GPL is a strong copyleft license, requiring modified versions to be distributed under the GPL. Second, the GPL states that no further restrictions may be placed on the rights of recipients. Third, all other software freedom respecting licenses in common use contain certain requirements, many of which are not conditions made by the GPL. Thus, when GPL'd code is modified by combination with code covered by another formal license that specifies other requirements, and that modified code is then distributed to others, the freedom of recipients may be burdened by additional requirements in violation of the GPL. It can be seen that additional permissions in other licenses do not raise any problems of license compatibility.

出现此许可证兼容性问题的原因有以下三个。首先，GPL 是一个强大的 copyleft 许可证，要求在 GPL 下分发修改后的版本。其次，GPL 声明不能对接收者的权利施加进一步的限制。第三，所有其他尊重通用许可证的软件自由都包含某些要求，其中许多不是 GPL 规定的条件。因此，当 GPL 代码与另一个指定其他要求的正式许可证所涵盖的代码相结合进行修改，然后将修改后的代码分发给其他人时，接收者的自由可能会受到违反 GPL 的额外要求的负担。可以看出，其他许可证中的附加权限不会引起任何许可证兼容性问题。

GPLv3 took a new approach to the issue of combining GPL'd code with code governed by the terms of other software freedom licenses. Traditional GPLv2 license compatibility theory (which was not explicitly stated in GPLv2 itself, but treated as a license interpretation matter by the FSF) held that GPLv2 allowed such combinations only if the non-GPL licensing terms permitted distribution under the GPL and imposed no restrictions on the code that were not also imposed by the GPL. In practice, the FSF historically supplemented that policy with a structure of exceptions for certain kinds of combinations.

GPLv3 采取了一种新方法来解决将 GPL 代码与受其他软件自由许可条款约束的代码相结合的问题。传统的 GPLv2 许可兼容性理论（GPLv2 本身并未明确说明，但被 FSF 视为许可解释事项）认为 GPLv2 仅在非 GPL 许可条款允许在 GPL 下分发并且不对任何限制施加限制的情况下才允许此类组合 GPL 也没有强加的代码。在实践中，FSF 历来为该政策补充了针对某些类型组合的例外结构。

GPLv3 7 implements a more explicit policy on license compatibility. It formalizes the circumstances under which a licensee may release a covered work that includes an added part carrying non-GPL terms. GPLv3 7 distinguish between terms that provide additional permissions, and terms that place additional requirements on the code, relative to the permissions and requirements established by applying the GPL to the code.

GPLv3 第7条在许可证兼容性方面实施了更明确的政策。它正式规定了被许可人可以发布包含带有非 GPL 条款的附加部分的涵盖作品的情况。GPLv3 第7条区分提供额外权限的条款和对代码提出额外要求的条款，相对于通过将 GPL 应用于代码而建立的权限和要求。

As discussed in the previous section of this tutorial, GPLv3 7 first and foremost explicitly allows added parts covered by terms with additional permissions to be combined with GPL'd code. This codifies the existing practice of regarding such licensing terms as compatible with the GPL. A downstream user of a combined GPL'd work who modifies such an added part may remove the additional permissions, in which case the broader permissions no longer apply to the modified version, and only the terms of the GPL apply to it.

正如本教程上一节中所讨论的，GPLv3 第7条首先明确允许将具有附加权限的条款所涵盖的附加部分与 GPL 代码相结合。这规范了将此类许可条款视为与 GPL 兼容的现有做法。修改此类添加部分的组合 GPL 作品的下游用户可以删除额外的权限，在这种情况下，更广泛的权限不再适用于修改后的版本，只有 GPL 的条款适用于它。

In its treatment of terms that impose additional requirements, GPLv3 7 extends the range of licensing terms with which the GPL is compatible. An added part carrying additional requirements may be combined with GPL'd code, but only if those requirements belong to a set enumerated in GPLv3 7. There are, of course, limits on the acceptable additional requirements, which ensures that enhanced license compatibility does not defeat the broader software-freedom-defending terms of the GPL. Unlike terms that grant additional permissions, terms that impose additional requirements cannot be removed by a downstream user of the combined GPL'd work, because only in the pathological case ³⁵ would a user have the right to do so.

在处理附加要求的条款时，GPLv3 第7条扩展了与 GPL 兼容的许可条款范围。带有附加要求的附加部分可以与 GPL 代码组合，但前提是这些要求属于 GPLv3 第7条中列举的集合。当然，可接受的附加要求是有限制的，这确保增强的许可证兼容性不会击败 GPL 更广泛的软件自由捍卫条款。与授予额外权限的条款不同，施加额外要求的条款不能被组合 GPL 作品的下游用户删除，因为只有在病态情况下 ³⁵ 用户才有权这样做。

In general, the types of additional requirements were those terms in regular use by other non-copyleft Free Software licenses that the FSF found unobjectionable. The specific details GPLv3's permitted additional requirements hat GPLv3 are as follows:

一般来说，附加要求的类型是 FSF 认为无异议的其他非 copyleft 自由软件许可证经常使用的条款。GPLv3允许的附加要求 GPLv3的具体细节如下：

7(a): This provision allows alternative "disclaimer of warranty" forms. Copyright holders can disclaim warranty or limit liability differently from the terms as provided under GPLv3 15--16. Drafters included this permission to advance the internationalization goals of GPLv3; international treaties lack adequate harmonization for laws regarding warranty and disclaimer.

7(b): This provision allows alternative requirements for preservation of appropriate legal notices. GPLv3 permits additional requirements regarding preservation of legal notices, including on output from exe- cution of covered works. Preserved information can include information about the origins of the code or alterations of the code.

7(b)：本条款允许对适当的法律声明进行保存的替代要求。GPLv3 允许关于保存法律声明的额外要求，包括关于执行涵盖作品的输出。保留的信息可以包括有关代码来源或代码更改的信息。

7(c): This provision allows prohibition of misrepresentation of original material. The provision yields com- patibility with non-copyleft Free Software licenses that require marking of modified versions in "rea- sonable"ways which differ from GPL's own precise marking requirements.

7(c)：该条款允许禁止对原始材料进行虚假陈述。该条款与非 copyleft 自由软件许可证兼容，这些许可证要求以“合理”的方式标记修改版本，这与 GPL 自己的精确标记要求不同。

7(d): This provision allows limitations on the use of names of licensor for publicity purposes. This provision also yields additional compatibility with non-copyleft Free Software licenses that prohibit the use of the licensor's name on unmodified versions (or other prohibitions on advertising rights). The third clause of the 3-Clause BSD License, for example, long considered de-facto compatible with GPLv2 anyway, is via this clause unequivocally compatible with GPLv3. However, this clause does not make GPL compatible with the old BSD advertising clause that the FSF long ago identified as problematic.

7(d)：该条款允许限制出于宣传目的使用许可方名称。该规定还与非 copyleft 自由软件许可证产生了额外的兼容性，这些许可证禁止在未修改的版本上使用许可方的名称（或其他广告权禁令）。例如，3 条款 BSD 许可证的第3条，长期以来一直被认为事实上与 GPLv2 兼容，通过该条款明确兼容 GPLv3。然而，该条款并没有使 GPL 与 FSF 很久以前认为有问题的旧 BSD 广告条款兼容。

7(f): This provision allows indemnification requirements of authors and licensors. The FSF specifically designed this clause to achieve GPLv3 compatibility for the Apache Software License, Version 2.0.

7(f)：该条款允许作者和许可人提出赔偿要求。FSF 专门设计了此条款以实现 Apache 软件许可证版本 2.0 的 GPLv3 兼容性。

During the GPLv3 drafting process, some questioned the necessity of GPLv3 7; those critics suggested that it creates complexity that did not previously exist. However, by the time of GPLv3's drafting, many existing GPLv2'd software packages already combined with various non-copylefted Free Software licensed code that carried such additional terms. Therefore, GPLv3 7 is rationalized existing practices of those package authors and modifiers, since it sets clear guidelines regarding the removal and addition of these additional terms. With its carefully limited list of allowed additional requirements, GPLv3 7 accomplishes additional objectives as well, since it permits the expansion of the base of code available for GPL developers, while also encouraging useful experimentation with requirements the GPLv3 does not include by default.

在 GPLv3 起草过程中，有人质疑 GPLv3 第7条的必要性；这些批评者认为，它造成了以前不存在的复杂性。然而，在 GPLv3 起草之时，许多现有的 GPLv2 软件包已经与各种非 copyleft 自由软件许可代码相结合，这些代码带有此类附加条款。因此，GPLv3 第7条合理化了这些软件包作者和修改者的现有做法，因为它为删除和添加这些附加条款设定了明确的指导方针。GPLv3 第7条仔细限制了允许的附加要求列表，还实现了其他目标，因为它允许扩展 GPL 开发人员可用的代码基础，同时还鼓励对 GPLv3 默认不包含的要求进行有用的实验。

However, any other non-permissive additional terms apart from those stated above are considered "fur- ther" restrictions which GPLv3 10 prohibits. Furthermore, as a compliance matter, if you add additional terms in accordance with GPLv3 7, you must ensure that the terms are placed in the relevant source files or provide a conspicuous notice about where to find the additional terms.

但是，除上述条款之外的任何其他非许可附加条款均被视为 GPLv3 第10条禁止的“进一步”限制。此外，作为合规性事项，如果您根据 GPLv3 第7条添加附加条款，您必须确保将这些条款放在相关源文件中或提供关于在哪里可以找到附加条款的显着通知。

GPLv3 §8: A Lighter Termination

9.11 GPLv3 第8条：更轻松的终止

GPLv2 provided for automatic termination of the rights of a person who copied, modified, sublicensed, or distributed a work in violation of the license. Automatic termination can be too harsh for those who have committed an inadvertent violation, particularly in cases involving distribution of large collections of software having numerous copyright holders. A violator who resumes compliance with GPLv2 technically needs to obtain forgiveness from all copyright holders, and even contacting them all might be impossible.

GPLv3 8 now grants opportunities for provisional and permanent reinstatement of rights. The termi- nation procedure provides a limited opportunity to cure license violations. If a licensee has committed a first-time violation of the GPL with respect to a given copyright holder, but the licensee cures the violation within 30 days following receipt of notice of the violation, then any of the licensee's GPL rights that have been terminated by the copyright holder are "automatically reinstated".

Finally, if a licensee violates the GPL, a contributor may terminate any patent licenses that it granted under GPLv3 *§*11, in addition to any copyright permissions the contributor granted to the licensee.

最后，如果被许可人违反 GPL，贡献者可以终止其根据 GPLv3 第11条授予的任何专利许可，以及贡献者授予被许可人的任何版权许可。

GPLv3 §9: Acceptance

9.12 GPLv3 第9条：接受

GPLv3 9 means what it says: mere receipt or execution of code neither requires nor signifies contractual acceptance under the GPL. Speaking more broadly, GPLv3 is intentionally structured as a unilateral grant of copyright permissions, the basic operation of which exists outside of any law of contract. Whether and when a contractual relationship is formed between licensor and licensee under local law do not necessarily matter to the working of the license.

代码既不需要也不表示 GPL 下的合同接受。更广泛地说，GPLv3 被有意构建为单方面授予版权许可，其基本操作存在于任何合同法之外。根据当地法律，许可人和被许可人之间是否以及何时形成合同关系不一定对许可的运作有影响。

GPLv3 §10: Explicit Downstream License

9.13 GPLv3 第10条：显式下游许可

GPLv3 10 is a generally straightforward section that ensures that everyone downstream receives licenses from all copyright holders. Each time you redistribute a GPL'd program, the recipient automatically receives a license, under the terms of GPL, from every upstream licensor whose copyrighted material is present in the work you redistribute. You could think of this as creating a three-dimensional rather than linear flow of license rights. Every recipient of the work is "in privity," or is directly receiving a license from every licensor. This mechanism of automatic downstream licensing is central to copyleft's function. Every licensor in- dependently grants licenses, and every licensor independently terminates the license on violation. Parties further downstream from the infringing party remain licensed, so long as they don't themselves commit infringing actions. Their licenses come directly from all the upstream copyright holders, and are not depen- dent on the license of the breaching party who distributed to them. For the same reason, an infringer who acquires another copy of the program has not thereby acquired any new license rights: once any upstream licensor of that program has terminated the license for breach of its terms, no new automatic license will issue to the recipient just by acquiring another copy³⁶

GPLv3 第10条通常是一个简单明了的部分，可确保下游的每个人都从所有版权所有者那里获得许可。每次您重新分发 GPL 程序时，接收者都会根据 GPL 的条款自动从每个上游许可人那里收到一份许可，其受版权保护的材料出现在您重新分配的工作。您可以将其视为创建三维而非线性的许可权流。作品的每个接收者都是“私密的”，或者直接从每个许可人那里获得许可。这种自动下游许可机制是 Copyleft 功能的核心。每个许可人独立地授予许可，并且每个许可人在违反时独立地终止许可。侵权方下游的各方仍然获得许可，只要他们自己不实施侵权行为。他们的许可直接来自所有上游版权所有者，不依赖于向他们分发的违约方的许可。出于同样的原因，获得该程序的另一个副本的侵权者并没有因此获得任何新的许可权：一旦该程序的任何上游许可人因违反其条款而终止许可，则不会有新的自动许可只需获取另一份副本即可发送给收件人³⁶。

Meanwhile, one specific addition in GPLv3 here in GPLv3 10 deserves special mention. Specifically, GPLv3 removed the words "at no charge" from GPLv2 2(b) (which, BTW, became GPLv3 5(b)) because it contributed to a misconception that the GPL did not permit charging for distribution of copies. The purpose of the "at no charge" wording was to prevent attempts to collect royalties from third parties. The removal of these words created the danger that the imposition of licensing fees would no longer be seen as a license violation. Therefore, GPLv3 10 adds a new explicit prohibition on imposition of licensing fees or royalties. This section is an appropriate place for such a clause, since it is a specific consequence of the general requirement that no further restrictions be imposed on downstream recipients of GPL-covered code.

同时，GPLv3 第10条中 GPLv3 中的一个特定添加值得特别提及。具体来说，GPLv3 从 GPLv2 2(b)（顺便说一句，后来变成了 GPLv3 5(b)）中删除了“免费”一词，因为它造成了一种误解，即 GPL 不允许对副本的分发收费。“不收费”措辞的目的是防止试图从第三方收取版税。删除这些词会产生危险，即征收许可费将不再被视为违反许可。因此，GPLv3 第10条新增了一项明确禁止征收许可费或版税的规定。本节是此类条款的适当位置，因为它是一般要求的特定结果，即不对 GPL 代码的下游接收者施加进一步的限制。

GPLv3 §11: Explicit Patent Licensing

9.14 GPLv3 第11条：显式专利许可

Software patenting is a harmful and unjust policy, and should be abolished; recent experience makes this all the more evident. Since many countries grant patents that can apply to and prohibit software packages, in various guises and to varying degrees, GPLv3 seeks to protect the users of GPL-covered programs from those patents, while at the same time making it feasible for patent holders to contribute to and distribute GPL-covered programs as long as they do not attack the users of those programs.

软件专利是一种有害和不公正的政策，应该废除；最近的经验使这一点更加明显。由于许多国家/地区以各种形式和不同程度授予可以应用于和禁止软件包的专利，因此 GPLv3 旨在保护受 GPL 保护的程序的用户免受这些专利的影响，同时使专利持有人能够贡献自己的力量分发 GPL 程序，只要它们不攻击这些程序的用户。

It is generally understood that GPLv2 implies some limits on a licensee's power to assert patent claims against the use of GPL-covered works. However, the patent licensing practice that GPLv2 7 (corresponding to GPLv3 12) is designed to prevent is only one of several ways in which software patents threaten to make free programs non-free and to prevent users from exercising their rights under the GPL. GPLv3 takes a more comprehensive approach to combating the danger of patents.

人们普遍认为，GPLv2 意味着对被许可人针对 GPL 保护作品的使用提出专利索赔的权力的一些限制。然而，GPLv2 第7条（对应于 GPLv3 第12条）旨在防止的专利许可实践只是软件专利威胁使免费程序成为非自由软件并阻止用户行使 GPL 下的权利的几种方式之一。GPLv3 采用更全面的方法来对抗专利的危险。

GPLv2 7 has seen some success in deterring conduct that would otherwise result in denial of full downstream enjoyment of GPL rights, and thus it is preserved in GPLv3 12. Experience has shown that more is necessary, however, to ensure adequate community safety where companies act in concert to heighten the anticompetitive use of patents that they hold or license.

GPLv2 第7条在阻止可能导致下游无法完全享受 GPL 权利的行为方面取得了一些成功，因此它在 GPLv3 第12条中得到了保留。然而，经验表明，在公司采取行动的地方，还需要做更多的工作来确保充分的社区安全共同加强对他们持有或许可的专利的反竞争使用。

Therefore, GPLv3 is designed to reduce the patent risks that distort and threaten the activities of users who make, run, modify and share Free Software. At the same time, GPLv3 gives favorable consideration to practical goals such as certainty and administrability for patent holders that participate in distribution and development of GPL-covered software. GPLv3's policy requires each such patent holder to provide appropriate levels of patent assurance to users, according to the nature of the patent holder's relationship to the program.

因此，GPLv3 旨在降低扭曲和威胁制作、运行、修改和共享自由软件的用户的活动的专利风险。同时，GPLv3 对参与 GPL 软件分发和开发的专利持有人的确定性和可管理性等实际目标给予了有利的考虑。GPLv3 的政策要求每个此类专利持有人根据专利持有人与程序的关系性质，向用户提供适当级别的专利保证。

In general, GPLv3 provides for two classes of patent commitments:

Grant of license to claims in contributor versions: GPLv3 11 introduces an affirmative grant of rights to patent claims by those who contribute code to GPL'd programs. The intent is to prevent parties from aggressively asserting patents against users of code those parties have themselves modified --- in theory preventing betrayal by "insiders" of the copyleft community. A contributor's patent claims necessarily infringed by the version of the program created by the incorporation of its modifications are licensed to all subsequent users and modifiers of the program, or programs based on the program. No patent claims only infringed by subsequent modifications by other parties are thus licensed. Patent claims acquired after the making of the "contributor version" necessarily infringed by that version are also licensed by this provision at the time of their acquisition or perfection.

一般来说，GPLv3 提供两类专利承诺：

授予贡献者版本中声明的许可：GPLv3 第11条引入了对那些为 GPL 程序贡献代码的人的专利声明的肯定性授予权利。这样做的目的是防止各方针对他们自己修改的代码的用户积极主张专利——理论上防止 copyleft 社区的“内部人士”背叛。贡献者的专利声明必然会受到其修改的合并所创建的程序版本的侵犯，该版本将许可给该程序或基于该程序的程序的所有后续用户和修改者。仅因其他方的后续修改而侵犯的专利权利要求不会因此获得许可。在制作“贡献者版本”后获得的专利权利要求必然受到该版本的侵犯，在其获得或完善时也根据本条款获得许可。

Prohibition of enforcement of patent claims against those to whom you distribute: GPLv3 10 makes explicit that licensees who directly distribute may not make demands for acceptance of patent licenses or payment of patent royalties from distribution recipients. This provision establishes a uniform rule of patent exhaustion with respect to GPL'd programs regardless of the domestic patent law in any particular system or locale.

禁止对您分发的人执行专利索赔：GPLv3 第10条明确规定直接分发的被许可人不得要求接受专利许可或支付分发接收者的专利使用费。无论任何特定系统或地区的国内专利法如何，该条款都针对 GPL 程序建立了统一的专利用尽规则。

The following two subsections discuss in order each of the above mentioned classes of patent commitments.

以下两小节按顺序讨论上述每一类专利承诺。

9.14.1 The Contributor's Explicit Patent License

9.14.1 贡献者的显示专利许可

Specifically, the ideal might have been for GPLv3 to feature a patent license grant triggered by all acts of distribution of GPLv3-covered works. The FSF considered it during the GPLv3 drafting process, but many patent-holding companies objected to this policy. They have made two objections: (1) the far-reaching impact of the patent license grant on the patent holder is disproportionate to the act of merely distributing code without modification or transformation, and (2) it is unreasonable to expect an owner of vast patent assets to exercise requisite diligence in reviewing all the GPL-covered software that it provides to others. Some expressed particular concern about the consequences of "inadvertent" distribution.

具体来说，理想的情况可能是 GPLv3 具有由 GPLv3 涵盖作品的所有分发行为触发的专利许可授予。FSF 在 GPLv3 起草过程中考虑过这一点，但许多专利持有公司反对这一政策。他们提出了两个反对意见：（1）授予专利许可对专利持有人的深远影响与仅分发代码而不进行修改或改造的行为不相称，（2）期望拥有大量专利的所有者是不合理的专利资产，以尽必要的努力审查其提供给他人的所有 GPL 软件。一些人对“无意”分发的后果表示特别关注。

The argument that the impact of the patent license grant would be "disproportionate", that is to say unfair, is not valid. Since software patents are weapons that no one should have, and using them for aggression against free software developers is an egregious act (thus preventing that act cannot be unfair).

专利许可授予的影响将“不成比例”，即不公平的论点是无效的。由于软件专利是任何人都不应该拥有的武器，使用它们来攻击自由软件开发者是一种恶劣的行为（因此阻止这种行为是不公平的）。

However, the second argument seems valid in a practical sense. A typical GNU/Linux distribution includes thousands of programs. It would be quite difficult for a re-distributor with a large patent portfolio to review all those programs against that portfolio every time it receives and passes on a new version of the distribution. Moreover, this question raises a strategic issue. If the GPLv3 patent license requirements convince patent-holding companies to remain outside the distribution path of all GPL-covered software, then these requirements, no matter how strong, will cover few patents.

然而，第二个论点在实际意义上似乎是有效的。典型的 GNU/Linux 发行版包括数千个程序。对于拥有大量专利组合的再分发者来说，每次收到并传递新版本的分发时，都很难根据该组合审查所有这些程序。此外，这个问题提出了一个战略问题。如果 GPLv3 专利许可要求说服专利持有公司置身于所有受 GPL 保护的软件的分发路径之外，那么这些要求，无论多么强烈，都将覆盖很少的专利。

GPLv3 therefore makes a partial concession which would lead these companies to feel secure in doing the distribution themselves. GPLv3 11 applies only to those distributors that have modified the program. The other changes we have made in sections 10 and 11 provide strengthened defenses against patent assertion and compensate partly for this concession.

因此，GPLv3 做出了部分让步，这将使这些公司在自己进行分发时感到安全。GPLv3 第11条仅适用于修改了程序的发行商。我们在第10条和第11条中所做的其他更改提供了针对专利主张的强化抗辩，并部分补偿了这种让步。

Therefore, GPLv3 11 introduces the terms "contributor", "contributor version", and "essential patent claims", which are used in the GPLv3 11 3. Viewed from the perspective of a recipient of the Program, contributors include all the copyright holders for the Program, other than copyright holders of material originally licensed under non-GPL terms and later incorporated into a GPL-covered work. The contributors are therefore the initial GPLv3 licensors of the Program and all subsequent upstream licensors who convey, under the terms of GPLv3 5, modified covered works. Thus, the "contributor version" includes the material the contributor has copied from the upstream version that the contributor has modified. GPLv3 11 3 does not apply to those that redistribute the program without change.³⁷ In other words, the "contributor version" includes not just the material added or altered by the contributor, but also the pre-existing material the contributor copied from the upstream version and retained in the modified version. (GPLv3's usage of "contributor" and "contribution" should not be confused with the various other ways in which those terms are used in certain other free software licenses.³⁸)

因此，GPLv3 第11条第3款引入了 GPLv3 第11条中使用的术语“贡献者”、“贡献者版本”和“必要的专利权利要求”。从程序接收者的角度来看，贡献者包括程序所有版权持有者，最初根据非 GPL 条款许可并后来合并到 GPL 作品中的材料的版权所有者除外。因此，贡献者是本程序的初始 GPLv3 许可人，以及根据 GPLv3 第5条传送修改后的涵盖作品的所有后续上游许可人。因此，“贡献者版本”包括贡献者从贡献者已修改的上游版本复制的材料。GPLv3 第11条第3款不适用于那些不加改动地重新发布程序的人³⁷。换句话说，“贡献者版本”不仅包括贡献者添加或更改的材料，还包括贡献者从中复制的现有材料上游版本并保留在修改版本中。（GPLv3 对“贡献者”和“贡献”的使用不应与这些术语在某些其他自由软件许可中的各种其他使用方式相混淆³⁸。）

Some details of the "essential patent claims" definition deserve special mention. "Essential patent claims", for a given party, are a subset of the claims "owned or controlled" by the party. They do include sublicensable claims that have been licensed to the contributor by a third party.³⁹ Most commercial patent license agreements that permit sublicensing do so under restrictive terms that are inconsistent with the requirements of the GPL. For example, some patent licenses allow the patent licensee to sublicense but require collection of royalties from any sublicensees. The patent licensee could not distribute a GPL-covered program and grant the recipient a patent sublicense for the program without violating section 12 of GPLv3.⁴⁰ In rare cases, however, a conveying party can freely grant patent sublicenses to downstream recipients without violating the GPL.

“必要专利权利要求”定义的一些细节值得特别提及。对于给定的一方，“必要专利权利要求”是该方“拥有或控制”的权利要求的子集。它们确实包括已由第三方许可给贡献者的可再许可声明。³⁹ 大多数允许再许可的商业专利许可协议都是在与 GPL 要求不一致的限制性条款下进行的。例如，一些专利许可允许专利被许可人进行再许可，但要求从任何被再许可人处收取使用费。专利被许可人不能在不违反 GPLv3 第12条的情况下分发受 GPL 保护的程序并向接收者授予该程序的专利从属许可⁴⁰ 然而，在极少数情况下，传送方可以在不违反 GPLv3 的情况下自由向下游接收者授予专利从属许可 GPL。

Additionally, "essential patent claims" are those patents "that would be infringed by some manner, permitted by this License, of making, using, or selling the work". This intends to make clear that a patent claim is "essential" if some mode of usage would infringe that claim, even if there are other modes of usage that would not infringe.

此外，“基本专利权利要求”是那些“在本许可证允许的情况下，以某种方式侵犯制作、使用或销售作品的专利”。这旨在表明，如果某种使用方式会侵犯专利权利要求，则该专利权利要求是“必要的”，即使存在其他不会侵权的使用方式也是如此。

Finally, "essential patent claims . . . do not include claims that would be infringed only as a consequence of further modification of the work." The set of essential patent claims licensed is fixed by the particular version of the work that was contributed. The claim set cannot expand as a work is further modified downstream. (If it could, then any software patent claim would be included, since any software patent claim can be infringed by some further modification of the work.)⁴¹

最后，“必要的专利声明……不包括仅因进一步修改作品而被侵权的索赔。” 许可的基本专利权利要求集由所贡献作品的特定版本确定。随着作品在下游进一步修改，声明集无法扩展。（如果可以，那么将包括任何软件专利声明，因为任何软件专利声明都可能因对作品的进一步修改而受到侵犯。）⁴¹

Ideally, this contributor patent policy will result in fairly frequent licensing of patent claims by contrib- utors. A contributor is charged with awareness of the fact that it has modified a work and provided it to others; no act of contribution should be treated as inadvertent. GPLv3's rule also requires no more work, for a contributor, than the weaker rule proposed by the patent holders. Under their rule, the contributor must always compare the entire work against its patent portfolio to determine whether the combination of the modifications with the remainder of the work cause it to read on any of the contributor's patent claims.

理想情况下，这种贡献者专利政策将导致贡献者相当频繁地许可专利权利要求。贡献者有责任意识到自己修改了作品并将其提供给他人；任何捐助行为都不应被视为无意。对于贡献者来说，GPLv3 的规则也不需要比专利持有人提出的较弱的规则更多的工作。根据他们的规定，贡献者必须始终将整个作品与其专利组合进行比较，以确定修改与作品其余部分的组合是否会导致其阅读贡献者的任何专利声明。

Finally, GPLv3's explicit patent license for contributors has an interesting and useful side effect. When a company with a large number of such claims acquires the program's modifier, all claims held or thereafter acquired by the purchaser are automatically licensed under this provision. For example, Microsoft's acqui- sition of Nokia resulted in the automatic licensing of all Microsoft patent claims now or hereafter acquired which read on any contributor version of any GPLv3 program ever modified by Nokia.

最后，GPLv3 对贡献者的明确专利许可有一个有趣且有用的副作用。当拥有大量此类权利要求的公司获得该程序的修改器时，购买者持有或之后获得的所有权利要求将根据本条款自动获得许可。例如，微软对诺基亚的收购导致微软现在或以后获得的所有专利权利要求的自动许可，这些权利要求阅读诺基亚曾经修改过的任何 GPLv3 程序的任何贡献者版本。

9.14.2 Conveyors' Patent Licensing

9.14.2 专利许可的传递

The remaining patent licensing in GPLv3 deals with patent licenses that are granted by conveyance. The licensing is not as complete or far reaching as the contributor patent licenses discussed in the preceding section.

GPLv3 中剩余的专利许可涉及通过转让授予的专利许可。许可不像上一节中讨论的贡献者专利许可那样完整或广泛。

The term "patent license," as used in GPLv3 11 4--6, is not meant to be confined to agreements formally identified or classified as patent licenses. GPLv3 11 3 makes this clear by defining "patent license," for purposes of the subsequent three paragraphs, as "any express agreement or commitment, however denomi- nated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement)"

GPLv3 第11条第4-6款中使用的术语“专利许可”并不意味着仅限于正式确定或归类为专利许可的协议。GPLv3 第11条第3款通过为后续三段的目的将“专利许可”定义为“任何明确的协议或承诺，无论名称如何，不强制执行专利（例如明确许可实施专利或承诺不起诉专利侵权）”

GPLv3 11 5 is commonly called GPLv3's downstream shielding provision. It responds particularly to the problem of exclusive deals between patent holders and distributors, which threaten to distort the free software distribution system in a manner adverse to developers and users. The fundamental idea is to make a trade-off between assuring a patent license for downstream and making (possibly patent-encumbered) CCS publicly available.

GPLv3 第11条第5款通常称为 GPLv3 的下游屏蔽条款。它特别针对专利持有人和分销商之间的排他性交易问题作出回应，这些交易有可能以对开发者和用户不利的方式扭曲自由软件分发系统。基本思想是在确保下游专利许可和公开提供（可能受专利保护的）CCS 之间做出权衡。

Simply put, in nearly all cases in which the "knowingly relying" test is met, the patent license will indeed not be sublicensable or generally available to all on free terms. If, on the other hand, the patent license is generally available under terms consistent with the requirements of the GPL, the distributor is automatically in compliance, because the patent license has already been extended to all downstream recipients. Finally, if the patent license is sublicensable on GPL-consistent terms, the distributor may choose to grant sublicenses to downstream recipients instead of causing the CCS to be publicly available. (In such a case, if the distributor is also a contributor, it will already have granted a patent sublicense anyway, and so it need not do anything further to comply with the third paragraph.)

简而言之，在几乎所有满足“故意依赖”测试的情况下，专利许可确实不可再许可或普遍免费提供给所有人。另一方面，如果专利许可在符合 GPL 要求的条款下普遍可用，则分销商自动遵守，因为专利许可已经扩展到所有下游接收者。最后，如果专利许可可以按照与 GPL 一致的条款进行再许可，则分发者可以选择向下游接收者授予再许可，而不是让 CCS 公开可用。（在这种情况下，如果分销商也是贡献者，那么无论如何它已经授予了专利从属许可，因此它不需要做任何进一步的事情来遵守第三段。）

Admittedly, public disclosure of CCS is not necessarily required by other sections of the GPL, and the FSF in drafting GPLv3 did not necessarily wish to impose a general requirement to make source code available to all, which has never been a GPL condition. However, many vendors who produce products that include copylefted software, and who are most likely to be affected by the downstream shielding provision, lobbied for the addition of the source code availability option, so it remains.

诚然，CCS 的公开披露不一定是 GPL 的其他部分所要求的，并且 FSF 在起草 GPLv3 时并不一定希望强加一个通用的要求，即向所有人提供源代码，这从来都不是 GPL 的条件。然而，许多生产包含 copylefted 软件的产品的供应商，以及最有可能受到下游屏蔽条款影响的供应商，游说添加源代码可用性选项，因此它仍然存在。

^18^ However, "the work" should not be understood to be restricted to a particular mechanical affixation of, or medium for distributing, a program, where the same program might be provided in other forms or in other ways that may be captured by other patent claims held by the contributor.

Meanwhile, two specific alternatives to the source code availability option are also available. The dis- tributor may comply by disclaiming the patent license it has been granted for the conveyed work, or by arranging to extend the patent license to downstream recipients.⁴² The GPL is intended to permit private distribution as well as public distribution, and the addition of these options ensures that this remains the case, even though it remains likely that distributors in this situation will usually choose the source code availability option.

同时，还提供了源代码可用性选项的两个特定替代方案。发行商可以通过放弃已授予其所传送作品的专利许可，或通过安排将专利许可扩展到下游接收者来遵守。⁴² GPL 旨在允许私人发行和公共发行，并且这些选项的添加确保了这种情况仍然存在，即使在这种情况下分销商仍然可能通常会选择源代码可用性选项。

Note that GPLv3 11 5 is activated only if the CCS is not already otherwise publicly available. (Most often it will, in fact, already be available on some network server operated by a third party.) Even if it is not already available, the option to "cause the Corresponding Source to be so available" can then be satisfied by verifying that a third party has acted to make it available. That is to say, the affected distributor need not itself host the CCS to take advantage of the source code availability option. This subtlety may help the distributor avoid certain peculiar assumptions of liability.

请注意，仅当 CCS 尚未以其他方式公开可用时，GPLv3 第11条第5款才会被激活。（事实上，大多数情况下，它已经在第三方运营的某些网络服务器上可用。）即使它还不可用，“使相应的源如此可用”的选项也可以通过验证来满足第三方已采取行动使其可用。也就是说，受影响的分销商不需要自己托管 CCS 来利用源代码可用性选项。这种微妙之处可能有助于分销商避免某些特殊的责任假设。

Note that GPLv3 11 6--7 are designed to stop distributors from colluding with third parties to offer selective patent protection. GPLv3 is designed to ensure that all users receive the same rights; arrangements that circumvent this make a mockery of free software, and we must do everything in our power to stop them. First, GPLv3 11 6 states that any license that protects some recipients of GPL'd software must be extended to all recipients of the software. If conveyors arrange to provide patent protection to some of the people who get the software from you, that protection is automatically extended to everyone who receives the software, no matter how they get it.

请注意，GPLv3 第11条第6–7款旨在阻止分销商与第三方串通以提供选择性专利保护。GPLv3 旨在确保所有用户获得相同的权利；规避这一点的安排是对自由软件的嘲弄，我们必须竭尽全力阻止它们。首先，GPLv3 第11条第6款声明任何保护 GPL 软件的某些接收者的许可证必须扩展到该软件的所有接收者。如果传送者安排向从您那里获得软件的某些人提供专利保护，则该保护会自动扩展到接收到软件的每个人，无论他们如何获得它。

Second, GPLv3 11 7 prohibits anyone who made such an agreement from distributing software released under GPLv3. Conveyors are prohibited from distributing software under GPLv3 if the conveyor makes an agreement of that nature in the future.

其次，GPLv3 第11条第7款禁止任何签订此类协议的人分发根据 GPLv3 发布的软件。如果传送者将来达成此类性质的协议，则禁止传送者分发 GPLv3 下的软件。

The date in GPLv3 11 7 likely seems arbitrary to those who did not follow the GPLv3 drafting process. This issue was hotly debated during the drafting of GPLv3, but ultimately one specific deal of this type --- a deal between Microsoft and Novell for Microsoft to provide so-called "coupons" to Microsoft customers to redeem for copies of Novell's GNU/Linux distribution with a Microsoft patent license -- was designed to be excluded.

对于那些不遵循 GPLv3 起草过程的人来说，GPLv3 第11条第7款中的日期可能看起来很武断。这个问题在 GPLv3 的起草过程中引起了激烈的争论，但最终达成了一项此类具体交易——微软和 Novell 之间的一项交易，微软向微软客户提供所谓的“优惠券”，以兑换 Novell 的 GNU/Linux 发行版副本微软专利许可——被设计为被排除在外。

The main reason for this was a tactical decision by the FSF. FSF believed they can do more to protect the community by allowing Novell to use software under GPLv3 than by forbidding it to do so. This is because of paragraph 6 of section 11 (corresponding to paragraph 4 in Draft 3). It will apply, under the Microsoft/Novell deal, because of the coupons that Microsoft has acquired that essentially commit it to participate in the distribution of the Novell SLES GNU/Linux system.

主要原因是 FSF 的战术决定。FSF 认为，与禁止 Novell 使用 GPLv3 软件相比，他们可以通过允许 Novell 使用 GPLv3 软件来保护社区。这是因为第11条第6款（对应草案3中的第4款）。根据 Microsoft/Novell 协议，它将适用，因为 Microsoft 获得的优惠券实质上承诺参与 Novell SLES GNU/Linux 系统的分发。

The FSF also gave a secondary reason: to avoid affecting other kinds of agreements for other kinds of activities. While GPLv3 sought to distinguish pernicious deals of the Microsoft/Novell type from business conduct that is not particularly harmful, the FSF also did not assume success in that drafting, and thus there remained some risk that other unchangeable past agreements could fall within the scope of GPLv3 11 7. In future deals, distributors engaging in ordinary business practices can structure the agreements so that they do not fall under GPLv3 *§11¶*7.

FSF 还给出了一个次要原因：避免影响其他类型活动的其他类型协议。虽然 GPLv3 试图将 Microsoft/Novell 类型的有害交易与不是特别有害的商业行为区分开来，但 FSF 也没有假设在该起草中取得成功，因此仍然存在一些风险，即其他不可更改的过去协议可能属于 GPLv3 的范围 GPLv3 第11条第7款。在未来的交易中，从事普通商业行为的分销商可以构建协议，使其不属于 GPLv3 第11条第7款。

GPLv3 §12: Familiar as GPLv2 §7

9.15 GPLv3 第12条：与GPLv2 第7条相似

GPLv2 12 remains almost completely unchanged from the text that appears in GPLv2 7. This is an important provision that ensures a catch-all to ensure that nothing "surprising" interferes with the continued conveyance safely under copyleft.

GPLv3 第12条与 GPLv2 第7条中出现的文本几乎完全保持不变。这是一项重要的规定，确保包罗万象，确保没有任何“意外”干扰 copyleft 下的安全继续传输。

The wording in the first sentence of GPLv3 12 has been revised slightly to clarify that an agreement -- such as a litigation settlement agreement or a patent license agreement -- is one of the ways in which conditions may be "imposed" on a GPL licensee that may contradict the conditions of the GPL, but which do not excuse the licensee from compliance with those conditions. This change codifies the historical interpretation of GPLv2.

GPLv3 第12条第一句的措辞略有修改，以阐明协议（例如诉讼和解协议或专利许可协议）是可以对 GPL 被许可人“施加”条件的方式之一与 GPL 的条件相矛盾，但不能成为被许可人不遵守这些条件的借口。此更改整理了 GPLv2 的历史解释。

GPLv3 removed the limited severability clause of GPLv2 7 as a matter of tactical judgment, believing that this is the best way to ensure that all provisions of the GPL will be upheld in court. GPLv3 also removed the final sentence of GPLv2 section 7, which the FSF consider to be unnecessary.

GPLv3 作为战术判断删除了 GPLv2 第7条的有限可分割性条款，认为这是确保 GPL 所有条款在法庭上得到维护的最佳方式。GPLv3 还删除了 GPLv2 第 7 条的最后一句，FSF 认为这是不必要的。

GPLv3 §13: The Great Affero Compromise

9.16 GPLv3 第13条：伟大的Affero妥协

The Affero GPL was written with the expectation that its additional requirement would be incorporated into the terms of GPLv3 itself. Many software freedom advocates, including some authors of this tutorial, advocated heavily for that, and fully expected it to happen.

Affero GPL 的编写期望将其附加要求纳入 GPLv3 本身的条款中。许多软件自由倡导者，包括本教程的一些作者，大力倡导这一点，并完全期待它的发生。

The FSF, however, chose not to include the Affero clause in GPLv3, due to what it called "irreconcilable views from different parts of the community". Many commercial users of Free Software were opposed to the inclusion of a mandatory Affero-like requirement in the body of GPLv3 itself. In fact, some wealthier companies even threatened to permanently fund forks of many FSF copyrighted-programs under GPLv2 if the Affero clause appeared in GPLv3.

然而，由于所谓的“来自社区不同部分的不可调和的观点”，FSF 选择不将 Affero 条款包含在 GPLv3 中。许多自由软件的商业用户反对在 GPLv3 本身的主体中包含强制性的类似 Affero 的要求。事实上，如果 Affero 条款出现在 GPLv3 中，一些更富有的公司甚至威胁要永久资助许多 GPLv2 下的 FSF 版权程序的分支。

Meanwhile, there was disagreement even among copyleft enthusiasts about the importance of the pro- vision. A coalition never formed, and ultimately the more powerful interests implicitly allied with the companies who deeply opposed the Affero clause such that the FSF felt the Affero clause would need its own license, but one compatible with GPLv3.

与此同时，甚至在 copyleft 爱好者中也对该条款的重要性存在分歧。一个联盟从未形成，最终更强大的利益集团与那些强烈反对 Affero 条款的公司暗中结盟，以至于 FSF 认为 Affero 条款需要自己的许可，但要与 GPLv3 兼容。

GPLv3 13 makes GPLv3 compatible with the AGPLv3, so that at least code can be shared between AGPLv3'd and GPLv3'd projects, even if the Affero clause does not automatically apply to all GPLv3'd works.

GPLv3 第13条使 GPLv3 与 AGPLv3 兼容，因此至少可以在 AGPLv3 和 GPLv3 项目之间共享代码，即使 Affero 条款不会自动适用于所有 GPLv3 作品。

Meanwhile, those who criticize the permission to link with code under the Affero GPL should recognize that most other free software licenses also permit such linking. In particular, when a combined work is made by linking GPLv3-covered code with AGPLv3-covered code, the copyleft on one part will not extend to the other part. In such combinations, the Affero requirement will apply only to the part originally brought into the combination under the Affero license. In theory, those who receive such a combination and do not wish to use code under the Affero requirement may remove the Affero-covered portion of the combination. (Admittedly, in practice, de-mingling of combined code can be technically difficult.)

人应该认识到，大多数其他自由软件许可证也允许此类链接。特别是，当通过将 GPLv3 覆盖的代码与 AGPLv3 覆盖的代码链接起来制作组合作品时，一部分的 copyleft 不会扩展到另一部分。在此类组合中，Affero 要求将仅适用于最初根据 Affero 许可引入组合的部分。理论上，那些收到此类组合并且不想根据 Affero 要求使用代码的人可以删除组合中 Affero 覆盖的部分。（诚然，在实践中，组合代码的去混合在技术上可能很困难。）

GPLv3 §14: So, When's GPLv4?

9.17 GPLv3 第14条：那么GPLv4什么时候会出？

No substantive change has been made in section 14. The wording of the section has been revised slightly to make it clearer.

第 14 条未作实质性更改。该节的措辞已略作修改，以使其更加清晰。

It's unclear when the FSF might consider publishing GPLv4. However, this section makes it clear that the FSF is the sole authority who can decide such.

目前尚不清楚 FSF 何时会考虑发布 GPLv4。但是，本节明确表示 FSF 是唯一可以做出此类决定的机构。

The main addition to this section allows a third-party proxy to be appointed by contributors who wish someone else to make relicensing to new versions of GPL when they are released. This is a "halfway" point between using "-only" or "-or-later" by consolidating the decision-making on that issue to a single authority.

本节的主要新增内容允许贡献者指定第三方代理，这些贡献者希望其他人在发布新版本的 GPL 时重新授权。通过将该问题的决策整合到一个单一的权威机构，这是使用“仅”或“及后续”之间的“中间”点。

GPLv3 §15--17: Warranty Disclaimers and Liability Limita- tion

9.18 GPLv3 第15——17条：免责声明与有限责任

No substantive changes have been made in sections 15 and 16.

第 15 和 16 条未作实质性修改。

Finally, the FSF shortened the section on "How to Apply These Terms to Your New Programs" to just the bare essentials.

最后，FSF 将“如何将这些条款应用于您的新程序”部分缩短为仅保留基本要素。

CHAPTER 10 THE LESSER GPL

第10章宽松GPL

As we have seen in our consideration of the GPL, its text is specifically designed to cover all possible derivative, modified and/or combined works under copyright law. Our goal in designing the GPL was to maximize its use of the controls of copyright law to maximize the number of works that were covered by GPL.

正如我们在考虑 GPL 时所看到的，它的文本是专门设计用于涵盖所有可能的衍生作品，修改和/或版权法下的组合作品。我们设计 GPL 的目标是为了最大限度地利用版权法来最大化地控制涵盖的作品数量。

However, while the strategic goal of software freedom is to bring as much Free Software into the world as possible, particular tactical considerations regarding software freedom dictate different means. Extending the copyleft effect as far as copyright law allows is not always the most prudent course in reaching the goal. In particular situations, even those of us with the goal of building a world where all published software is Free Software realize that full copyleft does not best serve us. The GNU Lesser General Public License ("GNU LGPL") was designed as a solution for such situations. The Lesser General Public License is sometimes described as a "weak copyleft" license, because code licensed under LGPL's terms can be combined with code under non-free licenses, and is sometimes used in that fashion.

然而，虽然软件自由的战略目标是尽可能多的把自由软件带给世界，特别是关于软件自由的战术考虑决定了不同的方式。在版权法允许的范围内扩大 copyleft 的效果并不始终是实现目标最谨慎的做法。特殊情况下，甚至我们当中有些人的目标是建立一个世界所有发布的软件都是自由软件，实现完全的 copyleft 并不能最好地为我们服务。 GNU 宽松通用公共许可证(“GNU LGPL") 被设计为针对此类情况的解决方案。LGPL 有时被描述为“弱 copyleft” 许可，因为根据 LGPL 条款许可的代码可以与非自由许可下的代码，有时确实以这种方式使用。

10.1 The First LGPL'd Program

10.1 第一个采用LGPL许可的程序

The first example that FSF encountered where such altered tactics were needed was when work began on the GNU C Library. The GNU C Library would become (and today, now is) a drop-in replacement for existing C libraries. On a Unix-like operating system, C is the lingua franca and the C library is an essential component for all programs. It is extremely difficult to construct a program that will run with ease on a Unix-like operating system without making use of services provided by the C library --- even if the program is written in a language other than C. Effectively, all user application programs that run on any modern Unix-like system must make use of the C library.

FSF 遇到的第一个需要改变策略的例子是从 GNU C 库的工作开始时。 GNU C 库将成为（现在已经是）现有 C 的直接替代品库。在类 Unix 操作系统上，C 是通用语言，C 库是所有程序的重要组成部分。在类 Unix 操作系统上，不使用 C 库构建一个可以轻松运行的程序是非常困难的 —— 即使程序是用一种 C 语言之外的语言编写的。实际上，所有运行在任何现代类 Unix 系统上的程序都必须使用 C 库。

By the time work began on the GNU implementation of the C libraries, there were already many C libraries in existence from a variety of vendors. Every proprietary Unix vendor had one, and many third parties produced smaller versions for special purpose use. However, our goal was to create a C library that would provide equivalent functionality to these other C libraries on a Free Software operating system (which in fact happens today on modern GNU/Linux systems, which all use the GNU C Library).

当 C 库的 GNU 实现工作开始时，已经有来自各种供应商的许多 C 库。每个专有的 Unix 供应商都有一个，还有许多第三方为特殊用途生产了较小的版本。然而，我们的目标是在自由软件操作系统上创建一个于这些其他 C 库提供等效功能的 C 库（事实上如今在现代 GNU/Linux 系统上，它们都使用GNU C 库）。

Unlike existing GNU application software, however, the licensing implications of releasing the GNU C Library ("glibc") under the GPL were somewhat different. Applications released under the GPL would never themselves become part of proprietary software. However, if glibc were released under the GPL, it would require that any application distributed for the GNU/Linux platform be released under the GPL.

然而，与现有的 GNU 应用软件不同的是，在 GPL 许可证下发布 GNU C 库（“glibc”）的影响有些不同。在 GPL 下发布的应用程序将永远不会自己成为专有软件的一部分。然而，如果 glibc 是在 GPL 下发布的，它要求任何为 GNU/Linux 平台分发的应用程序在 GPL 下发布。

Since all applications on a Unix-like system depend on the C library, it means that they must link with that library to function on the system. In other words, all applications running on a Unix-like system must be combined with the C library to form a new whole work that is composed of the original application and the C library. Thus, if glibc were GPL'd, each and every application distributed for use on GNU/Linux would also need to be GPL'd, since to even function, such applications would need to be combined into larger works by linking with glibc.

由于 Unix 系统上的所有应用程序都依赖于 C 库，这意味着它们必须链接到该库才能在系统上运行。换句话说，运行在 Unix 系统上的所有应用程序必须与 C 库结合在一起，形成一个新的整体作品，由原始应用程序和 C 库组成。因此，如果 glibc 被授权为 GPL，那么每个在 GNU/Linux 上使用的应用程序也需要遵循 GPL，因为为了使这些应用程序能够运行，它们需要通过与 glibc 链接而被组合成更大的作品。

At first glance, such an outcome seems like a windfall for Free Software advocates, since it stops all proprietary software development on GNU/Linux systems. However, the outcome is a bit more subtle. In a world where many C libraries already exist, many of which could easily be ported to GNU/Linux, a GPL'd glibc would be unlikely to succeed. Proprietary vendors would see the excellent opportunity to license their C libraries to anyone who wished to write proprietary software for GNU/Linux systems. The de-facto standard for the C library on GNU/Linux would likely be not glibc, but the most popular proprietary one.

乍一看，这样的结果似乎对自由软件倡导者来说是一笔意外之财，因为它停止了所有在 GNU/Linux 系统上的专有软件开发。然而，结果却更加微妙。在已经存在许多C库的世界中，其中许多都可以很容易地移植到 GNU/Linux 上，一个 GPL 的 glibc 很难成功。专有供应商将会看到优秀的机会，可以向希望为 GNU/Linux 系统编写专有软件的任何人授权其 C 库。在GNU/Linux 上，C 库的事实标准可能不会是 glibc，而是最受欢迎的专有C库。

Meanwhile, the actual goal of releasing glibc under the GPL --- to ensure no proprietary applications on GNU/Linux --- would be unattainable in this scenario. Furthermore, users of those proprietary applications would also be users of a proprietary C library, not the Free glibc.

同时，在 GPL 下发布 glibc 的实际目标 —— 确保 GNU/Linux 上没有专有应用程序 —— 将是在这种情况下无法实现。此外，那些专有的用户应用程序也将是专有 C 库的用户，而不是免费的 glibc。

The Lesser GPL was initially conceived to handle this scenario. It was clear that the existence of proprietary applications for GNU/Linux was inevitable. Since there were so many C libraries already in existence, a new one under the GPL would not stop that tide. However, if the new C library were released under a license that permitted proprietary applications to link with it, but made sure that the library itself remained Free, an ancillary goal could be met. Users of proprietary applications, while they would not have the freedom to copy, share, modify and redistribute the application itself, would have the freedom to do so with respect to the C library.

宽松 GPL 最初是为处理这种情况而设计的。很明显，GNU/Linux 的专有应用程序的存在是不可避免的。由于已经存在这么多 C 库，GPL 下的新库不会阻止这种趋势。但是，如果新 C 库是根据允许专有的许可证发布的应用程序与它链接，又能确保库本身保持自由，那么就可以实现附属目标。专有应用程序的用户虽然不能复制、共享、修改和重新分发应用程序本身，但可以分享 C 库的这些自由。

There was no way the license of glibc could stop or even slow the creation of proprietary applications on GNU/Linux. However, loosening the restrictions on the licensing of glibc ensured that nearly all proprietary applications at least used a Free C library rather than a proprietary one. This trade-off is central to the reasoning behind the LGPL.

glibc 的许可证无法阻止甚至减慢在 GNU/Linux 上创建专有应用程序。然而，对 glibc 许可的宽松限制确保几乎所有专有应用程序至少使用自由软件 C 库而不是专有的。这种权衡是 LGPL 背后的核心理由。

Of course, many people who use the LGPL today are not thinking in these terms. In fact, they are often choosing the LGPL because they are looking for a "compromise" between the GPL and the X11-style liberal licensing. However, understanding FSF's reasoning behind the creation of the LGPL is helpful when studying the license.

当然，今天许多使用 LGPL 的人并没有考虑这些条款。事实上，他们经常选择 LGPL，因为他们正在寻找 GPL 和 X11 风格之间的“妥协”自由许可。然而，了解 FSF 创建 LGPL 背后的原因有助于学习许可证。

10.2 What's the Same?

10.2 相同的是什么？

Much of the text of the LGPL is identical to the GPL. As we begin our discussion of the LGPL, we will first eliminate the sections that are identical, or that have the minor modification changing the word "Program" to "Library."

LGPL 的大部分文本与 GPL 相同。当我们开始讨论 LGPL 时，我们将首先删除以下相同的部分，或者将“程序”改成“库”有微小的修改。

First, LGPLv2.1 1, the rules for verbatim copying of source, are equivalent to those in GPLv2 1.

首先，LGPLv2.1 第1条，逐字复制源码的规则，等同于 GPLv2 第1条中的规则。

Second, LGPLv2.1 8 is equivalent GPLv2 4. In both licenses, this section handles termination in precisely the same manner.

其次，LGPLv2.1 第8条等同于 GPLv2 第4条。在这两个许可证中，这部分以完全相同的方式处理许可终止。

LGPLv2.1 9 is equivalent to GPLv2 5. Both sections assert that the license is a copyright license, and handle the acceptance of those copyright terms.

LGPLv2.1 第9条等同于 GPLv2 第5条。这两部分都声明许可是版权许可，并处理接受版权的条款。

LGPLv2.1 10 is equivalent to GPLv2 6. They both protect the distribution system of Free Software under these licenses, to ensure that up, down, and throughout the distribution chain, each recipient of the software receives identical rights under the license and no other restrictions are imposed.

LGPLv2.1 第10条等同于 GPLv2 第6条。它们都保护这些许可证下的自由软件分发系统，以确保在整个分发链上、下游和整个分发链中，每个收件人的软件根据许可证获得相同的权利，并且没有施加了其他限制。

LGPLv2.1 11 is GPLv2 7. As discussed, it is used to ensure that other claims and legal realities, such as patent licenses and court judgments, do not trump the rights and permissions granted by these licenses, and requires that distribution be halted if such a trump is known to exist.

LGPLv2.1的第11条是GPLv2的第7条。如前所述，它用于确保其他主张和法律现实，例如专利许可和法庭判决，不会否定这些许可证授予的权利和权限，并要求如果已知存在这样的否定情况，则必须停止分发。

LGPLv2.1 12 adds the same features as GPLv2 8. These sections are used to allow original copyright holders to forbid distribution in countries with draconian laws that would otherwise contradict these licenses. LGPLv2.1 13 sets up the FSF as the steward of the LGPL, just as GPLv2 9 does for GPL. Meanwhile, LGPLv2.1 14 reminds licensees that copyright holders can grant exceptions to the terms of LGPL, just as GPLv2 10 reminds licensees of the same thing.

LGPLv2.1 第12条款增加了与 GPLv2 第8条相同的功能。这些条款用于允许原始版权持有人禁止在拥有极其严苛法律的国家进行分发，否则将与这些许可证相矛盾。LGPLv2.1 第13条设立了 FSF 作为 LGPL 的管理者，就像 GPLv2 第9条为 GPL 所做的那样。同时，LGPLv2.1 第14条提醒许可证持有人版权持有人可以授予对 LGPL 条款的例外，就像 GPLv2 第10条提醒许可证持有人一样。

Finally, the assertions of no warranty and limitations of liability are identical; thus LGPLv2.1 15 and LGPLv2.1 16 are the same as GPLv2 11 and 12.

最后，无保证和责任限制的声明是相同；因此 LGPLv2.1 第15条和 LGPLv2.1 第16条与 GPLv2 第11条和第12条相同。

As we see, the entire latter half of the license is identical. The parts which set up the legal boundaries and meta-rules for the license are the same. It is our intent that the two licenses operate under the same legal mechanisms and are enforced precisely the same way.

如我们所见，许可证的整个后半部分是相同的。这为许可证设置法律边界和元规则的部分是相同的。我们的意图是这两个许可证在相同的法律机制，并以完全相同的方式执行。

We strike a difference only in the early portions of the license. Namely, in the LGPL we go into deeper detail of granting various permissions to create certain types of combinations, modifications and derivations. The LGPL does not stretch the requirements as far as copyright law does regarding what works must be relicensed under the same terms. Therefore, LGPL must in detail explain which works can be proprietary. Thus, we'll see that the front matter of the LGPL is a bit more wordy and detailed with regards to the permissions granted to those who modify or redistribute the software.

我们只在许可证的早期部分进行了一些不同。也就是说，在 LGPL 中，我们更详细地授予各种权限，以创建某些类型的组合、修改和派生作品。LGPL 并不像版权法那样要求作品必须按相同条款重新许可，因此，LGPL 必须详细说明哪些作品可以是专有的。因此，我们将看到 LGPL 的前言部分在授予修改或重新分发软件的人所获得的权限方面更加冗长和详细。

10.3 Additions to the Preamble

10.3 序言的补充

Most of the LGPL's Preamble is identical, but the last seven paragraphs introduce the concepts and reasoning behind creation of the license, presenting a more generalized and briefer version of the story with which we began our consideration of the LGPL.

LGPL 的前言大部分内容相同，但最后7段介绍了创造该许可证的概念和理由，提供了一个更加普遍和简短的版本，这个版本与我们开始考虑 LGPL 时所讲述的故事相似。

In short, FSF designed the LGPL for those edge cases where the freedom of the public can better be served by a more lax licensing system. FSF doesn't encourage use of the LGPL automatically for any software that happens to be a library; rather, FSF suggests that it only be used in specific cases, such as the following:

简而言之，自由软件基金会设计LGPL是为了那些边缘情况，这些情况中公众的自由可以通过更宽松的许可系统更好地得到保障。自由软件基金会并不会自动鼓励对任何恰好是库的软件使用LGPL；相反，自由软件基金会建议只在以下特定情况下使用LGPL：

To encourage the widest possible use of a Free Software library, so it becomes a de-facto standard over similar, although not interface-identical, proprietary alternatives

为了鼓励尽可能广泛地使用自由软件库，使其成为类似专有替代品之间的事实标准，尽管它们的接口并不完全相同。

To encourage use of a Free Software library that already has interface-identical proprietary competitors that are more developed

为了鼓励使用已经有更成熟的专有竞争对手存在的自由软件库，而这些竞争对手的接口是相同的。

To allow a greater number of users to get freedom, by encouraging proprietary companies to pick a Free alternative for its otherwise proprietary products

为了让更多的用户获得自由，通过鼓励专有公司在其原本专有的产品中选择自由的替代方案。

The LGPL's preamble sets forth the limits to which the license seeks to go in chasing these goals. The LGPL is designed to ensure that users who happen to acquire software linked with such libraries have full freedoms with respect to that library. They should have the ability to upgrade to a newer or modified Free version or to make their own modifications, even if they cannot modify the primary software program that links to that library.

LGPL的前言阐述了许可证在追求这些目标时的限制。LGPL的设计旨在确保那些获取与这些库链接的软件的用户对该库拥有完全的自由。他们应该有能力升级到一个更新或修改后的自由版本，或者进行自己的修改，即使他们不能修改链接到该库的主要软件程序。

Finally, the preamble introduces two terms used throughout the license to clarify between the different types of combined works: "works that use the library," and "works based on the library." Unlike the GPL, the LGPL must draw some lines regarding permissibly proprietary combined works. We do this here in this license because we specifically seek to liberalize the rights afforded to those who make combined works. In the GPL, we reach as far as copyright law allows. In the LGPL, we want to draw a line that allows some derivative works copyright law would otherwise prohibit if the copyright holder exercised his full permitted controls over the work.

最后，前言引入了两个术语，这些术语贯穿整个许可证，以澄清不同类型的组合作品之间的区别：“使用该库的作品”和“基于该库的作品”。与GPL不同，LGPL必须在允许专有组合作品方面划分一些界限。我们在这个许可证中这样做，因为我们特别寻求放宽对那些制作组合作品的人所享有的权利。在GPL中，我们尽可能地延伸到版权法所允许的范围。在LGPL中，我们想划定一条线，如果版权持有人行使其对作品的全部允许控制权，那么版权法本来会禁止一些衍生作品的产生。

10.4 An Application: A Work that Uses the Library

10.4 应用：使用该库的作品

In the effort to allow certain proprietary works and prohibit others, the LGPL distinguishes between two classes of works: "works based on the library," and "works that use the library." The distinction is drawn on the bright line of binary (or runtime) combined works and modified versions of source code. We will first consider the definition of a "work that uses the library," which is set forth in LGPLv2.1 5.

为了允许某些专有作品并禁止其他作品，LGPL 区分了两类作品：“基于该库的作品”和“使用该库的作品”。这个区分是基于二进制（或运行时）组合作品和源代码的修改版本的明显界限。我们首先考虑“使用该库的作品”的定义，这在LGPLv2.1 第5条中规定。

We noted in our discussion of GPLv2 3 (discussed in Section 5.2 of this document) that binary programs when compiled and linked with GPL'd software are covered as a whole by GPL. This includes both linking that happens at compile-time (when the binary is created) or at runtime (when the binary -- including library and main program both -- is loaded into memory by the user). In GPL, binary works are controlled by the terms of the license (in GPLv2 3), and distributors of such binary works must release full corresponding source.

我们在讨论GPLv2 第3条时指出（在本文档的第5.2节中讨论），当二进制程序在编译时与GPL软件链接时，整个程序都受GPL的覆盖范围。这包括在编译时发生的链接（创建二进制文件时）或在运行时发生的链接（当用户将包括库和主程序的二进制文件加载到内存中时）。在GPL中，二进制作品受许可证条款（GPLv2 第3条）的控制，这些二进制作品的分发者必须发布相应的全部源代码。

The LGPL, by contrast, allows partial proprietarization of such binary works. This scenario, defined in LGPL as "a work that uses the library," works as follows:

相比之下，LGPL 允许对这种二进制文件进行部分专有化作品。这种场景在 LGPL 中定义为“使用库”的工作原理如下：

A new copyright holder creates a separate and independent work, I, that makes interface calls (e.g., function calls) to the LGPL'd work, called L, whose copyright is held by some other party. Note that since I and L are separate and independent works, there is no copyright obligation on this new copyright holder with regard to the licensing of I, at least with regard to the source code.
一个新的版权持有者创建了一个名为 I 的独立作品，它进行接口调用（例如函数调用）到由其他方持有版权的 LGPL 作品 L。请注意，由于 I 和 L 是独立的作品，因此对于 I 的许可证至少在源代码方面，新的版权持有者没有版权义务。
The new copyright holder, for her software to be useful, realizes that it cannot run without combining I and L. Specifically, when she creates a running binary program, that running binary must be a combined work, called L+I, that the user can run.
新的版权持有者，为了让她的软件有用，意识到如果不结合 I 和 L，它就无法运行。具体来说，当她创建一个可执行的二进制程序时，那个可执行的二进制程序必须是用户可以运行的组合作品，称为 L+I。
Since L+I is a based on both I and L, the license of L (the LGPL) can put restrictions on the license of L+I. In fact, this is what the LGPL does.
由于 L+I 是基于 I 和 L 的，L 的许可证（LGPL）可以对 L+I 的许可施加限制。事实上，LGPL 就是这么做的。

We will talk about the specific restrictions LGPLv2.1 places on "works that use the library" in detail in Section 10.7. For now, focus on the logic related to how the LGPLv2.1 places requirements on the license of

下面我们就来说说 10.7 节中 LGPLv2.1 对使用库的“作品”的具体限制部分中的详细信息。现在，关注 LGPLv2.1 中如何添加条件的现在

+ . Note, first of all, the similarity between this explanation and that in Section 5.1.2, which discussed the combination of otherwise separate and independent works with GPL'd code. Effectively, what LGPLv2.1 does is say that when a new work is otherwise separate and independent, but has interface calls out to an LGPL'd library, then it is considered a "work that uses the library."

+ 首先注意到这个解释和5.1.2节中讨论的将GPL代码与本来是独立的代码组合起来的相似之处。实际上，LGPLv2.1的作用是指出，当一个新的作品本来是独立的，但是它与LGPL库存在接口调用时，那么它被认为是“使用该库的作品”。

In addition, the only reason that LGPLv2.1 has any control over the licensing of a "work that uses the library" is for the same reason that GPL has some say over separate and independent works. Namely, such controls exist because the binary combination ( + ) that must be created to make the separate work ( ) at all useful is a work based on the LGPLv2.1'd software ( ).

此外，LGPLv2.1对“使用该库的作品”的许可控制之所以存在，唯一的原因与GPL对于本来是独立的作品有一定程度的控制权是相同的。也就是说，这些控制权存在是因为必须通过二进制组合(+)来使本来是独立的作品( )有用，而这个二进制组合是基于LGPLv2.1的软件( )创建的作品。

Thus, a two-question test that will help indicate if a particular work is a "work that uses the library" under LGPLv2.1 is as follows:

因此，一个包含两个问题的测试将有助于表明一个特定的工作是否是LGPLv2.1下的“使用库的作品”如下：

Is the source code of the new copyrighted work, I, a completely independent work that stands by itself, and includes no source code from L?
When the source code is compiled, does it combine into a single work with L, either by static (compile- time) or dynamic (runtime) linking, to create a new binary work, L+I?

新的被版权保护的作品 I 的源代码是完全独立的吗？它能够单独存在并且不包括来自 L 的任何源代码吗？
当源代码被编译时，它是否通过静态（编译时）或动态（运行时）链接与L组合成一个单一的工作，以创建一个新的二进制工作，即 L+I？

If the answers to both questions are "yes," then is most likely a "work that uses the library." If the answer to the first question "yes," but the answer to the second question is "no," then most likely is neither a "work that uses the library" nor a "work based on the library." If the answer to the first question is "no," but the answer to the second question is "yes," then an investigation into whether or not is in fact a "work based on the library" is warranted.

如果两个问题的答案都是“是”，那么这很可能是一个“使用库的作品”。如果第一个问题的答案是“是”，但第二个问题的答案是“否”，那么很可能既不是“使用库的作品”，也不是“基于库的作品”。如果第一个问题的答案是“否”，但第二个问题的答案是“是”，那么需要调查是否实际上是一个“基于库的作品”。

10.5 The Library, and Works Based On It

10.5 库，基于它的衍生作品

In short, a "work based on the library" could be defined as any work based on the LGPL'd software that cannot otherwise fit the definition of a "work that uses the library." A "work based on the library" extends the full width and depth of derivative, combined and/or modified works under copyright law, in the same sense that the GPL does.

简而言之，“基于库的作品”可以被定义为任何基于LGPL 许可的软件的作品，否则不能符合“使用库的作品”的定义。在版权法的范围内，“基于库的作品”扩展了派生、组合和/或修改作品的全部范围，与 GPL 的作用相同。

Most typically, one creates a "work based on the library" by directly modifying the source of the library. Such a work could also be created by tightly integrating new software with the library. The lines are no doubt fuzzy, just as they are with GPL'd works, since copyright law gives us no litmus test for determining if a given work is a derivative or otherwise a modified version of another software program.

最常见的情况是通过直接修改库的源代码创建一个“基于库的作品”。这样的作品也可以通过与库紧密集成新软件来创建。这些界限无疑是模糊的，就像 GPL 的作品一样，因为版权法没有给我们一个检验标准来确定一个给定的作品是否是另一个软件程序的派生或修改版本。

Thus, the test to use when considering whether something is a "work based on the library" is as follows:

因此，在考虑是否是一个“基于库的作品”时，可以使用以下测试：

Is the new work, when in source form, a derivative and/or modified work of, and/or a combined work with the LGPL'd work under copyright law?
Is there no way in which the new work fits the definition of a "work that uses the library"?

在源代码形式下，新的作品是否在版权法下是一个派生和/或修改的作品，和/或一个与 LGPL 许可作品组合的作品？
新的作品是否没有符合“使用库的作品”的定义的方式？

If the answer is "yes" to both these questions, then you most likely have a "work based on the library." If the answer is "no" to the first but "yes" to the second, you are in a gray area between "work based on the library" and a "work that uses the library."

如果两个问题的答案都是“是”，那么你很可能有一个“基于库的作品”。如果第一个问题的答案是否定的，但第二个问题的答案是肯定的，你就处于“基于库的作品”和“使用库的作品”之间的灰色地带。

You can also perform a similar same analysis through careful consideration of the license text itself. LGPLv2 2(a) states that if a licensed work is a software library (defined in LGPLv2 0 as "a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables"), you have permission to distribute modified versions only if those versions are themselves libraries. LGPLv2.1 code can therefore not be compliantly taken from its context in a library and placed in a non-library modified version or work based on the work. For its part, LGPLv2 6 does not provide an exception for this rule: a combination may be made of a modified version of an LGPL'd library with other code, but the LGPL'd code must continue to be structured as a library, and to that library the terms of the license continue to apply.

你还可以通过仔细考虑许可证文本本身来进行类似的分析。LGPLv2 2(a)规定，如果一个许可工作是软件库（在LGPLv2 第0条中定义为“一组软件函数和/或数据，为了方便地与应用程序（使用其中一些函数和数据）链接形成可执行文件而准备的”），你只有在这些版本本身是库时才有权限分发修改版本。因此，LGPLv2.1 代码不能从其上下文中以合规的方式作为库被拿出来并放置在非库修改版本或基于该工作的工作中。对于其部分，LGPLv2 第6条并没有为此规则提供例外：可以将 LGPL 许可的库的修改版本与其他代码组合，但 LGPL 许可的代码必须继续作为库结构化，并且该库的条款仍然适用于该库。

Either way you view the rules, these issues are admittedly complicated. Nevertheless, In our years of work with the LGPLv2.1, however, we have never seen a work of software that was not clearly one or the other; the line is quite bright. At times, though, we have seen cases where a particularly large work in some ways seemed to be both to both a work that used the library and a work based on the library. We overcame this problem by dividing the work into smaller subunits. It was soon discovered that what we actually had were three distinct components: the original LGPL'd work, a specific set of works that used that library, and a specific set of works that were based on the library. Once such distinctions are established, the licensing for each component can be considered independently and the LGPLv2.1 applied to each work as prescribed. Finally, note though that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the worst case you simply need to comply as if the software was licensed under GPLv2. The only reason you must consider the question of whether you have a "work that uses the library" or a "work based on the library" is when you wish to take advantage of the "weak copyleft" effect of the Lesser GPL. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the entire work anyway), you may find this an easier option.

无论您如何看待这些规则，这些问题都可以说是相当复杂的。然而，在我们多年 LGPLv2.1 工作的经验中，我们从未见过一个软件作品不明确属于其中之一的情况；界限非常明显。不过，有时我们会遇到一些特别大的作品，在某些方面似乎既是使用库的作品，又是基于库的作品。我们通过将作品分成较小的子单元来解决这个问题。很快就发现我们实际上有三个不同的组成部分：原始的LGPL作品、使用该库的一组具体作品以及基于该库的一组具体作品。一旦建立了这样的区分，每个组件的许可证可以独立考虑，而且可以按照规定为每个作品应用 LGPLv2.1。最后，请注意，由于 LGPLv2.1 可以很容易地升级为 GPLv2 或更高版本，因此在最坏的情况下，您只需要遵守好像软件已经根据GPLv2许可的规定即可。您必须考虑是否拥有“使用库的作品”或“基于库的作品”的问题，唯一的原因是当您想要利用较弱的版权保护（“weak copyleft”）效果时。如果 GPLv2 或更高版本是可接受的许可证（即如果您计划无论如何都使用copyleft保护整个作品），那么您可能会发现这是一个更容易的选择。

10.6 Subtleties in Defining the Application

10.6 定义应用程序的微妙之处

In our discussion of the definition of "works that use the library," we left out a few more complex details that relate to lower-level programming details. The fourth paragraph of LGPLv2.1 5 covers these complexities, and it has been a source of great confusion. Part of the confusion comes because a deep understanding of how compiler programs work is nearly mandatory to grasp the subtle nature of what LGPLv2.1 5, 4 seeks to cover. It helps some to note that this is a border case that we cover in the license only so that when such a border case is hit, the implications of using the LGPL continue in the expected way.

在我们讨论“使用库的作品”的定义时，我们忽略了一些与较低级编程细节相关的更复杂的细节。LGPLv2.1 第5条的第4项涵盖了这些复杂性，它已经成为了一个极大的困惑来源。部分的困惑来自于深入理解编译器程序工作方式几乎是必需的，以理解LGPLv2.1 第5条第4项试图涵盖的微妙性质。需要注意的是，这是一个边界情况，我们仅在许可证中涵盖它，以便当出现这样的边界情况时，LGPL的使用后果将以预期的方式继续产生影响。

To understand this subtle point, we must recall the way that a compiler operates. The compiler first generates object code, which are the binary representations of various programming modules. Each of those modules is usually not useful by itself; it becomes useful to a user of a full program when those modules are linked into a full binary executable.

要理解这个微妙的点，我们必须回顾编译器的工作方式。编译器首先生成目标代码，这些是各种编程模块的二进制表示。这些模块通常本身并不有用；只有当这些模块被链接到一个完整的二进制可执行文件中时，它们才对完整程序的用户有用。

As we have discussed, the assembly of modules can happen at compile-time or at runtime. Legally, there is no distinction between the two --- both create a modified version of the work by copying and combining portions of one work and mixing them with another. However, under LGPL, there is a case in the compilation process where the legal implications are different. To understand this phenomenon, we consider that a "work that uses the library" is typically one whose final binary is a work based on the Program, but whose source is not. However, sometimes, there are cases where the object code --- that intermediate step between source and final binary --- is a work created by copying and modifying code from the LGPL'd software.

正如我们所讨论的，模块的组合可以在编译时或运行时发生。从法律上讲，这两者之间没有区别——都通过复制和组合一个作品的部分并将它们与另一个混合来创建一个修改版本的作品。然而，在LGPL下，编译过程中存在一种情况，其法律影响是不同的。为了理解这种现象，我们考虑“使用库的作品”通常是指其最终二进制文件是基于程序的作品，但其源代码不是。然而，有时候，在目标代码——源代码和最终二进制文件之间的中间步骤中——存在一种情况，即通过复制和修改LGPL软件中的代码创建了一个作品。

For efficiency, when a compiler turns source code into object code, it sometimes places literal portions of the copyrighted library code into the object code for an otherwise separate independent work. In the normal scenario, the final combined work would not be created until final assembly and linking of the executable occurred. However, when the compiler does this efficiency optimization, at the intermediate object code step, a combined work is created.

为了提高效率，编译器将源代码转换为目标代码时，有时会将受版权保护的库代码的文字部分放入目标代码中，以便于另一个独立的作品。在正常情况下，直到最终的汇编和可执行文件链接发生时，才会创建最终的组合作品。但是，当编译器进行这种效率优化时，在中间的目标代码步骤中，就创建了一个组合作品。

LGPLv2.1 5 4 is designed to handle this specific case. The intent of the license is clearly that simply compiling software to "make use" of the library does not in itself cause the compiled work to be a "work based on the library." However, since the compiler copies verbatim, copyrighted portions of the library into the object code for the otherwise separate and independent work, it would actually cause that object file to be a "work based on the library." It is not FSF's intent that a mere compilation idiosyncrasy would change the requirements on the users of the LGPLv2.1'd software. This paragraph removes that restriction, allowing the implications of the license to be the same regardless of the specific mechanisms the compiler uses underneath to create the "work that uses the library."

LGPLv2.1 第5条第4项的设计目的是处理这种特定情况。许可证的意图显然是，仅仅编译软件以“使用”库本身并不会导致编译后的作品成为“基于库的作品”。然而，由于编译器将受版权保护的库的文字部分复制到了另一个独立的作品的目标代码中，实际上会使得该目标文件成为“基于库的作品”。FSF并不希望仅仅是编译的怪癖会改变LGPLv2.1软件的用户的要求。该段落移除了这个限制，允许许可证的影响在不考虑编译器在创建“使用库的作品”时使用的具体机制的情况下是相同的。

As it turns out, we have only once had anyone worry about this specific idiosyncrasy, because that particular vendor wanted to ship object code (rather than final binaries) to their customers and was worried about this edge condition. The intent of clarifying this edge condition is primarily to quell the worries of software engineers who understand the level of verbatim code copying that a compiler often does, and to help them understand that the full implications of LGPLv2.1 are the same regardless of the details of the compilation progress.

事实证明，我们只有一次有人担心这个特定的怪癖，因为那个特定的供应商想要向他们的客户提供目标代码（而不是最终的二进制代码），并担心这种边缘情况。澄清这种边缘情况的目的主要是为了平息那些了解编译器常常进行逐字复制的软件工程师的担忧，并帮助他们理解LGPLv2.1的全部含义，而不管编译过程的细节如何。

10.7 LGPLv2.1 §6 & LGPLv2.1 §5: Combining the Works

10.7 LGPLv2.1 第6条和第5条：组合作品

Now that we have established a good working definition of works that "use" and works that "are based on" the library, we will consider the rules for distributing these two different works.

既然我们已经建立了一个关于“使用”和“基于”该库的作品的良好工作定义，我们将考虑分发这两种不同作品的规则。

The rules for distributing "works that use the library" are covered in LGPLv2.1 6. LGPLv2.1 6 is much like GPLv2 3, as it requires the release of source when a binary version of the LGPL'd software is released. Of course, it only requires that source code for the library itself be made available. The work that "uses" the library need not be provided in source form. However, there are also conditions in LGPLv2.1 6 to make sure that a user who wishes to modify or update the library can do so.

分发“使用该库的作品”的规则在LGPLv2.1 第6条中有所涉及。LGPLv2.1 第6条类似于GPLv2 第3条，因为它要求在发布LGPL 许可的软件的二进制版本时发布源代码。当然，它只需要该库本身的源代码可用。使用该库的作品不必以源代码形式提供。但是，LGPLv2.1 第6条也有条件，以确保希望修改或更新库的用户可以这样做。

LGPLv2.1 6 lists five choices with regard to supplying library source and granting the freedom to modify that library source to users. We will first consider the option given by 6(b), which describes the most common way currently used for LGPLv2.1 compliance on a "work that uses the library."

LGPLv2.1 6列出了五个选项，关于提供库源代码和向用户授予修改该库源代码的自由。我们将首先考虑6(b)提供的选项，这是目前在“使用该库的作品”上遵守LGPLv2.1的最常见方式。

LGPLv2.1 6(b) allows the distributor of a "work that uses the library" to simply use a dynamically linked, shared library mechanism to link with the library. This is by far the easiest and most straightforward option for distribution. In this case, the executable of the work that uses the library will contain only the "stub code" that is put in place by the shared library mechanism, and at runtime the executable will combine with the shared version of the library already resident on the user's computer. If such a mechanism is used, it must allow the user to upgrade and replace the library with interface-compatible versions and still be able to use the "work that uses the library." However, all modern shared library mechanisms function as such, and thus LGPLv2.1 6(b) is the simplest option, since it does not even require that the distributor of the "work based on the library" ship copies of the library itself.

LGPLv2.1 6(b)允许“使用该库的作品”的分发者简单地使用动态链接共享库机制与该库链接。这是分发的最简单和最直接的选择。在这种情况下，“使用该库的作品”的可执行文件将只包含由共享库机制放置的“存根代码”，在运行时可执行文件将与已经驻留在用户计算机上的共享库的共享版本合并。如果使用这种机制，它必须允许用户升级和替换库并仍然能够使用“使用该库的作品”，前提是它们具有界面兼容版本。然而，所有现代共享库机制都是这样工作的，因此LGPLv2.1 6(b)是最简单的选择，因为它甚至不需要“基于该库的作品”的分发者提供该库本身的副本。

LGPLv2.1 6(a) is the option to use when, for some reason, a shared library mechanism cannot be used. It requires that the source for the library be included, in the typical GPL fashion, but it also has a requirement beyond that. The user must be able to exercise her freedom to modify the library to its fullest extent, and that means recombining it with the "work based on the library." If the full binary is linked without a shared library mechanism, the user must have available the object code for the "work based on the library," so that the user can relink the application and build a new binary.

LGPLv2.1 6(a)是当某些原因无法使用共享库机制时使用的选项。它要求以典型的GPL方式包含该库的源代码，但它还有一个额外的要求。用户必须能够充分行使其修改该库的自由，这意味着将其与“基于该库的作品”重新组合。如果完整的二进制文件没有使用共享库机制进行链接，则用户必须可用“基于该库的作品”的目标代码，以便用户可以重新链接应用程序并构建一个新的二进制文件。

Almost all known LGPL'd distributions exercise either LGPLv2.1 6(a) or LGPLv2.1 6(b). However, LGPLv2.1 6 provides three other options. LGPLv2.1 6(c) allows for a written offer for CCS (akin to [GPLv2 3(b)).] CCS may also be distributed by network under the terms of LGPLv2.1 6(c). Furthermore, under LGPLv2.1 6(e) the distributor may "verify" that the user has already received, or at least that the distributor has already sent to this particular user, the relevant source[^1^].

几乎所有已知的LGPL发行版都使用LGPLv2.1 6(a)或LGPLv2.1 6(b)。但是，LGPLv2.1 6还提供了另外三个选项。LGPLv2.1 6(c)允许书面提供CCS的选择（类似于GPLv2 3(b)）。CCS也可以按照LGPLv2.1 6(c)的条款通过网络分发。此外，在LGPLv2.1 6(e)下，分发者可以“验证”用户已经收到了相关的源代码，或者至少已经向该特定用户发送了相关源代码 [^1^]。

Finally, LGPLv3 *§*6 also requires that:

最后，LGPLv3 第6条还要求：

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License.

^1^ Policy motivations for LGPLv2.1 6(d) are unclear, but it presumably intended to prevent requiring duplicate deliveries in "whole distribution" situations.

^1^ LGPLv2.1 6(d) 的政策动机尚不清楚，但它可能旨在防止在“整个分发”情况下要求重复交付。

This is not identical to the roughly parallel requirements of GPLv2 and GPLv3. Compliance requires slightly different measures with respect to the "credits" or "licenses" or "about" screens in interactive programs.

是的，这与GPLv2和GPLv3的大致类似要求不完全相同。在交互式程序中，符合要求需要采取稍微不同的措施来处理“信用”、“许可”或“关于”屏幕。

10.8 Distributing Works Based On the Library

10.8 分发基于该库的作品

Essentially, "works based on the library" must be distributed under the same conditions as works under full GPL. In fact, we note that LGPLv2.1 2 is nearly identical in its terms and requirements to GPLv2 2.

本质上，“基于库的作品”必须按照完整版GPL下作品的相同条件分发。事实上，我们注意到LGPLv2.1的条款和要求与GPLv2 2几乎完全相同。

There are, however, subtle differences and additions. For example not only is CCS required (as would be with normal versions of GPL), but also the CCS provided must enable a developer to regenerate the modified version of the entire combined work, using with a modified version of the LGPL'd work (as a replacement for the version a distributor provided). For example, LGPL'd code is statically linked to a non-copyleft executable, the required source code must also include sufficient material to split the distributed executable and relink with a modified version of the library.

然而，存在一些细微的差异和添加。例如，不仅需要使用通用公共许可证（CCS）（与普通GPL版本一样），还需要提供的CCS必须使开发人员能够使用LGPL作品的修改版本（作为替换分发者提供的版本），重新生成整个组合作品的修改版本。例如，如果LGPL的代码被静态链接到一个非版权的可执行文件中，所需的源代码还必须包括足够的材料来拆分分发的可执行文件，并与库的修改版本重新链接。

10.9 And the Rest

10.9 其余部分

The remaining variations between the LGPL and the GPL cover the following conditions:

LGPL 和 GPL 之间的其余差异涵盖了以下条件：

Allowing a licensing "upgrade" from the LGPL to the GPL (in LGPLv2.1 3). Note, however, LGPLv2.1 3 allows relicensing of works under its terms instead under the terms of GPLv2-or-later. This provides, for example, a pathway for those who do not want to use code under the requirements of LGPLv2.1 to do so under GPLv2 or GPLv3 at their discretion.

允许从LGPL升级到GPL进行许可证“升级”（在LGPLv2.1 第3条中）。但是请注意，LGPLv2.1 第3条允许将作品重新许可为其条款下的作品，而不是 GPLv2 或更高版本的条款下的作品。例如，这为那些不想按照 LGPLv2.1 要求使用代码的人提供了一条路径，让他们可以根据自己的意愿在 GPLv2 或 GPLv3 下使用该代码。

Binary distribution of the library only, covered in LGPLv2.1 *§*4, which is effectively equivalent to LGPLv2.1 *§*3
LGPLv2.1的第4条涵盖的是仅对库进行二进制分发，其实质上相当于LGPLv2.1的第3条。
Creating aggregates of libraries that are separate and independent works from each other, and dis- tributing them as a unit (in LGPLv2.1 *§*7)
LGPLv2.1的第7条涵盖的是创建库的集合，这些库彼此独立且相互独立，作为一个单元进行分发。

Due to time constraints, we cannot cover these additional terms in detail, but they are mostly straight- forward. The key to understanding LGPLv2.1 is understanding the difference between a "work based on the library" and a "work that uses the library." Once that distinction is clear, the remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in our more extensive GPL unit can be directly applied.

由于时间限制，我们无法详细讨论这些额外条款，但它们大多数都很简单。理解 LGPLv2.1 的关键在于理解“基于库的作品”和“使用库的作品”之间的区别。一旦这种区别清晰明了，LGPLv2.1 的其余部分就足够接近 GPL，以至于我们在更广泛的 GPL 单元中讨论的概念可以直接应用。

CHAPTER 11 LGPLv3

第11章 LGPLv3

LGPLv3 was designed to rectify architectural flaws in the GNU family of licenses. Historically , LGPLv2.1 was a textual modification of GPLv2. Reconciliation of licensing terms upon combination of LGPLv2.1'd and GPLv2'd works is cumbersome, from a licensing bookkeeping perspective.

LGPLv3旨在纠正GNU许可证系列中的结构缺陷。历史上，LGPLv2.1是GPLv2的文本修改。从许可证记账的角度来看，当LGPLv2.1的作品与GPLv2的作品结合时，许可证条款的协调是麻烦的。

LGPLv3 redresses this historical problem through extensive use of GPLv3 7's exception architecture.

LGPLv3通过广泛使用GPLv3第7条的例外结构来纠正这个历史性问题。

LGPLv3 is therefore a set of additional permission to GPLv3.

因此，LGPLv3 是 GPLv3 的一组附加许可。

11.1 Section 0: Additional Definitions

11.1 第 0 条：附加定义

LGPLv3 0 defines the "Library" -- a work that presents one or more interfaces at which a "use" can be made by an "Application." Class inheritance is "deemed" a use of an interface. An "Application," which is other program code using one or more "Library" interfaces can be combined with the code on the other side of the interfaces it uses to form a "Combined Work."

LGPLv3 第0条定义了“库”，这是一种提供一个或多个接口，可以被“应用程序”使用的作品。类继承被视为对接口的使用。“应用程序”是指使用一个或多个“库”接口的其他程序代码，可以与其使用的接口对面的代码结合起来形成“组合作品”。

11.2 LGPLv3 §1: Exception to GPLv3 §3

11.2 LGPLv3 第1条：GPLv3 第3条的例外情况

LGPLv3 *§*1 excepts away the interference with use of LGPLv3 code as part of "effective technological measures" of access limitation for other copyrighted works provided otherwise by GPLv3 *§*3.

LGPLv3 第1条中规定，使用LGPLv3代码作为“有效技术措施”限制其他受版权保护作品的访问的一部分，不能排除GPLv3 第3条的规定。

11.3 LGPLv3 §2: Conveying Modified Versions

11.3 LGPLv3 §2：传送修改后的版本

LGPLv3 2 continues to require, as LGPLv2.1 2(d) requires, that the Library not be modified to require keys, tokens, tables, or other global non-argument data unrelated to function. This is again stated as a "good faith effort" requirement, but failure to cure on notice is strong evidence of the absence of good faith. LGPLv3 *§*2(b) permits removal of the permissions entirely (as prescribed by GPLv3 *§*7); however, such removal reduces the license of the entire covered work back to pure GPLv3. Thus, exercising LGPLv3 *§*2(b) as a compliance alternative to LGPLv3 *§*2(a) likely creates more compliance obligations than it removes.

LGPLv3 第2条继续要求，与LGPLv2.1 2(d)类似，库不能被修改以需要与函数无关的密钥、令牌、表格或其他全局非参数数据。这再次被规定为“诚信努力”的要求，但是在通知后未能纠正的情况是缺乏诚信的强有力证据。LGPLv3 2(b)允许完全删除权限（如GPLv3 第7条所规定的），但是这种删除会将整个被覆盖作品的许可证还原为纯GPLv3。因此，将LGPLv3 2(b)作为符合要求的替代方案，用于替代LGPLv3 2(a)，可能会创建比它所消除的符合要求的义务更多的符合要求的义务。

11.4 LGPLv3 §3: Object Code Incorporating Material from Li- brary Header Files

11.4 LGPLv3 第3条：目标代码包含来自库头文件的材料

LGPLv3 3's front matter assures incorporation of smaller header files into non-copylefted object code can proceed unimpeded. More complex header files (those that do not meet the limitations provided in the section), can still be incorporated into object code, a copy of appropriate licensing information must accompany distribution (per LGPLv3 *§*3(a--b).

LGPLv3 第3条的前言确保较小的头文件可以无障碍地合并到非版权对象代码中。更复杂的头文件（不符合该部分提供的限制的头文件）仍然可以合并到对象代码中，但必须附带适当的许可证信息副本进行分发（根据LGPLv3 3(a--b)）。

11.5 LGPLv3 §4: Combined Works

11.5 LGPLv3 第4条：组合作品

LGPLv3 4 is the combination permission at the heart of LGPLv3. It restates the license limitation provision of LGPLv2.1 2 to clarify that the terms on the Combined Work may not prohibit user modification of the Library code, or the debugging of such modifications to the Library code by means of whatever reverse engineering is necessary.

LGPLv3 第4条是LGPLv3的核心组合授权。它重新表述了LGPLv2.1 第2条的许可限制规定，以澄清组合作品的条款不能禁止用户修改库代码，或通过必要的逆向工程手段对库代码的这些修改进行调试。

LGPLv3 4(d)(0) contains the source provision requirement, for the Minimal Corresponding Source, which "means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version [of the Library]". The alternative to the provision of source code is distribution by way of the "shared library" mechanism under LGPLv3 4(d)(1), described with respect to LGPLv2.1 6.

LGPLv3 4(d)(0)包含源代码条款要求，即“最小对应源码”，这意味着组合作品的对应源码，不包括在分离状态下基于应用程序而不是基于（库的）链接版本的任何部分的源代码。提供源代码的替代方案是通过LGPLv3 4(d)(1)中描述的“共享库”机制进行分发，该机制与LGPLv2.1 第6条有关。

In addition, LGPLv3 4(e) requires the delivery of "installation information" required to install the modified version of the Library in "user products" under GPLv3 6. Where Library Minimal Corresponding Source is not made available under LGPLv3 4(d)(1), LGPLv3 4(e) reaffirms that "installation information" must still be compliantly delivered under the terms of GPLv3 6.

此外，LGPLv3 4(e)要求提供“安装信息”，以便根据 GPLv3 第6条在“用户产品”中安装修改版本的库。如果库的最小对应源代码未在LGPLv3 4(d)(1)下提供，LGPLv3 4(e)重申必须按照 GPLv3 第6条合规地提供“安装信息”。

All other provisions of GPLv3 are in force as previously described, and are not excepted by the additional permission granted in LGPLv3.

除了LGPLv3授予的附加权限之外，GPLv3的所有其他规定均如先前所述生效，并没有任何例外。

If the distributor of the combined work intends not to distribute or offer the source code of the LGPL'd components, the LGPL'd work must be separately distributed (subject to source code delivery requirements as part of that separate distribution) and packaged in a "shared library" mechanism, which means that it:

如果组合作品的分发者不打算分发或提供 LGPL 组件的源代码，LGPL 作品必须单独分发（以源代码交付为准要求作为该单独分发的一部分）并打包在 “共享库”机制，这意味着它：

4(d)(1): uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and

如果组合作品的分发者不打算分发或提供LGPL组件的源代码，则必须单独分发LGPL作品（作为该单独分发的一部分，需满足源代码交付要求），并将其打包在“共享库”机制中，这意味着：

4(d)(2): will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

LGPLv3 4(d)(2)：如果用户安装了与创建该作品的版本兼容的修改版本的库，那么作品将能够与该修改版本正确地运行。

Taken all together, LGPLv3 *§*4's primary implications for redistributors are two-fold, as follows:

综合而言，LGPLv3 第4条对于再分发者的主要影响有以下两个方面：

If you create a program that links through a shared library mechanism to a work that is separately distributed under LGPLv3, then you can distribute the resultant program under a license of your choice and you need not convey the LGPLv3'd work's source code. If you distribute the library along with your program, or are the separate distributor of the work in another context or as another product, you must distribute its corresponding source under the terms of LGPLv3 or GPLv3-or-later.

如果你创建一个通过共享库机制链接到在LGPLv3下单独分发的作品的程序，那么你可以将生成的程序在你选择的许可下分发，而且你不需要传达LGPLv3下的作品源代码。如果你将库与你的程序一起分发，或者在另一个上下文或另一个产品中作为独立分发者分发作品，那么你必须根据LGPLv3或GPLv3或后续版本的条款分发相应的源代码。

If you choose to statically link or otherwise combine your program with an LGPLv3'd work via mech- anisms other than a shared library, you may choose your own license for the work provided the license terms limitations for user modification, reverse engineering and debugging are met, and given that the LGPL'd components are still governed by LGPL's terms. You must offer or provide CCS for the LGPL'd components. The source code material provided must be sufficient to regenerate the combined work with a user-modified version of the LGPL'd components.

如果您选择通过除共享库以外的机制静态链接或以其他方式组合您的程序与LGPLv3的作品，则可以选择自己的许可证，前提是符合用户修改、反向工程和调试的许可条款限制，并且LGPL的组件仍受LGPL的条款约束。您必须提供或提供LGPL组件的CCS。提供的源代码材料必须足以使用LGPL的组件的用户修改版本重新生成组合工作。

CHAPTER 12　INTEGRATING THE GPL INTO BUSINESS PRACTICES

第12章将 GPL 整合到商业实践中

Since GPL'd software is now extremely prevalent through the industry, it is useful to have some basic knowledge about using GPL'd software in business and how to build business models around GPL'd software.

由于 GPL 授权的软件现在在行业中非常普遍，因此了解在商业中使用GPL授权的软件以及如何围绕GPL授权的软件构建商业模型是非常有用的。

12.1 Using GPL'd Software In-House

12.1 在企业内部使用 GP L授权的软件

As discussed in Sections 3.1 and 7.2 of this tutorial, the GPL only governs the activities of copying, modifying and distributing software programs that are not governed by the license. Thus, in FSF's view, simply installing the software on a machine and using it is not controlled or limited in any way by the GPL. Using Free Software in general requires substantially fewer agreements and less license compliance activity than any known proprietary software.

正如本教程第3.1节和7.2节中所讨论的，GPL仅控制未受许可证管辖的软件程序的复制、修改和分发活动。因此，根据FSF的观点，简单地在机器上安装软件并使用它并不受GPL的任何控制或限制。总的来说，使用自由软件所需的协议和许可证合规活动比任何已知的专有软件都要少得多。

Even if a company engages heavily in copying the software throughout the enterprise, such copying is not only permitted by GPLv2 1 and 3, but it is encouraged! If the company simply deploys unmodified (or even modified) Free Software throughout the organization for its employees to use, the obligations under the license are very minimal. Using Free Software has a substantially lower cost of ownership --- both in licensing fees and in licensing checking and handling -- than the proprietary software equivalents.

即使公司大量复制软件到企业中，这种复制不仅在GPLv2的第1条和第3条中是允许的，而且还被鼓励！如果公司只是部署未经修改（甚至经过修改的）自由软件供员工使用，则许可证下的义务非常少。使用自由软件的拥有成本（包括许可证费用以及许可证检查和处理方面）要比专有软件的等效物低得多。

12.2 Business Models

12.2 商业模式

Using Free Software in house is certainly helpful, but a thriving market for Free Software-oriented business models also exists. There is the traditional model of selling copies of Free Software distributions. Many companies make substantial revenue from this model. Some choose this model because they have found that for higher-end hardware, the profit made from proprietary software licensing fees is negligible. The real profit is in the hardware, but it is essential that software be stable, reliable and dependable, and the users be allowed to have unfettered access to it. Free Software, and GPL'd software in particular, is the right choice. For instance IBM can be assured that proprietary versions of the their software will not exist to compete on their hardware.

在公司内部使用自由软件确实是有帮助的，但也存在一个以自由软件为导向的商业模式兴旺的市场。有传统的模式是销售自由软件发行版的副本。许多公司从这个模式中获得了大量的收入。一些公司选择这种模式，因为他们发现对于高端硬件来说，从专有软件许可费中获得的利润微不足道。真正的利润在于硬件，但是软件必须是稳定、可靠和可信赖的，并且用户可以自由获取它。自由软件，特别是GPL软件，是正确的选择。例如，IBM可以确信，他们的软件的专有版本不会存在以与他们的硬件竞争。

For example, charging a "convenience fee" for Free Software, when set at a reasonable price (around $60 or so), can produce some profit. Even though Red Hat's system is fully downloadable on their Web site, people still go to local computer stores and buy copies of their box set, which is simply a printed version of the manual (available under a Free license as well) and the Free Software system it documents.

例如，对于自由软件收取“便利费”，如果价格合理（大约为60美元左右），可以产生一些利润。尽管Red Hat的系统可以在他们的网站上完全下载，但人们仍然会去当地的计算机商店购买他们的盒装套装，这只是手册的打印版本（同样可在自由许可下获得）和所记录的自由软件系统。

Custom support, service, and software improvement contracts are the most widely used models for GPL'd software. The GPL is central to their success, because it ensures that the code base remains common, and that large and small companies are on equal footing for access to the technology. Consider, for example, the GNU Compiler Collection (GCC). Cygnus Solutions, a company started in the early 1990s, was able to grow steadily simply by providing services for GCC --- mostly consisting of new ports of GCC to different or new, embedded targets. Eventually, Cygnus was so successful that it was purchased by Red Hat where it remains a profitable division.

定制支持、服务和软件改进合同是GPL软件最广泛使用的模式。GPL对于它们的成功至关重要，因为它确保代码库保持共同，并且大大小小的公司在访问技术方面处于平等地位。例如，考虑GNU编译器集合（GCC）。上世纪90年代初创立的Cygnus Solutions公司，仅通过为GCC提供服务（主要包括将GCC移植到不同的或新的嵌入式目标）就能够稳步增长。最终，Cygnus取得了如此成功，以至于被Red Hat收购，现在它仍然是一个有利可图的部门。

However, there are very small companies that compete in this space. Modern industry demands the trust created by GPL protected code-bases. Companies can cooperate on the software and improve it for everyone. Meanwhile, companies who rely on GCC for their work are happy to pay for improvements, and for ports to new target platforms. Nearly all the changes fold back into the standard versions, and those forks that exist remain freely available.

然而，在这个领域中也有一些非常小的公司在竞争。现代产业需要由GPL保护的代码库所创造的信任。公司可以合作开发软件，并为每个人都进行改进。与此同时，那些依赖GCC进行工作的公司很乐意为改进和移植到新的目标平台付费。几乎所有的变化都会被折叠回标准版本中，而那些存在的分支仍然可以自由获取。

A final common business model that is perhaps the most controversial is proprietary relicensing of a GPL'd code base. This is only an option for software in which a particular entity holds exclusive rights to relicense.⁴³ As discussed earlier in this tutorial, a copyright holder is permitted under copyright law to license a software system under her copyright as many different ways as she likes to as many different parties as she wishes.

最后一个常见的商业模式可能是最具争议的，那就是专有软件重新许可一个GPL的代码库。这只是适用于那些拥有重新许可排他性权利的软件。⁴³ 如本教程前面所讨论的，根据版权法，版权持有人可以根据自己的意愿以任何不同的方式将软件系统许可给尽可能多的不同方。

Some companies use this to their financial advantage with regard to a GPL'd code base. The standard version is available from the company under the terms of the GPL. However, parties can purchase separate proprietary software licensing for a fee.

一些公司利用这一点在财务上获得了利益，与GPL许可的代码库相关。标准版本可以在公司按照GPL条款的条件下获取。但是，各方可以通过付费购买单独的专有软件许可证。

This business model is at best problematic and at worst predatory because it means that the GPL'd code base must be developed in a somewhat monolithic way, because volunteer Free Software developers may be reluctant to assign their copyrights to the company because it will not promise to always and forever license the software as Free Software. Indeed, the company will surely use such code contributions in proprietary versions licensed for fees.

这种商业模式充其量是有问题的，最坏的情况下是掠夺性的，因为它意味着GPL许可的代码库必须以某种集中的方式进行开发，因为志愿的自由软件开发人员可能不愿将其版权分配给公司，因为公司不会承诺永远将软件许可为自由软件。事实上，该公司肯定会将这样的代码贡献用于收费许可的专有版本中。

12.3 Ongoing Compliance

12.3 持续合规

GPL compliance is in fact a very simple matter --- much simpler than typical proprietary software agreements and EULAs. Usually, the most difficult hurdle is changing from a proprietary software mindset to one that seeks to foster a community of sharing and mutual support. Certainly complying with the GPL from a users' perspective gives substantially fewer headaches than proprietary license compliance.

事实上，GPL合规实际上是一个非常简单的问题 —— 比典型的专有软件协议和最终用户许可协议(EULAs)简单得多。通常，最困难的障碍是从专有软件的心态转变为寻求培育共享和相互支持社区的心态。从用户的角度来看，遵守GPL比遵守专有许可证要简单得多，减少了很多麻烦。

For those who go into the business of distributing modified versions of GPL'd software, the burden is a bit higher, but not by much. The glib answer is that by releasing the whole product as Free Software, it is always easy to comply with the GPL. However, admittedly to the dismay of FSF, many modern and complex software systems are built using both proprietary and GPL'd components that are clearly and legally separate and independent works, merely aggregated together on the same device.

对于那些从事分发修改版GPL软件的业务的人来说，负担略微增加，但并不多。简单的答案是，通过将整个产品作为自由软件发布，始终很容易遵守GPL。然而，诚然让自由软件基金会(FSF)失望的是，许多现代复杂的软件系统是使用既有专有又有GPL组件构建的，这些组件在法律上明显独立并独立存在，仅仅是聚合在同一设备上。

However, it sometimes is easier, quicker, and cheaper to simply improve an existing GPL'd application than to start from scratch. In exchange for this amazing benefit, the license requires that the modifier gives back to the commons that made the work easier in the first place. It is a reasonable trade-off and a way to help build a better world while also making a profit.

然而，有时候，与其从头开始，改进现有的GPL软件可能会更容易、更快捷、更便宜。为了换取这一惊人的好处，许可证要求修改者将工作的成果回馈给共同体，因为共同体在第一时间让这项工作变得更容易。这是一个合理的权衡和一种帮助建设更美好世界同时也获得利润的方式。

Note that FSF does provide services to assist companies who need assistance in complying with the GPL. You can contact FSF's GPL Compliance Labs at licensing@fsf.org>.

请注意，自由软件基金会(FSF)提供帮助企业遵守GPL的服务。您可以联系FSF的GPL合规实验室，电子邮件地址为licensing@fsf.org。

If you are particularly interested in matters of GPL compliance, we recommend the next two parts, which include both recommendations on good compliance and compliance case studies.

如果您特别关心GPL合规问题，我们建议阅读接下来的两个部分，其中包括有关良好合规的建议和合规案例研究。

Part II A Practical Guide to GPL Compliance

第2部分 GPL 合规实用指南

EXECUTIVE SUMMARY

概要

This is a guide to effective compliance with the GNU General Public License (GPL) and related licenses. Copyleft advocates usually seek to assist the community with GPL compliance cooperatively. This guide focuses on complying from the start, so that readers can learn to avoid enforcement actions entirely, or, at least, minimize the negative impact when enforcement actions occur. This guide introduces and explains basic legal concepts related to the GPL and its enforcement by copyright holders. It also outlines business practices and methods that lead to better GPL compliance. Finally, it recommends proper post-violation responses to the concerns of copyright holders.

这是一份有关有效遵守GNU通用公共许可证(GPL)和相关许可证的指南。Copyleft倡导者通常希望通过合作来协助社区进行GPL合规。本指南侧重于从一开始就合规，以便读者可以学习避免完全执行行动，或者至少在执行行动发生时将负面影响最小化。本指南介绍并解释与GPL及其版权持有者的执行相关的基本法律概念。它还概述了导致更好的GPL合规的业务实践和方法。最后，它建议适当的违规后应对版权持有者的关切的措施。

CHAPTER 13 BACKGROUND

第13章背景

Copyright law grants exclusive rights to authors. Authors who chose copyleft seek to protect the freedom of users and developers to copy, share, modify and redistribute the software. However, copyleft is ultimately implemented through copyright, and the GPL is primarily and by default a copyright license. (See [1.2] for more about the interaction between copyright and copyleft.) Copyright law grants an unnatural exclusive control to copyright holders regarding copyright-controlled permissions related to the work. Therefore, copyright holders (or their agents) are the ultimately the sole authorities to enforce copyleft and protect the rights of users. Actions for copyright infringement are the ultimate legal mechanism for enforcement. Therefore, copyright holders, or collaborative groups of copyright holders, have historically been the actors in GPL enforcement.

版权法授予作者独占权利。选择使用copyleft的作者试图保护用户和开发人员复制、分享、修改和重新分发软件的自由。然而，copyleft最终是通过版权实施的，而GPL主要且默认是一种版权许可证。（有关版权和copyleft之间相互作用的更多信息，请参见[1.2]。）版权法在涉及作品的版权受控权限方面授予版权持有人不自然的独占控制。因此，版权持有人（或其代理人）最终是唯一的权力机构，用于执行copyleft并保护用户的权利。版权侵权行为是执行的最终法律机制。因此，版权持有人或版权持有人的协作团体在GPL执行中一直是行动者。

The earliest of these efforts began soon after the GPL was written by Richard M. Stallman (RMS) in 1989, and consisted of informal community efforts, often in public Usenet discussions.⁴⁴ Over the next decade, the Free Software Foundation (FSF), which holds copyrights in many GNU programs, was the only visible entity actively enforcing its GPL'd copyrights on behalf of the software freedom community. FSF's enforcement was generally a private process; the FSF contacted violators confidentially and helped them to comply with the license. Most violations were pursued this way until the early 2000's.

最早的这些努力始于1989年Richard M. Stallman（RMS）撰写的GPL之后不久，这些努力由非正式的社区努力组成，通常在公共的Usenet讨论中进行。⁴⁴ 在接下来的十年中，自由软件基金会（FSF）在为软件自由社区代表其GPL版权方面是唯一一个可见的实体。FSF的执行通常是一个私人流程；FSF会与侵权者进行保密联系，并帮助他们遵守许可证。大多数侵权行为都是通过这种方式来处理的，直到2000年代初期。

By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in embedded devices such as wireless routers. During this period, public ridicule of violators in the press and on Internet fora supplemented ongoing private enforcement and increased pressure on businesses to comply. In 2003, the FSF formalized its efforts into the GPL Compliance Lab, increased the volume of enforcement, and built community coalitions to encourage copyright holders to together settle amicably with violators. Beginning in 2004, Harald Welte took a more organized public enforcement approach and launched gpl-violations.org, a website and mailing list for collecting reports of GPL violations. On the basis of these reports, Welte successfully pursued many enforcement actions in Europe, including formal legal action. Harald earns the permanent fame as the first copyright holder to bring legal action in a court regarding GPL compliance.

到那个时候，基于Linux的系统，例如GNU/Linux和BusyBox/Linux已经非常普遍，特别是在无线路由器等嵌入式设备中。在这段时间内，对违规者的公开嘲笑在新闻媒体和互联网论坛上进行，补充了正在进行的私人执法，并增加了对企业遵守许可证的压力。2003年，FSF将其努力正式组织成GPL合规实验室，增加了执行量，并建立社区联盟，鼓励版权持有者与侵权者友好地共同解决问题。从2004年开始，Harald Welte采取了更有组织的公开执行方法，并推出了 gpl-violations.org，这是一个收集GPL侵权报告的网站和邮件列表。在这些报告的基础上，Welte成功地在欧洲追究了许多执行行动，包括正式的法律行动。Harald因成为第一个在GPL合规方面在法院提起法律诉讼的版权持有人而永久获得了名声。

In 2007, two copyright holders in BusyBox, in conjunction with the Software Freedom Conservancy ("Conservancy"), filed the first copyright infringement lawsuit based on a violation of the GPL in the USA. While lawsuits are of course quite public, the vast majority of Conservancy's enforcement actions are resolved privately via cooperative communications with violators. As both FSF and Conservancy have worked to bring individual companies into compliance, both organizations have encountered numerous violations resulting from preventable problems such as inadequate attention to licensing of upstream software, misconceptions about the GPL's terms, and poor communication between software developers and their management. This document highlights these problems and describe best practices to encourage corporate Free Software users to reevaluate their approach to GPL'd software and avoid future violations.

2007年，BusyBox的两个版权持有人与软件自由保护协会（“协会”）一起，根据违反GPL的行为在美国提起了第一起版权侵权诉讼。虽然诉讼当然是相当公开的，但绝大多数协会的执法行动都是通过与侵权者的合作沟通私下解决的。由于FSF和协会都致力于使各个公司符合许可证，因此两个组织都遇到了许多违规问题，这些问题可以通过避免诸如不充分关注上游软件的许可证、对GPL条款的误解以及软件开发人员和他们的管理之间的沟通不良等问题而防止。本文强调了这些问题，并描述了最佳实践，以鼓励企业自由软件用户重新评估其对GPL软件的处理方式并避免未来的违规行为。

Both FSF and Conservancy continue GPL enforcement and compliance efforts for software under the GPL, the GNU Lesser Public License (LGPL) and other copyleft licenses. In doing so, both organizations have found that most violations stem from a few common, avoidable mistakes. All copyleft advocates hope to educate the community of commercial distributors, redistributors, and resellers on how to avoid violations in the first place, and to respond adequately and appropriately when a violation occurs.

FSF和协会都继续对使用GPL、GNU Lesser Public License (LGPL)和其他copyleft许可证的软件进行执行和合规工作。在执行过程中，两个组织发现大多数违规行为都源于一些常见的可避免错误。所有copyleft的支持者都希望教育商业分发者、再分发者和转售商社区如何避免首次违规，并在发生违规时做出足够和适当的回应。

13.1 Who Has Compliance Obligations?

13.1 谁有合规义务？

All distributors of modified or unmodified versions of copylefted works unmodified versions of the works have compliance obligations. Common methods of modifying the works include innumerable common acts, such as:

所有分销修改或未修改的copyleft作品的分发者都有合规义务。修改作品的常见方法包括无数常见的行为，例如：

embedding those works as executable copies into a device,
将这些作品作为可执行副本嵌入到设备中，
transferring a digital copy of executable copies to someone else,
将可执行副本的数字副本转移给其他人，
posting a patch to the copylefted software to a public mailing list.
将著佐权软件的补丁发布到公共邮件列表。

Such distributors have obligations to (at least) the users to whom they (or intermediary parties) distribute those copies. In some cases, distributors have obligations to third parties not directly receiving their distribution of the works (depending on the distributors chosen licensing options, as described later in [15.1).] In addition, distributors have compliance obligations to upstream parties, such as preservation of reasonable legal notices embedded in the code, and appropriate labeling of modified versions.

这些分发者有义务向他们（或中间方）分发这些副本的用户（至少）承担责任。在某些情况下，分发者对未直接接收其作品分发的第三方也有义务（取决于分发者选择的许可选项，如稍后在15.1中所述）。此外，分发者还有向上游方的合规义务，例如保留代码中嵌入的合理法律声明，并适当标记修改版本。

Online service providers and distributors alike have other compliance obligations. In general, they must refrain from imposing any additional restrictions on downstream parties. Most typically, such compliance problems arise from "umbrella licenses:" EULAs, or sublicenses that restrict downstream users' rights under copyleft. (See 7.3 and 9.13).

在线服务提供商和分发商都有其他的合规义务。通常来说，他们必须避免对下游方施加任何额外的限制。这种合规问题最常见的来源是“伞形许可证”：即限制下游用户在copyleft下享有的权利的最终用户许可协议（EULA）或子许可证。（详见7.3和9.13）。

Patent holders having claims reading on GPL'd works they distribute must refrain from enforcing those claims against parties to whom they distribute. Furthermore, patent holders holding copyrights on GPLv3'd works must further grant an explicit patent license for any patent claims reading on the version they dis- tributed, and therefore cannot enforce those specific patent claims against anyone making, using or selling a work based on their distributed version. All parties must refrain from acting as a provider of services or distributor of licensed works if they have accepted, or had imposed on them by judicial action, any legal conditions that would prevent them from meeting any obligation under GPL. (See § 7.5, § 9.14 and § 9.15.

在分发 GPL 的作品时具有专利权的人必须避免对他们分发的任何一方强制执行其专利权声明。此外，持有 GPLv3 的版权者还必须为其分发版本中与专利有关的任何专利声明明确授予专利许可，因此不能对任何基于其分发版本进行制作、使用或销售的人执行这些特定的专利声明。如果任何一方接受或由司法行为强制执行任何法律条件以阻止其履行 GPL 下的任何义务，则所有各方都必须避免充当服务提供者或许可作品的分发者。 (参见 7.5, 9.14 和 9.15.)

13.2 What Are The Risks of Non-Compliance?

13.2 不合规的风险是什么？

Copyleft experts have for decades observed a significant mismatch between the assumptions most businesses make about copyleft compliance and the realities. Possibly due to excessive marketing of proprietary tools and services from the for-profit compliance industry, businesses perennially focus on the wrong concerns. This tutorial seeks to educate those businesses about what actually goes wrong, what causes disputes, and how to resolve those disputes.

多年来，知识产权专家一直观察到，大多数企业对于版权许可合规性的假设与实际情况存在显著的不匹配。可能是由于盈利合规行业过度营销专有工具和服务，企业经常关注错误的问题。本教程旨在教育这些企业关注实际出现的问题、引发争议的原因以及如何解决这些争议。

Many businesses currently invest undue resources to avoid unlikely risks that have low historical incidence of occurrence and low cost of remediation, while leaving unmanaged the risks that have historically resulted in all the litigation and other adverse outcomes. For example, some "compliance industry"⁴⁵ vendors insist that great effort must be expended to carefully list, in the menus or manuals of embedded electronics products, copyright notices for every last copyright holder that contributed to the Free Software included in the product. While nearly all Free Software licenses, including copylefts like GPL, require preservation and display of copyright notices, failure to meet this specific requirement is trivially remedied. Therefore, businesses should spend just reasonable efforts to properly display copyright notices, and note that failure to do so is simply remedied: add the missing copyright notice!

许多企业目前投入过多的资源来避免那些历史上发生率低、补救成本低的不太可能发生的风险，而忽略了那些历史上导致所有诉讼和其他不利后果的风险。例如，一些“合规产业”⁴⁵ 的供应商坚持认为，必须付出极大努力，在嵌入式电子产品的菜单或手册中仔细列出每个为产品中的自由软件做出贡献的版权持有者的版权声明。虽然几乎所有的自由软件许可证，包括类似GPL的Copyleft，都要求保存和显示版权声明，但未能满足这一具体要求是很容易纠正的。因此，企业应该花费合理的努力来正确显示版权声明，并注意未能这样做的问题是很容易解决的：只需添加缺少的版权声明即可！

13.3 Understanding Who's Enforcing

13.3 了解谁在执法

The mismatch between actual compliance risk and compliance risk management typically results from a misunderstanding of licensor intentions. For-profit businesses often err by assuming other actors have kindred motivations. The primary enforcers of the GPL, however, have goals that for-profit businesses will find strange and perhaps downright alien.

实际合规风险与合规风险管理之间的不匹配通常是由于对许可方意图的误解而导致的。营利性企业经常错误地假设其他参与者有类似的动机。然而，GPL的主要执行者的目标可能对营利性企业来说会感到奇怪，甚至完全陌生。

Specifically, community-oriented GPL enforcement organizations (called "COGEOs" throughout the re- mainder of this tutorial) are typically non-profit charities (such as the FSF and Software Freedom Conser- vancy) who declare, as part of their charitable mission, advancement of software freedom for all users. In the USA, these COGEOs are all classified as charitable under the IRS's 501(c)(3) designation, which is reserved for organizations that have a mission to enhance the public good.

具体来说，在这个教程的剩余部分中称为“COGEOs”的社区导向的GPL执法组织通常是非营利性慈善机构（例如FSF和软件自由保护协会），它们宣布作为其慈善使命，推进所有用户的软件自由。在美国，这些COGEOs都被归类为非营利性慈善机构，根据IRS的501(c)(3)规定，这种分类是为了那些旨在增进公共福利的组织而保留的。

As such, these COGEOs enforce GPL primarily to pursue the policy goals and motivations discussed throughout this tutorial: to spread software freedom further. As such, COGEOs are unified in their primary goal to bring the violator back into compliance as quickly as possible, and redress the damage caused by the violation. COGEOs are steadfast in their position in a violation negotiation: comply with the license and respect freedom.

因此，这些COGEOs主要通过执行GPL来追求本教程中讨论的政策目标和动机：进一步推广软件自由。因此，COGEOs在其主要目标上是一致的，即尽快将违规者带回遵守许可证的轨道，并补救违规造成的损害。在违规协商中，COGEOs坚定地主张：遵守许可证并尊重自由。

Certainly, other entities do not share the full ethos of software freedom as institutionalized by COGEOs, and those entities pursue GPL violations differently. Oracle, a company that produces the GPL'd MySQL database, upon discovering GPL violations typically negotiates a proprietary software license separately for a fee. While this practice is not one a COGEO would undertake nor endorse, a copyleft license technically permits this behavior. To put a finer point on this practice already discussed in [12.2,] copyleft advocates usually find copyleft enforcement efforts focused on extract alternative proprietary licenses distasteful at best, and a corrupt manipulation of copyleft at worst. Much to the advocates' chagrin, such for-profit enforcement efforts seem to increase rather than decrease.

当然，其他机构并不完全分享COGEO所制定的软件自由理念，这些机构以不同的方式追究GPL违规行为。甲骨文公司是一个提供GPL的MySQL数据库的公司，发现GPL违规行为后通常会单独协商收费的专有软件许可证。虽然这种做法不是COGEO会采取或支持的做法，但著佐权许可证从技术上允许这种行为。更进一步地，正如在12.2中已经讨论过的这种做法，著佐权的倡导者通常认为，着重提取替代专有许可证的著佐权执法行动充其量令人不快，最坏的情况是对著佐权的腐败操纵。令倡导者感到烦恼的是，这样的营利性执法行动似乎越来越多，而不是减少。

Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly assume that all copyright holders seek royalties. Businesses therefore focus on the risk of so-called "accidental" (typically as the result of unsupervised activity by individual programmers) infringe copyright by incorporating "snippets" of copylefted code into their own proprietary computer program. "Compliance industry" flagship products, therefore, focus on "code scanning" services that purport to detect accidental inclusions. Such effort focuses on proprietary software development and view Free Software as a foreign interloper. Such approach not only ignores current reality that many companies build their products directly on major copylefted projects (e.g., Android vendor's use of the kernel named Linux), but also creates a culture of fear among developers, leading them into a downward spiral of further hiding their necessary reliance on copylefted software in the company's products.

因此，毫不奇怪，采用GPL授权软件的营利企业通常会错误地认为所有版权持有人都寻求版税。因此，企业关注所谓的“意外”侵犯版权的风险（通常是由个人程序员的监管不足导致），他们将“片段”的通用公共授权代码合并到自己的专有计算机程序中。因此，“合规产业”的旗舰产品便集中于声称能够检测到这些意外合并的“代码扫描”服务。这种做法关注的是专有软件开发，并将自由软件视为一个外来者。这种方法不仅忽略了当前的现实情况，即许多公司直接在重要的通用公共授权项目（例如，Android供应商使用名为Linux的内核）上构建他们的产品，而且还在开发人员之间创造了一种恐惧文化，导致他们在公司产品中进一步隐藏其对通用公共授权软件的必要依赖。

Fortunately, COGEOs regard GPL compliance failures as an opportunity to improve compliance. Every compliance failure downstream represents a loss of rights by their users. The COGEOs are the guardian of its users' and developers' rights. Their activity seeks to restore those rights, and to protect the project's contributors' intentions in the making of their software.

幸运的是，COGEO（社区导向的GPL执行组织）将GPL合规失败视为提高合规性的机会。每一次合规失败都代表着用户失去了权利。COGEO是其用户和开发人员权利的守护者。他们的活动旨在恢复这些权利，并保护项目贡献者在制作软件时的意图。

CHAPTER 14 BEST PRACTICES TO AVOID COMMON VIOLATIONS

第14章避免常见违规的最佳实践

Unlike highly permissive licenses (such as the ISC license), which typically only require preservation of copy- right notices, licensees face many important requirements from the GPL. These requirements are carefully designed to uphold certain values and standards of the software freedom community. While the GPL's re- quirements may initially appear counter-intuitive to those more familiar with proprietary software licenses, by comparison, its terms are in fact clear and quite favorable to licensees. Indeed, the GPL's terms actually simplify compliance when violations occur.

GPL violations occur (or, are compounded) most often when companies lack sound practices for the incorporation of GPL'd components into their internal development environment. This section introduces some best practices for software tool selection, integration and distribution, inspired by and congruent with software freedom methodologies. Companies should establish such practices before building a product based on GPL'd software.⁴⁶

当公司在其内部开发环境中整合GPL组件时，GPL违规（或加剧）的情况最常见于公司缺乏可靠的实践。本节介绍了一些基于软件自由方法的软件工具选择、集成和分发的最佳实践。公司应在基于GPL软件构建产品之前建立这些实践。⁴⁶

14.1 Evaluate License Applicability

14.1 评估许可证适用性

Political discussion about the GPL often centers around determining the "work" that must be licensed under GPL, or in other words, "what is the derivative and/or combined work that was created". Nearly ever esoteric question asked by lawyers seek to consider that question ⁴⁷ (perhaps because that question explores exciting legal issues while the majority of the GPL deals with much more mundane ones). Of course, GPL was designed primarily to embody the licensing feature of copyleft.

关于GPL的政治讨论通常集中于确定必须在GPL下许可的“作品”，换句话说，“创作了什么派生和/或组合作品”。律师们几乎询问了每一个奇怪的问题，以考虑这个问题⁴⁷（也许是因为这个问题探讨了令人兴奋的法律问题，而GPL的大多数内容都涉及更为平凡的问题）。当然，GPL的设计主要是体现copyleft的许可特性。

However, most companies who add complex features to and make combinations with GPL'd software are already well aware of their more complex obligations under the license that require complex legal analysis. And, there are few companies overall that engage in such activities. Thus, in practical reality, this issue is not relevant to the vast majority of companies distributing GPL'd software.

然而，大多数向GPL软件添加复杂功能并与之组合的公司已经充分了解许可证下更复杂的义务，这些义务需要进行复杂的法律分析。而且，总体上从事此类活动的公司很少。因此，在实际情况下，这个问题对于分发GPL软件的绝大多数公司来说并不相关。

Thus, experienced GPL enforcers find that few redistributors' compliance challenges relate directly to combined work issues in copyleft. Instead, the distributions of GPL'd systems most often encountered typically consist of a full operating system including components under the GPL (e.g., Linux, BusyBox) and components under the LGPL (e.g., the GNU C Library). Sometimes, these programs have been patched or slightly improved by direct modification of their sources, and thus the result is unequivocally a modified version. Alongside these programs, companies often distribute fully independent, proprietary programs, developed from scratch, which are designed to run on the Free Software operating system but do not combine with, link to, modify, derive from, or otherwise create a combined work with the GPL'd components.⁴⁸ In the latter case, where the work is unquestionably a separate work of creative expression, no copyleft provisions are invoked. The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a combined, derivative, and/or modified version of the work, but rather, issues related to distribution and conveyance of binary works based on GPL'd source, but without Complete, Corresponding Source.

因此，有经验的GPL执法者发现，很少有再分发者的合规挑战直接涉及到在Copyleft中的组合工作问题。相反，最常遇到的是包含GPL组件（例如Linux，BusyBox）和LGPL组件（例如GNU C库）的完整操作系统的分发。有时，这些程序通过直接修改其源代码进行修补或略微改进，因此结果是明确的修改版本。除了这些程序外，公司通常还会分发完全独立的专有程序。即那些独立开发的软件，旨在运行在自由软件操作系统上，但不与GPL的组件组合，链接，修改，派生或以其他方式创建一个结合作品。⁴⁸ 在后一种情况下，如果作品毫无疑问是一份独立的创意表达作品，则不会引用版权保护规定。因此，在这种情况下，所面临的核心合规问题不是讨论作品是否为组合，派生或修改版本，而是涉及基于GPL源代码的二进制作品的分发和传递问题，但没有提供完整的对应源代码。

As such, issues of software delivery are the primary frustration for GPL enforcers. In particular, the following short list accounts for at least 95% of the GPL violations ever encountered:

因此，软件交付问题是GPL执行者主要遇到的挫折。特别是以下简短清单中至少占了95%的GPL违规行为：

The violator fails to provide required information about the presence of copylefted programs and their applicable license terms in the product they have purchased.

违规者未能提供关于他们购买的产品中存在的版权保护程序及其适用的许可证条款的所需信息。

The violator fails to reliably deliver [complete, corresponding source] (CCS) for copylefted programs the violator knew were included (i.e., the CCS is either delivered but incomplete, or is not delivered at all).

违规者未能可靠地交付违规者知道已包含的版权保护程序的完整对应源代码 (CCS)（即，CCS被交付但不完整，或者根本没有被交付）。

Requestors are ignored when they communicate with violator's published addresses requesting fulfill- ment of businesses' obligations.

当请求者通过违规者公布的地址联系请求履行义务时，被忽视。

This tutorial therefore focuses primarily on these issue. Admittedly, a tiny minority of compliance situations relate to question of derivative, combined, or modified versions of the work. Those situations are so rare, and the details from situation to situation differ greatly. Thus, such situations require a highly fact-dependent analysis and cannot be addressed in a general-purpose document such as this one.

因此，本教程主要关注这些问题。不可否认，极少数的合规情况涉及到作品的派生、合并或修改版本的问题。这些情况非常罕见，并且各种情况之间的细节差异很大。因此，这些情况需要进行高度依赖事实的分析，不能在这样一个通用性的文档中解决。

Most companies accused of violations lack a basic understanding of how to comply even in the straight- forward scenario. This document provides those companies with the fundamental and generally applicable prerequisite knowledge. For answers to rarer and more complicated legal questions, such as whether your software is a derivative or combined work of some copylefted software, consult with an attorney.[^4^]

大多数被指控违规的公司甚至缺乏基本的理解如何在简单的情况下进行合规性操作。本文档提供了这些公司所需的基本和普遍适用的先决知识。对于更罕见和更复杂的法律问题，例如您的软件是否是某些版权保护软件的派生或合并作品，请咨询律师^4^。

This discussion thus assumes that you have already identified the "work" covered by the license, and that any components not under the GPL (e.g., applications written entirely by your developers that merely happen to run on a Linux-based operating system) distributed in conjunction with those works are separate works within the meaning of copyright law and the GPL. In such a case, the GPL requires you to provide complete corresponding source (CCS)[^5^] for the GPL'd components and your modifications thereto, but not for independent proprietary applications. The procedures described in this document address this typical scenario.

因此，本讨论假定您已经确定了受许可证保护的“作品”，并且在与这些作品一起分发的任何未受GPL保护的组件（例如，完全由您的开发人员编写的仅恰好在基于Linux的操作系统上运行的应用程序）中，根据版权法和GPL的意义，它们是独立的作品。在这种情况下，GPL要求您提供GPL保护的组件及其修改的完整对应源代码(CCS)[^5^](#_bookmark183]，但不包括独立的专有应用程序。本文档中描述的程序解决了这种典型情况。

14.2 Monitor Software Acquisition

14.2 监控软件采购

Software engineers deserve the freedom to innovate and import useful software components to improve products. However, along with that freedom should come rules and reporting procedures to make sure that you are aware of what software that you include with your product.

软件工程师应该拥有创新和引入有用软件组件来改进产品的自由。然而，与此自由相应的应该是规则和报告程序，以确保您知道您所包含产品中的哪些软件。

The most typical response to an initial enforcement action is: "We didn't know there was GPL'd stuff in there". This answer indicates failure in the software acquisition and procurement process. Integration of third-party proprietary software typically requires a formal arrangement and management/legal oversight before the developers incorporate the software. By contrast, developers often obtain and integrate Free Software without intervention nor oversight. That ease of acquisition, however, does not mean the oversight is any less necessary. Just as your legal and/or management team negotiates terms for inclusion of any proprietary software, they should gently facilitate all decisions to bring Free Software into your product.

最典型的初步执行行动的回应是：“我们不知道里面有GPL的东西。”这个答案表明软件采购和采购流程的失败。第三方专有软件的集成通常需要正式的安排和管理/法律监督，然后开发人员才能将该软件纳入产品中。相比之下，开发人员通常无需干预或监督即可获得和集成自由软件。但是，这种获取的便利性并不意味着监督就不再必要了。正如您的法律和/或管理团队为纳入任何专有软件而协商条款一样，他们应该慢慢促进所有决定将自由软件引入您的产品。

Simple, engineering-oriented rules help provide a stable foundation for Free Software integration. For example, simply ask your software developers to send an email to a standard place describing each new Free Software component they add to the system, and have them include a brief description of how they will incorporate it into the product. Further, make sure developers use a revision control system (such as Git or Mercurial), and store the upstream versions of all software in a "vendor branch" or similar mechanism, whereby they can easily track and find the main version of the software and, separately, any local changes. Such procedures are best instituted at your project's launch. Once chaotic and poorly-sourced development processes begin, cataloging the presence of GPL'd components becomes challenging.

简单的工程规则有助于为自由软件集成提供稳定的基础。例如，只需要求您的软件开发人员将每个新的自由软件组件添加到系统中的标准位置发送电子邮件，并包括他们将如何将其集成到产品中的简要描述。此外，确保开发人员使用修订控制系统（如Git或Mercurial），并将所有软件的上游版本存储在“供应商分支”或类似机制中，从而可以轻松地跟踪和查找软件的主版本以及任何本地更改。这些程序最好在项目启动时实施。一旦混乱和低质量的开发过程开始，就会变得很难记录GPL的组件的存在。

§ 9.3 of this tutorial.

Such a situation often requires use of a tool to "catch up" your knowledge about what software your product includes. Most commonly, companies choose some software licensing scanning tool to inspect the codebase. However, there are few tools that are themselves Free Software. Thus, GPL enforcers usually recommend the GPL'd FOSSology system, which analyzes a source code base and produces a list of Free Software licenses that may apply to the code. FOSSology can help you build a catalog of the sources you have already used to build your product. You can then expand that into a more structured inventory and process.

这种情况通常需要使用一种工具来“跟进”了解产品包含的软件。最常见的做法是选择一些软件许可扫描工具来检查代码库。然而，很少有工具本身是自由软件。因此，GPL 执法者通常推荐 GPL 的 FOSSology 系统，它可以分析源代码库，并生成可能适用于代码的自由软件许可证列表。FOSSology 可以帮助您建立一个您已经使用的源代码的目录，然后将其扩展为更结构化的清单和流程。

14.3 Track Your Changes and Releases

14.3 跟踪你的变更与发布

As explained in further detail below, the most important component of GPL compliance is the one most often ignored: proper inclusion of CCS in all distributions of GPL'd software. To comply with GPL's CCS requirements, the distributor must always know precisely what sources generated a given binary distribution. In an unfortunately large number of our enforcement cases, the violating company's engineering team had difficulty reconstructing the CCS for binaries distributed by the company. Here are three simple rules to follow to decrease the likelihood of this occurrence:

如下所述，GPL合规的最重要组成部分是最常被忽略的：在所有GPL软件的发布中正确包含CCS。为了遵守GPL的CCS要求，分发者必须始终精确地知道哪些源代码生成了特定的二进制分发。在我们的许多执法案件中，违规公司的工程团队通常难以重建公司分发的二进制文件的CCS。以下是三个简单的规则，可以降低这种情况发生的可能性：

Ensure that your developers are using revision control systems properly.
确保您的开发人员正确使用版本控制系统。
Have developers mark or "tag" the full source tree corresponding to builds distributed to customers.
确保您的开发人员正确使用版本控制系统。

Check that your developers store all parts of the software development in the revision control system, including readmes, build scripts, engineers' notes, and documentation.

检查开发人员是否将软件开发的所有部分存储在版本控制系统中，包括readme、构建脚本、工程师的笔记和文档。

Your developers will benefit anyway from these rules. Developers will be happier in their jobs if their tools already track the precise version of source that corresponds to any deployed binary.

无论如何，您的开发人员都会受益于这些规则。如果他们的工具已经跟踪与部署的二进制文件相对应的精确源代码版本，开发人员将更加愉快地工作。

14.4 Avoid the "Build Guru"

14.4 避免“构建大师”

Too many software projects rely on only one or a very few team members who know how to build and assemble the final released product. Such knowledge centralization not only creates engineering redundancy issues, but also thwarts GPL compliance. Specifically, CCS does not just require source code, but scripts and other material that explain how to control compilation and installation of the executable and object code.

太多的软件项目仅依赖于一个或非常少数的团队成员，他们知道如何构建和组装最终发布的产品。这种知识集中不仅会创建工程冗余问题，还会阻碍GPL合规。具体而言，CCS不仅需要源代码，还需要脚本和其他材料，以说明如何控制可执行和目标代码的编译和安装。

Thus, avoid relying on a "build guru", a single developer who is the only one who knows how to produce your final product. Make sure the build process is well defined. Train every developer on the build process for the final binary distribution, including (in the case of embedded software) generating a final firmware image suitable for distribution to the customer. Require developers to use revision control for build processes. Make a rule that adding new components to the system without adequate build instructions (or better yet, scripts) is unacceptable engineering practice.

因此，避免依赖“构建大师”，即只有一个开发人员知道如何生成您的最终产品。确保构建过程被明确定义。对最终二进制分发的构建过程对每个开发人员进行培训，包括（在嵌入式软件的情况下）生成适合分发给客户的最终固件映像。要求开发人员在构建过程中使用版本控制。制定规则，即添加新组件到系统中，如果没有足够的构建说明（或更好的是脚本），则是不可接受的工程实践。

CHAPTER 15 DETAILS OF COMPLIANT DISTRIBUTION

第15章符合要求的发行

Distribution of GPL'd works has requirements; copyleft will not function without placing requirements on redistribution. However, some requirements are more likely to cause compliance difficult than others. This chapter⁴⁹ explains some the specific requirements placed upon distributors of GPL'd software that redistributors are most likely to overlook, yielding compliance problems.

分发GPL作品有要求；没有对再分发提出要求，共享版权也无法发挥作用。然而，有些要求比其他要求更容易导致符合要求的困难。本章⁴⁹解释了针对GPL软件的分发商放置的一些具体要求，这些要求往往被再分发者忽视，从而导致符合要求的问题。

First, GPLv2 1 and GPLv2 4 require that the full license text must accompany every distribution (either in source or binary form) of each licensed work. Strangely, this requirement is responsible for a surprisingly significant fraction of compliance errors; too often, physical products lack required information about the presence of GPL'd programs and the applicable license terms. Automated build processes can and should carry a copy of the license from the the source distribution into the final binary firmware package for embedded products. Such automation usually achieves compliance regarding license inclusion requirements⁵⁰

首先，GPLv2 1和GPLv2 4要求每个受许可作品的每个分发（无论是源代码还是二进制形式）必须附带完整的许可证文本。奇怪的是，这一要求导致了相当大比例的符合要求错误；太多的物理产品缺乏关于GPL程序的存在和适用许可证条款的必要信息。自动化的构建过程可以并且应该将许可证副本从源代码分发中携带到嵌入式产品的最终二进制固件包中。这种自动化通常可以达到符合许可证包含的要求⁵⁰。

15.1 Binary Distribution Permission

15.1 二进制分发许可

The various versions of the GPL are copyright licenses that grant permission to make certain uses of software that are otherwise restricted by copyright law. This permission is conditioned upon compliance with the GPL's requirements.

GPL的各个版本都是版权许可证，授权在版权法限制下进行某些软件使用。这个许可是有条件的，需要遵守GPL的要求。

This section walks through the requirements (of both GPLv2 and GPLv3) that apply when you distribute GPL'd programs in binary (i.e., executable or object code) form, which is typical for embedded applications. Because a binary application derives from a program's original sources, you need permission from the copy- right holder to distribute it. 3 of GPLv2 and 6 of GPLv3 contain the permissions and conditions related to binary distributions of GPL'd programs.⁵¹ Failure to provide or offer CCS is the single largest failure mode leading to compliance disputes.

本节介绍了适用于以二进制形式（即可执行或目标代码）分发GPL程序时（这在嵌入式应用中很常见）的要求（适用于GPLv2和GPLv3）。因为二进制应用程序是从程序的原始源代码中派生出来的，因此你需要版权持有人的许可才能分发它。GPLv2的第3条和GPLv3的第6条包含了与GPL程序的二进制分发相关的许可和条件。⁵¹未能提供或提供CCS是导致合规争议的最大失败模式。

GPL's binary distribution sections offer a choice of compliance methods, each of which we consider in turn. Each option refers to the "Corresponding Source" code for the binary distribution, which includes the source code from which the binary was produced. This abbreviated and simplified definition is sufficient for the binary distribution discussion in this section, but you may wish to refer back to this section after reading the thorough discussion of "Corresponding Source" that appears in § [15.2.]

GPL的二进制分发部分提供了几种合规方法选择，我们依次考虑每种选项。每个选项都涉及二进制分发的“相应源代码”，其中包括生成二进制代码的源代码。这个缩写和简化的定义足以在本节的二进制分发讨论中使用，但是你可能希望在阅读了出现在§15.2中的“相应源代码”的详细讨论后再参考本节。

15.1.1 Option (a): Source Alongside Binary

15.1.1 选项（a）：与二进制文件同时提供源代码

GPLv2 3(a) and v3 6(a) embody the easiest option for providing source code: including Corresponding Source with every binary distribution. While other options appear initially less onerous, this option invari- ably minimizes potential compliance problems, because when you distribute Corresponding Source with the binary, your GPL obligations are satisfied at the time of distribution. This is not true of other options, and for this reason, we urge you to seriously consider this option. If you do not, you may extend the duration of your obligations far beyond your last binary distribution.

GPLv2 3(a)和GPLv3 6(a)体现了提供源代码最简单的选项：在每个二进制发布中包含相应的源代码。虽然其他选项最初似乎不那么麻烦，但这个选项不可避免地最大限度地减少了潜在的合规问题，因为当你将相应的源代码与二进制文件一起分发时，你的GPL义务在分发时就得到了满足。其他选项并非如此，因此我们敦促你认真考虑此选项。如果你不这样做，你可能会将你的义务延长到最后一个二进制分发之后。

Compliance under this option is straightforward. If you ship a product that includes binary copies of GPL'd software (e.g., in firmware, or on a hard drive, CD, or other permanent storage medium), you can store the Corresponding Source alongside the binaries. Alternatively, you can include the source on a CD or other removable storage medium in the box containing the product.

按照此选项的合规性很简单。如果你发布的产品包含GPL软件的二进制副本（例如在固件中或存储在硬盘驱动器、CD或其他永久存储介质上），则可以将相应的源代码与二进制文件一起存储。或者，你可以在产品所在的盒子里包含一个 CD 或其他可移动存储介质，上面包含源代码。

GPLv2 refers to the various storage mechanisms as "medi[a] customarily used for software interchange". While the Internet has attained primacy as a means of software distribution where super-fast Internet connections are available, GPLv2 was written at a time when downloading software was not practical (and was often impossible). For much of the world, this condition has not changed since GPLv2's publication, and the Internet still cannot be considered "a medium customary for software interchange". GPLv3 clarifies this matter, requiring that source be "fixed on a durable physical medium customarily used for software interchange". This language affirms that option (a) requires binary redistributors to provide source on a physical medium.

GPLv2将各种存储机制称为“软件交换习惯上使用的介质”。虽然在超快速互联网连接可用的情况下，互联网已经成为软件分发的主要手段，但GPLv2是在下载软件不可行（并且经常是不可能的）的时代编写的。对于世界上大部分地区而言，自GPLv2出版以来，这种情况并没有改变，因此互联网仍不能被视为“软件交换的常规介质”。GPLv3澄清了这一点，要求源代码“固定在常规用于软件交换的耐用物理介质上”。这种语言确认了选项（a）要求二进制再分发者在物理介质上提供源代码。

Please note that while selection of option (a) requires distribution on a physical medium, voluntary distribution via the Internet is very useful. This is discussed in detail in § [15.1.2.]

请注意，虽然选择选项（a）需要通过物理介质分发，但自愿通过互联网分发非常有用。这在15.1.2.中详细讨论。

15.1.2 Option (b): The Offer

15.1.2 选项（b）：提供源代码

Many distributors prefer to ship only an offer for source with the binary distribution, rather than the complete source package. This option has value when the cost of source distribution is a true per-unit cost. For example, this option might be a good choice for embedded products with permanent storage too small to fit the source, and which are not otherwise shipped with a CD but are shipped with a manual or other printed material.

许多分发者更喜欢仅随二进制分发提供源代码，而不是完整的源代码包。当源代码分发成本是真正的单位成本时，这个选项是有价值的。例如，当嵌入式产品的永久存储空间太小无法容纳源代码，并且没有随盘（CD）或其他印刷材料一起发送时，这个选项可能是一个好的选择。

However, this option increases the duration of your obligations dramatically. An offer for source must be good for three full years from your last binary distribution (under GPLv2), or your last binary or spare part distribution (under GPLv3). Your source code request and provisioning system must be designed to last much longer than your product life cycle. Thus, it also increases your compliance costs in the long run. In addition, if you are required to comply with the terms of GPLv2, you cannot use a network service to provide the source code. For GPLv2, the source code offer is fulfilled only with physical media. This usually means that you must continue to produce an up-to-date "source code CD" for years after the product's end-of-life.

然而，这个选项会显著增加你的义务期限。根据GPLv2，源代码邀请必须在你的最后一个二进制分发之后保持三年有效期，或在GPLv3下，你的最后一个二进制或备件分发之后保持三年有效期。你的源代码请求和提供系统必须设计得比你的产品生命周期长得多。因此，它也会增加你长期的合规成本。此外，如果你需要遵守GPLv2的条款，则不能使用网络服务提供源代码。对于GPLv2，只有在实体媒介上提供源代码邀请才能履行义务。这通常意味着你必须在产品的生命周期结束后多年继续生产最新的“源代码CD”。

Under GPLv2, it is acceptable and advisable for your offer for source code to include an Internet link for downloadable source in addition to offering source on a physical medium. This practice enables those with fast network connections to get the source more quickly, and typically decreases the number of physical media fulfillment requests. (GPLv3 6(b) permits provision of source with a public network-accessible distribution only and no physical media. We discuss this in detail at the end of this section.)

根据GPLv2，你的源代码邀请可以包括可下载源代码的Internet链接，并且建议这么做，除了提供实体媒介的源代码。这种做法可以使那些拥有快速网络连接的人更快地获取源代码，并且通常会减少实体媒介履行请求的数量。（GPLv3 6(b)仅允许在公共网络可访问分发源代码，不提供实体媒介。我们在本节末尾详细讨论此问题。）

The following is a suggested compliant offer for source under GPLv2 (and is also acceptable for GPLv3) that you would include in your printed materials accompanying each binary distribution:

以下是在每个二进制分发品附带的印刷材料中建议的符合GPLv2（也适用于GPLv3）的源代码提供方案：

The software included in this product contains copyrighted software that is licensed under the GPL. A copy of that license is included in this document on page X. You may obtain the complete Corresponding Source code from us for a period of three years after our last shipment of this product, which will be no earlier than 2011-08-01, by sending a money order or check for $5 to:

GPL Compliance Division

Our Company

Any Town, US 99999

Please write "source for product Y " in the memo line of your payment.

You may also find a copy of the source at http://www.example.com/sources/Y/. This offer is valid to anyone in receipt of this information.

此产品中包含根据GPL许可的受版权保护的软件。该许可证的副本已包含在本文档的第X页中。你可以通过发送5美元的汇票或支票到以下地址，获得我们提供的该产品最后一次装运后三年内的完整的对应源代码：

GPL合规部门

我们公司

Any Town, US 99999

请在付款单的备忘录栏中写上“产品Y的源代码”。

你还可以在 http://www.example.com/sources/Y/ 找到源代码的副本。此提供方案适用于所有收到此信息的人。

There are a few important details about this offer. First, it requires a copying fee. GPLv2 permits "a charge no more than your cost of physically performing source distribution". This fee must be reasonable. If your cost of copying and mailing a CD is more than around $10, you should perhaps find a cheaper CD stock and shipment method. It is simply not in your interest to try to overcharge the community. Abuse of this provision in order to make a for-profit enterprise of source code provision will likely trigger enforcement action.

提供源代码有几个重要的细节。首先，要求授权费。GPLv2 授权你“收取不超过你实际分发源代码成本的费用”。收费必须合理。如果你复制和邮寄一张 CD 的费用超过10美元，你可能需要找更便宜的 CD 店和邮寄方式。简单来说，从社区盈利不是你的目的。滥用此条款建立靠源代码盈利的企业可能会引发执行行动。

Second, note that the last line makes the offer valid to anyone who requests the source. This is because v2 3(b) requires that offers be "to give any third party" a copy of the Corresponding Source. GPLv3 has a similar requirement, stating that an offer must be valid for "anyone who possesses the object code". These requirements indicated in v2 3(c) and v3 6(c) are so that noncommercial redistributors may pass these offers along with their distributions. Therefore, the offers must be valid not only to your customers, but also to anyone who received a copy of the binaries from them. Many distributors overlook this requirement and assume that they are only required to fulfill a request from their direct customers.

其次，注意最后一行规定了向任何要求源代码的人提供源代码都是有效的。这是因为第2版3(b)要求了向“任何第三方”提供相应源代码的副本。GPLv3 有相似的要求，声明了提供源代码必须是向“任何拥有目标代码的人”都是有效的。第2版 3(c) 和第3版 6(c) 中指出的这些要求是为了让非商业再分发者可以与他们的分发一起传递。因此，提供源代码必须不仅对你的客户有效，而且对从他们那里收到二进制文件副本的任何人都必须有效。许多分销商忽视了这一要求，并认为他们只需要满足直接客户的要求。

The option to provide an offer for source rather than direct source distribution is a special benefit to companies equipped to handle a fulfillment process. GPLv2 3(c) and GPLv3 6(c) avoid burdening noncommercial, occasional redistributors with fulfillment request obligations by allowing them to pass along the offer for source as they received it.

提供源代码而不是直接分发源代码对有能力履行流程的公司来说是特殊的好处。GPLv2 3(c)和GPLv3 6(c)允许非商业性、偶尔地再分发者在收到请求时提供源代码，从而避免履行请求义务的负担。

Note that commercial redistributors cannot avail themselves of the option (c) exception, and so while your offer for source must be good to anyone who receives the offer (under v2) or the object code (under v3), it cannot extinguish the obligations of anyone who commercially redistributes your product. The license terms apply to anyone who distributes GPL'd software, regardless of whether they are the original distributor. Take the example of Vendor V , who develops a software platform from GPL'd sources for use in embedded devices. Manufacturer M contracts with V to install the software as firmware in M 's device. V provides the software to M , along with a compliant offer for source. In this situation, M cannot simply pass V 's offer for source along to its customers. M also distributes the GPL'd software commercially, so M too must comply with the GPL and provide source (or M 's own offer for source) to M 's customers.

请注意，商业再分发者无法利用选项(c)的例外情况，因此，尽管你的源代码提供必须对任何接收到提供（在v2下）或目标代码（在v3下）的人有效，但它不能免除任何商业再分发你产品的人的义务。许可条款适用于任何分发GPL软件的人，无论他们是否是最初的分发者。以供应商 V 为例，该厂商从GPL源代码开发软件平台用于嵌入式设备。制造商M与V签订合同，在M的设备中安装该软件作为固件。V提供该软件给M，以及符合规定的源代码提供。在这种情况下，M不能简单地将V的源代码提供转交给其客户。因为M也在商业上分发GPL软件，所以M也必须遵守GPL并向M的客户提供源代码（或M自己的源代码提供）。

This situation illustrates that the offer for source is often a poor choice for products that your customers will likely redistribute. If you include the source itself with the products, then your distribution to your customers is compliant, and their (unmodified) distribution to their customers is likewise compliant, because both include source. If you include only an offer for source, your distribution is compliant but your customer's distribution does not "inherit" that compliance, because they have not made their own offer to accompany their distribution.

这种情况说明，对于你的客户很可能会重新分发的产品，提供源代码的选择通常不是一个好选择。如果你将源代码本身与产品一起提供，那么你向客户的分发是合规的，他们（未修改的）向他们的客户的分发同样合规，因为两者都包含源代码。如果你只提供源代码的提供，你的分发是合规的，但你的客户的分发不会“继承”这种合规性，因为他们没有提供自己的提供来伴随他们的分发。

The terms related to the offer for source are quite different if you distribute under GPLv3. Under v3, you may make source available only over a network server, as long as it is available to the general public and remains active for three years from the last distribution of your product or related spare part. Accordingly, you may satisfy your fulfillment obligations via Internet-only distribution. This makes the "offer for source" option less troublesome for v3-only distributions, easing compliance for commercial redistributors. However, before you switch to a purely Internet-based fulfillment process, you must first confirm that you can actually distribute all of the software under GPLv3. Some programs are indeed licensed under "GPLv2, or any later version" (often abbreviated "GPLv2-or-later"). Such licensing gives you the option to redistribute under GPLv3. However, a few popular programs are only licensed under GPLv2 and not "or any later version" ("GPLv2-only"). You cannot provide only Internet-based source request fulfillment for the latter programs. If you determine that all GPL'd works in your whole product allow upgrade to GPLv3 (or were already GPLv3'd to start), your offer for source may be as simple as this:

与提供源代码相关的条款在 GPLv3 下有很大不同。根据 v3，你可以仅通过网络服务器提供源代码，只要它对一般公众可用并且从你的产品或相关备件的最后分发开始保持活动状态三年。因此，你可以通过仅通过互联网分发来满足你的履行义务。这使得“提供源代码”选项对仅适用于 v3 的分发来说不那么麻烦，为商业再分发者简化了合规性。但是，在切换到纯粹基于互联网的履行流程之前，你必须首先确认你实际上可以在 GPLv3 下分发所有软件。一些程序确实是根据“GPLv2，或任何以后版本”（通常缩写为“GPLv2-或更高版本”）许可的。这种许可给了你在 GPLv3 下重新分发的选择。然而，一些流行的程序仅根据 GPLv2 许可，而不是“或任何以后版本”（“GPLv2-only”）。你不能为后者的程序提供仅基于互联网的源代码请求履行。如果你确定整个产品中的所有 GPL 软件都允许升级到 GPLv3（或已经从 GPLv3 开始），那么你的源代码提供可能像这样简单：

The software included in this product contains copyrighted software that is licensed under the GPLv3. A copy of that license is included in this document on page X. You may obtain the complete Corresponding Source code from us for a period of three years after our last shipment of this product and/or spare parts therefor, which will be no earlier than 2011-08-01, on our website at http://www.example.com/sources/productnum/.

本产品中包含受 GPLv3 许可的版权软件。该许可证的副本在本文档的第 X 页中包含。你可以在我们的网站 http://www.example.com/sources/productnum/ 上在最后一次发货和/或备件发货之后三年的时间内获取完整的相应源代码。

Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of the license itself, either electronically or in print, with every distribution.

在 GPLv2 和 GPLv3 下，每次分发源代码提供必须附带许可证本身的副本，可以是电子版或印刷版。

Finally, it is unacceptable to use option (b) merely because you do not have Corresponding Source ready. We find that some companies choose this option because writing an offer is easy, but producing a source distribution as an afterthought to a hasty development process is difficult. The offer for source does not exist as a stop-gap solution for companies rushing to market with an out-of-compliance product. If you ship an offer for source with your product but cannot actually deliver immediately on that offer when your customers request it, you should expect an enforcement action.

最后，仅仅因为没有准备好相关源代码，就使用选项（b）是不可接受的。我们发现，有些公司选择这个选项只是因为编写提供书面源代码的声明很容易，但在匆忙的开发过程中，生产源代码分发却很困难。提供源代码的声明不是一种临时的解决方案，用于公司匆忙推出不合规产品的情况。如果你向产品中附上了提供源代码的声明，但在客户要求时无法立即履行该声明，那么你应该预期会受到执法行动。

15.1.3 Option (c): Noncommercial Offers

15.1.3 选项（c）：非商业提供

As discussed in the last section, GPLv2 3(c) and GPLv3 6(c) apply only to noncommercial use. These options are not available to businesses distributing GPL'd software. Consequently, companies that redis- tribute software packaged for them by an upstream vendor cannot merely pass along the offer they received from the vendor; they must provide their own offer or corresponding source to their distributees. We talk in detail about upstream software providers in § [18.2.]

正如上一节所述，GPLv2 3(c)和GPLv3 6(c)仅适用于非商业用途。这些选项对于分发GPL软件的企业不可用。因此，通过上游供应商打包软件的公司不能仅仅转交他们从供应商获得的提供，他们必须向他们的分发对象提供自己的提供或对应源代码。我们在18.2.小节中详细讨论了上游软件提供商的问题。

15.1.4 Option 6(d) in GPLv3: Internet Distribution

15.1.4 GPLv3中的选项6(d)：互联网分发

Under GPLv2, your formal provisioning options for Corresponding Source ended with 3(c). But even under GPLv2, pure Internet source distribution was a common practice and generally considered to be compliant. GPLv2 mentions Internet-only distribution almost as aside in the language, in text at the end of the section after the three provisioning options are listed. To quote that part of GPLv2 § 3:

根据GPLv2，与对应源代码的正式供应选项在3(c)结束。但即使在GPLv2下，纯互联网源分发也是一种常见做法，通常被认为是符合规定的。GPLv2在语言上几乎只是提到互联网分发，是在列出三个供应选项后的章节末尾的一段文字。引用GPLv2 第3条的部分内容如下：

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

如果通过提供从指定位置复制的访问来进行可执行或对象代码的分发，则提供从同一位置复制源代码的等效访问计为源代码的分发，即使第三方不必与对象代码一起复制源代码。

When that was written in 1991, Internet distribution of software was the exception, not the rule. Some FTP sites existed, but generally software was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that binary distribution happened on some physical media. By contrast, GPLv3 6(d) explicitly gives an option for this practice that the community has historically considered GPLv2-compliant.

当这段话在1991年写出来时，软件的互联网分发是例外，而不是规则。一些FTP站点存在，但通常软件是通过磁带或CD发送的。因此，GPLv2主要假定二进制分发是在某些物理媒体上发生的。相比之下，GPLv3 6(d)明确给出了这种做法的一个选项，社区历来认为这是符合GPLv2的。

Thus, you may fulfill your source-provision obligations by providing the source code in the same way and from the same location. When exercising this option, you are not obligated to ensure that users download the source when they download the binary, and you may use separate servers as needed to fulfill the requests as long as you make the source as accessible as the binary. However, you must ensure that users can easily find the source code at the time they download the binary. GPLv3 6(d) thus clarifies a point that has caused confusion about source provision in v2. Indeed, many such important clarifications are included in v3 which together provide a compelling reason for authors and redistributors alike to adopt GPLv3.

因此，你可以通过以相同的方式和从相同的位置提供源代码来履行你的源代码供应义务。在行使此选项时，你不需要确保用户在下载二进制文件时也下载源代码，并且你可以使用所需的单独服务器来满足请求，只要你使源代码与二进制文件同样易于获取即可。但是，在用户下载二进制文件时，你必须确保用户可以轻松找到源代码。因此，GPLv3 6(d)澄清了有关v2中源代码供应的一个引起混淆的问题。实际上，许多这样的重要澄清都包含在v3中，这些澄清共同为作者和再分发者采用GPLv3提供了一个有力的理由。

15.1.5 Option 6(e) in GPLv3: Software Torrents

15.1.5 GPLv3的选项6(e)：软件种子

Peer-to-peer file sharing arose well after GPLv2 was written, and does not easily fit any of the v2 source provision options. GPLv3 6(e) addresses this issue, explicitly allowing for distribution of source and binary together on a peer-to-peer file sharing network. If you distribute solely via peer-to-peer networks, you can exercise this option. However, peer-to-peer source distribution cannot fulfill your source provision obligations for non-peer-to-peer binary distributions. Finally, you should ensure that binaries and source are equally seeded upon initial peer-to-peer distribution.

对等文件共享出现在 GPLv2 之后，不容易符合任何 v2 源代码供应选项。GPLv3 6(e) 解决了这个问题，明确允许在P2P文件共享网络上同时分发源代码和二进制文件。如果你仅通过对等文件共享网络进行分发，你可以行使此选项。但是，对等文件共享的源代码分发无法满足非对等文件共享二进制分发的源代码供应义务。最后，你应确保二进制文件和源代码在初始P2P文件共享分发时被平等分布。

15.2 Preparing Corresponding Source

15.2 准备相应源代码

Most enforcement cases involve companies that have unfortunately not implemented procedures like our [14] recommendations and have no source distribution arranged at all. These companies must work backwards from a binary distribution to come into compliance. Our recommendations in [14] are designed to make it easy to construct a complete and Corresponding Source release from the outset. If you have followed those principles in your development, you can meet the following requirements with ease. If you have not, you may have substantial reconstruction work to do.

大多数执行案例涉及那些不幸没有实施像我们建议的14那样的程序，也没有安排任何源代码分发的公司。这些公司必须从二进制分发开始向后工作，以达到合规。我们在14中的建议旨在使从一开始就构建完整的相应源代码发布变得容易。如果你在开发过程中遵循了这些原则，你可以轻松满足以下要求。如果没有，你可能需要进行大量的重建工作。

15.2.1 Assemble the Sources

15.2.1 收集源代码

For every binary that you produce, you should collect and maintain a copy of the sources from which it was built. A large system, such as an embedded firmware, will probably contain many GPL'd and LGPL'd components for which you will have to provide source. The binary distribution may also contain proprietary components which are separate and independent works that are covered by neither the GPL nor LGPL.

对于你生成的每个二进制文件，都应该收集和维护一个从中构建出来的源代码副本。一个大型的系统，例如嵌入式固件，可能包含许多 GPL 和 LGPL 组件，你需要为其提供源代码。二进制分发还可能包含专有组件，这些组件是独立的作品，既不受 GPL 也不受 LGPL 的覆盖。

The best way to separate out your sources is to have a subdirectory for each component in your system. You can then easily mark some of them as required for your Corresponding Source releases. Collecting subdirectories of GPL'd and LGPL'd components is the first step toward preparing your release.

分离源代码的最佳方式是为系统中的每个组件都创建一个子目录。然后，你可以轻松地将其中一些标记为所需的相应源代码发布。收集 GPL 和 LGPL 组件的子目录是准备发布的第一步。

15.2.2 Building the Sources

15.2.2 构建源代码

Few distributors, particularly of embedded systems, take care to read the actual definition of Corresponding Source in the GPL. Consider carefully the definition, from GPLv3:

很少有分发者，特别是嵌入式系统的分发者，会注意到GPL中"对应源代码"的实际定义。仔细考虑GPLv3中的定义：

The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

对于以目标代码形式提供的作品，"对应源代码"是指生成、安装和（对于可执行作品）运行目标代码以及修改该作品所需的所有源代码，包括控制这些活动的脚本。

and the definition from GPLv2:

和GPLv2中的定义：

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

作品的源代码是指进行修改所需的首选形式。对于可执行作品，完整的源代码是指其中包含的所有模块的源代码，以及任何相关的接口定义文件和用于控制可执行文件编译和安装的脚本。

Note that you must include "scripts used to control compilation and installation of the executable" and/or anything "needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities". These phrases are written to cover different types of build environments and systems. Therefore, the details of what you need to provide with regard to scripts and installation instructions vary depending on the software details. You must provide all information necessary such that someone generally skilled with computer systems could produce a binary similar to the one provided.

请注意，你必须包括"用于控制编译和安装可执行文件的脚本"和/或任何"生成、安装和（对于可执行作品）运行目标代码以及修改该作品所需的所有源代码，包括控制这些活动的脚本"。这些短语被编写成覆盖不同类型的构建环境和系统的情况。因此，关于脚本和安装说明的提供细节取决于软件的细节。你必须提供所有必要的信息，以便一般熟练掌握计算机系统的人可以生成与提供的二进制文件类似的二进制文件。

Take as an example an embedded wireless device. Usually, a company distributes a firmware, which includes a binary copy of Linux⁵² and a filesystem. That filesystem contains various binary programs, including some GPL'd binaries, alongside some proprietary binaries that are separate works (i.e., not derived from, nor based on freely-licensed sources). Consider what, in this case, constitutes adequate "scripts to control compilation and installation" or items "needed to generate, install and run" the GPL'd programs.

以嵌入式无线设备为例。通常，一家公司会分发一个固件，其中包括Linux⁵²的二进制副本和一个文件系统。该文件系统包含各种二进制程序，包括一些GPL的二进制程序，以及一些专有的二进制程序，它们是独立的作品（即不是基于自由许可证源代码派生的或基于自由许可证源代码的）。在这种情况下，考虑什么构成足够的"用于控制编译和安装的脚本"或"生成、安装和运行"GPL的程序所需的内容。

Most importantly, you must provide some sort of roadmap that allows technically sophisticated users to build your software. This can be complicated in an embedded environment. If your developers use scripts to control the entire compilation and installation procedure, then you can simply provide those scripts to users along with the sources they act upon. Sometimes, however, scripts were never written (e.g., the information on how to build the binaries is locked up in the mind of your "build guru"). In that case, we recommend that you write out build instructions in a natural language as a detailed, step-by-step readme.

最重要的是，你必须提供某种路线图，让技术复杂的用户能够构建你的软件。在嵌入式环境中，这可能很复杂。如果你的开发人员使用脚本来控制整个编译和安装过程，那么你可以简单地将这些脚本与它们所处理的源代码一起提供给用户。然而，有时候脚本从未编写过（例如，如何构建二进制文件的信息被锁在你的“构建专家”的头脑中）。在这种情况下，我们建议你用自然语言编写详细的、逐步的构建说明。

No matter what you offer, you need to give those who receive source a clear path from your sources to binaries similar to the ones you ship. If you ship a firmware (kernel plus filesystem), and the filesystem contains binaries of GPL'd programs, then you should provide whatever is necessary to enable a reasonably skilled user to build any given GPL'd source program (and modified versions thereof), and replace the given binary in your filesystem. If the kernel is Linux, then the users must have the instructions to do the same with the kernel. The best way to achieve this is to make available to your users whatever scripts or process your engineers would use to do the same.

无论你提供什么，你都需要为那些收到源代码的人提供一个明确的路径，让他们能够从你的源代码到类似于你提供的二进制文件的文件。如果你提供了固件（内核加文件系统），并且文件系统中包含了GPL的程序二进制文件，那么你应该提供一切必要的东西，以使合理熟练的用户能够构建任何给定的GPL源代码程序（及其修改版本），并替换文件系统中的给定二进制文件。如果内核是Linux，那么用户必须有相同的指令来执行相同的操作。实现这个的最好方法是向你的用户提供你的工程师将使用的任何脚本或过程。

These are the general details for how installation instructions work. Details about what differs when the work is licensed under LGPL is discussed in § [18.1,] and specific details that are unique to GPLv3's installation instructions are in § [18.4.]

这些是安装说明的一般细节。关于在作品采用LGPL许可下安装说明有何不同之处，可以参考18.1节。另外，GPLv3安装说明所特有的细节可以参考18.4节。

15.2.3 What About the Compiler?

15.2.3 关于编译器呢？

The GPL contains no provision that requires distribution of the compiler used to build the software. While companies are encouraged to make it as easy as possible for their users to build the sources, inclusion of the compiler itself is not normally considered mandatory. The Corresponding Source definition -- both in GPLv2 and GPLv3 -- has not been typically read to include the compiler itself, but rather things like makefiles, build scripts, and packaging scripts.

GPL中没有规定要求分发用于构建软件的编译器。虽然我们鼓励公司尽可能地让用户容易地构建源代码，但通常情况下不认为包含编译器本身是强制性的。无论是在GPLv2还是GPLv3中，“相应源代码”的定义通常不包括编译器本身，而是像makefile、构建脚本和打包脚本这样的东西。

Nonetheless, in the interest of goodwill and the spirit of the GPL, most companies do provide the compiler itself when they are able, particularly when the compiler is based on GCC or another copylefted compiler. If you have a GCC-based system, it is your prerogative to redistribute that GCC version (binaries plus sources) to your customers. We in the software freedom community encourage you to do this, since it often makes it easier for users to exercise their software freedom. However, if you chose to take this recommendation, ensure that your GCC distribution is itself compliant.

尽管如此，在善意和GPL精神的基础上，大多数公司在可能的情况下会提供编译器本身，特别是当编译器基于GCC或其他使用Copyleft协议的编译器时。如果你有一个基于GCC的系统，你有权将该GCC版本（二进制和源代码）重新分发给你的客户。我们在自由软件社区鼓励你这样做，因为这通常使用户更容易行使其软件自由。但是，如果你选择采取这个建议，请确保你的GCC发行版本身符合要求。

If you have used a proprietary, third-party compiler to build the software, then you probably cannot ship it to your customers. We consider the name of the compiler, its exact version number, and where it can be acquired as information that must be provided as part of the Corresponding Source. This information is essential to anyone who wishes to produce a binary. It is not the intent of the GPL to require you to distribute third-party software tools to your customer (provided the tools themselves are not based on the GPL'd software shipped), but we do believe it requires that you give the user all the essential non-proprietary facts that you had at your disposal to build the software. Therefore, if you choose not to distribute the compiler, you should include a readme about where you got it, what version it was, and who to contact to acquire it, regardless of whether your compiler is Free Software, proprietary, or internally developed.

如果你使用专有的第三方编译器构建软件，则可能无法将其发送给客户。我们认为编译器的名称、确切版本号以及其获取方式是必须作为“相应源代码”的一部分提供的信息。这些信息对于希望生成二进制文件的任何人都是必不可少的。GPL的意图不是要求你向客户分发第三方软件工具（前提是这些工具本身不是基于已分发的GPL软件），但我们确实认为它要求你向用户提供你用于构建软件的所有基本非专有信息。因此，如果你选择不分发编译器，无论你的编译器是自由软件、专有软件还是内部开发的，请在README文件中说明你获取编译器的来源、版本以及联系方式。

15.3 Best Practices and Corresponding Source

15.3 最佳实践和对应源代码

[14] and [15.2] above are closely related. If you follow the best practices outlined above, you will find that preparing your Corresponding Source release is an easier task, perhaps even a trivial one.

上面的 14 和 15.2 密切相关。如果你按照上面概述的最佳实践，你会发现准备相应源代码的发布将是一个更容易的任务，甚至可能是一个微不足道的任务。

Indeed, the enforcement process itself has historically been useful to software development teams. Devel- opment on a deadline can lead organizations to cut corners in a way that negatively impacts its development processes. We have frequently been told by violators that they experience difficulty when determining the exact source for a binary in production (in some cases because their "build guru" quit during the release cycle). When management rushes a development team to ship a release, they are less likely to keep release sources tagged and build systems well documented.

事实上，执法过程本身对软件开发团队历史上一直是有益的。在期限紧迫的开发中，组织可能会在某种程度上走捷径，从而对其开发过程产生负面影响。我们经常被侵权者告知，他们在确定正在生产的二进制文件的确切源代码时遇到了困难（在某些情况下，因为他们的“构建专家”在发布周期内离开了）。当管理层迫使开发团队发布一个版本时，他们更不可能保持发布源代码标记和构建系统记录的良好状态。

We suggest that, if contacted about a violation, product builders use GPL enforcement as an opportunity to improve their development practices. No developer would argue that their system is better for having a mysterious build system and no source tracking. Address these issues by installing a revision system, telling your developers to use it, and requiring your build guru to document his or her work!

如果你收到关于侵权的通知，我们建议产品构建者将GPL执行视为改进其开发实践的机会。没有开发人员会认为他们的系统因拥有神秘的构建系统和没有源代码跟踪而变得更好。通过安装修订系统，告诉你的开发人员使用它，并要求你的构建专家记录他或她的工作来解决这些问题！

15.4 Non-Technical Compliance Issues

15.4 非技术合规问题

Certainly, the overwhelming majority of compliance issues are, in fact, either procedural or technical. Thus, the primary material in this chapter so far has covered those issues. However, a few compliance issues do require more direct consideration of a legal situation. This portion guide does not consider those in detail, as a careful reading of the earlier chapters of Part [I] shows various places where legal considerations are necessary for considering compliance activity.

当然，绝大多数合规问题实际上都是程序上的或技术上的问题。因此，本章的主要内容到目前为止都涵盖了这些问题。然而，少数合规问题确实需要更直接地考虑法律情况。本指南的这一部分不会详细介绍这些问题，因为仔细阅读第 I 部分早期章节就可以看到，在考虑合规性活动时需要考虑法律问题的各个方面。

For example, specific compliance issues related to GPLv2 7, GPLv3 7, and GPLv3 11 demand a more traditional approach to legal license compliance. Of course, such analysis and consideration can be com- plicated, and some are considered in the enforcement case studies that follow in the next part. However, compliance issues related to such sections are not rare, and, as is typical, no specific training is available for dealing with extremely rare occurrences.

例如，与 GPLv2 7、GPLv3 7 和 GPLv3 11 相关的具体合规问题需要更传统的法律许可证合规方法。当然，这样的分析和考虑可能会很复杂，并且在下一部分的执行案例研究中会涉及其中一些问题。然而，与这些部分相关的合规问题并不罕见，正如通常情况下，对于处理极为罕见的情况没有特定的培训。

15.5 Self-Assessment of Compliance

15.5 合规自我评估

Most companies that adopt copylefted software believe they have complied. Humans usually have difficult admitting their own mistakes, particularly systematic ones. Therefore, perhaps the most important necessary step to stay in compliance is a company's regular evaluation of their own compliance.

大多数采用Copyleft软件的公司都认为自己已经合规了。人们通常很难承认自己的错误，特别是系统性的错误。因此，保持合规性的最重要的必要步骤可能是公司定期评估自己的合规性。

First, exercise a request CCS for all copylefted works from all your upstream providers of software and of components embedding software. Then, perform your own CCS check on this material first, and verify that it meets the requirements. This tutorial presents later a case study of a COGEO's CCS check in [21,] which you can emulate when examining their own CCS.

首先，向所有软件和嵌入软件组件的上游提供商请求所有Copyleft作品的CCS。然后，首先对这些材料进行自己的CCS检查，并验证其是否符合要求。本教程随后将在21中提供COGEO的CCS检查案例，你可以在检查自己的CCS时进行仿效。

Second, measure all copyleft compliance from the position of the users⁵³ downstream from you exercising their rights under GPL. Have those users received notice of the copylefted software included in your product? Is CCS available to the users easily (preferably by automated means)? Ask yourself these questions frequently. If you cannot answer these questions with certainty in the positive, dig deeper and modify your process.

其次，从使用GPL下游用户⁵³的角度度量所有Copyleft合规性。这些用户是否收到了你产品中包含的Copyleft软件的通知？用户是否能够轻松获取CCS（最好通过自动化手段）？经常问自己这些问题。如果你无法确定地回答这些问题，请深入挖掘并修改你的流程。

Avoid "compliance industry" marketing distractions and concentrate on the copylefted software you already know is in your product. Historically, the risk from a copylefted code snippet that some programmer dropped in your proprietary product careless of the consequences is a problem far more infrequent and less difficult to resolve. Efficient management of the risks of higher concern lies in making sure you can provide, for example, precisely CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that you included in a product your company shipped two years ago than in the risk of 10 lines of GPL'd Java code an engineer accidentally pasted into the source of your ERP system.

避免“合规产业”营销分散注意力，集中精力处理你已经知道存在于你的产品中的Copyleft软件。历史上，某些程序员在你的专有产品中随意添加的Copyleft代码片段带来的风险问题远不如解决起来容易。更高关注度的风险的有效管理在于确保你可以提供例如Coreboot的副本、命名为Linux的内核、BusyBox或GNU tar的精确CCS，这些软件两年前包含在你公司发货的某个产品中，而不是在你的ERP系统源代码中无意贴入10行GPL的Java代码的风险。

Thus, reject the "compliance industry" suggestions that code scanners find and help solve fundamental compliance problems. Consider how COGEO's tend to use code scanners. FOSSology is indeed an important part of a violation investigation, but such is the last step and catches only some (usually minor) licensing notice problems. Thus, code scanners can help solve minor compliance problems once you have resolved the major ones. Code scanners do not manage risk.

因此，请拒绝“合规产业”建议，即代码扫描器可以找到和帮助解决基本的合规性问题。考虑一下COGEO的使用代码扫描器的方式。FOSSology确实是违规调查的重要组成部分，但它是最后一步，仅能发现一些（通常是较小的）许可通知问题。因此，一旦你解决了重大问题，代码扫描器可以帮助解决较小的合规问题。代码扫描器不能管理风险。

CHAPTER 16 WHEN THE LETTER COMES

第16章当信来的时候

Unfortunately, many GPL violators ignore their obligations until they are contacted by a copyright holder or the lawyer of a copyright holder. You should certainly contact your own lawyer if you have received a letter alleging that you have infringed copyrights that were licensed to you under the GPL. This section outlines a typical enforcement case and provides some guidelines for response. These discussions are generalizations and do not all apply to every alleged violation. However, COGEO's in particular universally follow the processes described herein.

16.1 Communication Is Key

16.1 沟通是关键

GPL violations are typically only escalated when a company ignores the copyright holder's initial commu- nication or fails to work toward timely compliance. Accused violators should respond very promptly to the initial request. As the process continues, violators should follow up weekly with the copyright holders to make sure everyone agrees on targets and deadlines for resolving the situation.

Ensure that any staff who might receive communications regarding alleged GPL violations understands how to channel the communication appropriately within your organization. Often, initial contact is addressed for general correspondence (e.g., by mail to corporate headquarters or by e-mail to general informational or support-related addresses). Train the staff that processes such communications to escalate them to someone with authority to take action. An uninformed response to such an inquiry (e.g., from a first-level technical support person) can cause negotiations to fail prematurely.

确保任何可能收到关于涉嫌违反GPL了解如何引导沟通适当地在您的组织内。通常，初次接触是用于一般通信（例如，通过邮寄给公司总部或通过电子邮件发送给一般信息或支持相关的地址）。培训处理此类通信的员工以将他们上报给有权采取行动的人。一个不知情的对此类询问的回应（例如，来自一级技术支持者）可能导致谈判过早失败。

Answer promptly by multiple means (paper letter, telephone call, and email), even if your response merely notifies the sender that you are investigating the situation and will respond by a certain date. Do not let the conversation lapse until the situation is fully resolved. Proactively follow up with synchronous communication means to be sure communications sent by non-reliable means (such as email) were received. Remember that the software freedom community generally values open communication and cooperation, and these values extend to GPL enforcement. You will generally find that software freedom developers and their lawyers are willing to have a reasonable dialogue and will work with you to resolve a violation once you open the channels of communication in a friendly way.

通过多种方式（纸质信函、电话、电子邮件），即使您的回复只是通知发件人您是调查情况，并将在特定日期前做出回应。不要让谈话停止，直到情况完全解决。以同步沟通方式主动跟进以确保通过不可靠的方式（例如电子邮件）发送的通信被已收到。请记住，软件自由社区通常重视开放的交流与合作，这些价值观延伸到GPL强制执行。您通常会发现软件自由开发商和他们的律师愿意进行合理的对话一旦您以友好的方式打开沟通渠道，我们将与您一起解决违规问题。

Furthermore, if the complaint comes from a COGEO, assume they are well-prepared. COGEO's fully investigate compliance issues before raising the issue. The claims and concerns will be substantiated, and immediate denials will likely lead the COGEO to suspect malice rather than honest mistake.

此外，如果投诉来自COGEO，假设他们是早有准备。COGEO之前全面调查合规问题提出问题。索赔和担忧将得到证实，并且立即否认可能会导致COGEO怀疑恶意而不是而不是诚实的错误。

However, the biggest and most perennial mistake that all COGEOs see during enforcement is this: failure to include the violators' software development teams in the enforcement discussions and negotiations. As described above, CCS verification and approval is the most time-consuming and difficult part of resolving most compliance matters. Without direct contact between software developers on both sides, the resolution of the technical issues involved in demonstrating that the binary distributed was built from the source provided is likely to be tortuous, expensive, and tense. Your lawyers will certainly be understandably reluctant to expose your employees to direct inquiry from potentially adverse parties. However, facilitated exchanges of information among software engineers communicating on technical subjects shortens the time to resolution, substantially reduces the cost of reaching resolution, and prevents unnecessary escalation due to mutual misunderstanding. Furthermore, such frank technical discussion will often be the only way to avoid compliance litigation once a violation has occurred.

然而，所有COGEO都看到的最大和最常犯的错误执法期间是这样的：未能包括违规者的软件执行讨论和谈判中的开发团队。作为综上所述，CCS验证认可是最解决大多数合规性的耗时且困难的部分事项。软件开发人员之间没有直接联系双方，解决涉及的技术问题证明二进制分发是从源代码构建的provided很可能是曲折的、昂贵的和紧张的。你的律师可以理解的是，您肯定不愿意让您的员工暴露在来自潜在不利方的直接询问。然而，促进软件工程师之间的信息交换技术主题大大缩短了解决问题的时间降低达成决议的成本，并防止不必要的因相互误会而升级。此外，这种坦率的技术讨论往往是避免合规的唯一途径一旦发生侵权行为。

Fortunately, these frank discussions will improve your company's relationships. Free Software develop- ment communities improve software to benefit everyone, which includes you and your company. When you use copylefted community software in your products, you are part of that community. Therefore, resolv- ing a compliance matter is an occasion to strengthen your relationship to the community, by increasing communication between your developers and the project whose work you use for business benefit.

幸运的是，这些坦率的讨论将提高贵公司的关系。自由软件开发社区得到改善使所有人受益的软件，包括您和您的公司。当您在您的产品中使用copylefted社区软件时，您那个社区的一部分。因此，解决合规问题是一个加强你与社区关系的机会，通过增加开发人员与项目之间的沟通您用于商业利益的工作。

16.2 Termination

16.2 终止

Many redistributors overlook the GPL's termination provision (GPLv2 4 and GPLv3 8). Under v2, violators forfeit their rights to redistribute and modify the GPL'd software until those rights are explicitly reinstated by the copyright holder. In contrast, v3 allows violators to rapidly resolve some violations without consequence.

If you have redistributed an application under GPLv2⁵⁴, but have violated the terms of GPLv2, you must request a reinstatement of rights from the copyright holders before making further distributions, or else cease distribution and modification of the software forever. Different copyright holders condition reinstatement upon different requirements, and these requirements can be (and often are) wholly independent of the GPL. The terms of your reinstatement will depend upon what you negotiate with the copyright holder of the GPL'd program.

Since your rights under GPLv2 terminate automatically upon your initial violation, all your subsequent distributions are violations and infringements of copyright. Therefore, even if you resolve a violation on your own, you must still seek a reinstatement of rights from the copyright holders whose licenses you violated, lest you remain liable for infringement for even compliant distributions made subsequent to the initial violation.

GPLv3 is more lenient. If you have distributed only v3-licensed programs, you may be eligible under v3 § 8 for automatic reinstatement of rights. You are eligible for automatic reinstatement when:

GPLv3更宽松。如果您只分发了v3许可程序，您可能有资格根据v3*§*8获得自动恢复权利。您有资格获得自动恢复什么时候：

you correct the violation and are not contacted by a copyright holder about the violation within sixty days after the correction, or you receive, from a copyright holder, your first-ever contact regarding a GPL violation, and you correct that violation within thirty days of receipt of copyright holder's notice.

In addition to these permanent reinstatements provided under v3, violators who voluntarily correct their violation also receive provisional permission to continue distributing until they receive contact from the copyright holder. If sixty days pass without contact, that reinstatement becomes permanent. Nonetheless, you should be prepared to cease distribution during those initial sixty days should you receive a termination notice from the copyright holder.

Given that much discussion of v3 has focused on its so-called more complicated requirements, it should be noted that v3 is, in this regard, more favorable to violators than v2.

鉴于对v3的大量讨论都集中在其所谓的更多复杂的要求，需要注意的是v3是，在这个考虑到，比v2对违规者更有利。

However, note that most Linux-based systems typically include some software licensed under GPLv2-only, and thus the copyright holders have withheld permission to redistribute under terms of GPLv3. In larger aggregate distributions which include GPLv2-only works (such as the kernel named Linux), redistributors must operate as if termination is immediate and permanent, since the technological remove of GPLv2-only works from the larger distribution requires much more engineering work than the negotiation required to seek restoration of rights for distribution under GPLv2-only after permanent termination.

CHAPTER 17 STANDARD REQUESTS

第17章标准要求

As we noted above, different copyright holders have different requirements for reinstating a violator's distri- bution rights. Upon violation, you no longer have a license under the GPL. Copyright holders can therefore set their own requirements outside the license before reinstatement of rights. We have collected below a list of reinstatement demands that copyright holders often require.

Compliance on all Free Software copyrights. Copyright holders of Free Software often want a company to demonstrate compliance for all GPL'd software in a distribution, not just their own. A copyright holder may refuse to reinstate your right to distribute one program unless and until you comply with the licenses of all Free Software in your distribution.
遵守所有自由软件版权。的版权持有人自由软件通常希望公司证明所有人的合规性发行版中的GPL软件，而不仅仅是他们自己的。版权持有人可以拒绝恢复您分发一个程序的权利除非并直到您遵守所有自由软件的许可你的分布。
Notification to past recipients. Users to whom you previously distributed non-compliant software should receive a communication (email, letter, bill insert, etc.) indicating the violation, describing their rights under the GPL, and informing them how to obtain a gratis source distribution. If a customer list does not exist (such as in reseller situations), an alternative form of notice may be required (such as a magazine advertisement).
通知过去的收件人。您之前联系过的用户分布式不合规软件应收到通信（电子邮件、信件、账单插页等）表明违规行为，描述他们在GPL下的权利，并告知他们如何获得免费的源代码分发。如果客户名单不存在（例如在转销商的情况下），另一种形式的通知可能是必需的（例如杂志广告）。
Appointment of a GPL Compliance Officer. The software freedom community values personal accountability when things go wrong. Copyright holders often require that you name someone within the violating company officially responsible for Free Software license compliance, and that this indi- vidual serve as the key public contact for the community when compliance concerns arise.
**任命GPL合规官。**软件自由当出现问题时，社区重视个人责任。版权所有者通常要求您在违反公司正式负责自由软件许可证合规性，并且此人是关键的公众联系人在出现合规性问题时为社区提供服务。
Periodic Compliance Reports. Many copyright holders wish to monitor future compliance for some period of time after the violation. For some period, your company may be required to send regular reports on how many distributions of binary and source have occurred.
**定期合规报告。**许多版权所有者希望在违规发生后的一段时间内监控未来的合规性。在一段时间内，您的公司可能需要定期发送报告关于发生了多少次二进制和源代码分发。

These are just a few possible requirements for reinstatement. In the context of a GPL violation, and particularly under v2's termination provision, the copyright holder may have a range of requests in exchange for reinstatement of rights. These software developers are talented professionals from whose work your company has benefited. Indeed, you are unlikely to find a better value or more generous license terms for similar software elsewhere. Treat the copyright holders with the same respect you treat your corporate partners and collaborators.

这些只是恢复的一些可能要求。在里面违反GPL的上下文，尤其是在v2终止的情况下规定，版权持有人可能有一系列的要求换取权利的恢复。这些软件开发商是有才华的专业人士，他们的工作使贵公司受益。事实上，您不太可能找到更好的价值或更慷慨的别处类似软件的许可条款。对待版权持有人与您对待您的公司合作伙伴一样尊重，并且合作者。

CHAPTER 18 SPECIAL TOPICS IN COMPLIANCE

第18章合规的特别话题

There are several other issues that are less common, but also relevant in a GPL compliance situation. To those who face them, they tend to be of particular interest.

在GPL合规情况下，还有一些不太常见但也相关的问题。对于那些面临这些问题的人，它们往往具有特别的兴趣。

18.1 LGPL Compliance

18.1 GPL 合规

GPL compliance and LGPL compliance mostly involve the same issues. As we discussed in [14.1,] questions of modified versions of software are highly fact-dependent and cannot be easily addressed in any overview document. The LGPL adds some additional complexity to the analysis. Namely, the various LGPL versions permit proprietary licensing of certain types of modified versions. These issues are discussed in greater detail in Chapter [10] and [11.] However, as a rule of thumb, once you have determined (in accordance with LGPLv3) what part of the work is the "Application" and what portions of the source are "Minimal Corresponding Source", then you can usually proceed to follow the GPL compliance rules that discussed above, replacing our discussion of "Corresponding Source" with "Minimal Corresponding Source".

GPL合规性和LGPL合规性大多涉及相同的问题。正如我们在14.1中讨论的那样，关于软件修改版本的问题高度依赖于事实，并且无法在任何概述性文件中轻易解决。LGPL在分析中增加了一些额外的复杂性。即，各种LGPL版本允许某些类型的修改版本使用专有许可证。这些问题在第10章和第11章中进行了更详细的讨论。然而，作为一个经验法则，一旦你已经确定了（按照LGPLv3的规定）工作的哪个部分是“应用程序”，源代码的哪些部分是“最小对应源代码”，那么你通常可以继续遵循上面讨论的GPL合规规则，将我们对“对应源代码”的讨论替换为“最小对应源代码”。

LGPL also requires that you provide a mechanism to combine the Application with a modified version of the library, and outlines some options for this. Also, the license of the whole work must permit "reverse engineering for debugging such modifications" to the library. Therefore, you should take care that the EULA used for the Application does not contradict this permission.

LGPL还要求你提供一种将应用程序与库的修改版本结合的机制，并概述了一些选项。此外，整个工作的许可证必须允许“反向工程调试此类修改”到库中。因此，你应该注意，应用程序使用的EULA不应违反此许可。

Thus, under the terms of LGPL, you must refrain from license terms on works based on the licensed work that prohibit replacement of the licensed components of the larger non-LGPL'd work, or prohibit decompilation or reverse engineering in order to enhance or fix bugs in the LGPL'd components.

因此，在LGPL的条款下，你必须避免授权作品的许可条款，这些作品禁止替换较大的非LGPL作品的授权组件，或禁止反汇编或反向工程以增强或修复LGPL组件。

LGPLv3 is not surprisingly easier to understand and examine from a compliance lens, since the FSF was influenced in LGPLv3's drafting by questions and comments on LGPLv2.1 over a period of years. Admittedly, LGPLv2.1 is still in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you may encounter. The best advice there is careful study of Chapter [10.]

LGPLv3自然更易于从合规角度理解和审查，因为FSF在起草LGPLv3时受到了多年来关于LGPLv2.1的问题和评论的影响。值得注意的是，LGPLv2.1仍在广泛使用，因此遵守LGPLv2.1仍然是你可能遇到的频繁话题。最好的建议是仔细研究第10章。

However, to repeat a key point here made within that chapter: Note though that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the worst case you simply need to comply as if the software was licensed under GPLv2. The only reason you must consider the question of whether you have a "work that uses the library" or a "work based on the library" is when you wish to take advantage of the "weak copyleft" effect of the Lesser GPL. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the entire work anyway), you may find this an easier option.

然而，重复一下该章节中的一个关键观点：请注意，由于LGPLv2.1可以轻松升级为GPLv2或更高版本，在最坏的情况下，你只需要按照软件受GPLv2许可证的规定来遵守。你必须考虑是否有一个“使用该库的工作”或者“基于该库的工作”的问题的

18.2 Upstream Providers

18.2 上游供应商

With ever-increasing frequency, software development (particularly for embedded devices) is outsourced to third parties. If you rely on an upstream provider for your software, note that you cannot ignore your GPL compliance requirements simply because someone else packaged the software that you distribute. If you redistribute GPL'd software (which you do, whenever you ship a device with your upstream's software in it), you are bound by the terms of the GPL. No distribution (including redistribution) is permissible absent adherence to the license terms.

越来越多的情况下，软件开发（尤其是嵌入式设备）被外包给第三方。如果你依赖上游供应商提供的软件，请注意，你不能仅因为别人打包了你分发的软件，就忽略你的GPL合规要求。如果你重新分发GPL的软件（每当你将设备带着上游提供的软件发货时，你就在重新分发），你就必须遵守GPL的条款。在未遵守许可证条款的情况下，没有任何分发（包括重新分发）是可行的。

Therefore, you should introduce a due diligence process into your software acquisition plans. This is much like the software-oriented recommendations we make in [14.] Implementing practices to ensure that you are aware of what software is in your devices can only improve your general business processes. You should ask a clear list of questions of all your upstream providers and make sure the answers are complete and accurate. The following are examples of questions you should ask:

因此，你应该在你的软件获取计划中引入尽职调查流程。这很像我们在14章中提出的面向软件的建议。采取实践来确保你了解设备中的软件内容，只能提高你的一般业务流程。你应该向所有的上游供应商提出一系列明确的问题，并确保回答完整准确。以下是你应该问的问题示例：

What are all the licenses that cover the software in this device?
From which upstream vendors, be they companies or individuals, did you receive your software before distributing it to us?
What are your GPL compliance procedures?
If there is GPL'd software in your distribution, we will be redistributors of this GPL'd software. What mechanisms do you have in place to aid us with compliance?
If we follow your recommended compliance procedures, will you formally indemnify us in case we are nonetheless found to be in violation of the GPL?
该设备中涵盖的软件的所有许可证是什么？
你在将软件分发给我们之前从哪些上游供应商（无论是公司还是个人）处获得了你的软件？
你的GPL合规程序是什么？
如果你的分发中有GPL的软件，我们将成为这个GPL的软件的重新分发者。你有哪些机制来帮助我们合规？
如果我们遵循你推荐的合规程序，你是否会正式赔偿我们，以防我们仍然被发现违反GPL？

This last point is particularly important. Many GPL enforcement actions are escalated because of petty finger-pointing between the distributor and its upstream. In our experience, agreements regarding GPL compliance issues and procedures are rarely negotiated up front. However, when they are, violations are resolved much more smoothly (at least from the point of view of the redistributor).

最后一个问题尤其重要。许多GPL执法行动由于分销商和其上游供应商之间的琐碎指责而升级。根据我们的经验，在GPL合规问题和程序方面达成协议是很少提前谈判的。然而，当这样做时，违规处理更加顺畅（至少从再分销商的角度来看）。

Consider the cost of potential violations in your acquisition process. Using Free Software allows software vendors to reduce costs significantly, but be wary of vendors who have done so without regard for the licenses. If your vendor's costs seem "too good to be true," you may ultimately bear the burden of the vendor's inattention to GPL compliance. Ask the right questions, demand an account of your vendors' compliance procedures, and seek indemnity from them.

在你的采购过程中考虑潜在违规的成本。使用自由软件可以显著降低软件供应商的成本，但要警惕那些没有考虑许可证的供应商。如果你的供应商成本看起来“太好了”，最终你可能会承担供应商对GPL合规的忽视的负担。问对问题，要求供应商说明其合规程序，并向他们索取赔偿。

In particular, any time your vendor incorporates copylefted software, you must exercise your own rights as a user to request CCS for all the copylefted programs that your suppliers provided to you. Furthermore, you must ensure that CCS is correct and adequate yourself. Good vendors should help you do this, and make it easy. If those vendors cannot, pick a different vendor before proceeding with the product.

特别是当你的供应商使用具有版权保护的自由软件时，你必须行使自己作为用户的权利，要求所有供应商提供给你的受版权保护的程序的完整、正确的源代码。此外，你必须自己确保源代码是正确的和充分的。好的供应商应该帮助你做到这一点，并使其变得简单。如果供应商无法提供这样的帮助，请在继续使用该产品之前选择另一个供应商。

18.3 Mergers and Acquisitions

18.3 合并与收购

Often, larger companies often encounter copyleft licensing during a Mergers and Acquisitions (M&A) process. Ultimately, a merger or acquisition causes all of the other company's problems to become yours. Therefore, for most concerns, the acquirer "simply" must apply the compliance analysis and methodologies discussed earlier across the acquired company's entire product line. Of course, this is not so simple, as such effort may be substantial, but a well-defined process for compliance investigation means the required work, while voluminous, is likely rote.

在合并和收购（M&A）过程中，大公司通常会遇到知识共享许可证。最终，合并或收购会导致所有其他公司的问题成为你的问题。因此，对于大多数问题，收购者“只需”在收购公司的整个产品线上应用先前讨论的合规分析和方法。当然，这并不是那么简单，因为这样的努力可能是重大的，但是明确定义的合规调查流程意味着所需的工作虽然繁重，但很可能是例行公事。

A few sections of GPL require careful attention and legal analysis to determine the risk of acquisitions. Those handling M&A issues should pay particular attention to the requirements of GPLv2 7 and GPLv3 10-- 12 --- focusing on how they relate to the acquired assets may be of particular importance.

GPL的几个部分需要仔细关注和法律分析，以确定收购的风险。处理M&A问题的人员应特别注意GPLv2 第7条和GPLv3 第10 - 12条的要求——重点关注它们与所收购资产的关系可能是特别重要的。

For example, GPLv3 10 clarifies that in business acquisitions, whether by sale of assets or transfers of control, the acquiring party is downstream from the party acquired. This results in new automatic downstream licenses from upstream copyright holders, licenses to all modifications made by the acquired business, and rights to source code provisioning for the now-downstream purchaser. However, despite this aid given by explicit language in GPLv3, acquirers must still confirm compliance by the acquired (even if GPLv3 10 does assert the the acquirers rights under GPL, that does not help if the acquired is out of compliance altogether). Furthermore, for fear of later reprisal by the acquirer if a GPL violation is later discovered in the acquired's product line, the acquired may need to seek a waiver and release of from additional damages beyond a requirement to comply fully (and a promise of rights restoration) if a GPL violation by the acquired is later uncovered during completion of the acquisition or thereafter.

例如，GPLv3 第10条澄清，在商业收购中，无论是通过资产销售还是控制权转移，收购方都位于被收购方的下游。这导致上游版权持有人向下游自动授予新的下游许可证，授予所有被收购企业所做的修改的许可证，并为现在的下游购买者提供源代码供应的权利。然而，尽管GPLv3明确语言为收购者提供了帮助，但收购者仍必须确认被收购方的合规性（即使GPLv3 第10条确实声明了收购者在GPL下的权利，如果被收购方完全不合规，则这并不能帮助到收购者）。此外，由于担心被收购方的产品线中以后发现GPL违规行为会导致收购者以后受到报复，被收购方可能需要寻求豁免并免除额外的损害赔偿要求，除了完全遵守（并承诺恢复权利）的要求外，如果收购方的GPL违规行为在完成收购或之后被发现，就需要这样做。

Finally, other advice available regarding handling of GPL compliance in an M&A situation tends to ignore the most important issue: most essential copylefted software is not wholly copyrighted by the entities involved in the M&A transaction. Therefore, copyleft obligations likely reach out to the customers of all entities involved, as well as to the original copyright holders of the copylefted work. As such, notwithstanding the two paragraphs in GPLv3 10, the entities involved in M&A should read the copyleft licenses through the lens of third parties whose software freedom rights under those licenses are of equal importance to then entities inside the transaction.

在 M&A 情况下处理 GPL 合规的其他可用建议往往忽略了最重要的问题：大多数重要的共享软件并非完全由 M&A 交易涉及的实体拥有版权。因此，共享义务可能会延伸到所有实体客户，以及共享作品的原始版权持有人。因此，尽管 GPLv3 第10条中有两段话，但 M&A 中涉及的实体应该通过第三方的视角阅读共享许可证，这些第三方的软件自由权利在这些许可证下与交易内部实体的权利同等重要。

18.4 User Products and Installation Information

18.4 用户产品和安装信息

GPLv3 requires you to provide "Installation Information" when v3 software is distributed in a "User Product." During the drafting of v3, the debate over this requirement was contentious. However, the provision as it appears in the final license is reasonable and easy to understand.

GPLv3要求在分发“用户产品”中的v3软件时提供“安装信息”。在v3起草期间，对此要求的争论很激烈。然而，在最终许可证中出现的规定是合理且易于理解的。

If you put GPLv3'd software into a User Product (as defined by the license) and you have the ability to install modified versions onto that device, you must provide information that makes it possible for the user to install functioning, modified versions of the software. Note that if no one, including you, can install a modified version, this provision does not apply. For example, if the software is burned onto an non-field- upgradable ROM chip, and the only way that chip can be upgraded is by producing a new one via a hardware factory process, then it is acceptable that the users cannot electronically upgrade the software themselves.

如果你将GPLv3的软件放入用户产品中（根据许可证的定义），并且你有能力将修改版安装到该设备上，你必须提供信息，使用户能够安装功能齐全的修改版软件。请注意，如果没有人（包括你在内）能够安装修改版，这项规定就不适用。例如，如果软件被烧录到不可升级的ROM芯片上，唯一的升级方式是通过硬件工厂流程制造新芯片，那么用户无法电子升级软件本身是可以接受的。

Furthermore, you are permitted to refuse support service, warranties, and software updates to a user who has installed a modified version. You may even forbid network access to devices that behave out of speci- fication due to such modifications. Indeed, this permission fits clearly with usual industry practice. While it is impossible to provide a device that is completely unmodifiable⁵⁵, users are generally on notice that they risk voiding their warranties and losing their update and support services when they make modifications.⁵⁵

此外，你被允许拒绝向安装修改版的用户提供支持服务、保修和软件更新。你甚至可以禁止因此类修改而出现规格不符的设备访问网络。事实上，这个许可与通常的行业惯例完全相符。虽然无法提供完全不可修改的设备⁵⁵，但用户通常会注意到，当他们进行修改时，他们冒着使保修失效和失去更新和支持服务的风险。⁵⁶

GPLv3 is in many ways better for distributors who seek some degree of device lock-down. Technical processes are always found for subverting any lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike with GPLv2, the license gives you clear provisions that you can rely on when you are forced to cut off support, service or warranty for a customer who has chosen to modify.

GPLv3在许多方面对寻求某种程度的设备锁定的分发商更为有利。技术过程总是被发现用于颠覆任何锁定；追求这一点总是徒劳无功的。与GPLv2不同，GPLv3许可证在你被迫切断为已选择修改的客户提供支持、服务或保修时，为你提供了清晰的规定。

18.5 Beware The Consultant in Enforcers' Clothing

18.5 注意扮成执法者的顾问

There are admittedly portions of the GPL enforcement community that function somewhat like the computer security and network penetration testing hacker community. By analogy, most COGEO's consider themselves white hats, while some might appropriately call [proprietary relicensing] by the name "black hats". And, to finalize the analogy, there are indeed few grey hat GPL enforcers.

公开执法GPL的社区中，有一部分确实像计算机安全和网络渗透测试黑客社区一样运作。类比地，大多数COGEO认为自己是“白帽子”，而一些人可能恰当地将“专有重新许可”称为“黑帽子”。此外，确实有一些灰帽GPL执法者。

Grey hat GPL enforcers usually have done some community-oriented GPL enforcement themselves, typ- ically working as a volunteer for a COGEO, but make their living as a "hired gun" consultant to find GPL violations and offer to "fix them" for companies. Other such operators hold copyrights in some key piece of copylefted software and enforce as a mechanism to find out who is most likely to fund improvements on the software.

灰帽GPL执法者通常已经自己进行过一些面向社区的GPL执行，通常作为COGEO的志愿者工作，但他们通过作为“聘用枪手”顾问为公司寻找GPL违规行为并提供“修复”服务谋生。其他类似的运营商拥有某些关键的copylefted软件的版权，并强制执行以了解谁最有可能为软件改进提供资金。

A few companies report that they have formed beneficial consulting or employment relationships with developers they first encountered through enforcement. In some such cases, companies have worked with such consultants to alter the mode of use of the project's code in the company's products. More often in these cases, the communication channels opened in the course of the inquiry served other consulting purposes later.

一些公司报告称，他们已经与通过执行遇到的开发人员建立了有益的咨询或雇佣关系。在某些这样的情况下，公司已经与这些顾问合作，以改变项目代码在公司产品中的使用方式。在这些情况下，更多的是，在调查过程中开放的通信渠道后来为其他咨询目的服务。

Feelings and opinions about this behavior are mixed within the larger copyleft community. Some see it as a reasonable business model and others renounce it as corrupt behavior. Regardless, a GPL violator should always immediately determine the motivations of the enforcer via documented, verifiable facts. For example, COGEOs such as the FSF and Conservancy have made substantial public commitments to enforce in a way that is uniform, transparent, and publicly documented. Furthermore, since these specific organizations are public charities in the USA, they are accountable to the IRS (and the public at large) in their annual Form 990 filings. Everyone may examine their revenue models and scrutinize their work.

在更广泛的copyleft社区中，人们对这种行为的感受和意见是各不相同的。有些人认为这是一个合理的商业模式，而另一些人则谴责它是腐败行为。无论如何，GPL违规者应该始终通过有文件记录的可验证事实来确定执法者的动机。例如，像自由软件基金会（FSF）和保护协会这样的COGEO已经做出了重大的公开承诺，以一种统一、透明和公开记录的方式进行执法。此外，由于这些特定组织是美国的公共慈善机构，它们在年度990表申报中对IRS（以及公众）负责。每个人都可以审查它们的收入模型和审查它们的工作。

However, entities and individuals who do GPL enforcement centered primarily around a profit motive are likely the most dangerous enforcement entities for one simple reason: an agreement to comply fully with the GPL for past and future products --- always the paramount goal to COGEOs --- may not suffice as adequate resolution for a proprietary relicensing company or grey hat GPL enforcer. Therefore, violators must consider carefully who has made the enforcement inquiry and ask when and where the enforcer made public commitments and reports regarding their enforcement work and perhaps even ask the enforcer to directly mimic CEOGEO's detailed public disclosures and follow the [standard requests for resolution] found in this document.

然而，以盈利为中心的GPL执法实体和个人可能是最危险的执法实体，原因很简单：对于一个专门进行专有再许可的公司或灰帽GPL执法者而言，完全遵守过去和未来产品的GPL协议可能不足以作为充分的解决方案。因此，违规者必须仔细考虑谁进行了执法调查，并询问执法者何时何地作出公开承诺和报告其执法工作，甚至可以要求执法者直接模仿COGEO的详细公开披露并遵循本文档中找到的标准解决请求。 \

CHAPTER 19 CONCLUSION

第十九章结论

GPL compliance need not be an onerous process. Historically, struggles have been the result of poor de- velopment methodologies and communications, rather than any unexpected application of the GPL's source code disclosure requirements.

遵循GPL并不一定需要特别复杂的流程。根据历史经验，糟糕的开发方法和沟通所导致的结果往往是争议，而非任何GPL源代码公开要求的不经意应用。

Compliance is straightforward when the entirety of your enterprise is well-informed and well-coordinated. The receptionists should know how to route a GPL source request or accusation of infringement. The lawyers should know the basic provisions of Free Software licenses and your source disclosure requirements, and should explain those details to the software developers. The software developers should use a version control system that allows them to associate versions of source with distributed binaries, have a well-documented build process that anyone skilled in the art can understand, and inform the lawyers when they bring in new software. Managers should build systems and procedures that keep everyone on target. With these practices in place, any organization can comply with the GPL without serious effort, and receive the substantial benefits of good citizenship in the software freedom community, and lots of great code ready-made for their products.

当您所在的企业可以得到充足的信息和良好的协作时，是很容易做到合规的。接洽人员应该熟悉如何发送GPL源请求或侵权指控。法务人员应该了解自由软件许可的基本条款和自有源代码的披露要求，并有义务向软件开发人员解释这些细节问题。软件开发人员应使用版本控制系统，通过该系统将源代码版本与分布式二进制文件相关联，使用一个良好的文档编辑流程，方便任何熟悉技术的人员快速理解，并可以在法务引入新软件时通知他们及时收悉。管理者应该建立一套能够让每个人都能达到目标的制度和程序。通过这些实践，任何组织都能轻而易举地遵守GPL，并在自由软件社区中获得良好公民身份的资格与福利，同时为他们的产品收获大量现成的优质代码。

Part III Case Studies in GPL Enforcement

第2部分 GPL 执行案例研究

PREFACE

前言

This one-day course presents the details of five different GPL compliance cases handled by FSF's GPL Compliance Laboratory. Each case offers unique insights into problems that can arise when the terms of the GPL are not properly followed, and how diplomatic negotiation between the violator and the copyright holder can yield positive results for both parties.

Attendees should have successfully completely the course, a "Detailed Study and Analysis of the GPL and LGPL," as the material from that course forms the building blocks for this material.

与会者应已成功完成课程，“详细 GPL和LGPL的研究和分析“，作为其中的材料课程构成了该材料的基石。

This course is of most interest to lawyers who have clients or employers that deal with Free Software on a regular basis. However, technical managers and executives whose businesses use or distribute Free Software will also find the course very helpful.

本课程对有客户或定期与自由软件打交道的雇主。然而其业务使用或分发的技术经理和高管自由软件也会发现这门课程非常有帮助。

These course materials are merely a summary of the highlights of the course presented. Please be aware that during the actual GPL course, class discussion supplements this printed curriculum. Simply reading it is not equivalent to attending the course.

这些课程材料只是对课程介绍。请注意，在实际的 GPL 课程中，课堂讨论是对这一印刷课程的补充。简单阅读它不等同于参加课程。

CHAPTER 20 OVERVIEW OF COMMUNITY ENFORCEMENT

第20章社区执法概述

The GPL is a Free Software license with legal teeth. Unlike licenses like the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is designed to defend as well as grant freedom. We saw in the last course that the GPL uses copyright law as a mechanism to grant all the key freedoms essential in Free Software, but also to ensure that those freedoms propagate throughout the distribution chain of the software.

GPL 是一个具有法律效力的自由软件许可证。与许可证不同像 X11 风格或各种 BSD 许可证一样，GPL（以及扩展， LGPL）旨在捍卫和给予自由。我们在 GPL使用版权法作为机制的最后一门课程授予自由软件中必不可少的所有关键自由，但也授予确保这些自由在整个分销链中传播的软件。

20.1 Termination Begins Enforcement

20.1 终止开始强制执行

As we have learned, the assurance that Free Software under the GPL remains Free Software is accomplished through various terms of the GPL: 3 ensures that binaries are always accompanied with source; 2 ensures that the sources are adequate, complete and usable; 6 and 7 ensure that the license of the software is always the GPL for everyone, and that no other legal agreements or licenses trump the GPL. It is 4, however, that ensures that the GPL can be enforced.

正如我们所了解到的，保证GPL下的自由软件仍然自由软件是通过各种条款完成的 GPL：3 确保二进制文件始终与源代码一起提供;2 确保来源充足、完整和可用;6 和 7 确保软件的许可证始终是 GPL 每个人，并且没有其他法律协议或许可证胜过 GPL。然而，正是 4 确保了 GPL 的执行。

Thus, 4 is where we begin our discussion of GPL enforcement. This clause is where the legal teeth of the license are rooted. As a copyright license, the GPL governs only the activities governed by copyright law --- copying, modifying and redistributing computer software. Unlike most copyright licenses, the GPL gives wide grants of permission for engaging with these activities. Such permissions continue, and all parties may exercise them until such time as one party violates the terms of the GPL. At the moment of such a violation (i.e., the engaging of copying, modifying or redistributing in ways not permitted by the GPL) 4 is invoked. While other parties may continue to operate under the GPL, the violating party loses their rights.

因此，4 是我们开始讨论 GPL 执行的地方。这条款是许可证的法律牙齿扎根的地方。作为一个版权许可，GPL 仅管辖受版权法 ---复制、修改和重新分发计算机软件。与大多数版权许可证，GPL给予广泛的许可参与这些活动。此类权限将继续，并且所有当事人可以行使这些权利，直到一方违反 GPL 的条款。在发生此类违规行为时（即以不允许的方式进行复制、修改或重新分发通过 GPL） 4 被调用。而其他各方可能继续运营根据 GPL，违规方将失去其权利。

Specifically, 4 terminates the violators' rights to continue engaging in the permissions that are otherwise granted by the GPL. Effectively, their rights revert to the copyright defaults --- no permission is granted to copy, modify, nor redistribute the work. Meanwhile, 5 points out that if the violator has no rights under the GPL, they are prohibited by copyright law from engaging in the activities of copying, modifying and distributing. They have lost these rights because they have violated the GPL, and no other license gives them permission to engage in these activities governed by copyright law.

具体来说，4终止了违规者继续参与的权利在 GPL 以其他方式授予的权限中。有效他们的权利恢复为版权默认值---没有权限授予复制、修改或重新分发作品的权限。同时，5 指出，如果违反者在GPL下没有权利，他们是版权法禁止从事以下活动复制、修改和分发。他们失去了这些权利因为他们违反了GPL，并且没有其他许可证给他们允许从事受版权法管辖的这些活动。

20.2 Ongoing Violations

20.2 持续的违规行为

In conjunction with 4's termination of violators' rights, there is one final industry fact added to the mix: rarely does one engage in a single, solitary act of copying, distributing or modifying software. Almost always, a violator will have legitimately acquired a copy of a GPL'd program, either making modifications or not,

结合4的终止侵权者权利，有一个最后的行业事实补充：很少有人参与复制、分发或修改软件的单一、单独行为。几乎总是，违规者会合法地获得一份副本 GPL 程序，无论是否进行修改，

and then begun distributing that work. For example, the violator may have put the software in boxes and sold them at stores. Or perhaps the software was put up for download on the Internet. Regardless of the delivery mechanism, violators almost always are engaged in ongoing violation of the GPL.

然后开始分发该作品。例如，违规者可能已将软件放在盒子中并在商店出售。或者也许软件在互联网上可供下载。无论交付机制，违反者几乎总是在持续违反GPL。

In fact, when we discover a GPL violation that occurred only once --- for example, a user group who distributed copies of a GNU/Linux system without source at one meeting --- we rarely pursue it with a high degree of tenacity. In our minds, such a violation is an educational problem, and unless the user group becomes a repeat offender (as it turns out, they never do), we simply forward along a FAQ entry that best explains how user groups can most easily comply with the GPL, and send them on their merry way.

事实上，当我们发现只发生过一次 GPL 违规时--- 例如，分发 GNU/Linux 系统副本的用户组在一次会议上没有来源---我们很少以高坚韧程度。在我们看来，这种侵犯是一种教育问题，除非用户组成为累犯者（因为它事实证明，他们从不这样做），我们只是沿着常见问题解答条目转发最好地解释用户组如何最容易地遵守 GPL，以及送他们快乐的路。

It is only the cases of ongoing GPL violation that warrant our active attention. We vehemently pursue those cases where dozens, hundreds or thousands of customers are receiving software that is out of compliance, and where the company continually offers for sale (or distributes gratis as a demo) software distributions that include GPL'd components out of compliance. Our goal is to maximize the impact of enforcement and educate industries who are making such a mistake on a large scale.

只有持续违反 GPL 的情况才值得我们积极关注。我们强烈追查那些案件，其中数十，成百上千的客户正在接收已淘汰的软件合规性，以及公司持续提供销售（或免费分发作为演示）软件分发，包括 GPL 组件不合规。我们的目标是最大限度地发挥影响力执法和教育犯了这种错误的行业规模大。

In addition, such ongoing violation shows that a particular company is committed to a GPL'd product line. We are thrilled to learn that someone is benefiting from Free Software, and we understand that sometimes they become confused about the rules of the road. Rather than merely giving us a postmortem to perform on a past mistake, an ongoing violation gives us an active opportunity to educate a new contributor to the GPL'd commons about proper procedures to contribute to the community.

此外，这种持续的违规行为表明，特定公司是致力于GPL产品线。我们很高兴得知有人从自由软件中受益，我们理解这一点有时他们对道路规则感到困惑。而不仅仅是给我们一个事后分析来执行过去的错误，一个持续的违规行为为我们提供了一个积极的机会来教育新的 GPL 共享资源的贡献者关于贡献的正确程序到社区。

Our central goal is not, in fact, to merely clear up a particular violation. In fact, over time, we hope that our compliance lab will be out of business. We seek to educate the businesses that engage in commerce related to GPL'd software to obey the rules of the road and allow them to operate freely under them. Just as a traffic officer would not revel in reminding people which side of the road to drive on, so we do not revel in violations. By contrast, we revel in the successes of educating an ongoing violator about the GPL so that GPL compliance becomes a second-nature matter, allowing that company to join the GPL ecosystem as a contributor.

事实上，我们的中心目标不仅仅是澄清一个特定的问题。违反。事实上，随着时间的推移，我们希望我们的合规实验室将是停业。我们寻求教育从事以下业务的企业与GPL软件相关的商业，以遵守道路规则和允许他们在他们之下自由运作。就像交通官员一样不会陶醉于提醒人们在马路的哪一边开车上，所以我们不陶醉于违规行为。相比之下，我们陶醉在成功教育持续违反 GPL 的人，以便 GPL 合规成为第二天性问题，允许该公司作为贡献者加入 GPL 生态系统。

20.3 How are Violations Discovered?

20.3 如何发现违规行为？

Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL Compliance Lab runs at a loss (in other words, it is subsided by our donors). Our violation reports come from volunteers, who have encountered, in their business or personal life, a device or software product that appears to contain GPL'd software. These reports are almost always sent via email to license-violation@fsf.org>.

我们对 GPL 的执行不是筹款工作;事实上 FSF 的 GPL 合规性实验室亏本运行（换句话说，它是由我们的捐助者补贴）。我们的违规报告来自志愿者，在业务或个人生活中遇到设备或似乎包含 GPL 软件的软件产品。这些报告几乎总是通过电子邮件发送到 license-violation@fsf.org。

Our first order of business, upon receiving such a report, is to seek independent confirmation. When possible, we get a copy of the software product. For example, if it is an offering that is downloadable from a Web site, we download it and investigate ourselves. When it is not possible for us to actually get a copy of the software, we ask the reporter to go through the same process we would use in examining the software.

在收到这样的报告后，我们的首要任务是寻求独立确认。如果可能，我们会获得软件的副本产品。例如，如果它是可从网站，我们下载它并自己调查。当它不是我们可能实际获得该软件的副本，我们要求报告者经历我们在检查软件。

By rough estimation, about 95% of violations at this stage can be confirmed by simple commands. Almost all violators have merely made an error and have no nefarious intentions. They have made no attempt to remove our copyright notices from the software. Thus, given the third-party binary, tpb, usually, a simple command (on a GNU/Linux system) such as the following will find a Free Software copyright notice and GPL reference:

    strings tpb \| grep Copyright

In other words, it is usually more than trivial to confirm that GPL'd software is included.

换句话说，确认 GPL 通常不是微不足道的包括软件。

Once we have confirmed that a violation has indeed occurred, we must then determine whose copyright has been violated. Contrary to popular belief, FSF does not have the power to enforce the GPL in all cases. Since the GPL operates under copyright law, the powers of enforcement --- to seek redress once 4 has been invoked --- lie with the copyright holder of the software. FSF is one of the largest copyright holders in the world of GPL'd software, but we are by no means the only one. Thus, we sometimes discover that while GPL'd code is present in the software, there is no software copyrighted by FSF present.

In cases where FSF does not hold copyright interest in the software, but we have confirmed a violation, we contact the copyright holders of the software, and encourage them to enforce the GPL. We offer our good offices to help negotiate compliance on their behalf, and many times, we help as a third party to settle

such GPL violations. However, what we will describe primarily in this course is FSF's first-hand experience enforcing its own copyrights and the GPL.

此类违反 GPL 的行为。但是，我们将在此主要描述的内容课程是 FSF 执行自己的版权和GPL的第一手经验。

20.4 First Contact

20.4 第一次接触

The Free Software community is built on a structure of voluntary cooperation and mutual help. Our community has learned that cooperation works best when you assume the best of others, and only change policy, procedures and attitudes when some specific event or occurrence indicates that a change is necessary. We treat the process of GPL enforcement in the same way. Our goal is to encourage violators to join the cooperative community of software sharing, so we want to open our hand in friendship.

自由软件社区建立在自愿的结构之上合作互助。我们的社区已经了解到当你假设别人最好的时，合作效果最好，而且只有在某些特定事件或发生表示需要更改。我们对待过程以同样的方式执行 GPL。我们的目标是鼓励违规者加入软件共享的合作社区，所以我们想在友谊中张开我们的手。

Therefore, once we have confirmed a violation, our first assumption is that the violation is an oversight or otherwise a mistake due to confusion about the terms of the license. We reach out to the violator and ask them to work with us in a collaborative way to bring the product into compliance. We have received the gamut of possible reactions to such requests, and in this course, we examine four specific examples of such compliance work.

因此，一旦我们确认了违规行为，我们的第一个假设是违规行为是疏忽或其他错误，原因是对许可条款的混淆。我们联系违规者并要求他们以协作的方式与我们合作，以带来产品合规。我们已经收到了可能的所有范围对此类请求的反应，在本课程中，我们将研究四个此类合规工作的具体示例。

CHAPTER 21 THINKPENGUIN WIRELESS ROUTER: EXCELLENT CCS

第21章 THINKPENGUIN 无线路由器：优秀的 CCS

Too often, case studies examine failure and mistakes. Indeed, most of the chapters that follow herein will consider the myriad difficulties discovered in community-oriented GPL enforcement for the last two decades. However, to begin, this is a case study in how copyleft compliance can indeed be done correctly.

往往情况下，案例研究都是关于失败和错误的。事实上，下面的大多数章节将考虑过去二十年中在面向社区的 GPL 执行方面所发现的无数困难。然而，首先，这是一个关于如何正确执行版权合规性的案例研究。

This example is, in fact, more than ten years in the making. Since almost the inception of for-profit corporate adoption of Free Software, companies have requested a clear example of a model citizen to emulate. Sadly, while community-oriented enforcers have vetted uncounted thousands of "Complete, Corresponding Source" (CCS) candidates from hundreds of companies, this particular CCS release described herein is the first ever declared a "pristine example".

事实上，这个例子已经经过了十年以上的时间。自从营利性企业采用自由软件的几乎开始以来，公司们一直在要求一个明确的示范公民的清晰案例来仿效。遗憾的是，尽管面向社区的执行者们从数百家公司中审核了无数个"完整的、相应的源代码"(CCS) 候选者，但这个在此描述的 CCS 版本是第一个被宣布为"纯净样例"的。

Of course, most CCS examined for the last decade has (eventually) complied with the GPL, perhaps after many iterations of review by the enforcer. However, in the experience of the two primary community-oriented enforcers (Conservancy and the FSF), such CCS results routinely "barely comply with GPL's requirements". To use an academic analogy: while a "C" is certainly a passing grade, any instructor prefers to disseminate to the class an exemplar sample that earned an "A".

当然，过去十年中大多数 CCS 最终都符合了 GPL，可能经过了执行者的多次审核。然而，在面向社区的两个主要执行者（Conservancy 和 FSF）的经验中，这样的 CCS 结果通常只是"勉强符合 GPL 的要求"。用一个学术类比：虽然"C"当然是及格的，但是任何教师都更喜欢向班上展示一个获得"A"的样例。

Fortunately, thanks in large part to the FSF's "Respects Your Freedom" (RYF) certification campaign[^1^], a few electronics products on the market meet a higher standard of copyleft compliance. As such, for the first time in the history of copyleft, CCS experts have pristine examples to study and present as exemplars worthy of emulation.

幸运的是，由于大部分得益于 FSF 的"尊重你的自由"(RYF) 认证运动，市场上有几款电子产品符合了更高的版权合规标准。因此，对于版权合规的历史来说，CCS 专家们有了可供研究和展示的纯净样例，值得仿效。

This case study therefore examines the entire life-cycle of a GPL compliance investigation: from product purchase, to source request, to CCS review, and concluding in a final compliance determination. Specifically, this chapter discusses the purchase, CCS provision, and a step-by-step build and installation analysis of a specific, physical, embedded electronics product: the "TPE-NWIFIROUTER" wireless router by ThinkPenguin.[^2^]

因此，这个案例研究考察了 GPL 合规调查的整个生命周期：从购买产品到请求源代码，到 CCS 审查，以及最终的合规性决定。具体而言，本章讨论了购买、CCS 提供以及特定的物理嵌入式电子产品（ThinkPenguin 的"TPE-NWIFIROUTER"无线路由器）[^2^]的逐步构建和安装分析。

21.1 Consumer Purchase and Unboxing

21.1 消费者购买和开箱

The process for copyleft compliance investigation, when properly conducted, determines whether users in- clined to exercise their rights under a copyleft license will be successful in their attempt. Therefore, at every stage, the investigator seeks to take actions that reasonably technically knowledgeable users would during the ordinary course of their acquisition and use of copyleft-covered products. As such, the investigator typ- ically purchases the device on the open market to verify that distribution of the copylefted software therein complies with binary distribution requirements (such as those discussed earlier in 5.2 and 9.9).

如果正确进行，copyleft 合规调查的过程将确定倾向于行使 copyleft 许可下权利的用户是否能够成功实现他们的尝试。因此，在每个阶段，调查人员都会寻求采取合理的技术知识，通常是在获取和使用 copyleft 覆盖产品的普通过程中普通用户会采取的行动。因此，调查人员通常会在开放市场上购买设备，以验证其中 copylefted 软件的分发是否符合二进制分发要求（例如 5.2 和 9.9 中讨论的那些要求）。

Therefore, the investigator first purchased the TPE-NWIFIROUTER through an online order, and when the package arrived, examined the contents of the box. The investigator immediately discovered that ThinkPenguin had taken advice from [15.1.2,] and exercised GPLv2 3(a) and GPLv3 6, rather than us- ing the [problematic offer for source provisions.] This choice not only accelerated the investigation (since there was no CCS offer to "test"), but also simplified the compliance requirements for ThinkPenguin.

因此，调查人员首先通过在线订购购买了TPE-NWIFIROUTER，并在包裹到达后检查了盒子的内容。调查人员立即发现，ThinkPenguin已经遵循了15.1.2节的建议，并执行了GPLv2 3(a)和GPLv3 6节，而不是使用问题来源提供条款。这种选择不仅加速了调查过程（因为没有CCS来源提供要“测试”），还简化了ThinkPenguin的合规要求。

21.2 Root Filesystem and Kernel Compilation

21.2 Root文件系统和内核合规

The CD found in the box was labeled "libreCMC v1.2.1 source code", and contained 407 megabytes of data. The investigator copied this ISO to a desktop GNU/Linux system and examined its contents. Upon doing so, the investigator immediately found a file called "README" at the top-level directory:

盒子里发现的CD标签上写着“libreCMC v1.2.1源代码”，里面包含407兆字节的数据。调查员将这个ISO文件复制到一个桌面GNU/Linux系统并检查了它的内容。在这样做的过程中，调查员立即在顶级目录下发现了一个名为“README”的文件。

$ dd if=/dev/cdrom of=libreCMC_v1.2.1_SRC.iso 
$ mkdir libCMC 
$ sudo mount -o loop ./libreCMC_v1.2.1_SRC.iso libCMC 
mount: block device /path/to/libreCMC_v1.2.1_SRC.iso 
       is write-protected, mounting read-only 
$ ls -1 libCMC 
bin 
librecmc-u-boot.tar.bz2 
librecmc-v1.2.1.tar.bz2 
README 
u-boot_reflash 
$ cat libCMC/README 
...

The investigator therefore knew immediately to begin the CCS check should begin with a study of the contents of "README". Indeed, that file contained the appropriate details to start the build:

In order to build firmware images for your router, the following needs to be installed:

gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff, unzip, gawk, getopt, libz-dev and libc headers.

Please use "make menuconfig" to configure your appreciated configuration for the toolchain and firmware. Please note that the default configuration is what was used to build the firmware image for your router. It is advised that you use this configuration.

Simply running "make" will build your firmware. The build system will download all sources, build the cross-compile toolchain, the kernel and all chosen applications.

To build your own firmware you need to have access to a GNU/Linux system (case-sensitive filesystem required).

为了为您的路由器构建固件映像，需要安装以下内容：

gcc、binutils、bzip2、flex、python、perl、make、find、grep、diff、unzip、gawk、getopt、libz-dev和libc头文件。

请使用“make menuconfig”配置您欣赏的工具链和固件的配置。请注意，默认配置是用于构建路由器固件映像的配置。建议您使用此配置。

只需运行“make”即可构建您的固件。构建系统将下载所有源代码，构建交叉编译工具链、内核和所有已选择的应用程序。

要构建自己的固件，您需要访问一个GNU/Linux系统（需要区分大小写的文件系统）。

In other words, the first "script" that investigator "ran" was the above. This was not a software script, rather the processor for the script was the investigator's own brain - like a script of a play. Less glibly stated: instructions written in English are usually necessary for the build and installation operations that demand actual intelligence. In this case, the investigator ascertained the host system requirements for construction of this embedded firmware.

换句话说，调查员“运行”的第一个“脚本”就是上述内容。这不是软件脚本，而是调查员自己的大脑充当脚本的处理器——就像一部戏剧的剧本。更严谨地说：通常需要使用英语编写的说明来进行构建和安装操作，这些操作需要实际智能。在这种情况下，调查员确定了构建这个嵌入式固件所需的主机系统要求。

GPL does not give specific guidance on the form or location of "scripts used to control compilation and installation of the executable" and/or "Installation Information". Community-oriented GPL enforcers apply a "reasonableness standard" to evaluate such instructions. If an investigator of average skill in embedded firmware construction can surmise the proper procedures to build and install a replacement firmware, the instructions are likely sufficient to meet GPL's requirements. Fortunately, in this case, the instructions are more abundant and give extra detail.

GPL并没有对“用于控制可执行文件编译和安装的脚本”和/或“安装信息”的形式或位置提供具体指导，社区导向的GPL执行者采用“合理性标准”来评估此类说明。如果嵌入式固件构建方面的一般技能的调查员可以推测出正确的构建和安装程序，则说明足以满足GPL的要求。幸运的是，在这种情况下，说明更加详尽，提供了额外的细节。

Nevertheless, these instructions offer more options than the reader typically sees in other CCS candidates. More typically, top-level build instructions name an exact host distribution to use, such as "Debian 7 installed on an amd64 system with the following packages installed". Of course, if the build will fail on any other system, instructions should include such details. However, this CCS builds on a wide range of distributions, and thus it was appropriate (and preferred) that the build instructions do not specify a specific distribution. In this specific case, the developers of the libreCMC project (a Free Software project that forms the base system for the TPE-NWIFIROUTER) have clearly made an effort to ensure the CCS builds on a variety of host systems. The investigator was in fact dubious upon seeing these instructions, since finicky embedded build processes usually require a very specific host system. Fortunately, it seems such doubts were generally unfounded (although the investigator did find [a minor annoyance that could be resolved with more detailed] [instructions).]

然而，这些说明提供的选项比读者通常在其他CCS候选项中看到的要多。更典型的情况是，顶级构建说明指定要使用的确切主机分发版本，例如“在安装有以下软件包的amd64系统上安装了Debian 7”。当然，如果在任何其他系统上构建失败，说明应该包括这些详细信息。然而，这个CCS可以在各种发行版上构建，因此不指定特定的发行版是合适的（也是首选的）。在这个特定情况下，libreCMC项目的开发人员（一个自由软件项目，形成TPE-NWIFIROUTER的基础系统）已经明确努力确保CCS在各种主机系统上构建。实际上，调查员对这些说明持怀疑态度，因为挑剔的嵌入式构建过程通常需要非常具体的主机系统。幸运的是，似乎这种怀疑通常是没有根据的（尽管调查员确实发现了一些可以通过更详细的说明解决的小问题（参见＃u-boot-compilation））。

Anyway, since these instructions did not specify a specific host system, the investigator simply used his own amd64 Debian GNU/Linux 6 desktop system. Before beginning, the investigator used the following command:

无论如何，由于这些说明没有指定特定的主机系统，调查员只是使用了自己的amd64 Debian GNU / Linux 6桌面系统。在开始之前，调查员使用了以下命令：

$ dpkg --list | egrep ’ˆiii’ | less

to verify that the required packages listed in the README were installed⁵⁷.

Next, the investigator then extracted the primary source package with the following command:

为了确认 README 中列出的所需软件包已安装，调查员使用了该命令。⁵⁷ 接下来，调查员使用以下命令提取主要源代码包：

$ dpkg --list | egrep ’ˆiii’ | less

The investigator did notice an additional source release, entitled "librecmc-u-boot.tar.bz2". The in- vestigator concluded upon simple inspection that the instructions found in "u-boot_reflash" were specific instructions for that part of the CCS. This was a minor annoyance, and ideally the "README" would so-state, but the CCS filesystem layout met the reasonableness standard; the skilled investigator determine the correct course of action with a few moments of study.

The investigator then noted the additional step offered by the "README", which read:

Please use "make menuconfig" to configure your appreciated configuration for the toolchain and firmware. Please note that the default configuration is what was used to build the firmware image for your router. It is advised that you use this configuration.

This instruction actually exceeds GPL's requirements. Specifically, the instruction guides users in their first step toward exercising the freedom to modify the software. While the GPL does contain requirements that facilitate the freedom to modify (such as ensuring the CCS is in the "preferred form . . . for making modifications to it"), GPL does not require specific instructions explaining how to undertake modifications. This specific instruction therefore exemplifies the exceptional quality of this particular CCS.

调查员注意到还有一个名为“librecmc-u-boot.tar.bz2”的源代码发布包。经过简单的检查，调查员得出结论，"u-boot_reflash" 中的说明是针对 CCS 的那一部分的具体说明。这是一个小小的烦恼，理想情况下，"README" 应该说明清楚，但是 CCS 文件系统布局符合合理性标准；经验丰富的调查员在短短几分钟的学习之后便能确定正确的操作步骤。

However, for purposes of the CCS verification process, typically the investigator avoids any unnecessary changes to the source code during the build process, lest the investigator err and cause the build to fail through his own modification, and thus incorrectly identify the CCS as inadequate. Therefore, the investigator proceeded to simply run:

然而，在CCS验证过程中，为了避免不必要的更改，调查人员通常在构建过程中避免对源代码进行任何更改，以免因其自己的修改而导致构建失败，并因此错误地确定CCS不足。因此，调查人员只是简单地运行了以下命令：

$ cd libCMC 
$ make

and waited approximately 40 minutes for the build to complete⁵⁸. The investigator kept a full log of the build, which is not included herein due its size (approximately 7.2K of text).

调查员运行了上述命令，并等待大约40分钟，直到构建完成⁵⁸。调查员记录了完整的构建日志，此处不包含日志，由于其大小（约7.2K的文本）。

Upon completion of the "make" process, the investigator immediately found (almost to his surprise) several large firmware files in the "bin/ar71xx" directory. Typically, this step in the CCS verification process is harrowing. In most cases, the "make" step will fail due to a missing package or because toolchain paths are not setup correctly.

当“make”过程完成后，调查员立即在“bin/ar71xx”目录下找到了几个大型固件文件，这几乎让他感到惊讶。在大多数情况下，这个CCS验证过程是困难的。通常，由于缺少软件包或工具链路径设置不正确，"make"步骤会失败。

In light of such experiences, the investigator speculated that ThinkPenguin's engineers did the most important step in self-CCS verification: test one's own instructions on a clean system. Ideally, an employee with similar skills but unfamiliar with the specific product can most easily verify CCS and identify problems before a violation occurs.

考虑到这样的经历，调查员推测ThinkPenguin的工程师们在自我CCS验证中完成了最重要的一步：在一个干净的系统上测试自己的说明。理想情况下，一位具有相似技能但不熟悉特定产品的员工可以最轻松地验证CCS并在违规发生之前识别问题。

However, upon completing the "make", the investigator was unclear which filesystem and kernel images to install on the TPE-NWIFIROUTER hardware. Ideally, the original "README" would indicate which image is appropriate for the included hardware. However, this was ultimately an annoyance rather than a compliance issue. Fortunately, the web UI (see next section) on the TPE-NWIFIROUTER performs firmware image installation. Additionally, the router's version number was specified on the bottom of the device, which indicated which of the differently-versioned images we should install. The investigator would prefer instruc- tions such as those found at http://librecmc.org/librecmc/wiki?name=Tp+MR3020instructions similar to these in the README itself; however, application of the reasonableness standard here again indicates compliance, since a knowledgeable user can easily determine the proper course of action.

然而，在完成“make”后，调查员不清楚哪个文件系统和内核镜像适合TPE-NWIFIROUTER硬件。理想情况下，原始的“README”应该指出适用于所包含硬件的映像。然而，这最终只是一个烦恼而不是合规问题。幸运的是，TPE-NWIFIROUTER上的Web UI（见下一节）执行固件映像安装。此外，路由器的版本号被指定在设备底部，表明我们应该安装哪个不同版本的映像。调查员希望在README中找到类似于http://librecmc.org/librecmc/wiki?name=Tp+MR3020这样的说明，但是这里再次适用合理性标准表明符合合规要求，因为有知识的用户可以轻松确定正确的操作。

21.3 U-Boot Compilation

21.3 U-Boot编译

The investigator then turned his attention to the file, "u-boot_reflash". These instructions explained how to build and install the bootloader for the device.

然后，调查人员将注意力转向了文件“u-boot_reflash”。这些说明解释了如何构建和安装设备的引导加载程序。

The investigator followed the instructions for compiling U-Boot, and found them quite straight-forward. The investigator discovered two minor annoyances, however, while building U-Boot:

调查人员按照编译U-Boot的说明进行操作，发现它们非常简单。然而，在构建U-Boot时，调查人员发现了两个小问题：

The variable $U-BOOT_SRC was used as a placeholder for the name of the extracted source directory. This was easy to surmise and was not a compliance issue (per the reasonableness standard), but explicitly stating that fact at the top of the instructions would be helpful.
Toolchain binaries were included and used by default by the build process. These binaries were not the appropriate ones for the investigator's host system, and the build failed with the following error:
变量$U-BOOT_SRC被用作提取的源目录名称的占位符。这很容易推断出来，并且不是一个合规问题（按照合理性标准），但在说明书的顶部明确说明这一点会更有帮助。
编译过程中默认使用了包含的工具链二进制文件。这些二进制文件不适用于调查人员的主机系统，并且编译失败，出现以下错误：

mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6: 
   version ‘GLIBC‘_2.14’ not found 
   (required by mips-librecmc-linux-uclibc-gcc.bin)

(The complete log output from the failure is too lengthy to include herein.) This issue is an annoyance, not a compliance problem. It was clear from context that these binaries were simply for a different host architecture, and the investigator simply removed "toolchain/bin" and created a symlink to utilize the toolchain already built earlier (during the compilation discussed in § [21.2):]

完整的故障日志输出太长，无法在此包含。此问题只是一个烦恼，而不是合规问题。从上下文中可以清楚地看出，这些二进制文件只是针对不同的主机架构，调查人员只需删除 "toolchain/bin" 并创建符号链接以利用之前已构建的工具链（在第21.2节中讨论的编译期间）。

$ ln -s \ 
  ../../staging_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin \ 
  toolchain/bin

After this change, the U-Boot build completed successfully.

经过这个更改，U-Boot 构建成功了。

The full log of the build is not included herein due its size (approximately 3.8K of text). After that, the investigator found a new U-Boot image in the "bin" directory.

由于体积太大（约3.8K文字），此构建的完整日志未在此处包含。之后，调查人员在 "bin" 目录中找到了一个新的 U-Boot 映像。

21.4 Root Filesystem and Kernel Installation

21.4 根文件系统和内核安装

The investigator next tested installation of the firmware. In particular, the investigator connected the TPE- NWIFIROUTER to a local network, and visited http://192.168.10.1/, logged in, and chose the option sequence: "System Backup / Flash Firmware".

接下来，调查人员测试了固件的安装。特别地，调查人员将 TPE-NWIFIROUTER 连接到本地网络，并访问 http://192.168.10.1/，登录并选择选项序列："System Backup / Flash Firmware"。

From there, the investigator chose the "Flash new firmware image" section and selected the "librecmc- ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin" image from the "bin/ar71xx" directory. The investi- gator chose the "v8" image upon verifying the physical router read "v8.2" on its bottom. The investigator chose the "sysupgrade" version of the image because this was clearly a system upgrade (as a firmware already came preinstalled on the TPE-NWIFIROUTER).

从那里，调查人员选择了 "Flash new firmware image" 部分，并从 "bin/ar71xx" 目录中选择了 "librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin" 映像。在验证物理路由器底部显示 "v8.2" 后，调查人员选择了 "v8" 映像。调查人员选择了 "sysupgrade" 映像版本，因为这显然是系统升级（因为 TPE-NWIFIROUTER 上已经预装了固件）。

Upon clicking "Flash image. . . ", the web interface prompted the investigator to confirm the MD5 hash of the image to flash. The investigator did so, and then clicked "Proceed" to flash the image. The process took about one minute, at which point the web page refreshed to the login screen. Upon logging in, the investigator was able to confirm in the "Kernel Log" section of the web interface that the newly built copy of Linux had indeed been installed.

单击 "Flash image. . . " 后，Web 接口提示调查人员确认要刷写的映像的 MD5 哈希值。调查人员确认后，点击 "Proceed" 来刷写映像。该过程大约需要一分钟，此时网页会刷新到登录界面。登录后，调查人员能够在 Web 接口的 "Kernel Log" 部分确认新构建的 Linux 副本确实已安装。

The investigator confirmed that a new version of "busybox" had also been installed by using SSH to connect to the router and ran the command "busybox", which showed the newly-compiled version (via its date of compilation).

通过使用 SSH 连接到路由器并运行 "busybox" 命令，调查人员确认已安装了新版本的 "busybox"。该命令显示了新编译版本（通过其编译日期）。

21.5 U-Boot Installation

The U-Boot installation process is substantially more complicated than the firmware update. The investigator purchased the optional serial cable along with the TPE-NWIFIROUTER, in order to complete the U-Boot installation per the instructions in "u-boot_reflash" in its section "Installing u-boot to your router", which reads:

Install and configure any TFTP server on your PC (tftp-hpa). Set a fixed IP address on your PC . . . and connect it to the router, using RJ45 network cable . . .
Connect USB to UART adapter to the router and start any application to communicate with it, like PuTTY. . . .
Power on the router, wait for a line like one of the following and interrupt the process of loading a kernel:

Autobooting in 1 seconds

(for most TP-Link routers, you should enter tpl at this point) Hit ESC key to stop autoboot: 1 (for 8devices Carambola 2, use ESC key) Hit any key to stop autoboot: 1 (for D-Link DIR-505, use any key)

Set ipaddr and serverip environment variables:

        hornet> setenv ipaddr 192.168.1.1 
        hornet> setenv serverip 192.168.1.2

在您的PC上安装和配置任何TFTP服务器（tftp-hpa）。在您的PC上设置一个固定的IP地址，并使用RJ45网络电缆将其连接到路由器上。将USB转UART适配器连接到路由器上，并启动任何通信应用程序，例如PuTTY。打开路由器电源，等待类似以下内容的提示，并中断加载内核的过程： Autobooting in 1 seconds

（对于大多数TP-Link路由器，此时您应该输入tpl）按ESC键停止自动引导：1（对于8devices Carambola 2，请使用ESC键）按任意键停止自动引导：1（对于D-Link DIR-505，请使用任意键）

设置ipaddr和serverip环境变量：

The investigator used the purchased serial cable, which was a USB serial adapter with a male USB type A connector to 4 female jumper wires. The female jumper wires were red, black, white, and green.

调查员使用了购买的串行电缆，这是一个USB串行适配器，带有一个雄性USB Type A连接器和4个母式跳线。这些母式跳线的颜色分别为红色、黑色、白色和绿色。

The instructions here were slightly incomplete, since they did not specify how to connect the wires to the router. However, the investigator found general information available online at http://wiki.openwrt.org/ toh/tp-link/tl-wr841nd#serial.console which described the proper procedure. While the "power" and "ground" cables were obvious, some trial and error was necessary to find the RX and TX cables, but this was easily determined since miswiring TX and RX yields no I/O and proper wiring yields the output as expected. Using the pin gender changer included with the adapter, the investigator was able to stably wire the pins for use once the proper RX and TX connections were determined.

这里的说明略微不完整，因为它们没有说明如何将电缆连接到路由器。然而，调查员在http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console上找到了通用的在线信息，描述了正确的过程。虽然“电源”和“地”电缆很明显，但需要一些尝试才能找到RX和TX电缆，但这很容易确定，因为错连接TX和RX不会产生I/O，正确连接会产生预期的输出。使用适配器附带的针脚转换器，一旦确定了正确的RX和TX连接，调查员就能够稳定地连接针脚以供使用。

The investigator then used the recommended 115200 8N1 for serial console settings, leaving all flow control off, and tested both with the minicom and screen commands. The investigator found that if all 4 wires were connected on the USB serial adapter that the router would start without additional power and the console would receive the startup messages. The investigator could replicate the same behavior by omitting the power cable from the USB serial adapter (red wire) and connecting the main power adapter to the router instead.

然后，调查员使用推荐的115200 8N1串行控制台设置，关闭所有流控制，并使用minicom和screen命令进行测试。调查员发现，如果将USB串行适配器上的所有4根电线连接起来，路由器就会开始启动，而控制台会收到启动消息。调查员可以通过省略USB串行适配器上的电源电缆(红线)并将主电源适配器连接到路由器上来复制相同的行为。

At this point, the on-screen messages as described in the installation instructions appeared, but the investigator found that no key events sent via the serial port appeared to reach the U-Boot console. In other words, while the investigator saw both U-Boot and kernel boot messages in the serial console, the investigator was unable to interrupt the boot process as instructed by "u-boot_reflash". Hitting a key simply did not interrupt the boot process and yield the hornet> prompt.

此时，安装说明中描述的屏幕上的消息出现了，但是调查员发现，通过串口发送的任何按键事件似乎都无法到达U-Boot控制台。换句话说，尽管调查员在串行控制台中看到了U-Boot和内核引导消息，但是调查员无法按照“u-boot_reflash”的指示打断引导过程。按键根本没有打断引导过程并显示 hornet> 提示符。

After additional trial and error over a period of hours, the investigator had finally to consider this question for the first time during the process: "Has ThinkPenguin violated the GPL?" More specifically, the immediate question was: "Given this failure, has the distributor met [the requirements for 'scripts used to] [control installation of the executable' (GPLv2)] and [necessary 'Installation Information' (GPLv3)?"]

经过数小时的额外试验和错误，调查人员最终在过程中第一次考虑了这个问题：“ThinkPenguin是否违反了GPL？”更具体地说，立即的问题是：“鉴于这个失败，发行者是否符合了“用于控制可执行文件安装的脚本”（GPLv2）和“必要的安装信息”（GPLv3）的要求？”

The appropriate answer to the question (at this specific stage) is "possibly, but more information is needed". Embedded installation and configuration is a tricky and complex technical process. While the GPL requires documentation and clear instructions for this process, the investigator did not immediately blame the distributor for what may be an honest, correctable mistake, or an issue legitimately explained by feasible alternative theories.

在这个特定阶段，这个问题的适当答案是“可能，但需要更多信息”。嵌入式安装和配置是一个棘手和复杂的技术过程。虽然GPL要求对此过程进行文档记录和清晰的说明，但调查人员并没有立即指责分发者，因为这可能是一个诚实的、可以纠正的错误，或者是一个可以通过可行的替代理论合理解释的问题。

In this case, upon remembering the issues of wiring, the investigator wonder if perhaps the power pin was accidentally connected for a moment to the RX pin while live. Such action could easily fry the RX pin, and yield the observed behavior. Since the investigator could not rule out the possibility of accidental connection of power to the RX pin mentioned, the investigator had to assume the instructions would work properly if he had not made that error.

在这种情况下，调查人员在想起接线问题后，想知道是否有可能在通电时将电源引脚误连接到了RX引脚。这样的行为可能会轻易地烧掉RX引脚，导致观察到的行为。由于调查人员不能排除提到的意外将电源连接到RX引脚的可能性，因此调查人员不得不假设如果他没有犯下这个错误，指令将正常工作。

That conclusion, while correct, also left the investigator with only two option to complete the final verification of the CCS:

这个结论虽然正确，但也让调查人员只剩下两个选项来完成CCS的最终验证：

Purchase a new router and cable anew, and reattempt the installation process while taking extra care not to miswire any cables.
Seek assistance from the libreCMC community to find an alternative method of installation.
购买新的路由器和电缆，重新尝试安装过程，并特别注意不要误接任何电缆。
寻求libreCMC社区的帮助，找到一种替代的安装方法。

The investigator chose the latter and then contacted a libreCMC developer familiar with the product. That developer, who agreed the the RX pin was likely ruined, described an alternative method for console access using the netcat. The libreCMC developer described the process as follows:

调查人员选择了后者，然后联系了一个熟悉该产品的libreCMC开发者。这位开发者同意RX引脚很可能被毁坏，并描述了一种使用netcat进行控制台访问的替代方法。该libreCMC开发者描述了如下过程：

Change the IP address of the router to 192.168.1.1.
Change the IP address of a desktop GNU/Linux system to 192.168.1.2.
Power on the router while holding the reset button for 7 seconds.
Use the netcat command (as below) on the desktop, and press enter to receive U-Boot's prompt:
- 将路由器的IP地址更改为192.168.1.1。
- 将桌面GNU/Linux系统的IP地址更改为192.168.1.2。
- 按住重置按钮7秒钟，开启路由器。
- 在桌面上使用netcat命令（如下），并按Enter键接收U-Boot的提示：

$ nc -u -p 6666 192.168.1.1 6666 
uboot>

Upon following this procedure, the investigator was able to confirm the (original) shipped version of U-Boot was still installed:

按照这个步骤，调查员确认了原始发货版本的 U-Boot 仍然安装在系统中：

$ nc -u -p 6666 192.168.1.1 6666 
uboot> version 
U-Boot 1.1.4 (Jul 28 2014)

Thereafter, the investigator followed the instructions from "u-boot_reflash". Specifically, the investigator configured a TFTP server and placed the newly built firmware into /srv/tftp. The investigator also followed the remaining instructions in "u-boot_reflash", but used the netcat console rather than the serial console, and used U-Boot's reset command to reboot the router.

此后，调查员按照“u-boot_reflash”中的说明进行操作。具体来说，调查员配置了一个 TFTP 服务器，并将新构建的固件放置在 /srv/tftp 中。调查员还按照“u-boot_reflash”中的其余说明进行操作，但是使用了 netcat 控制台而不是串行控制台，并使用了 U-Boot 的重置命令来重新启动路由器。

Upon reboot, the serial console (still connect with working output) showed the message U-Boot 1.1.4 (Oct 17 2014), and thus confirmed a successful reflash of the U-Boot image built by the investigator.

重新启动后，串行控制台（仍然连接并输出正常）显示了消息“U-Boot 1.1.4（2014 年 10 月 17 日）”，从而确认了调查员构建的 U-Boot 映像的成功重新烧写。

21.6 Firmware Comparison

21.6 固件比较

Next, to ensure the CCS did indeed correspond to the firmware original installed on the TPE-NWIFIROUTER, the investigator compared the built firmware image with the filesystem originally found on the device itself. The comparison steps were as follows:

接下来，为确保 CCS 确实与安装在 TPE-NWIFIROUTER 上的原始固件相对应，调查员将构建的固件映像与设备本身上原始的文件系统进行比较。比较步骤如下：

Extract the filesystem from the image we built by running > find-firmware.pl on "bin/ar71xx/librecmc- ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin" and then running bat-extratools' "squashfs4.2/squashfs- tools/bat-unsquashfs42" on the resulting morx0.squash, using the filesystem in the new squashfs-root directory for comparison.
Login to the router's web interface (at http://192.168.10.1/) from a computer connected to the router.
Set a password using the provided link at the top (since the router's UI warns that no password is set and asks the user to change it).
Logged into the router via SSH, using the root user with the aforementioned password.
Compared representative directory listings and binaries to ensure the set of included files (on the router) is similar to those found in the firmware image that the investigator created (whose contents are now in the local squashfs-root directory). In particular, the investigator did the following comparisons:
运行 > find-firmware.pl 命令从 "bin/ar71xx/librecmc- ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin" 中提取我们构建的文件系统，然后使用 bat-extratools' 中的 "squashfs4.2/squashfs- tools/bat-unsquashfs42" 命令解压 morx0.squash，将结果中的文件系统保存到新的 squashfs-root 目录中，用于比较。
使用连接到路由器的计算机从路由器的 Web 界面（位于 http://192.168.10.1/）登录。
使用顶部提供的链接设置密码（因为路由器的用户界面会警告用户未设置密码并要求用户更改密码）。
使用具有上述密码的 root 用户通过 SSH 登录到路由器。
比较代表性的目录列表和二进制文件，以确保在路由器上包含的文件集与调查员创建的固件映像中找到的文件集（其内容现在保存在本地的 squashfs-root 目录中）相似。特别是，调查员进行了以下比较：

a. Listed the /bin folder ("ls -l /bin") and confirm the list of files is the same and that the file sizes are similar.

b. Checked the "strings" output of "/bin/busybox" to confirm it is similar in both places (similar number of lines and content of lines). (One cannot directly compare the binaries because the slight compilation variations will cause some bits to be different.)

c. Repeated the above two steps for "/lib/modules", "/usr/bin", and other directories with a signif- icant number of binaries.

d. Checked that the kernel was sufficiently similar. The investigator compared the "dmesg" output both before and after flashing the new firmware. As the investigator expected, the kernel version string was similar, but had a different build date and user@host indicator. (The kernel binary itself is not easily accessible from an SSH login, but was retrievable using the U-Boot console (the start address of the kernel in flash appears to be 0x9F020000, based on the boot messages seen in the serial console).

a. 列出 /bin 文件夹（"ls -l /bin"）并确认文件列表相同，文件大小相似。

b. 检查 "/bin/busybox" 的 "strings" 输出，以确认两个位置的输出相似（行数和内容）。（不能直接比较二进制文件，因为轻微的编译差异会导致某些位不同。）

c. 对 "/lib/modules"、"/usr/bin" 和其他具有大量二进制文件的目录重复上述两个步骤。

d. 检查内核是否足够相似。调查员比较了刷写新固件前后的 "dmesg" 输出。如调查员所预期的，内核版本字符串相似，但具有不同的构建日期和 user@host 指示器。（内核二进制文件本身无法从 SSH 登录轻松访问，但可以使用 U-Boot 控制台检索（基于在串行控制台中看到的启动消息，内核在闪存中的起始地址似乎是0x9F020000）。）

21.7 Minor Annoyances

21.7 小问题

As discussed in detail above, there were a few minor annoyances, none of which were GPL violations. Rather, the annoyances briefly impeded the build and installation. However, the investigator, as a reasonably skilled build engineer for embedded devices, was able to complete the process with the instructions provided.

正如上面详细讨论的那样，存在一些小问题，但没有违反 GPL 许可证。这些问题稍微阻碍了构建和安装过程。但是，作为一个技能较强的嵌入式设备构建工程师，调查员能够按照提供的说明完成整个过程。

To summarize, no GPL compliance issues were found, and the CCS release was one of the best ever reviewed by any investigator at any community-oriented enforcement organization. However, the following annoyances were discovered:

总结一下，没有发现任何 GPL 合规性问题，而且 ThinkPenguin 发布的 CCS 版本是任何一个社区导向执法组织评审过的最好的版本之一。但是，还发现了以下问题：

Failure to explain how to extract the source tarball and then where to run the "make" command.

Failure to explain how to install the kernel and root filesystem on the device; the user must assume the web UI must be used.

Including pre-built toolchain binaries that don't work on all systems, and failure to copy and/or symlink built toolchain binaries in the right location.

Failure to include information in the U-Boot installation instructions for wiring the serial cable.
Ideally, the U-Boot installation instructions would also include the netcat method of installation. Finally, the instructions should note that the new U-Boot firmware should be placed into /srv/tftp when using TFTP on most GNU/Linux desktops.
没有说明如何提取源码 tarball，以及在哪里运行“make”命令。
没有说明如何在设备上安装内核和根文件系统；用户必须假设必须使用 Web UI 进行操作。
包括不适用于所有系统的预编译工具链二进制文件，并且没有在正确的位置复制和/或创建工具链二进制文件的符号链接。
在 U-Boot 安装说明中没有包括有关连接串行电缆的信息。
理想情况下，U-Boot 安装说明还应包括 netcat 安装方法。最后，说明应指出，在大多数 GNU/Linux 桌面系统上使用 TFTP 时，新的 U-Boot 固件应放置在 /srv/tftp 中。

Thus, no CCS is absolutely perfect, but GPL violation investigators always give the distributors the benefit of any doubts and seek to work with the vendors and improve their CCS for the betterment of their users, customers, and the entire software freedom community.

因此，没有绝对完美的 CCS，但是 GPL 违规调查员始终会给予发行商任何怀疑的权利，并寻求与供应商合作，改进他们的 CCS，以造福他们的用户、客户和整个软件自由社区。

21.8 Lessons Learned

21.8 总结与教训

Companies that seek to redistribute copylefted software can benefit greatly from ThinkPenguin's example. Here are just a few of the many lessons that can be learned here:

试图重新分发共享软件的公司可以从 ThinkPenguin 的例子中受益。这里只是可以学到的许多教训中的几个：

Even though copyleft licenses have them, [avoid the offer-for-source provisions]. Not only does including the CCS alongside binary distribution make violation investigation and compliance confir- mation substantially easier, but also (and more importantly) doing so [completes the distributor's CCS] [compliance obligations at the time of distribution] (provided, of course, that the distributor is otherwise in compliance with the relevant copyleft license).
Include top-level build instructions in a natural language (such as English) in a [clear and] [conspicuous place.] Copyleft licenses require that someone reasonably skilled in the art can reproduce the build and installation. Typically, instructions written in English are necessary, and often easier than writing programmed scripts. The "script" included can certainly be more like the script of a play and less like a Bash script.
Write build/install instructions to the appropriate level of specificity. The upstream engi- neers in this case study [clearly did additional work to ensure functionality on a wide variety of host] [build systems;] this is quite rare. When in doubt, include the maximum level of detail build engi- neers can provide with the CCS instructions, but also double-check to investigate if a more generalized solution (such as other host systems) work just as well for the build.
Seek to adhere to the spirit of copyleft, not just the letter of the license. Encouragement of users to improve and make their devices better is one of ThinkPenguin's commercial differentiators. Copyleft advocates that other companies have undervalued the large and lucrative market of users who seek hackable devices. By going beyond the mere minimal requirements of GPL, companies can immediately reap the benefits in that target market.
Community-oriented enforcement organizations do not play "gotcha"⁵⁹ with distributors regarding GPL violations. The goal in the GPL enforcement process is to achieve compliance and correct mistakes and annoyances. Such organizations therefore take an "innocent until proven guilty assume guilty due to honest error rather than malicious action " approach. The goal is compliance (in direct contrast with the [discussion in § 12.2 about the proprietary relicensing] business model).
即使共享许可证包括它们，尽量避免提供源代码条款。将 CCS 与二进制分发一起包含不仅使违规调查和合规确认变得更加容易，而且（更重要的是）在分发时**（前提是分发商符合相关共享许可证）完成了分发商的 CCS 合规义务**。
**在明显的位置用自然语言（如英语）包含顶层构建说明。**共享许可证要求合理熟练的人可以重现构建和安装过程。通常需要使用英语编写的说明，并且往往比编写脚本更容易。包含的“脚本”当然可以更像戏剧脚本，而不是 Bash 脚本。
编写适当级别的构建/安装说明。在这个案例研究中，上游工程师们显然做了额外的工作，以确保在各种主机构建系统上的功能正常，这是非常罕见的。当存在疑虑时，将构建工程师可以提供的最详细的构建说明包括进 CCS 指令中，但同时要仔细检查是否有更普适的解决方案（如其他主机系统）同样适用于构建。
力求遵守 Copyleft 精神，而非仅遵守许可证条款。鼓励用户改进和使其设备更好是 ThinkPenguin 的商业差异化之一。Copyleft 倡导其他公司低估了寻求可黑客化设备的大型和有利可图的用户市场。通过超越 GPL 的最低要求，公司可以立即在这个目标市场中获得好处。
面向社区的执法组织在 GPL 违规问题上不与分销商玩“抓到你了”⁵⁹的游戏。在 GPL 执法过程中，目标是实现合规并纠正错误和恼人之处。因此，这样的组织采取“假定无罪，由于诚实的错误而不是恶意行为而被认定有罪”的方法。目标是遵守（与商业模型章节中关于专有再许可的讨论形成鲜明对比）。

CHAPTER 22 BORTEZ: MODIFIED GCC SDK

第22章 Bortez:修改版的GCC SDK

In our first case study, we will consider Bortez, a company that produces software and hardware toolkits to assist OEM vendors, makers of consumer electronic devices.

在第一个案例研究中，我们把目光投到Bortez，这是一家生产软件和硬件工具包用来服务于OEM供应商和消费电子设备制造商的公司。

22.1 Facts

22.1 事情经过

One of Bortez's key products is a Software Development Kit ("SDK") designed to assist developers building software for a specific class of consumer electronics devices.

Bortez的主打产品是一款软件开发工具包(“SDK”)，用途是帮助开发人员为特定类型的消费电子设备进行软件架构。

FSF received a report that the SDK may be based on the GNU Compiler Collection (which is an FSF- copyrighted collection of tools for software development in C, C++ and other popular languages). FSF investigated the claim, but was unable to confirm the violation. The violation reporter was unresponsive to follow-up requests for more information.

FSF收到的一份举报，称SDK似乎是基于GNU编译器套件（GNU Compiler Collection，这是FSF拥有版权的C、C++和其他流行语言软件开发工具箱）。FSF就这个反映进行了调查，但无法证实这一违规行为。举报人没有对后续提供更多信息的请求做出回应。

Since FSF was unable to confirm the violation, we did not pursue it any further. Bogus reports do happen, and we do not want to burden companies with specious GPL violation complaints. FSF shelved the matter until more evidence was discovered.

由于FSF无法证实这一违规行为，我们没有做进一步追究。鉴于可能存在不实举报，我们不愿让公司背负莫须有的GPL违规投诉。FSF将此事搁置，直到发现更多证据。

FSF was later able to confirm the violation when two additional reports surfaced from other violation reporters, both of whom had used the SDK professionally and noticed clear similarities to FSF's GNU GCC. FSF's Compliance Engineer asked the reporters to run standard tests to confirm the violation, and it was confirmed that Bortez's SDK was indeed a modified version of GCC. Bortez had ported to Windows and added a number of features, including support for a specific consumer device chipset and additional features to aid in the linking process ("LP") for those specific devices. FSF explained the rights that the GPL afforded these customers and pointed out, for example, that Bortez only needed to provide source to those in possession of the binaries, and that the users may need to request that source (if 3(b) was exercised). The violators confirmed that such requests were not answered.

一段时间以后，当来自其他举报人的另外两份报告浮出水面时，FSF终于对这一违规行为予以确认。这两人都曾专业地使用过SDK，并注意到与FSF的GNU GCC有明显的相似之处。FSF的合规工程师要求报告人通过运行标准测试来确认违规，并证实Bortez的SDK确实是GCC的修改版本。Bortez已经将其移植到Windows，并添加了许多功能，包括对特定消费设备芯片组的支持，并在这些设备的连接过程(“LP”)中提供一些额外支持功能。FSF对GPL赋予客户的权利做出说明，例如，Bortez只可以向那些拥有二进制文件的人提供源代码，并且用户只能对该源代码提出请求(在遵循3(b)的情况下)。违规者证实，这些请求没有得到回应。

FSF brought the matter to the attention of Bortez, who immediately escalated the matter to their attorneys. After a long negotiation, Bortez acknowledged that their SDK was indeed a modified version of GCC. Bortez released most of the source, but some disagreement occurred over whether LP was also derivative of GCC. After repeated FSF inquiries, Bortez reaudited the source to discover that FSF's analysis was correct. Bortez determined that LP included a number of source files copied from the GCC code-base. Once the full software release was made available, FSF asked the violation reporters if it addressed the problem. Reports came back that the source did not properly build. FSF asked Bortez to provide better build instructions with the software, and such build instructions were incorporated into the next software release.

FSF向Bortez发出警告函，后者立即将此事通知他们的律师。经过长时间的谈判，Bortez承认他们的SDK确实是GCC的修改版本。Bortez公布了大部分来源，但在LP是否也属于GCC的衍生产品的问题上出现了一些分歧。经过FSF的反复质询，Bortez重新对出处进行溯源，发现FSF的分析是正确的。Bortez确定LP包含了许多从GCC代码库复制的源文件。当完整版软件发行后，FSF询问举报人该问题是否得到解决。回信说，该来源并没有被正确构建。FSF要求Bortez为软件做出更适当的构建说明，并将其合并到下一个软件版本中。

At FSF's request as well, Bortez informed customers who had previously purchased the product that the source was now available by announcing the availability on its Web site and via a customer newsletter.

在FSF的要求下，Bortez通过其网站以及客户通讯录发布消息，通知以前购买过该产品的客户，已经可以正常使用该来源。

Bortez did have some concerns regarding patents. They wished to include a statement with the software release that made sure they were not granting any patent permission other than what was absolutely required by the GPL. They understood that their patent assertions could not trump any rights granted by the GPL. The following language was negotiated into the release:

Bortez对专利问题有一些顾虑。他们希望在软件发行时包含一份声明，以确保他们没有授予除GPL基础条款以外的任何专利许可。他们清楚，自己的专利主张无法凌驾于GPL授予的权利之上。以下内容是通过谈判达成的结果：

Subject to the qualifications stated below, Bortez, on behalf of itself and its Subsidiaries, agrees not to assert the Claims against you for your making, use, offer for sale, sale, or importation of the Bortez's GNU Utilities or derivative works of the Bortez's GNU Utilities ("Derivatives"), but only to the extent that any such Derivatives are licensed by you under the terms of the GNU General Public License. The Claims are the claims of patents that Bortez or its Subsidiaries have standing to enforce that are directly infringed by the making, use, or sale of an Bortez Distributed GNU Utilities in the form it was distributed by Bortez and that do not include any limitation that reads on hardware; the Claims do not include any additional patent claims held by Bortez that cover any modifications of, derivative works based on or combinations with the Bortez's GNU Utilities, even if such a claim is disclosed in the same patent as a Claim. Subsidiaries are entities that are wholly owned by Bortez.

根据下述的条款，Bortez代表自身及其子公司，同意不对他人制作、使用、出售、销售或进口Bortez GNU工具组或Bortez GNU工具组的派生产品(“衍生品”)的行为主张权利，但仅限于在GNU通用公共许可证的条款许可下的任何此类衍生品。这是Bortez及其子公司有权强制执行的专利声明，一旦出现利用Bortez发行的版本制作、使用或销售Bortez分布式GNU实用程序的行为则属于直接侵权，并且不包括任何对硬件的限制；权利要求不包括由Bortez持有的那部分额外的专利要求，这涵盖了任何基于Bortez GNU工具组的修改、衍生或组合产品，即使此类权利要求已经在相关专利中予以披露。所谓子公司，是指Bortez全资控股的实体。

This statement does not negate, limit or restrict any rights you already have under the GNU General Public License version 2.

本声明并不否认、限制或禁止您在GNU通用公共许可证第2版框架下已经拥有的任何权利。

This quelled Bortez's concerns about other patent licensing they sought to do outside of the GPL'd software, and satisfied FSF's concerns that Bortez give proper permissions to exercise teachings of patents that were exercised in their GPL'd software release.

至此Bortez免除了在GPL版软件之外出现其他专利许可的担忧。为了让FSF放心，Bortez还给予了适当的许可，以行使在GPL版软件中行使的教学的权利。

Finally, a GPL Compliance Officer inside Bortez was appointed to take responsibility for all matters of GPL compliance inside the company. Bortez is responsible for informing FSF if the position is given to someone else inside the company, and making sure that FSF has direct contact with Bortez's Compliance Officer.

最后，Bortez任命了一名GPL合规官，负责公司内所有GPL合规事宜。如果该职位出现人员调整，Bortez负责通知FSF，并确保FSF与Bortez的合规官保持直接对话。

22.2 Lessons

22.2 经验教训

This case introduces a number of concepts regarding GPL enforcement.

本案例涉及了一些关于GPL实施的概念。

Enforcement should not begin until the evidence is confirmed. Most companies that distribute GPL'd software do so in compliance, and at times, violation reports are mistaken. Even with extensive efforts in GPL education, many users do not fully understand their rights and the obligations that companies have. By working through the investigation with reporters, the violation can be properly confirmed, and the user of the software can be educated about what to expect with GPL'd software. When users and customers of GPL'd products know their rights, what to expect, and how to properly exercise their rights (particularly under 3(b)), it reduces the chances for user frustration and inappropriate community outcry about an alleged GPL violation.
除非证据确凿，否则不应执行。 大多数GPL软件的发行公司都是遵守规定的，违规举报有时是错误的。即使在GPL宣贯方面做了大量的努力，许多用户也不完全理解他们企业的权利和义务。通过与报告人一起联合调查，可以正确地确认违规行为，并且可以引导用户如何使用GPL软件。当GPL产品的用户和客户知道他们的权利、期望，并了解如何正确行使他们的权利（尤其是在3(b)框架下）时，这可以减少用户的不满和社区中抗议违反GPL侵权的机会。
GPL compliance requires friendly negotiation and cooperation. Often, attorneys and man- agers are legitimately surprised to find out GPL'd software is included in their company's products. Engineers sometimes include GPL'd software without understanding the requirements. This does not excuse companies from their obligations under the license, but it does mean that care and patience are essential for reaching GPL compliance. We want companies to understand that participating and benefiting from a collaborative Free Software community is not a burden, so we strive to make the process of coming into compliance as smooth as possible.
GPL的合规需要友好协商和合作。 通常情况下，法务人员和管理层在发现公司产品中包含GPL软件时，理所当然地会感到惊讶。工程师有时会在不了解需求的情况下使用GPL软件。而这并不能作为免除企业在许可证框架下相关义务的借口，但这也确实意味着实现GPL合规必须具备严谨和耐心。我们希望企业能够理解，参与并受益于一个自由软件社区的协作并非会成为负担，因此我们努力促使合规过程尽量顺利。
Confirming compliance is a community effort. The whole point of making sure that software distributors respect the terms of the GPL is to allow a thriving software sharing community to benefit and improve the work. FSF is not the expert on how a compiler for consumer electronic devices should work. We therefore inform the community who originally brought the violation to our attention and ask them to assist in evaluation and confirmation of the product's compliance. Of course, FSF coordinates and oversees the process, but we do not want compliance for compliance's sake; rather, we wish to foster a cooperating community of development around the Free Software in question, and encourage the once-violator to begin participating in that community.
合规确认是社区整体共同努力的结果。 确保软件发行者尊重GPL条款的全部意义在于允许一个蓬勃发展的软件共享社区从中受益并完善。FSF对消费类电子设备编译器并不擅长。因此，我们通知了最初报告违规问题的社区，并请他们协助评估和确认产品的合规性。当然，FSF对这个过程进行了协调和监督，但我们并不希望大家为了合规而合规；相反，我们更愿意围绕所讨论的自由软件来建立一个合作开发的社区，并鼓励曾经的违反者也参与到这个社区中来。
Informing the harmed community is part of compliance. FSF asks violators to make some attempt --- such as via newsletters and the company's Web site --- to inform those who already have the products as to their rights under the GPL. One of the key thrusts of the GPL's 1 and 3 is to make sure the user knows she has these rights. If a product was received out of compliance by a customer, she may never actually discover that she has such rights. Informing customers, in a way that is not burdensome but has a high probability of successfully reaching those who would seek to exercise their freedoms, is essential to properly remedy the mistake.
通知受害社区也是合规的工作之一。 FSF要求违规者做出一些尝试——比如通过新闻媒体和公司网站——把GPL权益告诉那些已经成为产品用户的人们。GPL第1条和第3条的重点之一便是确保用户了解自己拥有这些权利。如果客户收到的产品不符合规范，他可能永远不会清晰的知道自己享有这样的权利。要正确地纠正错误，必须采用一种不折腾、又最可能成功地联系到的方式通知那些想要行使自由权利的客户。
Lines between various copyright, patent, and other legal > mechanisms must be precisely de- fined and considered. The most difficult negotiation point of the Bortez case was drafting language that simultaneously protected Bortez's patent rights outside of the GPL'd source, but was consistent with the implicit patent grant in the GPL. As we discussed in the first course of this series, there is indeed an implicit patent grant with the GPL, thanks to 6 and 7. However, many companies become nervous and wish to make the grant explicit to assure themselves that the grant is sufficiently narrow for their needs. We understand that there is no reasonable way to determine what patent claims read on a company's GPL holdings and which do not, so we do not object to general language that explicitly narrows the patent grant to only those patents that were, in fact, exercised by the GPL'd software as released by the company.
必须精确地定义和考虑各种版权、专利和其他法律机制之间的界限。 Bortez案最困难的谈判环节是起草文本，需要保护Bortez在GPL来源之外的专利权，并兼顾GPL隐性专利授权的一致性。正如我们在本系列的第一节课中所讨论的，依照第6条和第7条规定，GPL确实存在隐性专利授权。然而，许多企业开始关切，希望对补偿加以明确，以确保范围足以满足他们的需要。我们知道并没有科学的方法来确定哪些专利声明是或者不是基于企业GPL所有权，因此我们不反对将专利授予范围明确缩小到那些实际上由企业发布的GPL软件行使的专利上。

CHAPTER 23 BRACKEN: A MINOR VIOLATION IN A GNU/LINUX DISTRIBUTION

第23章 BRACKEN：GNU/LINUX发行版中的一次小违规

In this case study, we consider a minor violation made by a company whose knowledge of the Free Software community and its functions is deep.

在这个案例的研究过程中，我们来讨论一个轻微的违规行为，该企业对自由软件社区及其功能有着很透彻的了解。

The Facts

23.1 事情经过

Bracken produces a GNU/Linux operating system product that is sold primarily to OEM vendors to be placed in appliance devices used for a single purpose, such as an Internet-browsing-only device. The product is almost 100% Free Software, mostly licensed under the GPL and related Free Software licenses.

Bracken研发了一款GNU/Linux操作系统产品，主要客户是OEM供应商，可应用于单一用途的电器设备中，例如仅用于互联网浏览的设备。该产品几乎100%使用了自由软件，大部分是在GPL和相关的自由软件许可证下授权的。

FSF found out about this violation through a report first posted on a Slashdot[^1^] comment, and then it was brought to our attention again by another Free Software copyright holder who had discovered the same violation.

Bracken's GNU/Linux product is delivered directly from their Web site. This allowed FSF engineers to directly download and confirm the violation quickly. Two primary problems were discovered with the online distribution:

Bracken的GNU/Linux产品直接通过他们的网站发行。因此FSF工程师可以直接下载并快速确认违规。我们发现了在线分发的两个主要问题:

No source code nor offer for source code was provided for a number of components for the distributed GNU/Linux system; only binaries were available

没有为分布式GNU/Linux系统的诸多组件提供源代码或源代码报价；只有二进制文件可用；

An End User License Agreement ("EULA") was included that contradicted the permissions granted by the GPL

包含了与GPL授予的权限相矛盾的最终用户许可协议(“EULA”) ；

FSF contacted Bracken and gave them the details of the violation. Bracken immediately ceased distri- bution of the product temporarily and set forth a plan to bring themselves back into compliance. This plan included the following steps:

FSF与Bracken取得联系，告知他们违规的细节。Bracken立即叫停了该产品的分销，并制定了一项计划，使自己重新合规。该计划包括以下步骤:

Bracken attorneys would rewrite the EULA to comply with the GPL and would vet the new EULA through FSF before use

Bracken律师将重写符合GPL的EULA，并在使用前交由FSF对新EULA进行审查。

Bracken engineers would provide source side-by-side with the binaries for the GNU/Linux distribution on the site (and on CD's, if ever they distributed that way)

Bracken工程师将在线为GNU/Linux发行版提供源代码和二进制文件（如以CD方式发行，同样也会提供）

Bracken attorneys would run an internal seminar for its engineers regarding proper GPL compliance to help ensure that such oversights regarding source releases would not occur in the future

Bracken的律师将为其工程师举办一场关于正确遵循GPL的内部研讨会，以帮助确保此类关于源代码发布的疏忽在未来不会再发生。

^1^ Slashdot is a popular news and discussion site for technical readers.

^1^ Slashdot是一个受技术读者欢迎的新闻和讨论平台。

Bracken would resume distribution of the product only after FSF formally restored Bracken's distri- bution rights

只有在FSF正式恢复Bracken的分销权后，Bracken才可以恢复该产品的分销。

This case was completed in about a month. FSF approved the new EULA text. The key portion in the EULA relating to the GPL read as follows:

这个案件大约一个月就办理完毕了。FSF批准了新的EULA文本。EULA中与GPL相关的关键部分如下:

Many of the Software Programs included in Bracken Software are distributed under the terms of agreements with Third Parties ("Third Party Agreements") which may expand or limit the Licensee's rights to use certain Software Programs as set forth in [this EULA]. Certain Software Programs may be licensed (or sublicensed) to Licensee under the GNU General Public License and other similar license agreements listed in part in this section which, among other rights, permit the Licensee to copy, modify and redistribute certain Software Programs, or portions thereof, and have access to the source code of certain Software Programs, or portions thereof. In addition, certain Software Programs, or portions thereof, may be licensed (or sublicensed) to Licensee under terms stricter than those set forth in [this EULA]. The Licensee must review the electronic documentation that accompanies certain Software Programs, or portions thereof, for the applicable Third Party Agreements. To the extent any Third Party Agreements require that Bracken provide rights to use, copy or modify a Software Program that are broader than the rights granted to the Licensee in [this EULA], then such rights shall take precedence over the rights and restrictions granted in this Agreement solely for such Software Programs.

Bracken产品中的许多软件程序都是根据与第三方签署的协议条款(“第三方协议”)来分发的，这些协议条款可能在被许可方使用[本EULA]中规定的某些软件程序的权利时扩展或限制。一些软件程序可以根据GNU通用公共许可证和本章列出的其他相似许可协议授权(或二次授权)给被许可方，在其他权利中，允许被许可方复制、修改和重新发布某些软件或其中一部分程序，并有权访问某些软件或其部分程序的源代码。另外，某些软件或其部分程序可按照比[本EULA]更严格的条款授权(或二次授权)给被许可方。被许可方必须审阅这些软件或其部分程序的电子文档附件，以了解适用的第三方协议。如果任何第三方协议要求Bracken提供比[本EULA]向被许可方授予的更广泛的使用、复制或修改软件程序的权利，则该权利的级别应优先于本协议中授予该软件程序的权利和限制的等级。

FSF restored Bracken's distribution rights shortly after the work was completed as described.

在工作完成后不久，FSF恢复了Bracken的分销权。

23.2 Lessons Learned

23.2 经验教训

This case was probably the most quickly and easily resolved of all GPL violations in the history of FSF's Compliance Lab. The ease with which the problem was resolved shows a number of cultural factors that play a role in GPL compliance.

这个案例可能是FSF合规实验室历史上最快速、最容易解决的GPL违规事件。相关问题的轻松解决表明了许多文化因素在GPL合规中发挥了作用。

**Companies that understand Free Software culture better have an

easier time with compli- ance.** Bracken's products were designed and built around the GNU/Linux system and Free Software components. Their engineers were deeply familiar with the Free Software ecosystem, and their lawyers had seen and reviewed the GPL before. The violation was completely an honest mistake. Since the culture inside the company had already adapted to the cooperative style of resolution in the Free Software world, there was very little work for either party to bring the product into compliance.
了解自由软件文化的企业更容易做到合规。

Bracken的产品是基于GNU/Linux系统和自由软件组件而设计和构建的。他们的工程师非常熟悉自由软件生态系统，他们的律师之前阅读并审查过GPL。这次违规完全是无心之过。由于企业内部的文化已经适应了自由软件世界的协作解决方式，各方所需开展的工作很少，即可使产品重新合规。
**When people in key positions understand the Free Software nature

of their software products, compliance concerns are as mundane as minor software bugs.** Even the most functional system or structure has its problems, and successful business often depends on agile response to the problems that do come up; avoiding problems altogether is a pipe dream. Minor GPL violations can and do happen even with well-informed redistributors. However, resolution is reached quickly when the company --- and in particular, the lawyers, managers, and engineers working on the Free Software product lines --- have adapted to Free Software culture that the lower-level engineer already understood
当处于关键位置的人理解其软件产品的自由软件本质时，合规问题就像软件的小错误一样普通了。

即使是功能最强大的系统或结构也有它的问题，成功的业务往往取决于对出现问题的敏捷反应；完全避免问题是一个白日做梦。即使是经验丰富的再发布者也会发生轻微违反GPL的情况。然而，当企业——特别是律师、经理和在自由软件产品一线工作的工程师——就连基层工程师也已经理解并适应自由软件文化时，解决方案很快就会落实。
Legally, distribution must stop when a violation is identified.

In our opinion, Bracken went above and beyond the call of duty by ceasing distribution while the violation was being resolved. Under GPL 4, the redistributor loses the right to distribute the software, and thus they are in ongoing violation of copyright law if they distribute before rights are restored. It is FSF's policy to temporarily allow distribution while compliance negotiations are ongoing and only in the most extreme cases (where the other party appears to be negotiating in bad faith) does FSF even threaten an injunction on copyright grounds. However, Bracken --- as a good Free Software citizen --- chose to be on the safe side and do the legally correct thing while the violation case was pending. From start to finish, it took less than a month to resolve. This lapse in distribution did not, to FSF's knowledge, impact Bracken's business in any way.
依照法律要求，分发任务在确认违规行为时必须立刻中止。

从我们的角度来看，Bracken在解决违规问题时停止分发，属于超出责任范围之外。根据GPL 4，再发布者不继续享有分发软件的权利，因此，如果他们在恢复权利之前分发软件，就违反了版权法。FSF的政策是在合规谈判进行期间暂时允许发行，只有在最极端的情况下(当另一方疑似恶意谈判时)，FSF才会以版权为由发出禁止警告。然而，Bracken——作为一个优秀的自由软件公民——选择了稳妥的做法，在违规案件悬而未决的时候做了法律上正确的事情。从开始到结束，用时不到一个月就解决了。据FSF所知，这次分销上的失误并没有以任何方式影响到Bracken的业务。
EULAs are a common area for GPL problems. Often, EULAs are

drafted from boilerplate text that a company uses for all its products. Even the most diligent attorneys forget or simply do not know that a product contains software licensed under the GPL and other Free Software licenses. Drafting a EULA that accounts for such licenses is straightforward; the text quoted above works just fine. The EULA must be designed so that it does not trump rights and permissions already granted by the GPL. The EULA must clearly state that if there is a conflict between it and the GPL, with regard to GPL'd code, the GPL is the overriding license.
EULA是GPL问题的一个常见领域。

通常情况下，EULA的策划是以企业的产品样板文本为基础的。即使是最认真的律师也会忘记或不清楚某个产品是否包含基于GPL和其他自由软件许可证的软件。起草一份对此类许可做出规范的EULA并不难，前面引用的这篇文章就是个很好的参照。EULA在设计时必须确保它不会超出GPL已经授予的权利和权限。EULA必须明确声明，如果与GPL之间存在冲突，GPL对于GPL代码具有上位覆盖许可权力。
**Compliance Officers are rarely necessary when companies are

educated about GPL com- pliance.** As we saw in the Bortez case, FSF asks that a formal "GPL Compliance Officer" be appointed inside a previously violating organization to shepherd the organization to a cooperative approach to GPL compliance. However, when FSF sees that an organization already has such an approach, there is no need to request that such an officer be appointed.
当企业具有GPL合规培养环境时，合规官的作用并不明显。

正如我们在Bortez案例中所看到的，FSF要求在先前违反GPL的企业内部任命一个正式的“GPL合规官”，以指导企业采取合作的方法来遵守GPL。然而，当FSF看到一个组织已经有这样的态度时，便没有必要再强制要求这类人事任命。

CHAPTER 24 VIGORIEN: SECURITY, EXPORT CONTROLS, AND GPL COMPLIANCE

第24章 Vigorien：安全、出口管制和GPL合规性

This case study introduces how concerns of "security through obscurity" and regulatory problems can impact GPL compliance matters.

本案例研究介绍了"安全通过混淆"和法规问题如何影响GPL合规问题。

24.1 The Facts

24.1 事实

Vigorien distributes a back-up solution product that allows system administrators to create encrypted back- ups of file-systems on Unix-like computers. The product is based on GNU tar, a backup utility that replaces the standard Unix utility simply called tar, but has additional features.

Vigorien分发一款备份解决方案产品，使系统管理员能够在类Unix计算机上创建加密备份文件系统。该产品基于GNU tar，这是一种备份实用程序，可以替换称为tar的标准Unix实用程序，并具有其他功能。

Vigorien's backup solution added cryptographic features to GNU tar, and included a suite of utilities and graphical user interfaces surrounding GNU tar to make backups convenient.

FSF discovered the violation from a user report, and determined that the cryptographic features were the only part of the product that constituted a derivative work of GNU tar; the extraneous utilities merely made shell calls out to GNU tar. FSF requested that Vigorien come into compliance with the GPL by releasing the source of GNU tar, with the cryptographic modifications, to its customers.

FSF从用户报告中发现了这一违规行为，并确定加密功能是该产品中唯一构成GNU tar衍生作品的部分；多余的实用程序只是向GNU tar发出shell调用。FSF要求Vigorien通过向其客户发布带有加密修改的GNU tar源代码来符合GPL。

Vigorien released the original GNU tar sources, but kept the cryptographic modifications proprietary. They argued that the security of their system depending on keeping the software proprietary and that regardless, USA export restrictions on cryptographic software prohibited such a release. FSF disputed the first claim, pointing out that Vigorien had only one option if they did not want to release the source: they would have to remove GNU tar from the software and not distribute it further. Vigorien rejected this suggestion, since GNU tar was an integral part of the product, and the security changes were useless without GNU tar.

Vigorien发布了原始的GNU tar源代码，但保留了加密修改的专有权利。他们认为，系统的安全性取决于保持软件的专有性，并且无论如何，美国对加密软件的出口限制禁止这样的发布。FSF对第一项声明表示异议，指出如果他们不想发布源代码，只有一个选择：他们必须从软件中删除GNU tar，并不再分发它。Vigorien拒绝了这个建议，因为GNU tar是产品的一个重要组成部分，而没有GNU tar，安全更改是无用的。

Regarding the export control claims, FSF proposed a number of options, including release of the source from one of Vigorien's divisions overseas where no such restrictions occurred, but Vigorien argued that the problem was insoluble because they operated primarily in the USA.

关于出口控制的说法，FSF提出了许多选项，包括从Vigorien在没有此类限制的海外分支之一发布源代码，但Vigorien认为问题是无法解决的，因为他们主要在美国运营。

The deadlock on the second issue was resolved when those cryptographic export restrictions were lifted shortly thereafter, and FSF again raised the matter with Vigorien. At that point, they dropped the first claim and agreed to release the remaining source module to their customers. They did so, and the violation was resolved.

第二个问题的僵局在加密出口限制不久后解决，此后FSF再次向Vigorien提出了这个问题。此时，他们放弃了第一个声明，并同意向其客户发布剩余的源代码模块。他们这样做了，违规行为得到了解决。

24.2 Lessons Learned

24.2 教训

Removing the GPL'd portion of the product is always an option. Many violators' first response is to simply refuse to release the source code as the GPL requires. FSF offers the option to simply remove the GPL'd portions from the product and continue along without them. Every case where this has been suggested has led to the same conclusion. Like Vigorien, the violator argues that the product cannot function without the GPL'd components, and they cannot effectively replace them.

Such an outcome is simply further evidence that the combined work in question is indeed a modified version of the original GPL'd component. If the other components cannot stand on their own and be useful without the GPL'd portions, then one cannot effectively argue that the work as a whole is not a based on the GPL'd portions.

The whole product is not always covered. In this case, Vigorien had additional works aggregated. The backup system was a suite of utilities, some of which were the GPL and some of which were not. While the cryptographic routines were tightly coupled with GNU tar and clearly made a whole new combined work of both components, the various GUI utilities were separate and independent works merely aggregated with the distribution of the GNU-tar-based product.
"Security" concerns do not exonerate a distributor from GPL obligations, and "security through obscurity" does not work anyway. The argument that "this is security software, so it cannot be released in source form" is not a valid defense for explaining why the terms of the GPL are ignored. If companies do not want to release source code for some reason, then they should not base the work on GPL'd software. No external argument for noncompliance can hold weight if the work as a whole is indeed a modified version of a GPL'd program.

The "security concerns" argument is often floated as a reason to keep software proprietary, but the computer security community has on numerous occasions confirmed that such arguments are entirely specious. Security experts have found --- since the beginnings of the field of cryptography in the ancient world --- that sharing results about systems and having such systems withstand peer review and scrutiny builds the most secure systems. While full disclosure may help some who wish to compromise security, it helps those who want to fix problems even more by identifying them early.

External regulatory problems can be difficult to resolve. The GPL, though grounded in copyright law, does not have the power to trump regulations like export controls. While Vigorien's "security concerns" were specious, their export control concerns were not. It is indeed a difficult problem that FSF acknowledges. We want compliance with the GPL and respect for users' freedoms, but we certainly do not expect companies to commit criminal offenses for the sake of compliance. We will see more about this issue in our next case study.

移除产品中受GPL保护的部分始终是一种选择。 许多违规者的第一反应是拒绝按照GPL要求发布源代码。FSF提供了一种简单的解决方案，即从产品中简单地移除受GPL保护的部分，然后继续使用其他部分。每个这样建议的案例都导致了相同的结论。就像Vigorien一样，违规者辩称，如果没有GPL保护的组件，产品无法正常运行，并且他们无法有效地替换它们。

这样的结果仅仅进一步证明，涉及的组合作品确实是原始GPL组件的修改版本。如果其他组件不能独立运行且没有GPL的部分有用，则不能有效地主张整个作品不是基于GPL组件的。

整个产品并不总是被覆盖。 在这种情况下，Vigorien还有其他聚合的作品。备份系统是一套实用工具，其中一些是GPL，一些不是。虽然加密例程与GNU tar紧密耦合，并明显形成了GNU-tar-based产品的全新组合作品，但各种GUI实用程序是单独和独立的作品，仅仅是与分发GNU-tar-based产品的聚合。
“安全”问题不能使分发者免除GPL义务。“通过模糊来保护安全性”也行不通。“这是安全软件，因此不能以源代码形式发布”这种论点不是一个有效的辩护理由，解释为什么忽略了GPL的条款。如果公司出于某种原因不想发布源代码，那么他们就不应该以GPL软件为基础进行开发。如果整个作品确实是GPL软件的修改版本，那么任何非遵守的外部论点都没有说服力。

“安全问题”论点经常被提出作为保持软件专有的理由，但是计算机安全社区在许多场合证实，这种论点完全是无稽之谈。自古代密码学领域以来，安全专家们已经发现，共享关于系统的结果，并让这些系统经受同行评审和审查，构建最安全的系统。虽然完全披露可能有助于一些想要破坏安全的人，但它更有助于那些想要尽早识别问题并修复它们的人。

**外部监管问题可能难以解决。**尽管GPL是基于版权法的，但它无法取代出口管制等法规。尽管Vigorien的“安全担忧”是牵强的，但他们的出口管制担忧并非如此。这确实是一个FSF承认的难题。我们希望遵守GPL并尊重用户的自由，但我们肯定不希望公司为了遵守GPL而犯罪。我们将在下一个案例研究中详细了解这个问题。

CHAPTER 25 HAXIL, POLGARA, AND THESULAC: MERGERS, UPSTREAM PROVIDERS AND RADIO DEVICES

第25章 HAXIL，POLGARA和THESULAC：合并，上游供应商和无线电设备

This case study considers an ongoing (at the time of writing) violation that has occurred. By the end of the investigation period, three companies were involved and many complex issues arose.

本案例研究考虑了一起正在发生（在撰写本文时）的侵犯行为。调查期结束时，三家公司参与其中，出现了许多复杂的问题。

25.1 The Facts

25.1 事实

Haxil produced a consumer electronics device which included a mini GNU/Linux distribution to control the device. The device was of interest to many technically-minded consumers, who purchased the device and very quickly discovered that Free Software was included without source. Mailing lists throughout the Free Software community erupted with complaints about the problem, and FSF quickly investigated.

Haxil生产了一种消费电子设备，其中包括一个迷你GNU / Linux发行版来控制设备。该设备引起了许多技术爱好者的兴趣，他们购买了该设备，并很快发现其中包含未附源代码的自由软件。整个自由软件社区的邮件列表都在抱怨这个问题，FSF迅速展开调查。

FSF confirmed that FSF-copyrighted GPL'd software was included. In addition, the whole distribution included GPL'd works from hundreds of individual copyright holders, many of whom were, at this point, up in arms about the violation.

FSF确认包含了FSF版权的GPL软件。此外，整个发行版包括来自数百个个人版权持有者的GPL作品，其中许多人此时都对侵犯行为感到愤怒。

Meanwhile, Haxil was in the midst of being acquired by Polgara. Polgara was as surprised as everyone else to discover the product was based on GPL'd software; this fact had not been part of the disclosures made during acquisition. FSF contacted Haxil, Polgara, and the product managers who had transitioned into the "Haxil division" of the newly-merged Polgara company. Polgara's General Counsel's office worked with FSF on the matter.

同时，Haxil正在被Polgara收购。Polgara像其他人一样惊讶地发现该产品是基于GPL软件构建的；这个事实在收购过程中没有被披露。FSF联系了Haxil，Polgara和已经转入新合并的Polgara公司的“Haxil部门”的产品经理。Polgara的总法律顾问办公室与FSF一起处理此事。

FSF formed a coalition with the other primary copyright holders to pursue the enforcement effort on their behalf. FSF communicated directly with Polgara's representatives to begin working through the issues on behalf of itself and the Free Software community at large.

FSF与其他主要版权持有者组成了联盟，代表他们追求执行行动。FSF直接与Polgara的代表沟通，开始代表自己和整个自由软件社区处理问题。

Polgara pointed out that the software distribution they used was mostly contributed by an upstream provider, Thesulac, and Haxil's changes to that code base were minimal. Polgara negotiated with Thesulac to obtain the source, although the issue moved very slowly in the channels between Polgara and Thesulac.

Polgara指出，他们使用的软件发行版大部分是由上游供应商Thesulac提供的，并且Haxil对该代码库的更改很少。Polgara与Thesulac协商以获得源代码，尽管问题在Polgara和Thesulac之间的渠道中进展缓慢。

FSF encouraged a round-table meeting so that high bandwidth communication could occur between FSF, Polgara and Thesulac. Polgara and Thesulac agreed, and that discussion began. Thesulac provided nearly complete sources to Polgara, and Polgara made a full software release on their Web site. At the time of writing, that software still has some build problems (similar to those that occurred with Bortez, as described in Section [22.1).] FSF continues to negotiate with Polgara and Thesulac to resolve these problems, which have a clear path to a solution and are expected to resolve.

FSF鼓励进行圆桌会议，以便FSF，Polgara和Thesulac之间进行高带宽通信。Polgara和Thesulac同意，并开始讨论。Thesulac几乎完整地提供了源代码给Polgara，Polgara在其网站上发布了完整的软件版本。撰写本文时，该软件仍然存在一些构建问题（与第22.1节中描述的Bortez类似）。FSF继续与Polgara和Thesulac协商解决这些问题，这些问题有一个明确的解决路径，预计会解决。

Similar to the Vigorien case, Thesulac has regulatory concerns. In this case, it is not export controls - an issue that has since been resolved - but radio spectrum regulation. Since this consumer electronic device contains a software-programmable radio transmitter, regulations in (at least) the USA and Japan prohibit release of those portions of the code that operate the device. Since this is a low-level programming issue, the changes to operate the device form a single combined work with the kernel named Linux. A decade later, this situation remains largely unresolved.

与 Vigorien 案类似，Thesulac 也存在监管问题。在这种情况下，不是出口管制问题-该问题已经解决，而是无线电频谱监管问题。由于这种消费电子设备包含软件可编程无线电发射器，美国和日本的法规禁止发布操作该设备的代码部分。由于这是一个低级编程问题，操作设备的更改与名为 Linux 的内核形成一个单独的组合作品。十年后，这种情况仍然没有得到解决。

25.2 Lessons Learned

25.2 教训

Community outrage, while justified, can often make negotiation more difficult. FSF has a strong policy never to publicize names of GPL violators if they are negotiating in a friendly way and operating in good faith toward compliance. Most violations are honest mistakes, and FSF sees no reason to publicly admonish violators who genuinely want to come into compliance with the GPL and to work hard staying in compliance.

This case was so public in the Free Software community that both Haxil's and Polgara's representatives were nearly shell-shocked by the time FSF began negotiations. There was much work required to diffuse the situation. We empathize with our community and their outrage about GPL violations, but we also want to follow a path that leads expediently to compliance. In our experience, public outcry works best as a last resort, not the first.

For software companies, GPL compliance belongs on a corporate acquisition checklist. Polgara was truly amazed that Haxil had used GPL'd software in a major new product line but never informed Polgara during the acquisition process. While GPL compliance is not a particularly difficult matter, it is an additional obligation that comes along with the product line. When planning mergers and joint ventures, one should include lists of GPL'd components contained in the products discussed.
Compliance problems of upstream providers do not excuse a violation for the downstream distributor. To paraphrase 6, upstream providers are not responsible for enforcing compliance of their downstream, nor are downstream distributors responsible for compliance problems of upstream providers. However, engaging in distribution of GPL'd works out of compliance is still just that: a compliance problem. When FSF carries out enforcement, we are patient and sympathetic when the problem appears to be upstream. In fact, we urge the violator to point us to the upstream provider so we may talk to them directly. In this case, we were happy to begin negotiations with Thesulac. However, Polgara still has an obligation to bring their product into compliance, regardless of Thesulac's response.
It behooves upstream providers to advise downstream distributors about compliance matters. FSF has encouraged Thesulac to distribute a "good practices for GPL compliance" document with their product. Polgara added various software components to Thesulac's product, and it is conceivable that such additions can introduce compliance. In FSF's opinion, Thesulac is in no way legally responsible for such a violation introduced by their customer, but it behooves them from a marketing standpoint to educate their customers about using the product. We can argue whether or not it is your coffee vendor's fault if you burn yourself with their product, but (likely) no one on either side would dispute the prudence of placing a "caution: hot" label on the cup.
FSF enforcement often avoids redundant enforcement cases from many parties. Most Free Software systems have hundreds of copyright holders. Some have thousands. FSF is in a unique position as one of the largest single copyright holders on GPL'd software and as a respected umpire in the community, neutrally enforcing the rules of the GPL road. FSF works hard in the community to convince copyright holders that consolidating GPL claims through FSF is better for them, and more likely to yield positive compliance results.

**社区的公愤，虽然有道理，但通常会使谈判变得更加困难。**自由软件基金会(FSF)有一个强有力的政策，即如果GPL违规者以友好的方式进行谈判并以诚信的态度遵守，FSF将永远不公开GPL违规者的名称。大多数违规都是诚实的错误，FSF认为没有理由公开责备那些真正想遵守GPL并努力保持合规的违规者。

这个案件在自由软件社区是如此公开，以至于 Haxil 和 Polgara 的代表在 FSF 开始谈判时几乎被打击了。需要做很多工作才能化解局势。我们理解我们的社区及其对GPL违规的愤怒，但我们也希望走一条通向合规的捷径。根据我们的经验，公众的抗议最好作为最后一招，而不是第一招。

对于软件公司来说，GPL合规应该列在企业收购清单上。 Polgara 真的很惊讶 Haxil 在一个重要的新产品线中使用了GPL软件，但在收购过程中从未告知 Polgara。虽然GPL合规并不是一个特别困难的问题，但它是随着产品线而来的一个额外义务。在规划合并和合资企业时，应该列出所讨论产品中包含的GPL组件清单。
**上游提供商的合规问题并不能为下游分销商的违规行为开脱责任。**换句话说，上游提供商没有责任强制执行下游分销商的合规性，下游分销商也没有责任对上游提供商的合规问题负责。然而，未合规地分发 GPL 作品仍然是一个合规性问题。当 FSF 进行执法时，如果问题似乎出在上游，我们会耐心并且同情。事实上，我们敦促违规者指出上游供应商，以便我们可以直接与他们交流。在这种情况下，我们很高兴开始与 Thesulac 进行谈判。然而，Polgara 仍然有义务使他们的产品符合规定，而不管 Thesulac 的回应如何。
**上游提供商应该告知下游分销商合规事宜。**FSF 鼓励 Thesulac 在他们的产品中分发“GPL 合规的良好实践”文档。Polgara 将各种软件组件添加到 Thesulac 的产品中，这可能会引入合规性问题。在 FSF 的看法中，Thesulac 对于客户引入的违规行为没有任何法律责任，但从市场的角度来看，向他们的客户宣传产品的使用方式是值得的。我们可以争论是否应该归咎于您的咖啡供应商，如果您用他们的产品烫伤了自己，但（可能）双方都不会争议在杯子上贴上“注意：热”的标签的明智性。
**FSF 的执法通常避免了许多各方的重复执法案件。**大多数自由软件系统有数百个版权持有人。有些有数千个。作为 GPL 软件最大的单一版权持有人之一，以及社区中备受尊重的裁判员，FSF 处于独特的地位，中立地执行 GPL 路线规则。FSF 在社区中努力说服版权持有人通过 FSF 整合 GPL 索赔，这对他们更好，并且更有可能产生积极的合规结果。

A few copyright holders engage in the "proprietary relicensing" business, so they use GPL enforcement as a sales channel for that business. FSF, as a community-oriented, not-for-profit organization, seeks only to preserve the freedom of Free Software in its enforcement efforts. As it turns out, most of the community of copyright holders of Free Software want the same thing. Share and share alike is a simple rule to follow, and following that rule to FSF's satisfaction usually means you are following it to the satisfaction of the entire Free Software community.

几个版权持有者从事“专有重新许可”业务，因此他们将GPL执法用作该业务的销售渠道。作为一个面向社区的非营利组织，FSF仅在其执法工作中寻求保护自由软件的自由。事实证明，大多数自由软件版权持有者社区也希望实现同样的目标。共享并分享是一个简单的规则，遵循这个规则通常意味着你已经达到了整个自由软件社区的满意度。

Generally, from the experience of GPL enforcement, we glean the following general practices that can help in GPL compliance for organizations that distribute products based on GPL'd software:

通常从GPL执法的经验中，我们得出以下对于基于GPL软件的产品进行分发的组织来说可以帮助实现GPL合规的一些通用做法：

Talk to your software engineers and ask them where they got the components they use in the products they build. Find out if GPL'd components are present.
Teach your engineering staff to pay attention to license documents. Give them easy-to-follow policies to get approval for using a Free Software component.
Build a "Free Software Licensing" committee that handles requests and questions about the GPL and other Free Software licenses.
Add "What parts of your products are under the GPL or other Free Software licenses?" to your checklist of questions to ask when you consider mergers, acquisitions, or joint ventures.
Encourage your engineers to participate collaboratively with GPL'd software development. The more knowledge about the Free Software world your organization has, the better equipped it is to deal with this rapidly changing field.
When someone points out a potential GPL violation in one of your products, do not assume the product line is doomed. The GPL is not a virus; merely having GPL'd code in one part of a product does not necessarily mean that every related product must also be GPL'd. And, even if some software needs to be released that was not before, the product will surely survive. In FSF's enforcement efforts, we have not yet seen a product line die because source was released to customers in compliance with the GPL.
与你的软件工程师交谈并问问他们从哪里获得他们在构建产品中使用的组件。了解是否存在GPL组件。
教育你的工程人员注意许可文件。为他们提供易于遵循的政策，以获取使用自由软件组件的批准。
建立一个“自由软件许可”委员会，负责处理GPL和其他自由软件许可的请求和问题。
在考虑合并、收购或联合企业时，将“你的产品的哪些部分受GPL或其他自由软件许可证的保护？”添加到你的问题清单中。
鼓励你的工程师参与GPL软件开发的协作。你的组织对自由软件世界的了解越多，就越能应对这个快速变化的领域。
当有人指出你的产品可能存在GPL违规行为时，不要认为整个产品线都会毁掉。GPL不是病毒；仅仅在产品的某个部分存在GPL代码并不一定意味着每个相关产品都必须成为GPL。即使需要发布一些以前没有发布的软件，该产品也一定会生存。在FSF的执法工作中，我们还没有看到因为向客户发布了符合GPL的源代码而使得产品线死亡的情况。

Appendices

附录

APPENDIX A** CITATIONS OF INCORPORATED MATERIAL FROM OTHER PUBLISHED WORKS

从其他已发表作品中引用的材料的引证

作为一项公开的协作项目，本指南主要由通过其公共贡献流程收到的许多贡献组成。请查看Git日志以获取所有贡献的完整文档记录。

Below is a list of CC-By-SA-licensed works, with specific titles and publication dates, from which any material was incorporated into this Guide. The specific methods and details of incorporation are fully documented in the Git logs of the project.

以下是CC-By-SA许可的作品列表，包括特定的标题和出版日期，这些作品中的任何材料都被纳入了本指南中。具体的纳入方法和细节在项目的Git日志中得到了充分的记录。

GPLv3 First Discussion Draft Rationale, published by the Free Software Foundation on 2006-01-16.
GPLv3 Second Discussion Draft Rationale, published by the Free Software Foundation circa 2006-07.
GPLv3 Third Discussion Draft Rationale, published by the Free Software Foundation on 2007-03-28.
GPLv3 Discussion Draft 3 FAQ , published by the Free Software Foundation on 2007-03-28.
GPLv3 Final Discussion Draft Rationale, published by the Free Software Foundation on 2007-05-31.
GPLv3 Final Rationale, written and published by the Free Software Foundation on 2007-06-29.
GPLv3第一次讨论草案理由，由自由软件基金会于2006年1月16日发布。
GPLv3第二次讨论草案理由，由自由软件基金会于2006年7月左右发布。
GPLv3第三次讨论草案理由，由自由软件基金会于2007年3月28日发布。
GPLv3第三次讨论草案常见问题解答，由自由软件基金会于2007年3月28日发布。
GPLv3最终讨论草案理由，由自由软件基金会于2007年5月31日发布。
GPLv3最终理由，由自由软件基金会于2007年6月29日撰写并发布。

A Practical Guide GPL Compliance, written by Bradley M. Kuhn, Aaron Williamson and Karen Sandler and published by the Software Freedom Law Center on 2008-08-20.

GPL合规实践指南，由Bradley M. Kuhn、Aaron Williamson和Karen Sandler撰写，并于2008年8月20日由软件自由法律中心出版。

Software Freedom Law Center Guide to GPL Compliance, 2nd Edition, written by Eben Moglen and Mishi Choudhary and published by the Software Freedom Law Center on 2014-10-31.

软件自由法律中心GPL合规指南第2版，由Eben Moglen和Mishi Choudhary撰写，并于2014年10月31日由软件自由法律中心出版。

Detailed Analysis of the GNU GPL and Related Licenses, written by Bradley M. Kuhn, Daniel B. Ravicher, and John Sullivan and published by the Free Software Foundation for its CLE courses on 2004-01-20, 2004-08-24, and 2014-03-24.

《GNU GPL及相关许可证的详细分析》是由Bradley M. Kuhn、Daniel B. Ravicher和John Sullivan所著，由自由软件基金会于2004年1月20日、2004年8月24日和2014年3月24日发表于其CLE课程中的一篇文章。

Enforcement Case Studies, written by Bradley M. Kuhn and published by the Free Software Foundation for its CLE courses on 2004-01-20, 2004-08-24, and 2014-03-24.

《执行案例研究》是Bradley M. Kuhn撰写的，由自由软件基金会于2004年1月20日、2004年8月24日和2014年3月24日为其CLE课程出版。

Please note, however, that this list above does not include nor adequately represent the substantial contributions from those who directly contributed to this Guide using its Git (and formerly, CVS) repository. Rather, this is a list of third-party published works from which any text was herein included under their CC-By-SA licensing. Thus, as the reader might expect, the version control logs contain the only true and accurate view available of who has contributed which portions of this project.

请注意，上述列表不包括也无法充分代表那些直接通过Git（以前是CVS）代码库对本指南做出实质性贡献的人。相反，这是一个第三方已发布作品的列表，其中任何文本都是根据它们的CC-By-SA许可证在此处包含的。因此，正如读者所期望的那样，版本控制日志包含了对谁在此项目的哪些部分做出了贡献的唯一真实和准确的视图。

The remaining appendices include a full copy of GPLv2, GPLv3, LGPLv2.1, LGPLv3, and AGPLv3.

其余的附录包括 GPLv2、GPLv3、LGPLv2.1、LGPLv3 和 AGPLv3 的完整副本。

These are the most commonly used licenses in the GPL family of licenses.

这些是GPL许可证家族中最常用的许可证。

APPENDIX B GNU通用公共许可证

第二版，1991年6月

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

任何人都可以复制和发布本许可证完整副本，但不允许修改。

译者声明

This is an unofficial translation of the GNU General Public License into Chinese. It was not published by the Free Software Foundation, and does not legally state the distribution terms for software that uses the GNU GPL--only the original English text of the GNU GPL does that. However, we hope that this translation will help Chinese speakers understand the GNU GPL better.

本译文是GNU通用公共许可证的一份非官方中文翻译，并非自由软件基金会所发表，不适用于使用GNU通用公共许可证发布的软件的法律声明——只有GNU通用公共许可证英文原版才具有法律效力。不过我希望本翻译能够帮助中文读者更好地理解GNU通用公共许可证。

You may publish this translation, modified or unmodified, only under the terms at https://www.gnu.org/licenses/translations.html.

仅在遵循 https://www.gnu.org/licenses/translations.html 中的条款时，你才可以经过修改地或者不经过修改地发布本译文。

序言

大部分软件的许可证都是被设计为剥夺你分享和修改的自由。相反，GNU通用公共许可证的目的是保护你分享和修改自由软件的自由——确保软件对所有用户都是自由的。本通用公共许可证适用于自由软件基金会的大部分软件以及任何作者承诺使用该许可证的软件（自由软件基金会的其他一些软件受GNU宽松通用许可证的保护）。你也可以将本许可证用于你的程序。

自由软件，强调的是自由，而不是免费。本通用公共许可证的目的是保证你拥有分发自由软件的自由（如果你愿意还可以为此收费），确保你有收到源代码或者想要获得时拥有获得源代码的自由，确保你想要修改或者在新的自由软件中使用其中代码的自由，并且确保你有知情权。

为了保护你的权利，我们设置了一些限制以防止其他人否定你的权利或者要求你放弃你的权利。这些限制在你分发或者修改这些软件时会成为你的责任。

例如，你分发这类软件的副本，无论是免费的或者收费的，你必须授予接收者你拥有的所有权利。你必须保证他们也能收到或者能够获得源代码。并且你也要确保他们也知道他们的权利。

我们通过两步保护你的权利：(1) 授予软件著作权；(2) 赋予你合法复制、分发和修改软件的权利。

此外，为了保护每一位作者和我们自己，我们向每个人声明：自由软件是没有任何品质保证的。如果被其他人修改或者转发，我们希望接收者知道他们收到的不是原始版本，因此其他人引入的任何问题不会影响原作者的声誉。

最后，自由软件还不停地收到软件专利的威胁。我们希望避免自由软件分发者以个人名义获取专利，从而导致自由软件成为私有软件。为了避免这种事情发生，我们明确声明：任何专利必须许可给任何人自由使用或者完全不进行许可。

以下是复制、分发和修改的具体条款和条件。

复制、分发与修改条款和条件

0、本许可适用于任何版权持有人在他的程序或作品中声明以通用许可证条款发布的程序或作品。“程序”在下文中是指，任何程序或者作品，“程序的衍生作品”是指程序或者衍生作品包含该程序的全部或者部分，无论是逐字复制地或者经过修改的，或者是翻译成其他语言的。（下文中，翻译属于但不限于修改的范围）。每个被许可人均指“你”。

除复制、分发、修改之外的其他行为不在本许可范围内。运行软件的行为是不受约束的，软件的输出一般不在本许可范围内，除非它构成了本程序的衍生作品（单独通过运行本软件产生）。具体情况依程序用途而定。

你可以为你实际发送副本的实际行为收取费用，你也可以提供品质保证收取费用。

2、你可以通过修改本程序副本或者其中任意部分，从而构成衍生作品，并在满足条款1以及下列3点要求的前提下复制或者分发修改的作品。

a）你必须在修改后的文件带有明显的声明，说明你修改的任何文件和日期。

b）你必须将你发布或者发表的整个或者部分，或者基于本程序或者任意部分衍生的作品，全部免费地按照本许可证许可给所有第三方。

上述要求对修改后作品的整体有效。如果作品可以独立的部分不是从本软件衍生的，可以合理地将它们作为独立或者单独的作品，进行单独分发，本许可及其条款不适应于它们。但是，当你将它们与本程序的衍生作品一同发布时，分发的作品必须作为一个整体按照本许可证许可，本许可证的授权延伸到全部作品，而无论其任何部分是谁写的。

因此，本条款的目的不是声明或者争辩你创造的作品的全部权利，而是行使控制本程序衍生作品或者集体作品的分发权利。

另外，仅仅与本程序或者衍生作品一同存储或者通过同一个介质上分发的其他非本程序的衍生作品不在本许可证范围内。

3、在上述第1条和第2条约束下，你可以复制或者分发本程序（或根据第2条的衍生作品）的目标代码或者可执行格式分发本程序时，你必须满足下列要求：

a）根据上述第1条和第2条要求，附上完整的、机器可读的源代码，按照常用的软件交换媒介分发。或者

b）附上至少3年有效期的书面报价，向任何第三方，收取不高于你因分发源代码的实际花费的费用。源代码是根据上述第1条和第2条要求机器可读的完整的源代码，通过常用的软件交换介质分发。或者

c）附上你所收到的源代码的信息（该要求仅适用于非商业性分发，并且仅当你收到程序是目标代码或者可执行格式，同时还要满足本条款b项要求）。

作品的源代码是修改作品的首选格式。对于一个可执行的作品，完整的源代码是指其所有模块的所有源代码、相关接口定义文件、编译和安装所需的脚本。然而，作为例外，分发的源代码不必包括任何通常随运行本软件的目标操作系统的主要组件（编译器、内核等）一同分发的（源代码或者二进制）文件，除非它们是本软件的一部分。

如果是通过指定访问位置的形式分发可执行文件或者目标代码，那么提供获取源代码副本相同地址也算分发源代码，即使不要求第三方在复制目标代码时复制源代码。

4、除本许可证许可之外，你不能复制、修改、再许可或者分发本程序。试图进行任何其他形式的复制、修改、再许可或者分发本程序都是无效的，并且本许可证授予你的权利自动终止。然而，只要符合本许可证条款，从你获得副本的其他人的权利仍然有效。

5、你没有签署本许可证，你也不必接受本许可证。而且，此外无人可以授权你修改本程序及其衍生作品。除非你接受本许可证，否则这些行为是被法律禁止的。然而，修改或者分发本软件（或基于本软件的任何作品），表明你接受本许可证复制、分发或者修改本软件或者基于本软件的条款和条件。

6、你每次再分发本程序（或本程序的衍生作品）时，接收者自动从原始权利人获得本许可，以复制、分发或者修改本软件。你不能对他们获得的权利引入任何限制。你也没有要求第三方遵循本许可的责任。

7、如果由于法庭裁决或者专利侵权或者其他原因（不限于专利），使得你面临与本许可证冲突的情况（无论由于法庭裁决、协议或者其他），这也不能成为你不遵守本许可证的理由。如果你不分发本程序，就能满足本许可证条款和其他相关要求，你就不要分发本软件。例如，某专利许可不允许直接或者间接从你获得副本的接受者免费再分发本软件，为了同时满足本许可证和它的要求，你的唯一做法就是不再分发本软件。

如果在特定情况下本条款的任何部分无效或者无法实施，本条款的其余部分仍然适用，并且本条款作为整体适用于其他情况。

本条款的目的不是怂恿你违反任何专利或者其他权利要求，或者与它们抗辩。本条款的目的纯粹是保护自由软件分发系统的完整性，即通过公共许可证来实现。通过一致地应用该分发系统，很多人已经向通过该系统分发的大量软件做出了慷慨的贡献；作者/贡献者也可以决定是否愿意通过其他渠道分发，被授权人无权干涉该决定。

本条款旨在彻底阐明本许可其他条款所带来的当然后果。

8、如果本程序的分发和/或使用收到一些国家专利或者著作权的限制，权利人可以在通过本许可证授权的软件中明确添加受限的地理范围，以排除那些受限的国家，因此分发仍然可以在其他国家进行。这种情况下，本许可将这些限制纳入许可范围内。

9、自由软件基金会可能不时发布通用公共许可证的修订版和/或新版本。此类新版本与当前版本精神上相似，但在描述细节上可能不同，以解决新问题或情况。

每个版本都有一个唯一的版本号。如果软件指定了具体的版本号和“任何后续版本”，你可以选择遵守该版本或者后续版本。如果软件没有指定具体的许可证版本号，你可以选择自由软件基金会发布的任何版本。

10、如果你希望将本软件的部分并于分发条件不同的其他自由软件，应对书面请求作者的许可。对于自由软件基金会拥有著作权的软件，写信给自由软件基金会。我们有时会例外处理。我们的处理此类事情是有两个目标：保持所有自由软件衍生作品的自由属性以及促进软件共享和重用。

免责声明

11、本软件免费许可，因此在适用法律范围内不提供品质保证。除非另有书面声明，本软件著作权人和/或其他作者按“原样”提供本软件，不提供任何形式的显示的或隐式的品质保证，包括但不限于经济价值和适合特定用途的保证。本软件的全部品质和性能风险均由你承担。如果本软件出现缺陷、你将承担所有必要服务、修复和更正的成本。

12、在任何情况下，除非适用的法律要求或者书面协议，任何版权方和/或任何按照上述条款修改或/和分发本软件的第三方都不对你的损失负责，包括任何一般的、特殊的、偶发的或者重大损失（包括但不限于因你或者第三方，或操作不当、或无法与其他软件错误协同造成的数据丢失，数据失真、失效），即使那些持有方或者其他人已被告知此类损失的可能性。

条款和条件结束

如何将上述条款应用于你的新程序

如果你开发了一个新程序，并且希望它最大限度地被公众所使用，最好的办法就是将其作为自由软件，使得每个人都可以按照本许可证分发和修改。

用一行标明程序的名称和作用。

本程序是自由软件，你可以根据自由软件基金会发布的GNU通用许可证自由地再分发或者修改。本程序适用第2版或者后续版本（具体随你）。

我们希望本程序有用，但是不提供任何保证，甚至不保证它的经济价值或者适合特定目的。具体细节参加GNU通过公共许可证。

你应当随本程序收到了GNU通用公共许可证的副本，如果没有请致信自由软件基金会：51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

同时提供你的电子邮件或者纸质邮件地址。

如果本程序是交互的，让它在交互模式启动前输出如下的简短声明：

Gnomovision不提供任何品质保证，输入“show w”查看详情。本软件是自由软件，欢迎你根据许可条件再分发，输入“show c”查看详情。

假设的命令show w和show c用于显示通用公共许可证相应的内容。当然，你也可以使用show w和show c之外的其他命，甚至点击鼠标或者菜单项等——任何适合你程序的方式。

Yoyodyne有限公司声明放弃James Hacker所写的“Gnomovision”（编译通过的程序）的版权权益。

Ty Coon的签名 1989年4月1日

副总裁 Ty Coon

本通用公共许可证不允许将你的程序合并到私有程序。如果你的程序是子程序库，而你可以考虑让私有程序链接它，使其更有用。如果你希望这么做，你可以使用GUN宽松通用许可证。

APPENDIX C GNU通用公共许可证

第二版，1991年6月

51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

任何人都可以复制和发布本许可证完整副本，但不允许修改。

译者声明

You may publish this translation, modified or unmodified, only under the terms at https://www.gnu.org/licenses/translations.html.

仅在遵循 https://www.gnu.org/licenses/translations.html 中的条款时，你才可以经过修改地或者不经过修改地发布本译文。

序言

我们通过两步保护你的权利：(1) 授予软件著作权；(2) 赋予你合法复制、分发和修改软件的权利。

以下是复制、分发和修改的具体条款和条件。

复制、分发与修改条款和条件

你可以为你实际发送副本的实际行为收取费用，你也可以提供品质保证收取费用。

2、你可以通过修改本程序副本或者其中任意部分，从而构成衍生作品，并在满足条款1以及下列3点要求的前提下复制或者分发修改的作品。

a）你必须在修改后的文件带有明显的声明，说明你修改的任何文件和日期。

b）你必须将你发布或者发表的整个或者部分，或者基于本程序或者任意部分衍生的作品，全部免费地按照本许可证许可给所有第三方。

因此，本条款的目的不是声明或者争辩你创造的作品的全部权利，而是行使控制本程序衍生作品或者集体作品的分发权利。

另外，仅仅与本程序或者衍生作品一同存储或者通过同一个介质上分发的其他非本程序的衍生作品不在本许可证范围内。

a）根据上述第1条和第2条要求，附上完整的、机器可读的源代码，按照常用的软件交换媒介分发。或者

c）附上你所收到的源代码的信息（该要求仅适用于非商业性分发，并且仅当你收到程序是目标代码或者可执行格式，同时还要满足本条款b项要求）。

如果在特定情况下本条款的任何部分无效或者无法实施，本条款的其余部分仍然适用，并且本条款作为整体适用于其他情况。

本条款旨在彻底阐明本许可其他条款所带来的当然后果。

免责声明

条款和条件结束

如何将上述条款应用于你的新程序

如果你开发了一个新程序，并且希望它最大限度地被公众所使用，最好的办法就是将其作为自由软件，使得每个人都可以按照本许可证分发和修改。

用一行标明程序的名称和作用。

本程序是自由软件，你可以根据自由软件基金会发布的GNU通用许可证自由地再分发或者修改。本程序适用第2版或者后续版本（具体随你）。

我们希望本程序有用，但是不提供任何保证，甚至不保证它的经济价值或者适合特定目的。具体细节参加GNU通过公共许可证。

你应当随本程序收到了GNU通用公共许可证的副本，如果没有请致信自由软件基金会：51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

同时提供你的电子邮件或者纸质邮件地址。

如果本程序是交互的，让它在交互模式启动前输出如下的简短声明：

Gnomovision不提供任何品质保证，输入“show w”查看详情。本软件是自由软件，欢迎你根据许可条件再分发，输入“show c”查看详情。

Yoyodyne有限公司声明放弃James Hacker所写的“Gnomovision”（编译通过的程序）的版权权益。

Ty Coon的签名 1989年4月1日

副总裁 Ty Coon

翻译：赵振华 zhao.zhenhua@gmail.com

发布日期：2022年12月28日

地址：https://github.com/zRich/gpl/blob/main/gplv2/gplv2.pdf

如有修改建议欢迎发邮件或者到 https://github.com/zRich/gpl 讨论。

参考：

[简体中文译本] https://www.gnu.org/licenses/old-licenses/gpl-2.0-translations.html

APPENDIX D GNU通用公共许可证

第3版，2007年6月29日

任何人都可以复制和发布本许可证的完整副本，但不允许修改。

引言

GNU通用公共许可证是一份面向软件及其他类型作品的、著佐权许可证。

就多数软件而言，许可证被设计用于剥夺你分享和修改软件的自由。相反，GNU通用公共许可证力图保障你分享和修改某程序全部版本的权利——确保自由软件对其用户来说是自由的。我们——自由软件基金会——将GNU通用公共许可证用于我们的大多数软件，并为一些其他作品的作者效仿。你也可以将本许可证用于你的程序。

所谓自由软件，强调自由，而非免费。设计GNU通用公共许可证的目的在于确保你享有分发自由软件的自由（你可以为此服务收费），确保你可以在需要的时候获得cd这些软件的源代码，确保你可以修改这些软件或者在新的自由软件中复用其中某些片段，并且确保你在这方面享有知情权。

例如，你分发这类软件的副本，无论是收费或者免费，你必须授予接收者你拥有的所有权利。你必须保证他们也能收到或者能够获得源代码。并且你也要确保他们也知道他们的权利。

采用GNU通用公共许可证的开发者通过两步保障你的权利：（1）声明软件的版权；（2）通过本许可证授予你合法地复制、分发和修改该软件的权利。

为了保护作者和开发者，GPL明确声明：自由软件并没有品质担保。为用户和作者双方着想，GPL要求修改版必须有修改标记，以免其问题被错误地归到先前版本的作者身上。

某些设备设计成拒绝用户安装、运行修改过的软件，但设备生产商不受此限制。这和我们保护用户享有修改软件的自由的宗旨存在根本性矛盾。这种系统化地滥用模式常常出现于个人用品领域，这恰恰是最不可接受的。因此，我们设计了这版GPL来禁止这类做法的产品。如果此类问题在其他领域大量出现，我们随时在GPL的后续版本中把规定扩展到相应领域，以保护用户的自由。

最后，每个程序都持续受到软件专利的威胁。政府不应该允许专利限制通用计算机软件的开发和应用，在做不到这点时，我们希望避免因专利的应用而使自由软件私有化的危险。就此，GPL保证专利不能使程序非自由化。

下文是关于复制、分发和修改的详细条款和条件。

条款和条件

0. 定义

“本许可证”指GNU通用公共许可证第3版。

“版权”也指适用于其他类型作品的类似版权的法律，如半导体掩模。

“本程序”指任何受本许可证保护的任何有版权的作品。每位被授权人称作“你”。“被授权人”和“接收者”可以是个人或组织。

“修改”一个作品指需要版权授权才能复制该作品以及对作品全部或部分的改编行为，不同于制作完全相同的副本。所产生的作品称作上一作品的“修改版”，或“基于”上一作品衍生作品。

“涵盖的作品”指未修改的程序或其衍生作品。

“传播”作品指那些未经授权就会在适用版权法律下构成直接或间接侵权的任何行为，但在计算机上运行和修改私有副本除外。传播包括复制、分发（无论修改与否）、向公众公开，以及在某些国家的其他行为。

“传递”作品指让他方能够制作或者接收副本的行为。仅仅通过计算机网络与用户交互，但没有传输副本，则不算传递。

1. 源代码

作品的“源代码”指其可修改的首选形式，目标代码指所有其他形式。

“标准接口”指标准化组织定义的官方标准中的接口，或针为某种编程语言设定的为开发者广泛使用的接口。

可执行作品中的“系统库”不是指整个程序，而是包含任何这类内容的部分：（a）以通常形式和主要组件打包到一起却并非后者的一部分，且（b）仅为和主要组件一起使该作品可用或实现某些已有公开实现源代码的接口。“主要组件”在这里指可执行该作品运行依赖的操作系统（如果存在）的必要组件（内核、窗口系统等），或者生成该作品的编译器，或运行所需的目标代码解释器。

目标代码作品的“相应源代码”指所有修改该作品及生成、安装、运行（对可执行作品而言）目标代码所需的所有源代码，或者修改作品的所有源代码，包括控制上述行为的脚本。可是，其中不包括系统库、通用工具、不需要修改就可以直接用于支持上述行为但不是该作品一部分的、通常可得的自由软件。例如，相应的源代码包含与作品源文件相关的接口定义，以及共享库和该作品专门依赖的动态链接子程序的源代码。这里的依赖体现为密切的数据交换或者该子程序和作品其他部分的控制流切换。

相应的源代码不必包含那些用户可以通过源代码其他部分自动生成的内容。

源代码形式作品的相应源代码即该作品本身。

2. 基本授权

本许可证的所有授权都是对本程序的版权而言的，并且当所述条件都满足时不可撤销。本许可证明确授权你不受限制地运行本程序的未修改版本。运行涵盖的作品的输出结果，仅当其内容构成一个涵盖的作品时，才受本许可证约束。如版权法授权一样，本许可证承认你合理使用权或其他同等权利。

只要你获得的许可仍有效，你就可以制作、运行和传播不是你传递的涵盖的作品。在你遵守本许可证中关于转发你拥有版权的材料的条款时，你可以向他人传递涵盖的的作品，以让对方单独为你定制修改，或者向你提供运行这些作品的工具。那些为你制作或运行这些涵盖的作品的人，必须在你的指引和控制下，仅代表你工作，即禁止他们在双方关系之外制作任何你提供的受版权保护材料的副本。

仅当满足后文所述条件时，其他各种情况下的传递才是被允许的。不允许再授权，而第10条的存在也使再授权变得没有必要。

3. 保护用户的合法权益免受反破解法限制

为了履行1996年12月20日通过的WIPO版权条约第11章规定的义务，法律规定了禁止或规避措施的条款，所有涵盖的作品不应该被视为规避这些法律条款的技术手段的一部分。

如果你传递一个涵盖的作品，即表明你放弃禁止技术规避措施的法律权利，行使本许可证所授予权利可以实现规避，同时，你也放弃禁止技术规避措施相关的法律赋予你或者第三方限制运行或者修改本作品的权利。

4. 传递原始副本

你可以免费或收任何费用传递，也可以选择提供技术支持或品质担保以收取费用。

5. 传递经过修改的源代码

你可以以第4条规定的源代码形式传递基于本程序的作品或修改的内容，但必须满足以下要求：

a）该作品必须带有明显的修改声明及相应的日期。
b）该作品必须带有明显的声明，指明其在本许可证及任何符合第7条的附加条款下发布。这个要求修正了第4条关于“完整保留所有声明”的内容。
c）你必须按照本许可证将该作品整体许可给任何得到副本的人。本许可证与符合第7条的附加条款共同适用于整个作品，以及作品的任何一部分，不管它们是如何组建的。本许可证不允许以其他形式许可本作品，但不会使你已经单独收到的其他授权无效。
d) 如果该作品有交互式用户界面，则其必须显示适当的法律声明。然而，当该程序有交互式用户界面却不显示适当的法律声明时，你的作品也无需使其显示。

一个涵盖的作品与其他单独且独立的作品组成一个组合，其中的单独作品既不是涵盖的作品的自然延伸，也不是为了与涵盖的作品组成更大程序而与被保护作品存储或者分发介质上，并且这种组合和组合后的版权不会限制单独作品的授权，则这种组合称为“组合体”。

6. 以非源代码形式传递

你可以以第4条和第5条所述那样以目标代码形式传递涵盖的作品，同时在本许证可规范下以如下方式之一传递机器可读的对应源代码：

a) 通过物理产品（包括物理分发媒介）传递或者嵌入目标代码时，通过常用于软件交换的耐用型物理媒介传递相应的源代码。
b) 通过物理产品（包括物理分发媒介）时，附随具有至少3年有效期的书面承诺，并且有效期涵盖提供的备件或客户支持，以授予任何目标代码的持有者：（1）获得产品中全部涵盖的软件的相应源代码的副本，副本通过常用于软件交换的耐用型物理媒介提供，且收费不超过其合理的传递成本；或者（2）通过网络免费获得相应源代码的途径。
c) 单独传递目标代码的副本时，伴以提供源代码的书面承诺。本选项仅在偶尔并且非商业情况下，同时你收到也是第6条b项所述的目标代码的情况下可用。
d) 通过在指定地址获取目标代码（无论是否收费）的形式传递目标代码时，对同一地址以同样的方式提供相应源代码同等访问权限，并不得额外收费。你不必要求接收者在复制目标代码的同时复制源代码。如果提供获取目标代码的地址为网络服务器，相应的源代码可以提供在另一个支持相同复制功能的服务器上（由你或者第三方运营），不过你要在目标代码处指出相应源代码的确切路径。不管你用什么源代码服务器，你有义务要确保持续可用以满足这些要求。
e) 通过点对点传输传递目标代码时，告知其他节点目标代码和源代码在何处，并以第6条d项形式向大众免费提供。

如果目标代码的可分离部分，其源代码作为系统库在相应的源代码之外，则不需要被包括在传送目标代码作品中。

“用户产品”指（1）“消费品”，即个人、家庭或日常用途的个人的有形财产；或者（2）面向家庭设计或销售的物品。在判断一款产品是否消费品时，对于有争议的案例，应尽量扩大覆盖范围。就特定用户接收到特定产品而言，“正常使用”指对此类产品的典型的或一般使用，与该用户的身份，该用户对该产品的实际用法，以及该产品的预期用法无关。无论产品是否实质上具有商业上的，工业上的，及非面向消费者的用法，它都视为消费品，除非以上用法代表了它唯一的重要使用模式。

用户产品的“安装信息”，指基于修改过的源代码来安装运行该产品中的涵盖的作品的修改版所需的方法、流程、授权秘钥及其他信息。这些信息必须足以保证修改过的目标代码不会仅仅因为被修改过而不能继续工作。

如果你根据本条规定，传递一个目标代码作品到用户产品中或与用户产品一起，或专门用于特定用户产品，并且传送行为成为交易的一部分，使得用户产品永久或在特定期限内暂时转移给接收者（无论交易的特征如何），必须通过安装信息附上根据本条传递的相应来源。但如果你和第三方都没有在用户产品中保留安装修改目标代码的能力时，可以不遵守该要求（例如，作品有已安装在 ROM 中）。

提供安装信息的要求不包括对接受者修改或者安装、或者已经被修改或者安装的用户产品继续提供支持服务、品质担保或者升级。当修改本身对网络运行有重大负面影响，或违反网络通信规则和协议时，可能会被拒绝访问网络。

根据本条规定发布的源代码及安装信息，必须以公共的文档格式（并且以源代码形式实现对公众可用）存在，同时不得对解压、阅读和复制设置任何密码或秘钥。

7. 附加条款

“附加许可”用于补充本许可证的条款，以允许一或者多个例外情况。如果附加许可适用于整个程序且在适用的法律范围内有效，就应该视为本许可证的一部分。如果附加许可只适用于程序的某部分，则该部分受此附加许可约束，而其他部分受不适用附加许可之外的条款约束。

当你传递本程序的副本时，你可以选择性从副本中删除任何附加许可。（在某些情况下，当你修改作品时，附加许可可能已经写明要求你删除该附加许可。）对于你传递的作品，如果你拥有或者可以适当地授权，你也可以在作品的材料中添加附加许可。

尽管本许可证还有的其他条款，对于你添加到涵盖的作品中的材料，你可以对本许可证（如果你获得该材料版权持有人的授权）添加如下补充条款：

a) 以第15条、第16条之外的方式，拒绝提供品质担保或缩小责任范围。或者
b) 要求在此材料中或在法律声明中包含特定的合理法律声明或作者信息。或者
c) 禁止对该原始材料不当描述，或要求用不同与原始版本的方式对该材料修改版本合理标示。或者
d) 限制公开使用授权人或者该材料作者姓名。或者
e) 拒绝使用在商标法下使用商号、商标及服务标识。
f) 任何传递该材料（或其修改版）者，如果对接收者提供契约性责任许诺，需要为授权人或者该材料作者承担赔偿责任，因为任何契约假设责任都造成授权人或者作者承担。

此外的非授权附加条款都被视作第10条所说的“进一步的限制”。如果你接收到的程序或程序的任何部分，包含受本许可约束的声明，却补充了这种进一步的限制条款，你可以删除它们。如果某许可文件包含进一步的限制条款，但允许通过本许可证再授权或传递，你可以添加受该许可文件保护的材料，同时提供其他的再许可或者传递的进一步限制条款。

如果你根据本条规定向涵盖的作品添加了新的条款，你必须在相关的源文件中加入附加条款的对应的声明，或者指明在哪里可以找到适用的条款。

附加条款，不管是授权的还是非授权的，可以以独立的书面许可出现，也可以声明为例外情况，两种做法都可以实现上述要求。

8. 终止

除非在本许可证明确授权下，你不得传播或修改涵盖的作品。其他任何传播或修改涵盖的作品的做法都是无效的，你通过本许可证获得的权利（包括第11条第3段中授予的专利权限）也自动终止。

然而，当你不再违反本许可证时，你从特定版权持有人处获得的许可可以：（1）暂时恢复，直到版权持有人明确终止；（2）永久恢复，如果版权持有人没能在60天内以合理的方式指出你的侵权行为。

再者，如果你第一次收到了特定版权持有人关于你违反本许可证（对任意作品）的通知，且在收到通知后30天内改正，那你可以继续享此有许可。

当你享有的权利如本条所述被中止时，根据本许可证从你这里获得许可的第三方的权利不会因此中止。在你的权利恢复之前，你没有资格凭第10条获得同一材料的许可。

9. 持有副本不需要接受

你不必为接收或运行本程序而接受本许可。类似地，仅仅因点对点传输接收到副本引发的对涵盖的作品的辅助性传播，并不要求接受本许可证。但是，除本许可证外没有什么可以授权你传播或修改任何涵盖的作品。如果你不接受本许可证，这些行为就侵犯了著作权。因此，一旦修改和传播一个涵盖的作品，就表明你接受了本许可证。

10. 对下游接收者的自动授权

每当你传递一个涵盖的作品，其接收者自动获得来自原始授权人的许可，依照本许可证可以运行、修改和传播此作品。你没有要求第三方遵守本许可证的责任。

“实体交易”指转移一个组织的控制权或全部资产、或拆分或合并组织的交易。如果实体交易导致一个涵盖的作品的传播，则交易中各收到作品副本方，都有获得前利益相关者享有或可以如前段所述提供的对该作品的任何授权，以及从前利益相关者处获得并拥有相应的源代码的权利，如果前利益相关者享有或可以通过合理的努力获得此源代码。

你不可以对本许可证所授权利的行使施以进一步的限制。例如，你不可以索要许可费或版税，或就行使本许可证所授予的权利征收其他费用；你也不能发起诉讼（包括交互诉讼和反诉），宣称制作、使用、零售、批发、引进本程序或其部分的行为侵犯了任何专利声明。

11. 专利

“贡献者”指通过本许可证对本程序或其衍生作品进行许可的版权持有人。贡献者许可的作品称为“贡献者版本”。

贡献者的“必要专利声明”是由贡献者拥有或控制所有专利声明，无论是已经获得还是将要获得的，通过本许可证授权本来侵犯行为，例如制作、使用或销售其贡献者版本，但不包括仅对贡献者版本进一步修改的行为。根据本定义，“控制”包括符合本许可证要求的专利再许可的权利。

每位贡献者皆其就拥有的实际专利权限，授予你一份全球有效的免版费的非独占专利许可，以制作、使用、零售、批发、引进，及运行、修改、传播其贡献者版的内容。

在以下3段中，“专利授权”指通过任何方式明确表达的不行使专利权（如对使用专利的明确许可和不起诉专利侵权的契约）的协议或承诺。对某方“授予”专利权限，指这种不对其强制行使专利权的协议或承诺。

如果你传递的涵盖的作品时，明知需要某专利授权，而其相应的源代码并不是任何人都能根据本许可从网上或其他地方免费获得，那你必须（1）提供相应的源代码；或者（2）放弃从该程序的专利授权中的权益；或者（3）以某种和本许可相一致的方式将专利许可扩展到下游接收者。“明知需要”指你实际上知道若没有专利授权，你在某国家传递涵盖的作品的行为，或者接收者在某国家使用涵盖的作品的行为，会侵犯一项或多项该国认定的专利，而这些专利你有理由相信它们的有效性。

如果根据单一交易或安排，抑或与之相关，你传递某涵盖的作品，或通过促成其转手以实现传播，并且该作品的接收方被授予专利权限，以使其可以使用、传播、修改或转发该作品的特定副本，则此等专利授权将自动延伸及每一个收到该作品或其衍生作品的接受者。

如果某专利在其涵盖范围内，不包含本许可证专门授予的一项或多项权利，禁止行使它们或以不行使它们为前提，则该专利是“歧视性”的。如果你和软件发布行业的第三方有合作，合作要求你就转发涵盖的作品的情况向其付费，并授予作品接收方歧视性专利，而且该专利（a）与你转发的副本（或在此基础上制作的副本）有关，或针对包含该涵盖的作品的产品或联合作品，你不得转发本程序，除非参加此项合作或取得该专利授权早于2007年3月28日。

本许可证的任何部分不应被解释成在排斥或限制任何暗含的许可，或者其他在适用专利法下对抗侵权的措施。

12. 不得牺牲他人的自由

即便你面临与本许可证条款冲突的条件（来自于法庭要求、协议或其他），也不能成为你违反本许可证的理由。倘若你不能在传递涵盖的作品时同时满足本许可证和其他相关文件的要求，那么你就不要传递本程序。例如，你为了遵循某些要求，你必须向传递对象的接收者收取版税，唯一能同时满足它和本许可证要求的做法便是不传递本程序。

13. 与GNU Affero通用公共许可证一起使用

尽管本许可证中已存在其他条款，你可以将任何涵盖的作品与以GNU Affero通用公共许可证保护的作品关联或组合成一个联合作品，并转发。本许可证对其中的涵盖的作品部分仍然有效，但GNU Affero通用公共许可证第13条的关于网络交互的特别要求适用于整个联合作品。

14. 本许可证的修订版

自由软件基金会可能会不定时发布GNU通用公共许可证的修订版或新版。新版将秉承当前版本的精神，但在细节上描述不尽相同，以解决新的问题或事项。

每一版都会有不同的版本号，如果本程序指定其使用的是某个GNU通用公共许可证的版本“或后续版本”，你可以选择遵守该版本或者任何后续版本的条款。如果本程序没有指定许可证的版本，你可以选用自由软件基金会发布的GNU通用公共许可证任何版本。

如果本程序指明代理可以决定使用GNU通用公共许可证哪个版本，则该代理的公开声明的版本为授权你永久使用的版本。

后续版本可能会给予你额外或不同的许可。但是，任何作者或版权持有人的义务，不会因为你选择新后续版本而增加。

15. 免责声明

本程序在适用法律范围内不提供品质担保。除非另作书面声明，版权持有人及其他程序提供者“概”不提供任何显式或隐式的品质担保，品质担保所指包括而不仅限于有经济价值和适合特定用途的保证。全部风险，如程序的质量和性能问题，皆由你承担。若程序出现缺陷，你将承担所有必要的修复和更正服务的费用。

16. 责任限制

除非适用法律或书面协议要求，任何版权持有人或本程序按本许可证可能存在的第三方修改和再发布者，都不对你的损失负有责任，包括由于使用或者不能使用本程序造成的任何一般的、特殊的、偶发的或重大的损失（包括而不限于数据丢失、数据失真、你或第三方的后续损失、其他程序无法与本程序协同运作），即使有人声称会对此负责。

17. 第15条和第16条的解释

如果上述免责声明和责任限制不为地方法律所支持，上诉法庭应采用与之最接近的关于放弃本程序相关民事责任的地方法律，除非本程序附带收费的品质担保或责任许诺。

条款和适用条件结束

如何将上述条款应用到你的程序

如果你开发了一个新程序，并且希望它最大限度地被公众所使用，最好的办法就是将其作为自由软件，使得每个人都可以按照本许可证分发和修改。

<用一行标明程序的名称和作用。 >

本程序是自由软件，你可以根据自由软件基金会发布的GNU通用许可证自由地再分发或者修改。本程序适用第3版或者后续版本（具体随你）。

我们希望本程序有用，但是不提供任何保证，甚至不保证它的经济价值或者适合特定目的。具体细节参加GNU通过公共许可证。

你应当随本程序收到了GNU通用公共许可证的副本，如果没有，请参阅 https://www.gnu.org/licenses/ 。

同时提供你的电子邮件或者纸质邮件地址。

如果本程序是交互的，使其在交互模式启动前输出如下的简短声明：

本程序不提供任何品质保证，输入“show w”查看详情。本软件是自由软件，欢迎你根据许可条件再分发，输入“show c”查看详情。

假设的命令show w 和 show c 用于显示通用公共许可证相应的内容。当然，你也可以使用show w 和 show c 之外的其他命令，对于图形界面程序，你可以使用“关于”对话框。

本通用公共许可证不允许将你的程序合并到私有程序。如果你的程序是子程序库，而你可以考虑让私有程序链接它，使其更有用。如果你希望这么做，你可以使用GUN宽松通用许可证，但是首先，请阅读 https://www.gnu.org/licenses/why-not-lgpl.html 。

APPENDIX E: GNU AFFERO GENERAL PUBLIC LICENSE

附录#： GNU Affero 通用公共许可证

Version 3, 19 November 2007

第3版, 2017年11月19日

任何人都可以复制和发布本许可证的完整副本，但不允许修改。

Preamble

引言

The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.

GNU Affero通用公共许可证是一个面向软件和其他类型作品自由的、著佐权许可证，专门针对网络服务软件，确保社区合作而设计。

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.

就多数软件而言，许可证被设计用于剥夺你分享和修改软件的自由。相反，通用公共许可证力图保障你分享和修改某程序全部版本的权利——确保自由软件对其用户来说是自由的。我们——自由软件基金会——将GNU通用公共许可证用于我们的大多数软件，并为一些其他作品的作者效仿。你也可以将本许可证用于你的程序。

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

所谓自由软件，强调自由，而非免费。设计通用公共许可证的目的在于确保你享有分发自由软件的自由（你可以为此服务收费），确保你可以在需要的时候获得这些软件的源代码，确保你可以修改这些软件或者在新的自由软件中复用其中某些片段，并且确保你在这方面享有知情权。

Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.

采用我们通用公共许可证的开发者通过两步保障你的权利：（1）声明软件的版权；（2）通过本许可证授予你合法地复制、分发和修改该软件的权利。

A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.

捍卫所有用户自由的次要好处是如果在软件替代版本在的改进被广泛实用，其他开发者也可以采用它们。很多自由软件的开发者对产生的合作感到振奋和受到鼓舞。然而，对于网络服务器上使用的软件，这种结果可能不会出现。GNU通用公共许可证允许在服务器上提供一个公众可以访问的修改版，而不需要向公众提供修改版的源代码。

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

GNU Affero通用公共许可证针对这种情况设计，让修改后的代码仍然能被社区使用。这要求网络服务器的运营商提供在服务器上为用户运行的修改版的源代码。因此，公众使用的修补版，在一个公众可以访问的服务器上，公众可以获得修改版的源代码。

An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.

Affero发布的一个称为Affero通用公共许可证的旧许可证，也为实现类似的目的。那个许可证不是GNU Affero通用公共许可证的版本，但是Affero已经发布了新版本，允许在该许可证下重新许可。

The precise terms and conditions for copying, distribution and modification follow.

下文是关于复制、分发和修改的详细条款和条件。

Terms and Conditions

条款和条件

0. Definitions

0. 定义

This License refers to version 3 of the GNU Affero General Public License.

“本许可证”指GNU Affero通用公共许可证第3版。

Copyright also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“版权”也指适用于其他类型作品的类似版权的法律，如半导体掩模。

The Program refers to any copyrightable work licensed under this License. Each licensee is addressed as you. Licensees and recipients may be individuals or organizations.

“本程序”指任何受本许可证保护的任何有版权的作品。每位被授权人称作“你”。“被授权人”和“接收者”可以是个人或组织。

To modify a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a modified version of the earlier work or a work based on the earlier work.

A covered work means either the unmodified Program or a work based on the Program.

“涵盖的作品”指未修改的程序或其衍生作品。

To propagate a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To convey a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

“传递”作品指让他方能够制作或者接收副本的行为。仅仅通过计算机网络与用户交互，但没有传输副本，则不算传递。

An interactive user interface displays Appropriate Legal Notices to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.

1. Source Code

1. 源代码

The source code for a work means the preferred form of the work for making modifications to it. Object code means any non-source form of a work.

作品的“源代码”指其可修改的首选形式，目标代码指所有其他形式。

A Standard Interface means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

“标准接口”指标准化组织定义的官方标准中的接口，或针为某种编程语言设定的为开发者广泛使用的接口。

The System Libraries of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The Corresponding Source for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

相应的源代码不必包含那些用户可以通过源代码其他部分自动生成的内容。

The Corresponding Source for a work in source code form is that same work.

源代码形式作品的相应源代码即该作品本身。

2. Basic Permissions

2. 基本授权

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

仅当满足后文所述条件时，其他各种情况下的传递才是被允许的。不允许再授权，而第10条的存在也使再授权变得没有必要。

3. Protecting Users' Legal Rights From Anti-Circumvention Law

3. 保护用户的合法权益免受反破解法限制

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

4. Conveying Verbatim Copies

4. 传递原始副本

You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

你可以免费或收任何费用传递，也可以选择提供技术支持或品质担保以收取费用。

5. Conveying Modified Source Versions

5. 传递经过修改的源代码

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

你可以以第4条规定的源代码形式传递基于本程序的作品或修改的内容，但必须满足以下要求：

a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
a) 该作品必须带有明显的修改声明及相应的日期。
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to keep intact all notices.
b) 该作品必须带有明显的声明，指明其在本许可证及任何符合第7条的附加条款下发布。这个要求修正了第4条关于“完整保留所有声明”的内容。
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
c) 你必须按照本许可证将该作品整体许可给任何得到副本的人。本许可证与符合第7条的附加条款共同适用于整个作品，以及作品的任何一部分，不管它们是如何组建的。本许可证不允许以其他形式许可本作品，但不会使你已经单独收到的其他授权无效。
d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
d) 如果该作品有交互式用户界面，则其必须显示适当的法律声明。然而，当该程序有交互式用户界面却不显示适当的法律声明时，你的作品也无需使其显示。

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an aggregate if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

6. Conveying Non-Source Forms

6. 以非源代码形式传递

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

你可以以第4条和第5条所述那样以目标代码形式传递涵盖的作品，同时在本许证可规范下以如下方式之一传递机器可读的对应源代码：

a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
a) 通过物理产品（包括物理分发媒介）传递或者嵌入目标代码时，通过常用于软件交换的耐用型物理媒介传递相应的源代码。
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
b) 通过物理产品（包括物理分发媒介）时，附随具有至少3年有效期的书面承诺，并且有效期涵盖提供的备件或客户支持，以授予任何目标代码的持有者：（1）获得产品中全部涵盖的软件的相应源代码的副本，副本通过常用于软件交换的耐用型物理媒介提供，且收费不超过其合理的传递成本；或者（2）通过网络免费获得相应源代码的途径。
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
c) 单独传递目标代码的副本时，伴以提供源代码的书面承诺。本选项仅在偶尔并且非商业情况下，同时你收到也是第6条b项所述的目标代码的情况下可用。
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
d) 通过在指定地址获取目标代码（无论是否收费）的形式传递目标代码时，对同一地址以同样的方式提供相应源代码同等访问权限，并不得额外收费。你不必要求接收者在复制目标代码的同时复制源代码。如果提供获取目标代码的地址为网络服务器，相应的源代码可以提供在另一个支持相同复制功能的服务器上（由你或者第三方运营），不过你要在目标代码处指出相应源代码的确切路径。不管你用什么源代码服务器，你有义务要确保持续可用以满足这些要求。
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
1. 通过点对点传输传递目标代码时，告知其他节点目标代码和源代码在何处，并以第6条d项形式向大众免费提供。

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

如果目标代码的可分离部分，其源代码作为系统库在相应的源代码之外，则不需要被包括在传送目标代码作品中。

A User Product is either (1) a consumer product, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, normally used refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

Installation Information for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

根据本条规定，所专递相应源代码和所提供的安装信息必须以公开的文档格式（并且以源代码形式实现对公众可用）存在，同时不得对解包、阅读和复制设置任何密码或秘钥。

7. Additional Terms

7. 附加条款

Additional permissions are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

尽管本许可证还有的其他条款，对于你添加到涵盖的作品中的材料，你可以对本许可证（如果你获得该材料版权持有人的授权）添加如下补充条款：

a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
a) 以第15条、第16条之外的方式，拒绝提供品质担保或缩小责任范围。或者
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
b) 要求在此材料中或在法律声明中包含特定的合理法律声明或作者信息。或者
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
c) 禁止对该原始材料不当描述，或要求用不同与原始版本的方式对该材料修改版本合理标示。或者
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
d) 限制公开使用授权人或者该材料作者姓名。或者
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
e) 拒绝使用在商标法下使用商号、商标及服务标识。
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
f) 任何传递该材料（或其修改版）者，如果对接收者提供契约性责任许诺，需要为授权人或者该材料作者承担赔偿责任，因为任何契约假设责任都造成授权人或者作者承担。

All other non-permissive additional terms are considered further restrictions within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

如果你根据本条规定向涵盖的作品添加了新的条款，你必须在相关的源文件中加入附加条款的对应的声明，或者指明在哪里可以找到适用的条款。

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

附加条款，不管是授权的还是非授权的，可以以独立的书面许可出现，也可以声明为例外情况，两种做法都可以实现上述要求。

8. Termination

8. 终止

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

再者，如果你第一次收到了特定版权持有人关于你违反本许可证（对任意作品）的通知，且在收到通知后30天内改正，那你可以继续享此有许可。

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.

9. Acceptance Not Required for Having Copies

9. 持有副本不需要接受

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

10. Automatic Licensing of Downstream Recipients

10. 对下游接收者的自动授权

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An entity transaction is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

11. Patents

11. 专利

A contributor is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's contributor version.

“贡献者”指通过本许可证对本程序或其衍生作品进行许可的版权持有人。贡献者许可的作品称为“贡献者版本”。

A contributor's essential patent claims are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, control includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a patent license is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To grant such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. Knowingly relying means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is discriminatory if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.

本许可证的任何部分不应被解释成在排斥或限制任何暗含的许可，或者其他在适用专利法下对抗侵权的措施。

12. No Surrender of Others' Freedom

12. 不得牺牲他人的自由

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

13. Remote Network Interaction; Use with the GNU General Public License

13. 远程网络交互；与GNU GPL通用公共许可证一起使用

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

尽管本许可证中已存在其他条款，如果你修改了本程序，你的修改版必须在明显位置向所有通过计算机网络（如果你的版本支持此类交互）交互的用户在网络服务器上提供标准的或者符合用户习惯的、免费地获取你的版本的相应的源代码的方式。

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

尽管本许可证有其他规定，你有权将任何涵盖的作品与根据 GNU 通用公共许可证第 3 版许可的作品链接或组合成一个单一的组合作品，并传递由此产生的作品。本许可证的条款将继续适用于包含作品的部分，但与之结合的作品将继续受 GNU 通用公共许可证第 3 版的约束。

14. Revised Versions of this License

14. 本许可证的修订版

The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU Affero General Public License or any later version applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU Affero General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU Affero General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

如果本程序指明代理可以决定使用GNU通用公共许可证哪个版本，则该代理的公开声明的版本为授权你永久使用的版本。

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

后续版本可能会给予你额外或不同的许可。但是，任何作者或版权持有人的义务，不会因为你选择新后续版本而增加。

15. Disclaimer of Warranty

15. 免责声明

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability

16. 责任限制

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16

17. 第15条和第16条的解释

If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

End of Terms and Conditions

条款和适用条件结束

How to Apply These Terms to Your New Programs

如何将上述条款应用到你的程序

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

如果你开发了一个新程序，并且希望它最大限度地被公众所使用，最好的办法就是将其作为自由软件，使得每个人都可以按照本许可证分发和修改。

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the © line and a pointer to where the full notice is found.

< one line to give the program's name and a brief idea of what it does. >

<用一行标明程序的名称和作用。 >

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

本程序是自由软件，你可以根据自由软件基金会发布的GNU通用许可证自由地再分发或者修改。本程序适用第3版或者后续版本（具体随你）。

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

我们希望本程序有用，但是不提供任何保证，甚至不保证它的经济价值或者适合特定目的。具体细节参加GNU通过公共许可证。

You should have received a copy of the GNU Affero General Public License along with this program. If not, see https://www.gnu.org/licenses/ . 你应当随本程序收到了GNU通用公共许可证的副本，如果没有，请参阅 https://www.gnu.org/licenses/。

Also add information on how to contact you by electronic and paper mail.

同时提供你的电子邮件或者纸质邮件地址。

If your software can interact with users remotely through a computer network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a Source link that leads users to an archive of the code. There are many ways you could offer source, and different solutions will be better for different programs; see section 13 for the specific requirements.

如果你的软件可以通过计算机网络远程与用户交互，你应该确保它提供了让用户获得源代码的方式。例如，你的程序是一个Web应用程序，它应该显示“源代码”链接，以让用户访问代码存档。提供源代码的方式有多种，不同的程序适合不同的方式；具体参考第13条。

You should also get your employer (if you work as a programmer) or school, if any, to sign a copyright disclaimer for the program, if necessary. For more information on this, and how to apply and follow the GNU AGPL, see https://www.gnu.org/licenses.

The political differences between the Free Software Movement and the Open Source Movement are documented on FSF's Web site at (http://www.fsf.org/licensing/essays/free-software-for-freedom.html). ↩ ↩² ↩³ ↩⁴
This is still commonly the case, though today there are additional ways of sharing Free Software. ↩ ↩² ↩³ ↩⁴
This statement is admittedly an oversimplification. Patents and trade secrets can cover software and make it effectively non-Free, and one can contract away their rights and freedoms regarding software, or source code can be practically obscured in binary-only distribution without reliance on any legal system. However, the primary control mechanism for software is copyright, and therefore this section focuses on how copyright restrictions make software proprietary. ↩ ↩² ↩³ ↩⁴
Copyright law in general also governs "public performance" of copyrighted works. There is no generally agreed definition for public performance of software and both GPLv2 and GPLv3 do not restrict public performance. ↩ ↩² ↩³ ↩⁴
Note that this is again an oversimplification; the complexities with this argument are discussed in Section [1.2.3.] ↩ ↩² ↩³
Copyleft communities' use of the term "strong copyleft" is undoubtedly imprecise. For example, most will call the GNU GPL a "strong copyleft" license, even though the GPL itself has various exceptions, such as the [GPLv3's system library exception] written into the text of the license itself. Furthermore, the copyleft community continues to debate where the a license cross the line from "strong copyleft" to "license that fails to respect software freedom", although ultimately these debates are actually regarding whether the license fits [Free Software definition] at all. ↩ ↩² ↩³
See [6,] 7.5, 9.14 for more discussion on how the patent system interacts with copyleft, and read Richard M. Stallman's essay, Let's Limit the Effect of Software Patents, Since We Can't Eliminate Them for more information on the problems these patents present to society. ↩ ↩²
See 9.5 for more information on how GPL deals with this issue. ↩ ↩²
See Andrew Tridgell's "A bit of history and a bit of fun" ↩ ↩²
This quotation is Copyright c 2002, Lawrence Lessig. It is licensed under the terms of the "Attribution License" version 1.0 or any later version as published by Creative Commons. ↩
Most Free Software enthusiasts believe there is a moral obligation to redistribute changes that are generally useful, and they often encourage companies and individuals to do so. However, there is a clear distinction between what one ought to do and what one must do. ↩ ↩²
Recall that you could by default charge for any acts not governed by copyright law, because the license controls are confined by copyright. ↩ ↩²
As a matter of best practice, it's useful to assume that all software may eventually be distributed later, even if there no plans for distribution at this time. Too often, GPL violations occur because of a late distribution decision of software that was otherwise never intended for distribution. ↩ ↩²
"Compilation" in this context refers to the automated computing process of converting source code into binaries. It has absolutely nothing to do with the term "compilation" in copyright statues. ↩ ↩²
In the USA, due to unfortunate legislation, the length of copyright is nearly perpetual, even though the Constitution forbids perpetual copyright. ↩ ↩²
This section was substantially expanded for clarity and detail in GPLv3 *§*10. ↩ ↩²
While this is legally true, as a practical matter, a failure of "complete, corresponding source" (CCS) provisioning by an upstream could make it effectively impossible for a downstream party to engage in a commercial redistribution pursuant to GPLv2 3(a--b). ( [18.2] in the Compliance Guide portion of this tutorial discussed related details.) ↩ ↩²
While nearly all attorneys and copyleft theorists are in agreement on this point, German copyleft legal expert Till Jaeger vehemently disagrees. Jaeger's position is as follows: under German copyright law, a new copy of GPL'd software is a "fresh" license under GPL, and if compliance continues from that point further, the violator's permissions under copyright law are automatically restored, notwithstanding the strict termination provision in GPLv2 4. However, in practice, this issue is only salient with regard to [proprietary relicensing] business models, since other copyright holders typically formally restore distributions rights once the only remaining compliance issue is "you lost copyright permission due to GPLv2 4". Therefore, the heated debates, which have raged between Jaeger and almost everyone else in the copyleft community for nearly a decade, regard an almost moot and wholly esoteric legal detail. ↩ ↩²
For example, the argument has been made that there may be a failure of consideration on the part of the contributor. While Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) is accepted as holding that there is consideration received by the contributor in a FOSS license, the posture of the case was one where the contributor advocated for the theory, not against it. The author is not aware of any other decisions that have analyzed the question in any depth, so it perhaps could be challenged in the right factual situation. ↩ ↩²
A contract without a definable duration can be terminated on reasonable notice. Great W. Distillery Prod. v. John A. ↩ ↩²
Kajima/Ray Wilson v. Los Angeles Cty. Metro. Transp. Auth., 23 Cal. 4th 305, 310, 1 P.3d 63, 66 (2000), citing Restatement (Second) of Contracts *§*90(1) (1979). ↩ ↩²
One of the authors of this tutorial, Bradley M. Kuhn, has often suggested the aesthetically preferable compromise of a specifically designed "small caps" font, such as this one, as an alternative to WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS), since the latter adds more ugliness than conspicuousness. Kuhn once engaged in reversion war with a lawyer who disagreed, but that lawyer never answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE CONSPICUOUS Than this is. ↩ ↩²
Scholars continue to debate to what extent CISG applies to software licenses. For example, Diedrich concluded that "CISG is prima facie applicable to international transactions involving the transfer of computer software for a price", but Sono disagrees with this "prevailing view", presenting an "analysis [that] restricts the applicability of the CISG to software transactions by excluding 'license contracts"'. (See Frank Diedrich, The CISG and Computer Software Revisited , 6 Vindobona Journal of International Commercial Law and Arbitration, Supplement 55--75 (2002), and Hiroo Sono, The Applicability and Non-Applicability of the CISG to Software Transactions, Camilla B. Andersen & Ulrich G. Schroeter eds., Sharing International Commercial Law across National Boundaries: Festschrift for Albert H. Kritzer on the Occasion of his Eightieth Birthday, Wildy, Simmonds & Hill Publishing (2008) 512--526.) ↩ ↩²
See Section 1.2.4 of this tutorial for a brief discussion about non-USA copyright systems. ↩ ↩²
Ironically, most criticism of USA-specific legal terminology in GPLv2’s “work based on the Program” definition historically came not primarily from readers outside the USA, but from those within it. The FSF noted in that it did not generally agree with these views, and expressed puzzlement by the energy with which they were expressed, given the existence of many other, more difficult legal issues implicated by the GPL. Nevertheless, the FSF argued that it made sense to eliminate usage of local copyright terminology to good effect. ↩ ↩²
Note that the preferred term for those who work regularly with both GPLv2 and GPLv3 is “Complete Corresponding Source”, abbreviated to “CCS”. Admittedly, the word “complete” no longer appears in GPLv3 (which uses the word “all” instead). However, both GPLv2 and the early drafts of GPLv3 itself used the word “complete”, and early GPLv3 drafts even called this defined term “Complete Corresponding Source”. Meanwhile, use of the acronym “CCS” (sometimes, “C&CS”) was so widespread among GPL enforcers that its use continues even though GPLv3-focused experts tend to say just the defined term of “Corresponding Source”. ↩ ↩²
See § 1.1.1 of this tutorial for the details on “the freedom to run”. ↩ ↩²
These sections of the USC are often referred to as the “Digital Millennium Copyright Act”, or “DMCA”, as that was the name of the bill that so-modified these sections of the USC. ↩ ↩²
Magnuson-Moss 消费品定义本身在美国和加拿大具有影响力，已被多个州和省的消费者保护法采纳。 ↩
然而，FSF 非常清楚，纳入此类法律解释绝不是为了作为美国法律对 GPLv3 的一般选择。 ↩
16 CFR § 700.1(a); McFadden v. Dryvit Systems, Inc., 54 UCC Rep. Serv.2d 934 (D. Ore. 2004). ↩ ↩²
16 CFR § 700.1(a). Numerous court decisions interpreting Magnuson-Moss are in accord; see, e.g., Stroebner Motors, Inc. v. Automobili Lamborghini S.p.A., 459 F. Supp.2d 1028, 1033 (D. Hawaii 2006). ↩ ↩²
Tandy Corp. v. Marymac Industries, Inc., 213 U.S.P.Q. 702 (S.D. Tex. 1981). In this case, the court concluded that TRS-80 microcomputers were consumer products, where such computers were designed and advertised for a variety of users, including small businesses and schools, and had only recently been promoted for use in the home. ↩ ↩²
Building materials that are purchased directly by a consumer from a retailer, for improving or modifying an existing dwelling, are consumer products under Magnuson-Moss, but building materials that are integral component parts of the structure of a dwelling at the time that the consumer buys the dwelling are not consumer products. 16 C.F.R. 700.1(c)--(f); Federal Trade Commission, Final Action Concerning Review of Interpretations of Magnuson-Moss Warranty Act, 64 Fed. Reg. 19,700 (April 22, 1999); see also, e.g., McFadden, 54 U.C.C. Rep. Serv.2d at 934. ↩ ↩²
Theoretically, a user could collect copyright assignment from all known contributors and then do this, but this would indeed be the pathological case. 7(e): This provision clarifies that refusal to grant trademark rights for a GPLv3'd covered work remains compatible with GPLv3. Again, some non-copyleft permissive licenses include such clauses. ↩ ↩²
Footnote 3 also applies here in discussion of GPLv3 just as it did in discussion of GPLv2. ↩ ↩²
An implied patent license from the distributor, however, often arises. See [6]in this tutorial ↩ ↩²
Cf., e.g., Apache License, version 2.0, section 1; Eclipse Public License, version 1.0, section 1; Mozilla Public License, version 1.1, section 1.1. ↩ ↩²
This issue is typically handled in other software freedom licenses having patent licensing provisions by use of the unhelpful term "licensable," which is either left undefined or is given an ambiguous definition. ↩ ↩²
GPLv3 also provides an example in section 12 that makes this point clear. ↩ ↩²
　However, “the work” should not be understood to be restricted to a particular mechanical affixation of, or medium for　distributing, a program, where the same program might be provided in other forms or in other ways that may be captured by　other patent claims held by the contributor． ↩ ↩²
The latter option, if chosen, must be done "in a manner consistent with the requirements of this License"; for example, it is unavailable if extension of the patent license would result in a violation of GPLv3 *§*12. ↩ ↩²
Entities typically hold exclusive relicensing rights either by writing all the software under their own copyrights, collect- ing copyright assignments from all contributors, or by otherwise demanding unconditional relicensing permissions from all contributors via some legal agreement ↩ ↩²
One example is the public outcry over NeXT's attempt to make the Objective-C front-end to GCC proprietary. RMS, in fact, handled this enforcement action personally and the Objective-C front-end is still part of upstream GCC today. ↩ ↩²
“Compliance industry” refers to third-party for-profit companies that market proprietary software tools and/or consulting services that purport to aid businesses with their Free Software license compliance obligations, such as those found in GPL and other copyleft licenses. This tutorial leaves the term in quotes throughout, primarily to communicate the skepticism most of this tutorial’s authors feel regarding the mere existence of this industry. Not only do copyleft advocates object on principle to proprietary software tools in general, and to their ironic use specifically to comply with copyleft, but also to the “compliance industry” vendors’ marketing messaging, which some copyleft advocates claim as a cause in the risk misassessments discussed herein. Bradley M. Kuhn, specifically, regularly uses the term “compliance industrial complex” to analogize the types of problems in this industry to those warned against in the phrase of origin. ↩ ↩²
This document addresses compliance with GPLv2, GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common errors differs little for compliance with these four licenses. [18.1] discusses the key differences between GPL and LGPL compliance. ↩ ↩²
This tutorial in fact also addresses the issue at length in § [14.1.] ↩ ↩²
However, these programs do often combine with LGPL'd libraries. This is discussed in detail in [18.1.] ↩ ↩²
Note that this chapter refers heavily to specific provisions and language in [GPLv2 3] and [GPLv3 6.] It may be helpful to review 5.2 and 9.9 first, and then have a copy of each license open while reading this section. ↩ ↩²
At least one COGEO recommends the Yocto Project, since its engineers have designed such features into it build process. ↩ ↩²
These sections cannot be fully understood in isolation; read the entire license thoroughly before focusing on any particular provision. However, once you have read and understood the entire license, look to these sections to guide compliance for binary distributions. ↩ ↩²
"Linux" refers only to the kernel, not the larger system as a whole. ↩ ↩²
Realizing of course that user very well may not be your own customer. ↩ ↩²
This applies to all programs licensed to you under only GPLv2 ("GPLv2-only"). However, most so-called GPLv2 programs are actually distributed with permission to redistribute under GPLv2 or any later version of the GPL ("GPLv2-or-later"). In the latter cases, the redistributor can choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the v2 termination provision will always apply. If the redistributor has chosen v3, the v3 termination provision will always apply. If the redistributor has chosen GPLv2-or-later, then the redistributor may want to narrow to GPLv3-only upon violation, to take advantage of the termination provisions in v3. ↩ ↩²
Consider that the iPhone, a device designed primarily to restrict users' freedom to modify it, was unlocked and modified within 48 hours of its release. ↩ ↩² ↩³
A popular t-shirt in the software freedom community reads: "I void warranties.". Our community is well-known for modifying products with full knowledge of the consequences. GPLv3's "Installation Instructions" section merely confirms that reality, and makes sure GPL rights can be fully exercised, even if users exercise those rights at their own peril. ↩
The “dpkg” command is a Debian-specific way of finding installed packages. ↩ ↩²
Build times will likely vary widely on various host systems. ↩ ↩²
For lack of a better phrase. ↩ ↩²

开源办公室演进

2023年3月21日 · 阅读需 99 分钟

赵振华

孙振华

基于彭博社、康卡斯特和保时捷的开源办公室成熟度模型特征

2022年2月

Chris Aniszczyk, Linux 基金会 CTO，TODO Group联合创始人

前言：Linux 基金会执行董事 Jim Zemlin

前言

虽然开源软件 (Open Source Software， OSS)随着开发人员自下而上的快速采用而有机地出现，但随着时间的推移，使用开源软件的企业意识到他们需要创建治理结构和"护城河"，以确保合规地使用这种新兴的范式转换技术。开源软件在加速技术创新方面如此强大、对开发人员和"解决问题"的工程师如此有吸引力的元素——透明、快速迭代、协作创新——是法律团队经常关注的特征，也与传统技术开发战略背道而驰。

人们很快就清楚地认识到，开源不仅是一个可行的选择，而且是技术创新的关键途径。企业意识到他们需要适应这种新的创新方式，否则就有落后的风险。在这种背景下，最初的组织工作重点是确保开发人员遵守开源许可证并维护一份可用的开源软件清单。在技术性组织中，开源估值是企业文化不可分割的一部分，并且经常嵌入到产品中；话题通常远远超出许可证合规性，而是探索这些公司如何利用开源社区来加速和改进产品开发，同时保持商业优势。从这两个维度上看，开源办公室 (OSPO) 的种子已经萌发、成长为促进合规地使用开源软件的正规程序。随着时间的推移，在新成立的OSPO的大力支持下，我们见证了更多的开源项目的采用、贡献和社区范围内的参与。

TODO小组的存在是为了促进开源软件使用和社区建设方面的最佳实践。这越来越意味着授权企业和组织创建有效的 OSPO 计划。我们发布了许多广受好评的关于如何构建 OSPO计划的指南和工具包。本报告旨在提供一个更广泛的框架，以了解 OSPO 的原型以及我们在与数千家企业和组织合作时所看到的成熟阶段，因为他们已经完成了开源之旅。我们还想捕捉一些真实的 "用户旅程" ，用真实的人的真实声音讲述他们的真实体验。我们希望他们的见解能让现有和潜在的 OSPO 领导者了解促进开源的细微差别。这项工作为这些旅程提供了指导和路线图，因为 OSPO 的概念和结构随着开源运动而不断发展。

Jim Zemlin

Linux 基金会执行董事

Info Graph


OSPO 的采用率在科技行业中仍然最高，但在公共部门和教育机构正强劲增长	那些认为OSPO对工程或产品团队的成功非常或极其关键的人在去年从54%上升到63%	OSPO 的专业化仍在继续，58% 的 OSPO 正在正式组建，高于此前的 54%
51% 的人表示，本财年他们的开源计划很有可能或有可能增加资金	77% 的受访者表示他们的开源项目对其公司的软件实践产生了积极影响	63%计划创建OSPO的受访者预计将在一年内启动该流程
35% 的 OSPO 位于软件工程和开发部门，另外 18% 位于 CTO 办公室内	已建立的OSPO突显了在改进代码质量和利用CI/CD管道方面的示例	组织从 OSPO 中受益的主要领域是对“开源使用和商业依赖”和“增加创新”有了更多认识

总结

在我们对开源实践的第四次 TODO小组调查中，我们发现 OSPO 正朝着拥有更多专用资金和资源的更专业的组织发展。这种演变符合大小组织中开源软件和开发实践持续增长和接受的持续主题。为了更深入地了解 OSPO 的演变，我们采访了著名 OSPO 项目的领导者，包括一些最具影响力的技术公司，如红帽、微软和 VMware，以及一些最具标志性的汽车品牌和最大的媒体和娱乐公司之一。我们询问了他们的计划是如何开始的以及它们是如何演变的。基于这些访谈和调查数据，我们制定了一个五阶段的 OSPO 成熟度模型，从 (1) 临时使用开源软件到 (2) 解决合规性和许可问题到 (3) 鼓励参与到 (4) 贡献代码，以及最后，到 (5) 孵化开源有意义的项目。在本报告中，我们详细介绍了每个阶段，并开发了一些 OSPO 组织的原型。作为该过程的一部分，我们对三个不同行业（媒体、金融服务和汽车）中三个 OSPO 的演变进行了三个案例研究，每个案例都构建为 OSPO 各个阶段的旅程。在 OSPO 运动二十多年后，OSPO 的作用已发展成为专业知识的核心来源，并在全球具有前瞻性思维的公司制定和实施技术战略方面发出强有力的声音。

介绍

OSPO 的兴起大致反映了开源软件在当今世界组织内构建和运行最重要的技术应用程序的扩张。精心设计的 OSPO是组织开源运营和结构的能力中心。它的角色可以包括设置代码使用、分发、选择、审计和其他政策，以及培训开发人员、确保法律合规以及促进和建立有利于组织战略的社区参与。 OSPO 的概念大约有 20 年的历史，但在过去十年左右才真正开始加速。大多数著名的技术基础设施公司（例如亚马逊、VMware、思科）和消费技术公司（例如Apple、Google、Facebook 和 Twitter）都有 OSPO 或正式的开源规划。所有人都在鼓励他们的员工为对其业务和安全具有战略意义的开源项目做出贡献。

OSPO 在早期最初专注于许可证合规性，如今在组织内部经常发挥更广泛的作用。 OSPO通过促进最佳开源软件实践和参与开源软件社区来提高开发人员的效率，从而对开发人员和其他员工进行有关开源软件的教育。随着时间的推移，OSPO 已经从参与现有开源项目发展为在更广大的社区内创建和启动项目。高层管理人员更有可能承认开源技术在加速创新和在多个受益者之间分摊软件开发成本方面发挥的关键作用。 OSPO的任务在关键方面取得了进展，包括：

创建内部框架和工具以有效和高效地使用开源项目代码
就组织应如何指导员工参与开源以及支持哪些项目提供战略和战术指导
评估开源项目，并就将项目纳入组织的长期技术计划的风险和回报提供战略指导，重点关注开发人员的经验和效率

随着这种趋势的发展，人们更加依赖开源软件并开发测量指标来衡量 OSPO对组织的影响、每个组织对开源项目的影响，以及由 OSPO 及其上级组织创建和维护的项目的总体健康状况。 OSPO 的形成类似于组织首次开始建立 CISO 作为对安全事件的反应。建立这些安全能力中心的组织保护并武装自己，以创造更美好的未来。而那些没有经历、安全实践不佳的组织遭受了财务上的影响。

简而言之，随着时间的推移，OSPO 所关注的内容已经与他们的新角色相匹配。本报告的目的有两个：介绍最新的年度 OSPO 调查的主要发现，并通过与领先的从业者和专家的访谈为这些结果提供参考。我们在由 Linux 基金会主办的组织 TODO小组的主持下进行了调查和采访。 TODO 是一个开放的组织团体，他们在实践、工具和其他方式上进行协作，以执行成功和有效的开源项目和计划。

调查方法和受访者构成

从 2021 年 6 月 10 日到 6 月 29 日，TODO 小组与 Linux Foundation Research 和 New Stack 合作进行了这项调查，以更好地了解 OSPO 的形成、运作和演变。这是 TODO小组连续第四年进行这项调查。我们通过社交媒体和直接电子邮件向 Linux 基金会、TODO小组和New Stack订阅者列表征集受访者。最终数据集包括来自 1,141 名调查参与者的回复。我们从至少有两名员工的 932 个组织中得出结论。受访者的构成与往年略有不同，更多人将自己描述为"个体经营者"或"不工作"。在 2021 年的调查中，与往年相比，为科技公司工作的受访者减少了。受访者来自各行各业，包括教育、电信、媒体、金融服务、政府、交通和汽车、医疗保健和零售。按行业划分的受访者百分比增幅最大的是政府、教育和零售业。

图1 OSPO普及率：各行业于2018-2021年

资料来源： 2021年OSPO调查

图内文字翻译
技术（软件或 IT）
其他
教育
电信、通信或媒体
金融服务
政府
交通和汽车
卫生保健
零售
制造和原材料
国防
公用设施
保险

主要调查发现

随着 OSPO 调查的受访者数量在 2021 年显着增加，调查受访者的构成发生了变化，以反映整体经济，而不仅仅是技术（尽管回复仍然以技术为主）。与 2019 年相比，对 OSPO 角色、优先级和价值观的看法出现了一些趋势。尽管所有组织规模的组织中，拥有 OSPO 计划的组织的响应百分比都有所下降，但在大型组织中下降幅度最小。这种下降可能反映了调查构成的变化：它包括教育和政府等行业，这些行业的开源项目还处于起步阶段。这种下降也可能与 COVID-19 带来的经济和人员配置挑战有关。

即便如此，OSPO 运动仍有发展空间。显然，OSPO 倡导者必须更有效地传达专门创建 OSPO 和使用开源软件以及更广泛地为开源社区做出贡献的价值。调查显示，组织使用的开源软件多于他们对开源项目的贡献，而做出回应的组织并不完全了解 OSPO：

19% 的受访者表示他们从未听说过 OSPO。
28% 的受访者表示他们认为 OSPO 没有商业价值。
35% 的没有 OSPO 的组织表示他们没有考虑开设 OSPO。

该调查还揭示了充满希望的信号。与去年相比，受访者认为，由于宏观经济状况，本财年为其公司的开源计划提供的资金将增加的可能性是去年的两倍。为此，51% 的人表示很有可能或可能增加资金。调查数据显示，从 54% 增加到 63% 的受访者表示 OSPO 对其工程或产品团队的成功非常或极其重要。 OSPO 也通过正式的组织架构变得更加专业。 2021 年的调查发现，58% 的 OSPO 是正式的，高于 2020 年的 54%。在调查的开放式部分中，受访者强调了 OSPO 的许多有价值的好处，例如提高代码质量、更好地利用开源软件工具（如持续集成） /持续交付（CI/CD），以及外部协作（开源）和内部协作（内部开源）之间的积极联系。

OSPO 的主要职责发生了一些变化。维持开源许可证合规审查和监督的调查参与者从 68% 下降到 59%，认为这是一项主要责任。对于大型非科技公司，合规仍然是最常被提及的主要责任，占 86%。将与开发者社区互动作为主要责任的比例从 48% 上升到 56%。在与生态系统参与和宣传相关的几个积极指标中，对开发人员关系和参与的重视将内部开源项目的外部贡献从 38% 增加到 47%。

五阶段 OSPO 成熟度模型

随着 OSPO 的激增并变得越来越普遍，OSPS已经成熟。通过将与 OSPO 领导者和专家的对话反映到 OSPO 调查结果，我们开发了一个 OSPO 成熟度模型来描述 OSPO 的典型演变。该模型是通用的：组织的规模和类型会影响 OSPO 的成熟度。在较大的组织中，多个业务部门可能会开发不同的开源方法，每个方法都有不同的技术文化；而纯数字技术公司更有可能更早地使用开源软件并为之做出贡献，并且更容易接触到开源技术和概念。

考虑一下企业基础架构软件提供商 VMware。它的工程师与网络、云和其他关键领域的许多开源社区合作并为之做出贡献，仅仅是因为他们知道，使用开源进行构建可以为社区和 VMware 的客户带来更好的结果和更高的互操作性。相比之下，红帽是第一家上市的开源公司。它在开源软件上建立了整个业务实践，压缩了成熟度生命周期，实际上，使整个公司成为了一个 OSPO。如今，红帽将更多资源用于早期生命周期活动，例如教育内部利益相关者（例如，销售团队、营销人员、新工程员工）和促进上游社区的协作。对于我们研究中的大多数其他公司，成熟度模型的一般阶段在消费、贡献、协作和参与以及领导力方面密切地映射了组织的开源软件轨迹。我们访谈的一些组织还设定参与和使用开源项目的指标。

这些指标可能包括开源软件项目中的工程参与率（拉取请求、评论、提交）、开源活动的出席和参与、撰写的博客文章、发表的演讲以及利用业余时间参与开源项目等等。更高级的开源组织可能有关于项目成功增长的指标，这些项目由他们自己的工程团队发起或部分创建。一些领先的组织，例如康卡斯特、VMware 和 Red Hat，已经构建或正在构建高级度量和测量工具。

也就是说，即使是这些设置精准跟踪指标的组织也不会明确使用指标来跟踪或设置开源软件目标。以微软为例，该组织曾经几乎完全专注于专有软件，但现在已成为开源项目的主要支持者，并在其自己的产品中广泛使用开源软件。 "我们专注于让我们的开发人员更容易使用 [开源软件]，我们鼓励他们回馈他们所依赖的项目。我们跟踪整体参与情况，但OSPS确实在个人或团队层面设定了目标，" 微软 OSPO 前负责人 Stormy Peters 说。 "我们的开发人员可以自愿将他们的公司 ID 与他们的 GitHub 登录名关联起来，这使我们能够衡量公司层面的参与度。"¹大多数情况下，指标的系统收集和分析发生在采用的后期阶段，此时开源软件成为企业和大型组织的技术路线图和战略的关键要素，同时伴随着 OSPO 计划、预算、和工作人员。

图2 OSPO 的四个阶段

来源：TODO 小组


高			领导成为战略决策伙伴	第 4 阶段
			积极参与主办 OSS 项目与发展社区	第 3 阶段
执行能力		社区教育宣传 OSS 使用和生态系统参与		第 2 阶段
	法律教育提供 OSS 合规性、清单、开发人员教育			第 1 阶段
低	采用临时采用OS			第 0 阶段
	无	低	OSPO 水平	高

阶段 0：临时使用开源软件

今天，几乎所有的组织都使用开源软件。他们采用和最初使用它的方式各不相同。他们可能将开源软件用作产品或工具中的构建模块或库，或供应商产品堆栈的关键部分或支持供应商的服务产品。开发人员可以将开源软件用于快速原型设计或微服务和小型应用程序。开发人员还经常采用开源软件开发工具，例如集成开发环境 (IDE)，或构建在开源之上的工具，例如 GitHub 和 GitLab。现代云原生应用程序几乎默认使用开源系统进行容器编排、可观察性、数据存储、消息传递等。在应用程序的前端，开发人员严重依赖开源库和框架。 Red Hat 报告称，" 90% 的 IT 领导者都在使用企业开源。 " Synopsys 等软件组成分析供应商确定超过 75% 的代码库包含开源组件。²

换句话说，几乎每个组织都在使用开源软件。然而，最早的采用形式是临时的，开发人员使用现成的工具和技术解决问题。这种"临时采用"通常意味着很少考虑默认情况下的许可合规性或使用开源和分发使用开源组件构建的产品的长期影响。在大多数情况下，一些工程师正在积极寻找开源，而工程组织的其他成员可能会巧合地使用开源，但并不认为其活动依赖于开源。因此，组织既没有专注于开源的集中团队，也没有顶级开源战略。这些至关重要，因为一旦采用这些开源组件，默认情况下，这些组件就会成为组织软件供应链的一部分，这使得战略方法变得更加必要。

阶段1：提供开源软件合规性、清单和开发人员教育

一般来说，当一个组织意识到几乎所有来自工程、开发部门和职能部门的人员都在使用开源产品和代码时，就会形成一个 OSPO。这种使用通常是内部的，而不是客户或用户的产品或服务的一部分。实际上，任何拥有大量 IT 功能和先进的在线或以应用程序为中心的组织都使用开源，因为开源在整个技术堆栈中无处不在--从 Linux 服务器和 MySQL 数据库到 Node.js 和 Python 等编程语言以及 React 和 Vue.js 等前端框架。

在这个早期阶段，组织经常为 OSPO 使用许多不同的名称。例如， IBM 最初将其程序化开源工作称为"开源指导委员会" 。然而，在所有情况下，处于阶段1的组织都认识到开源软件是其业务和技术战略的关键部分。他们了解开源软件项目的安全实践与专有软件公司的不同。例如，开源软件项目的披露规则往往比专有项目的披露规则更严格。因此，他们必须识别其法律和安全风险。风险缓解策略包括谨慎的许可、开发人员教育和严格的盘点。

管理法律风险和许可

组织的法律团队或技术领导者倾向于推进OSPO 的阶段1开发，以确保其员工（以及承包商、供应商等）都根据其许可条款使用开源软件，并且使用开源软件不会使其面临法律风险。可以使用的开源软件许可证有几十个。在 2020 年的调查中，受访者将合规列为大公司 OSPO 的最大优势，而合规仍然是中型公司的第二大优势。 "公司一开始通常会很困惑。没有针对许可证合规性的政策，开发人员会做他们认为正确的事情，" 弗里德里希-亚历山大大学埃尔兰根-纽伦堡开源软件教授 Dirk Riehle 说：

我曾经走进一家公司，一位开发者说：我们没有开源政策。另一个打趣道：我们有，而且是：没有开源。第三个皱着眉头评论道："你在说什么？一段时间以来，我们一直在为开源项目做出贡献。" 这并不罕见。他们最终将建立一个开源办公室，负责处理开源的使用和贡献。³

虽然开源软件用户一直考虑合法合规，但一些开源软件贡献者设计了新的许可证，以阻止大型云服务商创建基于开源项目的专有服务。其中最突出的是Affero通用公共许可证 ( AGPL)。公司可能会使用根据本许可条款发布的开源软件向其客户提供专有软件即服务 (SaaS)，但如果 AGPL 条款确实违反了许可，则开源软件的作者可能有理由起诉该公司没有明确区分内部和外部交付。许多企业的部门间也有内部财务收费系统，进一步模糊了付费服务和内部服务之间的界限。

教育开发者

为了保持合规性，处于 OSPO 成熟阶段 1 的组织创建了教育计划，以帮助其开发人员决定何时使用开源软件来创建新产品或服务。 "许多没有接受过开源教育的开发人员认为，因为他们没有购买软件，所以没有涉及许可，因为他们没有签署合同，" VMware 开源营销和战略总监Suzanne Ambiel说。 "开源软件可能是免费的——就像无价之宝一样——如果以不合规的方式使用，它也可能代价高昂。 开源软件总是带有许可证。任何 OSPO 最重要的角色之一是确保开发人员了解不同许可选择的含义。"⁴

通过开发人员教育，高级管理人员通常认可开源软件的价值和重要性。在此类程序中，开发人员学习：

不同许可证类型的细微差别
引入新的开源软件产品的正式批准流程
不合规地消费开源软件的真正风险，包括在没有正式许可的情况下使用项目中的产品或代码
使用贡献者许可协议 (CLA) 来涵盖组织为开源做出贡献的开发人员

有时组织会在此阶段引入正式的 CLA 政策。它还可以为判断开源软件项目的健康状况提供指导，作为其决定在组织的技术堆栈或基础设施中使用哪个开源软件的标准的一部分。

清点软件清单

开发人员可能随机性地部署开源软件而不是系统地对他们的工作进行分类。法律团队和技术领导倾向于推动组织中使用的所有开源软件的清单。这样的清单将组织代码存储库（例如 GitHub、GitLab）和系统中的开源软件逐项列出。阶段1的组织设置特定的软件清单流程以创建组织范围的软件材料清单 (SBOM)。借助此清单，法律团队（通常与 OSPO 团队合作）可以持续监控开源软件的使用情况并标记法律、安全或其他项目风险。通过详细的 SBOM，首席技术官 (CTO) 或首席信息官 (CIO) 等技术领导可以识别并密切监控最关键的业务用途并保护组织安全。

阶段2 ：鼓励使用开源软件和生态系统参与

在组织认识到开源软件的价值以及对合规性、教育和 SBOM 的需求之后，他们开始意识到使用开源软件的经济利益并寻求扩展它。阶段2的 OSPO 创建了诸如推广使用经批准的开源软件产品的大使等内部机制，关于良好开源软件"卫生"的教育计划，以及用于开源软件技能建设和认证的技术培训或学费报销。通过这些举措，组织可以扩大其对开源软件的使用并扩大其信息，即开源软件不仅重要，而且比专有软件产品更可取和更可获取专利。

员工教育包括制定与开源软件项目交互的最佳实践，例如如何请求功能、提交错误报告和贡献基本代码。在此阶段，该组织加强了其协作能力，并体验了开源软件项目和社区的社交生活。在这一点上，OSPO 向员工和经理传达了为开源软件做出贡献而不仅仅是使用开源软件的重要性。这种外展活动包括倡导和推动活动赞助、在公共编码论坛中预定项目负责人和维护者作为演讲者或小组成员，以及为关键任务开源软件项目确保组织资源（例如人才、资金）。

对于组织而言，积极和可见的参与会产生多种好处：更好的知名度、更好的声誉、更有吸引力的雇主。为此，许多非技术组织在著名的开源软件活动上购买展位，以与这些社区进行更多互动，并招募喜欢在开源软件生态系统中工作的开发人员。活跃于开源领域的技术公司可能会将教育计划扩展到希望与开源软件社区和供应商互动的客户。 Red Hat 开源高级总监 Deborah Bryant 说： "我们从客户那里收到了很多请求，他们要求帮助和指导如何参与开源，或者如何为项目做出贡献或与我们合作。"⁵

随着他们进入阶段2，组织开始鼓励他们的开发人员从事对其运营至关重要的开源软件项目，以使开发人员成为高度活跃的贡献者或主要维护者。对于技术组织来说，为一个著名的开源软件项目聘请贡献者是一项有价值的投资：他们的大多数贡献者，例如，Linux 内核（Linux 操作系统的核心组件和计算机硬件和软件之间的关键接口）都是全职员工 (Full Time Employee，FTE)，他们的工作是为 Linux 编写代码。

在技术部门之外，更少的组织可以分配开源工作的全职员工，但他们正在这样做。例如，康卡斯特和 Bloomberg 的员工全职从事开源软件项目。在生命周期的这个阶段，OSPO 开始探索如何简化开发人员使用开源软件的流程。这种开发人员效率可能包括简化 CLA、将具有可接受许可证类型的开源软件添加到票务系统以便快速批准、促进开源软件架构和现有软件的重用（内部采购的一种变体）以及标准化库选择和开源开发工具，从而融合 OSPO 和平台运营职责。

在这个阶段，组织向 OSPO 寻求有关如何积极参与开放生态系统的指导。 Futurewei Technologies的OSPO负责人Chris Xie说： "你必须确保回馈与获得的一样多。你不希望人们认为你只是在通过开源获利而不回馈社区。" "我们强烈考虑到这一点——比以往任何时候都更加强烈。"⁶ 电信等受监管行业的公司还必须了解其国家出口法律并驾驭政治紧张局势，以保护开源软件社区并避开国际纠葛。⁷ "我们始终希望确保我们的贡献真正开放，造福社区，造福整个行业，" Xie谢解释道。

通常在 OSPO 成熟度周期的阶段2（也可能在阶段1，如果公司是软件或核心技术公司），OSPO 开始为其开发人员简化和优化源代码贡献流程。在早期，请求和获得对外参与批准的过程通常是临时的和痛苦的。 SAP OSPO 的首席架构师Michael Picht说： "我们在建立 OSPO 时首先考虑的是捐款流程。" "使用 Word、Excel 和电子邮件，这个过程根本没有自动化。当我们打开 OSPO 时，我们做的第一件事就是简化流程并实施端到端工具支持。我们将 GitHub 问题用于不同的流程步骤。"⁸

阶段3：托管开源软件项目和发展社区

在阶段3，组织发起开源软件项目并随后托管（host）项目或作为该项目赞助商。他们将指定一名或多名全职员工参与一个项目，他们承担培育开源社区，并确保其健康。在这个级别上，他们不会混淆组织的承诺与个别员工决定开源他们自己的项目的承诺。在阶段3，组织领导者支持孵化和启动公共领域的开源项目，因为他们了解这些项目是如何使他们的组织受益。这样的项目往往不能为其提供更好的可能对组织的非核心能力的关键能力的绩效和经济性价值主张，但对其至关重要技术基础设施。

此外，创建和启动开源项目的组织在开源社区中建立了广泛的信誉；从事开源技术的可能性对许多开发人员来说很有吸引力。我们采访过的大多数 OSPO 都将招聘新的工程人才和留住现有人才作为开源工作的关键动力。在Linux Foundation Research最近对金融服务行业的一项研究中，53% 的贡献者表示他们为开源软件做出贡献是因为"它很有趣"。

用全职员工和资金支持项目是开源游戏的真正皮肤。跨越这一门槛并成功启动多个开源项目的组织开发了内部资源和流程，可以孵化并确保这些项目在启动后的成功。 OSPO 不仅仅是项目形成和启动的守门人和导师；他们教育项目创建者培养健康的开源生态系统的要求，并指导项目负责人，让他们为开源软件项目所需的更公开的领导角色做好准备。

随着开源软件组织的成熟，其 OSPO 会开发内部流程、手册、检查清单、工具和其他机制来审查、组织和运营开源项目，并为他们的领导者做好准备和指导。一些 OSPO 更喜欢在协助下启动项目，主要与开源基金会或合作组织（例如 TODO小组）的合作，以增强能力或提供基础设施、战术援助和其他资源。这种偏好的资源密集度较低，但会将项目的控制权交给更广泛的社区。

阶段4：成为战略决策合作伙伴

在这个成熟阶段，OSPO 成为战略合作伙伴技术决策，帮助指导选择和塑造长期对项目的承诺。在阶段4，CTO 和其他技术领导者咨询 OSPO 及其领导层依赖的开源技术和决策标准用于判断开源项目。因为主要的开源技术选择往往会产生显着的二次和三级成本并影响上下游技术以及招聘计划、开源项目的选择成为一项重大的商业决策。从广义上讲，在阶段4OSPO 提供三种类型的战略指导。首先，OSPO 为 CTO 和技术领导提供建议采用或删除哪些开源技术来自组织的技术栈。鉴于当今有许多开源软件可供选择--大多数主要类别的软件具有数十种选择，如图 3 所示 --- OSPO 可以提供对开源软件趋势的洞察，例如不同的流行趋势不同 NoSQL 的语言、API 设计或功能数据库。在这个角色中，OSPO 成为一种内部技术CTO 顾问和开源软件内部专家。在第二种类型的战略指导中，OSPO 带头对什么构成可接受的开源软件项目进行基准测试。这OSPO 经常评估项目，尤其是限制使用的许可证类型的更改，或项目路线图的突然变化，以确定是否项目经理牢记社区的最大利益。大多数 OSPO 依赖粗略的指标来评估项目行为，例如：

它的行为准则是什么，违反它的后果是什么？
它的治理结构是什么，这种结构是否确保独立性？
响应拉取请求或错误文件需要多长时间？
项目多久发布一次新版本？
是由一方（公司或组织）还是整个社区控制项目？
该项目有多少贡献者？随着时间的推移，这个数字是如何变化的？

第三种指导是帮助组织了解并驾驭项目政治，例如保持中立当多个意见领袖试图引导的项目，或阐明潜在的政治考虑的社区成员。在更高的层面上，OSPO 可以提供帮助公司对技术民主保持中立态度并通过培养个人和跨越国界的工作关系和政治领域。越来越多地，这种价值延伸到基金会和非营利组织，因为这些领域变得重要开源中的中性空间。根据 Red Hat 的 Deborah Bryant 的说法，她的 OSPO 不得不承担开源基金会的管理工作，例如作为赞助商和委派员工担任领导角色。 "我们发现我们需要花更多的时间关于我们参与的一些中央管理和行政在软件基础中，以确保我们得到我们的投资回报并重新评估我们的参与有规律的节奏，" 她说。⁹

在这个职位上，OSPO 拥有数百万美元的基金会预算，参与开源软件生态系统的战略重要性形成和增长与基金会的货币投资平行和非营利组织。在这个阶段，我们往往会看到快速OSPO 的增长。根据 VMware 的 Ambiel 的说法：

OSPO 今天的主要目标之一是帮助最佳实践在指导以及如何成为一个优秀的开源公民。什么时候你在开源社区，你正在参与开放——每个人都可以看到你在做什么。这一点很重要一个组织尽其所能。 OSPO 帮助人们做始终如一地自信地在会议上发言或贡献一个小图书馆参与一个大项目社区，例如 Kubernetes¹⁰.

图 3 云原生全景图

来源：云原生计算基金会，2022 年 2 月 22 日访问。


应用定义和开发层	数据库	流和消息传递	应用程序定义和镜像构建	持续集成和持续交付	平台类
编排和管理层	编排和调度	协调和服务发现	远程进程调用	服务代理	API 网关	服务网格
运行时层	云原生存储	容器运行时	云原生网络
自动化和部署工具	容器注册表	安全和合规	密钥管理
认证的K8s	认证的托管 K8s	认证的K8s 安装程序	PaaS / 容器服务
可观察性和分析	监控方案	日志工具	追踪工具	混沌工程

图 4 OSPO 的角色

资料来源：TODO 小组


大型项目推动者		跨行业合作		行业合作
开源优先		技术战略专家		软件公司
		OSPO的角色
员工的任务是促进和培养 OSS 的使用。	该组织针对 OSS 的使用和生产制定了正式的政策。	高管们认识到 OSS 和更广泛的开源是重要的战略资产。	大量员工正在为开源项目贡献代码。	流程、程序和工具已经到位，以简化和促进开源使用和参与。

OSPO 原型

经常出现的一个问题是，各种OSPO原型是什么以及它们有何不同？在一定程度上，任何自称有 OSPO的组织可能表明该组织已达到或者临近某个成熟阶段，OSPO具有共同关键特征：

任务是促进和培养开源软件的使用。
该组织针对开源软件的使用和生产制定了正式的政策。
高管们认识到开源软件和更广泛的开源是重要的战略资产。
大量员工正在为开源项目贡献代码。
流程、程序和工具已经到位，以简化和促进开源消费和参与。

在本文中，我们采访了主要在总部位于北美、欧盟和亚洲的大型企业工作的 OSPO 领导人。由于样本数量有限，我们无法正确观察小型组织、非公司实体和总部位于其他领域的组织的原型（更详细、更细致的原型研究将有利于 OSPO 运动）。根据我们为本文所进行的采访，我们总结了一些推动 OSPO 行为差异化的广泛原型。

行业内协助

这种原型中的 OSPO 将开源视为一个平台，不仅用于一般技术开发，而且还作为其特定行业通过分摊成本和创新以满足特定行业需求的一种方式来提高效率。在欧盟，许多主要汽车公司已经形成了一个松散的 OSPO 协调联盟，该联盟优先考虑汽车的关键开源软件计划，并就这些计划的软件开发进行合作。该联盟还致力于解决非行业特定的开源软件问题，例如创建和维护一组工具以自动化开源软件合规性和验证。

行业合作

描述

将开源视为特定行业通过分摊成本和创新来满足行业特定需求的一种方式

例子

来自欧盟的汽车公司

跨行业协助

具有这种原型的 OSPO 渴望致力于解决跨行业的基础技术问题。这项工作通常采用其他工具的形式，以自动消费和合规开源编程语言和框架（如 JavaScript 和 Node.js）上的开源工作。例如，Bloomberg 与 Microsoft 合作，为 TypeScript（JavaScript 的超集）做出了贡献，并创建了一个更好的工具结构，使 Bloomberg 工程师能够更轻松地回馈代码。

跨行业合作

描述

渴望解决跨行业的基础技术问题。这项工作通常采用其他工具的形式，以自动化开源编程语言和框架上开源工作的使用和合规性

例子

彭博与微软合作为 TypeScript 做出贡献

大项目推动者

这些是罕见的 OSPO，它们在组织内部形成或促进大型、复杂的开源项目的形成，然后将它们作为公开可用的项目启动。此类项目的开销和承诺水平很高。代码的持续发展和社区的发展都需要大量的时间和金钱投资。出于这个原因，大多数 OSPO 并不寻求从其组织中启动大型项目。相反，当一个大项目启动时，公司通常会将其捐赠给基金会来启动。

大型项目推动者

描述

罕见的OSPO，它们在组织内部形成或促进大型、复杂的开源项目的形成，然后将它们作为公开可用的项目启动

例子

康卡斯特孵化了 Apache Traffic Control Project

开源优先

当今许多 OSPO 的一项关键工作是帮助公司及其技术团队优先考虑开源软件使用，并使开源成为任何技术计划的默认首选。这些 OSPO 倾向于与 CTO 和公司战略家密切合作，以绘制开源项目和能力。开源优先， OSPO 敏锐地意识到Copyleft许可和其他限制性开源许可形式的趋势。

开源优先

描述

帮助公司及其技术团队优先考虑 OSS 的使用，并使开源成为任何技术计划的默认首选

示例

OSPO与CTO和公司战略专家密切合作，发现开源项目和能力

技术战略专家

这个 OSPO 原型与开源优先原型密切相关并且经常重叠，在评估可行的开源技术和帮助组织的 CTO 和工程副总裁制定技术路线图方面发挥着关键作用。这种咨询角色通常表明较低级别的类似方法，其中 OSPO 及其成员或大使可以充当内部顾问，以帮助开发人员和团队更好地理解、交互、使用和规划开源技术。

技术战略专家

描述

在评估可行的开源技术和帮助组织的 CTO 和工程副总裁制定技术路线图方面发挥着关键作用。

例子

一个 OSPO，其成员可以充当内部顾问，以帮助开发人员和团队更好地理解、交互、使用和规划开源技术

软件公司

由于这些公司生产支持开源运动核心的相同产品，因此软件公司的 OSPO 往往具有略微不同的特征。在这些公司中，绝大多数开发人员通常都很好地理解和使用开源。这种原型更有可能孵化或参与大型项目，更有可能有专门从事开源工作的专门开发人员。例如，软件和技术公司主导着 Linux 项目的核心开发团队。子原型是技术公司严重依赖开源软件，必须专门设计来满足开源软件社区需求。英特尔和高通等半导体公司符合这一描述。

软件公司

描述

帮助公司及其技术团队优先考虑 OSS 的使用，并使开源成为任何技术计划的默认首选

例子

OSPO 与 CTO 和公司战略专家密切合作以发现开源项目和能力

随着我们对 OSPO 及其支持的组织的活动进行更多研究，此原型列表将不断发展。同样具有指导意义的是通过访谈和案例研究对 OSPO 的形成、组织和利用进行详细检查。

OSPO 案例研究

表1

公司简介

	康卡斯特	彭博社	保时捷
OSPO成立时间	5年	9年	2年
OSPO全职员工人数	5-10	2	未透露
孵化的项目	Apache Traffic Control, Trickster, Kuberhealthy	KServe, bqplot, PowerfulSeal	Porsche Design System, OSS， Review Toolkit, Cookie Consent
Banner
监控指标	详细	更喜欢整体方法	一些贡献指标和最佳实践
开发者数量	1,000	6,500+	未透露
汇报给	首席技术官	首席技术官	CPO（首席隐私官）
专用开源软件开发人员数量	100s	未透露	10-15

彭博社

跨行业开源

彭博社（Bloomberg）是为世界领先的投资者和金融服务公司提供数据、新闻和分析的供应商。彭博社于 2012 年开始正式与开源社区合作，现在参与的人员包括公司 6,500 多名全球工程人员中的数百人。彭博社经常使用开源软件，并为数十个外部开源项目贡献了大量代码。

在与彭博基础设施需求特别相关的领域，例如索引、机器学习、可视化以及用于中间件和表示层的核心 JavaScript/Node.js 语言，公司的工程师已成为项目负责人和主要负责人。在为彭博平台的核心功能提供支持的Apache Lucene / Solr项目中，一名公司员工是项目管理委员会的成员。彭博孵化并发布了多个开源项目到社区。例如，Bloomberg 的技术人员与其他组织合作创建了独立的开源项目和蓬勃发展的社区，例如KServe项目，以便更容易地使用常见的机器学习软件和在 Kubernetes 上服务的模型。

彭博的 OSPO 之旅

Bloomberg 于 2012 年开始其 OSPO 之旅，当时工程领导层意识到其工程师正在 Bloomberg 内部大规模使用开源。 JavaScript 和 Node.js 社区的早期和杰出贡献者，Bloomberg 的主要员工已经沉浸在开源中。 Bloomberg 的技术领导层也意识到了开源软件的战略和商业价值，并计划将其软件技术堆栈转变为强调开源而不是专有代码。

早在 2012 年，OSPO 运动仍处于起步阶段，而彭博社在大型科技公司之外几乎没有 OSPO 的例子（甚至在科技公司内部也很少有官方的 OSPO）。彭博社前技术社区参与负责人 Kevin P. Fleming 告诉我们， "在我开始在彭博社工作的前一年，工程人员之间一直在与首席技术官办公室讨论如何利用开源软件和云基础设施。他们意识到，'我们不只是想成为 [开源软件] 的消费者；我们想成为合作者。'"¹¹

作为公司 CTO 办公室的第一位 OSPO 员工，Fleming 的任务是从头开始创建一个 OSPO，以帮助这家传统上像许多其他组织一样将所有代码视为必须保护的知识产权的公司解锁开源。"彭博社一直非常孤立和保护一切。我们来自专有软件的世界，" Fleming说。他曾在拥有大量开源项目的小公司担任工程负责人，直至维护和发展整个项目。 "所以我们必须学习如何成为开源社区的成员，并跨越专有代码和开源的界限。"

作为一家具有超前法律思维的组织，彭博社制定了围绕开源合规和消费的政策，但现有政策旨在管理内部消费。它需要的是关于如何积极参与外部开源生态系统的指导和定义。例如，当Fleming来到彭博时，公司工程师没有在技术会议上谈论他们在开源方面的工作。他们有一种默契，即公司不赞成公开讨论内部技术。Fleming解释说：

我的任务与合规无关。这是关于启用的。如果我们要选择这些 [开源软件] 工具来代替供应商提供的工具，我们如何让自己走上成为社区高效成员的道路，而不是成为一个发布和部署它们的组织，但想知道， "当我们需要进行更改或回答问题时，我们将如何获得支持？"¹²

Fleming上任几年后，负责技术活动的人离开了公司，Fleming安排将这一责任移交给 OSPO。此举是彭博社公共宣传及其生态系统足迹的合乎逻辑的扩展；Fleming已经参与审查外部演讲的内容提案。彭博社的开源理念也推动了它的赞助政策，承保或在社区驱动的活动中发言，但不是公司活动。 "我们很高兴赞助或在 Apache Spark 会议上发言，但不是由一家销售基于 Spark 构建的带有专有模块的服务的公司举办的会议，" 他举例说。

随着时间的推移，彭博社的 OSPO 不仅发展为促进社区参与，还为考虑启动开源项目的团队提供必要的指导和支持。为了简化教育，Fleming和彭博社的团队编写了一份内部手册，概述了团队或员工在启动之前应该采取的所有考虑因素和步骤。与 TODO小组的许多最佳实践相呼应，Fleming根据彭博社及其特定的内部流程和决策实践定制了手册。

这个过程是微妙的，并考虑了许多因素。 "如果有人启动了一个潜在的项目，我们会召集我们的一位内部主题专家来查看代码，" Fleming解释道。 "他们可能会说，'代码看起来很旧; 再也没有人以这种方式编写 Python，'这是一个考虑因素，因为我们不希望在社区中被视为追求过时的做法或发布较少的代码。" 希望发布代码的团队还必须致力于培养社区并响应错误和拉取请求。 "如果我们要发布一个项目，工程师必须从他们的经理那里获得承诺，他们将有足够的时间来支持这个项目。" 他说。

彭博社 OSPO 的角色从战术发展到战略。 "一开始，当开源实践的知识没有在公司内很好地分布时，我们所做的大部分工作都是战术性的——让我们完成一件特定的事情，" Fleming说。

随着越来越多的从管理层到个人贡献者的人明白我们想要建立更好的关系并扩大开源的参与和使用，我们成为了战略决策的顾问。我们应该使用这个社区的这个特定项目吗？它看起来像一个真正的社区，还是由一个公司或个人经营？我们帮助回答了这些问题。¹³

换言之，社区健康和行为已成为公司技术投资的关键决定因素。

Fleming 告诉我们，彭博社定期与开源公司合作，帮助他们了解他们需要什么样的行为和治理结构来巩固使用他们的软件的长期承诺。Fleming说，

在我的历史中，有人来找我们说："我们想使用这个软件！" 我们说，"软件很可靠，但社区并不健康。我们不知道该项目的未来是什么。也许我们应该考虑使用替代品，因为我们可能会发现自己在未来必须切换到替代品，而且成本会更高。"

这种做法已经超越了最初的决定，从以违反彭博社首选最佳实践的方式更改许可证或治理的项目中收回资源。Fleming说，

我们不允许我们的工程师为不属于正确类型的开源许可的事物做出贡献。随着项目将许可证从 OSI 批准的许可证更改为他们自己的许可证类型，我们可能无法再为这些项目做出贡献，因为它们不再是真正的 [开源软件]。我们可能会建议减少对这些项目的投资。

此外，彭博社的 OSPO 帮助该公司制定了一项开放政策，优先考虑基于社区的开源技术，具有独立治理和充满活力、多样化的成员资格。 "当基础架构团队考虑更换支持内部服务产品的技术时，我们非常倾向于首先尝试找到解决该问题的开源软件解决方案，" Fleming 解释道。 "如果他们能找到解决 90% 问题的方法，而我们可以建立专业知识来解决剩下的 10%，我们就会这样做。只有当我们找不到关闭的东西时，我们才会考虑专有供应商或我们认为不开放的东西。"

2021 年 6 月，彭博社为 OSPO 增加了第二位全职员工，Alyssa Wright，她在开源软件方面拥有深厚的背景，包括在 OpenStreetMap 担任董事会领导。Wright和Fleming计划扩大彭博社的开源知识和实践以支持越来越多经常参与开源社区的工程师。有几名员工全职从事开源代码工作，这是彭博社的一个更高的门槛，因为员工通常必须向他们的经理证明，全职从事社区项目的工作为公司带来了明确的价值和效用。

彭博社最近加快了重要开源项目的发布步伐，这通常是由其积极的方法推动的，即建立共享工作并产生更多动力的多组织协作。Wright告诉我们：

我们中的很多人都明白，将代码作为开源发布并不是在打开代码开关然后说："嘿，我们到此为止了。" 以负责任和有意义的方式这样做有助于创建和支持社区，并使其他人可以访问代码。我们总是希望以负责任和支持的方式行事，使其对他人有用。¹⁴

康卡斯特

关于康卡斯特的开源

康卡斯特是一家全球媒体和技术公司，在其整个组织中都采用了开源。康卡斯特使用开源来帮助构建一些为其产品和服务提供支持的主要基础设施服务。康卡斯特了解全球开源协作和创新的力量，它是改善客户体验和吸引公司最优秀人才的重要工具。该公司拥有数千名技术人员，其中许多人将开源作为其开发工作流程的一部分。康卡斯特为开源社区贡献了一些主要的开源项目，包括 Apache Traffic Control，这是康卡斯特生产中的一个大型内容交付网络解决方案，用于向客户交付 "最后一英里" 的内容。

除了在其产品中使用开源之外，康卡斯特还积极参与并赞助开源基金会和社区，包括 Linux 基金会、OpenStack 基金会、Apache 基金会、the Innersource Commons 和the Internet Engineering Task Force。康卡斯特鼓励其软件工程师回馈开源项目以及向他们所使用的上游开源项目提交变更。康卡斯特支持开源生态系统背后的集体开发精神。

康卡斯特的OSPO之旅

康卡斯特正式参与开源开始于 2006 年，当时一位软件开发人员为 Apache HTTP 做出了补丁贡献，并证明了在上游修复比在消费级别维护补丁更容易。康卡斯特正式进入消费和合规性的OSPO 成熟度周期的第一阶段始于几年前，当时一些法律和发展领导者制定了更正式的政策和流程，以应对不断增长的消费和贡献。

不久之后，康卡斯特进入了 OSPO 成熟度周期的贡献阶段，公司开发人员开始为开源项目贡献代码，康卡斯特成立了一个开源咨询委员会。为了正确衡量对开源的影响，康卡斯特从 2013 年开始跟踪贡献。第一年，公司员工统计了 13 项贡献。几年后，康卡斯特进入了成熟周期的下一个阶段，当时公司从 Apache Traffic Control 开始孵化并向公众发布项目。此后，康卡斯特不仅为公司使用的多个项目做出了贡献，还在 GitHub 上发布了数十个开源存储库，并发布了多个项目。

随着开源对康卡斯特的业务和技术战略变得越来越重要，该公司认识到它需要进入一个更成熟的阶段，即协作和社区领导阶段，以建立一个有凝聚力的内部和外部开源战略。 Nithya Ruff是康卡斯特研究员，自 2017 年起担任康卡斯特开源负责人，并担任 Linux 基金会董事会主席，受聘帮助推动整个公司的开源参与。 "公司希望确保我们有一个单一的地方来推动整个组织的开源参与和合规性。康卡斯特的 OSPO 的工作描述需要比合规性更广泛，并且需要包括继续促进代码贡献回馈社区，" Ruff 说。 "我们还需要加强我们的开发者关系实践，增加我们与领先基金会和生态系统的社区参与度。"¹⁵

自成立以来，康卡斯特的OSPO有两个主要目标。第一个目标是让康卡斯特开发人员在消费、贡献、遵守、工作和创建开源时尽可能顺畅。第二个目标是通过回馈、积极参与并帮助社区更快地创新来支持和参与广泛的开源社区。这也有助于康卡斯特吸引和留住有才华的开源开发人员进入公司。 Ruff 指出， "我们的很多工程师都喜欢能够为开源软件做出贡献，能够在会议上发言，发表论文和博客。我们的工作是让它在开源软件中工作变得容易。我们相信开源软件是公司创新的关键组成部分，也是吸引优秀开发人员与我们合作的关键优势。"

为了实现这些目标以及更多目标，康卡斯特为其开源实践开发了所谓的"6Cs 战略"。6C 是 "沟通（communications）、消费（consumption）、贡献（contribution）、协作（collaboration）、合规（compliance）和文化（culture），这些都是在开放中发展和构建健康的开源生态系统的关键属性。 6C体现了康卡斯特的开源实践，从与 TODO小组和OpenChain中的其他公司合作，到参与和赞助开源基金会，再到创建开源的内部思维和文化。例如，为了更加协作，康卡斯特加入了 Linux 和 Apache 基金会，并开始在这些机构中寻求领导角色并参加更多活动。康卡斯特在启动 OSPO 的早期就对开源软件使用情况和依赖项进行了清点，以便更好地了解依赖项在哪里以及要支持和合作的社区。 "该清单引导我们将资源用于协作和贡献，" Ruff 说。

随着时间的推移，OSPO 在康卡斯特的实践变得更加主动和更具战略性。随着OSPO的壮大，康卡斯特开源团队已经扩展到新的领域，创建了一个内部开源大使计划来扩大关于开源最佳实践的教育，并创建一个内部源代码实践来分担多个业务部门的开发负担。康卡斯特的 OSPO 还收集有关开源和内部源代码工作影响的详细指标，包括已处理的贡献和贡献类型、事件（赞助、参与、内部、用户组等）、博客和文章出版物、合规自动化和咨询。

如今，康卡斯特的OSPO 已发展成为一个内部卓越中心和所有开源事物的咨询中心。 Ruff 解释说： "我们的业务部门现在向我们提出想法并说， '嘿，这就是我们想要做的。你能帮助实现这一目标吗？我们如何将其置于基础中？是否有流程或最佳实践？" 最近，OSPO 指导 Trickster 和Kuberhealthy维护人员将项目贡献给云原生计算基金会。 "通过这些项目，我们发现许多其他大公司也发现这些项目很有用，并积极参与了该项目。看到其他公司在博客上介绍他们对Kuberhealthy的使用以及它如何帮助他们，真是令人兴奋。这帮助我们为 CNCF 建立了一个商业案例，表明这两个项目有足够的吸引力，应该将它们添加到基金会的沙箱中。"

康卡斯特的 OSPO 在指导组织了解技术趋势、不断变化的许可证和开源方向以及最佳实践方面发挥着重要作用。 "当事情发生变化时，例如许可证更改或产品意外终止 (EOL)，我们会建议团队做什么以及如何应对，" Ruff 说。

"我的愿景是作为一家 OSPO 对公司具有战略意义，并使企业能够通过开源软件更好地实现其目标。今天，我们在做开源软件的方式上非常具有战略意义，" Ruff 说。 "从商业模式到生态系统建设，再到确定我们可以构建什么以及我们可以与谁合作，我相信，OSPO 可以提供很多东西。"

保时捷

汽车领域的开源

这家传奇的汽车制造商正在迅速迈向开源的未来。作为大众汽车集团的一部分，保时捷主要将开源软件用于嵌入式系统，例如电子控制单元，以及面向消费者的移动应用程序。在特斯拉的快速增长及其软件优先的汽车技术开发方法的推动下，大众汽车制定了多项举措来加速软件的内部创建，以及参与开源社区和项目。作为这项努力的一部分，保时捷于 2020 年创建了自己的 OSPO。该集团现在声称有 12 名全职员工在整个汽车公司的多个产品组中运营。

保时捷的 OSPO 之旅

从历史上看，保时捷一直是开源软件的消费者。在 2018 年之前，该公司专注于确保选择使用开源的工程师以合规的方式这样做。虽然开源使用确实经过了法律审查，但每个产品组都有自己的合规流程和协调。

该公司认识到，统一的开源合规性和许可策略将更好地服务于它，一套工具可以简化合规性。

"我们一直都有一个合规计划。有一次，我们决定，因为我们确实消耗了大量的开源资源，所以我们需要一个跨职能的总体团队，" 保时捷 OSPO 负责人 Nik Peters 说。 "我们不想依靠产品团队，而是依靠技术、法律和其他问题的中心联络点。"

除了合规性之外，保时捷认识到它的未来在于拥抱开源，以更快地进行迭代和创新，并更快地将产品推向市场。 "很明显，仅仅遵守许可证是不够的。我们需要推动对开源软件的贡献，创建内部采购计划，并确保我们的开源软件是安全的，" Peters 解释说。

与许多公司相比，大众汽车正在积极推动开源，创建完全独立的公司，专注于汽车行业的软件创新。该公司希望减少对供应商的软件驱动组件的依赖，并增加内部开发。为此，大众成立了CARIAD 作为一个独立的企业，为企业集团的所有品牌创建软件并汇集资源。 CARIAD 密切参与了保时捷和其他大众汽车集团公司的 OSPO 工作。与此同时，保时捷和大众希望通过加强合作来改进他们的技术开发方法。

Peters 于 2018 年启动了 OSPO 之前的工作，并于 2020 年启动了正式的 OSPO。他围绕"协调员" 的概念组织了保时捷的 OSPO， "协调员" 位于产品团队内部，但向 OSPO 报告。在早期，Peters 和其他保时捷开源软件领导者花时间与拥有长期开源记录的领先软件和技术公司（例如 SAP）进行交流，以了解他们如何处理和培育开源。保时捷 OSPO 最初仅由 Peters 和一名同事组成，现已发展到 12 名全职员工，并制定了从上层管理层获得支持和资助的路线图。Peters本人向保时捷首席技术官汇报。 2020年，保时捷正式推出了OSPO。如今，所有开源软件合规性和批准都通过 OSPO 进行。

甚至从一开始，该集团创建保时捷开源生态系统的愿景就包含了更宏大、更全面的目标，包括：

提高保时捷在开源开发社区中作为软件组织的声誉
通过开源缩短产品上市时间和创新
降低软件开发成本
加强与行业和其他技术领导者的合作
提高软件质量和安全性
吸引和留住高素质员工

自 2020 年以来，保时捷旗下的 OSPO 迅速扩大了对开源的参与。 "今天，我们依赖其他公司和其他开发工作，以至于我们根据这些团队正在做的事情来计划我们的内部发布，" Peters说。 "从加入邮件列表和 Slack [频道] 到推动新的开源计划，它已经发生了巨大的变化。"

例如，保时捷与众多行业参与者合作开发开源软件 Review Toolkit ，这是一个工具链和一组管道，可实现开源软件合规性和报告的自动化和标准化。保时捷正在与来自Bosch 、Here Technologies 以及欧盟其他汽车行业参与者和软件公司的开发人员合作。该公司还通过媒体和代码学校赞助加强了其开源工作的推广，Peters经常在这些学校发表主题演讲。

平心而论，Peters觉得保时捷已经取得了很大的进步，但还有很长的路要走。保时捷开发人员是参与者，但还不是重要的贡献者。该公司确实监控贡献，并希望围绕开源软件参与安装指标，作为 OSPO 管理目标的一部分。 "作为一个组织，我们既是贡献者，又是参与者。我们的一大目标是看看我们是否能够推动和制定开放标准——例如，汽车开源标准，" Peters 说。毫无疑问，对速度的需求正在推动保时捷的 OSPO。Peters指出，虽然普通汽车有几十个电子控制单元（ECU），每个都有不同的软件位，但特斯拉制造的汽车只有两个 ECU。这使特斯拉能够将功能开发更多地视为软件问题。 "我们的大目标是在五年内从 10% 到 20% 的内部嵌入式软件提高到至少 60%。对我们来说，这改变了游戏规则，" Peters说。为了实现这一目标，保时捷将需要从开源中获得的所有推动力。

结论：OSPO 的未来

随着世界从专有软件转向开源软件，OSPO 的作用将变得越来越重要。在我们对 OSPO 领导者的采访中，我们看到了 OSPO 的作用、OSPO 的预算以及致力于在组织中推广开源的员工的普遍扩展。显然，开源已经从构建技术产品和基础设施的方法和思维方式上升为吸引顶尖人才和实现业务目标的手段。这与社会的数字化转型平行。

在一个软件吞噬一切，大大小小的组织都非常喜欢开源软件的世界里，开源专业知识成为创造出色产品和产品体验不可或缺的一部分，无论是在产品层（媒体、通信）还是在支持产品。 OSPO 正在成长以填补这些新的更大的鞋子，充当内部咨询、卓越中心以及值得信赖的顾问和导师。这样的成长并非没有成长的阵痛。对开源和 OSPO 服务的需求似乎超过了供应，更成熟的 OSPO 正在开发扩展流程和功能，以服务于这些组织内更广泛的用户群。此外，OSPO 不仅仅适用于科技行业。我们看到学术界和政府内部正在建立 OSPO，以帮助进行软件采购和创新。

也就是说，我们与 OSPO 领导者的对话和调查回复表明，如果有的话，组织正在计划扩大 OSPO 预算和授权，以反映开源的增长。 OSPO 将拥有更多资源来自动化 OSPO 手动任务（在合规性或尽职调查等领域）和更大的 OSPO 团队，以满足在开源领域花费更多时间的开发人员的需求。对成功的 OSPO 的期望将从教育开发人员或编组代码贡献转变为增加有意义的战略价值并推动更高级别的开源战略、创新和开发人员效率。

OSPO 检查清单

阶段1

定义程序品牌（例如，OSPO、开源计划、开源运营负责人）
管理法律风险和许可，创建新程序和文档，以确保员工根据许可条款使用开源软件，并且组织的开源软件消费不会使其面临法律风险
创建教育计划以帮助开发人员决定何时使用开源软件创建新产品或服务
设置特定的软件库存流程以创建组织范围内的软件物料清单 (SBOM)
总体而言，认识到开源软件的价值以及对合规性、教育和 SBOM 的需求

阶段2

列出与开源软件项目交互的最佳实践，例如如何请求功能、提交错误报告和贡献基本代码
向员工和经理传达为开源软件做出贡献而不是仅仅使用开源软件的重要性（包括倡导和推动活动赞助，在公共编码论坛中将项目负责人和维护者预订为演讲者或小组成员，以及确保组织资源用于关键任务开源软件项目）
激励开发人员从事对其运营至关重要的开源软件项目，使开发人员成为高度活跃的贡献者或主要维护者

阶段3

发起和主持开源软件项目，或作为项目主要发起人
创建和启动开源项目，以在开源社区中建立广泛的信誉
将一名或多名全职员工专门用于项目，并承担培养项目社区并确保其健康的责任
开发内部流程、手册、检查清单、工具和其他机制来审查、组织和运营开源项目，并准备和指导他们的领导者

阶段4

成为技术决策的战略合作伙伴，帮助指导选择并塑造对项目的长期承诺向 CTO 和技术领导提出建议，让他们了解在组织的技术堆栈中采用或删除哪些开源技术
带头对什么构成可接受的开源软件项目进行基准测试
帮助组织理解和驾驭项目政治

致谢

感谢本研究的所有参与者，他们慷慨地与我们交谈并审阅报告的各个部分，包括 Deborah Bryant、Chris Xie 、Dirk Riehle、Kevin Fleming、Alyssa Wright、Robyn "Stormy" Peters、Suzanne Ambiel 、Nikita Peters，Michael Picht和Peter Giese。如果没有熟练地领导研究和写作工作的 Alex Salkever以及帮助项目设计和推广的 TODO小组的 Ana Jimenez，这份报告是不可能完成的。我们还要感谢 VMware 对这项研究的赞助。

免责声明

本报告"按原样"提供。 Linux 基金会及其作者、贡献者和赞助商明确否认与本报告相关的任何保证（明示、暗示或其他方式），包括对适销性、不侵权、适用于特定目的或标题的暗示保证。在任何情况下，Linux 基金会及其作者、贡献者和赞助商均不对任何其他方因任何形式的诉讼因由而导致的利润损失或任何形式的间接、特殊、偶然或后果性损害承担责任。无论是基于违约、侵权（包括疏忽）还是其他原因，以及他们是否已被告知此类损害的可能性。赞助本报告的编写并不构成其任何赞助商对其调查结果的认可。

TODO

TODO 小组是一个由70多个组织组成的开放团体，他们拥有多年运行开源项目的经验，希望就实践、工具和其他方式进行协作，以运行成功和有效的开源项目和计划。这是一个分享经验、开发最佳实践和指导以及开发通用工具以改善全球跨部门OSPO采用和教育的地方。在此处可以发现有关所有正在进行的 TODO 倡议的更多信息，并查看OSPO全景图：https://landscape.todogroup.org

The Linux Foundation Research

Linux Foundation Research 成立于 2021 年，探索不断扩大的开源协作规模，提供对新兴技术趋势、最佳实践以及开源项目的全球影响的洞察。通过利用项目数据库和网络，致力于定量和定性方法的最佳实践，Linux Foundation Research

本报告根据知识共享署名-禁止演绎 4.0 国际公共许可协议获得许可。本材料可以根据知识共享许可条款进行复制和分发。要引用该作品，请注明以下内容：Chris Aniszczyk，“开源办公室的演变”，前言由 Jim Zemlin 完成，Linux 基金会，2022 年 2 月。

Stormy Peters, Zoom interview with author, Nov. 19, 2021 ↩
"2021 Open Source Security and Risk Analysis Report," Synopsis Inc., May 14, 2021, p. 6. (https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html), accessed Jan. 4, 2022. ↩
Dirk Riehle（教授，OSS，埃尔兰根-纽伦堡弗里德里希-亚历山大大学），Zoom 采访作者，2021 年 9 月 9 日。 ↩
Suzanne Ambiel （VMware 开源营销和战略总监），Zoom 采访作者，2021 年 10 月 12 日。 ↩
Deborah Bryant（Red Hat 开源高级总监），Zoom 采访作者，2021 年 8 月 24 日。 ↩
Chris Xie （Futurewei Technologies OSPO 负责人），Zoom 作者采访，2021 年 8 月 24 日和 9 月 30 日。 ↩
参见，例如，Robert W. Hahn, "Government Policy toward Open-Source Software: An Overview," Government Policy Toward Open-Source Software, Brookings Institution Press and American Enterprise Institute, 2002年12月31日。 https://www.brookings.edu/wp-content/uploads/2016/07/ governmentpolicytowardopensourcesoftware_chapter.pdf, 2021年10月19日访问。 ↩
Michael Picht （SAP 开源办公室首席架构师），Zoom 作者采访，2021 年 11 月 8 日 ↩
Deborah Bryant (Senior Director, Open Source, Red Hat), Zoom interview with author, Aug. 24, 2021. ↩
Suzanne Ambiel (Director, Open Source Marketing and Strategy, VMware), Zoom interview with author, Oct. 12, 2021. ↩
Kevin P. Fleming (Bloomberg前Technology Community Engagement负责人), Zoom作者访谈, 2021年9月24日。 ↩
Kevin P. Fleming (Bloomberg前Technology Community Engagement负责人), Zoom作者访谈, 2021年9月24日。 ↩
Kevin P. Fleming (Bloomberg前Technology Community Engagement负责人), Zoom作者访谈, 2021年9月24日。 ↩
Alyssa Wright (Bloomberg OSPO), Zoom作者访谈, 2021年9月24日。 ↩
Nithya Ruff (康卡斯特 OSPO), Zoom作者访谈，2021年9月20日. ↩

将内部代码发布为一个新的开源项目

2023年3月16日 · 阅读需 78 分钟

将内部代码发布为一个新的开源项目：干系人指南

November 2022

2022年11月

Ibrahim Haddad, Ph.D.

Executive Director, LF AI & Data and PyTorch Foundation

Ibrahim Haddad 博士

LF AI & Ddata 和 PyTorch 基金会 执行董事

Font Cover

In partnership with:

联合：

Contents

[Infographic 4]

[信息图 4]

[Abstract 5]

[摘要 5]

[Introduction 6]

[概述 6]

[Initial investigations 8]

[前期调查 8]

[Make the business case to open source 8]

[开源商业方案 8]

[Evaluate possible ways to open source 8]

[评估可能的开源方式 8]

[Project funding 9]

[项目资金 9]

[Legal considerations 9]

[法律考虑 9]

[Confirm ownership of all the code 9]

[确认代码所有权 9]

[Conduct intellectual property review 10]

[进行知识产权审查 10]

[Choose the open source license 10]

[选择开源许可证 10]

[Apply license terms to the code 11]

[应用许可证条款到代码 11]

[Code clean-up 11]

[清理代码 11]

[Project branding 12]

[项目品牌 12]

[Develop a trademark strategy and policy 12]

[制定商标战略和政策 12]

[Domain names 12]

[域名 12]

[Creative assets 12]

[创意资产 12]

[Register external accounts 12]

[注册外部账户 12]

[Develop a certification/compliance strategy 12]

[制定认证/合规策略 12]

[Recruit business partners 12]

[招募商业伙伴 12]

[Establish project governance 13]

[建立项目治理制度 13]

[Set up project infrastructure 14]

[建立项目基础设施 14]

[Apply recommended practices for your GitHub repo 14]

[为你的 GitHub 仓库应用推荐做法 14]

[Project launch 15]

[项目启动 15]

[Prepare the announcement 15]

[准备公告 15]

[Press and analyst relations 15]

[媒体和分析师关系 15]

[Announce and launch the project 15]

[宣布并启动项目 15]

[Summary of recommended practices for running an open source project 16]

[运营一个开源项目的实践经验 16]

[License 16]

[开源协议使用 16]

[Governance 16]

[治理模型 16]

[Access 16]

[使用权 16]

[Processes 16]

[流程 16]

[Development 16]

[项目发展 16]

[Community 16]

[社区运营 16]

[Community structure 16]

[社区结构 16]

[Releases 17]

[版本发布 17]

[Communication tools 17]

[沟通工具 17]

[Transparency 17]

[透明度 17]

[Documentation 17]

[文档工作 17]

[Ongoing support 18]

[持续支持 18]

[Support the community 18]

[支持社区 18]

[Support project infrastructure 18]

[支持项目基础设施 18]

[Endnotes 18]

[尾注 18]

Infographic


License your project under an OSI-APPROVED OPEN SOURCE LICENSE to freely create and distribute derivative works. 根据 OSI批准的开放源代码许可证来许可你的项目以自由创建和分发衍生品。	Set up a transparent and equalizing governance model to SUPPORT THE HEALTH, LONGEVITY, AND GROWTH of the project. 建立一个透明平等的治理模式，以支持项目健康、长期发展和增长。	Allow OPEN ACCESS TO PROJECT RESOURCES for anyone interested in participating in and contributing to the project. 允许任何有兴趣参与项目且做出贡献的人公开访问项目资源。
DOCUMENT ALL PROJECT PROCESSES to maintain standards around commits, requests, peer reviews, and member roles, and be open to revising them with community feedback. 记录所有项目过程，以维护有关提交、请求、同行评审和成员角色的相关标准，并对基于社区反馈的修订保持开放。	Manage the DEVELOPMENT OF THE PROJECT THROUGH CAPABLE INDIVIDUALS MEETING QUALITY STANDARDS at multiple levels of review before entering the final release. 在进入最终版本前，通过满足质量标准的合格人员进行多级审校来管理项目开发。	Establish a community culture that strives for ACCESSIBILITY, VISIBILITY, SELF-ORGANIZATION AND RESILIENCE. 建设社区文化，努力实现可访问性、可见性、自组织性和弹性。
Structure the community to promote scalable activity from those who ADD VALUE, WHETHER THEY ARE NEWCOMERS, ESTABLISHED MAINTAINERS, END-USERS, OR DEVELOPERS. 构建社区来为贡献价值的人推广扩展活动，无论他们是新人、固定维护人员、最终用户还是开发者。	Provide STABLE RELEASES AT A DEFINED AND TRANSPARENT CADENCE that promote new functionality while maintaining reliability and security for users and developers. 以明确和透明的节奏稳定发布，以推广新功能，同时为用户和开发人员维持可靠性和安全性。	Establish OPEN AND ACCESSIBLE COMMUNICATION TOOLS to anyone wishing to participate in the project. 为任何希望参与项目的人提供开放和可访问的沟通工具。
PROVIDE REGULAR COMMUNITY SUPPORT by holding meetings and events, issuing project updates, answering questions, pulling patch submissions, and creating accountable and trackable KPIs and goals. 通过召开会议和活动、发布项目更新、回答问题、提交补丁以及创建可度量可追踪的KPI目标，定期提供社区支持。	To attract participation, MAINTAIN TRANSPARENCY in contributions, peer reviews, discussions, and maintainer or committer romotions. 为了吸引参与者，在贡献、同行评审、讨论和维护者或提交者宣传中保持透明度。	MAKE AVAILABLE ALL DOCUMENTATION on architecture, APIs, tutorials, and guides for installation, development, and participation. 公开所有文档，包括架构、API、教程以及安装、开发和参与指南。

Abstract

摘要

Corporate participation in open source has reached an all-time high and continues to grow as companies realize the value of consuming and contributing to open source projects. The nature of corporate participation continues to evolve, as companies increasingly discover that open sourcing proprietary technologies can create new sources of value and stronger product ecosystems.

随着企业意识到消费和贡献开源项目的价值，其在开源方面的参与度已达历史新高，且持续增长。企业越来越多地发现，开源自有技术可以创造新的价值源和更强大的产品生态, 其参与的性质在不断演进。

Open sourcing a proprietary technology involves far more than just making the source code available. There are many ways of building or joining communities to use and help maintain the project, which is why it should be a well-ordered and deliberate process.

开源一种自有技术不只是局限在源代码开放，有很多种方式来建立或加入社区，以应用并帮助维护项目，因此它应当是一个条理清晰且深思熟虑的过程。

For companies that plan to open source proprietary code as a standalone open source project, this paper offers a high-level overview of the process and provides a sample checklist that can help ensure that all tasks are properly captured and executed.

对于有计划开源自有代码成为一个独立开源项目的企业，本文给出了该过程的顶层概述，并提供了一个示例的检查清单，有助于确保正确识别和执行所有任务。

Introduction

概述

Open source software (OSS) has been shifting the software industry into a new paradigm, moving from developing propri- etary code behind closed doors to developing code that parties can share, modify, and redistribute openly. The key benefits of this shift include reducing development costs and software component complexity, developing reusable, common, off-the- shelf software assets, increasing flexibility, and benefiting from the innovation multiplier factor of community-driven development projects. Organizations that embrace the open source model as a positive means of building software will increase their chances of retaining their competitive advantage. Figure 1 illustrates the various strategic advantages that OSS offers to organizations adopting it and contributing to it.

开源软件（OSS）一直在并将持续推动软件行业发展到一种新范式，从闭门开发专有代码，转向为开发各方可以公开共享、修改和重新分发的代码。这种转变的主要好处在于降低开发成本和软件组件复杂性，开发可复用的通用标准软件资产，提高灵活性，并受益于社区驱动开发项目带来的多重创新。组织将开源模式作为构建软件的积极手段，可以增加其保持竞争优势的机会。图 1 说明了开源软件为采纳和促进开源软件的组织所提供的各种战略优势。

During the previous two decades, organizations have realized the benefits of using and contributing to open source projects in their products and services. This has created a trend of organizations setting up Open Source Program Offices (OSPOs) to manage all aspects of OSS, including the use of and compliance with OSS licenses, contribution to OSS projects, and community-building around key OSS technologies.

在过去的二十年中，企业组织已经意识到在其产品和服务中采纳和贡献开源项目的好处。这导致设立开源项目办公室（OSPO）成为一种趋势，组织通过它来管理开源软件的各个方面，包括开源软件许可证的使用和遵守、对开源软件项目的贡献以及围绕开源软件关键技术的社区建设。


FIGURE 1
图 1
Why Open Source ?
为何开源？
1. Neutral environment for collaboration & cross-pollination 1. 适于合作和交流的中立环境	2. Innovation multiplier — community driven 2. 创新加速器——社区驱动	3. Minimizes fragmentation and supports the upstream development model 3. 最小化碎片，支持上游开发模式	4. Enables better interoperability 4. 实现更好的互操作性	5. Facilitates standardization on open technologies 　5. 促进开放技术的标准化
6. Qualifies reference architectures 6. 合格的参考架构	7. Lowers barriers to enter a new domain 7. 降低进入新领域的阻碍	8. Enables business opportunities supported by a flexible licensing model 8. 通过灵活的许可模式支持商业机会	9. Leads to better products, improved quality, and improved security 9. 带来更好的产品、改善质量并提升安全性	10. Allows fast trailing 12 months and shared cost of development 10. 允许快速跟踪12个月并分担开发成本


FIGURE 2
图 2
Enterprise open source ladder 企业开源阶梯
CONTRIBUTOR 贡献者
PARTICIPANT 参与者
CONSUMER 消费者
LEADER 领导者
Continuous participation and contribution to open source project 对开源项目的持续参与和贡献


FIGURE 3 图 3
Steps involved in the process of open-sourcing 开源过程的相关步骤
Ongoing Support 持续支持
Initial Investigations 前期调查
Funding 资金支持
Legal 法务
Branding 品牌建设
Partners 合作伙伴
Governance 治理
Infrastructure 基础设施
Project Launch 项目发布

Figure 2 illustrates four primary OSS enterprise strategies: consumption of OSS, participation, contribution, and leadership. Each strategy requires an enterprise to succeed at the previous strategy, and how far an organization advances depends entirely on the enterprise. Engineering drives the early strategies of consumption and participation. Engineers use various open source components for their technical merits to speed up development, but they participate little in the projects that maintain these components. Over time, higher levels of the organization learn about the value of this OSS usage. As OSS gains traction, business needs begin to drive such OSS involvement, and OSS efforts contribute to a determined business strategy. Some companies achieve their goals as consumers. Other companies see strategic advantages in other stages of involvement and in most cases they set up an OSPO to oversee strategic planning and execution through these stages.

图 2 说明了四种主要的OSS企业战略：OSS 消费、参与、贡献和领导。每一项战略都要求企业在前一项战略中取得成功，而组织的进步程度完全取决于企业。工程推动了消费和参与的早期战略。工程师使用各种开源组件以提高开发速度，但他们很少参与维护这些组件的项目。随着时间的推移，组织的高层了解到 OSS 使用的价值。随着 OSS 的发展，业务需求开始推动 OSS 的参与，OSS 的努力有助于确定业务战略。一些公司实现了作为消费者的目标。其他公司在参与的其他阶段看到了战略优势，在大多数情况下，他们设立了一个 OSPO 来监督这些阶段的战略规划和执行。

As part of the third stage---contributing to open source---organizations often choose to contribute key proprietary technologies to open source with various motivations, such as the following:

作为第三阶段——贡献开源——的一部分，组织通常会以各种动机为开源贡献关键专有技术，例如：

Providing a reference implementation to a standard
提供标准的参考实现
Ensuring that critical software remains viable
确保关键软件持续可用
Undercutting the competition
削弱竞争对手
Commoditizing a market
开辟商业化市场
Partnering with others and promoting goodwill in the developer community
与他人合作并提升在开发者社区的信誉
Driving market demand by building an ecosystem
准确把握市场需求，构建上下游生态
Offering customers the ability to support themselves and add custom features
支持客户自助服务及增加自定义功能

Open sourcing with the wrong motivation will often have a negative effect on achieving the desired outcome and can disrupt the relation of the enterprise with the communities of specific open source projects.

带有错误动机的开源通常会对实现预期结果产生负面影响，并可能破坏企业与特定开源项目社区的关系。

This paper identifies questions to ask, practices to consider, and steps to take when making a proprietary technology open source. Figure 3 illustrates the various steps involved in the process of open sourcing internal code and launching it as an open source project. These steps are not necessarily executed in a linear order and several of them can be taking place in parallel. Our goal with this paper is to provide a basic template that organizations can adjust to accommodate their own policies and strategies.

本文确定了在开源专有技术时要明确的问题、要考虑的实践以及要采取的具体步骤。图 3 说明了将内部代码发布为一个开源项目过程中涉及的各个步骤。这些步骤不一定按顺序逐个执行，其中一些步骤可以并行进行。本文的目标是提供一个基本模板，组织可以根据自己的政策和战略按需调整。

Initial investigations

前期调查

When open sourcing proprietary technology, it is important to thoroughly evaluate the reasons for the transition and align internal incentives and metrics accordingly. Open sourcing for the wrong reasons could have the opposite effect than is originally intended. To successfully open source a project, you must have the right reasons or motivations.

在开源自有技术时，必须彻底评估转型的原因，并相应地调整内部激励和相应指标。出于错误的动机进行开源可能会产生与最初预期相反的效果。想要成功地开源项目，你必须得有正确的理由或动机。

Make the business case to open source

开源商业方案

There are many sound business reasons for open sourcing propri- etary code, such as the following:

有许多合理的商业理由来开源自有代码，比如：

Strengthening the ecosystem for the product or service you are building
强化正在开发中的产品或服务的生态系统
Improving product quality by engaging business partners and customers in enhancing features and fixing bugs
吸引业务合作伙伴和客户参与增强功能和修复缺陷，以提升产品质量
Providing a reference implementation to a standard, thereby driving the adoption of your software as a de facto implementation
为某个标准提供参考实现，从而推动该软件成为事实上的标准实现
Commoditizing non-strategic layers of a software stack
推动软件栈的非战略层面商业化
Pushing the value line higher and forcing more innovation
推动更高价值和更多创新
Partnering with open source communities and increasing goodwill within the developer communities
与开源社区合作，提升在开发者社区的好感度

Equally, there are many counterproductive reasons to open source proprietary code. These arguments should act as red flags:

同样地，开源自有代码也有许多因素会导致事与愿违。以下这些应当作为危险信号：

You want others to maintain a codebase you still need so that you can stop investing in that code
希望有其他人来维护你依然需要的代码库，以便你自己可以停止对该代码的持续投入
You want to retire code with unique functionality that you will nolonger maintain or use in your products
希望淘汰那些你不打算再维护或使用的独特功能的代码
The source code links directly to code you cannot release under an open source license
源代码直接链接到了你不能在开源许可证下发布的代码

Now that you have a business case for open sourcing your code at your organization, the next step is to determine the actual path to open source.

你现在已经有了在组织中开源代码的商业案例，下一步就是要确定具体的开源方式。

Evaluate possible ways to open source

评估可能的开源方式

There is no single way to achieve the possible goal, and it's not an exercise that your organization has to do alone. In most cases, there are multiple options that you can explore, such as the following:

并不存在什么唯一的方法来达成可能的目标，并且这也不是要你的组织必须单独完成的。在大多数情况下，你可以探索多种可能性，例如：

Evaluate the technology and determine whether you should open source any other components
做好技术评估并确定是否应该同时开源其他组件
Analyze existing open source projects your company could join as a major participant, reducing your need to create new infrastructure and a new community
分析那些适合你的公司作为主要参与者加入的已有开源项目，尽量避免创建新的基础设施和新的社区
Explore the possibility of launching the planned open source project with some of your existing clients and partners
探索与客户和合作伙伴一起发布计划中的开源项目的可能性
Evaluate the option of launching and hosting the planned open source project in an open source foundation with a record of launching and sustaining successful open source projects.
评估有发布并维护成功的开源项目的开源基金会，通过其发布和托管计划中的开源项目。

Project funding

项目资金

Once you have made the business case for open source, you'll need a project plan and time-phased budget covering the costs to launch and maintain the project over time. Some of the costs are one-time and others are recurring. Examples of such costs include the following:

商业方案一旦开源，你就需要制定一个项目计划以及各阶段的预算，包括随着时间的推移启动和维护项目的成本；这些费用中的一部分是一次性的，而其他的则可能反复出现。举例来说，这类成本可能包括：

Internal legal efforts leading to posting the code publicly
通过有计划的内部法务活动指引公开的代码发布
Ongoing IT project infrastructure and cloud credits (when applicable)
持续的 IT 基础设施和云服务配额（如适用）支持
Trademark management
商标管理
Creative and branding (logo, website, signage at events, etc.)
创意及品牌设计（徽标、网站、活动标识等）
Project management
项目管理
Regularly scheduled open source license compliance and security scans
需要定期执行的开源许可证合规性和安全性扫描
Community events and hackathons
社区活动与黑客马拉松

Legal considerations

法律考量

On the legal side, there are five major activities that need to be executed. These include:

在法律层面，有 5 个主要的活动需要执行，包括：

Confirming ownership of all the source code intended for open source
Conducting intellectual property review
Choosing an open source license
Applying the license terms to the code and updating the license information in the source code
Cleaning up the source code before posting it in public

确认开源项目相关的所有源代码的所有权
进行知识产权审查
选择一个开源许可证
应用许可证条款到代码并更新源代码中的许可证信息
在公开发布前清理源代码

In the following subsections, we cover these various activities and provide recommendations where applicable.

在下面的小节中，我们将介绍这些活动，并提供适当的建议。

Confirm ownership of all the code

确认代码所有权

One of the risks in open sourcing proprietary technology is the accidental inclusion of third-party proprietary code as part of the open sourced code. Before releasing any code under an open source license, it is highly recommended that an organization holds all the rights and permissions necessary to open source the code.

开源自有技术的风险之一是意外将第三方专有代码作为开源代码的一部分。在根据开源许可证发布任何代码之前，强烈建议组织确认拥有开源代码所需的所有权利和权限。

Some of the steps in this exercise include the following:

可以按照以下步骤方式执行：

Auditing the source code with a software composition analysis (SCA) tool ¹
使用软件组成分析工具(SCA)审计源代码 ¹
Identifying third-party source code---open source or commercial
识别第三方代码，确定是开源的还是商业的
Determining whether you have the right to open source any found third-party commercial code under an open source license; if the answer is no, you cannot open source some third-party code, then you need to provide alternate code
确认你是否有权根据开源许可证对任何发现的第三方商业代码进行开源；如果答案是否定的，则无法开源那些第三方代码，你需要提供可替代代码

Conduct intellectual property review

进行知识产权审查

Software likely subject to patent or other intellectual property claims is not an ideal candidate for open source release. Here are questions to ask to help you with this exercise:

可能受到专利或其他知识产权保护的软件，不是开源发布的理想候选软件。回答以下问题可以帮助你完成此活动：

Does the code disclose or realize any inventions the company plans to protect through patents?
该代码是否披露或实现了公司计划通过专利保护的任何发明？
- If the answer is yes, then you need to decide whether to remove the code, establish an IP policy, or make a nonassertion pledge. In all cases, your legal counsel will make the appropriate recommendations for next steps when such a scenario arises.
- 如果答案是肯定的，那么需要决定是移除代码、建立 IP 策略还是做出不声明承诺。在任何情况下，一旦出现这种情形，你的法律顾问都会为接下来的步骤提出适当的建议。
Will the source code release trigger patent claims against the open-source software?
该源代码的发布会引发对开源软件的专利索赔吗？
- If the answer is yes, then you have to remove and replace the protected code or seek appropriate licenses or permissions.
- 如果答案是肯定的，那么你必须移除并替换受保护的代码，或寻求更适合的许可证或权限。
Does the name you chose for the open source project (assuming you're starting a new project) protectable under trademark law? Does the name or any trademarks associated with or registered to the project present any risk of infringement claims?
你为开源项目所选的名称（假设您正启动一个新项目）是否受商标法保护？与项目相关的或已注册的名称或商标是否存在侵权索赔风险？

Choose the open source license

选择开源许可证

The license of an open source project determines the rights to use, copy, modify, and distribute the code. The choice of license for an open source project is an essential factor in determining the openness of the project. Open source projects should only use licenses that the Open Source Initiative has approved. Such licenses allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative, a license must go through its license review process to confirm that the license satisfies its Open Source Definition (OSD). You may come across many other licenses that are incompatible with the OSD. Most of these licenses are "Source Available" licenses that commonly include restrictions or limitations on the use and/or distribution of the software. These restrictions often render the licenses incompatible with the OSD.

开源项目的许可证定义了使用、复制、修改和分发代码的权利。开源项目的许可证选择是决定项目开放性的一个重要因素。开源项目只能使用Open Source Initiative已批准的许可证。这类许可证允许软件自由使用、修改和共享。要获得Open Source Initiative的批准，许可证必须通过license review process确认其满足Open Source Definition (OSD)。你可能会遇到许多其他与 OSD 不兼容的许可证。这些许可证中的大多数是"Source Available"许可证，通常包括对软件的使用和/或分发的约束或限制。这些限制通常使许可证与 OSD 不兼容。

It is always recommended to adopt an OSI-approved open source license. The choice of the specific license depends on the specific goals you want to achieve as an organization. We preview in this section some of the questions that will drive a discussion on this topic and help you make a decision on the license to adopt.

始终建议采用 OSI 批准的开源许可证。具体许可证的选择取决于你作为一个组织想要实现的具体目标。在本节中，我们将预览一些问题，这些问题将推动关于此主题的讨论，并帮助你决定所要采用的许可证。

Do you want to relinquish control over how others use and distribute the code?
是否要放弃控制他人如何使用和分发代码？
Do you want to allow others to use the code in commercial programs and products?
是否允许他人在商业程序和产品中使用该代码？
If others use the code in their program and sell it for money, do you want a percentage of those revenues?
如果他人在其程序中使用代码并将其出售，你想要获得这些收入的一部分吗？
If others use and distribute the code and improve it (e.g., fix bugs or add features), do you want them to contribute those improvements back to the project?
如果他人使用和分发代码并对其进行改进（例如修复漏洞或增加特性），你是否希望他们将这些改进贡献给项目？

What licenses will you accept for contributed code?

你希望在何种许可证下接受贡献代码？

Will you require a Developer Certificate of Origin (DCO) or a Contributor License Agreement (CLA) as a contribution requirement?
是否需要开发者溯源认证（DCO）或贡献者许可协议（CLA）作为贡献要求？

There may be additional questions to consider as part of this exercise, which is mainly driven by your legal counsel and tech- nology leaders within your organization.

作为此活动的一部分，可能还需要考虑其他问题，这主要由你的法律顾问和组织内的技术领导者推动。

DCO

DCO

The DCO sign-off process ensures that every single line of code accepted into a project has a clear audit trail. It is a developer's certification that they have the right to submit code for inclu- sion into the project. The Linux kernel process, for instance, requires all contributors to sign off their code, which indicates that the contributor certifies the code, as outlined in the DCO. The signature communicates that the contributor has created or received the contribution under an appropriate open source license that incorporates it into the project's codebase under the license indicated in the file. The DCO establishes a chain of people who take responsibility for the licensing and prove- nance of contributions to the project.>

DCO 签署流程确保了项目中接受的每一行代码都有清晰的审计跟踪。这是开发者有权提交代码到项目中的凭证。例如，Linux 内核流程要求所有贡献者为其提交的代码做签名，以示贡献者证>明自己的代码如DCO所述。签名表明贡献者根据适当的开源许可证创建或接收了贡献，该许可证根据文件中所示的许可证将其纳入项目的代码>库。DCO 建立了一个负责许可和证明项目贡献的人员链。

Some projects require either developers or their employers to sign a CLA. Unlike the DCO, the text of CLAs can vary signifi- cantly from project to project, so the terms of any given CLA may have different effects. The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights >over all contributions to allow them to distribute under the chosen license. In some cases, this even means that the contributor will grant an irrevocable license, which allows the project to distribute the contribution as part of the project.

有些项目要求开发者或其雇主签署 CLA 。与 DCO 不同，CLA 的内容可能会因项目而异，因此任何给定的 CLA 条款可能具有不同的效果。CLA 的目的是确保项目产出的监护人对所有贡献拥有必要的所有权或授予的权利，以允许他们在选定的许可证下进行分发。在某些情况下，这甚至意味着贡献者将授予不可撤销的许可，允许项目将贡献作为项目的一部分进行分发。

应用许可证条款到代码

Once the source code has been cleaned up following the recommendations provided in a previous step, it is time to apply the license terms to the code. This exercise includes the following steps:

一旦按照上一步中提供的建议清理了源代码，就应该将许可条款应用于代码。该项活动包括以下步骤：

Add a license file in the root directory of the component containing the full license text. For instance, if you are posting the code on GitHub, you will provide a LICENSE.md file containing the full text of the open source license
在包含完整许可文本的组件的根目录中添加许可文件。例如，如果你在 GitHub 上发布代码，就要提供一个 LICENSE.md 文件，其中包含开源许可证的全文。
Add license header and copyright notice to every source code file
向每个源代码文件添加许可证头信息和版权声明
Clearly designate the license on the project's website, any frequently asked questions (FAQ) that you provide, and the download page if applicable
在项目网站上明确指定许可证、常见问题（FAQ）以及下载页面（如果适用）
Use SPDX2 License List "short identifiers" in source files
在源文件中使用 SPDX2 许可证列表“短标识符”

Code clean-up

清理代码

Another risk to open sourcing a project is the inclusion of private information, confidential communications, and trade secrets. To minimize this risk, you can take the following actions:

开源一个项目的另一种风险是，包含了私有信息、通信凭证以及商业秘钥等。为了最小化此类风险，可以参考下列行动项：

Remove any exposure of nonpublic application programming interfaces (APIs).
移除暴露的任何非公开应用程序接口（API）。
Remove any comments containing employee names or personally identifying information, product code names, road maps, future product descriptions, or disparagements.
删除任何包含员工姓名或个人识别信息、产品代号、路线图、未来产品描述或贬损的评论。
Remove any unused or obsolete code from the source code to increase the likelihood of the community's making contributions.
从源代码中删除任何未使用或过时的代码，以增加社区做出贡献的可能性。
Create and include a file that contains the license and copyright notices of all third-party software and, if applicable, make the source code available.
创建并包含一个包含所有第三方软件的许可证和版权声明的文件，并在适用时提供源代码。
If the source code has dependencies on third-party code, then provide the necessary information to the community; it's preferred that the code does not have any dependencies on non-open source components.
如果源代码有第三方代码的依赖，则需向社区提供必要的信息；最好避免代码对非开源组件的依赖。
Remove any third-party proprietary code.
删除所有第三方私有代码。
- Add a license file in the root directory of the component containing the full license text. For instance, if you are posting the code on GitHub, you will provide a LICENSE.md file containing the full text of the open source license.
- 在包含完整许可文本的组件的根目录中添加许可文件。例如，如果你在 GitHub 上发布代码，就要提供一个 LICENSE.md 文件，其中包含开源许可证的全文。

Project branding

项目品牌

Project branding includes a number of activities that should be considered and are discussed in the following subsections.

项目品牌建设包括一些应该考虑的活动，我们在下面的小节中讨论。

Develop a trademark strategy and policy

制定商标战略和政策

Agree on a name/mark for the project.
约定项目的名称/标志。
Perform a knockout search to determine whether the registrations will succeed.
通过淘汰式搜索确定名字是否被占用。
Specify internal contact for trademark (if not counsel).
指定商标的内部联系人（该联系人不能是律师）。
Develop a registration strategy:
制定注册策略：
- Which classes of goods/services apply?
- 适用于哪些类别的商品/服务？
- Which countries to prioritize?
- 哪些国家要优先考虑？
Register the tradename and trademark.
注册商号和商标。

Domain names

域名

Register domains and set up redirects.
注册域名并设置重定向。

Creative assets

创意资产

Create the logo, logo package, and visual assets.
设计 logo、logo 包装和视觉资产。
Create and publish on the website the logo usage guidelines.
设计并在网站上发布 logo 使用指南。

Register external accounts

注册外部账号

Set up the project organization name on GitHub.
在 GitHub 上创建项目组织名。
Set up @projectname on various social media platforms such as Twitter, LinkedIn and Facebook.
在不同社交媒体平台如 Twitter、LinkedIn 和 Facebook 上创建 @项目名称账号。

Develop a certification/compliance strategy

制定一个认证/合规战略

Decide the criteria projects must meet to claim compatibility with the parent project.
制定合规标准，如果某项目对外声明与母项目兼容，需遵循此标准。
Create a specification document and tools that can verify whether a custom build of the project complies with the specification.
创建规范文件和可验证项目的定制构建是否符合规范的工具。
Agree on the name/mark for the certification program.
约定认证项目的名称/标志。
Develop a trademark policy/FAQ if you wish to control the use of the project name. Ask these questions to drive a conversation on the topic:
如果你想控制项目名称的使用，就制定一个商标政策/常见问题列表。提出下面这些问题，以引导关于该主题的对话：
- May distributors, user groups, or developers register domain names that include the project's name?
- 贡献者、用户组或开发者是否可以注册含有项目名称的域名？
- Will the project run certification programs allowing others to use the mark for modified products?
- 该项目是否会实施认证程序，以允许其他人使用修改后的商标？
Create a certification test suite.
创建认证测试套件。
Establish a contract with a testing facility.
与测试机构建立契约。
Schedule the first year of plugfests.
安排第一年的互操作性测试。

Recruit business partners

招募商业伙伴

Approach business partners that will benefit the most from the project for public support on launch day.
与将从项目中受益最多的商业伙伴接触，以便在启动日获得公开支持。
Secure commitments from key partners to encourage employee participation in the project and have some basic commitments.
确保得到主要合作伙伴的承诺，鼓励他们的员工参与项目并提供一些基础的贡献。
Approach compatible projects, communicate how the new project will benefit them and prepare them for the announcement.
接洽兼容的项目，沟通新项目将如何使他们受益，并让他们为公告做好准备。
Anticipate conflicts where existing projects misinterpret the launch as competition and defuse them before they start.
预测哪些现有的项目会误认为此项目与他们有竞争关系，并提前化解。
Give business partners early access to project source code.
让商业伙伴尽早接触到项目源代码。
Work with partners to establish a joint value proposition and reference stack for shared customers.
与合作伙伴合作，为共享客户建立一个联合价值主张和参考堆栈。

Establish project governance

建立项目管理制度

Governance determines who has influence and control over the project beyond what is legally required in the open source license. A project's governance model establishes a collaboration framework that addresses difficult questions, such as the following:

治理制度决定了谁对项目的影响和控制超出了开源许可中的基本要求。一个项目的管理制度建立了一套解决以下疑难问题的协作框架，如：

Contributions
项目贡献
- Who makes decisions for code inclusion and releases, and how?
- 谁来决定代码的收录和发布，以及如何决定？
- Who can be the lead maintainer or architect for the project (larger projects have more than one)?
- 谁是项目的主要维护者或架构师（较大的项目有不止一个）？
- How can the project contributors become maintainers or committers?
- 项目的贡献者如何成为维护者或提交者？
Direction and Finance
方向和资金
- How can the project raise money, and who decides how this money is spent?
- 项目如何筹备资金，谁可以决定资金的用途？
- Should the project have a Technical Steering Committee (TSC) or a Conformance and Certification Committee? Who can be on them?
- 该项目是否应该有一个技术指导委员会（TSC）或合规性认证委员会？谁可以加入它们？
- Who decides the project's direction and road map?
- 谁来决定项目的方向和路线？
Transparency
透明度
- Who can participate in the discussions and decide on critical matters?
- 谁能参与讨论并决定关键事项？
- How transparent are the decision-making processes?
- 决策过程的透明度如何？
- Can anyone follow the discussions and meetings that take place in the project?
- 谁能参与项目中发生的讨论和会议？
Reuse
复用
- What compliance requirements are there for redistributing, modifying, or using the software?
- 对重新分发、修改或使用软件有什么合规要求？
- How can the project enable contributors and downstream redistributors to comply with these requirements?
- 项目如何使贡献者和下游的再分配者遵守这些要求？
Copyright and Trademark
版权和商标
- Who owns the copyright on contributed code?
- 谁拥有贡献代码的版权？
- How can users license the project's branding?
- 用户如何许可项目的品牌？

Typically, the initial maintainers of the project form the TSC of the project. These individuals are likely from the founding orga- nization(s) of the project. The goal is to grow the TSC over time to include high-value contributors.

通常情况下，项目的初始维护者构成项目的 TSC。这些人通常来自项目的创始组织。我们的目标是随着时间的推移增加TSC的成员，吸引高价值的贡献者。

Project governance
项目管理制度
- Identify members of the TSC.
- 确定 TSC 的成员。
- Identify primary duties of the TSC, such as the following:
- 确定 TSC 的主要职责，如：
  - Overseeing software architecture and implementation activities
  - 监督软件架构和实施活动
  - Drafting the release plan and road map
  - 起草发布计划和路线
  - Working with other open source projects on which the new project depends
  - 与项目所依赖的其他开源项目合作
  - Setting the criteria for accepted/rejected code
  - 制定接受/拒绝代码的标准
  - Managing source code security issues
  - 处理源代码安全问题
Project processes: A project with a high degree of openness will have clearly defined processes for how things work in the community and how to contribute to the project. For starters, a clear development process should outline how to incorpo- rate code into the project, the release process and schedule of the project, and any requirements developers need to meet to get their code accepted. This should also include guidelines for participation that demonstrate community best practices for things like patch submissions, feature requests, bug reports, and signing off on code contributions.
项目流程： 一个高度开放的项目会清楚地定义社区工作事务流转以及如何为项目做出贡献的流程。对于新手来说，一个清晰的开发流程应该展示如何将代码合入项目、发布流程和项目的计划表、开发者需要满足的要求，还应该包含诸如补丁提交、功能请求、bug 报告以及代码贡献签名等的社区最佳实践的参与准则。
- Feature request
- 功能请求
- Release management
- 发布管理
- Code submission
- 代码提交
- Bug reporting
- Bug 报告
Project agreements
项目协议
- Develop a third-party contribution agreement to govern how the project will manage contributions from the community.
- 制定一个第三方贡献协议，以治理项目如何管理来自社区的贡献。

Set up project infrastructure

建立项目基础设施

Documentation
文档
Project website
项目网站
Wiki
Wiki
Community communication channels
社区交流频道
- Mailing list
- 邮件列表
- Live chat (e.g., Slack, Internet Relay Chat (IRC))
- 即时通讯（如 Slack、互联网中继聊天（IRC））
Collaboration platforms
协作平台
- Wiki
- Wiki
- GitHub repositories (or manage your own git servers)
- GitHub 仓库（或者自己搭建 git 服务器）
Bug tracking and feature requests
缺陷追踪和功能请求
Build system
构建系统

Apply recommended practices for your GitHub repo

Project launch

项目启动

Prepare the announcement

公告的准备

Brief launch partners.
简要介绍合作伙伴
Check that all project infrastructure is running, secure, and scalable.
检查所有项目基础设施是否正在运行、安全且可扩展。
Subscribe key project personnel to project mailing lists.
为关键项目人员订阅和配置项目邮件列表。
Make sure internal developers join and continually monitor the live chat.
确保内部开发人员加入并持续对内部沟通进行监控。

Press and analyst relations

媒体以及舆情监测

Establish launch strategy and timeline.
制定启动策略和时间表。
Draft press release and get signoff from all involved parties.
起草新闻稿并征得所有相关方的同意。
Identify spokesperson and media contact.
确定发言人和媒体联系人。
Create internal and external FAQ.
创建内部和外部常见问题解答(FAQ)。
Manage ongoing press and analyst relations.
对媒体和舆情进行持续监测。
Develop the ongoing public relations/analyst relations strategy.
制定持续的公共关系/舆情分析战略。
Engage a PR/AR firm if needed to deliver fully on the strategy.
如果需要，外部聘请 PR/AR 公司以全面实施该战略。

Announce and launch the project

宣布并启动项目

Release source code.
发布源代码。
Publish a road map, even if it is preliminary.
发布一份路线图，即使它是不成熟的设想。
Follow the open source development model.
遵循开源开发模式。
Monitor effects of PR/AR strategy across touchpoints.
综合监控和分析 PR/AR 策略带来的效果。

Summary of recommended practices for running an open source project

运营一个开源项目的实践经验

License

开源协议的使用

OSI-approved open source license offering the freedom to create and distribute derivatives.

通过OSI 批准的开源许可证赋予项目创建和发行衍生产品的自由。

Governance

治理模型

A governance model that gives equal footing to all current and future contributors to the project. Open source projects with an open and transparent governance model have better chances to grow, have a healthy environment, and attract developers and adoptees.

一种为项目的所有当前和未来贡献者提供平等地位的治理模型。具有开放透明治理模型的开源项目有更好的发展机会，以及健康发展的生态，并会吸引更多的开发人员和采用者。

Access

使用权

Project resources are accessible to any users or developers interested in the project. Anyone can participate in the project, and any participant can earn committer rights by contributing and building trust with the project's community.

对项目感兴趣的任何用户或开发人员都可以访问项目资源。任何人都可以参与该项目，任何参与者都可以通过贡献和与项目社区建立信任关系来获得提交者的权利。

Processes

流程

General project processes are documented for requesting a feature, reporting bugs, submitting code, etc.
一般来说项目中比如提出功能需求，为项目提交错误报告，提交代码等都会被文档记录。
Source code contributions are only committed through the project's defined process for incoming contributions.
源代码的贡献需要通过达成共识的提交流程进行。
All code goes through a peer review process.
所有代码都经过同行评审过程。
The process to become a committer/maintainer/reviewer is enforced by the project for consistency.
由于项目需要确保一致性，成为提交者/维护者/审查者需要严格遵守流程。
The project's community revises its processes based on incoming feedback to ensure they continue to meet the project's needs as it grows and scales.
项目社区根据反馈修改其流程，以确保随着项目的发展和规模变化不断满足和适应项目的需求。

Development

项目的发展

Responsibility for development is allocated to the individuals with the best capacity to deliver.
发展的责任需要分配给具有最佳交付能力的个人
The project enforces quality standards when merging code.
项目在合并代码时需要严格执行质量标准。
The project implements multiple levels of review before entering the final release.
项目在发布版本前需要进行多级审核。
Peer review is mandatory and public.
同行评审是强制性的和公开的。

Community

社区的运营

Accessible to newcomers---open development generally strives for inclusiveness.
对新手友好 —— 项目通常都是开放式开发。
Focused on visibility with emphasis on open decision-making processes and communication.
社区注重开放的决策过程和沟通方式，突出项目的治理透明和可视化。
Self-organizing; individuals contribute in their areas of interest or those of their employers.
良性的社区是自驱型组织；项目中的参与者，无论是个人还是组织都积极的在其关注和擅长的领域对项目做出贡献。
Resilient to organizational change, given that leadership comes with experience. If individuals cease to participate, there are others to take their place.
由于领导力来自经验和演进，因此参与项目需要能够适应组织的变化。如果有开发者停止参与，也会有别的开发者代替他们。

Community structure

社区结构

Meritocracy drives advancement and acceptance. Contributors who provide the most value to the community are granted project leadership roles.
采用精英管理推动社区的形成。那些为社区提供最大贡献的参与者会被社区选为项目的领导角色。
The project welcomes newcomers who have the freedom and access to participate in public discussions, development, and testing.
项目欢迎积极参与公共讨论、开发和测试的贡献者加入。
The project's hierarchy is scalable because it consists of maintainers who oversee specific bodies of code in levels that can be added or removed as needed based on the size of the community.
项目的层次结构是可扩展的，负责监督不同代码区块的维护者组成了代码维护团队，随着社区的规模的变化，这个维护管理的层级可以根据需要增加或减少。
Anyone can submit patches, and both developers and users are involved in the testing process. The roles of developer and user are closely integrated with open source development, allowing users to have a more direct path to influencing the project.
任何人都可以提交补丁，开发人员和用户都参与了测试过程。开发者和用户的角色与开源开发紧密结合，让用户有更直接的途径来影响项目。

Releases

版本发布

To protect certain users from the instability of rapidly developing software, projects provide stable releases that restrict the addition of experimental features to provide a reliable version that better supports use cases that rely on stability.
项目在不断的迭代，为了让某些用户避免使用不稳定的开发中版本，项目会将部分新的实验特性进行有限制的发布，确保用户在稳定版本中使用已经有过案例测试过的功能。
Weekly or monthly stable releases provide users and developers with the newest functionality after it has been tested.
每周或每月为用户和开发者提供经过测试后的最新功能的稳定版本。
Long-term stable versions extend to longer periods and often only include security patches and bug fixes.
长期稳定版本扩展到更长的发布周期，而且通常只包括安全补丁和错误修复。
The project has a defined cadence for its releases, with set goals per release.
项目需要有明确的发布节奏和每个版本的既定目标。
The release cadence and the goals to be met by each release are known to all project stakeholders.
发布节奏和每次发布要达到的目标是所有项目利益相关者都需要周知的。

Communication tools

沟通工具

Tools, including mailing lists, Slack, and IRC, are available and open to anyone wishing to participate in the project.

包括邮件列表、Slack 和 IRC 等在内的有效工具都可以被项目选用，并开放给任何希望参与该项目的人。

Transparency

透明度

Open source communities must be as transparent as possible to attract new participation, such as contribution transparency, peer review transparency, transparency of discussions, and transparency of promotion to committer or maintainer.

开源社区必须尽可能透明以吸引新的人参与，例如贡献透明度、同行评审透明度、讨论透明度以及向提交者或维护者晋升的透明度。

Documentation

文档工作

Availability of documentation covering architecture, APIs, installation guides, developer guides, development processes, participation guides, tutorials, etc.

文档是社区的重要组成，需要提供涵盖体系结构、API、安装指南、开发人员指南、开发过程、参与指南、教程等的文档，便于新用户了解项目，开发者参与项目。

Ongoing support

持续支持

After the project has launched, it is essential to monitor the vitality of the external community and support the project in various areas to nurture it and support the growth of its community.

项目启动之后，应对外部社区的活跃度进行持续跟踪，并从各个领域对项目提供支持，从而对其进行扶植并支持相关社区的成长。

Support the community

对社区的支持

Meet regularly with key stakeholders.
定期与主要干系人沟通。
Issue regular project updates through the website, PR, and social media.
通过网站、公关和社交媒体定期发布项目更新信息。
Respond to questions from the community in communication channels.
通过沟通渠道回复来自社区的提问。
Review patch submissions and pull them into the codebase as necessary.
对提交的补丁进行审查并在必要时拉入代码库。
Coordinate events to cultivate community and promote the technology.
通过活动协调，实现社区培育和技术推广。
Develop a set of KPIs for project success, track these metrics, and develop and implement plans to ensure the attainment of these goals.
为项目成功量身定制一套KPI，跟踪这些指标，制定计划并落实，以确保实现这些目标。

Support project infrastructure

对项目基础设施的支持

Keep content on the website and wiki up to date.
确保网站和Wiki的实时更新。
Provide ongoing guidance to trademark counsel.
及时为商标律师提供指导。
Manage trademark over time.
常态化的商标管理。
Manage domain registrations and renewals.
域名注册和续订管理。
Monitor and moderate communication channels (mailing lists, IRC, forums, etc.).
交流平台的监督与引导(邮件列表，IRC，论坛等)。
Maintain press and analyst relations.
媒体、评论员的关系维护。
Develop the ongoing PR/AR strategy, and engage with a firm to provide an appropriate level of service.
制定可持续的PR/AR战略，并通过与公司合作，谋求相应的服务支持。

Endnotes

尾注

SCA tools are applications that support software development teams to ensure open source license compliance and improve the security of the code. At a high level, they perform automated scans on source codebases. The tools also help the team identify open source components and their license and flag any known security vulnerabilities.
The Software Package Data Exchange® (SPDX®) is an open standard for communicating software bill of material information between organizations as well as from upstream open source projects into an organization.

SCA工具是软件开发团队用来检测开源许可证合规性并提高代码安全性的一系列应用程序。高级的SCA工具可以对源代码库进行自动扫描。它们还可以帮助团队识别开源代码组件及其许可证，并对已知的安全漏洞进行标记。
软件包数据交换®(SPDX®)是一项可用于组织之间或上游开源项目到组织间传递的软件物料清单开放标准。

Conclusion

总结

There are many ways to successfully open source proprietary technology. This paper provides a high-level overview of the process and can be used as a base for a more detailed internal plan. It is important to acknowledge that this checklist may not be complete and differs between organizations and projects. The goal is to provide the most common tasks associated with open sourcing internal projects and make them available to ease the process. While this process may seem complex and lengthy, many organizations have successfully followed similar procedures to bring internal code to market as an open source project and, in the process, have automated a lot of tasks and used project management tools to coordinate and track all tasks.

开源专有技术成功的途径多种多样。本文对这个流程提供了一种高级概括，可作为进一步制定详细内部计划的基础。需要强调的是，应当意识到这个清单可能并不完整，并且在不同组织和项目之间也有差异。其目标是提供与内部开源项目相关的最普遍任务，并帮助它们简化流程。虽然这个过程看起来可能复杂又漫长，但许多组织已经通过遵循类似过程，成功将内部代码作为开源项目推向市场。同时，这个过程也将很多任务环节自动化，并使用项目管理工具来协调和跟踪所有任务。

For more information on creating successful open source projects and working with open source communities, please visit the Linux Foundation website for a host of free resources available to help you with your open source journey.

了解更多关于创建成功开源项目以及与开源社区合作的信息，请访问Linux基金会网站，在这里您将获得大量免费资源，助您开启开源之旅。

Acknowledgments

鸣谢

The author would like to express his sincere appreciation to his Linux Foundation colleagues Hilary Carter, Jason H. Perlow, and Melissa Schmidt for their valuable reviews and feedback. This report has benefited immensely from their experiences and contributions.

作者对Linux基金会同事Hilary Carter、Jason H. Perlow和Melissa Schmidt表示衷心的感谢，感谢他们的宝贵点评和反馈意见。这份报告极大地得益于他们的经验和贡献。

Linux Foundation resources

Linux基金会资源

E-book: A Deep Dive into Open Source Program Offices
电子书：《带你深入开源项目办公室》
E-book: Guide to Enterprise Open Source
电子书：《企业开源指南》
E-book: Open Source Compliance in the Enterprise
电子书：《企业开源合规性》
E-book: Open Source Audits in Merger and Acquisition Transactions
电子书：《并购交易中的开源审计》
Linux Foundation Enterprise Guides
《Linux基金会企业指南》
Linux Foundation Open Compliance Program---Resources to support organizations with open source compliance.
Linux基金会开源规范(https://compliance.linuxfoundation.org/)——组织开放源码合规支持资源
TODO Group---Open community of practitioners and organizations that collaborate on best practices, tools, and other ways to run successful open source programs.
TODO工作组——一个由从业人员和组织组成的开放社区，他们通过最佳实践、工具和其他方式进行协作，以成功运行开源程序。
Software Package Data Exchange® (SPDX®)
软件包数据交换（SPDX® ） (SPDX®)

Feedback

意见反馈

The author apologizes in advance for any spelling mistakes or possible errors and is grateful to receive corrections and suggestions for improvements via ibrahimatlinux.com/contact.html

作者为任何拼写错误或其他可能存在的错误提前表示歉意，并对通过ibrahimatlinux.com/contact.html (http://www.ibrahimatlinux.com/contact.html)收到的更正和改进建议表示感谢。

About the author

作者简介

Dr. Ibrahim Haddad is Vice President of Strategic Programs at the Linux Foundation. He focuses on facilitating a vendor-neutral environment for advancing the open source AI platform and empowering generations of open source innovators by providing a neutral, trusted hub for developers to code, manage, and scale open source technology projects. Haddad leads the LF AI & Data Foundation and the PyTorch Foundation. His work and the work of both foundations support companies, developers, and the open source community in iden- tifying and contributing to the technological projects that address industry and technology challenges for the benefit of all participants.

Ibrahim Haddad博士是Linux基金会战略项目副总裁。他致力于为开发人员提供一个集编码、管理和扩展为一体的开源项目中心，从而打造一个与供给侧无关的环境来推进开源AI平台，进而为几代开源创新者提供支持。Haddad领导着LF人工智能与数据基金会和PyTorch基金会。他及这两个基金会都在为支持公司、开发人员和开源社区开展的解决行业与技术挑战、造福所有参与者的技术项目的识别和贡献而努力。

Twitter: @IbrahimAtLinux

推特: @IbrahimAtLinux

Website: IbrahimAtLinux.com

网址: IbrahimAtLinux.com

Fun project: Tux NFT Club

有趣项目: Tux NFT Club

Disclaimer

免责声明

This report is provided "as is." The Linux Foundation and its authors, contributors, and sponsors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this report. In no event will The Linux Foundation and its authors, contributors, and sponsors be liable to any other party for lost profits or any form of indirect, special, incidental, or consequential damages of any character from any causes of action of any kind with respect to this report, whether based on breach of contract, tort (including negligence), or otherwise, and whether they have been advised of the possibility of such damage. Sponsorship of the creation of this report does not constitute an endorsement of its findings by any of its sponsors.

本报告“按原样”提供。Linux基金会及其作者、贡献者和赞助商明确否认任何承诺（明示、暗示或其他），包括与本报告相关的可销性、不侵权、适合特定目的或标题的暗示性承诺。在任何情况下，Linux基金会及其作者、贡献者和赞助者都不对任何其他方的利润损失或任何形式的间接的、特殊的、偶然的或任何性质的后果性损失负责，无论是基于违反合同、侵权行为（包括过失），还是其他原因，以及他们是否被告知这种侵害的可能性。赞助编写本报告并不代表任何发起者对其调查结果的认可。

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quan- titative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

Linux 基金会研究部成立于2021年，旨在研究日益扩大的开源协作规模，提供对于新兴技术趋势、最佳实践和开源项目全球化影响的洞察。基于对项目数据库与网络的利用，并承诺使用定量和定性方法的最佳实践，Linux 基金会研究部正在打造开源见解的首选资料库，造福于世界各地的组织机构。

This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.

本报告采用知识共享署名4.0国际许可协议（CC4.0）进行许可。

To reference the work, please cite as follows: Ibrahim Haddad, "Artificial Intelligence and Data in Open Source: Challenges and Opportunities for Mass Collaboration at Scale," foreword by Dr. Seth Dobrin, March, 2022.

如需了解详细工作内容，请参考原文：“开源中的人工智能和数据：大规模集同的挑战和机遇”，作者：Ibrahim Haddad，Seth Dobrin博士（序），2022年3月。

企业开源指南

2022年8月24日 · 阅读需 89 分钟

赵振华

刘天栋，开源社

适兕

王峰，安势信息

张岩

侯胡的

Donald Liu，Linux Foundation APAC

Maggie Cheung，Linux Foundation APAC

Michelle Ko，Linux Foundation APAC

制定与实施开源软件战略

In partnership with:

2022年5月

Ibrahim Haddad, 博士

Executive Director, LF AI & Data Foundation

前言：David Marr, 副总裁，高通公司法律顾问

Front Cover

前言

在开源早期，（来自企业的）许多作为仅只是临时的、即兴的、符合许可要求的。在某些地方，根本就没有人注意合规问题。这并不是对当时任何特定的人的指控，因为不良的合规实践在现实世界会导致什么后果，在当时还是不确定。就像大多数新的实践领域一样，我们在不断地发展才会走向成熟，例如，在留言板上发生了激烈的争吵，在网页上专门设立了 “耻辱堂”-- 列出了那些已知的没有遵守许可条款的人，有的开源项目维护者甚至还威胁要提起诉讼。这些威胁性的诉讼，起初是由 “朝圣者” 提出的，他们要求的只是被告承诺负起许可里的相关义务（扣除向法院提起诉讼的费用）。但紧接着就有一些“投机者”，将许可合规性诉讼视为有利可图的收入来源，这被认为是一种投机作为，而并非开源社区的本意，这让开源社区的领导者警觉了起来，要坚决抵制这样的行为。

Ibrahim 在开源许可合规领域的经验丰富，这得益于他多年来在开源领域的卓越工作。他是那种在专业领域里出类拔萃的人，只要你进入开源合规，就一定知道他。就我而言，我第一次听说 Ibrahim 是在 2005 年，地点是在曼哈顿上西区的一家咖啡馆。我当时正在和哥伦比亚法学院的 Eben Moglen 教授谈话，Moglen 教授是通用公共许可第三版（GPL v3）的联合作者之一，Moglen 教授很有礼貌地纵容了我关于当时在开源许可合规这一相对较新的领域人才匮乏的抱怨，特别是缺乏那些同时拥有技术熟悉度和许可知识的必要技能。Moglen 教授认为我应该去会会 Ibrahim，于是，我在Ibrahim 的一次会议演讲中建立了联系。多年来，我发现他是一位亲切的同仁。Ibrahim 是一位热心肠的人，不仅是在开源许可的合规性的领域颇有建树，而且也热衷于将这些知识传授给更多的人。

在下面的篇幅中，作为读者的您，可以了解到开源对我们今天的数字世界有多么广泛的影响，以及如何推动现代社会，使得我们拥有很多便利。促成这些成果的是那些编写和贡献社区代码项目的大批的程序员，这些项目反过来又被产品公司所消费。在采用这些项目的公司中，软件工具、代码管理和法律相关的神秘混合体共同组成了我们所说的开源项目办公室，以管理各种开源许可及其在软件工程流程中的无数相关义务。Ibrahim 的这本小册子让这个领域的所有复杂问题变得简单明。

大卫-马尔 ，高通技术公司法律顾问部副总裁

Infographic

摘要

开源软件（OSS）已经改变了我们的世界，成为我们数字经济的支柱和构筑数字世界的基础。从互联网和我们日常使用的移动应用程序，到我们用来构建未来的操作系统和编程语言，开源软件都发挥了重要作用。它是技术行业的命脉。今天，开源软件为数字经济提供动力，并实现了改善我们生活的科学和技术的突破。它存在于我们的手机、汽车、飞机之中，也存在于家庭、企业和政府的治理之中。但是，在二十多年前，只有很少人听说过开源软件，它的使用也仅限于一小群专门的爱好者。

参与构建涉及软件的产品或服务的组织，无论其具体行业或部门如何，都有可能采用开源，并会参与到那些对其产品和服务至关重要的开源项目。各组织正在创建开源项目办公室（OSPO）来管理他们的开源活动，这些活动包含了从采用开源软件、遵守适用的许可到参与开放标准制定、基金会建设。

多年来，新的行业和数以千计的组织已经进入了开源生态系统。在早期，一些组织在没有适当的战略和执行计划的情况下贸然走进开源，他们并没有获得益处。而另外一些组织则采取了慎重的方法，接受了开源软件的方法论和工程实践，这使得他们在其行业或垂直领域的开源活动中脱颖而出，成为了领导者。为了指导企业对开源软件的持续使用和对开源生态系统的参与，企业已经制定了适合其组织限制和行业挑战的开源战略。

本指南提供了一个实用和系统的方法来建立开源战略，制定实施计划，并加速组织的开源工作。

导论

2000 年 12 月，IBM 宣布对 Linux 和开源软件投资 10 亿美元（换算为今天价值 15.8 亿美元），这是一个里程碑式的事件。这一承诺大大提高了 Linux 作为替代性操作系统的知名度。其他公司开始评估Linux，并评估哪些开源软件组件值得企业资助和采用。

企业级开源软件的可用性正在改变企业创建、开发、交付和维护产品和服务的方式。全球性的软件开发社区、开放的管理模式、对源代码的公开访问，以及对经批准的开源许可的采用，都对企业的思维方式产生了渐进式的影响。现在，组织领导者对如何采购、实施、测试、部署和维护软件有了不同的思考。这种转变可以带来一些好处 -- 降低开发成本、加快产品开发、提高代码质量等等。

一个组织开启开源之旅的第一步就是了解开源，如何从开源工程的努力中受益，参与开源项目，并与行业参与者、大学和开源基金会合作。虽然没有两个组织在使用和受益于开源方面完全相同，但所有成功的开源软件（OSS）实现都有两个共同的要素：一个强大的开源战略和一个明确的执行计划。

一般来说，我们把开源战略定义为一个简明的、高层次的文档将组织的业务目标与开源软件的使用和管理部门的指导联系起来。它是建立未来开源政策和流程的共同协定的参考文档。领导者必须考虑到他们的组织可以从开源战略中受益的方方面面。例如，许多组织将其作为实施开源最佳实践和步骤的指令。

为了发展和实现开源软件（OSS）战略，组织还必须阐明一套业务层面的目标，并确定采用开源和为集成到其产品和服务的项目做出贡献的所有限制。本指南将帮助你的领导团队制定一个适合贵司的战略--一个员工可以接受的战略，将你的开源软件开发和工程化的方法从消极应对转变为积极主动。

利用开源软件

从我们携带的设备到控制我们关键基础设施的系统，开源软件已经成为现代社会的重要组成部分。本节讨论了组织可以实现的六个战略目标，这取决于他们如何采用开源软件，将开源软件如何纳入产品和服务，以及如何参与开源软件项目及社区。

1.软件领导力。正如房地产价值就是地理位置一样，软件已经成为每个行业价值的决定性因素。软件的世界正在发生变化。开源曾经是边缘创业公司的小众技术，现在已经成为财富 500^1 强公司的主流技术。¹ 在各行业的垂直软件栈中，开源的渗透率已经从占整个软件使用量的 20% 上升到 85%。无论你身处哪个行业，无论你开发什么产品或软件，你都可能严重依赖开源。这种对开源软件的大量采用彻底重塑了技术格局。但这也要求软件的领导力需要发生转变，从封闭的专有软件模式转变为开放的开源软件模式，从使用开源软件转变为构建、改进和完善开源软件的开发者社区。

2.企业对开源的依赖。开源软件已经成为新的商业产品和服务的基础，其开发模式对许多企业的软件开发工作流程至关重要。一个企业很少能在不使用开源软件的情况下打造一个产品，或者采用一个不借鉴开源软件代码库的产品。

3.商业模式的适应性。商业模式是通过产品或服务创造价值的架构。暂时不论具体的许可要求，我们可以使开源软件适应各种商业模式，使开源软件适用于几乎所有行业里的行业软件供应链。表1 显示了一个企业使用开源软件实现不同商业模式的各种方式。

4.产品改进。开源软件可以通过两种方式改进企业的产品开发（图1）：

直接地，透过内部活动加强企业的开源开发和自身的产品或服务：（1）通过开源项目满足内部研发和产品团队的要求，（2 ）将内部代码提交给开源项目，从而减少开源代码分支和内部分支之间的差异，以及（3）帮助解决合规问题和应对相关查询。
间接地，企业的开源活动通过以下方式，不仅能提高自身人才的技能同时也帮助夯实了开源软件：（1）将产品中使用的上游代码变得更稳定；（2）参与内部政策讨论和决策，确保公司支持开源开发；（3）通过思想领导力和持续的代码贡献影响上游项目；（4）参与外部技术讨论，影响开源社区；(5）参与内部技术讨论，使企业的方向与特定开源项目社区的方向一致。构建开源利用开源进行建设为开源而建设建立在开源之上公司所创造的东西开源软件基本的低层开源软件库和组件开源软件开源产品与服务客户所购买的商品专家服务和产品在开源之上的专有软件或服务集成与服务更上层的软件栈

表 1

5.聚焦/加速创新。正如谚语所说，“众人拾柴火焰高”。在开源项目中，更是人多手快。跨组织的协作者可以更快地对他们的共享代码进行修改和修订。因此，企业开发者可以（ 1 ）在他人的工作基础上进行构建，（ 2 ）在上游开源尝试新的功能和优化，要比在公司内部更快地实现技术上的突破；（3）将员工的工作集中在更高的软件栈级别的差异化上，提高产品对消费者的独特价值。在这样做的过程中，员工为一个组织的整体创新途径做出了贡献。小型初创企业可以更快地将新的想法推向市场，而大型公司可以尝试新的想法，而无需面对丧失对其知识产权控制的风险。

6.开源研发有助于推动企业创新。参与开源项目使企业能够利用外部的研发实力（R&D），发现商业化的惊爆点机会，并利用这些突破性的产品和服务提高企业进入市场的速度。对开源研发的共享访问推动了这种跨业务部门的创新。它是许多创新加速器之一，如学术研究、企业风险资本、行业合作、内部研发和创业生态等。

图 1

图 2

为企业开源做准备

IBM 在 2000 年对于开源的投资，开创了企业采用开源的模式。从那时起，成千上万的公司进入了开源生态（图3 ）。所有这些公司在与开源软件以及社区合作方面都有很多收获；通过企业的参与，开源模式已经成为软件开发的新常态。企业若加入开源软件社区，如何最大限度地减少企业学习曲线，并能够加速消费和参与的回报？以下部分将探讨作者从二十多年来企业在开源软件方面的经验中获得的一些经验。

找出企业对开源软件的依赖性

提高组织的开源参与度的第一步是确认组织对开源软件的依赖程度。随着对开源软件依赖性的增加，企业有几种选择可以探索。一种选择是关注许多业务部门使用的软件。第二个选择是关注那些比其他软件具有更大合规风险的软件。例如，移动应用程序和嵌入式硬件可能比你的数据中心代码带来更大的风险。通过不断的追踪这些选项，你可以在多个业务部门或高风险领域展示投资回报，并为获得更多资金和支持提出充足的理由。

另一个选择是把你的贡献集中在直接有利于贵司的战略和产品的上游项目上，而不是在不同的相关的项目中纠结。如果你的企业认为开源工程是一个成本中心，那么就把重点放在支持产品开发的开源项目上。每年对组织的产品组合进行一次审查。确定哪些产品借鉴了哪些开源项目，然后优先考虑那些支持最多产品的开源项目。这种方法使有限的软件工程资源得到最大的利用。

找出企业的开源技能组合

一旦你确定了贵司在哪些方面依赖开源，然后就可以开始确定需要什么样的专业知识了，以及是选择在内部发展还是从外部获取。通过从开源软件社区雇用开源开发者，贵司可以获得技能、赞誉和指导的能力。

两到三个开源开发者雇员可以对一个大型项目（如 Linux 内核）产生明显的影响。他们还可以为公司吸引到其他开发者成为贵司的雇员，并能够指导初级开发人员。企业的目标是找到在社区中哪些得到了同行认可，并拥有影响力的开发者。

在招聘开源开发者时要考虑这四个关键要素：技术领域的专业知识，开源方法论和经验，工作实践，以及企业利益和候选人利益的一致性。当高级开源开发者的兴趣和技能与企业在特定项目中的利益相一致时，激励他们就更容易。例如，一个 Linux 内存管理专家可能不喜欢在文件系统上工作，（所以最好的选择是让内存管理专家仍然开发内存管理，）找到这样的匹配是建立长久关系的关键。

考虑加入.TODO.小组

TODO Group 是一个由众多科技公司所组成的虚拟小组（集合），这些来自企业的成员对各自的开源项目办公室的政策、实践和实用性开展协同合作。成员的协作是作为 Linux 基金会下的一个社区项目来管理的，TODO 小组是那些刚刚开始建立开源项目的公司的可用资源。TODO Group 写作了《开源项目办公室指南》，其成员经常在各类开源会议上介绍最佳实践。请访问 todogroup.org 了解更多。要加入，请联系info@todogroup.org。

图 3

制定开源战略

开源软件是以规模化交付软件的最具影响力的方式。利用开放生态的力量来解决复杂问题的能力是独一无二的，因为任何人都可以在其中贡献。开源是可能比封闭源码的替代品更有影响力，前提是需要一个坚实可靠的开源战略引领它时，方能实现开源的全部力量。在制定开源战略时，有许多问题需要回答。企业应该在这个过程中尽早针对这些问题，提出解决办法。一个开源战略应该解决四个基本要求（图4 ）：

企业寻求参与的开源项目。
企业希望密切联系的相关开源项目社区。
企业开源治理的有效性。
企业文化的开放性，以及它是否会欢迎或拒绝开源的努力与活动。

确定企业的目标

本节涵盖了一个组织在创建其开源战略之前需要解决的三个主要问题。

企业目标

开源战略如何帮助你实现企业的总体目标？

你回答的第一个问题将确定开源在你的整体企业目标中的位置。在许多领域里，公司可以从开源的使用和贡献中获益。开源战略通常解决具体的需求。一旦你确定了这些需求，你就可以把注意力集中在开源能给你的组织带来最大好处的领域。你的目标可以包括以下任何一项：

创建一个长期的、高质量的路线图，在产品生态系统中占据领导地位。
降低构建和维护产品或服务的成本和复杂性。
建立一个差异化区隔的定位，以更高的利润率为目标。
通过构建开源替代品，使竞争产品或服务商品化。
提高产品和服务的整体质量。
通过公开的参与开源，提高外部知名度和品牌认可度。

图 4

知识产权战略

开源战略如何帮助你的组织实现其知识产权（IP）战略？

开源软件可以成为企业建立满足其需求的产品和服务的有效途径，而无需在编码和设计方面投入大量资金。它往往是商业产品的原型，企业利用开源代码开发产品或服务，并最终推向市场和销售。开源也是企业实现其知识财产权战略的绝佳方式。开源许可与专有许可不同，因此企业必须考虑许可的差异如何影响他们从开源的使用和开发中获益的能力。商业目标可以包括以下任何一项：

确定一种许可战略，使组织能够从外部参与中获得最大的利益，并仍然能够改进专有产品。
通过遵守产品和服务中使用的开源软件的许可来减轻知识产权风险。
通过改进核心的开源组件，显著地提升专有知识产权的差异。
将原来的专有源代码采用开源许可发布。

许多企业发现清单和模板对指导开源许可下的代码发布很有帮助。每个案例都是不同的，但发布开源的机制是相似的。Linux 基金会已经创建了一个指南，” 开始一个开源项目”，以指导组织完成这个过程，从项目的选择、预算和法律考虑，到项目的启动和维护。它提供了一个样本清单，作为贵司从零开始创建开源项目的绝佳案例，以便各个团队了解开源过程中所涉及的内容。

开源许可与专有许可不同，因此组织必须考虑许可的差异如何影响该组织从开源的使用和发展中获益的能力识别你的参与阶段

通过开源提供机会

开源战略如何帮助你抓住本来无法实现的机会？

开源还提供了独特的机会，这些机会企业只有通过开源战略才能获得。其中包括：

通过将研发投资集中在改善关键的开源技术，补充差异化的产品能力，从而实现市场领导地位。
通过支持关键的开源倡议和联盟来捍卫现有的市场地位。
将选定的专有能力作为开源发布，以扰乱竞争对手或竞争性市场。
利用开源来创造公平的技术竞争环境。
在产品中纳入现成的开源商品化能力和市场加速器，以降低长期的售货成本和交付产品的单价。

图 5

识别你的参与阶段

组织通过四种主要的开源软件策略：消费开源软件、参与、贡献和领导力。每一种策略都要求企业在前一种策略上取得成功，而一个组织的进展程度完全取决于该企业总体。图5 说明了这四种主要策略。请注意，当一个企业从一个阶段过渡到另一个阶段时，中间是有过渡期的，有一个重叠的区域。工程师推动了消费和参与的早期策略。工程师利用各种开源组件的技术优点来加快开发速度，但他们很少参与维护这些组件的项目。随着时间的推移，组织的高层了解到这种开源软件使用的价值。随着开源软件获得牵引力，商业需求开始推动这种开源软件的参与，参与开源软件有助于确定商业战略。一些公司作为消费者实现了他们的目标。其他公司在参与的其他阶段看到了战略优势。他们有时会设立一个开源项目办公室（OSPO）来监督这些阶段的战略规划和执行。本节有助于确定贵司的开源现在在阶段，想要达到那个阶段，以及如何到达。

消费

组织的共同出发点是采用开源。积极地消费开源组件将提高贵司的产品和服务的差异化能力，可有效减少提供这些产品和服务的总体时间和成本。以下是对这一战略至关重要的行动项目：

建立一个开源审查委员会（OSRB），作为所有开源活动的信息交流中心，其中包括许可合规
使用战略分类方案，从而来指导关于消费什么开源软件的决定。
清点使用中的开源软件的许可，以确定企业是否遵守了所有的许可义务。
部署自动工作流程软件来评估/批准开源的使用。
为工程、产品管理和法律方面的人员和基础设施的增量投资制定计划，以管理封闭源码和开源软件的复杂组合。

参与

一旦贵司成功地在产品或服务中使用了开源，就可以继续扩大战略了，参与到开源社区中。除非贵司已经雇用了有经验的开发人员，否则可能需要更加密集地参与到社区中，从而提高贵司的知名度，并开始吸引所需要的人才。以下是参与这个阶段的必要行动项目： - 对社区交流平台保持关注，如聊天服务器、邮件列表、论坛和网站，以保持对项目发展的关注。

对社区交流平台保持关注，如聊天服务器、邮件列表、论坛和网站，以保持对项目发展的关注。
赞助项目活动和基金会，以增加企业的曝光度。
教育开发者如何参与开源项目并贡献。

贡献

一旦贵司意识到定期参与到开源社区的益处，就可以评估向项目和提交代码的优势。代码贡献者有助于构建项目未来的功能，因此向那些对贵司的商业目标至关重要的开源项目贡献源代码是影响这些项目和建立积极声誉的最佳途径。以下是对这一战略至关重要的行动清单：

雇用一名专职主管来领导开源战略和管理开源项目办公室（OSPO)。
雇用对贵司的产品和服务至关重要的开源社区的贡献者和提交者。
部署开源协作工具，以支持开源的使用和提交。
增加开源开发者资源（投入)。
逐步投资于工程、产品管理和法律资源，以便与外部开源社区建立密切联系。

领导力

开源战略的最高形式是领导力。开源的领导者通过与项目成员建立信任并保持高水平的持续贡献来赢得其战略地位。领先的组织可以利用技术上的新兴趋势。为了建立领导力，这种战略需要对目标开源社区和联盟进行较大投资。以下是保持领导地位必不可少的行动清单：

在工程、产品管理和法律资源方面，对外部开源社区和行业联盟进行逐步增加投资。
增加与目标开源社区的密切联系。
有选择地参与开放标准，以推动组织的需求和要求。
与开源基金会合作。
建立一个开源项目、组织或基金会。

开源战略的最高形式是领导力。开源的领导者通过与项目成员建立信任，并保持高水平的持续贡献来赢得其战略地位。领先的组织可以有效利用技术上的新兴趋势

转型

作为一个技术驱动的组织，贵司已经在评估、使用和部署开源软件。你很可能正在参与并可能对项目做出贡献。理想的情况是，你的开源团队指导这些工作，减少风险，并利用你的参与来有利于你的战略。图.6 说明了参与的阶段。前面的阶段有无指导都会发生，而在领导阶段的成功只有在开源项目到位的情况下才有可能发生。

图.6 还说明了四个关键战略和每个战略中的主要活动。目的是强调开源的逐渐扩散和企业可以采取的行动，以让企业能加速采用，并在开源中积极地贡献。

图 6

为执行工作而建立基础设施

一旦贵司制定了开源战略，就需要建立基础设施来支持开源相关的工程。

图.7. 显示了该基础设施的四个关键要素：社区参与、开源贡献、开源合规和开源使用。

该基础设施支持组织和其开源项目之间的社区内所有的互动--包含消费、合规和贡献代码。

从消费与合规开始

消费与合规是密切相关的，特别是在企业环境中，消费通常意味着在产品或服务的一部分中使用开源。因此，我们经常把这些核心要素放在一起表示，至少从基础设施的角度来看，因为任何对开源软件的商业使用都需要遵守相应的许可。图.8. 列出了这些组件。

制定战略框架。开源的合规性应包括法律合规性和风险容忍度战略、并购（M&A）和企业发展、软件采购和管理合规性查询的框架。
定义流程。开源项目办公室（ O S P O ）定义了贵司如何处理代码分发、审计、通知和使用的流程和政策。此外，OSPO 还会发布内部政策，实施强制遵守合规准则的流程，并提供关于开源许可的培训。
公开分享你的计划。我们建议建立两个网站来支持贵司的开源计划-- 一个用于企业内部交流，另一个用于和企业外部交流。组织在其内部网上发布其开源政策和流程，在那里他们可以解释开源的合规性并引导员工使用可用的服务。企业还可以利用其面向公众的网站来发布其开源项目的信息，分享公告，并可能发布合规报告、通知和源代码。
建立团队。建立专门负责合规的团队。根据他们的角色和责任进行培训。商定他们的成功指标。
协助各方利益相关者。对每一位处理软件采购、开发、分发和聘雇的员工进行开源合规性教育。建立一个流程，让员工可以提出问题并获得答案。
获取工具。考虑投资于能自动化发现和审计过程的软件组成分析工具。这种工具将协助合规团队和各方利益相关者。
将合规性整合到流程中。将开源的合规性直接整合到开发和质量保证（QA）流程中。理想情况下，应将合规性工具直接整合到构建系统中。
参与到社区。某些基金会专门关注开源的采购、分发和合规性。例如，Linux 基金会托管了几个支持和实现开源合规活动的倡议。制定一个参与这些基金会的计划可以使企业的整体业务目标受益。请参考文末 Linux 基金会资源的章节，以获得这些倡议的链接。

图 7

执行核心的合规实践

图 8

每个组织都必须有关于开源软件的政策、准则和流程。因此，其中一些建议可能并不完全适合贵司目前的合规性框架，但仍然可以把它们作为改进的思路。

识别所有的源代码。软件通过三个主要来源进入组织：由组织的开发人员引入的源代码，通过第三方商业软件供应商引入的源代码，以及 GitHub 等开源渠道。我们推荐所有集成到产品或服务中的源代码都要经过合规流程。通过这个过程，组织将确定源代码的来源和许可，并制定一个计划来满足所有适用许可的义务。
建立一个经常性的扫描模式。组织采用各种方法来管理使用开源的审批。鉴于开源软件的大规模采用，这些审批应保持尽可能的高效。一些组织要求开发者申请正式的授权来使用开源，并在获得批准后才将其与产品代码库整合。在某些情况下，开发人员在急于完成工作的情况下，可能不会发出合规工单来请求授权使用所需的开源。因此，关键是要有一个额外的检查点或方法来捕获进入软件栈的未经批准的开源。贵司可以通过每隔 X 周定期对整个软件堆栈进行全面扫描，并识别没有相应合规工单的组件来解决这种情况。每个组件将被创建一个新的合规性工单，并通过正常的合规性验证过程推送. 。
逐案核实合规性。在某种情况下批准使用开源软件并不一定适用于所有情况。合规问题可能会出现，这取决于使用特定组件的背景，以及它与其他在不同许可（开源或专有）下许可的组件之间的互动。我们建议，每次开发人员修改以前批准的开源组件或计划使用以前批准的组件时，都要进行一次新的扫描。这样就会产生一份新的材料清单，许可的确认，以及在当前情况下使用开源代码的核准。
在升级开源组件的版本时要验证许可。开源组件的许可变化可能发生在项目主要版本的升级。当开发者升级开源组件时，我们建议验证许可。如果许可有变化，则需要创建一个新的合规工单，以请求批准使用当下在不同许可下的开源组件的最新版本。
解决合规性问题。当源代码扫描器检查代码库时，它可能会根据软件组成分析（SCA）工具中配置的规则和策略来标记可能的问题。一旦合规性工程师确认了这些标记的准确性，我们建议与开发人员一起解决这个问题，对解决方案进行扫描，并从更新的源代码中生成一个新的材料清单。
保存所有的许可信息。我们建议保存所有相关的许可信息，如 COPYING、README 或 LICENSE 文件，为法律审查做准备。许多组织要求开发者将这些文件附在特定的开源组件的合规工单上，这样工单审查员就有了评估合规状态所需的所有信息。
保持讨论记录。按照之前的做法（保存许可信息），我们也建议在合规性工单中保留一份导致批准或拒绝特定开源组件的讨论摘要。在试图确定批准某一特定软件组件的依据以及如何解决可能存在的问题时，这样的文件可以证明非常有用。
提供一个书面提议。特定的开源许可要求项目通知软件的接受者各种许可信息，并提供对源代码的访问。我们建议使用清晰的语言，并包括产品或服务中使用的所有开源软件。组织通常把书面要约和开源许可信息放在产品本身、产品文档和网站上。其位置得依据产品或服务的不同而变化。
管理对开源软件的修改。我们建议在修订历史（又称变更日志文件）中捕获所有对开源源代码的修改。在诸如重新发布修改过。的代码时，根据有效的许可，将对源代码的修改标记。有些公司选择在提供原始的开源源代码的同时提供公司贡献的补丁文件，以便公司的修改可以被识别，并与原始开源包分开。
.追踪退役的组件。在某些情况下，开发者可能会停止使用以前批准开源组件。我们建议开发者重新打开相应的合规工单，并更新工单以反映这些已经退役的组件，并提供关于构建编号和具体使用信息的细节。这一行动将触发给产品或服务用户的开源许可信息的更新。
.避免复制 / 粘贴。开发人员必须避免在没有批准文件的情况下将开源代码复制和粘贴到专有或第三方源代码中（或反之）。这种行为会对许可的合规产生严重影响。
避免混合使用不同许可的源代码。有些开源许可与其他许可不兼容，有些则与专有许可不兼容。因此，我们建议在混合不同许可下发布的源代码之前，寻求贵司的法律顾问的指导并获得批准。
保留原始许可信息。我们强烈建议保留任何开源组件中现有的版权、归属和许可信息。
.更新外包协议。修订软件外包协议，以反映对开源合规做法的遵守，并规定所有进入的源代码都要经过合规程序。

图 9

为贡献提供适当的架构

当归属把精力扩展到对开源项目的贡献时，就需要基础设施和框架来支持这些行为，执行公司层面的贡献政策，并阻止临时性即兴做法。通常一个支持开源贡献的基础设施有三个要素（图.9 ）。

对贡献的支持。支持贡献是至关重要的，包括提交政策和流程；贡献参与到开源项目的准则；对开发团队的培训，使他们了解政策和流程；负责批准贡献请求的小组；以及向支持产品开发的开源项目做事情的明确计划。
设立专门的开源小组。一个专门为参与上游的小组可能是有价值的。这个小组，有时被称为开源项目办公室（OSPO），将支持与开源项目和基金会的持续合作，并帮助建立组织的开源消费、合规性和合规性基础设施。
参与开放标准。参与相关的开放标准机构和行业组织对开源贡献基础设施至关重要。指派人员负责让组织及时了解相关标准的变化。

更新并购实践

更新有关并购或其他公司交易的政策和准则，以覆盖开源软件。如果贵司正在考虑合并或收购，那么应该构建相应的合规计划，以提供必要的信息披露和陈述层次。企业发展必须授权合规团队在任何合并或收购之前评估源代码，以避免可能破坏协商或影响可能估值的意外情况。全面的代码评估保证了对收购公司的软件资产的准确估值，并减少了意外的许可问题对未来价值的破坏。企业还必须更新其要求披露开源资产的尽职调查做法，并向其员工提供关于开源许可的指导。在购买协议中，收购方公司也可以包括要求对方在交易中披露开源的条款。

参与合规性倡议

Linux 基金会托管了几个旨在改善自由和开源软件许可的合规性的计划。OpenChain 和软件包数据交换（SPDX）是两个重要的 Linux 基金会开放合规计划（Open Compliance Program）项目。我们强烈建议企业参与这些计划，以支持自身的开源合规工作。

OPENCHAIN

OpenChain 项目是一个高质量的开源合规计划的标准。该项目通过使开源许可合规性更直接、更一致来建立对开源的信任。OpenChain 由三个核心要素组成：

OpenChain.规格定义了每个质量合规计划必须满足的一组核心要求。
OpenChain.课程为开源流程和解决方案提供了教育基础，并满足了 OpenChain 规格的一个重要要求。
OpenChain.一致性允许组织展示他们对这些要求的遵守。因此，对于软件供应链的参与者来说，开源许可的合规性变得更加可预测、可理解和高效。最重要的是，OpenChain 是一个不断增长的社区，社区的成员是开始开源合规之旅的组织的优秀资源。

SOFTWARE.PACKAGE.DATA.EXCHANGE

软件生态系统已经变得越来越复杂且相互关联。一个公司不可能轻易地对其软件资产和许可有一个准确和最新的看法。这种复杂性也阻碍了公司识别和抓住机会来降低其软件成本。软件包数据交换（SPDX）解决了这种复杂性。

SPDX 是一种标准化的格式，用于捕获、存储和共享有关软件包的数据，如开源软件包。SPDX 是一个由社区驱动的项目，托管在 Linux 基金会，帮助软件开发者和工程师捕捉和分享关于软件包、许可和依赖性的重要元数据。 SPDX 还通过规范整个软件供应链的许可信息共享方式，帮助促进自由和开源软件许可的合规性。它通过为公司和社区提供一种标准格式来分享有关软件许可和版权的重要数据，从而精简和提高合规性，从而减少冗余。

为成功培养贵司的人才

为团队指定一个领导者

雇用或提拔一个对开源开发背后的方法论有深刻理解并具有领导特质的人，来推动贵司的开源工作。候选人应该具备几个特点：

坚实的工程背景。
在开源组织中的人脉丰沛。
对开源许可的深刻理解。
具备行业最佳实践的知识。
在建立企业范围内的政策和流程方面的知识和经验。
了解与组织的产品和服务相关的技术知识。
具备开源的历史视角。
了解各种技术项目社区运作机理。

TODO Group 已经为这个角色发布了一个工作规范的模版，你可以根据自己的需要进行定制：https://todogroup.org/blog/sample-job-req.

将开源职业道路正规化

在贵司的人力资源（ H R ）系统中创建一个开源开发人员的路线图，以便被雇用为开源开发人员的人看到他们在组织内而不是在其他地方的职业潜力。组织还应该调整基于绩效的奖金，以包括开源开发工作目标。专有/封闭源代码开发人员的绩效指标往往与开源开发人员的绩效指标不同。在现实中，所有的现代开发者都必须使用开源；世上并不存在完全的闭源开发者。相反，有时他们的代码会留在组织内部，有时他们会发布代码，也许是把它贡献给第三方，或者作为一个新项目发布。人力资源的职业路线图和激励措施应该反映每个组织的结构和对开源的态度。

最后，不管一般的公司其它政策如何，至少应该有一条允许开源开发者在家工作。最近，我们目睹了各公司在家工作的政策发生了逆转；许多公司甚至禁止或严格限制在家工作。在开源世界，在家工作的政策几乎是强制性的，因为开源专家分布在地球的各个角落，而这一政策往往是雇用他们的唯一途径。灵活的工作政策在操作上也有好处。

提供开源培训

教育是开源项目办公室的一个重要组成部分。它分为两类：扩大开源技术知识的技术培训和确保员工了解使用开源软件的政策的合规培训。培训旨在提高对开源政策和战略的认识，并围绕开源许可的问题和事实以及在产品和软件组合中纳入开源的商业和法律风险建立共同的理解。培训也是宣传和推广合规政策和流程以及培养合规文化的一个途径。没有一个组织可以在一个特定的领域内雇佣所有顶级和最专业的开发人员。

这个理念也适用于Linux 内核和任何其他著名的开源项目。因此，贵司必须提高开发人员在特定技术领域的能力，并对他们进行开源开发模式和开源合法合规的基本概念教育。培训课程的样本包括：

核心开源技术的技术培训。
开源开发的方法论。
开源许可的合规。

组织可以利用其他资源，如 OpenChain 课程和 Linux 基金会免费的 “开发人员合规基础知识“ 培训课程。

鼓励内部协作

促进在其产品中使用相同开源项目的业务部门之间的内部合作，可以提高开源工程团队的影响力。这些合作可以采取多种形式，如：

为产品开发人员提供培训。
举办关于特定主题或问题的研讨会。
开发新的功能。
排除故障并解决问题和错误。
对企业没有资源支持的现有代码进行上游处理。
帮助企业从一个旧的分叉版本过渡到主线版本。

这些内部合作有很多目的，其中有两个特别重要：

它们提高了开源团队在项目社区或企业内部团体中的知名度。
它们培养了内部的开源专业知识，为企业成为研发和产品团队的上游合作伙伴做准备。

内部协作是具有挑战性的，特别是在大公司。开源使员工的激励与上游合作关系的巨大利益相一致；团队合作能实现这些利益。

内部协作是具有挑战性的，特别是在大公司。开源使员工的激励与上游合作关系的巨大利益相一致；团队协作能实现这些利益

提供灵活的.IT.服务

开发人员在开源开发中主要使用三个领域的 IT 服务。贵司的开源开发者应该在内部使用这些服务：

知识共享（维基、协作编辑平台和公开的网站）。
交流和解决问题（邮件列表、论坛、Slack和类似的实时聊天）。
代码开发和发布（代码库和错误跟踪平台）。

建立灵活的 IT 服务，使开源的开发者可以以最小的摩擦在开源项目上进行交流和合作。这些服务通常需要一个没有限制性 IT 政策的 IT 基础设施，因此这个建议可能与现有的 IT 政策相冲突。解决这些冲突并允许开源开发者使用他们需要的工具。

确保贵司采用的工具与外部使用的工具相匹配。贵司的许多基础设施服务将随着贵司的开源文化而有机地发展，但如果了解它的必要性，那么就可以计划它并指导其实施。

通过有意义的指标追踪进展

一旦一个组织开始实施开源的最佳实践，它将需要适当的衡量标准来驱动所需的开发行为。然而，产品组织的传统指标并不能在开源开发中转移和应用。例如，你可能会跟踪更改集或接受的代码行的数量来衡量你的开源开发的影响，但你会错过有多个理想功能在上游实现的实例，因为你的开源开发者有效地游说了上游的支持。在这种情况下，团队成员在上游的技术领导力减少了组织在下游的维护工作。因此，你跟踪的指标应该考虑到这两种类型的活动。首先，创建一个内部系统，跟踪开发人员的贡献和影响。衡量标准可以包括上游开发、对产品团队的支持、知识转移（即指导、培训和通过维基、邮件列表、

论坛、S l a c k 等的分享）、知名度（即出版物、访谈）、新开源项目的启动以及与其他团队或小组的内部合作。以下是一些需要考虑的主要指标。

提交和核对补丁的数量。提交和核对补丁的数量是最基本的跟踪指标。它应该让你对项目的日常活动有一个概念。它包括谁编写了代码，它的提交项目，以及接受提交的日期等信息。把这个指标与下面的其他指标结合起来，或者找出值得进一步定性分析的数据。
补丁的类型。我们可以把补丁的类型，或代码提交，分为六类：

错误修复
对现有功能的改进
实施新的次要功能
实施新的重要功能
提交测试案例和测试代码
撰写文档

补丁接受率。为一个开源项目写代码并不意味着能够在同行评审过程中被接受。有时，开发者必须在很长一段时间内多次修改它。提交给项目的补丁与接受到代码库的补丁数量之比是一个有价值的指标，可以跟踪贵司的工程师是如何成功地让代码在第一时间被接受。
作为协作项目的一部分而提交的补丁。如果贵司的开源工程师直接代表其他团队提交代码--与其他内部团体或外部组织（如大学）的协作，那么你可能想跟踪这些提交对上游工作的影响。
能见度。通过开源工程，贵司可以在社区内影响一个项目的走向。开发人员通过不断为项目及其开源社区做出高质量的贡献来赢得同行的尊重。为了衡量开发人员的知名度，可以考虑跟踪出版物、博客文章、会议发言和媒体提及的数量，例如，鼓励开发人员花时间提高他们的开源领导力。
新项目和倡议。如果贵司目标之一是创建新的项目，以填补未满足的需求，那么你可以跟踪启动的新项目的数量，并激励团队创建这些项目。
对开放标准的贡献。有时，一个开源项目为一个开放标准提供了现实的参考。在这种情况下，你可以跟踪员工对开放标准的贡献。

将开源方法应用于内部项目

内源是将开源方法应用于企业内部的开发项目。其目的是在企业内部孵化与开源社区内孵化相同的能力，并促进跨职能和涉及多个产品领域的新的员工对员工的关系。开源原则在分布于企业内部的大型项目上运作良好。许多财富 500 强公司出于同样的原因在外部和内部都采用了这些原则：更快的发布、提高质量、增加创新、增加沟通和信息共享、降低成本、增加和更有效的合作，以及提高员工的士气和留存。

内源使得贵司准备好与外部开源社区的有效合作。它鼓励贵司员工与其他地方的同事和外部开源成员进行互动，而毋需要转换背景。熟悉这种开发模式的新员工可能更快融入贵司的工作流程。最后，商业伙伴可能已经在使用许多这样的开发实践，因此贵司的采用可以加强与商业生态系统的整合。

内源的实践

内源意味着代码库向企业的所有员工开源，并允许任何员工使用它们，可以对项目进行改进，或根据需要分叉它们。建立一个团队，来管理代码、审查以及应用代码的提交。使用内源方法的公司使用相同的邮件列表、聊天室和工单系统，这些系统对组织中的任何人完全开放，用于讨论修改和提问。请查看参考资料以了解更多关于实施内源做法的信息。

基本的开源原则

实施正确的内源实践有几个基本原则。本节将分别介绍这些原则。

支持贵司的开发人员出席和参与开源会议和活动，包括当地社区聚会、黑客马拉松和峰会。这种参与有助于他们与同行联系，建立关系，进行面对面的交流，并参与指导项目方向的技术讨论。

透明度。所有的内部软件项目在默认情况下应该对所有的员工都是可见的，而且沟通渠道应该尽可能的开放。这种透明性使团队之间的交叉交流成为可能，并为员工提供了一个感受共同责任感的机会。它也有利于贵司中人们之间的临时沟通和关系建立。偶尔，项目需要额外的保护，因为与他们的发展有关的敏感信息，这些可以对选定的小组和个人保密。然而，这些应该是例外，而不是常规。
分叉。允许任何可以看到内部代码的人创建一个副本（分叉），并自由地进行修改，只要他们使这些分叉对所有人可见。这种方法鼓励组织内各团队对软件堆栈有更多的了解和更好的整合，并交叉交流想法。
拉取 / 合并请求。允许项目以外的人建议和提交修改。鼓励员工欢迎来自自己团队以外的输入，并认真对待他们的提交。
同侪评审。同侪评审可以减少风格上的差异，促进有益的对话，并保证项目的质量标准。对代码库有深刻理解的人应该在提交者提交代码之前始终对其进行审查。这些同侪审查者也应该向提交者提供反馈，以便后者随着时间的推移完善他们的风格，增加被接受的可能性。
尽早发布，经常发布。更频繁的发布，更少的功能和定期的更新发布，对提高代码开发效率。
测试。将单元和集成测试直接纳入软件开发过程中，以便进行修改而不必担心产生新的问题。尽早发现并解决潜在的问题，避免积累技术债务。
持续集成。软件开发过程应实施持续集成，以自动测试每一个拟议的变化。
文档。所有的软件项目都应该包括文档，描述软件是做什么的，为什么它很重要，如何运行它，以及如何参与其开发过程。
问题跟踪器。每个人都应该能够提交 bug，提出功能请求，或提交问题。所有内部项目的问题跟踪器都应该对这些提交的问题开放。这种开放性增加了他们收到反馈的数量。它也扩大了其他团队的可用专业知识。

提高开发者的能见度

主办和参加开源活动

支持贵司的开发人员出席和参与开源会议和活动，包括当地社区聚会、黑客马拉松和峰会。这种参与有助于他们与同行联系，建立关系，进行面对面的交流，并参与指导项目方向的技术讨论。

如果贵司的开发者有其他人可能感兴趣的工作任务，那么就帮助这些开发者准备演讲。考虑赞助大大小小的活动，以提高项目社区内的知名度。这些活动也是寻找人才的绝佳场所!

同时查看 Linux 基金会的活动，确定与你的兴趣相关的活动。鼓励你的开发人员扩展或分享他们的知识，或派管理代表去确定潜在的雇员和招募新的人才。

与大学合作开展研究和开发项目

许多大学和学校都渴望与那些为学生提供学习机会的公司合作，因为公司能够提供给学生获得真实世界软件开发经验的机会。这种关系也往往对参与的公司有利，因为它可以成为在现有的开源社区发展和吸引新人才的好方法。组织不可能在全球范围内雇佣所有的聪明人，所以他们需要找到一种方法来挖掘新的知识，并在外部项目中影响有利的结果。

挑战

开源软件已经成为许多组织的默认选择，这些软件为互联网上一些最引人注目的网站和服务提供动力。虽然开源软件的概念很简朴，但多年来组织如何使用和采用开源，其蕴含的内容已经有了很大的发展。有些组织仍然在懵懂无知中使用开源软件，而优秀的组织已经在开源做出重大努力，全面拥抱开源软件（OSS），就像他们采用专用软件一样。在某些情况下，他们已经摆脱了组织多年来使用的专有软件，转而采用他们可以修改和定制的开源软件。尽管开源有着巨大的优势，但企业往往在采用开源软件和推进数字化转型方面举步维艰。

一般来说，组织通常在五个领域面临重大挑战：文化、流程、工具、连续性和教育（图10）。在每个挑战中，组织必须解决几个问题，以支持他们采用开源方法和实践。

文化

文化挑战往往来自于传统的软件开发实践与开源开发要求之间的差距。为了弥合这一差距，聘请开源专家并请求他们培训其他不熟悉开源开发模式的员工。开源专家可以提供如下指导帮助：

建立遵循开源开发实践的内部流程，即尽早发布、经常发布和同行评审。
提高部门之间的透明度，鼓励更多的跨职能合作。
围绕优绩制（meritocracy）的理想来组建工程团队。
建立适当的成功指标，鼓励开源和跨部门的贡献。

图 10

流程

开源的开发是动态的，进展非常快，并且对合规性有独特的要求。软件驱动的世界将把那些不调整其内部流程以支持开源开发的公司远远地抛在了后面。开发人员必须能够迅速向上游提交代码，（方能赶上）因此，企业必须修改任何阻碍开源开发的内部代码政策。

让一个团队负责维护开源的合规性，以避免法律问题，并为开源的使用和提交建立一个简单的内部审批模式。
从高度复杂和繁琐的政策转向更直接的方法来接收、审查和批准源代码的提交。
平衡法律、工程和开源的利益，并给予专门的开源团队一揽子审批核准的权限，以便为许多开源项目的贡献扫清障碍。
根据提交代码的性质使用不同的批准级别（例如，修复简单错误的代码，改进现有功能的代码，实现新功能的代码，或作为新项目种子的代码。

工具

贵司创建的 IT 环境应该允许开发人员加入一个团队，而不需要对他们的工作方式做任何重大改变。这些工具应该支持开源开发模式，满足开源项目办公室（OSPO）的需求，并符合企业的 IT 准则。开源工程师需要更大的灵活性，通过电子邮件、聊天和代码开发平台与外部参与者沟通，他们的 IT 工具必须为让这种沟通更为便捷。例如，向开源项目发送的电子邮件绝不应包括声称内容为电子邮件发件人公司的知识财产权的附件。

允许从公司账户与公共邮件列表沟通，不受阻碍。给工程师提供支持他们选择的分布式开发的设备。确保所有的开源开发者可以在 Linux 上或通过单独的兼容设备访问所有重要的内部工具和资源。支持在远程地点工作的完全分布式团队，使他们能够通过虚拟专用网络（VPN）或类似技术连接到内部业务资源。评估贵司的 IT 政策，并获得帮助中心支持，用安全的方法来解决远程员工的 IT 问题。

连续性

对于一些组织来说，连续性让人想到的是一份冗长、无聊的文件，没有人看。当涉及到开源软件时，连续性是一个持续不断的挑战，因为组织要适应其业务、业务战略和行业的变化。在实践中，我们可以将连续性分为三类：

开源战略的连续性：告知当前和未来的员工不断发展的开源战略，并在发生新的发展和变化时即时进行更新。
项目和优先事项的延续性：确保继续参与开源项目和倡议，以持续地利用组织环境中断或变化之前的任何势头。
行政支持和资金的连续性：确保持续的财政和行政支持，并确保有足够的资源来支持开源项目。公司的高层赞助对连续性至关重要，他们要在整个组织内传达开源工作的价值和期望，以鼓励成功地采用、实施和在开源项目中贡献。

教育培训

开源软件是软件领域不可或缺的一部分，为用户和生态系统带来了巨大的利益。但要实现这些好处，企业必须通过教育和培训来克服知识上的不足：

决策层培训：这些课程帮助决策层和管理人员理解和阐述建立有效的开源实践的基本概念。这类课程通常包括建立有效的流程和战略的技巧，以消费开源软件，创建新的开源项目，参与到开源项目中，并在开放的生态系统中推动公司在软件领域的领导地位。
决策层培训：这些课程帮助决策层和管理人员理解和阐述建立有效的开源实践的基本概念。这类课程通常包括建立有效的流程和战略的技巧，以消费开源软件，创建新的开源项目，参与到开源项目中，并在开放的生态系统中推动公司在软件领域的领导地位。
导师计划：为了增加开源知识和技术技能，各组织设立了导师计划，由资深的开源开发者以结构化的、通常是一对一的关系指导初级开发者。其目的是传授知识和培训被指导者如何有效地与开源项目合作，并在此过程中提高他们在特定领域的技术能力。
技术培训：技术培训扩大了员工的技术知识基础。它解决了员工的弱点，提高了员工做新的和不同任务的技能。由于对开源技能和最新开源技术培训的强烈需求，开源培训行业正在蓬勃发展。

结束语

开源正在吞噬软件世界”[^2]，这是得到大众公认的。掌握开源需要一个包含开源消费、参与、贡献和领导力的策略。这些活动中的每一项都需要在改善开源工程方面做出渐进的努力和投入：

消费：建立内部基础设施，以实现正确的开源实践，并纳入开源政策、流程、列表清单和培训。
参与：开始在交流平台和活动中与开源社区接触。赞助项目和组织对于贵司的产品所依赖的开源软件是必不可少的。
贡献：雇用或培训开发人员专注于在开源项目中贡献，并部署必要的工具来支持内部开源工程。
领导力：增加与开源社区、开放标准机构和开源基金会的密切接触。启动新的开源倡议，提高贵司在开源世界的曝光度。

通往开源的道路并没有什么秘密。如果贵司遵循本指南中的建议，那么应该发现自己已经在路上了。欢迎来到企业开源。

Linux.基金会资源

出版物

企业中的开源合规性，第二版
兼并与收购交易中的开源审计
技术债务和开源开发：探讨如何更好地理解技术债务以及开源开发如何帮助缓解技术债务问题
GPL 合规实战
评估开源的做法，作为并购交易尽职调查的一部分
提高开源开发的影响力
使用开源
开源的开发模式是否适合贵司？
建立开源软件战略：关键考虑因素和战术建议
开放专有技术的简单方法：开源你的代码的高层次路线
上游优先：加强开源开发

计划

Open Compliance Program
TODO Group

项目

OpenChain
Software Package Data eXchange

指南

Linux 基金会企业指南
招募开源开发者
OpenChain 课程体系

免费培训

Linux 基金会为开发者提供免费的合规培训

关于作者

Ibrahim Haddad 博士是 Linux 基金会的战略项目副总裁，他专注于促进一个厂商中立的环境，以推进开源平台和赋能一代又一代的开源创新者。Haddad 领导着 LF 人工智能和数据基金会，为编程、管理和扩展开源人工智能和数据项目的开发者提供一个值得信赖的枢纽。他以及基金会的整体工作就是支持公司、开发人员和开源社区识别和贡献于解决行业挑战的技术项目，使所有参与者受益。在加入 Linux 基金会之前，他曾在三星电子担任研发副总裁和开源部门的负责人。在他的职业生涯中，Haddad 曾在爱立信研究院、开源开发实验室（OSDL）、摩托罗拉、Palm、惠普和 Linux 基金会担任技术和组合管理职务。他以优异的成绩毕业于康科迪亚大学（加拿大蒙特利尔），获得计算机科学博士学位。

免责声明

本报告是“按原样”提供的。Linux 基金会及其作者、贡献者和赞助者明确表示不提供任何明示、暗示或其它保证，包括与本报告有关的适销性、非侵权性、特定目的适用性或所有权的暗示保证。在任何情况下，Linux 基金会及其作者、贡献者和赞助者都不对任何其他方的利润损失或任何形式的间接、特殊、偶然或后果性的损害负责，这些损害来自与本报告有关的任何类型的诉讼原因，无论是否基于违约、侵权（包括过失）或其他原因，也无论他们是否被告知这种损害的可能性。对本报告创作的赞助并不构成任何赞助商对其结论的认可。

感谢以下LINUX.基金会.APAC.开源布道者翻译.SIG.的成员，.

为本企业开源指南翻译成简体中文作出了贡献。.该团队成员包括:

赵振华，深圳市启锐信息技术有限公司
刘天栋 Ted，开源社
适兕, LF APAC 开源布道者
王峰, 安势信息
张岩, LF APAC 开源布道者
侯胡的, LFAPAC 开源布道者
Donald Liu, Linux Foundation APAC
Maggie Cheung, Linux Foundation APAC
Michelle Ko, Linux Foundation APAC

Megan Barnett, “美国企业如何走向开源”, Fortune, Fortune Media IP Ltd., 2010 年 8 月 16 日；以及 Raju Shahi，”建立在开源世界之上的商业公司”，Hackernoon，Artmap Inc.，2020 年 6 月 9 日。 ↩