分类 观点 下的文章
独家专访 MIT 2017 年度 TR35 吴翰清
先分享一个好消息：今天 《麻省理工学院科技评论》 杂志揭晓 2017 年全球青年科技创新人才榜（TR35）评选结果，阿里巴巴人工智能实验室首席科学家王刚、阿里云首席安全科学家吴翰清脱颖而出，获此殊荣。
TR 35 获奖者 吴瀚清
TR35 是一个针对 35 岁以下青年科技才俊，为找出最有可能改变世界的牛人而设立的奖项。
自 1999 年以来，该杂志每年会在全球 IT（计算机、通信、网络）和生物医药、商业等领域内，从影响力、创新力、进取力、未来潜力、沟通力五个维度进行评估，挖掘学术界和工业界的 35 位科技创新精英。
从以往的上榜者来看，说 TR 35 是预言人类进程的先知也不为过。Google 联合创始人拉里·佩奇（2002 年）和谢尔盖·布林（2002 年），Linux 之父林纳斯·托瓦兹（1999 年），Facebook创始人马克·扎克伯格（2007 年），Yahoo 创始人杨致远（1999 年），Apple 设计总监乔纳夫·伊森（1999 年）等，都曾是该奖的座上宾。如今，他们正在改变我们所处的世界，甚至影响人类进步的方向。
正因如此，TR35 的门槛极高。据统计，从 1999 年到 2016 年，共评选出 820 名 TR35，中国入选者仅 17 人。今年，阿里巴巴有两位科学家同时入选，创下中国互联网科技企业的先例。
非常荣幸，上月在北京举办的网络安全生态峰会上，我与吴翰清有过一次深入的独家专访。本文特别采用问答形式，希望还原吴翰清在技术领域的深度思考。
一、云计算终极目标：实现飞机那样的技术普惠
老王：
网络攻击和渗透行为日益增多，给社会和企业带来巨大危害。但并不是每个企业都有足够的预算和技术能力来迎接安全风险的威胁。
安全服务也能像水、电、网这样的基础服务一样，可以随时购买、随时使用，而不用关心很多引擎盖下面的技术细节？
吴瀚清：
我自己觉得这个问题得分成两部分来看。
首先，今天整个云端团队，或者阿里云安全团队希望成为互联网安全的一种基础设施。既然它是基础设施，它对于很多的人来说，就应该是普惠的，如同今天的水、电、网一样。在这个层面上来讲，我们希望把安全服务做的更加的透明一些，更加的无感知一些。
从技术的角度来讲，有一些问题通过弹性安全网络就有可能解决掉。
但网络安全服务其实是一个研究对抗的问题，只要是人与人之间的对抗，只要还要有坏人存在，就一定有新的安全问题会涌现出来，只是会随着技术发展不断更新。
比如，过去从 PC 走向了互联网、移动互联网，再走向 IoT，所有的安全问题也是跟随着 PC 的发展，然后到互联网，再到移动互联网的安全问题，到未来是研究 IoT 的安全问题。
另一方面，其实我觉得云计算的安全方面，或者云计算本身，它非常像飞机。比如说你要造一架飞机，用到的技术是极其复杂的，但是今天我们每个人都能够用非常便宜的价格，去享受这个航班的服务。所以我觉得这就是里面的差别。
就是说，我们要重新去发明一项技术，把它做到足够成熟是需要非常专业的人，花非常大的代价去把它做出来的。但是，最后我们要把这个非常复杂的技术，做到每个人都能够用。每个人都能够用最低的成本、最低的门槛去使用。
我觉得这个就是云计算所要追求的目标。就是要让技术变的普惠。让每个人都能够非常简单的去用非常复杂的技术。
对于普通客户，他并不需要理解一架飞机的原理，它只要能乘坐就好。
二、安全边界将会越来越模糊
老王：
怎么样才能让用户，在需要时能够感知到安全，没有遇到安全问题的时候实现隐形。这个安全边界是怎么确定比较好？
吴瀚清：
AWS 提出了责任共担模型，他们认为操作系统之下的都是他们来负责；操作系统之上的都是客户自己来负责的，比如客户自己写的应用，比如自己管理的一些系统，比如客户配置出现了问题，都是要客户自己来负责的。但是操作系统之下，进程本身的安全，包括底层基础设施的安全，这些都是由 AWS 来负责。他们把这个边界划在这里。
但是我觉得这个边界，也不是一成不变的，它会随着软件架构的演进而不断发生变化。
边界会越来越模糊，而且我们整个技术是在进步的，所以在我的理解里，云计算是不需要像 Windows 跟 Linux 这样的 PC 时代的操作系统的。
因为今天大量的云时代的应用，或者互联网时代的应用，实际上就是用代码直接操作数据，其实并不需要关心底层操作系统。从这个角度来讲，今天这些程序员写代码的方式将来都是需要变化的。当计算时代真正到来的时候，比如说现在 AWS 就在推 serverless 这样的一些东西，谷歌也有 GCE，类似这些东西，实际上它真正代表的是未来我们写代码操作数据的方式。
所以回到未来来看，今天你所关心的很多的软件问题，在那个时候已经不再是一个问题了。因为都被云计算公司封装到了它的责任范围之内，所以我觉得这条线、这个边界是在不断地演进的，而且它的封装是越来越完整的。
三、未来五年，安全看 IoT 和 AI
老王：
你们现在有没有考虑到三年、五年以后的安全势态会怎么样，会不会研发相应的产品和技术？
吴瀚清：
我觉得未来要抓的两件事情，还是相对比较明确。
在战略思考方面，第一个就是抓 IoT。可能在整个 IoT 这方面，最根本的一个东西就是认证体系，它应该是从一个硬件芯片开始，通过证书做硬件的加密和认证，然后通过信任链的传递，在整个 IoT 里面我们就会有一个可信的计算环境。我们今天在 IoT 的安全方面，已经有一些解决方案。
另外一件，我觉得 AI 是我们这个时代接下来需要重点去抓的事情，它带来的这个变化，可能会超过我们所有人的想象，它可能会像手机出现的时候，会对这个世界带来这么大的影响和变化。所以今天如何把 AI 应用在我们安全技术本身，这个是我们今天要去思考的。
四、对网络暴力斗争到底
老王：
在安全圈子里，有没有攻击者和厂商互相勾结？
吴瀚清：
从这个行业乱象来讲，今天一定存在你刚才说的这种黑与白的互相勾结，或者收取保护费的事情。
特别在我所了解的高防这个产业，实际上有一些这样的乱象的，就是攻击者和收保护费的实际上是同一波人。但是今天从其他的一些我所了解的一些厂商来说，比如说像今天的阿里，或者我们的一些友商，他们是绝对不会做这种事情。
因为对于阿里自己来说，对我们来说每一次大的攻击的挑战，实际上都是一次磨炼我们技术的机会，如果我们不去正面迎接这种挑战，我们的技术就不会进步。错过了我们技术进步的这个机会，我觉得这才是对阿里来说更大的一个损失。所以面对这种网络暴力，实际上我们更加采取的是这种绝不宽容的这种态度，一定会去斗争到底的。
五、安全和开源、闭源没有关系
老王：
你对开源与安全是怎么看的？它们之间有没有必然联系？有什么样的联系？
吴瀚清：
我觉得安全不安全，跟开源还是闭源没有直接的关系。但是它跟这个软件背后的这个运营方是有关系的。
比如就开源软件来讲，有很多很多的开源软件，确实对整个互联网作出了不可磨灭的贡献。但是也有很多开源软件，它的软件开发者是非常、非常缺乏安全意识的。
像 Linux 这种，它本身有一个非常好的基金会，它的开发者都是非常资深的软件工程师，本身又有非常好的安全意识和非常完善的机制。从这个角度来讲，Linux 本身的安全，我觉得是做的非常不错的，而且它也在持续的、不断推出一些新的安全功能。
回到闭源软件这一边，比如微软本身就建立了非常好的一个应急响应机制，它本身建立了非常大的安全团队来做安全这个事情。从这个角度来讲，微软的安全也做的不错。
在我看来，更重要的应该去关注应急响应，这应该是整个安全机制里面最重要的一些事情。甚至我觉得，应该占到整个安全工作的 50%。另外 50% 的工作就是检测，所以安全实际上就是做两件事情，就是检测和响应。
所以在这里面我们做的很多工作，都可以看成应急响应的一部分。比如说你发现问题之后，你去做这个漏洞的修补，以及定期检查之后做的加固。包括通知机制，实际上都是应急响应需要去做的。应急响应不仅仅是解决具体某一个漏洞的问题，它还包括一系列的问题，包括安全的分析，以及产品能力本身的提升，比如说这次响应没有做好，下一次你的产品是不是有更强的能力来提升？
同时这还涉及到一个对外舆情的问题。这种应急响应是不是会带来恐慌？比如说有一些安全问题，完全是炒作漏洞，很多客户就会引发恐慌，这时候你能不能通过技术分析出来拨乱反正？所以有很多这样的问题，综合起来就会变成一个体系。
我们觉得今天可能更多的东西，应该是从实践中来的。所以几乎阿里云每周都在进行安全响应，每周都在响应两到三次。所以就会把我们的一套非常高效的流程给逼出来。
在未来我们也希望在这一块能够帮到更多的企业，我们在应急响应这块，也希望能够推出更多的产品和服务。
六、坚持产品的使命是最根本的东西
老王：
你是阿里云的初创成员之一，也是阿里云安全团队初创成员。是否可以分享一下如何规划团队的技术和发展？
吴瀚清：
阿里本身也是一家使命驱动的公司。所以这两点，造成我们的做事方式实际上还是有迹可循的。
今天在所有的战略思考和所有的坚持上面，我们的使命一直是建设互联网安全的基础设施。
从这个角度来讲，我们会做很多、很多的东西。我们现在的产品，不管这个产品的形态如何发生变化，可能会经历一些阶段性的失败，但是我们的产品，最终它要去的那个地方，是始终没有动摇过的。
像我们的高防产品，我们第一天就打出一个使命，就是我们要消灭互联网的 DDoS，这是我们和其他所有做高防产品厂商的区别。他们都是希望 DDoS 存在的，因为这个能带来业务收入。
但是我们今天不在乎靠这个反 DDoS 产品赚钱，虽然今天我们的主要收入确实来自这个产品。这是一个现状，但是未来我们要去的地方-------我们是希望消灭整个互联网的 DDoS 的。我也觉得，只有真正到了那一天，我们对这个互联网和对这个社会的贡献的价值足够大，才会有足够大的商业空间诞生出来。我觉得这是我对整个商业的一个理解。
所以我觉得，今天在整个使命愿景的坚持上面，是我们最根本的东西，今天经历的所有的波折，实际上都是可以根据时间随着来调整的。
七、给年轻从业者的建议
老王：
现在有很多年轻人想从事安全服务行业。作为一个资深的网络安全专家，有什么建议？
吴瀚清：
我觉得主要是三件事情。第一件就是多看一些书；第二件是多去见一些真正优秀的人；第三件是多经历一些事情。
回到安全服务这个行业，我觉得除了多看书之外，动手能力是最重要的。我觉得这个对于所有从事计算机产业的年轻人，都是非常重要的一个建议。就是动手远比从书本上看东西要重要------当然看书也很重要。
再就是能够多接触一些行业里面真正优秀的顶尖人物，我觉得这是需要他自己不断去找机会去拓展的。
安全这个行业，我觉得跟其他产业不太一样的地方，就是在于今天我们是在里面有一个对抗存在，涉及到正义与邪恶的，我希望未来的年轻人不要走上邪路，要站在正义的这一方，真正成为光明的守护者，去保护我们人民财产的安全。
采访后记
对吴瀚清的采访就到这里，从和吴瀚清的交谈中，我能体会到真正纯粹的技术专家的赤子之心，也能感受到吴瀚清和他的团队对安全的热爱和社会责任感，其所一直践行的，或许就是他的“道”吧。
采访者：老王，Linux 中国开源社区的创始人，曾任职亚信旗下的玛赛系统安全公司的华东区技术总监，中国电信系统集成公司网络安全事业部高级专家。
踢掉 FB+PL：Apache 的开源激进宣言？
本文撰写参考了以下文章，并引用了该文章部分内容：专利告诉你，为何 Apache 禁用 FB + PL 代码，作者：付钦伟。
哪里有压迫，哪里就有反抗
身为知识产权圈里的专利人，笔者钦佩开源情怀，并曾写道：即使专利人也有专利情怀，现实世界中开源与专利的碰撞依然难免丑陋。现在看来，这话有点轻描淡写了。
笔者未能认真发掘开源运动史，只好拍拍脑袋认定：开源软件运动是针对知识产权制度，尤其是专利制度，对软件产业之压迫的暴动。
“哪里有压迫，哪里就有反抗。”
这场轰轰烈烈的暴动在发展过程中，于 2017 年 7 月，“Apache Software Foundation 主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents license（以下简称 FB+PL）已经正式被列入 “CategoryX” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。”
简而言之，Apache 一脚将 FB+PL 踢出了。这是不是 Apache 在开源暴动中的激进声明？为什么这么说？
专利情怀
故事要从头讲起：
专利制度产生了，那时候大家并不认为这是一个万恶的吃人的制度。专利制度的根本目的还是促进技术进步，从而推动产业和经济发展。为了达成此目的，则需要合理保护发明人的积极性，具体而言，就是给予他们一定时期的专有保护为回报，在这种利益驱动下，他们会积极的做出发明，并通过申请专利，在向社会公布技术促进技术进步的同时，兑现专有保护。
"Before then [the adoption of the United States Constitution], any man might instantly use what another had invented; so that the inventor had no special advantage from his own invention. The patent system changed this; secured to the inventor, for a limited time, the exclusive use of his invention; and thereby added the fuel of interest to the fire of genius, in the discovery and production of new and useful things. "
-- Abraham Lincoln, Second lecture on discoveries and inventions, February 11, 1859
以上这段诠释了专利情怀的话出自美国总统林肯的演讲。只需要读懂这个短句就好了：专利制度为天才之火添上利益之油。
开源与专利的碰撞
到上世纪 90 年代，专利海盗开始大行其道，软件产业受害最深。在软件行业里，程序员和开发者需要开放、自由地交流和利用彼此的成果才利于行业发展。这一特性先天与专利制度八字不合。这个死结是一百多年的林肯总统绝对意料不到的。
从根本上，开源情怀在于：对于自己的智力劳动成果，放弃可取得收益的专有权利，给软件松绑，从而利于成果的流通、利用，以及行业发展。
绑在软件身上的主要知识产权绳索有两条：版权，专利。商标不起核心作用。解开版权这条绳索的方式比较成熟：版权开源许可证。而专利很微妙，最主要的原因是它的无形，主动权常常不在开源作者自己手里。版权是属于作者的，所以作者有主动权；而专利属于申请人，申请人有主动权，申请人可以是任何第三方。这是开源与专利之矛盾的根源。
对开源情怀的最大伤害在于：不知道是谁用专利这根无形绳索悄悄捆绑了自己的作品。这是开源人对专利的敏感和敌视的由来。开源人常常感到愤怒和难以理解的是：为什么自己的智力成果，别人可以用专利来捆上？
对不起，这一个很让人遗憾的回答：任何人都可以对包括已公开的开源技术在内的任何现有技术做出改进，并就改进获得专利权。而当有别人在某项开源技术比较可行的主要改进方向上都申请了专利，就相当于把主要出路都卡上了，那么这项开源技术也就被别人的专利绑上了。这种专利申请技术，在圈内有一个好听的名字：专利布局。防御性的专利布局可以用来对自己的技术成果形成严密保护。进攻性的专利布局可以用来摘别人的桃子的，包括摘开源的桃子。专利海盗就属于充分、高超地利用专利手段和法律程序，激进地玩进攻性专利布局来摘别人桃子的。有时，手法可以高超到骗过专利审查员的法眼，将与现有技术很接近的内容纳入自己的保护范围。软件行业是重灾区。
应当说，在专利方面，对开源最大的威胁来自第三方，而不是开源的作者、后续开发者、用户。在社区内，大家尝试在版权开源许可之外附加专利开源许可，但是因为这种附加许可的效力仅能延伸到后续开发者、用户，不能规制第三方或专利海盗，实质能达到的效果较为有限。
Facebook 被踢的委屈
现在，我们重新梳理一下 Apache 踢 FB+PL 这件事。Apache 主要是对 Facebook Patents license，即对专利许可的条件不满意才开踢的。
Apache 的表态很干脆地捍卫了开源情怀，但是不是有些偏强硬激进了呢？
对于发展开源事业，首要的问题是什么呢？当然应当是分清谁是朋友，谁是敌人。然后，团结一切可以团结的进步力量，形成对敌统一战线。
笔者猜想，开源的敌人是第三方专利海盗，以及供专利海盗滋生的土壤。Facebook 看起来更像可以团结的朋友：Facebook 对开源有很积极的贡献和推动，其在专利许可方面的动作应当也没有越线。Facebook 如果真想以专利捆绑开源，另安排一个白手套作为第三方来布局专利，岂不干脆彻底？哪里还需要如此费事的搞 Facebook Patents license？至少应当说，Facebook 还是出于基本善意的立场提出的专利许可。
扒扒 Facebook 专利许可
再深入剖析这个问题，就要梳理 Facebook Patents license 的主要条款对开源的影响了。
Facebook Patents license 的主要条款：
Additional Grant of Patent Rights Version 2
"Software" means the React software distributed by Facebook, Inc.
Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.
简要而言，关键点有两个：
- Facebook 对免费专利许可设了限制条件：你不可以诉我知识产权侵权；
- 专利许可所涉及的专利，仅限于所涉及的开源软件本身，对于软件修改后或与其他技术共同使用而可能侵犯的专利，不在许可之列。
法律背景扑朔迷离
即使分析以上两个要点，也要仔细衡量，须考虑现实背景中的重要因素：
- 如果无专利许可，会如何？
- 许可不涉及实质性的对价。
- 许可涉及复杂的国际司法环境。
笔者认为，许可条款之外的上述背景中的三条因素才真正使许可的效力变得扑朔迷离。
就背景因素 1 而言，现实情况中，普遍存在开源许可证仅涉及版权而回避了专利的情况。这是社区当中大家普遍可以接受的条件。未提及专利，并不等于没有给予专利许可，尤其在许可证中没有明示“专利要另收钱”的情况下。有一个奇妙的东西，可以叫作基于诚实信用或善意公平原则的“默认许可”。
何为“默认许可”？简单讲，当你给人家什么东西去用，没有明示这个东西要收钱，人家用了之后，你向人家去收钱，这么做不太厚道吧？基于诚实信用或善意公平原则，通常法院不会支持这种像是给人下了套，然后去收钱的行为的，而会认为当你给人家东西去用，没有明示这个东西要收钱时，已经“默认许可”人家免费用了。
开源软件的作者或提供者，同时又作为相关专利的专利权人时，在提供了明确免除版权费用的许可证的情况下，如果在向用户交付产品的同时，没有明示要收取专利费，“默认许可”应当成立。从学术讨论的角度，也有将之称为“专利权权利用尽”的。但是由于未收钱，“专利权权利用尽”的成立更有困难些。笔者还是坚持“默认许可”路线。
但还是很遗憾，法律世界不同于软件世界。在软件世界里，每一段算法程序，在给定条件后，都会给你执行出一个清楚的结果。法律世界里很难如此。“默认许可”是否会得到司法完全支持？真的很难讲，各个国家，甚至一个国家在不同时期，都可能对相似的情况采取不同的思路并给出不同的分寸和方向的判决。在美国、英国、澳大利亚等海洋法系的国家，前后判例的一致性会比较高。而中国、德国等大陆法系国家，变化可能较大。以下将要讨论的诸多问题均受各国司法差异因素影响，以下不再赘述。
总之，不确定性较大。尽管笔者对各国实际判例缺少一手研究，但从法理和情理上倾向于在专利“默认许可”成立，即利于开源免费。
就背景因素 2 而言，许可是否涉及实质性的对价是很重要的因素。实际上，我们现在讨论的是许可证，性质又不同于协议，但一些相关因素可以类比来考虑。没有实质性对价，指没有因交易性的收获进行实质支付，比如，支付价款。在这种情形下，许可证或协议在性质上更类似于赠与，对有关方的权利义务要求未必牢固。比如，Facebook 将自己开发的软件拿出来开源，自己付出了开发成本，却没有向使用者收取费用；使用者可以较随意地拿 Facebook 的开源软件免费使用。如果由于这种免费的行为中暗藏玄机，而导致 Facebook 或使用者要承受重大的义务、付出重大代价，则是有失基本公平的，除非有特别原因。所以，各国从司法的角度，会考虑“是否涉及实质性的对价”这一因素，但仍然是会采取不同的思路并给出不同的分寸和方向的判决。简而言之，Facebook Patents license 并不涉及实质性的对价，所以司法层面不会随便基于这种许可而使有关方承担与对价不相匹配的重大义务。
总之，还是不确定性较大，尽管笔者还是对各国实际判例缺少一手研究，但从法理和情理上仍倾向于 Facebook Patents license 因不存在实质性对价，相关方带来重大义务或损失的可能性较低，即利于开源免费。
背景因素 3 已经融合在以上讨论之中了。
综合以上背景因素的讨论，可知 Facebook Patents license 对开源还是比较友好的，至少不会造成重大损害。
Facebook，面子大于里子
再审视 Facebook Patents license 的两个关键点，其对“默认许可”是否仍能成立各有微妙影响。笔者的观点是，很可能使情形确实反而不如没有这个 Facebook Patents license，不过负面影响有限。
就关键点 1，Facebook 对免费专利许可设了限制条件：你不可以诉我知识产权侵权。
明示的效力当然优于默认的效力，所以笔者倾向认为默认许可的效力被破坏了。但以下三个因素将对开源有利：
- 用户对 Facebook 发起诉讼时，许可终止，但用户此前的使用仍享受免费许可。所以，主动权还是在用户手里，可以选择有利形势。当用户认为自己更多的知识产权为 Facebook 所使用，份量重于自己所使用的 Facebook 开源软件的知识产权时，才发起诉讼，并在诉讼前做好调整和准备；如果自己用的 Facebook 的知识产权比较多，而被 Facebook 使用的知识产权少，自己还是在赚便宜，何必去找 Facebook 麻烦呢？更应当指出，Facebook 所设的这个条件较容易做被规避：可以将专利转移给第三人，也就是白手套，由白手套去诉 Facebook。这样，即可以继续享受免费许可，又可以搞 Facebook。这在法理上是成立的。
- 对单一用户来讲，出现要诉 Facebook 而会破坏免费许可这一情况的现实可能性较低。
- Facebook 此条件有构成滥用知识产权的风险。
以上第 1 条实际上已经能够让 Facebook 的关键点 1 形同虚设，达不成实际意义了。以上第 3 条，不确定性很大。
就关键点 2，专利许可所涉及的专利，仅限于所涉及的软件本身，对于软件修改后或与其他技术共同使用而可能侵犯的专利，不在许可之列。
关键点 2 实际上暗藏杀机，比形同虚设的关键点 1 凶险些，但实际威力也还有限。重点在于：
- Facebook 明示不予许可的专利：软件修改后或与其他技术共同使用而可能侵犯的专利，实际上照样可能将开源软件捆死。这是其心机最凶险之处。
- 尽管 Facebook 明示排除了软件修改后或与其他技术共同使用而可能侵犯的专利，但只是泛泛而论。实际上，用户修改软件或将之与其他技术共同使用是必然普遍发生的情况，如果 Facebook 没有及时向用户提示这些具体专利的存在，并对收费有明确具体要求，笔者倾向于默认许可的效力仍应成立。当然，不确定性仍然较大。“及时向用户提示”指对于软件交付之前已经持有的专利，应在软件交付前明确提示；对于软件交付之后获得的专利，应在专利获得后马上提示。
综上，尽管复杂的不确定性仍较多，笔者倾向于认为 Facebook Patents license 总体上对开源较为友善，与不涉及专利的许可证相比较，没有带来实质性变劣。对 Facebook 而言，可能象征意义更大于实质意义，即面子大于里子。
Apache 潜在风险
另外，还有一个潜在风险因素，使 Apache 踢掉 FB+PL 之后使自己处在更为不利的境地。
Apache的风险控制措施是：“Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉 及FB+PL 许可证的，需要在 8 月 31 号前完成替换。”这一措施理论上说说还好，但在可操作性上问题很多。笔者认为，剔除 FB+PL 版权许可证所涉及的内容比较好操作：只要剔除相关的代码，替之以其他来源或自编的代码就好了。因为其他来源或自编的代码，基本就能确保在表达方式上的不同，从而规避版权侵权。这是现实的操作方式。
而规避侵犯 Facebook 专利权，上述方式很可能并不奏效。简单而言，版权保护表达形式，专利保护构想。规避表达形式，也就是从表述方式上加以实质调整就可以做到了。而规避构想，确实很难。实际上，Facebook 到底有哪些专利与之相关恐怕也很不清晰，还要加以规避，就更是难上加难了。分析工作和代码的重新设计对专利的专业性要求非常高，工作很复杂，工作量也很大。
这种情况下，Apache 可能面对的最坏情况是：放弃了 FB+PL 的开源代码，仍存在侵犯 Facebook 专利的高风险，又不会得到 Facebook 明示、默认许可。
Apache 的激进开源
所以，笔者认为，Apache 的表态很干脆地捍卫了开源情怀，踢掉 FB+PL 的行事方式有可能略偏强硬激进，尽管从规避不确定的风险而言，也不是完全没有道理。
（题图：HuffPost）
作者简介：
李可
集慧智佳知识产权咨询公司，李可。江湖人称“可哥”，老牌专利代理人，知识产权高级咨询师。70 后文艺理工男，属牛，性子慢但踏实稳妥。
如何建模可以帮助你避免在 OpenStack 中遇到问题
OpenStack 部署完就是一个 “ 僵栈 ”，一般出于技术原因，但有时是商业上的原因，它是无法在没有明显中断，也不花费时间和成本的情况下升级的。在关于这个话题的最后一篇文章中，我们讨论了这些云中有多少陷入僵局，以及当时是怎么决定的与如今的大部分常识相符。现在 OpenStack 已经有 7 年了，最近随着容器编排系统的增长以及更多企业开始利用公共和私有的云平台，OpenStack 正面临着压力。
没有魔法解决方案
如果你仍在寻找一个可以没有任何问题地升级你现有的 僵栈 的解决方案，那么我有坏消息给你：没有魔法解决方案，你最好集中精力建立一个标准化的平台，它可以有效地运营和轻松地升级。
廉价航空业已经表明，虽然乘客可能渴望最好的体验，可以坐在头等舱或者商务舱喝香槟，有足够的空间放松，但是大多数人会选择乘坐最便宜的，最终价值等式不要让他们付出更多的代价。工作负载是相同的。长期而言，工作负载将运行在最经济的平台上，因为在高价硬件或软件上运行的业务实际上并没有受益。
Amazon、Microsoft、Google 等大型公共云企业都知道，这就是为什么他们建立了高效的数据中心，并使用模型来构建、操作和扩展基础设施。长期以来，企业一直奉行以设计、制造、市场、定价、销售、实施为一体的最优秀的硬件和软件基础设施。现实可能并不总是符合承诺，但它现在还不重要，因为 成本模式 在当今世界无法生存。一些组织试图通过改用免费软件替代，而不改变自己的行为来解决这一问题。因此，他们发现，他们只是将成本从获取软件变到运营软件上。好消息是，那些高效运营的大型运营商使用的技术，现在可用于所有类型的组织。
什么是软件模型？
虽然许多年来，软件程序由许多对象、进程和服务而组成，但近年来，程序是普遍由许多单独的服务组成，它们高度分布在数据中心的不同服务器以及跨越数据中心的服务器上。
OpenStack 服务的简单演示
许多服务意味着许多软件需要配置、管理并跟踪许多物理机器。以成本效益的方式规模化地进行这一工作需要一个模型，即所有组件如何连接以及它们如何映射到物理资源。为了构建模型，我们需要有一个软件组件库，这是一种定义它们如何彼此连接以及将其部署到平台上的方法，无论是物理的还是虚拟的。在 Canonical 公司，我们几年前就认识到这一点，并建立了一个通用的软件建模工具 Juju，使得运营商能够从 100 个通用软件服务目录中组合灵活的拓扑结构、架构和部署目标。
Juju 建模 OpenStack 服务
在 Juju 中，软件服务被定义为一种叫做 Charm 的东西。 Charms 是代码片段，它通常用 python 或 bash 编写，其中提供有关服务的信息 - 声明的接口、服务的安装方式、可连接的其他服务等。
Charms 可以简单或者复杂，具体取决于你想要赋予的功能。对于 OpenStack，Canonical 在上游 OpenStack 社区的帮助下，为主要 OpenStack 服务开发了一套完整的 Charms。Charms 代表了模型的说明，使其可以轻松地部署、操作扩展和复制。Charms 还定义了如何升级自身，包括在需要时执行升级的顺序以及如何在需要时优雅地暂停和恢复服务。通过将 Juju 连接到诸如 裸机即服务（MAAS） 这样的裸机配置系统，其中 OpenStack 的逻辑模型可以部署到物理硬件上。默认情况下，Charms 将在 LXC 容器中部署服务，从而根据云行为的需要，提供更大的灵活性来重新定位服务。配置在 Charms 中定义，或者在部署时由第三方工具（如 Puppet 或 Chef）注入。
这种方法有两个不同的好处：1 - 通过创建一个模型，我们从底层硬件抽象出每个云服务。2 - 使用已知来源的标准化组件，通过迭代组合新的架构。这种一致性使我们能够使用相同的工具部署非常不同的云架构，运行和升级这些工具是安全的。
通过全面自动化的配置工具和软件程序来管理硬件库存，运营商可以比使用传统企业技术或构建偏离核心的定制系统更有效地扩展基础架构。有价值的开发资源可以集中在创新应用领域，使新的软件服务更快上线，而不是改变标准的商品基础设施，这将会导致进一步的兼容性问题。
在下一篇文章中，我将介绍部署完全建模的 OpenStack 的一些最佳实践，以及如何快速地进行操作。如果你有一个现有的 僵栈 ，那么虽然我们不能很容易地拯救它，但是与公有云相比，我们将能够让你走上一条完全支持的、高效的基础架构以及运营成本的道路。
即将举行的网络研讨会
如果你在旧版本的 OpenStack 中遇到问题，并且想要轻松升级 OpenStack 云并且无需停机，请观看我们的在线点播研讨会，从 Newton 升级到 Ocata 的现场演示。
联系我们
如果你想了解有关迁移到 Canonical OpenStack 云的更多信息，请联系这里。
（题图：乐高的空客 A380-800模型。空客运行 OpenStack）
作者简介：
专注于 Ubuntu OpenStack 的云产品经理。以前在 MySQL 和 Red Hat 工作。喜欢摩托车，遇见使用 Ubuntu 和 Openstack 做有趣事的人。
作者：Mark Baker 译者：geekpi 校对：wxy
极客漫画：不要使用 SIGKILL 的原因（看哭了）
在 Linux 中，通常可以发送一些信号来杀死一个进程，一般用来杀死进程的信号有 SIGTERM、 SIGKILL。但是，如果希望进程合理地终止，就不要发送硬中断信号 SIGKILL，因为该信号是不能拦截的，进程接到该信号之后会马上退出，并没有机会进行现场清理——这包括对线程的关闭等操作。更好的做法是，发送 SIGTERM 信号，这样进程在接到该信号后，可以做一些退出的准备工作。
或许你之前对如何杀死进程并没有感到什么不同，但是，看了这幅漫画，你不觉得那些孩子们（线程）很可怜么——虽然 温和的 SIGTERM 也是要全家干掉的。哭~
via: http://turnoff.us/geek/dont-sigkill/
作者：Daniel Stori 译者&校对&点评：wxy 合成：wxy
极客漫画：Linux 内核中的兄弟打架
多线程编程中，如何处理共享的资源是个头疼的事情。
那边那个蹦起来的就是堆栈被搞乱的，罪魁祸首显然就在这两个背手挨骂的线程当中。
via: http://turnoff.us/geek/brothers-conflict/
作者：Daniel Stori 译者&校对&点评：wxy 合成：wxy