Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Anti-DRM efforts in Boston and Cambridge



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org