On Wed, 2009-07-01 at 20:37 +0100, Simon Kenyon wrote: > Andy Walls wrote: > > Those latest changes look for the "dvb-cx18-mpc718-mt352.fw" file to > > load and initialize the MT352 DVB-T demodulator chip. > > > > It has to be done this way to avoid any software license problems. The > > information to properly initialize the MT352 is not publicly available, > > and we musn't hardcode into the Linux kernel an initialization sequence > > extracted from the Windows driver. > > > > What you have tested previously and have reported as working, *cannot* > > be included in the Linux kernel. These latest changes in my cx18-mpc718 > > repo *can* be included in the Linux kernel. > > > you said > > "we musn't hardcode into the Linux kernel an initialization sequence > extracted from the Windows driver" > > this caught my attention. the kernel probably has other code like that > in it. can you explain the reasoning behind that statement?
Simon, For patches I contribute to the kernel, I essentially have to attest: http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches#Developer.27s_Certificate_of_Origin_1.1 with the software license in question being the GPLv2. Given that: 1. I, along with most Linux users, don't have license to use the Yuan MPC718 Windows driver software since I (we) don't own a Yuan MPC718 device 2. The Yuan MPC718 Windows driver likely (I haven't checked nor will I bother) has an EULA agreement that asserts rights and restrictions regarding use of the Windows driver binary 3. The Yuan MPC718 Windows driver binary is covered US and international copyright laws (although 48 bytes out of ~150K may be "fair use") I deemed (i.e. my personal belief) hardcoding a binary sequence extracted from the Windows driver into the Linux kernel patch, puts the patch on very shaky ground legally. I cannot make the attestation needed for a "Signed-off-by" as outline in the Developer's Ceritifcate of Origin. If I could have snooped the initialization sequence via a PCI or I2C bus monitoring mechanism with the actual hardware in my possession, that may have been different. But that was not the case here. If you look at the tuner-xc2028 module and the xc2028 firmware file, you'll see the exact same process is in place. That "firmware" file is a collection of sniipets pulled out of a Windows driver binary. The tuner-xc2028 module won't work without it. As for the rest of the kernel? I don't know. Check the mailing list archives for various subsystems. I know the video4linux or linux-dvb list went through some debate with the past year or so. I think the resolution was to get firmware, that was coded in C arrays, out of the kernel, so that there is no question of distribution rights under the GPLv2. Regards, Andy > simon _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
