Re: kernel 2.6.8 pwc patches and counterpatches

Re: kernel 2.6.8 pwc patches and counterpatches

[Nemosoft Unv.]

Hello,

On Tuesday 24 August 2004 00:10, you wrote:
> On Wed, Aug 18, 2004 at 09:05:36AM -0700, Fr?d?ric Detienne wrote:
> > On Tue, 2004-08-17 at 21:38, Andrew Morton wrote:
> > > Fr?d?ric Detienne <fd@cisco.com> wrote:
> > > > I suppose this is not the only place where we
> > > >  prepare API's for modules that do not belong to the kernel tree.
> > >
> > > It _is_ the only place, and that's the problem.
> >
> > yes and no. By providing a hook, there is a chance to insert an other
> > decompressor (hopefully, a reverse engineered, open source one).
>
> Actually, in thinking about this even more, I just realized that I have
> to rip this hook out.  I say this because we are allowing a change to
> the kernel that is needed _only_ for a closed source module.  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.
>
> So, I'll rip this out with the next round of USB patches that I send off
> to Linus.
>
> Nemosoft, any thoughts?

Uhm, excuse me? This hook has been there since the beginning of PWC in the 
kernel, so I don't consider it a 'change'. The only change there has been 
is in the declaration part, to allow for a single type of linkage with an 
external library [*]. Actually, if they hadn't started using "Register 
parameters" in the kernel to squeeze out a a few microseconds, I wouldn't 
have had this problem, and nobody would have noticed. The real problem is 
that GCC 2.95 doesn't like 'asmlinkage' in function pointer declarations 
which is why PWC failed to compile. I was _about_ to create in a patch 
tonight that would solve this problem and make it work on both GCC 2 and 
GCC 3 again, until I read this mail. 

Anyway....

I've just about had it with the increasing 
"we-don't-want-binary-stuff-in-Linux" attitude lately. If you rip out this 
hook for PWC (pwc_register_decompressor), which would make it impossible to 
load a decompressor, closed source *OR* open source (should that happen one 
day), is going to be the last straw.

Without this hook, PWC will work, but with limitations, just as it always 
has. But the _user_ always had a choice of loading a closed source module 
to get the extras. If you, kernel developers, maintainers, etc. are going 
to take away that right from the _users_, I think you're way over head, 
forgetting what open source is about, IMO.

I accept that the Linux kernel is the work of Linus and the maintainers, and 
they can do with it as they please, but I will not accept that they can put 
arbitrary limits on the kernel's use by me, or other users.

I've been maintaining this driver for the past 4 years, and it's always been 
an uphill battle against the closed sourceness of the driver. First, it was 
completely binary, which proved to be quite a support burden but I managed. 
Then I got allowance to open source part of the driver and add it to the 
kernel, so a) the webcam could run on more platforms, b) I could narrow 
down the support issues. Then, I started introducing cross-compiled PWCX 
(decompressor) modules for a variety of platforms, so it would work on even 
more systems. In the mean time, I had to dodge several changes to the 
kernel that, intentionally or unintentionally, caused the PWCX part to 
break down. But I managed. [**] And now, finally with PWC 9, I could 
provide even better cross-platform support. All to get these webcams 
working, make _a lot_ of people happy, and make Linux the top OS it 
deserves to be. Appearantly all in vain.

To come back to Linus´s comment "if a change is needed [...] in order to get 
a closed source module to work, that module must be made opensource". Well, 
that ain't gonna work. There is no way that manufacturers are suddenly 
going to wave their hands in the air and start panicking "Oh dear, we're 
going to loose Linux support! What must we do?! Should we open source? 
Argh!" It is not going to happen. Period. Get down to earth, now.

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...

Anyway, before this gets too long... I'm giving you a choice here. Either:

* you are going to accept that there is a driver in the Linux kernel that 
has a hook that _may_ be used to load a binary-only decompressor part into 
the kernel, at the user's disgression. Maybe, one day, that part will be 
open source too but I cannot guarantuee that. 

