On May 18, the Linux Foundation
that it had sent a joint letter to the American Law Institute protesting
some provisions in the ALI's proposed principles to be applied to the law of
software contracts. That was likely the first that many LWN readers had
heard of this particular initiative - or, indeed, of the ALI in general.
Your editor, being a masochistic sort of person, has plowed through all 305
pages of the principles (which were made official by the ALI on
May 20) with an eye toward their effect on free software. What
follows is a non-lawyerly summary of what he found.
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:
The final product, the work of highly competent group scholarship,
thus reflects the searching review and criticism of learned and
experienced members of the bench and bar. Many Institute
publications have been accorded an authority greater than that
imparted to any legal treatise, an authority more nearly comparable
to that accorded to judicial decisions.
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
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:
For several reasons, § 2.02(b) does not establish a bright-line
rule for enforcement requiring, for example, clicking "I agree" at
the end of an electronic standard form. First, as already
mentioned, case law already presents a wide variety of formation
types that are not easily captured by a narrow rule and, for the
most part, handle the issues in an effective manner. These include
situations in which the transferee is aware of the terms because of
a course of dealing or because the transferor delivered an update
of previously downloaded software. The safeguard of requiring a
click at the end of the form does not seem necessary in either
case. Second, open-source transfers rarely follow the current
click-wrap model, and these Principles should not upset an
established custom unless problematic.
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
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
A transferor that receives money or a right to payment of a
monetary obligation in exchange for the software warrants to any
party in the normal chain of distribution that the software
contains no material hidden defects of which the transferor was
aware at the time of the transfer. This warranty may not be
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
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:
Disclosure of a material hidden defect occurs when a reasonable
transferee would understand the existence and basic nature of a
defect. Disclosure ordinarily should involve a direct communication
to the transferee, if feasible. A mere posting of defects on the
transferor's website generally should be insufficient.
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
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:
For example, software "hobbyists" (who do not "deal in software of
the kind transferred" or "hold [themselves] out by occupation as
having knowledge or skill peculiar to the software") may provide
open-source software without charge under terms that disclaim all
responsibility for performance and provenance. Under the
circumstances, no remedy at all may be the appropriate result when
the software does not perform or infringes a third party's
intellectual property right. In other words, the transfer of
open-source software in this context may be a case in which,
essentially, there can be no breach by the transferor that supports
the grant of a remedy to the transferee.
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;
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
to post comments)