But DRM only requires a secret key in the hardware. None of the implementing code needs to be secret, and indeed DRM that relies on opaque binary blobs or convoluted setup is useless.
If the issue is why Intel, AMD, NXP, etc aren't more transparent with their references, DRM doesn't really explain any of that. The only reason that makes sense to me other than sheer neglect is fear of IP infringement claims, a fear that any developer contemplating releasing their source code has surely struggled with. The patent landscape is a fscking field of indiscriminate landmines.
The "obviousness" test for patent eligibility is farcical. Just because the implementation of some driver seems obvious and straight-forward doesn't mean there doesn't exist a patent. Because of how technology develops--path dependency, foreseeable constraints--the vast majority of implementation details (including patented details) are obvious as understood by engineers, even if they've never encountered them before. But in practice obvious has effectively come to mean novel; were it any other way the vast majority of patents would never issue. And without omniscience you can never consistently know ahead of time whether something is novel or not; not if you're doing anything worthwhile. (Copyright is predicated on novelty, but copyright law permits independent development; patent law does not.)
Patent claims usually turn on minute implementation details. (A result, no doubt, of the surfeit of patents. Were it otherwise patents would stop industry completely rather than slowly bleeding it.) I'm not a patent lawyer, but I know that in general (in the U.S.) any claim needs to make a prima facie showing, which over the past several decades SCOTUS has required provide increasingly direct evidence. In as much as you raise the costs of discovering the evidence necessary to make a prima facie case, you've reduced your exposure to lawsuits.
If you're intent on targeting a particular company, and especially on targeting a particular company with a particular patent, opaque implementations are not much of a hurdle. But if you have a mountain of patents, the transactional costs of matching those patents to particular instances of [potential] infringement are quite significant. You not only need to expend effort to reverse engineer, but also effort to craft an argument to convince a court that your discoveries are legitimate. If an implementation is open it's much cheaper to accomplish both. Remember, labor is the single biggest expense in the Western world, and these types of activities are the epitome of labor intensive tasks. Reverse engineering a binary blob may be easy conceptually, but its absolutely costly in terms of labor, especially when it comes to pinning down the details in a way that matches particular claims in a patent.
The reverse is also true: if you have a mountain of products and components with significant exposure to infringement liability, opaqueness can substantially reduce your risk and effective liability. Even if exposure merely scales linearly with market or company size it suffices to explain the behavior of large companies, but I doubt it scales linearly. For one thing, larger companies are juicier targets, all else being equal, from the perspective of an individual claimant.
> But DRM only requires a secret key in the hardware. None of the implementing code needs to be secret, and indeed DRM that relies on opaque binary blobs or convoluted setup is useless.
DRM for a general purpose device needs way more than that. You need a full 'Trusted Execution Environment' to run the code that uses those keys.
Trusted execution doesn't need blobs, no? I.e. you can have secure boot with perfectly open booting. DRM is only used against the user, not for making things secure for the user. That's why DRM is relying on blobs.
If the issue is why Intel, AMD, NXP, etc aren't more transparent with their references, DRM doesn't really explain any of that. The only reason that makes sense to me other than sheer neglect is fear of IP infringement claims, a fear that any developer contemplating releasing their source code has surely struggled with. The patent landscape is a fscking field of indiscriminate landmines.
The "obviousness" test for patent eligibility is farcical. Just because the implementation of some driver seems obvious and straight-forward doesn't mean there doesn't exist a patent. Because of how technology develops--path dependency, foreseeable constraints--the vast majority of implementation details (including patented details) are obvious as understood by engineers, even if they've never encountered them before. But in practice obvious has effectively come to mean novel; were it any other way the vast majority of patents would never issue. And without omniscience you can never consistently know ahead of time whether something is novel or not; not if you're doing anything worthwhile. (Copyright is predicated on novelty, but copyright law permits independent development; patent law does not.)
Patent claims usually turn on minute implementation details. (A result, no doubt, of the surfeit of patents. Were it otherwise patents would stop industry completely rather than slowly bleeding it.) I'm not a patent lawyer, but I know that in general (in the U.S.) any claim needs to make a prima facie showing, which over the past several decades SCOTUS has required provide increasingly direct evidence. In as much as you raise the costs of discovering the evidence necessary to make a prima facie case, you've reduced your exposure to lawsuits.
If you're intent on targeting a particular company, and especially on targeting a particular company with a particular patent, opaque implementations are not much of a hurdle. But if you have a mountain of patents, the transactional costs of matching those patents to particular instances of [potential] infringement are quite significant. You not only need to expend effort to reverse engineer, but also effort to craft an argument to convince a court that your discoveries are legitimate. If an implementation is open it's much cheaper to accomplish both. Remember, labor is the single biggest expense in the Western world, and these types of activities are the epitome of labor intensive tasks. Reverse engineering a binary blob may be easy conceptually, but its absolutely costly in terms of labor, especially when it comes to pinning down the details in a way that matches particular claims in a patent.
The reverse is also true: if you have a mountain of products and components with significant exposure to infringement liability, opaqueness can substantially reduce your risk and effective liability. Even if exposure merely scales linearly with market or company size it suffices to explain the behavior of large companies, but I doubt it scales linearly. For one thing, larger companies are juicier targets, all else being equal, from the perspective of an individual claimant.