写给知乎:最艰难的告别

这一周,我的工作量很大。因为,我下决心要告别知乎了。为了让自己绝对不可能再回来,我做了以下一些事情:

  • 关注的80+话题,一一取消关注
  • 关注的50+专栏,一一取消关注
  • 关注了880+知友,一一取消关注,就像是向880+朋友,一一道别
  • 收到了2000+个邀请,积压着一直没有回答,也只能一一忽略,抱歉
  • 关注了3000+问题,一一取消关注,这样我就不会看到自己关心的问题的最新回答了
  • 回答了1200+问题,一一看过,有价值的移到自己的blog,然后全部删除,有时候还要再回顾一下评论
  • 写了110+篇专栏,一一看过,转移,删除
  • 卸载了手机上的知乎

这些事情,花了我7~8天的时间。写完这篇专栏之后,我会把知乎的密码改成一个自己永远都想不起来的乱码,以确保自己再也上不了知乎。

 

来知乎已经四年了,我也曾经说过:「说了这么多,但是,我从来没有想过,要戒知乎!知乎依然是我现在最喜欢,也最经常去的网络社区(没有之一)。」

为什么要这么干呢?因为对知乎,彻底失望了。事情的来龙去脉,可以看这几篇文章:

一篇锤子手机总监级别的软文是怎样诞生的?

[知乎专栏–思考IT]运营的底线

[知乎专栏–私吐槽]是什么人,在修改问题?

[知乎专栏–私吐槽]知乎,你们这样真的有意思吗?!!

如何看待『Smartisan OS 中的定时静音功能』问题下出现的许多知乎用户认为是软文的现象?

这个问题里的黄继新的回答!

Smartisan OS 中的定时静音功能设计过程是如何的?

以及这个问题的修改记录里,众多知乎员工的身影!

 

既然想走,那就走得彻底些,最后的最后,我的心情非常复杂,却不想写什么狠话。2年前,我曾经为知乎写过一首诗,就以这首诗,作为这段时光的结束吧。

 

对酒当歌,叹人生兮几何。
古有屈原,咏天问与九歌。
浩瀚苍茫,当上下而求索。
时光荏苒,惜岁月之蹉跎。

昔日艰难,有凿壁而偷光。
发奋苦读,常刺股与悬梁。
名师难遇,千里求学他乡。
知音难觅,伯牙摔琴心伤。

今非昔比,求知易如反掌。
身无长物,揽万卷于网上。
问答辩难,可教学而相长。
千里知音,未谋面却来访。

知乎出世,聚英才于一堂。
稀有社区,以认真为风尚。
妙问妙答,常有缘得欣赏。
牛人高人,可讨教也无妨。

赞曰:
惟愿知乎常驻世,惟愿知友常交流;
惟愿知识常流传,惟愿智慧常增长。

[知乎专栏–思考IT]运营的底线

在2年前的一个回答里,我谈到了知乎走向失败的风险:可能导致知乎走向失败的最大风险是什么?

周源的理想是:

  • 知乎将持续产生高质量、可沉淀的信息,并让有价值的信息和人都关联起来

而我的担忧是:

知乎的运营,一直都在追求优质的回答。这是大家有目共睹的。但是,何为优质呢?
1、大家都赞同?
2、运营的员工有偏爱?
3、名人?
4、能够激发更多的讨论?
5、具备足够的深度和长度?

这些都可能不是优质的判断依据,但是也有可能被用来判断是否优秀。

我担心的最大的问题,就是知乎运营团队,在何为优秀的判断上,默默的,不自觉的,有意无意的,向KPI低头,向热闹低头,向名人和大企业低头

最终,从一个一流的问答社区,变成为一个二流的,却标榜自己是一流的问答社区。

现在,李奇作为一名知乎员工, 在微博上看到了「好的内容」,就在微博上邀请,然后在知乎「提了一个最适合朱萧木回答的问题」,然后再自己点赞,然后在推送到知乎日报。

这,已经大大的越过了内容运营的底线,而是在践踏的知乎,作为一个问答社区的原则!

在这个问题下,目前有38个回答被折叠,据说原因是「并未回答问题」。但是:「李奇根本就不是在提问」,他只是用提问的形式,「导入了一篇外部的内容」,因为手法拙劣,结果被抓了现行,遭到了吐槽!

一个更加有趣的现象是:Smartisan OS 中的定时静音功能设计过程是如何的? – 知乎用户的回答

这篇@土星光环 拉偏架的「回答」,同样没有回答问题,却依然高高在上。

这真的令人感到不齿!

update1:

对于「donhi feng 是知乎员工」的猜测,是我的错误记忆与判断,特此删除并致歉!

update2:

如果我是李奇,我会这么做: 提一个问题「手机的静音功能设计,应该考虑哪些因素?」

然后,将各个手机厂商相关人等,邀请来回答这个 问题。

然后,等待各种优秀的回答浮现出现,择优挑选上日报。

[知乎专栏–思考IT]长假记事——聊聊用户体验

在国庆长假的前几天,我在知乎看到了两个回答,心中虽然有些想法,却不知如何表达,也就存在心里,出去旅游去了。

为什么阿里系软件体验都不好?

百度阅读还有什么不足,阅读产品让你来做你怎么做?

虽然这两个答案,我都不太喜欢,但是却不想正面评论,只想讲几个旅游途中发生的小事。

一、华为E585

