Kernel Maintainer Kills Philips USB Camera Support

outanowhere writes "The author of the Philips webcams kernel module has thrown in the towel and quit providing the pwc and pwcx kernel modules which make using Philips-based USB cameras such as those from Logitech and Philips possible with Linux. According to the author, the last straw was when a kernel maintainer changed his pwc module to make using the binary-only pwcx compression module impossible. It is a victory for obsessive kernel-purists but a major loss for all Linux users."

Comments

By the way

[gazbo]

For all of you who wonder what we mean when we say "zealots make it hard for businesses to take F/OSS seriously", this is what we mean.

Re:By the way

[psavo]

For all of you who wonder what we mean when we say "zealots make it hard for businesses to take F/OSS seriously", this is what we mean.

Nope. This is eating own dogfood, having a stance and keeping it. Businesses can be sure that there's no fucking around rules of linux development. It's either playing by the rules or not playing at all.

Re:By the way

[MS_is_the_best]

Despite the somewhat suggestive text from 'outanowhere' the truth is different I guess. Philips does not want to support linux, by providing a kernel driver for their device. That is their choice. This is and stays the main problem.

Now, someone ported a binary driver to linux. Very nice from this guy, but in the long run this will hurt linux (AND linux users). Manufacturers are just weighing what's the penalty and the profit for bringing out a driver (binary or source), no driver or support somenone who writes a driver (binary or source). Now, if the use of binary drivers is discouraged, there will be more source drivers becoming available (but less drivers, some manufacturers are not willing to open their source). However in the long run (and linux marketshare will help) manufacturers have to support linux. The more other manufacturers have open source drivers, the less trouble they have doing the same.

Of course you can say all things about manufacturers 'not being able to open' (nvidia binary drivers cannot be opened, because of rules, etc.), but that is just not true. Nvidia has no advantage of opening their secrets (yes, their competitors will take advantage of this) and therefore they are not doing it (they lose perhaps a handfull of users). A perfect business decision in the light of most linux users using a binary driver. However if ATI IS providing (this is an example) the source, Nvidia has to look different to the situation, especially if, say 20% of the users uses ATI because of this and if ATI is also 'giving up' their secrets.

All this is just negotiation in the end and we should not give up already and accept binary drivers. That is just like a salesman selling televisions for 1 dollar, because that is bidded first.

No, i am not obsessed, just differently minded (and not native, sorry for my language).

Re:By the way

[GregChant]

Manufacturers are just weighing what's the penalty and the profit for bringing out a driver (binary or source), no driver or support somenone who writes a driver (binary or source).

Do you have any evidence that this is the case, or is this just pure speculation?

Now, if the use of binary drivers is discouraged, there will be more source drivers becoming available (but less drivers, some manufacturers are not willing to open their source).

This is wholly fallacious. There is nothing to suggest that by blocking binary-only development, more source will become available. This is a pipe-dream of the F/OSS utopia.

However in the long run (and linux marketshare will help) manufacturers have to support linux.

Again, fallacious; again, a pipe-dream of the F/OSS community.

The more other manufacturers have open source drivers, the less trouble they have doing the same.

Do you have any evidence that this is the case?

Nvidia has no advantage of opening their secrets (yes, their competitors will take advantage of this) and therefore they are not doing it (they lose perhaps a handfull of users). A perfect business decision in the light of most linux users using a binary driver. However if ATI IS providing (this is an example) the source, Nvidia has to look different to the situation, especially if, say 20% of the users uses ATI because of this and if ATI is also 'giving up' their secrets.

You ought to have stopped after the first sentence. There is no monetary advantage to opening source or revealing trade secrets: the software industry isn't high school. If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.

As several people have said, the consumer cares about what "just works". They don't care about software ideals, as evidenced by Microsoft's 95% market share. The software industry is inherently capitalistic, and will follow the money. If the consumer wants something that just works, and the F/OSS community isn't going to give it to them, they are going to pay money for it. This is where you will find the software industry: not out trying to "play by the F/OSS rules".

Re:By the way

[MS_is_the_best]

Yep, I agree with you. However about 'the evidence' you want. I just know business, they (actually we), just weigh in the advantages against the disadvantages (usually involves calculation of money).

