Audible.com and other DRM format ideas

[chripley]

I've read all about how Rockbox can't support DRM-protected files.  That makes sense.  But since there is a plugin architecture, could not someone write a plugin that was closed-source?  Would this approach not allow the rockbox to play audible format files, keep the agreement with Audible in tact by "keeping the secret", and provide additional functionality to users that may not have had the ability to play Audible format with their native firmware (like my v1 Sansa e260)?  Please help me understand if this approach is possible...  or does the license Rockbox is published under forbid the interoperation with closed-source systems?

[AlexP]

Nope, this can't be done as Rockbox is licensed under the GPL.

[chripley]

OK, so does anyone have any links on where I can discuss licensing topics?  If this is the case, how can GPL projects run on MS Windows?  What about how we modify the bootloader of a closed-source product in order to be able to run this open source one - does that not violate the license of the original system?  Is there any discussion on an alternate open-source license, or is that just not attractive to the development team?

Yeah, I could probably find a way to remove DRM from Audible.com files.  There are two ways I can think of right now, but I'd rather not.  Right now I play them through my TomTom, but I'm not bringing my TomTom on a plane to travel to San Francisco just to listen to audible.com audiobooks (the battery life stinks on that thing...  5 hours my bum!  hehe).  I could find non-DRM audio books, but as someone else already pointed out, they are not produced as well as Audible, the titles they have are usually dull and they have few in number.

[Llorean]

GPL programs can run on a Windows computer because the code isn't *linked*.

Rockbox isn't a full OS. Plugins are linked to Rockbox. And we don't link any code to the original firmware at any point.

[chripley]

Thank you for being patient with me an answering these types of questions.  What is the technical difference of a GPL program "not linking code" into Windows but taking advantage of its .DLL files (for drawing windows, drivers for keyboard/mouse access, etc) and a closed-source plugin "linking" code to Rockbox?

By the way, I'm loving my RockBox!  I was playing blackjack in my car, listening to FLOSS Weekly (where I learned about this to begin with) while waiting for a meeting to start at a client's.

[saratoga]

Thank you for being patient with me an answering these types of questions.  What is the technical difference of a GPL program "not linking code" into Windows but taking advantage of its .DLL files (for drawing windows, drivers for keyboard/mouse access, etc)

GPLed programs are allowed to call operating system libraries.  This in the GPL.  Perhaps you should read it.

and a closed-source plugin "linking" code to Rockbox?

The problem is you can't have closed source code at all in rockbox, not that the closed source code would need to talk to rockbox.

[cool_walking_]

Couldn't you have a bytecode interpreter in Rockbox, and write this DRM thing in that?  Impractical, I know, but just talking about legality.  Isn't bytecode/scripting different here in that it isn't linked, but interpreted?

D'oh.  This bytecode format would be documented in Rockbox's source, thus the DRM plugin could be decompiled.

[saratoga]

Couldn't you have a bytecode interpreter in Rockbox, and write this DRM thing in that?  Impractical, I know, but just talking about legality.

You can do this.  Theres nothing stopping you from implementing an OS that allows running closed source applications.  Ipodlinux for instance.  However, if you do this, its no longer rockbox, but rather some other OS.

[dreamlayers]

I'm not sure why someone couldn't release a closed source plugin.  It's a separate file, just like applications in Linux and other OSes.  It couldn't become an official part of Rockbox, they'd have to rewrite some Rockbox components which go into the .rock file, and it'd be difficult to keep it up to date, but it seems feasible.  This is entirely hypothetical however.  I don't expect that Audible cares about making a Rockbox plugin.

The best solution is to not buy things with DRM.  The next best solution is to make a program which removes the DRM.  For example, it can't be that hard to reverse-engineer an Audible player application and find how to get unencrypted data from it.  Neither of these solutions have anything to do with Rockbox however.

[saratoga]

I'm not sure why someone couldn't release a closed source plugin.  It's a separate file, just like applications in Linux and other OSes. 

File doesn't matter.  What matters is how it runs.  Plugins must have the same license as the host application because they run inside it.  Applications in linux do not, because they do not run inside the OS "process", but rather as a separate process.

[dreamlayers]

File doesn't matter.  What matters is how it runs.  Plugins must have the same license as the host application because they run inside it.  Applications in linux do not, because they do not run inside the OS "process", but rather as a separate process.

Wow!  This seems illogical because I can't see how plugins and applications differ.  Applications can interact with the operating system and other applications in many ways, including shared memory.  "Separate" processes can be more intertwined and interdependent than some applications and their plugins.  But you're right:
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
http://groups.google.ca/group/gnu.misc.discuss/browse_thread/thread/1abca508ac605aa

Thanks for telling me this.

[chripley]

Yeah, I have trouble wrapping my head around it, too.  Its a cliche how confusing all the different license structures of OSS can be.  Thanks for clarifying this to me as well.

So from what I'm understanding, in order to do this it would require:

• Turning Rock box into an OS and the DRM stuff can be an application, not a plugin or
• Convincing Audible to drop DRM

Neither of these are likely to happen so now I more fully understand why Rockbox will not support DRM.

But, since Rockbox is not classified as an OS and is instead classified as an application, can you tell me what the OS is?  Because then someone can write a closed source library for that OS that Rockbox would be allowed to call upon, according to what you all just wrote.

The best solution is to not buy things with DRM.

There is no viable non-DRM audio book market for purchase of digital files.  You can purchase audio books on CD and rip them, but that's more expensive and less convenient.

[saratoga]

But, since Rockbox is not classified as an OS and is instead classified as an application, can you tell me what the OS is?

Depending on your definition it can be both or either.

  Because then someone can write a closed source library for that OS that Rockbox would be allowed to call upon, according to what you all just wrote.

No this is not a valid conclusion to draw from what I have said.  Reread my reply to you from the last time you suggested this idea.

[chripley]

GPLed programs are allowed to call operating system libraries

You mean this?  If Rockbox is not defined as an OS but is an application, then I should be able to write a closed source library in the OS.  I could then write an open-sourced plugin to Rockbox that calls the library.  So I ask, what's the OS?

Or better yet, what would it take to allow Rockbox to do this?  That's what I'm getting at with all the questions.  And most importantly, are the developers of Rockbox even interested in DRM products?  If not, that's a simple enough and acceptable answer to me.

[Llorean]

Rockbox is also the OS, but it's not an OS designed around the possibility/idea of running applications. It's firmware. You'd have to adapt the architecture to run things as "separate" applications. Then of course you'd have to separate the entire media player out of Rockbox so that your DRM-music-read can actually PLAY the media because there's no way they're going to let you get away with stripping it and writing it back to file, you'd have to keep it in RAM and play it back. Then the playback program is open source, so it'd be trivial to dump to file, so they'd probably require you to decrypt *and* playback in your closed source program, requiring closed-source reimplementation of many of the codecs, etc, etc.

The Rockbox project isn't interested in DRM, anyway, but it's really not nearly as simple as you'd think if you want to do it in a way that even has a hope of achieving cooperation with the people providing the DRM.