The Free Software Foundation (FSF) prides itself on being the champion of
free software and its licensing, so a recent misstep with Emacs source code has to be a
little embarrassing. But it is just that, a misstep, and one that was
quickly addressed in two separate ways. While it may be tempting to lambaste
the FSF and the Emacs developers for the oversight (and many have done so),
it really should be seen as a lesson for projects and companies to be ever
more vigilant regarding the licensing of their code. That may cause some
to question whether complying with free software licenses is harder than it
needs to be, but that would be ignoring the huge benefits that the GPL and
bring to the table.
The problem stems from the inclusion of CEDET (a Collection of Emacs
Development Environment Tools) into Emacs 23.2. CEDET has parsers for
various languages that are based on Bison grammar files that get translated
into Elisp (an Emacs dialect of Lisp). The grammar files were not included
with Emacs 23.2 and 23.3, but, in addition, the Lisp output from the Bovine
and Wisent parser generator tools used to do the translation had been
meant that even having the grammar files was insufficient to reproduce the
Lisp code that got shipped with those versions of Emacs.
Needless to say, shipping code without providing source in the "preferred form
of the work for making modifications" is not at all GPL-compliant. That's not really a
legal issue for the Emacs project because the FSF owns the copyright
to the code and is thus not required to follow the GPL. It
certainly sets a bad precedent, however, and one that Richard Stallman and
others wanted fixed in short order. That fix took two paths.
To start with, Chong Yidong created new
versions of the two affected Emacs releases. Those included the
grammar files and a script to apply the changes made to the Lisp output.
That means that anyone distributing 23.2a or 23.3a
would be in compliance
with the GPL.
But that left those who had already distributed the earlier versions in a
bit of a bind, as they were in technical non-compliance with the GPL for
doing so. Stallman solved that problem with a grant of permission that essentially absolves
those distributors of any copyright violation and "extends to versions with unrelated modifications, provided those
versions comply with GNU GPL version 3 in all other respects". He
also notes that the GPLv3 makes the process a little easier:
Thanks to improvements in GPL version 3, we don't need to explicitly
forgive past violations caused by redistributing Emacs 23.1 and 23.2,
because those violations would only become legally significant if the
FSF were to complain about them to the redistributors within 60 days.
The FSF, having granted the above permission to distribute those
releases, could not complain about it.
The version numbers aren't quite right in his explanation above (though they are in the
grant), but his point is an interesting one. The GPLv3 has
explicit language that reinstates the distribution right for violators if
they cease the violation (which the permission grant effectively does) and aren't contacted by the copyright holder in 60
days. The picture for GPLv2 would have been a bit murkier because it lacked
the automatic reinstatement of the license. Though, obviously, the FSF
could have explicitly forgiven the earlier violations had Emacs been
released under GPLv2.
Clearly Stallman is a stickler for adhering to the letter of the
GPL—as he should be—and the problem was resolved less than a
week after it came to his attention. The fact that it took more than a
year for the problem to be recognized is unfortunate, but it stemmed from a
misunderstanding about the "preferred form". It seems that Chong believed
that the Lisp source code, which was distributed, was a reasonable
interpretation of providing the source—which it is. Where it falls
down, of course, is that it isn't the form that a programmer would want to
use if they were to make modifications to CEDET.
There was some unhappiness expressed in the thread on emacs-devel regarding
the coverage of the issue, specifically that which appeared at LWN. While there may have
been some intemperate comments in the thread, it's a little strange to
hear that coverage of the issue should have
been out-of-bounds. As Stephen J. Turnbull points out, it's important for word to get out
about the problem:
There are probably millions of copies in
the wild, and in theory a for-profit distributor could be sued for
statutory damages and subjected to criminal prosecution, and *that*
is *no joke*. The public deserves to be told about this, just as they
are told about other major defects such as security holes in
Turnbull's footnote notes that it is extremely unlikely that it would go
that far, but his point is well taken.
Whether one likes the coverage (and comments) or not, it is important for
the word to get out to downstream distributors so that they can decide if they
want to update to 23.2a or 23.3a. It would be well-nigh impossible for the
project to find and contact all of the different distributors who have
shipped the non-compliant code. The Linux and free software media have a
role to play, though the coverage here and elsewhere still won't reach
every downstream of course.
Turnbull also makes a larger point:
True, the fact that even the FSF can mess up this way is going to make
a few people wonder whether the downsides of copyleft are more serious
than had previously been apparent. So make a solid and timely fix and
those who have open minds will dismiss the whole thing as a rather
There is a cost associated with using free software, and complying with the
license is the biggest part of that cost. Proprietary licenses have their
costs as well, of course, and those can be partially measured in dollars.
Complying with a thick stack of legalese in order to
license some bit of proprietary code may seem easier, at least
partly because companies are used to those kinds of licenses, but probably
isn't. In the end, free software is an enormous bargain, in general,
because the amount of work required to comply is far outweighed by the
usefulness of the code. It may take a bit of a different mindset, but the
value gained is enormous.
Beyond that, the GPL also provides a level playing field for contributors,
so that individuals and companies can contribute to a common code base and
know that no one has the upper hand. No one can take the code proprietary
or make changes and distribute them without sharing those changes back. Copyright assignment (or licensing) may
muddy the water to some extent, but, for many projects, the GPL provides the
needed cover for competitors to collaborate.
In the end analysis, this was a minor problem that was addressed fairly
quickly. The grammar files were always available at the CEDET site, and
the handmade changes were pretty trivial
overall. That said, it is important that it was found and fixed, not least
because the FSF is the poster child for GPL compliance. The silver lining
is that other projects are likely to remember this
mistake and keep an eye out for similar problems in their own code. If
suffering a little public embarrassment results in fewer GPL mistakes (and
violations) down the road, the FSF's goals will have been well-served in
Comments (23 posted)
Finding an open source RSS feed reader is not a hard task. Finding an
open source feed reader that compares with Google Reader is another
story. After using
Newsbeuter for a while, I eventually slipped back to using Google
Reader. Having a web-based reader is just too convenient for those of us
who use two, three, or more computers regularly. After a bit of hunting, I
found rsslounge, a GPLed and
web-based feed reader that gives Google Reader a strong run for its money.
Written by Tobias Zeising, rsslounge requires PHP 5.2.4, MySQL, and a web server. The web server needs to support .htaccess files, but otherwise it doesn't appear to be too picky. I chose Apache, but you should be able to use lighttpd or nginx if you are willing to add a few re-write rules.
Installing rsslounge is a five-minute task for anybody passingly
familiar with setting up a PHP-based application. If you've ever installed
WordPress, Drupal, or something similar, the rsslounge installation is easy
as pie. The only word of caution when installing rsslounge: users should be
sure to create an administrative account if it's going to be on a public
network. Without such an account, anyone can come in and change the
settings of the installation and/or add and delete feeds. Note that
rsslounge is designed for a single user, and not for multiple users with
Since I've been using Google Reader for some time, I decided to start testing rsslounge by importing my Google Reader feeds. This was easy and took about 30 seconds for rsslounge to parse the file and start fetching feeds. It took about another minute before rsslounge had fetched the feeds and started displaying them. I should note that rsslounge did a good job of importing the feeds and preserving the categories/folders from Google Reader. This is sometimes a problem when importing Google Reader's OPML into another application, and, if you have a lot of feeds, having to re-categorize them can be a bit of a hassle.
The layout for rsslounge is similar to Google Reader: The list of feeds is displayed on the left-hand side and the articles are displayed on the right. Each item in a feed is displayed with the time stamp for the item, its headline or title, and then the name of the site that it originated from. On the left-hand side, rsslounge displays the site names, site icons, and unread count (if any). To read an item, clicking on the headline will expand the article, or clicking on the site name will open the link in a new window. Like Reader, you can "star" items to save them for re-reading. One thing that I'm not crazy about with rsslounge is that there appears to be no way to expand items by default. That is, Google Reader gives the option of just skimming headlines, or skimming full posts. With rsslounge, you simply skim headlines and have to expand each item when you want to read it.
If you like to skim feeds without touching the mouse, rsslounge supports
a short list of
keyboard shortcuts. You can navigate within feeds pretty easily, though switching feeds using the keyboard does not yet seem to be supported. So, for example, if you're reading through your uncategorized feeds and want to switch to a category, there's no keyboard shortcut for that.
Though rsslounge may not be at par with Google Reader's keyboard
shortcuts, it does make up for that with a few features that you don't get
with Google Reader. For example, rsslounge allows you to browse through
feeds by date. Up in the left-hand corner is a small calendar icon (which
is easy to miss) that will expose a monthly calendar. You can then choose
to see a feed, category, or all feeds by date. For instance, if you want to see only feeds from July 16, you can click the All Items category and then select the 16th from the calendar.
Managing feeds is also far more pleasant in rsslounge, at least in this users' opinion. If a feed's URL changes, in Google Reader you're stuck unsubscribing and then re-subscribing using the new URL. In rsslounge you simply click on its edit icon, change the source for the feed, and you're good to go.
The settings for feeds are more fine-grained than with Google reader as
well. If you subscribe to a lot of RSS feeds that are for images rather
than text, such as feeds from photo blogs like deviantArt or Flickr,
rsslounge has a special feed type for those. If you select the image type
for a feed, then rsslounge displays a grid of thumbnails instead of a list of headlines.
If you have some feeds that take priority over others, you can increase their priority so that they'll be shown first. You can also, of course, decrease a feed's priority so that you only see it after you've read everything else. Another thing that many users will appreciate is the option to filter feeds. You can provide a regular expression in the "Edit Feed" dialog that will be used to match items from a given Atom or RSS feed. If the entry doesn't match the expression, it won't be fetched. It doesn't seem that rsslounge provides support for filtering out entries that match an expression, unfortunately.
The only downside that I've found so far with rsslounge is a paucity of documentation and information on the project in general. The wiki for rsslounge on Google Code has a brief set of installation instructions, and there's the keyboard shortcuts document, and that's really about it. It appears to be a one-man show, though there is a forum for users to ask questions. However, the forum is a bit underpopulated.
Other web-based alternatives
A few years ago, there was a project released by Fastladder, free web-based RSS and Atom
feed reader service. It claims to
be faster than Google Reader and Bloglines, with a "transaction speed
close to that of humans", whatever that means. Called OpenFL
(at least according to its README, the Google Code project is just
"fastladder"), it's a Ruby on Rails project that can be installed on Linux,
Windows, or Mac OS X. However, it looks like the project is more or less
dead as an open source effort. The last updates shown on Google Code date back to April 2009, and most of the code hasn't been touched since February 2008. There's also a fork on GitHub, which is also a bit long in the tooth — the last updates are from May 2010. However, the code is out there, so if anyone would like to pick it up it's easily forkable on GitHub.
For non-defunct projects, there's also Tiny
Tiny RSS, which also requires PHP and a web server, but gives
the option of MySQL or PostgreSQL. It requires a bit more setup and
tweaking than rsslounge, but also offers more options. For instance, it can
be configured to use SimplePie for parsing feeds instead of Magpie, and has
a multi-user mode. Nathan Willis has a good write-up on Linux.com about Tiny Tiny RSS that goes into detail on setting it up.
Overall, rsslounge looks to be close to a drop-in replacement for Google Reader. It does lack a few features, but it's a good substitute for Google Reader without the need to give up control of your data or privacy.
Comments (21 posted)
Developers from the Elementary OS
project have crafted a new method that allows users to install and run
sandboxed versions of unstable applications more safely inside their main Linux environment. Dubbed Glimpse, the system uses a chroot environment to isolate the unstable code and Another Union FS (aufs) to safely provide the chrooted binary with read access to the host filesystem. Just as importantly, Glimpse provides a straightforward mechanism for users to automatically install the unstable applications they wish to test, using pre-configured OS "profiles."
It is certainly already possible to test pre-release upstream
applications before one's distribution provides them directly, of course,
but the Glimpse team found the available options unsatisfying. Testing a
new release in a virtual machine isolates it from real world data —
which makes it difficult to get a practical feel for editing, file
management, and a host of other tasks. Compiling from source deprives one
of regular updates, and often introduces the time-consuming task of
compiling pre-release library dependencies as well (which may also introduce instabilities to the rest of the system).
Launchpad offers an Apt-based middle ground through its personal package
archives (PPAs), which quite a few development teams use to provide public
testing or "daily
build" repositories, but these too often require updating library
packages with the resulting hit to system stability. In contrast, Glimpse
provides the user with an easy-to-use launcher that can start up
pre-release applications, but keeps all of the packages involved sandboxed
from the host OS. The applications run at native speed, and can read local
files, but cannot modify or delete them on the underlying filesystem.
The Glimpse framework makes heavy use of the Ubuntu Customization Kit (UCK)
tools, which are designed to add and replace individual packages within
bootable ISO images, but provide extra utilities as well — including
uck-remaster-chroot-rootfs, which executes a package with chroot
providing an alternate root directory.
The Glimpse workflow begins with installing a distribution "profile" package. A profile consists of Bash scripts to install, update, and purge the test OS, and scripts to install and purge specific applications. Profiles are distribution-specific, not only because they start with specific ISO releases as the base system, but also because they rely on remote Apt repositories to provide package updates, include distribution-specific tweaks to enable PulseAudio compatibility and other miscellany, and provide a custom "launcher list" of testable applications.
When run, Glimpse loads a list of the installed OS profiles. The first time a profile is used, Glimpse downloads the base ISO of the OS to be tested (in the current profiles, this is a bootable live CD image), or allows the user to locate a local copy on the filesystem (if one exists). It then uses UCK tools to "remaster" the image adding any external unstable packages users wish to test. Subsequently, Zsync pulls in any updates to the base ISO, which prevents the need to re-download the entire image if an updated alpha or beta image is released. Together, these tools handle dependency resolution in the same fashion that Apt would for a full installation.
When an installed profile is run, Glimpse opens up a second window with
basic profile-control buttons: "Launch an app," "Update sandbox," "Purge
file modifications," and "Remove sandbox." The "Launch an app" button opens
up a window with the pre-configured launcher list defined in the profile.
These launchers are merely a pre-selected list of .desktop
launchers available within the sandboxed OS. Aufs is used to mount an
overlay filesystem on top of specific directories (/home/$USER, /var/run,
/proc, /dev/pts, /tmp, /sys, and /dev/shm). The overlay filesystem provides read-only access to the host OS underneath. That permits the user to work with his or her real files, but isolates any changes within the sandbox. When the user clicks on a launcher, the binary is executed with uck-remaster-chroot-rootfs.
Thus far, the only two profiles available are Ubuntu 11.10 and Elementary OS 0.2 (which is an Ubuntu derivative). The Elementary OS profile includes launchers for nine Elementary OS applications not found in upstream Ubuntu, such as the BeatBox audio client and Marlin file manager. A terminal is also in the list, however, which makes it possible to launch the Elementary OS version of any other application (which could be useful to test compatibility or new features).
Of course, since Elementary OS is such a new distribution — the first release was in March of 2011 — the Ubuntu 11.10 profile will certainly attract a larger set of users. Unfortunately, at the moment it is considerably less polished: it cannot initiate the application launcher window of the Elementary OS profile, and there are several bugs filed indicating that the launcher and filesystem mounting scripts are incomplete. Nevertheless, interested Ubuntu users can still make good use of the Elementary OS profile to test PPA-provided unstable packages thanks to the fact that Elementary OS 0.2 uses Ubuntu 11.10 as its base ISO, and provides a terminal in its Glimpse application launcher list.
Glimpse in practice
Glimpse itself is available
as a PPA via Launchpad. The main package and the two official OS profiles
are in separate packages. Zsync and UCK are dependencies, as are the GTK+ shell-script interface Zenity and a special purpose library named Gaffel that Glimpse's developers wrote in order to write better GTK dialogs for Glimpse.
Where it works, Glimpse offers a compelling user experience: there is no lag, the sandboxed applications run at full speed, and are virtually indistinguishable from natively-installed programs. The main difference is the process for launching them: the Glimpse UI must be launched first, then the proper OS profile selected, then the launcher list, then, finally, the application — with each step spawning a separate window. For launching a single application, it would be much nicer to roll those steps together (perhaps consolidating them into a sub-menu of the desktop environment's Applications menu, just to provide some level of distinction between the sandboxed and un-sandboxed applications). Then again, it could be argued that testing "unstable" code is not a process most users will engage in on a long-term, regular basis.
The Glimpse sandboxing method does have its limitations. First, no matter what distribution is used for the profile (and no matter how many libraries within the sandbox UCK loads in order to launch the app), applications running in Glimpse sandboxes are always run using the host OS's kernel. That could cause problems if the application in question needs a driver or filesystem module unavailable in the host OS kernel, but it is probably unavoidable. Second, Glimpse uses aufs to mount overlay versions of several key directories, but for one reason or another, it does not mount the /usr/share hierarchy, which has the side effect of making the host OS's window manager themes unavailable. If you use a theme not provided in the default install, your sandboxed applications will look (and perhaps even behave) differently.
Glimpse also allows only one copy of each OS profile to be installed. The profiles and their associated files (the ISO image, "remastered" update packages, and filesystem overlays) are stored in ~/.glimpse, each in its own subdirectory by distribution name, rather than by some unique key or ID, and the scripts enumerate and access them by name. While this is good enough for the general use-case (testing pre-release applications), Glimpse would be useful for some additional scenarios if multiple copies of each profile could be installed and compared.
The system also lacks a UI for adding additional application launchers and additional Apt repositories to an installed profile. Here again, for testing purposes, it is easy enough to open a terminal and run add-apt-repository to enable a third-party PPA, but as long as we are dreaming of game-changing application testing, we'd might as well dream big. Finally, as is frequently the case with new utilities, there is a shortage of documentation. The code is reasonably well-documented (and it is Bash), but I eventually gave up trying to hack the incomplete Ubuntu 11.10 profile into shape with only the Elementary OS profile for guidance.
From a security standpoint, developer Sergey Davidioff cautions that
exploits breaking out of the chroot environment would then break through Glimpse as well. This could result in a privilege escalation attack, because Glimpse must be run with root privileges in order to mount aufs filesystems. The trouble is that Glimpse launches the tested applications with uck-remaster-chroot-rootfs, which was designed to execute system configuration scripts when remastering an ISO image. So although it launches the selected application in a chroot environment, it also launches that application as root. Chroot alone does not provide a security "jail." Accidental vulnerabilities are a constant threat of course, but a malicious attacker could replace a "daily build" PPA package and thus trick users into running it in Glimpse.
Glimpse of the future
Davidoff frames his introductory blog post about Glimpse as a project that will help Elementary OS users alpha-test new software for the distribution (although, for the time being, Glimpse is not yet an official sub-project of Elementary OS). There have been other tools designed to do the same task, such as Arkose and Ubuntu Test Drive. Arkose is designed to build a static sandbox around a single application, however, which means that users must repeat the process for every application they test. Ubuntu Test Drive runs the "tested" application on a remote server, and tunnels the GUI back to the client machine using the NX protocol.
Between the two, Arkose is definitely the closer match for Glimpse, and with some additional code it might be able to provide a comparable experience, with multiple applications and support for daily (or frequent) package updates. However, it would probably be shortsighted to focus solely on Glimpse's ability to track a full distribution during the alpha-testing phase. A simple scheme to run chroot-sandboxed applications with aufs-based filesystem access has other useful applications, too.
For example, I occasionally wonder whether or not some of the dust-covered binaries of long-abandoned applications in my desk drawer (such as IBM ViaVoice for Linux or The Sims) would still run — and perhaps run better on today's faster processors. To test them out, I would need to procure older, not newer, copies of a bunch of system libraries. But if I could sandbox them with Glimpse, it would be far easier to work with than running a full distribution in a virtual machine, and the odds of getting the audio to work correctly would be better as well.
If multiple profiles were supported, a range of testing scenarios become possible that today would have to be done in a virtual machine. Naturally, since Glimpse does not provide access to a sandboxed kernel, it is no replacement for a full virtual machine environment — but at the application level, it is interesting to speculate. A great many Unix graybeards will fall back on "chroot it" as the answer to how to test an untrusted program, but it has never been presented with a friendly GUI veneer on the outside. Perhaps now it has.
In the short term, Glimpse needs to complete its Ubuntu 11.10 OS
profile; this will attract a significantly large user and developer base
that could extend the tool further. A way to launch sandboxed application
without running them as root is critical to attracting more than the casual
user — although here again the exposure to attack involves planting a
backdoor or exploiting a bug in an upstream application. There are bugs filed for encrypted home directory support and other features, but in the medium term the next big hurdle will be getting contributors to develop profiles for other distributions — openSUSE and Fedora are mentioned in Davidoff's blog post and, although much of the logic remains the same, supporting RPM and Yum instead of Apt and Debian packages will be a challenge, and adding support for other distribution's ISO remastering tools could be a task unto itself.
Whatever direction Glimpse takes in the future, for today it is an intriguing tool for users and developers alike. Most distributions are on six-to-eight-month release cycles, which makes it conceivable to run "unstable" applications while waiting for the next version to hit the file server. Whether testing or living on the bleeding-edge is the goal, Glimpse does make it simple to get started.
Comments (11 posted)
Page editor: Jonathan Corbet
Next page: Security>>