Leading items

Getting grubby with ZFS

The GRUB bootloader is widely used to get Linux (and other) systems running. Its flexibility and configurability make it a logical choice for many types of computers, as does its "just works" factor: your editor cannot be the only one to smile when he realizes how long it has been since the last "I forgot to run LILO and my new kernel won't boot" episode. One of GRUB's nice features is its ability to understand filesystem structures and find bootable kernels on the fly. So the addition of support for another filesystem type would not normally be a noteworthy event. When that filesystem is ZFS, though, people will pay attention.

ZFS was developed by Sun Microsystems, and is now owned by Oracle. It offers some nice features that Linux does not (yet) have in a production-quality filesystem. ZFS, like the rest of Solaris, is licensed under the CDDL, which is not considered to be compatible with the GPLv3 license used by GRUB. Over the years, ZFS has also been the subject of a fair amount of dark murmuring with regard to a large pile of associated software patents. For these reasons, there has never been a serious push to get ZFS support into Linux.

One would think that these concerns would keep ZFS support out of GRUB as well. It turns out that one of those concerns - licensing - is not relevant for the simple reason that Sun saw fit to release some small bits of ZFS code under the GPL for the express purpose of compatibility with GRUB. The released code is not enough to run a ZFS filesystem; it's really just enough to locate and read files. Just enough, in other words, to bootstrap a ZFS-based system.

What about software patents? One would assume that Oracle would not go out of its way to sue GRUB users for using its built-in ZFS code to boot Solaris systems. Those people are, after all, Oracle's customers, and, for all the criticism of Oracle which has been heard recently, nobody has suggested that it has reached a point where it will take advice from the SCO playbook. Still, assumptions can lead to trouble; Oracle may yet hire Darl McBride once Larry Ellison retires to his yacht, it may sell the patents to somebody else, or any of a number of other things may happen. Depending on rational behavior from corporations over the long term is always a scary bet.

In this case, the GRUB maintainers (and, presumably, the Free Software Foundation, which owns the GRUB project) have decided that incorporating the code is safe. Their reasons are described in the announcement; it comes down to the fact that Oracle has distributed the code under the GPL:

The announcement goes on to suggest that anybody who cares about the freedom of all their users should always release code under the latest version of the GPL.

There is an interesting implication here. The FSF is counting on Oracle being bound by the strengthened patent clauses found in GPLv3. But the code found in Solaris was never explicitly distributed under GPLv3; it is under a GPLv2+ license. The code only became explicitly GPLv3 when it was moved into the GNU-run Savannah repository. The FSF is saying that, thanks to the "or any later version" language in the copyright notice, users of the ZFS code can assume that Oracle is bound by the more explicit GPLv3 patent language even though GPLv3 did not exist when the code was released. They are probably right.

GPLv2 arguably contains an implicit patent grant. But it certainly does not have the Novell-inspired "you can't buy a license for your users only" language. Sun's lawyers may not have thought that they were giving the FSF the right to further bind Sun's actions with regard to patents through updated versions of the GPL. Using the "or any later version" language hands a powerful blank check to whoever controls later versions of the license.

The merging of the ZFS code raises eyebrows for another reason: neither Sun nor Oracle has assigned ownership of this code to the FSF. The Foundation's policy is clear: it needs to obtain assignment, or, failing that, a complete disclaimer of rights on the code; the ZFS code comes with neither. This exception to policy is justified this way:

The FSF has often claimed that copyright assignment is required in order to be able to prosecute infringement cases. Either the FSF no longer believes this, or it has decided that license enforcement will never be necessary for GRUB. It's hard to find any other possible explanations for this decision.

The FSF has also pronounced as "safe" a chunk of code which was never submitted for inclusion by its authors, and which is owned by a company which is known for its active legal department. This is the company which is currently suing Google over an alternative Java implementation, after all. Perhaps the FSF has a hush-hush agreement with Oracle regarding the merging of this code, but that seems unlikely. Merging the code is almost certainly safe without such an agreement, but it would be a stretch to say that it is more safe than merging code from individual contributors who do not wish to assign their copyrights to the FSF. If this code can be safely accepted without copyright assignment, so can contributions from many others.

