开发的某些（部分）软件可能来自外部开发人员，通常是承包商、其分包商或其他供应商。如果他们正在处理OSS，他们将被要求遵循类似的指导方针。如果您在工作过程中与这些外部开发人员有联系，请毫不犹豫地提请他们注意这些指导原则，并要求他们提供有关自己使用OSS的相关文档。此类要求应在与承包商签订的相关合同中规定。如果在检查由外部开发人员开发的部分软件时，您注意到当前的指导方针没有得到遵守（例如，没有版权声明，插入的OSS的使用没有文档记录，软件包含根据许可证发布的不允许使用的部分代码对于这种类型的项目等），您必须咨询您的行动负责人/项目经理。

在投标和合同中使用这些指南 ¶

如果从外部开发人员或承包商处采购软件，也必须遵守这些指南中规定的原则。确保招标和合同要求承包商必须遵守这些指南，这些指南必须附在本指南之后。此类招标和合同还应说明有关项目中使用OSS的具体要求（如有），并要求投标人和承包商提前解释和记录他们打算使用的OSS。

检查表 ¶

您是否确定要从外部分发软件？
您决定了要用于分发软件的许可证类型了吗？
您是否记录，或要求您的承包商/合作者记录在开发项目中预先存在的OSS代码的使用情况？
在修改、插入或链接已有的OSS组件时，是否检查了许可证的兼容性？
您是否复制了项目中使用的现有软件上出现的所有版权声明和免责声明？
您是否发送了用于合法存档的代码副本，并检查这些代码是否应在在线存储库中可用？

开源许可证 ¶

版权和使用条件 ¶

只要用户在允许的使用范围内并遵守OSS许可证规定的条件，使用OSS是合法的。因此，了解和尊重管理项目中使用的OSS部件的许可条款至关重要。

左移效果 ¶

一些开放源代码许可要求分发原始软件及其任何衍生作品的用户按照相同的许可条款进行分发。GPL和EUPL是包含此类义务的许可证的示例。实际后果示例如下：

您修改了在GPL下发布的软件，并且希望分发修改过的工作：您必须在GPL下发布它。
您可以将GPL下发布的一些软件代码行集成到一个更大的工作中。如果你想分发它，你必须在GPL下发布所有的结果工作，因为它将被视为GPL软件的“衍生工作”，即使只使用其中的一小部分。

包含这种义务的许可被称为“版权”许可，通常被称为具有“病毒效应”，因为它们通过衍生作品传播。相反，不包含此类义务并允许您选择要在哪些条件下分发衍生软件的许可证称为“许可”。

兼容性 ¶

开源许可证A被称为与开源许可证B“兼容”，当最初根据许可证A授权的软件在修改或与其他软件合并后可以根据许可证B重新分发时。

兼容性不是必需的互惠：许可证A可能与许可证B兼容，而许可证B可能与许可证A不兼容。

兼容性/不兼容性示例 ¶

两部分软件的合并，一部分根据BSD发布，另一部分根据EUPL发布。

bsd+eupl=eupl（正常）

在这种情况下，最初根据BSD许可证发布的软件集成到最终结果中，并在与其他软件合并后根据EUPL许可证分发。BSD许可证的条款授权随后的许可证更改。可以说，BSD与eupl兼容。

bsd+eupl=bsd（不可能）

这种情况与前面的操作完全相同，但您希望在BSD许可证下分发最终结果。这是不可能的，因为eupl的条款规定，在eupl下发布的软件的衍生作品也在eupl（copyleft）下发布。可以说，eupl与bsd不兼容。因此，在这种情况下，BSD和EUPL之间的兼容性不是相互的。

合并两部分软件，一部分在eupl下发布，另一部分在gpl v2下发布。

gplv2+eupl=eupl（不可能）

GPLv2规定最终结果，即“衍生作品”是根据GPLv2发布的。因此，在不违反GPL v2条款的情况下，此操作是不可能的。GPL v2与eupl不兼容。

这种情况似乎与前一种情况完全相同，因为eupl还规定衍生作品在eupl下发布。但是，eupl包含一个条款，该条款明确允许在eupl和gpl v2软件合并的情况下发布gpl v2下的衍生作品。

这是一个 快速兼容性 ：eupl与gpl v2兼容。

这里再次指出，eupl和gpl v2之间的兼容性不是相互的。

开源软件指南 ¶

早期判定原则 ¶

分销政策的早期确定 ¶

开源许可证的早期确定 ¶

面向开发人员的OSS指南 ¶

记录您的工作 ¶

哪里可以得到开源软件？¶

使用OSS开发工具或环境 ¶

在项目中合并开源代码 ¶

将软件链接到OSS库 ¶

版权声明和免责声明 ¶

保存并发送代码的副本，以便存档 ¶

与外部开发人员的关系 ¶