OSNews

It seems like a practical reality of DRM software, though, that it will violate the desires of GPL3 advocates (and perhaps any anti-tivo clause in the license). I am not an expert in DRM crypto algorithms or anything along those lines, but it seems to me that you can make a modification of the decoder and get the unencrypted stream if you can arbitrarily change the software. The only way to avoid this is multi-stage decoding with the last unencryption done on the hardware itself. But I can think of some issues here as well. It's a lot easier to make DRM work when you ensure that the decoder and lower layers of the OS do not work against the desired usage policy and sign the relevant software so that it cannot be modified.

Edited 2008-01-19 10:45 UTC

In order to write DRM software you have a number of choices:
(1) write your DRM application as proprietary code. To do that for a KDE target requires only that you pay Trolltech for a developer license, and you avoid statically linking to any other GPL'ed code. LGPL is OK, and dynamic linking is OK.

(2) write your DRM application as open-source code. This means that you do not have to pay Trolltech for a developer license, but it becomes trickier to write your application. If you write your application as BSD code, then anyone can steal it from you. If you write it as GPL'ed code, then you must not apply the DRM to the code itself. Therefore, you must put all of the DRM cleverness into the decryption key, which you c must keep a secret. In that way, anyone downstream removing your decryption will also remove access to DRM'd content.

weather the reason for wanting to lock up software is to provide a 'better' DRM or anything else, it goes against the idea of being able to modify and run GPL'd code.

If an author wants to release their code and ensure that the rights of others to modify and run that code are protected and not taken away through a back door like 'tivoization' (or to my mind, the far more potentially dangerous 'trust computing' platforms) then GPL3 is a stronger choice than GPL2.

Now, like all code, if someone wants to incorporate my code into a product and the 'price' I've set on the use of my copyrighted work is that certain end user rights are protected, then I expect that price to be paid, no differently than would any software supplier who charged $ for a software license. If someone takes my code and adheres to the letter of the license but, to mind, doesn't 'pay' me the price I'm charging (in this case, end use rights) then I'm going to look to make sure that that can't happen in the future. Which is basically how the anti-digital locks part of GPL3 came about.

You, me, the DRM implementers, Linus, Trolltech, the BSD guys and everyone else in the world may (almost certainly do) all have different ideas on what it is they want to receive in recompense for their effort and what they think makes up a good license to build upon. GPL3 is one choice among many and like all others, involves certain pros and cons for both those seeking to license their work under it and those seeking to use work licenses under it.