分类 观点 下的文章

这几天,开源界就 RMS 重返 FSF 形成了一场大辩论,有人因为 RMS 本人的一些言论和观点而 反对 他重新回到 FSF 董事会,相应的,也有一些人基于 RMS 的既往贡献和对言论自由的保护而 支持 他重返。

我个人一直以来是以敬仰和尊敬的态度来看待 RMS 的,也积极支持 RMS 重返他创立的 FSF。但是在我公开表明了“支持”的态度后,经过读者反馈,我发现 RMS 在其 博客 上发表的一些言论是充满偏见和误解的。

我对引发 RMS 辞职和重返 FSF 后受到的抗议的 原因,并没有强烈的倾向性观点。但是,在了解了 RMS 近年来关于中国的部分言论存在偏见,作为一名中国人,以我所了解的信息事实,有些观点和偏见是我无法接受的。虽然 RMS 曾多次来访中国,但我认为 RMS 至少在部分信息上存在严重缺失,并基于此有重大偏见。因此,我不会再继续支持他,并从支持 RMS 的公开信中撤销了签名,由此引发了一点关注,这也是我写这封说明的原因。

另外一方面,鉴于 RMS 对自由软件运动的巨大贡献,为如今的自由及开源软件的蓬勃发展奠定了坚实的基础,其创立的 FSF 也发挥了重要的作用,因此,我也不会反对他返回 FSF。

所以,我对 RMS 重返 FSF 这件事持既不反对、也不支持的态度

wxy@Linux 中国

2021/3/28

2022 年 SD-WAN 市场 40% 的同比增长主要来自于包括 Cisco、VMWare、Juniper 和 Arista 在内的网络供应商和包括 AWS、Microsoft Azure,Google Anthos 和 IBM RedHat 在内的服务提供商之间的紧密联系。

越来越多的云应用,以及越来越完善的网络安全性、可视化特性和可管理性,正以惊人的速度推动企业 软件定义广域网 software-defined WAN SD-WAN)的部署。

IDC(LCTT 译注:International Data Corporation)公司的网络基础架构副总裁 Rohit Mehra 表示,根据 IDC 的研究,过去一年中,特别是软件和基础设施即服务(SaaS 和 IaaS)产品推动了 SD-WAN 的实施。

例如,IDC 表示,根据其最近的客户调查结果,有 95% 的客户将在两年内使用 SD-WAN 技术,而 42% 的客户已经部署了它。IDC 还表示,到 2022 年,SD-WAN 基础设施市场将达到 45 亿美元,此后每年将以每年 40% 的速度增长。

“SD-WAN 的增长是一个广泛的趋势,很大程度上是由企业希望优化远程站点的云连接性的需求推动的。” Mehra 说。

思科最近撰文称,多云网络的发展正在促使许多企业改组其网络,以更好地使用 SD-WAN 技术。SD-WAN 对于采用云服务的企业至关重要,它是园区网、分支机构、物联网数据中心 和云之间的连接中间件。思科公司表示,根据调查,平均每个思科的企业客户有 30 个付费的 SaaS 应用程序,而他们实际使用的 SaaS 应用会更多——在某些情况下甚至超过 100 种。

这种趋势的部分原因是由网络供应商(例如 Cisco、VMware、Juniper、Arista 等)(LCTT 译注:这里的网络供应商指的是提供硬件或软件并可按需组网的厂商)与服务提供商(例如 Amazon AWS、Microsoft Azure、Google Anthos 和 IBM RedHat 等)建立的关系推动的。

去年 12 月,AWS 为其云产品发布了关键服务,其中包括诸如 AWS Transit Gateway 等新集成技术的关键服务,这标志着 SD-WAN 与多云场景关系的日益重要。使用 AWS Transit Gateway 技术,客户可以将 AWS 中的 VPC( 虚拟私有云 Virtual Private Cloud )和其自有网络均连接到相同的网关。Aruba、Aviatrix Cisco、Citrix Systems、Silver Peak 和 Versa 已经宣布支持该技术,这将简化和增强这些公司的 SD-WAN 产品与 AWS 云服务的集成服务的性能和表现。

Mehra 说,展望未来,对云应用的友好兼容和完善的性能监控等增值功能将是 SD-WAN 部署的关键部分。

随着 SD-WAN 与云的关系不断发展,SD-WAN 对集成安全功能的需求也在不断增长。

Mehra 说,SD-WAN 产品集成安全性的方式比以往单独打包的广域网安全软件或服务要好得多。SD-WAN 是一个更加敏捷的安全环境。SD-WAN 公认的主要组成部分包括安全功能,数据分析功能和广域网优化功能等,其中安全功能则是下一代 SD-WAN 解决方案的首要需求。

Mehra 说,企业将越来越少地关注仅解决某个具体问题的 SD-WAN 解决方案,而将青睐于能够解决更广泛的网络管理和安全需求的 SD-WAN 平台。他们将寻找可以与他们的 IT 基础设施(包括企业数据中心网络、企业园区局域网、公有云 资源等)集成更紧密的 SD-WAN 平台。他说,企业将寻求无缝融合的安全服务,并希望有其他各种功能的支持,例如可视化、数据分析和统一通信功能。

“随着客户不断将其基础设施与软件集成在一起,他们可以做更多的事情,例如根据其局域网和广域网上的用户、设备或应用程序的需求,实现一致的管理和安全策略,并最终获得更好的整体使用体验。” Mehra 说。

一个新兴趋势是 SD-WAN 产品包需要支持 SD-branch 技术。 Mehra 说,超过 70% 的 IDC 受调查客户希望在明年使用 SD-Branch。在最近几周,JuniperAruba 公司已经优化了 SD-branch 产品,这一趋势预计将在今年持续下去。

SD-Branch 技术建立在 SD-WAN 的概念和支持的基础上,但更专注于满足分支机构中局域网的组网和管理需求。展望未来,SD-Branch 如何与其他技术集成,例如数据分析、音视频、统一通信等,将成为该技术的主要驱动力。


via: https://www.networkworld.com/article/3527194/multicloud-security-integration-drive-massive-sd-wan-adoption.html

作者:Michael Cooney 选题:lujun9972 译者:cooljelly 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽(Red Hat)精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客《代码英雄》第四季(1):小型机 —— 旧机器的灵魂音频脚本。

导语:它们不适合放在你的口袋里。但在当时, 小型机 minicomputer 比之前的房间大小的 大型机 mainframe 的尺寸小了一个数量级。它们为可以装进包里的 个人电脑 Personal Computer (PC),以及最终你口袋里的手机铺平了道路。

16 位小型机改变了 20 世纪 70 年代的 IT 世界。他们让公司的每个工程师都有机会拥有自己的计算机。但这还不够,直到 32 位版本的到来。

Carl Alsing 和 Jim Guyer 讲述了他们在 数据通用 Data General 公司创造革命性的新 32 位计算机的工作。但他们如今被视作传奇的工作是在秘密中完成的。他们的机器代号为 “Eagle”,其设计目的是为了与自己公司的另一个团队正在制造的机器竞争。这些工程师们回忆了为使项目继续进行而做的公司政治和阴谋,以及他们如何将限制转化为优势。Neal Firth 则讨论了如何在一个令人兴奋但要求很高的项目中的生活。在这个项目中,代码英雄们一起工作,只是因为他们想这样做,而不是期望获奖或成名。这三个人都讨论了这个故事如何在 Tracy Kidder 的非虚构工程经典《 新机器的灵魂 The Soul of a New Machine 》中所成就的不朽。

00:00:03 - Saron Yitbarek

那是 1978 年,小型机业界激战正酣。就在一年前, 数字设备公司 Digital Equipment Corporation (DEC)发布了其 32 位的 VAX 11 780 计算机。它比市面上的 16 位机器要强大得多。 VAX 的销售迅速地超越了那些步履缓慢的竞争对手。其主要竞争对手 数据通用 Data General 公司迫切需要一台新机器来和 VAX 竞争。他们需要一台属于自己的 32 位计算机,而且要够快才行,但数据通用公司和 DEC 之间的竞争并不是唯一的战斗。数据通用公司内部还正酝酿一场地盘争夺战,而这两场战斗的战利品都是在令人难以置信的环境下创造令人难以置信的机器。一台 13 英寸的笔记本电脑大概有 3 磅重。如今,我们认为计算机的便携性及方便的尺寸是理所应当的,但是在 20 世纪 70 年代,大多数计算机仍然有着整个机房大小的大型机、重达数吨,而且价值数百万美金。而当硬件成本急剧下降后,开发更小、更快、更便宜的机器的竞争就开始了。小型机为工程师和科学家打开了拥有自己的终端机的大门。正是小型机引领我们到了今天的样子。