There is nothing to suggest that by blocking binary-only development, more source will become available. This is a pipe-dream of the F/OSS utopia.
No, it is just common sense. The push on, say Nvidia, to open their source is larger if binary drivers are not possible. Two things are important in this situation, marketshare and large customers. Large customers can perhaps (now under NDA) already get the source, lose of market share (if net loss of opening drivers is smaller than loss of profit by a smaller share in market they will just open of course).

However I tend to agree with you that when all binary drivers are forbidden and the manufacturers are offered a choice, leave the linux market or open their code, much much more will choose the first. That is because the business situation is like this at the moment. But some will not. (for example the NIC company specialized in linux clustering etc.).

If Janie (i.e. ATI) is smoking the marijuana (opens the source to its drivers), it doesn't mean it's okay for Bobby (nVidia) to do the same; it just means Janie (ATI) is foolish.
Companies are sometimes behaving more emotional than factual. For example if some major top 500 companies buy Linux licenses from SCO, a lot will follow. Their bosses will say, 'hey if BMW buys a license we have to do that also, because they have good lawyers'. Without even checking theirselves. This happens a lot (too much).

Re:By the way

[orthogonal]

Nope. This is eating own dogfood, having a stance and keeping it. Businesses can be sure that there's no fucking around rules of linux development. It's either playing by the rules or not playing at all.

Um, whose rules?

If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.

But if by "rules" you mean that the linux developers are making me -- and many others -- bear the costs of the developers' ideological fights, then say so. Explain to me honestly that linux isn't about "choice", it's about forcing anyone who wants to play with linux to license everything under the GPL (or BSD, or release to the public domain).

This is little different that the "anti-spam" campaigners who -- admittedly with virtuous goals -- blacklist email from domains which can't avoid sharing an upstream provider with a spammer. The blacklisters know full well that many of the blacklisted domains have nothing to do with spammers -- and in fact they count on that -- because they hope that by injuring innocent third parties, those third parties will demand that their ISPs stop hosting the spammers (or more often, that their ISPs upstream's upstream will stop hosting a client which sub-leases to another company which hosts a spammer).

The kernel developers apparently hope that we will all now boycott Phillips and companies like Logitech which use the Phillips chip-set, and this in turn will forceforcing Phillips and inconveniencing thousands (millions?) of end-users?

If the GPL such a terrible idea that it can only work when people are forced to use it, maybe it's time to re-think the GPL.

Or maybe the kernel developers cold figure out a more direct avenue of action, that doesn't inconvenience third parties: imagine a GPL that read, "everybody can use linux (and apache, and gcc, and PHP) except Phillips. End-users wouldn't be inconvenienced, but Phillips -- well, I'm guessing they probably use quite a few linux machines for development, and gcc on them, and probably an apache webserver or three.

Now, of course, that's not going to happen, not least because the developers get a real thrill from listing all the companies that use linux, and threatening to take it away from one company would cause a whole lot of companies to reconsider their use of Open Source tools.

But a similar bludgeon is being wielded on the common home and hobbyist end-user here. And that's fine: the kernel developers have every right to write the kernel the way they want, and to use it for political purposes if they so choose. But then don't come to me and tell me linux is about "choice". Be honest, and tell me linux is about pushing an ideological agenda.

Re:By the way

[nathanh]

If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.

It is about choice. You can choose to put the USB hook back and maintain the Philips webcam driver indefinitely in a separate kernel tree. The current kernel developers have the choice to drop that USB hook and tell the Philips webcam guy to find another way. The Philips webcam guy has the choice to reimplement the Philips webcam driver in userspace using libusb. Though as it is, he chose to have a hissy fit. His choice.

The mistake you've made is in thinking that "choice" is equivalent to "kernel developers give you all the options and you just choose a precanned solution from a checklist". That's not how it works. Get off your lazy butt and make things happen. Stop complaining that the kernel developers aren't doing things the way you want them to be done. That's their choice to make, not yours. Exercise your freedom of choice but don't expect others to do the work for you.

Re:By the way

[squiggleslash]

If open source is about choice, I've just lost the choice to use both Phillips-based webcams and linux. Now my choice is one or the other.

Open source is about source code availability and the freedom to use that source code. It has nothing to do with "choice", it's just choice - the right to use something other than what a proprietary software vendor has told you to do - is one of the many, many, benefits.

