与全世界分享你的创意工作会是一次令人兴奋且有益的经历。它也可能意味着一堆你不知道你必须担心的法律问题。谢天谢地，有了这本指南，你不必从头开始。（在你深入研究之前，一定要阅读我们的免责声明.)

很高兴你这么问！当你创作一件创造性的作品（如写作、图形或代码）时，该作品默认享有独家版权。也就是说，法律假定，作为你作品的作者，你对其他人可以用它做什么有发言权。

一般来说，这意味着没有其他人可以使用、复制、分发或修改您的作品，而不会面临被接受、篡改或诉讼的风险。

然而，开源是一种不寻常的情况，因为作者希望其他人能够使用、修改和共享作品。但是，由于法律默认仍然是独占版权，因此您需要明确授予这些权限并附带许可证。

当有人为您的项目做出贡献时，这些规则也适用。在没有许可证或其他协议的情况下，任何稿件都归作者独家所有。这意味着没有人——甚至你——可以使用、复制、分发或修改他们的贡献。

最后，您的项目可能与您不知道的许可证要求存在依赖关系。您的项目社区或您雇主的政策也可能要求您的项目使用特定的开源许可证。我们将在下面介绍这些情况。

公共GitHub项目是开源的吗？

当你创建新项目在GitHub上，您可以选择创建存储库私有的或公众的.

创建存储库

公开GitHub项目与授权项目不同。公共项目由GitHub的服务条款，它允许其他人查看和派生您的项目，但您的工作没有权限。

如果您希望其他人使用、分发、修改或回馈您的项目，则需要包含开放源代码许可证。例如，有些人不能在他们的代码中合法地使用GitHub项目的任何部分，即使它是公开的，除非您明确授予他们这样做的权利。

只要给我TL；我需要什么来保护我的项目。

你很幸运，因为今天，开源许可证已经标准化并且易于使用。您可以将现有许可证直接复制粘贴到您的项目中。

麻省理工学院,阿帕奇2.0、和GPLv3级是流行的开源许可证，但还有其他选项可供选择。您可以在上找到这些许可证的全文以及如何使用它们的说明choosealicense.com.

当您在GitHub上创建新项目时，您将要求添加许可证.

哪个开源许可证适合我的项目？

很难出错麻省理工学院许可证如果你从一张白板开始。它简短易懂，允许任何人做任何事情，只要他们保留许可证的副本，包括您的版权声明。如果需要，您可以使用不同的许可证发布项目。

否则，为您的项目选择合适的开源许可证取决于您的目标。

你的项目很可能已经（或将要）依赖项，每个都有自己的开放源码许可证，其中包含您必须遵守的条款。例如，如果您正在开源Node.js项目，您可能会使用NodePackageManager（npm）中的库。

与的依赖项许可证喜欢麻省理工学院,阿帕奇2.0,英思科、和BSD公司允许您随心所欲地许可您的项目。

与的依赖项copyleft许可证需要密切关注。包括任何具有“强”版权许可的库，如GPLv2级,GPLv3级，或AGP第3版要求您选择相同或兼容许可证用于您的项目。具有“有限”或“弱”版权许可的库，如MPL 2.0标准和LGPL公司可以包含在具有任何许可证的项目中，前提是您遵循附则他们指定了。

您可能还需要考虑社区您希望使用并为您的项目做出贡献：

  • 是否希望您的项目被其他项目用作依赖项？可能最好使用相关社区中最流行的许可证。例如，麻省理工学院是最受欢迎的许可证npm库.
  • 你想让你的项目吸引大企业吗？所有贡献者的明确专利许可可能会让大型企业感到欣慰。在这种情况下阿帕奇2.0你（和他们）都被覆盖了吗。
  • 你想让你的项目吸引那些不想在封闭源代码软件中使用他们的贡献的贡献者吗？ GPLv3级或者（如果他们也不想为封闭源代码服务捐款）AGP第3版会很顺利。

您的公司可能有开源项目许可政策。一些公司要求您的项目具有许可证，以允许与公司的专有产品集成。其他政策强制执行强大的版权许可和附加的贡献者协议(参见下文)因此，只有您的公司可以在封闭源代码软件中使用该项目。组织也可能有某些标准、社会责任目标或透明度需求，这些可能需要特定的许可策略。与您的公司法律部以获取指导。

在GitHub上创建新项目时，您可以选择许可证。包括上面提到的一个许可证将使您的GitHub项目开源。如果您想查看其他选项，请查看choosealicense.com为您的项目找到合适的许可证，即使它不是软件.