00:01:37

在上一季的《代码英雄》中,我们深入探究了对软件开发至关重要的领域 —— 编程语言的世界。诸如 JavaScript、Python 和 C、Perl、COBOL 以及 Go 之类的语言,我们审视了它们的历史、它们所解决的问题,以及它们是怎样随着时间推移而演变的。在这一季中,也就是第四季,我们将再一次深入探索,这一次是我们软件运行于其上的硬件。我们将为大家讲述七个特别的故事,讲述那些敢于改变硬件规则的人和团队。你桌上的笔记本电脑、口袋里的手机,如今你所拥有的每一件硬件设备,以及它们的前代产品,都是代码英雄们全身心投入的结果。他们的激情打造、他们的大胆举动,让我们的硬件成为现实,彻底改变了我们现如今的编程方式。

00:02:36

我是 Saron Yitbarek。这里是代码英雄,一档来自 红帽 Red Hat 的原创播客节目。

00:02:45

在我们本季的首播中,将讲述一个工程团队竞相设计、调试和交付下一代计算机的故事。他们工作的故事变成了 1981 年 Tracy Kidder 获得了普利策奖的畅销书《 新机器的灵魂 The Soul of a New Machine 》的主题。在这本书中讲述了这一集中你将听到的众多嘉宾的故事。

00:03:07

让我们说回到数据通用公司。该公司主席 Ed de Castro 制定了与 DEC 竞争的计划。他拆分了工程部门,将一支团队从其位于 马萨诸塞州 Massachusetts 韦斯特伯勒 Westborough 的总部迁移到了 北卡罗来那州 North Carolina 的新办公室。他们的任务是开发一款领先的 32 位的机器设计,以粉碎 VAX。他们将项目命名为 “Fountainhead”。Ed de Castro 为这支团队提供了几乎无限的支持和资源,他将 Fountainhead 视为他公司的救星。而剩下的几名工程师被留在了马萨诸塞州,他们觉得自己被严重轻视了。他们认为自己能够开发一个干掉 VAX 的杀手,可能会比 Fountainhead 项目所能开发的更好,但是 Ed de Castro 不会给他们机会。因此,这个小组的负责人 Tom West 决定自己动手。Tom West 是一名自学成才的计算机工程师,他负责数据通用公司的 Eclipse 部门。 Eclipse 是数据通用公司最成功的 16 位小型机产品线。Tom 能造机器,也能卖货,而且他知道市场需求是什么。Fountainhead 项目成立以后,Ed de Castro 让剩下的工程师们继续致力于优化去年的产品线。 而 Tom 和其他人都对此不以为然。

00:04:31 - Carl Alsing

我们对此一点都不满意。我们中有些人离开去做其他工作,而另一些人则感到十分沮丧,担心自己的事业,而且感觉没意思。而且我们觉得另一组人肯定会失败。

00:04:46 - Saron Yitbarek

Carl Alsing 是数据通用公司微编程小组的经理。他是 Tom 的副手。他们决定提出自己的项目计划。

00:04:56 - Carl Alsing

这将是使用最新技术进行的全新设计,构建一个能够击败 DEC 的 VAX 的 32 位计算机。所以我们为此提出了一项建议,并去找了主席 Ed de Castro,他说:“不,没门儿。北卡罗来那州的小组在负责这项工作。你们不必操心。”因此,我们感到十分灰心,回去提出了另一个名为 Victor 的计划。我们研究了如何使去年的老产品更好的方法。我们在里面设置了一个小开关,即系统里的一个模式位,当你打开它时,它将使得计算机能够像现代 32 位小型机一样运行,尽管比较慢。然后我们向 Ed de Castro 提出了这个功能。最后他说:“你们在这里有个模式位。我不想再看到其他任何带有模式位的设计。北卡罗来那州那边正在负责新设计。”于是乎又一次,我们深感沮丧,我想就是在那会儿 Tom West 决定要做一些秘密的事情。

00:06:06 - Saron Yitbarek

Tom 想出了两个故事。一个是讲给 Ed de Castro 的:他们将会对旧的 Eclipse 产品线进行加强,使它运行得更快一点,增加几个新按钮,并且换个新颜色。Tom 把它说成保险措施,以防万一北卡罗来那州那边出了什么问题。Ed de Castro 同意了。然后 Tom 给他的团队讲了另一个更棒的故事。

00:06:32 - Carl Alsing

Tom West 向我们团队中的一些人提议,我们要开发一款真正优秀的现代机器,它对以前的机器完全兼容,并且采用我们所需的所有最新高科技的东西,有虚拟内存、32 位和纠错代码,以及所有这类东西:多任务、多处理、大量内存。“伙计们,我们将打造出最新的、能在市场上大杀四方的新机器。”

00:07:04 - Saron Yitbarek

这款极具市场杀伤力的新机器的代号是 “Eagle”。现如今,人们觉得我们的电脑中的内存是没有任何限制的,但是在那时候,当从 16 位转换到 32 位时,发生了重大的突破。突然之间,你的地址空间就从能够存储 65000 字节的信息变成了 40 多亿字节。随着这一增长,软件也可以处理更加大量的数据。这给计算机公司带来了两个基本的挑战:从 16 位过渡到 32 位,这是肯定的,但是他们还得让使用旧软件的老客户感到满意。因此,他们必须得开发一款能够让旧软件继续运行的机器,即一款向后兼容的 32 位计算机。VAX 尽其所能也没有找到第二个问题的完美解决方案,但是 Tom 坚信他的 Eagle 可以做到。

00:08:14

Eagle 的总部位于韦斯特伯勒 14 号楼 AB 的地下室。Tom 指派 Carl 负责 微码 micro coding 。Carl 指派 Chuck Holland 来管理 编码员 coder ,他们被称为 微码小子 Micro Kids 。同时,Ed Rasala 将负责硬件。他委派了 Ken Holberger 负责管理团队,这个团队被恰当地称为 哈迪男孩 Hardy Boys 。(LCTT 译注:《哈迪男孩》是一部 1977 年的美国电视剧。) Tom 有一个盟友,就是工程副总裁 Carl Carman。 Carman 也对 Ed de Castro 有意见,因为 Ed de Castro 拒绝让他来负责北卡罗来那州的小组。

00:08:51 - Carl Alsing

Carl Carman 知道我们在干什么,却什么都没有对他的老板说。所以他给我们提供了资金,但我们需要保持较低的薪水,并且需要一些非常聪明的工程师。因此,我们决定去招收大学毕业生。这样做的好处之一是他们不知道什么是你做不到的。他们以为你无所不能。

00:09:15 - Saron Yitbarek

那时 Jim Guyer 刚从大学毕业两年,在数据通用公司工作时被分派到了哈迪男孩。

00:09:21 - Jim Guyer

北卡罗来那州那边正在开发的机器更多是高端计算,本质上几乎是大型机。而且,嗯,我的意思是,这在当时确实是投入到与 IBM 以及其他大型机公司的竞争中去的相当重要的一步。我们认为我们有优势,因为我们想做的事情并不那么雄心勃勃,而且我们真的、真的专注于一种简洁、干净、简单的实现方案,用最低的成本、最少的组件等等。

00:09:51 - Saron Yitbarek

成本低廉,设计简单。他们意识到他们需要使用 固件 firmware 来控制一切。与硬件相比,把越多的功能置于固件控制之下,所开发的机器就越便宜、越灵活。

00:10:03

而且它们能够根据需求进行修改。当然,现代计算机都是以这种方式构建而成的,但在 1978 年,这种方法是全新的。

00:10:15 - Carl Alsing

我们所做的设计非常简约。我们正在研究能够使事情简单明了的方法。因为我们知道,它不可能变成一个庞大而又昂贵的机器。它必须只是几块板子、几个电路,这是让使它快速发展的一个优势。设计一款安全的、无风险的产品,和设计一款用于制胜的产品是有区别的。而我们并不担心风险,我们在意的是取胜。我们希望它既快速又便宜,我们希望快速地开发它。因此,我们只用了三、四块板子,这是最低限度的硬件,我们通过固件来弥补这些。

00:11:06 - Saron Yitbarek

Eagle 团队面临着很多严苛的限制。 VAX 是这个星球上(当时)性能最高的 32 位计算机。 Eagle 必须与之匹敌。但最重要的是,它还必须兼容他们的 16 位架构。要用比其他团队更少的金钱和时间来做到所有这一切,这使得 Eagle 感觉像是在赌博。但 Tom West 的团队全力以赴投身于其中。

00:11:32 - Jim Guyer

