跳转到内容

FOSS 许可证/场景

Add links
来自维基教科书，开放世界中的开放书籍

不同的利益相关者将对 FOSS 有不同的用途。开发人员可能会比最终用户更密集地使用某个程序，这意味着开发人员的活动可能比最终用户受到更多的限制。以下部分试图提供一些场景作为示例，以解释不同利益相关者可能遇到的不同法律问题。

最终用户（个人/企业/政府）

[编辑 | 编辑源代码]

阿布尔是一名公立高中教师。他的学校负担不起昂贵的专有办公应用程序许可证费用。尽管专有软件公司为学校提供特别优惠，但阿布尔希望找到一种替代解决方案，以减少学生对专有软件的依赖。他的朋友纳兹莉是一位参与过 FOSS 项目的程序员，向他介绍了一款 FOSS 办公应用程序。然后，阿布尔和他的同事下载了 FOSS 办公解决方案，并教授学生专有和 FOSS 应用程序。他对性能感到满意，并向他的同事介绍了纳兹莉的程序。逐渐地，学校行政部门开始使用 FOSS 解决方案进行行政工作。

在这种情况下，无论是阿布尔（个人）还是他的学校（公共政府机构）都没有对他们从网络下载的软件进行任何修改。他们只是最终用户。

最终用户的状况相对简单。软件程序的最终用户可以是个人、政府机构或商业实体。这些个人或法人实体可能出于不同的原因使用 FOSS。有些人可能试图找到更便宜的解决方案或更适合他们需求的解决方案；其他人可能希望使用 FOSS 进行更好的定制；还有一些人可能希望减少对专有公司的依赖。

涉及的法律问题
最终用户使用 FOSS 解决方案的方式可能与他们使用专有解决方案的方式没有太大区别。他们下载 FOSS 解决方案的副本或购买副本（通常是为了换取一些支持和服务），将其安装在计算机中（从而在硬盘上制作副本），运行程序，并让其功能满足他们的需求。这里关注的权利是复制程序和运行程序的权利。（运行程序的行为也可能算作复制行为，但在一些 FOSS 许可证中有所不同。例如，GNU GPL 对运行 GPL 程序没有限制，但确实规范了复制行为。）这些权利是由所有 FOSS 许可证授予的。因此，涉及最终用户的法律纠纷较少。但是，最终用户确实需要考虑一些问题。
  • 问题 1：技术支持 由于最终用户可能不是电脑高手，因此在选择 FOSS 解决方案时，他们可能对技术支持存在顾虑。因此，他们可能不会简单地免费下载 FOSS 解决方案的副本，而是选择在专有解决方案也提供的商店购买一盒 FOSS，有时价格大致相同。区别在于，购买时，假设是商用 Linux 发行版，最终用户不是在为许可证付费，而是在为服务和支持付费。软件和 FOSS 文档的额外副本可以自由分发，例如分发给学生，或安装在其他计算机上；这些额外的用户或安装通常不包含在支持范围内，除非在协议中明确包含。当服务期限到期后，最终用户可以选择支付另一期限的服务费用，或向其他可用提供商请求类似的服务。
  • 问题 2：定制 当现有的 FOSS 解决方案不符合他们的需求时，最终用户可能需要请个人开发人员或供应商定制解决方案。在这种情况下，由于最终用户可能没有足够的专业知识来发现可能的侵权行为，因此他们可能希望在合同中加入书面条款，确保供应商或开发人员将承担任何可能的版权侵权行为的全部责任，并赔偿因侵权指控可能造成的任何损失。买方在与供应商或开发人员谈判时，可以自由地将这些条款添加到合同中。
  • 问题 3：政府采购 由于 FOSS 许可证与传统软件许可证不同，因此政府在为软件解决方案招标或与供应商签订合同时，应特别注意这些差异。现有的政府招标和合同模板可能是在传统版权法传统的专有模型下起草的，如果它们不能平等地对待 FOSS 和专有软件，则需要检查或修改。

开发人员（个人，企业）

[编辑 | 编辑源代码]

开发人员（个人和商业实体）在使用 FOSS 时需要更加注意不同许可证的条款和条件。开发人员通常不仅运行和复制软件，而且还会从软件中创建衍生作品，并将这些衍生作品与原始程序一起分发。因此，为了让开发人员能够为某个 FOSS 程序的开发做出贡献，必须拥有运行程序、复制程序、分发程序和准备衍生作品的权利。

