LWN.net Weekly Edition for May 16, 2013

XBMC on Android != XBMC for Android

The XBMC media center front-end runs on a wide variety of platforms—most recently Android, as we saw in January. But as the project discovered recently, not everything advertised to the public as "XBMC" is its work. Those who follow the project closely are unlikely to be confused, but the wider marketplace is another matter. Moreover, XBMC developers have had to spend their time and energy on the clarifications, which is quite understandably a source of frustration.

At issue is a spin-off of XBMC which calls itself "XBMC for Android." Shortly after the first releases of the official port of XBMC to the Android platform, the spin-off project announced its own release, which it tagged "the first end user friendly release of XBMC for Android" in a blog post that makes no mention of the fact that it is not the work of the official XBMC project. That blog announcement was picked up by a number of online news sources, including the popular consumer electronics blog Engadget. XBMC contacted all of the sites running the story, and all of them corrected their copy to note that XBMC for Android is not affiliated with the official XBMC project.

Then in May, the cycle repeated itself. The XBMC project released its latest update, version 12.2, on May 3, and on May 4 the XBMC for Android project announced its release, which was again picked up by Engadget, who again had to alter the story after an email from the genuine XBMC project. That prompted XBMC's Nate Thomas to post a story on the official XBMC blog titled "This Site is the Only Official Source of XBMC Software." Initially Thomas was upset that Engadget had not corrected the second story, although it did so later (which Thomas noted in the post).

But the bigger issue remains that a fork of the official project exists which has chosen to brand itself with a name confusingly similar to that of the upstream project. A commercial entity with a registered trademark to protect might well pursue legal action in such a situation, but the best approach for a GPL-licensed software project is considerably less clear. XBMC does not have sales to protect, of course, and in fact the project is expressly open to working with commercial XBMC derivatives (at the moment, Plex and Voddler; formerly Boxee as well). But it does undertake the costs of supporting users, a task which is greatly complicated when the user had unknowingly installed a modified version of the software.

What's in a (my) name?

How a project's name can be used by other parties is a tricky affair, and it is not as well-understood in free software circles as is copyright. As Karen Sandler explained in her SCALE 8x talk about trademarks, a project does not have to register a trademark (at least in the United States) in order to protect it. Rather, a trademark carries weight based on how well it establishes a brand in the minds of actual users. XBMC does not advertise a trademark on the name XBMC, nor does it have an explicit trademark-usage policy, but if it did feel that its brand was being exploited, it would still be able to make that case before a court. And it might have the structure in place to do so—which not every project would. In January 2009, the project formed the XBMC Foundation to handle donations and sponsorships, and it is represented by the Software Freedom Law Center.

However, as Sandler also discussed in her talk, there is such a thing as the acceptable "nominative use" of someone else's trademark: it is a protected use of another party's trademark to refer factually to the trademarked product. That is why Ford cannot stop Chevrolet from mentioning it in its own TV commercials. So advertising "Foo for Android" would probably not be considered a violation of the Android trademark by a court, if it is clear that the "for Android" part was a factual reference to the platform and not part of the product's name.

That particular parsing exercise is not quite as clear for XBMC for Android, however. The spin-off project does include a disclaimer on its About page, reading "XBMCANDROID.COM is not connected to or in any other way affiliated with XBMC, Team XBMC, or the XBMC Foundation." That is a plus; seemingly an addition made to the page since January. But it does not go very far; the same page states:

That wording suggests some sort of collaborative relationship between the two projects. Perhaps more to the point, the announcements picked up by Engadget and other online news sources are a lot less clear about a distinction between XBMC for Android and the official XBMC release; for example they go back and forth between referring to the download as "XBMC for Android" and "XBMC." A comment on the official XBMC blog post claiming to be from an XBMC for Android team member says a disclaimer was also included in the press release sent to Engadget, although it does not appear in the blog announcement.

A little less ambiguation

Assuming there is no intent to confuse, however, the spin-off project could still stand to do a lot more clarification. The links and other site content are as inconsistent about the name of the software as were the announcements. The site sports the official XBMC logo at the top of the page (and the Android logo) as well. But ultimately the most confusing part of the spin-off project is that fact that it has not selected a unique name for itself. It clearly could have, just as its team members clearly could have chosen to work on their own branch within the official XBMC project.

