![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Jason Woodward wrote: | > On Jun 7, 2006, at 6:35 AM, Jerry Feldman wrote: | > | > DRM is evil but it is a bit misguided to take aim at Apple's DRM. | > Apple is "reasonable" when it comes to fair use. You can authorize | > up to FIVE players to listen to your iTunes music and you can even | > burn your music to a plain unprotected audio CD. I think time would | > be better spent focusing on HDCP (high definition content protection) | > and Microsoft's DRM in the upcoming Windows Vista release which are | > by far more draconian (to use M$ lingo.) | > | | I believe the reason they chose Apple is because it is the most popular | music download site. I think the FSF's stance on the matter is that any | DRM is an attack on your right to use the music or video you legally | purchased in the way you choose. Apple may be more "reasonable" than | others, but it is still limiting what you can legally do with the copy.=20 | The fact that most people are willing to accept Apple's DRM makes it the | perfect target, given the goal of no DRM. Funny thing is that when I experimented with this a few months ago, I found that when I told iTunes on my Powerbook to convert some tracks to MP3 and put them in a web directory, it worked fine. I could download the MP3 files to various other unix/linux systems and play them with anything. The only limit was that I then had problems copying them back to the Mac. The first couple of times worked, but then iTunes figured out that some copies were past the 5-copies limit, and wouldn't play them. I could still copy them over to linux and play them. So the DRM is inside the MP3 files; it just isn't recognized by non-Apple software. What I've wondered is whether Apple would tell us enough about how their DRM works that we can implement it (presumably as an optional feature) in our own software. You'd think they'd want us to do this, but of course we'd also then figure out how to remove the DRM, So they probably won't tell us, and we'll never implement their DRM in our MP3 players. This isn't a totally hypothetical quandary. Back in the 80s, I wrote a getty-like program whose main purpose was to include lots and lots of diagnostics, so I could tell why things like modem links weren't working right. I made it available to others, and I found that many people were using it because it didn't implement the 2-login limit that most commercial unix systems had then for their low-cost packages. In one newsgroup discussion, I publicly offered to implement the login limit if the unix vendors would tell me where my code could find it. I got no answers to this offer at all, probably because it was obvious that if they told me, then anyone could look at my code and figure out how to overwrite the login limit on their machines. So my program never did enforce the login limit. (I've heard that some Windows releases have a limit like this. Is there any commercial unix system that still has one? I haven't heard of this silliness for some years now. I'd say it qualifies as "silly" because it's a case of a vendor charging extra for changing the value of one byte - or maybe just one bit - in one file. And it totally depends on secrecy to work. And it's done by code whose sole purpose is to cripple the computer system.) -- _, O John Chambers <:#/> <jc at trillian.mit.edu> + <jc1742 at gmail.com> /#\ in Waltham, Massachusetts, USA, Earth | | ' `
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |