“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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide