vacancies advertise contact news tip The Vault
facebook rss twitter

Compro Technology responds to GPL accusations

by Parm Mann on 27 May 2008, 17:16

Tags: Compro

Quick Link: HEXUS.net/qangd

Add to My Vault: x

Just last week, we reported that Taiwanese manufacturer of TV cards, Compro Technology, had been accused of violating the General Public License (GPL).

The accuser, Jo Shields, had stated: "they (Compro) are offering a "driver" for Mandriva Linux 2007.1, in the form of an 18 meg "linux.rpm". This "driver" is, in fact, an entire kernel image (from snd-emu10k1.ko to libata.ko, with everything in between), generated from Mandriva's kernel source package, with local modifications to at least two files (major file size gap between Compro and Mandriva kernels in tuner.ko and cx88xx.ko)."

"Their "driver" is being offered in binary-only form, without any accompanying license, and I have received no replies to a formal request for source after 2 (Taiwanese) working days. Obviously, this violates several GPL clauses, and infringes on the rights of every kernel developer with code in 2.6.17."

Having read Mr Shields' comments, Nicole Tseng, marketing communication manager at Compro Technology, has issued the following statement:

"We are in the process of adhering to the GNU General Public License rules and we expect to have the drivers ready by Q3 2008."

In the meantime, both the Mandriva Linux 2007 and Fedora Core 6 drivers have been removed from the Compro Technology website. Looks like someone was being naughty, but, at least they've taken action to rectify the situation.

Related reading
Compro Technology accused of GPL violation



HEXUS Forums :: 5 Comments

Login with Forum Account

Don't have an account? Register today!
this is excellent news for all concerned, and i'm including Compro in that. they've also responded pretty quickly compared to how long some GPL violation cases drag on for, so that can only be a good thing

for the people who work hard on the linux kernel, their work is no longer being distributed in ways that directly conflict with their wishes. and for Compro, it means at worst case they've avoided a messy PR fight with some of the most vocal nerds on the internet

if they go the “proper” route to getting their kit supported, and work with the linuxtv developers to add support “at the source”, then Compro's cards can get out-of-the-box support in every single linux distro, rather than only old versions of mandriva and fedora. at which point they can be a name that gets thrown around in linux (and htpc) circles as a company that just works, out of the box, and is a great buy. support for their S300 series (at the very least) isn't a million miles from working anyway, so if they can provide the last few hints needed for full support, then that's a lot of extra work and duplicated effort avoided

lord knows their DVB-S card is the cheapest on the market by a long shot, so out of the box support would be fantastic.

if they can kick it up a gear, then they can try and aim for the next batch of major distros - Debian 5.0 is due in September, and both Fedora 10 and Ubuntu 8.10 in late October.
so, as an interim solution, no support. (not that forcing people to use a pre-compiled kernel is support).

(one of my major hates of modern bsd/linux practices is this pre-compiled nonsense, in my virtaully un-payed days of running quake and half life servers i was sure that simply compiling it targeted for my machine would give a hudge performance boost, thou at the time gcc was a bit poor at this. I'm quite tempted to have a full rant at this, i've got vc6 un-service packed, and vs2008 at work, i'll compile the same simple test app in both, and bench it next time i'm bored, i recon there will be some major boostage to be had by having a compiler that has a clue about my cpu).

The question i have to ask is, why where they needing to provide a whole compiled kernel anyway, linux's driver model isn't *that* bad that they should have to be fiddeling with other modules to leaver in their support, i wounder what they where tweaking?

The problem is thou hex, they won't see it as a chance to get their hardware as an established brand that just works. Relteck for instance spend hudge wads of cash on their drivers, they've noticed that for the vast majority of users, even a few who play games, everyones waxing lyrical about how great their products are under vista, how it just works, whilst 3 years ago they where considered an economy choice, they're now seen as solid and reliable, just from better drivers. Many companies as such want to sit on their work, and not allow others to get their competative edge, even thou its damaging to the CS world.
TheAnimus
so, as an interim solution, no support. (not that forcing people to use a pre-compiled kernel is support).

well, indeed. an insecure kernel for mandrake 2007.1 is hardly “support”

(one of my major hates of modern bsd/linux practices is this pre-compiled nonsense, in my virtaully un-payed days of running quake and half life servers i was sure that simply compiling it targeted for my machine would give a hudge performance boost, thou at the time gcc was a bit poor at this. I'm quite tempted to have a full rant at this, i've got vc6 un-service packed, and vs2008 at work, i'll compile the same simple test app in both, and bench it next time i'm bored, i recon there will be some major boostage to be had by having a compiler that has a clue about my cpu).

for most apps, there's little benefit to compiler-side optimizations done by a “generic” compiler. use a CPU-specific one like ICC or PathCC, and you get a boost. and if it's performance critical, pull out the assembly & do runtime cpu detection (like mencoder does)

The question i have to ask is, why where they needing to provide a whole compiled kernel anyway, linux's driver model isn't *that* bad that they should have to be fiddeling with other modules to leaver in their support, i wounder what they where tweaking?

our suspicion is that they copy-pasted large portions of (proprietary) code from the Zarlink SDK - and here's the stupid bit, ALL the chips used by their cards have support in the standard upstream kernel. all they had to do was some bugfixing to a couple of files (e.g. mt352.c) to fix card-specific problems

the other option is simple ignorance of correct linuxy practices - any bugger can write a kernel module, any bugger can edit a .c file, perhaps their dev's desktop just happened to have mandrake on it

The problem is thou hex, they won't see it as a chance to get their hardware as an established brand that just works. Relteck for instance spend hudge wads of cash on their drivers, they've noticed that for the vast majority of users, even a few who play games, everyones waxing lyrical about how great their products are under vista, how it just works, whilst 3 years ago they where considered an economy choice, they're now seen as solid and reliable, just from better drivers. Many companies as such want to sit on their work, and not allow others to get their competative edge, even thou its damaging to the CS world.

realtek? they already do just that though - their chips tend to just work out of the box on linux, and you can download some source straight from Realtek

they've got their fingerprints all over the kernel. in the sound case, Kailang Yang and PeiSen Hou at realtek are their main contributors
In my C++ days (which where spent bitching about much nicer java was) i was amazed when the HL mod i was working got a 5% frame rate boost just with a simple update to visual studio (which included the ms c compiler update). No code changes, no config changes. This was running intel cpus.

as for ignorance of practices? I don't see that for a second, when i last tried to write a kernel module, it was following about 4 HOWTOs (that didn't quite cover it properly) and took me a bloody week to do something i did with an MS tool for NT5! I can't see them been ignorant.

Someone as you suggest did something naughty and tried to hide it is one likely option, the other been they just didn't want to share and enjoy.
Gcc can do some rather nice sub-architecture optimisations these days, their value varies between programmes of course.