Google Code 早在很久以前就尝试解决这个问题。从 2006 年到 2010 年，你得到了一个大约 7 到 9 个可能的许可证选项的下拉菜单。就这样。结束了。不允许许可证的创造性。他们希望减少许可证的扩散，你上面谈到的那种混乱，以及个别作者对许可证的细微定制。他们发布了对其政策的辩护，无论每个人是否喜欢，这都是站得住脚的。但自由市场当然可以选择其他东西。我敢打赌，如果 GitHub 愿意，它可以提出自己的理由。
2010 年，Google Code 放宽了限制，允许使用一个包罗万象的菜单选项，“其他开源”许可证。因此，一个项目被引导到 9 个常见的许可证，从而减少了扩散，但具有更具体需求的项目不会像以前那样被拒绝。这是一个合理的菜单驱动的社会工程。
“专业”软件开发人员有其他理由避免业余项目，而不仅仅是许可证的模糊性。因此，将许可证的模糊性作为“我们不帮助你”的主要原因是不真诚的。年轻人有很多关于如何使一个开源项目对其他人有价值的东西需要学习，而这仅仅是其中之一。
在评估一个项目时，“你是否真的发布了一些可以工作的东西？”在我的优先事项列表中要高得多。我高度怀疑任何持续存在于源代码库中，并且从不发布官方文件版本或软件包的项目。我对看看我是否可以构建你的软件不感兴趣！绝大多数具有这种态度，即构建软件是我的工作，的项目都有糟糕的构建，无法工作。我对决定一个项目是否值得的时间和精力障碍不感兴趣；如果他们如此不关心我作为潜在消费者或贡献者的时间，那么这个项目可能不值得。
在邮件列表或论坛上没有沟通是一个糟糕的迹象，尤其是当缺乏沟通已经持续多年时。项目开始之初的大量沟通是一个糟糕的迹象，“嘿，让我们启动一个邮件列表！”现象。如果他们停止喋喋不休并做任何实际工作，请稍后查看。
我更同情“只需提交该死的代码”的文化，而不是不同情。至少这是一种完成事情的文化。因此，它可能不会产生完全可用的许可证。也许它会崩溃并烧毁。孩子们必须以某种方式学习，而且大多数开源努力无论如何都会因各种原因而失败。他们要么会重新站起来并再次尝试，吸取教训，要么就不会。
多年来，我遇到过不止几个项目，这些项目贴上了 GPL 或 LGPL。如果我足够关心他们正在做的事情的价值，我会问他们为什么不提供 LGPL 或 MIT / BSD / zlib 许可证。一般来说，我对 Copyleft 限制不感兴趣，并寻求减少它们，这取决于库所做的任何合理的事情。我为激烈的回应做好准备。但通常情况下，开发人员根本没有对许可证进行太多思考，而是抓住了他们在开源领域谈论的第一个东西。
Google Code 早在很久以前就尝试解决这个问题。从 2006 年到 2010 年，你得到了一个大约 7 到 9 个可能的许可证选项的下拉菜单。就这样。结束了。不允许许可证的创造性。他们希望减少许可证的扩散，你上面谈到的那种混乱，以及个别作者对许可证的细微定制。他们发布了对其政策的辩护，无论每个人是否喜欢，这都是站得住脚的。但自由市场当然可以选择其他东西。我敢打赌，如果 GitHub 愿意，它可以提出自己的理由。
2010 年，Google Code 放宽了限制，允许使用一个包罗万象的菜单选项，“其他开源”许可证。因此，一个项目被引导到 9 个常见的许可证，从而减少了扩散，但具有更具体需求的项目不会像以前那样被拒绝。这是一个合理的菜单驱动的社会工程。