如果我想更改项目的许可证，该怎么办？

大多数项目从不需要更改许可证。但有时情况会发生变化。

例如，随着项目的增长，它会增加依赖项或用户，或者您的公司会更改策略，其中任何一个都可能需要或想要不同的许可证。此外，如果您从一开始就忽略了对项目进行许可，那么添加许可实际上与更改许可相同。添加或更改项目许可证时，需要考虑三个基本事项：

这很复杂。确定许可证兼容性和合规性以及谁拥有版权可能会很快变得复杂和令人困惑。为新版本和贡献切换到新的但兼容的许可与重新许可所有现有贡献不同。一旦有迹象表明您希望更改许可证，请让您的法律团队参与进来。即使您已经或可以从项目的版权所有者那里获得许可证更改的许可，也要考虑更改对项目的其他用户和贡献者的影响。将许可证变更视为项目的“治理事件”，通过与项目的利益相关者进行明确的沟通和协商，该事件更有可能顺利进行。更有理由从一开始就为您的项目选择并使用合适的许可证！

您项目的现有许可证。如果您项目的现有许可证与您要更改的许可证兼容，您可以开始使用新的许可证。这是因为如果许可证A与许可证B兼容，那么您将遵守A的条款，同时遵守B的条款（但不一定反之亦然）。因此，如果您当前正在使用许可许可证（例如MIT），您可以更改为具有更多条件的许可证，只要您保留MIT许可证的副本和任何相关的版权声明（即，继续遵守MIT许可的最低条件）。但是，如果您当前的许可证是不允许的（例如，copyleft，或者您没有许可证），并且您不是唯一的版权所有者，那么您不能将您的项目许可证更改为MIT。从本质上讲，只要有许可证，项目的版权所有者就可以提前许可更改许可证。

您项目的现有版权所有者。如果你是你的项目的唯一贡献者，那么你或你的公司是项目的唯一版权所有者。您可以添加或更改您或您的公司想要的任何许可证。否则，可能需要其他版权所有者的同意才能更改许可证。他们是谁？在您的项目中有承诺的人是一个很好的起点。但在某些情况下，版权将由这些人的雇主持有。在某些情况下，人们只会做出最小的贡献，但没有硬性规定，在某些代码行下的贡献不受版权限制。该怎么办？视情况而定。对于一个相对较小且年轻的项目，让所有现有贡献者同意发布或拉取请求中的许可证更改可能是可行的。对于大型长期项目，您可能需要寻找许多贡献者，甚至他们的继承人。Mozilla花了数年时间（2001-2006年）才重新授权Firefox、Thunderbird和相关软件。

或者，您可以通过附加贡献者协议让贡献者预先批准某些许可证更改(参见下文). 这稍微改变了更改许可证的复杂性。您需要提前获得律师的更多帮助，并且在执行许可证更改时，您仍然希望与项目的利益相关者进行清楚的沟通。

我的项目需要额外的贡献者协议吗？

可能不会。对于绝大多数开放源码项目，开放源码许可证隐含地充当入站（来自贡献者）和出站（对于其他贡献者和用户）许可证。如果您的项目在GitHub上，GitHup服务条款将“入站=出站”设置为显式默认.

附加的贡献者协议（通常称为贡献者许可协议（CLA））可以为项目维护者创建管理工作。协议增加多少工作取决于项目和实施。一个简单的协议可能要求贡献者通过单击确认他们拥有根据项目开放源代码许可进行贡献所需的权限。一份更为复杂的协议可能需要法律审查和出资人雇主的签字。

此外，通过添加一些一些人认为不必要、难以理解或不公平的“文书工作”（当协议接收人通过项目的开放源代码许可获得比贡献者或公众更多的权利时），额外的贡献者协议可能会被视为对项目社区不友好。

