dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19])

[Oleg Verych]

On 2006-12-14, Alan wrote:
[]
> I doubt any distribution but the FSF "purified" Debian (the one that has
> no firmware so doesn't work) would do it.

DFSG "purified" Debian[1], please.

[1] 

--
-o--=O C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o ( yes! -- R.I.P. FSF+RMS, viva )
<___=E M  man gcc: not found`-- ( Debian Free Operating System )

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19])

[Oleg Verych]

On 2006-12-14, Alan wrote:
[]
 I doubt any distribution but the FSF purified Debian (the one that has
 no firmware so doesn't work) would do it.

DFSG purified Debian[1], please.

[1] http://www.debian.org/social_contract

--
-o--=O C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o ( yes! -- R.I.P. FSF+RMS, viva )
___=E M  man gcc: not found`-- ( Debian Free Operating System )

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dmitry Torokhov]

On Sunday 24 December 2006 09:27, Pavel Machek wrote:
> 
> perhaps printk('Binary only modules are not allowed by kernel license,
> but copyright law may still allow them in special cases. Be careful,

Come again?

> Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
> would be acceptable way to educate people?

Since this message will be seen by an end-user who is likely does not
do any distribution he has nothing to fear from Greg ;)

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

Sean wrote:
> On Sun, 24 Dec 2006 06:57:58 -0500
> Mark Hounschell <[EMAIL PROTECTED]> 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=" 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

Hi!

> > > > So let's come out and ban binary modules, rather than pussyfooting
> > > > around, if that's what we actually want to do.
> > > 
> > > Give people 12 months warning (time to work out what they're going to do,
> > > talk with the legal dept, etc) then make the kernel load only GPL-tagged
> > > modules.
> > > 
> > > I think I'd favour that.  It would aid those people who are trying to
> > > obtain device specs, and who are persuading organisations to GPL their 
> > > drivers.
> > 
> > Ok, I have no objection to that at all.  I'll whip up such a patch in a
> > bit to spit out kernel log messages whenever such a module is loaded so
> > that people have some warning.
> 
> Here you go.  The wording for the feature-removal-schedule.txt file
> could probably be cleaned up.  Any suggestions would be welcome.
> 
> thanks,
> 
> greg k-h
> 
> ---
> From: Greg Kroah-Hartmna <[EMAIL PROTECTED]>
> Subject: Notify non-GPL module loading will be going away in January 2008
> 
> 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.
> 
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> 
> ---
>  Documentation/feature-removal-schedule.txt |9 +
>  kernel/module.c|6 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
> +++ gregkh-2.6/Documentation/feature-removal-schedule.txt
> @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
>  Who: Venkatesh Pallipadi <[EMAIL PROTECTED]>
>  
>  ---
> +
> +What:non GPL licensed modules will able to be loaded successfully.
> +When:January 2008
> +Why: Numerous kernel developers feel that loading non-GPL drivers into the
> + kernel violates the license of the kernel and their copyright.
> +
> +Who: Greg Kroah-Hartman <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
> +
> +---
> --- gregkh-2.6.orig/kernel/module.c
> +++ gregkh-2.6/kernel/module.c
> @@ -1393,9 +1393,13 @@ static void set_license(struct module *m
>   license = "unspecified";
>  
>   if (!license_is_gpl_compatible(license)) {
> - if (!(tainted & TAINT_PROPRIETARY_MODULE))
> + if (!(tainted & TAINT_PROPRIETARY_MODULE)) {
>   printk(KERN_WARNING "%s: module license '%s' taints "
>   "kernel.\n", mod->name, license);
> + printk(KERN_WARNING "%s: This module will not be able "
> + "to be loaded after January 1, 2008 due to its "
> + "license.\n", mod->name);
> + }
>   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>   }
>  }

perhaps printk('Binary only modules are not allowed by kernel license,
but copyright law may still allow them in special cases. Be careful,
Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
would be acceptable way to educate people?
Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Sean]

On Sun, 24 Dec 2006 06:57:58 -0500
Mark Hounschell <[EMAIL PROTECTED]> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[James Courtier-Dutton]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[James Courtier-Dutton]

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

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



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Sean]

On Sun, 24 Dec 2006 06:57:58 -0500
Mark Hounschell [EMAIL PROTECTED] 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

Hi!

So let's come out and ban binary modules, rather than pussyfooting
around, if that's what we actually want to do.
   
   Give people 12 months warning (time to work out what they're going to do,
   talk with the legal dept, etc) then make the kernel load only GPL-tagged
   modules.
   
   I think I'd favour that.  It would aid those people who are trying to
   obtain device specs, and who are persuading organisations to GPL their 
   drivers.
  
  Ok, I have no objection to that at all.  I'll whip up such a patch in a
  bit to spit out kernel log messages whenever such a module is loaded so
  that people have some warning.
 
 Here you go.  The wording for the feature-removal-schedule.txt file
 could probably be cleaned up.  Any suggestions would be welcome.
 
 thanks,
 
 greg k-h
 
 ---
 From: Greg Kroah-Hartmna [EMAIL PROTECTED]
 Subject: Notify non-GPL module loading will be going away in January 2008
 
 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.
 
 Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 
 ---
  Documentation/feature-removal-schedule.txt |9 +
  kernel/module.c|6 +-
  2 files changed, 14 insertions(+), 1 deletion(-)
 
 --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt
 +++ gregkh-2.6/Documentation/feature-removal-schedule.txt
 @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI
  Who: Venkatesh Pallipadi [EMAIL PROTECTED]
  
  ---
 +
 +What:non GPL licensed modules will able to be loaded successfully.
 +When:January 2008
 +Why: Numerous kernel developers feel that loading non-GPL drivers into the
 + kernel violates the license of the kernel and their copyright.
 +
 +Who: Greg Kroah-Hartman [EMAIL PROTECTED] or [EMAIL PROTECTED]
 +
 +---
 --- gregkh-2.6.orig/kernel/module.c
 +++ gregkh-2.6/kernel/module.c
 @@ -1393,9 +1393,13 @@ static void set_license(struct module *m
   license = unspecified;
  
   if (!license_is_gpl_compatible(license)) {
 - if (!(tainted  TAINT_PROPRIETARY_MODULE))
 + if (!(tainted  TAINT_PROPRIETARY_MODULE)) {
   printk(KERN_WARNING %s: module license '%s' taints 
   kernel.\n, mod-name, license);
 + printk(KERN_WARNING %s: This module will not be able 
 + to be loaded after January 1, 2008 due to its 
 + license.\n, mod-name);
 + }
   add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
   }
  }

perhaps printk('Binary only modules are not allowed by kernel license,
but copyright law may still allow them in special cases. Be careful,
Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
would be acceptable way to educate people?
Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Mark Hounschell]

Sean wrote:
 On Sun, 24 Dec 2006 06:57:58 -0500
 Mark Hounschell [EMAIL PROTECTED] 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= 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dmitry Torokhov]

On Sunday 24 December 2006 09:27, Pavel Machek wrote:
 
 perhaps printk('Binary only modules are not allowed by kernel license,
 but copyright law may still allow them in special cases. Be careful,

Come again?

 Greg is going tuo sue you at beggining of 2008 if you get it wrong.')
 would be acceptable way to educate people?

Since this message will be seen by an end-user who is likely does not
do any distribution he has nothing to fear from Greg ;)

-- 
Dmitry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

[EMAIL PROTECTED] 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 InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

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 +, 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 +, 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
> On Thu, Dec 21, 2006 at 03:38:29PM +, 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 +, 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 21, 2006 at 03:38:29PM +, 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 +, 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Thu, Dec 21, 2006 at 03:38:29PM +, 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 +, 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 letters 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

