随着Apache、百度、Wordpress都在和Facebook的React.js以及其专利许可证划清界限,似乎大家又在讨论Facebook的这个BSD+PATENT的许可证问题了。这让我想起了之前在Medium读过的一篇文章——《React, Facebook, and the Revocable Patent License, Why It’s a Paper》,我觉得那篇文章写的不错,而且还是一个会编程的律师写的,所以有必要把这篇文章传播到中文社区这边来。注意,我不会全部翻译,我只是用我的语言来负责搬运内容和观点,我只想通过这篇文章让大家了解一下这个世界以及专利相关的知识,这样可以避免你看到某乎的“怎么看待XXX”这类的问题时人云亦云,能有自己的独立思考和自我判断。;-)

这篇文章的作者叫Dennis Walsh,他自称是亚历桑那和加利福尼亚州的律师,主要针对版权法和专利诉论的法律领域。但是这个律师不一样,他更很喜欢商业和软件多一些。现在他用React/GraphQL/Elixir在写一个汽车代理销售相关的软件,而且已经发布到第2版了。

首先,作者表明,专利法经常被人误解,因为其实充满了各种晦涩难懂的法律术语,所以,作者用个例子来讲述专利的一个原则 —— 专利并不是授于让你制造或开发的权利,而是授予你可以排他的权利。(事实上似乎也是这样,申请专利很多时候都不是为了制作相关的产品,而是为了防止别人使用类似的技术制作相关的产品)

如果有公司X为铅笔申请了专利,而另一家公司Y为把用于铅笔的橡皮擦申请了专利。那么,公司X可以阻止公司Y来生产铅笔,而对带橡皮擦的铅笔没办法,但是公司Y的专利可以让公司X不能生产带有橡皮擦的铅笔。

所以,公司Y的橡皮擦专利又被广泛地叫作“Blocking Patent”。公司Y不能说他发明了铅笔,因为这是公司X的专利,但是,他们可以让公司X无法对铅笔做出某些改进。

于是,因为这种 Blocking Patent 存在,对于开源的公司是不利的,因为根据上面的那个例子来说,开源公司就是公司X,他们做了一个基础的软件,而公司Y在上面做了些改进,并注册成了专利,从而导致开源的公司X无法对它基础开源软件作出被公司Y专利阻止的改进,开源的公司X希望能够自由地使用公司Y的橡皮擦专利,因为毕竟是它发明了铅笔并放弃了铅笔的专利。

于是就出来了“专利反击条款”(Patent Retaliation Clauses)。一般来说有两种专利条款,一种是弱条款,一种是强条款。

Weak Patent Retaliation Clauses – 这种条款声明,如果许可证持有者用某个专利来打击许可证颁布者,那么专利就视为终止。用人话来表达就是,公司X做了一个开源铅笔,而公司Y注册了橡皮檫专利。此时,公司X做了一支带像皮擦的铅笔,而公司Y马上对公司X提起专利侵权诉讼。那么,公司Y就失去了对底层铅笔的专利控制。(正如前面所说的,公司Y的橡皮擦专利因为在起诉公司X的开源铅笔,而失去了对开源铅笔的专利排他权利)

Strong Patent Retailiation Clauses – 这种条款声明比“弱条款”要的更多。具体来说就是,任何专利声明终结许可证,而不管这个专利有没有和你基础的软件有关系。用人话来说就是,公司Y使用他们的热气球专利来起诉公司X,那么公司Y就失去了他们对铅笔的专利限制。

我个人理解起来,这两种条款看上去是防御性质的。

Facebook的React的Patent License如下:

The license granted hereunder will terminate, automatically and without notice,if you (or any of your subsidiaries, corporate affiliates or agents) initiatedirectly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporateaffiliates, (ii) against any party if such Patent Assertion arises in whole orin part from any software, technology, product or service of Facebook or any ofits subsidiaries or corporate affiliates, or (iii) against any party relating to the Software. Notwithstanding the foregoing, if Facebook or any of itssubsidiaries or corporate affiliates files a lawsuit alleging patentinfringement against you in the first instance, and you respond by filing apatent infringement counterclaim in that lawsuit against that party that isunrelated to the Software, the license granted hereunder will not terminateunder section (i) of this paragraph due to such counterclaim.