But if by "rules" you mean that the linux developers are making me -- and many others -- bear the costs of the developers' ideological fights, then say so. Explain to me honestly that linux isn't about "choice", it's about forcing anyone who wants to play with linux to license everything under the GPL (or BSD, or release to the public domain).

Actually, no. If you want the camera driver to be part of the Linux kernel, then, yeah, you have to abide by the GPL both directly and in spirit. If you want to have a camera driver in userland, however, available as an option to the Philips driver writer and specifically rejected for, what I can only see as, ideological reasons, then you're free to do so.

Whatever the case, proprietary software is proprietary. You can't say "The great advantage of Linux is that it's open source!" in one breath and then say "Well, actually, you can't do anything with this camera driver" in the other.

Philips, not the various Linux contributors, has made the decision not to allow the free flow of information about how their devices work. It is Philips who are responsible for this, not the Linux contributors. They are the people who are restricting your freedoms. Address your complaints to them.

Re:By the way

[Enrico Pulatzo]

So you have a choice, be practical and don't use the camera with Linux, or be shackled with the responsibility of maintaining a module across any kernel version you may ever come across.

Ain't freedom grand? As with most things in life, freedom is only available to the elite few that possess enough understanding to be free in the first place. I understand that I'm free to fork the source, but if I lack the knowledge necessary to hack on the kernel what good is it to me to fork?

Re:By the way

[Teogue]

As a developer for a very small company, trying to get our Open Source driver into the 2.4 kernel was a nightmare.

For several reasons, user land was not a viable option. The elitist control freak running the show wouldn't let our code in. Consequently, we lost some good free advertising, and possibly some customers in order to feed the ego of some guy bent on denying anything he thought could go through user land instead.

We ended up just putting the source on our web site. Several customers already use it very successfully. But none the less, we were blocked from contributing while trying to uphold the spirit and ideals of OSS. I can only imagine how much the poor sap from Philips was being jerked around.

That being said, Linux was a stroll through a grassy meadow compared to trying to go through WHQL testing for M$.

Re:By the way

[V. Mole]

There is no monetary advantage to opening source or revealing trade secrets.

Sure there is. I buy only hardware that is supported by open source drivers. Philips, Nvidia, and ATI are in the hardware business. If they want to sell hardware to people like me, they'll have to supply the docs. I'm not asking them to supply drivers, although that would be nice. I'm asking them to make the docs available, so that others can write drivers.

The Philips case is especially absurd. I'm prepared to believe that ATI and Nvidia have stuff in their drivers that gives them a competitive advantage. But some dinky little compressor? Give me a break. I bet it's only proprietary because it's some crappy little algortithm that it would embarass them to release.

"but a major loss for all Linux users."

[Fizzl]

Yes, all Linux users who care about that particular module.

Itt's not like everyone in the world own a Philips USB camera.

Yes, yes. I know what's the point. Making it harder to include binary carbage in the kernel makes it harder to provide modules for proprietary hardware solutions.

But in the long run, do you want to have third party binary carbage in YOUR KERNEL?
No way to check out what's in there. Except perhaps reverse engineering, which isn't an option to everyone. Programming is hard. Reverse engineering is harder.

Re:"but a major loss for all Linux users."

[megalomaniacs4u]

Yes, yes. I know what's the point. Making it harder to include binary carbage in the kernel makes it harder to provide modules for proprietary hardware solutions.

Forward to the past!

Yes, binary only modules are unacceptable in principle. Unfortunately unless you want to head back the days when most hardware wouldn't work under Linux they are a necessary evil.

Of course the zealots who want pure open-source will eventually have to face the fact that some companies will never open-source anything or live in eternal denial.

Re:"but a major loss for all Linux users."

[ColaMan]

The thing is , if you *want* binary third-party carbage in your kernel, well now *you cannot do it at all*
If you don't want third-party binary carbage in your kernel, well, you don't load the module that contains it.

People want their stuff to work. If they need to load a binary module to get their stuff to work, then they'll generally do that, zealots be damned.

Re:"but a major loss for all Linux users."

[psavo]

I think you are missing the point. Not every user cares what is in their kernel, much the same was as Windows users don't. They just want stuff to work.

And you're missing the 'provider' point. If Linux kernel maintainer isn't willing to provide binary module hooks into kernel, then it's his right to refuse having them.

