“Roadcast Flag” Is MPAA's Latest Attack on Linux
The Digital Millennium Copyright Act (DMCA) gave copyright holders powerful new rights to control implementations of proprietary protocols and media formats. Yet, it took a hands-off position toward non-proprietary formats. You still are free under the DMCA to implement a system based on open standards with the features of your choice.
But now, even this “no mandate” rule is under attack from proposals to regulate the use of open standards. The best-known is the Consumer Broadband and Digital Television Promotion Act (CBDTPA), introduced by Sen. Ernest Hollings. CBDTPA goes beyond the DMCA and requires that any “digital media device” must include “standard security technologies”.
The CBDTPA has been criticized from many directions. But entertainment industries have effectively split it into a series of more palatable pieces. The Motion Picture Association of America (MPAA) has spent the past year pursuing three new regulatory measures:
A “broadcast flag” mandate for all devices that can receive digital television broadcasts.
An “analog hole” watermark-detection mandate for “all devices that perform analog-to-digital conversions”.
An unspecified technology mandate for peer-to-peer file-sharing software.
None of these measures, individually, is as drastic as the CBDTPA. Mandates can be imposed gradually; technology industries may not launch an all-out campaign against any particular measure. Tech vendors may be divided and choose not to oppose measures that don't affect them directly.
MPAA's lobbying for a “broadcast flag” mandate is already underway. This proposal is specific to US terrestrial digital television broadcasts. But it's the first part of a larger regulatory agenda that needs to be stopped now—movie studios should have less, not more, control over our technology.
Current-generation US television broadcasts use the 50-year-old analog NTSC transmission standard. In 1996, the US adopted a plan to replace NTSC gradually with a next-generation digital standard, ATSC, capable of carrying high-definition TV pictures. This transition was meant to finish around 2006 with the complete discontinuation of analog TV broadcast. Meanwhile, stations are broadcasting both analog and digital TV signals (using additional channels lent to them by the government). ATSC-capable home theater equipment and PC adapters are now available. The transition is underway.
ATSC is an open standard, and terrestrial broadcasts using it are always unencrypted. Therefore, the DMCA does not restrict the kinds of features that can be included in an ATSC receiver. Hollywood studios have begun to complain that this means ATSC broadcasts are too insecure for transmission of Hollywood movies—if anybody can build a receiver, the movies could be used in ways the studios might wish to prevent.
The studios have argued that the “insecurity” of ATSC receivers is deterring them from licensing their movies for ATSC broadcast. They regularly license their movies for unencrypted NTSC broadcast, but the superior quality of ATSC purportedly makes it a more attractive target for copyright infringement. Instead of encrypting the broadcasts, however, the studios have proposed new legal restrictions that limit how a TV signal can be used on receiving devices. According to the studios' proposal, the TV receiver, whether hardware or software, would have to be “compliant” and “robust” against modification by an end user.
Instead of encryption, the proposed measure is merely a label or header akin to an e-mail header defined to signal “technological control of consumer redistribution”. Such a measure is no more effective than an “X-No-Forward:” e-mail header, but a law or regulation could deem it illegal to fail to honor such a header.
This regulation leads us away from a world where people are free to implement open standards as they choose. ATSC has been such a standard, but the benefits of its openness, including support by free software, could be lost.
“Compliance” requirements limit permissible outputs to a short list of restricted formats, implementations of which are subject, in turn, to DMCA restrictions. Open standards need not apply. This creates a tremendous incentive for consumer electronics manufacturers to implement proprietary technologies. Open interfaces, which one studio representative referred to as “legacy interfaces” because they lack copy controls, would suffer a substantial competitive disadvantage.
“Robustness” requirements prevent programmers from developing free drivers for ATSC, such as the free drivers already being developed for ATSC tuner cards. They also would ban free software implementations of ATSC, such as FSF's GNU Radio Project, which interprets radio signals in software. If software can be modified by an end user, it can't be trusted to control how users use it—the same argument the MPAA uses against the development of free DVD players. The broadcast flag rules could result in a ban on certain kinds of free software specifically because that software can be modified by end users.
The Federal Communications Commission (FCC) is now considering whether to mandate that TV-receiving equipment comply with these rules.
EFF is fighting this proposal and recently filed comments with the FCC against it. We attended all the meetings of the Broadcast Protection Discussion Group where the proposal was developed. With our “Consensus At Lawyerpoint” web site, we've tried to fill the information vacuum surrounding the broadcast flag issue. (Reporters were barred from meetings, which had a $100-per-meeting admission fee.)
Seth David Schoen created the position of EFF staff technologist, helping other technologists understand the civil liberties implications of their work, EFF staff better understand the underlying technology related to EFF's legal work, and the public understands what the technology products they use really do.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
4 hours 29 min ago
- seo services in india
9 hours 1 min ago
- For KDE install kio-mtp
9 hours 2 min ago
- Evernote is much more...
11 hours 2 min ago
- Reply to comment | Linux Journal
19 hours 47 min ago
- Dynamic DNS
20 hours 21 min ago
- Reply to comment | Linux Journal
21 hours 20 min ago
- Reply to comment | Linux Journal
22 hours 10 min ago
- Not free anymore
1 day 2 hours ago
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?