对您来说，软件是“可用源”而不是“开源”对您来说是否重要

您可能知道OSI正式批准的开源许可证列表。最值得一提的是，我猜应该是GPL，MIT，[在此处插入您喜欢的许可证]。

我最近遇到了一个项目，该项目虽然是开源的（创建者提供了所有源代码），但在其中一个正式许可下并不是正式开源的。

• 它发布了源，但没有承诺将来发布源。

• 它允许修改建议，但不承诺接受补丁程序，并且不允许外部分发外部补丁程序版本。

• 它允许在商业或付费项目中使用该软件，但不允许出售该软件本身。

我想我们可以将其称为“可用资源”，而不是开放源代码。

我可以看到为什么公司的管理团队不想使用此软件开展业务。他们不能分叉，不能出售，也不能创建自己的软件版本来分发或出售。

但是，作为仅使用此软件的软件工程团队的一部分，这对您来说重要吗？我仍然可以用它来完成工作，可以在有偿的项目中使用它（但是我不能出售软件本身，无论如何我都不会从事这项工作），并且我可以对代码进行更改以使其行为能够满足我的需要（但我不能公开这些修改），如果我确实希望将这些修改正式提供给其他人，则批准取决于项目本身，他们选择是否是否将它们合并到正式版本中。

因此，我们知道，一家公司希望基于此“可用源”软件来开展业务，但是不能做到这一点，但是作为软件工程团队中的某个人，这些差异对您来说是否重要，或者它们似乎无关紧要？

很好奇别人对此的看法。

对于那些必须从头开始开发此软件提供的功能的项目，这样做绝对是很方便的。

但是，具有可比性的开源软件包是否会更好取决于其他因素：

• 它将用于提供某些服务还是将其捆绑为另一产品的一部分？
• 他们是否有资源独立地增强和维护产品？
• 与开源版本相比（在代码或项目管理中）使用此软件是否有竞争优势？

对这些因素中的任何一个回答为否，表明OSS是更好的选择。

大多数时候，代码本身不是决定因素。人们需要审视大局。

SIDEBAR OSS项目不能合法地保证它们将保持将来的版本开放，或者会有将来的版本。这就是为什么拥有开放许可证如此有利的原因之一。另外，OSS项目也不需要接受贡献者提供的补丁（尤其是没有所有权或权利的转移）。

这个问题以及其他任何外部库的问题都是维护。

您的应用程序的寿命是多少，该库的表观寿命是什么？希望您的时间最短。

谁将对此库进行错误修复？从这里看起来，您的公司将来应该明确分配资源来维护该软件，因为您不能依靠任何其他修复错误。您无法与其他人分担维护负担，因为您无法共享源。想要找出您不知道的代码中难以捉摸的种族条件错误吗？

仅凭这种想法可能会使该库使用起来过于昂贵。

如果该库非常坚固，健壮并且易于在源代码级别使用，则这可能无关紧要，但是我的经验是，真正的开源项目的同伴压力只会使代码变得更好，因为您倾向于尽力而为。

就我个人而言，如果要采用此代码或任何其他外部代码，我会非常谨慎，因为使用其他人的代码的全部原因是您不必自己处理它。还要考虑将来的维护者-您应该在库中进行防火练习更改代码，以查看它是否可以完成。这里可能会有一些非常令人讨厌的惊喜。

您有自由讨论有问题的图书馆吗？

老实说，我不明白为什么公司的管理团队在使用这种“可用源”库时会遇到问题。就集成到自己的产品而言，他们可以将其视为一个封闭源代码库。

对我而言，作为一名程序员，库是“开源”还是“可用源”都没有关系。我不希望对外部库进行本地修改，因为这意味着额外的维护负担。不仅是在我的本地修改中发现错误时，而且还在库的新版本发布时一次又一次地集成修改时。

恕我直言，“开放源代码”击败问题中概述的“可用源代码”许可证的唯一情况是何时

• 我们产品的许可还要求披露所包含库的来源
• 我们正在生产该库的增强/扩展版本

这就是自由软件基金会使用术语“自由”或“非自由”来描述软件的原因。它们不是指价格，而是对软件使用或发行的限制。

似乎您碰到了极少数情况，在这种情况下您可以完全访问某物的源代码，但是按OSI定义，该软件不是“开放源代码” 。

任一个词都有能力成为错误的名词。我为第一份emacs（在QIC磁带上）支付了50美元，但是emacs是免费软件。我拥有公司内部使用的某些专有应用程序的源代码，但它们不是开源的。

引起最大危险的事情（至少对我来说）是不能保证访问将来版本的源代码。如果您严重依赖于能够修改此工具，请注意。即使您与供应商达成口头协议，您也将始终拥有代码，除非它采用合同形式..该协议永远不会发生。

作为首席技术官，我尽力确保我们不依赖非自由软件。过去，我几次都处于供应商锁定的糟糕境地，这是我想避免的错误。尽管我们确实使用了一些专有的东西，但是如果突然之间我们不再使用它，我们的业务也不会遭受不适当的困难。

在我看来，您正在围绕使用此软件和访问代码来构建东西，因此，我建议您以书面形式获得表明您将始终具有访问权限的信息。如果购买了供应商会怎样？

这确实很重要。您描述的“可用源”方法的主要问题：

• 如果您没有修改源代码的自由，那么您将无法控制自己的技术命运。通常，直接破解源代码可能比使用混乱的解决方法更可取。
• 您不能保证该软件将继续得到维护，并且您没有使用真正的开源软件自己做的后备选项。
• 由于它听起来像是自定义许可证，因此与使用诸如GPL或BSD许可证之类的众所周知且经过验证的许可证相比，您可能会有更大的法律风险。
• 如果它不是真正的开源项目，那么您将获得与它同样程度的有用社区，这对许多开源项目来说都是一个主要优势

我的建议：尝试说服创建者在开放源代码许可下发布该软件。对于每个人来说，这应该是一个双赢的局面-您是因为您在开源许可下获得了所需的软件，而创建者是因为从长期来看使该项目开源可能使该软件更加成功。