提要：传统观点认为，Apache 许可证拥有“真正”的专利许可，那 MIT 许可证呢？

我经常听到说，MIT 许可证中没有专利许可，或者它只有一些“默示”专利许可的可能性。如果 MIT 许可证很敏感的话，那么它可能会因为大家对其较为年轻的同伴 Apache 许可证的不断称赞而产生自卑感，传统观点认为，Apache 许可证拥有“真正”的专利许可。

这种区分经常重复出现，以至于人们认为，在许可证文本中是否出现“专利”一词具有很大的法律意义。不过，对“专利”一词的强调是错误的。1927 年，美国最高法院表示：

“专利所有人使用的任何语言，或者专利所有人向其他人展示的任何行为，使得其他人可以从中合理地推断出专利所有人同意他依据专利来制造、使用或销售，便构成了许可行为，并可以作为侵权行为的辩护理由。”

MIT 许可证无疑拥有明示许可。该许可证不限于授予任何特定类型的知识产权。但其许可证声明里不使用“专利”或“版权”一词。您上次听到有人表示担心 MIT 许可证仅包含默示版权许可是什么时候了？

既然授予权利的文本中没有“版权”和“专利”，让我们来研究一下 MIT 许可证中的字眼，看看我们能否了解到哪些权利被授予。

没有任何信息会导致人们认为，许可人会保留对使用专利所有人创造的软件的行为起诉专利侵权的权利，并允许其他人“无限制地处理本软件”。

为什么说这是默示专利许可呢？没有充足的理由这么做。我们来看一个默示专利许可的案例。Met-Coil Systems Corp. 诉Korners Unlimited 的专利纠纷涉及专利的默示许可（美国专利 4,466,641，很久以前已过期），该专利涉及用于连接供暖和空调系统中使用的金属管道段。处理该专利纠纷上诉的美国法院认定，专利权人（Met-Coil）出售其成型机（一种不属于专利保护主体的机器，但用于弯曲金属管道端部的法兰，使其作为以专利方式连接管道的一部分）授予其客户默示专利许可；因此，所谓的专利侵权者（Korners Unlimited）向这些客户出售某些与专利有关的部件（与 Met-Coil 机器弯曲产生的法兰一起使用的特殊角件）并不促成专利的侵权，因为客户被授予了许可（默示许可）。

通过销售其目的是在使用受专利保护的发明中发挥作用的金属弯曲机，专利权人向机器的购买者授予了专利许可。在 Met-Coil 案例中，可以看到需要谈论“默示”许可，因为根本不存在书面许可；法院也试图寻找由行为默示的许可。

现在，让我们回到 MIT 许可证。这是一个明示许可证。这个明示许可证授予了专利许可吗？事实上，在授予“无限制地处理软件”权限的情况下，MIT 许可证的确如此。没有比通过直接阅读授予许可的文字来得出结论更有效的办法了。

“明示专利许可”一词可以用于两种含义之一：

• 包括授予专利权利的明示许可证，或
• 明确提及专利权利的许可证。

其中第一项是与默示专利许可的对比。如果没有授予专利权利的明示许可，人们可以在分析中继续查看是否默示了专利许可。

人们经常使用第二个含义“明示专利许可”。不幸的是，这导致一些人错误地认为缺乏这样的“明示专利许可”会让人寻找默示许可。但是，第二种含义没有特别的法律意义。没有明确提及专利权利并不意味着没有授予专利权利的明示许可。因此，没有明确提及专利权利并不意味着仅受限于专利权利的默示许可。

说完这一切之后，那它究竟有多重要呢？

并没有多重要。当个人和企业根据 MIT 协议贡献软件时，他们并不希望稍后对那些使用专利所有人为之做出贡献的软件的人们主张专利权利。这是一个强有力的声明，当然，我没有直接看到贡献者的期望。但是根据 20 多年来我对依据 MIT 许可证贡献代码的观察，我没有看到任何迹象表明贡献者认为他们应该保留后续对使用其贡献的代码的行为征收专利许可费用的权利。恰恰相反，我观察到了与许可证中“无限制”这个短语一致的行为。

本讨论基于美国法律。其他司法管辖区的法律专家可以针对在其他国家的结果是否有所不同提出意见。