这些条款中和基础软件没有任何关系,所以,这个条款是“强专利反击条款”

在后面,本文的作者又解解释了,为什么React的“强专利反击条款”就跟没有似的。他在文中针对一些歇斯底里的言论,如:“Facebook不用害怕专利诉讼了,而且他可以随时偷袭你家的专利仓库”,也作出了一些解释来分析这个事。

Contractural Liability – 意思是说,专利方面的东西只会影响专利上的事,而不会影响和专利无关的事,React底层协议是BSD-3许可证还是会被保留。换句话说,React的“强专利反击条款”只生效于专利层面,而不会对非常专利的软件使用产生问题,如果和专利无关,React还是走BSD-3的许可协议。

Copyright Liability – 这个和Contractural Liablitity 一样。作者说,如果有人有特别的案例或是有说服力的论据来说明Facebook的这个条款会作用于非专利的地方,那么,请告诉他。

Patent Liability – 专利的责任和损害是两件事,非专业人士总是会把其搞混。

第一个问题是Liability, 要搞清这个事,得搞清“Patent’s Claims”,而不是这个技术的技术规格说明,技术规格说明和权力主张是两码事。作者说,现在的很多专利都是一些想法,很多投机份子随便一拍脑袋就发明出一个想法,然后就去注册专利了。但是可以被用来法律执行的只有“Patent’s Claims”(专利的权利主张),而不是那些想法。这些权利主张相当相当的晦涩难读,而且是会故意被模糊掉的,因为,当你清楚的定义了你的发明是什么,那么,就可以清楚的定义出来什么不是你的发明。比如:一个铅笔专利权利主张里说,“这一个用石墨和木头组合起来的写字工具”,那么,只要我不用木头和石墨来做组合,而是用塑料来做组合,那么我就不是专利侵权。所以,一般来说,专利主张是会更为通用一些,比如,“这是一个用于涂画表面的装置,其包括:与涂画端相连的握持端”。作者这里给了一个苹果公司的滑动解锁专利的示例。可以感受一下产品规格说明和专利权利主张完全是两码事。

专利这些事,在法律界里是非常非常困难作出评估的。所以,这个社会每年都会给律师们几十亿美金来一遍又一遍地回答这些问题,而且律师还经常回答错了。而对于美国的法律,对于专利诉讼会有一个叫Markman hearing的审前听证会(马克曼听证会),自从1996年美国最高法的“马克曼诉威斯幽仪器公司案”这个听证会就变成了一个惯例,美国联邦法院用这个听证会来向决定专利权利主张的解释,而且,上诉法院还经常性的推翻审判法院的裁决。(对于美国法律来说,一般是法官认证法律,陪审团认定事实,然而,对于专利而言,1996年的那个案件认为专利术语是一个需要法官决定的法律问题,而不是陪审团决定的事实问题。关于马克曼听证会的事,可以参看本文未尾的附录)

所以,要决定Facebook的专利责任,我们需要评估Facebook的专利及其权利主张,而不是技术规格说明。具体来说,要明确Facebook对于React这个底层技术的专利权利主张是什么?但是作者搜了一下,发现什么也没有找到。也就是说,对于USPTO(美国专利商标局)或法院来说,他们没办法对Facebook的这样没有为React申请专利的方式来执行任何和专利的诉讼,也就是说,Facebook的这个React License的条款,美国政府是无法在法律上支持的。

第二个问题是专利损害。就算是Facebook可以评估出来一个合法可执行的专利来保护React,对于专利损害也是很有问题的。作者说他到目前还没有发现一个开源软件被专利侵权的事,就算有这样的案例,也不会是这里说的这个事。作者觉得在这个事上操作起来就是一个笑话。

