“Licensing”的版本间差异
小 |
|||
第24行: | 第24行: | ||
[https://creativecommons.org/licenses/?lang=en 知识共享(CC)许可证套件]: | [https://creativecommons.org/licenses/?lang=en 知识共享(CC)许可证套件]: | ||
: 这与其他许可证的不同之处在于,这是几种许可证变体的统称,每种变体都有自己的特定规定。 | : 这与其他许可证的不同之处在于,这是几种许可证变体的统称,每种变体都有自己的特定规定。 开发者可以选择是否限制发行、衍生用途、商业用途,或其中任何一种; 所有六个版本唯一的共同要求是必须保留作者对原始代码的署名权。 它是GPL越来越受欢迎的替代品,因为它相当简单,但也被认为不太有 “传播性”。 | ||
[[wikipedia:Public_Domain|简单公共领域许可]]: | [[wikipedia:Public_Domain|简单公共领域许可]]: | ||
第39行: | 第39行: | ||
当你签订雇佣合同时,你在办公时间编写的代码通常由支付你工资的人''拥有'',除非你的合同''明确''另有规定。 | 当你签订雇佣合同时,你在办公时间编写的代码通常由支付你工资的人''拥有'',除非你的合同''明确''另有规定。 | ||
在某些国家/地区{{which}},工作合同可能包括'' | 在某些国家/地区{{which}},工作合同可能包括''合同有效有效期内你在某一知识领域(有时甚至超出此范围)所做的所有工作''。 这意味着,如果你受雇于白天编写代码,你在家办公时间后编写的代码也可能是你雇主的合法财产。这是因为你的雇主付钱给你在某个领域工作 (和获得经验),这种经验是很有价值的,而你有义务将这种经验带回为你付出代价的公司。 另一个理由可能是,不允许你在业余时间制作可能成为公司产品竞争对手的产品。 | ||
这对你来说可能听起来很奇怪,甚至有些离谱。 但是进行业余开发时你真的应该和你的上司谈谈。 最好的情况,你的上司会看到你真的是一个敬业的软件工程师,很高兴有这么一个热情的人能签下合同,并告诉你继续你的业余项目。 在最坏的情况下,你会被告知你不能在那个项目上工作-- 但愿在这''之前''你还没已经写出了10K行源代码,并且被你的雇主起诉了。 | 这对你来说可能听起来很奇怪,甚至有些离谱。 但是进行业余开发时你真的应该和你的上司谈谈。 最好的情况,你的上司会看到你真的是一个敬业的软件工程师,很高兴有这么一个热情的人能签下合同,并告诉你继续你的业余项目。 在最坏的情况下,你会被告知你不能在那个项目上工作-- 但愿在这''之前''你还没已经写出了10K行源代码,并且被你的雇主起诉了。 | ||
第49行: | 第49行: | ||
==合并源代码== | ==合并源代码== | ||
假如你正在寻找一些现有的代码,看是否可以插入到自己的代码库中。 | |||
* '''无许可证声明''' - 如上所述,如果你是软件开发人员,并且没有允许的''书面''证明,则''不''允许你从雇主的代码库中提取代码,并将其粘贴到你自己的项目中。 你会被解雇和起诉的。 不要这样做。 | * '''无许可证声明''' - 如上所述,如果你是软件开发人员,并且没有允许的''书面''证明,则''不''允许你从雇主的代码库中提取代码,并将其粘贴到你自己的项目中。 你会被解雇和起诉的。 不要这样做。 | ||
: | : 了解到这些你可能会惊讶,发布到某些论坛的教程或代码片段也受其作者的版权保护,除非另有''明确''备注。(译者注:现在很多论坛都会专门要求发帖人接受开放授权。)''从法律上讲'',这意味着你也不能将它们复制到你的代码中。 但是,这通常对作者和读者一样都有点意外,其实你可以与对方联系以获取个人许可 (请参见下文)。 | ||
* '''专有许可声明''' - 实际上,复制和粘贴受专有许可(取决于实际许可)保护的源代码到别处是'''永远不'''可以的。 通常,你也甚至无法访问到它们的源代码。 | * '''专有许可声明''' - 实际上,复制和粘贴受专有许可(取决于实际许可)保护的源代码到别处是'''永远不'''可以的。 通常,你也甚至无法访问到它们的源代码。 | ||
* '''公共领域许可''' - 公共领域许可是软件社区的万能供血者:复制公共领域源代码''始终''是可以的。 | * '''公共领域许可''' - 公共领域许可是软件社区的万能供血者:复制公共领域源代码''始终''是可以的。 | ||
第59行: | 第59行: | ||
** 公共领域许可项目可以做类似的事情,但这意味着项目不再是''作为一个整体''的公共领域许可,而是带有BSD部分的公共领域许可 - 这应该在源代码和文档(如果有的话)的显著位置指出。 | ** 公共领域许可项目可以做类似的事情,但这意味着项目不再是''作为一个整体''的公共领域许可,而是带有BSD部分的公共领域许可 - 这应该在源代码和文档(如果有的话)的显著位置指出。 | ||
** ''我完全不确定将BSD源代码包含到专有软件中的法律含义,你最好必须保持原来BSD许可部分的"情况条件清单"不变,并在其中包括重新分配的许可说明。 关于这件事,我听到了些相互矛盾的意见。''- MartinBaute注 | ** ''我完全不确定将BSD源代码包含到专有软件中的法律含义,你最好必须保持原来BSD许可部分的"情况条件清单"不变,并在其中包括重新分配的许可说明。 关于这件事,我听到了些相互矛盾的意见。''- MartinBaute注 | ||
如果你自己的项目属于LGPL或GPL许可发布,你可以复制LGPL的源代码而无需另行通知,因为LGPL明确允许将源代码从LGPL'提升'到GPL。 | |||
: 另请参阅下面 (L)GPL版本的段落。 | : 另请参阅下面 (L)GPL版本的段落。 | ||
* '''GPL''' - 除了在类似的GPL项目中,你不能将GPL的源代码带到其他任何地方使用。 | * '''GPL''' - 除了在类似的GPL项目中,你不能将GPL的源代码带到其他任何地方使用。 | ||
第77行: | 第77行: | ||
: 如果仅分发二进制文件,则''必须''提供目标代码的 ''未链接''版本,以便人们可以链接LGPL部分的''不同''版本。 这是LGPL的明确要求! | : 如果仅分发二进制文件,则''必须''提供目标代码的 ''未链接''版本,以便人们可以链接LGPL部分的''不同''版本。 这是LGPL的明确要求! | ||
: 另请参阅下面关于(L)GPL版本的段落。 | : 另请参阅下面关于(L)GPL版本的段落。 | ||
* '''GPL'''- | * '''GPL'''- 你只能在本身就是GPL许可的项目中使用GPL的源代码。 | ||
:另请参阅下面关于(L)GPL版本的段落。 | :另请参阅下面关于(L)GPL版本的段落。 | ||
第89行: | 第89行: | ||
* '''BSD许可证 ''' - BSD许可证适用于代码本身,"是否经过修改",但并不涉及从中获得灵感。 你应该可以安全地使用BSD许可的代码来自学。 | * '''BSD许可证 ''' - BSD许可证适用于代码本身,"是否经过修改",但并不涉及从中获得灵感。 你应该可以安全地使用BSD许可的代码来自学。 | ||
* '''(L)GPL '''- LGPL和GPL都要求任何“源自产品的作品”必须置于同一许可证之下。 | * '''(L)GPL '''- LGPL和GPL都要求任何“源自产品的作品”必须置于同一许可证之下。 | ||
: | :铁杆传道者声称就算是受到(L)GPL代码的启发,这也构成了一种"源自"关系。 就我个人而言,我认为这和公司声称“付了你白天的工资,就要拥有你晚上编写的成果”一样荒谬。 同时似乎还没有这样的案件被提交法庭,但风险是存在的,所以要小心。 | ||
==(L)GPL版本== | ==(L)GPL版本== | ||
GPL和LGPL许可证经历过一个变革,后来它们是多''版本''的。 版权持有人可以自由指定源代码应根据的(L)GPL特定版本,或指定特定版本''及更高版本'',或根本不指定任何版本。 | |||
复制(L)GPL许可的代码时要注意这一点。 如果未指定版本,则可以假设版权所有者不在乎,并在你再次发布时带有或不带有"及更高版本"的版本规范。 | 复制(L)GPL许可的代码时要注意这一点。 如果未指定版本,则可以假设版权所有者不在乎,并在你再次发布时带有或不带有"及更高版本"的版本规范。 | ||
第103行: | 第103行: | ||
我们在本文档中只讨论了''通用''许可证。 如果''特定''代码的许可政策给你带来了问题,你''始终''可以尝试联系版权所有者并要求获得单独的许可。 | 我们在本文档中只讨论了''通用''许可证。 如果''特定''代码的许可政策给你带来了问题,你''始终''可以尝试联系版权所有者并要求获得单独的许可。 | ||
例如,如果你正在构建一个公共领域许可的库,而你完成需要的只是一个仅在BSD许可下可用的特定功能,请询问版权所有者是否可以在你的项目中包含''这''一个功能,而不必费心使用BSD版权声明/ | 例如,如果你正在构建一个公共领域许可的库,而你完成需要的只是一个仅在BSD许可下可用的特定功能,请询问版权所有者是否可以在你的项目中包含''这''一个功能,而不必费心使用BSD版权声明/条件清单。 | ||
== 更改许可证 == | == 更改许可证 == | ||
第118行: | 第118行: | ||
这时如果以前都是你一人独自从事你的项目,也没什么能阻止你。 | 这时如果以前都是你一人独自从事你的项目,也没什么能阻止你。 | ||
'''但是 ''',如果许多其他人为你的项目做出了贡献,那么你可能会遇到严重的麻烦,因为 - ''合法地说'',并且从道德上讲 - 你可能不再是项目唯一的版权所有者,并且许可证只能'' | '''但是 ''',如果许多其他人为你的项目做出了贡献,那么你可能会遇到严重的麻烦,因为 - ''合法地说'',并且从道德上讲 - 你可能不再是项目唯一的版权所有者,并且许可证只能''在每个版权所有者同意''下更改。 | ||
让我重复一下: 如果要更改项目的许可 | 让我重复一下: 如果要更改项目的许可 |
2022年2月16日 (三) 15:17的最新版本
本文的语气或风格 可能无法反映整个wiki使用的百科全书式语气。 有关建议,请参阅 Wikipedia's article on tone |
- "读起法规条文就让人满脑子浆糊" - Amiga ROM内核参考手册: Includes & Autodocs, 第二版
简介
当一个出色的新软件想法到来时,许可规则问题通常是你最后考虑的事情。 但许可证问题可能会在事后让你栽跟头,在某种程度上切实伤害你。 所以最好还是花点时间考虑一下。 本文实际上不仅适用于OS开发,还适用于其它一般的软件。
关于软件许可证,最可怕的可能是理解没完没了的法律条文; 我们尽量使这篇文章简洁明了。
热门许可证
以下是最受欢迎的一些许可证版本,并带有“非常”简短的对应说明(希望能帮助大家):
- 最终用户有权保留源代码,并可以自由使用、修改和重新发布,只要源代码仍然有效,所有内容要都在GPL下。 链接到GPL代码的对象文件也属于GPL。
- 最终用户有权保留源代码,并可以自由使用,修改和重新分发,只要源代码仍然有效,所有内容都保留在LGPL或 (可选) GPL下。 链接到LGPL代码的对象文件不受LGPL影响,但必须得最终用户自己来链接(即,需要单独分发还未链接到LGPL代码的非(L)GPL对象文件,让用户自己链接后使用软件)。
- 只要保留BSD许可证内的版权声明,用户就可以自由使用,修改和重新分发,无论有无提供源代码。 请注意,BSD两个版本,含义略有不同。
- 这与其他许可证的不同之处在于,这是几种许可证变体的统称,每种变体都有自己的特定规定。 开发者可以选择是否限制发行、衍生用途、商业用途,或其中任何一种; 所有六个版本唯一的共同要求是必须保留作者对原始代码的署名权。 它是GPL越来越受欢迎的替代品,因为它相当简单,但也被认为不太有 “传播性”。
- 放弃版权,对使用、修改或再分发没有限制。 在某些国家/地区,即使发布者不住在当地,也无法直接获得公共领域许可。 通常情况下,公共领域许可会向用户授予全部权利(个别情况例外,比如道德权利),因为就是要完全交出权利。 尽管如此,仍然应该有一个后备条款,允许用户明确拥有全部权利。 表达使用公共领域许可的最简单方法是使用 CC0。
专有许可证:
- 专门许可的用户可以免费使用; 也许 (取决于合同) 用户可以修改软件代码以供自己使用,但不能重新分发。
无许可证的情况:
- 默认为'保留所有权利',这样做的结果通常会让作者和用户都感到意外.
被聘为软件开发人员
当你签订雇佣合同时,你在办公时间编写的代码通常由支付你工资的人拥有,除非你的合同明确另有规定。
在某些国家/地区[待列出?],工作合同可能包括合同有效有效期内你在某一知识领域(有时甚至超出此范围)所做的所有工作。 这意味着,如果你受雇于白天编写代码,你在家办公时间后编写的代码也可能是你雇主的合法财产。这是因为你的雇主付钱给你在某个领域工作 (和获得经验),这种经验是很有价值的,而你有义务将这种经验带回为你付出代价的公司。 另一个理由可能是,不允许你在业余时间制作可能成为公司产品竞争对手的产品。
这对你来说可能听起来很奇怪,甚至有些离谱。 但是进行业余开发时你真的应该和你的上司谈谈。 最好的情况,你的上司会看到你真的是一个敬业的软件工程师,很高兴有这么一个热情的人能签下合同,并告诉你继续你的业余项目。 在最坏的情况下,你会被告知你不能在那个项目上工作-- 但愿在这之前你还没已经写出了10K行源代码,并且被你的雇主起诉了。
这不是开玩笑,也不是可以掉以轻心的事情。 如果你的雇主粗暴对待你,并以违约为由起诉你,你可能会失去工作,还有一大笔钱。 自由软件基金会在接受你的代码提交之前,会要求你提交由你上级签署的纸质文件。这样显得过程比较规范正式(官僚主义)。
这意味着,除非你 已明确 自己的法律地位,否则请将在办公时间内使用的代码视为 外来代码,即使是你自己编写了它们。 无论源文件中给出的许可信息是否适用于你,如果没有给出许可信息,则表示保留所有权利,因为即使你是代码作者,你也可能不是版权所有者。
合并源代码
假如你正在寻找一些现有的代码,看是否可以插入到自己的代码库中。
- 无许可证声明 - 如上所述,如果你是软件开发人员,并且没有允许的书面证明,则不允许你从雇主的代码库中提取代码,并将其粘贴到你自己的项目中。 你会被解雇和起诉的。 不要这样做。
- 了解到这些你可能会惊讶,发布到某些论坛的教程或代码片段也受其作者的版权保护,除非另有明确备注。(译者注:现在很多论坛都会专门要求发帖人接受开放授权。)从法律上讲,这意味着你也不能将它们复制到你的代码中。 但是,这通常对作者和读者一样都有点意外,其实你可以与对方联系以获取个人许可 (请参见下文)。
- 专有许可声明 - 实际上,复制和粘贴受专有许可(取决于实际许可)保护的源代码到别处是永远不可以的。 通常,你也甚至无法访问到它们的源代码。
- 公共领域许可 - 公共领域许可是软件社区的万能供血者:复制公共领域源代码始终是可以的。
- BSD许可证- BSD许可证要求你保留版权声明和说明那些构成BSD许可证的情况条件清单。 因此,源代码的特定部分可仍然单独保留在BSD许可证下,无论它所集成到的代码的许可证是什么。 只要你尊重这一点,那么你可以在任何BSD许可或 (L)GPL许可的项目中自由使用BSD源代码,而不用另行通知版权所有者。
- (L)GPL许可过的项目应该当心,BSD许可的源代码的部分可在不侵犯(L)GPL的情况下,由专有许可或公共领域许可项目合法'提取'。
- 公共领域许可项目可以做类似的事情,但这意味着项目不再是作为一个整体的公共领域许可,而是带有BSD部分的公共领域许可 - 这应该在源代码和文档(如果有的话)的显著位置指出。
- 我完全不确定将BSD源代码包含到专有软件中的法律含义,你最好必须保持原来BSD许可部分的"情况条件清单"不变,并在其中包括重新分配的许可说明。 关于这件事,我听到了些相互矛盾的意见。- MartinBaute注
如果你自己的项目属于LGPL或GPL许可发布,你可以复制LGPL的源代码而无需另行通知,因为LGPL明确允许将源代码从LGPL'提升'到GPL。
- 另请参阅下面 (L)GPL版本的段落。
- GPL - 除了在类似的GPL项目中,你不能将GPL的源代码带到其他任何地方使用。
- 请注意,虽然可以将LGPL的代码提升为GPL,但不允许反过来 (GPL -> LGPL)。
- 另请参见下面关于(L)GPL版本的段落。
单独使用编译转换后单位(对象)代码
你有一个单独转换后的单元 (即,与单个目标文件、模块等相对应的文件或文件集合,或者用于链接的二进制目标文件),并且你希望将其集成到你的项目中。 (通常是在编译时包含头文件,并在编译可执行文件/库时链接二进制对象。)
- 没有许可证声明 - 如果没有许可证声明,则你无权使用或重新分发。 注意避免
- 专有许可证声明 - 受实际许可证条款的约束。
- 公共领域授权 - 没有任何附加条件,请便。
- BSD许可证 - 你必须保留版权声明和BSD许可证中的情况条件清单。 如果只发布二进制文件,则在文档中提供;否则,在源代码中提供。
- 根据我上面的注意点,我建议将BSD许可的单元保持充分的可识别度,包括重新分配的权利(以下针对LGPL的内容所述也一样),以避免对适用于你的整个项目的BSD许可产生任何误解。-MartinBaute注
- 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代码的启发,这也构成了一种"源自"关系。 就我个人而言,我认为这和公司声称“付了你白天的工资,就要拥有你晚上编写的成果”一样荒谬。 同时似乎还没有这样的案件被提交法庭,但风险是存在的,所以要小心。
(L)GPL版本
GPL和LGPL许可证经历过一个变革,后来它们是多版本的。 版权持有人可以自由指定源代码应根据的(L)GPL特定版本,或指定特定版本及更高版本,或根本不指定任何版本。
复制(L)GPL许可的代码时要注意这一点。 如果未指定版本,则可以假设版权所有者不在乎,并在你再次发布时带有或不带有"及更高版本"的版本规范。
但如果版权持有人指定了一个版本,未经版权持有人书面同意,你既不能添加“并更高版本”,也不能删除现有版本。
独立许可
我们在本文档中只讨论了通用许可证。 如果特定代码的许可政策给你带来了问题,你始终可以尝试联系版权所有者并要求获得单独的许可。
例如,如果你正在构建一个公共领域许可的库,而你完成需要的只是一个仅在BSD许可下可用的特定功能,请询问版权所有者是否可以在你的项目中包含这一个功能,而不必费心使用BSD版权声明/条件清单。
更改许可证
作为项目的版权所有者,你完全可以更改项目的许可政策。 尽管如此,还是要准备好迎接来自你同僚的怒火,因为这通常会让他们大吃一惊。
是的,你可以自由地把先前专有软件发布在GPL许可下,同样你也可以自由地把先前GPL开发的项目的v2.0作为专有软件发布,。 在后一种情况下,你的同僚同样可以自由选择GPL许可的v1.9版本,并继续在GPL许可下的项目,因为不允许追溯更改许可证。
贡献者绑定
前面已经说了几个令人惊讶的法规:论坛帖子是被'保留所有权利'的;你的雇主可以告诉你 “你所有的工作都属于我们”。这里还要说明一个同样令人惊讶的事情:贡献者绑定。
假设你已经阅读了以上所有内容,冒然决定将你的项目置于GPL之下,当你想要更改许可证时,会发现这不是一个好主意。 这时如果以前都是你一人独自从事你的项目,也没什么能阻止你。
但是 ,如果许多其他人为你的项目做出了贡献,那么你可能会遇到严重的麻烦,因为 - 合法地说,并且从道德上讲 - 你可能不再是项目唯一的版权所有者,并且许可证只能在每个版权所有者同意下更改。
让我重复一下: 如果要更改项目的许可
- 从GPL到其他任何许可政策;
- 从LGPL到GPL以外的任何许可政策;
- 从BSD到其他任何许可政策;
- 从X到Y,其它我没有考虑过的许可政策;
通通都是,即使你自己的项目,你也可能不允许更改许可政策。
由于这个原因,许多项目在GPL声明中添加"包括任何更新版本",这样更改到新的GPL版本就不再需要项目的每个版权所有者同意。 也可以对更高版本的该软件将其上的旧版本GPL许可删除。
另见
外部链接
- choosealicense.com - 一个可以帮助你选择开源许可证的网站