因为要自驾游,而且是从上海出发,沿途经过南浔、湖州、宣城、芜湖、巢湖等地,所以配一个3G转无线WIFI,非常有必要。在淘宝上与卖家聊了10分钟,在众多的华为E5中,选择了号称性价比最高的E585,再买了一张联通的15G年卡,共计:497元。

但是,这个小玩意却给我们的这趟旅途,带来了极大的方便,全程随身WIFI,流量与网速都丝毫不必担心,唯一的苦恼,是5小时左右,需要充一次电,但是这也合情合理,毕竟那么小小的一个机器,能够撑5小时,已经很不错了。

对于产品的基本要求:提供符合我预期的功能,不要给我带来烦恼

二、高德地图与百度地图

我一直在用高德地图,在相当长的时间里,它也工作的不错。直到这回在芜湖,有一个宾馆,它没有找到。害我们钻到另一个莫名其妙的弄堂里去了。

还好有E585,我当场下载了一个百度地图,搜到了宾馆。

过了两天,在巢湖,我怀着再给高德地图一次机会的心情,搜索了一次加油站。 结果还是没有找到,我用百度地图,再次搜到了加油站,顺利加到了油。

最近,高德地图,还在搞一个活动:「你敢用,我敢赔」。但是,我根本不会想找他赔钱,我直接就换了另外一个地图来用了。

对于产品的基本要求:首先完成基本功能

购物网站无法完成购物,地图App无法找到地点,阅读软件让人无法顺利阅读,这种软件,就没有存在的必要。

三、微信

我们家在微信上有一个群,所有的亲戚都在里面。这次出门,我们基本上每天会在群里发一些旅游的照片。有一天照片发得晚了些,老妈的电话就打过来了:「怎么今天没有拍照片吗?还在等着看呢!」

国庆期间,我爸妈在上海,自得其乐的玩了很多地方,然后每天都在朋友圈里发照片。我有一天忘记点赞了。老妈的电话又打过来了:「我们今天去了XXX和XXX,好多人都看到了,都夸我们了,你看了吗?」我赶紧打开微信,把该补的赞补上了。

回到上海,老妈捧着她的手机过来,第一件事就是让我帮她看看,怎么他的微信又要重新登录了。

这里虽然只是说我老妈,但实际上,我身边的几乎所有父母辈的老人,都极其热衷使用微信。虽然他们很多地方不会,而且学得很慢,操作很慢,打字也很慢。但是这丝毫不妨碍他们,每天玩得不亦乐乎。

对于产品的终极要求:抓住核心需求,满足核心需求

四、 结束语

再来谈谈我对阅读的根本需求的看法:作为一个经常在手机上阅读的人,我大概有百分之90的时间,都是在进行翻下一页的操作。在这个过程中,我的用户体验如何?或者换言之:什么样的阅读体验,才算是顺畅的?

能够顺畅的阅读一本书,这是核心需求。

其次,如何找到我想要读的书?以及,我可能会喜欢的书,该如何找到我?这其中存在一个过犹不及的问题:书太少,没办法读,简直就没有打开App的动力。书太多,读不完,也会有另一种自暴自弃的压力。

所以:根据用户的实际阅读进度,推荐新书,我觉得是一个重要的需求。

因此,我比较认同百度阅读的PM,@冶林 的观点:「细节是否重要?很重要,但是如果连根本需求都没有做好,细节做的再好也还是没用。」

[知乎专栏–思考IT]成功的开源项目都有什么样的特点?

前几天,我在知乎回答了一个问题:成功的开源软件都有什么样的特点?

一、萌芽阶段
1. 解决实际问题,这是核心,不一定要特别创新,特别酷,当然如果有的话是加分项
2. 定期发布,及时接受反馈,不断满足用户需求,形成稳定预期

二、成长阶段
1. 出色的宣传手段,引导传播的能力,很多不错的开源项目因为这一点不够,始终默默无闻
2. 足够好的协作机制,虽然开源社区通常有较为成熟的玩法,但是做得不够好的项目比比皆是
3. 友好的参与引导,不断的吸引新人加入贡献(包括新手指南,开发文档,Demo等等)

三、成熟阶段
1. 商业介入,获得资金支持(很多一开始选择了不太具备商业价值的开源项目,会始终非常小众)
2. 良好的社区氛围,老人有地位,新人有上升空间,公开透明不内斗
3. 正确的方向感,是长期繁荣的保障

以上这些,都依赖于一个最重要的先决条件:足够强大、足够优秀的创始人+领导者!

这两天又思考了一下,发现开源软件与开源项目,还是有一些差别的。通常来说:开源软件,主要是供最终用户使用,而开源项目,则是一个更大的概念,可以做一个菱形图来说明:

在开源项目的基础上,可以创造一个好的开源生态圈,而基于开源生态圈,会产生一个甚至多个不同的开源产品。这里说「开源产品」,也就包含了「开源软件」与「开源硬件」。

因此,深入思考的结果就是:优秀的、成功的开源产品,依赖于良好的开源生态圈,而良好的开源生态圈,严重依赖于最初开源项目的定位与类别。

例如:依赖于Wordpress的平台,诞生了一大批Wordpress的插件。依赖于Eclipese的平台,又诞生了一大批Eclipse的插件。Firefox、Chrome莫不如是。

所以:一个能够让开发者参与扩展的平台,是建立生态圈的重点之一。

