eula解决_解决EULA问题

eula解决

每个人都认识到这种情况。 某些软件已经发布了更新，或者您是第一次安装它，并且要求您接受新的EULA 。 EULA通常为5-15页密集的法律文本。 几乎每个人都尽最大努力尽快找到“接受”按钮，有时会有些叹息，因为他们意识到必须先向下滚动才能点击接受按钮。

我认为这里有一些根本性的缺陷。 （实际上，这不仅限于EULA：而且还包括例如为手机订购所签订的合同，以及许多其他东西-本质上是大多数旨在给消费者的法律合同）

问题

如标题所示，我打算提出一个解决方案。 但是首先，我需要明确我要解决的问题，并为它成为一个开始的问题提供理由。 我将假设以下前提是正确的（并且我认为大多数读者都会同意）：

• 实际上，一小部分最终用户会阅读EULA。
• 如果用户确实决定阅读（而不是筛选）它，则平均长度的EULA将至少平均需要 10分钟才能正确理解。
• 大多数EULA往往包含许多标准样板，这些标准样板可能与其他EULA并不完全相同，但几乎相同。 根据用例和EULA作者的期望，存在一些关键变化。
• 在某种程度上，广大用户会注意到EULA的内容，通常是因为博客文章，新闻或类似内容引起EULA的更改或特定部分引起公众注意。

鉴于到目前为止，普通用户从未阅读过EULA，从本质上讲，它仍然只是“您是否相信该软件的制造商能够做出明智的事情？”。 EULA的详细信息基本上与用户无关。 用户想要使用该软件，并且在某种程度上显式或隐式地选择信任该软件的制造商。 如果软件做了用户不喜欢的事情（例如发布用户认为不公开的信息），则无论EULA碰巧有直接或间接允许它的条款，用户都会生气。 无论最终用户许可协议（EULA）如何，都会有影响（无论是正面还是负面）。 无论最终用户许可协议如何，个人用户几乎没有机会做任何事情。 一家公司出于公共关系目的或出于法律/政治原因，可能会为了响应公众的整体压力而更改EULA。

此外，让我们采取理论上的法律立场，只是说这取决于用户阅读和接受EULA，这才是讨论的结尾。 至少有两个大问题：

• 如果更新了一个拥有1亿用户的软件，并提示您接受EULA，则在上述前提下，这意味着在阅读EULA时将浪费1902人年 （100000000 * 10/60/24/365）。 让我重复一遍。 阅读EULA将花费数千个人年 。 您能想到与2000年人类更好的关系吗？ 请注意，通常不会尝试优化此过程。 例如，通过呈现EULA的注释很好的视图，该视图显示相对于已接受的最后版本已更改的部分。
• 该论点假设，由于EULA的一部分不清楚，稍有允许或限制等，实际上可以期望用户退出使用该应用程序。在大多数情况下，用户实际上对精确解释法律并不感兴趣。段落，他们只想使用软件/服务并使其表现得体。

但是，尽管如此，EULA：s仍然存在。 我不是律师，但据我所知，这是因为它们实际上确实具有法律意义。 在极少数情况下有人提出诉讼，精美的印刷品很重要。 尽管事实是受所谓违反EULA的影响的原始用户可能从未读过EULA。 当斗争变成合法时，法律文本就是武器和战场。 好像我们有两个不同的世界–现实世界和法律世界。 在它们之间有一些门。 在现实世界中，我们必须应对EULA：在现实世界中对我们完全无用的EULA（并且作为最终用户仅存在于现实世界中），因为服务或软件背后的公司都存在于两者中他们必须通过使现实世界遭受某些副作用来保护自己在法律世界中的地位。

拒绝非解决方案

我发现，每当讨论EULA：s时，都会出现过分对抗的观点。 很多人抱怨公司不关心隐私，而拥有允许各种事情的EULA ：。

好吧，我认为这是因为就像最终用户生活在现实世界而不是法律世界中一样，公司端的开发人员，营销人员和获利者也是如此。 他们想做自己想做的事，同时保持一些体面的行为，而不会遇到法律问题。 因此，为了完成任务，您希望EULA尽可能开放，以便具有灵活性，以便在需要进行一些微小更改时不会陷入巨大的法律问题。

假设您正在为iTunes或Facebook之类的东西编写EUAL。 您可以深入了解有关如何精确使用每条信息的详细信息。 例如，在Facebook的情况下，他们可以确切指定信息的呈现方式，确切的对象以及在何种情况下。
但是，当您对UI进行细微调整时会发生什么？ 或者，您引入了新的隐私功能–即使它们是旨在并合理地尝试改善隐私功能，现在突然也需要非常仔细地重新编写整个EULA，以使其匹配。 作为开发人员，您是否希望它不断阻碍您的进步？ 作为最终用户，每次更改一些小细节时，您是否真的想阅读新的EULA？

这就是为什么我认为完全有道理的是，EULA通常看起来非常适合让公司与您一起做他们想做的事情。 我不认为这是邪恶（通常）； 我认为这是在现实世界中切实可行的做法，因为它受到法律界的溢出影响。

另一个潜在的解决方案是立法。 以某种方式使用信息或以某种方式使软件行为是非法的。 我将立即拒绝这种观点是不现实的，因为没有法律能够足够灵活地允许真正的创新和自由，同时又以某种方式阻止公司“行恶”。 我们有一个公众希望所有东西都是免费的（部分原因是我怀疑，因为没有可用的小额支付系统，但这是另一个博客条目），但是任何利用内容或统计信息货币化的尝试都被认为是邪恶的。 假设这样的法律是几年前制定的，并且这些法律说安装在计算机上的软件绝不能通过网络将个人用户信息发送给第三方或提供该软件的公司运营的服务器。