作者简介：Scott Peterson 是红帽公司（Red Hat）法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个决定性的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

最大化你的项目影响。

科学社区正在加速拥抱 自由及开源硬件 Free and Open Source Hardware （FOSH）。 研究员正忙于改进他们自己的装备并创造数以百计的基于分布式数字制造模型的设备来推动他们的研究。

热衷于 FOSH 的主要原因还是钱： 有研究表明，和专用设备相比，FOSH 可以节省 90% 到 99% 的花费。基于开源硬件商业模式的科学 FOSH 的商业化已经推动其快速地发展为一个新的工程领域，并为此定期举行 GOSH 年会。

特别的是，不止一本，而是关于这个主题的[两本学术期刊]：[Journal of Open Hardware] （由 Ubiquity 出版，一个新的自由访问出版商，同时出版了 Journal of Open Research Software ）以及 HardwareX（由 Elsevier 出版的一种自由访问期刊，它是世界上最大的学术出版商之一）。

由于学术社区的支持，科学 FOSH 的开发者在获取制作乐趣并推进科学快速发展的同时获得学术声望。

科学 FOSH 的5个步骤

Shane Oberloier 和我在名为 Designs 的自由访问工程期刊上共同发表了一篇关于设计 FOSH 科学设备原则的文章。我们以滑动式烘干机为例，制造成本低于 20 美元，仅是专用设备价格的三百分之一。科学和医疗设备往往比较复杂，开发 FOSH 替代品将带来巨大的回报。

我总结了 5 个步骤（包括 6 条设计原则），它们在 Shane Oberloier 和我发表的文章里有详细阐述。这些设计原则也可以推广到非科学设备，而且制作越复杂的设计越能带来更大的潜在收益。

如果你对科学项目的开源硬件设计感兴趣，这些步骤将使你的项目的影响最大化。

1. 评估类似现有工具的功能，你的 FOSH 设计目标应该针对实际效果而不是现有的设计（LCTT 译注：作者的意思应该是不要被现有设计缚住手脚）。必要的时候需进行概念证明。

2. 使用下列设计原则：

   • 在设备生产中，仅使用自由和开源的软件工具链（比如，开源的 CAD 工具，例如 OpenSCAD、 FreeCAD 或 Blender）和开源硬件。
   • 尝试减少部件的数量和类型并降低工具的复杂度
   • 减少材料的数量和制造成本。
   • 尽量使用能够分发的部件或使用方便易得的工具（比如 RepRap 3D 打印机）进行部件的数字化生产。
   • 对部件进行参数化设计，这使他人可以对你的设计进行个性化改动。相较于特例化设计，参数化设计会更有用。在未来的项目中，使用者可以通过修改核心参数来继续利用它们。
   • 所有不能使用现有的开源硬件以分布式的方式轻松且经济地制造的零件，必须选择现货产品以方便采购。
3. 验证功能设计。

4. 提供关于设计、生产、装配、校准和操作的详尽设备文档。包括原始设计文件而不仅仅是用于生产的。 开源硬件协会 Open Source Hardware Association 对于开源设计的发布和文档化有额外的指南，总结如下：

   • 以通用的形式分享设计文件。
   • 提供详尽的材料清单，包括价格和采购信息。
   • 如果涉及软件，确保代码对大众来说清晰易懂。
   • 作为生产时的参考，必须提供足够的照片，以确保没有任何被遮挡的部分。
   • 在描述方法的章节，整个制作过程必须被细化成简单步骤以便复制此设计。
   • 在线上分享并指定许可证。这为用户提供了合理使用该设计的信息。
5. 主动分享！为了使 FOSH 发扬光大，设计必须被广泛、频繁和有效地分享以提升它们的存在感。所有的文档应该在自由访问文献中发表，并与适当的社区共享。 开源科学框架 Open Science Framework 是一个值得考虑的优雅的通用存储库，它由 开源科学中心 Center for Open Science 主办，该中心设置为接受任何类型的文件并处理大型数据集。

这篇文章得到了 Fulbright Finland 的支持，该公司赞助了芬兰 Fulbright-Aalto 大学的特聘校席 Joshua Pearce 在开源科学硬件方面的研究工作。

