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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This was a good one. ;-)
Prakash
The GPL provides is a very _specific_ kind of freedom. It has its own
restrictions -- in many ways it's less free than if we were to just
release our code to the public domain, or under a BSD-style licence.
That is intentional.
> Q: You are keeping companies from wanting to write binary drivers for
> Linux.
Again, that is intentional. People are free to go use BSD if the GPL is
not compatible with their desires. Or Windows, perhaps.
People seem to be whining that Linux is released under the GPL instead
of a BSD licence. Perhaps the users concerned should be gently
encouraged to go elsewhere?
Linus was _joking_ when he said 'world domination'.
--
dwmw2
On Fri, 27 Aug 2004, Greg KH wrote:
> Q: But you took away my freedom! Isn't Linux about freedom?
We cannot take something away, you never had to begin with. The GPL gives
you the freedom to modify the source of your driver. If you decide to
relinquish this freedom by using a binary driver, we respect this
decision, but this also means we cannot help you if something goes wrong
with this driver.
bye, Roman
> Again, that is intentional. People are free to go use BSD if the GPL is
> not compatible with their desires. Or Windows, perhaps.
>
> People seem to be whining that Linux is released under the GPL instead
> of a BSD licence. Perhaps the users concerned should be gently
> encouraged to go elsewhere?
>
Very constructive. If you would use this zealotry energy in getting
results from Philips, we might not be here arguing. I get the feeling some
seem to think of the removal of this popular driver as a *contribution* to
Linux. This attitude contributes nothing to Linux. If you don't like a
partially binary driver, then I suggest you, too, contact Philips instead
of turning on your own users and contributors, or fighting with driver
maintainers that simply can't change the world to fit your wishes. We are
all in this mess, we all want good working drivers, preferably opensource.
If the opensource principle really is that important to you, I invite you
to send an email to Philips like the rest of us. And not attack people for
wanting to have their hardware in a working state, or turning this into a
BSD vs. GPL discussion.
Here: http://www.philips.com/
Thanks in advance!
> 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.
Can you say exactly where these procedures/policies are spelled out?
Alan Stern
> On Fri, 27 Aug 2004, David Woodhouse wrote:
>
>> Again, that is intentional. People are free to go use BSD if the GPL is
>> not compatible with their desires. Or Windows, perhaps.
>>
>> People seem to be whining that Linux is released under the GPL instead
>> of a BSD licence. Perhaps the users concerned should be gently
>> encouraged to go elsewhere?
>
> Very constructive. If you would use this zealotry energy in getting
> results from Philips, we might not be here arguing. I get the feeling
> some seem to think of the removal of this popular driver as a
> *contribution* to Linux. This attitude contributes nothing to Linux. If
> you don't like a partially binary driver, then I suggest you, too,
> contact Philips instead of turning on your own users and contributors,
> or fighting with driver maintainers that simply can't change the world
> to fit your wishes. We are all in this mess, we all want good working
> drivers, preferably opensource.
You've got things a little out of perspective.
1. Linux does not serve Philips.
2. Philips does not serve Linux.
Can we agree on that much?
3. Linux's licensing (i.e., the GPL) does not allow partial
closed-source drivers.
You can agree or disagree with that until your face falls off. That is
the way that it is. Allowing a license violation to continue would set
a bad precedent that goes beyond open-source dogma. It has nothing to
do with zealotry. It *is* a legal issue. You're not free to pick and
choose the parts of the license you like or don't like. Using a
license, ANY license, is like being pregnant: there is no half-way.
4. Philips serves *its* customers.
The logical conclusion is that, one way or another, Philips needs to
make a driver available that is compatible with Linux's licensing. It
can do that or decide that it doesn't care about its customers that use
Linux. The license really doesn't leave room for a third option.
Further bickering about it here is an exercise in futility.
Ehhh????? No comment.
>As I understand it the hook should never have been added in the first
>place. Doesn't matter if it has been there for a day, a week, a year or 10
>years - it should never have been added and once it was discovered it was
>removed - I have no trouble with that bit, especially since the pieces
>are still out there and you are free to just patch your personal kernel in
>any way you please to get the result you desire, or you can just stick
>with an older kernel until a suitable alternative shows up.
Why not let the current driver be and then work on the alternative?
Why is it so important that it is removed now?
Why does it have to be done in a way that create a problem for the common
users?
Linus indicated that since Nemosoft had asked for his driver to be removed
noone else could take the sources as they are and add them again. So any
altertive would be a start from scratch? Or did I misunderstand this?
That can take years. So I cannot update my kernel for years?
How many normal users knows even how to compile their own kernel?
You guys on this list talk as if anyone knows how to write a kernel module.
I think most of you have lost contact with the real users.
>And why is it you expect open source developers to assist in supporting
>binary only drivers?
I am just asking for you guys to not DESTROY what is already there without
an alternative.
>Binary only drivers undermine open source. If you want to depend on closed
>drivers go ahead, but if that support disappears then take it up with the
>company unwilling to provide open drivers or open specs so people can
>write their own open drivers.
Treating the normal users using Linux this badly undermines open source
1000 times more I can assure you.
Linux is getting a reputation of being an operating system that you cannot
trust being fully available in the future.
I am hearing those arguments in my own company. Stability and making sure
that investments in information technilogy will not be obsolete at least
some years is vital.
>You purchased a piece of hardware that depended on a closed source driver,
>no open source developer has any resonable commitment to support that.
It is sad that you need legal counselling before you buy a USB camera.
Besides. There are no real altertives. I have tried 4-5 other cameras using
for example the OV511 driver. They all failed. They were either not light
sensitive enough for surveillance at night or the firmware/driver was so
unstable that the cameras froze and had to be disconnected to work again.
Only the pwc driven cameras are stable and good enough.
Otherwise you have to use expensive real video cameras and they cost many
times more for the same quality image.
So I did not really have much choice. And this is still the case as far as
I know.
>If you want to be constructive instead of just bitch and moan, then go
>talk to Philips and get them to release code or specs so we can get proper
>open source drivers - your real beef is with them, not with open source
>developers.
Many have. And I will again. But if Philips will not let their competitors
know about some brillient compression algoritm we cannot blame them for
protecting their investment in the development. In the real world not
everything can be open source. At least not when new technology needs to be
kept secret to prevent copycat companies from lawless countries to harvest
the fruits of expensive investments.
It is our own jobs that are in danger. Remember that.
But I think it is about time Philips releases the code or at least algoritm
now. The copycats must have reverse engineered that little piece of code 5
times now.
I have tried also but it is just too difficult for me to follow the binary
stuff.
>PS. I'm wondering why you asked Linus a whole host of questions yet did
>not even CC the man on your email.
On most mailing lists people get angry if they receive the same mail both
from the list and directly. It seems to be different on this list. I am
starting to figure out the tradition here.
Kenneth
PS: Thanks to the many that writes support mails directly to me. I am
really happy to receive them. And post them in public too. Linus is not God
and he is not always right. He and his kernel developers need to learn that
there are actual users out there.
--
Kenneth Lavrsen,
Glostrup, Denmark
ken...@lavrsen.dk
Home Page - http://www.lavrsen.dk
See Linus's response on this thread for a statement of such a policy.
As to where they are written down, I don't know, sorry.
greg k-h
You're making a huge fuss over this. You're making wild claims about
being forced to throw away $2000 worth of cameras, the next great thing
that Linus will toss out of the kernel, companies being hurt, and 10,000
or more people being put out.
Here are a few points to consider Kenneth;
- Maintain the PWC support yourself
- Stay with the last kernel that supported PWC
- Maintain a patch that puts PWC support into the kernel
- Since the NDA has long since expired, why not investigate using the
whole of the code?
I would also consider the ramifications of a business model that uses
bleeding edge releases of kernels for their customers. You're so upset
and maddened by what has happened, that you've lost focus on what is
going on.
The hook wasn't right. It goes against policy of the kernel. Putting
off dealing with it is a slippery slope.
The reaction from the PWC camp seems to be wholly heated and with little
logical discussion. Before you turn your flamethrower on me, I also
have two cameras. Doing things the Right Way is better, I really don't
want to be moving the lines every time something doesn't suit me perfectly.
-david
p.s. If you feel like throwing away two grand worth of cameras, feel
free to ship them to me. I'm sure my trashcan would enjoy the use of them.
> - What is your excuse for forcing us to throw away worth 2000 dollars of
> cameras?
You, just like the rest of the world and even distribution makers if
they choose to do so, can patch the driver back into the kernel.
Just because it's not in the vanilla sources doesn't mean you can't
get a working setup. Look at all the NVIDIA users out there. :-)
Are they moaning about how the vanilla kernel maintainers are making
them "throw away blah blah dollars of video cards"? Absolutely not,
they load the binary-only blob, the go play quake3, and they're happy.
> - What is the next hardware or software - currently supported by Linux -
> that you will allow being made impossible to use for whatever fanatic
> reasons? (This is not exactly like the principles you stated in your book).
Not impossible, you're being rediculious, you can add the driver back
into the kernel you use just fine. See above.
>> Very constructive. If you would use this zealotry energy in getting results
>> from Philips, we might not be here arguing. I get the feeling some seem to
>> think of the removal of this popular driver as a *contribution* to Linux.
>> This attitude contributes nothing to Linux. If you don't like a partially
>> binary driver, then I suggest you, too, contact Philips instead of turning
>> on your own users and contributors, or fighting with driver maintainers
>> that simply can't change the world to fit your wishes. We are all in this
>> mess, we all want good working drivers, preferably opensource.
>
> You've got things a little out of perspective.
>
> 1. Linux does not serve Philips.
> 2. Philips does not serve Linux.
>
> Can we agree on that much?
>
Sure.
> [...]
> Further bickering about it here is an exercise in futility.
>
True. That's why I suggested that every developer who want this driver
removed, also stays true in their dedication for open drivers, delivers
some *constructive* action and emails Philips or whatever company of the
day that needs some convincing. Not just shooting down what you don't like
and being impossibly hard to people like Nemosoft who are caught between
two fires. If you care about opensource, equally much time would be spent
in (1) giving a minimal try to get it opensource, and (2) having a
constructive dialog with the maintainer. It can't take more time than
having these fights, can it?
BTW Sun did similar things with Solaris somewhere aroung 2.6 IIRC.
> Ehhh????? No comment.
Why?
[...]
> Why not let the current driver be and then work on the alternative?
> Why is it so important that it is removed now?
Because the driver's maintainer wanted it.
> Linus indicated that since Nemosoft had asked for his driver to be removed
> noone else could take the sources as they are and add them again. So any
> altertive would be a start from scratch? Or did I misunderstand this?
Yes, anyone - including you - can take over the maintanance of the
GPL-part of driver. Even if the former maintainer does not like it.
> That can take years. So I cannot update my kernel for years?
> How many normal users knows even how to compile their own kernel?
> You guys on this list talk as if anyone knows how to write a kernel module.
> I think most of you have lost contact with the real users.
No, they complain all around all the time. I don't think one can loose
contact eeven if he wishes.
The point is: This is GPL software - either you do something, or someone
else does something or nothing is done. Whining doesn't help that much
compared to writing code.
> >And why is it you expect open source developers to assist in supporting
> >binary only drivers?
>
> I am just asking for you guys to not DESTROY what is already there without
> an alternative.
It is not destroyed, it is only in another place. Find it and put it
back whereever you need it.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> You did not HAVE TO remove the hook. It had been there for years. You could
> have worked out an alternative way nice and quietly....
And it had also been an issue for years, on technical grounds too:
that such number crunching does not belong in-kernel.
That's evidence that there was really no "alternative" way.
- Dave
http://linux.slashdot.org/comments.pl?sid=119578&cid=10089410
From the LavaRND people. Apparently images produced with the binary
pcwx portion loaded (full-sized frame) had *less* entropy than the
smaller images produced without. Hence they speculate that the
function of the binary pcwx part is actually to interpolate the
160x120 image to the bigger 640x480 size, and has little to do with
hardware..
allegedly..
regards,
--
Paul Jakma pa...@clubi.ie pa...@jakma.org Key ID: 64A2FF6A
Fortune:
"Let's show this prehistoric bitch how we do things downtown!"
-- The Ghostbusters
Because Nemo felt that the driver was not in an acceptable shape
the way Greg was willing to accept it.
> Why does it have to be done in a way that create a problem for the common
> users?
There's no way to remove a driver without causing somebody problems.
> Linus indicated that since Nemosoft had asked for his driver to be removed
> noone else could take the sources as they are and add them again. So any
> altertive would be a start from scratch? Or did I misunderstand this?
> That can take years. So I cannot update my kernel for years?
You are free to take the driver from older versions and add it to your
personal kernel. You may even publish it. You can be quite confident
that most distributors will add the driver to their kernels.
> How many normal users knows even how to compile their own kernel?
> You guys on this list talk as if anyone knows how to write a kernel module.
> I think most of you have lost contact with the real users.
>
> >And why is it you expect open source developers to assist in supporting
> >binary only drivers?
>
> I am just asking for you guys to not DESTROY what is already there without
> an alternative.
Keeping drivers against the wishes of the authors in the tree would
be very troubling for the future. I can assure you that no maintainer
will lightly pull a driver in this way.
> It is sad that you need legal counselling before you buy a USB camera.
> Besides. There are no real altertives. I have tried 4-5 other cameras using
> for example the OV511 driver. They all failed. They were either not light
Then organize a website where people can sign a plea to Nemo to
maintain the driver out of kernel.
> sensitive enough for surveillance at night or the firmware/driver was so
> unstable that the cameras froze and had to be disconnected to work again.
> Only the pwc driven cameras are stable and good enough.
And thank him for the good work.
You are of cause also free to point out to Philips that you are creating
sales and are hampered by the secrecy of the compression method.
And give Nemo a little peace and consolation. He's very hurt now.
Regards
Oliver
> - What is your excuse for forcing us to throw away worth 2000 dollars of
> cameras?
I would think that Greg has invested more time than what could be covered
by that $2000 (i suggest you look up the going rate for experienced kernel
developers), you could at least show him some respect in the way you form
your questions.
Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Actually, it's probably *colour* interpolation. Digital cameras are
based on fundamentally black-and-white image sensors, with a filter
grid superimposed. (Search on "Bayer filter" for the most common RGGB
pattern.) A "640x480" digital camera has 640x480 = 307200 sensor pixels,
divided among 3 (or sometimes 4) colours.
Note that this is unlike a "640x480" colour LCD, which will have 640x480x3
= 921600 active elements. But it is the standard terminology for the field.
This gives some luminance/chrominance information at each pixel, but to
assign a 24-bit colour to each pixel requires some interpolation based on
adjacent picels. Digital cameras do such interpolation internally, but
it's also popular to support a "raw" image format to an external program,
in the hope of better result. See gPhoto for examples of such algorithms.
Anyway, I can imagine that the camera can do something crude internally
like downsampling by 2x2 to get colour values for each pixel. I can also
imagine that it can export the raw image to a software driver for better
interpolation that would take more CPU horsepower than it has on board.
Now, the fact that colour is effectively encoded in the high-frequency
portion of the luminance signal makes it rather tricky to produce a
"sharp" colour image without introducing artifacts when a high-frequency
black & white signal is present. The general techniques are published,
but digital camera makers put a lot of effort into the subtleties and are
generally very posessive of the details of their implementation.
This might be what's going on with Philips.
However, given that we already have access to lots of suitable Free
interpolating software, Linux doesn't need that. It just needs to know
how to elicit a raw high-res frame from the camera and what the returned
bits mean. The rest can be coped with.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
640 x 480 x 8 x 24 is still a lot more than USB 1.1 can handle.
What goes over the wire will be compressed.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Then the kernel community is no longer fit to use my code. So you should
remove everything I've written from Linus kernel too. I'll maintain my
own kernel.
Oh gosh, look I've just crippled Linus tree and stolen his project.
Thats *WHY* you can't just rip drivers out. A license was granted, for
ever. You can certainly remove him from maintainers, and if he insists
from the author credits.
Alan
This has been discussed before (on this list, I think), and
the answer may surprise you, or maybe not: nothing lasts forever.
I am not a laywer. I haven't looked at the U.K. copyright
laws. I *have* read throught the relevant U.S. laws (a few years
back), and a copyright assignment or license (which I believe is a
broad enough category to include the GPL) *can* be terminated in the
U.S. in certain cases -- that's quite clear. The "recapture" period
(for works created after 1978) is a five-year period that starts 35
years after the license was issued. In that window, the author of
copyrighted code, or the author's heirs or estate, have the option to
revoke the original copyright assignment or license, i.e., in our
case, presumably, revoke the GPL.
There are various details and procedures involved. They must
be followed precisely, or the opportunity to recapture the copyright
may be lost. One important detail is that work-for-hire copyright
assignments may not be recaptured.
So, If you keep track of everyone to whom you, the author,
*directly* distribute a copy of your GPL'd work (and thus assign an
"original" GPL'd license), you might be able to effect a recapture by
notifying everyone on that list. Then again, you might have to notify
everyone who ever received a copy of the GPL'd code, directly from you
or not. The GPL raises certain issues that simply weren't forseen by
the framers of the statutes in question! :-)
Again, I don't have the U.S. Federal Code references at hand.
However, here is an article that explains this issue for composers of
music:
http://www.ascap.com/estates/estatescopyrights.html
Finally, three preemptive comments:
1) This aspect of copyright law is something that all professional
authors should know about. You shouldn't have to relay upon
a lawyer to know your basic legal rights.
2) Linus Torvalds has recently reinforced the notion that the Linux
developers comminuty should behave as honorable gentlebeings, rather
than behave as lawyers. This posting is not meant to gainsay that
statement in any way. Think of knowledge of copyright law as akin to
knowing the terrain of a potential battlefield -- even though the
successful strategist seeks victory without the need for battle
(Sun Tzu, more or less).
3) The U.S. Congress or courts could make further changes to the laws that
affect copyright recapture. Again, nothing is forever.
Craig Milo Rogers
Hardware which needs a binary driver is not `supported by Linux'. You _know_
the so-called support may vanish in the (near) future.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> I think Greg "chose" to take it out.
True, No one was holding a gun to his head. :)
> > 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.
> I do not believe he "had no choice". The guards at Auswitchs made the
> same argument at Nuremberg.
[*** Nice "subtle" technique to call someone a Nazi. Real smooth!]
I "choose" to stop at stop signs and red lights. Yay me.
> I disagree. Binary drivers may take away from Linux and they may add to it.
My experiences: Binary drivers make Linux harder to support, harder to
distribute, harder to administrate and harder to maintain in production.
While they provide short term benefits, their long term impact is
negative. One example: What happens when company X goes out of business
or stops supporting the device?
A decision has been made: My understanding is that the Binary portion is
moving to user space and the devices in question will still function
as a result.
Please move it off the kernel list.
--
Idealism: "Realism applied over a longer time period"
Jeff Kinz
I would like to put a great deal of distance between myself and the
oppinions I and others have expressed concerning a little driver for a
camera - and the unacceptable analogy expressed above.
Brian! - comparing Nazies that exterminated millions of people in gas
chambers with a guy that annoys some people that happens to own a webcamera
is disgusting.
I do not want anyone to think that I - in any way - am associated with the
above repulsive statement.
Kenneth
--
Kenneth Lavrsen,
Glostrup, Denmark
ken...@lavrsen.dk
Home Page - http://www.lavrsen.dk
Q. Is there anyother way to support the binary only driver?
A. Yes. You can maintain a separate linux-pwc tree with the necessary hooks :)