This module could walk around this rule by having same system as nVidia kernel driver, but no, they come to slashdot, bitch and moan.

Re:"but a major loss for all Linux users."

[squiggleslash]

...which it still could. It's a USB camera driver, it doesn't have to be a part of the kernel. Indeed, the guy says it himself:

I've considered the alternative, taking PWC/PWCX out of the kernel and supporting it solely as an add-on module, but rejected it. It would mean a demotion of PWC to a 2nd rank module, and probably quite a bit more work to maintain. Also, PWC would not work out-of-the-box anymore, while it does now. That would be acceptable if it's rarely used module, but that is not the case and it would probably confuse a lot of people.

I find this hilarious. He, and the submitter, have decided to attack the kernel maintainers for being ideological, when actually they're just trying to ensure the kernel remains legal for redistribution (it's licensed under the GPL, after all.) There's a route open to them that allows them to make a restricted product work under Linux, albeit in a slightly restricted way, but they're not taking it because it's horrid and PWC would be demoted to being second rank.

Well diddums! Complain to frickin' Philips then! They're the people being arseholes here by requiring people who want to make their bought, paid-for, hardware work under alternative operating systems sign NDAs. In the meantime, there are alternatives, the authors can still produce tools that will make their cameras "just work", it's going to be harder, but that's the downside of getting a proprietary device.

Re:"but a major loss for all Linux users."

[nathanh]

YOu mean like the firmware required to run the Hauppauge PVR250/350 cards? Or perhaps some of the SCSI drivers which require binary firmware to be downloaded? Hell I even think there are a few network cards which require it, too.

The kernel does support firmware. In fact, there has been significant effort recently to standardise the way that firmware is loaded to hardware by the kernel. The kernel developers don't seem to have a problem with firmware. Their beef is with binary drivers that run in the same address space as the rest of the kernel. I can see the kernel developer's point of view: they don't want to waste their time debugging around binary drivers.

And unless I'm misunderstanding the basic premise behind what's going on here this is likely only the start because, as I've mentioned, there are plenty of cards already supported by the kernel which require non-OSS parts to be part of the driver. What's next?

Hopefuly the nvidia drivers. As much as I like the nvidia company - they have some of the best minds in the business, they are good contributors to the state of the art, they pump significant money into R&D, and they play (mostly) nicely with the standards bodies - their binary drivers are retarding the future of Linux. If the nvidia binary drivers stopped working tomorrow then we'd hear the howls from millions of Linux users, but after the howling stopped there would be some real progress on pushing DRM and Xorg DDX forwards.

Re:"but a major loss for all Linux users."

[tigersha]

Another example here: Wireless LAN cards.

Many (actually, all) of the Wireless LAN cards on Linux require a binary driver. There is a reason for this: A Wireless Lan Card is a radio transmitting device and falls under FCC rules.

The FCC has regulations about not allowing end users to change some of the parameters (which the chipset may allow) and therefore is pretty much ILLEGAL to have a source code driver for these cards because they are regulated devices.

For instance, some of the chips allow you to jack up the power beyond what the FCC allows. Which the binary driver does not, which is why the FCC allows the manufacturer to distribute the thing in the first place.

And the US is liberal in these matters. In Europe rules are usually stricter.

Re:"but a major loss for all Linux users."

[albalbo]

Then people shouldn't buy cards which require proprietary drivers for bizarre reasons; there are plenty which do not.

People should vote with their feet, and the fact is that free software drivers are better in the long run than proprietary drivers. Not withstanding the fact that they are commonly more modern in design and better written, they are also more likely to be portable across architectures. If Linux runs on PowerPC, but all the drivers are proprietary binary x86, well, it kind of makes it pointless.

Re:"but a major loss for all Linux users."

[zenyu]

For instance, some of the chips allow you to jack up the power beyond what the FCC allows. Which the binary driver does not, which is why the FCC allows the manufacturer to distribute the thing in the first place.


Simply not true. You can transmit 1 Watt with 802.11b in the US, but the most powerful cards can only be pumped up to about a 1/4 Watt. What you can do is tune to a different frequency on some of these cards, which is you can't do without a license of some sort from your government. But the thing is you can use channels 1 to 14 on these cards with the binary drivers which means you can break the rules in just about any Western country since each licenses only a subset of those channels. But, you can also install your own antenna which will take you outside the rules.

