版权和专利

  • 著作权是正确称呼
  • 著作权保护实现,专利保护理念
  • 其实还有商标,外观等等

著作权划分

  • 精神权利
    • 署名权
    • 保持原作品的完整
  • 著作财产权
    • 重制权
    • 公开口述,播送,上映,演出,传输,展示权
    • 改作权
    • 散布权
    • 出租权
    • ...

授权

样例

       DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 
                   Version 2, December 2004 

Copyright (C) 2004 Sam Hocevar <sam@hocevar.net> 

Everyone is permitted to copy and distribute verbatim or modified 
copies of this license document, and changing it is allowed as long 
as the name is changed. 

           DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE 
  TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 

 0. You just DO WHAT THE FUCK YOU WANT TO.

(声明:以上文字仅是示例,不代表作者真实意图)

结合本文

如果使用了WTFPL会发生什么事


但是我仍然没有放弃著作权。

什么叫做放弃著作权

这个slide不是我写的。

(声明:以上内容仅仅是举例,也不代表作者真实意愿)

LICENSE

本slide的真正授权:

cc-by-sa3.0

我为什么要共享

  • 个人的良好意愿
  • 一个人的力量不足以做出足够好的作品
  • 多人合作作品,又不愿意协调共同所有权的问题
  • 限于时间/精力,不愿意再维护程序,但是又不甘心放弃自己的工作

可不可以不要追究这些细节

可以,只要你能接受。。。

一个血淋淋的案例

wikipedia的XviD页面上说:

在以往,个人电脑只能使用微软开发的MPEG-4 Codec,即MS MPEG4 V1、MS MPEG4 V2、MS MPEG4 V3的系列编码核心。其中
以MS MPEG4 V3的画质最好[来源请求]。不过其只可用在ASF文件,但这个文件格式是封闭的。故此网上有些黑客将其改写
为著名的MPEG4 Codec DivX 3.11。

但问题是,DivX 3.11的基础技术是非法盗用微软的,无法进行更广泛的产品化及生产硬件播放机。因此,一些精通视频编
码的工程师(包括原DivX 3.11的开发者)成立了一家名为DivX Networks Inc.的公司,简称DXN。他们主导了完全符合ISO
MPEG4标准的Open DivX CODEC的开发,并吸引了许多软件高手参与。这时,主要的编程工作是由DXN来做,但很多技术上的
难题却是由开放源代码社区帮忙解决。

但因为整个计划并不是根据GPL开发的,而是LGPL,因此在Open DivX即将成形时,DXN借此漏洞将其闭源,结果使众多开放
源代码社区的义工感到被出卖。也是因为这个原因,整个0day组织永远的拒绝了DXN公司的DivX格式。

而原Open DivX计划的义工最后决定在最后一个Open DivX版本的基础上,编写XviD(将DivX反过来写)以继续原Open DivX
的目的。

大约1年后,Xvid计划的开发者重写了所有代码,并依照GPL发布(而不再是LGPL,所以谁要是想用它做成产品而不开放源代
码是非法的)。但因为某些国家如美国,日本有软件专利法,使得其在该地区可能出现法律纠纷。因此,Xvid官方网站只提
供源代码下载,用户只可由第三方网站下载第三方的安装文件。

漏洞的原因

LGPL允许其他程序链接到这些代码而本身不需要开源。

想象一下有两个代码仓库,A和B。A是LGPL的,B是商业授权。两者合起来能够完成完整的编码工作。

平时有很多社区的义工在A仓库中为B实现功能。但事实上离开B,A是不能独立运作的。

DXN做的事,就是把B封闭源码,并借助版权法保证即使义工接触到了源码,也不能使用。

也许有人会说,那做一个不同的实现,补上B的代码就好了。这就是XviD的工作。

在比较大的软件工程中,不会有人随时随地检查协议。更不会有人对协议如此敏感。

但是在这次事件之后,整个欧美开源社区对LGPL都非常警惕。当有合作时,会要求彼此一定要采用GPL而非LGPL。

自由软体的基本权力

  • 自由使用
  • 自由研究/修改
  • 自由散布
  • 自由改善并重发布

免费软体(Freeware)和自由软件(Free Software)是不一样的。

开放源代码(Open Source)不等于自由软件(Free Software)。

