这就是为什么商业机构应该选择开源模式的原因

在相同的基础上，开源软件要优于专有软件。想知道为什么？这里有六个商业机构及政府部门可以从开源技术中获得好处的原因。

1、 让供应商审核更简单

在你投入工程和金融资源将一个产品整合到你的基础设施之前，你需要知道你选择了正确的产品。你想要一个处于积极开发的产品，它有定期的安全更新和漏洞修复，同时在你有需求时，产品能有相应的更新。这最后一点也许比你想的还要重要：没错，解决方案一定是满足你的需求的。但是产品的需求随着市场的成熟以及你商业的发展在变化。如果该产品随之改变，在未来你需要花费很大的代价来进行迁移。

你怎么才能知道你没有正在把你的时间和资金投入到一个正在消亡的产品？在开源的世界里，你可以不选择一个只有卖家有话语权的供应商。你可以通过考虑发展速度以及社区健康程度来比较供应商。一到两年之后，一个更活跃、多样性和健康的社区将开发出一个更好的产品，这是一个重要的考虑因素。当然，就像这篇 关于企业开源软件的博文 指出的，供应商必须有能力处理由于项目发展创新带来的不稳定性。寻找一个有长支持周期的供应商来避免混乱的更新。

2、 来自独立性的长寿

福布斯杂志指出 90%的初创公司是失败的 ，而他们中不到一半的中小型公司能存活超过五年。当你不得不迁移到一个新的供应商时，你花费的代价是昂贵的。所以最好避免一些只有一个供应商支持的产品。

开源使得社区成员能够协同编写软件。例如 OpenStack 是由许多公司以及个人志愿者一起编写的，这给客户提供了一个保证，不管任何一个独立供应商发生问题，也总会有一个供应商能提供支持。随着软件的开源，企业会长期投入开发团队，以实现产品开发。能够使用开源代码可以确保你总是能从贡献者中雇佣到人来保持你的开发活跃。当然，如果没有一个大的、活跃的社区，也就只有少量的贡献者能被雇佣，所以活跃贡献者的数量是重要的。

3、 安全性

安全是一件复杂的事情。这就是为什么开源开发是构建安全解决方案的关键因素和先决条件。同时每一天安全都在变得更重要。当开发以开源方式进行，你能直接的校验供应商是否积极的在追求安全，以及看到供应商是如何对待安全问题的。研究代码和执行独立代码审计的能力可以让供应商尽可能早的发现和修复漏洞。一些供应商给社区提供上千的美金的漏洞奖金作为额外的奖励来鼓励开发者发现他们产品的安全漏洞，这同时也展示了供应商对于自己产品的信任。

除了代码，开源开发同样意味着开源过程，所以你能检查和看到供应商是否遵循 ISO27001、 云安全准则 及其他标准所推荐的工业级的开发过程。当然，一个可信组织外部检查提供了额外的保障，就像我们在 Nextcloud 与 NCC小组合作的一样。

4、 更多的顾客导向

由于用户和顾客能直接看到和参与到产品的开发中，开源项目比那些只关注于营销团队回应的闭源软件更加的贴合用户的需求。你可以注意到开源软件项目趋向于以“宽松”方式发展。一个商业供应商也许关注在某个特定的事情方面，而一个社区则有许多要做的事情并致力于开发更多的功能，而这些全都是公司或个人贡献者中的某人或某些人所感兴趣的。这导致更少的为了销售而发布的版本，因为各种改进混搭在一起根本就不是一回事。但是它创造了许多对用户更有价值的产品。

5、 更好的支持

专有供应商通常是你遇到问题时唯一能给你提供帮助的一方。但如果他们不提供你所需要的服务，或者对调整你的商务需求收取额外昂贵的费用，那真是不好运。对专有软件提供的支持是一个典型的 “柠檬市场”。 随着软件的开源，供应商要么提供更大的支持，要么就有其它人来填补空白——这是自由市场的最佳选择，这可以确保你总是能得到最好的服务支持。

6、 更佳的许可

典型的软件许可证充斥着令人不愉快的条款，通常都是强制套利，你甚至不会有机会起诉供应商的不当行为。其中一个问题是你仅仅被授予了软件的使用权，这通常完全由供应商自行决定。如果软件不运行或者停止运行或者如果供应商要求支付更多的费用，你得不到软件的所有权或其他的权利。像 GPL 一类的开源许可证是为保护客户专门设计的，而不是保护供应商，它确保你可以如你所需的使用软件，而没有专制限制，只要你喜欢就行。

由于它们的广泛使用，GPL 的含义及其衍生出来的其他许可证得到了广泛的理解。例如，你能确保该许可允许你现存的基础设施（开源或闭源）通过设定好的 API 去进行连接，其没有时间或者是用户人数上的限制，同时也不会强迫你公开软件架构或者是知识产权（例如公司商标）。

