Messages in this thread | | | Date | Mon, 20 Jul 2009 21:13:53 +0200 | Subject | Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream | From | Stephane Marchesin <> |
| |
> You obviously got all this completely wrong. > > I avoid writing closed source drivers whenever I can, I'm not whining and > I'm not trying to push any of them. The code VIA is trying to submit has not > been written by me nor anybody I know. All VIA code I and the companies I've > worked for has written is open-sourced and contributed to the Openchrome / > mesa / drm project. > > The point I'm trying to make is the following: > > If the common agreement of the linux community is to *NOT* allow these > drivers in, so be it, then be honest and go ahead and tell the driver > writers. Don't make them respin their development trying to fix minor flaws > when their driver won't get in anyway! >
I would like to raise a couple of real-life issues I have in mind:
* First example, let's say VIA gets their Chrome9 DRM merged into the kernel. Now let's say I reverse engineer the hardware (or use the docs whenever they're available) and write a 3D component that needs modifications to the existing DRM interface (or maybe I realize I need a completely new DRM). Then who gets the upper hand? Do I have to keep compatibility with user space binary modules that I do not care about?
* Second example, what is the policy if we find security holes in the DRM for a closed user-space afterwards? This breaks the initial promise of security, does that get the driver removed then? Or what if the promise is pending updated documentation that never arrives?
* Third example, what if down the line we need changes in the DRM that require updating all DRM modules. Do we (we as in DRM developers) touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking the code (since we don't test with proprietary modules)? Or do we let the Chrome9 files as-is, keeping the old DRM infrastructure and therefore add more and more DRM cruft?
In my opinion, accepting GPL'ed DRM modules that support binary user space components is like opening pandora's box.
Stephane
| |