Merge branch 'master' into hans-hant

Author: mlinksva

Gemfile.lock

@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (6.0.2)
+    activesupport (6.0.2.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -80,7 +80,7 @@ GEM
       octokit (~> 4.0)
       public_suffix (~> 3.0)
       typhoeus (~> 1.3)
-    html-pipeline (2.12.2)
+    html-pipeline (2.12.3)
       activesupport (>= 2)
       nokogiri (>= 1.4)
     html-proofer (3.15.0)

_articles/zh-hans/legal.md

@@ -13,19 +13,19 @@ redirect_from: /zh-cn/legal/
 
 ## 理解开源的法律含义
 
-向世界分享你们具有创造性的工作，这是一个多么令人激动和有价值的经历。这也意味着你们必须担心一堆你们不清楚的法律问题。幸运的是，你们不必从头开始。我们已经涵盖了你们的法律需求。（在你们行动前，请确定阅读了我们的[免责声明](/notices/)。）
+向世界分享你们具有创造性的工作，是一个多么令人激动和有价值的经历。这也意味着你们必须担心一堆你们不清楚的法律问题。幸运的是，你们不必从头开始。我们已经涵盖了你们的法律需求。（在你们行动前，请确定阅读了我们的[免责声明](/notices/)。）
 
-## 为什么人们这么关心开源的法律问？
+## 为什么人们这么关心开源的法律方面问题？
 
-很高兴你们提问！当你们行创造性工作（例如写作，图形或代码）时，默认情况下该作品属于专有版权（copyright）。也就是说，法律承认你们是你们作品的作者，他人在没有经得你们同意的情况下不能使用你们的工作。
+很高兴你们提问了！当你们做创造性工作（例如写作，图形或代码）时，该作品默认为专有版权（copyright）。也就是说，法律承认你们是你们作品的作者，他人在没有经得你们同意的情况下不能使用你们的工作。
 
 一般来说，这意味着没有人可以在没有你们授权的情况下使用，复制，分发或者修改你们的工作。
 
 然而，开源有着不一样的情况。因为作者希望他人使用，修改以及分享他们的工作。但因为法律默认依然是专有版权（copyright），所以你们需要一个明确说明这些权限的协议。
 
 如果你们不应用开源许可协议，那么对你们项目做出贡献的人也都将成为其工作的专属版权（copyright）所有者。这意味着没有人（也包括你们）可以使用，复制，分发后者修改他们的贡献，
 
-最后，你们的项目可能具有你们不知道的许可证要求的依赖关系。你们的项目社区，或者你们的雇主政策也可能要求你们使用特定的开源许可协议。
+最后，你们的项目可能和你们不知道的许可证要求存在依赖关系。你们的项目社区，或者你们的雇主政策也可能要求你们使用特定的开源许可协议。我们将在下面介绍这些情况。
 
 ## Github上的公开项目都是开源的吗？
 
@@ -39,7 +39,7 @@ redirect_from: /zh-cn/legal/
 
 ## 如何保护我们的项目
 
-你们很幸运，开源许可协议已经标准化了，同时使用简单。你们可以直接复制粘贴一个已经存在的许可协议到你们的项目里。
+你们很幸运，开源许可协议已经是标准化而且易于使用的。你们可以直接复制粘贴一个已经存在的许可协议到你们的项目里。
 
 [MIT](https://choosealicense.com/licenses/mit/)，[Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)和[GPLv3](https://choosealicense.com/licenses/gpl-3.0/)都是非常流行的开源许可协议，但是也有其它选择。你们可以在[choosealicense.com](https://choosealicense.com/)上找到这些许可协议的全部文本，同时说明了如何使用他们。
 
@@ -55,35 +55,35 @@ redirect_from: /zh-cn/legal/
 
 ## 我的项目适合什么样的开源许可?
 
-如果你们是小白，那么使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出错。它很短，很容易理解，并允许任何人做任何事情，只要他们保留许可证的副本，包括你们的版权声明。如果你们需要，您们能够根据不同的许可协议发布项目。
+如果你们是从头开始的，那么使用[MIT License](https://choosealicense.com/licenses/mit/)，不容易出错。它很短，很容易理解，并允许任何人做任何事情，只要他们保留许可证的副本，包括你们的版权声明。如果你们需要，您们能够根据不同的许可协议发布项目。
 
-然而，为项目选择合适的开源许可协议这取决于你们。
+否则，为项目选择合适的开源许可协议，取决于你们的目标。
 
 你们的项目非常可能有（或将有）**依赖**。例如，如果你们开源了一个Node.js的项目，你们将可能使用来自npm（Node Package Manager）的库。你们依赖的这些库都有它们自己的开源许可协议。如果他们的许可协议"允许"（对使用，修改和分享给予公共权限，而对有关项目的许可协议没有要求），这样你们就可以使用任何你们想要的许可协议。共同允许许可协议包括MIT，Apache 2.0，ISC和BSD。
 
-另一方面，如果你们的依赖中有一个的许可协议是"强硬的copyleft"（他们也给同样的允许，但条件是有关项目得使用同样的许可协议），那么你们的项目将使用与之相同的许可协议。copyleft许可协议包括GPLv2，GPLv3和AGPLv3。
+另一方面，如果你们的依赖中有一个的许可协议是"强硬的copyleft"（也给予公众相同的权限，但条件是有关项目得使用同样的许可协议），那么你们的项目将必须使用与之相同的许可协议。copyleft许可协议包括GPLv2，GPLv3和AGPLv3。
 
-你们也会想到考虑希望你们的社区使用以及贡献你们的项目：
+你们也会想要考虑你们希望的社区使用以及为你们的项目做贡献：
 
 * **你们是否想让你们的项目成为其它项目的依赖？**在你们的相关社区最好尽可能使用最流行的许可协议。例如，[MIT](https://choosealicense.com/licenses/mit/)是[npm libraries](https://libraries.io/search?platforms=NPM)使用的最流行的许可协议。
 * **你们的项目是否想吸引大企业？**大型企业可能需要所有贡献者的明确专利许可。在这种情况下，[Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)适合你们。
 * **你们的项目是否想吸引不愿自己的贡献用于其它同类型软件的贡献者？**[GPLv3](https://choosealicense.com/licenses/gpl-3.0/)和[AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)适合你们。
 
-你们的公司可能为自己的项目准备了特定的许可协议。例如，它可能需要许可许可证，以便公司可以在公司的闭源产品中使用你们的项目。或者你们的公司要求强大的copyleft许可协议同时要求贡献者赞成，这样项目只属于你们公司，没有人能在有关的软件中使用你们的项目。或者你们的公司可能有与标准，社会责任或透明度相关的某些需求，其中任何一个都可能需要特定的许可策略。与你们[公司的法律部门](#公司的法律团队需要知道什么)谈谈。
+你们的公司可能为自己的项目准备了特定的许可协议。例如，它可能需要宽松的许可证，以便公司可以在公司的闭源产品中使用你们的项目。或者你们的公司要求严格的copyleft许可协议和一份附加的贡献者协议，以便除了你们公司以外，没有人能在封闭源代码的软件中使用你们的项目。或者你们的公司可能有与标准，社会责任或透明度相关的某些需求，其中任何一个都可能需要特定的许可策略。与你们[公司的法律部门](#公司的法律团队需要知道什么)谈谈。
 
-当你们在GitHub上创建了一个新项目，它给你们提供了选择许可协议的机会。包括上面提到的可以使你们的GitHub项目开源的许可协议。如果你们想要了解其他选择，可以通过查阅[choosealicense.com](https://choosealicense.com)找到适合你们项目（即使它[不是软件](https://choosealicense.com/non-software/)）的许可协议。
+当你们在GitHub上创建了一个新项目，它给你们提供了选择许可协议的选项。包括上面提到的可以使你们的GitHub项目开源的许可协议。如果你们想要了解其他选择，可以通过查阅[choosealicense.com](https://choosealicense.com)找到适合你们项目（即使它[不是软件](https://choosealicense.com/non-software/)）的许可协议。
 
 ## 如果我想修改开源许可该怎么办?
 
 大多数项目绝不需要更换许可协议。但是情况偶尔有变。
 
 例如，随着你们项目的壮大，它添加了新的依赖或用户，或者你们的公司改变了策略，或者其他的要求要更换不同的许可协议。如果你们在开始项目的时候没有添加许可协议，那么再添加一个许可协议和更换许可协议是一样的效果。当你们要添加或者更换项目的许可协议时，需要考虑以下三件事：
 
-**这件事很复杂。**确定许可协议的兼容性和合规行，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你已经或可以获得项目版权所有者的许可证更改许可，请考虑更改对项目的其他用户和贡献者的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。
+**这件事很复杂。**确定许可协议的兼容性和合规性，以及谁拥有版权，这会非常快速地变得复杂和混乱。为新的发布和贡献选择一个新的且合适的许可协议与重新许可已存在的贡献是不同的。一旦你们有任何想改变许可协议的想法，请首先让法律团队知道。即使你已经或可以获得项目版权所有者的许可证更改许可，请考虑更改对项目的其他用户和贡献者的影响。将更换许可协议视为"管理事件"，只有通过与项目的利益相关者进行明确的沟通和咨询，才更有可能顺利进行。请谨记，从一开始就为你们的选择和使用合适的许可协议。
 
 **你们的项目已经有了许可协议。**如果项目的现有许可证与您要更改的许可证兼容，则可以开始使用新许可证。这是因为如果A许可协议与B许可协议兼容，你们将遵守A的条款，同时遵守B的条款（但不一定反之亦然）。因此，如果你们目前正在使用许可型的许可协议（例如MIT），则可以更改为具有更多条件的许可协议，只要你们保留MIT许可协议的副本和任何相关的版权声明（即继续遵守MIT许可协议的最低条件）。如果你们现在的许可协议不是许可型的（例如，copyleft或者你们还没有许可协议）以及你们不是版权的唯一所有者，那么你们不能将许可协议改为MIT。基本上，只要是使用的许可型的许可协议，版权所有者能事先更换许可协议。
 
-**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年重新授权Firefox，Thunderbird和相关软件。
+**你们的项目已经有版权所有者。**如果你们是你们项目的唯一贡献者，然后你们或者你们的公司是项目版权的唯一所有者。你们可以添加或更换任何你们或者你们公司心仪的许可协议。不然你们需要取得其他版权所有者的同意。他们是谁？他们是已经参与你们项目提交的人。但有些情况是项目版权掌握在这些人的雇主手中。在某些情况下，人们只是做了_微小的_贡献，但没有硬性规定，在一些行代码下的贡献不受版权保护。对与这样的情况该怎么办？对于一个相对较小以及年轻的项目来说，取得所有贡献者对更换许可协议的同意是可行的。但对于大项目和老项目来说，你们必须寻求很多贡献者以及他们继承者的共识。Mozilla花费了多年(2001-2006)重新授权Firefox，Thunderbird和相关软件。
 
 或者，你们可以让贡献者事先同意（通过额外的贡献者协议 - 见下文）在某些条件下更改某些许可协议，这些更改将超过现有的开源许可协议。这会改变许可协议改的复杂性。如果在执行许可协议更改时，你们仍然想要和项目利益相关者进行沟通，你们需要从你们律师那得到更多帮助。