这也让合规变得更加的容易；使用专有软件意味着你面临着苛刻的法规遵从性条款和高额的罚款。更糟糕的是一些 开源内核 open core 的产品在混合了 GPL 软件和专有软件。这违反了许可证规定并将顾客置于风险中。同时 Gartner 指出，开源内核模式意味着你不能从开源中获利。纯净的开源许可的产品避免了所有这些问题。取而代之，你只需要遵从一个规则：如果你对代码做出了修改（不包括配置、商标或其他类似的东西），你必须将这些与你的软件分发随同分享，如果他们要求的话。

显然开源软件是更好的选择。它易于选择正确的供应商（不会被供应商锁定），加之你也可以受益于更安全、对客户更加关注和更好的支持。而最后，你将处于法律上的安全地位。

作者简介：

一个善于与人打交道的技术爱好者和开源传播者。Nextcloud 的销售主管，曾是 ownCloud 和 SUSE 的社区经理，同时还是一个有多年经验的 KDE 销售人员。喜欢骑自行车穿越柏林和为家人朋友做饭。点击这里找到我的博客。

via: https://opensource.com/article/17/10/6-reasons-choose-open-source-software

作者：Jos Poortvliet Feed 译者：ZH1122 校对：wxy

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

在这篇分析报告中，我们将使用 2017 年度截止至当前时间（2017 年 10 月）为止，GitHub 上所有公开的推送事件的数据。对于每个 GitHub 用户，我们将尽可能地猜测其所属的公司。此外，我们仅查看那些今年得到了至少 20 个星标的仓库。

以下是我的报告结果，你也可以在我的交互式 Data Studio 报告上进一步加工。

顶级云服务商的比较

2017 年它们在 GitHub 上的表现：

• 微软看起来约有 1300 名员工积极地推送代码到 GitHub 上的 825 个顶级仓库。
• 谷歌显示出约有 900 名员工在 GitHub 上活跃，他们推送代码到大约 1100 个顶级仓库。
• 亚马逊似乎只有 134 名员工活跃在 GitHub 上，他们推送代码到仅仅 158 个顶级项目上。
• 不是所有的项目都一样：在超过 25% 的仓库上谷歌员工要比微软员工贡献的多，而那些仓库得到了更多的星标（53 万对比 26 万）。亚马逊的仓库 2017 年合计才得到了 2.7 万个星标。

红帽、IBM、Pivotal、英特尔和 Facebook

如果说亚马逊看起来被微软和谷歌远远抛在了身后，那么这之间还有哪些公司呢？根据这个排名来看，红帽、Pivotal 和英特尔在 GitHub 上做出了巨大贡献：

注意，下表中合并了所有的 IBM 地区域名（各个地区会展示在其后的表格中）。

Facebook 和 IBM（美）在 GitHub 上的活跃用户数同亚马逊差不多，但是它们所贡献的项目得到了更多的星标（特别是 Facebook）：

接下来是阿里巴巴、Uber 和 Wix：

以及 GitHub 自己、Apache 和腾讯：

百度、苹果和 Mozilla：

（LCTT 译注：很高兴看到国内的顶级互联网公司阿里巴巴、腾讯和百度在这里排名前列！）

甲骨文、斯坦福大学、麻省理工、Shopify、MongoDb、伯克利大学、VmWare、Netflix、Salesforce 和 Gsa.gov：

LinkedIn、Broad Institute、Palantir、雅虎、MapBox、Unity3d、Automattic（WordPress 的开发商）、Sandia、Travis-ci 和 Spotify：

Chromium、UMich、Zalando、Esri、IBM (英)、SAP、EPAM、Telerik、UK Cabinet Office 和 Stripe：

Cern、Odoo、Kitware、Suse、Yandex、IBM (加)、Adobe、AirBnB、Chef 和 The Guardian：

Arm、Macports、Docker、Nuxeo、NVidia、Yelp、Elastic、NYU、WSO2、Mesosphere 和 Inria：

Puppet、斯坦福（计算机科学）、DatadogHQ、Epfl、NTT Data 和 Lawrence Livermore Lab：

我的分析方法

我是怎样将 GitHub 用户关联到其公司的

在 GitHub 上判定每个用户所属的公司并不容易，但是我们可以使用其推送事件的提交消息中展示的邮件地址域名来判断。

• 同样的邮件地址可以出现在几个用户身上，所以我仅考虑那些对此期间获得了超过 20 个星标的项目进行推送的用户。
• 我仅统计了在此期间推送超过 3 次的 GitHub 用户。
• 用户推送代码到 GitHub 上可以在其推送中显示许多不同的邮件地址，这部分是由 GIt 工作机制决定的。为了判定每个用户的组织，我会查找那些在推送中出现更频繁的邮件地址。
• 不是每个用户都在 GitHub 上使用其组织的邮件。有许多人使用 gmail.com、users.noreply.github.com 和其它邮件托管商的邮件地址。有时候这是为了保持匿名和保护其公司邮箱，但是如果我不能定位其公司域名，这些用户我就不会统计。抱歉。
• 有时候员工会更换所任职的公司。我会将他们分配给其推送最多的公司。

