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

[Scott Preece]

On 12/19/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

On Dec 19, 2006, "D. Hazelton" <[EMAIL PROTECTED]> wrote:

> However I have a feeling that the lawyers in the employ of the
> companies that ship BLOB drivers say that all they need to do to
> comply with the GPL is to ship the glue-code in source form.

> And I have to admit that this does seem to comply with the GPL - to the
> letter, if not the spirit.

I don't see that it does comply even with the letter.  Consider this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work
  based on the Program, the distribution of the whole must be on the
  terms of this License, whose permissions for other licensees extend
  to the entire whole, and thus to each and every part regardless of
  who wrote it.

The work, in this case, is the GPLed glue code, in source form, and
the binary blob, without sources.  See that, even though the binary
blob is an independent and separate work in itself, and so it can
indeed be distributed separaly under a different license, when it's
distributed as part of a whole, then the whole must be on the terms of
the GPL.

---

The question is what "the whole work" is. If the binary is not a
derived work, and is not prelinked with the work, then it seems likely
to be considered merely an aggregation, not requiring GPL licensing.
Note that there's some difficulty in the language, in that the GPL
uses "work based on the work" to mean something that it defines
specifically, while the Copyright Act defines "derived work" as "work
based on the work". THere is no equivalence there - The GPL's "work
based on the work" includes cases that do not fit the Act's
definition.

So, the GPL's requirement for licensing under the GPL clearly applies
to prelinked binaries, but it is not at all clear that it would apply
to a binary object, not derived from the kernel, shipped on the same
media. That is, the aggregation is NOT a modification of the original
work, it's just an aggregation (work of colective authorship).

---

...
Let's assume they're not intentionally violating the GPL, but rather
that they believe they're entitled to do what they're doing, i.e.,
that they believe (a) their glue code is not a derived work from
Linux.

In this case, they *can* distribute the glue source code under the GPL
along with their binary blob.  But can anyone else?

Methinks anyone else would be entitled to pass the same whole along
under the GPL, per section 1, but wouldn't be entitled to distribute
modified versions, because this would require the derived work to be
licensed under the GPL, and nobody else is able to provide the source
code to the binary blob.

---

I'm confused here.  If the glue code is not a derived work, then they
don't need to use the GPL at all. If they DO ue the GPL, then (as you
note) if they didn't include the source code, nobody else could
redistribute it because nobody else would be able to meet the license
terms. I would expect that if they were going to GPL the glue code,
they would also provide the source for it.

---

...
Well...  Not quite.  For one, even if enabling others to distribute
glue code + binary blobs were a good thing, using somebody else's glue
code means you're bound by the GPL requirements, so you can't ship the
combination of the glue code with your binary blob.

---

Only if you assume that using the glue code would make your blob a
derived work of the glue code. In many cases the point of the glue
code is to be an adapter between Linux and an existing interface. In
such a case, any binary blob using that interface would not be a
derived work of the glue code.

As before, though, if you linked the binary blob with the glue code
object, then the combined object probably would be a derived work and
have to conform to the GPL.

---

...
So, even if condoning binary blobs were morally acceptable, we still
wouldn't be gaining anything from this relationship, we'd only be
enabling vendors to sell us their undocumented hardware while denying
us our freedoms.

Why should we do this?

---

To enable the use of the hardware in Linux systems? Most people would
prefer well-documented hardware with free drivers, but when that isn't
available, many people might still like to be able to use the
hardware. It's less than ideal, but so is having no way at all to use
the hardware.

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

[David Schwartz]

> > However, those restrictions do not affect those who did not
> > agree to them.
> > For example, if I buy such a JVM and don't agree to the license
> > (assuming I
> > don't have to agree to the license to lawfully acquire the
> > JVM), I can give
> > it to a friend along with any other software I want.

> No

Yes.

> as with the language in the GPL, your right to distribute is
> provided by the license you received with the JVM, so if you don't
> accept it, you can't distribute.

This is flat out self-contradiction. If my right is provided by the license,
then I can distribute. If I don't accept the license, then how is my right
to distribute provided by it?

The paragraph you are saying "No" to is completely correct and your response
is complete double-speak.

> However, the first sale doctrine
> provides a limited exception;

Exactly. So the idea that you can't distribute a work unless you agree to
its license is nonsense. With a license like the GPL, that is something that
is not a shrink-wrap, click-through, or EULA, the license does not apply to
anyone who does not agree to it. The GPL makes this totally clear in section
5.

If you don't accept the license, you simply don't get the additional rights
the license offers. You still have all the rights you originally had.

> if you got the JVM through an
> unrestricted sale, then you would normally have the right to sell that
> particular copy without any further license (though possibly not to
> someone in a different part of the world).

Your license to distribute is provided by the license if and only if you
agree to the license. Otherwise, it's as if the license doesn't exist. You
can get the right to distribute the work any other way that may be available
to you. First sale is just one example.

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

[Scott Preece]

On 12/20/06, David Schwartz <[EMAIL PROTECTED]> wrote:


> I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I
> think that "objcopy" does create a derived work, and "ld" does too, by
> virtue of modifying the objects it takes to resolve symbols. ...

The question is, as a matter of copyright law, what right do you need to
distribute the aggregate? As I understand the law, the answer is that you
need the right to distribute each of the individual works in the aggregate.
Fortunately, you can trivially get the right to distribute any GPL'd work
under first sale. (Simply download as many copies as you plan to
distribute.)

To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
card and ship the two of them together to your mother.

---

If the aggregate is not a derived work, then you only need the
separate permissions for the original works. If the aggregate is a
derived work, then you need permissions relative to the derived work,
not just the original work - essenitlally, permission to modify the
work. And, the permissions would all have to allow the specific form
of distribution and aggregation involved. [Don't give me back the
example of breaking the DVD in half - "the work" is not the medium;
your purchase of a DVD does not give you the right to modify the movie
it carries and redistribute the modified version, even under first
sale.]

---


>This is an interesting argument that was new to me. However, it is not
>clear at all that First Sale applies to intangible copies. And it's
>not clear that there is a sale involved, legally. Again, IANAL, but I
>think this is seriously untested ground.

First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding
the provisions of section 106 (3), the owner of a particular copy or
phonorecord lawfully made under this title, or any person authorized by such
owner, is entitled, without the authority of the copyright owner, to sell or
otherwise dispose of the possession of that copy or phonorecord."

---

While I generally agree with you that first sale can occur without an
actual sale, the GPL (and distribution by free download in general) is
an odd situation (the law wasn't designed for works that could be
freely copied) and I would not suggest anyone depend on a court to
interpret that clause the way you are.

---

I'm not really qualified to respond to the argument that first sale doesn't
apply to an intangible copy. As the law is written, it simply refers to the
owner of a "a particular copy". Sometimes "a copy" only means tangible
copies and sometimes it simply means the result of copying. It seems bizarre
to me, however, to argue that if I lawfully download a program, I need
special permission from the copyright holder to put it on CD but not a hard
drive. What is the *legal* difference? And if I put it no a hard drive, I
can't sell it? Seems crazy to me.

---

Nevertheless, the only decided cases I could find in the area went the
other way - saying that intangible copies did not exhaust the author's
distribution rights. Note that your example is misleading - you don't
need different permission to put it on a CD than to put it on a hard
drive, but you might not have permission to distribute it (depending
on the terms under which you received it). There is case law finding
that, in at least some cases, the author's rights in particular copies
(even tangible copies) was not exhausted.

---


Nobody ever said a copyright holder couldn't restrict the distribution of
his software when such distribution is not authorized by things like fair
use, first sale, or other things. Of course a copyright holder can set any
rules he want for those distributions not authorized by law.

However, those restrictions do not affect those who did not agree to them.
For example, if I buy such a JVM and don't agree to the license (assuming I
don't have to agree to the license to lawfully acquire the JVM), I can give
it to a friend along with any other software I want.

---

No, as with the language in the GPL, your right to distribute is
provided by the license you received with the JVM, so if you don't
accept it, you can't distribute. However, the first sale doctrine
provides a limited exception; if you got the JVM through an
unrestricted sale, then you would normally have the right to sell that
particular copy without any further license (though possibly not to
someone in a different part of the world).

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]

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