via: https://opensource.com/article/18/2/5-steps-creating-successful-open-hardware

作者：Joshua Pearce 译者：kennethXia 校对：wxy

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

你可能并不想把所有的遗留应用全部分解为微服务，或许你可以考虑从安全功能开始。

我为了给这篇文章起个标题，使出 “洪荒之力”，也很担心这会变成标题党。如果你点击它，是因为它激起了你的好奇，那么我表示抱歉 ^注1 。我当然是希望你留下来阅读的 ^注2 ：我有很多有趣的观点以及很多 ^注3 脚注。我不是故意提出微服务会导致安全问题——尽管如同很多组件一样都有安全问题。当然，这些微服务是那些安全方面的人员的趣向所在。进一步地说，我认为对于那些担心安全的人来说，它们是优秀的架构。

为什么这样说？这是个好问题，对于我们这些有系统安全 经验的人来说，此时这个世界才是一个有趣的地方。我们看到随着带宽便宜了并且延迟降低了，分布式系统在增长。加上部署到云愈加便利，越来越多的架构师们开始意识到应用是可以分解的，不只是分成多个层，并且层内还能分为多个组件。当然，均衡负载可以用于让一个层内的各个组件协同工作，但是将不同的服务输出为各种小组件的能力导致了微服务在设计、实施和部署方面的增长。

所以，到底什么是微服务呢？我同意维基百科的定义，尽管没有提及安全性方面的内容 ^注4 。 我喜欢微服务的一点是，经过精心设计，其符合 Peter H. Salus 描述的 UNIX 哲学 的前俩点：

1. 程序应该只做一件事，并尽可能把它做好。
2. 让程序能够互相协同工作。
3. 应该让程序处理文本数据流，因为这是一个通用的接口。

三者中最后一个有点不太相关，因为 UNIX 哲学通常被用来指代独立应用，它常有一个实例化的命令。但是，它确实包含了微服务的基本要求之一：必须具有“定义明确”的接口。

这里的“定义明确”，我指的不仅仅是可外部访问的 API 的方法描述，也指正常的微服务输入输出操作——以及，如果有的话，还有其副作用。就像我之前的文章描述的，“良好的系统架构的五个特征”，如果你能够去设计一个系统，数据和主体描述是至关重要的。在此，在我们的微服务描述上，我们要去看看为什么这些是如此重要。因为对我来说，微服务架构的关键定义是可分解性。如果你要分解 ^注5 你的架构，你必须非常、非常地清楚每个细节（“组件”）要做什么。

在这里，就要开始考虑安全了。特定组件的准确描述可以让你：

• 审查您的设计
• 确保您的实现符合描述
• 提出可重用测试单元来审查功能
• 跟踪实施中的错误并纠正错误
• 测试意料之外的产出
• 监视不当行为
• 审核未来可能的实际行为

现在，这些微服务能用在一个大型架构里了吗？是的。但如果实体是在更复杂的配置中彼此链接或组合在一起，它们会随之越来越难。当你让一小部分可以彼此配合工作时，确保正确的实施和行为是非常、非常容易的。并且如果你不能确定单个组件正在做它们应该作的，那么确保其衍生出来的复杂系统的正确行为及不正确行为就困难的多了。

而且还不止于此。如我已经在许多以往场合提过的，写足够安全的代码是困难的 ^注7 ，证实它应该做的更加困难。因此，有理由限制有特定安全要求的代码——密码检测、加密、加密密钥管理、授权等等——将它们变成小而定义明确的代码块。然后你就可以执行我上面提及所有工作，以确保正确完成。

还有，我们都知道并不是每个人都擅长于编写与安全相关的代码。通过分解你的体系架构，将安全敏感的代码限制到定义明确的组件中，你就可以把你最棒的安全人员放到这方面，并限制了 J.佛系.码奴 ^注8 绕过或降级一些关键的安全控制措施的危险。

它可以作为学习的机会：它对于设计/实现/测试/监视的兄弟们都是好的，而且给他们说：“听、读、标记、学习，并且引为己用 ^注9 。这是应该做的。”

是否应该将所有遗留应用程序分解为微服务？ 不一定。 但是考虑到其带来的好处，你可以考虑从安全入手。