我的查询语句

#standardSQL
WITH
period AS (
  SELECT *
  FROM `githubarchive.month.2017*` a
),
repo_stars AS (
  SELECT repo.id, COUNT(DISTINCT actor.login) stars, APPROX_TOP_COUNT(repo.name, 1)[OFFSET(0)].value repo_name 
  FROM period
  WHERE type='WatchEvent'
  GROUP BY 1
  HAVING stars>20
), 
pushers_guess_emails_and_top_projects AS (
  SELECT *
    # , REGEXP_EXTRACT(email, r'@(.*)') domain
    , REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain
  FROM (
    SELECT actor.id
      , APPROX_TOP_COUNT(actor.login,1)[OFFSET(0)].value login
      , APPROX_TOP_COUNT(JSON_EXTRACT_SCALAR(payload, '$.commits[0].author.email'),1)[OFFSET(0)].value email
      , COUNT(*) c
      , ARRAY_AGG(DISTINCT TO_JSON_STRING(STRUCT(b.repo_name,stars))) repos
    FROM period a
    JOIN repo_stars b
    ON a.repo.id=b.id
    WHERE type='PushEvent'
    GROUP BY  1
    HAVING c>3
  )
)
SELECT * FROM (
  SELECT domain
    , githubers
    , (SELECT COUNT(DISTINCT repo) FROM UNNEST(repos) repo) repos_contributed_to
    , ARRAY(
        SELECT AS STRUCT JSON_EXTRACT_SCALAR(repo, '$.repo_name') repo_name
        , CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64) stars
        , COUNT(*) githubers_from_domain FROM UNNEST(repos) repo 
        GROUP BY 1, 2 
        HAVING githubers_from_domain>1 
        ORDER BY stars DESC LIMIT 3
      ) top
    , (SELECT SUM(CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64)) FROM (SELECT DISTINCT repo FROM UNNEST(repos) repo)) sum_stars_projects_contributed_to
  FROM (
    SELECT domain, COUNT(*) githubers, ARRAY_CONCAT_AGG(ARRAY(SELECT * FROM UNNEST(repos) repo)) repos
    FROM pushers_guess_emails_and_top_projects
    #WHERE domain IN UNNEST(SPLIT('google.com|microsoft.com|amazon.com', '|'))
    WHERE domain NOT IN UNNEST(SPLIT('gmail.com|users.noreply.github.com|qq.com|hotmail.com|163.com|me.com|googlemail.com|outlook.com|yahoo.com|web.de|iki.fi|foxmail.com|yandex.ru', '|')) # email hosters
    GROUP BY 1
    HAVING githubers > 30
  )
  WHERE (SELECT MAX(githubers_from_domain) FROM (SELECT repo, COUNT(*) githubers_from_domain FROM UNNEST(repos) repo  GROUP BY repo))>4 # second filter email hosters
)
ORDER BY githubers DESC

FAQ

有的公司有 1500 个仓库，为什么只统计了 200 个？有的仓库有 7000 个星标，为什么只显示 1500 个？

我进行了过滤。我只统计了 2017 年的星标。举个例子说，Apache 在 GitHub 上有超过 1500 个仓库，但是今年只有 205 个项目得到了超过 20 个星标。

这表明了开源的发展形势么？

注意，这个对 GitHub 的分析没有包括像 Android、Chromium、GNU、Mozilla 等顶级社区，也没有包括 Apache 基金会或 Eclipse 基金会，还有一些其它项目选择在 GitHub 之外开展起活动。

这对于我的组织不公平

我只能统计我所看到的数据。欢迎对我的统计的前提提出意见，以及对我的统计方法给出改进方法。如果有能用的查询语句就更好了。

举个例子，要看看当我合并了 IBM 的各个地区域名到其顶级域时排名发生了什么变化，可以用一条 SQL 语句解决：

SELECT *, REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain

当合并了其地区域名后， IBM 的相对位置明显上升了。

回音

• 关于“ GitHub 2017 年顶级贡献者”的一些思考

接下来

我以前犯过错误，而且以后也可能再次出错。请查看所有的原始数据，并质疑我的前提假设——看看你能得到什么结论是很有趣的。

• 用一下交互式 Data Studio 报告

感谢 Ilya Grigorik 保留的 GitHub Archive 提供了这么多年的 GitHub 数据！

想要看更多的文章？看看我的 Medium、在 twitter 上关注我 并订阅 reddit.com/r/bigquery。试试 BigQuery，每个月可以免费分析 1 TB 的数据。

via: https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

作者：Felipe Hoffa 译者：wxy 校对：wxy

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

2017云栖大会，阿里巴巴集团 CTO 兼阿里云 CTO 行癫就开源谈了一番他的看法。