[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: 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

[David Schwartz]

Note: Combined responses.

> I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I
> think that "objcopy" does create a derived work, and "ld" does too, by
> virtue of modifying the objects it takes to resolve symbols. Now, you
> could distribute to somebody an ar archive of your program, and the
> recipient (given fair use rights to the copy of the program they
> received)
> could do "gcc program.a -o program" to link it. But I don't think you
> automatically get the right (under the "mere aggregation" permission) to
> distribute the result of relocating the symbols of gnutls around those of
> your program and vice versa, along with modifying the references to
> external symbols from each of these to point to specific locations.

The question is, as a matter of copyright law, what right do you need to
distribute the aggregate? As I understand the law, the answer is that you
need the right to distribute each of the individual works in the aggregate.
Fortunately, you can trivially get the right to distribute any GPL'd work
under first sale. (Simply download as many copies as you plan to
distribute.)

To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
card and ship the two of them together to your mother.

--

>This is an interesting argument that was new to me. However, it is not
>clear at all that First Sale applies to intangible copies. And it's
>not clear that there is a sale involved, legally. Again, IANAL, but I
>think this is seriously untested ground.

First sale has nothing do with a sale. 17 USC 109(a) says, "Notwithstanding
the provisions of section 106 (3), the owner of a particular copy or
phonorecord lawfully made under this title, or any person authorized by such
owner, is entitled, without the authority of the copyright owner, to sell or
otherwise dispose of the possession of that copy or phonorecord."

I think it's well settled law that everyone who lawfully acquires a copy of
a copyrighted work has the right to its normal expected use and may transfer
that right along with their copy to another without needing any special
permission from the copyright holder. Exceptions would include cases where
there was specific assent to a license, such as shrink-wrap, click-through,
or EULA.

I'm not really qualified to respond to the argument that first sale doesn't
apply to an intangible copy. As the law is written, it simply refers to the
owner of a "a particular copy". Sometimes "a copy" only means tangible
copies and sometimes it simply means the result of copying. It seems bizarre
to me, however, to argue that if I lawfully download a program, I need
special permission from the copyright holder to put it on CD but not a hard
drive. What is the *legal* difference? And if I put it no a hard drive, I
can't sell it? Seems crazy to me.

--

>AFAIK it's perfectly legitimate (even if immoral) for a copyright
>license to prohibit the distribution of the software governed by the
>license with anything else the author establishes.  E.g., some Java
>virtual machine's license used to establish that you couldn't ship it
>along with other implementations of Java that didn't pass some
>comformance test.

Nobody ever said a copyright holder couldn't restrict the distribution of
his software when such distribution is not authorized by things like fair
use, first sale, or other things. Of course a copyright holder can set any
rules he want for those distributions not authorized by law.

However, those restrictions do not affect those who did not agree to them.
For example, if I buy such a JVM and don't agree to the license (assuming I
don't have to agree to the license to lawfully acquire the JVM), I can give
it to a friend along with any other software I want.

--

>A bare license probably cannot take them away, since you haven't
>agreed to anything.  But (1) that may not be true in all legal
>systems, and (2) a contract-based license can take it away (e.g. an
>NDA).  So the GPL's clarification is worthwhile.  For the same reason,
>I'm guessing, the Creative Commons licenses have (also in section 2,
>at least in v2.5):

The clarification serves another important purpose as well. If some
provision is ambiguous and admits of two readins, one which conflicts with
fair use and would not be enforceable and one which doesn't that is, these
disclaimers make clear that the latter interpretation is the one that should
be chosen. So they may actually *increase* the scope of the license.

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

[David Schwartz]

Note: Combined responses.

 I'd agree that ar, like mkisofs, doesn't create a derived work, but I
 think that objcopy does create a derived work, and ld does too, by
 virtue of modifying the objects it takes to resolve symbols. Now, you
 could distribute to somebody an ar archive of your program, and the
 recipient (given fair use rights to the copy of the program they
 received)
 could do gcc program.a -o program to link it. But I don't think you
 automatically get the right (under the mere aggregation permission) to
 distribute the result of relocating the symbols of gnutls around those of
 your program and vice versa, along with modifying the references to
 external symbols from each of these to point to specific locations.

The question is, as a matter of copyright law, what right do you need to
distribute the aggregate? As I understand the law, the answer is that you
need the right to distribute each of the individual works in the aggregate.
Fortunately, you can trivially get the right to distribute any GPL'd work
under first sale. (Simply download as many copies as you plan to
distribute.)

To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
card and ship the two of them together to your mother.

--

This is an interesting argument that was new to me. However, it is not
clear at all that First Sale applies to intangible copies. And it's
not clear that there is a sale involved, legally. Again, IANAL, but I
think this is seriously untested ground.

First sale has nothing do with a sale. 17 USC 109(a) says, Notwithstanding
the provisions of section 106 (3), the owner of a particular copy or
phonorecord lawfully made under this title, or any person authorized by such
owner, is entitled, without the authority of the copyright owner, to sell or
otherwise dispose of the possession of that copy or phonorecord.

I think it's well settled law that everyone who lawfully acquires a copy of
a copyrighted work has the right to its normal expected use and may transfer
that right along with their copy to another without needing any special
permission from the copyright holder. Exceptions would include cases where
there was specific assent to a license, such as shrink-wrap, click-through,
or EULA.

I'm not really qualified to respond to the argument that first sale doesn't
apply to an intangible copy. As the law is written, it simply refers to the
owner of a a particular copy. Sometimes a copy only means tangible
copies and sometimes it simply means the result of copying. It seems bizarre
to me, however, to argue that if I lawfully download a program, I need
special permission from the copyright holder to put it on CD but not a hard
drive. What is the *legal* difference? And if I put it no a hard drive, I
can't sell it? Seems crazy to me.

--

AFAIK it's perfectly legitimate (even if immoral) for a copyright
license to prohibit the distribution of the software governed by the
license with anything else the author establishes.  E.g., some Java
virtual machine's license used to establish that you couldn't ship it
along with other implementations of Java that didn't pass some
comformance test.

Nobody ever said a copyright holder couldn't restrict the distribution of
his software when such distribution is not authorized by things like fair
use, first sale, or other things. Of course a copyright holder can set any
rules he want for those distributions not authorized by law.

However, those restrictions do not affect those who did not agree to them.
For example, if I buy such a JVM and don't agree to the license (assuming I
don't have to agree to the license to lawfully acquire the JVM), I can give
it to a friend along with any other software I want.

--

A bare license probably cannot take them away, since you haven't
agreed to anything.  But (1) that may not be true in all legal
systems, and (2) a contract-based license can take it away (e.g. an
NDA).  So the GPL's clarification is worthwhile.  For the same reason,
I'm guessing, the Creative Commons licenses have (also in section 2,
at least in v2.5):

The clarification serves another important purpose as well. If some
provision is ambiguous and admits of two readins, one which conflicts with
fair use and would not be enforceable and one which doesn't that is, these
disclaimers make clear that the latter interpretation is the one that should
be chosen. So they may actually *increase* the scope of the license.

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]