* Or, you're saying: no, we cannot allow this under any circumstance. We do 
not even want to provide the means for the theoretical possibility that a 
binary module might be loaded into the kernel (in which case you can scrap 
the whole idea of loadable modules, if you want my opinion)

Those are the options. No more, no less.

In case the answer is "No", then I will:
- demand that the PWC driver is removed from any further Linux kernel 
releases; Open source or not, it's still _my_ work.
- remove the website (http://www.smcc.demon.nl/webcam/), all webpages and 
PWC version available for download from that site.
- shut down the bug-tracker 
- remove the PWC related mailbox from my system
- not respond to ANY mail related to PWC anymore; no user requests, no 
problem solving, no queries for information.

Basicly, the PWC driver will then be null and void. And yes, that is a 
threat, but it shows how fed up I am with this. And believe me, there are a 
lot of users who will NOT be happy. But if you (kernel peeps) show contempt 
for all the work that I have done, then I'm not going to help you anymore, 
with Linux. Simple as that. 

I'm demanding a clear, and unambiguous answer on my question, if need be 
from Linus himself. I think the status of binary-only drivers, or in this 
case, a plugin, has always been in some sort of 'legal' limbo, and that PWC 
has always more or less meandered through the gaps. Now I want to know 
where I'm standing at.

 - Nemosoft

[*] Two different version are possible, but most people would probably not 
have a clue as to how their kernel is compiled; and you won't know until 
the module Oopses...

[**] To the nitwit on /. who once said "Well, you brought that all onto 
yourself when you signed that NDA", I can only say: "Go suck a lemon", to 
quote Maj. Carter. (SG-1)

Re: kernel 2.6.8 pwc patches and counterpatches

[Greg KH]

On Wed, Aug 25, 2004 at 12:58:24AM +0200, Nemosoft Unv. wrote:
> Anyway....
> 
> I've just about had it with the increasing 
> "we-don't-want-binary-stuff-in-Linux" attitude lately. If you rip out this 
> hook for PWC (pwc_register_decompressor), which would make it impossible to 
> load a decompressor, closed source *OR* open source (should that happen one 
> day), is going to be the last straw.

Well, I just made a patch that did just that, and applied it to my
trees.

> Without this hook, PWC will work, but with limitations, just as it always 
> has. But the _user_ always had a choice of loading a closed source module 
> to get the extras. If you, kernel developers, maintainers, etc. are going 
> to take away that right from the _users_, I think you're way over head, 
> forgetting what open source is about, IMO.
> 
> I accept that the Linux kernel is the work of Linus and the maintainers, and 
> they can do with it as they please, but I will not accept that they can put 
> arbitrary limits on the kernel's use by me, or other users.

Think legal limits, not arbitrary.

> Anyway, before this gets too long... I'm giving you a choice here. Either:
> 
> * you are going to accept that there is a driver in the Linux kernel that 
> has a hook that _may_ be used to load a binary-only decompressor part into 
> the kernel, at the user's disgression. Maybe, one day, that part will be 
> open source too but I cannot guarantuee that. 

I now realize that.  So I've ripped that hook out, as it's only used to
load a binary driver, which is not allowed.

That's the change I'm going to make.

If you want to send me a patch to tell me to rip the whole driver out,
fine I will, no problems, I completly understand.

But realize that anyone can then add it back, as the work you did was
released under the GPL :)

thanks,

greg k-h

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Norbert Preining]

On Die, 24 Aug 2004, Greg KH wrote:
> > * you are going to accept that there is a driver in the Linux kernel that 
> > has a hook that _may_ be used to load a binary-only decompressor part into 
> > the kernel, at the user's disgression. Maybe, one day, that part will be 
> > open source too but I cannot guarantuee that. 
> 
> I now realize that.  So I've ripped that hook out, as it's only used to
> load a binary driver, which is not allowed.
> 
> That's the change I'm going to make.
> 
> If you want to send me a patch to tell me to rip the whole driver out,
> fine I will, no problems, I completly understand.