行癫在阿里历经了从技术到商业，又从商业到技术的过程，十多年的阿里生涯，让他对开源、技术和商业有了深刻了解。

开源的核心是连接，社区的根本是连接

行癫说，阿里巴巴的平台将“消费者和商家连接在了一起，这个平台不仅是个渠道，也从消费者获得了非常多一些反馈，能够快速的根据消费者的需求，来做出满足消费者要求的一些产品。我们回过头来想一下，开源社区，非常像这个模式。”

这个商业模式，其实就是将相关的人、物、关系连接到了一起，与开源的道理是一致的。

行癫认为“开源要做好，它最重要、最核心的一点，是把相关的一些开发者、用户，通过软件、工具和平台连接在一起了。”

纵观那些发展的比较好的开源软件，都是通过开源软件、通过开源的模式和开源的平台，将最优秀的开发者联系起来，将最有价值的软件用户连接起来。

互联网的本质是连接。没有互联网之前，所有的行为、所有的商业都是单向的；有互联网之后，非常非常多的连接就产生了。所以对于开源，行癫认为它“是根植于互联网的，有了互联网技术平台之后，开源能够做得更好。”

开源是生长于社区土壤中的，而社区就是一种将参与者连接起来的机制。首先通过将人连接起来，然后才能逐步考虑将来的发展，考虑如何发展和进行商业化发展。

一个开源软件在诞生之初，有可能只是表达一下对技术的理解和看法，也有可能只是解决某个痛点——大多数情况下是自己的痛点，还有可能只是好玩。至于将来能走多远，能否得到社区的迎合，能否发展出一个生态，甚至成为商业新动力，在最初往往并没有很远的计划和远景。

但是，在建立连接后，有了一个社区的土壤之后，就有了成长为一棵大树、一片森林的可能。“把人连接在一起，然后后面才是讨论核心问题，和怎么样进行商业化”。

而现在的云栖大会“也是一个连接”，通过网上直播，中国大概会有一千万左右的开发者会来参加这个云栖大会，所以“云栖大会把中国最具有活力的一群开发者，全部连接在一起了。今天这种形式的大会，本身就是一个对开发者来说，一个最重要的纽带。”

阿里为何拥抱开源

阿里巴巴最初是采用商用软件做解决方案，基于小型机、企业级的基础设施。阿里巴巴的平台三个比较大的特点，“互联网级的规模、金融级的稳定性、企业级的复杂程度。”在这种情况下，一方面，如果继续用 IOE 基础设施，随着业务规模的扩大，将来根本无法覆盖剧增的成本。另外一方面，商用软件的支持情况也难以满足业务的增长带来的各种需求。

因此，阿里巴巴发起了去 IOE 行动，全面投向开源解决方案，用开源软件构建了满足其体量和需求的基础设施。在这个过程中，阿里巴巴一方面大量采用开源软件替代传统的 IOE 基础设施，另外一方面也要面临一些前所未有的需求。

“阿里巴巴应该是最早把这么复杂的一个应用系统，全部放到开源社区的应用上的。”因此，在规模扩大了到开源软件原来很少涉及的数量级时，就会发现很多之前隐藏的场景问题。在这其中解决了无数的问题，因为面临的环境跟别人不一样，面临的要求也跟别人不一样。阿里做了非常多的工作，把他们的互联网的架构中现在社区不具备的一些功能，都纷纷补上去。自己开发了很多的中间件去满足这些功能需求。

积极回馈开源

在全面投入开源的怀抱后，阿里也积极回馈开源社区，真正使自己成为开源社区的一份子。这可以从近年来阿里加大对开源社区的赞助、代码的贡献、开源社区的扶持，以及鼓励技术人员走出去等举措上可以看出来。

在本次云栖大会上，阿里巴巴宣布了正式发布了 OpenMessaging 和 ApsaraCache 两个开源项目。此前，阿里巴巴捐赠的开源的 RocketMQ 已被 Apache 基金会接纳为全球顶级项目。

“开源和阿里巴巴都根植于互联网，有了互联网技术平台之后，开源和商业将在未来相当长的时间内保持平衡的发展。”行癫表示。

据悉， OpenMessaging 项目是由阿里巴巴发起，与雅虎、滴滴出行、 Streamlio 公司共同参与创立的分布式消息中间件、流处理领域的应用开发标准，目前已正式入驻 Linux 基金会，这也是国内首个在全球范围内发起的分布式消息领域的国际标准。

该标准可以不受编程语言限制，能满足企业对扩展性、伸缩性、隔离和安全的要求，可提供大规模的工业级支持，支持标准参照点的添加与标准化测试，开放接口便于对其他不同标准的接入，适用于金融、电商、物联网、工业互联网等行业。

“OpenMessaging 希望成为全球化、无国界、无公司边界、面向云和大数据、多行业领域的一站式方案标准，这也是阿里巴巴第一次在国际社区进行的主导和探索。” 项目负责人蒋江伟表示。

