开源数据库 Licensing 定义的 “烦人” 原因？ （译）

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2780人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，8群近260+ 9群)

正文

过去几年，涌现出许多呼吁改进《开源定义》（OSD）以适应现代世界的呼声。一些人希望看到像服务器端公共许可证 (SSPL) 或 Elastic 许可证这样的非竞争性许可证被视为开源。另一些人则从伦理角度出发，思考“使用软件为善而非作恶”。还有一群人非常关注隐私，他们认为强大的隐私保护需要作为一项标准纳入开源定义。

然而，我从所有这些讨论中得到的结论是，几十年前由一小群团结的自由和开源软件爱好者组成的群体，已经发展演变成多个拥有不同需求和不同愿景的群体。当前试图将整个软件领域划分为开源软件和专有软件的论述并无益处。拥有伦理或非竞争限制的源代码可用许可证的支持者们，理所当然地不认为自己与你无法访问源代码并且可能被阻止做其他事情的铁杆专有软件属于同一阵营。

此外，开源本身也有很多不同的层次。根据 BSD 许可证条款获得许可的软件与根据 AGPL 3.0 获得许可的软件，你在实际使用中可以做的事情有很大不同。每种许可证的存在都有其原因。

这段话主要阐述了以下几个观点：

对开源定义的挑战： 随着时代发展，人们对“开源”的理解和期望变得多样化，传统的《开源定义》面临着被重新审视和改进的呼声。 不同类型的许可证： 除了传统的开源许可证外，还出现了像 SSPL 和 Elastic 许可证这样的非竞争性许可证，以及强调伦理和隐私的许可证。这些许可证的出现模糊了开源和专有软件之间的界限。 开源内部的多样性： 即便是在传统的开源领域，不同的许可证（例如 BSD 和 AGPL 3.0）也赋予了用户不同的权利和义务，体现了开源本身的多样性。 二元划分的局限性： 将所有软件简单地划分为“开源”和“专有”已经无法准确描述当前的软件生态，需要更 nuanced 的分类和理解。 作者认为，开源社区已经不再是铁板一块，而是分化成了多个群体，各自有着不同的诉求。简单地将软件区分为“开源”或“专有”已经无法满足当今软件生态的复杂性，需要更细致的划分和理解。

如今，开源变得越来越两极分化。一部分人坚持 OSD（开源定义）以及专注于社区或基金会模型的项目，另一部分人是单一供应商驱动的商业开源项目，它们越来越多地引入非 OSD 许可证来保护其地位和竞争优势，但仍然希望获得开源在社区、市场覆盖和开发者访问方面提供的好处。任何以这种方式分裂的市场，对最终的参与者——开发者来说，都会变得不那么有用。我认为处理这种情况的最佳方式，不是简单地固执地争论要获得一个单一的现代化的开源定义，而是拥抱多样性，并就如何描述软件许可领域达成一致，在这个领域中，各种类型的许可证都有其存在的空间。

我使用以下列表来展示不同的许可证在整个软件许可领域中的位置：

这段话解释了当前关于开源定义的辩论的起因，并提出了作者的观点。主要内容包括：

开源领域的分裂： 开源领域出现了两类项目：

一类坚持传统的 OSD 和社区/基金会模式。

另一类是商业公司主导的，使用非 OSD 许可证但仍然希望利用开源的优势。 市场分裂的危害： 这种分裂对开发者不利，因为它使得开源生态变得更加混乱和难以理解。

作者的观点： 作者认为，与其争论一个统一的“现代化”开源定义，不如拥抱许可证的多样性，并建立一个清晰的框架来描述各种许可证，承认它们各自的价值和适用场景。 引入许可证列表： 作者接下来会提供一个列表，用于展示不同许可证在软件许可领域的位置。

总而言之，这段话强调了当前开源领域面临的挑战，并提倡以更加包容和务实的态度来对待不同的许可证类型。

这是一篇关于软件许可证的入门读物，它对各种许可证进行了分类和解释，并探讨了当前关于开源定义的辩论。以下是翻译和总结：

许可证快速入门（简化版）

经典专有软件： 涵盖 Windows、Mac OS、iOS 以及我们日常使用的许多其他软件。所有此类软件通常都有独特的最终用户许可协议 (EULA)，用户在购买或使用时需要接受。用户通常无法访问其完整源代码。 源代码可用： 这类许可证允许你查看源代码，但不赋予你以任何你认为合适的方式使用该软件的权利。例如，它可能不允许你在某些情况下使用或重新分发修改后的软件，因此你无法获得开源所期望的自由。 开源（Copyleft，著佐权/传染性）： 涵盖 GPL 和 AGPL 等开源软件许可证，它们要求衍生作品以相同的许可证分发，因此，理论上要求社区从变更和改进中受益。另一方面，这意味着此软件无法嵌入任何商业软件中，这在实践中会降低其采用率。此外，许多软件不是以分发的形式提供，而是以服务的形式提供。这些许可证通常无法实现其确保软件变更与社区共享的最初目的。 开源（Permissive，宽松型）： 例如 BSD、MIT、MPL 和 APL 等许可证是开源的，但与 Copyleft 许可证不同，它们通常允许软件嵌入其他软件中，即使是专有软件。 公共领域： 意味着没有人主张任何知识产权，可以不受任何限制地使用。例如，一些开源许可证要求你保留版权信息，而公共领域则没有此类限制。 许可证的分类和比较