再者,开发、调试、发布、获取、升级、评价这些扩展插件,是否易懂,是否方便,是否快捷,也是一个生态圈,是否能够健康的重要支撑特性。

例如:ruby的gem,nodejs的npm,就是极大的提升了ruby与nodejs的生态圈活力

所以:一个能够支持生态圈得以出现的机制,一个能够辅助生态圈形成的工具,至关重要。

再深入的想一层,当我们开发一个软件,他应该具备哪些功能,他的可扩展性该如何实现,则是考验最初创始人的架构能力的关键。

例如:UNIX/Linux的核心思想:「一切皆文件」

再如:Rails的核心思想:「约定大于配置」以及「Rack架构」所带来的活力

所以:优秀的架构,能够从一开始,就为开源生态圈打下良好的基础。

[知乎专栏–思考IT]下一代研发平台的四块积木

最 近正在看一本书,就是之前介绍过的Jared Diamond写的《第三种黑猩猩》,昨天又读到了其中一段,是讲人类如何分析动物的语言的。在引入了录音技术之后,人类对于猴子的语言的了解,有了突破 性的进展。通过分析,我们分析出了10个词汇。在没有先进的录音分析技术之前,哪怕是最有经验的动物学家,也没办法了解这么多。另一方面,对于大猩猩的语 言的分析,却很困难,因为他们动来动去,不容易录音。

回到研发的话题,在我看来:缺乏对于研发过程中各种行为的分析,是无法真正改进研发 管理的关键原因,程序员每天到底花多时间编程?花多少时间看文档?花多少时间开会?一个Story,会经过多少道工序,最终被开发完成,发布上线?如果研 发的效率不高,最大的瓶颈到底是在哪个环节?

大数据分析工具出现之前,这些答案,都是被一种奇怪的方式回答的:数据散乱,随意,缺乏统一的标准,领导想看了,下面的人就去搞一个Excel。

如果我们有了足够好的大数据分析工具,问题就得到解决了吗?实际上并没有这么简单。究竟应该采集哪些数据呢?在研发的过程中,相关人员,究竟发生了哪些行为呢?这些行为,是能够被分析的吗?是能够被量化的吗?

我 发出了一个邮件,包含了一个word文档作为附件。这个行为的含义,如何分析?以Github为代表的Social Coding,在我看来,最大的贡献是将原来含混的研发行为,原子化了。star、watch、fork、issue、pull request、follow,过去可能都是在email里完成的。通过社交化服务将研发行为原子化,也因此使得量化这些行为,变得可能。

在写Blog的时候,我们会引用其他人的Blog,这时候,BSP就会帮我发出一个PingBack,告诉那篇Blog,它被我引用了。但是,在开源项目的领域,还缺乏这种项目之间的PingBack机制,因此在项目与项目之间的关系,我们还很难梳理清楚。

一个可以期待的功能特性,应该是基于开放平台的OpenAPI的,假设每一个开源项目托管平台,都支持UseIt这样的API,任何使用了它的项目,或者部署了这个开源项目的平台,都会发出一个UseIt的请求给它。该是多么美好的未来啊?

最后,我们再来回顾一下动物语言的研究,为什么大猩猩的语言不好研究?因为采集数据困难。从这个角度来说,如果开发人员都在自己的本地机器上工作,大多数时候不联网,那么研发数据的采集就会非常困难。如果基于云计算的开发平台能最终普及,所有的研发行为,都实际上在云平台上发生,我想:这个故事就基本上完整了。

因此,我们得到了这样四块积木:大数据分析+社交化服务+开放平台+云计算=下一代研发平台

[知乎专栏–思考IT]互联网公司的研发组织

一、平台化趋势

各个互联网公司,都有类似的发展趋势,腾讯的总结是:云中发展、轻重分开、快速沉淀。

盛大的类似道路是:将各个技术团队的平台类技术收拢成盛大在线(SDO),在后期由于云计算技术的兴起,又联合盛大创新院与盛大在线,建立了盛大云。

阿里云、京东云、腾讯云,这些云服务的发展趋势,也非常类似。

平台化、服务化、虚拟化、分层化,是统一的趋势。

与这种趋势相关联的,是组织机构的调整,与研发节奏的调整,越是底层的架构,研发(迭代)周期越长,走得更加稳健。

越是上层(应用层)的产品,越是强调快速开发,快速迭代,快速试错。

二、矩阵型团队

随着互联网研发技术的日益成熟,各种工种也逐渐出现:产品经理、前端工程师、前端架构师、后端研发、后端架构、用户体验设计师、运营、运维、测试、安全、策划等等。

大 多数互联网公司的研发团队,都成为一种矩阵型的结构。项目经理+一群研发人员,是一个项目组的基本构成,人数会非常少,3~5个人的规模非常常见。但是, 这些人之外,还有各种专职团队的人员加入:产品经理团队,会派驻1~2个产品经理过来;架构师团队,会派一个架构师过来;与此类似:前端设计师、测试工程 师之类的专业角色,也会被派来。

这种团队的组织,往往是动态的,在项目完成后,也许会各奔东西。

运营、运维、DBA之类的人员,不太会直接加入具体的项目,但是会与项目组有密切的协作。

因为矩阵型团队,交叉协作,多线汇报,使得绩效考核的工作,会相当困难。

三、能者多劳