另外,作者认为,React 专利许可证这个事就是个纸老虎。因为,一方面,这个专利不像电信通讯里的那些专利,你拿不掉。作者认为要从你的代码中把React去掉虽然难,但是也不是什么很难的事,另外,要打这样的专利官司,一般来说,在美国至少要花100-200万美金的费用才能发起诉讼,而要胜诉则需要需要200多万到2000万美金的费用,你觉得你要花多钱才能把React从你的代码库中剔除?肯定比这钱少。

作者还认为,Facebook玩这个事虽然出发点不错,但是感觉并不聪明,从目前的情况看下来,就像他想咬你一口,但却没有牙。

后面,作者还说了一下,转成别的框架会不会有问题?比如:你用Preact/Vue或是你自研的东西?作者说,未必,如果Facebook真的为React注册了专利,比如:React里的组件技术、虚拟DOM渲染技术等等。那么,你用Preact/Vue或是带这样技术的自研的框架,那么,从你使用的第一天就在侵犯Facebook的专利权了。然而,使用React反而不会有这么大的风险,因为Facebook让你免费的用React。作者说,用别的框架的法律风险比用其它替代品的风险更高。

后面,作者也更新了一篇文章 《Using GraphQL? Why Facebook Now Owns You》,意思是,用React可能还好,但是用GraphQL就有问题了。因为找到了GraphQL的专利—— “Graph Query Logic”

后来我查了一下,我发现,React也有个相关的专利—— “Efficient event delegation in browser scripts ”,看上去和虚拟DOM渲染有关。Holy Shit!

好了,用还是不用React我也不知道,总之,这个世界比较复杂,我只是想借这篇文章来学习一下法律上的相关东西,欢迎听到大家的观点。

最后,请允许我调侃一下来结束本文——“不用担心React的许可证问题,因为前端不是一年半就用新的框架重写一次么?”哈哈。

延伸阅读

马克曼听证会 – Markman Hearing

马克曼听证会的一些背景知识,下面的文字来源于《“马克曼听证”制度的由来及启示

与美国专利诉讼的悠长历史相比,1996年才经美国最高法院确立的“马克曼听证”(Markman Hearing,也称为Claim Construction,即权利要求书的解释)无疑是一项年轻的制度。但由于几乎所有的专利侵权诉讼中都会遇到涉案专利权利要求书的解释这一核心问题,且因“马克曼听证”结果往往清楚地预示了案件结果,经“马克曼听证”获得有利结论的一方一旦据此向法庭提起不审即判的动议,专利侵权诉讼往往可就此快速了结,因此该制度的确立成为美国专利诉讼历史上的一件大事。

“马克曼听证”制度的由来

“马克曼听证”制度确立之前,在专利侵权诉讼中的权利要求书解释,通常交由陪审团在对案件事实进行裁决时一并做出,且并不会在诉讼文件上单独就陪审团这一问题的判断进行记录。1991年,马克曼(Markman)先生因认为其拥有的专利号为RE33054的“干洗衣物贮存及追踪控制装置”专利权被Westview公司所侵犯,遂向宾夕法尼亚州东区联邦地方法院提起了专利侵权诉讼。

该专利是用扫描的方式,将客户的衣物编号扫描后输入电脑中做分类标示,并在衣物干洗过程中追踪衣物位置,干洗完成后自动将衣物放回客户固定的存贮位置。被告的产品则是同时运用扫描器和电脑两种方式,将客户干洗衣物的资料存入电脑并显示费用、日期等相关信息。本案陪审团的裁决认为被告装置构成对原告专利权利的侵犯,但该地方法院认为系争专利与被告装置在功能实施上并不一致,遂推翻陪审团的裁决,判决被告不构成侵权。

马克曼不服,于1995年向联邦上诉法院提起上诉,但其上诉理由仅为联邦地方法院错误地解释了陪审团关于专利权利要求书解释中某个词语的涵义。联邦上诉法院在审理该案时,将案件的核心问题定为两个:一是原告对于请求项解释有无权利请求陪审团裁决;二是联邦地方法院是否正确地解释了“Inventory”一词。该院多数法官经审理后认为,权利要求书范围的解释与确定,属于法律问题而非事实问题,因而属于法院权限,而不应交由陪审团决定,且此前将此问题交由陪审团确定并不妥当。同时,由于认为原告专利与被告装置存在实质功能上的差异,联邦上诉法院亦不认为被告构成专利侵权。少数持不同意见的该院法官主要是质疑这一结论违反了美国第七宪法修正案(即所有根据美国法律进行的普通法诉讼,只要争议金额超过20美元,即有要求陪审团审判的权利)。

