Solving the EULA problem

Everyone recognizes the situation. Some piece of software has released an update, or you are installing it for the first time, and you’re asked to accept a new EULA. The EULA is typically 5-15 pages of dense legal text. Almost everyone just tries their best to find the “accept” button as quickly as possible, sometimes giving a sigh as they realize you first have to scroll down before you can hit the accept button.

I think there is something fundamentally flawed here. (In reality this extends to more than just EULA:s and include e.g. contracts signed for a cell phone subscription, and many other things – essentially most legal contracts intended for consumers)

The problem

As the title indicates, I intend to suggest a solution. But first I need to be clear about what I am solving, and make a case for it being a problem to begin with. I will assume the following premises as true (and I think most readers will agree):

• A very tiny portion of end-users actually read the EULA.
• If a user does decide to read (not sift) it, it will take, on average, at least 10 minutes for an average-length EULA to be properly understood.
• Most EULA:s tend to contain a lot of standard boilerplate that may not be exactly identical to other EULA:s, but is pretty much the same. Some key variation exists depending on the use-case and the desires of the author of the EULA.
• To the extent that users at large notice the contents of EULA:s, it is typically because a change or a particular part of the EULA is brought to public attention by a blog post, news article or the like.

Given that the average user by far, never reads the EULA, it is essentially still just down to “do you trust the maker of this software to do something sensible?”. The details of the EULA are mostly irrelevant to the user. The user wants to use the software, and either explicitly or implicitly chooses to trust the maker of said software to some extent. If the software does something the user does not like (such as posting information the user thought was private, publicly) the user will become angry regardless of whether the EULA happened to have a clause that directly or indirectly allowed it. The effects (whether positive or negative) are there regardless of the EULA. The individual user has very little chance to do anything about it, regardless of the EULA. A company that changes its EULA will probably do so in response to overall public pressure for PR purposes or for legal/political reasons.

Further, let us take the theoretical legal stance and just say that it is up to a user to read and accept the EULA and that’s the end of discussion. There are at least two huge problems with this:

• If a piece of software with 100 million users gets updated and prompts for EULA acceptance, given the above premises that means that 1902 human-years are wasted on reading the EULA (100000000*10/60/24/365). Let me repeat that. A couple of thousand human years would be spent reading the EULA. Can you think of something better to do with two thousand human years? Note that no attempt is typically made to optimize this process; for example by presenting a nicely annotated view of the EULA which shows which sections have been changed relative to the last version that was accepted.
• The argument assumes the user can realistically be expected to opt out of using the application because a part of the EULA is unclear, slightly too allowing or restrictive, etc. Most of the time, the user really isn’t interested in precise interpretation of legal paragraphs and they just want to use the software/service and have it behave decently.

But, despite this, EULA:s still exist. I am not a lawyer, but as far as I can tell, this is because they actually do matter legally. In the rare case that someone does bring suit, the fine print matters. Despite the fact that the original users affected by the alleged violation of the EULA might not ever have read the EULA to begin with. When the fight turns legal, the legal text is the weapon and the battleground. It’s as if we have two different worlds – the real world, and the legal world. And there are some doors in between them. In the real world, we have to deal with EULA:s that are completely useless to us in the real world (and as an end-user one exists in the real world only), because the company behind the service or software exists in both worlds and they must protect themselves in the legal world by subjecting the real world to certain side-effects.

Rejecting non-solutions

I find that there is an overly adversarial view going on whenever EULA:s are discussed. There is plenty of people complaining about companies not caring about privacy and having EULA:s that allow all sorts of things.

Well, I think that is because just like the end-user lives in the real world and not the legal world, the same is true for the developers, marketers and monetizers on the company end. They want to do what they want to do, while maintaining some decent behavior, without legal issues getting in the way. In order to get things done, you thus want an EULA that opens up as much as possible to be flexible so as to not get into a huge legal issue as soon as some tiny change needs to be made.

Pretend you’re writing an EUAL for something like iTunes or Facebook. You could go into excruciating detail about exactly how each piece of information is allowed to be used. For example, in Facebook’s case, they could specify exactly how information is presented, exactly to whom, and under what circumstances.
But what happens when you make a minor tweak to the UI? Or you introduce new privacy features – even if they are intended to, and legitimately try to, improve privacy features now suddenly an entire EULA needs to be very carefully re-written to match. As a developer, would you want this constantly impeding your progress? As an end-user, would you really want to read new EULA:s every time some little detail is changed?

This is why I think it makes total sense that EULA:s often seem to be very much geared towards letting the company do whatever they want with you. I don’t think this is evilness (usually); I think it’s about being practical in a real world hampered by spill-over from the legal world.

Another potential solution is legislation. Making it illegal to use information in certain ways, or for software to behave in certain ways. I wil immediately reject this notion as unrealistic because no law will ever be flexible enough to allow true innovation and freedom while somehow preventing companies from “doing evil”. We have a public that expects everything to be free (in part I suspect because there is no usable micro payment system, but that’s another blog entry), yet any attempt to monetize on content or statistics is hailed as evil. Let’s say such laws were enacted a few years ago, and that these laws said that software installed on a computer must never send personal user information over the network to servers operated by a third party or the company providing the software.

That would probably have made sense to many people at the time, but would make a huge part of today’s software legally impossible. Before the buzzword of “cloud computing” existed, people didn’t really get it. There are plenty of reasons to want your data available centrally and online instead of tying it to a specific physical computer. This was always the case, but before the advent of the cloud computing buzz, it was not commonly realized.

No, we need to have a free system that can grow organically and where innovation is possible and encouraged. We cannot legislate away this problem.

A quick look at open source licenses

Most open source software today is distributed under one of the well-known open sources licenses. I want to mention some things about the situation, in part because some readers may not be familiar with the situation, and in part because even for readers that are I want to highlight certain specific properties.
There is plenty of room for debate concerning which open source license is the better choice for a particular project. But the unique aspect of an open source project that adopts one of them, is that it does not invent its own license. Someone inquiring about the license of a piece of software may receive the response “the MIT license“, or “the Apache license“. While there is some potential for confusion (for example, if you say “The BSD license” are you talking about the 2-clause version or the 3-clause version?), in general the name of the license is enough for the person asking. There is no need to read through the license in detail, because you already know what the license entails by name.

From the point of view of the software developer, adopting a well-known established license is an easy way to get going with actually writing the software, which is often what you care about, without getting a lawyer to draft you a license. (This does not mean that all open source software projects get away without legal assistance, particularly if there are multiple contributors, but it does make the barrier of releasing something much smaller.)

For many end-users, this is probably not a very big deal. Many people probably only care about the fact that it is free-as-in-beer and generally open, rather than each particular detail. But even though it may not be perceived as a big deal, it does allow the individual end-user to make a true decision to accept the license with reasonable knowledge of what it entails, without constantly be reading dense legal text.

More importantly however, look at the typical company. Companies typically have to be very careful in what software they use internally (or as part of released products), mainly for legal reasons. A big company has a lot at stake, and a foul-up with incorrect use of a software can be extremely costly. The difference between the company and the typical private individual, is that the company has the motivation to actually treat the software license the way it is really supposed to be treated; they cannot do the “scroll down and accept” dance that the average person does when he or she gets an iTunes update. And that causes practical problems. If you want to use some piece of software with an arbitrary license, you are likely to have to clear it through legal. That means costs (for legal services), and inconvenience (developers having to go through a bureaucratic process to get to use software), and ultimately less use of the software if the software has a problematic license.

But a company can easily have a policy that anything under a certain set of licenses are always okay to use. Typically licenses like the 2-clause BSD license, the MIT license, the Apache license etc fall in that category (sometimes the GPL).

Solving the EULA problem by generalizing the named license model

My proposed solution is the following.

1. Establish an authoritative directory of contract clauses where each clause has a globally unique identifier (similarly to how you can link to a license at the Open Source Initiative).
2. Establish a format and software to express combinations of these clauses.
3. When constructing a contract or EULA, pick a combination of clauses that exist in this directory.
4. If needed, add additional clauses – but then also add the clause to said authoritative directory.

Imagine the ecosystem that can be built on top of this. Imagine a database of clauses, which over time are debated and discussed and even tested in court. There can be an accumulation of interpretation and evidence of legal effectiveness and implications for the user. An end-user can decide that a certain set of clauses are acceptable, while others are not.

Consider a world where this was standard practice. Not only it is so much easier for the user to make informed decisions, it is also much more difficult for companies to sneak in unreasonable changes in contracts because they will be so obviously flagged – and everyone following directly links will be able to see whatever discussion and evaluation has happened. The user is not alone.

But it is also better for the company – hopefully there will be an ecosystem of clauses that give companies reasonable rights to be flexible and monetize in a reasonable fashion, while also being reasonable to the user. There should be no, or less (only when doing unique things that have not yet had time to establish an ecosystem of contract clauses), reason to construct clauses that are seen as questionable to the user and maybe even are in fact more allowing than they need to be.

Note that this system assumes that clauses are independent of each other. The way contracts are expressed has to actually change to make this a reality; you can no longer have subtle relations between difference clauses of a contract; each has to stand on its own. That said, some context is probably going to be necessary, such as identifying different parties to the contract in a way which allows automatic treatment of it (for example, I might consider a certain clause acceptable if I am party A, but not if I am party B).

I do not pretend to have all the details worked out, but it seems very much plausible that something along these lines would be possible. I would appreciate comments, especially by lawyers, as to the feasibility of such a system.

Reference: Solving the EULA problem from our JCG partner Peter Schuller at the (mod :world :scode) blog.