next up previous contents
Next: Privacy Up: End User License Agreements Previous: 180solutions' Zango   Contents

Fair End User License Agreement

Ed Foster has established the idea of a ``fair'' EULA, aiming to provide industry with an EULA example that was accessible, had the right amount of legal weight, and that treated both the company and the software user fairly (see Appendix 2) [Foster, 2006,Foster, 2007].

The FEULA is definitely a step forward in license construction, without the problems of capital letter readability, and with significantly less legal jargon, and at only 630 words is a significantly quicker read than that of Zango's. It outlines the rights and responsibilities of the user and company in a way that is easily accessible, but it could be argued that the lack of specificity that is common in other, more mainstream EULAs could mean that there are more loopholes to be exploited by companies and users alike, and thus that the FEULA would fail in its purpose to protect the interests of the company and user. The FEULA is also very United States-centric which is a problem because it does not provide for non-American consumers. A company could easily change the agreement to suit their own local laws, but this does not empower the user to understand their local rights and responsibilities, thus putting more onus on the consumer to investigate the laws that apply to them. The FEULA also has a clause that disclaims warranties of merchantability or fitness for a particular purpose, which once again greatly and unfairly benefits the company rather than the consumer. Many jurisdictions include laws requiring products to meet merchantable quality standards. If the software claims to do some particular task but does not actually carry out that task properly, according to the Australian Trade Practices Act (1974) it is not of merchantable quality [Commonwealth of Australia, 1974]. To disclaim warranty of this in a general EULA could imply that software malfunctions would not be the responsibility of the company who wrote the program, which would be deceptive under Australian law, making users of the software think they cannot make a claim if such damages arose from unmerchantable quality software. However, unlike other EULAs, this particular EULA points out the limitations on its liability, in that it would be responsible for injuries ``resulting from gross negligence, fraud, or knowing misrepresentation on [the company's] part''. It also continues to refer to ``statutory rights'', which Belgrove's study finds too vague [Belgrove, 2008] to be useful for the average user.

Despite its flaws, the FEULA is on the right track to balance out the fairness for users and companies. It could easily start to suffer from length concerns if it becomes tailored to an individual company's needs, but something like the FEULA could be used as the template for license agreements, given adequate supporting infrastructure. The conditions in the FEULA also highlight the problem of localisation, in that there needs to be either an easy localisation option for users to understand their local laws, or there needs to be a concerted education campaign to empower users with more knowledge of their rights and responsibilities. The clauses2.5 allowing for users to transfer their copy and license of the software to someone else are good, because they allow for greater freedom of use of the software, as are the clauses which state in clear language that the company will request specific permission before updating itself or taking personal information.

This section has discussed in detail the problems associated with End User License Agreements. It has shown the predominant method for gaining informed consent has inherent flaws in its design, requiring companies to simply disclose terms and conditions, and allowing consumers to accept these without any sorts of testing of understanding or competence, or mechanisms for feedback and questions about the agreement. The fact that the major operating system companies have included these sorts of EULAs as examples or templates within their development environments helps to further solidify the practice amongst software developers. In the Zango case study we see a particularly bad example of the problems that can be effectively ``hidden'' within the EULA due to the difficulty and imposing nature of the length and legal language used, and the use of hard-to-process capital letters to make the agreement even harder for everyday users to comprehend. The Fair EULA could be the start of a template for a set of standard license agreements, but even it has its flaws. As it is, this section shows how the effective consent and duty of disclosure models do not work effectively when disclosure is made the focus of the agreement and informed consent is considered the goal rather than an enabler (and thus falls into the problems of Brownsword's ``cult of consent'' [Brownsword, 2004] discussed in section 1.2.3). This section also shows the difficulty of determining what would be considered sufficient in the case of autonomous actions. Both sufficient understanding and sufficiently autonomous actions are hard to set thresholds for here because of the huge range of potential users, the lack of being able to adequately test users, and the culture of minimal concern for user rights and maximal concern for limitation of legal liability. The next section will show how these same problems affect areas of privacy in computing as well.


next up previous contents
Next: Privacy Up: End User License Agreements Previous: 180solutions' Zango   Contents
Catherine Flick 2010-02-03