马克曼不服,向最高法院提出上诉。1996年4月23日,美国最高法院就马克曼诉Westview器械公司案(Markman v. Westview Instruments, Inc. 517 U.S. 370 (1996))做出终审裁决,裁决认定:权利要求书的解释是联邦地区法院法官应当处理的法律问题,而不是应当由陪审团来认定的事实问题,尽管在解释权利要求书的过程中可能会包含一些对于事实问题的解释,且这样做并不违反第七修正案赋予给陪审团的权利。这一裁决标志着“马克曼听证”制度的正式确立。

“马克曼听证”制度的不足

该案判决是美国专利诉讼史上的一个重大转折。“马克曼听证”成为法官专门用于解释专利权利要求的一个经常性听证程序,用以解决专利侵权诉讼的核心问题。由于该听证并非普遍适用,因此,十几年来,联邦民事诉讼规则并未正式对其有任何规定,而是给予法院绝对的自由裁量权。但是,何时可以进行“马克曼听证”?如何进行?是否有必要进行?类似问题在一定程度上困扰了审理专利侵权案件较多的法院。

2001年,加州北区联邦地区法院率先制定了供本法院使用的专利审判专属规则(Patent Local Rules),其中第四部分即为权利要求书的解释程序(Claim Construction Proceddings),对“马克曼听证”的时间、流程、限制及当事人的义务均进行了规定。此后,各州纷纷效仿。目前,乔治亚州北区联邦法院、得克萨斯州东区联邦法院、得克萨斯州南区联邦法院、宾夕法尼亚州西区联邦法院等都制订了书面的“马克曼听证”程序指南。近年来,不断有新的案例在解释与细化着“马克曼听证”,如2006年的Wilson Sporting Goods Co.诉Hillerich & Bradsby Co.案,2005年的Phillips诉AWH Corp.案,2008年的Howmedica Osteonics Corp.诉Wright Medical Technology, Inc.案,这些司法实践大大拓展与丰富了“马克曼听证”使用的实体和程序规则,使之日渐成为美国专利诉讼中一个复杂、完备的司法程序。以至于竟然有人开发了模拟“马克曼听证”程序,只要你愿意,可以下载并训练,以熟悉和确保有真正的权利要求书解释时不会出现不利于自己的问题。

但是,该听证带来的问题也逐渐受到重视。有人质疑说该程序导致专利诉讼费用增加,因为“马克曼听证”通常会单独进行,且程序复杂,因此导致当事人花费大量的时间与精力,更为重要的是,由于40%至60%的联邦地区法院案件会在联邦巡回上诉法院被推翻,因此,花费巨大的“马克曼听证”似乎价值有限。同时,权利要求书的解释要求是不多不少,忠实于技术发明思想与发明事实,但由于地区法院分散,法官的相关技术知识不十分专业,将权利要求书解释这样的问题交给他们,难免会带来一些无法克服的问题。

“马克曼听证”制度的启示

我国民事诉讼中并无陪审团制度,案件的事实问题与法律问题均由法官审理与确定。在专利侵权诉讼中,对于案件中涉及到的技术问题可以通过专家鉴定等方式解决,但并不因此免除法官审理案件的义务,即法律问题的判断归于法官,事实的法律属性判断仍然归于法官。同时,权利要求书的解释在我国的专利侵权诉讼中并不是一个单独的程序,而是合并在案件审理过程中。因此,仅就我国的司法审判而言,“马克曼听证”制度并无直接的借鉴意义。