With WiMax it will be a bigger problem, since you will probably be required to implement a serious power back-off algorithm. But I highly doubt liability would attach to the manufacturer if someone hacked their drivers to go outside the rules, liablity does not seem to attach for semi-standard antenna ports. The real problem is that these companies are licensing not just their firmware but their driver software as well and don't want to put up the $$$ to get a GPL license on that. Kernel devs understand this and just ask for the specs for interacting with the firmware, the manufacturer could have gotten this included for free when they bought the firmware & driver software. But if they didn't they now have to pay more for it. Hopefully they learn their lesson for next time, being able to say you added 5-10% to sales by simply adding a free rider to a licensing agreement gets you kudos at any company (and easy to survey for too, linux&bsd users know which OS they are using.)

Re:"but a major loss for all Linux users."

[Frantactical Fruke]

The binary driver for the Aureal Vortex soundcard stopped working when distributions started using GCC 3 for kernel compiles. What can we do? Nothing. Aureal went bankrupt in 2000.
A binary driver means planned obsolescence for your hardware as soon as the manufacturer loses interest.
Oh, I'm sure you simply dump your machines yearly and get a new one, but those old clunkers are not defective in any way - or wouldn't be, if their driver came with source that we could update. There's your ecological argument for open source.

Annoying for a nice guy

[The Flying Guy]

I met the maintainer once (although he lives relativly close), nice guy, but I kinda think this is just a useless move to annoy him, there are many fully binary only modules out there and he makes the effort to make opensource what he can (NDA) but provides a binary only module (on his own website) to add some more functionality (larger image/higher fps).

Last release ...

[dago]

Sad, really sad. It's a lose-lose situation, and the biggest losers are linux users [who have pwc-based webcams].

Anyway, the last release files can still be found online, backup fast (e.g. gentoo distfiles : pwcx-8.4.tar.gz, usb-pwcx-8.2.2.tar.gz).

Re:"Zealotry"

[DarkDust]

