有关选择哪种许可证的软件的建议和经验？

软件开发人员可以根据工作目标选择适当的许可证。

任何人都可以就选择哪种许可证提供一些建议/经验吗？

“放弃”所有编码工作作为开源代码的利弊是什么？

如何与希望从研究代码中受益的行业参与者打交道？

任何人都可以就选择哪种许可证提供一些建议/经验吗？

选择哪种许可证将取决于您希望代码有多自由，但是对于不同的人来说，自由意味着不同的事情。

• 对于支持者许可执照，免费的手段让人们不过他们现在要使用该软件，现在，不担心如何自由 的未来推导的。
• 对于支持者开放版权许可，自由的手段确保软件和它的任何形式的免费入住，正在准备牺牲一些眼前的自由，以确保。

许可的许可程度越高，可以使用该许可的人就越多，但是您对该许可的控制就越少。但是，限制越严格，首先您就越有可能让人们放弃使用您的软件。

有许多免费和开源许可证，包括GPL <= 2，GPL 3，LGPL，BSD和Eclipse等。每个都有优缺点，因此请仔细阅读它们对代码施加的限制，并确定您想让谁使用它。警告，无论您选择哪个人都会抱怨-这是 神圣的战争领土。

总体而言，这是一种微妙的平衡行为，并且在很大程度上取决于软件的目标受众。

• 牛津大学OSS Watch提供的非常全面的交互式许可证区分符是确定哪种许可证最适合您的重要资源。

我认为，许可许可证和非专利许可证都适用于科学代码-重要的是，该代码首先是开源的。我认为科学应该是开放的，支持科学的代码也应该是开放的。

“放弃”所有编码工作作为开源代码的利弊是什么？

赠送软件的想法是，如果其他人觉得它有用，那么他们就会使用它。

如果他们使用它，他们将发现，报告并经常修复错误，从而节省了这样做的精力。

如果他们喜欢它，而您的软件几乎可以满足他们的要求，那么他们可能会增强您的软件并将这些改进归还。

这是一个很大的IFS虽然。

如何与希望从研究代码中受益的行业参与者打交道？

首先，如果要禁止将代码用于商业用途，则可以选择没有商业重用条款的许可证。

其次，如果您认为有人可以使用您的软件来提供服务，而没有实际将代码分发给其他任何人，那么您可以考虑使用Affero GPL来填补特定的copyleft漏洞。

第三，您可以执行上述操作并提供双重许可选项。提供GPL或AGPL许可证以供公共下载，并提供收费的商业许可证可为您带来两全其美的体验，这意味着您甚至可以从软件的商业销售中获得一定的收入，从而有助于支持您的科学活动。

请注意，如果您要这样做，请从一开始就提供它-与以后开始提供商业许可相比，这可能导致您的开源贡献者减少摩擦。如果您的社区变得受欢迎，那么您不希望人们在以后对商业开发的可能性不了解的情况下指责您变卖。理想情况下，在开始接受第三方对代码库的贡献之前，您应该设置适当的贡献者许可协议（CLA）。

这个答案对这个问题提供了此选项一些有用的信息了。

PETSc使用此许可证，这是对BSD的限制较少的形式。与GPL的关键区别，是该软件可以商业使用。有许多人原则上反对封闭软件，但是根据我的经验，如果拥有GPL许可证，那么您的代码不会有业务。而且，PETSc的工业用户具有不可思议的价值。它们往往会遇到非常复杂的问题，大多数学者会发现这比出版所需要的困难得多。他们还为PETSc贡献了很多代码，因此它可以进入正常的支持链。我建议不要使用任何没有商业使用潜力的许可证，并且实际上提倡使用限制性最小的许可证（您可以将PETSc刻录到CD上，然后尝试将其出售给gullible）。

我之所以使用GPL，主要是因为人们对原始的开源运动怀有浓厚的兴趣（因此希望它能帮助其传播）。此外，这反而是保护您可能的收益免受不道德资本家侵害的最佳方法-作为作者，您始终可以并行地将代码分发在不同的许可证上，从而维护专有版本以用于白标业务。
但是，这也可能是一个弊端-您的资金来源可能会声明您的所有工作都应成为公共领域，这超出了此许可范围。

总之，该主题中最重要的事情是，任何牌照总比没有好，这是不幸的是经常在科学发展的世界-我只是讨厌那些/ *被盗约翰·史密斯的节目，他从来没有公开* /或CI认为我在1995年或1993年在Jane Smith某个小组的帖子中看到了这一点？

首先，开源的利弊：

优点：会有更多的人使用您的代码，提供反馈，更正，改进等。您最终将拥有更好的代码，并且更多的人会信任它。

缺点：如果您想以代码为基础建立业务，那么选择就更少了（但仍然有很多选择，例如出售咨询服务）

至于选择许可证，我将按以下顺序进行：