组织结构与分工甚至技术架构的决策,往往与各个团队的人员能力有关。能力强大的个人与团队,会逐渐膨胀,扩大其职责。比如最近比较热门的淘宝前端团队,推出的中途岛项目,其本质,就是借助Node.JS的后端能力,接管部分原本由后端团队负责的工作。

很多身在互联网公司的员工,会觉得这种情况非常混乱。不过,这也正是互联网公司的活力所在。

 

保留评论:

真正的互联网公司,追求的并不是体系的完善化。而是单点的极致。
以前都在讲,最短的一块板子,决定水桶装多少水。现在这种状态变化了,现在是,所有的板子都要达到一个标准的水准,然后要有一根最长的,要比所有人的板子都长。
对于腾讯那种,已经平台化的企业来说,平台就是他们的产品。平台就是他们最长的一块板,是其他人所无法超越的。
真正的互联网企业,不需要把水桶的所有板子都做得一样长,而是需要保证所有板子都满足基本需求的同时,有一块特别长的板子。

能 够让用户记住你,一想到要做什么,就想到你。就像施乐、巴可,分别成为了复印机和投影仪在一些国家的代名词。如果只是能够提供满足需求的产品,而无法树立 独特的,能够占领用户心理位置的品牌,那么体系再完善都没有意义。还是说水桶,哪怕你的水桶最短的板子,比我的水桶第二块板子还要长,只要你的最长板子, 没有我的最长板长,那么用户就会记住我,而不是你。那么最终成功的就肯定是我。

[知乎专栏–思考IT]从软件工程到研发管理(三)

三、从一个完整企业的角度,来看待研发行为

真实的研发,至少可以分为两大类:经营性研发与非经营性研发,或者说:以盈利为目的的研发与不以盈利为目的的研发。

在这篇文章里,我们将主要讨论在企业内进行的以盈利为目的的研发活动。

1. 从追求利润最大化到追求研发效率与研发能力

任何企业,都会追求利润最大化,收入越多越好,成本越少越好。

具 体到一家研发型的项目,自然希望自己研发出来的产品,能够卖得越多越好,越贵越好。但是产品的质量不过硬,产品的性能不过关,产品的功能达不到客户的要 求,哪怕软件都开发出来了,也照样卖不掉。我们都知道操作系统很赚钱,但是有几家公司能够开发出 足够商用的OS呢?我们都知道最賺钱的软件例如 Oracle 数据库、Office 套件,Photoshop 套件,但是又有几家公司能够开发得出来呢?

因此我们可以认为: 研发能力,决定了一个研发型企业的收入上限

相应的,研发成本越低越好。由于研发人员通常是固定月薪,所以:开发速度越快,则成本越低,开发人员投入越少,则成本越低。在确保完成的前提下,减少投入,加快速度,就是降低成本的必然选择。

因此我们可以认为:研发效率,决定了一个研发型企业的成本下限

2. 在开放创新的时代,追求利润最大化的更多努力

缺 乏远见的企业,可能只会不断的压榨员工,以降低成本。较有远见的企业,还会想着提升员工与团队的研发能力,以增强盈利能力。 基本上,如上所述,一家传统的IT企业,它追求利润最大化的努力,也就到此为止了。但是,在一个开放创新的时代,企业应该能够找到更多利润最大化的途径, 也应该做出更多的努力。

什么是开放创新呢?

一家企业往往不仅仅只有一个研发项目,跨团队的研发管理优化,有哪些事情可以做?

在一个开源软件越来越具有活力的时代,一家企业有哪些事情可以做?

互联网大行其道,移动互联网热火朝天,各行各业都在加速创新,各种技术的交叉融合,孕育了无数的创新机会,一家有进取心的企业,又该做些什么?

  • 通过鼓励复用以节约成本
  • 通过鼓励创新以开拓财源

无外乎以上两点吧。

3. 研发活力概念的提出

无论是复用还是创新,都需要一个企业的研发团队,具备更加强大的实力。

  • 复用需要架构支持、眼界开阔、充分交流
  • 创新需要组织支持、思路开阔、充分交流

一个具备活力的学习型组织,才能满足以上的要求,作为一个度量思维活跃度与行为活跃度的指标,提升研发活力,对于提升企业的利润,具有重要意义。

我们可以简单的理解研发活力的概念:当一个物体内的分子逐渐开始运动,则物体的温度就会逐渐升高,分子运动越剧烈,则物体的温度越高。

组织内的成员,越是僵化的「仅仅从事自己的本职工作」,则一个组织越是死气沉沉。反之,越是有活力的企业,有能量,有创造力的企业,内部员工的可活动空间就越大,活动的自主性也就越大。

如果我们能够以某种类似热力学定义温度的方式,找到一个指标衡量IT企业内的研发活力,则可以以此来判断企业「在研发过程中,创造利润的潜力」。

<未完待续>

[知乎专栏–思考IT]极客的进化

去年七月,我去南京参加@极客行动,回到家,在跟儿子解释什么是极客的时候,我对他说:「极客就是这么一种人,他们觉得这个世界不好,他们不会等别人来改变,他们自己就会动手。如果需要改程序,他们就去改程序;如果需要修机器,他们就去修机器;如果需要发明什么,他们就去发明。

今天,我打算接着聊聊极客的进化。

一开始,他们只是去改进。会计电算化,办公自动化,计算机辅助设计,计算机辅助制造,计算机辅助 XXX。说到底,仅仅是利用计算机去辅助些传统的工作,去提高原有工作的效率而已。