[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 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: 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

[Scott Preece]

On 12/20/06, David Schwartz [EMAIL PROTECTED] wrote:


 I'd agree that ar, like mkisofs, doesn't create a derived work, but I
 think that objcopy does create a derived work, and ld does too, by
 virtue of modifying the objects it takes to resolve symbols. ...

The question is, as a matter of copyright law, what right do you need to
distribute the aggregate? As I understand the law, the answer is that you
need the right to distribute each of the individual works in the aggregate.
Fortunately, you can trivially get the right to distribute any GPL'd work
under first sale. (Simply download as many copies as you plan to
distribute.)

To argue otherwise would be to argue that you can't buy a DVD and a Hallmark
card and ship the two of them together to your mother.

---

If the aggregate is not a derived work, then you only need the
separate permissions for the original works. If the aggregate is a
derived work, then you need permissions relative to the derived work,
not just the original work - essenitlally, permission to modify the
work. And, the permissions would all have to allow the specific form
of distribution and aggregation involved. [Don't give me back the
example of breaking the DVD in half - the work is not the medium;
your purchase of a DVD does not give you the right to modify the movie
it carries and redistribute the modified version, even under first
sale.]

---


This is an interesting argument that was new to me. However, it is not
clear at all that First Sale applies to intangible copies. And it's
not clear that there is a sale involved, legally. Again, IANAL, but I
think this is seriously untested ground.

First sale has nothing do with a sale. 17 USC 109(a) says, Notwithstanding
the provisions of section 106 (3), the owner of a particular copy or
phonorecord lawfully made under this title, or any person authorized by such
owner, is entitled, without the authority of the copyright owner, to sell or
otherwise dispose of the possession of that copy or phonorecord.

---

While I generally agree with you that first sale can occur without an
actual sale, the GPL (and distribution by free download in general) is
an odd situation (the law wasn't designed for works that could be
freely copied) and I would not suggest anyone depend on a court to
interpret that clause the way you are.

---

I'm not really qualified to respond to the argument that first sale doesn't
apply to an intangible copy. As the law is written, it simply refers to the
owner of a a particular copy. Sometimes a copy only means tangible
copies and sometimes it simply means the result of copying. It seems bizarre
to me, however, to argue that if I lawfully download a program, I need
special permission from the copyright holder to put it on CD but not a hard
drive. What is the *legal* difference? And if I put it no a hard drive, I
can't sell it? Seems crazy to me.

---

Nevertheless, the only decided cases I could find in the area went the
other way - saying that intangible copies did not exhaust the author's
distribution rights. Note that your example is misleading - you don't
need different permission to put it on a CD than to put it on a hard
drive, but you might not have permission to distribute it (depending
on the terms under which you received it). There is case law finding
that, in at least some cases, the author's rights in particular copies
(even tangible copies) was not exhausted.

---


Nobody ever said a copyright holder couldn't restrict the distribution of
his software when such distribution is not authorized by things like fair
use, first sale, or other things. Of course a copyright holder can set any
rules he want for those distributions not authorized by law.

However, those restrictions do not affect those who did not agree to them.
For example, if I buy such a JVM and don't agree to the license (assuming I
don't have to agree to the license to lawfully acquire the JVM), I can give
it to a friend along with any other software I want.

---

No, as with the language in the GPL, your right to distribute is
provided by the license you received with the JVM, so if you don't
accept it, you can't distribute. However, the first sale doctrine
provides a limited exception; if you got the JVM through an
unrestricted sale, then you would normally have the right to sell that
particular copy without any further license (though possibly not to
someone in a different part of the world).

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

[David Schwartz]

  However, those restrictions do not affect those who did not
  agree to them.
  For example, if I buy such a JVM and don't agree to the license
  (assuming I
  don't have to agree to the license to lawfully acquire the
  JVM), I can give
  it to a friend along with any other software I want.

 No

Yes.

 as with the language in the GPL, your right to distribute is
 provided by the license you received with the JVM, so if you don't
 accept it, you can't distribute.

This is flat out self-contradiction. If my right is provided by the license,
then I can distribute. If I don't accept the license, then how is my right
to distribute provided by it?

The paragraph you are saying No to is completely correct and your response
is complete double-speak.

 However, the first sale doctrine
 provides a limited exception;

Exactly. So the idea that you can't distribute a work unless you agree to
its license is nonsense. With a license like the GPL, that is something that
is not a shrink-wrap, click-through, or EULA, the license does not apply to
anyone who does not agree to it. The GPL makes this totally clear in section
5.

If you don't accept the license, you simply don't get the additional rights
the license offers. You still have all the rights you originally had.

 if you got the JVM through an
 unrestricted sale, then you would normally have the right to sell that
 particular copy without any further license (though possibly not to
 someone in a different part of the world).

Your license to distribute is provided by the license if and only if you
agree to the license. Otherwise, it's as if the license doesn't exist. You
can get the right to distribute the work any other way that may be available
to you. First sale is just one example.

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

[Scott Preece]

On 12/19/06, Alexandre Oliva [EMAIL PROTECTED] wrote:

On Dec 19, 2006, D. Hazelton [EMAIL PROTECTED] wrote:

 However I have a feeling that the lawyers in the employ of the
 companies that ship BLOB drivers say that all they need to do to
 comply with the GPL is to ship the glue-code in source form.

 And I have to admit that this does seem to comply with the GPL - to the
 letter, if not the spirit.

I don't see that it does comply even with the letter.  Consider this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work
  based on the Program, the distribution of the whole must be on the
  terms of this License, whose permissions for other licensees extend
  to the entire whole, and thus to each and every part regardless of
  who wrote it.

The work, in this case, is the GPLed glue code, in source form, and
the binary blob, without sources.  See that, even though the binary
blob is an independent and separate work in itself, and so it can
indeed be distributed separaly under a different license, when it's
distributed as part of a whole, then the whole must be on the terms of
the GPL.

---

The question is what the whole work is. If the binary is not a
derived work, and is not prelinked with the work, then it seems likely
to be considered merely an aggregation, not requiring GPL licensing.
Note that there's some difficulty in the language, in that the GPL
uses work based on the work to mean something that it defines
specifically, while the Copyright Act defines derived work as work
based on the work. THere is no equivalence there - The GPL's work
based on the work includes cases that do not fit the Act's
definition.

So, the GPL's requirement for licensing under the GPL clearly applies
to prelinked binaries, but it is not at all clear that it would apply
to a binary object, not derived from the kernel, shipped on the same
media. That is, the aggregation is NOT a modification of the original
work, it's just an aggregation (work of colective authorship).

---

...
Let's assume they're not intentionally violating the GPL, but rather
that they believe they're entitled to do what they're doing, i.e.,
that they believe (a) their glue code is not a derived work from
Linux.

In this case, they *can* distribute the glue source code under the GPL
along with their binary blob.  But can anyone else?

Methinks anyone else would be entitled to pass the same whole along
under the GPL, per section 1, but wouldn't be entitled to distribute
modified versions, because this would require the derived work to be
licensed under the GPL, and nobody else is able to provide the source
code to the binary blob.

---

I'm confused here.  If the glue code is not a derived work, then they
don't need to use the GPL at all. If they DO ue the GPL, then (as you
note) if they didn't include the source code, nobody else could
redistribute it because nobody else would be able to meet the license
terms. I would expect that if they were going to GPL the glue code,
they would also provide the source for it.

---

...
Well...  Not quite.  For one, even if enabling others to distribute
glue code + binary blobs were a good thing, using somebody else's glue
code means you're bound by the GPL requirements, so you can't ship the
combination of the glue code with your binary blob.

---

Only if you assume that using the glue code would make your blob a
derived work of the glue code. In many cases the point of the glue
code is to be an adapter between Linux and an existing interface. In
such a case, any binary blob using that interface would not be a
derived work of the glue code.

As before, though, if you linked the binary blob with the glue code
object, then the combined object probably would be a derived work and
have to conform to the GPL.

---

...
So, even if condoning binary blobs were morally acceptable, we still
wouldn't be gaining anything from this relationship, we'd only be
enabling vendors to sell us their undocumented hardware while denying
us our freedoms.

Why should we do this?

---

To enable the use of the hardware in Linux systems? Most people would
prefer well-documented hardware with free drivers, but when that isn't
available, many people might still like to be able to use the
hardware. It's less than ideal, but so is having no way at all to use
the hardware.

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]