当时，这对于许多人来说可能是合情合理的，但从法律上讲，这将使当今软件的很大一部分无法实现。 在“云计算”这个流行术语出现之前，人们并没有真正理解它 。 有很多理由希望您的数据可以集中和联机使用，而不是将其绑定到特定的物理计算机上。 情况总是如此，但是在云计算嗡嗡声出现之前，这种认识并不普遍。

不，我们需要有一个可以有机增长，可以鼓励创新的自由系统。 我们不能立法解决这个问题。

快速查看开源许可证

如今，大多数开源软件都是根据一种著名的开源许可证发行的 。 我想谈一谈这种情况，部分是因为有些读者可能不熟悉这种情况，部分是因为即使对于那些本人的读者，我也希望强调某些特定的属性。
关于哪个开放源代码许可证是特定项目的更好选择，还有很多争论的余地。 但是采用其中一个的开源项目的独特之处在于它没有发明自己的许可证 。 询问软件许可证的人可能会收到响应“ MIT许可证 ”或“ Apache许可证 ”。 尽管存在一些潜在的混淆（例如，如果您说“ BSD许可证”是在谈论2子句版本还是3子句版本 ？），通常来说，许可证的名称足以使提出要求的人。 无需详细阅读许可证，因为您已经知道许可证的名称。

从软件开发人员的角度来看，采用众所周知的既定许可证是实际编写软件的一种简便方法，而这通常是您所关心的，而无需律师为您起草许可证。 （这并不意味着所有开放源代码软件项目都会在没有法律帮助的情况下逃脱，特别是在有多个贡献者的情况下，但这确实使发布某些东西的障碍变得小得多。）

对于许多最终用户来说，这可能不是什么大问题。 许多人可能只关心啤酒是免费的并且通常是开放的 ，而不是每个细节。 但是，尽管它可能不会被认为是一件大事，但它确实允许个人最终用户做出真正的决定，即在合理了解其含义的前提下接受许可，而不必不断阅读繁琐的法律文本。

但是，更重要的是，看看典型的公司。 通常，出于法律原因，公司通常必须非常谨慎地内部使用（或作为已发布产品的一部分）使用哪种软件。 一家大公司面临很多风险，并且由于软件使用不当而造成的纠缠非常昂贵。 公司与典型的私人个人之间的区别在于，公司有动机按照应有的对待方式来实际对待软件许可。 他们无法像普通人在获取iTunes更新时那样“滚动并接受”舞蹈。 这会导致实际问题。 如果要使用具有任意许可证的某些软件，则可能必须通过法律进行清除。 这意味着成本（用于法律服务）和不便（开发人员必须经过官僚程序才能使用软件），并且如果软件的许可有问题，最终将减少对软件的使用。

但是，公司可以轻松地制定一项政策，即一定许可下的任何东西都可以使用。 通常，诸如2子BSD许可证，MIT许可证，Apache许可证等许可证都属于该类别（有时称为GPL）。

通过推广命名许可模型来解决EULA问题

我提出的解决方案如下。

1. 建立合同条款的权威目录，其中每个条款都有一个全局唯一标识符（类似于您可以在“ 开源倡议”中链接到许可证的方式）。
2. 建立一种格式和软件来表达这些条款的组合。
3. 构造合同或EULA时，请选择此目录中存在的条款的组合。
4. 如果需要，添加其他子句–但也将子句添加到所述权威目录中。

想象一下可以在此基础上构建的生态系统。 想象一下一个条款数据库，随着时间的流逝，辩论，讨论和法庭测试这些条款。 可能会积累解释和法律效力以及对用户的影响的证据。 最终用户可以决定接受某些条款，而其他条款则不可接受。

在这个世界上，每当我（作为用户）收到有关iTunes（或其他任何东西）的新许可协议的提示时，（由于以上几点）我都会在屏幕上看到（由我的许可处理软件提供，不信任iTunes） ：

• 我以前未批准为普遍接受的任何条款都将非常明显地突出显示，并且与该条款的评估，讨论和法律优先级（如果有）直接相关，从而使我有最大的机会评估我是否愿意接受该条款。
• 我与某些条款相关的任何注释（例如，也许我已将某些条款标记为可疑，并且我想查看合同何时包含这些条款）。
• 如果我愿意的话，请提供完整的条款清单，如果我真的想看看的话。

考虑这是标准做法的世界。 用户不仅可以更轻松地做出明智的决定，而且公司更容易潜入不合理的合同变更中，因为它们会被明显地标记出来-直接链接的每个人都可以看到任何讨论并且评估已经发生。 用户并不孤单。

但是， 这对公司也更好 -希望会有一个条款生态系统，赋予公司合理的权利以合理的方式灵活地变现并从中获利，同时对用户也保持合理。 应该没有理由，或者更少（只有在做还没有时间建立合同条款生态系统的独特事情时），才有理由构造对用户有疑问的条款，甚至实际上比他们更允许的条款需要。

请注意，该系统假定子句彼此独立。 合同的表达方式必须实际改变才能实现。 您不能再在合同的差异条款之间建立微妙的关系； 每个人都必须自立。 就是说，可能需要某种上下文，例如以允许自动处理合同的方式来识别合同的不同方（例如，如果我是甲方，我可能会认为某个条款可以接受，但如果我是甲方，则我认为不可接受）是乙方）。

我不假装将所有细节都弄清楚，但是似乎很可能在这些方面有所作为。 我希望特别是律师对这种系统的可行性发表评论。

参考：在（mod：world：scode）博客上，我们的JCG合作伙伴 Peter Schuller 解决了EULA问题 。

翻译自: https://www.javacodegeeks.com/2012/02/solving-eula-problem.html

eula解决