Leading items

Emacs and the GPL

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 free software 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 hand-edited. That 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:

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:

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:

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 the process.

Comments (23 posted)

Web-based feed reading with rsslounge

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 separate accounts.

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)

Getting a better Glimpse at unstable applications

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.

Glimpse inside

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)