Historically, name collisions are a pretty rare event in open source software; the major ones can probably be counted on one hand. But the reason is not that open source projects fiercely protect trademarks (much less unregistered ones). Instead, it is the simple practical matter of minimizing confusion. Name collisions make packaging and distribution harder, and when they occur the bigger and better-known project generally has such an advantage that the fork is eventually forced by circumstance to rename itself.

For the time being, XBMC seems content to deal with this particular situation as a public relations matter. As the larger, more well-established project, the odds are good that events will resolve in its favor. But the issue will not disappear entirely; even within the comments on the XBMC blog post, there is a message from yet another XBMC fork, which calls itself "XBMC Android TV." Sadly, it probably would not hurt to double check the next announcement you see about XBMC—if it does not originate directly from xbmc.org.

Comments (1 posted)

DRM in HTML5 published in draft form

Despite the protests of multiple critics, the World Wide Web Consortium's (W3C) HTML working group has published the first working draft of the Encrypted Media Extensions (EME) proposal. The EME proposal is commonly referred to as "DRM for HTML" or words to that effect, although that is not a strictly accurate description. Reading through the proposal, however, may only cloud the real issues at stake. EME merely defines an API for browsers to pass messages back and forth between a content server and DRM module. But those DRM modules are little different from the closed plugins used to deliver DRM today—except that the EME proposal would bear the W3C seal of approval. Of course, the proposal must first make it all the way through the W3C's labyrinthine standardization process, and whether W3C endorsement makes any real difference for users depends on who you ask.

The EME proposal was released on May 10. Its exact status it a bit complicated; it is labeled a "public working draft," which designates the lowest level of maturity in the W3C development process. Officially, a working draft is "a signal to the community to begin reviewing the document;" hypothetically, after several working drafts, a "last call announcement" is published, followed by "candidate recommendation," "proposed recommendation," and (finally) "recommendation"—with reviews, revisions, and red tape separating each stage. Still, the publication of this initial draft does signal that EME is moving forward, in spite of objections to the core concept from advocates of software freedom, privacy, and related matters.

The EME draft has three editors: Google's David Dorwin, Microsoft's Adrian Bateman, and Netflix's Mark Watson. Also noteworthy is that although the proposal is officially a product of the HTML working group, that means only that it impacts HTML elements; the EME authors operate as an effort distinct from the HTML working group's larger activities.

An uncomfortably close look

The EME proposal defines two abstract components: the Content Decryption Module (CDM) and the Key System. A CDM is a browser component (either built-in or installed as an extension) responsible for authenticating a user session with a remote content server and for decrypting the media served up by the server. A Key System is a complete implementation of an access-control framework in all of its constituent parts: the remote media streaming server, its standards for session and key management, and whatever else the provider chooses to implement.

Both are essentially black boxes as far as the browser is concerned; the CDM can decrypt encrypted media frames and hand them right back to the browser's playback stack, or it can render them directly to hardware—the EME proposal does not address this functionality. Similarly, a Key System is identified by a reverse domain name (e.g., com.example.payperviewservice), and EME outlines several interfaces for session management messages, but the key format and encryption method are left up to each implementer, as are session IDs and other initialization data.

In practice, a playback scenario would involve a JavaScript application that provides the local user interface and connects to the Key System to fetch content for an HTML mediaElement (that is, a <video> or <audio> element on the page; EME does not currently affect any other HTML elements), then passes that content to the CDM, which both authenticates the user and decrypts the content. It is the hooks for these JavaScript applications that make up the meat of the EME proposal. There is a new keys attribute for mediaElements, setMediaKeys and createSession methods which the application uses to get key and session information from the CDM, and a message event which the application uses to relay messages from the CDM to the Key System.

For instance, see the proposal's "other CDM" example, which depicts a mediaElement:

    <video src="foo.webm" autoplay onneedkey="handleKeyNeeded(event)">
    </video>