有两套无时无刻都在运行着的系统,我们有两班工程师为之工作。我们所有人都必须全盘掌握。因此,我们不得不学会其他每一个人的岗位所要做的工作。这对我而言既具有挑战性又极其富有教育意义。但是我们大家都参与其中努力着,“要解决这个问题下一步该做什么?我们需要着眼于何处?”每个人都仔细钻研原理图和其他文档,试图找出办法,“看看这个信号,看看那台计算机的状态,看看微码正在执行的步骤顺序。它在正常运转吗?哦等等,它出错了。呃,为什么它会这样运行呢?”

00:12:13 - Carl Alsing

这是件严肃的事情,这就是工作态度。小组里的工作很紧张。有时候人们会对于采用何种方式去做某件事情而发生争论。可能有一种方法会花费稍微多一点的钱,而另一种方法则更便宜,但是可能速度稍慢或效率稍低。为了达成共识,可能会开展激烈的讨论或会议。但我们还是做出了这些选择,然后我们协作努力。

00:12:44

我们没日没夜地工作,在 原型 prototype 上付出了很多时间。我们只有两个原型,两个团队都能在这两个原型上工作着实很重要。因此,晚班和白班都有人在工作,人们都很疲惫,但这让人感到非常兴奋 —— 这是值得的。所以没有人过多地抱怨工作条件。

00:13:11 - Saron Yitbarek

工作条件 —— 据传当时 Tom West 为了让团队完成他所期望的东西,实行了一种被称为“ 蘑菇管理 mushroom management ”的方法。喂养它们然后看着它们成长。在狭窄而炎热的工作空间里,时间很漫长,日程安排也不切实际。Tom 本人被形容为神秘、冷酷、无情的人。有位工程师甚至称他为“ 黑暗王子 the Prince of Darkness ”。 Tom West 是否如此渴望取胜以至于剥削了他的团队吗?他是否为了得到完美的机器而牺牲了微码小子们和哈迪男孩们的福祉?

00:13:56 - Jim Guyer

Tom 是个有趣的家伙。他对你期望很高,但不会给你很多指导。他希望你可以自己弄清楚需要做什么,而如果你不能做到的话,你就会被踢出团队。

00:14:10 - Saron Yitbarek

指导来自于 Carl 或是 Ed, 他们是 Jim 和团队其他成员每天都与之工作的部门经理。但这些年轻的工程师也为了取胜而参与其中,他们喜欢自己所获得的机会,愿意自己去搞清楚。

00:14:26 - Jim Guyer

我个人获得了第一届微码小子通宵荣誉奖。我不知道是什么理由,也许我们都是能力超群、豪气冲天、无知无畏的年轻后浪。我们很自信,我们觉得自己相当聪明,可以解决问题,我们相互依靠,也许这就是自负。我乐在其中。我认为我们大部分人都乐在其中。

00:14:56 - Saron Yitbarek

Carl 不同意“蘑菇管理”这一说法。他说情况恰恰相反。他们都确切地知道正在发生什么,以及预期是什么。反而是高层管理人员不知道。同时,Tom West 正在承受着来自多条战线的巨大压力,而这种压力也传递给了他的团队。

00:15:18 - Carl Alsing

Tom 对这个项目的真实性质保持着低调。因此,他并没有对工程师们说很多,他保持着超然的态度,当然他也告诉他们,他们不能在团队之外或是家中讨论该项目。甚至不能使用 “Eagle” 一词。因此,我们还传达了这个项目非常紧急,我们必须在一年之内完成,竞争已在市场中展开,如果我们要通过这个东西来占据市场之巅,我们必须现在就把它完成。因此他们承受着很大的压力,并且团队期望他们在夜晚和周末也参加工作,没有时间留给他们去和家人野餐或是做其他任何与工作不相关的事情。

00:16:06 - Saron Yitbarek

我想知道在 14 号楼 AB 的战壕里奋战是怎样的感受。所以我邀请 Neal Firth 来到身边。他是微码小子中的一员,刚毕业就加入了团队。

00:16:20

和 Tom West 共事的感觉如何?你和他有过很多互动吗?

00:16:24 - Neal Firth

不一定。他是那种幽灵般的人物。我们能看到他在身边。他一般也不会不干预,以便我们能够领导自己、实现目标。我们正在做的事情是全新的,他不想把上一代处理器要做的工作强加给我们。

00:16:49 - Saron Yitbarek

这听起来像是一个工作十分紧张的地方,在这里你真切地想不断前进并完成工作。你是怎样应对没有太多时间这一事实的?

00:16:57 - Neal Firth

老实说,这并不是问题。想要时间充裕实际上并没有什么问题。我们可能会花费一些时间来实现结果。这需要家里人非常支持与理解,因为她们并不一定会立马同意。你可以将其等同于当时的一些硅谷人,或是像 乔布斯 Jobs 沃兹尼亚克 Wozniak 之类的人,我们投身其中并搞定它。我们确实不全是“ 住在同一间公寓 live-in-the-same-apartment ”或“ 在地板上写代码 code-on-the-floor ”那样的人,但具有其中的一些特征。

00:17:35 - Saron Yitbarek

在那段时间里,是什么让你坚持了下来?为什么你这么有动力?

00:17:39 - Neal Firth

坦率地说,就是在解决问题。我一直是一个喜欢思考并善于解决问题的人。事实上,团队里的大部分人都是这样的。我们所有人都有着类似的背景,并且我们都很享受解决问题这件事。就是,解决那些难题,找到一种前所未有的方式去做事。

00:18:01 - Saron Yitbarek

那么在这个项目中,你最难忘的时刻是什么?

00:18:05 - Neal Firth

当时,项目已经进行了相当长的时间,我们正在运行微码模拟器,它实际上是被提议当作生产模拟器来运行的,已经运行了 10 到 12 个小时了。突然,字母 E 出现在了控制台上,然后我们等了一会儿,又是一个字母,接着又是一个字母,然后我们突然意识到我们运行的是测试代码,是正在设计运行的诊断程序。因此,微码模拟器正在模拟运行这份微码的硬件,并且它开始打印字母,就好像它真的在运行一样。所以当它真正问世并运行时,可能比实际上要慢了十万倍,但这仍是我最难忘的时刻之一。

00:19:02 - Saron Yitbarek

现在回过头想想,你觉得自己当时有被剥削吗?

00:19:07 - Neal Firth

没有。我可以意识到正在发生着什么。我知道正在发生什么。所以,没有,我没觉得被剥削。实际上,这是我大学毕业时候的期望,否则我永远都不可能参与这么重大的项目,或是有机会在这样的一个项目中扮演那么重要的角色。

00:19:31 - Saron Yitbarek

我想知道你如何看待发明的牺牲,因为如果你要考虑所有我们所创造的伟大事物,通常来说我们不得不放弃一些东西,是这样吗?必须舍弃一些东西来做出真正惊人的东西。这样的情况你遇到过吗?如果有的话,你不得不放弃的东西是什么呢?

00:19:48 - Neal Firth

我不会说我放弃某些东西是有一个思想驱动的过程,我认为更重要的是,我更能适应自己正在做的事情以及所做的事对周围人的影响。

00:20:03

但我从来没把它看作是一种牺牲,而与我亲近的人们,他们生活在就是这样的一个世界里。我听说过一些可怕的故事,如果你愿意的话,在今天,在这里都是,你醒来,插上你的咖啡机,拿一些披萨或点心,然后你开始写代码,最后你在你的键盘上睡着。然后你在下一个早晨醒来,重复这个过程。

00:20:35

我们当然远没有达到那种牺牲的程度,我仍然有妻子,我仍然有朋友,我们仍然在一起。这当然不是份 朝九晚五 nine-to-five 的工作,但是它给我带来了许多个人层面与技术层面的成就,我能把这些和我的妻子、姐妹、父亲、母亲以及岳父分享,这些人可以欣赏这些。

00:20:59 - Saron Yitbarek

是啊。那么,你认为使某件事情变得真正伟大的关键是什么呢?

00:21:06 - Neal Firth

使某件事情变得真正伟大的关键 —— 有趣的问题 —— 我认为这取决于参与其中的人员,因为他们想要这样做,而不是因为他们对成就、财富或是名望的渴望。因为那些东西都转瞬即逝,而且永远无法使人满足。但是如果你要努力地去实现一个目标,而且你和一群人共同努力并去实现它,那么当你最终实现目标的时候,这确确实实是能令人心满意足的。

00:21:42 - Saron Yitbarek

Neal Firth 是 Eagle 项目中微码小子中的一员。他目前是一家名为 VIZIM Worldwide 的软件公司的总裁。

00:21:57

