The War On Bullshit

A Software License Agreement is a contract between a software producer and a software user that grants the user a license; an End-User License Agreement (EULA) is a Software License Agreement that indicates terms of use. EULAs are fine in principle, but the way many EULAs are written makes them legally meaningless, unenforceable nonsense. This article explores five reasons why EULAs are bogus: the first three are based on legal and commonsense principles, the last two are specific to US laws.

1. One Way Contract

In common law systems, for a contract to be legally binding, both sides must provide “consideration.” When you buy an apple, you give money and you get an apple. The money and the apple are consideration. Many EULAs have a clause to the effect that the Software Provider can change the terms of the contract at any time, without notice. In other words, after you have agreed to the contract, the Provider can remove all of its obligations from the contract, and change your obligations to whatever it wants. I call this a one way contract because you are bound by the contract, but the Provider is not, because the Provider can just change it. This means the Provider has not given consideration, and the contract is invalid.

2. False Advertising

Often times, the advertising for a software packages makes promises that the software does not keep. Voice recognition software is a prime example. If you buy software that doesn’t work as promised, any contract you may have entered into is null and void. It’s like ordering a car off Ebay and finding out when you get it that it won’t start. If the ad said the car was in working order, the sale is invalid.

3. Agreement Unavailability

When you buy software at a store, you don’t see the agreement. Usually, you don’t see the agreement until you’ve opened the box and tried to install it. Some EULA’s say, if you don’t agree to this contract, return the software to the vendor for a full refund. Except, the vendor won’t take it back because it’s open. Does this make sense to anyone?

4. Adhesion Contracts

In some countries, such as the USA, a Contract of Adhesion or Standard Form Contract is a take-it-or-leave-it contract with no negotiation and unequal bargaining power between parties. If a term in an Adhesion Contract is outside the normal expectations of the weaker party, it is not enforceable. For instance, terms that say ‘the Provider is never liable for anything, ever,’ or ‘the Povider can change the terms of the contract whenever we damn-well please and to whatever our lawyers can dream up’ would be considered unreasonable and not enforceable.

5. Unconscionability

In same countries, a contract is unconscionable if the consideration from one side is so dismal as to make the contract unfair to one party. For instance, if you buy software that crashes every five minutes or produces the wrong outputs, it’s not worth the money you spent on it, and therefore the contract is unconscionable. Unconscionable contracts are not enforceable as-is and courts have a fair bit of leeway in dealing with them.

On Liability

In closing, not everyone can exempt themselves for the damage done by their crappy software. An open source programmer who makes no claims and takes no money for his or her work is perfectly safe in declaiming responsibility. Microsoft, Oracle, Cisco, IBM, etc. are not. The difference is in their advertising. Lying to customers about one’s products is generally illegal. If GE makes a hot water boiler that explodes and ruins someone’s basement, GE is responsible. Similarly, if Oracle claimed that its database software safeguards information, but an actual Oracle database spontaneously emptied itself, Oracle would be responsible: not because it broke the contract but because it lied in the advertising.

Now if everybody would please stop accepting these bullshit EULAs, we might foster some responsibility in the software community.

Allow me briefly to depart from the usual subject matter of this blog, BS in society, to address Service Oriented Architecture (SOA), BS in Information Technology. I recently discovered that proponents of SOA, such as Thomas Erl, claim it increases agility. This is unadulterated bullshit.

SOA for Dummies

Suppose you are a programmer and you have to build a large, complicated application. You have to break up the code into pieces so you can keep everything straight and not get lost. For years, programmers have divided code into interconnected hierarchies of objects, a practice called object-oriented programming. Service Oriented Architecture is an alternative code organization, based on services. For example, you might have a weather service that returns weather conditions, given a city. A service is a chunk of code that has several properties:

Service Oriented Architecture has become a major buzzword in the software design community, and everyone and his code monkey is claiming to use it. So if it doesn’t do what’s promised, a lot of people are going to lose a lot of money.

The Claim: SOA Increases Agility

Thomas Erl is the guy who wrote the book, literally, on SOA (see Service-Oriented Architecture (SOA): Concepts, Technology, and Design, Service-Oriented Architecture : A Field Guide to Integrating XML and Web Services, SOA Principles of Service Design). He claims that SOA facilitates agility. This is bogus for two reasons: SOA requires upfront architecture, and SOA, left unchecked can create strange loops.

Problem One: SOA Requires Architecture Upfront

One of the key tenants of Agile Development is to delay defining the system architecture (the organization of the code) as long as possible, because having a defined architecture limits your flexibility in changing code. According to Erl, SOA requires even more upfront architecture definition than an upfront-design-heavy object-oriented software development process. In other words, SOA requires you to do a whole load of up-front design and specification that’s very difficult to change after. Not being able to changes things is the antithesis of agility!

Problem Two: Strange Loops

Here’s something really interesting about SOA: your services can use other people’s services and vice versa. Furthermore, you have no idea how anyone else’s services work, or what services they are using. Now suppose Bob makes a service, B, and Tim makes a service, T, using B, and Jane makes a service, J, using T. The dependency looks like: B<--T<--J . Now suppose that Bob sees J, and thinks, hey, if I use this I can make my service way simpler. When Bob changes B to use J, we have a dependency loop, and all the services will just go around and around until something crashes. The problem is that Bob has no way of knowing which services depend on his. Now scale this up to thousands and thousands of interconnected services, made by many, many different programmers. Nobody can see the dependencies. It gets to the point that if anybody changes anything, the whole system can come crashing down. Debugging becomes a nightmare! More specifically, the lack of dependency knowledge drastically limits your ability to change services, once again retarding agility.

SOA is the Opposite of Agile

I’m not saying that SOA doesn’t have any advantages. It certainly promotes low coupling and code reuse. If you already have a large library of helpful services, you may be able to code some things faster. What I am saying is that SOA, scaled up in the distributed way SOA proponents talk about, does not foster agility. Loads of upfront design and unknown dependencies seriously hamper a code provider’s ability to change things quickly. I’m also not saying that these problems are insurmountable. What I am saying is that, if SOA is scaled up without precaution, it can create systems so precarious that anyone asked to maintain them will feel like s/he’s won a ticket to programmer hell.