On Sat 2006-12-23 12:24:29, Adrian Bunk wrote:
 On Thu, Dec 21, 2006 at 03:38:29PM +, 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 +, 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 letters 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

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 +, 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 +, 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 letters 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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

[EMAIL PROTECTED] 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 InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Niklas Steinkamp]

Hi,

Pavel wrote:
> Something is very wrong with German legal system, I'm afraid.
 
In this case you are right. Our legal system is often very strange.
__
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

Hi!

>  > Anything else, you have to make some really scary decisions. Can a judge 
>  > decide that a binary module is a derived work even though you didn't 
>  > actually use any code? The real answer is: HELL YES. It's _entirely_ 
>  > possible that a judge would find NVidia and ATI in violation of the GPLv2 
>  > with their modules.
> 
> ATI in particular, I'm amazed their lawyers OK'd stuff like..
> 
> +ifdef STANDALONE
>  MODULE_LICENSE(GPL);
> +endif
> 
> This a paraphrased diff, it's been a while since I've seen it.
> It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
> but the usual use case is that it's built-in to fglrx.ko, which sounds
> incredibly dubious.
> 
> Now, AGPGART has a murky past wrt licenses.  It initally was imported
> into the tree with the license "GPL plus additional rights".
> Nowhere was it actually documented what those rights were, but I'm
> fairly certain it wasn't to enable nonsense like the above.
> As it came from the XFree86 folks, it's more likely they really meant
> "Dual GPL/MIT" or similar.
> 
> When I took over, any new code I wrote I explicitly set out to mark as GPL
> code, as my modifications weren't being contributed back to X, they were
> going back to the Linux kernel.  ATI took those AGPv3 modifications from
> a 2.5 kernel, backported them to their 2.4 driver, and when time came

Do they actually distribute that AGPv3 + binary blob? In such case,
you should simply ask them for the binary blob sources, and take them
to the court if they refuse. RedHat should be big enough, and ATI
certainly makes enough money...

They'll probably resolve the problem fast if they feel legal actions
are pending.
Pavel

-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

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 +, 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

Hi!

   Anything else, you have to make some really scary decisions. Can a judge 
   decide that a binary module is a derived work even though you didn't 
   actually use any code? The real answer is: HELL YES. It's _entirely_ 
   possible that a judge would find NVidia and ATI in violation of the GPLv2 
   with their modules.
 
 ATI in particular, I'm amazed their lawyers OK'd stuff like..
 
 +ifdef STANDALONE
  MODULE_LICENSE(GPL);
 +endif
 
 This a paraphrased diff, it's been a while since I've seen it.
 It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
 but the usual use case is that it's built-in to fglrx.ko, which sounds
 incredibly dubious.
 
 Now, AGPGART has a murky past wrt licenses.  It initally was imported
 into the tree with the license GPL plus additional rights.
 Nowhere was it actually documented what those rights were, but I'm
 fairly certain it wasn't to enable nonsense like the above.
 As it came from the XFree86 folks, it's more likely they really meant
 Dual GPL/MIT or similar.
 
 When I took over, any new code I wrote I explicitly set out to mark as GPL
 code, as my modifications weren't being contributed back to X, they were
 going back to the Linux kernel.  ATI took those AGPv3 modifications from
 a 2.5 kernel, backported them to their 2.4 driver, and when time came

Do they actually distribute that AGPv3 + binary blob? In such case,
you should simply ask them for the binary blob sources, and take them
to the court if they refuse. RedHat should be big enough, and ATI
certainly makes enough money...

They'll probably resolve the problem fast if they feel legal actions
are pending.
Pavel

-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Pavel Machek]

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 +, 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 letters 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Niklas Steinkamp]

Hi,

Pavel wrote:
 Something is very wrong with German legal system, I'm afraid.
 
In this case you are right. Our legal system is often very strange.
__
Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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


pgpp6pDU9qCJl.pgp
Description: PGP signature

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

Marek Wawrzyczny <[EMAIL PROTECTED]> 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  and + 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 InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

On Wednesday 20 December 2006 16:11, [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

On Wednesday 20 December 2006 16:11, [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Horst H. von Brand]

Marek Wawrzyczny [EMAIL PROTECTED] 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 InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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


pgpp6pDU9qCJl.pgp
Description: PGP signature

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[alan]

On Wed, 20 Dec 2006, [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lord of the code! [was: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]]

[alan]

On Wed, 20 Dec 2006, Steven Rostedt wrote:


On Sat, 2006-12-16 at 01:27 +, Alan wrote:


blather and idiotic hogwash. "Information" doesn't want to be free,

nor is

it somethign you should fight for or necessarily even encourage.


As a pedant that is the one item I have to pick you up on Linus.
Information wants to be free, the natural efficient economic state of
information is generally free in both senses.


"Remember Frodo, It wants to be free^Wfound"


"Information does not want to be free. It wants to be tied up and 
spanked."



Sorry, couldn't resist...


Neither could I. ]:>

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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


pgpq0qBwboKZ7.pgp
Description: PGP signature

Lord of the code! [was: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]]

[Steven Rostedt]

On Sat, 2006-12-16 at 01:27 +, Alan wrote:

> > blather and idiotic hogwash. "Information" doesn't want to be free,
> nor is 
> > it somethign you should fight for or necessarily even encourage.
> 
> As a pedant that is the one item I have to pick you up on Linus.
> Information wants to be free, the natural efficient economic state of
> information is generally free in both senses.

"Remember Frodo, It wants to be free^Wfound"

Sorry, couldn't resist...

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Schwartz]

> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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




pgpTVtJLX4nbG.pgp
Description: PGP signature

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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




pgpTVtJLX4nbG.pgp
Description: PGP signature

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[David Schwartz]

 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


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lord of the code! [was: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]]

[Steven Rostedt]

On Sat, 2006-12-16 at 01:27 +, Alan wrote:

  blather and idiotic hogwash. Information doesn't want to be free,
 nor is 
  it somethign you should fight for or necessarily even encourage.
 
 As a pedant that is the one item I have to pick you up on Linus.
 Information wants to be free, the natural efficient economic state of
 information is generally free in both senses.

Remember Frodo, It wants to be free^Wfound

Sorry, couldn't resist...

-- Steve


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Valdis . Kletnieks]

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


pgpq0qBwboKZ7.pgp
Description: PGP signature

Re: Lord of the code! [was: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]]

[alan]

On Wed, 20 Dec 2006, Steven Rostedt wrote:


On Sat, 2006-12-16 at 01:27 +, Alan wrote:


blather and idiotic hogwash. Information doesn't want to be free,

nor is

it somethign you should fight for or necessarily even encourage.


As a pedant that is the one item I have to pick you up on Linus.
Information wants to be free, the natural efficient economic state of
information is generally free in both senses.


Remember Frodo, It wants to be free^Wfound


Information does not want to be free. It wants to be tied up and 
spanked.



Sorry, couldn't resist...


Neither could I. ]:

--
Q: Why do programmers confuse Halloween and Christmas?
A: Because OCT 31 == DEC 25
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[alan]

On Wed, 20 Dec 2006, [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Steven Rostedt]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 12:11, Bill Nottingham wrote:
>Gene Heskett ([EMAIL PROTECTED]) said:
>> FWIW:
>> [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Bill Nottingham]