正如 Tracy Kidder 书中所记载的那样, Tom West 的超然和距离感是刻意为之的。这是他试图在日常交谈中保持头脑清醒,从而能使 Eagle 的目标保持原样。不过更重要的是,他想保护团队,将他们与周遭发生的政治与企业边缘化相隔绝。他也保护了微码小子们和哈迪男孩们不受先入为主的观念影响。

00:22:28

1980 年, Eagle 完成了。比 Tom 所承诺的要晚了一年,但至少还是完成了,不像 Fountainhead。就像资深团队所预料的那样, Fountainhead 团队失败了,他们的项目遭到了搁置。这位是 Bill Foster,当时的软件开发总监,他谈到了 Fountainhead 的挣扎。

00:22:50 - Bill Foster

我认为所犯下的最大错误在于没有对其设置任何限制。或多或少地,就是让我们去开发世界上最好的计算机。嗯,它应该在什么时候被完成?哦,我们对此确实没有个明确的期限。它应该花费多少成本?好吧,我们也不确定。我不得不让 Ed 失望了。他没有在程序员和工程师之间设置足够的界限。

00:23:15

而且如果你让一群程序员和工程师放任自流,猜猜怎么着,他们将使事情变得复杂,设计出过分庞大的东西,以至于永远不能完成。

00:23:26 - Saron Yitbarek

让我们回忆一下。从 Tom 和他的团队决定秘密开发 Eagle 开始,这已经进行了两年了。整个过程中,公司总裁并不知道正在发生了什么。当现在已经正式命名为 Eclipse MV/8000 的这款机器准备交付时,市场营销负责人去找了 Ed de Castro,为营销活动放行。 Carl Alsing 将对此作出解释。

00:23:53 - Carl Alsing

市场营销负责人说道:“好吧,我们已经准备好为 Eagle 进行推广了,我们需要数千美元。我们将在全球六个不同的城市举行新闻发布会。我们将进行一个巡演,去到很多城市,我们将拍摄一部影片来展示它,这将轰动一时。”

00:24:14 - Carl Alsing

然后 Ed de Castro 说:“我不明白。你们为什么要那样做?”这只不过是在 Eclipse 那边的另一个包而已,表面工夫的工作而已。市场经理说:“不,这是一款全新的机器。这是一款 32 位的机器,有虚拟内存,具备兼容性。它将击败 VAX。所有你要的东西都在这里了。”

00:24:37 - Carl Alsing

Ed de Castro 着实有点儿困惑。他以为我们在北卡罗来那州遭遇了失败,将成为事情的终结,但我们拯救了他。因此,是的,他邀请了我们所有人,我们举行了一次小型的午餐会。午餐会上有三明治和苏打水,他说:“嗯,你们做得很好,我很吃惊。我此前并没有意识到你们在做这个,但是我们会推广它,我知道将会安排一部影片、一些巡游,而且你们将成为这其中的一部分,所以,感谢你们,请吃你们的三明治吧。”

00:25:19 - Saron Yitbarek

现如今被命名为 MV/8000 的 Eagle 出现在了《 计算机世界 Computer World 》杂志的封面上。推出期间,媒体的炒作使得这支原本秘密的、深居地下室的团队成员们变成了小名人。毕竟,他们拯救了数据通用公司。

00:25:38

但好景不长。 Tom West 再也无法让团队免受公司内部政治的影响。团队面对敌意毫无准备。公司里的其他人都嫉妒他们的成就,并对他们能在秘密项目中逃离如此之久感到震惊。

00:25:57

不久后,一个新的工程副总裁取代了他们的盟友 Carl Carman。这个新来的人在第一台 MV/8000 被售出之前就拆分了 Eagle 小组,并把 Tom 发配到了数据通用公司的日本办事处。

00:26:13 - Jim Guyer

我认为我们开发出了花钱所能够买到的最好的 32 位超级小型机,我认为这对数据通用公司来说是一件很棒的事情,我认为它将能把 DEC 稍微踢开一点,而不是我们把世界从他们身边夺走。那时候的竞争太艰难了,在高科技领域很难成为赢家,但我认为我们已经做了一些有价值的事情。

00:26:42 - Saron Yitbarek

当 Eagle 发行时,它确实拯救了数据通用公司,但在市场份额被 DEC 夺走三年后,该公司从未真正恢复过来,而行业却发展了。小型机不再是大势所趋。 微型计算机 microcomputer 的竞争已经开始了,这为 个人计算机 personal computer 革命铺平了道路。

00:27:04 - Carl Alsing

数据通用公司继续开发了其他的版本,并在其他的型号上进行了改进,这样进行了一段时间,取得了一些成功。但是世事无常。市场发生了变化,他们自己转型成了一家软件公司,然后最终被其他人收购了。如今,我认为他们在马萨诸塞州 霍普金顿 Hopkinton 某家公司的文件抽屉里。

00:27:36 - Saron Yitbarek

一年后, Eagle 团队中的许多人离开了数据通用公司。有人感到精疲力竭。有些人准备好要去开发一些不一样的东西。一些人前往西部的硅谷,热衷于寻找下一个创意火花。无论如何,在一个不承认他们为拯救公司所做的一切的公司里,继续待下去似乎没有什么意义。1981 那一年 Tracy Kidder 的《 新机器的灵魂 The Soul of a New Machine 》出版了。现如今,全世界都知道 Eagle 是如何构建起来了。

00:28:14 - Carl Alsing

如果你问我新机器的灵魂是什么,我想我会说是他们所经历的人和事,他们所做出的牺牲,他们所做出的努力,他们对此所感到的兴奋,以及他们所希望得到的满足感。也许得到了,也许没有,但他们为之而努力。

00:28:35 - Jim Guyer

从某种意义上说,这款机器是有点儿个性。但真正有个性的是这些有勇气的人。

00:28:47 - Saron Yitbarek

在我们有关硬件的全新一季的下一集里,我们会将时光倒回大型机世界,讲述另一群叛逆员工的故事。他们制造的计算机催生了一门改变世界的编程语言。

00:29:04 - Saron Yitbarek

代码英雄 Command Line Heroes 》是 红帽 Red Hat 的一档原创播客节目。这一季,我们正在为你整理一些出色的研究,以便你可以更多地了解到我们正在谈论的硬件的历史。请前往 redhat.com/commandlineheroes 深入了解 Eagle 及其背后的团队。我是 Saron Yitbarek。下集之前,编码不止。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


via: https://www.redhat.com/en/command-line-heroes/season-4/minicomputers

作者:Red Hat 选题:bestony 译者:JonnieWayy 校对:windgeek, wxy

本文由 LCRH 原创编译,Linux中国 荣誉推出

让我们来看看 OSI 最新批准的加密自治许可证和 CERN 开源硬件许可协议。

 title=

作为 开源定义 Open Source Defintion (OSD)的管理者, 开源促进会 Open Source Initiative (OSI)20 年来一直在批准“开源”许可证。这些许可证是开源软件生态系统的基础,可确保每个人都可以使用、改进和共享软件。当一个许可证获批为“开源”时,是因为 OSI 认为该许可证可以促进相互的协作和共享,从而使得每个参与开源生态的人获益。

在过去的 20 年里,世界发生了翻天覆地的变化。现如今,软件以新的甚至是无法想象的方式在被使用。OSI 已经预料到,曾经被人们所熟知的开源许可证现已无法满足如今的要求。因此,许可证管理者已经加强了工作,为更广泛的用途提交了几个新的许可证。OSI 所面临的挑战是在评估这些新的许可证概念是否会继续推动共享和合作,是否被值得称为“开源”许可证,最终 OSI 批准了一些用于特殊领域的新式许可证。

四个新式许可证

第一个是 加密自治许可证 Cryptographic Autonomy License (CAL)。该许可证是为分布式密码应用程序而设计的。此许可证所解决的问题是,现有的开源许可证无法保证开放性,因为如果没有义务也与其他对等体共享数据,那么一个对等体就有可能损害网络的运行。因此,除了是一个强有力的版权保护许可外,CAL 还包括向第三方提供独立使用和修改软件所需的权限和资料的义务,而不会让第三方有数据或功能的损失。

随着越来越多的人使用加密结构进行点对点共享,那么更多的开发人员发现自己需要诸如 CAL 之类的法律工具也就不足为奇了。 OSI 的两个邮件列表 License-Discuss 和 License-Review 上的社区,讨论了拟议的新开源许可证,并询问了有关此许可证的诸多问题。我们希望由此产生的许可证清晰易懂,并希望对其他开源从业者有所裨益。