[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

[Alexandre Oliva]

On Dec 19, 2006, "Horst H. von Brand" <[EMAIL PROTECTED]> wrote:

> Sanjoy Mahajan <[EMAIL PROTECTED]> wrote:

>> This License acknowledges your rights of "fair use" or other
>> equivalent, as provided by copyright law. 

>> By choosing 'acknowledges' as the verb, the licensee says explicitly
>> that fair-use rights are already yours, not that they are being given
>> to you.

> Pure noise, a license can't take them away in any case.

Yeah, that's merely informative, indeed.  Point is to ensure people
know their rights, while at the same time avoiding giving impressions
such the one Linus somehow got.

> [That is my pet pevee with GPL: It has a bit of legally binding text, and
>  lots of "explanation" and "philosophy" that don't add anything but
>  confusion. A clear-cut license plus an explanation/comment would have been
>  better. IMHO, IANAL. HAND.]

This bit would probably fit better in the spirit (preamble) than in
the letter.  That's why I filed the comment about it in the preamble.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 19, 2006, "D. Hazelton" <[EMAIL PROTECTED]> wrote:

> However I have a feeling that the lawyers in the employ of the
> companies that ship BLOB drivers say that all they need to do to
> comply with the GPL is to ship the glue-code in source form.

> And I have to admit that this does seem to comply with the GPL - to the 
> letter, if not the spirit.

I don't see that it does comply even with the letter.  Consider this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work
  based on the Program, the distribution of the whole must be on the
  terms of this License, whose permissions for other licensees extend
  to the entire whole, and thus to each and every part regardless of
  who wrote it.

The work, in this case, is the GPLed glue code, in source form, and
the binary blob, without sources.  See that, even though the binary
blob is an independent and separate work in itself, and so it can
indeed be distributed separaly under a different license, when it's
distributed as part of a whole, then the whole must be on the terms of
the GPL.

So the question becomes whether the copyright holder of the glue code
bound by these GPL terms.

(a) If the glue code can be shown to be a derived work from Linux,
even in source form, then the copyright holder *is* bound by these
terms, and thus the whole could only be distributed under the GPL, so
including the binary blob would be in violation of the license.

(b) Now, if the glue code is *not* a derived work from Linux, then the
copyright holder is entitled to use whatever terms she likes.  It
could be any license whatsoever, that permits the distribution of the
whole or of the parts with whatever constraints copyright law
permitted.  Why would they choose the GPL in this case, then?


Let's assume they're not intentionally violating the GPL, but rather
that they believe they're entitled to do what they're doing, i.e.,
that they believe (a) their glue code is not a derived work from
Linux.

In this case, they *can* distribute the glue source code under the GPL
along with their binary blob.  But can anyone else?

Methinks anyone else would be entitled to pass the same whole along
under the GPL, per section 1, but wouldn't be entitled to distribute
modified versions, because this would require the derived work to be
licensed under the GPL, and nobody else is able to provide the source
code to the binary blob.

And then, who'd be entitled to complain?  Only the copyright holder of
the glue code and the binary blob.

Would you like to be on the wrong end of a copyright infringement
lawsuit by one of these binary blob distributors for distributing a
patched version of their glue code + binary blob?  More to the point,
do you think they would actually bring suit, just to make it clear
that the whole point is for them to keep a monopoly on the rights to
modify and then distribute the combined work, in spite of using the
GPL for (part of) the work?


It gets trickier for binaries, since they are quite possibly derived
works from the kernel, licensed under the GPL.  If they are, they
can't be distributed at all, not even by the copyright holder of the
glue code + binary blob.  If they aren't, then the copyright holder
can distribute them, but nobody else can because that would be a
violation of the GPL, as in the discussion above.  So, the copyright
holder would be keeping a monopoly on the rights to distribute
binaries, and anyone else could be sued by them.


Sure enough, one might think of praising them for distributing the
glue code under the GPL.  Then others could take this glue code and
use it for something else that is useful, right?

Well...  Not quite.  For one, even if enabling others to distribute
glue code + binary blobs were a good thing, using somebody else's glue
code means you're bound by the GPL requirements, so you can't ship the
combination of the glue code with your binary blob.

And then, if you intend to use the glue code to plug in some other
code that is GPL-compatible in the kernel, perhaps you'd be better off
not using the glue code at all, but rather modifying the
GPL-compatible code to fit.

So, even if condoning binary blobs were morally acceptable, we still
wouldn't be gaining anything from this relationship, we'd only be
enabling vendors to sell us their undocumented hardware while denying
us our freedoms.

Why should we do this?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from 

Re: GPL only modules

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> It makes no difference whether the "mere aggregation" paragraph kicks in
> because the "mere aggregation" paragraph is *explaining* the *law*. What
> matters is what the law actually *says*.

You mean "mere aggregation" is defined in copyright law?  I don't
think so, otherwise the term 'aggregate' probably wouldn't have
been used in GPLv3.

AFAIK it's perfectly legitimate (even if immoral) for a copyright
license to prohibit the distribution of the software governed by the
license with anything else the author establishes.  E.g., some Java
virtual machine's license used to establish that you couldn't ship it
along with other implementations of Java that didn't pass some
comformance test.

Now, the GPL doesn't do this.  It doesn't say you can't distribute
GPLed software along with any other software.  It only says that, when
you distribute together works that don't constitute mere aggregation
(providing its own definition of mere aggregation), then the whole
must be licensed under the GPL.

> The GPL could say that if you ever see the source code to a GPL'd work,
> every work you ever write must be placed under the GPL. But that wouldn't
> make it true, because that would be a requirement outside the GPL's scope.

It is indeed possible that this would fall outside the scope of
copyright law in the US, and it would not be morally acceptable for
the GPL to impose such a condition.  But then, since nobody can be
forced to see the source code of a GPLed work, or any work for that
matter, acceptance is voluntary, and one shouldn't enter an agreement
one's not willing to abide by.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> I don't see why you can't distribute a single DVD that combines the contents
> of the two you bought, so long as you destroy the originals.

Because, for example, per Brazilian law since 1998, fair use only
grants you the right to copy small portions of copyrighted works for
personal use.   http://www.petitiononline.com/netlivre

Remember that the GPL is not only about US copyright law or US
courts.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 18, 2006, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> No automated, mechanical process can create a derivative work of software.
> (With a few exceptions not relevant here.)

Can you explain what mechanisms are involved in copyright monopolies
over object code, then?
(there's a hint at http://www.fsfla.org/?q=en/node/128#1 )

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Sanjoy Mahajan]

>> [GPL acknowledging fair-use rights]

> Pure noise, a license can't take them away in any case.

A bare license probably cannot take them away, since you haven't
agreed to anything.  But (1) that may not be true in all legal
systems, and (2) a contract-based license can take it away (e.g. an
NDA).  So the GPL's clarification is worthwhile.  For the same reason,
I'm guessing, the Creative Commons licenses have (also in section 2,
at least in v2.5):

   2. Fair Use Rights. Nothing in this license is intended to reduce,
   limit, or restrict any rights arising from fair use, first sale or
   other limitations on the exclusive rights of the copyright owner
   under copyright law or other applicable laws.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
 --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
-
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

[David Lang]

On Tue, 19 Dec 2006, D. Hazelton wrote:


This doesn't negate any problems with people making Blob drivers, because, as
you pointed out, under the same laws they aren't a derivative work, which
means that that clause of the license doesn't apply. Now if the GPL contained
a clause specifically defining what it considered a derivative work things
would be different.


incorrect, the GPL (or any other license) cannot define what is a derived work, 
the law does that. they could have a clause in them that said that something 
that is a derived work under the law is not considered a derived work by the 
author (implicitly giving unrestricted permission to that something), but you 
cannot define something that the law doesn't consider a derived work to be one 
in the license.


David Lang

-
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

[Scott Preece]

On 12/18/06, David Schwartz <[EMAIL PROTECTED]> wrote:



> First sale has nothing to do with this. First sale applies to the
> redistribution or resale of copies you have purchased, not with the
> right to make additional copies.

First sale is exactly what this is about. Nobody needs to make "additional
copies" of the Linux kernel because I can download a thousand of them from a
computer operated by the guy in the office down the hall from me.

---

This is an interesting argument that was new to me. However, it is not
clear at all that First Sale applies to intangible copies. And it's
not clear that there is a sale involved, legally. Again, IANAL, but I
think this is seriously untested ground.

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]

[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

[Horst H. von Brand]

Sanjoy Mahajan <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> > That said, I think they are still pushing the "you don't have any
> > rights unless we give you additional rights explicitly" angle a bit
> > too hard.
> 
> From section 2 (GPLv3, draft 2):
> 
>  This License acknowledges your rights of "fair use" or other
>  equivalent, as provided by copyright law. 
> 
> By choosing 'acknowledges' as the verb, the licensee says explicitly
> that fair-use rights are already yours, not that they are being given
> to you.

Pure noise, a license can't take them away in any case.

[That is my pet pevee with GPL: It has a bit of legally binding text, and
 lots of "explanation" and "philosophy" that don't add anything but
 confusion. A clear-cut license plus an explanation/comment would have been
 better. IMHO, IANAL. HAND.]
-- 
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 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

[Horst H. von Brand]

D. Hazelton <[EMAIL PROTECTED]> wrote:

[...]

> The GPL is a License that covers how the code may be used, modified and 
> distributed. This is the reason that the FSF people had to make the big 
> exception for Bison, because the parser skeleton is such an integral part of 
> Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the 
> program) that truthfully, any parser built using Bison is a derivative work 
> of code released under the GPL.

They didn't "have to make the big exception", if Linus' view is correct:
The parser is built mechanically from the skeleton and the user's input, so
it is just an aggregation. Sure, it is best to make this clear (by the
exception), even if not needed.

> That said, since there is a distribution, use and modification license on
> the Linux Kernel - the GPLv2 - there are those extra restrictions on the
> code *OUTSIDE* the copyright rules.

A license like GPL works /inside/ copyright law, by allowing you to do
things the law prohibits unless the owner of the right agrees. What the law
allows explicitly, regardless of the owner's wishes, can't be taken away.
-- 
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

[Sanjoy Mahajan]

Linus Torvalds wrote:
> That said, I think they are still pushing the "you don't have any
> rights unless we give you additional rights explicitly" angle a bit
> too hard.

>From section 2 (GPLv3, draft 2):

 This License acknowledges your rights of "fair use" or other
 equivalent, as provided by copyright law. 

By choosing 'acknowledges' as the verb, the licensee says explicitly
that fair-use rights are already yours, not that they are being given
to you.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
 --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
-
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

[Sanjoy Mahajan]

Linus Torvalds wrote:
 That said, I think they are still pushing the you don't have any
 rights unless we give you additional rights explicitly angle a bit
 too hard.

From section 2 (GPLv3, draft 2):

 This License acknowledges your rights of fair use or other
 equivalent, as provided by copyright law. 

By choosing 'acknowledges' as the verb, the licensee says explicitly
that fair-use rights are already yours, not that they are being given
to you.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
 --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
-
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

[Horst H. von Brand]

D. Hazelton [EMAIL PROTECTED] wrote:

[...]

 The GPL is a License that covers how the code may be used, modified and 
 distributed. This is the reason that the FSF people had to make the big 
 exception for Bison, because the parser skeleton is such an integral part of 
 Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the 
 program) that truthfully, any parser built using Bison is a derivative work 
 of code released under the GPL.

They didn't have to make the big exception, if Linus' view is correct:
The parser is built mechanically from the skeleton and the user's input, so
it is just an aggregation. Sure, it is best to make this clear (by the
exception), even if not needed.

 That said, since there is a distribution, use and modification license on
 the Linux Kernel - the GPLv2 - there are those extra restrictions on the
 code *OUTSIDE* the copyright rules.

A license like GPL works /inside/ copyright law, by allowing you to do
things the law prohibits unless the owner of the right agrees. What the law
allows explicitly, regardless of the owner's wishes, can't be taken away.
-- 
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 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

[Horst H. von Brand]

Sanjoy Mahajan [EMAIL PROTECTED] wrote:
 Linus Torvalds wrote:
  That said, I think they are still pushing the you don't have any
  rights unless we give you additional rights explicitly angle a bit
  too hard.
 
 From section 2 (GPLv3, draft 2):
 
  This License acknowledges your rights of fair use or other
  equivalent, as provided by copyright law. 
 
 By choosing 'acknowledges' as the verb, the licensee says explicitly
 that fair-use rights are already yours, not that they are being given
 to you.

Pure noise, a license can't take them away in any case.

[That is my pet pevee with GPL: It has a bit of legally binding text, and
 lots of explanation and philosophy that don't add anything but
 confusion. A clear-cut license plus an explanation/comment would have been
 better. IMHO, IANAL. HAND.]
-- 
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]

[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

[Scott Preece]

On 12/18/06, David Schwartz [EMAIL PROTECTED] wrote:



 First sale has nothing to do with this. First sale applies to the
 redistribution or resale of copies you have purchased, not with the
 right to make additional copies.

First sale is exactly what this is about. Nobody needs to make additional
copies of the Linux kernel because I can download a thousand of them from a
computer operated by the guy in the office down the hall from me.

---

This is an interesting argument that was new to me. However, it is not
clear at all that First Sale applies to intangible copies. And it's
not clear that there is a sale involved, legally. Again, IANAL, but I
think this is seriously untested ground.

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

[David Lang]

On Tue, 19 Dec 2006, D. Hazelton wrote:


This doesn't negate any problems with people making Blob drivers, because, as
you pointed out, under the same laws they aren't a derivative work, which
means that that clause of the license doesn't apply. Now if the GPL contained
a clause specifically defining what it considered a derivative work things
would be different.


incorrect, the GPL (or any other license) cannot define what is a derived work, 
the law does that. they could have a clause in them that said that something 
that is a derived work under the law is not considered a derived work by the 
author (implicitly giving unrestricted permission to that something), but you 
cannot define something that the law doesn't consider a derived work to be one 
in the license.


David Lang

-
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

[Sanjoy Mahajan]

 [GPL acknowledging fair-use rights]

 Pure noise, a license can't take them away in any case.

A bare license probably cannot take them away, since you haven't
agreed to anything.  But (1) that may not be true in all legal
systems, and (2) a contract-based license can take it away (e.g. an
NDA).  So the GPL's clarification is worthwhile.  For the same reason,
I'm guessing, the Creative Commons licenses have (also in section 2,
at least in v2.5):

   2. Fair Use Rights. Nothing in this license is intended to reduce,
   limit, or restrict any rights arising from fair use, first sale or
   other limitations on the exclusive rights of the copyright owner
   under copyright law or other applicable laws.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
 --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
-
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

[Alexandre Oliva]

On Dec 18, 2006, David Schwartz [EMAIL PROTECTED] wrote:

 No automated, mechanical process can create a derivative work of software.
 (With a few exceptions not relevant here.)

