Standard Agreements

With the normative expectations identified, and mechanisms in place to allow users to confidently waive them with informed consent, it is important to look at the other end of the system, that is, the rights and responsibilities of the software writers and vendors that was previously the sole focus of an End User License Agreement. To effectively deal with this more legal side, I propose that a set of standard agreements be drawn up, with the basic legal requirements available to be added in as ``modules'', similar to the drop-down menu selection screens of the Creative Commons Website, as seen in Figure 4.4 [Creative Commons, 2008b]. In this way, licensers could choose which normative expectations licensees need to waive in their agreement, with appropriate text and icons inserted into the created agreement. It would, by necessity, be a little more complicated than the Creative Commons example, but considering there would be fewer licenses compiled and there are greater ramifications of poor informed consent at stake, this would be a necessary and reasonable tradeoff to make.

Figure 4.4: The Creative Commons license choice screen.

The use of modular standard agreements would be a convenient, clear, and effective way to communicate rights and responsibilities of both the user and consent requirer, and to obtain waivers of a user's normative expectations in order to install and use the software. Not only would a user be able to predict the sort of content of the agreement given the icons used to draw attention to potentially problematic areas of the agreement, but there would be a greater level of trust in a lack of the previously identified ``hidden'' or otherwise ambiguous clauses.

Should any conditions required by the licenser fall outside the provided sets of modules, a separate ``additional clauses'' section could be provided, on a second screen, with particular attention drawn to them and the specific mention that they fall outside the conditions provided by the standard license template. Generally speaking these should be generally discouraged, or be considered for module status with appropriate standard wording devised, but for more obscure software inclusions this option should be available. Examples of these will be discussed in section 4.4.3.