Might the FSF be slowly rethinking its position on copyright assignment? There have been few signs of any such deliberation, but the acceptance of the ZFS code sets an interesting precedent. Perhaps the FSF has an internal policy saying that unassigned code is acceptable if it comes from an Oracle-sized corporation? It would be nice to know what the FSF is really thinking.

Comments (59 posted)

Mozilla's open web app platform

The Mozilla Labs project is rolling out a framework it calls Open Web Apps intended to improve the "stickiness" and operating system integration of web-based applications. The framework uses HTML5 features like local storage and existing standards like OpenID to create an installation workflow that more closely mimics the process traditionally used with desktop applications. Officially announced in October, the first bits of code have now started to appear on Github.

Based on the initial announcement in October and a foreshadowing post from May, the theory underlying Open Web Apps seems to be that, under the current paradigm, users have little more than their browser's bookmarking system to keep track of web applications that they frequently use. As a result, web applications (in spite of their growing popularity) remain segregated from the rest of the OS experience — they do not have a persistent presence, they all behave differently in regard to sign-on procedures, and so forth.

On top of that, the May post suggests that as more web developers build web applications disguised as mobile applications for consumer smartphones like Android or Apple's iPhone, they have grown to like the browsable, searchable, rate-able interface of the "mobile app store."

What it is

The Open Web Apps experiment attempts to solve both of these problems at once. On the web apps' side, it describes a JSON-based application "manifest" file that each application would serve up to describe basic metadata about itself — name, icon, creator, launch path, verification URL, and a set of basic capabilities. On the browser side, it lays out a standard for a web app "repository" (which could be implemented directly in browser code, as an extension, or via JavaScript) made up of a locally-stored collection of these manifests.

The repository has two APIs: one that web sites can use to offer the user an "install this web app" option, and one that the browser can use to show the user his or her currently installed web apps. There is a JavaScript-based demo running at myapps.mozillalabs.com that uses this user-facing API to create a dashboard, showing a launcher for each app in the repository as well as an uninstall option.

At apps.mozillalabs.com (be sure to note the absence of "my"), the project has several demonstration implementations of the server-side code that illustrate different possibilities. A simple app can "self-publish," meaning that it offers its own manifest file and "install me" button, but interested third parties could also build directories, cataloging manifests found in the wild and presenting them to site visitors in categories and with rankings. The is also a "store" demonstration that illustrates the optional verification scheme, which can be used to hand off login via OpenID or even to charge an online payment before returning a successful install.

At the moment, the feature set offered by the demos is a little thin. There are a half-dozen apps available, but the only one that uses the paid-verification architecture is a fake app called TaskTracker which does not actually charge any money ... but neither is it a real app. The dashboard demo has big, glossy icons, but it also does not offer any genuine functionality beyond the standard Firefox bookmarks the system is supposed to be replacing.

As a result, it is easy to imagine that the manifest system could be good for web app developers if the "app store" model does indeed take off (Mozilla makes it clear repeatedly in the documentation that it is not interested in running such a store or directory). The ranking and sorting could be beneficial, and the unified verification/payment method would simplify sign-up. But there is not as much to like from the end user's point of view. Launchers are just launchers, regardless of the size of the icon.

Extending the idea

Moving forward, however, there may still be some interesting offerings in future versions of the architecture. The capabilities field, for example, has yet to be fully explored, but exposing what an application can do in advance could help users search for the apps they want. The wiki lists a handful of proposed capabilities, including geolocation support, media capture, read/write file access, read access to contacts, and so on.

Apart from geolocation, few current web applications make use of capabilities that users might care to seek out or specifically avoid, but more are presumably on the way. Mozilla's own Rainbow project exposes desktop audio and video recording hardware to web applications, for example. The existing capabilities list comes from the W3C's Permissions working group. Elsewhere the documentation and blog posts mention 3-D rendering, which might also be a viable candidate.

A blog post from November introduces an enhancement to the original scheme that does offer clear benefits to the user: synchronization of repositories between multiple computers. Code for this feature is already available on Github, though interestingly enough, as a separate server. The functionality to synchronize client data between browsers is already present in Firefox Sync (formerly Weave), though, so app repository synchronization may make it there someday.

Some of the features described as possibilities for future client-side enhancement cannot be implemented in the JavaScript-based demo dashboard running at myapps.mozillalabs.com due to the need to access lower-level browser code. The project says that add-ons-based implementations will follow — presumably for Firefox first, and Firefox for Mobile, though possibly for other HTML5 browsers as well.

