Leading items

ELCE11: Till Jaeger on AVM vs. Cybits

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 software, he said, which is why they are publicizing it.

The dispute

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 nobody is 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.

Legal questions

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.

What's next?

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 to come.

[ I'd like to thank the Linux Foundation for assisting with travel expenses to attend the conferences in Prague. ]

Comments (29 posted)

LCE11: UMMS, an audio/video abstraction layer

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.

Initial API

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" MediaPlayer objects. 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 fast-forward/reverse scrubbing.

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 embedded long-term support initiative

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 for the 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 than 2.6.35.

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 can graduate.

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 for the 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
Next page: Security>>