Gene Heskett ([EMAIL PROTECTED]) said: 
> FWIW:
> [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 08:56, Diego Calleja wrote:
>El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny 
<[EMAIL PROTECTED]> 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:
[EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <[EMAIL PROTECTED]> 
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 ...



#!/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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Marek Wawrzyczny]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny [EMAIL PROTECTED] 
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 ...



#!/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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 08:56, Diego Calleja wrote:
El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny 
[EMAIL PROTECTED] 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:
[EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Diego Calleja]

El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Bill Nottingham]

Gene Heskett ([EMAIL PROTECTED]) said: 
 FWIW:
 [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gene Heskett]

On Tuesday 19 December 2006 12:11, Bill Nottingham wrote:
Gene Heskett ([EMAIL PROTECTED]) said:
 FWIW:
 [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Steven Rostedt]

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

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Scott Preece]

On 12/18/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:


In other words, it means that we are pushing a agenda that is no longer
neither a technical issue (it's clearly technically _worse_ to not be able
to do something) _nor_ a legal issue.

So tell me, what does the proposed blocking actually do?

It's "big prother, FSF style". And I say NO THANK YOU.

Linus

---

Well, you can't really say it's "FSF-style", since the GPLv3 language
explicitly gives permission to circumvent any protection measures
implemented by a GPLv3 program.  Even the FSF doesn't support using
the DMCA to support GPL restrictions.

scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Mon, 18 Dec 2006, karderio wrote:
> 
> I don't see how what is proposed for blocking non GPL modules at all
> touches the definition of derived work. Even if according to law and the
> GPL, binary modules are legal, the proposed changes could still be
> made. 

.. and then what does that mean? It means that we try to say that people 
cannot do what they LEGALLY can do? 

In other words, it means that we are pushing a agenda that is no longer 
neither a technical issue (it's clearly technically _worse_ to not be able 
to do something) _nor_ a legal issue. 

So tell me, what does the proposed blocking actually do?

It's "big prother, FSF style". And I say NO THANK YOU.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Mon, Dec 18, 2006 at 10:04:07PM +0100, karderio wrote:
> I have realised that the proposed changes do not *impose* any more
> restriction on the use of the kernel than currently exists. Currently
> the Kernel is licenced to impose the same licence on derived works,
> enforce distribution of source code etc. and this by law. The proposed
> changes do not impose anything, they just make things technically a
> little more complicated for some, and they can be trivially circumvented
> if one desires. 

 except that the people who proposed these changes have already
suggested that these circumventions would be violations of the United
States' Digital Milllenium Copyright Act, which has rather draconoian
penalties for these "trivial circumventions".  Which is precisely why
Linus has said that if we go down this path, we are basically using
the same tactics as the RIAA and MPAA.  And why this kind of arm
twisting as "pursuasion" would be a very, VERY bad idea.  

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[karderio]

Hi :o)

On Fri, 2006-12-15 at 18:55 -0800, Linus Torvalds wrote:
> But the point is, "derived work" is not what _you_ or _I_ define. It's 
> what copyright law defines.

Of course not. I never suggested trying to define a derived work.

> And trying to push that definition too far is a total disaster. If you 
> push the definition of derived work to "anything that touches our work", 
> you're going to end up in a very dark and unhappy place. One where the 
> RIAA is your best buddy.

I don't see how what is proposed for blocking non GPL modules at all
touches the definition of derived work. Even if according to law and the
GPL, binary modules are legal, the proposed changes could still be
made. 

I have realised that the proposed changes do not *impose* any more
restriction on the use of the kernel than currently exists. Currently
the Kernel is licenced to impose the same licence on derived works,
enforce distribution of source code etc. and this by law. The proposed
changes do not impose anything, they just make things technically a
little more complicated for some, and they can be trivially circumvented
if one desires. Maybe not a good idea, but still no excuse for the sort
of atrocious bigotry some people are exhibiting here.

I do not mean to say this is a good thing, some of the arguments
advanced here make me much less enthusiastic as at the beginning. As I
said in my first post, and seemed to be promptly ignored, this can only
by any use at all if it persuades vendors to provide the essential
information about their products without hurting users too much, or
further alienating vendors. All this is of course highly debatable, and
needs discussing properly, if people are able to communicate in a civil
manner that is.

Before any fanatic ranting saying that people inducing slight
complications are freedom hating Nazis who should be burned at the
stake, please contrast this trivial complication with the extremely
difficult work that must be done by someone wanting to write a driver
when a vendor doesn't provide adequate documentation.

It might be noted that in some countries it is quite illegal not to
provide documentation for a product, just as it is illegal to limit a
product to only work with a specific vendors merchandise when said
product is in essence generic. This is the case in France, where these
laws are simply ignored by corporations. A large French NFP sued HP last
week about them not allowing their PCs to be sold without Windows, so we
may finally start to get these laws applied. I have written the NFP to
suggest that if the case does not extend to missing hardware
documentation, maybe another case would be in order. In the past the
people at this NFP have been very civil and cooperative with me.

> And that is why it would be WRONG to think that we have the absolute right 
> to say "that is illegal". It's simply not our place to make that 
> judgement. When you start thinking that you have absolute control over the 
> content or programs you produce, and that the rest of the worlds opinions 
> doesn't matter, you're just _wrong_.

I have seen nobody with the ponce to judge people or try to have control
over them when arguing for these mods. I think all that has been said
has been people trying to interpret the law, it's quite possible they
got it wrong. Not that I can blame them, law is a not simple, and I can
see people on both "sides" of the argument not getting things quite
right here.

I would note however that I personally find it distasteful to call
people "wrong" rather than respectfully disagreeing with them.

> So don't go talking about how we should twist peoples arms and force them 
> to be open source of free software. Instead, BE HAPPY that people can take 
> advantage of "loopholes" in copyright protections and can legally do 
> things that you as the copyright owner might not like. Because those 
> "loopholes" are in the end what protects YOU.

I admit I should not have used the phrase "twist arm", I meant it in an
entirely jocular sense, it is a phrase I never employ usually. Of course
it is a mistake I regret. The word "persuade" would have been a much
better choice.

As I hope I clearly explained above, it wasn't suggested to "force"
anybody to do anything.

Although I don't appreciate insult or aggressively, I choose to ignore
it in order to try and advance a reasonable discussion. I will not stand
here and let you tell me what to and not to do however. It also makes
you seem a bit hypocritical in a discussion where you are claiming to be
arguing for "freedom".

Love, Karderio.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

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

 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eric W. Biederman]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Brendan Scott]

> It's just that I'm so damn tired of this whole thing.  I'm tired of
> people thinking they have a right to violate my copyright all the time.
> I'm tired of people and companies somehow treating our license in ways
> that are blatantly wrong and feeling fine about it.  Because we are a
> loose band of a lot of individuals, and not a company or legal entity,
> it seems to give companies the chutzpah to feel that they can get away
> with violating our license.

Why don't you consider some intermediate position?  If the issue is that you 
don't want people infringing copyright, then don't load the module unless it's 
accompanied by a [text] file in a standard format which states that the module 
is not infringing.  

So the default would be that non-GPL modules would not be loaded, but that the 
non-load could be easily circumvented by someone with a legitimate non-GPL 
module.  That would mean truly non infringing modules could be loaded.  
Moreover, anyone could still load an infringing module, but to do so would mean 
they would need to actively be either reckless or lying (even if all the fields 
are left blank) - which would not look very good when it was exposed.  It would 
also help educate those people who are bona fide, but ignorant of their 
obligations.  

The file could include (eg):
Module name: 
Version number:
License: 
I have read the statement on GPL binary modules and the kernel developers' 
views on GPL-infringement available from [address]: yes/no
I verify that I have reviewed the developer's statement above and honestly 
believe that this version of this module does not infringe copyright in the 
kernel when assessed in accordance with that statement.  I also verify that in 
making this verification I am, or am acting on behalf of, the author(s) and 
copyright owner(s) of this module : [name]
Date verified: [date]
Name of organisation: 
Contact email:


If you're interested, I'd be happy to help draft something more involved. 


Regards


Brendan  

-- 
Brendan Scott IT Law Open Source Law 
0414 339 227 http://www.opensourcelaw.biz
Liability limited by a scheme approved under Professional Standards Legislation
Open Source Law Weekly digest: [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Brendan Scott]

 It's just that I'm so damn tired of this whole thing.  I'm tired of
 people thinking they have a right to violate my copyright all the time.
 I'm tired of people and companies somehow treating our license in ways
 that are blatantly wrong and feeling fine about it.  Because we are a
 loose band of a lot of individuals, and not a company or legal entity,
 it seems to give companies the chutzpah to feel that they can get away
 with violating our license.

Why don't you consider some intermediate position?  If the issue is that you 
don't want people infringing copyright, then don't load the module unless it's 
accompanied by a [text] file in a standard format which states that the module 
is not infringing.  

So the default would be that non-GPL modules would not be loaded, but that the 
non-load could be easily circumvented by someone with a legitimate non-GPL 
module.  That would mean truly non infringing modules could be loaded.  
Moreover, anyone could still load an infringing module, but to do so would mean 
they would need to actively be either reckless or lying (even if all the fields 
are left blank) - which would not look very good when it was exposed.  It would 
also help educate those people who are bona fide, but ignorant of their 
obligations.  

The file could include (eg):
Module name: 
Version number:
License: 
I have read the statement on GPL binary modules and the kernel developers' 
views on GPL-infringement available from [address]: yes/no
I verify that I have reviewed the developer's statement above and honestly 
believe that this version of this module does not infringe copyright in the 
kernel when assessed in accordance with that statement.  I also verify that in 
making this verification I am, or am acting on behalf of, the author(s) and 
copyright owner(s) of this module : [name]
Date verified: [date]
Name of organisation: 
Contact email:


If you're interested, I'd be happy to help draft something more involved. 


Regards


Brendan  

-- 
Brendan Scott IT Law Open Source Law 
0414 339 227 http://www.opensourcelaw.biz
Liability limited by a scheme approved under Professional Standards Legislation
Open Source Law Weekly digest: [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Eric W. Biederman]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Jeff V. Merkey]

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

 



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[karderio]

Hi :o)

On Fri, 2006-12-15 at 18:55 -0800, Linus Torvalds wrote:
 But the point is, derived work is not what _you_ or _I_ define. It's 
 what copyright law defines.

Of course not. I never suggested trying to define a derived work.

 And trying to push that definition too far is a total disaster. If you 
 push the definition of derived work to anything that touches our work, 
 you're going to end up in a very dark and unhappy place. One where the 
 RIAA is your best buddy.

I don't see how what is proposed for blocking non GPL modules at all
touches the definition of derived work. Even if according to law and the
GPL, binary modules are legal, the proposed changes could still be
made. 

I have realised that the proposed changes do not *impose* any more
restriction on the use of the kernel than currently exists. Currently
the Kernel is licenced to impose the same licence on derived works,
enforce distribution of source code etc. and this by law. The proposed
changes do not impose anything, they just make things technically a
little more complicated for some, and they can be trivially circumvented
if one desires. Maybe not a good idea, but still no excuse for the sort
of atrocious bigotry some people are exhibiting here.

I do not mean to say this is a good thing, some of the arguments
advanced here make me much less enthusiastic as at the beginning. As I
said in my first post, and seemed to be promptly ignored, this can only
by any use at all if it persuades vendors to provide the essential
information about their products without hurting users too much, or
further alienating vendors. All this is of course highly debatable, and
needs discussing properly, if people are able to communicate in a civil
manner that is.

Before any fanatic ranting saying that people inducing slight
complications are freedom hating Nazis who should be burned at the
stake, please contrast this trivial complication with the extremely
difficult work that must be done by someone wanting to write a driver
when a vendor doesn't provide adequate documentation.

It might be noted that in some countries it is quite illegal not to
provide documentation for a product, just as it is illegal to limit a
product to only work with a specific vendors merchandise when said
product is in essence generic. This is the case in France, where these
laws are simply ignored by corporations. A large French NFP sued HP last
week about them not allowing their PCs to be sold without Windows, so we
may finally start to get these laws applied. I have written the NFP to
suggest that if the case does not extend to missing hardware
documentation, maybe another case would be in order. In the past the
people at this NFP have been very civil and cooperative with me.

 And that is why it would be WRONG to think that we have the absolute right 
 to say that is illegal. It's simply not our place to make that 
 judgement. When you start thinking that you have absolute control over the 
 content or programs you produce, and that the rest of the worlds opinions 
 doesn't matter, you're just _wrong_.

I have seen nobody with the ponce to judge people or try to have control
over them when arguing for these mods. I think all that has been said
has been people trying to interpret the law, it's quite possible they
got it wrong. Not that I can blame them, law is a not simple, and I can
see people on both sides of the argument not getting things quite
right here.

I would note however that I personally find it distasteful to call
people wrong rather than respectfully disagreeing with them.

 So don't go talking about how we should twist peoples arms and force them 
 to be open source of free software. Instead, BE HAPPY that people can take 
 advantage of loopholes in copyright protections and can legally do 
 things that you as the copyright owner might not like. Because those 
 loopholes are in the end what protects YOU.

I admit I should not have used the phrase twist arm, I meant it in an
entirely jocular sense, it is a phrase I never employ usually. Of course
it is a mistake I regret. The word persuade would have been a much
better choice.

As I hope I clearly explained above, it wasn't suggested to force
anybody to do anything.

Although I don't appreciate insult or aggressively, I choose to ignore
it in order to try and advance a reasonable discussion. I will not stand
here and let you tell me what to and not to do however. It also makes
you seem a bit hypocritical in a discussion where you are claiming to be
arguing for freedom.

Love, Karderio.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Mon, Dec 18, 2006 at 10:04:07PM +0100, karderio wrote:
 I have realised that the proposed changes do not *impose* any more
 restriction on the use of the kernel than currently exists. Currently
 the Kernel is licenced to impose the same licence on derived works,
 enforce distribution of source code etc. and this by law. The proposed
 changes do not impose anything, they just make things technically a
 little more complicated for some, and they can be trivially circumvented
 if one desires. 

 except that the people who proposed these changes have already
suggested that these circumventions would be violations of the United
States' Digital Milllenium Copyright Act, which has rather draconoian
penalties for these trivial circumventions.  Which is precisely why
Linus has said that if we go down this path, we are basically using
the same tactics as the RIAA and MPAA.  And why this kind of arm
twisting as pursuasion would be a very, VERY bad idea.  

- Ted

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Mon, 18 Dec 2006, karderio wrote:
 
 I don't see how what is proposed for blocking non GPL modules at all
 touches the definition of derived work. Even if according to law and the
 GPL, binary modules are legal, the proposed changes could still be
 made. 

.. and then what does that mean? It means that we try to say that people 
cannot do what they LEGALLY can do? 

In other words, it means that we are pushing a agenda that is no longer 
neither a technical issue (it's clearly technically _worse_ to not be able 
to do something) _nor_ a legal issue. 

So tell me, what does the proposed blocking actually do?

It's big prother, FSF style. And I say NO THANK YOU.

Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Scott Preece]

On 12/18/06, Linus Torvalds [EMAIL PROTECTED] wrote:


In other words, it means that we are pushing a agenda that is no longer
neither a technical issue (it's clearly technically _worse_ to not be able
to do something) _nor_ a legal issue.

So tell me, what does the proposed blocking actually do?

It's big prother, FSF style. And I say NO THANK YOU.

Linus

---