作者采用了一种单维方法，根据原始开发者或供应商保留的权利与他们赋予软件用户关于代码及其使用方式的权利进行比较，对许可证进行排名。当你发布最大限度赋予用户自由的软件时，你允许他们将软件用于任何目的，包括与你竞争或将其用于可能不符合你伦理的目的。

作者将“源代码可用”许可证进一步细分为以下几类：

伦理源代码： 这可能是最好的源代码可用许可证，因为它们倾向于最大化公共利益，而不是确保某个参与者处于特权地位。即使此许可证的创建意图良好，但它可能会在控制谁是软件最终用户以及软件用于什么目的方面增加许多不切实际的摩擦。 非竞争性许可证： 这是当今涌现的软件许可证。它们专注于使软件和代码可供像开发者这样的群体使用，同时也帮助一个供应商（通常是开源项目的创建者）保留围绕谁可以使用该软件的额外权利。这使得这些供应商可以轻松地将其软件货币化。另一方面，这种市场捕获可能会导致实际使用该软件的公司或个人的成本增加和选择受限。许多非竞争性许可证目前都侧重于云交付（SSPL、Elastic 2.0）。过去，我们也看到过一些旨在防止在支持订阅和专业服务方面进行竞争的许可证。HashiCorp 使用其 BSL 许可证采用了这种方法，该许可证限制了对公司软件项目的任何竞争性使用。这里的挑战是谁来决定哪些项目是“竞争性的”；如果没有严格的定义，这可能会对超出原始许可证设计范围的更广泛的市场产生寒蝉效应。 参考源代码： 虽然我们现在看不到很多这种类型的许可证，但它是最早的源代码可用许可证类型之一。例如，微软的共享源代码许可证允许你作为客户查看源代码，以执行安全审查，但它没有提供更多。 所有这些组中的许可证都可以借鉴 Copyleft 或 Permissive 开源许可证的思想。例如，SSPL 基于 AGPL，因此与开源 Copyleft 许可证有很多相似之处，而 HashiCorp 的 BSL 变体只要你不与 HashiCorp 竞争，就更类似于开源 Permissive 许可证。

此外，我们可以将源代码可用许可证视为“永久源代码可用”或“最终开源”。永久源代码可用软件很简单——它开始是源代码可用软件，并且仍然是源代码可用软件。最终开源许可证开始是源代码可用，然后在给定的时间后使软件的源代码以开源形式提供。根据最近的例子，最常见的时间范围是三到四年。你可以将其与知识产权专利进行比较，专利最终会过期，并允许发明在足够长的时间后被所有人使用。商业源代码许可证 (BSL) 是该领域唯一广泛使用的许可证。但请注意，与 20 年后好主意往往仍然是好主意的专利不同，到任何代码转换为开源许可证时，它往往已经过时。根据相关供应商的承诺，这可能会导致无人维护的、充满安全漏洞的代码，随着时间的推移，对用户或社区提供的价值非常有限。

为什么定义很重要

软件许可可以追溯到 20 世纪 60 年代最初决定用版权保护软件的决定。在此之前，不可能将软件与其运行的硬件分开，因此人们认为价值在于购买的硬件。今天，云是软件运行的地方，许多人——IT 人员、开发人员和商业人士——都将云定义为价值的来源。它让你可以在需要时以及需要的时间内轻松运行软件。但这同样忽略了软件本身的价值。

我们需要各种各样的软件许可证来满足那些开发软件的人围绕其代码提出的要求，从保护其知识产权到建立可持续发展的业务。所有这些许可证都是可选的。专有软件和源代码可用软件的倡导者将始终认为他们的方法使企业和开发人员更容易。

挑战在于，对于许多开发人员来说，在源代码可用性和社区对项目的控制真正重要之前，开源并不重要。开发人员确实需要易用性、易访问性以及能够响应其需求的软件。他们是因为开源而不是云而获得了这些。云同样可以以易于使用的名义将其夺走。

为了支持开源并使其在未来保持活力，我们需要考虑围绕软件许可的选择，以及我们如何满足开发人员围绕他们创建、贡献和使用的软件的不同需求。但是，作为其中的一部分，我们还需要更明确地说明开源的含义以及可以定义为开源的内容。对于我们这些在社区中的人来说，我们还需要牢记为什么开源为社区以及为那些为支持这些项目并使其长期保持活力的商业实体提供价值。

总而言之，这段话详细解释了各种软件许可证的类型和特点，并强调了定义清晰的软件许可生态系统的重要性，以平衡开发者、商业实体和社区的需求。文章也暗示了当前“源代码可用”许可证的兴起以及由此带来的挑战，并呼吁对“开源”的定义进行更严格的规范。