German lawyer Till Jaeger came to the Embedded Linux Conference Europe to
update attendees on the AVM vs. Cybits
case that is currently underway in Germany. The case has some
potentially serious implications for users of GPL-licensed software,
particularly in embedded Linux contexts, so Jaeger (and his client Harald
Welte) felt it was important to
publicize the details of the case. So important, in fact, that he and
Welte are forgoing the usual practice of keeping all of the
privileged information (between a lawyer and client) private.
Jaeger has also represented Welte in GPL enforcement cases based on the
work the latter has done with gpl-violations.org. It is
"clear I'm not neutral in this case", Jaeger said. The case
is important to kernel developers, device makers, and to people using GPL
said, which is why they are publicizing it.
AVM is a company that makes DSL routers called the "FRITZ!Box"—because
anything named "Fritz" sells well in Germany, he
said—which are based on Linux. These routers have 68% market share
in Germany. Cybits offers a product to do internet filtering on the
FRITZ!Box with its "Surf-Sitter" software. Surf-Sitter is installed on the
router by the
user downloading firmware from AVM, running a program that modifies the
Linux kernel in the firmware and adding a user-space program to it, then
installing the modified firmware onto the router.
AVM did not like that,
Jaeger said, so it asked a court to prevent Cybits from distributing
software that allowed a customer to change any software on the
router. There are some side issues, like the changed firmware not blinking
the lights of the device correctly when online, but the core issue is that
allowed to change any software on the router, according to AVM's
arguments. That is a "major attack on users' freedoms under the
GPL", Jaeger said. It should not be possible to stop sales of
software that changes the firmware on a device like the FRITZ!Box, he said.
In January 2010, a preliminary injunction was issued in a Berlin court that
prevented Cybits from selling its software. That is when Welte got
involved. In German civil law, it is possible to intervene in a case if
you are concerned that your rights are not being upheld. Because Welte
licensed his kernel code to both AVM and Cybits (i.e. under the GPL), he
was able to intervene with Jaeger as his lawyer. When Cybits appealed the
preliminary injunction, the court of appeals overruled most of the original
decision, saying that Cybits could continue distributing its software as
long as it doesn't cause technical problems with the router (such as the
blinking lights problem).
At the same time, though, AVM filed another case in the Berlin regional
court to, once again, stop Cybits from shipping its software. AVM won that
case by default, because Cybits did not respond to the complaint in a
timely manner. According to Jaeger, the company moved and the case fell
through the cracks. Cybits then appealed the decision, which was
considered at an oral hearing in June.
In that hearing, the details were discussed quite deeply, Jaeger said. The
legal question had gotten more complicated because AVM had changed its
claims, though the additional claims are not the interesting ones, he
said. The main claim of interest is that you can't change any of the
software installed on the router, including the GPL-covered software.
Jaeger said that he asked AVM if it really meant to make that claim
against the GPL software, and AVM affirmed that. He noted that Welte would
probably not have intervened without the GPL claim. So far, there has been
no decision, and he had hoped there would be one before the talk, but one
is due sometime around November 1.
Jaeger's opinion is that if AVM prevails in its case, it will itself lose the
right to distribute the kernel as it does on the FRITZ!Box. Because it
will be imposing further restrictions than those embodied in the GPL, its
license to distribute the GPL-covered parts will be automatically
terminated. Because the GPL (version 2 in this case) clearly states that
the source code includes the scripts used to control compilation and
installation, it is clear that the intent is to enable the user to
reinstall modified versions of the software, he said.
One member of the audience wondered whether the GPLv2 was sufficient to
require AVM to allow its customers to change the firmware, as that was one
of the things that the GPLv3 tried to address. Jaeger said that his
interpretation of the GPLv2 was that it was sufficient to the task at hand,
at least under German law. Another asked whether the Cybits software was
free or proprietary, and he noted that it was the latter, but that there
wasn't a GPL question about Surf-Sitter itself because it all ran in user space.
AVM has made several arguments about why the injunction should be upheld:
trademark and copyright infringement, as well as unfair competition. One
of the main questions that was discussed in the oral hearing in June
seems silly to him: is the router a computer? AVM argued that it is not
and that they are the only ones who should be allowed to change the
firmware on the device. It
is not a good argument in Jaeger's opinion, especially because the device
is owned by the customer, so it is their property.
AVM claims to get more support calls from Surf-Sitter users than it does
from users of unmodified FRITZ!Box routers. That is the basis of the unfair
competition claim. It is an argument that the free software community
would not like to hear Microsoft or HP make about installing free software
on their systems, he said. If there were truly a support issue, AVM could
refuse to support modified routers, so there is clearly more to it than
that, he said.
The trademark claims are not really an issue in Jaeger's view, but the
copyright infringement claims are more interesting. AVM argued that the
firmware is a copyrighted work that cannot be changed without its
permission, but Jaeger and Welte argued that the firmware is a derivative work
of the GPL-covered kernel. AVM then changed its argument to say that the
firmware was a collective work, but Jaeger believes that the GPL is
intended to handle both derivative and collective works.
AVM is being contradictory in its behavior, he said, by claiming to be
licensees of the kernel by releasing the source code as is required by the
GPL, but then asserting claims that others cannot change the code. Those
assertions constitute a GPL violation in his opinion, so that AVM will lose
its rights to distribute the kernel if it prevails.
When the court releases its decision, which could be any time now, it may
render a judgement or reopen the case because of the additional claims made
by AVM. If there is a final decision, either side can appeal, which is
a likely outcome, he said. There may be an additional case eventually filed against
AVM for violating the GPL. That could come from Welte or others, depending
on how things play out, he said.
There were various audience questions about TiVo's technical measures to
stop owners from changing the firmware (i.e. Tivoization) in relationship to this case. There
are differences, Jaeger said, as AVM is trying to legally bar customers
from changing the firmware, rather than using a technical measure (like
cryptographically signing the binary as TiVo does). In his opinion, even
the technical measure used by TiVo is a violation of the GPLv2, though he
recognizes that there is a different interpretation in the
US—something that led to some of the wording in the GPLv3. In
Germany, Jaeger said, the court can dig into the intent of the license, in
addition to its words.
Jaeger believes that what AVM really wants is an "Apple-like
system" where it controls all of the software that runs on the
device. But that runs afoul of its GPL obligations. AVM didn't write all
of the software that runs on the FRITZ!Box, so it needs to comply with the
licenses of the software it includes. That means allowing customers to
modify the GPL-covered software contained inside, at least in Jaeger's
view. We should know more about the case soon, but, whatever the outcome
from the oral hearing, it seems likely that it will drag on for some time
[ I'd like to thank the Linux Foundation for assisting with travel
expenses to attend the conferences in Prague. ]
Comments (29 posted)
Geoffroy van Cutsem from Intel presented
work on the Unified Multimedia
Service (UMMS) on the first day of LinuxCon Europe. UMMS is a
high-level abstraction layer for audio/video operations, which is meant to provide an API for application developers that is independent of both the playback engine used on the back end and of the output target. Van Cutsem described it as analogous to CUPS for printing or SANE for scanners.
UMMS was initially developed for the MeeGo Smart TV user experience (UX) and, although it will be developed from this point forward as a framework for the Tizen successor to MeeGo Smart TV, it could also be useful on desktop systems and other Linux environments. At present, the design covers media playback and basic media capture features, although more advanced features needed for the smart TV platform are on the roadmap.
As most end-users know, there is no shortage of video playback engines available for Linux: GStreamer, FFmpeg, Xine, MPlayer, and so on. However, they provide no uniform API: front-end applications must be specifically written to tie in to each back-end. Most application projects choose just one, and those that choose several undertake a major duplication in effort. For any particular engine there also need to be language-specific bindings and, in most cases, the application is still responsible for low-level details like constructing its own GStreamer pipelines.
Video capture is similarly fragmented. It requires the application to manage the capture hardware, and in the case of TV tuners, to know the format (DVB, ATSC, QAM, IPTV, etc) and manage the frequency tables and other tuning details. Commercial smart TV and set-top box OEMs also face a challenge when implementing video-on-demand (VOD) applications and playback engines for protected content streams like Blu-Ray in their products, because content-production companies demand isolating that code from GPL and LGPL modules.
UMMS is an attempt to solve all of these problems at once by
constructing a consistent playback and capture API. It provides a D-Bus
service, so it is both language-independent and capable of providing
license isolation. There are playback, recording, and time-shifting
functions, as well as methods to query media properties. Applications can
access media by URI, without regard to whether the source is local or
remote, whether it uses a protected VOD playback engine or GPLed media framework, or the output format used — including the availability of hardware acceleration for the file in question. The latter capability is intended to future-proof UMMS so that it can provide applications with transparent access to new advances in video processing; Van Cutsem cited processing video as OpenGL textures as one example.
The project is currently hosted
in the MeeGo build service, but Van Cutsem said it will be migrating to
Gitorious soon. Unfortunately online resources for the work are still on
the scarce side at the moment — there is a draft
version of the requirements document on the MeeGo wiki, but the best
documentation of the API itself is contained inside the spec/
directory of the source repository.
The API provides a way to create and manipulate "MediaPlayer"
objects. Two types are available, "attended" or "unattended"
For attended objects, the application must remain active during execution
(as in most video playback scenarios), and can manipulate the video. With
unattended objects, the application registers an event with UMMS, then
shuts down. The canonical unattended example is scheduling a DVR
recording: the application provides a "time to execute" to the UMMS service, along with an input URI and a destination file name.
The code from the MeeGo build service stands at version 0.0.1, and implements sample applications of each type. There is a media player using GStreamer as the back-end framework, and a video recorder that can schedule recordings from a DVB video source. UMMS is licensed under the LGPL v2.1.
Each MediaPlayer object supports methods to report the codec used, the
height and width, the playback rate, whether the content is seekable,
allowed (by the copyright holder) to be displayed at full-screen
resolution, and the presence and location of all audio, video, and subtitle
tracks (although much of the focus deals with video content, UMMS supports
audio-only media just as easily). Applications can use UMMS to query or
set the playback position, adjust volume or playback speed, and do basic
UMMS defines a "target" as the output destination of any MediaPlayer stream. For PC usage, this would be either an X window or an OpenGL (or other hardware acceleration) pipeline. For direct connection to TVs, there are other considerations that mandate handling HDMI and other output signals differently — non-square pixels, overscan, and so on. But a target could also be a UI element inside of another application, for example a <video> object on a web page, in the case of a browser.
Although UMMS is designed to abstract away many of the details of a
media file from the application, it may not always be possible. In a discussion
on the meego-dev list in March, developer Dominig ar Foll explained that
some content sources will still demand that the application inspect codec
settings, bit rates, buffer depths, and other specifics — in order to
manage hardware resources on the device. For example, some sources are
expected to provide multiple video tracks using different codecs all in a
single multiplexed stream, allowing the application to choose between them. The plan is for UMMS itself to also support automatically selecting the codec in such a situation, based on a pre-defined policy — such as whether an unoccupied hardware decoder for one codec is available, or whether hardware-decoding of a codec would consume less power than software-decoding of another.
Extending the concept
Beyond the basic playback and scheduled recordings already set out in the reference applications, the plan is to extend UMMS to cover a few other TV-specific features, starting with additional functions for DVR applications. There will need to be methods to work with electronic program guides (EPG), as well as to support time-shifting and conditional-access restrictions (think pay-per-view and VOD features, where the content provider might want to ensure that a media file is not watched multiple times).
Smart TVs must also implement industry standards like parental controls and channel locks. In some countries, this is not merely an issue of conforming to expectations, but of adhering to mandatory regulations. Finally, as in the codec-selection example above, one of the goals of UMMS is to provide a framework for managing hardware resources for access by multiple applications. Thus it will need to be able to report status back to applications when there are no tuners or decoders currently available, as well as distinguish between the capabilities of various playback and capture resources, and prioritize requests based on policies.
Although UMMS is designed to meet the needs of the smart TV UX, both Van Cutsem and the developers on the MeeGo lists emphasized that it will hopefully provide useful functionality to other form factors as well — in-vehicle systems and tablets in particular. But it fills in a gap in PC-based Linux systems, too. The ability to abstract away the playback engine would simplify development of desktop media players, especially those wanting to use hardware video decoding. TV capture cards are more of a specialty item, at least for now. However, the slow pace of development in the open source DVRs MythTV and Freevo could probably benefit from an abstraction layer like UMMS as well.
To be sure, a portion of the free software community may always grate at the prospect of building a framework that explicitly enables proprietary playback engines and applications, but UMMS is not substantially different from CUPS or other system frameworks in that regard. In this case, supporting the needs of set-top box makers who are beholden to the content industry bears dividends for open source, too, by clearly defining an API layer Linux has been missing for too long.
Van Cutsem ended his talk promising that more details would be coming
online soon — UMMS happened to land at an awkward point in the
transition between MeeGo and Tizen, after all. The MeeGo build system,
lists, and wiki are slated to be taken offline in one year, but the Tizen
project infrastructure has not yet rolled out. "Stay tuned" seems like the appropriate message.
[The author would like to thank the Linux
Foundation for assisting with his travel to LinuxCon Europe 2011.]
Comments (16 posted)
The Linux Foundation's Consumer Electronics Working Group (the group known
as the Consumer Electronics Linux Forum before the two organizations
merged) chose the Embedded Linux Conference Europe as the forum for the
announcement of a new
mechanism for the maintenance of stable kernels for the embedded industry.
If all goes well, this "long-term support initiative" (LTSI) will provide better
kernels for embedded systems with less effort while increasing the amount
of code that the embedded industry sends upstream.
The initiative was presented by Tsugikazu Shibata, a manager at NEC and a
member of the Linux Foundation's board. According to Shibata-san, current
long-term supported kernels do not really meet the embedded industry's
needs. Those kernels are well suited to the needs of the enterprise
distributions, where the same kernel can be used and supported for periods
up to ten years. A number of those distributions are built on 2.6.32,
which can expect to be supported for some time yet. Enterprise
distributions last for a long time, so the kernels they use are picked
rarely and supported for many years.
In the embedded world, 2.6.32 is very old news. Product lifetimes are much
shorter for most embedded products; manufacturers in this area need a new,
supported kernel every year. This industry, however, has no infrastructure
support of kernels on that sort of schedule. Last year the industry came
together and decided to standardize on 2.6.35, but it was a one-shot
action; no plans were made to support any later kernel versions. That is a
problem: but products being designed now are likely to need something newer
Another problem is that finding common ground for a standard embedded
kernel is hard. Much of the industry is currently driven by Android, which
releases with new kernels every six months or so. Manufacturers, though,
tend to get their kernels from their suppliers; those kernels can be based
on almost any version and lack any support going forward. Those
manufacturers need that support. They also would really like to use the
same kernel for a few generations of a product; that requires support for a
period of a few years, but it also requires
a certain amount of backporting of drivers and features.
Yet another problem, one that has characterized the embedded industry for
years, is that there still are not enough contributions to the mainline from
embedded developers (though, in all fairness, things have improved
considerably). Manufacturers have a lot of patches in house, many of which
do good stuff, but they are not going upstream. That imposes costs on
those manufacturers, who have to carry those patches forward, and it
impoverishes the mainline.
The LTSI project will have three components to address these problems. The
first of those will be a long-term stable tree for the embedded industry.
A new tree will be selected roughly once each year; 3.0 has been picked as
the initial kernel in this series. Each long-term kernel will receive
updates for two years as part of the usual stable update process; as with
the other stable kernels, only bug fixes and security updates will be
considered. Some sort of advisory board will be set up with a number of
industry developers to pick subsequent stable kernels.
The second component will be the "LTS industry tree," which will be
maintained, by CE Working Group members, independently from the regular
stable updates. This is the tree that, it is expected, will actually be
used in products. It will be based on the long-term releases, but will
include some extras: backported drivers, perhaps some backported features,
and various other vendor patches. In addition, there will be an associated
"staging tree" where interesting code can be tested out prior to its
inclusion in the industry tree. A separate quality assurance group will
devote itself to testing the code in the staging tree and deciding when it
The normal path for getting code into the industry tree will be to get it
upstream; a backport can then be done. There is, however, an intended
mechanism to take code directly via the LTSI staging tree in
unusual or urgent cases. Shibata-san was clear, though, that "upstream
first" will be the usual rule for this tree.
Finally, there will be an initiative to help industry engineers get their
code upstream. Yet another staging tree will hold these patches while they
are made suitable for inclusion into the mainline.
While it is assumed that the embedded industry is carrying a lot of code
internally, nobody has ever really known for sure. To get a better handle
on how much out-of-tree code exists, the Working Group launched the
"Yami-nabe Project." Yami-nabe parties are, evidently, an old, no longer
observed Japanese custom. Everybody would show up to a dark room
containing a large pot of water; each would bring some item of food and
toss it in. Everybody would then eat the resulting soup without knowing
what was in it or where it came from - whether they liked it or not.
The modern form of a Yami-nabe party, it seems, involves collecting
out-of-tree patches from manufacturers without tracking where they came from.
None of the companies involved want to have their work compared
to that of others. The collected code was examined to see how much of the
kernel had been modified, and how much duplicated code there was. Turns
out there were a lot of files in the kernel that most or all manufacturers
felt the need to modify; much was in architecture-specific and driver code,
but there were a lot of core kernel code changes too. Quite a few vendors
had made similar changes in the same places.
So clearly there is some duplication of effort going on. The LTSI tree,
Shibata-san said, should help to reduce this duplicated effort and to
reduce the kernel fragmentation in the embedded industry. Throw in some
help with the upstreaming of code and, they hope, fragmentation in this
area can be eliminated entirely - or at least something close to that.
The first kernel will be 3.0-based which is, not coincidentally, the base
Android "ice cream sandwich" kernel. They hope to have an industry kernel
release available sometime in the first half of 2012. After that, it's a
matter of seeing what kind of uptake there is in the embedded industry. It
seems, though, that quite a few companies are interested in this project,
so the chances that they will at least look at its output are pretty good.
[Thanks to the Linux Foundation for supporting your editor's travel to
Prague to attend this event]
Comments (63 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Calibre and setuid; New vulnerabilities in chromium, kernel, phpldapadmin, radvd, ...
- Kernel: IIO; 3.2 merge window; Btrfs update; Frontswap gets broadsided.
- Distributions: Ubuntu focuses on mobile devices; OpenBSD, OLPC, Ubuntu, ...
- Development: Sandboxing for automotive Linux; ALAC, libabc, transmageddon, Xvisor, ...
- Announcements: UEFI secure boot white papers, Real Time Linux Workshop, @openoffice.org email, ...