Bummer. This is rubbish. And I am sure that this is not the intention of
Linus comments. IF the module would be NON functional without the closed
plugin, then yes, rip it out. But it is useable, and this hook *can* be
used for closed modules, but also for other modules. 

It really looks like personal stuff going on here, not really objective
discussion on this point.

> But realize that anyone can then add it back, as the work you did was
> released under the GPL :)

And who will take over the level of support that Nemosoft has put into
this driver without the internal knowledge of the device? Good luck.

Best wishes

Norbert

-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at>         Technische Universität Wien
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
			--- Douglas Adams, The Meaning of Liff

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Greg KH]

On Wed, Aug 25, 2004 at 07:35:16AM +0200, Norbert Preining wrote:
> 
> Bummer. This is rubbish. And I am sure that this is not the intention of
> Linus comments. IF the module would be NON functional without the closed
> plugin, then yes, rip it out. But it is useable, and this hook *can* be
> used for closed modules, but also for other modules. 

But it isn't, that's the point.

> It really looks like personal stuff going on here, not really objective
> discussion on this point.

Nothing personal here.  The GPL code has a exported symbol explicitly to
be able to load a closed source decoder module.  Because of that, I've
deleted that symbol (and the surrounding logic, as it's no longer
needed.)  One could also argue that no in-kernel code needs that symbol
exported, so it should be removed for that reason alone.

That's all I've done.  The in-kernel module still works the same as it
always did if you never used the closed source decoder.

thanks,

greg k-h

Re: kernel 2.6.8 pwc patches and counterpatches

[Simon Oosthoek]

Nemosoft Unv. wrote:

> 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...

I have one of those philips cams (bought it because I saw pwc in the 
kernel source), but I found out that without pwcx is was next to 
useless. I haven't found a good alternative camera though...

The fact that the NDA has expired already doesn't surprise me, but I 
would have expected some (or a huge) effort to liberate the source with 
full permission from Philips (they probably don't care anymore and could 
use the (marginal) good publicity more that the secret).

The fact that this hasn't happened is to me a hint that Nemosoft likes 
the power of "owning" it more that the chance of liberating it. But I 
could be wrong in that... (I apologise in advance if I'm wrong!)

I'd prefer that a clear choice is made on this, as Nemosoft suggests, 
because it shouldn't be in the kernel without the full decoding algorithms.

Cheers

Simon (a user)

Re: kernel 2.6.8 pwc patches and counterpatches

[Rob van Nieuwkerk]

On Wed, 25 Aug 2004 00:58:24 +0200
"Nemosoft Unv." <nemosoft@smcc.demon.nl> wrote:

Hi Nemosoft,

> 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...

Apparently Philips clearly indicated that disclosure would be fine with
them on this date (one year ago !!!!).  If they felt otherwise they
would have chosen a different date !

You don't mention any request or presure from Philips to not disclose.
So I assume that the only reason for you not to release the source is
some personal agenda.

The Philips cams are very good.  But for many real-life applications
they are useless without the binary-only decompressor module under Linux.

There are some severe bugs in either your Philips webcam driver, the
USB stack or the combination of both, resulting in a "dead" camera
within a second of use in some situations.  This can only be fixed by
a power cycle  (reported to you several times btw).

Not having the complete source available makes it unlikely that these
problems will be solved (nothing improved wrt this the last years).

I use 1000 Philips webcams in a product.  We are evaluating camera's for
a 2nd generation product of which several thousands more may be built.
Having the source for the driver available would certainly improve
chances that I'll use the Philips cams again.

Maybe Philips isn't impressed by thousands directly because they think
in hundreds of thousands.  But OTOH it may be an indication to them that
there is serious interest for a complete opensource Linux driver for
their nice webcam.

If you *do* notice some unhappy feelings within Philips about opensourcing
the decompressor, let me know: maybe it helps if I talk to them.

Please consider opening the source !

	greetings,
	Rob van Nieuwkerk

Re: kernel 2.6.8 pwc patches and counterpatches

[Rob van Nieuwkerk]

On Thu, 26 Aug 2004 02:55:45 +0200
Rob van Nieuwkerk <robn@berrymount.nl> wrote:

> There are some severe bugs in either your Philips webcam driver, the
> USB stack or the combination of both, resulting in a "dead" camera
> within a second of use in some situations.  This can only be fixed by
> a power cycle  (reported to you several times btw).
  ^^^^^^^^^^^^^

I mean "reboot" !

	greetings,
	Rob van Nieuwkerk

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Greg KH]

