OSDev——许可证

最新推荐文章于 2024-06-21 16:41:46 发布

lrcno6_

最新推荐文章于 2024-06-21 16:41:46 发布

阅读量144

点赞数

分类专栏： OSDev 文章标签：许可证操作系统

原文链接：https://wiki.osdev.org/Licensing

版权

OSDev 专栏收录该内容

11 篇文章 0 订阅

订阅专栏

原文链接：https://wiki.osdev.org/Licensing

主页：https://blog.csdn.net/qq_37422196/article/details/122591214

下面的链接如果指向原网站的话，大概是还没有翻译

在赶了在赶了……

“阅读法律糊状物可以让你的大脑变成鳄梨酱！”——Amiga ROM内核参考手册：Includes & Autodocs，第2版

介绍

当一个出色的新软件的想法一闪而过时，许可问题通常是你最不想考虑的事情。但是许可问题可能会在之后狠狠地给你一个教训。所以最好花点时间考虑一下。这篇文章实际上不仅适用于操作系统开发，也适用于一般的软件

软件许可证最可怕的地方可能是没完没了的法律术语；我们尽量使文本保持简洁明了

主流许可证

以下是最受欢迎的许可证，以及它们的简短描述（来为你提供帮助）：

GNU通用公共许可证(GPL)：

用户有权获取源代码，并且可以自由使用、修改和重新分发，只要仍然公开源代码并且一切都仍在GPL下。链接到GPL代码的目标文件也属于GPL
GNU较宽松通用公共许可证(LGPL)：

用户有权获取源代码，并且可以自由使用、修改和重新分发，只要保持公开源代码并且一切都保持在LGPL或（可选）GPL之下。链接到LGPL代码的目标文件不受LGPL影响，但用户必须能够自行链接（即，单独分发你的非(L)GPL目标文件，而不是链接到LGPL代码）
伯克利软件分发(BSD)许可证：

只要保留BSD许可证中的版权声明，用户就可以自由使用、修改和重新分发，无论是否包含源代码。请注意，BSD有两个版本，含义略有不同
知识共享(CC)许可证套件：

这与其他许可证的不同之处在于其许可证有多种变体，每种变体都有自己的特定规定。开发者可以选择是否限制分发、衍生用途、商业用途；所有六个版本的唯一共同点是作者获得原始代码的归属。这是GPL的一个越来越流行的替代方案，因为它相当简单，但也被认为不那么“粘性”
公共领域：

放弃版权，对使用、修改或再分发没有任何限制。在某些国家，公共领域是不可能的，即使出版商不居住在这样的国家。通常它仍会授予用户全部权利（除非可能的情况是不可能的，例如精神权利），因为意图很明确。尽管如此，仍然应该有一个备用条款，允许用户拥有全部权利。使用公共领域的最简单方法是CC0
专有许可证：

授权用户可以免费使用；也许（取决于合同）他们可以修改以供自己使用，但不得重新分发
无许可证信息：

默认为“保留所有权利”，这通常在作者和用户的意料之外…

被雇佣为软件开发者

当你签订雇佣合同时，你在办公时间编写的代码通常归支付你工资的人所有，除非你的合同另有明确规定。

在一些国家[哪个？]，一份工作合同可以涵盖你在某个知识领域所做的所有工作，只要合同有效，有时甚至超出此范围。这意味着，如果你被雇用在白天编写代码，那么你在下班后在家编写的代码也可能是你雇主的合法财产，原因是，由于你的雇主为你在某个领域的工作（和获取经验）支付了报酬，因此该经验是有偿的，并且你有义务将该经验回馈为你支付报酬的公司。另一个理由可能是不允许你在业余时间构建可能成为你公司产品竞争对手的产品

这对你来说可能听起来很奇怪，甚至令人发指。但是你真的应该和你的上级谈谈。最好的情况下，你的上级会看到你真的是一个敬业的软件工程师，很高兴有这样一个热情的人签约，并告诉你继续你的业余项目。最坏的情况下，你会被告知你不能在那个项目上工作——在你编写了一万行源代码并被你的雇主起诉之前

这不是玩笑，也不是掉以轻心的事情。如果你的雇主粗暴对待并起诉你违反合同，你可能会失去工作，以及除此之外的一大笔钱。自由软件基金会要求你在接受你的代码提交之前提交由你的上级签署的文件，而你的上司通常不会签署，因为他们喜欢官僚主义

合并源代码

你正在寻找是否可以利用一些现有的源代码以插入到你自己的代码库中