Well, you can't really say it's FSF-style, since the GPLv3 language
explicitly gives permission to circumvent any protection measures
implemented by a GPLv3 program.  Even the FSF doesn't support using
the DMCA to support GPL restrictions.

scott
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gerhard Mack]

On Sat, 16 Dec 2006, Dave Jones wrote:

> On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:
> 
>  > Anything else, you have to make some really scary decisions. Can a judge 
>  > decide that a binary module is a derived work even though you didn't 
>  > actually use any code? The real answer is: HELL YES. It's _entirely_ 
>  > possible that a judge would find NVidia and ATI in violation of the GPLv2 
>  > with their modules.
> 
> ATI in particular, I'm amazed their lawyers OK'd stuff like..
> 
> +ifdef STANDALONE
>  MODULE_LICENSE(GPL);
> +endif
> 
> This a paraphrased diff, it's been a while since I've seen it.
> It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
> but the usual use case is that it's built-in to fglrx.ko, which sounds
> incredibly dubious.
> 
> Now, AGPGART has a murky past wrt licenses.  It initally was imported
> into the tree with the license "GPL plus additional rights".
> Nowhere was it actually documented what those rights were, but I'm
> fairly certain it wasn't to enable nonsense like the above.
> As it came from the XFree86 folks, it's more likely they really meant
> "Dual GPL/MIT" or similar.
> 
> When I took over, any new code I wrote I explicitly set out to mark as GPL
> code, as my modifications weren't being contributed back to X, they were
> going back to the Linux kernel.  ATI took those AGPv3 modifications from
> a 2.5 kernel, backported them to their 2.4 driver, and when time came
> to do a 2.6 driver, instead of doing the sensible thing and dropping
> them in favour of using the kernel AGP driver, they chose to forward
> port their unholy abomination to 2.6.
> It misses so many fixes (and introduces a number of other problems)
> that its just unfunny.
> 
> The thing that really ticks me off though is the free support ATI seem
> to think they're entitled to.  I've had end-users emailing me
> "I asked ATI about this crash I've been seeing with fglrx, and they
>  asked me to mail you".
> 
> I invest my time into improving free drivers.  When companies start
> expecting me to debug their part binary garbage mixed with license
> violations, frankly, I think they're taking the piss.
> 
> A year and a half ago, I met an ATI engineer at OLS, who told me they
> were going to 'resolve this'.  I'm still waiting.
> I live in hope that the AMD buyout will breathe some sanity into ATI.
> Then again, I've only a limited supply of optimism.

You would think ATI's steaming pile of crap would be a good reason for 
them to give up on the whole binary module thing and just release specs so 
someone else can write a decent driver.

I made the mistake of purchasing an ATI X1600.  No open kernel driver.. no 
open X driver.  The ATI drivers don't even complile on amd64 on any 
recent kernel and their X drivers are prone to random screen corruption 
that requires nothing less than a full reboot to clear.

IMO let those morons keep writing themselves into a corner with this crud 
and then perhapse they will see for themselves that binary modules are a 
horribly bad idea instead of having someone else to blame when this whole 
thing finally fails.

Gerhard


--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

On Sat, 16 Dec 2006, Gene Heskett wrote:
> On Saturday 16 December 2006 05:28, Rafael J. Wysocki wrote:
> >On Saturday, 16 December 2006 07:43, Willy Tarreau wrote:
> [...]
> >I think the most important problem with the binary-only drivers is that
> > we can't support their users _at_ _all_, but some of them expect us to
> > support them somehow.
> >
> >So, why don't we make an official statement, like something that will
> > appear on the front page of www.kernel.org, that the users of
> > binary-only drivers will never get any support from us?  That would
> > make things crystal clear.
> 
> I disagree with this, to the extent that I perceive this business of no 
> support for a 'tainted' kernel to be almost in the same category as 
> saying that if we configure and build our own kernels, then we are alone 
> and you don't want to hear about it.
> 
> Yes, there is a rather large difference in actual fact, but if I come to 

There's indeed a big difference. That's why people ask for your .config and for
the changes you made to your kernel (especially in cases like `Hi, the kernel
crashes with my newly written driver').

> the list with a firewire or usb problem, we should be capable of 
> divorcing the fact that I may also be using an ati or nvidia supplied 
> driver from the firewire or usb problem at hand.

You can divorce it by not loading the binary-only driver(s) and reproducing the
problem.

> I am not in fact using the ati driver with my 9200SE, as the in-kernel as 
> its plenty good enough for that I do, but that's the point.  To 
> automaticly deny supplying what might be helpfull suggestions just 
> because the user has a 'tainted' kernel strikes me as being pretty darned 
> hypocritical, particularly when the user states he has reverted but this 
> instant problem persists.

Then the kernel is no longer tainted, right?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Rafael J. Wysocki]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Pavel Machek]

Hi!

> > Well.. it is easier to debug in userspace. While bad hw access can
> > still kill the box, bad free() will not, and most bugs in early
> > developent are actually of 2nd kind.
> 
> Isn't that what qemu is for?

I do not think you can reasonably debug driver for new hardware under
qemu.

Anyway, doing it in userspace is just convenient.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Pavel Machek]

Hi!

  Well.. it is easier to debug in userspace. While bad hw access can
  still kill the box, bad free() will not, and most bugs in early
  developent are actually of 2nd kind.
 
 Isn't that what qemu is for?

I do not think you can reasonably debug driver for new hardware under
qemu.

Anyway, doing it in userspace is just convenient.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Rafael J. Wysocki]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

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 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Geert Uytterhoeven]

On Sat, 16 Dec 2006, Gene Heskett wrote:
 On Saturday 16 December 2006 05:28, Rafael J. Wysocki wrote:
 On Saturday, 16 December 2006 07:43, Willy Tarreau wrote:
 [...]
 I think the most important problem with the binary-only drivers is that
  we can't support their users _at_ _all_, but some of them expect us to
  support them somehow.
 
 So, why don't we make an official statement, like something that will
  appear on the front page of www.kernel.org, that the users of
  binary-only drivers will never get any support from us?  That would
  make things crystal clear.
 
 I disagree with this, to the extent that I perceive this business of no 
 support for a 'tainted' kernel to be almost in the same category as 
 saying that if we configure and build our own kernels, then we are alone 
 and you don't want to hear about it.
 
 Yes, there is a rather large difference in actual fact, but if I come to 

There's indeed a big difference. That's why people ask for your .config and for
the changes you made to your kernel (especially in cases like `Hi, the kernel
crashes with my newly written driver').

 the list with a firewire or usb problem, we should be capable of 
 divorcing the fact that I may also be using an ati or nvidia supplied 
 driver from the firewire or usb problem at hand.

You can divorce it by not loading the binary-only driver(s) and reproducing the
problem.

 I am not in fact using the ati driver with my 9200SE, as the in-kernel as 
 its plenty good enough for that I do, but that's the point.  To 
 automaticly deny supplying what might be helpfull suggestions just 
 because the user has a 'tainted' kernel strikes me as being pretty darned 
 hypocritical, particularly when the user states he has reverted but this 
 instant problem persists.

Then the kernel is no longer tainted, right?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Gerhard Mack]