这些权利是由所有 FOSS 许可证 授予的，因为这些基本权利被认为在 自由软件定义 和 开源定义 中都很重要。然而，不同的 FOSS 许可证可能对行使这些权利有不同的限制，尤其是在创建和分发衍生作品方面。开发人员应特别注意这一点，并在需要时咨询他们的律师，了解他们具体的情况。

在软件开发的不同阶段，开发人员会考虑不同的因素。

启动新项目时

[编辑 | 编辑源代码]

阿布尔的同事乔莉是学校图书管理员。学校图书馆不是很大，但对村民开放。乔莉向她的朋友寻求帮助，编写一个程序，以便她能够准确地记录图书馆的书籍。

  • 涉及的法律问题 - 选择自己的许可证
开发人员
这个项目对我个人和其他人意味着什么？我希望其他人如何参与？FOSS 许可证怎么说？FOSS 许可证之间有什么区别？
如果开发人员是在不使用任何现有模块的情况下启动新项目，那么情况就比较简单，因为她不需要查看可能使用的现有模块的许可证。
但是，启动新项目也不是一件容易的事。她选择的 FOSS 许可证的不同特点将对项目的可能开发路径产生重大影响。开发人员应该在选择许可证之前确定她最关心的问题。
例如，如果开发人员是 copyleft 的支持者，她可能会坚持使用 GNU GPL 或 LGPL。如果开发人员认为她不需要要求人们在 FOSS 许可证下许可他们的修改作品，那么 BSD 风格的许可证 比较合适。或者，当开发人员认为最好以坚定而集中的方式控制开发时，她可能对 BSD 风格的许可证不感兴趣。但如果在未来的发展中更倾向于分支，那么 BSD 风格的许可证可能是更好的选择。
开发人员
我可以更改我的项目许可后改变主意吗？
项目的版权持有者始终可以决定为程序选择其他许可证，即使先前版本已经根据某些自由软件许可证获得许可。这不会影响先前版本接收者的权利，因为许可证授予是不可撤销的。如果社区的贡献已被纳入新版本，情况会更加复杂，这意味着这些其他贡献者可能会对新版本中代码的某些部分主张版权。在这种情况下，除非事先达成协议，否则许可证必须由所有贡献者选择。
开发人员
我不喜欢任何现有的自由软件许可证。我可以创建一个新的吗？
虽然已经存在许多自由软件许可证，但开发人员可能会发现自己不喜欢任何可用的许可证。只要开发人员拥有代码，她就有权为项目选择任何许可证，包括她自己起草的新的许可证。但是，创建新的自由软件许可证需要法律知识和技能，以避免含糊不清和漏洞。此外，已经存在许多自由软件许可证，理解这些许可证的交易成本很高。除非开发人员有充分的理由，否则不建议创建新的许可证。

修改现有模块时

[编辑 | 编辑源代码]

阿布尔和他所在的学校使用的办公应用程序有一个英文界面。它不支持当地语言。对于高中生来说，使用英文界面可能不会造成问题。然而，当阿布尔试图教村民时，却遇到了困难。他向纳兹莉咨询了这个问题。纳兹莉一直为自由软件项目做出贡献，并且也对该办公应用程序的源代码非常熟悉。她和几个朋友一起讨论了这个问题，并作为一个团队开始对应用程序进行本地化。

  • 相关法律问题：确定要修改的程序的许可证

当开发人员试图修改现有模块，并且修改不仅仅是为了她自己的使用，而是为了进一步分发（例如，本地化项目）时，她需要首先识别模块的许可证。

开发人员
根据许可证，我被授予了哪些权利，以及在行使这些权利时有哪些限制？
例如，在分发自由软件作品时，一些自由软件许可证（例如GNU GPL、LGPL）可能要求分发者提供目标代码和源代码，或者至少提供有关如何访问源代码的信息。在修改自由软件作品时，一些自由软件许可证（例如GNU GPL、LGPL、BSD）可能要求修改者提供所做更改的文档。在分发衍生作品时，复制左许可证要求衍生作品以与原始作品相同的许可证获得许可，而其他自由软件许可证允许修改者选择不同的许可证（BSD、MIT）。
如果纳兹莉和她的朋友们试图对双重许可的OpenOffice进行本地化，并且他们决定使用根据GNU GPL许可的版本，那么本地化的 OpenOffice 也将是 GPL 许可的。使用原始的许可证方案（双重许可），本地化可以轻松地集成到原始项目中，并且至少可以部分地维护在原始项目中。使用更严格的方案意味着本地化可能必须在本地维护。允许额外的许可证（例如，为了将来能够在其他项目中使用部分作品）通常没有问题。
一些自由软件许可证（例如MIT 许可证）可能允许用户对原始作品进行再许可。这意味着在分发原始作品的逐字副本时，在原始版权持有者授予的范围内，分发者可以选择不同的许可证并成为许可者。在这种情况下，当开发人员创建衍生作品并将其与原始作品一起分发时，他/她可以选择成为原始作品和衍生作品的许可者，这将法律关系简化为仅存在于双方之间的关系。如果不允许再许可，那么收到修改后作品的人将有两个许可者。原始作品的许可者将是原始作品的作者，而衍生作品的许可者将是准备衍生作品的开发人员。