再后来,他们不仅仅在改进,而且在创造。甚至是在颠覆。想象过完全不一样的汽车吗?想象过完全不一样的步枪吗?想象过完全不一样的银行吗?想象过完全不一样的工厂吗?各种新技术的运用,不仅仅在提高传统工作的效率,甚至让一些传统行业面临消失的危机。

与此同时,他们在创造各种各样的工具,他们在发明各种创新的协作方式。使得改变世界的难度,越来越低。傻瓜照相机,傻瓜打印机,傻瓜式图像处理工具,傻瓜式软件开发工具,等等等等。

那么,极客们还可以干些什么呢?自我改造!正如我之前的一篇文章《自动驾驶汽车、DevOps、SDE及其他》中谈到的:将 IT 技术应用于 IT 研发之中,进一步加快,甚至颠覆 IT 开发的传统模式,这是一个值得探索的「新」领域。

如果你也对成为这样的极客有兴趣,那么,从学习一门编程语言开始吧!

[知乎专栏–思考IT]Source Code + X

最近,有一位来自学术界朋友,找到了我们这个开源的圈子,因为他正在做一个课题《开源项目知识共享影响机理》,打算做一轮访谈,他所提出的大多数问题,都是围绕开源与知识共享展开的,我在经过相当长的一段时间思考之后,却打算撇开那些问题,谈谈我的一些思考。

最早的Source Code,其实是非常学术性的,那些科学家们,研究、发明并制造出了计算机,然后再编写计算机能够运行的代码。对于科学家来说:代码与论文非常类似,都是学术成果,饱含知识。他们应该、也必须被分享给学术界的其他专家。

所以,在非常早期的阶段:Source Code + 论文 = 知识分享

到 了1976年2月3日,比尔盖茨发了一封著名的《写给电脑爱好者的公开信》,高唱版权与利益。而且愤怒的将那些免费复制软件的家伙,称之为:窃贼!盖茨的 观点,可以说完全正当,甚至他的逻辑也完全成立,如果无法保护商业软件的版权,那么整个软件行业都不会出现,他们会永远停留在校园里,停留在学术阶段。

所以,在看到的软件利益之后:Source Code + 版权 = 利益

有一群黑客,他们崇尚自由,并且痛恨一切对于自由的限制,哪怕是合理的,合法的限制。伟大的Richard Stallman站了出来,在1985年发表了GNU宣言,并于1989年起草了GPL,提出了Copyleft的概念。

所以,在追求自由的黑客看来:Source Code + GPL = 自由

而在另一方面,「贪得无厌」的资本家们,觉得版权法对于他们利益的保护依然不够,他们需要借助专利的力量,不仅保证对手无法盗版他们的软件,而且连仿制都将违法。从美国的软件专利的历史来看,1992年以后,美国的软件专利保护,一直在承不断扩大的趋势。

所以,对于资本家来说:Source Code + 专利 = 受到更多保护的利益

当 然,这个世界上,中庸的人与团体,还是大多数。围绕着源代码,大家也在探索,是不是能够建立某种利益的共同体,而且这个共同体,并不会追求极端的自由,并 不是仅仅为了共享知识,交流学术,他们拿起了法律的武器,创作了很多种不同的License,用于规定参与各方的权利与义务,不但能够与版权相容,甚至与 专利都不产生矛盾。(最早的Open Source这个名词,诞生于1998年)

所以,成千上万的人们,从五湖四海走来,团结在某一个License之下:

Source Code + License = Open Source
就像我不会批评比尔盖茨一样,没有对于版权的强调,就不会有健康的软件行业。我也不会批评开源运动,没有足够好的利益协调机制,仅仅靠理想与坚持,根本不会有现在这么多开源软件。

总体而言,我的态度是:自由软件值得尊重;软件版权应该遵守;开源运动值得参与;专利说到底是个很糟糕的东西;而知识, 蕴含在任何能够被读到的源代码里。

[知乎专栏–思考IT][转载]第一份中文版自由開源授權條款「COPU 開源公共許可協議 v.1.0」草稿淺析

openfoundry.org/tw/lega

建立日期 2014-05-28 16:33 最近更新在 2014-05-29 17:59 作者是 葛冬梅 上週,中國開源軟件推進聯盟(China OSS Promotion Union, COPU,註一)發布了「COPU 開源通用許可協議 V.1.0(以下簡稱「COPU-1.0」,註二)」的草稿,整份授權條款由簡體中文撰寫而成,為全球第一份中文的自由開源授權條款,因此本期的法律專欄 將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同,為了避免辭彙轉換過程無法精確表達原簡體中文的詞意,因此本文在涉及說明 COPU-1.0 草稿內容時,將優先採用草稿中的用語,還請讀者自行參照本文末所附的辭彙對照表,來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞(註三)。

【草擬背景與目的】

根據中國開源軟件推進聯盟官方的新聞稿(註四),由於中國當地社群對於既有的自由開源授權條款大多不了解,許多專案並不知道該如何選擇授權條款,而即使選 擇了,可能也不是那麼切合該專案的狀況,導致在後來的運用上產生了一些問題;此外,目前常見的自由開源授權條款均是以英文撰寫而成,這對於中國大陸的社群 成員來說並不容易了解,同時在商業運用上也發生過,因為企業審核英文授權條款的時間較長,而導致自由開源專案與企業的合作時程必須推延二個月的狀況。鑑於 這些問題,因此中國開源軟件推進聯盟與北大法學院專家合作,制訂出 COPU-1.0 的草稿,一方面協議採用中文撰寫,解決英文所造成的隔閡問題,另外一方面,目前公開草稿內容、徵求當地社群成員意見,期望透過這樣的互動,來提升中國大陸 社群對於智慧財產相關議題的關注。

