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
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
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:
It has been our interest to attempt to independently port XBMC to
Android for quite some time, but thankfully the XBMC Foundation
obviously beat us to it, and since we have been working to assist in
improving their coding and furthering the development of this very
exciting software. Since the beginning, we’ve pretty much been
considered the main “go-to” for XBMC for Android type support and
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)
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
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
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
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.
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
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)">
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
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
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.
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
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
(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:
However, EME has the potential of becoming worse than status quo for
Free Software browsers on proprietary operating systems if the licensing
and availability of Content Decryption Modules turns out to be worse
than the licensing and availability for Silverlight and Flash Player.
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:
Perversely, this is exactly the reverse of the reason that the World
Wide Web Consortium exists in the first place. W3C is there to create
comprehensible, publicly-implementable standards that will guarantee
interoperability, not to facilitate an explosion of new
mutually-incompatible software and of sites and services that can
only be accessed by particular devices or applications.
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
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)
It's hard to say why, but May appears to be the month where we look in on PyPy.
years ago, we had a May 2010 introduction to
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
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
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
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
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
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.
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:
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.''
From the command line, it acts pretty much exactly like Python
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.