无许可声明——如上所述，如果你是软件开发人员并且你没有允许使用的书面证明，则不可以从雇主的代码库中获取代码，并将其粘贴到你自己的项目中。你会被解雇并被起诉。不要这样做

你可能会惊讶地听到发布到某个论坛的教程或代码片段的版权归其作者所有，除非另有明确标记。从法律上讲，这意味着你也不能将它们复制到你的代码中。然而，这对于作者和读者来说通常都是意料之外的，你可以联系他们以获得个人许可证（见下文）
专有许可声明——复制和粘贴专有许可下的源代码几乎是不可行的（以实际许可为准）。通常，你甚至无法访问源代码
公共领域——公共领域是软件社区的O-型血：复制公共领域源码总是可以的
BSD许可证——BSD许可证要求你保留版权声明和构成BSD许可证的条件列表。因此，该部分的源代码保留在BSD许可证下，无论它集成到的代码的许可证是什么。你可以在任何BSD或(L)GPL项目中自由使用BSD源代码，无需另行通知
- (L)GPL项目应该知道，BSD的源代码可以在以后被专有或公共领域项目合法地“提取”，而不会侵犯 (L)GPL
- 一个公共领域项目可以做类似的事情，但这意味着该项目不再全部属于公共领域，而是带有BSD部分的公共领域项目——这应该在源代码和文档（如果有的话）的明显位置指出
- 我完全不确定将 BSD源包含到专有软件中的法律含义，因为你必须保持“条件列表”的完整性，其中包括重新分发的许可。我听到了关于这方面的相互矛盾的意见——马丁鲍特
LGPL——如果你自己的项目在LGPL或GPL下，你可以在不另行通知的情况下复制LGPL的源代码，因为LGPL明确允许将源代码从LGPL“提升”到GPL

另请参阅下面有关(L)GPL版本的段落
GPL——除了在同样的GPL项目中，你不能获取GPL的源代码并在其他任何地方使用它

请注意，虽然LGPL的代码可能会被“提升”为GPL，但不允许以相反的方式进行(GPL->LGPL)

另请参阅下面有关(L)GPL版本的段落

单独的翻译单元/目标代码

你有一个单独的翻译单元（即，对应于单个目标文件、模块等的文件或文件集合，或用于链接的二进制目标文件），并且你希望将其集成到你的项目中（通常通过在编译时包含头文件并在编译可执行文件/库时链接二进制对象）

没有许可声明——如果没有许可声明，则你无权使用或重新分发。远离
专有许可声明——以实际许可条款为准
公共领域——没有附加条件，继续
BSD许可证——你必须保持BSD许可证中的版权声明和条件列表完好无损。如果你仅发送二进制文件，请放在文档中；否则，请放在源中

根据我上面的说明，我建议将BSD许可单元分开识别（如下所述LGPL的东西），以避免对适用于整个项目的BSD许可产生任何误解，包括重新分发的权利——马丁鲍特
LGPL——你可以使用LGPL的源，但如果项目本身不是(L)GPL的，必须将它们保存在单独的翻译单元中

如果你仅分发二进制文件，则必须提供目标代码的未链接版本，以便人们可以链接到LGPL部分的不同版本。这是LGPL的明确要求！

另请参阅下面有关(L)GPL版本的段落
GPL——你只能在本身属于GPL的项目中使用GPL的源代码

另请参阅下面有关(L)GPL版本的段落

引用/教育

这里的问题是，使用X作为教程材料编写的代码是否是“源自X的作品”（GPL术语）和/或“盗窃知识产权”（公司律师术语）。这在很大程度上取决于所涉及的代码，你编写的代码有多少实际上是基于你之前阅读的内容以及你询问的对象

没有许可声明——假设最坏的情况（如果有人发现则提起诉讼）
专有许可声明——以实际许可为准
公共领域——继续前进，受到启发并获得巨额利润；作者不会介意的
BSD许可证——BSD许可证适用于代码本身，“无论是否修改”，但并未提及从中获得灵感。你应该可以安全地使用BSD许可代码来进行学习
(L)GPL——LGPL和GPL都要求任何“源自产品的作品”必须置于相同的许可下

铁杆布道者声称，受到(L)GPL代码的启发构成了“源自产品的工作”。就个人而言，我认为这与声称白天付钱就能让公司拥有你晚上编写的代码一样荒谬。似乎尚未有人将此类案件提交法庭，但意见存在，所以要小心