在某些情况下，您可能希望为您的项目考虑附加供款人协议，包括：

  • 你的律师希望所有出资人明确接受(签名在线或离线）贡献条款，可能是因为他们觉得开源许可证本身是不够的（即使它是！）。如果这是唯一的问题，那么一份确认项目开源许可证的贡献者协议就足够了。这个jQuery个人贡献者许可协议是轻量级附加贡献者协议的一个好例子。
  • 您或您的律师希望开发人员表示，他们做出的每一项承诺都是经过授权的。A类开发商原产地证书要求是有多少项目实现了这一点。例如，Node.js社区使用DCO相反他们之前的CLA。在存储库上自动实施DCO的一个简单选项是DCO探针.
  • 您的项目使用的开放源代码许可证不包括明确的专利授权（例如MIT），并且您需要所有贡献者的专利授权，其中一些贡献者可能为拥有大型专利组合的公司工作，这些专利组合可能会被用于针对您或项目的其他贡献者和用户。这个Apache个人贡献者许可协议是一个常用的附加贡献者协议，其专利授权与Apache License 2.0中的专利授权相同。
  • 您的项目处于版权许可之下，但您还需要分发项目的专有版本。你需要每个贡献者为你分配版权或授予你（但不是公众）许可证。这个MongoDB贡献者协议这类协议就是一个例子。
  • 您认为您的项目可能需要在其生命周期内更改许可证，并希望贡献者提前同意此类更改。

如果您确实需要在项目中使用附加的贡献者协议，请考虑使用以下集成CLA助理尽量减少参与者的分心。

如果你是作为公司员工发布开源项目，首先，你的法律团队应该知道你是在开源项目。

无论好坏，考虑让他们知道，即使这是一个个人项目。你可能与你的公司签订了“员工知识产权协议”，让他们对你的项目有一定的控制权，尤其是当他们与公司的业务相关或你使用公司资源开发项目时。你的公司应该很容易给你许可，而且可能已经通过员工友好型IP协议或公司政策获得了许可。如果没有，您可以进行谈判（例如，解释您的项目符合公司的专业学习和发展目标），或者在找到更好的公司之前避免从事您的项目。

如果你正在为你的公司开源项目，那一定要让他们知道。根据公司的业务要求和专业知识，您的法律团队可能已经制定了使用哪些开源许可证（可能还有其他贡献者协议）的政策，以确保您的项目符合其依赖项的许可证。如果没有，你和他们很幸运！您的法律团队应该渴望与您合作解决这一问题。需要考虑的一些事项：

  • 第三方材料：您的项目是否具有其他人创建的依赖项，或者是否包含或使用其他人的代码？如果这些是开源的，你需要遵守这些材料的开源许可。首先选择一个与第三方开源许可证协同工作的许可证(参见上文). 如果您的项目修改或分发第三方开放源码材料，那么您的法律团队也会想知道您是否满足第三方开源许可的其他条件，例如保留版权声明。如果你的项目使用了其他人没有开源许可证的代码，你可能不得不要求第三方维护人员添加开源许可证，如果你不能得到一个，停止在你的项目中使用他们的代码。

  • 商业秘密：考虑项目中是否有公司不想向公众提供的内容。如果是这样的话，你可以在提取出你想要保密的材料后，将项目的其余部分开源。

  • 专利：您的公司是否申请了一项专利，您的项目将构成开源的专利公开披露? 可悲的是，你可能会被要求等待（或者公司可能会重新考虑申请是否明智）。如果您希望拥有大型专利组合的公司的员工为您的项目做出贡献，您的法律团队可能希望您使用许可证，并获得贡献者的明确专利授权（例如Apache 2.0或GPLv3），或者使用附加贡献者协议(参见上文).

  • 商标：仔细检查项目名称不与任何现有商标冲突。如果您在项目中使用自己的公司商标，请检查它是否不会引起任何冲突。FOSS标记是在自由和开源项目环境中理解商标的实用指南。

  • 隐私：您的项目是否收集用户数据？“呼叫总部”到公司服务器？您的法律团队可以帮助您遵守公司政策和外部法规。

如果您正在发布公司的第一个开源项目，以上内容已经足够了（但不用担心，大多数项目都不会引起任何重大关注）。

从长远来看，您的法律团队可以做得更多，以帮助公司从参与开源中获得更多，并保持安全：

  • 员工供款政策：考虑制定一项公司政策，规定员工如何为开源项目做出贡献。一个明确的政策将减少员工之间的困惑，并帮助他们为开源项目做出贡献，以符合公司的最大利益，无论是作为他们工作的一部分还是在空闲时间。Rackspace就是一个很好的例子示范IP和开源贡献政策.
  • 发布内容： （几乎）一切？如果您的法律团队理解并致力于公司的开放源码战略，他们将最能帮助而不是阻碍您的努力。
  • 顺从：即使你的公司没有发布任何开源项目，它也会使用其他公司的开源软件。意识和过程可以防止头痛、产品延迟和诉讼。