将不同的自由软件模块集成到一项服务中时

[编辑 | 编辑源代码]

纳兹莉在 AA 软件公司工作。为了更好地监督公司正在开发的许多不同的项目，该团队通过集成不同的自由软件模块构建了一个项目管理系统。该管理系统目前仅供内部使用，但由于它非常方便，因此该公司还计划将来以商业方式分发它。

自由软件许可证不对为内部使用而进行的修改施加限制。但是，当基于这些修改创建公开分发时，开发人员必须考虑正在使用的所有模块的许可证。

  • 相关法律问题：识别正在集成的程序的许可证，并查看这些许可证是否兼容。
在发布包含多个不同模块的项目时，必须确定每个模块的许可证。如果它们碰巧是在相同许可证下获得许可的，例如GNU GPL，那么集成系统将根据该许可证获得许可。当所有模块都在BSD 许可证下获得许可时，情况类似。但是，在这种第二种情况下，因为 BSD 许可证更加宽松，所以 AA 能够为修改后的模块和集成系统选择其他自由软件许可证或专有许可证。（BSD 许可证的宽松性允许 AA 通过添加更多条件来“缩小”许可证，而 GPL 不允许这样做。）
但是，如果某些模块具有不同的许可证，那么 AA 将不得不查看这些许可证的兼容性。当两个许可证兼容时，根据这两个许可证获得许可的两个模块可以合并成一个更大的作品，同时遵守两个许可证。[1]
在将一个根据GPL许可的程序和一个根据BSD许可（与 GPL 兼容）的程序组合成一个更大的程序时，更大的程序必须是 GPL 许可的，以满足 GPL 许可的程序和 BSD 许可的程序的要求。如果某些模块是 GPL 许可的，而其他模块与 GPL 不兼容，则 AA 必须决定哪个模块对他们来说更重要，并将另一个模块替换为具有兼容许可证的模块。[2]
不同模块中使用的许可证以及它们组合在一起的方式将决定如何对集成系统进行许可和分发。
  • 其他注意事项——法律选择和管辖范围选择条款
最后，对于能够为他们的程序选择许可证的人，无论是他们创建了自己的程序，还是他们被允许为他们准备的衍生作品选择许可证，他们应该意识到许多 OSI 批准的许可证是由专有软件公司开发的。有些是为了满足他们公司的政策和策略而设计的，因此对于一般的开发人员来说可能不是一个好的选择。某些技术问题，例如关于法律选择和管辖范围的条款（可以在Qt 公共许可证、Mozilla 公共许可证、通用公共许可证等中找到），在提起诉讼时可能会变得很重要。

供应商/生产者（企业）

[编辑 | 编辑源代码]

纳兹莉和她的朋友们已经发布了本地化的自由软件办公软件版本。AA 软件公司对该应用程序感兴趣。他们还开发了一些其他小型但有用的程序，用于行政工作。他们将本地化的办公软件与他们自己的程序（根据其专有许可证获得许可）一起打包。该软件包大受欢迎。几个月后，AA 还决定以商业方式分发他们从不同的自由软件模块集成的项目管理系统。

单纯分发
在这种情况下，自由软件和专有程序都包含在一个软件包中。对于自由软件应用程序，AA 只是一个分发者，并且必须按照其自由软件许可证的要求进行分发。对于专有程序，AA 持有版权，并且能够选择许可证和分发方式。将自由软件和专有应用程序放入一个分发软件包中（例如一张 CD-ROM）是可以的，如果这些应用程序分别运行，并且不会链接在一起创建任何衍生作品。
集成系统的分发
在集成系统分发的情况下，关键的是不同集成模块的许可证以及这些模块组合在一起的方式。如前所述，AA 需要首先确保不同模块的许可证允许 AA 将它们组合在一起。这些许可证也将决定 AA 可以分发集成系统的方式。
其他注意事项——驱动程序和认证
FOSS 供应商可能会遇到的一个困难是，硬件供应商可能没有意识到 FOSS 软件，因此无法提供驱动程序来使 FOSS 应用程序能够在硬件上运行。在硬件供应商中推广 FOSS 的理念非常重要。当有更多 FOSS 用户时，这将更容易。

