首先,为什么在一个技术论坛里冒出这篇法律和知识产权相关的分享呢? 因为,开源和自由软件是推动社会技术发展的重要力量,作为一个优秀的程序员,你一定会接触,学习和使用到开源软件,所以是一定要知道开源界最基本的游戏规则的~~
那么,今天我们来聊一下自由软件界的“君子协议”,为什么是打引号的君子协议?首先,开源协议,是具有法律效应的,但只要不碰到关键底线,一般以不会被起诉,大多数是谴责形式,比如说你不尊重开源精神啊什么的,事后都是可以弥补的:)所以我们还是叫他是君子协定 ~~
另外,下面的内容主要来自阿里的资深知识产权律师、纽约大学法学院法律博士(J.D.)Roger 老师的分享,不是出自我这个小程序员,我只是帮忙整理和解说,所以根据君子协定,我一定要声明原作者的著作权,嘿嘿~
言归正传, 分享提纲如下:
• 什么是开源软件?
• 为什么使用开源软件?
• 使用开源软件有哪些需要注意的地方? 君子协定的解读
什么是开源软件?
- 这个问题很简单了,只要是在网站上公开源代码,公众可以下载的软件,就是开源软件了。 例如我们都知道的:Linux, Hadoop, Android,Mysql等等
- 另外,一些公司在网站上提供试用版商业软件但不公开源代码, 不算开源软件。
- 有些软件同时提供开源版本和商业版本, 比如Gitlab是开源的,但只是开源其CE社区版本,另外有收费的EE商业版本提供。
商业软件和开源软件的对比?
- 商业软件就像教堂,神圣而高大,门槛很高,衣衫不整禁止入内 :)
- 开源软件就像集市,吵吵嚷嚷,但是种类很多,选择很多 :)
开源软件的优势
仅以下面表格说明,对开源软件的质疑只是自我的猜测:
对开源软件的质疑 | 开源软件的事实 |
---|---|
个人兴趣爱好者的业余成果,不可靠? | 参加开源的往往是高级软件人才; 更加珍重自己的声望 ->带来质量的保证 |
没有公司式的系统管理,不可靠? | 多名高级人才阅读源代码、试用产品,保证产品的质量和安全 |
源代码公开,无法收费? | 确实难以收费,但是: 可以收取技术支持费用,可以提供收费的非开源版本; 并且,很多时候收费并不是目的 |
为什么使用开源软件?
- 为什么使用这里不用过多解释了,不仅仅是免费,首先能够快速的得到,快速掌握达到一个基准的高度,并且经过社区和外部试用的认可,适合继续修改研发,并再次反馈回社区,引发良性循环,推动技术发展。
- 那么,使用开源软件,我们必须
遵守开源软件的授权协议(license)
, 因为开源软件作者拥有著作权,有利用协议控制他方的权利
使用开源软件要注意的地方,君子协定解读
重要预警,现在开始进入重要的协议部分
开源协议有非常多种,但基本可以分为两类:
- 一类叫做
学术型协议
,即以声明为主 - 另一类叫做
"Copyleft"协议
,只要你修改并发行,就必须开源你的代码
- 一类叫做
- 下面就开始介绍这两类协议。
学术型协议 | “Copyleft” 协议 | |
---|---|---|
常见要求 | 保留原作者的著作权声明和免责声明,修改处需要注明 | 除了学术型要求之外,如果基于开源软件生成衍生作品并发行,则有可能规定衍生作品也属于该协议控制,也必须公开源代码 |
常用协议 举例 | APACHE, BSD, MIT,PHP | GPL, LGPL,(AGPL) |
解释一下, 学术型的协议:
-
- 例如我们最熟悉的Apache 2.0 ,为什么说是学术型,是对商业友好的开源协议呢? 因为他只需要保证著作权(声明作者是谁),免责声明(声明这是开源代码,有问题可不负商业责任哦),修改处需要注明(你要是改了要注明是你改的哦,万一改的很挫不能让别人以为是原作者改的哦) 。
- 基本上可以认为,是以声明为主,之后我们修改了,再开源或作为商业产品发布/销售,都是可以的。
解释“Copyleft”协议:
- 核心是基于
开源代码的衍生作品,也必须开源。
- 很多开源软件都属于GPL家族(GPL,LGPL,AGPL) , 众所周知的Linux操作系统,内核和核心库都是GPL协议的。
- GPL的两个兄弟,LGPL是相对友好的,AGPL是更加严格的,后面会解释AGPL为什么是更加严格。
- 有一些(不是所有)GPL开源程序的版权属于Free Software Foundation (FSF),这是一个较激进的开源组织,他们确实会通过法律手段来保护GPL的开源软件,并不是谴责那么简单, 意思是告诉大家,他们是认真的。 下面这位就是这个组织的创始人Richard Stallman
- 核心是基于
- 阿里不会批判任何一方的思想,但我认为FSF也是必须要存在的,没有他们宣扬激进的理想主义理念,自由软件社区就不会存在。虽然现在很多落地的都是调和,妥协的结果,但如果失去理想主义的引领和召唤, 这个落地的东西就会退回到完全的商业化。
- 所以阿里是一直支持GNU FSF的 https://www.fsf.org/patrons 。 2014年的时候也邀请过Richard Stallman 来到阿里园区交流和分享自由软件的精神。
- 关于自由软件和开源,延伸阅读参考: https://www.gnu.org/philosophy/open-source-misses-the-point.html
重新回到正题,基于上面的简单解释, 使用学术型协议一般是不会有什么风险的,但“Copyleft”协议和公开源代码之间就会有风险存在,下面详细解释协议里的两个关键概念
关键概念解释: Derivative Works(衍生作品)
- 因为如果我们在使用过程中不生成衍生作品, 就不必公开源代码。 那么一定有同学疑问,什么叫衍生作品?什么样的行为生成衍生作品?
- 修改开源源代码 ,改了代码肯定算衍生作品了。
- 把我们的源代码和开源源代码组合在一个文件里编译(即等于修改开源源代码) , 一起编译也算哦。
最难理解的一种情况,我们的程序链接开源程序, 是否生成衍生作品?
- GPL: 静态链接生成衍生作品 ; 动态链接(即程序运行时才生成链接),是否生成衍生作品没有法律定论
- 其他大多数开源协议(包括“病毒”型协议): 链接不生成衍生作品
- 简单理解,静态链接的库(Linux的.a和Windows的.lib) , 动态链接库(Linux的.so,Windows的.dll)
- 静态库和程序编译在一起,任何情况下都能运行,所以在GPL系列里,静态链接都算衍生作品
- 动态链接顾名思义是程序启动的时候才会链接,多个应用程序可以使用同一个动态库,启动多个程序的时候只需要将动态库加载到内存一次。
什么情况下不会生成衍生作品呢?
- 开源程序和我们的程序在不同层面运行,比如Linux是GPL的,我写的程序在linux上运行,那不算,linux是操作系统程序,我是应用程序,不在一个层面上,不会被它的GPL感染而必须开源
- 远程程序调用(remote procedure call)不会产生衍生作品 , 比如我写的web程序,使用mysql或者mongoDB作为数据库,这都是以进程,服务调用为界,比动态链接更远,所以也是不算的。
- 开源程序和我们的程序分别独立运行没有交互不会产生衍生作品
关键概念解释:发行(distribute/convey)
- 如果我们修改了开源源代码但没有发行,就不必公开修改过的源代码,那么什么是发行?
- 首先,下载到用户端是发行, 这个很好理解。 即如果我们基于“Copyleft” 协议产生了衍生作品,只要提供用户下载使用,就必须对该用户公开源代码。
只在公司内部使用不算发行, 部署在公司的机房,在服务器端运行的系统和程序,比如淘宝网,比如大家用的各种邮箱产品,那只是通过网络与用户进行交互,都
不算发行
。 但是:AGPL, CPAL, OSL
(极少数非主流协议) 把通过网络与用户交互也当作发行 。- 网上有段话对AGPL解释的非常到位,粘出来给大家参考:
这类协议的开源软件非常少,但假如使用了上述协议的开源软件,并修改了作为业务的某一个组件, 那就必须把整个系统的代码开源。
其他有可能出现的开源协议要求
- 如果我们的软件包括开源软件,则必须允许使用我方软件的用户为个人使用的目的修改开源软件,并为调试修改版而 reverse engineer(反向工程)我方软件
- 如果我只发行开源软件的机器代码,则必须告知用户如 何获得开源源代码
- 不能把开源软件的商标名作为我们软件的名字
- 如果向用户发行,则必须在发行的软件中包括授权协议的全文
- 如果我的软件在运行时向用户显示我的版权声明,则必 须也显示所包括开源软件的版权声明
- 对用专利起诉开源软件侵权的限制
有可能出现的违反协议情况
开源协议要求 | 有可能出现的情况 |
---|---|
保留原作者的著作权声明和免责声明 | 被程序员误删除,或代码里没有放声明文件 |
修改处需要注明 | 没有注明 |
公开原开源软件的源代码,并告诉用户如何获得源代码 | 没有公开或没有告诉用户如何获得 |
显示开源软件的著作权声明 | 没有显示 |
公开修改后的源代码 |
没有公开 |
允许用户反向工程 | 不允许 |
反软件专利 | 告第三方使用开源软件侵犯我方专利 |
- 这个表格看起来好像很危险,但其实除了红色字体的错误,基本上是可以事后补救的。 好比没有标注,没有声明,如果只是当时的疏忽被别人谴责了,发现后给原作者道歉,承认一下错误,然后立刻补上。
- 只有一条是无法事后补救的, 就是开源协议里要求你公开修改后的代码,你并没有公开,这种情况下就已经违反开源协议的要求了,如果你本来不计划开源的软件变成必须开源,这就是无法补救的损失了。
- 同时,如果各位老板准备购买、投资技术企业的话, 就必须了解该企业使用开源软件、遵守开源协议的情况。 特别是如果计划使用、整合该企业的软件的话~
在协议介绍章节的最后, 列一下“Copyleft”协议的主要条款总结,每个协议的感染性不同,可以看到AGPL协议是在服务端运行也算发行的,所以这个协议谨慎使用,其他的都差不多。
开源协议 | 在服务器端运行算不算发行? | 修改开源源代码要不要公开? | 链接开源程序的程序是否也要公开? |
---|---|---|---|
CDDL | 否 | 是 | 否 |
CPL | 否 | 是 | 否 |
EPL | 否 | 是 | 否 |
MPL | 否 | 是 | 否 |
LGPL | 否 | 是 | 否 |
GPL | 否 | 是 | 是(动态链接无法律定论) |
AGPL |
是 |
是 |
是(动态链接无法律定论) |
“君子协定”相关的分享到此结束,最后说个八卦,近期以来最大的一场知识产权的官司。 因为在Android中用了Java,Oracle向Google索赔93亿美元,大致意思好像是Java是GPL的,谷歌商业性使用了(Android是Apache协议,否则其他的手机厂商就不敢用了),就需要获得许可。谷歌没获得许可,所以打起来了。 然后争论在API是不是受保护之类,经过6年之战,在上个月判定Google获胜,大家有兴趣的可以了解了解,不做评价:)