* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
@ 2006-12-14 5:39 ` Martin J. Bligh
2006-12-14 6:01 ` Hua Zhong
` (3 more replies)
2006-12-14 7:24 ` Jeffrey V. Merkey
` (7 subsequent siblings)
8 siblings, 4 replies; 160+ messages in thread
From: Martin J. Bligh @ 2006-12-14 5:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards,
linux-kernel
Linus Torvalds wrote:
>
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright. Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
>
> Btw, I really think this is shortsighted.
>
> It will only result in _exactly_ the crap we were just trying to avoid,
> namely stupid "shell game" drivers that don't actually help anything at
> all, and move code into user space instead.
I don't think pushing the drivers into userspace is a good idea at all,
that wasn't what I was getting at. Pushing the problem into a different
space doesn't fix it. IMHO, we're not a microkernel, and drivers for
hardware belong in the kernel.
Whether we allow binary kernel modules or not, I don't think we should
allow an API for userspace drivers - obviously that's not my call, it's
yours, but at least I don't want my opinion / intent misinterpreted.
> What was the point again?
>
> Was the point to alienate people by showing how we're less about the
> technology than about licenses?
The point of banning binary drivers would be to leverage hardware
companies into either releasing open source drivers, or the specs for
someone else to write them. Whether we have that much leverage is
debatable ... I suspect we do in some cases and not in others. It'll
cause some pain, as well as some gain, but I think we'd live through
it pretty well, personally.
The details of the legal minutiae are, I feel, less interesting than
what goal we want to acheive. If we decided to get rid of binary
drivers, we could likely find a way to achieve that. Is it a worthwhile
goal?
I've done both Linux support, where binary drivers are involved, before,
as well as supporting Sequent's Dynix/PTX in the face of a similar
situation with CA Unicenter. It makes life extremely difficult, if not
impossible for a support organisation, for fairly obvious and well known
reasons. When there are two binary drivers from different vendors in
there, any semblence of support becomes farcical.
The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
going. If we don't stand up at some point, and ban binary drivers, we
will, I fear, end up with an unsustainable ecosystem for Linux when
binary drivers become pervasive. I don't want to see Linux destroyed
like that.
I don't think the motive behind what we decide to do should be decided
by legal stuff, though I'm sure we'd have to wade through that to
implement it. It's not about that ... it's about what kind of ecosystem
we want to create, and whether that can be successful or not. Indeed,
there are good arguments both for and against binary drivers on that
basis.
But please can we have the pragmatic argument about what we want to
achieve, and why ... rather than the legal / religious arguments about
licenses? The law is a tool, not an end in itself.
If you don't feel it's legitimate to leverage that tool to achieve a
pragmatic end, fair enough. But please don't assume that the motivation
was legal / religious, at least not on my part.
Perhaps, in the end, we will decide we'd like to ban binary drivers,
but can't. Either for pragmatic reasons (e.g. we don't have enough
leverage to create the hardware support base), or for legal ones
(we don't think it's enforcable). But we seem to be muddled between
those different reasons right now, at least it seems that way to me.
I think allowing binary hardware drivers in userspace hurts our ability
to leverage companies to release hardware specs. The 'grey water' of
binary kernel drivers convinces a lot of them to release stuff, and
Greg and others have pushed that cause, all credit to them. In one way,
it does make the kernel easier to support, but I don't think it really
helps much to make a supportable *system*.
M.
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 5:39 ` Martin J. Bligh
@ 2006-12-14 6:01 ` Hua Zhong
2006-12-14 11:14 ` Alan
2006-12-14 8:03 ` James Morris
` (2 subsequent siblings)
3 siblings, 1 reply; 160+ messages in thread
From: Hua Zhong @ 2006-12-14 6:01 UTC (permalink / raw)
To: 'Martin J. Bligh', 'Linus Torvalds'
Cc: 'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
> I think allowing binary hardware drivers in userspace hurts
> our ability to leverage companies to release hardware specs.
If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 6:01 ` Hua Zhong
@ 2006-12-14 11:14 ` Alan
2006-12-14 11:31 ` Hans-Jürgen Koch
0 siblings, 1 reply; 160+ messages in thread
From: Alan @ 2006-12-14 11:14 UTC (permalink / raw)
To: Hua Zhong
Cc: 'Martin J. Bligh', 'Linus Torvalds',
'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
On Wed, 13 Dec 2006 22:01:15 -0800
"Hua Zhong" <hzhong@gmail.com> wrote:
> > I think allowing binary hardware drivers in userspace hurts
> > our ability to leverage companies to release hardware specs.
>
> If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?
The FUSE file system interface provides a clean disciplined interface
which allows an fs to live in user space. The uio layer (if its ever
fixed and cleaned up) provides some basic hooks that allow a user space
program to arbitarily control hardware and make a nasty undebuggable mess.
uio also doesn't handle hotplug, pci and other "small" matters.
Now if you wanted to make uio useful at minimum you would need
- PCI support
- The ability to mark sets of I/O addresses for the card as
"unmappable", "read only", "read-write", "any read/root write", "root
read/write"
- A proper IRQ handler
- A DMA interface
- The ability to describe sharing rules
Which actually is a description of the core of the DRM layer.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 11:14 ` Alan
@ 2006-12-14 11:31 ` Hans-Jürgen Koch
2006-12-14 12:42 ` Alan
0 siblings, 1 reply; 160+ messages in thread
From: Hans-Jürgen Koch @ 2006-12-14 11:31 UTC (permalink / raw)
To: Alan
Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds',
'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
Am Donnerstag, 14. Dezember 2006 12:14 schrieb Alan:
> On Wed, 13 Dec 2006 22:01:15 -0800
> "Hua Zhong" <hzhong@gmail.com> wrote:
>
> > > I think allowing binary hardware drivers in userspace hurts
> > > our ability to leverage companies to release hardware specs.
> >
> > If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground?
>
> The FUSE file system interface provides a clean disciplined interface
> which allows an fs to live in user space. The uio layer (if its ever
> fixed and cleaned up) provides some basic hooks that allow a user space
> program to arbitarily control hardware and make a nasty undebuggable mess.
You think it's easier for a manufacturer of industrial IO cards to
debug a (large) kernel module?
>
> uio also doesn't handle hotplug, pci and other "small" matters.
uio is supposed to be a very thin layer. Hotplug and PCI are already
handled by other subsystems.
>
> Now if you wanted to make uio useful at minimum you would need
>
The majority of industrial IO cards have registers and/or dual port RAM
that can be mapped to user space (even today). We want to add a simple
way to handle interrupts for such cards. That's all.
The fact that there might be some sort of hardware/interrupts/situations
where this is not possible or not so simple isn't that important at the
moment. We can extend the UIO system if somebody actually requires these
extensions.
Hans
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 11:31 ` Hans-Jürgen Koch
@ 2006-12-14 12:42 ` Alan
2006-12-14 12:54 ` Hans-Jürgen Koch
2006-12-14 12:55 ` Jan Engelhardt
0 siblings, 2 replies; 160+ messages in thread
From: Alan @ 2006-12-14 12:42 UTC (permalink / raw)
To: Hans-Jürgen Koch
Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds',
'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
On Thu, 14 Dec 2006 12:31:16 +0100
Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> You think it's easier for a manufacturer of industrial IO cards to
> debug a (large) kernel module?
You think its any easier to debug because the code now runs in ring 3 but
accessing I/O space.
> > uio also doesn't handle hotplug, pci and other "small" matters.
>
> uio is supposed to be a very thin layer. Hotplug and PCI are already
> handled by other subsystems.
And if you have a PCI or a hotplug card ? How many industrial I/O cards
are still ISA btw ?
Alan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 12:42 ` Alan
@ 2006-12-14 12:54 ` Hans-Jürgen Koch
2006-12-14 16:59 ` Greg KH
2006-12-14 12:55 ` Jan Engelhardt
1 sibling, 1 reply; 160+ messages in thread
From: Hans-Jürgen Koch @ 2006-12-14 12:54 UTC (permalink / raw)
To: Alan
Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds',
'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> On Thu, 14 Dec 2006 12:31:16 +0100
> Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> > You think it's easier for a manufacturer of industrial IO cards to
> > debug a (large) kernel module?
>
> You think its any easier to debug because the code now runs in ring 3 but
> accessing I/O space.
For the intended audience, yes.
>
>
> > > uio also doesn't handle hotplug, pci and other "small" matters.
> >
> > uio is supposed to be a very thin layer. Hotplug and PCI are already
> > handled by other subsystems.
>
> And if you have a PCI or a hotplug card ? How many industrial I/O cards
> are still ISA btw ?
Who is talking about ISA? All cards we had in mind are PCI. Of course
you have to do the usual initialization work in your probe/release or
init/exit functions. These are just a few lines you find in any
beginners device-driver-writing book. I don't think that the UIO
framework could simplify that in a sensible way.
Hans
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 12:54 ` Hans-Jürgen Koch
@ 2006-12-14 16:59 ` Greg KH
2006-12-14 18:26 ` Alan
0 siblings, 1 reply; 160+ messages in thread
From: Greg KH @ 2006-12-14 16:59 UTC (permalink / raw)
To: Hans-J??rgen Koch
Cc: Alan, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
On Thu, Dec 14, 2006 at 01:54:24PM +0100, Hans-J??rgen Koch wrote:
> Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan:
> > > > uio also doesn't handle hotplug, pci and other "small" matters.
> > >
> > > uio is supposed to be a very thin layer. Hotplug and PCI are already
> > > handled by other subsystems.
> >
> > And if you have a PCI or a hotplug card ? How many industrial I/O cards
> > are still ISA btw ?
>
> Who is talking about ISA? All cards we had in mind are PCI. Of course
> you have to do the usual initialization work in your probe/release or
> init/exit functions. These are just a few lines you find in any
> beginners device-driver-writing book. I don't think that the UIO
> framework could simplify that in a sensible way.
Agreed, you still have to write a kernel driver to handle the pci
probe/disconnect functions and the pci id stuff to use the uio core
properly. That's not in question here at all and please don't think
that uio even attempts to handle this, as that is not what it's job is.
Think of uio as just a "class" of driver, like input or v4l. It's still
up to the driver writer to provide a proper bus interface to the
hardware (pci, usb, etc.) in order for the device to work at all.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:59 ` Greg KH
@ 2006-12-14 18:26 ` Alan
2006-12-14 21:16 ` Greg KH
0 siblings, 1 reply; 160+ messages in thread
From: Alan @ 2006-12-14 18:26 UTC (permalink / raw)
To: Greg KH
Cc: Hans-J??rgen Koch, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
> Think of uio as just a "class" of driver, like input or v4l. It's still
> up to the driver writer to provide a proper bus interface to the
> hardware (pci, usb, etc.) in order for the device to work at all.
Understood. That leads me to ask another question of the folks who deal
with a lot of these cards. How many could reasonably be described by the
following
bar to map, offset, length, ro/rw, root/user, local-offset
(x n ?)
interrupt function or null
It seems if we have a lot of this kind of card that all fit that pattern
it might actually get more vendors submitting updates if we had a single
pci driver that took a struct of the above as the device_id field so
vendors had to write five lines of IRQ code, a struct and update a PCI
table ? That seems to have mostly worked with all the parallel/serial
boards.
Alan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:26 ` Alan
@ 2006-12-14 21:16 ` Greg KH
0 siblings, 0 replies; 160+ messages in thread
From: Greg KH @ 2006-12-14 21:16 UTC (permalink / raw)
To: Alan
Cc: Hans-J??rgen Koch, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Jonathan Corbet',
'Andrew Morton', 'Michael K. Edwards',
linux-kernel
On Thu, Dec 14, 2006 at 06:26:26PM +0000, Alan wrote:
> > Think of uio as just a "class" of driver, like input or v4l. It's still
> > up to the driver writer to provide a proper bus interface to the
> > hardware (pci, usb, etc.) in order for the device to work at all.
>
> Understood. That leads me to ask another question of the folks who deal
> with a lot of these cards. How many could reasonably be described by the
> following
>
> bar to map, offset, length, ro/rw, root/user, local-offset
> (x n ?)
> interrupt function or null
>
> It seems if we have a lot of this kind of card that all fit that pattern
> it might actually get more vendors submitting updates if we had a single
> pci driver that took a struct of the above as the device_id field so
> vendors had to write five lines of IRQ code, a struct and update a PCI
> table ? That seems to have mostly worked with all the parallel/serial
> boards.
I think that something like this might work out, and it would be a good
goal to get there eventually. But I would like to see a few drivers
using the uio core to see where we can consolidate things like this
first.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 12:42 ` Alan
2006-12-14 12:54 ` Hans-Jürgen Koch
@ 2006-12-14 12:55 ` Jan Engelhardt
2006-12-14 13:10 ` Arjan van de Ven
1 sibling, 1 reply; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 12:55 UTC (permalink / raw)
To: Alan
Cc: Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Greg KH',
'Jonathan Corbet', 'Andrew Morton',
'Michael K. Edwards',
linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 749 bytes --]
On Dec 14 2006 12:42, Alan wrote:
>On Thu, 14 Dec 2006 12:31:16 +0100
>Hans-Jürgen Koch <hjk@linutronix.de> wrote:
>> You think it's easier for a manufacturer of industrial IO cards to
>> debug a (large) kernel module?
>
>You think its any easier to debug because the code now runs in ring 3 but
>accessing I/O space.
A NULL fault won't oops the system, but of course the wrong inb/inw/inl() or
outb* can fubar the machine.
>> > uio also doesn't handle hotplug, pci and other "small" matters.
>>
>> uio is supposed to be a very thin layer. Hotplug and PCI are already
>> handled by other subsystems.
>
>And if you have a PCI or a hotplug card ? How many industrial I/O cards
>are still ISA btw ?
Something called PC104 out there.
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 12:55 ` Jan Engelhardt
@ 2006-12-14 13:10 ` Arjan van de Ven
2006-12-14 17:17 ` Jan Engelhardt
0 siblings, 1 reply; 160+ messages in thread
From: Arjan van de Ven @ 2006-12-14 13:10 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Alan, Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Greg KH',
'Jonathan Corbet', 'Andrew Morton',
'Michael K. Edwards',
linux-kernel
On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 12:42, Alan wrote:
> >On Thu, 14 Dec 2006 12:31:16 +0100
> >Hans-Jürgen Koch <hjk@linutronix.de> wrote:
> >> You think it's easier for a manufacturer of industrial IO cards to
> >> debug a (large) kernel module?
> >
> >You think its any easier to debug because the code now runs in ring 3 but
> >accessing I/O space.
>
> A NULL fault won't oops the system,
.. except when the userspace driver crashes as a result and then the hw
still crashes the hw (for example via an irq storm or by tying the PCI
bus or .. )
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 13:10 ` Arjan van de Ven
@ 2006-12-14 17:17 ` Jan Engelhardt
2006-12-17 10:54 ` Geert Uytterhoeven
0 siblings, 1 reply; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 17:17 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Alan, Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh',
'Linus Torvalds', 'Greg KH',
'Jonathan Corbet', 'Andrew Morton',
'Michael K. Edwards',
linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 768 bytes --]
On Dec 14 2006 14:10, Arjan van de Ven wrote:
>On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
>> >On Thu, 14 Dec 2006 12:31:16 +0100
>> >Hans-Jürgen Koch wrote:
>> >
>> >You think its any easier to debug because the code now runs in ring 3 but
>> >accessing I/O space.
>>
>> A NULL fault won't oops the system,
>
>.. except when the userspace driver crashes as a result and then the hw
>still crashes the hw (for example via an irq storm or by tying the PCI
>bus or .. )
hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers
(dangling references f.ex.)
However, if the userspace part is dead, no one acknowledges the irq, hence an
irq storm (if not caused by writing bogus stuff into registers) should not
happen.
>
>
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:17 ` Jan Engelhardt
@ 2006-12-17 10:54 ` Geert Uytterhoeven
0 siblings, 0 replies; 160+ messages in thread
From: Geert Uytterhoeven @ 2006-12-17 10:54 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Kernel Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1156 bytes --]
On Thu, 14 Dec 2006, Jan Engelhardt wrote:
> On Dec 14 2006 14:10, Arjan van de Ven wrote:
> >On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote:
> >> >On Thu, 14 Dec 2006 12:31:16 +0100
> >> >Hans-Jürgen Koch wrote:
> >> >
> >> >You think its any easier to debug because the code now runs in ring 3 but
> >> >accessing I/O space.
> >>
> >> A NULL fault won't oops the system,
> >
> >.. except when the userspace driver crashes as a result and then the hw
> >still crashes the hw (for example via an irq storm or by tying the PCI
> >bus or .. )
>
> hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers
> (dangling references f.ex.)
> However, if the userspace part is dead, no one acknowledges the irq, hence an
> irq storm (if not caused by writing bogus stuff into registers) should not
> happen.
Shared level IRQ?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 5:39 ` Martin J. Bligh
2006-12-14 6:01 ` Hua Zhong
@ 2006-12-14 8:03 ` James Morris
2006-12-14 15:39 ` Adrian Bunk
2006-12-14 13:07 ` Dave Jones
2006-12-14 14:12 ` Ben Collins
3 siblings, 1 reply; 160+ messages in thread
From: James Morris @ 2006-12-14 8:03 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Michael K. Edwards, linux-kernel
On Wed, 13 Dec 2006, Martin J. Bligh wrote:
> The point of banning binary drivers would be to leverage hardware
> companies into either releasing open source drivers, or the specs for
> someone else to write them.
IMHO, it's up to the users to decide if they want to keep buying hardware
which leads to inferior support, less reliability, decreased security and
all of the other ills associated with binary drivers. Let them also
choose distributions which enact the binary driver policies they agree
with.
Linux is precisely not about forcing people to do things.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 8:03 ` James Morris
@ 2006-12-14 15:39 ` Adrian Bunk
2006-12-14 20:08 ` David Schwartz
0 siblings, 1 reply; 160+ messages in thread
From: Adrian Bunk @ 2006-12-14 15:39 UTC (permalink / raw)
To: James Morris
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 03:03:10AM -0500, James Morris wrote:
> On Wed, 13 Dec 2006, Martin J. Bligh wrote:
>
> > The point of banning binary drivers would be to leverage hardware
> > companies into either releasing open source drivers, or the specs for
> > someone else to write them.
>
> IMHO, it's up to the users to decide if they want to keep buying hardware
> which leads to inferior support, less reliability, decreased security and
> all of the other ills associated with binary drivers. Let them also
> choose distributions which enact the binary driver policies they agree
> with.
>...
Unfortunately, we are living in an economic system with the strong
tendency to create oligopolys.
Situations with only 1-3 manufacturers you can choose from are quite
common (consider e.g. the 3D graphics market).
If you aren't a big company with big market power but a simple costumer
who needs such hardware you have zero choice if all manufactorers only
offer binary-only drivers at best.
And there's also the common misconception all costumers had enough
information when buying something. If you are a normal Linux user and
buy some hardware labelled "runs under Linux", it could turn out that's
with a Windows driver running under ndiswrapper...
> - James
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 15:39 ` Adrian Bunk
@ 2006-12-14 20:08 ` David Schwartz
2006-12-15 14:05 ` Paolo Ornati
2006-12-17 10:11 ` Geert Uytterhoeven
0 siblings, 2 replies; 160+ messages in thread
From: David Schwartz @ 2006-12-14 20:08 UTC (permalink / raw)
To: Linux-Kernel@Vger. Kernel. Org
> And there's also the common misconception all costumers had enough
> information when buying something. If you are a normal Linux user and
> buy some hardware labelled "runs under Linux", it could turn out that's
> with a Windows driver running under ndiswrapper...
That is something that I think is well worth fixing. Doesn't Linus own the
trademark 'Linux'? How about some rules for use of that trademark and a
'Works with Linux' logo that can only be used if the hardware specifications
are provided?
Let them provide a closed-source driver if they want. Let them provide
user-space applications for which no source is provided if they want. But
don't let them use the logo unless they release sufficient information to
allow people to develop their own drivers and applications to interface with
the hardware.
That makes it clear that it's not about giving us the fruits of years of
your own work but that it's about enabling us to do our own work. (I would
have no objection to also requiring them to provide a minimal open-source
driver. I'm not trying to work out the exact terms here, just get the idea
out.)
DS
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 20:08 ` David Schwartz
@ 2006-12-15 14:05 ` Paolo Ornati
2006-12-17 10:11 ` Geert Uytterhoeven
1 sibling, 0 replies; 160+ messages in thread
From: Paolo Ornati @ 2006-12-15 14:05 UTC (permalink / raw)
To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org
On Thu, 14 Dec 2006 12:08:11 -0800
"David Schwartz" <davids@webmaster.com> wrote:
>
> That is something that I think is well worth fixing. Doesn't Linus own the
> trademark 'Linux'? How about some rules for use of that trademark and a
> 'Works with Linux' logo that can only be used if the hardware specifications
> are provided?
>
> Let them provide a closed-source driver if they want. Let them provide
> user-space applications for which no source is provided if they want. But
> don't let them use the logo unless they release sufficient information to
> allow people to develop their own drivers and applications to interface with
> the hardware.
This is the same I think, but not Linux specific:
http://wiki.duskglow.com/tiki-index.php?page=Open+Hardware+Foundation
------------------------------------------------------------------
P. Mc Namara 12 Jul 06: about the OHF foundation providing
"certificates" for hardware, I'd propose (...) levels.
* First, any company that pledges full and complete interface and
behavioral documentation for a device, any docs necessary to make the
device do everything it is designed to do, and makes it publicly
available under nothing more cumbersome than the basic copyright that
exists on all written works receives one certificate. Somebody else
used "community friendly" or something similar. I don't know what to
call it. Perhaps just "Open Documentation" (...)
* A company that contributes back to the community during the
development of a device get labeled "Community Supporter" or something
similar.
* A company that enters into a legal agreement to release the
entire RTL and supporting information for a project at a given point in
the future (far enough ahead to protect the companies commercial
viability) can get the "Open Hardware" certificate.
------------------------------------------------------------------
--
Paolo Ornati
Linux 2.6.18 on x86_64
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 20:08 ` David Schwartz
2006-12-15 14:05 ` Paolo Ornati
@ 2006-12-17 10:11 ` Geert Uytterhoeven
2006-12-17 10:56 ` Rafael J. Wysocki
` (2 more replies)
1 sibling, 3 replies; 160+ messages in thread
From: Geert Uytterhoeven @ 2006-12-17 10:11 UTC (permalink / raw)
To: David Schwartz; +Cc: Linux-Kernel@Vger. Kernel. Org
On Thu, 14 Dec 2006, David Schwartz wrote:
> > And there's also the common misconception all costumers had enough
> > information when buying something. If you are a normal Linux user and
> > buy some hardware labelled "runs under Linux", it could turn out that's
> > with a Windows driver running under ndiswrapper...
>
> That is something that I think is well worth fixing. Doesn't Linus own the
> trademark 'Linux'? How about some rules for use of that trademark and a
> 'Works with Linux' logo that can only be used if the hardware specifications
> are provided?
Exactly my thoughts...
> Let them provide a closed-source driver if they want. Let them provide
> user-space applications for which no source is provided if they want. But
> don't let them use the logo unless they release sufficient information to
> allow people to develop their own drivers and applications to interface with
> the hardware.
>
> That makes it clear that it's not about giving us the fruits of years of
> your own work but that it's about enabling us to do our own work. (I would
> have no objection to also requiring them to provide a minimal open-source
> driver. I'm not trying to work out the exact terms here, just get the idea
> out.)
Since `works with' may sound a bit too vague, something like
`LinuxFriendly(tm)', with a happy penguin logo?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-17 10:11 ` Geert Uytterhoeven
@ 2006-12-17 10:56 ` Rafael J. Wysocki
2006-12-19 12:57 ` Marek Wawrzyczny
2006-12-20 4:27 ` Steven Rostedt
2 siblings, 0 replies; 160+ messages in thread
From: Rafael J. Wysocki @ 2006-12-17 10:56 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: David Schwartz, Linux-Kernel@Vger. Kernel. Org
On Sunday, 17 December 2006 11:11, Geert Uytterhoeven wrote:
> On Thu, 14 Dec 2006, David Schwartz wrote:
> > > And there's also the common misconception all costumers had enough
> > > information when buying something. If you are a normal Linux user and
> > > buy some hardware labelled "runs under Linux", it could turn out that's
> > > with a Windows driver running under ndiswrapper...
> >
> > That is something that I think is well worth fixing. Doesn't Linus own the
> > trademark 'Linux'? How about some rules for use of that trademark and a
> > 'Works with Linux' logo that can only be used if the hardware specifications
> > are provided?
>
> Exactly my thoughts...
>
> > Let them provide a closed-source driver if they want. Let them provide
> > user-space applications for which no source is provided if they want. But
> > don't let them use the logo unless they release sufficient information to
> > allow people to develop their own drivers and applications to interface with
> > the hardware.
> >
> > That makes it clear that it's not about giving us the fruits of years of
> > your own work but that it's about enabling us to do our own work. (I would
> > have no objection to also requiring them to provide a minimal open-source
> > driver. I'm not trying to work out the exact terms here, just get the idea
> > out.)
>
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?
I like this idea.
Greetings,
Rafael
--
If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-17 10:11 ` Geert Uytterhoeven
2006-12-17 10:56 ` Rafael J. Wysocki
@ 2006-12-19 12:57 ` Marek Wawrzyczny
2006-12-19 13:56 ` Diego Calleja
2006-12-20 5:11 ` Valdis.Kletnieks
2006-12-20 4:27 ` Steven Rostedt
2 siblings, 2 replies; 160+ messages in thread
From: Marek Wawrzyczny @ 2006-12-19 12:57 UTC (permalink / raw)
To: linux-kernel
On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?
It would be really cool to see penguin logos on hardware :)
I had another, probably crazy idea. Would it be possible to utilize the
current vendor/device PCI ID database to create Linux friendliness matrix
site?
And if you let yourself get carried away, you can also imagine a little
multi-platform utility. It would run on a test system collecting PCI IDs
before submitting them to the site to get the system's overall Linux
friendliness rating.
In cases where the system contains devices which do not have entries in the
database, the system could look up and use the vendor's Linux friendliness
rating.
Something like that could really help end users to select the right system and
would reward those who do the right thing.
Cheers,
Marek Wawrzyczny
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 12:57 ` Marek Wawrzyczny
@ 2006-12-19 13:56 ` Diego Calleja
2006-12-19 16:46 ` Gene Heskett
2006-12-20 5:11 ` Valdis.Kletnieks
1 sibling, 1 reply; 160+ messages in thread
From: Diego Calleja @ 2006-12-19 13:56 UTC (permalink / raw)
To: Marek Wawrzyczny; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <marekw1977@yahoo.com.au> escribió:
> I had another, probably crazy idea. Would it be possible to utilize the
> current vendor/device PCI ID database to create Linux friendliness matrix
> site?
I've a script (attached) that looks into /lib/modules/`uname -r`/modules.pcimap,
looks up the IDs in the pci id database and print the real name. At least it shows
it's possible to know what devices are supported ...
[-- Attachment #2: list-kernel-hardware.py --]
[-- Type: text/x-python, Size: 2278 bytes --]
#!/usr/bin/python
def pciids_to_names(ids):
# Only the last four numbers of the ids have useful info
vendorid = ids[1][6:10]
deviceid = ids[2][6:10]
subvendorid = ids[3][6:10]
subdeviceid = ids[4][6:10]
result = [ids[0], "", "", "", "", ""]
pciids = open('/usr/share/misc/pci.ids', 'r')
# Search for vendor
for line in pciids:
if line[0] == "#" or line[0] == "C" or line[0] == "\t":
continue
if line[0:4] == vendorid:
result[1] = line[6:].strip() # Vendor name
break
if result[1] == "": # Vendor not found
return result
# Search for a device
for line in pciids:
if line[0] != "\t":
continue
if line[1:5] == deviceid:
result[2] = line[7:].strip() # Device name
break
# Search a subsystem name
for line in pciids:
if line[2:11] == subvendorid + " " + subdeviceid: # subsystem name
result[3] = line[12:].strip() # The subvendor and subdevice ids point to a _single_ subsystem name
break
# Search a class name
if ids[5][4:6] == "00" and ids[5][6:8] == "00" and ids[5][6:8] == "00":
pass # void class ids
else:
pciids.seek(0)
# Search a class name
for line in pciids:
if line[0] == "C":
if line[2:4] == ids[5][4:6]: # found class
result[4] = line[6:].strip() # appended class name
break
if result[4] == "": # class not found
return result
# Search subclass name
for line in pciids:
if line [1:3] == ids[5][6:8]:
result[5] = line[5:].strip()
break
return result
### Start of the code flow ###
import platform
pcimap = open('/lib/modules/' + platform.uname()[2] + '/modules.pcimap', 'r')
previousmodule = ""
for line in pcimap:
if line[0] == "#" or line[0] == " ": continue
data = line.split(None)
ret = pciids_to_names(data)
if ret[0] != previousmodule:
previousmodule = ret[0]
print "Driver: " + previousmodule
if ret[2] == "":
output = "\tDevice NOT found in the pciid database: " + repr(data)
else:
output = "\tDevice: " + ret[2] + " (deviceid " + data[2][6:] + "); made by " + ret[1] + " (vendorid " + data[1][6:] + ")"
if ret[3] != "": output += "; Subsystem: " + ret[3] + " (subsysid " + data[3][6:] + ":" + data[4][6:] + ")"
if ret[4] != "": output += "; Class: " + ret[4]
if ret[5] != "": output += "; Subclass: " + ret[5]
print output
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 13:56 ` Diego Calleja
@ 2006-12-19 16:46 ` Gene Heskett
2006-12-19 17:11 ` Bill Nottingham
2006-12-19 17:13 ` Diego Calleja
0 siblings, 2 replies; 160+ messages in thread
From: Gene Heskett @ 2006-12-19 16:46 UTC (permalink / raw)
To: linux-kernel; +Cc: Diego Calleja, Marek Wawrzyczny
On Tuesday 19 December 2006 08:56, Diego Calleja wrote:
>El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny
<marekw1977@yahoo.com.au> escribió:
>> I had another, probably crazy idea. Would it be possible to utilize
>> the current vendor/device PCI ID database to create Linux friendliness
>> matrix site?
>
>I've a script (attached) that looks into /lib/modules/`uname
> -r`/modules.pcimap, looks up the IDs in the pci id database and print
> the real name. At least it shows it's possible to know what devices are
> supported ...
FWIW:
[root@coyote src]# python list-kernel-hardware.py
Traceback (most recent call last):
File "list-kernel-hardware.py", line 70, in ?
ret = pciids_to_names(data)
File "list-kernel-hardware.py", line 11, in pciids_to_names
pciids = open('/usr/share/misc/pci.ids', 'r')
IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'
That file apparently doesn't exist on an FC6 i686 system
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 16:46 ` Gene Heskett
@ 2006-12-19 17:11 ` Bill Nottingham
2006-12-19 17:24 ` Gene Heskett
2006-12-19 17:13 ` Diego Calleja
1 sibling, 1 reply; 160+ messages in thread
From: Bill Nottingham @ 2006-12-19 17:11 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-kernel, Diego Calleja, Marek Wawrzyczny
Gene Heskett (gene.heskett@verizon.net) said:
> FWIW:
> [root@coyote src]# python list-kernel-hardware.py
> Traceback (most recent call last):
> File "list-kernel-hardware.py", line 70, in ?
> ret = pciids_to_names(data)
> File "list-kernel-hardware.py", line 11, in pciids_to_names
> pciids = open('/usr/share/misc/pci.ids', 'r')
> IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'
>
> That file apparently doesn't exist on an FC6 i686 system
s/misc/hwdata/ for FC and derivatives.
Bill
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 17:11 ` Bill Nottingham
@ 2006-12-19 17:24 ` Gene Heskett
0 siblings, 0 replies; 160+ messages in thread
From: Gene Heskett @ 2006-12-19 17:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Bill Nottingham, Diego Calleja, Marek Wawrzyczny
On Tuesday 19 December 2006 12:11, Bill Nottingham wrote:
>Gene Heskett (gene.heskett@verizon.net) said:
>> FWIW:
>> [root@coyote src]# python list-kernel-hardware.py
>> Traceback (most recent call last):
>> File "list-kernel-hardware.py", line 70, in ?
>> ret = pciids_to_names(data)
>> File "list-kernel-hardware.py", line 11, in pciids_to_names
>> pciids = open('/usr/share/misc/pci.ids', 'r')
>> IOError: [Errno 2] No such file or directory:
>> '/usr/share/misc/pci.ids'
>>
>> That file apparently doesn't exist on an FC6 i686 system
>
>s/misc/hwdata/ for FC and derivatives.
>
>Bill
Ah, thanks. Verbose isn't it?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 16:46 ` Gene Heskett
2006-12-19 17:11 ` Bill Nottingham
@ 2006-12-19 17:13 ` Diego Calleja
1 sibling, 0 replies; 160+ messages in thread
From: Diego Calleja @ 2006-12-19 17:13 UTC (permalink / raw)
To: Gene Heskett; +Cc: linux-kernel, Marek Wawrzyczny
El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett <gene.heskett@verizon.net> escribió:
> IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids'
>
> That file apparently doesn't exist on an FC6 i686 system
Indeed, I forgot to document that. Ubuntu has it there (package pciutils), and
update-pciids updates the file from http://pciids.sourceforge.net/pci.ids. So you
can download that file and change the path in the script.
Anyway, you can find the output at http://www.terra.es/personal/diegocg/list.txt
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-19 12:57 ` Marek Wawrzyczny
2006-12-19 13:56 ` Diego Calleja
@ 2006-12-20 5:11 ` Valdis.Kletnieks
2006-12-20 19:29 ` David Schwartz
2006-12-21 15:34 ` Marek Wawrzyczny
1 sibling, 2 replies; 160+ messages in thread
From: Valdis.Kletnieks @ 2006-12-20 5:11 UTC (permalink / raw)
To: Marek Wawrzyczny; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]
On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said:
> On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> > Since `works with' may sound a bit too vague, something like
> > `LinuxFriendly(tm)', with a happy penguin logo?
>
> It would be really cool to see penguin logos on hardware :)
The little Microsoft flag sticker that was on my Dell Latitude got
replaced with a sticker that has a Tux and 'linux inside' on it. :)
> I had another, probably crazy idea. Would it be possible to utilize the
> current vendor/device PCI ID database to create Linux friendliness matrix
> site?
>
> And if you let yourself get carried away, you can also imagine a little
> multi-platform utility. It would run on a test system collecting PCI IDs
> before submitting them to the site to get the system's overall Linux
> friendliness rating.
This is a can of worms, and then some. For instance, let's consider this
Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's
not the default graphics card on a Latitude D820. So what number do you
put in? Do you use:
a) the *default* graphics card
b) the one *I* have with the open-source driver
c) the same one, but with the NVidia binary driver?
(Remember that "users" have different criteria than "developers" - most
users would consider this entire thread "intellectual wanking", especially
since the patch that spawned it got withdrawn. And 'Frames Per Second'
trumps that stupid little 'P' in the oops message. Failure to understand
this mindset guarantees that your computation of a "friendliness rating"
is yet more intellectual wanking... ;)
Similar issues are involved with the wireless card - the Intel 3945 I
have isn't the default. Repeat for several different disk options, and
at least 4 or 5 different CD/ROM/DVD options. Add in the fact that Dell
often changes suppliers for disk and CD/DVD drives, and you have a nightmare
coming...
And then there's stuff on this machine that are *not* options, but don't
matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have
no idea how well it works. I don't care what it contributes to the score.
On the other hand, somebody who uses external Firewire disk enclosures may
be *very* concerned about it, but not care in the slightest about the wireless
card.
Bonus points for figuring out what to do with systems that have some chip
that's a supported XYZ driver, but wired up behind a squirrely bridge with
some totally bizarre IRQ allocation, so you end up with something that's
visible on lspci but not actually *usable* in any real sense of the term...
> Something like that could really help end users to select the right system and
> would reward those who do the right thing.
"You are trapped in a maze of twisty little configurations, all different..."
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-20 5:11 ` Valdis.Kletnieks
@ 2006-12-20 19:29 ` David Schwartz
2006-12-20 20:52 ` Valdis.Kletnieks
2006-12-21 15:34 ` Marek Wawrzyczny
1 sibling, 1 reply; 160+ messages in thread
From: David Schwartz @ 2006-12-20 19:29 UTC (permalink / raw)
To: Marek Wawrzyczny, valdis.kletnietks; +Cc: linux-kernel
> This is a can of worms, and then some. For instance, let's consider this
> Latitude. *THIS* one has an NVidia Quadro NVS 110M in it.
> However, that's
> not the default graphics card on a Latitude D820. So what number do you
> put in? Do you use:
> a) the *default* graphics card
> b) the one *I* have with the open-source driver
> c) the same one, but with the NVidia binary driver?
> Similar issues are involved with the wireless card - the Intel 3945 I
> have isn't the default. Repeat for several different disk options, and
> at least 4 or 5 different CD/ROM/DVD options. Add in the fact that Dell
> often changes suppliers for disk and CD/DVD drives, and you have
> a nightmare
> coming...
> And then there's stuff on this machine that are *not* options, but don't
> matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have
> no idea how well it works. I don't care what it contributes to the score.
> On the other hand, somebody who uses external Firewire disk enclosures may
> be *very* concerned about it, but not care in the slightest about
> the wireless
> card.
>
> Bonus points for figuring out what to do with systems that have some chip
> that's a supported XYZ driver, but wired up behind a squirrely bridge with
> some totally bizarre IRQ allocation, so you end up with something that's
> visible on lspci but not actually *usable* in any real sense of
> the term...
Let's not let the perfect be the enemy of the good. Remember, the goal is to
allow consumers to know whether or not their system's hardware
specifications are available. It's not about driver availability -- if the
hardware specifications are available and a driver is not, that's not the
hardware manufacturer's fault.
Linux is about *allowing* people to do things.
DS
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-20 19:29 ` David Schwartz
@ 2006-12-20 20:52 ` Valdis.Kletnieks
2006-12-20 21:10 ` alan
0 siblings, 1 reply; 160+ messages in thread
From: Valdis.Kletnieks @ 2006-12-20 20:52 UTC (permalink / raw)
To: davids; +Cc: Marek Wawrzyczny, valdis.kletnietks, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]
On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said:
> Let's not let the perfect be the enemy of the good. Remember, the goal is to
> allow consumers to know whether or not their system's hardware
> specifications are available. It's not about driver availability -- if the
> hardware specifications are available and a driver is not, that's not the
> hardware manufacturer's fault.
My point was "their system's hardware specifications" is, for some popular
vendors, a *very* fuzzy notion. You can't (for instance) say "specs are
available for a Dell Latitude D820" - there are configurations that specs are
available for, and configs that aren't. My D820 has an NVidia card in it - we
know the answer there. Do you give a different answer for a D820 that has the
Intel i950 graphics chipset instead?
Even more annoying, Dell often *changes* the vendor - the line item for the DVD
drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD).
Mine showed up with a Philips SDVD8820 - but it's possible that some other D820
will get some other vendor's DVD (I've seen 2 C820's ordered at the same time,
they showed up with 2 different vendor's "24X CD-RW/DVD"). It's possible that
some poor guy is going to get a D820 that has a DVD that we have a known
buggy driver for - what do we tell *them*?
It's *easy* to do a "semi-good" that tells you if there's drivers for the
hardware config you're running the program on. But there's 2 problems:
a) You probably already know the answer
b) By the time you can run the program, it's often too late....
So given those 2 points, what actual value-added info does this *give*, over
and above 'lspci' and friends? I suppose maybe for a install CD, it gives
a quick way to cleanly abort the install with a "Don't bother continuing
unless it's OK that your graphics/wireless/whatever won't work". On the
other hand, the installer should have a grasp on this *already*....
Perfect may be the enemy of the good, but the good is also the enemy of
stuff claiming to be good but misses on an important design goal...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-20 20:52 ` Valdis.Kletnieks
@ 2006-12-20 21:10 ` alan
0 siblings, 0 replies; 160+ messages in thread
From: alan @ 2006-12-20 21:10 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: davids, Marek Wawrzyczny, valdis.kletnietks, linux-kernel
On Wed, 20 Dec 2006, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said:
>
>> Let's not let the perfect be the enemy of the good. Remember, the goal is to
>> allow consumers to know whether or not their system's hardware
>> specifications are available. It's not about driver availability -- if the
>> hardware specifications are available and a driver is not, that's not the
>> hardware manufacturer's fault.
>
> My point was "their system's hardware specifications" is, for some popular
> vendors, a *very* fuzzy notion. You can't (for instance) say "specs are
> available for a Dell Latitude D820" - there are configurations that specs are
> available for, and configs that aren't. My D820 has an NVidia card in it - we
> know the answer there. Do you give a different answer for a D820 that has the
> Intel i950 graphics chipset instead?
>
> Even more annoying, Dell often *changes* the vendor - the line item for the DVD
> drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD).
> Mine showed up with a Philips SDVD8820 - but it's possible that some other D820
> will get some other vendor's DVD (I've seen 2 C820's ordered at the same time,
> they showed up with 2 different vendor's "24X CD-RW/DVD"). It's possible that
> some poor guy is going to get a D820 that has a DVD that we have a known
> buggy driver for - what do we tell *them*?
>
> It's *easy* to do a "semi-good" that tells you if there's drivers for the
> hardware config you're running the program on. But there's 2 problems:
>
> a) You probably already know the answer
> b) By the time you can run the program, it's often too late....
>
> So given those 2 points, what actual value-added info does this *give*, over
> and above 'lspci' and friends? I suppose maybe for a install CD, it gives
> a quick way to cleanly abort the install with a "Don't bother continuing
> unless it's OK that your graphics/wireless/whatever won't work". On the
> other hand, the installer should have a grasp on this *already*....
>
> Perfect may be the enemy of the good, but the good is also the enemy of
> stuff claiming to be good but misses on an important design goal...
Valid points, but they are almost more for the distribution than they are
for the kernel.
I have considered designing a routine for use in Annaconda or some other
installer that lists all the known hardware and how much of it will
actually work with that particular distro. I know some people will not
care, but many will. (Especially the people who ask "Will my machine work
with Linux".)
Many people do not know what they have in the way of hardware. They
bought a machine. What they were sold (or requested) and what they got
are usually two different things. They may know a few specifics, but they
are probably missing important details. (How many people know the model
of PCI chip in their machine? Or who made the IDE chipset? Or the
ethernet chipset on the motherboard?) For those of us that deal with
hardware every day, this is not as big of an issue as those who bought
something from Dell or HP and it arrived in a big box pre-assembled.
Is there some way to look at a kernel and determine what drivers are
"good" and those that are "less good"? (Other than ordering Alan Cox's
brain in a jar...) What needs to be known is the state of the driver for
kernel X where X maybe something current or woefully out of date.
Maybe instead of an EXPORT_GPL symbol we need a
EXPORT_THIS_DRIVER_IS_CRAP symbol.
--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-20 5:11 ` Valdis.Kletnieks
2006-12-20 19:29 ` David Schwartz
@ 2006-12-21 15:34 ` Marek Wawrzyczny
2006-12-21 16:43 ` Horst H. von Brand
2006-12-21 19:28 ` Valdis.Kletnieks
1 sibling, 2 replies; 160+ messages in thread
From: Marek Wawrzyczny @ 2006-12-21 15:34 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
On Wednesday 20 December 2006 16:11, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said:
> > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> > And if you let yourself get carried away, you can also imagine a little
> > multi-platform utility. It would run on a test system collecting PCI IDs
> > before submitting them to the site to get the system's overall Linux
> > friendliness rating.
>
> This is a can of worms, and then some. For instance, let's consider this
> Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's
> not the default graphics card on a Latitude D820. So what number do you
> put in? Do you use:
No, no, no... I was never proposing that. I was thinking of something more
along the lines of reporting back on open-source friendliness of
manufacturers of devices, and perhaps on the availability of open source
drivers for the devices. I am talking only about "detected" devices. The
database would never try and guess the vendor, model and variation of the
system.
> (Remember that "users" have different criteria than "developers" - most
> users would consider this entire thread "intellectual wanking", especially
> since the patch that spawned it got withdrawn. And 'Frames Per Second'
> trumps that stupid little 'P' in the oops message. Failure to understand
> this mindset guarantees that your computation of a "friendliness rating"
> is yet more intellectual wanking... ;)
I actually find that trying to obtain information about what hardware is/isn't
supported in Linux is actually quite difficult to obtain. The information
that's on the internet is either outdated or has not yet been written.
I was hoping to analyze the system's device information together with
driver/device information obtained from the kernel source itself to give
users a better (but not perhaps not as authoritative as I'd like to) picture
of what to expect.
> And then there's stuff on this machine that are *not* options, but don't
> matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have
> no idea how well it works. I don't care what it contributes to the score.
> On the other hand, somebody who uses external Firewire disk enclosures may
> be *very* concerned about it, but not care in the slightest about the
> wireless card.
Perhaps we just report on the individual devices then... forget the system
rating.
> Bonus points for figuring out what to do with systems that have some chip
> that's a supported XYZ driver, but wired up behind a squirrely bridge with
> some totally bizarre IRQ allocation, so you end up with something that's
> visible on lspci but not actually *usable* in any real sense of the term...
Hmmm... does this happen often? False results are definedly a show stopper.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-21 15:34 ` Marek Wawrzyczny
@ 2006-12-21 16:43 ` Horst H. von Brand
2006-12-21 19:28 ` Valdis.Kletnieks
1 sibling, 0 replies; 160+ messages in thread
From: Horst H. von Brand @ 2006-12-21 16:43 UTC (permalink / raw)
To: Marek Wawrzyczny; +Cc: Valdis.Kletnieks, linux-kernel
Marek Wawrzyczny <marekw1977@yahoo.com.au> wrote:
[...]
> No, no, no... I was never proposing that. I was thinking of something more
> along the lines of reporting back on open-source friendliness of
> manufacturers of devices, and perhaps on the availability of open source
> drivers for the devices. I am talking only about "detected" devices. The
> database would never try and guess the vendor, model and variation of the
> system.
This is a /massive/ ammount of effort, and the data required is hard to
come by before buying, so it is rather useless. What chip is in NetworkCard
675? In 675a? (yes, I've seen dLink cards called <foo> and <foo>+ which
were /radically/ different!). Yes, here you go to the computer store and
ask them to build you a machine from parts you specify. But it is far from
the common way to get a PC (those stores mostly cater to heavy-weight
gamers, many pieces have to be special ordered), and building a machine
that works OK with Linux is a two or three day exercise in hunting down
specifications for compatible pieces. Most folks wander into the next
department store and buy a PC. Mostly terrible crap, BTW.
Where this makes sense (printers!) the data is there, mostly up to date,
and accurate.
[...]
> I actually find that trying to obtain information about what hardware
> is/isn't supported in Linux is actually quite difficult to obtain. The
> information that's on the internet is either outdated or has not yet been
> written. I was hoping to analyze the system's device information
> together with driver/device information obtained from the kernel source
> itself to give users a better (but not perhaps not as authoritative as
> I'd like to) picture of what to expect.
There is just way too much hardware out there, and new pieces come out
every day. Then there are lots of integrators that buy chips and build PCI
cards. Sometimes cards with supported chips just don't work at all. Etc. It
is all over the map.
Besides, many times you don't find information on some piece of hardware it
is because it is dirt cheap stuff that has no chance of working, so nobody
even tried.
[...]
> > Bonus points for figuring out what to do with systems that have some chip
> > that's a supported XYZ driver, but wired up behind a squirrely bridge with
> > some totally bizarre IRQ allocation, so you end up with something that's
> > visible on lspci but not actually *usable* in any real sense of the term...
> Hmmm... does this happen often? False results are definedly a show
> stopper.
Not just for systems, even for individual cards.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-21 15:34 ` Marek Wawrzyczny
2006-12-21 16:43 ` Horst H. von Brand
@ 2006-12-21 19:28 ` Valdis.Kletnieks
2006-12-24 3:11 ` Horst H. von Brand
1 sibling, 1 reply; 160+ messages in thread
From: Valdis.Kletnieks @ 2006-12-21 19:28 UTC (permalink / raw)
To: Marek Wawrzyczny; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]
On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said:
>
> > And then there's stuff on this machine that are *not* options, but don't
> > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have
> > no idea how well it works. I don't care what it contributes to the score.
> > On the other hand, somebody who uses external Firewire disk enclosures may
> > be *very* concerned about it, but not care in the slightest about the
> > wireless card.
>
> Perhaps we just report on the individual devices then... forget the system
> rating.
OK, *that* I see as potentially useful - I frequently get handed older
boxen with strange gear in them, and need a way to figure out if I want to
install software, or cannibalize it for parts. Also helpful if a buddy has
a Frankintel box they build, and they want to know if they can install
something other than Windows....
Bonus points if it sees a card that has a known out-of-tree driver and
tells you where to find it and what its license status is (I just went
down that road with an Intel 3945)...
> > Bonus points for figuring out what to do with systems that have some chip
> > that's a supported XYZ driver, but wired up behind a squirrely bridge with
> > some totally bizarre IRQ allocation, so you end up with something that's
> > visible on lspci but not actually *usable* in any real sense of the term...
>
> Hmmm... does this happen often? False results are definedly a show stopper.
Oh, we see reports of squirrelly or downright confused hardware all the time
on this list. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-21 19:28 ` Valdis.Kletnieks
@ 2006-12-24 3:11 ` Horst H. von Brand
0 siblings, 0 replies; 160+ messages in thread
From: Horst H. von Brand @ 2006-12-24 3:11 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Marek Wawrzyczny, linux-kernel
Valdis.Kletnieks@vt.edu wrote:
> On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said:
[...]
> > Perhaps we just report on the individual devices then... forget the system
> > rating.
> OK, *that* I see as potentially useful - I frequently get handed older
> boxen with strange gear
== gear for which there is probably no documentation at all
> in them, and need a way to figure out if I want to
> install software,
LiveCD of your choice...
> or cannibalize it for parts. Also helpful if a buddy has
> a Frankintel box they build, and they want to know if they can install
> something other than Windows....
Same as above.
> Bonus points if it sees a card that has a known out-of-tree driver and
> tells you where to find it and what its license status is (I just went
> down that road with an Intel 3945)...
If in-tree driver is already a challange, out-of-tree is hopeless.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-17 10:11 ` Geert Uytterhoeven
2006-12-17 10:56 ` Rafael J. Wysocki
2006-12-19 12:57 ` Marek Wawrzyczny
@ 2006-12-20 4:27 ` Steven Rostedt
2 siblings, 0 replies; 160+ messages in thread
From: Steven Rostedt @ 2006-12-20 4:27 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: David Schwartz, Linux-Kernel@Vger. Kernel. Org
On Sun, 2006-12-17 at 11:11 +0100, Geert Uytterhoeven wrote:
> On Thu, 14 Dec 2006, David Schwartz wrote:
> > That makes it clear that it's not about giving us the fruits of years of
> > your own work but that it's about enabling us to do our own work. (I would
> > have no objection to also requiring them to provide a minimal open-source
> > driver. I'm not trying to work out the exact terms here, just get the idea
> > out.)
>
> Since `works with' may sound a bit too vague, something like
> `LinuxFriendly(tm)', with a happy penguin logo?
>
I've bought a couple of products lately that had the happy penguin logo
on it. Just to find out that they only applied a bare minimum
functionality of the device for Linux. If you want more, you need to
plug it into a Windows box.
Funny, if you own a Mac, it had the same problem. It had a little more
functionality than the Linux port, but still far from what they give for
Windows.
I like the Open Hardware thing that Paolo mentioned.
-- Steve
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 5:39 ` Martin J. Bligh
2006-12-14 6:01 ` Hua Zhong
2006-12-14 8:03 ` James Morris
@ 2006-12-14 13:07 ` Dave Jones
2006-12-14 15:05 ` Adrian Bunk
` (2 more replies)
2006-12-14 14:12 ` Ben Collins
3 siblings, 3 replies; 160+ messages in thread
From: Dave Jones @ 2006-12-14 13:07 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Michael K. Edwards, linux-kernel
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary drivers become pervasive. I don't want to see Linux destroyed
> like that.
Thing is, if kernel.org kernels get patched to disallow binary modules,
whats to stop Ubuntu (or anyone else) reverting that change in the
kernels they distribute ? The landscape doesn't really change much,
given that the majority of Linux end-users are probably running
distro kernels.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 13:07 ` Dave Jones
@ 2006-12-14 15:05 ` Adrian Bunk
2006-12-14 16:11 ` Dave Jones
2006-12-14 15:36 ` Martin J. Bligh
2006-12-14 17:20 ` Jan Engelhardt
2 siblings, 1 reply; 160+ messages in thread
From: Adrian Bunk @ 2006-12-14 15:05 UTC (permalink / raw)
To: Dave Jones, Martin J. Bligh, Linus Torvalds, Greg KH,
Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
>
> > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> > going. If we don't stand up at some point, and ban binary drivers, we
> > will, I fear, end up with an unsustainable ecosystem for Linux when
> > binary drivers become pervasive. I don't want to see Linux destroyed
> > like that.
>
> Thing is, if kernel.org kernels get patched to disallow binary modules,
> whats to stop Ubuntu (or anyone else) reverting that change in the
> kernels they distribute ? The landscape doesn't really change much,
> given that the majority of Linux end-users are probably running
> distro kernels.
If a kernel developer or a competitor sends a cease&desist letter to
such a distribution, the situation changes from a complicated "derived
work" discussion to a relatively clear "They circumvented a technical
measure to enforce the copyright.".
> Dave
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 15:05 ` Adrian Bunk
@ 2006-12-14 16:11 ` Dave Jones
2006-12-14 16:31 ` Olivier Galibert
0 siblings, 1 reply; 160+ messages in thread
From: Dave Jones @ 2006-12-14 16:11 UTC (permalink / raw)
To: Adrian Bunk
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote:
> > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> >
> > Thing is, if kernel.org kernels get patched to disallow binary modules,
> > whats to stop Ubuntu (or anyone else) reverting that change in the
> > kernels they distribute ? The landscape doesn't really change much,
> > given that the majority of Linux end-users are probably running
> > distro kernels.
>
> If a kernel developer or a competitor sends a cease&desist letter to
> such a distribution, the situation changes from a complicated "derived
> work" discussion to a relatively clear "They circumvented a technical
> measure to enforce the copyright.".
C&D's don't work that way. They can enforce "don't ship my code"
but not "ship my code, or else". The modification would be just like
any other thats allowable by the GPL.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:11 ` Dave Jones
@ 2006-12-14 16:31 ` Olivier Galibert
0 siblings, 0 replies; 160+ messages in thread
From: Olivier Galibert @ 2006-12-14 16:31 UTC (permalink / raw)
To: Dave Jones, Adrian Bunk, Martin J. Bligh, Linus Torvalds,
Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards,
linux-kernel
On Thu, Dec 14, 2006 at 11:11:33AM -0500, Dave Jones wrote:
> On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote:
> > If a kernel developer or a competitor sends a cease&desist letter to
> > such a distribution, the situation changes from a complicated "derived
> > work" discussion to a relatively clear "They circumvented a technical
> > measure to enforce the copyright.".
>
> C&D's don't work that way. They can enforce "don't ship my code"
> but not "ship my code, or else". The modification would be just like
> any other thats allowable by the GPL.
Careful here. The "technical measure" protection is something
unrelated to the copyright license itself. Cf the streambox vcr
lawsuit for instance (settled though) where not implementing the
handling of one bit that said "don't save to disk" in original code
seemed to be illegal.
OG.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 13:07 ` Dave Jones
2006-12-14 15:05 ` Adrian Bunk
@ 2006-12-14 15:36 ` Martin J. Bligh
2006-12-14 17:20 ` Jan Engelhardt
2 siblings, 0 replies; 160+ messages in thread
From: Martin J. Bligh @ 2006-12-14 15:36 UTC (permalink / raw)
To: Dave Jones, Martin J. Bligh, Linus Torvalds, Greg KH,
Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel
Dave Jones wrote:
> On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
>
> > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> > going. If we don't stand up at some point, and ban binary drivers, we
> > will, I fear, end up with an unsustainable ecosystem for Linux when
> > binary drivers become pervasive. I don't want to see Linux destroyed
> > like that.
>
> Thing is, if kernel.org kernels get patched to disallow binary modules,
> whats to stop Ubuntu (or anyone else) reverting that change in the
> kernels they distribute ? The landscape doesn't really change much,
> given that the majority of Linux end-users are probably running
> distro kernels.
I don't think they'd dare spit in our faces quite that directly.
They think binary modules are permissible because we don't seem to have
consistently stated an intent contradicting that - some individual
developers have, but ultimately Linus hasn't.
I'm not talking about any legal issues to do with derived works,
copyrights or licenses - a clear statement of intent is probably all
it'd take to tip the balance.
M.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 13:07 ` Dave Jones
2006-12-14 15:05 ` Adrian Bunk
2006-12-14 15:36 ` Martin J. Bligh
@ 2006-12-14 17:20 ` Jan Engelhardt
2 siblings, 0 replies; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 17:20 UTC (permalink / raw)
To: Dave Jones
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
> > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> > going. If we don't stand up at some point, and ban binary drivers, we
> > will, I fear, end up with an unsustainable ecosystem for Linux when
> > binary drivers become pervasive. I don't want to see Linux destroyed
> > like that.
>
>Thing is, if kernel.org kernels get patched to disallow binary modules,
>whats to stop Ubuntu (or anyone else) reverting that change in the
>kernels they distribute ? The landscape doesn't really change much,
>given that the majority of Linux end-users are probably running
>distro kernels.
And even if the distros don't change it (all legal issues aside), there's
probably some free user who repacks the distro kernel.
/me eyeballs myself...
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 5:39 ` Martin J. Bligh
` (2 preceding siblings ...)
2006-12-14 13:07 ` Dave Jones
@ 2006-12-14 14:12 ` Ben Collins
2006-12-14 15:10 ` James Courtier-Dutton
` (2 more replies)
3 siblings, 3 replies; 160+ messages in thread
From: Ben Collins @ 2006-12-14 14:12 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Michael K. Edwards, linux-kernel
On Wed, 2006-12-13 at 21:39 -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable ecosystem for Linux when
> binary drivers become pervasive. I don't want to see Linux destroyed
> like that.
Yes, people have been worried about this for years, and to my knowledge,
it seems like things have been getting better with drivers, not worse
(look at Intel). And yet, people want to enforce more and more
restrictions against binary-only drivers, when it appears that we are
already winning.
You can't talk about drivers that don't exist for Linux. Things like
bcm43xx aren't effected by this new restriction for GPL-only drivers.
There's no binary-only driver for it (ndiswrapper doesn't count). If the
hardware vendor doesn't want to write a driver for linux, you can't make
them. You can buy other hardware, but that's about it.
Here's the list of proprietary drivers that are in Ubuntu's restricted
modules package:
madwifi (closed hal implementation, being replaced in openhal)
fritz
ati
nvidia
ltmodem (does that even still work?)
ipw3945d (not a kernel module, but just the daemon)
In over a year that list has only grown by ipw3945d. None of our users
are asking for new proprietary drivers. Believe me, if they needed them,
I'd hear about it. We have more cases of new unsupported hardware than
we do of new hardware with binary-only drivers. This proposed
restriction doesn't fix that.
You know what I think hurts us more than anything? You know what
probably keeps companies from writing drivers or releasing specs? It's
because they know some non-paid kernel hackers out there will eventually
reverse engineer it and write the drivers for them. Free development,
and they didn't even have to release their precious specs.
Don't get me wrong, I'm not bashing reverse engineering, or writing our
own drivers. It's how Linux got started. But the problem isn't as narrow
as people would like to think. And proprietary code isn't a growing
problem. At best, it's just a distraction that will eventually go away
on it's own.
The whole hardware vendor landscape is showing this, and it's not
because we locked down the kernel, it's because we've shown how well we
play with others, and how easy it is to get along with the whole
community. Do we want to destroy this good will?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 14:12 ` Ben Collins
@ 2006-12-14 15:10 ` James Courtier-Dutton
2006-12-14 16:09 ` Dave Jones
2006-12-14 16:36 ` Ben Collins
2006-12-14 17:34 ` Jan Engelhardt
2006-12-14 19:29 ` Michael Buesch
2 siblings, 2 replies; 160+ messages in thread
From: James Courtier-Dutton @ 2006-12-14 15:10 UTC (permalink / raw)
To: Ben Collins
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
Ben Collins wrote:
>
> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
>
> madwifi (closed hal implementation, being replaced in openhal)
> fritz
> ati
> nvidia
> ltmodem (does that even still work?)
> ipw3945d (not a kernel module, but just the daemon)
>
More items will be added to that list soon.
E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
http://opensource.creative.com/
> In over a year that list has only grown by ipw3945d. None of our users
> are asking for new proprietary drivers. Believe me, if they needed them,
> I'd hear about it. We have more cases of new unsupported hardware than
> we do of new hardware with binary-only drivers. This proposed
> restriction doesn't fix that.
Is there a list of "new unsupported hardware" ?
Reverse engineering or datasheets is the only way out of that.
As Linux becomes more and more popular on the desktop, manufacturers
will start feeling the pain of Linux "unsupported hardware" and have to
back down and release datasheets. Ubuntu is helping a lot in that direction.
>
> You know what I think hurts us more than anything? You know what
> probably keeps companies from writing drivers or releasing specs? It's
> because they know some non-paid kernel hackers out there will eventually
> reverse engineer it and write the drivers for them. Free development,
> and they didn't even have to release their precious specs.
Well, once a device has been reverse engineered and GPLed, the specs are
then in public domain and the IP does not exist any more. It actually
helps the company release the specs once the information is already out
there. The company then sees less reason to hold onto their specs in the
first place, and tends to release them earlier next time.
>
> Don't get me wrong, I'm not bashing reverse engineering, or writing our
> own drivers. It's how Linux got started. But the problem isn't as narrow
> as people would like to think. And proprietary code isn't a growing
> problem. At best, it's just a distraction that will eventually go away
> on it's own.
>
I agree, as time goes by, more and more devices are reverse engineered
or the manufacturer finally sees sense and releases the specs/datasheets.
James
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 15:10 ` James Courtier-Dutton
@ 2006-12-14 16:09 ` Dave Jones
2006-12-14 16:36 ` Ben Collins
1 sibling, 0 replies; 160+ messages in thread
From: Dave Jones @ 2006-12-14 16:09 UTC (permalink / raw)
To: James Courtier-Dutton
Cc: Ben Collins, Martin J. Bligh, Linus Torvalds, Greg KH,
Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 03:10:57PM +0000, James Courtier-Dutton wrote:
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/
Wow. That wins 'most ironic hostname' award for 2006.
Thankfully onboard hardware is "good enough" for most end-users
these days, leaving just the high-end audio professionals in the lurch.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 15:10 ` James Courtier-Dutton
2006-12-14 16:09 ` Dave Jones
@ 2006-12-14 16:36 ` Ben Collins
1 sibling, 0 replies; 160+ messages in thread
From: Ben Collins @ 2006-12-14 16:36 UTC (permalink / raw)
To: James Courtier-Dutton
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, 2006-12-14 at 15:10 +0000, James Courtier-Dutton wrote:
> Ben Collins wrote:
> >
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> >
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
> > ati
> > nvidia
> > ltmodem (does that even still work?)
> > ipw3945d (not a kernel module, but just the daemon)
> >
>
> More items will be added to that list soon.
> E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007.
> http://opensource.creative.com/
I haven't even caught wind of this not being supported yet. No demand ==
no reason to include it when it does become available.
> > In over a year that list has only grown by ipw3945d. None of our users
> > are asking for new proprietary drivers. Believe me, if they needed them,
> > I'd hear about it. We have more cases of new unsupported hardware than
> > we do of new hardware with binary-only drivers. This proposed
> > restriction doesn't fix that.
>
> Is there a list of "new unsupported hardware" ?
> Reverse engineering or datasheets is the only way out of that.
> As Linux becomes more and more popular on the desktop, manufacturers
> will start feeling the pain of Linux "unsupported hardware" and have to
> back down and release datasheets. Ubuntu is helping a lot in that direction.
I've not kept a list. Would be non-trivial to go through the bug tracker
to find this info. Mostly it's things like webcams, and wacky little
hardware that starts cropping up in laptops.
> >
> > You know what I think hurts us more than anything? You know what
> > probably keeps companies from writing drivers or releasing specs? It's
> > because they know some non-paid kernel hackers out there will eventually
> > reverse engineer it and write the drivers for them. Free development,
> > and they didn't even have to release their precious specs.
>
> Well, once a device has been reverse engineered and GPLed, the specs are
> then in public domain and the IP does not exist any more. It actually
> helps the company release the specs once the information is already out
> there. The company then sees less reason to hold onto their specs in the
> first place, and tends to release them earlier next time.
Right, I think reverse engineering does help in that aspect. The other
aspect is that they now have a driver that sort of works for their
hardware. Most of the work is done, and they decide to help things along
to make it stable. So laying ground work like this can have advantages.
I think hardware vendors are a lot like users. Once they see the
advantages to opening up their drivers, they wonder why they didn't do
it a long time ago. Sort of like how users need that one push to use
Linux, and they start to wonder why they should go back to Windows.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 14:12 ` Ben Collins
2006-12-14 15:10 ` James Courtier-Dutton
@ 2006-12-14 17:34 ` Jan Engelhardt
2006-12-14 19:29 ` Michael Buesch
2 siblings, 0 replies; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 17:34 UTC (permalink / raw)
To: Ben Collins
Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
>You know what I think hurts us more than anything? You know what
>probably keeps companies from writing drivers or releasing specs? It's
>because they know some non-paid kernel hackers out there will eventually
>reverse engineer it and write the drivers for them. Free development,
>and they didn't even have to release their precious specs.
I don't get them either. If reverse-engineering will release their
precious trade secrets they wanted to protect by making the thing
closed, they could have just asked someone to write a linux driver
for free if they don't have the guts to actually pay
qualified/experienced developers.
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 14:12 ` Ben Collins
2006-12-14 15:10 ` James Courtier-Dutton
2006-12-14 17:34 ` Jan Engelhardt
@ 2006-12-14 19:29 ` Michael Buesch
2006-12-14 20:19 ` Ben Collins
2 siblings, 1 reply; 160+ messages in thread
From: Michael Buesch @ 2006-12-14 19:29 UTC (permalink / raw)
To: Ben Collins
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Michael K. Edwards, linux-kernel, Martin J. Bligh
On Thursday 14 December 2006 15:12, Ben Collins wrote:
> You can't talk about drivers that don't exist for Linux. Things like
> bcm43xx aren't effected by this new restriction for GPL-only drivers.
> There's no binary-only driver for it (ndiswrapper doesn't count). If the
> hardware vendor doesn't want to write a driver for linux, you can't make
> them. You can buy other hardware, but that's about it.
Not that is matters in this discussion, but there are binary Broadcom
43xx drivers for linux available.
> Here's the list of proprietary drivers that are in Ubuntu's restricted
> modules package:
>
> madwifi (closed hal implementation, being replaced in openhal)
> fritz
Well, that's not just one, right?
That's like, 10 or so for the different AVM cards.
I'm just estimating. Correct me, if I'm wrong.
(And if I didn't mention it yet; AVM binary drivers are
complete crap.)
> ati
> nvidia
> ltmodem (does that even still work?)
> ipw3945d (not a kernel module, but just the daemon)
> Don't get me wrong, I'm not bashing reverse engineering, or writing our
> own drivers. It's how Linux got started. But the problem isn't as narrow
> as people would like to think. And proprietary code isn't a growing
> problem. At best, it's just a distraction that will eventually go away
> on it's own.
Well, I _hope_ that, too.
--
Greetings Michael.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:29 ` Michael Buesch
@ 2006-12-14 20:19 ` Ben Collins
0 siblings, 0 replies; 160+ messages in thread
From: Ben Collins @ 2006-12-14 20:19 UTC (permalink / raw)
To: Michael Buesch
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Michael K. Edwards, linux-kernel, Martin J. Bligh
On Thu, 2006-12-14 at 20:29 +0100, Michael Buesch wrote:
> On Thursday 14 December 2006 15:12, Ben Collins wrote:
> > You can't talk about drivers that don't exist for Linux. Things like
> > bcm43xx aren't effected by this new restriction for GPL-only drivers.
> > There's no binary-only driver for it (ndiswrapper doesn't count). If the
> > hardware vendor doesn't want to write a driver for linux, you can't make
> > them. You can buy other hardware, but that's about it.
>
> Not that is matters in this discussion, but there are binary Broadcom
> 43xx drivers for linux available.
>
> > Here's the list of proprietary drivers that are in Ubuntu's restricted
> > modules package:
> >
> > madwifi (closed hal implementation, being replaced in openhal)
> > fritz
>
> Well, that's not just one, right?
> That's like, 10 or so for the different AVM cards.
> I'm just estimating. Correct me, if I'm wrong.
One driver, many variations of the chipset. That's true of most drivers.
> (And if I didn't mention it yet; AVM binary drivers are
> complete crap.)
Wont disagree with you there.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
2006-12-14 5:39 ` Martin J. Bligh
@ 2006-12-14 7:24 ` Jeffrey V. Merkey
2006-12-14 8:21 ` David Woodhouse
` (6 subsequent siblings)
8 siblings, 0 replies; 160+ messages in thread
From: Jeffrey V. Merkey @ 2006-12-14 7:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
Well said, and I agree with ALL of your statements contained in this
post. About damn time this was addressed.
Jeff
Linus Torvalds wrote:
>On Wed, 13 Dec 2006, Greg KH wrote:
>
>
>>Numerous kernel developers feel that loading non-GPL drivers into the
>>kernel violates the license of the kernel and their copyright. Because
>>of this, a one year notice for everyone to address any non-GPL
>>compatible modules has been set.
>>
>>
>
>Btw, I really think this is shortsighted.
>
>It will only result in _exactly_ the crap we were just trying to avoid,
>namely stupid "shell game" drivers that don't actually help anything at
>all, and move code into user space instead.
>
>What was the point again?
>
>Was the point to alienate people by showing how we're less about the
>technology than about licenses?
>
>Was the point to show that we think we can extend our reach past derived
>work boundaries by just saying so?
>
>The silly thing is, the people who tend to push most for this are the
>exact SAME people who say that the RIAA etc should not be able to tell
>people what to do with the music copyrights that they own, and that the
>DMCA is bad because it puts technical limits over the rights expressly
>granted by copyright law.
>
>Doesn't anybody else see that as being hypocritical?
>
>So it's ok when we do it, but bad when other people do it? Somehow I'm not
>surprised, but I still think it's sad how you guys are showing a marked
>two-facedness about this.
>
>The fact is, the reason I don't think we should force the issue is very
>simple: copyright law is simply _better_off_ when you honor the admittedly
>gray issue of "derived work". It's gray. It's not black-and-white. But
>being gray is _good_. Putting artificial black-and-white technical
>counter-measures is actually bad. It's bad when the RIAA does it, it's bad
>when anybody else does it.
>
>If a module arguably isn't a derived work, we simply shouldn't try to say
>that its authors have to conform to our worldview.
>
>We should make decisions on TECHNICAL MERIT. And this one is clearly being
>pushed on anything but.
>
>I happen to believe that there shouldn't be technical measures that keep
>me from watching my DVD or listening to my music on whatever device I damn
>well please. Fair use, man. But it should go the other way too: we should
>not try to assert _our_ copyright rules on other peoples code that wasn't
>derived from ours, or assert _our_ technical measures that keep people
>from combining things their way.
>
>If people take our code, they'd better behave according to our rules. But
>we shouldn't have to behave according to the RIAA rules just because we
>_listen_ to their music. Similarly, nobody should be forced to behave
>according to our rules just because they _use_ our system.
>
>There's a big difference between "copy" and "use". It's exatcly the same
>issue whether it's music or code. You can't re-distribute other peoples
>music (becuase it's _their_ copyright), but they shouldn't put limits on
>how you personally _use_ it (because it's _your_ life).
>
>Same goes for code. Copyright is about _distribution_, not about use. We
>shouldn't limit how people use the code.
>
>Oh, well. I realize nobody is likely going to listen to me, and everybody
>has their opinion set in stone.
>
>That said, I'm going to suggest that you people talk to your COMPANY
>LAWYERS on this, and I'm personally not going to merge that particular
>code unless you can convince the people you work for to merge it first.
>
>In other words, you guys know my stance. I'll not fight the combined
>opinion of other kernel developers, but I sure as hell won't be the first
>to merge this, and I sure as hell won't have _my_ tree be the one that
>causes this to happen.
>
>So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
>first. This is not something where we use my tree as a way to get it to
>other trees. This is something where the push had better come from the
>other direction.
>
>Because I think it's stupid. So use somebody else than me to push your
>political agendas, please.
>
> Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
2006-12-14 5:39 ` Martin J. Bligh
2006-12-14 7:24 ` Jeffrey V. Merkey
@ 2006-12-14 8:21 ` David Woodhouse
2006-12-14 11:25 ` Alan
` (2 more replies)
2006-12-14 9:34 ` James Courtier-Dutton
` (5 subsequent siblings)
8 siblings, 3 replies; 160+ messages in thread
From: David Woodhouse @ 2006-12-14 8:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> If a module arguably isn't a derived work, we simply shouldn't try to say
> that its authors have to conform to our worldview.
I wouldn't argue that _anyone_ else should be exposed to my worldview; I
think the Geneva Convention has something to say about cruel and unusual
punishments.
But I would ask that they honour the licence on the code I release, and
perhaps more importantly on the code I import from other GPL sources.
If they fail to do that under the 'honour system' then I'm not averse to
'enforcing' it by technical measures. (For some value of 'enforcement'
which is easy for them to patch out if their lawyers are _really_ sure
they'll win when I sue them, that is.)
That's the big difference I see between this and the RIAA case you
mention -- in the case of Linux refusing to load non-GPL modules, if the
user _really_ thinks they'll win in court they can just hack it to load
the offending modules again. We are giving a _very_ strong indication of
our intent, but we aren't actually _forcing_ it on them in quite the
same way. With DRM-crippled players and hardware it's not so easy to get
around.
I'm very much in favour of Greg's approach. Give 12 months warning and
then just prevent loading of non-GPL modules.
That way, we get back from the current "binary modules are the status
quo even though some people are currently psyching themselves up to sue
for it" to "binary modules are possible if you're _very_ sure of your
legal position and willing to defend it". I think that's a very good
thing to do.
> We should make decisions on TECHNICAL MERIT. And this one is clearly being
> pushed on anything but.
Not on my part. The thing that makes me _particularly_ vehement about
binary-only crap this week is a very much a technical issue -- in
particular, the fact that we had to do post-production board
modifications to shoot our wireless chip in the head when it goes AWOL,
because the code for it wasn't available to us.
It's come back time and time again -- closed code is undebuggable,
unportable, unimprovable, unworkable. It's a detriment to the whole
system. That's very much a _technical_ issue, to me.
For non-kernel code I'm happy enough to release what I write under a BSD
licence. I'll default to GPL but usually respond favourably to requests
to do otherwise. It _isn't_ a religious issue.
> Same goes for code. Copyright is about _distribution_, not about use.
> We shouldn't limit how people use the code.
And we don't need to. Aside from the fact that they can patch out the
check if they have a genuine need to, they can also mark their module as
GPL without consequences as long as they don't _distribute_ it. We still
don't limit their _use_ of it.
> Oh, well. I realize nobody is likely going to listen to me, and everybody
> has their opinion set in stone.
My opinion is fairly much set from all the times I've come up against
_technical_ issues, I'll admit. But I did listen, and I agree with what
you say about the RIAA 'enforcement'. But I do see that as _very_
different to our 'enforcement', because ours is so easy to patch out
it's more of a 'hint' than a lockdown.
> That said, I'm going to suggest that you people talk to your COMPANY
> LAWYERS on this, and I'm personally not going to merge that particular
> code unless you can convince the people you work for to merge it first.
We've already merged EXPORT_SYMBOL_GPL. Is there a difference other than
one of extent? What about just marking kmalloc as EXPORT_SYMBOL_GPL for
a start? :)
> In other words, you guys know my stance. I'll not fight the combined
> opinion of other kernel developers, but I sure as hell won't be the first
> to merge this, and I sure as hell won't have _my_ tree be the one that
> causes this to happen.
>
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first. This is not something where we use my tree as a way to get it to
> other trees. This is something where the push had better come from the
> other direction.
It's better to have a coherent approach, and for all of us to do it on
roughly the same timescale. Getting the distributions do so this is
going to be like herding cats -- having it upstream and letting it
trickle down is a much better approach, I think.
--
dwmw2
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 8:21 ` David Woodhouse
@ 2006-12-14 11:25 ` Alan
2006-12-14 14:53 ` Theodore Tso
2006-12-14 16:52 ` Linus Torvalds
2 siblings, 0 replies; 160+ messages in thread
From: Alan @ 2006-12-14 11:25 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, 14 Dec 2006 08:21:20 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> If they fail to do that under the 'honour system' then I'm not averse to
> 'enforcing' it by technical measures. (For some value of 'enforcement'
> which is easy for them to patch out if their lawyers are _really_ sure
> they'll win when I sue them, that is.)
There are specific rules against removal of technical measures *even if
the result is legal*. It is an offence in many countries thanks to the
RIAA lobbyists and their corrupt pet politicians to remove technical
measures applied to a -public domain- work.
So your argument doesn't fly.
> Not on my part. The thing that makes me _particularly_ vehement about
> binary-only crap this week is a very much a technical issue -- in
> particular, the fact that we had to do post-production board
> modifications to shoot our wireless chip in the head when it goes AWOL,
> because the code for it wasn't available to us.
Consider it an education process. Hopefully the contracts for the
chips/docs were watertight enough you can sue the offending supplier for
the total cost of the rework. If not then you are really complaining
about getting contract negotiations wrong.
> It's better to have a coherent approach, and for all of us to do it on
> roughly the same timescale. Getting the distributions do so this is
> going to be like herding cats -- having it upstream and letting it
> trickle down is a much better approach, I think.
I doubt any distribution but the FSF "purified" Debian (the one that has
no firmware so doesn't work) would do it.
Alan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 8:21 ` David Woodhouse
2006-12-14 11:25 ` Alan
@ 2006-12-14 14:53 ` Theodore Tso
2006-12-14 16:52 ` Linus Torvalds
2 siblings, 0 replies; 160+ messages in thread
From: Theodore Tso @ 2006-12-14 14:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
>But I would ask that they honour the licence on the code I release, and
>perhaps more importantly on the code I import from other GPL sources.
It's not a question of "honoring the license"; it's a matter of what
is the reach of the license, as it relates to derivitive works. It's
a complicated subject, and very dependent on the local law; certainly
in the U.S., when I asked a Law Professor from the MIT Sloan School of
Management, who specialized in IP issues about the FSF theory of GPL
contamination by dynamic linking, after I explained all the details of
how dynamic linking work, she told me that it would be "laughed out of
the courtroom".
Now, is that a legal opinion? No, because the facts of every single
case are different, and it was an opinion from someone over a decade
ago, and case law may have changed (although as far as I know, there
has been no court ruling directly on this particular point since
then).
The bottom line though is that it is not _nearly_ so clear as some
people would like to believe. There is a lot of gray --- and that's a
GOOD thing. If copyright contamination via dynamic linking was the
settled law of the land, then all of the Macintosh extensions that
people wrote --- WHICH WORK BY PATCHING THE OPERATING SYSTEM --- would
be illegal. And given how much Apple hated people implying that the
UI as handed down from the mountain by the great prophet Steve Jobs
wasn't good enough, would we really have wanted Apple hounding
developers with lawsuits just because "they weren't honoring the
license" by daring to patch MacOS, and extending the OS by linking in
their code?
And what about people who link in a debugger into the Microsoft HAL or
other Microsoft DLL's in order to reverse engineer USB drivers for
Linux or reverse engineer protocols for Samba --- that's dynamic
linking of a sort too --- should that be illegal as well? Imagine the
power that Microsoft could put into their EULA if copyright
contamination could be as easily achieved by dynamic linking.
Please, let's try to have a little sanity here,
- Ted
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 8:21 ` David Woodhouse
2006-12-14 11:25 ` Alan
2006-12-14 14:53 ` Theodore Tso
@ 2006-12-14 16:52 ` Linus Torvalds
2006-12-14 17:33 ` Jeff V. Merkey
2 siblings, 1 reply; 160+ messages in thread
From: Linus Torvalds @ 2006-12-14 16:52 UTC (permalink / raw)
To: David Woodhouse
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Thu, 14 Dec 2006, David Woodhouse wrote:
>
> But I would ask that they honour the licence on the code I release, and
> perhaps more importantly on the code I import from other GPL sources.
This is a total non-argument, and it doesn't get any betetr by being
mindlessly repeated over and over and over again.
The license on the code you released talked about "derived works".
Not "everything I want to".
If a module owner can argue successfully in a court of law that a binary
driver isn't a derived work, then the GPL simply DOES NOT COVER IT!
In other words, people CAN "honor the license" and still not be required
to put their code under the GPL.
And no, including one header file in order to compile against something
does not automatically make something a "derived work". It may, or it may
not. It really isn't up to you to decide whether it does (and notice how
I'm not saying that it's up to _me_ either!).
For example, all the same people who clamor for free software get
absolutely RABID about "fair use". Guess what "fair use" actually MEANS?
Think about it for a moment. It expressly _limits_ the right of copyright
authors to claim "derived work". So if you argue that anything that ever
includes your header file (but none of your code) and compiles against it
is a "derived work", then you are basically very close to arguing that
"fair use" does not exist.
Do you really want to argue that "everything that has touched anything
copyrighted AT ALL is a derived work"? Do you feel lucky, punk?
THAT is why I think this discussion is so hypocritical. Either you accept
that "fair use" and copyrights aren't black-and-white, or you don't.
If you think this is a black-and-white "copyright owners have all the
rights", then you're standing with the RIAA's and the MPAA's of the world.
Me, personally, I think the RIAA and the MPAA is a shithouse. They are
immoral. But guess what? They are immoral exactly _because_ they think
that they automatically own ALL the rights, just because they own the
copyright.
That is what it boils down to: copyright doesn't really give you "absolute
power". This is why I have been _consistently_ arguing that we're not
about "black and white" or "good against evil". It simply isn't that
simple.
I don't like binary modules. I refuse to support them, and if it turns out
that the module was written using Linux code, and just for Linux, I htink
that's a _clear_ copyright violation, and that binary module is obviously
a license violation.
But if the module was written for other systems, and just ported to Linux,
and not using our code, then it's very much debatable whether it's
actually a "derived work". Interfaces don't make "derived works" per se.
Now, is it something you could sue people over? Sure. I actually do
believe that it's very possible that a judge _would_ consider such a
module a derived work, and you can sue people. It probably depends on
circumstances too.
But don't you see the problem with a black-and-white technical measure?
Don't you see the problem with the DMCA and the DVD encryption?
Those kinds of things REMOVE the "reasonable thought" from the equation,
and turn a gradual process into a sharp "right or wrong" situation. AND
THAT IS WRONG. We simply do not LIVE in a world that is black and white.
So if you think somebody violates your copyright, send them a C&D letter,
and eventually take them to court. It's been done. Companies that mis-used
the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing.
I'm not arguing against that at all. What I'm arguing against is the
"blind belief" that you or I have the right to tell people what to do,
just because we own copyrights.
It's not a blind belief that I'm willing to subscribe to. Exactly because
I have _seen_ what that blind belief results in - crap like the DMCA and
the RIAA lawsuits.
Linus
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:52 ` Linus Torvalds
@ 2006-12-14 17:33 ` Jeff V. Merkey
2006-12-14 18:01 ` Martin J. Bligh
0 siblings, 1 reply; 160+ messages in thread
From: Jeff V. Merkey @ 2006-12-14 17:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver")
and our proprietary
non derived code we sell with our appliances. He is right, everyone else
should just accept
it and get on with life or cry linus a river.
Jeff
Linus Torvalds wrote:
>On Thu, 14 Dec 2006, David Woodhouse wrote:
>
>
>>But I would ask that they honour the licence on the code I release, and
>>perhaps more importantly on the code I import from other GPL sources.
>>
>>
>
>This is a total non-argument, and it doesn't get any betetr by being
>mindlessly repeated over and over and over again.
>
>The license on the code you released talked about "derived works".
>
>Not "everything I want to".
>
>If a module owner can argue successfully in a court of law that a binary
>driver isn't a derived work, then the GPL simply DOES NOT COVER IT!
>
>In other words, people CAN "honor the license" and still not be required
>to put their code under the GPL.
>
>And no, including one header file in order to compile against something
>does not automatically make something a "derived work". It may, or it may
>not. It really isn't up to you to decide whether it does (and notice how
>I'm not saying that it's up to _me_ either!).
>
>For example, all the same people who clamor for free software get
>absolutely RABID about "fair use". Guess what "fair use" actually MEANS?
>
>Think about it for a moment. It expressly _limits_ the right of copyright
>authors to claim "derived work". So if you argue that anything that ever
>includes your header file (but none of your code) and compiles against it
>is a "derived work", then you are basically very close to arguing that
>"fair use" does not exist.
>
>Do you really want to argue that "everything that has touched anything
>copyrighted AT ALL is a derived work"? Do you feel lucky, punk?
>
>THAT is why I think this discussion is so hypocritical. Either you accept
>that "fair use" and copyrights aren't black-and-white, or you don't.
>
>If you think this is a black-and-white "copyright owners have all the
>rights", then you're standing with the RIAA's and the MPAA's of the world.
>
>Me, personally, I think the RIAA and the MPAA is a shithouse. They are
>immoral. But guess what? They are immoral exactly _because_ they think
>that they automatically own ALL the rights, just because they own the
>copyright.
>
>That is what it boils down to: copyright doesn't really give you "absolute
>power". This is why I have been _consistently_ arguing that we're not
>about "black and white" or "good against evil". It simply isn't that
>simple.
>
>I don't like binary modules. I refuse to support them, and if it turns out
>that the module was written using Linux code, and just for Linux, I htink
>that's a _clear_ copyright violation, and that binary module is obviously
>a license violation.
>
>But if the module was written for other systems, and just ported to Linux,
>and not using our code, then it's very much debatable whether it's
>actually a "derived work". Interfaces don't make "derived works" per se.
>
>Now, is it something you could sue people over? Sure. I actually do
>believe that it's very possible that a judge _would_ consider such a
>module a derived work, and you can sue people. It probably depends on
>circumstances too.
>
>But don't you see the problem with a black-and-white technical measure?
>
>Don't you see the problem with the DMCA and the DVD encryption?
>
>Those kinds of things REMOVE the "reasonable thought" from the equation,
>and turn a gradual process into a sharp "right or wrong" situation. AND
>THAT IS WRONG. We simply do not LIVE in a world that is black and white.
>
>So if you think somebody violates your copyright, send them a C&D letter,
>and eventually take them to court. It's been done. Companies that mis-used
>the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing.
>I'm not arguing against that at all. What I'm arguing against is the
>"blind belief" that you or I have the right to tell people what to do,
>just because we own copyrights.
>
>It's not a blind belief that I'm willing to subscribe to. Exactly because
>I have _seen_ what that blind belief results in - crap like the DMCA and
>the RIAA lawsuits.
>
> Linus
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:33 ` Jeff V. Merkey
@ 2006-12-14 18:01 ` Martin J. Bligh
2006-12-14 18:12 ` Jeff V. Merkey
0 siblings, 1 reply; 160+ messages in thread
From: Martin J. Bligh @ 2006-12-14 18:01 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: Linus Torvalds, David Woodhouse, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
Jeff V. Merkey wrote:
>
> Again, I agree with EVERY statement Linus made here. We operate exactly
> as Linus describes, and
> legally, NO ONE can take us to task on GPL issues. We post patches of
> affected kernel code
> (albiet the code resembles what Linus describes as a "skeleton driver")
> and our proprietary
> non derived code we sell with our appliances.
Yeah, like this one?
ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch
@@ -1316,8 +1316,8 @@
mod->license_gplok = license_is_gpl_compatible(license);
if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
- printk(KERN_WARNING "%s: module license '%s' taints
kernel.\n",
- mod->name, license);
+// printk(KERN_WARNING "%s: module license '%s' taints
kernel.\n",
+// mod->name, license);
add_taint(TAINT_PROPRIETARY_MODULE);
}
}
@@ -1691,10 +1691,10 @@
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
- if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint(TAINT_PROPRIETARY_MODULE);
- if (strcmp(mod->name, "driverloader") == 0)
- add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "ndiswrapper") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);
+// if (strcmp(mod->name, "driverloader") == 0)
+// add_taint(TAINT_PROPRIETARY_MODULE);
/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:01 ` Martin J. Bligh
@ 2006-12-14 18:12 ` Jeff V. Merkey
2006-12-14 18:37 ` Linus Torvalds
0 siblings, 1 reply; 160+ messages in thread
From: Jeff V. Merkey @ 2006-12-14 18:12 UTC (permalink / raw)
To: Martin J. Bligh
Cc: Linus Torvalds, David Woodhouse, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
Martin J. Bligh wrote:
> Jeff V. Merkey wrote:
>
>>
>> Again, I agree with EVERY statement Linus made here. We operate
>> exactly as Linus describes, and
>> legally, NO ONE can take us to task on GPL issues. We post patches of
>> affected kernel code
>> (albiet the code resembles what Linus describes as a "skeleton
>> driver") and our proprietary
>> non derived code we sell with our appliances.
>
>
>
> Yeah, like this one?
Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
Jeff
>
> ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch
>
>
> @@ -1316,8 +1316,8 @@
>
> mod->license_gplok = license_is_gpl_compatible(license);
> if (!mod->license_gplok && !(tainted &
> TAINT_PROPRIETARY_MODULE)) {
> - printk(KERN_WARNING "%s: module license '%s' taints
> kernel.\n",
> - mod->name, license);
> +// printk(KERN_WARNING "%s: module license '%s' taints
> kernel.\n",
> +// mod->name, license);
> add_taint(TAINT_PROPRIETARY_MODULE);
> }
> }
> @@ -1691,10 +1691,10 @@
> /* Set up license info based on the info section */
> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>
> - if (strcmp(mod->name, "ndiswrapper") == 0)
> - add_taint(TAINT_PROPRIETARY_MODULE);
> - if (strcmp(mod->name, "driverloader") == 0)
> - add_taint(TAINT_PROPRIETARY_MODULE);
> +// if (strcmp(mod->name, "ndiswrapper") == 0)
> +// add_taint(TAINT_PROPRIETARY_MODULE);
> +// if (strcmp(mod->name, "driverloader") == 0)
> +// add_taint(TAINT_PROPRIETARY_MODULE);
>
> /* Set up MODINFO_ATTR fields */
> setup_modinfo(mod, sechdrs, infoindex);
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:12 ` Jeff V. Merkey
@ 2006-12-14 18:37 ` Linus Torvalds
2006-12-14 18:30 ` Jeff V. Merkey
0 siblings, 1 reply; 160+ messages in thread
From: Linus Torvalds @ 2006-12-14 18:37 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: Martin J. Bligh, David Woodhouse, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
>
> Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
No. That's really a purely technical thing.
You can still do whatever you want, but people who support the resulting
mess know that they shouldn't.
Linus
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:37 ` Linus Torvalds
@ 2006-12-14 18:30 ` Jeff V. Merkey
0 siblings, 0 replies; 160+ messages in thread
From: Jeff V. Merkey @ 2006-12-14 18:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin J. Bligh, David Woodhouse, Greg KH, Jonathan Corbet,
Andrew Morton, Michael K. Edwards, linux-kernel
Linus Torvalds wrote:
>On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
>
>
>>Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
>>
>>
>
>No. That's really a purely technical thing.
>
>
>
>
I'm not certain I understand what you mean here. Nasty messages using
the word "taint" is purely subjective.
(as is your opinion or anyone else's about the use of the word,
including my opinion). Based upon the way the GPL is worded, "taint"
actually goes the other way in legal circles when corporate attorneys
talk about using GPL code with non-GPL code.
i.e. "... If we use that linux code it will TAINT our development
process and CONTAMINATE and POULLTE our proprietary
development efforts with GPL code and we do not know the IP sources of
such code...".
You should change it to "non-GPL" rather than "tainted" since the use of
this word is actionable and inaccruate of reality.
Free GPL code is what it is. The GPL is the only thing that "taints" IP.
The use of the word is reversed. Also Linus, we do
open source and promote certain projects outside of the Linux Kernel --
and we fully support the GPL.
You can still do whatever you want, but people who support the resulting
mess know that they shouldn't.
BULLSHIT. I diagree and you are talking out of both sides of your mouth.
:-)
Jeff
> Linus
>
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (2 preceding siblings ...)
2006-12-14 8:21 ` David Woodhouse
@ 2006-12-14 9:34 ` James Courtier-Dutton
2006-12-24 11:57 ` Mark Hounschell
2006-12-14 10:49 ` Xavier Bestel
` (4 subsequent siblings)
8 siblings, 1 reply; 160+ messages in thread
From: James Courtier-Dutton @ 2006-12-14 9:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
Linus Torvalds wrote:
>
> On Wed, 13 Dec 2006, Greg KH wrote:
>> Numerous kernel developers feel that loading non-GPL drivers into the
>> kernel violates the license of the kernel and their copyright. Because
>> of this, a one year notice for everyone to address any non-GPL
>> compatible modules has been set.
>
> Btw, I really think this is shortsighted.
>
> It will only result in _exactly_ the crap we were just trying to avoid,
> namely stupid "shell game" drivers that don't actually help anything at
> all, and move code into user space instead.
>
> What was the point again?
>
> Was the point to alienate people by showing how we're less about the
> technology than about licenses?
>
> Was the point to show that we think we can extend our reach past derived
> work boundaries by just saying so?
>
> The silly thing is, the people who tend to push most for this are the
> exact SAME people who say that the RIAA etc should not be able to tell
> people what to do with the music copyrights that they own, and that the
> DMCA is bad because it puts technical limits over the rights expressly
> granted by copyright law.
>
> Doesn't anybody else see that as being hypocritical?
>
> So it's ok when we do it, but bad when other people do it? Somehow I'm not
> surprised, but I still think it's sad how you guys are showing a marked
> two-facedness about this.
>
> The fact is, the reason I don't think we should force the issue is very
> simple: copyright law is simply _better_off_ when you honor the admittedly
> gray issue of "derived work". It's gray. It's not black-and-white. But
> being gray is _good_. Putting artificial black-and-white technical
> counter-measures is actually bad. It's bad when the RIAA does it, it's bad
> when anybody else does it.
>
> If a module arguably isn't a derived work, we simply shouldn't try to say
> that its authors have to conform to our worldview.
>
> We should make decisions on TECHNICAL MERIT. And this one is clearly being
> pushed on anything but.
>
I agree with Linus on these points. The kernel should not be enforcing
these issues. Leave the lawyers to do that bit. If companies want to
play in the "Grey Area", then it is at their own risk. Binary drivers
are already difficult and expensive for the companies because they have
to keep updating them as we change the kernel versions. If they do open
source drivers, we update them for them as we change the kernel
versions, so it works out cheaper for the companies involved.
The open source community tends to be able to reverse engineer all
drivers eventually anyway in order to ensure compatibility with all
kernel versions and also ensure that the code is well reviewed and
therefore contains fewer security loopholes, e.g. Atheros Wireless open
source HAL. This also tends to make it rather pointless for companies to
do binary drivers, because all it does is delay the open source version
of the driver and increase the security risk to users. One other example
I have, is that I reverse engineered a sound card driver so that we had
an open source driver for it. Once I had manually documented the sound
card, so we had details of all the registers and how to use them, the
manufacturer finally sent the datasheet to me! A bit late really, but it
certainly did encourage the manufacturer to pass datasheets to
developers. I now have a large array of datasheets from this
manufacturer that save me having to reverse engineer other sound cards
in their range.
Making binary drivers is therefore not a viable way to protect IP. We
are slowly removing the excuses that companies can hide behind as
reasons for not releasing datasheets to open source driver developers.
James
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 9:34 ` James Courtier-Dutton
@ 2006-12-24 11:57 ` Mark Hounschell
2006-12-24 13:22 ` Sean
0 siblings, 1 reply; 160+ messages in thread
From: Mark Hounschell @ 2006-12-24 11:57 UTC (permalink / raw)
To: James Courtier-Dutton
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
James Courtier-Dutton wrote:
>
> I agree with Linus on these points. The kernel should not be enforcing
> these issues. Leave the lawyers to do that bit. If companies want to
> play in the "Grey Area", then it is at their own risk. Binary drivers
> are already difficult and expensive for the companies because they have
> to keep updating them as we change the kernel versions. If they do open
> source drivers, we update them for them as we change the kernel
> versions, so it works out cheaper for the companies involved.
>
Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
for us. The only way that happens is if they can get in the official
tree. I know just from monitoring this list that our drivers would never
be acceptable for inclusion in any "functional form". We open sourced
them purely out of respect for the way we know the community feels about
it.
It would cost more for us to make them acceptable for inclusion than it
does for us to just maintain them ourselves. I suspect that is true for
most vendor created drivers open source or not.
So kernel developers making the required changes as the kernel changes
is NO real incentive for any vendor to open source their drivers. Sorry.
If it were knowingly less difficult to actually get your drivers
included, that would be an incentive and then you original point would
hold as an additional incentive.
My humble $.02 worth
Regards
Mark
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-24 11:57 ` Mark Hounschell
@ 2006-12-24 13:22 ` Sean
2006-12-24 14:42 ` Mark Hounschell
0 siblings, 1 reply; 160+ messages in thread
From: Sean @ 2006-12-24 13:22 UTC (permalink / raw)
To: Mark Hounschell
Cc: James Courtier-Dutton, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Sun, 24 Dec 2006 06:57:58 -0500
Mark Hounschell <dmarkh@cfl.rr.com> wrote:
> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
> for us. The only way that happens is if they can get in the official
> tree. I know just from monitoring this list that our drivers would never
> be acceptable for inclusion in any "functional form". We open sourced
> them purely out of respect for the way we know the community feels about
> it.
That shows some class, thanks.
> It would cost more for us to make them acceptable for inclusion than it
> does for us to just maintain them ourselves. I suspect that is true for
> most vendor created drivers open source or not.
>
> So kernel developers making the required changes as the kernel changes
> is NO real incentive for any vendor to open source their drivers. Sorry.
>
> If it were knowingly less difficult to actually get your drivers
> included, that would be an incentive and then you original point would
> hold as an additional incentive.
Out of curiosity what specific technical issues in your driver code make
you think that it would be too expensive to whip them into shape for
inclusion?
Cheers,
Sean
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-24 13:22 ` Sean
@ 2006-12-24 14:42 ` Mark Hounschell
0 siblings, 0 replies; 160+ messages in thread
From: Mark Hounschell @ 2006-12-24 14:42 UTC (permalink / raw)
To: Sean
Cc: James Courtier-Dutton, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
Sean wrote:
> On Sun, 24 Dec 2006 06:57:58 -0500
> Mark Hounschell <dmarkh@cfl.rr.com> wrote:
>
>
>> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them
>> for us. The only way that happens is if they can get in the official
>> tree. I know just from monitoring this list that our drivers would never
>> be acceptable for inclusion in any "functional form". We open sourced
>> them purely out of respect for the way we know the community feels about
>> it.
>
> That shows some class, thanks.
>
>> It would cost more for us to make them acceptable for inclusion than it
>> does for us to just maintain them ourselves. I suspect that is true for
>> most vendor created drivers open source or not.
>>
>> So kernel developers making the required changes as the kernel changes
>> is NO real incentive for any vendor to open source their drivers. Sorry.
>>
>> If it were knowingly less difficult to actually get your drivers
>> included, that would be an incentive and then you original point would
>> hold as an additional incentive.
>
> Out of curiosity what specific technical issues in your driver code make
> you think that it would be too expensive to whip them into shape for
> inclusion?
>
> Cheers,
> Sean
>
Well just off the top of my head, one of our drivers directly mucks with
all the irq affinities (irq_desc) via a provided user land library call.
This single call forces all 'other' irqs to be serviced by all the
'other' processors. I know this would never fly in kernel. User land
/proc manipulation is not an option for us here.
We have another that absolutely requires the Bigphysarea patch. We
refuse to use "MEM=xxxx" and use a fixed address. Every installation
would require a special configuration and our 'end users' would have to
have some understanding of all that. We are also maintaining that patch
internally also. So this product (for full functionality with our not so
open source application) requires a special kernel to begin with. Other
than that this one might have a chance of inclusion. It only requires
the bigphysarea when used with this application. It will actually build
and work (basically) with or without it.
Another is actually somewhat tied to the one mentioned above in that
this one has to facilitate the ability of its card being able to to PIO
reads and writes to 'special locations' in userspace and to the SRAM
memory of the above card. Even when on different pci busses. I've looked
at some of the V4L drivers that also do this sort of thing and I'm
confused by how they are doing it so I'm almost certain that what we are
doing would be considered 'wrong'.
Then there is probably the biggest one of all. The coding style issue.
Don't get me wrong I understand and agree with what I've read about it.
Our drivers were written by hardware people. Or I should say they were
written by OUR hardware people. I can offend them because I am among
them. No offense intended to any of you invaluable hardware guys.
I see 6 months of full time work before I could even sanely ask what I
needed to do for inclusion. It seems easier to just try to keep up with
the changes.
I'm certain our company is not the only one in this situation. I see
many GPL external kernel drivers. Why?
Mark
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (3 preceding siblings ...)
2006-12-14 9:34 ` James Courtier-Dutton
@ 2006-12-14 10:49 ` Xavier Bestel
2006-12-14 13:04 ` Dave Jones
` (3 subsequent siblings)
8 siblings, 0 replies; 160+ messages in thread
From: Xavier Bestel @ 2006-12-14 10:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> That said, I'm going to suggest that you people talk to your COMPANY
> LAWYERS on this, and I'm personally not going to merge that particular
> code unless you can convince the people you work for to merge it first.
That's quoting material :) Who's your master, by Linus.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (4 preceding siblings ...)
2006-12-14 10:49 ` Xavier Bestel
@ 2006-12-14 13:04 ` Dave Jones
2006-12-14 13:46 ` Ben Collins
` (2 subsequent siblings)
8 siblings, 0 replies; 160+ messages in thread
From: Dave Jones @ 2006-12-14 13:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first.
You don't think I already get enough hatemail from binary-module users ? :)
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (5 preceding siblings ...)
2006-12-14 13:04 ` Dave Jones
@ 2006-12-14 13:46 ` Ben Collins
2006-12-14 17:21 ` Jan Engelhardt
2006-12-14 15:46 ` Jeff Garzik
2006-12-14 16:17 ` Adrian Bunk
8 siblings, 1 reply; 160+ messages in thread
From: Ben Collins @ 2006-12-14 13:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> first. This is not something where we use my tree as a way to get it to
> other trees. This is something where the push had better come from the
> other direction.
I can probably speak for Ubuntu in saying we wont include any sort of
patch like this unless it's forced on us.
I have to agree with your your whole statement. The gradual changes to
lock down kernel modules to a particular license(s) tends to mirror the
slow lock down of content (music/movies) that people complain about so
loudly. It's basically becoming DRM for code.
I don't think anyone ever expected technical mechanisms to be developed
to enforce the GPL. It's sort of counter intuitive to why the GPL
exists, which is to free the code.
Let the licenses and lawyers fight to protect the code. The code doesn't
need to do that itself. It's got better things to do.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 13:46 ` Ben Collins
@ 2006-12-14 17:21 ` Jan Engelhardt
2006-12-14 17:49 ` Ben Collins
0 siblings, 1 reply; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 17:21 UTC (permalink / raw)
To: Ben Collins
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
On Dec 14 2006 08:46, Ben Collins wrote:
>I have to agree with your your whole statement. The gradual changes to
>lock down kernel modules to a particular license(s) tends to mirror the
>slow lock down of content (music/movies) that people complain about so
>loudly. It's basically becoming DRM for code.
>
>I don't think anyone ever expected technical mechanisms to be developed
>to enforce the GPL. It's sort of counter intuitive to why the GPL
>exists, which is to free the code.
"""To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights"""
>Let the licenses and lawyers fight to protect the code. The code doesn't
>need to do that itself. It's got better things to do.
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:21 ` Jan Engelhardt
@ 2006-12-14 17:49 ` Ben Collins
0 siblings, 0 replies; 160+ messages in thread
From: Ben Collins @ 2006-12-14 17:49 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, 2006-12-14 at 18:21 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 08:46, Ben Collins wrote:
> >I have to agree with your your whole statement. The gradual changes to
> >lock down kernel modules to a particular license(s) tends to mirror the
> >slow lock down of content (music/movies) that people complain about so
> >loudly. It's basically becoming DRM for code.
> >
> >I don't think anyone ever expected technical mechanisms to be developed
> >to enforce the GPL. It's sort of counter intuitive to why the GPL
> >exists, which is to free the code.
>
> """To protect your rights, we need to make restrictions that forbid
> anyone to deny you these rights"""
>
> >Let the licenses and lawyers fight to protect the code. The code doesn't
> >need to do that itself. It's got better things to do.
And these restrictions are in the letter of the GPL, not the function
prototypes of my code. Anyone willing to write libgpl-enforcement?
I don't care if someone wants to take my code and blatantly make use of
it in their own projects. I encourage it. I wrote it so people could do
whatever the hell they wanted to with it. It's when that project is made
available to others where I expect the GPL to enforce my copyrights and
licenses. I don't expect my code to be self checking for it, and then
add conditions that this portion of the code cannot be removed, because
then it isn't really GPL anymore, because then it isn't really free
either.
Maybe people will be happy if it ends up like this:
Booting Linux...
Please insert your original GNU/Linux source CD...
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (6 preceding siblings ...)
2006-12-14 13:46 ` Ben Collins
@ 2006-12-14 15:46 ` Jeff Garzik
2006-12-14 17:03 ` Linus Torvalds
2006-12-14 16:17 ` Adrian Bunk
8 siblings, 1 reply; 160+ messages in thread
From: Jeff Garzik @ 2006-12-14 15:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
Linus Torvalds wrote:
> Because I think it's stupid. So use somebody else than me to push your
> political agendas, please.
ACK, I agree completely. I think its a silly, political, non-technical
decision being pushed here.
For the record, I also disagree with the sneaky backdoor way people want
to add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.
EXPORT_SYMBOL_GPL() is more to emphasize that certain symbols are more
'internal' or frequently changed, and therefore use of them would imply
you are using a derived work of the kernel. EXPORT_SYMBOL_GPL() is
/not/ a place for political activism either.
Jeff
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 15:46 ` Jeff Garzik
@ 2006-12-14 17:03 ` Linus Torvalds
2006-12-14 17:08 ` Chris Wedgwood
0 siblings, 1 reply; 160+ messages in thread
From: Linus Torvalds @ 2006-12-14 17:03 UTC (permalink / raw)
To: Jeff Garzik
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Thu, 14 Dec 2006, Jeff Garzik wrote:
>
> For the record, I also disagree with the sneaky backdoor way people want to
> add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.
I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done
properly (and I think we use it fairly well).
I think we _can_ do things where we give clear hints to people that "we
think this is such an internal Linux thing that you simply cannot use this
without being considered a derived work".
It's really just a strong hint about what we consider to be internal. The
fact is, "intent" actually does matter, and as such our _intent_ in saying
"these are very deep and internal interfaces" is actually meaningful -
even in a court of law.
So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure",
I see it as being "documentation".
That said, I think that some people seem to be a bit over-eager to use it.
And I actually think that weakens the rest of them too (imagine a lawyer
saying in front of a judge:
"Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd,
but look, it's a standard function available everywhere else too, and
you can implement it as one line of code, so a module that uses it
clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not
something that means anything"
So this is why I've actually argued in the past for some
EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly
because over-using them actually _weakens_ them, and makes them pointless
both from a documentation _and_ from a legal standpoint.
Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal
sense and has actually made people happier, for what its worth. Of course,
you can get <n*2> different opinions from <n> lawyers, so that may not be
all that meaningful ;)
Linus
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:03 ` Linus Torvalds
@ 2006-12-14 17:08 ` Chris Wedgwood
2006-12-14 17:38 ` Christoph Hellwig
0 siblings, 1 reply; 160+ messages in thread
From: Chris Wedgwood @ 2006-12-14 17:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> done properly (and I think we use it fairly well).
>
> I think we _can_ do things where we give clear hints to people that
> "we think this is such an internal Linux thing that you simply
> cannot use this without being considered a derived work".
Then why not change the name to something more along those lines?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:08 ` Chris Wedgwood
@ 2006-12-14 17:38 ` Christoph Hellwig
2006-12-14 17:52 ` Chris Wedgwood
2006-12-17 10:57 ` Geert Uytterhoeven
0 siblings, 2 replies; 160+ messages in thread
From: Christoph Hellwig @ 2006-12-14 17:38 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
>
> > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> > done properly (and I think we use it fairly well).
> >
> > I think we _can_ do things where we give clear hints to people that
> > "we think this is such an internal Linux thing that you simply
> > cannot use this without being considered a derived work".
>
> Then why not change the name to something more along those lines?
Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:38 ` Christoph Hellwig
@ 2006-12-14 17:52 ` Chris Wedgwood
2006-12-14 18:09 ` Jan Engelhardt
2006-12-14 18:15 ` Eric Sandeen
2006-12-17 10:57 ` Geert Uytterhoeven
1 sibling, 2 replies; 160+ messages in thread
From: Chris Wedgwood @ 2006-12-14 17:52 UTC (permalink / raw)
To: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
linux-kernel
On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could support both during a transition and
migrate them over time).
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:52 ` Chris Wedgwood
@ 2006-12-14 18:09 ` Jan Engelhardt
2006-12-14 18:15 ` Eric Sandeen
1 sibling, 0 replies; 160+ messages in thread
From: Jan Engelhardt @ 2006-12-14 18:09 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
linux-kernel
On Dec 14 2006 09:52, Chris Wedgwood wrote:
>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>
>A quick grep shows that changing this now would require updating
>nearly 1900 instances, so patches to do this would be pretty large and
>disruptive (though we could support both during a transition and
>migrate them over time).
I'd prefer to do it at once. But that's not my decision so you anyway do what
you want.
That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL
is somehow contrary. Just a wording issue.
-`J'
--
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:52 ` Chris Wedgwood
2006-12-14 18:09 ` Jan Engelhardt
@ 2006-12-14 18:15 ` Eric Sandeen
2006-12-14 18:39 ` Chris Wedgwood
1 sibling, 1 reply; 160+ messages in thread
From: Eric Sandeen @ 2006-12-14 18:15 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
linux-kernel
Chris Wedgwood wrote:
> On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote:
>
>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
>
> A quick grep shows that changing this now would require updating
> nearly 1900 instances, so patches to do this would be pretty large and
> disruptive (though we could support both during a transition and
> migrate them over time).
Please don't use that name, it strikes me as much more confusing than
EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey
what it means, either.
EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least something
which is not internally inconsistent would be good (how is something
which is exported "internal?")
And, as long as EXPORT_SYMBOL_GPL continues to check that the module
using it has a GPL license, then it really -is- exactly descriptive of
what it's doing and probably shouldn't be changed. IIMHO.
-Eric
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:15 ` Eric Sandeen
@ 2006-12-14 18:39 ` Chris Wedgwood
2006-12-14 18:51 ` Linus Torvalds
2006-12-14 19:42 ` Scott Preece
0 siblings, 2 replies; 160+ messages in thread
From: Chris Wedgwood @ 2006-12-14 18:39 UTC (permalink / raw)
To: Eric Sandeen
Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
linux-kernel
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.
Calling internal symbols _INTERNAL is confusing?
> EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least
> something which is not internally inconsistent would be good (how is
> something which is exported "internal?")
But those symbols aren't, they're about internal interfaces that might
change.
> And, as long as EXPORT_SYMBOL_GPL continues to check that the module
> using it has a GPL license, then it really -is- exactly descriptive
> of what it's doing and probably shouldn't be changed. IIMHO.
Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about
documenting things, why restrict who can use them based on the
license?
Surely the licence is more about tainting the kernel and debugging not
politics?
Do we even need to check the license at all in that case? Maybe a
better idea would be to embed where the source code is located and use
the non-existence of that for a tainting?
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:39 ` Chris Wedgwood
@ 2006-12-14 18:51 ` Linus Torvalds
2006-12-14 19:42 ` Scott Preece
1 sibling, 0 replies; 160+ messages in thread
From: Linus Torvalds @ 2006-12-14 18:51 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Eric Sandeen, Christoph Hellwig, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
linux-kernel
On Thu, 14 Dec 2006, Chris Wedgwood wrote:
>
> Calling internal symbols _INTERNAL is confusing?
Well, I'm not sure the _INTERNAL name is all that much better than the
_GPL one.
In many ways, the _GPL one describes the _effects_ better, and also points
out the reason _why_ something is marked differently. Sure, it's marked
becasue it's internal, but why is does that have to be pointed out at all?
Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part,
ie the expectation that internal symbols are so internal that they have
license effects.
And if you were an external vendor doing binary only modules, would you
react to "internal"? It wouldn't have the same "oh, _that_ is what it is
all about" thing, would it?
So I do agree that we have probably done a bad job of explaining why that
_GPL thing makes sense, and what it means on a deeper level (the license
thing is a very superficial thing, but its worth naming just because the
superficial thing is also the biggest _impact_ - even if it may not be the
underlying deeper _reason_ for it).
So which makes more sense from a naming standpoint: the superficial impact
that is what _matters_ for people, or the more subtle issue that causes it
to have that impact?
I think that question is what it boils down to, and at least personally,
while I see both things as being worthwhile, I think the superficial thing
is the one that needs pointing out, because it's the one that may change
your behaviour (while the deeper _meaning_ is more of just an
explanation).
But I don't personally care that deeply. I mostly care about the fact that
changing the name now would just be inconvenient and unnecessary churn,
and that's probably my biggest reason to not want to do it ;)
Linus
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 18:39 ` Chris Wedgwood
2006-12-14 18:51 ` Linus Torvalds
@ 2006-12-14 19:42 ` Scott Preece
2006-12-14 19:34 ` Jeff V. Merkey
2006-12-14 19:49 ` Hua Zhong
1 sibling, 2 replies; 160+ messages in thread
From: Scott Preece @ 2006-12-14 19:42 UTC (permalink / raw)
To: Chris Wedgwood
Cc: Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik,
Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
>
> > Please don't use that name, it strikes me as much more confusing
> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> > convey what it means, either.
>
> Calling internal symbols _INTERNAL is confusing?
I think it's the combination of "INTERNAL" and "EXPORT" that seems
contradictory - "If it's internal, why are you exporting it?"
I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the
meaning clearer, but I don't really think the gain is worth the pain.
Anybody using kernel interfaces ought to be able to figure it out.
>
> But those symbols aren't, they're about internal interfaces that might
> change.
Folks who think this is likely to make a difference in court might
want to look at
<http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a
litany of court cases that have rejected infringement claims where a
much sterner effort had been made to hide or block use of interfaces.
The article claims that courts have increasingly found that
interfacing your code to an existing work is not infringement,
regardless of what you have to work around to do it.
Of course, that's one author's reading of the case law and I'm sure
there are others who disagree, but it's something you'd want to keep
in mind in calculating the expected value of a suit...
scott
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:42 ` Scott Preece
@ 2006-12-14 19:34 ` Jeff V. Merkey
2006-12-15 10:13 ` Eduard Bloch
` (2 more replies)
2006-12-14 19:49 ` Hua Zhong
1 sibling, 3 replies; 160+ messages in thread
From: Jeff V. Merkey @ 2006-12-14 19:34 UTC (permalink / raw)
To: Scott Preece
Cc: Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds,
Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
This whole effort is pointless. This is the same kind of crap MICROSOFT
DOES to create incompatibilities
DELIBERATELY. The code is either FREE or its NOT FREE. If the code
is FREE then let it be. You can put whatever
you want in the code -- I will remove any such constructs, just like I
remove them frm Red Hat's releases when they put
in the same kind of deliberate breakage for anti-competitive reasons.
You can go and yell at Novell too, since they do the SAME THING with
their releases and mix their modules with Linux.
All someone has to do or say is.
"... I did not ever accept the GPL license with the FREE code I was
given. They said the code was FREE, and I took them
at their word. .."
FREE implies a transfer of ownsership and you also have to contend with
the Doctrine of Estoppel. i.e. if someone
has been using the code for over two years, and you have not brought a
cause of action, you are BARRED from doing so
under the Doctrine of Estoppel and statute of limitations.
Here's what that means so you can look it up:
http://en.wikigadugi.org/wiki/Estoppel
What Linus argued is that FREE means just that.
Jeff
Scott Preece wrote:
> On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
>
>> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
>>
>> > Please don't use that name, it strikes me as much more confusing
>> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
>> > convey what it means, either.
>>
>> Calling internal symbols _INTERNAL is confusing?
>
>
> I think it's the combination of "INTERNAL" and "EXPORT" that seems
> contradictory - "If it's internal, why are you exporting it?"
>
> I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the
> meaning clearer, but I don't really think the gain is worth the pain.
> Anybody using kernel interfaces ought to be able to figure it out.
>
>>
>> But those symbols aren't, they're about internal interfaces that might
>> change.
>
>
> Folks who think this is likely to make a difference in court might
> want to look at
> <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a
> litany of court cases that have rejected infringement claims where a
> much sterner effort had been made to hide or block use of interfaces.
> The article claims that courts have increasingly found that
> interfacing your code to an existing work is not infringement,
> regardless of what you have to work around to do it.
>
> Of course, that's one author's reading of the case law and I'm sure
> there are others who disagree, but it's something you'd want to keep
> in mind in calculating the expected value of a suit...
>
> scott
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:34 ` Jeff V. Merkey
@ 2006-12-15 10:13 ` Eduard Bloch
2006-12-15 17:44 ` Dave Neuer
2006-12-18 10:55 ` Eric W. Biederman
2 siblings, 0 replies; 160+ messages in thread
From: Eduard Bloch @ 2006-12-15 10:13 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig,
Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
#include <hallo.h>
* Jeff V. Merkey [Thu, Dec 14 2006, 12:34:52PM]:
>
> This whole effort is pointless. This is the same kind of crap MICROSOFT
> DOES to create incompatibilities
Just my 0.02€ - one of the things I wonder about is why eg. class*
interfaces has been replaced with something "protected" by GPL enforcing
macros. What is the point? Nobody wins. The access to the new fine-grained
system has been restricted for users, and distributors (yes, I maintain
a such module) have to work around this in-kernel restriction
and create cludges.
Greg (and others from the "every touch of my bits is a derivation of it
and I need to protect it" party) - what are you thinking? Do you
seriously think that such restrictions would help anyone? IMO protecting
the access to interfaces is an utterly stupid idea in the free software
world.
Eduard.
--
<Ref|ex> Geht 'n Mantafahrer zum Manta-Treffen.
Fragt: Fährt hier wer Manta
-- #Debian.DE
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:34 ` Jeff V. Merkey
2006-12-15 10:13 ` Eduard Bloch
@ 2006-12-15 17:44 ` Dave Neuer
2006-12-18 10:55 ` Eric W. Biederman
2 siblings, 0 replies; 160+ messages in thread
From: Dave Neuer @ 2006-12-15 17:44 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig,
Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On 12/14/06, Jeff V. Merkey <jmerkey@wolfmountaingroup.com> wrote:
>
> This whole effort is pointless. This is the same kind of crap MICROSOFT
> DOES to create incompatibilities
> DELIBERATELY. The code is either FREE or its NOT FREE.
>
> All someone has to do or say is.
>
> "... I did not ever accept the GPL license with the FREE code I was
> given. They said the code was FREE, and I took them
> at their word. .."
At which point, hopefully everyone in that courtroom besides the idiot
who says this knows the difference between a license and a contract.
If anyone doesn't, they can be referred to:
"5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License."
The code is free, as in "redistributable at no charge as long as you
adhere to the terms of the license."
Your estoppel argument seems too confused between laches, promissory
estoppel and statutes of limitations to even make sense of, sorry.
Dave
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:34 ` Jeff V. Merkey
2006-12-15 10:13 ` Eduard Bloch
2006-12-15 17:44 ` Dave Neuer
@ 2006-12-18 10:55 ` Eric W. Biederman
2006-12-18 17:05 ` Jeff V. Merkey
2 siblings, 1 reply; 160+ messages in thread
From: Eric W. Biederman @ 2006-12-18 10:55 UTC (permalink / raw)
To: Scott Preece, Chris Wedgwood, Christoph Hellwig, Linus Torvalds,
Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel, Jeff V. Merkey
Things we can say without being hypocrites and without getting into
legal theory:
Kernel modules without source, or that don't have a GPL compatible
license are inconsiderate and rude.
Please don't be rude.
Eric
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-18 10:55 ` Eric W. Biederman
@ 2006-12-18 17:05 ` Jeff V. Merkey
0 siblings, 0 replies; 160+ messages in thread
From: Jeff V. Merkey @ 2006-12-18 17:05 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Scott Preece, Chris Wedgwood, Christoph Hellwig, Linus Torvalds,
Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
Eric W. Biederman wrote:
>Things we can say without being hypocrites and without getting into
>legal theory:
>
>Kernel modules without source, or that don't have a GPL compatible
>license are inconsiderate and rude.
>
>
??????
>Please don't be rude.
>
>
???????
J
>Eric
>
>
>
^ permalink raw reply [flat|nested] 160+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:42 ` Scott Preece
2006-12-14 19:34 ` Jeff V. Merkey
@ 2006-12-14 19:49 ` Hua Zhong
1 sibling, 0 replies; 160+ messages in thread
From: Hua Zhong @ 2006-12-14 19:49 UTC (permalink / raw)
To: 'Scott Preece', 'Chris Wedgwood'
Cc: 'Eric Sandeen', 'Christoph Hellwig',
'Linus Torvalds', 'Jeff Garzik',
'Greg KH', 'Jonathan Corbet',
'Andrew Morton', 'Martin Bligh',
'Michael K. Edwards',
linux-kernel
I'd suggest putting a Documentation/GPL-Symbols to explain this.
Then in the "tainted" message, have a pointer to that documentation.
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Scott Preece
> Sent: Thursday, December 14, 2006 11:43 AM
> To: Chris Wedgwood
> Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff
> Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin
> Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org
> Subject: Re: GPL only modules [was Re: [GIT PATCH] more
> Driver core patches for 2.6.19]
>
> On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote:
> > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
> >
> > > Please don't use that name, it strikes me as much more confusing
> > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL
> doesn't quite
> > > convey what it means, either.
> >
> > Calling internal symbols _INTERNAL is confusing?
>
> I think it's the combination of "INTERNAL" and "EXPORT" that
> seems contradictory - "If it's internal, why are you exporting it?"
>
> I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would
> make the meaning clearer, but I don't really think the gain
> is worth the pain.
> Anybody using kernel interfaces ought to be able to figure it out.
>
> >
> > But those symbols aren't, they're about internal interfaces
> that might
> > change.
>
> Folks who think this is likely to make a difference in court
> might want to look at
> <http:www.linuxworld.com/news/2006/120806-closed-modules2.html
> > for a litany of court cases that have rejected infringement
> claims where a much sterner effort had been made to hide or
> block use of interfaces.
> The article claims that courts have increasingly found that
> interfacing your code to an existing work is not
> infringement, regardless of what you have to work around to do it.
>
> Of course, that's one author's reading of the case law and
> I'm sure there are others who disagree, but it's something
> you'd want to keep in mind in calculating the expected value
> of a suit...
>
> scott
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:38 ` Christoph Hellwig
2006-12-14 17:52 ` Chris Wedgwood
@ 2006-12-17 10:57 ` Geert Uytterhoeven
1 sibling, 0 replies; 160+ messages in thread
From: Geert Uytterhoeven @ 2006-12-17 10:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Chris Wedgwood, Linus Torvalds, Jeff Garzik, Greg KH,
Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards,
Linux Kernel Development
On Thu, 14 Dec 2006, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote:
> > On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> >
> > > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> > > done properly (and I think we use it fairly well).
> > >
> > > I think we _can_ do things where we give clear hints to people that
> > > "we think this is such an internal Linux thing that you simply
> > > cannot use this without being considered a derived work".
> >
> > Then why not change the name to something more along those lines?
>
> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
I find all those names confusing. If these special symbols are
GPL/INTERNAL/WHATEVER, what are the other exported symbols?
GPL -> Non-GPL?
INTERNAL -> External?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 4:15 ` Linus Torvalds
` (7 preceding siblings ...)
2006-12-14 15:46 ` Jeff Garzik
@ 2006-12-14 16:17 ` Adrian Bunk
2006-12-14 16:33 ` Alan
8 siblings, 1 reply; 160+ messages in thread
From: Adrian Bunk @ 2006-12-14 16:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh,
Michael K. Edwards, linux-kernel
On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote:
>...
> The fact is, the reason I don't think we should force the issue is very
> simple: copyright law is simply _better_off_ when you honor the admittedly
> gray issue of "derived work". It's gray. It's not black-and-white. But
> being gray is _good_. Putting artificial black-and-white technical
> counter-measures is actually bad. It's bad when the RIAA does it, it's bad
> when anybody else does it.
>...
One important question is:
Who gets in danger due to this grey area?
E.g. if I'd consider it important enough to stop Ubuntu from
distributing kernels and binary-only modules, I wouldn't try the
difficult task to take legal actions against a company located on the
Isle of Man.
The trick is to let a lawyer send cease and desist letters to people
distributing the infringing software for 1 Euro at Ebay.
The nice thing about cease and desist letters is that the one who
accepts one has to pay the > 1000 Euro costs for the lawyer for this
letter.
Another lucrative task for the lawer would be to send cease and desist
letters to people running mirrors located in Germany distributing the
infringing software.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:17 ` Adrian Bunk
@ 2006-12-14 16:33 ` Alan
2006-12-14 16:54 ` Adrian Bunk
2006-12-14 17:17 ` Theodore Tso
0 siblings, 2 replies; 160+ messages in thread
From: Alan @ 2006-12-14 16:33 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
> The trick is to let a lawyer send cease and desist letters to people
> distributing the infringing software for 1 Euro at Ebay.
Doesn't that sound even more like the music industry ? Pick on Grandma,
and people who've no clue about the issue. It's not the way to solve such
problems. The world does not need "The war on binary modules". Educate
people instead, and talk to vendors.
Save the atomic weapons for the people who are straight forward ripping
off work in routers, tvs and all sorts of appliances.
Alan
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:33 ` Alan
@ 2006-12-14 16:54 ` Adrian Bunk
2006-12-14 17:17 ` Theodore Tso
1 sibling, 0 replies; 160+ messages in thread
From: Adrian Bunk @ 2006-12-14 16:54 UTC (permalink / raw)
To: Alan
Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton,
Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people
> > distributing the infringing software for 1 Euro at Ebay.
>
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.
>
> Save the atomic weapons for the people who are straight forward ripping
> off work in routers, tvs and all sorts of appliances.
I'm not saying that I would do it, but it's the way how it would be
done if anyone would do it.
It's not about whether that would be good or bad, the point is that the
ones that will most likely be affected if anyone will ever take legal
actions will not be the big distributions but people selling their old
distributions on Ebay or people operating mirrors.
Cease and desist letters are a lucrative business for lawyers here in
Germany, and such grey areas are simply a timebomb waiting for lawyers
and/or people wanting to harm Linux to (ab)use them.
> Alan
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 16:33 ` Alan
2006-12-14 16:54 ` Adrian Bunk
@ 2006-12-14 17:17 ` Theodore Tso
2006-12-14 18:18 ` Alan
2006-12-14 19:51 ` Adrian Bunk
1 sibling, 2 replies; 160+ messages in thread
From: Theodore Tso @ 2006-12-14 17:17 UTC (permalink / raw)
To: Alan
Cc: Adrian Bunk, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > The trick is to let a lawyer send cease and desist letters to people
> > distributing the infringing software for 1 Euro at Ebay.
>
> Doesn't that sound even more like the music industry ? Pick on Grandma,
> and people who've no clue about the issue. It's not the way to solve such
> problems. The world does not need "The war on binary modules". Educate
> people instead, and talk to vendors.
.... or like Microsoft, who is threatening to make war on end-users
instead of settling things with vendors. (One of the reasons why I
personally find the Microsoft promise not to sue _Novell_'s end users
so nasty. Microsoft shouldn't be threatening anyone's users; if they
have a problem, they should be taking it up with the relevant vendor,
not sueing innocent and relatively shallow-pocketed end-users and
distributors.)
One of the things that I find so interesting about how rabid people
get about enforcing GPL-only modules is how they start acting more and
more like the RIAA, MPAA, and Microsoft every day....
- Ted
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:17 ` Theodore Tso
@ 2006-12-14 18:18 ` Alan
2006-12-14 19:51 ` Adrian Bunk
1 sibling, 0 replies; 160+ messages in thread
From: Alan @ 2006-12-14 18:18 UTC (permalink / raw)
To: Theodore Tso
Cc: Adrian Bunk, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
> One of the things that I find so interesting about how rabid people
> get about enforcing GPL-only modules is how they start acting more and
> more like the RIAA, MPAA, and Microsoft every day....
There is a saying
"That which you fight you become"
It's a warning that is well worth heeding in a lot of situations
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 17:17 ` Theodore Tso
2006-12-14 18:18 ` Alan
@ 2006-12-14 19:51 ` Adrian Bunk
2006-12-21 15:38 ` Pavel Machek
1 sibling, 1 reply; 160+ messages in thread
From: Adrian Bunk @ 2006-12-14 19:51 UTC (permalink / raw)
To: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > The trick is to let a lawyer send cease and desist letters to people
> > > distributing the infringing software for 1 Euro at Ebay.
> >
> > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > and people who've no clue about the issue. It's not the way to solve such
> > problems. The world does not need "The war on binary modules". Educate
> > people instead, and talk to vendors.
>
> .... or like Microsoft, who is threatening to make war on end-users
> instead of settling things with vendors. (One of the reasons why I
> personally find the Microsoft promise not to sue _Novell_'s end users
> so nasty. Microsoft shouldn't be threatening anyone's users; if they
> have a problem, they should be taking it up with the relevant vendor,
> not sueing innocent and relatively shallow-pocketed end-users and
> distributors.)
>
> One of the things that I find so interesting about how rabid people
> get about enforcing GPL-only modules is how they start acting more and
> more like the RIAA, MPAA, and Microsoft every day....
Please don't think or imply I'd plan to do this, I'm only saying that
there's a risk for users in such grey areas.
It could be that someone who wants to harm Linux starts suing people
distributing Linux. If your goal is to harm Linux, suing users can
simply be much more effective than suing vendors...
It could even be that people distributing Linux could receive cease and
desist letters from people without any real interest in the issue
itself - "cease and desist letter"s are so frequent in Germany because
the people who have to sign them have to pay the lawyers' costs that are
usually > 1000 Euro, and that's a good business for the lawyers.
> - Ted
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-14 19:51 ` Adrian Bunk
@ 2006-12-21 15:38 ` Pavel Machek
2006-12-23 11:24 ` Adrian Bunk
0 siblings, 1 reply; 160+ messages in thread
From: Pavel Machek @ 2006-12-21 15:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > The trick is to let a lawyer send cease and desist letters to people
> > > > distributing the infringing software for 1 Euro at Ebay.
> > >
> > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > and people who've no clue about the issue. It's not the way to solve such
> > > problems. The world does not need "The war on binary modules". Educate
> > > people instead, and talk to vendors.
> >
> > .... or like Microsoft, who is threatening to make war on end-users
> > instead of settling things with vendors. (One of the reasons why I
> > personally find the Microsoft promise not to sue _Novell_'s end users
> > so nasty. Microsoft shouldn't be threatening anyone's users; if they
> > have a problem, they should be taking it up with the relevant vendor,
> > not sueing innocent and relatively shallow-pocketed end-users and
> > distributors.)
> >
> > One of the things that I find so interesting about how rabid people
> > get about enforcing GPL-only modules is how they start acting more and
> > more like the RIAA, MPAA, and Microsoft every day....
>
> Please don't think or imply I'd plan to do this, I'm only saying that
> there's a risk for users in such grey areas.
>
> It could be that someone who wants to harm Linux starts suing people
> distributing Linux. If your goal is to harm Linux, suing users can
> simply be much more effective than suing vendors...
>
> It could even be that people distributing Linux could receive cease and
> desist letters from people without any real interest in the issue
> itself - "cease and desist letter"s are so frequent in Germany because
> the people who have to sign them have to pay the lawyers' costs that are
> usually > 1000 Euro, and that's a good business for the lawyers.
Something is very wrong with German legal system, I'm afraid.
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-21 15:38 ` Pavel Machek
@ 2006-12-23 11:24 ` Adrian Bunk
2006-12-23 21:36 ` Pavel Machek
0 siblings, 1 reply; 160+ messages in thread
From: Adrian Bunk @ 2006-12-23 11:24 UTC (permalink / raw)
To: Pavel Machek
Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > The trick is to let a lawyer send cease and desist letters to people
> > > > > distributing the infringing software for 1 Euro at Ebay.
> > > >
> > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > and people who've no clue about the issue. It's not the way to solve such
> > > > problems. The world does not need "The war on binary modules". Educate
> > > > people instead, and talk to vendors.
> > >
> > > .... or like Microsoft, who is threatening to make war on end-users
> > > instead of settling things with vendors. (One of the reasons why I
> > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > so nasty. Microsoft shouldn't be threatening anyone's users; if they
> > > have a problem, they should be taking it up with the relevant vendor,
> > > not sueing innocent and relatively shallow-pocketed end-users and
> > > distributors.)
> > >
> > > One of the things that I find so interesting about how rabid people
> > > get about enforcing GPL-only modules is how they start acting more and
> > > more like the RIAA, MPAA, and Microsoft every day....
> >
> > Please don't think or imply I'd plan to do this, I'm only saying that
> > there's a risk for users in such grey areas.
> >
> > It could be that someone who wants to harm Linux starts suing people
> > distributing Linux. If your goal is to harm Linux, suing users can
> > simply be much more effective than suing vendors...
> >
> > It could even be that people distributing Linux could receive cease and
> > desist letters from people without any real interest in the issue
> > itself - "cease and desist letter"s are so frequent in Germany because
> > the people who have to sign them have to pay the lawyers' costs that are
> > usually > 1000 Euro, and that's a good business for the lawyers.
>
> Something is very wrong with German legal system, I'm afraid.
The point that you can take legal actions against anyone distributing
something that violates your rights should be present in more or less
all legal systems.
What might be special in Germany is only that you can demand your costs
after successfully taking legal actions.
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-23 11:24 ` Adrian Bunk
@ 2006-12-23 21:36 ` Pavel Machek
2006-12-24 1:07 ` Adrian Bunk
0 siblings, 1 reply; 160+ messages in thread
From: Pavel Machek @ 2006-12-23 21:36 UTC (permalink / raw)
To: Adrian Bunk
Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
> On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> > On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > > The trick is to let a lawyer send cease and desist letters to people
> > > > > > distributing the infringing software for 1 Euro at Ebay.
> > > > >
> > > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > > and people who've no clue about the issue. It's not the way to solve such
> > > > > problems. The world does not need "The war on binary modules". Educate
> > > > > people instead, and talk to vendors.
> > > >
> > > > .... or like Microsoft, who is threatening to make war on end-users
> > > > instead of settling things with vendors. (One of the reasons why I
> > > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they
> > > > have a problem, they should be taking it up with the relevant vendor,
> > > > not sueing innocent and relatively shallow-pocketed end-users and
> > > > distributors.)
> > > >
> > > > One of the things that I find so interesting about how rabid people
> > > > get about enforcing GPL-only modules is how they start acting more and
> > > > more like the RIAA, MPAA, and Microsoft every day....
> > >
> > > Please don't think or imply I'd plan to do this, I'm only saying that
> > > there's a risk for users in such grey areas.
> > >
> > > It could be that someone who wants to harm Linux starts suing people
> > > distributing Linux. If your goal is to harm Linux, suing users can
> > > simply be much more effective than suing vendors...
> > >
> > > It could even be that people distributing Linux could receive cease and
> > > desist letters from people without any real interest in the issue
> > > itself - "cease and desist letter"s are so frequent in Germany because
> > > the people who have to sign them have to pay the lawyers' costs that are
> > > usually > 1000 Euro, and that's a good business for the lawyers.
> >
> > Something is very wrong with German legal system, I'm afraid.
>
> The point that you can take legal actions against anyone distributing
> something that violates your rights should be present in more or less
> all legal systems.
>
> What might be special in Germany is only that you can demand your costs
> after successfully taking legal actions.
What is special in Germany is fact that any random lawyer can demand
$1000 (not his cost, his profit) if you distribute code that is not
his...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
2006-12-23 21:36 ` Pavel Machek
@ 2006-12-24 1:07 ` Adrian Bunk
0 siblings, 0 replies; 160+ messages in thread
From: Adrian Bunk @ 2006-12-24 1:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet,
Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel
On Sat, Dec 23, 2006 at 10:36:02PM +0100, Pavel Machek wrote:
> On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
> > On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote:
> > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote:
> > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
> > > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote:
> > > > > > > The trick is to let a lawyer send cease and desist letters to people
> > > > > > > distributing the infringing software for 1 Euro at Ebay.
> > > > > >
> > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma,
> > > > > > and people who've no clue about the issue. It's not the way to solve such
> > > > > > problems. The world does not need "The war on binary modules". Educate
> > > > > > people instead, and talk to vendors.
> > > > >
> > > > > .... or like Microsoft, who is threatening to make war on end-users
> > > > > instead of settling things with vendors. (One of the reasons why I
> > > > > personally find the Microsoft promise not to sue _Novell_'s end users
> > > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they
> > > > > have a problem, they should be taking it up with the relevant vendor,
> > > > > not sueing innocent and relatively shallow-pocketed end-users and
> > > > > distributors.)
> > > > >
> > > > > One of the things that I find so interesting about how rabid people
> > > > > get about enforcing GPL-only modules is how they start acting more and
> > > > > more like the RIAA, MPAA, and Microsoft every day....
> > > >
> > > > Please don't think or imply I'd plan to do this, I'm only saying that
> > > > there's a risk for users in such grey areas.
> > > >
> > > > It could be that someone who wants to harm Linux starts suing people
> > > > distributing Linux. If your goal is to harm Linux, suing users can
> > > > simply be much more effective than suing vendors...
> > > >
> > > > It could even be that people distributing Linux could receive cease and
> > > > desist letters from people without any real interest in the issue
> > > > itself - "cease and desist letter"s are so frequent in Germany because
> > > > the people who have to sign them have to pay the lawyers' costs that are
> > > > usually > 1000 Euro, and that's a good business for the lawyers.
> > >
> > > Something is very wrong with German legal system, I'm afraid.
> >
> > The point that you can take legal actions against anyone distributing
> > something that violates your rights should be present in more or less
> > all legal systems.
> >
> > What might be special in Germany is only that you can demand your costs
> > after successfully taking legal actions.
>
> What is special in Germany is fact that any random lawyer can demand
> $1000 (not his cost, his profit) if you distribute code that is not
> his...
This is a misunderstanding.
You can demand the costs for your lawyer.
The costs for your lawyer depend on the amount in controversy.
The one who tells his lawyer to take legal actions might be a copyright
owner, but it's also possible based on competition law.
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 160+ messages in thread