同时，在云栖大会现场，阿里云数据库负责人余锋与 Redis 创始人 Salvatore 共同宣布 ApsaraCache 在 Github 上正式开放下载。ApsaraCache 是阿里云数据库 Redis 版的分支，适用于更大的数据规模和更多的应用场景。

“ApsaraCache 项目开源是一件非常好的事情，将能够吸引全世界更多 Redis 核心专家参与，进一步提升产品的稳定性和可用性。” Salvatore 表示。

Mysql 之父、 MariaDB 创始人 Michael Widenius 已经连续三年参加云栖大会，年过 50 的他依然奋斗在代码第一线，Widenius 表示：“很多 MariaDB 的运用源自我们的开发者，维基百科用的就是 MariaDB，我们也从阿里巴巴中获得了很多开源的支持和贡献，确保能给大家提供功能丰富的数据库产品。”

图为 Mysql 之父、 MariaDB 创始人 Michael Widenius

近年来，阿里巴巴在技术领域投入不断加强，拥抱开源也由来已久，积极加入了包括自由软件基金会、Apache 软件基金会和 Linux 基金会在内的多家国际知名开源组织。目前，阿里巴巴开源和维护的开源项目超过 150 个，涵盖中间件、开发框架、数据库和各种工具类软件。在开源中国公布的“2016 年度最受欢迎中国开源软件评选 TOP20”榜单中，阿里巴巴独占 4 席。其中 Weex、Ant Design、Dubbo、Fastjson 在 GitHub 上的星标数已经破万，“Alibaba”组织在 GitHub 上星标数超过 170,000，组织排名进入前十。

开源之路

行癫认为，“开源我觉得有几个层次”，刚开始可能只是做了一个工具，这个工具做得非常好，可以解决一个非常确定性的问题。逐渐地，这个工具可能会变成一个产品、变成一个系统，慢慢延伸出一堆工具。“开源要成功，第一步要做好一个工具，第二步会变成全链的产品，我觉得最成功的就是变成新的一个生态。” 开源软件组成了一个生态，无数人为这个生态贡献了新的智慧、新的工具。融入这个生态的人，或许只用非常少的代价，就能够找到跟他的工作场景、业务场景相匹配的模式。到这个程度，“这个社区就发展得比较成熟了。这个可能是大多数开源软件必须要去走的一些路径。”

“今天要开源的其实不仅是软件，还有很多硬件”，行癫说。“今天的开源比以前的更复杂，有可能是端跟云端的结合。……互联网第一阶段的开源，是基于互联网的端建成的；互联网的第二个阶段是 IoT，我们希望所有的设备能够串起来。所以我认为接下去开源软件会与硬件结合，这就是从单纯的互联网向 IoT 时代发展非常重要的一个过程。”

结语

在近来几届云栖大会上，开源已经成为了永恒的主题，除了开源专场之外，在各个会场和论坛，充斥着各种热烈的开源气息，无数建筑于开源之上的产品、服务源源不断的开发出来，无数的技术人员和开源爱好者投身于开源世界。让我们期待云栖大会成为开源的大会，成为中国开源界和世界开源接轨的枢纽。

开源软件虽然可以免费使用，但就如同饲养一条幼犬一样（开始虽然花钱不多，后边越养越费钱）。在采用开源之前，确保能够了解其隐藏的成本和陷阱。

对于初创公司来说，开源软件是一把双刃剑。它可以成为一家创业公司的生命线，因为开源软件可以帮助初创企业快速创新，而不必从头开始。不过，正如有些人所说的，开源软件虽然可以免费使用，但就如同饲养一条幼犬一样，开始虽然花钱不多，后边越养越费钱。开源软件的真正代价是开源许可证合规成本。

滥用开源软件可能会造成获得投资的机遇被延迟或破坏。但是，如果遵守这些简单的法则，初创企业可以轻松地实现开源许可证合规。

法则一：不使用没有许可条款的软件

互联网上的一些软件不包含许可证通知，但这不意味它们可以自由使用。发布软件的人可能没有遵守上游许可条款。或者软件的作者可能尚未为其软件指定许可协议——无论是以开源方式亦或是其他方式。“没有许可条款”是指没有许可证：您应该避免使用该软件或要求作者为其该软件指定许可证。

法则二：不要违反开源许可证

开源软件的使用可能难以让其作者进行追踪，但并不意味着该软件的使用和不合规行为会被忽视。违反开源许可证可能会使初创公司面临法律责任和公众谴责，甚至可能会影响其被投资或收购。也可能导致潜在客户由于担心下游责任而拒绝购买您的产品。软件开发人员为实现其软件开源付出了巨大的努力，其中也包括上述的许可费用。滥用开源软件对这些开发人员是不公平的，并且损害了他们希望促成的创新。