On Sat, 16 Dec 2006, Dave Jones wrote:

 On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:
 
   Anything else, you have to make some really scary decisions. Can a judge 
   decide that a binary module is a derived work even though you didn't 
   actually use any code? The real answer is: HELL YES. It's _entirely_ 
   possible that a judge would find NVidia and ATI in violation of the GPLv2 
   with their modules.
 
 ATI in particular, I'm amazed their lawyers OK'd stuff like..
 
 +ifdef STANDALONE
  MODULE_LICENSE(GPL);
 +endif
 
 This a paraphrased diff, it's been a while since I've seen it.
 It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
 but the usual use case is that it's built-in to fglrx.ko, which sounds
 incredibly dubious.
 
 Now, AGPGART has a murky past wrt licenses.  It initally was imported
 into the tree with the license GPL plus additional rights.
 Nowhere was it actually documented what those rights were, but I'm
 fairly certain it wasn't to enable nonsense like the above.
 As it came from the XFree86 folks, it's more likely they really meant
 Dual GPL/MIT or similar.
 
 When I took over, any new code I wrote I explicitly set out to mark as GPL
 code, as my modifications weren't being contributed back to X, they were
 going back to the Linux kernel.  ATI took those AGPv3 modifications from
 a 2.5 kernel, backported them to their 2.4 driver, and when time came
 to do a 2.6 driver, instead of doing the sensible thing and dropping
 them in favour of using the kernel AGP driver, they chose to forward
 port their unholy abomination to 2.6.
 It misses so many fixes (and introduces a number of other problems)
 that its just unfunny.
 
 The thing that really ticks me off though is the free support ATI seem
 to think they're entitled to.  I've had end-users emailing me
 I asked ATI about this crash I've been seeing with fglrx, and they
  asked me to mail you.
 
 I invest my time into improving free drivers.  When companies start
 expecting me to debug their part binary garbage mixed with license
 violations, frankly, I think they're taking the piss.
 
 A year and a half ago, I met an ATI engineer at OLS, who told me they
 were going to 'resolve this'.  I'm still waiting.
 I live in hope that the AMD buyout will breathe some sanity into ATI.
 Then again, I've only a limited supply of optimism.

You would think ATI's steaming pile of crap would be a good reason for 
them to give up on the whole binary module thing and just release specs so 
someone else can write a decent driver.

I made the mistake of purchasing an ATI X1600.  No open kernel driver.. no 
open X driver.  The ATI drivers don't even complile on amd64 on any 
recent kernel and their X drivers are prone to random screen corruption 
that requires nothing less than a full reboot to clear.

IMO let those morons keep writing themselves into a corner with this crud 
and then perhapse they will see for themselves that binary modules are a 
horribly bad idea instead of having someone else to blame when this whole 
thing finally fails.

Gerhard


--
Gerhard Mack

[EMAIL PROTECTED]

 As a computer I find your faith in technology amusing.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote:
> OK, let assume your perspective of the history is the valid and real one, 
> then, ¿where are all lawsits against other big GPL only projects? For example 
> libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold 
> in court.

There's no need for lawsuits against things like libqt.  The question
is whether someone who writes a commercial program that happens to
dynamically link against libqt is in fact in violation of copyright
claims.  In such a case, the owners of libqt would have to sue the
commercial application writer, not the other way around.  There
haven't been any such cases, mostly because (a) the FUD generated by
the FSF about GPL vs. LGPL has generally been enough to cause
application authors to avoid using GPL'ed code even if it would be
legally defensible in court, and (b) I personally suspect that the FSF
has deliberately not tried to make a test case out of a commercial
application dynamically linking against a GPL'ed library.

In point of fact, if you compile libss from e2fsprogs on a Solaris
machine, and then let the Sun Enterprise Authentication Mechanism (a
propietary version of Kerberos v5) link against that version of libss
(as opposed to the one derived from the MIT Kerberos version of
libss), you can have a propietary Sun binary linking against libss
which will called will dynamically pull in the GPL'ed version of
readline (or the BSD licensed editline library, whichever one it finds
first in its search path).  Quick!  Is there a GPL violation involved,
and if so, who should the FSF try to sue first?

There are indeed plenty of cases where the GPL has been upheld in a
court of law, but usually it's some straightforward case of an
embedded version of Linux being used without releasing source.  As far
as I know, there has been no case on point about GPL and dynamic
linking, and I personally suspect it's at least partially because the
FSF is afraid it would lose such a case.  (As I've said, at least one
law professor of mine from the MIT Sloan School of Management has told
me that in her opinion the FSF's theory would be "laughed out of
court").

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Sun, Dec 17, 2006 at 02:56:09AM +0100, Adrian Bunk wrote:
>...
> Otherwise, it seems to be highly unlikely that anyone will want to sue a 
> company that is often located in a different country, and the only 
> possible legal action will be cease and desist letters against people 
> who are infriding the copyright by e.g. selling Linux distributions 
> containing fglrx at Ebay or operating Debian ftp mirrors. That sounds 
> highly unfair, but unfortunately it also seems to be the only effective 
> way for someone without a big wallet to effectively act against such 
> licence violations...

To avoid any misunderstandings:

I do not want to threaten anyone, and I do not plan to do such legal 
actions myself.

My point is simply that whoever considers this grey area a good thing 
and wants to leave clarifications to the lawyers should be aware that 
e.g. in the fglrx and nvidia cases it's quite possible that the target 
of legal actions might not be AMD but e.g. the Technical University of 
Dresden that is distributing the offending code in Germany [1].

cu
Adrian

[1] by operating ftp.de.debian.org

-- 

   "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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Adrian Bunk]

On Sat, Dec 16, 2006 at 01:33:01PM -0500, Dave Jones wrote:
> On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:
> 
>  > Anything else, you have to make some really scary decisions. Can a judge 
>  > decide that a binary module is a derived work even though you didn't 
>  > actually use any code? The real answer is: HELL YES. It's _entirely_ 
>  > possible that a judge would find NVidia and ATI in violation of the GPLv2 
>  > with their modules.
> 
> ATI in particular, I'm amazed their lawyers OK'd stuff like..
> 
> +ifdef STANDALONE
>  MODULE_LICENSE(GPL);
> +endif
> 
> This a paraphrased diff, it's been a while since I've seen it.
> It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
> but the usual use case is that it's built-in to fglrx.ko, which sounds
> incredibly dubious.
>...

Current versions contain
  MODULE_LICENSE("GPL and additional rights");
...

> The thing that really ticks me off though is the free support ATI seem
> to think they're entitled to.  I've had end-users emailing me
> "I asked ATI about this crash I've been seeing with fglrx, and they
>  asked me to mail you".
> 
> I invest my time into improving free drivers.  When companies start
> expecting me to debug their part binary garbage mixed with license
> violations, frankly, I think they're taking the piss.
> 
> A year and a half ago, I met an ATI engineer at OLS, who told me they
> were going to 'resolve this'.  I'm still waiting.
> I live in hope that the AMD buyout will breathe some sanity into ATI.
> Then again, I've only a limited supply of optimism.

But who's actually taking legal actions?

Perhaps pending legal changes that will turn copyright violations into 
crimes might help to take legal actions without the legal risks of
civil trials.

Otherwise, it seems to be highly unlikely that anyone will want to sue a 
company that is often located in a different country, and the only 
possible legal action will be cease and desist letters against people 
who are infriding the copyright by e.g. selling Linux distributions 
containing fglrx at Ebay or operating Debian ftp mirrors. That sounds 
highly unfair, but unfortunately it also seems to be the only effective 
way for someone without a big wallet to effectively act against such 
licence violations...

>   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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ricardo Galli]

On Saturday 16 December 2006 22:01, Linus Torvalds wrote:
> On Sat, 16 Dec 2006, Ricardo Galli wrote:
> > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never
> > tried to change or restrict "fair use". GPL[23] covers only to
> > "distibution" of the covered program. The freedom #0 says explicitly:
> > "right to use the program for any purpose".
>
> I'm sorry, but you're just rewriting history.
>
> The FSF very much _has_ tried to make "fair use" a very restricted issue.
> The whole reason the LGPL exists is that people realized that if they
> don't do something like that, the GPL would have been tried in court, and
> the FSF's position that anything that touches GPL'd code would probably
> have been shown to be bogus.
>
> In reality, if the FSF actually believed in "fair use", they would just
> have admitted that GNU libc could have continued to be under the GPL, and
> that any programs that link against it are obviously not "derived" from
> it.
>
> But no. The FSF has very much tried to confuse and muddle the issue, and
> instead have claimed that projects like glibc should be done under the
> "Lesser" GPL.

