On May 18, the Linux Foundation announced
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
Comments (38 posted)
The next buzzword on the desktop is likely to be "Activities." Today, the
chances are high that you have never heard of them, or, if you have, that
you have not identified the different uses of the term as having anything
in common. However, what all the usages do have in
common is that they signal a move away from a static desktop towards one
that changes with the tasks being performed.
Any more exact definition is elusive. All the same, Activities are
already part of the KDE 4 series, and scheduled to become more
prominent in the upcoming 4.3 release. Similarly, GNOME 3.0, which
is due out next year, will include its own, more limited concept of
the term. But, under any implementation, the term signals a shift in the
desktop, with free software developers leading the way.
The concept of Activities originates in Sugar, the desktop designed for
the One Laptop Per Child (OLPC)
project. In Sugar, "Activities" is used as a synonym for
"application." However, Gary C. Martin, one of the coordinators
for Sugar's Activity Team, explains that the change is more than
semantics or marketing. Because Activities run within the general
collaborative frame of Sugar, using them is intended as a very
different experience than running a standalone application on a
For me, the key parts of Activities are that
concepts of document, executable, and collaboration state into a
single, simple to use user interface. With the
Activity state automatically kept in the Journal, it's easy to
resume or reflect on past work, and, with realtime collaboration
as a first class feature, peer sharing and group work is
In other words, Sugar's Activities are not just about running an
application, or learning how to produce a spreadsheet or a
presentation. Instead, they are conceived as part of the total
learning experience that Sugar is designed to provide.
"It's not about producing documents in applications," Martin
explained. "It's the learning that happens while doing Activities.
Activities are at the heart of learning in Sugar. They support a class
working together, seeing what others are doing, sharing, learning, never
losing their work, and [being] able to reflect on that work with their
parents and teachers." Although the mechanics of running an Activity
may not be all that different from running an application in GNOME or KDE,
what matters is the context in which it is used.
The KDE implementation
Part of the design philosophy of KDE 4 is to accommodate the
growing sophistication of users, according to long-time KDE
developer Aaron Seigo. Thanks to mobile devices and gaming
consoles, many users — particularly younger ones — find
a static desktop confining. Nor is a traditional desktop
especially suited for multiple, specialized uses that range from
office productivity to social networking. Depending on whether
people are working, attending classes, or socializing, their ideal
desktop could vary considerably.
Even within a single activity, desktop needs can change, Seigo
Watching people use their computers, we noticed that a
lot of people who work on more than one project at a time were
manually arranging their icons between projects,
Graphic designers, for instance, would have two or three
projects they're working on. When they worked on one project,
they would take all the icons and files they're working on, and
they'd put those icons on the desktop. Then, when they were done
with that project, they'd put those icons back in a folder that
wasn't showing on the desktop, and move all the icons for a
second project out on to the desktop.
To simplify computing for these more sophisticated users, the KDE
concept of Activities was born: desktops with their own custom
sets of widgets, icons, and applications, that could be switched
by keyboard shortcuts or by zooming out via the Desktop Toolkit,
the cashew-shaped icon on the upper right of the desktop.
Originally, these desktops were called "containments" by Chani Armitage,
the developer who first implemented them:
But I didn't really like
the word 'containment' because it was pretty technical. I'd been using an
OLPC for a while at the time, so I actually got the inspiration from there.
We've kind of co-opted the term and put it to a slightly different meaning
than what they've been using.
In some senses, Activities resemble virtual desktops, which KDE
and other desktops have had for years. And Seigo acknowledged
that "they're complementary ideas." However, he
suggested that the resemblance depends on how you use virtual
desktops. If you use virtual desktops mainly to separate out
windows — for example, to keep a virtual terminal always
ready, or to run a full-screen browser — then there is
little to choose between virtual desktops and Activities.
By contrast, if you use separate virtual desktops for different tasks, then
Seigo suggested that Activities provide a superior experience, one closer
to that of mobile devices and more suited to some of the functionality
planned for the KDE 4.4 release (see below). Still, because of user
demand, KDE 4.2 allows an Activity to be tied to a particular virtual
desktop by changing a configuration
setting, and the final version of KDE 4.3 will include a setting for
the same task.
Seigo emphasized that the increased visibility of Activities in
the 4.3 release is not intended to pressure people to use them.
"What's really nice about this concept is that you can
completely ignore it," he said. "It's completely
unobtrusive." After all, he added, "for certain people,
the current metaphors work well," especially those who do
not carry their computers about or those who use them for basic
The main change heralded by Activities, according to Seigo is
that, unlike on the traditional desktop, they do not enforce one
particular way of working for every task:
This is no longer about forcing people into a mode of
work or behavior. Rather, we're trying to build
interfaces that are relevant to the device you're using them on,
and also relevant to the user — which means where are you
and who are you? That's something that hasn't started to sink in
with a lot of people.
People are demanding
more flexibility, and, with the current state of hardware, it can
be provided today without any undue strain on system resources.
GNOME 3.0's workspaces
Possibly because of KDE's use of the term, the implementation of multiple
workspaces (aka virtual desktops) is causing some confusion about GNOME-Shell, which is scheduled
to become the basis for GNOME 3.0.
As implemented so far, GNOME-Shell's Activities is an overlay mode for
organizing workspaces and arranging groups of windows on them. To a large
extent, it resembles the Zoom view in KDE. However, some people are
referring to the workspaces themselves as Activities, a change in reference
that might just stick, and make GNOME 3 more closely resemble KDE 4.
So far, these workspaces seem to function the same as those in recent
versions of GNOME and KDE, with no capacity for separate customization. Nor
have any plans to extend their functionality been announced. But, with ten
months before GNOME 3.0's estimated release, that could change, especially
if KDE's Activities become widely-used. At this point, though, even if
the reference is different, the use of the term does suggest that GNOME
developers are also thinking about contextualized computing. And even if
the implementation remains what it is today, the overlay mode remains a
de-emphasis of the single, static desktop.
Exactly how GNOME 3.0 will implement Activities remains uncertain. Meanwhile,
KDE developers are already contemplating future developments for
contextualized computing. Armitage talked about allowing Activities to
be de-activated and stored. Perhaps, too, she mused, applications
could become more contextualized; for example, KMail might be set
so that it used a particular address book when opened on a
A change already planned for KDE 4.4 is to associate an Activity
with a certain location via the new geo-location layer in KDE.
University instructors, for example, could have one Activity with
their notes and slides that would automatically open when they
started KDE in the class room for a particular class, and
another Activity with their research that started in their
offices. "You would basically train the computer,"
Seigo said. "As you move around, the interface comes to
Meanwhile, the different uses of the same term can obscure exactly
what each project means by it. But, as Seigo said:
idea that binds them all is a movement towards task-oriented
computing. Our viewpoint is that tasks are highly-contextual: What
are you doing? Where are you doing it? And who are you?
Whether Activities in any form will come to dominate the desktop
is still uncertain. Possibly, they will remain the interest of a
relatively small set of users. However, regardless of their
ultimate success, the fact that the context-based computing is being
emphasized more strongly is a shift in thinking about the desktop, and one
that free software is leading. Virtual workspaces -- let alone KDE's
Activities -- remain non-standard on Windows, while OS X's Spaces are
turned off by default. On both, the static desktop remains the norm.
"Nobody else is looking at these things," Seigo
said. "You don't see it on Windows and you don't see it on
Mac. This is very much an innovation that free software pretty
much owns. And I'm really happy to see that in GNOME and KDE
we're right at the front of this development."
Comments (16 posted)
Back in November, the OpenBSD development community first heard
project. OpenSMTPD is an all-new mail transfer agent implementation for
OpenBSD; it is getting ready for release sometime soon. It is an
interesting exercise in wheel reinvention which may well prove to be a
OpenSMTPD is developing most of the features that one would expect from an
SMTP daemon. It can speak the SMTP protocol, including the SSL-based
versions for added security. Virtual domains are supported, as are forward
files and external delivery agents like procmail. There are plans
to add a sendmail-like "milter" capability for mail-filtering extensions.
In summary, it is growing to the point that it can do most of the basic
things that the other MTA implementations do.
Given that those implementations represent a great deal of development and
debugging time, and that a new mail daemon will surely bring new bugs and
even security problems, one might well wonder why the OpenSMTPD developers
are doing it. It appears to come down to a combination of licensing issues
and a desire for a simpler and more OpenBSD-like tool.
Journal article which brought OpenSMTPD to the community's attention
includes this quote from Gilles Chehade, who started this project:
A few months ago, I had to dive into the configuration of sendmail
to make a very small change. It turns out I spent almost an hour
trying to make sense out of a maze of files that were plain
unreadable. Even the slightest changes would cause me to stand a
couple minutes thinking, just trying to make sure I really wanted
to make that change.
It is a rare mail system administrator who has not had a moment like this;
the lowest levels of sendmail configuration are a thing which must be seen
to be believed. The higher-level "language" implemented with a set of M4
macros has helped to keep an entire generation of administrators sane, but
it still presents its challenges. The end result is that, even though
sendmail seems to be long past its period where new remote root exploits
were a weekly experience, it is still a program with roots in the 1980's
that many administrators prefer to avoid.
So what about Postfix? It turns out that
Gilles likes Postfix reasonably well, but there is a fundamental problem
with it: the IBM Public
License under which Postfix is distributed includes copyleft-style
source availability requirements. Copyleft is not particularly popular in
OpenBSD circles, so that license ensures that Postfix will never be a part
of the OpenBSD source tree. For Gilles, that meant that he needed to
install Postfix separately after each OpenBSD installation; it also means
that Postfix does not receive the same level of attention from OpenBSD's
code auditors. So it seems that OpenSMTPD is being developed, at least
partially, out of a desire to have an MTA under a permissive license which
is less intimidating than sendmail.
Needless to say, the licensing issue is enough to exclude GPL-licensed
solutions like exim as well.
Beyond licensing, though, it seems that the OpenSMTPD developers want to
have an MTA which has more of an OpenBSD-like feel. The configuration file
format will be simplified and have a format very similar to that of the
"pf" packet filter. Techniques like privilege separation have been
designed into the program almost since the beginning. And, of course, it
will be a part of the unified OpenBSD source tree; it has been in the
OpenBSD CVS repository since November.
Some people within the OpenBSD community have questioned the need for this
kind of project, given the number of mail transfer agents already
available. Certainly there are projects which are not worth the effort
which goes into them, but, that said, it is usually a mistake to criticize
the work of people who have decided to scratch a particular itch.
Interesting things can come from such developments. From OpenSMTPD we may
get an MTA which sheds a lot of legacy requirements (sendmail still has
features that come from a time when one had to worry about routing a
message via two DECnet hops, over the NSFnet, then into a CSNet node) and
which, presumably, will offer a high degree of security.
Once it's stable, it would not be entirely surprising to see a Linux port
of OpenSMTPD as well. Whether it will take off in the Linux world remains
to be seen. Tools like OpenSSH are nearly universal on Linux systems; OpenCVS is ... less so. But
options are usually good, and the OpenSMTPD developers are busily working
toward the creation of another option for a crucial system component. It
will be interesting to see how it turns out.
Comments (17 posted)
Page editor: Jonathan Corbet
Next page: Security>>