Leading items

New rules for software contracts

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:

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.

Comments (38 posted)

Activities and the move to context-oriented desktops

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 traditional desktop.

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 said:

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:

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 productivity.

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:

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 incorrectly 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.

Coming attractions

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 certain Activity.

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 you."

Meanwhile, the different uses of the same term can obscure exactly what each project means by it. But, as Seigo said:

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)

Coming soon: OpenSMTPD

Back in November, the OpenBSD development community first heard about the OpenSMTPD 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 useful project.

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.

The OpenBSD Journal article which brought OpenSMTPD to the community's attention includes this quote from Gilles Chehade, who started this project:

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>>