Google Proposing HDCP Content Protection Be Added To Intel's Linux Graphics Driver

[shmerl]

DRM has been built in Intel CPU's since the Pentium D back in 2005. This simply brings it up to the display level.

So may be developers should reject bringing this garbage into the display level. DRM (the evil DRM that is, not the Linux Direct Rendering Manager) should simply have no place in the Linux graphics stack.

[bridgman]

Are you sure about that and do you have a link stating that? My 1 minute google-foo didn't turn anything up.

I think that refers to section 110 part 5 B i II of US copyright law rather than being specific to NFL broadcasts:

if the performance or display is by audiovisual means, any visual portion of the performance or display is communicated by means of a total of not more than 4 audiovisual devices, of which not more than 1 audiovisual device is located in any 1 room, and no such audiovisual device has a diagonal screen size greater than 55 inches, and any audio portion of the performance or display is communicated by means of a total of not more than 6 loudspeakers, of which not more than 4 loudspeakers are located in any 1 room or adjoining outdoor space

https://www.gpo.gov/fdsys/pkg/USCODE...ap1-sec110.pdf

BTW there is a grey area though about how 5 A should be interpreted - the wording suggests that 5 B only applies to "an establishment" and not to private residences, and from an equipment POV it mentions "a single receiving apparatus of a kind commonly used in private homes", which in turn leads to the question of whether a 60" or 90" screen is "sufficiently common" for 5 A to apply. Around here it certainly is - my low-budget 4x8 foot sheet of Formica is probably one of the smaller screens around here.

When in doubt I believe the usual solution is to invite at least one lawyer to the party.

[Niarbeht]

I think that refers to section 110 part 5 B i II of US copyright law rather than being specific to NFL broadcasts:



https://www.gpo.gov/fdsys/pkg/USCODE...ap1-sec110.pdf

BTW there is a grey area though about how 5 A should be interpreted - the wording suggests that 5 B only applies to "an establishment" and not to private residences, and from an equipment POV it mentions "a single receiving apparatus of a kind commonly used in private homes", which in turn leads to the question of whether a 60" or 90" screen is "sufficiently common" for 5 A to apply. Around here it certainly is - my low-budget 4x8 foot sheet of Formica is probably one of the smaller screens around here.

When in doubt I believe the usual solution is to invite at least one lawyer to the party.

My God, our laws are ridiculous.

[starshipeleven]

When I buy blurays in the store, I sign no such thing. But I heared in the USA the customer can get fucked after handing over the cash.
Also EULAs are practically worthless in parts of Europe. The law does however limit our right to circumvent copy protections...

You must be in Germany.

In my EU country all (legally sold) media has stickers of the local copyright enforcement association, and stuff with that sticker cannot be played in public, you are forbidden from lending it. And of course you can't copy or break its encryption.

Then again all this shit is 100% unenforceable (and unenforced).

FYI the storage devices or devices with internal storage that can be used to store pirated content have a higher price due to some kind of tax we give to this "copyright enforcement association" each time we buy as "compensation".
See here for an incomplete list of other nations doing the same https://en.wikipedia.org/wiki/Private_copying_levy

[jf33]

Those who want copy protection crap can use Windows. Keep GNU/Linux clean from it.

[bridgman]

My God, our laws are ridiculous.

Yeah, and companies have to obey them even more than individuals typically do. That is pretty much the heart of the DRM debate.

[edwaleni]

Are you sure about that and do you have a link stating that? My 1 minute google-foo didn't turn anything up.

People complained, and the NFL relented ( a little)

http://www.espn.com/nfl/news/story?id=3256621

https://arstechnica.com/tech-policy/2010/01/will-your-big-screen-super-bowl-party-violate-copyright-law/

[roothorick]

one might argue then that you are not a legit customer :P

also, strangely, if you get the right "hdmi recording" dongle (used for screen recording) they just happen to strip the content protection :P

What they do understand is the DMCA. Using equipment that strips HDCP is a federal felony. Possession might be a felony too but I'd have to check.

[robclark]

No, this garbage should be rejected by Mesa developers. I hope they understand how toxic and unethical this stuff is.

disclaimer: I'm not a fan of DRM (the evil one).. but..

(a) this is hardware enablement, and something that every CrOS/android/etc device vendor would add downstream if it wasn't supported upstream. I'd prefer more code upstream where it gets proper review, security audits (ie. not is HCDP "uncrackable" but "is there a potential buffer overflow in that code"), etc. Is it better to later discover a CVE effecting millions of devices because of code device vendors maintained downstream effecting potentially even users not using DRM content? Or to get the code upstream and more eyes on it? I'm not saying to accept crap code upstream, but we should try to get it upstream (and if it was crap, refine it to the point that it isn't and it can be accepted upstream).

(b) I don't really see a downside.. if you aren't a fan of DRM then don't buy/consume DRM content. It's not like this is adding some closed src blob to the kernel or something like that.. it is adding a feature, not compelling anyone to use that feature.

(c) perhaps a kconfig option or module param to disable HDCP support would perhaps be a reasonable compromise. Either way, more downstream device kernel code is the worst of both worlds.

[shmerl]

(b) I don't really see a downside.. if you aren't a fan of DRM then don't buy/consume DRM content. It's not like this is adding some closed src blob to the kernel or something like that.. it is adding a feature, not compelling anyone to use that feature.

There can be several downsides. First of all, it helps proliferation of DRM. I.e. Linux implicitly endorses it by implementing this. It already stinks for me. But bigger problem can be legal. Since that code touches on DRM, it still might be a subject to anti-circumvention provisions. I.e. you might be simply legally forbidden to modify it, since it can facilitate circumvention of DRM. I'm not sure this is even compatible with GPL. It's a very slippery slope.

How much stuff like DMCA-1201 can be abused, see here. We can all despise Sony for attacking developers based on their PlayStation OS, but think about someone doing it using this very Linux code.

Either way, more downstream device kernel code is the worst of both worlds.

This is moot. Same argument was in W3C. Should vendors implement bad DRM without standards, and use bad native plugins, or should W3C make EME and have standard interfaces (for DRM)? Their argument went that getting rid of bad native plugins is good. But I think it's the opposite. The more sore DRM is, the less likely it will be used. Improving it (or rather obscuring its problems from the user) serves the opposite purpose and only helps its proliferation. In the end W3C went ahead with it despite objections. I'd really not want Linux to end up the same way. But Google and Co. will surely put a lot of pressure, same as they did in W3C.