In the example, the video element triggers the EME script with the new onneedkey event. The script first initializes the video.keys attribute with the hard-coded "com.example.somesystem.1_0" Key System, then initializes the keySession, which tells the CDM to generate a key request message. The script then fires the request message off via XMLHttpRequest(); if the Key System responds with a key, the keySession is updated, and playback is started or resumed. The encrypted audio or video frames from the server are handed to the CDM, which decrypts them with the key and renders them as needed. There are several scenarios not addressed in this example, such as the availability of multiple CDMs in the browser (where the application might need to do some work to select the correct CDM).

From outside, this initialization and handshake process is pretty simple. One will note that the keySession is initialized with initData, the contents of which is not specified by the EME proposal—the CDM and the Key System determine what this data is (and how it authenticates the session). Likewise, the format of the key and the decryption of the media frames is pushed entirely out to the CDM and the remote Key System server.

What is left to the browser is a generic session initialization system and messaging framework, tied into <video> or <audio> elements with some new attributes and methods. As such, it does not directly mandate a DRM implementation. Actual DRM schemes would be implemented in CDMs, which are assumed to be resistant to key extraction, modification, and other methods that could be used to access mediaElement content outside of the parameters the CDM enforces. Similarly, the API between a CDM and the browser is not defined.

Feedback

So far, of course, there are no CDMs in the wild. On the other hand, there are "non-normative" (i.e., informational) sections in the proposal that discuss DRM details with more specificity. Section 7.1 defines an initialization data format and the encryption scheme for WebM content, and section 7.2 does the same for the ISO Base media File Format (ISOBMFF, the generic underpinnings of .MP4). Both use AES-128 in "counter" mode (CTR) for encryption; the WebM initialization data is a key ID, while the ISOBMFF initialization data is a more complicated structure that can hold separate keys for separate tracks. Section 6 also defines a trivial Key System named org.w3.clearkey (the only Key System defined in the document) which is mandatory for conforming browsers to implement. However, this clear key scheme has little practical value: it sends a decryption key in the clear as a JSON element.

But if the EME proposal does not actually enshrine a DRM scheme into the HTML specification, one might reasonably ask what all the fuss is about. After all, the Free Software Foundation denounced the publication, as did the Electronic Frontier Foundation.

The answer is two-fold. First, at a technical level, it is true that EME does not itself include a (non-trivial) DRM scheme. But EME's functionality hinges entirely on the presence of CDMs in the browser, which users by definition will have no control over. To software freedom advocates, that means handing control of a user's machine to proprietary code—which could very well contain anything from unintentional security flaws to secret user tracking frameworks. Whether built in to the browser or provided as separate downloads, only binary CDMs will be trusted: if users can compile their own CDM, they can alter it to include workarounds (e.g., to save content or encryption keys).

The same is true today, of course, which is why content services deploy protected content via proprietary plugins like Flash and Silverlight—in that sense, reliance on binary CDMs instead of binary plugins is at best a lateral move. Google and Microsoft very well could include binary CDMs in their browsers, but open source browsers like Firefox cannot, so they would be relying on third-party CDMs. And as Mozilla's Henri Sivonen observed (forwarded by Gervase Markham), support for binary plugins for Linux and other minority desktop operating systems is not good, and binary CDMs are certainly unlikely to be better. In fact, Sivonen doubts open source browsers will be well-served even on other OSes:

The other objection to the EME proposal is that it fundamentally goes against the stated mission of the W3C, both by advocating the distribution of proprietary CDMs in browsers and by endorsing restricted content itself. The EFF criticism of EME hits on this point, noting that the EME scheme is a mechanism for sites to require proprietary software or hardware in order to render web content:

The Free Culture Foundation argued that the proposal goes against the W3C mission statement, which is to make the benefits of the Web "available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability."

In addition, HTML working group member Manu Sporny argues that the proposal runs afoul of other W3C ideals, because it is advertised as a solution to prevent the piracy of copyrighted content, which he claims it simply does not do. Sporny also contends that in order for EME to be effective, sites will need to undertake expensive measures like re-encrypting each title for every user, which is a poor value proposition.

