您可能最终会将JSHint用于邪恶

重新发放JSHINT许可证的过程花了七年时间。这比任何人预期的都要长得多，但坚持到底不仅仅是耐力的问题。ASI与世界各地的人一起工作，以转移到MIT Expat许可，我经常体验到非自由许可(甚至像“好的，不是坏的”这样看似微不足道的)是如何毒害自由软件的。

在这里，一些数字可能会有所帮助。下图显示了在过去五年中，每周从NPM下载JSHinthas的次数：

我们去年有过低迷，但后来又恢复了，而且还有所回升。每周超过50万的下载量听起来确实令人印象深刻，不是吗？

2015年给人留下了深刻的印象。事实是，NPM的使用在过去的五年里呈爆炸式增长。在这个空间保持稳定实际上是落后的。看看ESLint的相同统计数据，这是一个与JSHint具有相同目的和目标受众的真正开源项目：

突然之间，2019年的下跌似乎不那么重要了。JSHint是如何从这个领域最流行的工具变成今天大多数开发人员都认为过时的工具的呢？有很多解释，但在这篇文章中，我将集中讨论非免费许可的影响。

JSHint的部分许可是在JSONLicense下进行的。它与广泛使用的MIT Expat许可证几乎相同，但它包含一个附加条款：

由于这一条款，尊重软件许可实践的人们根本不能使用JSHint。

如果你不精通法律事务，这可能看起来是个奇怪的限制。通过拒绝JSHint，人们是否承认他们想做坏事？不管怎么说，这一条款实际上是可以执行的吗？

第二个问题的答案是“不”，这有助于回答第一个问题。有法律意识的反对者并没有背叛他们自己卑鄙的动机；他们拒绝签订一份模棱两可的合同。不同的是：他们不是说，“我是个恶人”，他们是说，“我不明白你想要什么。”这一考虑取消了JSHint在各种上下文中的排除资格。

首先，有法律意识的软件库。Debian和FedoraGNU/Linux发行版的开发人员独立得出结论，由于许可问题，他们不能包含JSHint。这就是为什么Ubuntuuser不能通过sudo apt-get install jshint下载JSHint。

即使在眼光不太敏锐的包管理器中，人们也构建了工具来授权开发人员自己做出类似的决定。例如，JSHint从最初发布以来就在NPM上可用，但是SPDX(以及像License-Report和Yarn这样的工具)后来被设计用来帮助人们理解他们依赖的法律要求。这似乎是一个鼓励人们认真共享代码的趋势，所以我们在JSHint中采用了SPDX来做我们的一部分。

最近，一位美国大学的讲师写信给JSHint团队，请求允许在他们的课程中使用JSHint。我回答说，

当然，欢迎您在您的课程中使用该项目及其网站。但是请注意，源代码部分是在JSON许可下发布的。FSF不承认这是一个软件许可证，开放源码倡议也不承认它是一个开放源码许可。这一细节在实践中确实会影响到大多数人，但是在依赖代码库之前，您可能需要与您的法律团队进行验证。

诚实可能是最好的策略，但这也意味着更少的人会使用你那令人费解的JavaScript Linter。

最后，由于许可证问题，“重新打包”JSHint的编程平台重新考虑了这种做法。曾经有一段时间，流行的内容管理系统WordPress就是这样重新打包JSHintin的。一旦他们了解到JSON许可证，他们就在几周内更换了JSHint。

很多人对自由软件不屑一顾。无论出于什么原因，他们都不能不关心与公开源代码捆绑在一起的法律术语。“好的，不坏的”条款也把他们拒之门外，尽管他们没有意识到这一点。

它始于对许可证敏感的用户数量的下降。“用户”这个词在开源工具的上下文中是位被动的，因为使用该软件的人特别有权回馈它。“用户群”与“贡献者群”直接相关。当像JSHintt这样的项目失去用户时，它也会失去贡献者。

这会减慢添加新功能和纠正错误的速度。时间安排对这些事情很重要，人们对延误的看法非常负面。最好的例子来自JSHint对异步函数的延迟支持。

(异步函数是2017年引入的JavaScript语言特性。它在开发人员中非常流行，但解析器也很难正确实现。我们花了一年多的时间才在JSHint中支持它。)。

异步/等待已经处于第四阶段一个多月了(并且已经在Node和许多主流浏览器中进行了更长时间的烘焙)，但是jshint还没有增加对它的支持。

“我知道你对此有很多抱怨，但是…。如果您找不到包含异步/等待支持的方法，那么jshint对我来说毫无用处。我正在切换到仅使用node-c<；filename>；“(通过电子邮件)。

互联网有一种方式可以让最响亮和最愤怒的观点浮出水面，但似乎可以放心地假设，有相当一部分不那么直言不讳的开发商得出了类似的结论。

用户/贡献者基数不断减少是一个恶性循环。虽然这场运动可能是从有执照意识的人开始的，但每个人都同样感受到了放行周期的痛苦，他们的离开加剧了问题。

不过，这不仅仅是一个关于开源“市场”力量的故事。我自己的管理决策导致了JSHint不令人满意的发布周期。

你看，很多人使用一系列的版本来表达他们对软件的依赖。他们不会说，“给我火狐版本67.02.3”，因为他们并不真正关心那个版本。他们想要的是软件既熟悉又安全。他们更可能会说，“给我最新版本的Firefox67。”通过这一声明，他们相信Firefox的维护人员会提供一个外观和行为都与65或68版完全不同的程序，但也有最新的错误修复(因此，67.02.4比67.02.3更可取)。

这种做法通常使用户和开发人员受益。然而，在我的例子中，我有一个相互冲突的个人目标：我希望JSHint的老版本能接触到尽可能多的人。

如果我们对JSHint进行重大改进，我们将不得不发布一个新的主版本。新版本的重新授权工作可以继续，但很多人会继续使用旧版本。尽管这些年来我一直在为JSHint着迷，但我没有忘记，大多数人并不特别关心他们的JavaScript linter的发布时间表。当我们成功时，旧版本的用户将与我们的成功隔绝(更不用说我们从那时起所做的改进)。

考虑到这一点，我反对对JSHint进行剧烈的更改。对于项目维护人员来说，这是非常合适的。

对于许多人来说，许可是软件开发中深奥的一部分。这是一个相关的观点：法律框架令人望而生畏，大多数考虑因素可以通过简单地默认使用众所周知的免费/开放源码许可证来解决。

问题是，并不是所有的软件都是在众所周知的自由/开放源码许可下分发的。我希望JSHINT的细节能帮助人们理解为什么许可很重要。

在阅读了JSHint缓慢衰落的苦差事后，你可能会奇怪为什么我们没有放弃。只有当你珍视这艘船时，沉船才是悲剧。如果有一艘更新、更快、名字相近的船驶过，那么也许是时候放下救生艇了。要全面解决这一问题，还需要另一篇文章。