Leading items

Rietveld: another code review aid

With the release of Rietveld, another tool for those interested in doing web-based code reviews is now available. We looked at Review Board back in January. It was inspired by an internal Google tool, written by Python creator and Google employee Guido van Rossum, called Mondrian. That tool in turn spawned Rietveld.

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

There are multiple ways to get a set of patches into the Rietveld system to create an "issue"—the term used for a patch set undergoing review—from an upload of a unified diff to using a python script to retrieve the patches from a repository. Currently Rietveld only supports Subversion, but van Rossum would like to see support added for other version control systems over time. Review Board has a bit of a head start in this area, so it supports Mercurial, Git, Bazaar, Perforce, Subversion and CVS.

Once an issue has been created in the system, reviewers can then be invited to comment on the changes. Navigating through the diff is straightforward, with Javascript being used liberally to give an interactive "local application" feel to the interface. Double-clicking on a line brings up a comment box that a reviewer can fill in to attach some comments to that line. All comments are held as "drafts" until the reviewer is satisfied with their review at which point they "publish" the comments for the author and other reviewers to see.

The Rietveld project is free software, released under the Apache 2.0 license, while the application itself runs via the Google App Engine. Anyone can browse the system, but folks who have a Google account can add issues, comments, and conduct reviews using the tool. Because it uses App Engine, people wanting to try it out on their code need not find a server to install and run the application—as would be required with Review Board—they can just upload a set of patches, invite some reviewers, and proceed.

This kind of simplified deployment is one of the benefits that Google App Engine is meant to provide. For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. Those who wish to keep their source code secret may want to install their own instance of Review Board or another tool. It may be possible to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

While Rietveld does not provide much in the way of additional functionality from Review Board—in fact it lags Review Board in some areas—it does provide a very nice introduction to the Google App Engine interface. Developers will undoubtedly be using the code as a template for their own ideas once Google makes more App Engine accounts available. Given the shared history, language, and framework, it isn't impossible to imagine that Review Board and Rietveld might join forces one day. Even if they don't, some cross-pollination is inevitable which will result in both getting better. Hopefully, with more projects using one or both, better code for the community is the result.

Comments (4 posted)

How not to sell embedded Linux

Every now and then one should have a look at some unabashed fear, uncertainty, and doubt (FUD) material. It's good to know what the other side is saying, the level of unintended humor is often high, and, on occasion, one even learns something. Your editor's suggestion for FUD of the week is this Embedded.com article by Dan O'Dowd. Therein, one will learn about the impending death of embedded Linux as told by the companies which sell embedded Linux.

In particular, Mr. O'Dowd looks at some marketing material from MontaVista and Wind River, and concludes:

One can easily pick holes in this article, starting with the assertion that MontaVista and Wind River are "Linux's strongest proponents." One could also recall that we have heard this kind of thing before; in 2004, Mr. O'Dowd (who happens to be the founder and CEO of a proprietary embedded systems software vendor) helpfully warned us that "intelligence agencies and terrorists" would contribute "subversive software" to Linux and lectured on the need for secret source code to achieve true security. One could point out that many of the points put forward by Mr. O'Dowd appear to be pure fantasy. All of these rebuttals would be valid, but they risk missing an important point to be gained from this article - though it's not quite the point Mr. O'Dowd is trying to make.

Mr. O'Dowd obtains his "facts" from two sources: an advertisement by Wind River Systems (which your editor was unable to find online) and, primarily, from a column by MontaVista founder Jim Ready in Military Embedded Systems magazine. Mr. Ready's evident purpose is to frighten embedded systems vendors into buying his company's services; to that end, he lays it on pretty thick:

Somebody must have had a great deal of fun putting all of those numbers together. The generation of ordinary random numbers can be managed through traditional methods like a toss of the dice, picking numbers out of a hat, or reading corporate earnings estimates. Randomness on this scale, though, can only be achieved through the use of special-purpose software.

Even by kernel.org standards, 5,000 messages per day is fairly intense, though your editor, a subscriber to the linux-kernel, git-commits-head, and mm-commits lists, can attest that the order of magnitude is right at least. But your editor cannot even begin to grasp the thought process which turns a 13-line security patch into 800,000 lines of code. Imagine posting that to linux-kernel. "Pay now or really pay later" indeed.

But the provenance of the numbers is not really the point here. Mr. Ready is perpetrating the fallacy that, to build an embedded system with Linux, one starts with the various components and integrates them all by hand. If a company were to take that path, it might well incur the high costs that Mr. Ready warns about. Creating your own distribution - and maintaining it over a product's life - is, indeed, a difficult and expensive job.

But it is a rare vendor which does that; even Gentoo users outsource much of the integration work to their distributor. Why would any vendor create its own distribution when there are so many out there to base a product on? Customizing a distribution for an embedded application is not a trivial job, but it's not rocket science either. The distributor will keep up with most of those mailing lists, and, somehow, a reasonable distribution also manages to ship security updates which do not involve 800,000 lines of code. There is no reason for embedded systems vendors to wander into the expensive mess that Mr. Ready describes; the creation of a suitable distribution is much easier than that.

Even so, many vendors may decide that, in fact, they would rather not be in the business of customizing distributions. They might, instead, look to a vendor to do that work for them. It makes perfect sense for companies like MontaVista and Wind River (among others) to offer to provide a stable, integrated, and supported platform to embedded systems vendors for a fee. There is honest value in this line of business.

But one does have to wonder why these companies feel the need to scare companies into buying their services. Those services, properly rendered, have a real value which can be sold without resort to outright FUD. Failure to focus on that value gives encouragement to people like Mr. O'Dowd, who would be most pleased if embedded Linux were to go away altogether. This does not seem like a sensible business strategy. Companies which seek to make money from Linux might just want to think twice before poisoning the well they are trying to drink from. That is the real lesson to be learned from this particular piece of writing.