接下来是,欧洲核研究组织(CERN)提交的 CERN 开放硬件许可证 Open Hardware Licence (OHL)系列许可证以供审议。它包括三个许可证,其主要用于开放硬件,这是一个与开源软件相似的开源访问领域,但有其自身的挑战和细微差别。硬件和软件之间的界线现已变得相当模糊,因此应用单独的硬件和软件许可证变得越来越困难。欧洲核子研究组织(CERN)制定了一个可以确保硬件和软件自由的许可证。

OSI 可能在开始时就没考虑将开源硬件许可证添加到其开源许可证列表中,但是世界早已发生变革。因此,尽管 CERN 许可证中的措词涵盖了硬件术语,但它也符合 OSI 认可的所有开源软件许可证的条件。

CERN 开源硬件许可证包括一个 宽松许可证、一个 弱互惠许可证 和一个 强互惠许可证。最近,该许可证已被一个国际研究项目采用,该项目正在制造可用于 COVID-19 患者的简单、易于生产的呼吸机。

了解更多

CAL 和 CERN OHL 许可证是针对特殊用途的,并且 OSI 不建议把它们用于其它领域。但是 OSI 想知道这些许可证是否会按预期发展,从而有助于在较新的计算机领域中培育出健壮的开源生态。

可以从 OSI 获得关于 许可证批准过程 的更多信息。


via: https://opensource.com/article/21/2/osi-licenses-cal-cern-ohl

作者:Pam Chestek 选题:lujun9972 译者:wyxplus 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

每个程序员都应该明白的 171 个字。

MIT 许可证 是世界上最流行的开源软件许可证。以下是它的逐行解读。

阅读许可证

如果你参与了开源软件,但还没有花时间从头到尾的阅读过这个许可证(它只有 171 个单词),你需要现在就去读一下。尤其是如果许可证不是你日常每天都会接触的,把任何看起来不对劲或不清楚的地方记下来,然后继续阅读。我会分段、按顺序、加入上下文和注释,把每一个词再重复一遍。但最重要的还是要有个整体概念。

The MIT License (MIT)

Copyright (c)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The Software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the Software.

(LCTT 译注:MIT 许可证并无官方的中文文本,我们也没找到任何可靠的、精确的非官方中文文本。在本文中,我们仅作为参考目的提供一份逐字逐行而没有经过润色的中文翻译文本,但该文本及对其的理解不能作为 MIT 许可证使用,我们也不为此中文翻译文本的使用承担任何责任,这份中文文本,我们贡献给公共领域。)

MIT 许可证(MIT)

版权 (c) <年份> <版权人>

特此免费授予任何获得本软件副本和相关文档文件(下称“软件”)的人不受限制地处置该软件的权利,包括不受限制地使用、复制、修改、合并、发布、分发、转授许可和/或出售该软件副本,以及再授权被配发了本软件的人如上的权利,须在下列条件下:

上述版权声明和本许可声明应包含在该软件的所有副本或实质成分中。

本软件是“如此”提供的,没有任何形式的明示或暗示的保证,包括但不限于对适销性、特定用途的适用性和不侵权的保证。在任何情况下,作者或版权持有人都不对任何索赔、损害或其他责任负责,无论这些追责来自合同、侵权或其它行为中,还是产生于、源于或有关于本软件以及本软件的使用或其它处置。

该许可证分为五段,按照逻辑划分如下:

  • 头部

    • 许可证名称:“MIT 许可证”
    • 版权说明:“版权 (c) …”
  • 许可证授予:“特此授予 …”

    • 授予范围:“… 处置软件 …”
    • 条件:“… 须在 …”

      • 归因和声明:“上述 … 应包含在 …”
      • 免责声明:“本软件是‘如此’提供的 …”
      • 责任限制:“在任何情况下 …”

接下来详细看看。

头部

许可证名称

The MIT License (MIT)
MIT 许可证(MIT)

“MIT 许可证”不是一个单一的许可证,而是根据 麻省理工学院 Massachusetts Institute of Technology (MIT)为发行版本准备的语言衍生出来一系列许可证形式。多年来,无论是对于使用它的原始项目,还是作为其他项目的范本,它经历了许多变化。Fedora 项目一直保持着 收藏 MIT 许可证的好奇心,以纯文本的方式记录了那些平淡的变化,如同泡在甲醛中的解剖标本一般,追溯了它的各种演变。

幸运的是, 开放源码倡议组织 Open Source Initiative (OSI) 和 软件数据包交换 Software Package Data eXchange 组织(SPDX)已经将一种通用的 MIT 式的许可证形式标准化为“ MIT 许可证 The MIT License ”。OSI 反过来又采用了 SPDX 通用开源许可证的标准化 字符串标志符,并将其中的 “MIT” 明确指向了标准化形式的“MIT 许可证”。如果你想为一个新项目使用 MIT 式的条款,请使用其 标准化的形式

即使你在 LICENSE 文件中包含 “The MIT License” 或 “SPDX:MIT”,任何负责的审查者仍会将文本与标准格式进行比较,以确保安全。尽管自称为“MIT 许可证”的各种许可证形式只在细微的细节上有所不同,但所谓的“MIT 许可证”的松散性已经诱使了一些作者加入麻烦的“自定义”。典型的糟糕、不好的、非常坏的例子是 JSON 许可证,一个 MIT 家族的许可证被加上了“本软件应用于善,而非恶”。这件事情可能是“非常克罗克福特”的(LCTT 译者注,Crockford 是 JSON 格式和 JSON.org 的作者)。这绝对是一件麻烦事,也许这个玩笑本来是开在律师身上的,但他们却笑得前仰后合。

这个故事的寓意是:“MIT 许可证”本身就是模棱两可的。大家可能很清楚你的意思,但你只需要把标准的 MIT 许可证文本复制到你的项目中,就可以节省每个人的时间。如果使用元数据(如包管理器中的元数据文件)来指定 “MIT 许可证”,请确保 LICENSE 文件和任何头部的注释都使用标准的许可证文本。所有的这些都可以 自动化完成

版权声明

Copyright (c)
版权 (c) <年份> <版权持有人>

在 1976 年(美国)《版权法》颁布之前,美国的版权法规要求采取具体的行动,即所谓的“手续”来确保创意作品的版权。如果你不遵守这些手续,你起诉他人未经授权使用你的作品的权力就会受到限制,往往会完全丧失权力,其中一项手续就是“ 声明 notice ”。在你的作品上打上记号,以其他方式让市场知道你拥有版权。“©” 是一个标准符号,用于标记受版权保护的作品,以发出版权声明。ASCII 字符集没有 © 符号,但 Copyright (c) 可以表达同样的意思。

1976 年的《版权法》“落实”了国际《 伯尔尼公约 Berne Convention 》的许多要求,取消了确保版权的手续。至少在美国,著作权人在起诉侵权之前,仍然需要对自己的版权作品进行登记,如果在侵权行为开始之前进行登记,可能会获得更高的赔偿。但在实践中,很多人在对某个人提起诉讼之前,都会先注册版权。你并不会因为没有在上面贴上声明、注册它、向国会图书馆寄送副本等而失去版权。

即使版权声明不像过去那样绝对必要,但它们仍然有很多用处。说明作品的创作年份和版权属于谁,可以让人知道作品的版权何时到期,从而使作品纳入公共领域。作者或作者们的身份也很有用。美国法律对个人作者和“公司”作者的版权条款的计算方式不同。特别是在商业用途中,公司在使用已知竞争对手的软件时,可能也要三思而行,即使许可条款给予了非常慷慨的许可。如果你希望别人看到你的作品并想从你这里获得许可,版权声明可以很好地起到归属作用。

至于“ 版权持有人 copyright holder ”。并非所有标准形式的许可证都有写明这一点的空间。最新的许可证形式,如 Apache 2.0GPL 3.0,发布的许可证文本是要逐字复制的,并在其他地方加上标题注释和单独文件,以表明谁拥有版权并提供许可证。这些办法巧妙地阻止了对“标准”文本的意外或故意的修改。这还使自动许可证识别更加可靠。

MIT 许可证是从为机构发布的代码而写的语言演变而来。对于机构发布的代码,只有一个明确的“版权持有人”,即发布代码的机构。其他机构抄袭了这些许可证,用他们自己的名字代替了 “MIT”,最终形成了我们现在拥有的通用形式。这一过程同样适用于该时代的其他简短的机构许可证,特别是加州大学伯克利分校的最初的 四条款 BSD 许可证 four-clause BSD License 成为了现在使用的 三条款两条款 变体,以及 MIT 许可证的变体 互联网系统联盟 Internet Systems Consortium ISC 许可证