On Thu, Aug 26, 2004 at 12:58:59AM +0200, Nemosoft Unv. wrote:
> Hello,
> 
> On Wednesday 25 August 2004 01:04, Greg KH wrote:
> > On Wed, Aug 25, 2004 at 12:58:24AM +0200, Nemosoft Unv. wrote:
> > If you want to send me a patch to tell me to rip the whole driver out,
> > fine I will, no problems, I completly understand.
> 
> I don't think you do.

Just like I don't think you understand the laws involved here :)

> > But realize that anyone can then add it back, as the work you did was
> > released under the GPL :)
> 
> We'll see. Greg, please remove all references to the PWC driver from the 2.6 
> kernel ASAP. This also includes Documentation/usb/philips.txt and a 
> possible entry in the MAINTAINERS file. Sending a patch will probably be 
> pointless since you made changes I haven't seen.

I've done that.  You should send a patch to Pete to do the same for the
2.4 tree too.

I'm very sorry it's come to this, I really am.  

I'd like to personally thank you for all the time you've spent in
working on this driver over the years, and wish you the best in whatever
you do in the future.  Come back anytime.

thanks,

greg k-h

Re: kernel 2.6.8 pwc patches and counterpatches

[syrius.ml]

Hi there,

I'm very sad to read about that story...
I don't know all of the background, I first read
http://www.smcc.demon.nl/webcam/ then went to lkml to read a bit more
about it.
I just don't understand why Nemosoft did remove all his work (sources,
doc, and stuff). I don't like to be taken hostage !
btw nemosoft, atm what's philips' position about that ended nda and
about opening their source ? (has anyone asked philips already ?)

anyway, i've just applied pwcx-9.0-beta-2 on top of 2.6.9-rc1-bk1 and
it's working.
but I'm looking for the lastest pwc-9.0.2.tar.gz and pwcx-9.0.tar.gz,
could someone tell me where to find them (or send them to me) please.

TIA.

-- 

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Tuukka Toivonen]

On Wed, 25 Aug 2004, Simon Oosthoek wrote:

> I have one of those philips cams (bought it because I saw pwc in the kernel 
> source), but I found out that without pwcx is was next to useless. I haven't

Could you elaborate why it is next to useless? I think 95% of Linux
web camera drivers don't support all features of a camera, like 
compression. Reverse engineering USB traffic is easy, reverse engineering
compressed formats is _hard_.

