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,
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)
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
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:
This embedded Linux bashing from embedded Linux's strongest
proponents should give pause to those who are thinking through
their embedded operating system strategy. If embedded Linux
champions are saying that embedded Linux is terrible, why would
anyone want to risk their products or their company on it?
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:
To keep abreast of the changes occurring on a daily basis, a
developer needs to monitor the email traffic of 11 different and
unsynchronized open source projects: kernel.org, the core home of
the Linux kernel; the gcc and glibc projects (the core tool chain
and libraries from FSF at fsf.org); and at least nine other
components that would typically comprise a useable Linux
Kernel.org itself may have up to 5,000 messages a day with 1,000 of
these being patches that need to be evaluated and possibly applied
to the source base. Simply ignoring the traffic, figuring that the
system in use seems to be working well enough, can lead to
disastrous consequences later. For example, a recent security patch
that took all of 13 lines of code to implement against an embedded
Linux system would have taken more than 800k lines of source
patches to implement if the previous trail of patches had been
ignored. It's a classic case of pay now or really pay later.
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
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)
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
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>>