Another proposed enhancement to the architecture that has implications for app developers is support for cryptographically signed manifests, which would allow the browser to verify that a manifest has not been altered by an attacker. The manifest specification is still undergoing revision, including a discussion on how best to let an application delegate installation authority to a third-party — i.e., allowing an app manifest to specify which stores and directories are authorized to sell (or perhaps even list) it.

Further out, the project mentions several ideas for extending the repository and dashboard functionality to provide better OS integration, such as a notification framework, cross-application search methods, and possible support for cross-site user-experience schemes like OExchange, which could be used to link user content from several different apps into a single unified set of documents.

Security

Wherever cross-site functionality is concerned, security becomes an issue. The project has a dedicated page outlining all of the possible security and privacy concerns it knows of in the Open Web App architecture, and where possible, potential solutions.

Because the system is primarily used as a way to connect to third-party sites, most of the potential attack vectors are not direct exploits of the web app in question (such as stealing a user's GMail password); those would be security holes in the service itself. Rather, the page describes attacks against the repository, the installation and verification functions, and the dashboard.

Some aspects of the system do not introduce any new attack vectors. Tampering with the repository itself or any installed app's manifest amounts to an attack on the browser's implementation of HTML5 local storage — though it should also be noted that the signed manifests proposal mentioned earlier is a safeguard against this. Likewise, intercepting application launch via a man-in-the-middle attack amounts to performing the same attack against the existing site's OpenID login implementation.

On the other hand, it would be possible to build a man-in-the-middle dashboard that intercepted installation or launch requests and delivered tainted goods to the client. This is only possible with a JavaScript-based, hosted dashboard, as opposed to a native browser dashboard implementation. The demo dashboard at myapps.mozillalabs.com, of course, is one such hosted dashboard. The project page suggests implementing dashboards only over HTTPS to provide a layer of protection against this attack. It also notes, however, that if browsers begin to implement the dashboard in local code, the attack vector disappears.

Finally, it would be possible to build a malicious "app store" that, through iframe defacement, tricks the user into installing a different application than the one they intend. The page notes that Firefox 4's Content Security Policy can protect against this vulnerability.

Appzilla returns

Strangely absent from the Open Web App project documentation is how the scheme could fit in with Mozilla's other web application / desktop integration product, Mozilla Prism. Prism is the renamed XULRunner browser, which can be used to launch sites in separate processes that behave more like a native application on a desktop system — living in the system tray, running at startup, and so forth. Some of the proposed extensions to the Open Web App architecture sound like they would be a good fit for Prism, but there is no indication that native repository functionality is headed in Prism's direction.

The major challenge facing Open Web App's growth, however, is not lack of browser support, but the effort that would be required to convince web developers to create browser-agnostic sites. Written all over the Open Web App documentation (starting with the name) is the notion that compliant apps should be based on free and open standards: HTML5, CSS, and JavaScript. But just saying that doesn't make it happen. Nothing in the system prevents developers from building IE-only or iPhone-only sites and slapping a compliant manifest file up on the server — it will just fail to work properly once installed in a different browser.

Still, that is a hurdle that can only be overcome with evangelism, not with specifications. The development community is at least aware of the difference. On Tuesday, Google unveiled a similarly-themed "app store" designed to function solely with its Chrome browser. During the press conference, a Twitter message from one reader was re-tweeted multiple times, asking "So why again are we building web apps 'for Chrome' instead of for the Web?" If Mozilla is correct about the growing desire of web application developers to have an "app store" model in which to hawk their wares to the public, it can only find that question encouraging — but it may still face a long slog uphill to make truly cross-browser applications the standard.

Comments (8 posted)

The 2010 Linux and free software timeline - Q2

Here is LWN's thirteenth annual timeline of significant events in the Linux and free software world for the year.

In what is becoming a fairly standard pattern, 2010 brought various patent lawsuits, company acquisitions, new initiatives, and new projects. It also brought new releases of the software that we use on a daily basis. There were licensing squabbles and development direction disagreements—all things that we have come to expect from the Linux and free software world over a year's time. Also as expected, though, were the improvements in the kernel, applications, distributions, and so on that make up that world. Linux and free software just keep chugging along, and we are very happy to be able to keep on reporting about it.

Like last year, we will be breaking this up into quarters, and this is our report on April-June 2010. Over the next month or so, we will be putting out timelines of the other quarters of the year.

• January-March 2010

---

This is version 0.8 of the 2010 timeline. There are almost certainly some errors or omissions; if you find any, please send them to [email protected].

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those with a nostalgic bent, our timeline index page has links to the previous twelve timelines and some other retrospective articles going all the way back to 1998.

April

Subversion puts out a proposed vision and roadmap for the version control system (VCS), which recognizes that it has "no future" as a distributed VCS (DVCS) (proposal).

The Embedded Linux Conference is held in San Francisco (LWN coverage: Android and the community, Embedded Linux status, and Using LTTng).

The apache.org infrastructure is attacked in a direct, targeted fashion using cross-site scripting and password brute-forcing (report).

Perl 5.12.0 is released and the project moves to a time-based yearly release schedule (announcement).

Java inventor James Gosling leaves Oracle shortly after Oracle's acquisition of Sun (blog post).

The Linux Foundation Collaboration Summit is held in San Francisco (LWN coverage: Some notes and MeeGo)

Stefano Zacchiroli is elected as Debian Project Leader, succeeding Steve McIntyre (results).

GCC 4.5.0 is released (LWN coverage).

The Qubes security-oriented, virtualization-based open source OS is announced; it is built atop Xen and Linux (announcement, LWN coverage).

Ubuntu 10.04 LTS ("Lucid Lynx") is released (announcement).

May

Lennart Poettering announces "systemd" as a replacement for init, and it has gained traction in both Fedora and openSUSE though it has yet to be released in either distribution (announcement).

Red Hat and Novell fend off patent suit by IP Innovation, which, as its name might imply, is a patent troll. The suit was over some very broad patents that ended up being invalidated (LWN coverage of the suit, Groklaw coverage of the outcome).

Free Software Foundation Europe (FSFE) founder Georg Greve receives the German Cross of Merit (announcement).

The Ryzom multiplayer online role-playing game (MMORPG) code is released as free software after several years of almost being freed (announcement, 2008 LWN coverage).

Mandriva looks for a buyer (news article (in French), Google translation).

Linux 2.6.34 is released (announcement, KernelNewbies summary).

Linux Mint 9 is released (announcement).

Google launches the WebM media format for the web, which includes the VP8 video codec acquired when it bought On2, the Vorbis audio codec, and the Matroska media container format (announcement, LWN coverage).

Fedora 13 is released (announcement).

The Diaspora project forms to develop a privacy-friendly alternative to Facebook and other social networking sites. Its request for $10,000 in funding results in more than 20x as much in donations (LWN coverage).

The Libre Graphics meeting is held in Brussels (LWN coverage).

MeeGo 1.0 is released (announcement, LWN review).

The Free Software Foundation asks Apple's App Store to comply with the GPL on an iPhone port of GNU Go, which leads to Apple removing the app from the store (FSF blog post and update, LWN coverage).

June

The Linaro consortium is announced, which seeks to simplify the ARM Linux landscape (announcement, LWN article).

Rockbox 3.6 is released, with many new features for the free music player firmware (announcement, LWN review).

LinuxTag is held in Berlin, Germany (LWN coverage: Mark Shuttleworth, Thomas Gleixner, and Stefano Zacchiroli)

Another, seemingly final, setback for SCO in SCO v. Novell (Groklaw report).

SouthEast LinuxFest (SELF) is held in Spartanburg, South Carolina (USA) (LWN coverage).

GNOME finalizes speaker guidelines, which are meant to reduce friction and present a more welcoming face to newcomers (guidelines, LWN coverage).

The US Supreme Court rules in the Bilski case, which affirms the lower court's ruling against the Bilski patent, but does not make hoped-for changes to the patentability of software (LWN article).

FFmpeg 0.6 is released with support for WebM and better HTML5 compatibility (announcement).

The Electronic Frontier Foundation (EFF) launches HTTPS Everywhere, which is a Firefox plugin to promote better web security (LWN article).

Jared Smith becomes the new Fedora Project Leader, succeeding Paul Frields (announcement).

Comments (2 posted)