许多开源软件的用户对“衍生作品”这个术语感到害怕。他们担心自己可能会意外地创建衍生作品，并将自己的专有软件置于开源许可证之下。这是一个复杂的话题，法院和律师对此意见不一，但我认为我们可以找到一些定义来缓解人们的担忧。

首先，简要提醒一下为什么衍生作品这个术语如此重要。以下是一个典型的许可证可能说的话：“许可方特此授予您许可……以准备基于原始作品的衍生作品，并分发这些衍生作品但前提是您分发的这些衍生作品的副本应根据本许可证获得许可。” 例如，请参阅GNU通用公共许可证，网址为www.gnu.org/licenses/gpl.html或新的开放软件许可证，网址为www.opensource.org/licenses/osl.php。

您如何判断自己何时创建了衍生作品？美国版权法第17 U.S.C. §101条对此有点含糊不清，并且完全没有提及软件

几乎所有人都同意，如果您获取任何程序的受版权保护的源代码并对其进行物理修改——实际修改程序或将其翻译成另一种计算机语言——您就创建了该程序的衍生作品。这是一个简单的情况。如果您对根据GPL或OSL许可的程序执行此类操作，则必须遵守互惠条款并发布您分发的衍生作品的源代码。

但是，如果您只是将原始程序复制为自己（可能更大的）作品中的一个组件，会发生什么情况？您实际上没有修改源代码来将原始程序合并到您更大的作品中，这会产生影响吗？

仅仅链接到一个程序而不对原始源代码进行任何更改是否会创建该程序的衍生作品？几乎每个程序都链接到库例程。当然，仅仅通过调用库中的sqrt函数并不会创建库的衍生作品。当您链接到像企业服务器或数据库引擎这样复杂的东西时，为什么会有所不同呢？从软件程序链接又如何呢，例如当您将设备驱动程序链接到像Linux这样的GPL或OSL许可的程序中时？

您使用的链接的技术形式重要吗？或者，这种分析（例如，静态链接、动态链接、通过API传递数据、作为包含在更大对象中的对象等）是否是一个技术泥潭，掩盖了根本问题？衍生作品法如何跟上软件工程世界中的技术变革？

这些问题很重要，因为某些许可证要求您发布衍生作品程序中您那部分源代码，这可能是您不想接受的负担。以下是我将如何在上述情况下做出决定的方法。

1) 判断新程序是否为衍生作品的主要指标是，原始程序的源代码是否被使用、修改、翻译或以其他方式更改以创建新程序。如果不是，那么我认为它不是衍生作品。

2) 衍生作品的含义不会扩大到包括通过链接到旨在用作库程序的库程序而创建的软件。例如，当一家公司发布科学子例程库或对象库时，仅仅使用该库（未修改，甚至可能没有查看源代码）的人员，并不会因此而创建该库的衍生作品。

3) 衍生作品不会包含旨在从现成的、未修改的程序链接的插件和设备驱动程序。如果一个受GPL保护的程序被设计为接受单独设计的插件程序，那么即使您必须查看源代码以了解如何操作，您也仅仅通过在其下运行此类插件来创建衍生作品。

4) 在大多数情况下，我们不应关心单独程序之间的链接在技术上是如何完成的，除非这个事实有助于确定程序的创建者是否在对衍生作品的外观达成某种明显的共同理解的情况下设计了它们。我们应该考虑微妙的基于市场的因素作为意图的指标，例如，最终程序是否作为原始程序的“增强”版本出售，或者原始程序是否被设计和宣传为“像库一样”可改进的。

您应该关心这个问题，以鼓励创建自由和开源软件，而不会吓跑专有软件用户。我们需要确保公司在一定程度上确定地知道他们何时创建了衍生作品，以及何时没有。

法律建议必须在律师-客户关系的过程中提供，具体参考特定情况的所有事实以及您所在司法管辖区的法律。即使律师撰写了本文，本文中的信息也不得用作替代从持牌律师处获得具体法律建议的替代品。