> The fact that the NDA has expired already doesn't surprise me, but I would 
> have expected some (or a huge) effort to liberate the source with full 
> permission from Philips (they probably don't care anymore and could use the

I understood that Nemosoft has already asked Philips a permission and 
denied for that. It hardly helps asking again and again and again... he has 
to maintain the driver, too.

> The fact that this hasn't happened is to me a hint that Nemosoft likes the 
> power of "owning" it more that the chance of liberating it. But I could be

Why do you think that *most* of the pwc driver is already GPL'ed then, and 
even (was) in the kernel?

> I'd prefer that a clear choice is made on this, as Nemosoft suggests, because 
> it shouldn't be in the kernel without the full decoding algorithms.

Then you should remove most of the other drivers in the kernel too.

Besides, format conversions _are not allowed_ in the kernel. They belong 
into userspace.

Nemosoft: you should not have the power to demand removing the GPL'd code
from the kernel (I don't know about the law, but whatever it says, GPL'd 
license should not be revocable). You can ask, of course, but wouldn't it 
be simpler to just stop maintaining the in-kernel driver, if it already 
works?

From: Greg KH <greg@kroah.com>
>> We'll see. Greg, please remove all references to the PWC driver from the 2.6
>> kernel ASAP. This also includes Documentation/usb/philips.txt and a
>I'm very sorry it's come to this, I really am.
>
>I'd like to personally thank you for all the time you've spent in
>working on this driver over the years, and wish you the best in whatever
>you do in the future.  Come back anytime.

Too bad seeing this. Nemosoft, I hope you will continue maintaining
the driver which looks very nice (though I haven't been able to test it),
at least as an external module. That allows you free hands to add any nice
features that would never been accepted into kernel, anyway.

--
| Tuukka Toivonen <tuukkat@ee.oulu.fi>   [OpenPGP public key
| Homepage: http://www.ee.oulu.fi/~tuukkat/       available]
| M.Sc. Researcher, Dept of El & Inf Eng, University of Oulu
| "You will be shot if you try to do
|           format conversion in kernel" -Pavel Machek, 2001
+-----------------------------------------------------------

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Oliver Neukum]

Am Donnerstag, 26. August 2004 11:22 schrieb Tuukka Toivonen:
> Besides, format conversions _are not allowed_ in the kernel. They belong 
> into userspace.

Well, there's no need to be dogmatic about it. In a basic sense any driver
is performing a format conversion.

> Nemosoft: you should not have the power to demand removing the GPL'd code
> from the kernel (I don't know about the law, but whatever it says, GPL'd 
> license should not be revocable). You can ask, of course, but wouldn't it 
> be simpler to just stop maintaining the in-kernel driver, if it already 
> works?

Legally of course the license has been given and cannot unilaterally be
revoked. But his name is on the driver and he gets the mails about it.
So unless somebody takes over full maintenance, he should be allowed
to shoot his own dog and Greg has announced that he would take such a
patch.

	Regards
		Oliver

Re: [linux-usb-devel] Re: kernel 2.6.8 pwc patches and counterpatches

[Tuukka Toivonen]

On Thu, 26 Aug 2004, Oliver Neukum wrote:

> Am Donnerstag, 26. August 2004 11:22 schrieb Tuukka Toivonen:
>> Besides, format conversions _are not allowed_ in the kernel. They belong
>> into userspace.
> Well, there's no need to be dogmatic about it. In a basic sense any driver
> is performing a format conversion.

Well, it is possible that user applications get exactly the same bytes/bits
that the hardware generates, isn't that the case with most formats with 
common TV cards (bttv)? So I'm not sure why you say any driver does 
format conversions?

I find it rather confusing that some things are allowed in kernel while 
some not. Think about color balancing. This is image processing that I'm 
sure would be objected in the kernel, while it is mandatory to get 
useful colors from some cameras.

Something like picking up the image data from received USB packets and 
copying into image buffer, I don't consider that format conversion as long 
as no arithmetic operations are performed with the data.

And yeah, I do think that all of the arithmetic on the data should be done 
in userspace libraries, always. I'm just waiting until there is one common 
such library.

> Legally of course the license has been given and cannot unilaterally be
> revoked.

The GPL is an unilateral permission from author, and legally I don't know a 
rule which would prevent revocing it, because (usually) nobody has paid 
to obtain it. But IANAL, so I'll drop this subject now.

> But his name is on the driver and he gets the mails about it.

Well, the name could be prepended with a text explaining that Nemosoft does 
not maintain the code.