The module was fully GPL compliant but provided a hook where you could attach a binary-only part (this part wasn't necessary for the module to work, it just added more functionality).

So the module was completely GPL compliant but some people thought the hook to be "impure" or something... and removed it. After it has been three years in the kernel tree. The author is right: this is a little late to make a point !

That's zealotry in my book as the module did meet the legal requirements.

Sheesh...

[nathanh]

It is a victory for obsessive kernel-purists but a major loss for all Linux users.

Talk about flagrantly showing your bias. How about we rephrase that last sentence as...

It is a victory for kernel developers who do not have to waste their time with crash dumps from kernels linked to binary modules, for users who benefit from a more stable kernel, and for the advancement of Linux because it is not held back by archaic binary interfaces.

This is only a loss to those silly people who think that their $50 web cam is so damn important that all of the kernel developers should support binary interfaces to cater for undocumented video hardware. The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.

As for this..

So what's going to happen next? Well, I'm pulling the plug completely. I'm cleaning up this website, removing the downloads, documentation, FAQs, etc.

Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.

So what can you do about it? Not much, unless the kernel maintainers ease up a little, and stop being such fundamentalistic turds.

What a wanker.

Re:Sheesh...

[IamTheRealMike]

It is a victory for kernel developers who do not have to waste their time with crash dumps from kernels linked to binary modules, for users who benefit from a more stable kernel, and for the advancement of Linux because it is not held back by archaic binary interfaces

I don't have much sympathy. API versioning isn't rocket science, and it does not doom you to "archaic" interfaces when managed correctly. Compatibility between the major releases (2.4 series, 2.6 series) etc alone would be a major improvement. It can be as simple as introducing a new function instead of changing the prototype of a new one, or introducing padding into the structures.

Unfortunately the kernel developers have this idea that somehow the kernel is exempt from the same rules that govern userspace: if you document and expose interfaces to external code, you keep the interfaces stable.

Quite a lot of armchair coders don't understand backwards compatibility. It does not (necessarily) lead to insecurity or unreliability. I would like to be given examples of occasions where it has, in fact. It does mean managing change, but then this is what maintainership is all about.

The idea that making binary development hard increases the likelyhood of source releases is a fantasy based on an incomplete understanding of the economics involved. The most likely outcome is in fact the discontinuing of the drivers altogether, as has happened here.

The USB hook for binary modules was a real detriment to the USB subsystem. It was taken out for technical reasons.

It was not. Re-read Greg KHs emails. It was taken out because he thought it was a GPL violation (which is a gray area).

Talk about immature. He could leave it there until a new maintainer stepped forward but he'd rather have a dummy spit and stamp his feet.

He has worked for years to produce a solid driver for the community, even signed NDAs to get the relevant specs, and has coded on in the face of ridiculous instability in kernel development. It isn't easy doing such job, yet he did it anyway.

When you have contributed for so long, in the face of such a difficult API to work with, then you may have some authority to say whether his behaviour is "childish" or not. In his position I'd be pretty pissed off as well.

Hell, even Linux userspace has severe problems with keeping stable interfaces. I would hate to be a kernel developer.

Re:Sheesh...

[RustyTaco]

Unfortunately the kernel developers have this idea that somehow the kernel is exempt from the same rules that govern userspace: if you document and expose interfaces to external code, you keep the interfaces stable.

There's the part you're not understanding. Aside from the syscalls which havn't really changed in ages (You can boot the same userland on a 2.2, 2.4, or 2.6 kernel) Linux does not have any "Documented and exposed" interfaces. It's monolithic by design, so anything in kernel space is part of the kernel and uses volitile internal interfaces. It's not what they teach you in CS 101, but that's how it works.

- RustyTaco

Sympathy...and a future workaround

[Spoing]

There are debates like this on the Linux Kernel Mailing List frequently. Should binary modules be supported? If so, within what limits? The concensus seems to be;

• Loading firmware to a target device is OK.
• Loading a binary kernel module taints the kernel;
  • Idealistically: It's not open source!
  • Practically: Defects in that binary module can be debugged but the original source can't be fixed since it's not available -- so it's a waste of time.
  • A big annoyance: One bad module can cause non-obvious problems, so if the kernel is tainted it is entirely suspect.
• Code clean up and improvement will impact the kernel interfaces; changes constantly happen in other kernel structures as well as user space tools.
• The push over time is to place as much under the control of user space tools as possible and as little in kernel modules (within limits).

While the Philips binary seems to be stable, if an exception to it were made other binary modules could be argued for. In fact, that's what is happening now; more and more kernel patches are being made available with binary-only parts.

There are two solutions to this;

• Move the driver to user space and out of the kernel.
• Open the source for the binary part.

Converting USB kernel modules into user space tools happens regularly. Not as easily done as said, and it's less prestigious, though as a technical solution it does solve the kernel dispute.

Not having the source for these devices is silly, though. Do they intend to sell hardware or drivers? By releasing the source or the specs (at a minimum), Philips would gain much and loose little. Someone else can go on a rant to fill in the details...I'm done!

This should really be done in userspace anyway

[Nagus]

The decompression part of this driver is in the kernel. This allows applications to get at the uncompressed (or "decoded") videostream through the v4l (video4linux) programming interface.

That's all fine and dandy, you may think. Not so. Nowadays applications shouldn't use these kernel interfaces at all. They should use media frameworks like GStreamer. If they did, the driver core could remain in the kernel, while the decompressor would be a special video-source plugin for GStreamer that talks to the kernel driver through some private interface.

The decompressor code could remain in userspace, where no one gives a flying fsck about its license. Applications would be more portable, and could use any video source instead of only v4l devices. Plus, it would be much easier to reverse engineer that damn decompressor, put it under the GPL, and be done with it.

Re:How about a compromise ?

[drnlm]

You need to consider a) the GPL statements about derived code and b) the FSF statements about linking and the GPL.

Regarding point a), Linux has a hisotry of allowing binary modules, provided that there is reasonable evidence that they are not derived from the kernel code. This allows things like the andrew filesystem modules and various other binary modules to exist. The tainted flag is to mark them as non-debuggable. The primary module in this case is licensed as GPL, so that's not the issue. It debateable (as we don't have the source), whether the bianry module qualifies as being derived from the kernel or not. If a strong case can be made that it is derived, distributing under a non-GPL license is illegal. Non-one seems to have made this claim, so it is probable that this is not an issue.

b) on the other hand, is very much an issue. The GPL code provides a specialised hook for the binary-only module. It would be pretty difficult to argue that this does not consitute linking under the FSF's definition, and as such, the combined work must be distributable under the GPL. Since this is not the case, there is a licensing problem.

