Licensing/en

来自osdev
跳到导航 跳到搜索

<languages/>

本文的语气或风格 可能无法反映整个wiki使用的百科全书式语气。 有关建议,请参阅 Wikipedia's article on tone

"Reading legal mush can turn your brain to guacamole!" - Amiga ROM Kernel Reference Manual: Includes & Autodocs, 2nd edition


Introduction

When the idea for a brilliant new piece of software strikes, Licensing Issues are usually the last thing you want to think about. But Licensing Issues can bite you afterwards, in a way that really hurts. So it might be best to spend a moment of consideration. This text actually does not apply only to OS development, but to software in general.

Probably the scariest thing about software licenses are the endless paragraphs of legalese; we try to keep this text as crisp and short as possible.


Popular Licenses

Here's the most popular ones, with a very short version of the licence (to help you all):

GNU General Public License (GPL):

Users have a right to receive source code, and are free to use, modify, and redistribute as long as sources remain available and everything stays under GPL. Object files linked to GPL'ed code fall under GPL too.

GNU Lesser General Public License (LGPL):

Users have a right to receive source code, and are free to use, modify, and redistribute as long as sources remain available and everything stays under LGPL or (optionally) GPL. Object files linked to LGPL'ed code are unaffected by the LGPL, but users must be able to link themselves (i.e., distribute your non-(L)GPL'ed object files separately, not linked to the LGPL'ed code).

Berkeley Software Distribution (BSD) License:

只要BSD许可证中的版权声明仍然有效,用户可以自由使用、修改和重新发布源代码,也可以不使用源代码。 请注意,有两个版本,含义稍有不同。

The Creative Commons (CC) License Suite:

这与其他许可证的不同之处在于,许可证有几种变体,每种变体都有自己的具体规定。 开发商可以选择是否限制分销、衍生用途、商业用途,或其中任何一种或任何一种;所有六个版本的唯一共同要求是作者获得原始代码的属性。 这是一种越来越受欢迎的GPL替代方案,因为它相当简单,但也被认为不太“粘性”。

Simple Public Domain:

版权被放弃,对使用、修改或再分配没有任何限制。 在某些国家,公共领域是不可能的,即使出版商不住在这样的国家。 通常,它仍然会授予用户完全的权利(除了可能不可能的情况,比如道德权利),因为意图是明确的。 尽管如此,仍然应该有一个回退条款,允许用户拥有全部权利。 The easiest way to handle using public domain is the CC0.

专有许可证: :授权用户可以自由使用;也许“”(取决于合同),他们可以修改以供自己使用,但不能重新分发。

无许可证信息:

默认为“保留所有权利”,这通常会让作者和用户感到惊讶。。。


被聘为软件开发人员

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

在一些国家{{{},工作合同可以包含“你在某一知识领域所做的所有工作,只要合同有效,有时甚至超过该范围”。这意味着,如果你被雇佣在白天编写代码,那么你在家办公时间后编写的代码可能“也是”你雇主的合法财产,理由是,既然你的雇主为你在某个领域的工作(并获得经验)向你支付报酬,那么你的经验是值得支付的,你有义务将这种经历重新投入支付给你的公司。另一种推理可能是,你不允许在业余时间制造可能成为公司产品竞争对手的产品。

你可能觉得这很奇怪,甚至有些离谱。 但是你真的应该和你的上司谈谈。 充其量,你的上司会看到你真的是一个敬业的软件工程师,很高兴有这么一个热情的人签下合同,并告诉你继续你的业余项目。 在最坏的情况下,你会被告知你不能在那个项目上工作——“在”你大量生产了10000行源代码并被雇主起诉之前。

这不是一个玩笑,也不是一件可以掉以轻心的事情。 如果你的雇主粗暴对待你,并以违约为由起诉你,你可能会失去工作,还有一大笔钱。 [1]要求你在接受你的代码提交之前提交由你的上级签署的文件,而他们之所以不这样做,是因为他们喜欢官僚主义。

这意味着,除非你是“确定”你的法律地位,考虑你在办公时间内工作的代码是“外国”的来源,“即使你自己写了”。无论源文件中给出的许可信息“是否”适用于您,如果给出的许可信息为“否”,则表示“保留所有权利”,“即使您是作者,因为您可能不是版权所有者”。


合并源代码

您正在查看是否可以修复一些现有的源代码以插入 进入您自己的代码库。

  • Without License Statement - 如上所述,如果您被聘为软件开发人员,并且没有相反的“书面”证明,则“不”允许您从雇主的代码库中获取代码,并将其粘贴到您自己的项目中。 你会被解雇和起诉。 不要这样做。
 :您可能会惊讶地听到,除非“明确”标记为其他内容,否则发布到某个论坛的教程或代码片段受其作者的版权保护。 “从法律上讲”,这意味着您也不能将它们复制到代码中。 然而,这通常对作者和读者来说都是令人惊讶的,您可能会联系他们获取个人许可证(见下文)。
  • “专有许可证声明”- 复制和粘贴拥有专有许可证的源(以实际许可证为准)实际上是“从不”确定的。通常,您甚至无法访问源。
  • Public Domain - 公共域是软件社区的O型阴性血型:复制PD源“总是”可以。
  • BSD License - BSD许可证要求您保留版权声明和构成BSD许可证的条件列表。因此,源代码的特定部分“保留”在BSD许可证下,无论它集成到哪个代码许可证中。只要您尊重您可以在任何BSD'ed或(L)GPL'ed项目中自由使用BSD源,无需另行通知。
 **(L)GPL’ed项目应意识到,BSD’ed源片段可在不侵犯(L)GPL的情况下,由专有或PD项目合法“提取”。
 **PD项目也可以做类似的事情,但这意味着该项目不再是PD“整体”,而是带有BSD部分的PD-应在源文件和文档(如有)的显著位置指出。
 **“我完全不确定将BSD源代码包含到专有软件中的法律含义,因为您必须保持“条件列表”完整,其中包括重新分发的许可。我在这方面听到了相互矛盾的意见马丁堡特
  • LGPL - 如果您自己的项目在LGPL或GPL下,您可以在不另行通知的情况下复制LGPL的源代码,因为LGPL明确允许将源代码从LGPL“升级”到GPL。
 :另请参见下面关于(L)GPL版本的段落。
  • GPL - 除了在类似的GPL项目中,您不能在任何其他地方使用GPL源代码。
 :注意,虽然LGPL’ed代码可以“升级”为GPL,但不允许以相反的方式(GPL->LGPL)执行。
 :另请参见下面关于(L)GPL版本的段落。


独立翻译单元/目标代码

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

  • 无许可证声明 - 如果没有许可证声明,则您无权使用或重新发布。远离,远离
  • 专有许可证声明 - 以实际许可证的条款为准。
  • 公共领域 - 没有附加条件,继续吧。
  • 许可协议 - 您必须保持BSD许可证中的版权声明和条件列表的完整性。如果您仅提供二进制文件,请在文档中;否则,在源代码中。
 :“根据我上面的说明,我建议将BSD许可单位分开(如下所述,用于LGPL’ed的内容),以避免对BSD许可证适用于“整个”项目(包括重新发布的权利)产生任何误解。”马丁堡特
  • LGPL - 您可以使用LGPL'ed源,但非(L)GPL'ed本身的项目“必须将它们保存在单独的翻译单元中”。
 :如果仅分发二进制文件,则“必须”提供目标代码的“未链接”版本,以便人们可以链接LGPL部分的“不同”版本。这是LGPL的明确要求!
 :另请参见下面关于(L)GPL版本的段落。
  • GPL - 您只能在GPL下的项目中使用GPL源。
 :另请参见下面关于(L)GPL版本的段落。


参考/教育

这里的问题是使用X作为教程材料编写的代码是否正确 “源于X的作品”(GPL术语)和/或“窃取知识产权” “财产”(公司律师术语)。这在很大程度上取决于代码 涉及到,您编写的代码中有多少是基于 你以前读过什么,问过谁。

  • Without License Statement - 承担最坏的后果(如果有人发现,则提起诉讼)。
  • Proprietary License Statement - 以实际许可证为准。
  • Public Domain - 继续前进,受到鼓舞,收获巨大的利润;作者不会介意的。
  • BSD License - BSD许可证适用于代码本身,“有修改或无修改”,但并未提及从中获得灵感。 您应该可以安全地使用BSD许可代码进行自我教育。
  • (L)GPL - LGPL和GPL都要求任何“从产品衍生的作品”必须置于同一许可证之下。
 :铁杆福音传道者声称,受到(L)GPL'ed代码的启发构成了“从产品衍生的作品”。就我个人而言,我认为这是无稽之谈,因为声称一天付给你一家公司拥有你晚上的代码。似乎还没有这样的案件被提交到法庭,但意见是存在的,所以要小心。


(L)GPL versions

GPL和LGPL有一个转折点,因为它们是“版本化的”。 版权 持有人可自由指定源应提供的(L)GPL的特定版本 是否根据或特定版本“或任何更高版本”获得许可 指定任何版本。

复制(L)GPL’ed代码时请注意这一点。 如果未指定版本, 你可以假设版权所有者不在乎,然后添加一个版本 带或不带“或任何更高版本”零件的规范。

但如果版权持有人指定了一个版本,则您不得添加“或” 任何更高版本“如果它不存在,或删除现有版本而不写入 版权持有人的同意。


个人许可

我们在本文档中只讨论了“通用”许可证。 如果许可证 对于“特定”代码段给您带来的问题,您可以“始终”尝试 联系版权持有人并申请个人许可证。

例如,如果您正在组装一个PD库,那么 完成是仅在BSD许可证下可用的特定功能,请询问 版权所有人是否可以将“此”功能包含到您的 不必麻烦BSD版权通知/版权清单的项目 条件


更改许可证

作为项目的版权所有者,您完全可以“更改”项目 项目的授权。 但是,要准备好面对来自同龄人的愤怒, 因为这对他们来说通常是个惊喜。

是的,您可以“自由”发布v2。以前GPL项目的0作为 专有软件,就像您可以自由发布以前的专有软件一样 GPL下的软件。 在前一种情况下,你的同龄人同样可以自由选择 版本v1。9和继续GPL下的项目,因为你是“不”允许的 “追溯性”更改许可证。


贡献者陷阱

这其中有一个转折点,同样令人惊讶的是,论坛帖子也在不断增加 “保留所有权利”或你的雇主告诉你“你所有的基地都属于你” 对我们来说,“贡献者陷阱”。

假设您已经阅读了以上所有内容,并突然决定 GPL下的项目不是一个好主意:你想更改许可证。 现在,如果你独自完成你的项目,没有什么能阻止你。

但是',如果有许多其他人为你的项目做出贡献,你可能会在 深层次的麻烦,比如“从法律上讲”,也可能从道德上讲- 您可能不再是唯一的版权所有者,许可证只能 更改为“如果所有版权所有者同意”。

让我重复一下:如果您想更改项目的许可证

  • 从GPL到其他任何东西;
  • 从LGPL到GPL以外的任何其他内容;
  • 从BSD到其他任何东西;
  • 从某个X到某个Y我都没想过;

即使是您自己的项目,也可能不允许您这样做

出于这个原因,许多项目在GPL声明中添加了“或任何更高版本”,因为这样就不再需要项目的所有版权所有者同意更改为新的GPL版本。 也可以删除较旧版本的GPL以获得较新版本的软件。


另见


外部链接