在每一种情况下,该机构都根据版权所有权规则将自己列为版权持有人,这些规则称为“雇佣作品”规则,这些规则赋予雇主和客户在其雇员和承包商代表其从事的某些工作中的版权所有权。这些规则通常不适用于自愿提交代码的分布式协作者。这给项目监管型基金会(如 Apache 基金会和 Eclipse 基金会)带来了一个问题,因为它们接受来自更多不同的贡献者的贡献。到目前为止,通常的基础方法是使用一个单一的许可证,它规定了一个版权持有者,如 Apache 2.0EPL 1.0,并由 贡献者许可协议 contributor license agreements Apache CLA 以及 Eclipse CLA 为后盾,以从贡献者中收集权利。在像 GPL 这样的 左版 copyleft 许可证下,将版权所有权收集在一个地方就更加重要了,因为 GPL 依靠版权所有者来执行许可证条件,以促进软件自由的价值。

如今,大量没有机构或商业管理人的项目都在使用 MIT 风格的许可条款。SPDX 和 OSI 通过标准化不涉及特定实体或机构版权持有人的 MIT 和 ISC 之类的许可证形式,为这些用例提供了帮助。有了这些许可证形式,项目作者的普遍做法是在许可证的版权声明中尽早填上自己的名字...也许还会在这里或那里填上年份。至少根据美国的版权法,由此产生的版权声明并不能说明全部情况。

软件的原始所有者保留其工作的所有权。但是,尽管 MIT 风格的许可条款赋予了他人开发和更改软件的权利,创造了法律上所谓的“衍生作品”,但它们并没有赋予原始作者对他人的贡献的所有权。相反,每个贡献者在以现有代码为起点所做的任何作品都拥有版权,即使是稍做了一点创意

这些项目大多数也对接受 贡献者许可协议 contributor license agreements (CLA)的想法嗤之以鼻,更不用说签署版权转让协议了。这既幼稚又可以理解。尽管一些较新的开源开发人员认为,在 GitHub 上发送 拉取请求 Pull Request ,就会“自动”根据项目现有的许可证条款授权分发贡献,但美国法律不承认任何此类规则。强有力的版权保护是默认的,而不是宽松许可。

更新:GitHub 后来修改了全站的服务条款,包括试图至少在 GitHub.com 上改变这一默认值。我在 另一篇文章 中写了一些对这一发展的想法,并非所有想法都是积极的。

为了填补法律上有效的、有据可查的贡献权利授予与完全没有纸质痕迹之间的差距,一些项目采用了 开发者原创证书 Developer Certificate of Origin ,这是贡献者在 Git 提交中使用 Signed-Off-By 元数据标签暗示的标准声明。开发者原创证书是在臭名昭著的 SCO 诉讼之后为 Linux 内核开发而开发的,该诉讼称 Linux 的大部分代码源自 SCO 拥有的 Unix 源代码。作为创建显示 Linux 的每一行都来自贡献者的书面记录的一种方法,开发者原创证书的功能良好。尽管开发者原创证书不是许可证,但它确实提供了大量证据,证明提交代码的人希望项目分发其代码,并让其他人根据内核现有的许可证条款使用该代码。内核还维护着一个机器可读的 CREDITS 文件,其中列出了贡献者的名字、所属机构、贡献领域和其他元数据。我做了 一些 实验,把这种方法改编成适用于不使用内核开发流程的项目。

许可证授权

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”),
特此免费授予任何获得本软件副本和相关文档文件(下称“软件”)的人

MIT 许可证的实质是许可证(你猜对了)。一般来说,许可证是一个人或法律实体(“ 许可人 licensor ”)给予另一个人(“ 被许可人 licensee ”)做一些法律允许他们起诉的事情的许可。MIT 许可证是一种不起诉的承诺。

法律有时将许可证与给予许可证的承诺区分开来。如果有人违背了提供许可证的承诺,你可以起诉他们违背了承诺,但你最终可能得不到许可证。“ 特此 Hereby ”是律师们永远摆脱不了的一个矫揉造作、老生常谈的词。这里使用它来表明,许可证文本本身提供了许可证,而不仅仅是许可证的承诺。这是一个合法的 即调函数表达式(IIFE)

尽管许多许可证都是授予特定的、指定的被许可人的,但 MIT 许可证是一个“ 公共许可证 public license ”。公共许可证授予所有人(整个公众)许可。这是开源许可中的三大理念之一。MIT 许可证通过“向任何获得……软件副本的人”授予许可证来体现这一思想。稍后我们将看到,获得此许可证还有一个条件,以确保其他人也可以了解他们的许可。

在美国式法律文件中,括号中带引号的首字母大写词汇是赋予术语特定含义的标准方式(“定义”)。当法庭看到文件中其他地方使用了一个已定义的大写术语时,法庭会可靠地回顾定义中的术语。

授权范围

to deal in the Software without restriction,
不受限制地处置该软件的权利,

从被许可人的角度来看,这是 MIT 许可证中最重要的七个字。主要的法律问题就是因侵犯版权而被起诉,和因侵犯专利而被起诉。无论是版权法还是专利法都没有将 “ 处置 to deal in ” 作为一个术语,它在法庭上没有特定的含义。因此,任何法庭在裁决许可人和被许可人之间的纠纷时,都会询问当事人对这一措辞的含义和理解。法庭将看到的是,该措辞有意宽泛和开放。它为被许可人提供了一个强有力的论据,反对许可人提出的任何主张 —— 即他们不允许被许可人使用该软件做那件特定的事情,即使在授予许可证时双方都没有明显想到。

including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
包括不受限制地使用、复制、修改、合并、发布、分发、转授许可和/或出售该软件副本,以及再授权被配发了本软件的人如上的权利,

没有一篇法律是完美的、“意义上完全确定”、或明确无误的。小心那些假装不然的人。这是 MIT 许可证中最不完美的部分。主要有三个问题:

首先,“ 包括不受限制地 including without limitation ”是一种法律反模式。它有多种衍生:

  • 包括,但不受限制 including, without limitation
  • 包括,但不限于前述的一般性 including, without limiting the generality of the foregoing
  • 包括,但不限于 including, but not limited to
  • 很多、很多毫无意义的变化

所有这些都有一个共同的目标,但都未能可靠地实现。从根本上说,使用它们的起草者也会尽量试探着去做。在 MIT 许可证中,这意味着引入“ 处置软件 dealing in the Software ”的具体例子 — “使用、复制、修改”等等,但不意味着被许可方的行为必须与给出的例子类似,才能算作“处置”。问题是,如果你最终需要法庭来审查和解释许可证的条款,法庭将把它的工作看作是找出这些语言的含义。如果法庭需要决定“ 处置 deal in ”的含义,它不能“无视”这些例子,即使你告诉它。我认为,“不受限制地处置本软件”本身对被许可人更好,也更短。

其次,作为“ 处置 deal in ”的例子的那些动词是一个大杂烩。有些在版权法或专利法下有特定的含义,有些稍微有或根本没有含义:

  • 使用 use ”出现在 《美国法典》第 35 篇,第 271(a)节,这是专利法中专利权人可以起诉他人未经许可的行为的清单。
  • 复制 copy ”出现在 《美国法典》第 17 篇,第 106 节,即版权法列出的版权所有人可以起诉他人未经许可的行为。
  • 修改 modify ”既不出现在版权法中,也不出现在专利法中。它可能最接近版权法下的“ 准备衍生作品 prepare derivative works ”,但也可能涉及改进或其他衍生发明。
  • 无论是在版权法还是专利法中,“ 合并 merge ”都没有出现。“ 合并 merger ”在版权方面有特定的含义,但这显然不是这里的意图。相反,法庭可能会根据其在行业中的含义来解读“合并”,如“合并代码”。
  • 无论是在版权法还是专利法中,都没有“ 发布 publish ”。由于“软件”是被发布的内容,根据《版权法》,它可能最接近于“ 分发 distribute ”。该法令还包括“公开”表演和展示作品的权利,但这些权利只适用于特定类型的受版权保护的作品,如戏剧、录音和电影。
  • 分发 distribute ”出现在《版权法》中。
  • 转授许可 sublicense ”是知识产权法中的一个总称。转授许可的权利是指把自己的许可证授予他人,有权进行你所许可的部分或全部活动。实际上,MIT 许可证的转授许可的权利在开源代码许可证中并不常见。通常的做法是 Heather Meeker 所说的“ 直接许可 direct licensing ”方式,在这种方法中,每个获得该软件及其许可证条款副本的人都直接从所有者那里获得授权。任何可能根据 MIT 许可证获得转授许可的人都可能会得到一份许可证副本,告诉他们其也有直接许可证。
  • 出售副本 sell copies ”是个混杂品。它接近于《专利法》中的“ 要约出售 offer to sell ”和“ 出售 sell ”,但指的是“ 副本 coyies ”,这是一种版权概念。在版权方面,它似乎接近于“ 分发 distribute ”,但《版权法》没有提到销售。
  • 允许被配发了本软件的人这样做 permit persons to whom the Software is furnished to do so ”似乎是多余的“转授许可”。这也是不必要的,因为获得副本的人也可以直接获得许可证。