Now, if the binary only module communicated with the GPL'd code via standard interfaces (run as a userspace program, or whatever), the linking issue would not apply. This is not the case.

This is not zealotry. The Linux kernel is GPL. With that, come certain limitations. Especially with accusations (SCO) flying about, being very careful the kernel follows the legal requirements of the GPL is important.

Misguided

[albalbo]

I love the misguided comments in this story. In particular, I like the "most users don't care what is in their kernel, so we shouldn't care that we're taking away freedoms from all (including those who do care)".

Some comments from the guy who actually did this (http://www.uwsg.iu.edu/hypermail/linux/kernel/040 8.3/0270.html):

"Without this hook, PWC will work, but with limitations, just as it always has."
"Actually, I've got a little surprise for you. The NDA I signed with Philips has already expired a year ago. Yet, I didn't just throw the decompressor code on the Internet."

So, just to summarise, a) removing the hook doesn't stop the driver working, b) there isn't really anything stopping him publishing the code as free software. Basically, he just wants to take his ball home because he thinks he should be allowed to put hooks for proprietary modules into the kernel.

Is it the first time he's threatened to do this? No (http://www.uwsg.iu.edu/hypermail/linux/kernel/010 5.3/0365.html):

"Anyway, I am not going to debate this any further at this point. Johannes, please remove my webcam driver from the USB source tree" (May 25, 2001)

Linux doesn't need proprietary drivers, it doesn't need to compromise freedom, and it certainly doesn't need people to try to press the issue by holding code hostage. And, aside from all the facts that this guy is acting an arse, there are also questions over whether or not the hook is legal (Linus' point of view of derivative works of the Linux kernel is quite clear - they must be GPL'd), and the decision to remove the hook was partially a technical one anyway (only one driver is using it).

Yet, we are still going to get people holding this up as an example of the GPL preventing Linux from "going enterprise" or whatever. Guys; shove it - for Linux to be "accepted by business" doesn't mean that developers should bend over for whatever perversion proprietary companies want. Jeesh.

Taking my toys and going home

[Tom7]

So what's going to happen next? Well, I'm pulling the plug completely. I'm cleaning up this website, removing the downloads, documentation, FAQs, etc. I'm discontinuing the webcam@ mailbox, and I'm going to request (well, demand) that PWC will be removed from the kernel tree. I do not want a crippled driver in the kernel with my name attached to it. Last, I'm going to remove the entries in the bugtracker.

It's fine to lose interest due to political reasons and want to stop maintaining it. But this is pretty lame. Demanding that his code be removed from the kernel? (I expect the license will make it impossible to really "demand" that.) Getting rid of all the existing downloads, documentation and FAQs? It sounds more like a tantrum to me.

Reverse engineer it!

[spaceyhackerlady]

Since the Philips webcams work so well (I have half a dozen myself in various applications, most with the 9.0 beta 2 driver), I'm surprised nobody has ever attempted to reverse-engineer the USB traffic and create a completely open, non-tainted-by-NDA decompression module.

It wouldn't be the first time Linux developers had ignored an uncooperative device manufacturer.

...laura

advice requested - a potential loss for LavaRnd

[chongo]

The result of this PWC mess is a loss for the LavaRnd project. We used the Logitech QuickCam 3000 Pro - pwc730 webcam and the Logitech QuickCam 3000 Pro - pwc740 webcam as two of our reference entropy sources because the cameras, when tuned with our code, are an excellent entropy source for generating random numbers.

One ironic twist is that LavaRnd used only the PWC (open source) module. We did NOT use the PWCX (binary-only) module. Our hotplug script did an rmmod of the pwcx module. We discovered that the PWCX module reduced the entropy that the webcams provided. The PWCX module, when loaded, made webcams a poorer entropy source.

LavaRnd used the entropy provided by the actual hardware. Our analysis showed that PWCX was in effect "faking" the larger image sizes by taking, say the true 160x120 pixel CCD output and expanding it to something like 640x480. The expansion was as if a 2D smoothing function (such as a 2D spline?) filled in the pixels in between. Each of the original 160x120 hardware pixels was turned into a 4x4 pixel grid where the edges of the grid were adjusted to fit better with neighboring 4x4 pixel grids. The PWCX appeared to support a higher frame rate because the PWCX module "decompressed" the true hardware pixels and filled in the pseudo-pixels on the other side of the USB wire.