法则三：跟踪您正在使用的软件

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力，因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “license.txt” 或 “copy.txt” 文件。保留该许可证的副本，并记录其涵盖的软件。大多数创业公司都使用简单的电子表格跟踪软件许可情况。

法则四：了解 宽松 （ permissive ） 许可证和 左版 （ copyleft ） 许可证

开源许可证大致分为两种类型：宽松许可证（BSD、MIT 和 Apache）和左版许可证（GPL、LGPL、Eclipse 公共许可证、Mozilla 公共许可证以及 通用开发和分发许可证 （ Common Development and Distribution License ） ）。大多数公司及其客户对于使用遵循宽松许可证的软件没有什么法律上的担心。不过，遵循左版许可证需要更加谨慎，将软件保留为专有可能会与某些特定计划不一致。

法则五：遵守许可证 通知 （ notice ） 要求

无论是宽松许可证还是左版许可证，所有开源许可都有通知要求。通常，这意味着在分发开源软件时，您需要包含其所适用的许可证的副本，仅仅包括许可证的链接或缩略形式通常是不完备的。为了避免混淆或疏离您的客户，开发一个符合大多数开源许可证的通知传送策略非常重要。

法则六：了解哪些开源许可证与分布式软件兼容

除了 Affero GPL 之外，大多数开源许可证都没有涉及软件即服务（SaaS）的情境。对于 SaaS 和云系统的分布式组件（如 JavaScript）或分布式软件（包括移动 APP 和测试版），您可以使用遵循宽松许可证的软件，但在使用遵循左版许可证的软件之前，您需要特别小心。仅在其完全在自己的进程中执行并且没有链接的代码时才去使用遵循 GPL 的软件，而不要相信以下如何让 GPL 合规的谣传：动态链接至 GPL 代码或让客户下载 GPL 软件。仅将 LGPL 软件作为动态链接库进行使用。在不修改 API 的前提下使用遵循其它左版许可证的软件。遵循移动 APP 市场的分发规定也许与遵循某些特定的左版许可证有冲突（例如 GPL 或者 LGPL）。

法则七：在咨询律师之前不要贡献或发布开源软件

贡献和发布开源软件可能是公众的福音，但它可能不是您业务上的正确选择。一旦作出贡献或发布，您在软件中拥有的任何知识产权将不大可能构成您公司估值的依据。您的律师可以帮助您更好地理解在专有和开源软件之间如何选择，并对这一重要业务决策提供指导。

法则八：确保您的员工和第三方开发人员遵守这些规则

不管是由于您的员工或第三方承包商造成的开源违规行为，所引起的法律和宣传问题都将砸在您的头上。您可以通过适当的培训和跟踪开源软件来避免这些问题。

法则九：规划未来

初创公司业务模式可以快速变化。SaaS 模式可以快速转变为分布式软件模式。无论您当前的模式是什么，遵守分布式软件的规则将为您转变为分布式软件模式提供更大的灵活性，而无需删除某些开源软件并更改相关功能。

采用这些法则将有助于初创企业利用开源软件的优势，降低您在获取投资或收购时遇到的风险。对您的初创企业感兴趣的第三方想知道您如何应对开源软件问题，确保您做好准备，并能够为他们提供积极和专业的答案。

（题图：Beth Cortez-Neavel on Flickr. Public Domain. Modified by Opensource.com）

作者简介：Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人，为客户提供技术交易和知识产权方面的建议，是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 （ Best Lawyers ） 将她提名为 2018 年年度 IT 律师。

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

使用开源的方式有利于你的盈亏底线以及开源生态系统。

“ 合规性工业联合体 The Compliance Industrial Complex ” 是一个术语，它会唤起那些组织参与精心设计并且花费昂贵流程的以遵守开源许可条款的反乌托邦想象。由于“生活经常模仿艺术”，许多组织采用了这种做法，可惜的是它们剥夺了许多开源模型的好处。本文介绍了一种经济高效的开源软件许可证合规性方法。

开源许可证通常对从第三方授权的代码分发者有三个要求：

1. 提供开源许可证的副本
2. 包括版权声明
3. 对于 copyleft 许可证（如 GPL），将相应的源代码提供给接受者。

（与任何一般性声明一样，可能会有例外情况，因此始终建议审查许可条款，如有需要，请咨询律师的意见。）

因为源代码（以及任何相关的文件，例如：许可证、README）通常都包含所有这些信息，所以最简单的遵循方法就是随着二进制/可执行程序一起提供源代码。

替代方案更加困难并且昂贵，因为在大多数情况下，你仍然需要提供开源许可证的副本并保留版权声明。提取这些信息来结合你的二进制/可执行版本并不简单。你需要流程、系统和人员来从源代码和相关文件中复制此信息，并将其插入到单独的文本文件或文档中。