Comments (27 posted)

Blizzard tests the reach of copyright law

Free software users rarely, if ever, need to be concerned about the license that governs the applications they use. Unlike developers or distributors, users are unlikely to pay attention to whether a program is released under a BSD, GPL, or some other license—not so with proprietary software. If Blizzard Entertainment has its way, it could get a whole lot worse, with proprietary vendors controlling the behavior of its users and enforcing it by way of the Copyright Act.

Blizzard, makers of the online role-playing game World of Warcraft (WoW), has filed a lawsuit against MDY, Inc., makers of a tool that assists players in gaining levels within the game. The Glider program essentially plays the game for a user, creating a more powerful character, with additional riches, while the user is otherwise occupied. Some would claim it is a legitimate way to avoid some of the drudgery of "leveling up" a new character, while others would see it as a means of cheating. In any case it is clearly a violation of the Terms of Use (TOU) of WoW.

But those terms are only accepted by a user when they agree to the End User License Agreement (EULA) that comes with the game. Blizzard would seem to have plenty of ammunition to take action against players that use Glider, but instead of suing its customers for breach of contract—perhaps they have learned something by watching the music industry—they went after the easier target. Had they only sued MDY for "tortious interference with contracts", it probably would have attracted little attention. But Blizzard did something that aroused the interest of the Electronic Frontier Foundation (EFF), Public Knowledge, and others by trying to stretch copyright law to cover MDY's actions.

Certainly Blizzard is no stranger to using copyright law—in particular the much-despised Digital Millennium Copyright Act (DMCA)—in ways that many have found objectionable. The courts, at least in the Blizzard v. BNETD case, have agreed with Blizzard, though, shutting down the development of an alternative server for players of their games. Because of that, any time Blizzard makes a copyright claim, serious scrutiny from various watchdogs can be expected.

Blizzard's claim is that, by running Glider, its users are not only in violation of the contract they agreed to, but they are also committing copyright infringement. As has been seen in various file-sharing lawsuits, whenever copyright is supposedly violated on a computer, any program even tangentially involved in that violation is then accused of "contributory infringement"; this is the second claim that Blizzard makes against MDY in its suit. Under Blizzard's interpretation, users are allowed to copy the program into the RAM of their computer as long as they do not violate the TOU. If they do violate them, their license to copy to RAM—a necessary step to be able to use the program at all—is terminated; they are infringing Blizzard's copyright and liable for damages starting at $750 per illegal RAM copy.

If Blizzard's interpretation is upheld by the courts, many other acts would also serve as copyright infringements: choosing a character name that violates any of the thirteen name restrictions spelled out in the TOU, transmitting or posting "any content or language which, in the sole and absolute discretion of Blizzard, is deemed to be offensive...", or "anything that Blizzard considers contrary to the 'essence' of the Program", for example. Under those conditions, Blizzard could essentially claim copyright infringement any time they wish; racking up another $750+ each time the program is used.

Public Knowledge outlined two good reasons that the copyright infringement claim should be discarded. It is well established that it is not an infringement if making a copy is required to use the copyrighted material, as it is for software. Blizzard's argument that due to the terms of the EULA, those who buy WoW are not "owners" but instead license the software is also weak. The courts have always looked on software purchases as sales, not rentals under some company-controlled license, in much the same way that music and movies are purchased. Copyright owners would love to be able to eliminate the "first sale doctrine" that allows owners to sell used books and other copyrighted content, but the courts have so far been unwilling to go along.

One would hope that the courts would be persuaded not to see this dispute in terms of copyright either, but there is the risk that a tool used for "cheating" might not get the benefit of a well-reasoned view. There have been many occasions where the US courts have made surprising decisions regarding copyright. Undoubtedly there are various copycat suits waiting in the wings should such a decision be reached. In the end, though, neither Blizzard nor any copycats really want to go after the actual "infringers"—also known as customers—they want to go after others who allow users to use (or abuse) their software in ways they do not like. It is a classic proprietary software control strategy, and, thankfully, something that free software users do not have to endure.

There is an interesting comparison to be made with free software licensing, though. Licenses like the GNU GPL also restrict behavior based on copyright law; GPLv3, for example, makes some specific requirements on the patent-licensing agreements that one can make with third parties. Like Blizzard, those who release software under a free license can make a claim of copyright infringement (not breach of contract) if the terms of that license are not adhered to. There is a crucial difference, though: free software licenses do not regulate the use of the software, only its distribution. By claiming that users of the software violate copyright if it does not like their behavior, Blizzard is attempting to extend the reach of copyright law far beyond anything seen in the free software community.

It is certainly understandable that Blizzard would prefer that its users did not employ Glider or other, similar software. They believe it unbalances the game; making it unfair to other players. In the past, they have temporarily or permanently banned players for using bot software, but Glider is evidently more difficult to detect, which led to the current lawsuit.

Blizzard must police its own game, however, and should not expect others to do it for them. It is hard to see that Glider is doing anything particularly wrong here, though Blizzard may prevail on either or both of its claims. If players want to find ways around things they don't like about the game, they will, unless Blizzard finds technological means to prevent it. It would appear that there is a substantial business opportunity in helping players avoid some of the boring, repetitive parts of playing the game—one that Blizzard currently ignores.

Though there is no direct threat to free software from this litigation (unless one is developing free game-playing robots), any potential expansion of copyright is worth watching. The community relies upon copyright law to enforce its licenses, so watching how judges make decisions about such issues is important. While it may be that Blizzard is in the right to go after "cheaters" and a company that helps them, it should not be doing that by trying to expand the reach of its copyrights to this extreme.

Comments (25 posted)

Page editor: Jonathan Corbet
Next page: Security>>