• 注1、有一点——有读者总是好的。
• 注2、这是我写下文章的意义。
• 注3、可能没那么有趣。
• 注4、在我写这篇文章时。我或你们中的一个可能会去编辑改变它。
• 注5、这很有趣，听起来想一个园艺术语。并不是说我很喜欢园艺，但仍然... ^注6
• 注6、有意思的是，我最先写的 “如果你要分解你的架构....” 听起来想是一个 IT 主题的谋杀电影标题。
• 注7、长期读者可能会记得提到的优秀电影 “The Thick of It”
• 注8、其他的什么人：请随便选择。
• 注9、不是加密 摘要 digest ：我不认同原作者的想法。

这篇文章最初出在爱丽丝、伊娃与鲍伯——一个安全博客上，并被许可转载。

via: https://opensource.com/article/17/11/microservices-are-security-issue

作者：Mike Bursell 译者：erlinux 校对：wxy

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

有 65% 的企业在使用开源软件，并非只有互联网企业才能受惠于开源计划。

很多互联网企业如 Google、 Facebook、 Twitter 等，都已经正式建立了开源计划（有的公司中建立了单独的 开源计划部门 open source program office （OSPO）），这是在公司内部消化和支持开源产品的地方。在这样一个实际的部门中，企业可以清晰透明地执行开源策略，这是企业成功开源化的一个必要过程。开源计划部门的职责包括：制定使用、分配、选择和审查代码的相关政策；培育开源社区；培训开发技术人员和确保法律合规。

互联网企业并不是唯一建立开源计划的企业，有调查发现各种行业中有 65% 的企业的在使用开源和向开源贡献。在过去几年中 VMware、 Amazon、 Microsoft 等企业，甚至连英国政府都开始聘用开源管理人员，开展开源计划。可见近年来商业领域乃至政府都十分重视开源策略，在这样的环境下，各界也需要跟上他们的步伐，建立开源计划。

怎样建立开源计划

虽然根据企业的需求不同，各开源计划部门会有特殊的调整，但下面几个基本步骤是建立每个公司都会经历的，它们是：

• 选定一位领导者： 选出一位合适的领导之是建立开源计划的第一步。 TODO Group 发布了一份开源人员基础工作任务清单，你可以根据这个清单筛选人员。
• 确定计划构架： 开源计划部门可以根据其服务的企业类型的侧重点，来适应不同种类的企业需求，以在各类企业中成功运行。知识型企业可以把开源计划放在法律事务部运行，技术驱动型企业可以把开源计划放在着眼于提高企业效能的部门中，如工程部。其他类型的企业可以把开源计划放在市场部内运行，以此促进开源产品的销售。TODO Group 发布的开源计划案例或许可以给你些启发。
• 制定规章制度： 开源策略的实施需要有一套规章制度，其中应当具体列出企业成员进行开源工作的标准流程，来减少失误的发生。这个流程应当简洁明了且简单易行，最好可以用设备进行自动化。如果工作人员有质疑标准流程的热情和能力，并提出改进意见，那再好不过了。许多活跃在开源领域的企业中，Google 发布的规章制度十分值得借鉴。你可以参照 Google 发布的制度起草适用于自己企业的规章制度，用 TODO 提供其它开源策略也可以参考。 ### 建立开源计划是企业发展中的关键一步

建立开源计划部门对很多企业来说是关键一步，尤其是对于那些软件公司或是想要转型进入软件领域的公司。不论雇员的满意度或是开发效率上，在开源计划中企业可以获得巨大的利益，这些利益远远大于对开源计划所需要的长期投资。在开源之路上有很多资源可以帮助你成功，例如 TODO Group 的《怎样创建开源计划》、《开源计划的价值评估》和《管理开源计划的几种工具》都很适合初学者阅读。

随着越来越多的企业形成开源计划，开源社区自身的可持续性逐渐加强，这会对这些企业的开源计划产生积极影响，促进企业的发展，这是企业和开源间的良性循环。我希望以上这些信息能够帮到你，祝你在建立开源计划的路上一路顺风。

via: https://opensource.com/article/18/1/how-start-open-source-program-your-company