最后,由于这种法律、行业、一般知识产权和一般使用条款的混杂,并不清楚 MIT 许可证是否包括专利许可。一般性语言“ 处置 deal in ”和一些例子动词,尤其是“使用”,指向了一个专利许可,尽管是一个非常不明确的许可。许可证来自于版权持有人,而版权持有人可能对软件中的发明拥有或不拥有专利权,以及大多数的例子动词和“ 软件 the Software ”本身的定义,都强烈地指向版权许可证。诸如 Apache 2.0 之类的较新的宽容开源许可分别具体地处理了版权、专利甚至商标问题。

三个许可条件

subject to the following conditions:
须在下列条件下:

总有一个陷阱!MIT 许可证有三个!

如果你不遵守 MIT 许可证的条件,你就得不到许可证提供的许可。因此,如果不能履行条件,至少从理论上说,会让你面临一场诉讼,很可能是一场版权诉讼。

开源软件的第二个伟大思想是,利用软件对被许可人的价值来激励被许可人遵守条件,即使被许可人没有支付任何许可费用。最后一个伟大思想,在 MIT 许可证中没有,它构建了许可证条件:像 GNU 通用公共许可证(GPL)这样的左版许可证,使用许可证条件来控制如何对修改后的版本进行许可和发布。

声明条件

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
上述版权声明和本许可声明应包含在该软件的所有副本或实质成分中。

如果你给别人一份软件的副本,你需要包括许可证文本和任何版权声明。这有几个关键目的:

  1. 给别人一个声明,说明他们有权使用该公共许可证下的软件。这是直接授权模式的一个关键部分,在这种模式下,每个用户直接从版权持有人那里获得许可证。
  2. 让人们知道谁是软件的幕后人物,这样他们就可以得到赞美、荣耀和冷冰冰的现金捐赠。
  3. 确保保修免责声明和责任限制(在后面)伴随该软件。每个得到该副本的人也应该得到一份这些许可人保护的副本。

没有什么可以阻止你对提供一个副本、甚至是一个没有源代码的编译形式的副本而收费。但是当你这么做的时候,你不能假装 MIT 代码是你自己的专有代码,也不能在其他许可证下提供。接受的人要知道自己在“公共许可证”下的权利。

坦率地说,遵守这个条件正在崩溃。几乎所有的开源许可证都有这样的“ 归因 attribution ”条件。系统和装机软件的制作者往往明白,他们需要为自己的每一个发行版本编制一个声明文件或“许可证信息”屏,并附上库和组件的许可证文本副本。项目监管型基金会在教授这些做法方面起到了重要作用。但是整个 Web 开发者群体还没有取得这种经验。这不能用缺乏工具来解释,工具有很多,也不能用 npm 和其他资源库中的包的高度模块化来解释,它们统一了许可证信息的元数据格式。所有好的 JavaScript 压缩器都有保存许可证标题注释的命令行标志。其他工具可以从包树中串联 LICENSE 文件。这实在是没有借口。

免责声明

The Software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement.
本软件是“如此”提供的,没有任何形式的明示或暗示的保证,包括但不限于对适销性、特定用途的适用性和不侵权的保证。

美国几乎每个州都颁布了一个版本的《 统一商业法典 Uniform Commercial Code 》(UCC),这是一部规范商业交易的示范性法律。UCC 的第 2 条(加利福尼亚州的“第 2 部分”)规定了商品销售合同,包括了从二手汽车的购买到向制造厂运送大量工业化学品。

UCC 关于销售合同的某些规则是强制性的。这些规则始终适用,无论买卖双方是否喜欢。其他只是“默认”。除非买卖双方以书面形式选择不适用这些默认,否则 UCC 潜在视作他们希望在 UCC 文本中找到交易的基准规则。默认规则中包括隐含的“ 免责 warranties ”,或卖方对买方关于所售商品的质量和可用性的承诺。

关于诸如 MIT 许可证之类的公共许可证是合同(许可方和被许可方之间的可执行协议)还是仅仅是许可证(单向的,但可能有附加条件),这在理论上存在很大争议。关于软件是否被视为“商品”,从而触发 UCC 规则的争论较少。许可人之间没有就赔偿责任进行辩论:如果他们免费提供的软件出现故障、导致问题、无法正常工作或以其他方式引起麻烦,他们不想被起诉和被要求巨额赔偿。这与“ 默示保证 implied warranty ”的三个默认规则完全相反:

  1. UCC 第 2-314 节,“ 适销性 merchantability ”的默示保证是一种承诺:“商品”(即软件)的质量至少为平均水平,并经过适当包装和标记,并适用于其常规用途。仅当提供该软件的人是该软件的“商人”时,此保证才适用,这意味着他们从事软件交易,并表现出对软件的熟练程度。
  2. UCC 第 2-315 节,当卖方知道买方依靠他们提供用于特定目的的货物时,“ 适用于某一特定目的 fitness for a particular purpose ”的默示保证就会生效。商品实际上需要“适用”这一目的。
  3. 非侵权 noninfringement ”的默示保证不是 UCC 的一部分,而是一般合同法的共同特征。如果事实证明买方收到的商品侵犯了他人的知识产权,则这种默示的承诺将保护买方。如果根据 MIT 许可证获得的软件实际上并不属于尝试许可该软件的许可人,或者属于他人拥有的专利,那就属于这种情况。

UCC 的 第2-316(3)节 要求,选择不适用或“排除”适销性和适用于某一特定目的的默示保证措辞必须醒目。“醒目”意味着书面化或格式化,以引起人们的注意,这与旨在从不小心的消费者身边溜走的细小字体相反。各州法律可以对不侵权的免责声明提出类似的引人注目的要求。

长期以来,律师们都有一种错觉,认为用“全大写”写任何东西都符合明显的要求。这是不正确的。法庭曾批评律师协会自以为是,而且大多数人都认为,全大写更多的是阻止阅读,而不是强制阅读。同样的,大多数开源许可证的形式都将其免责声明设置为全大写,部分原因是这是在纯文本的 LICENSE 文件中唯一明显的方式。我更喜欢使用星号或其他 ASCII 艺术,但那是很久很久以前的事了。

责任限制

In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the Software or the use or other dealings in the Software.
在任何情况下,作者或版权持有人都不对任何索赔、损害或其他责任负责,无论这些追责来自合同、侵权或其它行为中,还是产生于、源于或有关于本软件以及本软件的使用或其它处置。

MIT 许可证授予软件“免费”许可,但法律并不认为接受免费许可证的人在出错时放弃了起诉的权利,而许可人应该受到责备。“责任限制”,通常与“损害赔偿排除”条款搭配使用,其作用与许可证很像,是不起诉的承诺。但这些都是保护许可人免受被许可人起诉的保护措施。

一般来说,法庭对责任限制和损害赔偿排除条款的解读非常谨慎,因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的切身利益,让民众有办法纠正在法庭上所犯的错误,他们“严格地”用措辞限制责任,尽可能地对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在“消费者”合同和其他放弃起诉权的人缺乏成熟度或讨价还价能力的情况下,法庭有时会拒绝尊重那些似乎被埋没在视线之外的措辞。部分是出于这个原因,部分是出于习惯,律师们往往也会给责任限制以全大写处理。

再往下看,“责任限制”部分是对被许可人可以起诉的金额上限。在开源许可证中,这个上限总是没有钱,0 元,“不承担责任”。相比之下,在商业许可证中,它通常是过去 12 个月内支付的许可证费用的倍数,尽管它通常是经过谈判的。

“排除”部分具体列出了各种法律主张,即请求赔偿的理由,许可人不能使用。像许多其他法律形式一样,MIT 许可证 提到了“ 违约 of contract ”行为(即违反合同)和“ 侵权 of tort ”行为。侵权规则是防止粗心或恶意伤害他人的一般规则。如果你在发短信时在路上撞倒了人,你就犯了侵权行为。如果你的公司销售的有问题的耳机会烧伤人们的耳朵,则说明贵公司已经侵权。如果合同没有明确排除侵权索赔,那么法庭有时会在合同中使用排除措辞以防止合同索赔。出于很好的考虑,MIT 许可证抛出“或其它”字样,只是为了截住奇怪的海事法或其它异国情调的法律主张。

