Shrink-Wrapped Licences

The legal fiction underlying shrink-wrapped licences is that the vendor hasn't sold you the software, they've merely licensed you to use it. It is as though, instead of buying a book, you bought the right to read a copy of that book which has been placed in your care. Note that when we buy a book, we are still bound by copyright, limiting what we may do with the book: but there are plenty of other things we may do – we can sell it on, we can cut it into little pieces and stick these in a scrap-book, optionally with other material, we can review it and publish our opinion of it. Buying a licence to use the book, we are bound by terms and conditions contained in the licence which might forbid us to do any or all of these things.

So why should the two be different ? Central to the answer is the legal status of a contract. Where two parties have negotiated a contract and had full scope to ask one another for variations in terms, subject to some basic reasonable/conscionable constraints, and have finally agreed a contract, they are bound by that contract, as though it were part of the law. These are the terms under which licensing is understood: it is an agreement between the software provider and the user. On the other hand, books are sold as mass-market goods: the normative form of purchase is that the customer is offered the book at some price on a take-it-or-leave-it basis; the book is being sold by a retailer who is not a representative of the copyright-holder, so there can be no sensible negotiation of terms between the potential customer and the retailer.

The virtues of a negotiated contract depend on reasonable scope for negotiation. If either party is in a position to make up the entire contract and present the other with a take-it-or-leave-it choice, interpreting the contract as an agreement freely entered into becomes less convincing. When the vendor does so and has a monopoly (namely copyright), there is no option for the free market to provide the customer with choice of terms and conditions. There comes a point where we recognize that the customer's interests need to be protected and cannot hope to be protected when the entire contract is written by (and to serve the interests of) the vendor. I contend that shrink-wrapped software licences (which, typically, the customer wasn't even in a position to read prior to making what the customer took to be a purchase) have gone way into this territory: the vendor disclaims all warranties, i.e. the contract guarantees the customer nothing, but the customer is constrained in a whole range of ways.

The terms I have seen quoted from shrink-wrapped contracts are just so outrageous that I feel it is time to suggest an antithesis: I do not claim that this is not outrageous, only that it is no more outrageous, but in the customer's favour rather than that of the copyright-holder.

Licences and downloads

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.

… it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

RFC 2616 (HTTP/1.1), Section 9.1.1 (extracts).

Press if you understand these instructions.

Fvqre gunderstand if you und have the guna metween poing an action or uryq nppbhagnoyr sbe gurz cannot be held accountabg of perfore.

