login
Search
A recent disagreement on the linux-usb-devel mailing list ultimately led to the removal of the Philips webcam driver known as 'pwc'. The driver contains two modules, an open source module that has long been part of the mainline Linux kernel, and a closed source module which ships separately. Craig Rogers explained on the lkml that the closed source module ships in object format and "provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family." A hook in the open-source module allows the compression module to register with the kernel.
The actual disagreement was from the removal of this hook which was only used by the closed source module. Greg KH explained, "see
Linus's comments about 'if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource' or something close to that." In response, the pwc maintainer requested that his GPL'd code be removed from the kernel, explaining why here in his own words. Greg KH offers his own explanation here.
Separate from the above debate around the removal of the hook, following the request for the driver's removal by its author it was pointed out that the driver is GPL'd, so the source code should legally be able to stay in the kernel regarldess of its author's requests. Linux creator Linus Torvalds replied, "yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes. Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine. I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law."
From: Craig Milo Rogers [email blocked] To: Linus Torvalds [email blocked] Subject: Termination of the Philips Webcam Driver (pwc) Date: Thu, 26 Aug 2004 16:32:53 -0700 As a third party, I issue a plea for mediation. Over on the linux-usb-devel mailing list, a spat has arisin between the Linux 2.6 USB maintainer, Greg K-H, and Nemosoft, the author of the driver (drivers/usb/media/pwc*) for certain Philips-based Web cameras. As a result, Nemosoft has asked that his driver be removed from the Linux 2.6 kernel. The driver is structured as two modules: an open-source module, included in the standard Linux kernel for years, which controls the basic operations of the camera chip, and a closed-source module, distributed in object format independently of the Linux kernel, that provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family. A hook in the open-source driver allows decompression modules (codec modules) (which may, after all, be either open source or proprietary) to register with the main driver. Citing the fact that the only current use of the hook was to register a non-open-source module, and citing a policy statement by Linux Torvalds (see the discussion on the linux-usb-devel archive for details), Greg K-H removed the hook from Nemosoft's in-kernel driver, and Nemosoft withdrew his driver from Linux. As a not uninterested bystander (I just invested $200 of my personal money in Logitech web cameras on the strength of the pwc driver, based on Web research only two days old now!), I appeal for higher-level arbitration in this issue. I, personally, would prefer a pure open-source kernel, and in fact, Nemosoft posted that he has at this time the opportunity to discuss with Philips the possibility of open-sourcing the codecs involved. However, Greg K-H's unilateral decision to excise the pwc codec hook has so infuriated Nemosoft that, unless another maintainer for this driver steps forth, we may be left with no Linux support at all for this popular family of web cameras. Craig Milo Rogers
From: Christoph Hellwig [email blocked] Subject: Re: Termination of the Philips Webcam Driver (pwc) Date: Fri, 27 Aug 2004 00:47:57 +0100 On Thu, Aug 26, 2004 at 04:32:53PM -0700, Craig Milo Rogers wrote: > As a third party, I issue a plea for mediation. > > Over on the linux-usb-devel mailing list, a spat has arisin > between the Linux 2.6 USB maintainer, Greg K-H, and Nemosoft, the > author of the driver (drivers/usb/media/pwc*) for certain > Philips-based Web cameras. As a result, Nemosoft has asked that his > driver be removed from the Linux 2.6 kernel. It's not up to him to decide. He can step down from his maintainership, but he can't force the driver to be removed.
From: Linus Torvalds [email blocked] Subject: Re: Termination of the Philips Webcam Driver (pwc) Date: Thu, 26 Aug 2004 17:03:42 -0700 (PDT) On Fri, 27 Aug 2004, Christoph Hellwig wrote: > > It's not up to him to decide. He can step down from his maintainership, > but he can't force the driver to be removed. Yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes. Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine. I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law. Linus
From: Christoph Hellwig [email blocked] Subject: Re: Termination of the Philips Webcam Driver (pwc) Date: Fri, 27 Aug 2004 09:43:46 +0100 On Thu, Aug 26, 2004 at 05:03:42PM -0700, Linus Torvalds wrote: > Of course if some new maintainer shows up and decides to infer how the > device worked by looking at the original open-source code, that's also > clearly fine. > > I don't want people to play lawyer. Honoring peoples rights to the code > they write is more important than just the law. Umm, just because he's piised off we shouldn't removed support for hardware. it's not like the driver suddenly stops from working because it's unmaintained.
From: Craig Milo Rogers [email blocked] Subject: Re: Termination of the Philips Webcam Driver (pwc) Date: Fri, 27 Aug 2004 02:48:09 -0700 On 04.08.27, Christoph Hellwig wrote: > On Thu, Aug 26, 2004 at 05:03:42PM -0700, Linus Torvalds wrote: > > Of course if some new maintainer shows up and decides to infer how the > > device worked by looking at the original open-source code, that's also > > clearly fine. > > > > I don't want people to play lawyer. Honoring peoples rights to the code > > they write is more important than just the law. > > Umm, just because he's piised off we shouldn't removed support for hardware. > it's not like the driver suddenly stops from working because it's unmaintained. Bit rot does occur in unmaintained Linux kernel drivers; I believe I've seen it happen. More immediately, though, is that the driver suddenly stops working (in effect) for new users who can no acquire a copy of the proprietary codec module, pwcx. Without pcwx, my brand new Logitech Web cameras are likely to be seriously crippled. I didn't get a copy of pcwx before the website that distributed it shut off access. I'm seriously considering offering Nemosoft money for a licence for pwcx. Of course, I'd need seperate copies for x86 and x86_64 architectures... Economic rationality rears its ugly head: the overhead costs might be too high. Craig Milo Rogers
From: Greg KH [email blocked] To: linux-kernel, [email blocked] Subject: Summarizing the PWC driver questions/answers Date: Fri, 27 Aug 2004 09:26:13 -0700 So, I've gotten a lot of emails about this topic, so I'll just answer them all here in public, and point people at them when they ask them again: First off, here's Nemosoft's big post about the driver, please read that first, and the responses to that thread: http://thread.gmane.org/gmane.linux.usb.devel/26310 And here's Linus's response after I removed the driver, when Nemosoft asked me to: http://thread.gmane.org/gmane.linux.kernel/229968 Oh, and there's now a lwn.net thread too: http://lwn.net/Articles/99615/ Ok, on to the questions: Q: Why did you remove the hook from the pwc driver? A: It was there for the explicit purpose to support a binary only module. That goes against the kernel's documented procedures, so I had to take it out. Q: That hook had been in there for years! Why did you suddenly decide to remove it now? A: I was really not aware of the hook, and the fact that it was only good for a binary module to use. I'm sorry, I should have realized this years ago, but I didn't. Recently someone pointed this hook out to me, and the fact that it really didn't belong in there due to the kernel's policy of such hooks. So, once I became aware of it, I had no choice but to remove it. Q: Why did you delete the whole pwc driver from the tree? A: That is what the original author (Nemosoft) wanted to happen. It was his request, and I honored it. Go ask him why he wanted it out if you are upset about this, I merely accepted his decision as he was the current maintainer and author of the code. Q: But you took away my freedom! Isn't Linux about freedom? A: Again, it was Nemosoft's decision. The kernel also has to abide by it's documented procedures, so that is why the hook had to go. Remember, the original driver was released under the GPL, so you are free to take that code and maintain it if you so desire. I'd gladly support someone taking the GPL code and agreeing to maintain it, and resubmitting it for inclusion in the main kernel tree. That's the freedom that Linux provides, no closed source OS would allow you to do that, if a company pulled support for a product (which happens all the time.) Q: You jerk, I had invested lots of money in this camera, you are costing me money by ripping it out. You should be ashamed of yourself! A: See the above question about freedom. If it means that much to you, then offer to maintain the code, it's that simple. Q: You are keeping companies from wanting to write binary drivers for Linux. A: Duh! What do you think all of the kernel developers have been stating for years, in public. Binary drivers only take from Linux, they do not give back anything. See Andrew Morton's OLS 2004 keynote address for more information and background on this topic. Q: You are a fundamentalist turd / jerk / pompous ass / GNU-freebeer-biased-idiot-fundamentalist fucktard / ignorant slut! A: I've been called worse by better people, get over yourself.
Thanks for reporting on this
Thanks for reporting on this with the several existing views, while providing links to the discussion, as done normally at Kerneltrap.org. This reflect objectivity from the editors. At least one other website (OSnews.com) failed to do this and posted a rant about open-source software being anti-user, or something like that.
Some interesting aspects
* It has been suggested in the discussion the author uses an Nvidia-like wrapper instead of the current hooks. The author has not argumented why he doesn't want to do this.
* The NDA has expired for a year which according to some gives green light to releasing the code as GPL, allowing it to be included in the main tree. The author refused to do so, because he says the writing of the driver was based on trust besides the NDA. However, he has not asked Philips if the code may be released as GPL, argumenting the NDA is expired.
I hope the problem will be resolved, and i hope the above will be taken into account after emotions got calmed down.
Best regards,
dpi
osnews.com
osnews.com seems to attract rants like dogs attract fleas. BTW, the technical level of their articles is low. I stopped reading that website.
Oh wait, this comment itself is a rant. :-) Oh well...
well, first of all, i'm upset
well, first of all, i'm upset because we're not talking about some abstract piece of hardware, we're talking about a webcam i use. not much, admittedly, but i do. removing pwc support from the kernel means that i now have one (!) reason for using windows. i don't want to. i also don't really see any point in buying a different webcam because this one worked just fine...
while i'm pretty much one of those people that prefer using 'free software' over 'open source', i really don't see the point of removing that hook. not at all. i completely agree with the points the author raises.
still, if as the above post says there _are_ other ways to continue supporting pwc in the kernel, i'd also be happy to know why the author chooses not to.
i'd be _really_ happy if the pwcx module could be included in the kernel source.
NDA expired?
Can you post a reference to where you got this information?
Source
http://marc.theaimsgroup.com/?l=linux-kernel&m=109348215128054&w=2
Nemosoft writes: 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. First, there could still be legal remedies since the cams are still in production to this very day. Second, that NDA was signed on a basis of trust and I do not want to lose that trust. I'm looking at the bigger picture here: if we (Linux developers) can show we are trustworthy, we may be able to get better support from hardware manufacturers now and in the future (and really, that's what the kernel is for 75% about ....) I'm still in contact with Philips and who knows, maybe we can get all the source opened up...
Hardware vendors! blow off Linux users at your peril...
I purchased Philips hardware after researching the availability of drivers for Linux. Philips only got the revenue because the driver existed.
What the Philips product-management-decision-makers must understand is that not only have I made a personal choice to work only with Linux, never again with Microsoft, but in my professional life, I make technology investment decisions on a very large scale. Hence, my personal experiences highly influence my professional decisions. Don't assume that behaviour with respect to a consumer does not impact enterprise-wide business. Do you hear me, hardware vendors?
This would all be much simpler should Philips open-source the required code. Object-code-only is really a weak IP-protection tool. It's about as sound as security through obfuscation. OCO impedes but does not prevent.
My guess is that Philips has a deal with a 3rd party codec provider that locks it into a closed source position. If this is the case, perhaps Philips can release hardware details to the open-source community facilitating development of open-source codecs. Or, better yet, release a product that is not encumbered.
Ah.. dpi, we meet again.
Well this will be my last comment on this matter. I've commented extensively on the OSNews story.
I believe that nemosoft did explain why he didn't want to rewrite his module to be an NVidia-like wrapper. It is simply a matter of taking a lot of time and effort just to work around an imposed change by the kernel devs. A lot of work for no good technical reason, and after 4 years of jumping through similar hoops, he is probably just sick of the whole thing.
Nemosoft did not say he hasn't asked Phillips if he can release the code. I suspect he did ask and they denied his request. Legally he can probably release it in spite of that, but as he says, he does not want to sacrifice the trust between himself and phillips nor poison their working relationship.
On the removal of the pwc code. I think it could have stayed, but it doesn't make much difference. Without pwcx, the webcam resolution is limited to 160x120 which is basically useless anyway. So I don't fault Nemosoft for taking the whole thing out.
What this comes down to is that support for a popular piece of hardware was removed for no good reason. The technical argument is weak (there was no CHANGE to support a binary module, rather a lack of change). The legal argument is also not definite. As linus said, unless a lawyer steps forward to clarify this, we can't be sure.
All I can say - drop such style of attitude - from both sides
It WON'T help Linux to grasp wide spread addaptation if such things will happen. Philip chipset Webcams are VERY popular so it is quite damaging NOT to have driver for them, period.
Most Linux developers aren't
Most Linux developers aren't concerned with world domination and having binary-only drivers is damaging as well and they choose the course of action that they fell is best technologically. I make an exception on my machines with the nVidia driver because the chances of getting a good, open source driver that does 3D and everything are slim to none, but given a choice I would always choose the open source drivers.
I've not been bit by this instance since I have no webcams, but I have/will with other drivers. For instance the QLogic SCSI driver has firmware embedded in a header file and since the firmware is just a binary blob in a header file Debian will probably be removing it after Sarge ships. It sucks and I would rather use the card but I'll be replacing it with an Adaptec card that has open source drivers.
Firmware drivers
Modern hardware design is very often based on a programmable logic device.
You first ship the board with a ROM on the specific hardware, and this is alright, since the driver does not contain any hardware configuration data, it is all hidden in the on board ROM.
When you then find a bug in your hardware and ship a driver with hardware configuration data, this is driver is flawed because of an extension of the source code license, I can't understand this!
Even if you had all the design data for this particular driver, do you know how much the closed source software that generates the bitstream cost? Too much for many small companies. Then setting up the bitstream generation environment is also a considerable task.
Which driver should we use, the one that has a flaw in the hardware or the one that has a flaw in the license?
I beleive we have to develop our hardware ourself, to get i truly opensource.
Linux is after all a personal software project
Linux has become a frankenstein, with its developers having their own set of ideas, which they should rightly have, and users requiring something different, and top vendors like Redhat trying make some money by pitting it against Windows, MAC, et all.
Also, the hardware manufacturers have been ahead of their competetors by having some secret mechanism in the hardware to better performance. And the drivers for these devices might reveal their secret sauce. Thus they dont want to release the source codes for the drivers.
And in all these fiasco, we the users, who, according a thread below, are rarely right, are caught off-gaurd. We either have to choose between a "good OS", a costly OS, and our favourite hardware.
But then the kernel-developers are not the one asking us to use Linux.
So we the users can never be judgemental about what they are doing is right or wrong.
It is after all their personal software project.
Period.
Good Policy.
This is the best policy for opensource to have: Talk and work together on all things. Not lawyers and lawsuits.
About linus comment
Linus says that if a kernel change is required to make a closed-source module work, then it's the module that need to change not the kernel.
AFAIK, no kernel change was required since the module had been there for 3 years. So the change has been made so that the binary module doesn't work anymore. That seems to me a bit of a far fetched way to comply.
And where does that leave us in terms of webcam support by the way ?
Ask Philips politely to make full open-source driver
Ask Philips politely to make full open-source driver.
Click here.
done
thanks.
No, that is not the right way
No, that is not the right way. The person on that address can tell you that your VIA/SIS/ALI chipset needs an updated driver under Windows, and why sound in MSN does not work, but he has no way of escalating requests like that to someone that has any influence. Please send a fax or a good old fashioned letter directly to Philips Eindhoven instead.
Customer rights
As a customer I have the right to respond to their normal customer
care channels.
Therefore, the above URL is ok.
If they do not get it, I'll continue to keep banging politely their door
at the above mentioned URL, until my customer rights are met.
BTW, it's good to pass the message that Linux users have buying power,
either individually or influencing through procurements.
A change was required
AFAIK, no kernel change was required since the module had been there for 3 years.
A change was required, it was just done 3 years ago and no one noticed till now.
Yup! Please get the hook back to kernel!!!
Please try to reconcilliate with each other and try to get the PWCX module back to the kernel at all cost. Forget both of your stupidities and the users are always right.
Please work it out.
Thanks a lot.
Whoops, wrong thread.
Whoops, wrong thread.
Sadly, users are rarely right
Sadly, users are rarely right and even less so when it comes to techincal matters.
Reminiscent of XFree
Linus has good sense, so I'm not worried about Linux dying, but this approach is exactly analagous to what made XFree completely irrelevant.
Far off. * XFree86 changed
Far off.
* XFree86 changed its license; Linux did not. There was no license change. Hopefully there will one in regard to PWCX though!
* First impact of XFree86 was the whole license changed; in Linux there is no license change. Later, after solutions were announced (X.Org...) Dawes reconsidered and made an exception for xlibx.
* The change of XFree86 license, had it been succesful, would create a huge bureaucracy of who wrote what.
* The change also rendered GPL applications linked to the xlibs useless, such as kdelibs, although after Dawes his repositioning this was not true anymore. By that time, the community already opted for X.Org though.
* The impact of some webcam is much less high than the change of XFree86, had they not changed their xlib license while X.Org did not forked, ie. when it still was in wide use.
* There is no indication this leads to a fork of Linux.
* The decision here was made by 2 people: Greg KH and Nemosoft; the decision of XFree86 was only made by David Dawes.
Taking the above into account this is quite a bad analogy and the wether it'll have the same impact is yet to be seen. In my opinion, what you think seems to be some kind of doom thinking whereas the discussion is still going on.
I was thinking of earlier
I wasn't thinking of the licensing change, actually. That was just the straw that finally broke the XFree camel's back. Rather I was thinking of the haughty license and contribution Xfree inner circle that drove off developers (namely the folks that started kdrive, xorg, etc). There's no good reason to fork linux with Linus in charge, but it sounds like their may be good reason to fork the USB subsystem. It looks like you could get webcams back with just that one simple step. :/
1 driver being removed is not
1 driver being removed is not even close the a project changing the license that everything they release is under.
Trust in Linux
Well, all this story will damage the trust people is starting to have in linux.
If just the change of humor of a developer can remove the support of a piece of harware, how can people think Linux is a serious thing ?
What feature could be the next one to be removed, just because a developer is sick & tired ?
Could someone base his work on a software that works in this way ?
I think Linus should reconsider and put the support for Philips webcam back again in the kernel.
No, no one can expect to work
No, no one can expect to work like this. That's why Linus and USB maintainer are correct, no exceptions for binary only modules. It looks like the webcam driver developer is trying to secure some prestige by locking his code in a way that nobody else but him can control, so that when people don't want to play by his rules he can take his ball away.
He managed to put a hook in the kernel source 3 years ago, it's sad that only now someone noticed but, it's correct to take it out, or he produces (full) GPL code or he goes by the rules of binary only modules.
From what i read, he seams to wants this kind of fame.
Lets wait for philips to provide that information for someone else produce a fully GPL module or, if not possible, a fully binary module without confusions. If philips doesn't care to the point of not even providing information under NDA for a binary only driver, then it's time to sell whatever cam you have and buy one that's suported.
There was no change of 'humor
There was no change of 'humor', this was just the case of a policy violation being found and removed.
What feature could be the next one to be removed, just because a developer is sick & tired ?
Depends, if enough developers feel it's not worth maintaining and noone screams it'll get removed. You did see the devfs threads didn't you?
Unlikely
There was no change of 'humor', this was just the case of a policy violation being found and removed.
Highly unlikely. AFAIK all patches applied to Linus tree have always been closely examined. It is rather clear that this is is due to change of humor. The issue was known for a long time and referred to in Slashdot earlier and commented on by a kernel developer. The issue has been known for a long time and is by no means unique. The reasons as to why the driver was effectively destroyed by removing the hook were dubious at the least - the driver only contains GPL'd code and it is the user's decision to link the separately distributed closed-source module to it.
Note this: with the same reasoning the kernel module loader should be removed because it allows for loading non-GPL'd modules while being completely GPL'd by itself.
3 years in the kernel, close cooperation and countless hours of work resulting in being promptly destroyed all of a sudden... frankly, the maintainer's reaction to the driver being ruined was to be expected. If they don't appreciate what he's doing, they may as well be without his contribution at all and get the blame.
Well, now someone else needs to code and start maintaining a Philips webcam driver - the demand is too large to be ignored. No idea who'd want to do that after seeing how a several years' work may get destroyed on a whim of a kernel maintainer. No matter how unpleasant it is, it is a utopy to think that proprietary code could be opened just like that. A lot of drivers should be removed from the kernel with the same argumentation as the one used in this case.
Not quite...
Note this: with the same reasoning the kernel module loader should be removed because it allows for loading non-GPL'd modules while being completely GPL'd by itself.
Not quite right - an important difference is that, to use a strangely familiar phrase, the kernel module loader also has "substantial non-infringing uses". That is, it's primarily used to load other GPL'd modules. The fact that it CAN also be used to load binary-only modules is incidental.
On the other hand, the Philips(r) webcam hook that was removed was apparently only used to enable use of proprietary binary modules, contrary to kernel development policy. Since it did not have "substantial non-infringing use", it was removed.
Personally, I think a simple "grandfathering in" statement and leaving the code in for now would have been a better approach (while the statement would make clear that the exception was being made only because it hadn't previously been caught, and no further exceptions would be made), but I can understand why the code was removed.
3 years in the kernel, close
3 years in the kernel, close cooperation and countless hours of work resulting in being promptly destroyed all of a sudden...
By who? The author of PWCX still had 2 viable options: release the code under the GPL or use the NVidia-like way everyone does. Why give him a special threatment? He diced to stop development of the PWCX and PWC, not someone else. This while he could have considered the other 2 viable options.
frankly, the maintainer's reaction to the driver being ruined was to be expected.
Why? He could have known this would happen sooner or later. Why didn't he consider the other alternatives?
If they don't appreciate what he's doing, they may as well be without his contribution at all and get the blame.
Nobody of the kernel maintainers said "i don't appreciate what you're doing". They just said: "these are the obvious rules and you need to abide these". Without rules and consistency, development will be a mess anyone who has ever developed software knows this.
Nothing but bad attitude
What sickens me most about this is the antagonistic attitudes that are being struck. I've seen no evidence that the maintainers attempted to talk to Nemosoft about whether changes could be made, given time to implement them. I've seen no definitive statement as to whether Nemosoft was continuing to attempt to persudae Philips to allow an open source driver, although that may be implied in his statement that he is still engaged in dialogue with them.
As far as I can see the whole thing has been handled in the most childish manner.
Anne
YES!
Exactly. Greg should have told nemosoft that because of policy, he believes he has to remove the hook but he won't do it for a couple months to give Nemosoft some time to change the driver.
Instead greg said that he will "rip" it out immediately and send it out in the next patches. I find that incredibly rude. Best case scenario, with nemosoft getting to work rewriting the driver loading, his driver would still be broken for a few kernel revisions.
What the hell is the sudden rush? I think Greg's arrogant attitude was partly what drove nemosoft to react as he did.
Vice versa
What you write also counts for the other side. If one side did something impulsive without discussing it with the other one does not mean you should make that same mistake. Just because one murders another does not justify you to murder that other (gang wars...).
AFAIK all patches applied to
AFAIK all patches applied to Linus tree have always been closely examined
Depends. This was probably submitted to Linus via Greg and there's no telling whether or not he read and understood the code 100% at the time of submition and when he said "this is OK for inclusion" Linus probably either just trusted him or did the same thing he did, scanned over it and went back to work on seemingly more important things. Any time people are involved there's a large chance of error, you can't get around that.
The issue has been known for a long time and is by no means unique
Well then we'll probably have some other drivers beeing evalutated in the future. As I said in another post, I know the QLogic ISP driver will most likely be removed from the Debian tree after the Sarge release because it contains firmware in one of the header files. It sucks because I have one of those cards but I understand the reasoning and have already acquired a replacement, although the new card may require some extra work since I don't think it's supported by SRM.
3 years in the kernel, close cooperation and countless hours of work resulting in being promptly destroyed all of a sudden... frankly, the maintainer's reaction to the driver being ruined was to be expected. If they don't appreciate what he's doing, they may as well be without his contribution at all and get the blame.
He chose to destroy the work not anyone on LKML, the driver could have stayed and worked just fine without the binary loader. AFAIK the loader was just for some proprietary codecs which I don't believe are necessary in all cases.
Well, now someone else needs to code and start maintaining a Philips webcam driver - the demand is too large to be ignored.
Not really, the current driver works fine. If he's too bullheaded to let it stay in someone can just take it and write a new one based off of his old code, the time killer will be implementing the codecs if someone actually wants to do that.
A lot of drivers should be removed from the kernel with the same argumentation as the one used in this case.
Name some, maybe we can pull a debian-legal here and cleanup the kernel.
The binary jihad
He chose to destroy the work not anyone on LKML, the driver could have stayed and worked just fine without the binary loader. AFAIK the loader was just for some proprietary codecs which I don't believe are necessary in all cases. Name some, maybe we can pull a debian-legal here and cleanup the kernel.
What's with the vengeance in taking out useful drivers?
I absolutely do not comprehend this jihad against some of the popular drivers just because they are not 100% pure.
The proprietary module was essential
AFAIK the loader was just for some proprietary codecs which I don't believe are necessary in all cases.
Excuse me? I doubt you've read enough about this. The driver is crippled and almost useless without support for the separately distributed module. Only resolutions up to 160x120 or so (and maybe some other more or less important features) are supported without the decompression module. Yes, the webcam can be used without support for the proprietary module but... come on. It is practically essential to download the proprietary module and load it in order to use the webcam properly.
So now you'll have to downloa
So now you'll have to download both parts seperately, big whoop.
Er, the licenses of proprieta
Er, the licenses of proprietary software do the same thing, where a "change of humor of a developer" can remove all your rights, yet people take proprietary software seriously every day.
At least with free software one could go grab a copy of the old version, use it, and pay someone new to maintain it.
what are you talking about?
listen, i'm not a dev of myself.especially of the linux kernel. I do have problems with my linux distro too, and a major one. I use a laptop which has broken PCI bus, optimized for WinXP. I'm very fond of linux so i tried to install it, but i failed: only kernels up to 2.2.26 can function with my broken bus.
What should i do? Yell to kernel developers and tell them to re-develop the pci sub-system?
Nope, the point is that, since companies don't allow the devs to know the internals of their hardware then why should their products work with linux?
It's all about freedom really. You are supposed to use linux because you don't know what lies under binary format. You want to know what the program does and how it does it. That's why linux has the reputation of a secure and trustworthy system.
The tendency of some distros to change into rpms (or other binary format) doesn't make linux better but worse. If you want binaries to work with, then use microsoft's products. Simple enough.
Linux started as a free development with volunteers from the whole world. Some (if not everyone) of them are still developing with this principle in their minds. Who are you (you=anyone) to demand support? Who gave you that right? Remember, you do not refer to companies, you don't buy linux, you just download it. Simple enough. Don't have demands though.
If you want to use the god-damn-camera then write a module of your own.I still have many problems with my linux distro. I do have difficulties in making it work everytime. And i'm not a dev. So? I still work on linux.If i want something pretty bad, then i'll sit and write a module on my own.Not that i have managed to succeed in it till now. But, that's life!!
So, conclusion: wanna something done? do it on your own. Don't demand. Noone owes you. you can't follow the procedures you may have followed if you bought a product from a company. Ask politely. If it is done then OK.if not then accept it. And if the major devs decide something cope with it. It's their product, their effort, their time spent. You don't agree? That's fine. Give it a try to write code. Find out how difficult it is. Don't wanna? OK...Microsoft is still a solution...
Finally, no i don't think that support for Philips should continue.
Four reasons:
a) Security. If someone breaks into the dev's machine , or even my own, and changes the bins with a trojan, how will i be able to know about it? tripwire? come on!!
b) a web cam is not something important for working in linux. it's something that *is* luxury. If you want luxury and all the things that go with it, go windows go!!
c) what if phillips decides to charge for the module? It's binary and you can't do anything about it...
d) if someone wants a hook in the kernel which enables binary execution, he is free to code his own kernel branch-binary-hook-enabled. The rest of us don't want and need to have one. It's more difficult for me to exclude every time the module from my kernel than you to insert it (nope? i believe it has the same difficulties.) why to have it your way and not mine?
Don't demand.
Be gratefull for having already what you have.
Nemosoft is being childish
If Greg KH wasn't aware of the special hook for the binary driver, that is understandable. Regrettable, but understandable. Now that he knows about it, he has no choice but to remove it. But Nemosoft certainly knew that his driver was not conforming to the kernel guidelines. He knew that all along. He did not play by the rules and was not loyal to the Linux developers and community. He should have adopted a different technical solution for his driver or he should never have included his driver in the kernel tree.
I think Nemosoft is being childish. Why does he expect special treatment for his binary driver from the kernel developers? Why doesn't he accept the rules for driver development? Why doesn't (didn't) he release it as a separate module? I that it is Nemosoft that is doing a disservice to the Linux community, not the kernel developers.
If you allow one hook for a particular binary driver, then you have to open the door to every other author that requests a hook for their ultra cool and super needed binary driver for that must have piece of hardware. It is not acceptable.
Exactly
He talks about "sacrifice of the trust between himself and Phillips nor poison their working relationship". What about the reverse? The trust of the community of kernel developers and their stated working position?
Linux position on binary modules has been clear for a very long time.
Mistakes happen, and maybe Grey was aware or not aware of the situation. Certainly when someone pointed it out to him, he was forced to act.
Undoubtable Nemosoft was aware he wasn't playing fair with the rules of kernel development. So he choice to try keep his 15 mintues of fame and is working relationship with Philips.
Off-topic legal stuff
The legal problem isn't that the binary driver part is derived from the Linux kernel or something like that, but rather that a piece of the Linux kernel (the opensource part of the driver) is derived from the closed source driver part. And that's not allowed by the GPL.
Nemosoft ate my GPL
this guy and joerg must be closely related.
This was the right thing to do, good job Greg. For everyone else,
the world is not ending (least I don't think) because of the current loss of the driver.
If you don't like what was done, shut up and go use some other kernel..the guidelines should not be broken. If you don't like that then open your editor and start coding, this is the way things work in this neck of the woods.
If this driver wasn't slipped in under the radar in the first place (yes sneaky and disrespectful), we wouldn't be here arguing this silly ordeal today. If you want to point fingers, point them at the people who didn't initially follow the rules and not the hands that guide our kernel.
And a closing note, and quoting as linus mentioned.
"Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine."
please note the clear cut hint that IF YOU WANT THE DRIVER (YOU meaning anyone, yes thats right ANYONE) CAN GET OFF THEIR ASS AND DO IT.
If you don't like what was do
And this is why Linux will never take off for non-techs and power users on the desktop.
And surprise...
...it is NOT a target of Linux kernel developers, but it IS target of distributors and vendors like RedHat, SUSE, Mandrake, etc.
Kernel should keep clean and legaly perfect, period. Distros can add stuff later. Enough said.
Userspace Drivers
Userspace drivers have been shown to have almost equivalent performance to their in-kernel counterparts. Why can't we have infrastructure setup to support userspace drivers? This removes the grey legal issues surrounding binary kernel modules, and for cases like PWC it would be ideal: just do the decompressing/codec stuff in userspace.
I've read reports that even IDE drivers in userspace have run well. Sometimes we just want our hardware to work. 99% Free (Linux + 1 or 2 binary modules) is better than 100% Non-Free (Running windows just so your hardware works).
Archives of the drivers
You can grab the latest Philips drivers from http://projects.raphnet.net/
Thanks :)
Big thanks for saving files from void - at least it will work for some months - I'm not upgrading my kernel so often, so neither my clients.
As for dispute - after rather long thinking about it I think author of driver played a little bit too arogant and self-important and he actually caused flame war, not remover of the hook - as many pointed out, author new that there WILL BE a problems, but he done NOTHING to prevent it. He done exelent job on driver, but he played himself too important and caused angriness from many kernel hackers.
Linux kernel is GPL and it is it's strengh and it's weakness. Get used to this fact.
p.s. problem with webcams is rather serious because Philips chipset based webcams are very popular and cheap - for example, in my country it is very hard to find other type webcam in reasonable price range. So I hope someone will pick-up the pieces and will countinue to maitain driver.
Why oh why
I can fully understand that the author is pissed off because his work
gets "destroyed" - but the reaction is soo false if you ask me. Why didn't they agree to let the hook in place until they ported it to a nvidia-like interface? They could have asked somebody to port the driver to this kind of interface, while nemosoft would have ported the binary module to the new interface. I don't think this would have been too much work and both parties would be ok with it.
As other posters said, I'm not okay with the attitude of nemosoft. He was lucky to be able to have the hook in place and shouldn't throw away everything because he doesn't have the extra.