但是,对于那些已经走出和正在走出国门的企业来说,了解与掌握这一重要的专利诉讼程序却是极其重要的。通领科技集团的积极尝试充分证明了这一点,而且随着这一程序的不断成熟,美国国际贸易法院(ITC)也开始在审理时适用“马克曼听证”制度。所以,知道“马克曼听证”意味着什么,确保所提交的用于解释权利要求的文件确实充分,学会利用“马克曼听证”,无论是对于破解美国的专利诉讼威胁,还是为未来准备有效的法律武器,无疑都非常重要。(知识产权报 作者 魏玮)

 

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——

Related Posts

技术读物

关于我”极客时间“的专栏

不少朋友都知道我在“极客时间”上开了一个收费专栏,这个专栏会开设大约一年的时间,一共会发布104篇文章。现在,我在上面以每周两篇文章的频率已发布了27篇文章了,也就是差不多两个半月的时间。新的一年开始了,写专栏这个事对我来说是第一次,在这个过程中有一些感想,所以,我想在这里说一下这些感受和一些相关的故事,算是一个记录,也算是对我专栏的正式介绍,还希望能得到、大家的喜欢和指点。(当然,CoolShell这边还是会持续更新的) 为什么要开设一个收费专栏 首先,说一下,为什么要开这个收费专栏。 老实说,我一开始根本就不想开收费专栏的,是的,完全不想!主要是有两个原因,一方面是我在创业中,我自然是没有太多的时间,另一方面是,我以前在《为什么我不在微信公众号上写文章》也说过,我觉得知识最好的方式是被检索、讨论、引用、整理、补充和更新。所以,收费这种模式,我感觉并不利于很好的传播。但是,我为什么还干了这么一件事?这事还得从2017年6月份开始说起。 这个月,一共有三家技术社区来找我,都是希望我能去他们那边开收费专栏,其中一家就是“极客邦科技”。对于这三家来说,从一开始我就是以婉拒的姿态回应的。而“极客邦科技”来找我的时候和我说,一周写五篇,写一年,一共260篇。我当时心想,“去你的,当我啥呢,你们真以为技术文章好写啊”?然后,他们问我可以写多少,我说,我现在也就一个月一篇的节奏…… 然后,就开始了时间漫长的拉锯战。极客邦这边一直从6月份和我谈到9月份,完全就是不达目的不罢休的玩法,其间,每当我说一个问题,他们就会想出一个解,我这边不断地制造不能写下去的问题,他们就不断的给出相应的解。我其实是想让他们知难而退,另外,我也不确定这帮人对于这个事有多上心,因为写技术文章是需要非常认真的态度的,所以,我提出了很多比较苛刻的条件,甚至也很直白的直接拒绝,但是他们完全就跟没有听见似的,不断的想新的方法来让我”上床”(对!就是上床,不是上船)。 我说,我最多一个月写2-3篇。他们和我说,我们看过了,你写的都是长文,都在5000字左右,一篇可以拆成上下篇,这样就有6篇左右了,然后,你每个月再来两篇文章,一篇是推荐一些资料或资源,一篇是回答读者的问题。这样就有8篇了,一周就可以发2篇了。 我说,就算是这样,我也没有时间写,我现在创业中,事多得去了,完全没精力投入。然后,他们说,不用你写,我们来帮你写。你去客户那边,叫上我们,你到大会上做分享,叫上我们,你和别人分享,也叫让我们,我们全程录音,然后帮你你整理。然后每周末的时候来找你,和你聊上2个小时。我们把内容做出来,你再精编一下就好了。而且,我们也会帮你分担创业的精力的,我们极客邦/QCon/ArchSummit会帮你的产品做推广、做市场和BD客户…… 我说,就算是这样,我也没时间。他们说,我们还会给你配个编辑,一个不够就配两个,他们会帮你上网查资料,他们都是计算机专业的,一定是懂技术的。不会让你一个人写的。专栏这种事一定是会需要一个小的编辑团队的。 他们还甚至在晚上10点左右跑到我家门口来和我谈。这还没完,我继续刁难他们…… 我说,技术文章相当专业,你们来试试看,于是,我给了一篇极其难读的英文论文,还有一篇技术细节非常晦涩的英文文章,我让他们不要翻译,而是读懂后理解完用自己的话,能够让一般人读懂的话写一下。这两篇文章,就算是对于有多年经验的程序员来说,也是很难读的。结果他们一周后,就搞好了,我读了一下,不算特别好,但是对于他们来说,已经很不错了。 我又说,我的文章中会有好些代码,有数学公式,在手机上怎么排版?阅读体验不行吧。你们还要做音频,我的文章中如果有代码,有图片,有数据公式,你让音频时怎么读?这不行吧。他们说,数学公式可以用LaTeX搞,代码排版会努力排好,同时也提供网页端的浏览。音频会这样搞,会让编辑把代码、数学公式、图片理解完后用别外的话说出来。也就是说,文章要有两个版本,一个是阅读的版本,一个是给音频师的版本。 就这样,这几个月的过程中,我心里面有了一些不一样的感觉。 一方面,我觉得这种“不达目的不罢休”的做法让我欣赏。因为我也在创业,创业的过程中有很多难题,也会遇到很多困难和艰辛。而极客邦他们这样的作法我是非常认可,也是非常佩服的,因为,要是换作我,我可能早放弃去寻找其它人了。但是他们没有,他们一直不断地在穷尽一切方法来说服我写专栏。能这样做的人,我觉得这个社会上少之又少,绝大多数人都是畏难和容易退缩的,所以,感觉可以深入交往和合作。 另外一方面,在整个过程中,我问他们,为什么你们要把这个事做得这么“重”?为什么不做得“轻”一点呢?还要录音频,音频对于技术型的文章里面有一堆坑啊,对于技术文章还有很多无法翻译的英文单词,在计算机的世界里,好多英文单词都是造出来的,音频师怎么读?(后来的确也是这样,我的音频师就把J2EE读成了“J二EE”),他们的编辑也不知道怎么读,就上Youtube上找相关视频看老外是怎么发音的,然后标注好。而且,我的文章有时候写得太快,经常会有一些小错误,文字好改,但是还要改语音。对于这些,我都觉得好重啊,结果他们说,就是要做个“重的”,就是要做一个别人达不到的标杆,让竞争对手望而却步! 对于这两点,是让我很赞的。这样的做事精神和态度让我很佩服,是啊,在Amazon里也常说,要不断地提高标准。而且这让我深入思考了一下,一个事如果想要做好,做到极致,就算再简单的事,也会变成复杂,这个世界上可能并不存在“轻模式”,只要你想做好,再“轻”的事都会变“重”。他们的这些做法,让我有了一种同道中人的感觉,人总是会向比自己强的人或是跟自己比较像的人靠近的。我感觉我在创业路上,就是要和这样的人在一起,面对再难的事,都要想尽一切办法解决之,面对再轻的事,都要花心思用重的模式去做好。 而其它两个来找我做同样的事的公司,却没有让我看到他们有这样把事做成的不服输的决心和态度,真是形成了强烈的反差和对比。 于是,我就这样“从”了!这里要点名一下极客邦的两个人——我叫他们作“双蕾”:司巧蕾 和 郭蕾。(池大大也为极客时间付出了好多,因为大家都认识他了,我就弱化他一下了,嘿嘿) 这个专栏主要会写什么样的内容 这是一个收费专栏,一旦收费了,我的压力也大了,因为你要写的内容就一定要能达到可以收费的价值了,不以再像个人博客一样,想写什么就什么。好在我从2003年开始我就在给好多企业做一些商业化的讲座和培训,也给一些公司做过一些商业的咨询和技术方案,包括在过去两年内帮助过一些公司打单。另外,在过去的10年内,我也在技术、职业和成长上帮助过很多年轻人。这些内容,我都没有完整或是具体地写在CoolShell中,所以,我觉得这些内容是可以放在这个收费专栏的。 此外,我在CoolShell上的文章都是不系统的,是碎片式的,还有一些只是知识,还不是认识。而我过去成长的20年,我的经验和知识已经在某些方面形成了比较完整的体系,而且有一些技术也能看到本质上的东西。所以,我觉得这些东西是可以呈现在这个专栏内的,都是非常有商业价值的,一定是可以帮助到大家的。当然,其中的一些东西,不是初级入门的程序员能够看懂的,需要有一定的工作经验和基础知识。 而在我入行的这20年来,我觉得对于一个企业,一个团队,一个个体的程序员来说,有三件事是密不可分,也是相辅相成的,这三件事就是:技术、发展和管理。每个人,每个团队,每个企业,都需要认真地面对技术,不断地挑战新的技术,并且还要非常认真地发展个人和团队,而这些都需要对自我的管理或是对团队和公司的管理才能更高效的达成。 所以,我的专栏会由这三部份构成: 技术。对于技术方面,我不会写太多关于知识点的东西,因为这些知识点大家可以自行Google可以RTFM。我要写就一定是以体系化的,而且要能直达技术的本质。我入行这20年来,我最擅长的是针对各种大规模的系统,所以,我会有2-3个和分布式系统相关的系列文章,然后,我学过也用过好多编程语言,所以,我也会有一系列的关于编程本质的文章,而我对一些基础知识研究的也比较多,所以,还会有一系列的和基础知识相关的文章。当然,其中还会穿插一些其它的技术文章,比如一些热点事件,还有一些经验之谈,包括,我会把我的《程序员技术练级攻略》在这个专栏里重新再写一遍。这些东西一定会让大家有醍醐灌顶的感觉。 成长。在过去这20年中,我感觉得到,很多人都会非常在意自己的成长。所以,我会分享一堆我亲身经历的,也是我自己实验的一定和个人发展相关的文章。比如,像技术变现啊、如何面试、如何选择新的技术、如何学习、如何管理自己的时间、如何管理自己的老板和工作、如何成为一个Leader……这些东西一定会对大家有用。但是,我这里一定不会有速成的东西。一切都是要花时间和精力的。如果你想要速成,你不应该来订阅我的专栏。 管理。这20年,我觉得做好技术工作,得做好技术的管理工作,只有管理好了软件工程和技术团队,技术才能发挥出最大的潜力。大多数的技术都是管理上的问题。所以,我会写上一系列的和管理相关的文章,管理三个要素,团队、项目和管理者自己。所以,我会从这三个方面写一系列包括,人员招聘、绩效考核、提升士气、解决冲突、面对变化、沟通说服、项目管理、任何排期、会议、远程管理……等等一系列的文章。这些东西都是我在外企时,接受到的世界顶级管理培训机构培训内容,我会把我的实践写出来分享给大家。这其中一定少不了亚马逊相关的各种实践。这些东西,我和很多公司和大佬都讲过,到目前为止还没有人不赞的。 现在,我这个专栏写了快三个月了,第一部分和第二部分已经有一些呈现了。我周末和假期的时间也完全都搭进去了 ;-)。后面的文章还在和我的编辑一起在整理和书写中,我感觉这个专栏只收199一年简直是太便宜了,我有点想涨价的冲动了。哈哈。 幕后团队 最后说一下我的专栏编辑——她叫杨爽!以前是CSDN的程序员杂志的编辑,后来去了七牛,现在和我一起做我的这个专栏。她对我的这个专栏上的投入非常大,除了帮助我编辑文章,还要帮音频师标注语气,英文发音,以及音频版的文章,还要深度参与写作,有的文章我只给了一个大纲,甚至只是一个方向,或是一系列的素材,然后都是她来操刀的,比如“推荐阅读”的文章、还有技术领导力的下篇,基本上是由杨爽来出第一版,然后我再上面再做修改和补充。她说,写技术文章真是太累了,尤其是帮你编辑你的分布式系列的文章,我基本都把这些技术都看了个大概了。我调侃到,如果你完全搞懂了,你就不用做编辑了,你可以做技术去了,嗯,而且,可以变成架构师了。 另外,她会深度的编辑我的文章,尤其是每篇文章最后的一些总结或是一些问题都是她写的。在我的一篇答疑的文章中,她自己加入了一个观点——“很多事情能做到什么程度,其实在思想的源头就被决定了,因为它会绝大程度地受到思考问题出发点、思维方式、格局观、价值观等因素的影响”,这个观点被读者当成是我的观点,其实,这是杨爽的观点,当然我也很同意。 所以,我的这个专栏离不开杨爽的付出,我和她一般都是在晚上或是周末沟通,因为平时我的时候都被创业的事给占据了。所以,她也只能适配我的时间,但她真的很努力,我能感觉得到她想把文章的质量不断提高的迫切。 关于专栏的音频师,他叫柴巍,是天津广播电台的主持人,一个89年的小伙子,网上他的个人信息在这里。他跨界来读这些技术文章的确对他来说非常不容易,因为一方面这文章里讲的这些东西他都看不懂,另外,他也不认识我,我脾气和性格他不知道,所以,他读我的文章里,并不能完全准确地把握相关的语气。这就需要杨爽来帮他标注和调整,有些地方,不断地修改,不断地录,大家知道,录音和写文章不一样,文章要修改很简单,语音要修改就非常麻烦,得把上下文全都一并重新再读一篇,这个过程的确难,杨爽在其中也花费了大量的时间和这个小伙子沟通和调整。 Read more…