软件,为演进而生

为什么改善和重发布的自由那么重要。

因为软件最重要的一个特性就是不停的演进。当用户有更新的需求的时候,他们可以自行改善。

并且这一改善可以通过上游优化和吸收,再发布。使得成千上万的最终用户获益。

同样,当软件的作者不再愿意维护软件,甚至不再存活时,其他用户也可以接手这一工作,使得软件继续生存。

相反,如果是闭源软件,当作者出现问题时,其后续就很难说。

大教堂和市集

ESR在1997年提出的软件工程学思想。将软件开发模式分为两种。

  • 大教堂模式:有一个专属的团队进行开发和演进。
  • 市集模式:没有一个专属的团队进行开发。每个用户开发自己需要的功能,上游进行合并。用户也可以产生自己的分支,并负责维护。

理论上看,市集模式的开发和调试速度要明显快过大教堂模式,因为可以在上面堆积的人力更加多一些。

实际上也是如此,采取大教堂模式的wikipedia,其词条数目已经远远超过了大英百科全书。

后软件时代的诗

市集模式,实际上是后软件时代的诗。他出现的前提,是有很多用户,有能力改进源码,翻译文档,或者至少可以提出修改意见。

而不是像软件初生的那个年代一般,只有专业的程序员,才能编写程序给普通人使用。

即使大部分用户并不具备修改源码的能力,能够看到源码并交由其他人修改就是一项非常重要的权力了。

保证软件的可维护性

如果你必须需要某个软件中增加一项功能,怎么办?

如果是闭源软件,没有任何办法。你唯一的办法就是联系原作者,看看他是否愿意为了你开发一个定制版本。

价格贵不说,更有可能因为原作者没有时间而无计可施。

开源软件至少保证你如下权利:你有权下载一份源码,然后找一家有能力开发的公司,和他们签署一个合同。要求在这个源码之上添加一项功能。

当然,很多协议同时要求,如果你需要向其他人提供这个修改后的版本,必须同时提供修改后的源码。

自由软件商业化方案

  • 开源授权和闭源授权
  • 免费软件和收费服务

授权是作者意愿的表达

作者希望用户能做什么,限制用户不能做什么,都在授权协议中做了统一规范。因此可以说授权是作者意愿的表达。

尊重授权,才能更好的鼓励作者和协作者,协调他们的关系。

我们可以想想,如果不尊重作者意愿,作者是否还愿意开发好的软件,并持续维护呢?这是一个很难说的问题。

固然很多作者不会因为几个不尊重作者的用户而终止开发。他们最多就是将这些用户钉上耻辱柱(ffmpeg耻辱柱)。

但是一定有作者,因为得不到用户的尊重而停止开发。

开源协议分类

copyleft

copyleft是一个非常重要的理念。他指的是,你是否希望基于你的代码衍生的代码必须使用相容的授权。

大致来说,上面的cc-sa就是此类。

如果你坚持copyleft,那么应当使用cc-sa类协议或者GPL2/3。前者常用于文件/文档/艺术品,而后者常用于软件。

其他人修改源码后,是否可以闭源

如果你选择了copyleft,当然不用考虑这个问题了——他自然必须使用开源协议发布。

如果你不介意其他人修改源码后闭源,那么应当采用BSD,MIT,Apache授权。

三者的基本差异在于,MIT允许使用你的名字促销,而BSD不允许。Apache则要求每个修改过的文件,都必须放置版权说明。

其他人修改后不能闭源,但是不必copyleft

这是一个很奇怪的选择。可选的项目有LGPL和Mozilla许可。

有点绕

请看这张图

简单来说

如果你希望衍生者也加入开源的行列,应当使用copyleft协议,例如cc-sa和GPL。

如果你不介意衍生者的使用方式,只希望保留基本的署名权等权力。可以选用BSD和MIT——对于大部分人来说,两者的差异可以忽略。

开源协议代表

GPL

GPL最广为人知的特性就是他的“传染”性。关于这点,我请教过一位比较专业的同行。

他的说法是,在C类语言中,如果要使用GPL类库,就必须包含原始头文件。而这一过程就构成了“包含和重构”。

因此链接方式调用的库就很难避免被传染GPL。而调用方式则不需要引用任何GPL许可的文件,因此可以规避。