由於期望這份協議未來可以被中國當地的專案加以採用,因此中國開源軟件推進聯盟之後將會發布條款的解釋文件,以輔助社群成員了解其中的內容。不過是否會發 布英文版本以及申請開放源碼促進會(Open Source Initiative,OSI,註五)的認証,官方新聞稿僅透露會加以「考慮」,因此關於這兩點還有待觀察後續的發展。

【幾近於無的 copyleft 特性】

COPU-1.0 草稿是一份具有非常低度 copyleft 特性(註六)的條款,主要是因為 COPU-1.0 允許使用者為衍生軟件選擇授權內容的自由,所以極端弱化了 copyleft 的特性。相關的規定詳細說明如下(註七):

1、使用者散布未經過修改的被許可軟件時,必須提供全部的源程序,提供的方法 COPU-1.0 規定有三種,使用者可以從其中擇一為之。

2、當被許可軟件被加以修改、增加或刪除之後,就會產生衍生軟件,不過 COPU-1.0 並沒有強制規定衍生軟件一定要繼續採用 COPU-1.0,而是將這樣的選擇權利交在使用者手上,使用者可以選擇繼續採用 COPU-1.0 散布,但是也可以自由採用其他的授權內容(註八)。不過很特別的是,依照 COPU-1.0 的規定,只要是沒有被修改、增加的部份,單獨來說都是「被許可軟件」,並不會構成衍生軟件的一部份,因此被許可軟件跟衍生軟件是兩個分開的、彼此獨立的部 份。舉例來說:最原始釋出的被許可軟件中有 A、B、C、D 四個部份,其中 A、C 被使用者修改後成為了衍生軟件,而 B、D 仍然是被許可軟件,即使 A、C 在運作上可能與 B、D 關係密切,但是 COPU-1.0 將其區分為衍生軟件跟被許可軟件,並分別適用不同的義務規定;這樣相同的修改情況,但若軟體是採用 GPL-2.0 釋出,極有可能因為 A、B、C、D 四個部份在運作上的關係密切,因此這四部份被視為一個整體看待,這一個整體是一個完整的衍生程式,無法切割,進而讓 A、B、C、D 四個部份都必須繼續採用 GPL-2.0 來授權。將被許可軟件與衍生軟件如此獨立區分,是 COPU-1.0 草稿非常特別的規定。

3、另外,COPU-1.0 明確規定兩種利用狀況不會產生衍生軟件,也因此在這兩種情況下,提供源程序的義務並不適用:

(a) 若使用者增加到軟件中的特定部份,是該使用者單獨的獨立作品,那麼這個獨立作品就不是衍生軟件,也因此,這個獨立作品完全不會受到 COPU-1.0 所拘束,使用者在散布時,並沒有提供源程序的義務;

(b) 第二種則是規定單純調用的狀況,並不會讓其他的軟件模組成為衍生程式:一個軟件模組若是為了調用被許可軟件,而包含了被許可軟件的部份調用信息時,這個軟 件模組將不會因此而成為衍生軟件;反之,若被許可軟件為了調用一個軟件模組,而包含了該軟件模組的部份調用信息,也不會讓這一個軟件模組成為衍生程式。不 過若是被許可軟件與軟件模組被編譯成為靜態調用狀態的話,這時候整個被編譯出來的程序仍然被認定為衍生軟件,未來散布的時候,使用者必須提供所有的源程序 給第三方。

上述第 1、2 與 3 (a) 點的內容與 MPL-1.1 的架構規定非常類似,但是相對來說,MPL-1.1 清楚地點出獨立性的判斷基礎在於檔案,也就是當一個檔案被增加到 MPL-1.1 程式中的時候,若是這個檔案並沒有包含任何 MPL-1.1 程式碼的話,這就是一個獨立的檔案,不會受到 MPL-1.1 所拘束,散布時可採用其他的條款授權,但是 COPU-1.0 對於何謂「獨立作品」,或其背後所蘊含的獨立性,並沒有更進一步的說明或闡釋,讓這部份規定留下疑義。另外,第 3 (b) 點的內容則與 LGPL-2.1 相近,因為 LGPL-2.1 是一份針對函式庫所制定的授權條款,因此一個程式單純連結利用 LGPL-2.1 函式庫的話,並不會讓這個程式也成為 LGPL-2.1 的衍生程式,不過若該程式與函式庫一起形成一個可執行檔的話,這整個可執行檔仍然必須受到 LGPL-2.1 所拘束,因此可以看得出來,COPU-1.0 草稿在這部份的規定是與 LGPL-1.1 非常相近(註九)。

MPL-1.1 與 LGPL-2.1 皆是 copyleft 授權條款,其所具有的 copyleft 特性雖然不如 GPL、AGPL 這些條款般強烈,但是基本上其衍生軟體都必須受到原條款所拘束,使用者無法為其自由選擇授權條款。與這兩份條款架構與內容近似的 COPU-1.0 照理也應該具有一定程度的 copyleft 特性,但是因為 COPU-1.0 允許使用者為衍生軟件自由選擇授權內容,讓 COPU-1.0 的 copyleft 特性大幅度地減弱,幾近於無 。

