对于开源，我们应该了解一些基本的法律知识。
Section 1 了解开源的法律含义
向全世界分享具有创造性的工作，是一个非常令人激动且很有意义的事情。但是这也意味着可能有一堆我们自己并不清楚的法律问题。幸运的是，开源的我们不必从头开始。本开源指南已经涵盖了大家的法律需求。（当然在具体的行动之前，请确定阅读了 GitHub 的免责声明。）
Section 2 为什么大家非常担心有关开源的法律问题？
很高兴提出这样大家都非常关心的问题！众所周知，当人们进行创造性的工作（例如写作、设计或编程）时，默认情况下该作品属于专有版权（copyright）。也就是说，法律承认人们是其作品的作者，他人在没有经得作者本人同意的情况下，是不能使用作者的成果的。
一般来说，这意味着没有人可以在没有作者本人授权的情况下使用、复制、分发或者修改作者的成果。
然而，开源有着不一样的情况。因为作者希望他人使用、修改以及分享他们的工作成果。但因为法律默认依然是专有版权（copyright），所以作者需要一个明确说明这些权限的许可协议。
如果作者没有应用开源许可协议，那么对项目做出贡献的人也将成为此项目的专属版权（copyright）所有者。这意味着没有人（也包括初始作者）可以使用、复制、分发后者修改他们的贡献，
另外，项目也可能具有贡献者不知道的许可证要求的依赖关系。开源项目社区，或者雇主政策也可能要求开发者们使用特定的开源许可协议。
Section 3 公开的 GitHub 项目是开源的吗？
当大家在 GitHub 上创建一个新项目 时，可以选择将仓库设置成 private 或者 public 。
将 GitHub 上的项目设置为公开并不意味着申明了项目的许可协议。 公开的项目涵盖了GitHub 的服务条款，它允许 GitHub 的其它用户查看和 fork 项目， 但是没有权限参与到项目中来。
如果想让他人使用、复制、修改开源项目，或者参与贡献的话，那么项目就需要包含一个开源许可协议。例如，即使你们的项目是公开的，但没有原作者的授权，一些人是不能合法在他们的代码中使用 GitHub 项目中的任何部分的。
Section 4 请告诉我该如何保护项目
大伙所处的时代，已经不同于往日，开源许可协议已经标准化了，同时应用起来也非常的简单。甚至仅仅是直接复制粘贴一个已经存在的许可协议到项目里即可。
MIT、Apache 2.0以及GPLv3 都是非常流行的开源许可协议，但是也有更多的其它选择。读者你可以在choosealicense.com上找到这些许可协议的全部文本，此网站也同时说明了如何使用这些许可协议。
当你在GitHub上创建了一个新的项目的时候，会被要求添加一个许可协议。
一个标准化的许可协议可以作为没有法律培训的人员的代理，以准确地知道他们可以和不能用软件做什么。除非绝对要求，否则应避免使用定制、修改或非标准术语，这将成为他人使用代码的障碍。
Section 5 哪个开源许可协议适合我的项目？
如果你们是小白，那么使用MIT License，不容易出错。它很短，很容易理解，并允许任何人做任何事情，只要贡献者保留许可证的副本即可，其中包括原作者的版权声明。如果需要，人们还可以根据不同的许可协议再发布项目。
然而，为项目选择合适的开源许可协议，仍忍由原作者做最终的决定。
项目非常可能有（或将有）依赖。举例来说，如果读者你开源了一个 Node.js 的项目，这个项目会使用到一些来自 npm（Node Package Manager）的库。项目所依赖的这些库都有它们自己的开源许可协议。如果这些许可协议“允许”（对使用、修改和分享给予公共权限，而对有关项目的许可协议没有要求），这样就可以使用任何想要的许可协议。其中共同允许许可协议包括MIT、Apache 2.0、ISC和BSD。
另一方面，如果项目的依赖中有一个的许可协议是“强制的 copyleft”（他们也给同样的允许，但条件是有关项目得使用同样的许可协议），那么项目将使用与之相同的许可协议。copyleft 许可协议包括GPLv2、GPLv3和AGPLv3。
作为社区经理，当然希望所建设的开源社区，能够有贡献者来贡献项目，那么久要考虑一些问题：
- 是否允许让项目成为其它项目的依赖？ 在相关社区最好尽可能使用最流行的许可协议。例如，MIT协议是npm 程序库所使用的最为流行的许可协议。
- 项目是否想吸引大企业？ 大型企业可能需要所有贡献者的明确专利许可。在这种情况下，Apache 2.0很适合。
- 项目是否想吸引不愿自己的贡献用于其它同类型软件的贡献者？ 在这种情况下，GPLv3和AGPLv3显然是更加合适的选择。
贵公司可能为自己的项目准备了特定的许可协议。例如，它可能需要较宽容的许可证，以便公司可以在公司的闭源产品中使用你们的项目。或者贵公司要求强大的 copyleft 许可协议同时要求贡献者赞成，这样的话，项目就只属于贵公司，没有人能在有关的软件中使用你们的项目。或者贵公司可能有与标准、社会责任或透明度相关的某些需求，其中任何一个都可能需要特定的许可策略。与贵公司的法律部门谈谈。
当大伙在 GitHub 上创建了一个新的项目时，GitHub 为给大家提供了选择许可协议的步骤。包括上面提到的可以使 GitHub 项目开源的许可协议。如果想要了解其他选择，可以通过查阅choosealicense.com找到适合项目（即使它不是软件）的许可协议。
Section 6 如果我想更换项目的许可协议，该怎么办？
大多数项目绝不需要更换许可协议。但是情况偶尔有变。
例如，随着项目的日益壮大，它添加了新的依赖或用户，或者贵公司改变了策略，或者其他的要求，总之要更换不同的许可协议。如果作者在开始项目的时候没有添加许可协议，那么再添加一个许可协议和更换许可协议是一样的效果。当要添加或者更换项目的许可协议时，需要考虑以下三件事：
这件事很复杂。 确定许可协议的兼容性和合规性，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦作者有任何想改变许可协议的想法，请首先让法律团队知道。即使修改这已经获得可以更换许可协议的权限，也要考虑者会给项目的其他用户和贡献者带来怎样的影响。将更换许可协议视为“管理事件”，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为项目选择和使用合适的许可协议。
你的项目已经有了许可协议。 如果项目的现有许可证与您要更改的许可证兼容，则可以开始使用新许可证。这是因为如果A许可协议与B许可协议兼容，你们将遵守A的条款，同时遵守B的条款（但不一定反之亦然）。因此，如果你目前正在使用许可型的许可协议（例如MIT），则可以更改为具有更多条件的许可协议，只要你们保留MIT许可协议的副本和任何相关的版权声明（即继续遵守MIT许可协议的最低条件）。如果你现在的许可协议不是许可型的（例如，copyleft或者你们还没有许可协议）以及你不是版权的唯一所有者，那么你不能将许可协议改为MIT。基本上，只要是使用的许可型的许可协议，版权所有者就可以事先更换许可协议。
你的项目已经有版权所有者。 如果你是项目的唯一贡献者，然后你或者贵公司是项目版权的唯一所有者。你可以添加或更换任何你或者贵公司认可的许可协议。不然你需要取得其他版权所有者的同意。他们是谁？他们是已经参与贵项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了 微小的 贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla 花费了多年重新授权 Firefox、Thunderbird 和相关软件。
或者，你可以让贡献者事先同意（通过额外的贡献者协议 - 见下文）在某些条件下更改某些许可协议，这些更改将超过现有的开源许可协议。这会改变许可协议改的复杂性。如果在执行许可协议更改时，你仍然想要和项目利益相关者进行沟通，你需要从律师那得到更多帮助。
Section 7 我的项目需要额外的贡献者协议吗？
可能不要。对于大多数的开源项目，一个开源许可协议可作用与所有贡献者和用户。
贡献者协议会给维护者带来额外的管理工作。这些协议增加了多少工作得取决去项目和实施。简单的协议可能要求贡献者确认和点击，在项目的开源许可协议下他们有权利贡献。更复杂的协议可能需要法律的审查和贡献者的雇主的签字。
此外，贡献者协议有时被认为对项目社区不友好。他们也增加了人们参与社区的障碍。
我们已经删除了 Node.js 的 CLA。这样做的结果就是有效降低了 Node.js 贡献者的参与门槛，从而吸引更多的贡献者。
一些情况下，可能想要为贵项目考虑一个额外的贡献协议：
- 贵公司律师想要所有的贡献者明确接受贡献者条款，或者因为他们觉得只有开源许可协议还远远不够。如果这是唯一的问题，那么有肯定项目开源许可协议的贡献者协议就足够了。jQuery个人贡献者许可协议就是一个很好的轻量级的个人贡献者协议。对于一些项目来说，Developer Certificate of Origin是一个很好的先择。
- 项目使用的开放源许可协议不包括明确的专利授权（如MIT），需要所有贡献者的专利授权，这些可能适合用于你们公司的专利组合或者项目的其他贡献者和用户。Apache 个人贡献者许可协议是一种常用的附加贡献者协议，其具有与Apache许可2.0中的专利许可相同的专利许可。
- 如果你的项目使用的是 copyleft 许可协议，但你也需要分发项目的专有版本。那你就需要每个贡献者分配版权给你或者授予你许可权。MongoDB贡献者协议就是这种类型的。
- 你认为项目在其有效期内需要更换许可协议，以及事先得到贡献者的同意。
如果确定需要在项目中使用额外的贡献者协议，请考虑使用诸如CLA助手之类的集成，以最大限度地减少贡献者的分心。
Section 8 我的公司的法律团队需要知道什么？
作为一名公司的雇员，如果要发布一开源项目的话，首先需要让公司的法律团队知道。
即使只是一个个人项目，也请考虑让法律团队知晓。你可能和贵公司有一个“员工知识产权协议”，这给了公司一些对你所做的项目的控制权，特别是当项目和公司的业务有着很多的联系或者你使用公司的资源来开发项目。贵公司 应该 很容易就可以给员工们许可，也许已经通过一个员工友好的知识产权协议或公司政策。如果不是这样，则可以谈判（例如，解释你的项目为公司的专业学习和发展目标服务），或者你在找到一个更好的公司前停止开源项目的工作。
如果开源项目是为了贵公司， 则绝对需要让他们知道。根据公司的业务需求和专业知识，法律团队可能已经制定了有关开放源代码许可协议（以及可能还有其他贡献者协议）的政策，以确保项目符合其依赖关系的许可协议。如果情况不是这样，那么就需要深度阅读本文，法律团队应该渴望与开源开发团队合作，把这个东西搞清楚。大家需要思考这些事：
-- 第三方资源： 项目是否有其他人创建的依赖或者使用他人的代码？如果这些开源项目，则需要遵守第三方资源的开源许可协议。首先，选择与第三方资源的开放源许可协议一起使用的许可协议（见上文）。如果项目修改或者发布第三方开源资源，那么法律团队还想知道项目是否符合第三方开源许可协议的其他条件，例如保留版权声明等。如果使用了其他没有开源许可协议的代码，那么可能会要求第三方资源的维护者添加一个开源许可协议，要是得不到许可，则只能停止使用别人的代码。
-- 商业机密： 请考虑项目中是否有公司不想对外公开的东西。如果是这样的话，则只能开源项目的一部分，保护好公司的商业机密为第一优先级。
-- 专利： 贵公司是否申请了与开源项目有关的专利？如果开源源代码，这会对公司的专利进行公开披露。不利的情况是，可能被要求等待（或者公司会重新思考应用程序）。如果期望从拥有大量专利组合的公司的员工那里得到贡献，法律团队可能希望大家使用来自贡献者的明确专利授权的许可协议（例如Apache 2.0或GPLv3）或者是其他贡献者协议（见上文）。
-- 商标： 认真检查项目名称没有与已经存在的商标冲突。如果将自己公司的商标用于项目，请检查它有没有造成冲突。FOSSmarks是在自由和开源项目的背景下理解商标的实用指南。
-- 隐私： 开源项目是否收集了用户数据并存储到公司的服务器？法律团队可以帮助开发者遵守公司政策和外部法规。
如果是发布贵公司的第一个开源项目的话，以上这些内容，让你通过法律团队则已经绰绰有余（不要担心，大多数项目不会引起重大关注）。
长期来说，贵司的法律团队需要做更多的事情，以帮助公司从开源中获得更多，并保证安全：
-- 员工贡献策略： 考虑制定一个公司策略，指明员工如何为开源项目贡献。明确的政策将减少大家的迷惑，并帮助他们为公司的最佳利益，从而向开源项目做贡献，无论是作为他们工作的一部分还是在自由时间。Rackspace 的知识产权模板和开源贡献策略就是很好的示例。
放弃与补丁相关的只是产权以构建员工知识库和信誉。它表明，公司关心员工的发展，以及让员工有种被赋权和自主的感觉。所有这些好处还导致更高的士气和更好地留住员工。
-- 发布什么：（几乎）是所有的内容？ 如果贵司的法律团队了解并花精力与贵公司的开源策略中来，他们将是开发人员最好的助手，而不是阻碍开发人员的。
-- 合规性： 即使贵公司没有发布任何开源项目，也会使用到开源软件。有意识的且及时处理可以避免很多麻烦，如产品延迟发布和诉讼等。
组织必须具有适合[“允许”和“copyleft”]类别的许可协议和合规性策略。首先，记录适用于你们所使用的开源软件的许可条款（包括子组件和依赖项）。
— Heather Meeker, “开源软件：基础合规最佳实践”
-- 专利： 贵公司可能希望加入开放发明网络，一个共享的专利防御池，以保护成员使用主要开源项目，或探索其他替代专利许可。
-- 治理： 特别是当如果将项目转移到公司以外的法律实体是有意义的。
- END -