The EME proposal does have a few supporters outside of the drafters of the document itself, though. Ars Technica's Peter Bright declared it a "victory" for the open web, on the grounds that it keeps HTML relevant to the critical big-media producers, who would otherwise switch to non-Web delivery mechanisms—such as the DRM-capable media services already provided by iOS and Android. It is certainly true that content services looking to make money from audio and video—particularly through rental and subscription services—are not likely to embrace unencrypted mediaElements in the browser, but by shuttling it directly from the server to a binary-only CDM, there is not a whole lot of "open web" involved in the transaction; a fact Bright seems to gloss over.

Naturally, any company interested in deploying DRM-restricted multimedia as a product is going to do so whether it gets a W3C stamp of approval or not. If affecting that outcome is the goal of a protest against the EME proposal it will likely have no impact. But there is still an argument to be made that the W3C should not play a part in the process. It might seem like an uphill battle; W3C Director Tim Berners-Lee approved the EME proposal publication and has stated his position in favor of allowing DRM.

In addition, HTML working group co-chair Paul Cotton has been very vocal about shutting down criticism of EME on the mailing list, telling everyone with a complaint to take it to the Restricted Media Community Group (in which Netflix's Watson is the only EME editor who participates). But vocal opposition to W3C behavior has been effective in the past. Sivonen noted that the W3C patent policy was revised due to opposition from free software advocates. The draft policy endorsed "reasonable and non-discriminatory" (RAND) patent licenses, but feedback from Mozilla and others eventually shifted the policy to a fully royalty-free model. Whether history repeats itself, only time will tell.

Comments (14 posted)

A look at the PyPy 2.0 release

It's hard to say why, but May appears to be the month where we look in on PyPy. Three years ago, we had a May 2010 introduction to PyPy, followed by an experiment using it in May 2011. This year, the PyPy 2.0 release was made on May 9—that, coupled with our evident tradition, makes for a good reason to look in on this Python interpreter written in Python.

One might ask: "Why write a Python interpreter in Python?" The possibly surprising answer is: "performance". It's not quite as simple as that, of course, as there are some additional pieces to the puzzle. To start with, PyPy is written in a subset of Python, called RPython, which is oriented toward making a Python dialect that is less dynamic and acts a bit more like C. PyPy also includes a just-in-time (JIT) compiler that flat out beats "normal" Python (called CPython) on a variety of benchmarks.

PyPy has been making steady progress for over ten years now, and has reached a point where it can be used in place of CPython in lots of places. For a long time, compatibility with the standard library and other Python libraries and frameworks was lacking, but that situation has improved substantially over the years. Major frameworks like Django and Twisted already work with PyPy. 2.0 adds support for Stackless Python with greenlets, which provide micro-threading for Python. Those two pieces should allow asynchronous programs using gevent and eventlet to work as well (though gevent requires some PyPy-specific changes).

In order to support more Python modules that call out to C (typically for performance reasons), PyPy now includes CFFI 0.6, which is a foreign function interface for calling C code from Python. Unlike other methods for calling C functions, CFFI works well for both CPython and PyPy, while also providing a "reasonable path" for IronPython (Python on .NET) or Jython (Python on the Java virtual machine).

Trying it out

Getting PyPy 2.0 is a bit tricky, at least for now. Those who are on Ubuntu 10.04 or 12.04 can pick up binaries from the download page (as can Mac OS X and Windows users). While many distributions carry PyPy in their repositories, 2.0 has not arrived yet. There are "statically linked" PyPy binaries, but the 64-bit version (at least) doesn't quite live up to the name—it requires a dozen or so shared libraries, including older versions of libssl, libcrypto, and libbz2 than those available for Fedora 18.

Normally, given constraints like that, building from source is the right approach, but the project has some fairly scary warnings about doing so. According to the docs, building on a 64-bit machine with 4G or less of RAM will "just swap forever", which didn't sound all that enticing. But there is a workaround that doesn't use CPython and instead requires PyPy using some magic incantations (an environment variable and command-line flag) to limit the memory usage—but that means making the static PyPy binary work. A little symbolic linking (for libbz2) and some library building (openssl-1.0.0j) resulted in a functioning PyPy. There is no real reason not to use that, but I was a little leery of it and curious to continue with the build process.

Running the PyPy build is a rather eye-opening experience. Beyond the voluminous output—including colored-ASCII Mandelbrot set rendering, lots of status, and some warnings that are seemingly not serious—it took more than 2 hours (8384.6 seconds according to the detailed timing information spit out at end of the build process) on my not horribly underpowered desktop (2.33 GHz Core 2 Duo). The Linux kernel only takes six minutes or so on that system.

Calculating the Mandelbrot set while translating is not the only whimsical touch that comes with PyPy. Starting it up leads to a fortune-like quote, though one with a PyPythonic orientation:

    $ pypy
    Python 2.7.3 (b9c3566aa0170aaa736db0491d542c309ec7a5dc, May 11 2013, 17:54:41)
    [PyPy 2.0.0 with GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    And now for something completely different: ``PyPy is a tool to keep otherwise
    dangerous minds safely occupied.''
    >>>> 

As a quick test of PyPy, I ran an amusingly shaped Mandelbrot program in both CPython and PyPy. As expected, the PyPy version ran significantly faster (just over 3 minutes, compared to 8+ minutes for CPython 2.7.3). In addition, the bitmaps produced were identical.

PyPy comes with its own set of standard library modules, but additional modules can be picked up from an existing CPython site-packages directory (via the PYTHONPATH environment variable). Trying out a few of those (BeautifulSoup 4 for example) showed no obvious problems, though a PyPy bug report shows problems using the lxml parser, along with some other, more subtle problems. The compatibility page gives an overview of the compatibility picture, while the compatibility wiki has more information on a per-package basis. A scan of the wiki shows there's lots more work to do, but it also shows a pretty wide range of code compatible with PyPy.

ARM and other projects

One of the more interesting developments in the PyPy world is ARM support, for which a 2.0 alpha has been released. It supports both ARMv6 (e.g., Raspberry Pi) and v7 (e.g., Beagleboard, Chromebook) and the benchmark results look good, especially given that the ARM code "is not nearly as polished as our x86 assembler". The Raspberry Pi Foundation helped get PyPy onto ARM with "a small amount of funding".

The PyPy project is running several concurrent fundraising efforts, three for specific sub-projects, and one for overall project funding. The transactional memory/automatic mutual exclusion sub-project is an effort to use software transactional memory to allow Python programs to use multiple cores more effectively. It would remove the global interpreter lock (GIL) for PyPy for better concurrency. PyPy hackers Armin Rigo and Maciej Fijałkowski gave a presentation at PyCon 2013 on this effort.

Another ongoing sub-project is an effort to add Python 3 support to PyPy. That would allow input programs in Python 3, but would not change the PyPy implementation language (RPython based on Python 2.x). A status report back in March shows good progress. On x86-32 Linux, the CPython regression test suite "now passes 289 out of approximately 354 modules (with 39 skips)".

The third sub-project is to make NumPy work with PyPy. NumPy is an extension for doing math with matrices and multi-dimensional arrays. Much of that work is done in C code, so PyPy's JIT would need to use the vector instructions on modern CPUs. A brief status update from May 11 shows some progress, as does the 2.0 release announcement (though the temporary loss of lazy expression evaluation may not exactly be considered progress).

Overall, the PyPy project seems to be cruising along. While none of the fundraising efforts have hit their targets, some fairly significant money has been raised. Beyond that, some major technical progress has been made. The sub-projects, software transactional memory in particular, are also providing interesting new dimensions for the project. We are getting closer to the day when most Python code is runnable with PyPy, though we still aren't there yet.

Comments (10 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Linux web servers pushing malware; New vulnerabilities in gpsd, httpd, java, kernel, ...
• Kernel: copy_range(); 3.10 merge window conclusion; Smarter shrinkers; User-space page fault handling.
• Distributions: Always-releasable Debian; Fedora, Ubuntu, ...
• Development: PostgreSQL 9.3 beta; Packetfence 4.0; Go 1.1; Tahoe-LAFS 1.10; ...
• Announcements: Linux Foundation New Members; no software patents in New Zealand, events.