We discovered the PWCX effect while taking entropy measurements of webcam frames. Using PWC alone in 160x120 mode, the webcam produced slightly more entropy than 640x480 PWCX mode. The PWCX module was not adding real image data to webcam frames, it was just smoothing and filling in data that looked good enough to a human. However, PWCX could not fool the math ... :-)

The PWC maintainer says on his web site:

" and I'm going to request (well, demand) that PWC will be removed from the kernel tree.''

The PWC maintainer's position appears to be that if you cannot use PWCX, then PWC is worthless. From LavaRnd's point of view, PWCX (the binary only module) adds no value and in some ways reduces the Logitech QuickCam's value as an entropy source.

We (LavaRnd) do not want to take sides in this PWC/PWCX kernel dispute. If this posting appears that way, then we apologize. The PWC folks have been mostly patient with our unusual use of their webcam modules. The Linux kernel folks have provided us with a wonderful platform for LavaRnd. As for ourselves, we put a lot of time into helping end users use the PWC module in older kernels.

Here is our advice request:

The LavaRnd project would like to see the PWC (open source) module remain in the Linux Kernel. We would like the Linux kernel folk to not honor the maintainer's request to remove everything. We want the support of PWC without PWCX to continue in the Linux Kernel. What is the best was to make this position / request known to the key Kernel people in the hopes they will PWC as part of Linux?

And does every chunk of the Linux Kernel need an active maintainer? Could PWC remain in the Linux Kernel without the original maintainer's support or would someone such as ourselves need to step up and offer to maintain it?

Re:advice requested - a potential loss for LavaRnd

[chongo]

We know that the 640x480 bits are not real bits from the hardware. Perhaps the 640x480 rate is due to the CPU time needed to fill in the in between pixels?

Try this experiment: Take a 640x480 picture of a grid such as graph paper ... lines on a plain color background. Enlarge the image until pixels are squares that you an clearly see. Notice the 4x4 pixel blocking. Notice how each 4x4 pixel block looks like a plane tilted in color space.

Now try the same for a 320x240 image. And notice the 2x2 pixel blocking.

Now try the same for a 160x120 image.

Re:advice requested - a potential loss for LavaRnd

[chongo]

Sorry, we do not have a system that runs windows. Also PWC/PWCX only runs under Linux. :-)

Our Logitech QuickCam 3000 Pro CCD only has a 160x120 pixel grid. While this closeup image of the chip is a bit small to count by, under higher magnification you can see the individual sensors and count them. They do not have 640x480 pixel array on our chip. We counted 160x120 instead.

One can do the math. At 30 fps with 640x480 pixels, using the YUV 4:2:0 Planar palette, (encodes at 1.5 bytes per pixel) you have:

640*480*1.5 octets*30/sec = 13824000 octets/sec

You cannot shove data down a USB1.1 pipe at that rate. Something has to fill in the extra data (between the 160x120 pixel grid and the frame buffer of an application) as it cannot be sent over a USB 1.1 wire and keep up.

If you examine under high magnifaction (where pixels are a few mm in size), you can see the 4x4 chunking that PWCX performs.

Maybe windows has the Philips decompressor builtin by default?

Re:advice requested - a potential loss for LavaRnd

[0x0d0a]

Post to LKML. This is probably the "official way", and even if not, they'll definitely tell you the right thing to do.

Also helpful is #kernelnewbies on Freenode, where a bunch of kernel hackers hang out, but it sounds like this doesn't require low-latency interaction.

I would like to thank you for stepping up. All of us Linux users benefit (I, have been batting around the idea of playing around with some image recognition and processing ideas on Linux, and this would allow me to continue to do so).

I'd like to point out that there is userspace software (GPLed) to do superresolution processing that may be able to provide PWXC-like functionality, but still keep the kernel hackers happy.

I would like to see the PWC/PWXC guy reconsider abandoning ownership (and all the nice work he did) -- he probably did what he did in a fit of frusteration with the other kernel hackers, but if he becomes willing to allow PWC to just pass its data through some userspace software, this might not hurt end users (and if the userspace software is better, might even be a win).