1. 您的雇主/资助机构是否施加任何费用？那你别无选择。检查此代码的所有贡献者。
2. 您是否重复使用具有某些特定许可证的代码，从而限制了您的选择？然后，您的选择也受到限制。实际上，集成GPL许可代码是此类限制的最常见来源。
3. 确定您更看重的是：GPL和类似许可证背后的所有代码都应该开放的哲学，或者BSD许可证背后的鼓励最广泛使用的哲学。
4. 在两个大型开放源代码许可系列中，根据您社区中最常见/可接受的选项进行选择。

我的大部分研究工作都是由公共资金资助的，因此我感到有义务使用限制最少的许可证。如果我所在国家的其他人正在帮助支付这项研究的费用，我真的有权告诉他们他们不能将我的代码集成到封闭的源代码和/或商业软件发行中吗？我希望使用我的代码的大多数人都是学术科学家，但是我对企业通过将其与其他（可能是商业的）软件集成，在其上放置GUI等来改进产品以提供产品来改善自己的软件没有任何哲学上的问题。帮助他们赚钱。

话虽如此，我尝试使用需要适当归属的许可证。例如，如果一家公司确实将我的代码折叠成一个较大的商业产品，我希望他们明确表明我的代码可以从我那里免费获得。但是除此之外，我想对我的代码用户提出尽可能少的要求。

对于非由纳税人资金资助的软件开发，我知道其他许可可能更合适。

没有人能清楚地说明这一点，所以我认为值得一提：

从某种意义上说，只要在新项目中使用代码，就必须以相同的方式对新项目进行许可，因此某些开源许可证（尤其是GPL）是“病毒性的”。而且，该代码不能链接到（以某些方式）不同许可的代码。

一个实际的结果是：

• 如果您在C中实现了新的数值方法，则该许可证将不允许从诸如MATLAB或Mathematica之类的通用软件中调用它

• 如果您实施新的图像处理算法，则该许可证将不允许使用该软件制作Photoshop插件

• 等等 ...

这不仅会阻止商业重用，而且还会使其他学者方便地重用（如果他们使用的是封闭软件），并且如果有人在您的代码之上构建代码，则将阻止他们在“做-您将使用它的方式”。

这是您在完成许可证制定之前必须考虑的事项。

我之所以这样说，是因为我遇到了一些人（对开源许可证不是很熟悉），他们不知道这一点，或者从未从这个角度考虑过它。

^{（这只是个人意见，但我认为对来自（公共资助的）学术界的工作应用此类限制是不合适的。因此，我要么保留代码，要么放弃代码。）}

无论选择哪种许可证，都请记住仔细检查所有资助协议，以确保其中没有任何条款指示或限制您如何许可软件。

以我为例，我的许多项目都是从几层资金中建立起来的，一点点在这里，一点点在那儿，并跟踪保持照明的人如何允许我许可我的东西运行的机器相当复杂。

对于大型代码，我会寻求其他答案中所述的一种许可证，通常是LGPL。但是，尽管通常不建议将其用于软件，但是对于我可能会发送给行业同事的小型自包含脚本，我经常选择使用知识共享许可。这是因为它们对于我将代码发送给的个人而言更加清晰，这消除了任何潜在的误解问题。过去，这对我来说效果很好。

与大多数在这里回答问题的人（在学术和/或公共组织中工作）不同，我在商业领域中工作。

对于我的产品，代码是封闭的，并且这样做仍然具有主要的业务优势。但是，当然还有其他方式可以做到这一点（例如，MySQL等人所展示的）。我经常看到图书馆的LGPL +商业许可方法。我尚未在商业系统中使用过这样的库，但我不排除它（到目前为止，我仅在研发级别上使用过这样的库，例如ALGLIB）。这与GPL产品形成鲜明对比-GPL产品我可能在内部使用，但由于病毒性质而永远不会在产品中使用。

当我发布源代码（操作示例，免费程序等）时，通常会使用Berkeley许可证。这似乎更符合“免费”代码的精神，带有归属，但没有GPL字符串和政治规定。也许这就是为什么它（或类似的许可证，如MIT许可证）在大学和公共组织中如此受欢迎的原因。源代码以“免费”的真正含义被赠送（这里有一些代码，您可以按照自己的意愿做），但是作者仍然可以得到荣誉/注明出处。

这是一个古老的问题，但是我认为值得一提的是Mozilla公共许可证，它是宽松许可证（BSD，MIT）和强版权左许可证（GPL）之间的中间地带。可以使用和重新分发MPL代码，但是必须提供MPL代码及其任何修改。例如，一家公司可以获取一些MPL代码，对其进行自己的改进，然后将其分发到专有的封闭源代码软件包中，只要他们能够提供其原始MPL代码的修改版本即可。他们没有义务像使用GPL一样发布所有自己的源代码。

有了BSD许可证，人们担心公司可以改进您的代码，而不必将这些贡献返还给您或整个社区，这是因为他们对其进行的改进可以带来竞争优势。（马特·奈普利的回答表明，并非所有行为都是这种方式）。另一方面，许多人可能完全避免使用GPL代码。MPL至少在原理上避免了这两个潜在的陷阱。