因此我特别问了他。如果是python类的脚本代码,在使用对方库的时候,不需要包含引用任何代码(duck typing),是否可以规避GPL。

他的意见是——不知道。

如何实施

  • 这个页面
  • 找到“How to Apply These Terms to Your New Programs”一节
  • 把上面那段实例增加到LICENSE文件里面,把版权人和年份改掉
  • 如果程序是交互的,需要一个单独的功能“显示授权”,如同下面的示例那样
  • 如果这是你的职务发明,你需要让雇主签署一个“放弃版权”声明,以避免自己的问题

BSD

BSD几乎不禁止用户的任何行为。但是在衍生产品的源码和二进制产品中,必须包含BSD的声明,而且不可以用原作者的名字来推广。

如何实施(用户)

  • 在文档中指明程序中包含了来自XX项目的内容,这部分内容满足以下授权,并且将BSD的版权文字放在下面
  • 在二进制发行中也需要包含这份文档
  • 在任何广告中,需要包含“本软件使用了XX的XX项目”的声明(仅对4-条款必须)
  • 不用作者的名字做广告(不得以作者名字背书或者促销)(3,4-条款版本必须)
  • 2-条款版本基本和MIT是一样的

如何实施(作者)

  • 这个页面
  • 找合适的授权文字,2-Clause/3-Clause
  • 复制内容到你项目的LICENSE里面,把版权人和年份改掉

CC

CC(Creative Commons)是一个知名的非盈利组织。CC系列协议是一系列创作共用协议的统称。下属N种子协议:

  • by: 署名。您(使用者)可以复制、发行、展览、表演、放映、广播或通过信息网络传播本作品;您必须按照作者或者许可人指定的方式对作品进行署名。
  • nc: 非商业性使用。
  • nd: 禁止修改作品。
  • sa: 相同方式。若您改变、转变或更改本作品,仅在遵守与本作品相同的授权条款下,您才能散布由本作品产生的衍生作品。

例如,这个slide的授权叫做cc-by-sa3.0,即cc3.0版本协议中,需要署名和相同方式使用的。在这个协议下:

  • 您可以自由复制、散布、展示,演出以及衍生本作品
  • 您必须适当的提及本作品(如果可以,应当提及作者和组织,并提供版权声明,授权声明和弃权声明。4.0协议要求在许可的情况下,提及标题)
  • 您如果基于这个作品衍生,衍生作品必须兼容cc-by-sa3.0协议

如何实施

  • 声明自己的版权权力。
  • 你需要给出材料基于CC某个子协议的声明,并附带一个指向具体CC协议的链接。

我们为什么要注重法律的繁文褥节

作为作者来说,请参考上面“血淋淋的例子”。

作为用户来说,请对善意的开放源码,简化了你的工作的人。保持最基本的尊重。

开源不是拿来主义

中国(不仅仅是大陆)这里,很多人对开源的认识还停留在“啊,这个东西不错,还有源码,我可以拿来用用”的地步。

实际上,拿来主义不是开源。

开源并不排斥拿来主义。实际上,开源就是要你们拿去用的。但是在拿去之外,他还提出了一些最低限度的要求。

例如要在二进制发行里面加入原作者和授权声明,或者引用源码的代码必须开源。原则上,这些东西都是必须遵守的,而非可选项。

可能有很多人对这些可选项不屑一顾,因为作者不可能为了不存在的损失而打一场不会赢的官司。

这是中国开源界的可悲现状,对此没什么办法。


但是至少,我们可以做一些可以做的努力。例如按照规范注明原作者和授权声明。

如果对利益无伤的话,尽量将我们的修改推到上游去做合并。

实际上这些工作很可能对我们反而有益——例如将修改推入上游可以避免我们自行维护一套分支。

当上游集合了其他人修改的新版本推出,并且上面包含我们所需要的新功能时,我们不需要做合并升级。

从哪里开始

  • 给自己的blog加上cc-by-sa3.0协议声明
  • 引用别人的内容/源码时,看一眼自己是不是可以做到授权
  • 帮助社区编写/翻译文档。并且保证原文档满足协议(参考上文),保证自己的文档带有协议
  • 使用不满足授权的软件/内容时,感到羞愧