OK, let assume your perspective of the history is the valid and real one, 
then, ¿where are all lawsits against other big GPL only projects? For example 
libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold 
in court.

> The fact is, if you accept fair use, you have to accept it for other
> people to take advantage of too. Fair use really isn't just a one-way
> street.

"Fair use: The right set forth in Section 107 of the United States Copyright 
Act, to use copyrighted materials for certain purposes, such as criticism, 
comment, news reporting, teaching, scholarship, and research. The Copyright 
Act does not define fair use. Instead, whether a use is fair use is 
determined by balancing these factors: ..."

According to the law, I don't see how FSF tries to avoid or to reject the fair 
use rights.

It seems to me you provides us with a copyright law interpretation supported 
only by the very [narrow] exceptions of the copyright law, a logical fallacy.


-- 
  ricardo galli   GPG id C8114D34
  http://mnm.uib.es/gallir/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Willy Tarreau]

On Sat, Dec 16, 2006 at 03:23:12PM -0500, Theodore Tso wrote:
> On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote:
> > I don't think this is the same case. The film _author_'s primary goal is
> > to have a lot of families buy his DVD to watch it. Whatever the MPAA says,
> > I can consider it "fair use" if a family of 4..8 persons watch the DVD at
> > the same time. 
> 
> "You can consider it"?  But you're not the author.  This is the
> hypocrisy that Linus was talking about.  At the same time that you're
> trying to dictate to other other people can use their copy of the
> Linux kernel, when it comes to others people's copyrighted work, you
> feel to dictate what is and isn't "fair use".

No, I don't want to dictate, it's the opposite, I say what _I_ consider
fair use. Other people will consider it other ways. It's exactly the
gray area Linus was talking about. As long as all parties agree on one
given fair use, there's no problem. Discussion and sometimes litigation
is needed when some parties disagree.

> That's the big thing about dynamic linking.  The GPL has always said
> it is about distribution, not about use.  The dynamic linking of a
> kernel module happens in the privacy of someone's home.  When we try
> to dictate what people are doing in the privacy in their home, we're
> no better than the MPAA or the RIAA.  

100% agreed with you on this !

> As far as whether or not someone is allowed to distribute a binary
> module that can be linked into the Linux kernel, that's a question of
> whether the binary module is a derived work or not.  And that's not up
> to us, that's up to the local laws.  But before you decide that you
> want the most extreme form of anything that wanders close to one
> person's code or header files is a derived work, and to start going to
> work lobbying your local legislature, recall that there have been
> those who have claimed that Linux is a derived work of Unix because we
> used things like #define's for errno codes and structure definitions
> of ELF binaries.  You really sure you want to go there?

Ted, I think you get me wrong. I don't want to dictate anyone what's
derived work and what is not. Instead, it's the opposite. I just want
to indicate them what's explicitly permitted by the author and copyright
owner (at least by me as the author/copyright owner when I can) so that
people can decide by themselves what level of risk they take by doing
whatever they want. What I consider the most important is to encourage
fair use even in areas I never anticipated, and when possible, try to
protect fair users from the GPL zealots who want to bite whenever one
gives them an opportunity to abuse the gray area to feel stronger.

I have opened even more my software and tried to clarify the reasons
why I chose the dual license exactly for this reason.

What I was suggesting is to add a clarification with the kernel to
avoid those overly long threads on LKML such as this one. It would
basically be structured like this :

"Use in the following order" :
  1) fully respect the license and you're OK.
  2) play in the gray area if you need and if you consider it fair use,
 but seek legal advice from a lawyer (and not LKML) before !
  3) explicitly violate the license, and prepare to get sued sooner or later.
  For GPL zealots : please do not report what _you_ consider abuse to LKML,
  contact the abuser, then a lawyer or specialized sites for this.

But Linus is right, he's not the only copyright owner, and that makes it
harder to touch anything related to license and use.

>   - Ted

Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Sat, 16 Dec 2006, Ricardo Galli wrote:

> As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
> to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
> covered program. The freedom #0 says explicitly: "right to use the program 
> for any purpose".

I'm sorry, but you're just rewriting history.

The FSF very much _has_ tried to make "fair use" a very restricted issue. 
The whole reason the LGPL exists is that people realized that if they 
don't do something like that, the GPL would have been tried in court, and 
the FSF's position that anything that touches GPL'd code would probably 
have been shown to be bogus.

In reality, if the FSF actually believed in "fair use", they would just 
have admitted that GNU libc could have continued to be under the GPL, and 
that any programs that link against it are obviously not "derived" from 
it.

But no. The FSF has very much tried to confuse and muddle the issue, and 
instead have claimed that projects like glibc should be done under the 
"Lesser" GPL.

That's just idiocy, but it works as a way to defuse the problem that the 
FSF has always had with admitting that not only _they_ have "fair use" 
rights, but others have them too.

Do you REALLY believe that a binary becomes a "derived work" of any random 
library that it gets linked against? If that's not "fair use" of a library 
that implements a standard library definition, I don't know what is.

And yes, the FSF really has tried to push that totally insane argument. 

So don't tell me that the FSF honors "fair use". They say they do, but 
they only seem to honor it when it helps _their_ argument, not when it 
helps "those evil people who try to take advantage of our hard work".

The fact is, if you accept fair use, you have to accept it for other 
people to take advantage of too. Fair use really isn't just a one-way 
street.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Jan Engelhardt]

On Dec 16 2006 15:13, Lee Revell wrote:
>On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
>> 
>> They use floating point in (Windows) kernelspace? Oh my.
>
>Yes, definitely.

Explains why Windows is so slow ;-) [FPU restore and stuff...]

On that matter, when does the Linux kernel do proper FPU handling? At context
switches? If so, would not that make a kthread fpu-capable?

>For example lots of Windows sound drivers do AC3 decoding in kernelspace.
>Of course the vendors usually lie and say it's done in hardware...

They don't need to lie, the user buys it anyway...


-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Theodore Tso]

On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote:
> I don't think this is the same case. The film _author_'s primary goal is
> to have a lot of families buy his DVD to watch it. Whatever the MPAA says,
> I can consider it "fair use" if a family of 4..8 persons watch the DVD at
> the same time. 

"You can consider it"?  But you're not the author.  This is the
hypocrisy that Linus was talking about.  At the same time that you're
trying to dictate to other other people can use their copy of the
Linux kernel, when it comes to others people's copyrighted work, you
feel to dictate what is and isn't "fair use".

That's the big thing about dynamic linking.  The GPL has always said
it is about distribution, not about use.  The dynamic linking of a
kernel module happens in the privacy of someone's home.  When we try
to dictate what people are doing in the privacy in their home, we're
no better than the MPAA or the RIAA.  

As far as whether or not someone is allowed to distribute a binary
module that can be linked into the Linux kernel, that's a question of
whether the binary module is a derived work or not.  And that's not up
to us, that's up to the local laws.  But before you decide that you
want the most extreme form of anything that wanders close to one
person's code or header files is a derived work, and to start going to
work lobbying your local legislature, recall that there have been
those who have claimed that Linux is a derived work of Unix because we
used things like #define's for errno codes and structure definitions
of ELF binaries.  You really sure you want to go there?

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PATCH] more Driver core patches for 2.6.19

[Lee Revell]