不要低估创建此文件的时间和费用。虽然有工具也许可以自动化部分流程，但这些工具通常需要人力资源（例如工程师、质量经理、发布经理）来准备代码来扫描并对结果进行评估（没有完美的工具，几乎总是需要审查）。你的组织资源有限，将其转移到此活动会增加机会成本。考虑到这笔费用，每个后续版本（主要或次要）的成本将需要进行新的分析和修订。

也有因不选择发布不能被很好识别的源码而导致增加的其他成本。这些根源在于不向开源项目的原始作者和/或维护者发布源代码, 这一活动称为上游化。独自上游化一般不满足大多数开源许可证的要求，这就是为什么这篇文章主张与你的二进制/可执行文件一起发布源代码。然而，上游化和提供源代码以及二进制/可执行文件都能提供额外的经济效益。这是因为你的组织不再需要保留随着每次发布合并开源代码修改而产生的私有分支 - 由于你的内部代码库与社区项目不同，这将是越来越消耗和凌乱的工作。上游化还增强了开源生态系统，它会鼓励社区创新，从中你的组织或许也会得到收益。

那么为什么大量的组织不会为其产品发布源代码来简化其合规性工作？在许多情况下，这是因为他们认为这可能会暴露他们竞争优势的信息。考虑到这些专有产品中的大量代码可能是开源代码的直接副本，以支持诸如 WiFi 或云服务这些当代产品的基础功能，这种信念可能是错误的。

即使对这些开源作品进行了修改来适配其专有产品，这些更改也往往是微不足道的，并包含了很少的新的版权部分或可用来专利的内容。因此，任何组织都应该通过这种方式来查看其代码，因为它可能会发现其代码库中绝大部分是开源的，只有一小部分是真正专有的、与竞争对手区分开来的部分。那么为什么不分发和向上游提交这些没有差别的代码呢？

考虑一下拒绝遵从工业联合体的思维方式, 以降低成本并大大简化合规性。使用开源的方式，并体验发布你的源代码的乐趣，以造福于你的盈亏底线和开源生态系统，从中你将继续收获更多的利益。

作者简介

Jeffrey Robert Kaufman - Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商红帽公司的开源知识产权律师。Jeffrey 还担任着 Thomas Jefferson 法学院的兼职教授。 在加入红帽前，Jeffrey 在高通担任专利法律顾问，为首席科学家办公室提供开源顾问。 Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。更多关于我

（题图： opensource.com）

via: https://opensource.com/article/17/9/economically-efficient-model

作者：Jeffrey Robert Kaufman 译者：geekpi 校对：wxy

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

基于 Linux 击败了专有软件一样的原因，开源应该成为云原生环境的首选。

让我们回溯到上世纪 90 年代，当时专有软件大行其道，而开源才刚开始进入它自己的时代。是什么导致了这种转变？更重要的是，而今天我们转到云原生环境时，我们能从中学到什么?

基础设施的历史经验

我将以一个高度武断的、开源的视角开始，来看看基础设施过去 30 年的历史。在上世纪 90 年代，Linux 只是大多数组织视野中一个微不足道的小光点而已——如果他们听说过它的话。你早早购入股票的那些公司们很快就发现了 Linux 的好处，它主要是作为专有的 Unix 的廉价替代品，而部署服务器的标准方式是使用专有的 Unix，或者日渐增多的使用 Microsoft Windows NT。

这种模式的专有本性为更专有的软件提供了一个肥沃的生态系统。软件被装在盒子里面放在商店出售。甚至开源软件也参与了这种装盒游戏；你可以在货架上买到 Linux，而不是用你的互联网连接免费下载。去商店和从你的软件供应商那里只是你得到软件的不同方式而已。

Ubuntu 包装盒出现在百思买的货架上

我认为，随着 LAMP 系列（Linux、Apache、MySQL 和 PHP / Perl / Python）的崛起，情况发生了变化。LAMP 系列非常成功。它是稳定的、可伸缩的和相对用户友好的。与此同时，我开始看到对专有解决方案的不满。一旦客户在 LAMP 系列中尝过了开源的甜头，他们就会改变他们对软件的期望，包括：

• 不愿被供应商绑架，
• 关注安全，
• 希望自己来修复 bug ，以及
• 孤立开发的软件意味着创新被扼杀。

在技术方面，我们也看到了各种组织在如何使用软件上的巨大变化。忽然有一天，网站的宕机变成不可接受的了。这就对扩展性和自动化有了更多的依赖。特别是在过去的十年里，我们看到了基础设施从传统的“宠物”模式到“群牛”模式的转变，在这种模式中，服务器可以被换下和替换，而不是一直运行和被指定。公司使用大量的数据，更注重数据留存和数据到用户的处理和返回速度。

开源和开源社区，以及来自大公司的日益增多的投入，为我们改变如何使用软件提供了基础。系统管理员的岗位要求开始 要求 Linux 技能和对开源技术和理念的熟悉。通过开源类似 Chef cookbooks 和 Puppet 模块这样东西，管理员可以分享他们的模式配置。我们不再单独配置和调优 MySQL；我们创建了一个掌控基础部分的系统，我们现在可以专注于更有趣的、可以给我们雇主带来更高价值的工程作业。

