New rules for software contracts

In the U.S. justice system, the written law which emerges from the legislative branch is just a starting point. The actual law that one must follow is determined by the rulings of a wide variety of courts across the country. At times, divergent rulings can result in different interpretations of the same law in different regions. The process of creating a coherent set of high-court precedents can be long and messy, and it can create a great deal of uncertainty while it is happening. Uncertainty about the law is never a good thing.

The ALI sees its purpose as improving that process through the creation of documents stating its view of how laws should be interpreted. The process is long and detailed; in some ways, it resembles how technical standards are created. But, certainly, the ALI believes it carries a strong influence in how the courts work:

So if this group sets itself to the task of directing the interpretation of the law around software, it's probably worth paying attention to what they are saying. Unfortunately, the draft principles must be purchased ($40 for the PDF version) and cannot be redistributed, so your editor will be restricted to an exercise of his fair-use rights in talking about this text.

The ALI has set itself the task of clarifying the law around software, and software contracts in particular. So the principles apply to "agreements for the transfer of software for a consideration. Software agreements include agreements to sell, lease, license, access, or otherwise transfer or share software." One might think that this restriction would move much free software activity out of the scope of the principles, but the ALI makes it clear that the source-release requirements found in licenses like the GPL are "consideration." While not taking a firm stance, the principles also suggest that a court would treat the GPL as a contract. The result is a clear statement that GPL-licensed software falls within the scope of this document. Whether software distributed under more permissive licenses would be covered is not addressed.

Much text is expended toward the question of when a contract is formed. In particular, the ALI takes a clear stance that shrinkwrap (or "clickwrap") agreements do, indeed, form a contract which can be enforced. It goes beyond that, though, in that even the "I agree" button click may not be necessary. The reasoning is interesting:

So the ALI says that it's pretty easy to be bound under a software contract. Doing something which requires the permissions in the GPL (redistributing software, for example) is enough. This is important: if the GPL is interpreted as a contract by some court, it will be relatively easy to demonstrate that somebody who is (say) distributing software in violation of the GPL's terms did, in fact, agree to be bound by that contract.

Warranties are treated in detail; this is the section that the Linux Foundation and Microsoft dislike. There are several types of warranties which are discussed:

• Warranties against infringement of somebody else's patents, trademarks, or copyrights, and associated indemnification.

• Guarantees of the quality of the software.

• Warranties of merchantability. Essentially, this says that the software is fit to be sold; it's properly packaged, does vaguely what it says, etc.

• Fitness for purpose: will the software actually perform the function for which it is sold?

• Implied quality warranties: the software has no hidden defects.

Anybody who has actually read a software license agreement knows that software vendors routinely disclaim all of those warranties. And, in fact, the ALI principles allow them to do that - except for the last one. The text reads:

So, if you are distributing free software under free-beer terms, you need not provide a warranty against "material hidden defects." The language is clear here: "consideration" is not enough to force the warranty; there must be actual money involved. But if you are, say, an enterprise Linux distributor, there could be a real problem here. Distributors and others shipping or supporting Linux in exchange for real money will, under these principles, be forced to provide a warranty against hidden defects in that software.

One might think that this is not a huge problem. Linux distributions do not, as a rule, have hidden defects. The list of defects that the distributor knows about is, almost by definition, found in the distributor's bug tracking system, and that information is usually widely available. The problem is that simply maintaining a publicly-available bug tracker is not, in the ALI's view, good enough:

What a distributor will have to do is not exactly clear. Printing out the entire bug tracker seems like an unsatisfactory solution. Perhaps getting the customer to sign a piece of paper acknowledging awareness of the bug tracker would be sufficient. There is an unpleasant vagueness here, right in the portion of the principles which has proved to be most controversial.

The remainder of the document is concerned with breach of contracts and remedies. One term states that software providers must accept a recipient's cure of a specific breach. In the free software realm, that means that one cannot terminate somebody's right to use GPL-licensed software if that somebody acts in good faith to fix a failure to distribute source. In general, nobody wants to do that anyway, so this term really just goes along with existing practice.

The remedies section is mostly straightforward contract-enforcement stuff. There is one interesting paragraph in the discussion:

One might interpret this as saying that, say, patent holders cannot go after free software developers who distribute code held to be infringing. That would all depend on the interpretation of "hobbyist," though. Developers working in a corporate setting would certainly not qualify.

The principles also take on the topic of remote disablement of software - an interesting issue, even if it does not really apply to free software. In summary, remote disablement is allowed, but only in tightly constrained circumstances. It cannot be used with mass-market software, and, in any other situation, it requires a court order first. So, while remote disablement is allowed in principle, it is made difficult in practice.

The meeting of the ALI which approved these principles debated the topic for all of 30 minutes. Clearly the participants do not see much here which strikes them as controversial. For the most part, they may be right; this exercise would seem to make sense. If the courts adhere to these principles, the result should be increased clarity and predictability around software contract law. Beyond that, the proposed principles are generally friendly to free software, acknowledging that it operates under different circumstances and that our licenses are valid. These are good things.

The one real sticking point is the issue pointed out by Microsoft and the Linux Foundation: mandatory warranties. Even that could turn out to not be a huge problem in practice for free software; it relates to hidden defects, and we do not hide our defects. Proprietary vendors - who do tend to hide defects - will have a harder time with this provision. As long as some sort of reasonable interpretation of "disclosure" is reached, Linux distributors should be in reasonable shape.

So, while it would have been nice to have a wider, more public debate about this document, the end result does not appear (to your most certainly not-a-lawyer editor) to be all that bad. We can probably live with those terms.