我可以删除所有大写字母并缩短许可证上的免责声明吗？

我将MIT许可证用于特定的代码段。现在，此许可证在所有大写字母中都有很大的免责声明：

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF...
...

我在zlib许可证上看到了通常大写的免责声明（请注意，它在许可证文本上方），甚至根本没有免责声明的软件（这意味着，我认为，确实有保证吗？），但是我希望得到可信赖的各方的一些建议。我只是没有找到任何东西。

此免责声明附带了GNU 其他文件的许可声明：

该文件按原样提供，没有任何保证。

简短而简单。

因此，我的问题是：是否有任何可信赖的消息来源表明在我应该关注的所有辖区中可以安全使用短的而不是长的，并且通常是拼写而不是大写的免责声明？

出于这个问题的目的，该软件在欧盟发行，如果有任何不同的话。

IANAL，但有人与我合作。所以，我问。结果：

• 大写字母可以让您说“他们绝对不能错过免责声明，这很难打印！” 这在非律师必须阅读和接受的许可证或EULA中很重要。

• “表达”和“暗示”之间有区别。某些地区的法律允许人们“暗示”担保，即使未明确提供担保，除非您制定某些规格。

他建议不要对现有许可证进行任何更改，因为这基本上会创建一个全新的（可能更弱的）许可证。许可证激增是一个问题。错误的许可证扩散是一个更大的问题。

许可证旨在保护您，在这个勇敢无休止的诉讼新时代中，很少有人读过的首字母大写和徒刑是一笔不小的代价：)

这是（L | A）GPL的V2 / V3特别声明禁止更改许可证的最大原因之一。

人们每天都在起诉..以免常识造成的损害。例如：“我怎么知道咖啡很热？如果它被贴上标签，我就不会洒在我的腿上。”

您确实应该注意不要削弱防止淘金者打扰您的“盾牌”。

MIT许可证中的全大写免责声明或多或少是从商业收缩包装许可证中使用的法律语言复制粘贴而成的，在该法律中，“无担保”的拼写要求在法律上比其所需要的更加精确。免费软件。由于确实存在不具有此法律文字的开源许可证，因此我认为该简短形式可能是可以的。

与所有合法事物一样，如果您真的对此感到担心，则应咨询专门从事软件许可法的律师。

该免责声明在那里可以保护您作为原始作者。否则，在进行软件工作时，您可能需要履行法律暗示的保证。

正如您在技术系统中可以想象的那样，这可能很复杂，这就是为什么您确实要排除保修的原因。这也是有关该主题的入门级或更高级文献的建议。

随着社会越来越多地依赖软件来执行从制造业到生命支持系统的所有重要功能，软件程序中的错误将导致经济损失，财产损失或人身伤害的风险增加。审慎的软件开发人员将意识到这些风险，并将采取措施将其承担的此类风险降至最低。要确定软件开发人员应该采取的措施，需要在承受软件产品责任的程度与限制该风险对软件供应商销售和销售其软件的能力的不利影响（如果有）之间进行权衡。

（摘自：IV。结论-软件产品责任：理解和最小化风险（由Lawrence B. Levy和Suzanne Y. Bell撰写））

由于您可能是在非常自由的自由软件条款下提供了软件，因此最好在更改已建立并被广泛接受的许可文本之前咨询律师（是的，这可能会有所不同，如果我阅读@Tim Posts Lawyers的反馈正确，这也是他的律师的意思。您也可以在其他律师的评论/出版物中发现这一点，尤其是有关自由软件许可证的信息。

但是，此免责声明并不是万能的。例如，在德国，仅通过在条款下添加免责声明就无法轻松降低责任。

由于法律要求对软件进行全面保修会给原始作者带来太多责任，而原始作者通常实际上并没有赚到一分钱，因此对于自由软件而言，这已经得到了更好的澄清，因为德国法律中现在有一些判决对此进行更明确的说明（并允许在一定程度上放弃保修）。这并没有使我们所知道的世界从上到下颠倒过来，而只是说事情并不像乍看起来那样容易，而且在关键区域，最好与大量的用户保持在一起。同样的条款，以在必要时有效地进行反击。

您还可以在GPL 3的条款中找到这些含义，GPL 3是具有国际用途的现代许可：

第15条是免责声明，第16条是责任限制：

17.第15和16条的解释。

如果以上提供的担保和责任限制免责声明无法根据其条款在当地产生法律效力，则复审法院应适用与该计划有关的所有民事责任的绝对放弃权最接近的当地法律，除非有担保或假设责任副本随附在本程序的副本中，以收取费用。

（摘自：GNU通用公共许可证-版本3，2007年6月29日）

仅当您遵循接受的做法（包括出于个人原因（或多或少））不更改接受的免费软件许可文本（包括其下的保修免责声明）时，才有可能。

但是，您在问题中涉及的MIT许可证文本并不需要保留保修免责声明。

这可能是有道理的，因为在某些情况下，在签订软件许可或基于软件的许可的合同时，可能需要删除此真正的广泛免责声明并在此处协商更精确的条款。

但是，由于这个原因，删除它可能不是一个好主意，OSI FAQ也包含不同的保修主题（不具体参见下文），措辞表明单独出售保修可能确实更有意义：

有些公司可能会向您单独出售有偿保修，但收费是免费的，但这不是开源许可证的一部分，这只是您与该公司的私人合同。

（摘自：我可以限制人们使用开放源代码许可程序的方式吗？-OSI常见问题解答）

因此，似乎不允许更改和删除它，并且看起来您不会失去任何重用权利，但是，您实际上在这里所做的是破坏文本，并按您的实际意愿为太多用户提供保修。关心某人或某事。

其他人进行进一步的文本分析可能不容易确定原始许可，这是通过在澄清作品的许可（对于使用该作品的第三方）时再增加一个步骤/要点来获得的。然后其他用户可能会感到困惑，而不会。因此，保持透明是我能提供的最佳建议。

并且这样做是有原因的。只是出于格式化目的，因为它不讨好您的口味？好吧，这是一个自由的世界，因此您可以做任何您想做的事，但这也是为了给别人一些东西，因此请记住，这会使别人的生活更加复杂。只需确定对您而言重要的事物以及您愿意承担的风险。

而且，如果您有法律问题，最好问一个能够以具有法律约束力的方式回答您的人（不要说律师会一直这样做，但是机会更大，从法律的角度出发，您以后会受到更多的教育： ））。但是我想你知道这笔交易。

IANA / YLJASD