IPR publishers want to be able to make their data available on the web subject to legally binding constraints on the recipients (over and above the law's basic constraint – no unauthorized copying): if you view this published content you must view all the adverts that come with it; if you click on the Accept button below, you have thereby agreed to abide by the terms and conditions set out in this page; etc. That makes a kind of commercial sense, if it can be made to work. However, to do it, they need some other way of arriving at it: HTTP is not the answer. The bold assertion that, by doing something to a web page, I agree to some conditions is simply an assertion. I might, in pressing that button, signify only that I want the software and I think doing so might gain me it.

When your web server responds to an HTTP request from some program on my computer, it has delivered some data to me and it has not placed me under any obligation (that I wasn't under already, e.g. copyright law already restricted my ability to redistribute). If your web-site's only link to that content comes with prominent notices claiming those who click on the link are thereby agreeing to some conditions, you none the less have no assurance that those who fetch the resource it links to have come via that page – someone else may have included a link to the same resource, from another web-site, without any such notice.

Thought Experiment

The user has typed in some words, presumed to have been the names of some freely available software programs; visit a search engine site, ask for hits on the named programs; visit those sites looking for links hanging off text which includes the word download; chase links out from there, looking for links to files with names ending .rpm, .tar.gz or .tgz, say; when some found, maybe do some choosing among the candidates found to chose the most recent or similar; download the chosen files. Not monumentally hard to code up, suppose I do so and made the program publicly available.

Someone using a copy of my program might hear of some program and, not knowing whether it is free, ask my program to fetch it for them. If my program succeeds, I see no way that the user can be considered bound by restrictions described by pages my program fetched on the way there, when the user never saw these. HTTP's definition is stateless: the meaning it ascribes to any request sent is independent of when that request was sent. The response a server gives might depend on when the request was sent but, whatever response it gives, the meaning HTTP ascribes to the response is likewise independent of when the transaction occurred.

Forms

Thus far, my imagined program chases links and I've supposed it's stuck at only seeking out the HREFs of A tags and the SRCs of IMG tags. The situation certainly looks murkier if it tries pressing buttons on forms – that is, decoding the mark-up of a form on a web page, identifying what the mark-up means and computing a URL to request based on that information (though, still, I might restrict myself to GET requests, using suitable query strings). None the less, consider what happens when someone unhooks the (nicely modular) parts of my tool that do link-chasing and replaces them with web-tree traversal module from some other web tool (part, perhaps, of a suite of such tools, some with legitimate purpose in form-following). I shall not suppose these tools able to make sense of the natural language, the text we would read, that's packed in between the mark-up: the task is notoriously hard. So now we have a version of my program which chases forms as well as links (e.g., given a form, it ignores all user-controllable INPUTS, collects together the rest and sends these to the ACTION URL using the indicated METHOD: or we can use GET as method if we're concerned to keep to HTTP's non-committal characterization of GET).

Take a trip over to a free software download site, hunt your way down the links until you find the page with the download on it. Now, the web-site at which you've found it might be run by some team working on it, possibly offering support services and a beta program, maybe asking whether you want to be added to related mailing lists, stuff like that. It might even be offering a service where (subject to site privacy policy) your e-mail address will be held in a database keyed on which version of which software you've downloaded for use in mail-outs of alerts if any serious bugs show up – to be able to provide that, it'd need the form to be on the chain of links down to the real moment of download and pretty much at the end of it. In any case, if you have to go through the form to get to the download, the site might plausibly get more folk who bother to fill it in. Of course, in that case, the right defaults for the form are no thanks, I just want to download and go, with an obvious button to press for that purpose – in response to which the server (once it's processed the form) will send you the software, with suitable HTTP headers to tell you what to do with it.

So, back to the modified version of my imagined down-load program for free software. Someone using it for that purpose is going to find it works better: it really will now fetch them downloads from places where my original couldn't find the download. One may suppose it will spread and be used by folk who don't realize that it fills in forms – maybe they confuse it with the original – and don't know which software is free (as before). The original may have been bolted into other things by this stage, too, so you upgrade your version of it to the better version you've found and leave your tools to operate it. Now, you've had my program lying around for a while, you're on a permanent net feed, so you did a neat hack a while back: a command shell that has an ultimate fall-back if it tries to execute a command in a script and the search falls off the end of PATH – pause the program for a moment, use my automatic down-loader, install the software and resume the program which needed it. Hideously insecure (i.e. about as secure as word macros), but handy for those moments when you trust the script's author not to be doing anything nasty if you just run the script, but the script may need some software you don't have installed.

Now, a perfectly sensible correspondent sends you a script but it runs some program you don't have installed. You and your correspondent are both running Linux and all the software you've got on it is free: and you both know this. Your correspondent has a free version of the program used by the script, but there's a non-free one available: you are oblivious of this, so may be your correspondent. Of course, both versions install to the same command name, and that's the key on which my program is searching, because that's the command your shell wants to run. You've never even heard of this program, but the nice efficient, helpful machine at your finger tips has just downloaded it. You have no idea where my program found it, even that it was sought, but you did know anything that might have been sought was freely available. You certainly don't know whether any forms were filled in, let alone what they said.

Or, of course, you could simply not be an anglophone. Visit the download site, making educated guesses and maybe a few false starts. Wonder what all the text means and look for the same kinds of file my imagined program hunted. Press the most prominent button on a form. Find what you're after, go home. Much like an adventure game, really. You weren't in an anglophone jurisdiction at the time and you couldn't reasonably be expected to know what any of that was about – clearly the software's free, look, you just fetched it.

Putting something up on a public web-server is not a viable way to form contracts on the Internet. For that, you need (echoing the existing software protocols) legal protocols for identification of a person and establishing that they understand and consent to the terms of the contract. Placing goods on a shelf with a big sign on it saying free and a little notice with some legal stuff on it isn't a viable way of binding passers-by who take your goods.

Aside

Thanks to the good folk who implemented the emacs facilities called dissociated-press and rot13-other-window. They can see what for.


Valid CSSValid HTML 4.01 Written by Eddy.