【其他主要內容】

除了上述極端被弱化的 copyleft 特性之外,COPU-1.0 草稿中其他主要的內容還包括了:

1、專利授權。

若是被許可軟件與衍生軟件中應用到許可人所擁有的專利技術,則此項專利技術也授權給予使用者來應用,只要依照 COPU-1.0 的規定來利用軟件,使用者就可以無償地連帶利用許可軟件中的專利技術。

2、顯名義務。

如同其他自由開源授權條款一樣,COPU-1.0 草稿也規定使用者不可刪除、修改許可軟件中的各項權利管理信息、署名信息與源程序中的注釋,除非使用者修改或刪減了源程序,為了配合這些修改、刪減,才可 以相對應地刪除或修改署名信息或相關的注釋。此外,若使用者透過網路提供許可軟件的應用服務時,其雖然不需要將源程序提供給予服務使用者,但卻有義務在提 供軟件應用服務的網站上或者是軟件的介面中,標示其使用了被許可軟件,而這項雲端應用時的標示義務,也及於衍生軟件。

3、文件與注釋保存義務。

對於被許可軟件所附隨的文件,以及在撰寫軟件過程中一併寫入源程序中的注釋,COPU-1.0 均相當重要這些文件資訊的保存。對於附隨的文件,COPU-1.0 規定使用者在散布軟件的時候,都必須要與源程序一併散布出來,不過若是在取得被許可軟件時,並沒有收到任何附隨文件的話,那麼使用者自然就沒有散布文件的 義務。而對於源程序中的注釋,如同上述第 2 點所提到過的,除非源程序經過修改或刪除,否則使用者是不得擅自修改任或刪除任何注釋的內容。

4、提供 COPU-1.0 協議內容的義務。

如同 GPL、MPL 等條款,COPU-1.0 草稿也規定使用者在提供被許可軟件的同時,也必須要提供 COPU-1.0 協議的內容,不過對於透過什麼樣的方式來提供,COPU-1.0 草稿並沒有更細部的規定,因此解釋上,使用者可以自行決定提供的方式,例如提供 COPU-1.0 協議內容所在的網頁網址,也應該是合於規定的。

5、強制散布被許可軟件的義務。

在散布「衍生軟件」的同時,使用者必須要將未經修改的「被許可軟件」的源程序、附隨文件以及 COPU-1.0 協議內容也提供給予第三方。之所有會有這項規定,是因為 COPU-1.0 草稿規定被許可軟件、衍生軟件與獨立作品是彼此獨立的三個部份,在定義上並沒有互相重疊,這樣的設計讓使用者可以選擇單獨散布衍生軟件,而不散布被許可軟 件。不過 COPU-1.0 草稿卻強制規定,無論衍生軟件採用什麼樣的授權條款,一旦使用者散布衍生軟件,同樣也必須將被許可軟件的源程序、附隨文件與 COPU-1.0 協議內容提供給予第三人,以增加被許可軟件的擴散度與能見度。

6、即時提供義務。

所有提供源程序、提供文件與提供 COPU-1.0 協議內容的義務,使用者都不得故意拖延,造成第三方無法即時獲得這些資料的狀況。

7、使用者失權不影響第三方所取得的合法授權。

使用者若是違反 COPU-1.0 規定時,所有原本所獲得的權利將會自動終止,但是第三方的權利並不會受到影響。

【草稿仍有許多待釐清或需要調整之處】

COPU-1.0 目前仍在草稿階段,有部份內容不清、需要被釐清或調整的地方。以下三點,是筆者認為幾項較為重要之處。

1、衍生軟件的定義不清。

GPL-2.0 所規定的衍生程式,是以一個整體運作的軟體為基本單位,MPL-1.1、MPL-2.0 則是以檔案為基本單位,此外,這些條款透過週邊文件的解說跟軟體專案的實務運作,讓使用者可以了解到,這些條款中的衍生程式是必須經過一定程度的修改之後 才會產生的,僅僅只是參數的調教、或少數幾行的改變,原則上並不會產生衍生程式。

但是,COPU-1.0 草稿並沒有像上述條款的闡釋或說明,目前也還沒有釋出說明文件,因此單就草稿的文字來解讀,只要排除被許可軟件與獨立作品後,其他被修改過的部份就是衍生 軟件,即使修改的幅度或品質是非常微量的。同時,對於何謂增加「部份」?何謂修改「部份」?何謂刪除「部份」?這些「部份」的基本計算單位為 何,COPU-1.0 也沒有闡釋或說明,因此這個「部份」可能是個別檔案,也可能是具有特定功效的模組,甚至也可能是一個元件,未來在實際運用上,很有可能會產生使用者各自界 定增加、修改、刪除與「部份」內涵的狀況,進而引發爭議。

此外,如同本文已經說明過的,COPU-1.0 草稿將衍生軟件與被許可軟件視為兩個分開、彼此獨立的部份來規定,這與現行一般自由開源授權條款中衍生程式的概念大不相同,由於筆者並不熟悉中國大陸相關 的法令規定,因此這個規定在其當地法規體系下的合理性與合法性有待考究,不過由於 COPU-1.0 對於如何界定增加、修改、刪除與「部份」等概念並沒有說明或闡釋,而衍生軟件與被許可軟件分別適用的義務跟權利內容差異非常大,因此這種嚴格區分的規範方 式,會讓何謂衍生軟件、何謂被許可軟件的爭議更為擴大。

