开源许可证的仲裁者

开源与大多数人类努力的领域一样，拥有使其能够运作的机构和规则。最近，开源社区在许可方面受到了挑战。这是一个说明问题的场景。

想象一下你在观看一场棒球比赛，投手决定他今天不想投球，所以他设置了一台机器来代替他投球。双方的球迷都会想，“这是在开玩笑吗？这不是棒球，这是怎么回事？” 裁判（裁判员）会停止比赛，并让人移除机器，可能也会移除投手。这就是为什么联盟聘请裁判来执行规则。他们确保规则得到遵守，以维护比赛的完整性。

现在想象一下，一群开发人员将其源代码公开。首先，他们根据 MIT 或 Apache 等流行的许可证为代码授权。随着时间的推移，并且软件变得越来越流行，作者决定他们需要编辑许可证以适应其业务需求。他们可能仍然称其为“开源”，但该许可证可能不再符合开源的条件。正确的术语可能更应该是“源代码可用”。（稍后会详细介绍。）

许多开发人员误以为“如果一个项目在 GitHub 或 GitLab 上，它就是开源的。” 但是，如果没有许可证，源代码默认受版权保护，而不是开源的。即使一个项目有一个 LICENSE 文件，如果它没有提供 开源定义 中概述的权利，它仍然可能是冒牌货。这就是为什么开源为开源许可证建立了仲裁机构。

它是否经过 OSI 批准？

开源促进会 (OSI) 可能是最广泛接受的开源社区仲裁机构，它代表了来自各行各业的人员和公司成员。就像棒球裁判一样，他们确保开源许可证遵守 规则。提交给 OSI 的许可证会经过严格且有时漫长的审查过程，开源社区成员会在其中辩论许可证是否符合开源定义。

一个项目使用未经 OSI 批准的许可证但发布其源代码，则可能被视为“源代码可用”。根据 维基百科，“源代码可用 软件是通过源代码分发模型发布的软件，该模型包括可以查看源代码的安排，在某些情况下可以修改源代码，但不一定满足被称为开源的标准”（强调部分由添加）。

以下是两者之间的一些区别

如何选择开源许可证

过去，很难理解许可证之间的区别。现在情况已不再如此。人们整理了大量资源来解释开源许可证之间的区别，以及在何种情况下特定许可证可能比另一种许可证更好。如有疑问或对于复杂情况，请咨询您的律师。以下是一些关于开源许可证的优秀资源

• 选择开源许可证
• TL;DR Legal：开源许可证
• OSI：流行的开源许可证 
• SPDX 许可证列表
• DFSG 和软件许可证

如何加强开源

没有理由反对 源代码可用 软件。但是，对于我们作为开源社区的成员来说，清楚地了解“开源”和“源代码可用”之间的区别，以及哪些软件正在使用 OSI 批准的许可证或未使用，这一点非常重要。OSI 在这里是仲裁者。

给开发者社区的注意事项

1. 认识到“源代码可用”不是“开源”。
2. 认识到 OSI 批准的许可证是开源的基础。
3. 了解开源定义，以避免因源代码可用许可证而失去权利。
4. 在为没有 OSI 批准许可证的项目做出贡献之前仔细选择。
5. 通过成为会员来支持 OSI。他们是捍卫开源定义的第一线人员，而我们许多人认为这是理所当然的。
6. 在 Sustain Open Source 论坛 上讨论许可和其他开源问题。

感谢维护者 Serkan Holat 和 Hank Grabowski 帮助我们撰写这篇文章。