Can you explain what mechanisms are involved in copyright monopolies
over object code, then?
(there's a hint at http://www.fsfla.org/?q=en/node/128#1 )

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 18, 2006, David Schwartz [EMAIL PROTECTED] wrote:

 I don't see why you can't distribute a single DVD that combines the contents
 of the two you bought, so long as you destroy the originals.

Because, for example, per Brazilian law since 1998, fair use only
grants you the right to copy small portions of copyrighted works for
personal use.   http://www.petitiononline.com/netlivre

Remember that the GPL is not only about US copyright law or US
courts.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 18, 2006, David Schwartz [EMAIL PROTECTED] wrote:

 It makes no difference whether the mere aggregation paragraph kicks in
 because the mere aggregation paragraph is *explaining* the *law*. What
 matters is what the law actually *says*.

You mean mere aggregation is defined in copyright law?  I don't
think so, otherwise the term 'aggregate' probably wouldn't have
been used in GPLv3.

AFAIK it's perfectly legitimate (even if immoral) for a copyright
license to prohibit the distribution of the software governed by the
license with anything else the author establishes.  E.g., some Java
virtual machine's license used to establish that you couldn't ship it
along with other implementations of Java that didn't pass some
comformance test.

Now, the GPL doesn't do this.  It doesn't say you can't distribute
GPLed software along with any other software.  It only says that, when
you distribute together works that don't constitute mere aggregation
(providing its own definition of mere aggregation), then the whole
must be licensed under the GPL.

 The GPL could say that if you ever see the source code to a GPL'd work,
 every work you ever write must be placed under the GPL. But that wouldn't
 make it true, because that would be a requirement outside the GPL's scope.

It is indeed possible that this would fall outside the scope of
copyright law in the US, and it would not be morally acceptable for
the GPL to impose such a condition.  But then, since nobody can be
forced to see the source code of a GPLed work, or any work for that
matter, acceptance is voluntary, and one shouldn't enter an agreement
one's not willing to abide by.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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

[Alexandre Oliva]

On Dec 19, 2006, D. Hazelton [EMAIL PROTECTED] wrote:

 However I have a feeling that the lawyers in the employ of the
 companies that ship BLOB drivers say that all they need to do to
 comply with the GPL is to ship the glue-code in source form.

 And I have to admit that this does seem to comply with the GPL - to the 
 letter, if not the spirit.

I don't see that it does comply even with the letter.  Consider this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections when you distribute them as separate works.  But when you
  distribute the same sections as part of a whole which is a work
  based on the Program, the distribution of the whole must be on the
  terms of this License, whose permissions for other licensees extend
  to the entire whole, and thus to each and every part regardless of
  who wrote it.

The work, in this case, is the GPLed glue code, in source form, and
the binary blob, without sources.  See that, even though the binary
blob is an independent and separate work in itself, and so it can
indeed be distributed separaly under a different license, when it's
distributed as part of a whole, then the whole must be on the terms of
the GPL.

So the question becomes whether the copyright holder of the glue code
bound by these GPL terms.

(a) If the glue code can be shown to be a derived work from Linux,
even in source form, then the copyright holder *is* bound by these
terms, and thus the whole could only be distributed under the GPL, so
including the binary blob would be in violation of the license.

(b) Now, if the glue code is *not* a derived work from Linux, then the
copyright holder is entitled to use whatever terms she likes.  It
could be any license whatsoever, that permits the distribution of the
whole or of the parts with whatever constraints copyright law
permitted.  Why would they choose the GPL in this case, then?


Let's assume they're not intentionally violating the GPL, but rather
that they believe they're entitled to do what they're doing, i.e.,
that they believe (a) their glue code is not a derived work from
Linux.

In this case, they *can* distribute the glue source code under the GPL
along with their binary blob.  But can anyone else?

Methinks anyone else would be entitled to pass the same whole along
under the GPL, per section 1, but wouldn't be entitled to distribute
modified versions, because this would require the derived work to be
licensed under the GPL, and nobody else is able to provide the source
code to the binary blob.

And then, who'd be entitled to complain?  Only the copyright holder of
the glue code and the binary blob.

Would you like to be on the wrong end of a copyright infringement
lawsuit by one of these binary blob distributors for distributing a
patched version of their glue code + binary blob?  More to the point,
do you think they would actually bring suit, just to make it clear
that the whole point is for them to keep a monopoly on the rights to
modify and then distribute the combined work, in spite of using the
GPL for (part of) the work?


It gets trickier for binaries, since they are quite possibly derived
works from the kernel, licensed under the GPL.  If they are, they
can't be distributed at all, not even by the copyright holder of the
glue code + binary blob.  If they aren't, then the copyright holder
can distribute them, but nobody else can because that would be a
violation of the GPL, as in the discussion above.  So, the copyright
holder would be keeping a monopoly on the rights to distribute
binaries, and anyone else could be sued by them.


Sure enough, one might think of praising them for distributing the
glue code under the GPL.  Then others could take this glue code and
use it for something else that is useful, right?

Well...  Not quite.  For one, even if enabling others to distribute
glue code + binary blobs were a good thing, using somebody else's glue
code means you're bound by the GPL requirements, so you can't ship the
combination of the glue code with your binary blob.

And then, if you intend to use the glue code to plug in some other
code that is GPL-compatible in the kernel, perhaps you'd be better off
not using the glue code at all, but rather modifying the
GPL-compatible code to fit.

So, even if condoning binary blobs were morally acceptable, we still
wouldn't be gaining anything from this relationship, we'd only be
enabling vendors to sell us their undocumented hardware while denying
us our freedoms.

Why should we do this?

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
To unsubscribe from this list: 

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

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> 
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed.  So what?  How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program.  Both
>> forms are subject to copyright law and to the license, in spite of
>> http://www.fsfla.org/?q=en/node/128#1
> 
> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>"the program" as defined by the GPLv2 AT ALL.
> 
> In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
> or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
> from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
> AFFECT THE RESULTING BINARY.

I really don't agree.  It seems you confuse source and binary application.

The source surelly is not derived, you can link *any* libc to your
program.

But a binary is different.

Let start with your example about books: you write a book, you have
the copyright of the text, but if you publish it with X publiher, he
may use a own font.  You can read the book, scan it to extract text
(I hope fair use allows it), but not copy the book pages: there is
your text, but also copyrighted font.  Publisher should check
that the two license are compatible, as the user that links
with a new library.

For binary, it is the same. You can extract libraries and rest of
programs (better doing with sources), but until it is one binary,
it is a new mixed entity.

It is not only linking, it is mixing bytes! Some part of library is
linked statically, there are some references in the static part of
program. It is a mix and until the two part are mixed (not only linked)
you should follow both licenses for copying!

Choose any dynamic program in your machine, try to link glibc with an
other (not directly derived libc) library... you see how it is hard,
and it is very different to an "aggregation".  And dynamic links is
only the latest step of "merging" the two binaries.

Other libraries tend to be more "dynamic", but glibc mixes to much

In other word, source A, library B: the binary C is derived both from A
and B, but surelly A is not derived by B.  So IMHO IANAL, in arguments
we should not confuse the sources and the binary in the arguments, so
not calling simply "the program".


ciao
cate


> 
> And I'm simply claiming that a binary doesn't become "derived from" by any 
> action of linking.
> 
> Even if you link using "ld", even if it's static, the binary is not 
> "derived from". It's an aggregate.
> 
> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".
> 
> THAT is my point. 
> 
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.
> 
> In the presense of dynamic linking the binary isn't even an aggregate 
> work.
> 
> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.
> 
> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.
> 
>   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

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> 
> On Mon, 18 Dec 2006, Alexandre Oliva wrote:
>>> In other words, in the GPL, "Program" does NOT mean "binary". Never has.
>> Agreed.  So what?  How does this relate with the point above?
>>
>> The binary is a Program, as much as the sources are a Program.  Both
>> forms are subject to copyright law and to the license, in spite of
>> http://www.fsfla.org/?q=en/node/128#1
> 
> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>"the program" as defined by the GPLv2 AT ALL.
> 
> In other words, it doesn't matter ONE WHIT whether you use "ld --static" 
> or "ld" or "mkisofs" - if the program isn't (by copyright law) derived 
> from glibc, then EVEN IF glibc was under the GPLv2, it would IN NO WAY 
> AFFECT THE RESULTING BINARY.

I really don't agree.  It seems you confuse source and binary application.

The source surelly is not derived, you can link *any* libc to your
program.

But a binary is different.

Let start with your example about books: you write a book, you have
the copyright of the text, but if you publish it with X publiher, he
may use a own font.  You can read the book, scan it to extract text
(I hope fair use allows it), but not copy the book pages: there is
your text, but also copyrighted font.  Publisher should check
that the two license are compatible, as the user that links
with a new library.

For binary, it is the same. You can extract libraries and rest of
programs (better doing with sources), but until it is one binary,
it is a new mixed entity.

It is not only linking, it is mixing bytes! Some part of library is
linked statically, there are some references in the static part of
program. It is a mix and until the two part are mixed (not only linked)
you should follow both licenses for copying!

Choose any dynamic program in your machine, try to link glibc with an
other (not directly derived libc) library... you see how it is hard,
and it is very different to an "aggregation".  And dynamic links is
only the latest step of "merging" the two binaries.

Other libraries tend to be more "dynamic", but glibc mixes to much

In other word, source A, library B: the binary C is derived both from A
and B, but surelly A is not derived by B.  So IMHO IANAL, in arguments
we should not confuse the sources and the binary in the arguments, so
not calling simply "the program".


ciao
cate


> 
> And I'm simply claiming that a binary doesn't become "derived from" by any 
> action of linking.
> 
> Even if you link using "ld", even if it's static, the binary is not 
> "derived from". It's an aggregate.
> 
> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".
> 
> THAT is my point. 
> 
> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.
> 
> In the presense of dynamic linking the binary isn't even an aggregate 
> work.
> 
> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.
> 
> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.
> 
>   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

[D. Hazelton]

On Monday 18 December 2006 12:16, David Schwartz wrote:
> Combined responses to save bandwidth and reduce the number of times people
> have to press "d".
>
> > Agreed. You missed the point.
>
> I don't understand how you could lead with "agreed" and then proceed to
> completely ignore the entire point I just made.

I *initially* thought you had missed the point. After your later post 
clarifying things I saw that my statement had been in error and that I did 
agree with you completely.

> > Since the Linux Kernel header files
> > contain a
> > chunk of the source code for the kernel in the form of the macros
> > for locking
> > et. al. then using the headers - including that code in your
> > module - makes
> > it a derivative work.
>
> No, it does not. The header files are purely function and not expressive in
> this case. Copyright only protects one choice among many equally-practical
> choices for expressing the same idea or performing the same function.

In this case, well. We aren't talking Copyright, but the license under which 
the software is distributed. According to the USPTO placing a statement such 
as (c) 2006 Pornrat Watanabe on a work you have created automatially places 
it under a copyright. The kernel source code, copyrighted as it is, is then 
distributed under the terms of the GNU GPL. 

Using the code from the header files may not make the module a derivative, but 
it is including parts of a copyrighted work. By *NOT* complying with the 
license under which said copyrighted work is distributed, you are giving up 
your rights under the license.

This doesn't negate any problems with people making Blob drivers, because, as 
you pointed out, under the same laws they aren't a derivative work, which 
means that that clause of the license doesn't apply. Now if the GPL contained 
a clause specifically defining what it considered a derivative work things 
would be different.

> > Actually, thinking about it, the way a Linux driver module works actually
> > seems to make *ANY* driver a derivative work, because they are
> > loaded into
> > the kernels memory space and cannot function without having that done.
>
> If every practical way of expressing an idea contains something, then that
> something is *not* protectable when used to express an idea of that kind.

Not what I was saying. There are any number of ways to make a driver 
function - the FUSE system has shown that clearly. But by making that driver 
one that is loaded directly into the kernels memory space...

It's that act that *I* *FEEL* makes it a derivative work.

> > *IF* the "Usermode Driver" interface that is being worked on ever proves
> > useful then, and only then, could you consider it *NOT* a
> > derivative work.
> > Because then the only thing it is using *IS* an interface, not complete
> > chunks of the source as generated when the pre-processor finishes running
> > through the file.
>
> No, you have it completely backwards.

No, you missed my point. I was saying that the Usermode Driver interface would 
make the current style of kernel modules fully derivative works. This being 
because they are using an open system interface and *NOT* including code 
distributed with the kernel.

> If a usermode driver interface was equally practical to develop a
> particular type of driver, then using the kernel headers would make the
> driver a derivative work. Because, in that case, the choice to use the
> kernel headers would be a creative choice -- one chosen method among many
> equally practical one.

And this is what I was saying. Perhaps I didn't state it in clear and concise 
english.

> Copyright only protects creative choices, not purely functional ones.
>
> "A Linux 2.6 driver for the ATI X800 graphics chipset" is an idea. If the
> only reasonably practical way to express that idea is with the Linux kernel
> header files, then using the Linux kernel header files is scenes a fair,
> not protected content.

Okay. I understood this back at the start of your reply.


> DS

Okay, after a lot of thought and me realizing some mistakes I had made in 
interpreting the law and legal precedents I see we are on the same page.

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

[Daniel Barkalow]

On Mon, 18 Dec 2006, Linus Torvalds wrote:

> Static vs dynamic matters for whether it's an AGGREGATE work. Clearly, 
> static linking aggregates the library with the other program in the same 
> binary. There's no question about that. And that _does_ have meaning from 
> a copyright law angle, since if you don't have permission to ship 
> aggregate works under the license, then you can't ship said binary. It's 
> just a non-issue in the specific case of the GPLv2.

Under US law, the distinction is between works that are copyrightable 
themselves as "derivative works" and works that are derived from others, 
but aren't copyrightable. Provided you're allowed to ship aggregate works, 
the question is whether the output of "ld" is a copyrightable work 
distinct from the inputs.

I'd agree that "ar", like "mkisofs", doesn't create a derived work, but I 
think that "objcopy" does create a derived work, and "ld" does too, by 
virtue of modifying the objects it takes to resolve symbols. Now, you 
could distribute to somebody an ar archive of your program, and the 
recipient (given fair use rights to the copy of the program they received) 
could do "gcc program.a -o program" to link it. But I don't think you 
automatically get the right (under the "mere aggregation" permission) to 
distribute the result of relocating the symbols of gnutls around those of 
your program and vice versa, along with modifying the references to 
external symbols from each of these to point to specific locations.

-Daniel
*This .sig left intentionally blank*
-
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

[D. Hazelton]

On Monday 18 December 2006 20:35, David Schwartz wrote:
> > For both static and dynamic linking, you might claim the output is an
> > aggregate, but that doesn't matter.  What matters is whether or not
> > the output is a work based on the program, and whether the "mere
> > aggregation" paragraph kicks in.
> >
> > If the output is not an aggregate, which is quite likely to be
> > the case for dynamic linking, and quite possibly also for many static
> > linking cases, then the "mere aggregation" paragraph of clause 2 does
> > not kick in.
> >
> > If the output is indeed an aggregate, as it may quite likely be in the
> > case of static linking, then the "mere aggregation" considerations of
> > clause 2 may kick in and enable the 'anything else' to not be brought
> > under the scope of the license.  You still need permission to
> > distribute the whole.  The GPL asserts its non-interference with your
> > ability to distribute the separate portion separately, under whatever
> > license you can, as long as it's not a derived work from the GPL
> > portion.
>
> No!
>
> It makes no difference whether the "mere aggregation" paragraph kicks in
> because the "mere aggregation" paragraph is *explaining* the *law*. What
> matters is what the law actually *says*.
>
> We are talking about what works are within the GPL's scope. The text of the
> GPL does not matter because the GPL does not set its own scope, copyright
> law does.
>
> The GPL could say that if you ever see the source code to a GPL'd work,
> every work you ever write must be placed under the GPL. But that wouldn't
> make it true, because that would be a requirement outside the GPL's scope.
>
> We are talking about works are inside the GPL's legal scope, and in that
> case, nothing the GPL says can enlarge the scope.
>
> DS


Actually, after rereading the GPLv2 because of this discussion I came to a 
most surprising conclusion. While there are *IMPLICIT* and *EXPLICIT* 
copyrights on the code, they have no bearing on the text of the GPL.

The GPL is a License that covers how the code may be used, modified and 
distributed. This is the reason that the FSF people had to make the big 
exception for Bison, because the parser skeleton is such an integral part of 
Bison (Bison itself, IIRC, uses the same skeleton, modified, as part of the 
program) that truthfully, any parser built using Bison is a derivative work 
of code released under the GPL.

That said, since there is a distribution, use and modification license on the 
Linux Kernel - the GPLv2 - there are those extra restrictions on the code 
*OUTSIDE* the copyright rules.

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

[D. Hazelton]

On Monday 18 December 2006 14:41, Alexandre Oliva wrote:
> On Dec 17, 2006, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > On the other hand, certain projects like OpenAFS, while not license-
> > compatible, are certainly not derivative works.
>
> Certainly a big chunk of OpenAFS might not be, just like a big chunk
> of other non-GPL drivers for Linux.
>
> But what about the glue code?  Can that be defended as not a derived
> work, such that it doesn't have to be GPL?

That has never been an issue, really. Its what 99% of the binary drivers 
believe - hence the reason that there is the user-compiled component to all 
of them.

> If not, can the whole containing both the non-derivative work and the
> source code providing the glue without which the whole wouldn't
> fulfill its intended purpose be regarded as a mere aggregate, and thus
> not be subject to the requirement that the whole be released under the
> GPL?

The view that binary vendors take is "Linking does not create a derived 
work" - regardless of the fact that you cannot have a complete compiled 
program or module *WITHOUT* that linking. However I have a feeling that the 
lawyers in the employ of the companies that ship BLOB drivers say that all 
they need to do to comply with the GPL is to ship the glue-code in source 
form.

And I have to admit that this does seem to comply with the GPL - to the 
letter, if not the spirit.

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

[David Schwartz]

Combined responses:

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference.  There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

We're only talking about the special case of GPL'd works. You can download a
million copies of a GPL'd work from a server run by a family member across
the room. You can then delete one copy for each copy you distribute in the
form of a statically linked work.

Issues of copying don't apply to GPL'd works unless you have no access to
the source code. Otherwise, someone else can copy you as many works as you
want with the source code, and you can use first sale to transfer every one
of them.

> I personally would think that a mechanical process of modification
> *does* create a derived work, but it would take a court of law or a
> legislature to make an authoritative decision, I guess.

Under at least United States law, copyright protected creative expression
and only creative expression. In other jurisdictions, there are other types
of rights similar to copyright that one can obtain by means of hard work,
for example database compilation rights. They are usually legally distinct
from copyright and grant different rights with different rules.

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

[David Schwartz]

> For both static and dynamic linking, you might claim the output is an
> aggregate, but that doesn't matter.  What matters is whether or not
> the output is a work based on the program, and whether the "mere
> aggregation" paragraph kicks in.
>
> If the output is not an aggregate, which is quite likely to be
> the case for dynamic linking, and quite possibly also for many static
> linking cases, then the "mere aggregation" paragraph of clause 2 does
> not kick in.
>
> If the output is indeed an aggregate, as it may quite likely be in the
> case of static linking, then the "mere aggregation" considerations of
> clause 2 may kick in and enable the 'anything else' to not be brought
> under the scope of the license.  You still need permission to
> distribute the whole.  The GPL asserts its non-interference with your
> ability to distribute the separate portion separately, under whatever
> license you can, as long as it's not a derived work from the GPL
> portion.

No!

It makes no difference whether the "mere aggregation" paragraph kicks in
because the "mere aggregation" paragraph is *explaining* the *law*. What
matters is what the law actually *says*.

We are talking about what works are within the GPL's scope. The text of the
GPL does not matter because the GPL does not set its own scope, copyright
law does.

The GPL could say that if you ever see the source code to a GPL'd work,
every work you ever write must be placed under the GPL. But that wouldn't
make it true, because that would be a requirement outside the GPL's scope.

We are talking about works are inside the GPL's legal scope, and in that
case, nothing the GPL says can enlarge the scope.

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

[David Schwartz]

> > It's also not clear that an aggregate work is in fact
> > a single work for any legal purpose other than the aggregator's claim to
> > copyright.

> Not sure what you're trying to say there - what are we talking about
> here other than the copyright?

We are talking about two different possible copyright claims. One is the
person who aggregates the works who may try to claim a "compilation
copyright" in the aggregate. The other is the authors of the original works
who may try to claim that the aggregate is a derivative work.

> First sale has nothing to do with this. First sale applies to the
> redistribution or resale of copies you have purchased, not with the
> right to make additional copies.

First sale is exactly what this is about. Nobody needs to make "additional
copies" of the Linux kernel because I can download a thousand of them from a
computer operated by the guy in the office down the hall from me.


> > ... For copyright law purposes, it is not a work because no creative
> > input was needed to produce it beyond what was used to create
> > the works from
> > which it was formed.

> Selection and organization are potentially creative. The Act
> distinguishes between derivative works, compilations, and collective
> works. A derivative work is a work "based on" the original work; a
> compilation is a work formed by "collecting and assembling"
> preexisting works "in such a way that the resulting work as a whole
> constitutes an original work of authorship. A "collective work" is any
> work formed by assembling independent works into a whole. All
> compilations are collective works, but not all collective works are
> compilations. Derivative works have nothing to do with aggregation.

Good, so we agree that aggregate is not a derivative work. That means it
doesn't have to be GPL'd even if some of its component works are GPL'd.

> > I recently bought two DVDs as a present for a friend of mine. I
> > put the two
> > DVDs in one box and shipped them to him. Just because the two
> > DVDs are in
> > one box does not make them a derivative work for copyright
> > purposes because
> > no creative input went in to them. I can even staple the two
> > DVDs together
> > if I want. I also don't need any special permission to ship the
> > two of them
> > together to my friend, first sale covers that. The right to ship each
> > individual work is all that's needed to ship the aggregate.

> First sale is separate from Copyright. You have the right to ship
> them, but not to make copies of them. You can't for instance, ship
> your friend a single DVD that combines the contents of the two you
> bought. That's not unlike the distinction GPLv3 makes between
> "propagating" and "conveying".

I don't see why you can't distribute a single DVD that combines the contents
of the two you bought, so long as you destroy the originals. There is no
issue about the number of copies with the GPL because you can download any
number of copies of a GPL'd work from someone else who provides you with
source.

> > Now, if I wanted to write my own story with elements from the content of
> > both DVDs, that would be a derivative work because the
> > combination itself is
> > done in a creative way.

> If it just rearranged the pieces, it would not be a derivative work,
> it would be a compilation. If you transformed the pieces, it might be
> a derivative work (depending on the nature of the transformation).

I think it depends upon how small the pieces are. If you rearranged them
creatively, and the result was in effect a single work, I think it would be
a derivative work.

> > No automated, mechanical process can create a derivative work
> > of software.
> > (With a few exceptions not relevant here.)

> The truth of that statement depends on exactly what you mean by "an
> automated, mechanical process". There are mechanical processs that
> would simply produce the original work itself, not a derivative (e.g.,
> changing the type from Courier to Times). There are other mechanical
> proceses that would produce a collective work (e.g., inserting after
> each line of the program a statement indicating whether or not it was
> valid C). There are other mechanical processes that would create a
> derivative work (e.g., a paraphrasing tool). It depends on the nature
> of the mechanical process; that is, the decision, by you, to apply a
> particular mechanical process is itself creative. But, perhaps that's
> what you meant by your "few exceptions".

I mean that you can't link together a bunch of works that would otherwise be
independent and get a derivative work as a result. Linking combines
mechanistically, not creatively, so it aggregates.

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

[Paul Mackerras]

Linus Torvalds writes:
> 
> 
> On Tue, 19 Dec 2006, Paul Mackerras wrote:
> >
> > There is in fact a pretty substantial non-technical difference between
> > static and dynamic linking.  If I create a binary by static linking
> > and I include some library, and I distribute that binary to someone
> > else, the recipient doesn't need to have a separate copy of the
> > library, because they get one in the binary.
> 
> I agree, and I do agree that it's a real difference. 
> 
> I personally think that it's the "aggregation" issue, not a "derivation" 
> issue, but I'll freely admit that it's just my personal view of the 
> situation.

I think the critical issue is whether any human creativity is required
to establish derivation.

Clearly there is some modification and adaptation that ld does to a
library in the process of linking it into a binary, and ld is unlike
mkisofs or gzip in that you can't extract the library in its original
form (or any form suitable for linking with another program) from the
output of ld --static.

The question is whether it matters that the process that ld does is
mechanical in nature.  This is possibly an area where you'll get a
different answer in different jurisdictions.  I believe that in the
US, some creative input is required to establish copyright, whereas in
Australia, only "effort" is needed.  I don't know whether that affects
the definition of "derived work".

I personally would think that a mechanical process of modification
*does* create a derived work, but it would take a court of law or a
legislature to make an authoritative decision, I guess.

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

[Linus Torvalds]

On Tue, 19 Dec 2006, Paul Mackerras wrote:
>
> There is in fact a pretty substantial non-technical difference between
> static and dynamic linking.  If I create a binary by static linking
> and I include some library, and I distribute that binary to someone
> else, the recipient doesn't need to have a separate copy of the
> library, because they get one in the binary.

I agree, and I do agree that it's a real difference. 

I personally think that it's the "aggregation" issue, not a "derivation" 
issue, but I'll freely admit that it's just my personal view of the 
situation.

> In other words, static linking gives the recipient a "free" copy of
> the library, but dynamic linking doesn't.  That is why some companies'
> legal guidelines have quite different rules about the distribution of
> binaries, depending on whether they are statically or dynamically
> linked.

Yes. There is not doubt at all that regardless of anything else, if you 
link statically, you at the VERY LEAST need to have the right to 
distribute the library as part of an "aggregate work". 

> So therefore I don't think you can reasonably claim that static
> vs. dynamic linking is only a technical difference.  There are clearly
> other differences when it comes to distribution of the resulting
> binaries.

Yes. And I have actually talked about this exact issue - even in the 
absense of any "derivation" from the library, the fact that static linking 
includes a _copy_ of the library does mean that you have to have the right 
to distribute that particular copy. 

Now, under the GPL, aggregate distribution is allowed, but you still do 
need to follow the other GPL rules (ie you would need to distributed 
sources for the library - even if you don't necessarily distribute sources 
to the binary you linked _with_).

So there's no question that "dynamic linking" simplifies issues, by virtue 
of not even distributing any library code at all. I absolutely agree about 
that part.

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

[Paul Mackerras]

Linus Torvalds writes:

> "Derivation" has nothing to do with "linking". Either it's derived or it 
> is not, and "linking" simply doesn't matter. It doesn't matter whether 
> it's static or dynamic. That's a detail that simply doesn't have anythign 
> at all to do with "derivative work".

There is in fact a pretty substantial non-technical difference between
static and dynamic linking.  If I create a binary by static linking
and I include some library, and I distribute that binary to someone
else, the recipient doesn't need to have a separate copy of the
library, because they get one in the binary.

If on the other hand the binary is dynamically linked, then the
recipient needs to get hold of a copy of the library from somewhere,
implying that they need to have satisfied whatever license conditions
the copyright owner of the library places on it, in order to have
obtained their copy of the library legally.

In other words, static linking gives the recipient a "free" copy of
the library, but dynamic linking doesn't.  That is why some companies'
legal guidelines have quite different rules about the distribution of
binaries, depending on whether they are statically or dynamically
linked.

If the library was a proprietary library, for which the copyright
owner wanted to charge a per-copy fee, the owner would no doubt object
to me distributing statically-linked binaries containing his library,
but could conceivably be perfectly happy with me distributing binaries
that have been dynamically linked against his library, since then
anyone who wants to use my binary has to purchase a copy of his
library from him.

So therefore I don't think you can reasonably claim that static
vs. dynamic linking is only a technical difference.  There are clearly
other differences when it comes to distribution of the resulting
binaries.

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

[Paul Mackerras]

Junio C Hamano writes:

> Excuse me, but are you two discussing "ld"? ;-)