作者：Chris Aniszczyk 译者：Valoniakim 校对：wxy

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

在这个列表中，没有项目管理软件，这里不包含清单，也没有与 GitHub 整合，只是几种组织思维和提高团队交流的方法。

你也许经常听说下面这句话：工具太多，时间太少。为了节约您的时间，我列出了几款我最常用的提高敏捷团队工作效率的工具。如果你也是一名敏捷主义者，你可能听说过类似的工具，但我这里提到的仅限于开源工具。

请注意！ 这些工具和你想象的可能有点不同。它们并不是项目管理软件——这领域已经有一篇好文章了。因此这里不包含清单，也没有与 GitHub 整合，只是几种组织思维和提高团队交流的方法。

组建一个充满积极反馈的团队

如果在产业中大部分人都习惯了输出、接收负面消息，就很难有人对同事进行正面反馈的输出。这并不奇怪，当人们乐于给出赞美时，人们就会竞相向别人说“干得漂亮！”、“没有你我们很难完成任务。”赞美别人干的漂亮并不会使你痛苦，它通常能激励大家更好地为团队工作。下面两个软件可以帮助你向同事表达赞扬。

• 对开发团队来说，Management 3.0 是个有着大量免费资源的宝箱，可以尽情使用。其中 Feedback Wraps 的观念最引人注目（不仅仅是因为它让我们联想到墨西哥卷）。 Feedback Wraps 是一个经过六步对用户进行反馈的程序，也许你会认为它是为了负面反馈而设计的，但我们发现它在表达积极评论方面十分有效。
• Happiness Packets 为用户提供了在开源社区内匿名正面反馈的服务。它尤其适合不太习惯人际交往的用户或是不知道说什么好的情况。Happiness Packets 拥有一份公开的评论档案（这些评论都已经得到授权分享），你可以浏览大家的评论，从中得到灵感，对别人做出暖心的称赞。它还有个特殊功能，能够屏蔽恶意消息。

思考工作的意义

这很难定义。在敏捷领域中，成功的关键包括定义人物角色和产品愿景，还要向整个敏捷团队说明此项工作的意义。产品开发人员和项目负责人能够获得的开源工具数量极为有限，对于这一点我们有些失望。

在 Rat Hat 公司，最受尊敬也最为常用于训练敏捷团队的开源工具之一是 Product Vision Board 。它出自产品管理专家 Roman Pichler 之手，Roman Pichler 提供了大量工具和模版来帮助敏捷团队理解他们工作的意义。（你需要提供电子邮箱地址才能下载这些工具。）

• Product Vision Board 的模版通过简单但有效的问题引导团队转变思考方式，将思考工作的意义置于具体工作方法之前。
• 我们也很喜欢 Roman 的 Product Management Test，它能够通过简便快捷的网页表单，引领团队重新定义产品开发人员的角色，并且找出程序漏洞。我们推荐产品开发团队周期性地完成此项测试，重新分析失败原因。

对工作内容的直观化

你是否曾为一个大案子焦头烂额，连熟悉的步骤也在脑海中乱成一团？我们也遇到过这种情况。使用思维导图可以梳理你脑海中的想法，使其直观化。你不需要一下就想出整件事该怎么进行，你只需要你的头脑，一块白板（或者是思维导图软件）和一些思考的时间。

• 在这个领域中我们最喜欢的开源工具是 Xmind3。它支持多种平台运行（Linux、MacOS 和 Windows），以便与他人共享文件。如果你对工具的要求很高，推荐使用其更新版本，提供电子邮箱地址即可免费下载使用。
• 如果你很看重灵活性，Eduard Lucena 在 Fedora Magazine 中提供的 三个附加选项 就十分适合。你可以在 Fedora 杂志上找到这些软件的获取方式，其他信息可以在它们的项目页找到。