同样，有时需要认证才能使 FOSS 与特定专有软件正常工作。更大的 FOSS 用户群将鼓励专有软件公司认证可能与他们的程序一起使用的 FOSS 应用程序。

其他考虑因素 - 嵌入式系统或设备中使用的 FOSS
FOSS 也用于电子设备中的嵌入式系统，例如手机、手持设备、数码相机和 DVD 播放器。使用 FOSS 可以帮助设备制造商在开发新产品时降低成本。设备的分配不同于 FOSS 本身的分配。关于后者，特定许可的规则仍然适用。

GPL 版本 3 要求不仅提供嵌入式设备的源代码，还描述如何将软件的本地修改版本安装到设备中，除非设备无法更新（例如，因为软件在 ROM 中）。

其他考虑因素 - 源代码
许多 FOSS 许可证坚持要求源代码可用。这必须是已分发的编译程序的实际源代码。由于对软件的更改会导致难以察觉的错误，使其在使用它的环境中变得不可用，因此仅提供最新版本的源代码是不够的。避免跟踪每个版本的简单方法是始终将源代码与编译后的软件一起分发（或在通过提供下载进行分发时，将它们保持在一起）。

政府资助的项目

[编辑 | 编辑源代码]

FOSS 运动和快速的 FOSS 发展不仅引起了 FOSS 社区的关注，也引起了学术界和政策制定者的关注。在一些亚洲国家，政府与 PC 制造商/供应商合作，提供捆绑了 FOSS 操作系统 和办公应用程序的经济实惠的 PC。[3] 政府还支持 FOSS 开发，生成与 FOSS 相关的项目，并推广 FOSS 作为国家技术和产业政策。[4] 但早在政府开始注意到 FOSS 的潜力并制定出明确的立场之前，一些与政府相关的学术机构就已经在进行与 FOSS 相关的项目。

FSF 维护的关于 GNU GPL 的常见问题解答还列出了关于美国政府是否可以在 GNU GPL 下发布程序或发布对 GPL 程序的改进的问题。[5] 情况可能因国家而异，也可能因不同国家不同的政府法规而异。大多数关于政府资助项目的政府法规通常是在其国内版权和专利法下起草的，并可能受到更保护主义的思想的影响，因此可能不熟悉，甚至对 FOSS 许可和开发模式不友好。

以下是两个政府资助的 FOSS 研究案例。第一个是关于在政府研究机构中进行的与 FOSS 相关的研究，没有相关的政府政策，而第二个是关于一个国家 FOSS 项目。

政府资助的 FOSS 项目：来自亚太地区的案例

[编辑 | 编辑源代码]

政府关联研究机构下的一个 FOSS 项目：多语言编辑器，日本

[编辑 | 编辑源代码]

Emacs 是由 理查德·斯托曼 在 麻省理工学院 开发的多语言文本编辑器。在 GNU 项目 于 1984 年 开始后，GNU Emacs 的开发开始，并在 1985 年 首次发布，根据 GNU GPL。

日本政府研究机构电子技术综合研究所 (ETL)[6] 在 1990 年代中期 开始研究多语言信息处理和整合 GNU Emacs 和 Mule（基于 Emacs 的多语言文本编辑器，后来并入 GNU Emacs 作为 MULE），但存在各种版权问题。

ETL 是一个政府研究机构，GNU GPL 中的许可模型与日本版权法大不相同，因此没有人能够确定 ETL 是否可以将代码分配给 FSF 并在 GNU GPL 下发布代码。结果，ETL 从未正式发布代码，而是发布了试用版。后来，ETL 和 FSF 之间进行了更多谈判，并达成了一项特殊协议。FSF 同意不要求 ETL 将修改后代码的版权分配给 FSF，ETL 同意授予 FSF 使用代码的权利。这是 Emacs 中一部分代码不属于 FSF 的第一次。

在 2001 年，ETL 被重组为国家先进工业科学技术研究所 (AIST)。虽然 AIST 仍然是一个政府资助的研究所，但它是一个独立的组织，其资产不是国家财产。似乎 AIST 将能够在 GNU GPL 下正式发布代码。但是，最初，AIST 的高层仍然很难做出最终决定。他们又花了一年的内部谈判时间来决定 AIST 有权发布他们的作品并选择他们作品的许可证。说服人们接受 GNU GPL 的优势也不容易。据 AIST 首席研究员半田健一博士说，AIST 管理层做出最终决定的原因从未清楚。