Oops.  Yes. :)

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

[Alexandre Oliva]

On Dec 18, 2006, Linus Torvalds <[EMAIL PROTECTED]> wrote:

> On Mon, 18 Dec 2006, Alexandre Oliva wrote:

>> > In other words, in the GPL, "Program" does NOT mean "binary". Never has.

>> Agreed.  So what?  How does this relate with the point above?

> Here's how it relates:
>  - if a program is not a "derived work" of the C library, then it's not 
>"the program" as defined by the GPLv2 AT ALL.

In the case I'm talking about, libgpl (make it a GPLed libc) is the
program, and a binary produced by linking anything else with the
program (libgpl) is what you claim to be an aggregate (a term not
defined in the GPL; is it defined in US law?).

For both static and dynamic linking, you might claim the output is an
aggregate, but that doesn't matter.  What matters is whether or not
the output is a work based on the program, and whether the "mere
aggregation" paragraph kicks in.

If the output is not an aggregate, which is quite likely to be
the case for dynamic linking, and quite possibly also for many static
linking cases, then the "mere aggregation" paragraph of clause 2 does
not kick in.

If the output is indeed an aggregate, as it may quite likely be in the
case of static linking, then the "mere aggregation" considerations of
clause 2 may kick in and enable the 'anything else' to not be brought
under the scope of the license.  You still need permission to
distribute the whole.  The GPL asserts its non-interference with your
ability to distribute the separate portion separately, under whatever
license you can, as long as it's not a derived work from the GPL
portion.