Facebook

Docusaurus – 5 分钟为开源项目创建一个静态网站,文档、API 一应俱全

Docusaurus 是 Faecbook 专门为开源项目开发者提供的一款易于维护的静态网站创建工具,使用 Markdown 即可更新网站。青小蛙实验了一下,构建一个带有主页、文档、API、帮助 以及博客页面的静态网站,真的没用上 5 分钟。@Appinn 来自微博好友 @Easy 同学的推荐: FB 搞了一个专门给开源项目架网站用的 docusaurus ,用 Markdown 写,生成静态网站,可以发布到 GitHub pages。logo 还挺萌的。 说了只需要五分钟,那么来看一下怎么个 5 分钟大法: 首先,去 Vultr (此链接带返利) 开一台最便宜的 VPS,目前只有 5 刀款了,青小蛙幸运的开到了可用的日本服务器(Ubuntu)。 然后安装 npm,这里青小蛙走了弯路,因为 apt install Read more…

HTTP

如何免费的让网站启用HTTPS

今天,我把CoolShell变成https的安全访问了。我承认这件事有点晚了,因为之前的HTTP的问题也有网友告诉我,被国内的电信运营商在访问我的网站时加入了一些弹窗广告。另外,HTTP的网站在搜索引擎中的rank会更低。所以,这事早就应该干了。现在用HTTP访问CoolShell会被得到一个 301 的HTTPS的跳转。下面我分享一下启用HTTPS的过程。 我用的是 Let’s Encrypt这个免费的解决方案。Let’s Encrypt 是一个于2015年推出的数字证书认证机构,将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程,为安全网站提供免费的SSL/TLS证书。这是由互联网安全研究小组(ISRG – Internet Security Research Group,一个公益组织)提供的服务。主要赞助商包括电子前哨基金会,Mozilla基金会,Akamai以及Cisco等公司(赞助商列表)。 2015年6月,Let’s Encrypt得到了一个存储在硬件安全模块中的离线的RSA根证书。这个由IdenTrust证书签发机构交叉签名的根证书被用于签署两个证书。其中一个就是用于签发请求的证书,另一个则是保存在本地的证书,这个证书用于在上一个证书出问题时作备份证书之用。因为IdenTrust的CA根证书目前已被预置于主流浏览器中,所以Let’s Encrypt签发的证书可以从项目开始就被识别并接受,甚至当用户的浏览器中没有信任ISRG的根证书时也可以。 以上介绍文字来自 Wikipedia 的 Let’s Encrypt 词条。 为你的网站来安装一个证书十分简单,只需要使用电子子前哨基金会EFF的 Certbot,就可以完成。 1)首先,打开 https://certbot.eff.org 网页。 2)在那个机器上图标下面,你需要选择一下你用的 Web 接入软件 和你的 操作系统。比如,我选的,nginx 和 Ubuntu 14.04 3)然后就会跳转到一个安装教程网页。你就照着做一遍就好了。 以Coolshell.cn为例 Read more…