4 ms·

Can you even name any other class of software that cannot work unless people are somehow forbidden to modify or even read the code? It sounds like this is a pr

Can you even name any other class of software that cannot work unless people are somehow forbidden to modify or even read the code? It sounds like this is a problem with DRM, not with the free software movement.

duncan_bayne 13y ago
Viruses, worms, trojans, spyware (think the NSA), hardware verifiers (think laptops that only allow one brand of battery). There are a few.
chc 13y ago
As a class, just about any program that depends on security through obscurity has this trait.
- malka 13y ago
  There is no 'Security through obscurity'. At best, you will have the illusion of security, wich is worse than no security at all.
  - chc 13y ago
    This seems a bit like saying that there is no such thing as debugging because applications still have bugs afterward. I agree with the overall thrust that the security through obscurity is unreliable, but it is something, and it has even been effective to a limited degree on many occasions. (For example, many video game companies have employed defeatable security-through-obscurity successfully, because they only need to hold off the crackers for a couple of weeks.)
    - betterunix 13y ago
      Can you name any software that relies on security through obscurity -- and I assume you mean obscurity from the user of the software, since nothing else seems relevant here -- that is not just a specific kind of DRM?
wmf 13y ago
I'm not making any kind of judgement or assigning blame, just stating the fact that free software is fundamentally incompatible with DRM. I'd prefer to see EME get killed. But as a practical matter, if we go into a negotiation with nothing that we're willing to concede, we can't be surprised if it stalls immediately.
- duncan_bayne 13y ago
  There is plenty that we're willing to concede; as I've said, there is only one single point where negotiation is not an option - both from a FOSS and Open Web perspective. Unfortunately, it seems like the same is true of EME proponents, and it's the same issue :(

duncan_bayne 13y ago

Viruses, worms, trojans, spyware (think the NSA), hardware verifiers (think laptops that only allow one brand of battery). There are a few.

chc 13y ago

As a class, just about any program that depends on security through obscurity has this trait.

malka 13y ago
There is no 'Security through obscurity'. At best, you will have the illusion of security, wich is worse than no security at all.
- chc 13y ago
  This seems a bit like saying that there is no such thing as debugging because applications still have bugs afterward. I agree with the overall thrust that the security through obscurity is unreliable, but it is something, and it has even been effective to a limited degree on many occasions. (For example, many video game companies have employed defeatable security-through-obscurity successfully, because they only need to hold off the crackers for a couple of weeks.)
  - betterunix 13y ago
    Can you name any software that relies on security through obscurity -- and I assume you mean obscurity from the user of the software, since nothing else seems relevant here -- that is not just a specific kind of DRM?

wmf 13y ago

I'm not making any kind of judgement or assigning blame, just stating the fact that free software is fundamentally incompatible with DRM. I'd prefer to see EME get killed. But as a practical matter, if we go into a negotiation with nothing that we're willing to concede, we can't be surprised if it stalls immediately.

duncan_bayne 13y ago
There is plenty that we're willing to concede; as I've said, there is only one single point where negotiation is not an option - both from a FOSS and Open Web perspective. Unfortunately, it seems like the same is true of EME proponents, and it's the same issue :(