2、COPU-1.0 在實質運用上的效果與 Apache-2.0 非常相近。

本文已經說明過,雖然 COPU-1.0 具有 copyleft 的形式架構,但是因為允許使用者自由為衍生軟件選擇授權內容,因此 copyleft 特性幾近於無。所以從技術上來說,只要使用者將整個被許可軟件修改過,使其整體轉變成為衍生軟件,就可以為其改用其他的條款來授權散布,甚至是不提供源碼 的條款也可以,也就是說,只要將 COPU-1.0 授權的軟件稍加修改,整個軟件就可以改用其他任何的條款授權。這樣的結果雖然一方面有利於與其他自由開源軟體相容,因為使用者可以為衍生軟件採用 GPL-3.0、MPL-1.1 等等其他的條款授權,但是另外一方面,這樣的結果卻也讓 COPU-1.0 跟 Apache-2.0 這份授權條款變得非常相近,因為 COPU-1.0 草稿的內容皆可在 Apache-2.0 中找到對應的規定,只不過 Apache-2.0 的設計架構,是讓未經修改的軟體可以採用再授權方式散布,而修改過的條款則可以在遵守簡單義務的範圍內,與 COPU-1.0 允許衍生軟件可以改採其他任何條款授權的結果是幾乎是一樣的。因此筆者相當好奇,COPU-1.0 這樣的設計與規定,是否有什麼特殊的背景原因?

3、未明示不可撤回。

經過三十多年的發展,自由開源授權條款具有不可撤回 (irrevocable) 的特性,幾乎已經是被各界所公認,因此在新近修訂的條款中,例如 GPL-3.0 與 MPL-2.0,皆會將這樣的特性在條款中加以明文規定,不過在 COPU-1.0 草稿中,並沒有看到類似的文字,稍有缺憾之感。

【結語】

COPU-1.0 草稿的部份規定,與目前常見自由開源授權條款有所不同,因此筆者相當期待可以看到官方發佈說明文件,來解釋這些文字規定背後的意涵,此外,也很期待可以在 意見徵求程序,看到中國大陸社群成員關於這些內容的討論。不過,若暫時先將草稿內容的疑義放在一邊,筆者以為,從這次 COPU-1.0 草稿的發佈可以了解到,自由開源軟體對於全球的影響之深,即使是中國大陸也因此必須要正視相關的授權議題,甚至進而積極起草制定這份 COPU-1.0 草稿,無論目前草稿內容如何,但這種正視自由開源軟體的態度是值得令人高興的。因此筆者期待中國開源軟件推進聯盟可以早日發佈說明文件,釐清 COPU-1.0 草稿中的疑義。

—-

註一:中國開源軟件推進聯盟:首页 | 中国开源软件推进联盟

註二:COPU 開源公共許可協議 v.1.0」草稿全文請見:中国通用开源许可协议V1.0 出炉,征求意见中 | CODE

註三:《COPU-1.0 草稿中文辭彙對照表》

以下辭彙依照筆劃順序排列

COPU-1.0 草稿用語 -> 台灣一般用語
(繁體中文/簡體中文)
==============================================================
信息/信息 -> 資訊
衍生軟件/衍生软件 -> 衍生軟體、衍生程式
軟件/软件 -> 軟體
許可人/许可人 -> 授權人、著作權人、權利人
被許可軟件/被许可软件 -> 本軟體、原軟體
軟件模塊/软件模块 -> 模組
程序/程序 -> 程式
源程序/源程序 -> 程式源碼、源碼、原始碼
第三方/第三方 -> 後手
署名聲明/署名信息 -> 貢獻聲明、貢獻資訊

註四:本段以下內容皆參考該篇新聞稿之內容,網頁連結如右:COPU 開源公共許可協議的官網,COPU开源公共许可协议背景资料

註五:關於 OSI 以及其所維護的開放源碼定義說明,請參閱:開放源碼定義與開放源碼促進會,開放源碼定義與開放源碼促進會

註六:關於 copyleft 概念的介紹,請參閱:什麼是”Copyleft”?,自由開源軟體概念相關類。關於常見條款所蘊含 copyleft 特性的概要介紹,請參閱:自由開源軟體授權條款的三分法,自由開源軟體授權條款的三分法

註七:本段相關的 COUP-1.0 草稿內容請參見第 2.4 條第 1 款、第 4.3.1 條 。

註八:不過若使用者採用非 COPU-1.0 授權散布衍生軟件的話,COPU-1.0 規定第 6 條的規定仍然繼續適用於衍生軟件,第 6 條主要是規定:當使用者因為違反 COPU-1.0 而喪失權利時,這並不影響使用者授予給第三方的權利。類似的規定在 GPL-2.0、MPL-1.1、MPL-2.0 中也可以見到,但是 COPU-1.0 將這樣的規定也適用在採用非 COPU-1.0 授權的衍生軟件中,則是少見的規定。

註九:本段所提及 MPL-1.1 與 LGPL-2.1 的特性,可以進一步參閱右列文章:從封閉到開放的副產品-MPL,從封閉到開放的副產品;稍稍鬆綁的堅持-LGPL,稍稍鬆綁的堅持

—-

《感謝》感謝林誠夏在本文寫作期間參與討論。

——————

感慨: 佩服对岸的开源研究者的认真和细致,大陆这边,除了冷嘲热讽,就是漠不关心…