+ [Labyrinth](https://people.gnome.org/%7Edscorgie/labyrinth.html)
+ [View Your Mind](http://www.insilmaril.de/vym/)
+ [FreeMind](http://freemind.sourceforge.net/wiki/index.php/Main_Page)

像我们开头说的一样，提高敏捷团队工作效率的工具有很多，如果你有特别喜欢的相关开源工具，请在评论中与大家分享。

作者简介

Jen Krieger ：Red Hat 的首席敏捷架构师，在软件开发领域已经工作超过 20 年，曾在瀑布及敏捷生命周期等领域扮演多种角色。目前在 Red Hat 负责针对 CI/CD 最佳效果的部际 DevOps 活动。最近她在与 Project Atomic & OpenShift 团队合作。她最近在引领公司向着敏捷团队改革，并增加开源项目在公司内的认知度。

via: https://opensource.com/article/18/1/foss-tools-agile-teams

作者：Jen Krieger 译者：Valoniakim 校对：wxy

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

在这篇文章中，我将分享企业环境下顶级的 Linux 发行版。其中一些发行版用于服务器和云环境以及桌面任务。所有这些可选的 Linux 具有的一个共同点是它们都是企业级 Linux 发行版 —— 所以你可以期待更高程度的功能性，当然还有支持程度。

什么是企业级的 Linux 发行版？

企业级的 Linux 发行版可以归结为以下内容 —— 稳定性和支持。在企业环境中，使用的 Linux 版本必须满足这两点。稳定性意味着所提供的软件包既稳定又可用，同时仍然保持预期的安全性。

企业级的支持因素意味着有一个可靠的支持机制。有时这是单一的（官方）来源，如公司。在其他情况下，它可能是一个非营利性的治理机构，向优秀的第三方支持供应商提供可靠的建议。很明显，前者是最好的选择，但两者都可以接受。

Red Hat 企业级 Linux（RHEL）

Red Hat 有很多很棒的产品，都有企业级的支持来保证可用。其核心重点如下：

• Red Hat 企业级 Linux 服务器：这是一组服务器产品，包括从容器托管到 SAP 服务的所有内容，还有其他衍生的服务器。
• Red Hat 企业级 Linux 桌面：这些是严格控制的用户环境，运行 Red Hat Linux，提供基本的桌面功能。这些功能包括访问最新的应用程序，如 web 浏览器、电子邮件、LibreOffice 等。
• Red Hat 企业级 Linux 工作站：这基本上是 Red Hat 企业级 Linux 桌面，但针对高性能任务进行了优化。它也非常适合于大型部署和持续管理。

为什么选择 Red Hat 企业级 Linux？

Red Hat 是一家非常成功的大型公司，销售围绕 Linux 的服务。基本上，Red Hat 从那些想要避免供应商锁定和其他相关问题的公司赚钱。这些公司认识到聘用开源软件专家和管理他们的服务器和其他计算需求的价值。一家公司只需要购买订阅来让 Red Hat 做支持工作就行。

Red Hat 也是一个可靠的社会公民。他们赞助开源项目以及像 OpenSource.com 这样的 FoSS 支持网站（LCTT 译注：FoSS 是 Free and Open Source Software 的缩写，意为自由及开源软件），并为 Fedora 项目提供支持。Fedora 不是由 Red Hat 所有的，而是由它赞助开发的。这使 Fedora 得以发展，同时也使 Red Hat 受益匪浅。Red Hat 可以从 Fedora 项目中获得他们想要的，并将其用于他们的企业级 Linux 产品中。 就目前来看，Fedora 充当了红帽企业 Linux 的上游渠道。

SUSE Linux 企业版本

SUSE 是一家非常棒的公司，为企业用户提供了可靠的 Linux 选择。SUSE 的产品类似于 Red Hat，桌面和服务器都是该公司所关注的。从我自己使用 SUSE 的经验来看，我相信 YaST 已经证明了，对于希望在工作场所使用 Linux 操作系统的非 Linux 管理员而言，它拥有巨大的优势。YaST 为那些需要一些基本的 Linux 命令行知识的任务提供了一个友好的 GUI。

SUSE 的核心重点如下：

• SUSE Linux 企业级服务器（SLES）：包括任务特定的解决方案，从云到 SAP，以及任务关键计算和基于软件的数据存储。
• SUSE Linux 企业级桌面：对于那些希望为员工提供可靠的 Linux 工作站的公司来说，SUSE Linux 企业级桌面是一个不错的选择。和 Red Hat 一样，SUSE 通过订阅模式来对其提供支持。你可以选择三个不同级别的支持。

为什么选择 SUSE Linux 企业版？

SUSE 是一家围绕 Linux 销售服务的公司，但他们仍然通过专注于简化操作来实现这一目标。从他们的网站到其提供的 Linux 发行版，重点是易用性，而不会牺牲安全性或可靠性。尽管在美国毫无疑问 Red Hat 是服务器的标准，但 SUSE 作为公司和开源社区的贡献成员都做得很好。

我还会继续说，SUSE 不会太严肃，当你在 IT 领域建立联系的时候，这是一件很棒的事情。从他们关于 Linux 的有趣音乐视频到 SUSE 贸易展位中使用的 Gecko 以获得有趣的照片机会，SUSE 将自己描述成简单易懂和平易近人的形象。

Ubuntu LTS Linux

Ubuntu Long Term Release （LTS） Linux 是一个简单易用的企业级 Linux 发行版。Ubuntu 看起来比上面提到的其他发行版更新更频繁（有时候也更不稳定）。但请不要误解，Ubuntu LTS 版本被认为是相当稳定的，不过，我认为一些专家可能不太同意它们是安全可靠的。

Ubuntu 的核心重点如下：

• Ubuntu 桌面版：毫无疑问，Ubuntu 桌面非常简单，可以快速地学习并运行。也许在高级安装选项中缺少一些东西，但这使得其更简单直白。作为额外的奖励，Ubuntu 相比其他版本有更多的软件包（除了它的父亲，Debian 发行版）。我认为 Ubuntu 真正的亮点在于，你可以在网上找到许多销售 Ubuntu 的厂商，包括服务器、台式机和笔记本电脑。
• Ubuntu 服务器版：这包括服务器、云和容器产品。Ubuntu 还提供了 Juju 云“应用商店”这样一个有趣的概念。对于任何熟悉 Ubuntu 或 Debian 的人来说，Ubuntu 服务器都很有意义。对于这些人来说，它就像手套一样，为你提供了你已经熟知并喜爱的命令行工具。
• Ubuntu IoT：最近，Ubuntu 的开发团队已经把目标瞄准了“物联网”（IoT）的创建解决方案。包括数字标识、机器人技术和物联网网关。我的猜测是，我们将在 Ubuntu 中看到大量增长的物联网用户来自企业，而不是普通家庭用户。

为什么选择 Ubuntu LTS？

社区是 Ubuntu 最大的优点。除了在已经拥挤的服务器市场上的巨大增长之外，它还与普通用户在一起。Ubuntu 的开发和用户社区是坚如磐石的。因此，虽然它可能被认为比其他企业版更不稳定，但是我发现将 Ubuntu LTS 安装锁定到 “security updates only” 模式下提供了非常稳定的体验。

CentOS 或者 Scientific Linux 怎么样呢？

首先，让我们把 CentOS 作为一个企业发行版，如果你有自己的内部支持团队来维护它，那么安装 CentOS 是一个很好的选择。毕竟，它与 Red Hat 企业级 Linux 兼容，并提供了与 Red Hat 产品相同级别的稳定性。不幸的是，它不能完全取代 Red Hat 支持订阅。

那么 Scientific Linux 呢？它的发行版怎么样？好吧，它就像 CentOS，它是基于 Red Hat Linux 的。但与 CentOS 不同的是，它与 Red Hat 没有任何隶属关系。 Scientific Linux 从一开始就有一个目标 —— 为世界各地的实验室提供一个通用的 Linux 发行版。今天，Scientific Linux 基本上是 Red Hat 减去所包含的商标资料。

这两种发行版都不能真正地与 Red Hat 互换，因为它们缺少 Red Hat 支持组件。

哪一个是顶级企业发行版？我认为这取决于你需要为自己确定的许多因素：订阅范围、可用性、成本、服务和提供的功能。这些是每个公司必须自己决定的因素。就我个人而言，我认为 Red Hat 在服务器上获胜，而 SUSE 在桌面环境中轻松获胜，但这只是我的意见 —— 你不同意？点击下面的评论部分，让我们来谈谈它。

via: https://www.datamation.com/open-source/best-linux-distros-for-the-enterprise.html

作者：Matt Hartley 译者：MjSeven 校对：wxy

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