On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote:
> On Dec 14 2006 10:56, Hans-Jürgen Koch wrote:
> >
> >A small German manufacturer produces high-end AD converter cards. He sells
> >100 pieces per year, only in Germany and only with Windows drivers. He would
> >now like to make his cards work with Linux. He has two driver programmers
> >with little experience in writing Linux kernel drivers. What do you tell him?
> >Write a large kernel module from scratch? Completely rewrite his code 
> >because it uses floating point arithmetics?
> 
> They use floating point in (Windows) kernelspace? Oh my.

Yes, definitely.  For example lots of Windows sound drivers do AC3
decoding in kernelspace.  Of course the vendors usually lie and say it's
done in hardware...

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Dave Jones]

On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote:

 > Anything else, you have to make some really scary decisions. Can a judge 
 > decide that a binary module is a derived work even though you didn't 
 > actually use any code? The real answer is: HELL YES. It's _entirely_ 
 > possible that a judge would find NVidia and ATI in violation of the GPLv2 
 > with their modules.

ATI in particular, I'm amazed their lawyers OK'd stuff like..

+ifdef STANDALONE
 MODULE_LICENSE(GPL);
+endif

This a paraphrased diff, it's been a while since I've seen it.
It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko,
but the usual use case is that it's built-in to fglrx.ko, which sounds
incredibly dubious.

Now, AGPGART has a murky past wrt licenses.  It initally was imported
into the tree with the license "GPL plus additional rights".
Nowhere was it actually documented what those rights were, but I'm
fairly certain it wasn't to enable nonsense like the above.
As it came from the XFree86 folks, it's more likely they really meant
"Dual GPL/MIT" or similar.

When I took over, any new code I wrote I explicitly set out to mark as GPL
code, as my modifications weren't being contributed back to X, they were
going back to the Linux kernel.  ATI took those AGPv3 modifications from
a 2.5 kernel, backported them to their 2.4 driver, and when time came
to do a 2.6 driver, instead of doing the sensible thing and dropping
them in favour of using the kernel AGP driver, they chose to forward
port their unholy abomination to 2.6.
It misses so many fixes (and introduces a number of other problems)
that its just unfunny.

The thing that really ticks me off though is the free support ATI seem
to think they're entitled to.  I've had end-users emailing me
"I asked ATI about this crash I've been seeing with fglrx, and they
 asked me to mail you".

I invest my time into improving free drivers.  When companies start
expecting me to debug their part binary garbage mixed with license
violations, frankly, I think they're taking the piss.

A year and a half ago, I met an ATI engineer at OLS, who told me they
were going to 'resolve this'.  I'm still waiting.
I live in hope that the AMD buyout will breathe some sanity into ATI.
Then again, I've only a limited supply of optimism.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Ricardo Galli]

> I think it would be a hell of a lot better idea if people just realized
> that they have "fair use" rights whether the authors give them or not, and
 ^
> that the authors copyrights NEVER extend to anything but a "derived work"
...
> I find the RIAA's position and the DMCA distasteful, and in that I
> probably have a lot of things in common with a lot of people on this list.
> But by _exactly_ the same token, I also find the FSF's position and a lot
> of GPL zealots' position on this matter very distasteful.
...
> Because "fair use" is NOT somethng that should be specified in the
  ^
> license.

As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried 
to change or restrict "fair use". GPL[23] covers only to "distibution" of the 
covered program. The freedom #0 says explicitly: "right to use the program 
for any purpose".

So, I don't see any clash here between GPL/FSF/RMS with "fair use"

And you probably know that any GPLed code can be linked and executed with any 
other program, whatever is its license if it's for personal use (is that 
worse than "fair use"?). 

And even if there is a function in linux that disables loading of non GPL 
modules, it's still allowed under the GPL to distribute a kernel with those 
functions removed. Any user can load any other module in this kernel without 
worrying about "fair use" or "derived work", GPL allows her to do it.

So, where's the freaking relationship between GPL (or its "zealots") and "fair 
use"? Who is trying to re-define it?

FUD, FUD, FUD.

-- 
  ricardo galli   GPG id C8114D34
  http://mnm.uib.es/gallir/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Linus Torvalds]

On Sat, 16 Dec 2006, Willy Tarreau wrote:
> 
> I understand your point, but not completely agree with the comparison,
> because I think that you (as the "author") are in the type of authors
> you describe below :
> 
> > Of course, all reasonable true authors tend to agree with fair use.

Sure. Sadly, in this day and age, "copyright owner" and "author" only bear 
a very passing resemblance to each other.

In a lot of areas, the AUTHOR may be a very reasonable person, and realize 
that fair use is a good thing, and perhaps even realize that in some 
places even unfair use can be a good thing (do you really think you should 
pay $20 for a DVD if you make $3 a month in a sweatshop in china? Maybe 
piracy sometimes is simply better..)

But the author may also have his own reasons for wanting to _deny_ fair 
use. Maybe he's just a royal a-hole, and wants to milk his work for 
whatever it's worth. But maybe he's a person with an agenda, and wants to 
ignore fair use because he wants to "improve the world for everybody", 
never mind that he tries to deny people a fundamental right in the 
process. I call those people a-holes too (in all fairness, they return the 
favor, so we're all even ;)

But even more commonly, the author simply doesn't control the copyright at 
all any more. In many areas (and software is one - including even large 
swaths of free software), the copyrights of a work is not really 
controlled by the author of the work, but by companies or foundations that 
have no reason to really try to educate people about "fair use".

So I actually think that the authors that actually UNDERSTAND fair use, 
and realize that people can use portions of their work without permission, 
AND that actually control their work is a very very very small subset of 
authors in general.

This has nothing to do with software per se, btw. Pick up one of the 
Calvin & Hobbes books by Bill Watterson - I think it may have been the "10 
year anniversary" one - where he talks about the disagreements he had with 
the people who actually controlled the copyrights (and I think also some 
of the people who used his artwork without any permission - the line 
between "fair use" and "illegal" really is a murky one, and while we 
should celebrate that murkiness, it's also why people disagree).

> > And I'd rather teach people that fundamental fact, than try to confuse the 
> > issue EVEN MORE by saying that my copyright only extends to derived works 
> > in the license text. That will just make people think that if the license 
> > does NOT say that, they don't have fair use. AND THAT IS WRONG.
> 
> That's a valid point. What is really needed is to tell them that if they
> doubt, they just have to ask the author and not be advised by any GPL zealot.

Well, in open source, there often isn't any one "the author". So you can't 
do that. And when there is, as mentioned, he may not actually even have 
the legal right any more to give you any license advice. And even when he 
does hold the copyrights, he may change his mind later.

So in the end, the thing you can and should depend on is: the license text 
itself (and happily, the GPLv2 very clearly talks about the real line 
being "derived work" - it may be a murky line, and they seem to want to 
change that to something harder in the GPLv3, but it's a good line), a 
separate signed contract, or simply a legal opinion, preferably by a judge 
in a court of law. 

Of course, it very seldom gets to that kind of issue. People tend to just 
walk very gently around it all.

If you want to be safe, you NEVER do any binary modules. The only 
_obviously_ safe thing is to always do only what the license very 
explicitly allows you to, and in the case of the GPLv2, that's to release 
all modifications under the same GPLv2.

Anything else, you have to make some really scary decisions. Can a judge 
decide that a binary module is a derived work even though you didn't 
actually use any code? The real answer is: HELL YES. It's _entirely_ 
possible that a judge would find NVidia and ATI in violation of the GPLv2 
with their modules.

Judges have done stranger things. And it's not my place to say what the 
limit of "derived work" actually is. It all probably depends on a lot of 
circumstances, and there simply isn't an easy answer.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/