pwc+pwcx is not illegal

(note: the following is not legal advice)

I think you'll find that this is not supported by the copyright law, at least in the United States and in any sane country.

Richard Stallman and The SCO Group might like your interpretation, at least when it serves them, but that doesn't make it the law.

What protectable elements of the kernel have been included within the driver? I don't see any. Like we say to SCO, where are the lines of code? Remember, nobody is distributing a kernel with this driver linked in. Merely loading the driver is obviously fair use of the kernel.

(BTW, something which is required for operation is not protectable. See the Sega v. Accolade case. Thus, mere usage of header files won't do. You couldn't even use the C header files on any UNIX system if that were the case. Let's not be silly.)

Is it "non-literal copying" that concerns you? Heh. OK. Name the jurisdiction you like, and describe the copyright infringement test accepted by the courts in that jurisdiction.

For example, the US 10th Circuit uses the "abstraction, filtration, comparison" test. The US 9th Circuit uses the "Analytic Dissection" test. There are others. I don't know of any such test under which the closed-source part of the driver could be considered to be a derived work of the Linux kernel. I can hardly imagine one that would make the driver derived without also making Linux derived from UNIX!

So anyway... where are the lines of code?

Can we drop this straw-man discussion now?

We don't do binary hooks in the kernel. Full stop. It's a gray area legally (and whatever you say won't change that), but it's absolutely not gray from a distribution standpoint.

AND IT WASN'T EVER THE REASON FOR REMOVING THE DRIVER IN THE FIRST PLACE!

So stop whining about it. The driver got removed because the author asked for it.

Linus

Try and see this from the developers perspective and then remember that he is a human beeing.

When I look at the postings from the past months I would say that he was provoked to react the way he did by the arrogant way that Greg handled it.
And from what Greg says himself that people has called him in the past (I will not repeat it) I would advice Greg to consider changing behavour.
Because this is what it all comes down to.
Why did Nemosoft react to hard?
When you love what you are doing and you have worked hard - not for your own good - but to help others - it is hard to repeatedly being treated badly. And there should be no need to in the open source community.

I agree that the right way to go is to get all drivers open source. And I think it is OK to reject new drivers.
But accepting a hook that allows a driver to use an external binary module for years and then suddenly remove this without making sure that it is replaced with something better is just plain wrong because it harms a lot of people.

Just look at the reaction everywhere. I have rarely seen so many angry Linux users. I have already started contacting computer magazines and news papers. I just cannot accept that people can care so little for other people.

Kenneth

Kenneth Lavrsen,
Glostrup, Denmark
[email protected]
Home Page - http://www.lavrsen.dk 

Hey, have you read the thread at all?

Respecting the developer is exactly why the code has been removed.

Being a developer gives you not only legal rights, but lots of other rights. One right IT DOES NOT give you, though, is the right to add binary hooks. That right is overridden by respecting other _developers_ rights.

Linux is all about open source. It's about making the best possible OS, and being as user-friendly as possible, but it's about doing so within the overriding goal of everybody being able to work together on the thing.

So please respect _our_ work.

I'm personally pretty optimistic that something can be worked out. But it will not happen by users whining - it will happen by users askign nemosoft politely to avoid the kernel hooks, or by other users deciding to step up to the plate and becoming developers.

Linus

These people do care, they created, wrote and/or maintain the Linux kernel in the first place! They also are wise enough to care more the long-term interests of Linux than just the short-term.

regards,

Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
Advertising is a valuable economic factor because it is the cheapest
way of selling goods, particularly if the goods are worthless.
		-- Sinclair Lewis

So we have to step on a few people on the way to build our great an glorious utopia! Well at leat it is for their own good.

Brian Litzinger

I love sensationalism. And you're really good at twisting the facts my friend. People can still get their cameras working just fine, but it's convenient for your argument that you ignore that fact.

One incredibly burning question sits before me. Why do you spend such an exorbitant amount of energy wailing and hand waving over this instead of coming up with a solution? You're so hellbent on making a big stink out of it instead of what seems to be a simple issue. Since the driver already exists in multiple parts, use the existing works to come up with a solution. I know Nemosoft loves his work and nobody likes getting pushed away. But if the approach is wrong, find a solution that is right.

Honestly, it's pretty annoying to see people hellbent on the ruckus itself with little or no thought to a solution.

Make sure that gets into the editorials too.

-david

begin:vcard
fn:David Ford
n:Ford;David
email;internet:[email protected]
title:Industrial Geek
tel;home:Ask please
tel;cell:(203) 650-3611
x-mozilla-html:TRUE
version:2.1
end:vcard

Sure. That has nothing to do with whether it would be legal or not. It had been implied (by Greg KH) that you thought Linux-specific proprietary drivers using hooks are illegal.

They're not nice at all, but that's a different matter.

Well, yes, but not very. If this ever goes before a judge, betting that pwcx is ruled to be a derived work would be a foolish way to bet.

Sure. No problem, but let's not be suggesting that this has anything to do with the law.

No, I was trying to state that the hook itself was not allowed. I'll let others argue about the legality of the code using such a hook.

Sorry for any confusion about that.

greg k-h

And they may be. As I said, your posturing doesn't matter. Using specialized hooks might very well be ruled to be a sign of being a derived work.

When you get a court ruling saying otherwise, come back stating it as fact. Until then, it's considered a gray area.

Linus

Please put it back, minus the hooks so the rest of the world can use it. If not please remove every line of code I've even written because I don't like the new attitude .. so ner..

Point made ? We can't go around throwing out drivers because the author had a tantrum. Its also trivial to move the decompressor to user space where it should be anyway. Similarly the driver is useful without the binary stuff.

Or do we need a -ac tree again where this time -ac is "added camera" ;)

Alan

Hello,

No, don't! There is one very practial reason for that: the utter confusion it will cause when suddenly PWCX cannot be loaded anymore, because users will assume that since PWC is in the kernel, PWCX will work too. I really would not like to be at the receiving end of the support mailbox when 2.6.9 comes out with such a crippled version of PWC.

That's one of the reasons I requested PWC to be removed. For me, it's also a matter of quality: what good is a half-baked driver in the kernel when you need to patch it first to get it working fully again? I don't want my name attached to that.

I'm not having a tantrum. If it is, it has been one in the making for 3 years.

*sigh* As I have been saying a 100 times before, it is illogical, cumbersome for both users and developers, and will probably take a very long time to adopt (notwithstanding V4L2 [*]).

I mean, I still remember when the YUV->RGB conversion code was snipped from PWC when I supplied it for inclusing in the kernel, back in 2001. It took a long, long time for webcam tools to adjust their code to check for the YUV palette and do the conversion themselves, and _to_this_very_day_ I'm getting mails about programs who still don't get it right.

*IF* there was a commonly accepted video "middle-layer", this would not pose much of a problem. But there is no such thing yet.

(maybe that's something for a 2.7 kernel...)

True. But judging from the mails I have received the last couple of days, people don't really care about the binary stuff, as long as it works. They want to use the cam to its full potential, so PWCX is more or less a necessity. However, there's has now been added an extra hurdle in getting it work, for reasons I find questionable, and really, 3 years too late.

Seriously, this probably would not have happened if, back in 2001, the driver was rejected on the basis of this hook (you were there, Alan...) I never made a secret of it, it has been in the driver from day 1 and its purpose was clearly spelled out. If it had been rejected, I would probably have just switched to '3rd party module' mode and maintained it outside the kernel indefinetely. I would not have liked it, but it would have been acceptable.

Another acceptable solution would have been, if after the 'discovery' of the hook, Greg or anybody else had said: "Look, we really don't want this kind of thing in the kernel. However, since we're a bit late to react, we'll leave it in the 2.4 and 2.6 series, but versions beyond that (2.7-devel, etc) will not have PWC included in this form. In the mean time, we're asking you to think of a solution". Chances are the situation would have been fully resolved before that (and I mean fully *hint*).

*lol* The code is still floating around on the Net, so nobody's stopping you...

- Nemosoft

[*] Some advice: if you really want to speed up V4L2 adoption by video tools, start disabling V4L1 in the kernel...

It works very well for some users without that code. The raw pass through for the compressed bitstreams solved the problems for the rest. You appear to be seeking to hurt your userbase for your own ends. Thats not pleasant behaviour. I can more than understand
"take my name off it, make it clear its nothing to do with me".

Video4linux has -always- specified decompressors in user space. This was pointed out ages ago. V4L2 rationalised it even more clearly.

No its for userspace. Just add it to the relevant video frameworks.

Back in 2001 I was saying that this was broken and it belonged in user space.

There isn't a plan to have a 2.7 development tree but to do gradual development until something major comes up. That makes the suggestion rather more tricky - as does the legal question.

On Sun, 29 Aug 2004 16:42:24 +0100 Alan Cox wrote:

| On Sul, 2004-08-29 at 17:33, Nemosoft Unv. wrote:
| > That's one of the reasons I requested PWC to be removed. For me, it's also a 
| > matter of quality: what good is a half-baked driver in the kernel when you 
| > need to patch it first to get it working fully again? I don't want my name 
| > attached to that.
| 
| It works very well for some users without that code. The raw pass
| through for the compressed bitstreams solved the problems for the rest.
| You appear to be seeking to hurt your userbase for your own ends. Thats
| not pleasant behaviour.  I can more than understand
| "take my name off it, make it clear its nothing to do with me".
| 
| > > Its also trivial to move the decompressor to user space 
| > > where it should be anyway. 
| > 
| > *sigh* As I have been saying a 100 times before, it is illogical, cumbersome 
| > for both users and developers, and will probably take a very long time to 
| > adopt (notwithstanding V4L2 [*]). 
| 
| Video4linux has -always- specified decompressors in user space. This was
| pointed out ages ago. V4L2 rationalised it even more clearly.
| 
| > *IF* there was a commonly accepted video "middle-layer", this would not pose 
| > much of a problem. But there is no such thing yet.
| > 
| > (maybe that's something for a 2.7 kernel...)
| 
| No its for userspace. Just add it to the relevant video frameworks.
| 
| > Seriously, this probably would not have happened if, back in 2001, the 
| > driver was rejected on the basis of this hook (you were there, Alan...) I 
| > never made a secret of it, it has been in the driver from day 1 and its 
| > purpose was clearly spelled out. If it had been rejected, I would probably 
| > have just switched to '3rd party module' mode and maintained it outside the 
| > kernel indefinetely. I would not have liked it, but it would have been 
| > acceptable.
| 
| Back in 2001 I was saying that this was broken and it belonged in user
| space.

Yes, that's right, and it should be done by now... We kept expecting updates in that direction.

| > of thing in the kernel. However, since we're a bit late to react, we'll 
| > leave it in the 2.4 and 2.6 series, but versions beyond that (2.7-devel, 
| > etc) will not have PWC included in this form. In the mean time, we're 
| > asking you to think of a solution". Chances are the situation would have 
| > been fully resolved before that (and I mean fully *hint*).
| 
| There isn't a plan to have a 2.7 development tree but to do gradual
| development until something major comes up. That makes the suggestion
| rather more tricky - as does the legal question.

--
~Randy

Hi,

A part of this discussion has to do with the expiration of the NDA covering pwcx. Can you disclose the NDA?
Also a person on the list tried to contact the correct person within Philips. Can you disclose the contact person or department which you used about 3 years ago?

Best regards,

Norbert van Nobelen

You're completely missing the point. I never said that the pwcx driver copies code from the kernel, and in doing so infringes copyright law.

What I'm saying is that the kernel is distributed with a license that allows you certain rights, and that extending the kernel functionality through closed source drivers is not one of those rights.

You're being silly, I've never said anything about header files, nor copied lines of code.

It is a derived work, not a "copied" work. The point is:

In the case of a nvidia driver (for instance) one can argue that the driver was written for another well known closed source operating system, and was latter ported to Linux, so that we can not honestly say that it is a derived work.

Anyway, this is all a big gray area, with darker and lighter tones of gray. So you only get a definite answer in front of a judge.

This whole discussion has been beaten to death in the past. I really don't want to go through that again. Although I have not been directly involved in the past discussion, the traffic in LKML is high enough that it doesn't need another one of those threads...

Paulo Marques - www.grupopie.com

To err is human, but to really foul things up requires a computer.
Farmers' Almanac, 1978

True, but misleading.

The GPL is not an EULA contract that makes you give up your right to extend kernel functionality. The GPL doesn't grant you the right to read the code, but nobody complains that code reading is prohibited. Such activities are outside the scope of the GPL.

Whatever. I don't see how that matters.

To be a derived work, some protectable element of the kernel would have to be included. That might be limited to lines of code, or it might include some higher-level features like control flow. Either way, the pwcx driver won't qualify as being derived.

The SCO Group has a better chance than you do. :-) (and, if you're right, BAD things happen)