开源现在无处不在，围绕它的模式也无处不在。曾经仇视这个想法的公司不仅通过协同项目与外界拥抱开源，而且进一步地，还发布了他们自己的开源软件项目并且围绕它们构建了社区。

转向云端

今天，我们生活在一个 DevOps 和云端的世界里。我们收获了开源运动带来的创新成果。在公司内部采用开源软件开发实践的情况下， Tim O'reilly 所称的 “内部开源” 有了明显增长。我们为云平台共享部署配置。像 Terraform 这样的工具甚至允许我们编写和分享我们如何部署特定的平台。

但这些平台本身呢？

“大多数人想都不想就使用了云……许多用户将钱投入到根本不属于他们的基础设施中，而对放弃他们的数据和信息毫无顾虑。" —Edward Snowden, OpenStack Summit, May 9, 2017

现在是时候要更多地想想本能地转移或扩展到云上的事情了。

就像 Snowden 强调的那样，现在我们正面临着对我们的用户和客户的数据的失控风险。抛开安全不谈，如果我们回顾一下我们转向开源的原因，个中原因还包括被厂商绑架的担忧、创新难以推动、甚至修复 bug 的考虑。

在把你自己和/或你的公司锁定在一个专有平台之前，考虑以下问题：

• 我使用的服务是遵循开放标准，还是被厂商绑架的？
• 如果服务供应商破产或被竞争对手收购，什么是我可以依赖的？
• 关于停机、安全等问题，供应商与其客户沟通中是否有一个明确而真诚的历史过往？
• 供应商是否响应 bug 和特性请求，即使那是来自小客户？
• 供应商是否会在我不知情的情况下使用我们的数据（或者更糟，即便我们的客户协议所不同意）？
• 供应商是否有一个计划来处理长期的，不断上升的增长成本，特别是如果最初的成本很低呢？

您可以通过这个问卷，讨论每个要点，而仍然决定使用专有的解决方案。这很好，很多公司一直都在这么做。然而，如果你像我一样，宁愿找到一个更开放的解决方案而仍然受益于云，你确实有的选择。

基于私有云

当您寻找私有云解决方案时，您的首选是开源，投资一个云提供商，其核心运行在开源软件上。 OpenStack 是行业领袖，在其 7 年的历史中，有 100 多个参与组织和成千上万的贡献者（包括我）。 OpenStack 项目已经证明，结合多个基于 OpenStack 云不仅是可行的，而且相对简单。云公司之间的 API 是相似的，所以您不必局限于特定的 OpenStack 供应商。作为一个开放源码项目，您仍然可以影响该基础设施的特性、bug 请求和发展方向。

第二种选择是继续在基础层面上使用私有云，但在一个开源容器编排系统中。无论您选择 DC/OS（基于Apache Mesos) 、Kubernetes 或 Docker Swarm 模式 ，这些平台都允许您将私有云系统提供的虚拟机作为独立的 Linux 机器，并在此之上安装您的平台。您所需要的只是 Linux 而已，不会立即被锁定在特定云的工具或平台上。可以根据具体情况来决定是否使用特定的专属后端，但如果你这样做，就应该着眼于未来。

有了这两种选择，你也可以选择完全离开云服务商。您可以部署自己的 OpenStack 云，或者将容器平台内部架构移动到您自己的数据中心。

做一个登月计划

最后，我想谈一谈开源项目基础设施。今年 3 月，在召开的 南加州 Linux 展会 上，多个开放源码项目的参与者讨论了为他们的项目运行开源基础设施。（更多的，请阅读我的 关于该会议的总结）我认为这些项目正在做的这个工作是基础设施开源的最后一步。除了我们现在正在做的基本分享之外，我相信公司和组织们可以在不放弃与竞争对手相区分的“独门秘方”的情况下，进一步充分利用他们的基础设施开源。

开源了他们的基础设施的开源项目，已经证明了允许多个公司和组织向他们的基础设施提交训练有素的 bug 报告，甚至是补丁和特定论文的价值。突然之间，你可以邀请兼职的贡献者。你的客户可以通过了解你的基础设施，“深入引擎盖子之下”，从而获得信心。

想要更多的证据吗？访问 开源基础设施 的网站了解开源基础设施的项目（以及他们已经发布的大量基础设施）。

可以在 8 月 26 日在费城举办的 FOSSCON 大会上 Elizabeth K. Joseph 的演讲“基础架构开源”上了解更多。

（题图：Jason Baker. CC BY-SA 4.0. Source: Cloud, Globe. Both CC0.）

via: https://opensource.com/article/17/8/open-sourcing-infrastructure

作者：Elizabeth K. Joseph 译者：wenzhiyi 校对：wxy

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