这发生在日本政府对 FOSS 开发形成明确立场之前。在 2003 年 亚洲国家举办的开源会议上，半田博士受邀发表关于 Emacs 开发的演讲，经济产业省领导的日本 FOSS 项目领导人田代修一表示，日本政府已经做出了必要的监管修订，以赋予政府资助项目的开发者版权（以及选择许可的权利），只要该法律从项目开始就适用。

在本例中，我们可以看到，当政府不熟悉 FOSS 许可和开发模式时，相关的政府法规可能会给寻求全面参与 FOSS 开发的政府关联研究机构带来不必要的困难。AIST（前身为 ETL）花了数年时间才最终能够在 GNU GPL 下正式发布代码。即使现在有特殊法规促进政府资助的开源项目的 FOSS 许可证的使用，但它们仍然被视为例外。

一个国家 FOSS 项目：自由软件产业发展项目，台湾

[编辑 | 编辑源代码]

在国会的压力下，台湾政府于 2002 年 开始规划一个国家 FOSS 项目，并在 2003 年 为一个为期五年的 FOSS 项目分配了大量预算。经济部 (MoEA) 被指定来构建、赞助和监督所有子项目。

根据由国家科学委员会 (NSC) 管理的一般政府法规，虽然结果可以由执行政府资助项目的实体拥有版权，但这些结果的应用仍然受到某些监管原则的约束。除非对国家科技发展更有利，否则结果必须

  1. 付费许可。
  2. 许可给台湾机构或公司。
  3. 在台湾管辖范围内使用或制造。

尽管 FOSS 项目可能会做出例外，但法律还没有以这种方式正式解释，没有人想冒违反法规的风险。

此外，国家 FOSS 项目被分配给了经济部，而经济部拥有保护国家利益和经济竞争力的更重要任务。因此，他们的规定比一般规则更具保护性和限制性。这些限制性规定被应用于国家 FOSS 项目。根据经济部的规定，只有第三项原则（在台湾管辖范围内使用和制造）可以豁免。这意味着国家 FOSS 项目的产出必须付费许可，并且只能许可给台湾的机构或公司。这些原则与 FOSS 许可模型不一致，使得国家 FOSS 项目下的所有子项目都很难发布他们的代码。

这个问题在五年期 FOSS 项目启动后就被提出来了。不同的政府机构多次会面，试图找到解决方案。由于 FOSS 许可模型对于他们惯用的模型来说太陌生了，直到第二年（2004）年中才解决这个问题，第一年开发的代码也没有及时正式发布。

这尤其成问题，因为国家 FOSS 项目下的一个子项目正在集成一个现有的 FOSS 程序。与此同时，该子项目打算参与并贡献到这个特定的 FOSS 项目。当社区准备将所有最新发展合并并在2004 年 3 月下GNU GPL发布其更新版本时，他们发现很难将台湾政府资助的子项目下开发的代码合并到一起。

直到2004 年 5 月举行了一次谈判后，不同的政府机构才最终找到了解决方案。经济部将该案件提交给行政院（最高行政机构），以获得政府关于 FOSS 项目是否符合例外条款并因此免除这些原则的正式解释。同时，经济部开始研究修订其限制性规定的可能性。

行政院最终在2004 年 7 月做出了正式解释，这距离国家 FOSS 项目正式启动已经过去了 18 个月。根据新的解释，政府资助的 FOSS 项目符合一般 NSC 规则的例外条款，可以免除与 FOSS 许可冲突的原则。虽然经济部的规定尚未修改，但一些代码生成 FOSS 项目被分配给了 NSC 和一般 NSC 规则，而不是更严格的经济部规则。希望 FOSS 项目能够此后在 FOSS 许可下发布代码。

这个案例表明，虽然政府已经开始认识到 FOSS 开发的重要性，但其监管和行政结构可能还没有准备好适应 FOSS。在台湾国家 FOSS 项目的案例中，在相关政府和项目人员的共同努力下，这个问题最终在一定程度上得到了解决。但这已经造成了一些严重的问题，特别是在与国际和本地 FOSS 社区合作方面。由于许多国家现在也认识到 FOSS 开发的重要性，并且正在开始或计划开始他们政府的 FOSS 项目，因此审查和更新相关法律结构以促进 FOSS 开发至关重要。

脚注

[edit | edit source]
取自 "https://wikibooks.cn/w/index.php?title=FOSS_Licensing/Scenarios&oldid=3324899"
华夏公益教科书