The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it.
Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to).
I piece of software cannot at the same time:
* be able to decrypt a video
* be able to be changed at the users' will
* be prevented from doing certain things the user wants.
If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying.
If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.
I think the parent's point is that it's absolutely feasible to build hardware and software that successfully enforces a DRM scheme, and also release the specs for the hardware and the source of the software.
That doesn't mean that a content producer will verify any old (modified) version of the software and allow it to play (and possibly "leak") their content.
Put another way: it's possible to build a secure DRM pipeline and then release all the source to it while maintaining the security of _that particular version_ of the pipeline. It's perfectly possible (cryptographically) to set it up so an unmodified version of that pipeline will be able to play protected content, while modifying it to (for example) dump decrypted bits to disk will cause the content to fail to play at all.
but what part of the pipeline is responsible for the verification of the 'unmodified' trait?
If it's a part that's open-sourced (hardware or software), then won't it simply be _modified_ to allow it to pass and allow extraction of decrypted content?
If it's _not_ open-source, then you don't have a fully open-source DRM scheme.
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
I was thinking along the lines of Kerckhoffs' principle.
You seem to be conflating open source with key extraction or decryption ability. You seem to be saying that if a specification is known then that implies an ability to modify the system to a degree that allows those things.
You can have a system whose workings you know precisely, without obscurity, where the SW/HW specifications are open and the only secret is the key material. For instance, you could have keys be embedded in processor fuses. How would a user extract the keys in that scenario?
For DRM systems the user or consumer is the adversary, but the principles of secure system design still apply. You can still place an asset outside of adversary reach. For example, by ensuring that they need a super expensive FIB machine to read keys. Or, more traditionally, by tailoring cryptography to their computational power.
You seem to be conflating the malleability of software with its modifiability in a given system, but in reality those can be controlled. Yes, you can fork the software, but why are you assuming you can replace it on a given system?
Consider a black box with an LED. The box has an internal power supply and the LED emits light pulses in a given pattern pleasing to the user who purchased it. I could give you its physical properties and circuit diagrams. The box has data stored in internal memory. You can call parts of this data software if you like, as long as we agree that the output of the box is a function of this data and time.
The only contradiction inherent in DRM systems is that knowledge of the data/function needs to be given to the adversary and not given to the adversary at the same time. This has less to do with open or closed source, and more to do with whether the user can open the box.
I think that the "solution" to this contradiction has been reduction in fidelity, where the user/adversary is only given an approximation of the function (analog outputs that they have a hard time spreading to other would be users).
DRM sucks, but is not fundamentally at odds with open source.
The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it.
Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to).
I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants.
If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying.
If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.