产生于、源于或有关于 arising from, out of or in connection with ”这句话是法律起草人固有的、焦虑的不安全感反复出现的症状。关键是,任何与软件有关的诉讼都被这些限制和排除范围所覆盖。万一某些事情可以“ 产生于 arising from ”,但不能“ 源于 out of ”或“ 有关于 in connection with ”,那就最好把这三者都写在里面,所以要把它们打包在一起。更不用说,任何被迫在这部分内容中斤斤计较的法庭将不得不为每个词提出不同的含义,前提是专业的起草者不会在一行中使用不同的词来表示同一件事。更不用说,在实践中,如果法庭对一开始就不利的限制感觉不好,那么他们会更愿意狭隘地解读范围触发器。但我离题了,同样的语言出现在数以百万计的合同中。

总结

所有这些诡辩都有点像在进教堂的路上吐口香糖。MIT 许可证是一个法律经典,且有效。它绝不是解决所有软件知识产权弊病的灵丹妙药,尤其是它比已经出现的软件专利灾难还要早几十年。但 MIT 风格的许可证发挥了令人钦佩的作用,实现了一个狭隘的目的,用最少的、谨慎的法律工具组合扭转了版权、销售和合同法等棘手的默认规则。在计算机技术的大背景下,它的寿命是惊人的。MIT 许可证已经超过、并将要超过绝大多数软件许可证。我们只能猜测,当它最终失去青睐时,它能提供多少年的忠实法律服务。对于那些无法提供自己的律师的人来说,这尤其慷慨。

我们已经看到,我们今天所知道的 MIT 许可证是如何成为一套具体的、标准化的条款,使机构特有的、杂乱无章的变化终于有了秩序。

我们已经看到了它对归因和版权声明的处理方法如何为学术、标准、商业和基金会机构的知识产权管理实践提供信息。

我们已经看到了 MIT 许可证是如何运行所有人免费试用软件的,但前提是要保护许可人不受担保和责任的影响。

我们已经看到,尽管有一些生硬的措辞和律师的矫揉造作,但一百七十一个小词可以完成大量的法律工作,为开源软件在知识产权和合同的密集丛林中开辟一条道路。

我非常感谢所有花时间阅读这篇相当长的文章的人,让我知道他们发现它很有用,并帮助改进它。一如既往,我欢迎你通过 e-mailTwitterGitHub 发表评论。


有很多人问,他们在哪里可以读到更多的东西,或者找到其他许可证,比如 GNU 通用公共许可证或 Apache 2.0 许可证。无论你的兴趣是什么,我都会向你推荐以下书籍:

我先说这本,因为虽然它有些过时,但它的方法也最接近上面使用的逐行方法。O'Reilly 已经把它放在网上
在我看来,这是迄今为止关于 GNU 通用公共许可证和更广泛的左版的最佳著作。这本书涵盖了历史、许可证、它们的发展,以及兼容性和合规性。这本书是我给那些考虑或处理 GPL 的客户的书。
一本很棒的入门书,也可以免费 在线阅读。对于从零开始的程序员来说,这是开源许可和相关法律的最好介绍。这本在一些具体细节上也有点过时了,但 Larry 的许可证分类法和对开源商业模式的简洁总结经得起时间的考验。

所有这些都对我作为一个开源许可律师的教育至关重要。它们的作者都是我的职业英雄。请读一读吧 — K.E.M

我将此文章基于 Creative Commons Attribution-ShareAlike 4.0 license 授权


via: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html

作者:Kyle E. Mitchell 选题:lujun9972 译者:bestony 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

对于不是工程师的人来说也有很多技术工作可以做。本文作为本系列的第二篇,就具体阐述这些工作。

 title=

本系列的第一篇文章 中,我解释了技术行业如何将人员和角色划分为“技术”或“非技术”类别,以及与此相关的问题。科技行业使得那些对科技感兴趣但不懂编程的人很难找到适合自己的角色。

如果你对技术或开源感兴趣,但对编程不感兴趣,这也有一些工作适合你。科技公司的任何一个职位都可能需要一个精通科技但不一定会写代码的人。但是,你确实需要了解术语并理解产品。

我最近注意到,在诸如技术客户经理、技术产品经理、技术社区经理等职位头衔上增加了“技术”一词。这反映了几年前的趋势,即在头衔上加上“工程师”一词,以表示该职位的技术需要。过了一段时间,每个人的头衔中都有“工程师”这个词,这样的分类就失去了一些吸引力。

当我坐下来写这些文章时,Tim Banks 的这条推特出现在我的通知栏上:

已经将职业生涯规划为技术行业的非开发人员(除了信息安全、数据科学/分析师、基础设施工程师等以外的人员)的女性,你希望知道的事情有哪些,有价值的资源有哪些,或者对希望做出类似改变的人有哪些建议?

—— Tim Banks is a buttery biscuit (@elchefe) December 15,2020

这遵循了我第一篇文章中的建议:Tim 并不是简单地询问“非技术角色”;他提供了更重要的详细描述。在 Twitter 这样的媒体上,每一个字符都很重要,这些额外的字符会产生不同的效果。这些是技术角色。如果为了节约笔墨,而简单的称呼他们为“非技术人员”,会改变你的原意,产生不好的影响。

以下是需要技术知识的非工程类角色的示例。

技术作者

技术作者的工作 是在两方或多方之间传递事实信息。传统上,技术作者提供有关如何使用技术产品的说明或文档。最近,我看到术语“技术作者”指的是写其他形式内容的人。科技公司希望一个人为他们的开发者读者写博客文章,而这种技巧不同于文案或内容营销。

需要的技术技能:

  • 写作
  • 特定技术或产品的用户知识或经验
  • 快速跟上新产品或新特性的速度的能力
  • 在各种环境中创作的技能

适合人群:

  • 可以清楚地提供分步说明
  • 享受合作
  • 对活跃的声音和音乐有热情
  • 喜欢描述事物和解释原理

产品经理

产品经理 负责领导产品战略。职责可能包括收集客户需求并确定其优先级,撰写业务案例,以及培训销售人员。产品经理跨职能工作,利用创造性和技术技能的结合,成功地推出产品。产品经理需要深厚的产品专业知识。

所需技术技能:

  • 掌握产品知识,并且会配置或运行演示模型
  • 与产品相关的技术生态系统知识
  • 分析和研究技能

适合以下人群:

  • 享受制定战略和规划下一步的工作
  • 在不同的人的需求中可以看到一条共同的线索
  • 能够清楚地表达业务需求和要求
  • 喜欢描述原因

数据分析师

数据分析师负责收集和解释数据,以帮助推动业务决策,如是否进入新市场、瞄准哪些客户或在何处投资。这个角色需要知道如何使用所有可用的潜在数据来做出决策。我们常常希望把事情简单化,而数据分析往往过于简单化。获取正确的信息并不像编写查询 select all limit 10 来获取前 10 行那么简单。你需要知道要加入哪些表。你需要知道如何分类。你需要知道是否需要在运行查询之前或之后以某种方式清理数据。

所需技术技能:

  • 了解 SQL、Python 和 R
  • 能够看到和提取数据中的样本
  • 了解事物如何端到端运行
  • 批判性思维
  • 机器学习

适合以下人群:

  • 享受解决问题的乐趣
  • 渴望学习和提出问题

开发者关系

开发者关系 是一门相对较新的技术学科。它包括 开发者代言人 developer advocate 开发者传道者 developer evangelist 开发者营销 developer marketing 等角色。这些角色要求你与开发人员沟通,与他们建立关系,并帮助他们提高工作效率。你向公司倡导开发者的需求,并向开发者代表公司。开发者关系可以包括撰写文章、创建教程、录制播客、在会议上发言以及创建集成和演示。有人说你需要做过开发才能进入开发者关系。我没有走那条路,我知道很多人没有。

所需技术技能:

这些将高度依赖于公司和具体角色。你需要部分技能(不是全部)取决于你自己。

  • 了解与产品相关的技术概念
  • 写作
  • 教程和播客的视频和音频编辑
  • 说话

适合以下人群:

  • 有同情心,想要教导和授权他人
  • 可以为他人辩护
  • 你很有创意

无限的可能性

这并不是一个完整的清单,并没有列出技术领域中所有的非工程类角色,而是一些不喜欢每天编写代码的人可以尝试的工作。如果你对科技职业感兴趣,看看你的技能和什么角色最适合。可能性是无穷的。为了帮助你完成旅程,在本系列的最后一篇文章中,我将与这些角色的人分享一些建议。


via: https://opensource.com/article/21/2/non-engineering-jobs-tech

作者:Dawn Parzych 选题:lujun9972 译者:Chao-zhi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出