关于开源,你必须知道的: "君子协定"

首先,为什么在一个技术论坛里冒出这篇法律和知识产权相关的分享呢? 因为,开源和自由软件是推动社会技术发展的重要力量,作为一个优秀的程序员,你一定会接触,学习和使用到开源软件,所以是一定要知道开源界最基本的游戏规则的~~

那么,今天我们来聊一下自由软件界的“君子协议”,为什么是打引号的君子协议?首先,开源协议,是具有法律效应的,但只要不碰到关键底线,一般以不会被起诉,大多数是谴责形式,比如说你不尊重开源精神啊什么的,事后都是可以弥补的:)所以我们还是叫他是君子协定 ~~

另外,下面的内容主要来自阿里的资深知识产权律师、纽约大学法学院法律博士(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(衍生作品)

  • 因为如果我们在使用过程中不生成衍生作品, 就不必公开源代码。 那么一定有同学疑问,什么叫衍生作品?什么样的行为生成衍生作品?
  1. 修改开源源代码 ,改了代码肯定算衍生作品了。
  2. 把我们的源代码和开源源代码组合在一个文件里编译(即等于修改开源源代码) , 一起编译也算哦。
  3. 最难理解的一种情况,我们的程序链接开源程序, 是否生成衍生作品?
 -  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获胜,大家有兴趣的可以了解了解,不做评价:)

http://www.oschina.net/news/73876/6-yeasr-google-win

http://arstechnica.com/tech-policy/2016/05/google-wins-trial-against-oracle-as-jury-finds-android-is-fair-use/

时间: 2024-08-22 15:27:03

关于开源,你必须知道的: "君子协定"的相关文章

Canvas性能技巧:必须知道的Canvas性能技巧

文章简介:你还在抱怨自己写的canvas demo徘徊在10帧以下吗?你还在烦恼打开自己写的应用就听见CUP风扇转吗?你正在写一个javascript Canvas库吗?那么下面九点就是你必须知道的! 你还在抱怨自己写的canvas demo徘徊在10帧以下吗?你还在烦恼打开自己写的应用就听见CUP风扇转吗?你正在写一个javascript Canvas库吗?那么下面九点就是你必须知道的! 一.预渲染错误代码:       var canvas = document.getElementById

你必须知道的.NET

[你必须知道的.NET]第三十五回,判断dll是debug还是release,这 [你必须知道的.NET]第三十四回,object成员,不见了! [你必须知道的.NET]第三十一回,深入.NET 4.0之,从"新"展望 [你必须知道的.NET]第三十三回,深入.NET 4.0之,Lazy<T> [你必须知道的.NET]第三十二回,,深入.NET 4.0之,Tuple一二 [你必须知道的.NET]第三十回:.NET十年(下) [你必须知道的.NET]第二十九回:.NET十年(

[你必须知道的.NET]第二十七回:interface到底继承于object吗?

说在,开篇之前 在.NET世界里,我们常常听到的一句话莫过于"System.Object是一切类型的根,是所有类型的父类",以至于我在<你必须知道的.NET>8.1节 以"万物归宗:System.Object"这样的title为System.Object授予至高荣誉.所以,基于这样的观点就有了下面这句"接口是否也继承于System.Object?",事实上这正是今天在技术群里小小讨论的一个插曲. 1 缘起 在.NET世界里,我们常常听

[你必须知道的.NET]第二十四回:认识元数据和IL(上)

说在,开篇之前 很早就有说说Metadata(元数据)和IL(中间语言)的想法了,一直在这篇开始才算脚踏实地的对这两个阶级兄弟投去些细关怀,虽然来得没有<第一回:恩怨情仇:is和as>那么迅速,但是Metadata和IL却是绝对重量级的内容,值得我们在任何时间关注,本文就是开始. 1 引言 你可曾想到,我们的C#代码,编译之后究竟为何物?你可曾认知,我们的可执行程序,运行之时的轨迹究竟为哪般?那么,本文通过对Metadata(元数据)和IL(Intermediate Language, 中间语

[你必须知道的.NET]第二十二回:字符串驻留(上)---带着问题思考

走钢丝的人,在刺激中体验快感.带着问题思考,在问题上迸发火花. 或者给问题以答案,或者给答案以问题,你可能永远无法看清全部,但是总能从一点突破很多.事实的关键就在于面对问题,我该如何思考? String Interning(字符串驻留)就是这样一个值得思考的话题,带着问题思考,我们至少要理清以下几个问题: 什么是string? 什么是字符串驻留? 字符串驻留的运行机制及执行过程? 字符串驻留的其他问题? 带着几个问号,你必须知道的.NET,继续更多体验. 1 带着问题? 带着问题思考,是技术探索

[你必须知道的.NET]第二十回:学习方法论

说在,开篇之前 本文,源自我回答刚毕业朋友关于.NET学习疑惑的回复邮件. 本文,其实早计划在<你必须知道的.NET>写作之初的后记部分,但是因为个中原因未能如愿,算是补上本书的遗憾之一. 本文,作为[<你必须知道的.NET>]系列的第20回,预示着这个系列将开始新的征程,算是[你必须知道的.NET]2.0的开始. 本文,作为一个非技术篇章,加塞儿到<你必须知道的.NET>队伍中,我想至少因为回答了以下几个必须知道的非技术问题:.NET应该学习什么? .NET应该如何学

[你必须知道的.NET]第十四回:认识IL代码---从开始到现在

本文将介绍以下内容: ·IL代码分析方法 ·IL命令解析 ·.NET学习方法论 1.引言 自从『你必须知道.NET』系列开篇以来,受到大家很多的关注和支持,给予了anytao巨大的鼓励和动力.俱往昔,我发现很多的园友都把目光和焦点注意在如何理解IL代码这个问题上.对我来说,这真是个莫大的好消息,因为很明显我们的思路慢慢的从应用向底层发生着转变,技巧性的东西是一个方面的积累,底层的探索在我认为也是必不可少的修炼.如果我们选择了来关注这项修炼,那么我们就应该选择如何来着手这项修炼,首先关注anyta

[你必须知道的.NET] 第五回:深入浅出关键字---把new说透

相关文章: [你必须知道的.NET] 第三回:历史纠葛:特性和属性 [你必须知道的.NET] 第四回:后来居上:class和struct 本文将介绍以下内容: 面向对象基本概念 new关键字深入浅出 对象创建的内存管理 1.引言 园子里好像没有或者很少把new关键字拿出来说的,那我就占个先机吧,呵呵.那么,我们到底有必要将一个关键字拿出来长篇大论吗?看来是个问题.回答的关键是:你真的理解了new吗?如果是,那请不要浪费时间,如果不是,那请继续本文的循序之旅. 下面几个 问题可以大概的考察你对ne

[你必须知道的.NET] 第二回:对抽象编程:接口和抽象类

相关文章: [你必须知道的.NET] 第三回:历史纠葛:特性和属性 [你必须知道的.NET] 第四回:后来居上:class和struct 1. 引言 在我之前的一篇post<抽象类和接口的谁是谁非>中,和同事管伟的讨论,得到很多朋友的关注,因为是不成体系的论道,所以给大家了解造成不便,同时关于这个主题的系统性理论,我认为也有必要做以总结,因此才有了本篇的新鲜出炉.同时,我将把上贴中的问题顺便也在此做以交代. 2. 概念引入 什么是接口? 接口是包含一组虚方法的抽象类型,其中每一种方法都有其名称