But what about the whole?  If you can't separate the whole into, well,
the separate components, is it still a mere aggregate?  mkisofs will
create an image in which the components are all there, easily
extractable individually in their original form.  This is *clearly*
mere aggregation, even if some components turn out to be works based
on other GPL programs.

But even in the case of static linking, this is not how it works.
Say, if the portions of the static libgpl to be copied to the output
are selected based on the contents of the 'anything else', could you
legitimately claim that the output is not a derived work of both
libgpl and this 'anything else', but rather a mere aggregation of
unrelated works?

In either case, if you distribute the linker output, and it happens to
be found to be a derived work of the program (libgpl), aggregate or
not, then you must license the whole of the linker output under the
GPL, and this means to me that you have to be able to provide the
source code of every portion thereof under the GPL, except for
portions explicitly excluded by the GPL itself.

So whether it's an aggregate or not is completely irrelevant.  What
matters is whether it's a derived work of a GPLed program (and if
there is copying, it probably is) and whether the mere aggregation
clause kicks in to grant an exception.

> THAT is the difference between static and dynamic. A simple command line 
> flag to the linker shouldn't really reasonably be considered to change 
> "derivation" status.

If in one case there is extraction, copying and transformation of the
GPLed intput, and in the other there is something much simpler (does
it still qualify as extraction, copying and transformation?), then
derivation becomes more or less obvious to prove, but you're right in
that the status of the output probably won't change.  The status of
the inputs certainly doesn't.

> Either something is derived, or it's not. If it's derived, "ld", 
> "mkisofs", "putting them close together" or "shipping them on totally 
> separate CD's" doesn't matter. It's still derived.

But the important questions at hand, I think, are what makes it
derived, and whether it qualifies for any of the exceptions in the
GPL.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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/