Driver Model
James Clark
a given binary driver working with a 2.6+ kernel.
2. Will the new model reduce the use/need for kernel modules. Would this be a
good thing if functionality could be implemented in a driver instead of a
module.
3. Will the practice of deliberately breaking some binary only 'tainted'
modules prevent take up of Linux. Isn't this taking things too far?
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1. Will the move to a more uniform driver model in 2.6 increase the chances of
a given binary driver working with a 2.6+ kernel.
2. Will the new model reduce the use/need for kernel modules. Would this be a
good thing if functionality could be implemented in a driver instead of a
module.
3. Will the practice of deliberately breaking some binary only 'tainted'
modules prevent take up of Linux. Isn't this taking things too far?
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Robert Love
> 1. Will the move to a more uniform driver model in 2.6 increase the chances of
> a given binary driver working with a 2.6+ kernel.
I don't see how.
> 2. Will the new model reduce the use/need for kernel modules.
No. The two concepts are really unrelated.
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
Tainted modules are not "broken" -- they just display a "tainted"
message. We do not do things to deliberately break binary-only modules.
The driver model has four main benefits, in my eyes:
- unifies code between the previous desperate driver models
- creates a device topology, which is needed for power
management
- allows for things like sysfs and other logical device
representations
- it is just the Right Way to do it
None of your questions are related to the driver model, really. It is
not a new uniform driver API, if that is what you are thinking. It is
a topology/hierarchal abstraction for devices.
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2003-09-02 at 14:43, James Clark wrote:
> 1. Will the move to a more uniform driver model in 2.6 increase the chances of
> a given binary driver working with a 2.6+ kernel.
I don't see how.
> 2. Will the new model reduce the use/need for kernel modules.
No. The two concepts are really unrelated.
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
Tainted modules are not "broken" -- they just display a "tainted"
message. We do not do things to deliberately break binary-only modules.
The driver model has four main benefits, in my eyes:
- unifies code between the previous desperate driver models
- creates a device topology, which is needed for power
management
- allows for things like sysfs and other logical device
representations
- it is just the Right Way to do it
None of your questions are related to the driver model, really. It is
not a new uniform driver API, if that is what you are thinking. It is
a topology/hierarchal abstraction for devices.
Robert Love
Richard B. Johnson
> 1. Will the move to a more uniform driver model in 2.6 increase the
> chances of
> a given binary driver working with a 2.6+ kernel.
>
Most changes to the kernel are made without any consideration
of a so-called binary drivers at all. FWIW all drivers are "binary".
If a file is created that was generated for a specific kernel version,
it will work on that kernel version whether or not the driver
sources are available. If the driver does not contain the appropriate
MODULE_LICENSE() string, then several tools will show "tainted" so
that kernel developers will not waste time attempting to find a problem
with a kernel that might be caused by a driver. If the driver has its
source-code released, shown by the appropriate MODULE_LICENSE() string,
then kernel developers may review that driver and fix it if it
is causing a kernel problem.
> 2. Will the new model reduce the use/need for kernel modules. Would this be a
> good thing if functionality could be implemented in a driver instead of a
> module.
>
The current trend is to make all drivers modules. That way, the
kernel will not be bloated with thousands of drivers that are never
used. Basically, the kernel will have just enough hardware-interface
to boot, possibly into a RAM Disk. Then the modules necessary to
support the specific hardware are loaded, the devices initialized
and the boot continues.
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
>
> James
> -
There is no such practice going on at this time. A module must
be compiled using the same interface elements (structure members, etc.)
as the kernel. Therefore it must have the same version number, compiled
against the same kernel headers. If the designer of the module can't
make the source code public (usually because of corporate restrictions)
then, if there is a problem that you need to report to the kernel
development group, you need to make sure that the "secret" module
is not installed at that time. If the secret module is causing
the kernel problem, which is seldom the case BYW, then you need to
contact the provider of the secret module. They may have a brand-
new version that works perfectly.
A case-in-point: A truly MAJOR screen-card developer has not been
allowed to make the source-code publically available because of
corporate restrictions (A publically-owned company might not be
able to make their intellectual property public. This might cause
a stock-holder revolt). This major company has quickly responded
to failures of their modules to work in the latest kernel versions.
The result is that they have a good working relationship, even though
inserting one of their drivers will cause the OPPS reporting software
to declare that the kernel is "tainted".
You don't get a "tainted" message otherwise. You just get good
screen graphics.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2 Sep 2003, James Clark wrote:
> 1. Will the move to a more uniform driver model in 2.6 increase the
> chances of
> a given binary driver working with a 2.6+ kernel.
>
Most changes to the kernel are made without any consideration
of a so-called binary drivers at all. FWIW all drivers are "binary".
If a file is created that was generated for a specific kernel version,
it will work on that kernel version whether or not the driver
sources are available. If the driver does not contain the appropriate
MODULE_LICENSE() string, then several tools will show "tainted" so
that kernel developers will not waste time attempting to find a problem
with a kernel that might be caused by a driver. If the driver has its
source-code released, shown by the appropriate MODULE_LICENSE() string,
then kernel developers may review that driver and fix it if it
is causing a kernel problem.
> 2. Will the new model reduce the use/need for kernel modules. Would this be a
> good thing if functionality could be implemented in a driver instead of a
> module.
>
The current trend is to make all drivers modules. That way, the
kernel will not be bloated with thousands of drivers that are never
used. Basically, the kernel will have just enough hardware-interface
to boot, possibly into a RAM Disk. Then the modules necessary to
support the specific hardware are loaded, the devices initialized
and the boot continues.
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
>
> James
> -
There is no such practice going on at this time. A module must
be compiled using the same interface elements (structure members, etc.)
as the kernel. Therefore it must have the same version number, compiled
against the same kernel headers. If the designer of the module can't
make the source code public (usually because of corporate restrictions)
then, if there is a problem that you need to report to the kernel
development group, you need to make sure that the "secret" module
is not installed at that time. If the secret module is causing
the kernel problem, which is seldom the case BYW, then you need to
contact the provider of the secret module. They may have a brand-
new version that works perfectly.
A case-in-point: A truly MAJOR screen-card developer has not been
allowed to make the source-code publically available because of
corporate restrictions (A publically-owned company might not be
able to make their intellectual property public. This might cause
a stock-holder revolt). This major company has quickly responded
to failures of their modules to work in the latest kernel versions.
The result is that they have a good working relationship, even though
inserting one of their drivers will cause the OPPS reporting software
to declare that the kernel is "tainted".
You don't get a "tainted" message otherwise. You just get good
screen graphics.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
Patrick Mochel
> 1. Will the move to a more uniform driver model in 2.6 increase the chances of
> a given binary driver working with a 2.6+ kernel.
Not necessarily. A binary driver still needs to be compiled for a specific
version of a kernel. And, if it's not already working, the new driver
model definitely won't help. :)
> 2. Will the new model reduce the use/need for kernel modules. Would this be a
> good thing if functionality could be implemented in a driver instead of a
> module.
No, it will not reduce usage of modules. The driver model has nothing to
do with whether something is compiled as a module or not.
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
This is a loaded question, but ultimately it's a vendor issue. Most people
do and will use vendor kernels. What they do with their kernel interfaces
and how well they support binary modules is their beef.
Pat
James Clark
the Driver Model (www.amc.com.au/lca/loopback/papers/
Patrick_Mochel/Patrick_Mochel.pdf).
The reason I posed the question, as a newcomer to kernel development, moving
from WIN32 DDK development (sorry!) to Linux is that I was very surprised by
the module interface.
Would a more rigid 'plugin' interface and the concequent move from mainly
'source' modules to binary 'plugins' (still with source-code available for
all to see) mean that (a) Kernel was smaller (2) Had to be
released/recompiled less (4) Was EVEN more stable and (4) 'plugins' were more
portable across releases and easier to install ?
I love Linux but this seems to be holding it back...
James
Robert Love
> Would a more rigid 'plugin' interface and the concequent move from mainly
> 'source' modules to binary 'plugins' (still with source-code available for
> all to see) mean that (a) Kernel was smaller (2) Had to be
> released/recompiled less (4) Was EVEN more stable and (4) 'plugins' were more
> portable across releases and easier to install ?
I do not think any of these implications are true, except (4).
A stable driver API would certainly imply (4). But I see no relation to
(a) -- actually, an API would bring complications and thus bloat, if
anything. I see no relation to (2). And (3) just seems like a wild
guess.
I agree that (4) would be a good thing. The problem is, its really not
what we have here today and not what any of the kernel developers want.
95% of the drivers (and 100% of those that the kernel developers use)
_are_ source-based and in the tree, so why have a stable API for them?
In other words, yes, (4) is nice. But not that nice, as a stable API
and driver interface implies a lot of other things that are not
necessarily good.
On the bright side, I do think that we will see a much more stable API
in 2.6. 2.4.n for n after Marcelo took over has also been stable.
Robert Love
Greg KH
>
> Would a more rigid 'plugin' interface and the concequent move from mainly
> 'source' modules to binary 'plugins' (still with source-code available for
> all to see) mean that (a) Kernel was smaller
No, we would have to support all versions of the APIs over time, making
the kernel larger and harder to maintain.
> (2) Had to be released/recompiled less
No, release frequency would have nothing to do with this.
> (4) Was EVEN more stable and (4) 'plugins' were more portable across
> releases and easier to install ?
No.
> I love Linux but this seems to be holding it back...
Please read the FAQ and many discussions about this very topic in the
past in the archives for why the kernel does not have a stable API
within itself.
That being said, the ammount the API changes over time in a "stable"
kernel series is usually quite small.
I understand coming from the Windows world this seems odd, but after a
bit of time you will see why it is quite nice.
Good luck,
greg k-h
Jamie Lokier
> Would a more rigid 'plugin' interface and the concequent move from mainly
> 'source' modules to binary 'plugins' (still with source-code available for
> all to see) mean that (a) Kernel was smaller
No, it would undoubtedly make the kernel larger and slower.
> I love Linux but this seems to be holding it back...
Most of the authors of Linux would prefer a little holding back, if
the alternative was widespread binary-only drivers that they couldn't
debug or fix, or learn from, and a slower, larger kernel.
Of course we might be mistaken.
But please take a look at other kernels which _do_ offer a rigid
interface to binary plugins. Then ask yourself what social phenomena
created the Linux which is exciting and useful as it is, that makes
you want to write drivers for it now instead of those other kernels.
-- Jamie
Andre Hedrick
## The unoffical insider's guide to thwart the gpl_only garbage ##
## First how to finally become a total outcast from being in/near the ##
## inner circle to exile. ##
The soul intent of "GPL_ONLY" is to prevent binary modules.
The soul intent of "tainting" is to ignore the people who want a choice.
Now two sides to the sword with the above:
Create a pre-loading module to wrapper all the needed "GPL_ONLY" symbols
which rightly belong to the unprotected API.
-------------------------------------------
/*
* freed_symbols.h
*
* The Free Stolen Symbols module.
* Licensed under GPL and source code is free.
*/
extern int freed_xxxxx ( ... );
-------------------------------------------
/*
* freed_symbols.c
*
* The Free Stolen Symbols module.
* Licensed under GPL and source code is free.
*/
... blah blah, standard kernel module stuff and setup ...
int freed_xxxxx ( ... )
{
return xxxxx( ... );
}
EXPORT_SYMBOL(freed_xxxxx);
... blah blah, standard kernel module stuff and clean up ...
LICENSE("GPL");
-------------------------------------------
Now wash rinse repeat for all the symbols you need to create a pre-loader
module to return to usage all the symbols you need.
First you will get people complaining this violates intent, kindly give
them the middle finger, two fingers, fore arm, or whatever non verbal
expression you wish. Second envite them to get a lawyer. Third, when
they tell you to stop, ask if they are imposing restrictions on GPL for
terms of usage. If they are notify them they are in violation of the
license.
If you are an embedded space widget. Apply thumb to nose and wiggle
fingers. Provided you ship the source code you modify in the kernel, and
I do mean all of it, use the short cut to clobber the issues in module.h.
When they scream and complain about, this violates intent, ask them are
they issuing a restriction on the usage of the GPL kernel? If they do not
permit one to use it under GPL them the kernel itself is in violation.
The short version: It is a game of politics, where people what it both
ways. They want it to be open source and restict the usage.
Now back to "tainting", if the politics were such to cause all modules
which are not GPL to be rejected then the game is over. Because the
kernel does not reject loading, it by default approves of closed source
binary modules. One could use the means of taint-testing to accept or
reject, regardless of the original intent. Many have and will make the
argument the kernel has the ability to reject closed source and it choose
to accept.
Well I have now alienated myself from the world of open source, but
someone has to show who intellectually dishonestity in the politics.
This goes even further in some folks in the embedded appliance who will
digitally sign binary kernels against their module suite to prevent one
from compiling an identical kernel but unsigned, and the modules will not
load. This is a hot topic along with distos adding into their big dollar
distributions extra export_symbol hooks for things that do not exist in
the source tree shipped.
There is more, but you can discover all the left-right speak on your own.
Cheers,
Andre
PS: Did this earn my way back into exile again, damn the truth hurts!
On Tue, 2 Sep 2003, James Clark wrote:
David Schwartz
I agree with you, except for the one place where you've contradicted
yourself:
> If you are an embedded space widget. Apply thumb to nose and wiggle
> fingers. Provided you ship the source code you modify in the kernel, and
> I do mean all of it, use the short cut to clobber the issues in module.h.
> When they scream and complain about, this violates intent, ask them are
> they issuing a restriction on the usage of the GPL kernel? If they do not
> permit one to use it under GPL them the kernel itself is in violation.
In other words, you cannot release something under the GPL and
simultaneously restrict its use.
> Now back to "tainting", if the politics were such to cause all modules
> which are not GPL to be rejected then the game is over. Because the
> kernel does not reject loading, it by default approves of closed source
> binary modules. One could use the means of taint-testing to accept or
> reject, regardless of the original intent. Many have and will make the
> argument the kernel has the ability to reject closed source and it choose
> to accept.
So no, the kernel does not have the ability to reject closed source. That
would be an additional restriction upon use that the GPL does not allow you
to impose.
DS
Alan Cox
> 3. Will the practice of deliberately breaking some binary only 'tainted'
> modules prevent take up of Linux. Isn't this taking things too far?
tainted doesn't break anything. tainted marks modules so we know they
are unsupported and every vendor, developer and the like can throw your
reports into the bitbucket. The binary vendor has our code we don;t have
theirs so they can go fix it.
As to "too far", the GPL is quite explicit and most people contributed
code on its basis. So its very unlikely that any binary only module is
legal in the first place. There is FSF code in the kernel, merged by
others and the FSF certainly feel that way.
If you want to run a binary unix system I'd recommend Mac OSx - its
rather nice.
Alan
Stuart MacDonald
> [mailto:linux-ker...@vger.kernel.org] On Behalf Of
> Richard B. Johnson
> sources are available. If the driver does not contain the appropriate
> MODULE_LICENSE() string, then several tools will show "tainted" so
If the MODULE_LICENSE() macro is what determines taint, what's to
prevent a company from compiling their driver in their own kernel tree
with that macro and releasing it binary-only? Wouldn't that module
then be taint-free?
..Stu
Jan-Benedict Glaw
wrote in message <002301c37228$bbc89950$294b82ce@stuartm>:
> From: linux-ker...@vger.kernel.org
> > [mailto:linux-ker...@vger.kernel.org] On Behalf Of
> > Richard B. Johnson
> > sources are available. If the driver does not contain the appropriate
> > MODULE_LICENSE() string, then several tools will show "tainted" so
>
> If the MODULE_LICENSE() macro is what determines taint, what's to
> prevent a company from compiling their driver in their own kernel tree
> with that macro and releasing it binary-only? Wouldn't that module
> then be taint-free?
To use it, you've to call it like
MODULE_LICENSE("GPL");
The string (license name) you supply is stored into the module binary
and checked ad module load time. Either it's "GPL" (or a few others
IIRC) or it isn't. If it is, the module is GPL and (after you've shipped
the module) any user can legally ask for sources (and you've to ship
them). If it isn't GPL (or the other accepted variants), it'll taint the
kernel. That'll tell us to not look at oopses, though...
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
Alan Cox
> If the MODULE_LICENSE() macro is what determines taint, what's to
> prevent a company from compiling their driver in their own kernel tree
> with that macro and releasing it binary-only? Wouldn't that module
> then be taint-free?
They would be representing their module is GPL when its not, obtaining
services by deceving people (3rd party support) and if they used _GPL
symbols probably violating the DMCA by bypassing a digital rights
system.
In practice we've had two cases we know about where someone tried this,
one at least was almost certainly an accident the other one the vendor
seems to now have fixed after the threat of acute bad publicity.
You could equally ask the same question about any other measure - its
no different to "I could shoot the shopkeeper and not pay", its an
incentive to behave, a way for developers to make it clear their code
isnt for stealing and without denying people the choice of what they
run. The reputable vendors on the whole not only seem to obey it but
actually put informative MODULE_LICENSE() tags into their code for
their proprietary licenses.
Alan
Stuart MacDonald
> no different to "I could shoot the shopkeeper and not pay", its an
> incentive to behave, a way for developers to make it clear their code
That's what I figured, I just wanted to check.
> isnt for stealing and without denying people the choice of what they
> run. The reputable vendors on the whole not only seem to obey it but
> actually put informative MODULE_LICENSE() tags into their code for
> their proprietary licenses.
Any examples off the top of your head? I'm curious.
..Stu
Richard B. Johnson
> From: linux-ker...@vger.kernel.org
> > [mailto:linux-ker...@vger.kernel.org] On Behalf Of
> > Richard B. Johnson
> > sources are available. If the driver does not contain the appropriate
> > MODULE_LICENSE() string, then several tools will show "tainted" so
>
> If the MODULE_LICENSE() macro is what determines taint, what's to
> prevent a company from compiling their driver in their own kernel tree
> with that macro and releasing it binary-only? Wouldn't that module
> then be taint-free?
>
> ..Stu
>
Well yes! You can do:
File: License.c
/*
*
* Everything in this file (only) is released under the so-called
* GNU Public License, incorporated herein by reference.
*
* Now, we just link this with any proprietary code and everybody
* but the lawyers are happy.
*/
#ifndef __KERNEL__
#define __KERNEL__
#endif
#ifndef MODULE
#define MODULE
#endif
#include <linux/module.h>
#if defined(MODULE_LICENSE)
MODULE_LICENSE("GPL");
#endif
You can link the output of this file with the binary-only file
and get rid of the 'tainted' message.
gcc -I./usr/src/linux/`uname-r` -o license.o License.c
ld -i -o driver.o binary.o license.o
....bbuutttt.... Now, if the kernel gets dorked because
a binary-only module is broken, the binary-only module will
not get fixed! The kernel developers need to know if the
source-code is available for everything that's in the kernel
when the kernel croaks. They need to examine the code of
every suspect module as well as the kernel code in the area
of interest. Note that a module inside the kernel is free to
destroy __everything__. A wild pointer in user-mode just
seg-faults, in kernel mode it can scribble over your hard-
disk and you won't even know it until you try to edit your
movie script that you've been working on for 20 years.
Currently, once an oops is reported and developers see the
'tainted' message, they ask the reporter to remove the module
that is producing that message. If the machine can't run without
it, they ask the person to get the help of the module provider.
Often "ask" is not too kind. Usually, it's a snide remark
by persons who are not trained in public affairs so this
may tend to cause some friction. However, remember that the
wizards that gave a lot of their time and effort to kernel
development don't really like to have some secret module
screwing up their work.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
Note 96.31% of all statistics are fiction.
Mariusz Zielinski
> From: linux-ker...@vger.kernel.org
>
> > You could equally ask the same question about any other measure - its
> > no different to "I could shoot the shopkeeper and not pay", its an
> > incentive to behave, a way for developers to make it clear their code
>
> That's what I figured, I just wanted to check.
>
> > isnt for stealing and without denying people the choice of what they
> > run. The reputable vendors on the whole not only seem to obey it but
> > actually put informative MODULE_LICENSE() tags into their code for
> > their proprietary licenses.
>
> Any examples off the top of your head? I'm curious.
Realtek 8180L wlan chipset driver.
--
...and all that jazz
Mariusz Zielinski - Wirtualna Polska
Stuart MacDonald
From:
http://www.realtek.com.tw/downloads/downloads1-3.aspx?series=16&Software=True
These drivers are all source and appear to be all GPLed.
..Stu
Mariusz Zielinski
> > Any examples off the top of your head? I'm curious.
> Realtek 8180L wlan chipset driver.
This is "bad example" ( closed source and GPL license ). Good one is nvidia
( MODULE_LICENSE("NVIDIA"); ).
Mariusz Zielinski
> From: Mariusz Zielinski [mailto:le...@wp-sa.pl]
>
> > Realtek 8180L wlan chipset driver.
>
> From:
> http://www.realtek.com.tw/downloads/downloads1-3.aspx?series=16&Software=Tr
>ue
>
> These drivers are all source and appear to be all GPLed.
Archive: rh90-8180(120).zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
2150 Defl:N 769 64% 07-24-03 10:30 bdcbb2db release/Makefile
216130 Defl:N 84093 61% 07-24-03 10:30 f6e934c9 release/priv_part.o
^^^^^^^^^^^^^^^^^^^
1503 Defl:N 548 64% 07-24-03 10:30 aa55c41c release/r8180_export.h
17834 Defl:N 3524 80% 07-24-03 10:30 b00831ae release/r8180_if.c
4488 Defl:N 1278 72% 07-24-03 10:30 00e6785f release/r8180_if.h
13319 Defl:N 2811 79% 07-24-03 10:30 1ad0ac11 release/r8180_pci_init.c
^^^^^^^^^^^^^^^^^^^^^^^^
#cat r8180_pci_init.c | grep MODULE_LICENSE
MODULE_LICENSE("GPL");
528 Defl:N 321 39% 07-24-03 10:30 9fe4dafc release/r8180_pci_init.h
8722 Defl:N 2028 77% 07-24-03 10:30 580d8c16 release/r8180_type.h
5072 Defl:N 1709 66% 07-24-03 10:30 90348255 release/readme
529 Defl:N 320 40% 07-24-03 10:30 aafe3723 release/rls_note_0724
155 Defl:N 116 25% 07-24-03 10:30 6d3018fc release/wlandown
587 Defl:N 266 55% 07-24-03 10:30 763d2e5f release/wlanup
-------- ------- --- -------
271017 97783 64% 12 files
--
Mariusz Zielinski
Alan Cox
> From: Mariusz Zielinski [mailto:le...@wp-sa.pl]
> > Realtek 8180L wlan chipset driver.
>
> From:
> http://www.realtek.com.tw/downloads/downloads1-3.aspx?series=16&Software=True
>
> These drivers are all source and appear to be all GPLed.
Only part source so realtek need a little re-education to make them fix
the drivers. Someone who deals with realtek drivers (Jeff Garzik ?) care
to start a polite initial dialog ?
Andre Hedrick
On Tue, 2 Sep 2003, David Schwartz wrote:
>
> I agree with you, except for the one place where you've contradicted
> yourself:
>
> > If you are an embedded space widget. Apply thumb to nose and wiggle
> > fingers. Provided you ship the source code you modify in the kernel, and
> > I do mean all of it, use the short cut to clobber the issues in module.h.
> > When they scream and complain about, this violates intent, ask them are
> > they issuing a restriction on the usage of the GPL kernel? If they do not
> > permit one to use it under GPL them the kernel itself is in violation.
>
> In other words, you cannot release something under the GPL and
> simultaneously restrict its use.
You have made my points even clearer.
The fact that GPL_ONLY horse sh*t exists means there is a restriction on
usage. So "GPL_ONLY" has in effect violated GPL, by imposing restrictions
of usage. People will say that I am nuts and have spent to much time in
the disk drive layers and my brain has not stopped spinning to reconnect
to the stem.
> > Now back to "tainting", if the politics were such to cause all modules
> > which are not GPL to be rejected then the game is over. Because the
> > kernel does not reject loading, it by default approves of closed source
> > binary modules. One could use the means of taint-testing to accept or
> > reject, regardless of the original intent. Many have and will make the
> > argument the kernel has the ability to reject closed source and it choose
> > to accept.
>
> So no, the kernel does not have the ability to reject closed source. That
> would be an additional restriction upon use that the GPL does not allow you
> to impose.
Exactly!
I think it is about time to start http://www.ungpl.com/ however that is a
gas and pipe line already, which gives a broader meaning to the what and
why many people have earned the title of "GPL NAZIS".
Yeah, I said it and it is flamebait. I am pulling out some marshmellows
to cook as I wait for the roasting fireballs to come my way.
I am not here to make friends, just promote Linux for business and
commerial usage and the direction today is wrong period. I will not
debate the point, this is my opinion and it is correct.
Cheers,
Andre
PS: any references to "you" is a general to the mailing list and not to
any individual.
Stuart MacDonald
> 6&Software=Tr
>
> Look at
> http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=2
> 002111&famid=2002111&series=2002121&Software=True
Indeed, I was fooled. The Quick Link download on the sidebar was
static, not dynamic (figured it would update appropriately when I
clicked on the 8180 link from the homepage).
..Stu
Jeff Garzik
> On Mer, 2003-09-03 at 16:50, Stuart MacDonald wrote:
>
>>From: Mariusz Zielinski [mailto:le...@wp-sa.pl]
>>
>>>Realtek 8180L wlan chipset driver.
>>
>>From:
>>http://www.realtek.com.tw/downloads/downloads1-3.aspx?series=16&Software=True
>>
>>These drivers are all source and appear to be all GPLed.
>
>
> Only part source so realtek need a little re-education to make them fix
> the drivers. Someone who deals with realtek drivers (Jeff Garzik ?) care
> to start a polite initial dialog ?
Maybe I'm blind but I don't see 8180 wireless support at all there.
They have for a driver whose zipfile is called "8139cp". You unpack it
and it's an ancient 8139too.c with 8139C+ support added :)
But no 8180 support?
Jeff
Andre Hedrick
On Wed, 3 Sep 2003, Alan Cox wrote:
> On Mer, 2003-09-03 at 18:38, Andre Hedrick wrote:
> > The fact that GPL_ONLY horse sh*t exists means there is a restriction on
> > usage. So "GPL_ONLY" has in effect violated GPL, by imposing restrictions
> > of usage. People will say that I am nuts and have spent to much time in
> > the disk drive layers and my brain has not stopped spinning to reconnect
> > to the stem.
>
> Mummy there's a troll on the list again...
>
> The GPL itself says that derivative works must be GPL. The GPL_ONLY
> stuff just helps make that clear.
>
Gee I should follow other peoples advice about it takes two idiots to
argue in public, and not reply to the "troll bait".
So I wait for your political crap and ideas of making it impossible for
businesses with IP and property that is not and will never be open to work
inside or with Linux.
So with your bait and troll rants, I will challenge you and the rest of
the GPL only pinheads, to the pre-loader module issue which is gpl'd.
What are you going to do now? Sue, send laywers, please I invite and beg
you to do so. The "freed_symbols" project just got energized!
Cheers,
Andre
PS I am bold enough to sign my name to such issues ...
Pascal Schmidt
> The fact that GPL_ONLY horse sh*t exists means there is a restriction on
> usage. So "GPL_ONLY" has in effect violated GPL, by imposing restrictions
> of usage.
Where is the restriction? You get the source code, you can roll your
own and remove the GPL_ONLY stuff. Apart from that I do not recall
to have seen anything about restrictions of usage in the GPL... the
only thing it tries to prevent is the source code becoming proprietary.
--
Ciao,
Pascal
Alan Cox
> usage. So "GPL_ONLY" has in effect violated GPL, by imposing restrictions
> of usage. People will say that I am nuts and have spent to much time in
> the disk drive layers and my brain has not stopped spinning to reconnect
> to the stem.
Mummy there's a troll on the list again...
The GPL itself says that derivative works must be GPL. The GPL_ONLY
stuff just helps make that clear.
-
Andre Hedrick
On Wed, 3 Sep 2003, Pascal Schmidt wrote:
> On Wed, 03 Sep 2003 20:00:24 +0200, you wrote in linux.kernel:
>
> > The fact that GPL_ONLY horse sh*t exists means there is a restriction on
> > usage. So "GPL_ONLY" has in effect violated GPL, by imposing restrictions
> > of usage.
>
> Where is the restriction? You get the source code, you can roll your
> own and remove the GPL_ONLY stuff. Apart from that I do not recall
> to have seen anything about restrictions of usage in the GPL... the
> only thing it tries to prevent is the source code becoming proprietary.
Pascal,
I agree with you and you make the point clear!
There are people who have issued letters to big linux distributors in the
US about changing a symbol types. That is a restriction for usage, in my
opinion.
Cheers,
Andre
David Schwartz
> On Mer, 2003-09-03 at 15:36, Stuart MacDonald wrote:
> > If the MODULE_LICENSE() macro is what determines taint, what's to
> > prevent a company from compiling their driver in their own kernel tree
> > with that macro and releasing it binary-only? Wouldn't that module
> > then be taint-free?
> They would be representing their module is GPL when its not, obtaining
> services by deceving people (3rd party support) and if they used _GPL
> symbols probably violating the DMCA by bypassing a digital rights
> system.
Holy crap! You've totally pegged my hypocrisy meter.
It is an outright blatant violation of the GPL to build use limitations
into GPL'd works and then use the DMCA to prevent people from removing or
bypassing those limitations.
Next I'm going to add some new features to Linux and my code will check for
a license certificate before it runs. I'll use the DMCA to protect the
license check but I'll distribute the source code just like the GPL requires
me to.
No, the GPL does not require derived works to be GPL'd. No, the GPL does
not allow you to impose additional usage restrictions and use the DMCA to
prohibit people from modifying the code to use it the way they want.
DS
David Schwartz
> On Wed, 03 Sep 2003 20:00:24 +0200, you wrote in linux.kernel:
> > The fact that GPL_ONLY horse sh*t exists means there is a restriction on
> > usage. So "GPL_ONLY" has in effect violated GPL, by imposing
> > restrictions
> > of usage.
> Where is the restriction? You get the source code, you can roll your
> own and remove the GPL_ONLY stuff. Apart from that I do not recall
> to have seen anything about restrictions of usage in the GPL... the
> only thing it tries to prevent is the source code becoming proprietary.
If the GPL_ONLY stuff is a license enforcement scheme, the DMCA prohibits
you from removing it. If the GPL_ONLY stuff is not a license enforcement
scheme, nothing prohibits you from stamping your module GPL when it's not.
However, the GPL (section 2b) prohibits you from imposing any restrictions
other than those in the GPL itself. The GPL contains no restrictions that
apply to mere use and the GPL_ONLY stuff affects use, so it can't be a
license restriction, hence there is no restriction to enforce.
I don't see anything preventing a GPL'd work from containing code that
imposes restrictions actually contained in the GPL and using the DMCA to
enforce them. But it would have to be a restriction contained in the GPL
itself, and there is no restriction about what code you can use with a GPL'd
work.
DS
Pascal Schmidt
> If the GPL_ONLY stuff is a license enforcement scheme, the DMCA
> prohibits you from removing it.
-ENOTUSCITIZEN
> If the GPL_ONLY stuff is not a license enforcement scheme, nothing
> prohibits you from stamping your module GPL when it's not.
I'd say its up to the lawyers and judges to find out whether having
MODULE_LICENSE("GPL") in a module means anything legally. It might
mean "I promise this module is made from GPL source", but it might
also mean nothing.
> However, the GPL (section 2b) prohibits you from imposing any
> restrictions other than those in the GPL itself.
Section 2b) in the file COPYING in the root dir of the kernel source
does not talk about restrictions. Are we talking about the same version
of the GPL?
> The GPL contains no restrictions that
> apply to mere use and the GPL_ONLY stuff affects use, so it can't be a
> license restriction, hence there is no restriction to enforce.
The GPL doesn't even cover use of the "product". It covers modification
and redistribution.
Well, it is still an open question whether kernel modules are derived
works or not, especially since we don't have a stable kernel ABI and
therefore modules have to use part of the kernel source (headers) and
module writers have to study kernel code to write their modules (since
there is no official complete documentation about functions in the
kernel).
If modules are derived works, then legally, following the GPL, they
must be GPL too and GPL_ONLY is no problem but pointless.
Seems to me you could say GPL_ONLY is a way of the developer saying
"I consider your stuff to be a derived work if you use this symbol".
Ask a lawyer whether that's their decision to make. ;)
Apart from that, I fail to see how it is an addition restriction
when you still have the right to remove all the GPL_ONLY stuff. After
all, the kernel is GPLed work, so you have the right to remove
things and distribute the result. How is it a real restriction when
the license allows you to remove it?
--
Ciao,
Pascal
David Schwartz
> On Wed, 3 Sep 2003, David Schwartz wrote:
> > If the GPL_ONLY stuff is a license enforcement scheme, the DMCA
> > prohibits you from removing it.
> -ENOTUSCITIZEN
In that case, there is more than likely nothing that prevents you from
doing whatever you want.
> > If the GPL_ONLY stuff is not a license enforcement scheme, nothing
> > prohibits you from stamping your module GPL when it's not.
> I'd say its up to the lawyers and judges to find out whether having
> MODULE_LICENSE("GPL") in a module means anything legally. It might
> mean "I promise this module is made from GPL source", but it might
> also mean nothing.
Probably so.
> > However, the GPL (section 2b) prohibits you from imposing any
> > restrictions other than those in the GPL itself.
> Section 2b) in the file COPYING in the root dir of the kernel source
> does not talk about restrictions. Are we talking about the same version
> of the GPL?
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
In other words, if you want to distribute the Linux kernel, you must
license it under the terms of the GPL. You may not impose additional
restrictions because if you do, you're not causing it to be distribute under
the terms of "this License".
So if I download the Linux kernel from somewhere, someone distributed it to
me. Hence, if they complied with the GPL, I am under only the obligations
imposed by the GPL.
> > The GPL contains no restrictions that
> > apply to mere use and the GPL_ONLY stuff affects use, so it can't be a
> > license restriction, hence there is no restriction to enforce.
> The GPL doesn't even cover use of the "product". It covers modification
> and redistribution.
It does cover use. Specifically, it permits unrestriced use. If you
received GPL'd code, you have the unrestricted right to use it. That's what
section 2b says.
> Well, it is still an open question whether kernel modules are derived
> works or not, especially since we don't have a stable kernel ABI and
> therefore modules have to use part of the kernel source (headers) and
> module writers have to study kernel code to write their modules (since
> there is no official complete documentation about functions in the
> kernel).
Non-issue. I'm talking about your rights to *use* the kernel.
> If modules are derived works, then legally, following the GPL, they
> must be GPL too and GPL_ONLY is no problem but pointless.
You must not be reading the same GPL I am. Can you please cite to me the
section that requires derived works to be placed under the GPL. I can't find
it.
> Seems to me you could say GPL_ONLY is a way of the developer saying
> "I consider your stuff to be a derived work if you use this symbol".
> Ask a lawyer whether that's their decision to make. ;)
But that's not what it does. It prevents you from using the kernel in
certain ways. The GPL does not permit such usage restrictions. It also
restricts your ability to create and use derived works. The GPL similarly
does not permit such restrictions. The only restrictions the GPL allows a
distributed derived work to contain are those specifically imposed by the
GPL, and those restrictions only kick in at distribution.
If there were distribution restrictions, you'd have an argument. But we are
talking about use restrictions.
> Apart from that, I fail to see how it is an addition restriction
> when you still have the right to remove all the GPL_ONLY stuff.
You only have that right (in the United States) if the GPL_ONLY stuff is
*not* a copyright enforcement scheme.
> After
> all, the kernel is GPLed work, so you have the right to remove
> things and distribute the result. How is it a real restriction when
> the license allows you to remove it?
Fine, so long as we all agree that the GPL_ONLY stuff is not a copyright or
license enforcement scheme and that evading or modifying it is not evading a
copyright/license enforcement scheme. In this case, you cannot argue that
the DMCA prohibits claiming a GPL license for purposes of compatability.
DS
Pascal Schmidt
> In other words, if you want to distribute the Linux kernel, you must
> license it under the terms of the GPL. You may not impose additional
> restrictions because if you do, you're not causing it to be distribute
> under the terms of "this License".
Correct.
> It does cover use.
In section 0:
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.
> Specifically, it permits unrestriced use. If you
> received GPL'd code, you have the unrestricted right to use it. That's
> what section 2b says.
No, section 2b gives you the the right to copy, distribute, and modify
the code (as the license only covers those rights, as per section 0) and
no restrictions may be placed on those specific rights.
> Non-issue. I'm talking about your rights to *use* the kernel.
Well, I'm not buying the argument that the GPL has anything to say
about usage.
> You must not be reading the same GPL I am. Can you please cite to me the
> section that requires derived works to be placed under the GPL. I can't
> find it.
You quoted it yourself. 2b)
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
"work that ... is derived from the Program or any part thereof"
> But that's not what it does. It prevents you from using the kernel in
> certain ways. The GPL does not permit such usage restrictions.
Lots of GPL'ed programs refuse to be used in certain ways. For example,
fetchmail will refuse to run with a world-readable .fetchmailrc file.
> It also restricts your ability to create and use derived works. The GPL
> similarly does not permit such restrictions.
That it does not, and such a restriction would violate the GPL, I'd
agree to that.
> You only have that right (in the United States) if the GPL_ONLY stuff is
> *not* a copyright enforcement scheme.
How can it be that? It does not restrict copying nor distribution
nor modification.
People here are saying that it's more of a hint to people that they
better think hard and ask a lawyer before implementing non-GPL'ed
kernel modules.
I think you bringing the DMCA into this shows an interesting aspect
of that law: who gets to say what is a copyright enforcement scheme
and what is not?
--
Ciao,
Pascal
Andre Hedrick
Pascal,
SUPER HIGH FIVE!
You have made the obvious clear, and most will not even follow or listen.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
David Schwartz
> On Wed, 3 Sep 2003, David Schwartz wrote:
>
> > In other words, if you want to distribute the Linux kernel, you must
> > license it under the terms of the GPL. You may not impose additional
> > restrictions because if you do, you're not causing it to be distribute
> > under the terms of "this License".
>
> Correct.
>
> > It does cover use.
>
> In section 0:
>
> Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope.
So are you arguing that I can distribute a derived work from the Linux
kernel and attach a 'you may not use this unless you pay me $100' clause and
it would be enforceable?
> > Specifically, it permits unrestriced use. If you
> > received GPL'd code, you have the unrestricted right to use it. That's
> > what section 2b says.
>
> No, section 2b gives you the the right to copy, distribute, and modify
> the code (as the license only covers those rights, as per section 0) and
> no restrictions may be placed on those specific rights.
If you are right, you've discovered a serious fundamental flaw in the GPL.
I can distribute code under the GPL and prohibit anyone from using derived
works, hence effectively removing their freedom to modify.
> > Non-issue. I'm talking about your rights to *use* the kernel.
>
> Well, I'm not buying the argument that the GPL has anything to say
> about usage.
Then you have no right to usage. The preamble contradicts this, but I doubt
it's binding.
> > You must not be reading the same GPL I am. Can you please cite to me the
> > section that requires derived works to be placed under the GPL. I can't
> > find it.
>
> You quoted it yourself. 2b)
>
> b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any
> part thereof, to be licensed as a whole at no charge to all third
> parties under the terms of this License.
>
> "work that ... is derived from the Program or any part thereof"
This is only about works that you distribute or publish. We're talking
about using modules.
> > But that's not what it does. It prevents you from using the kernel in
> > certain ways. The GPL does not permit such usage restrictions.
>
> Lots of GPL'ed programs refuse to be used in certain ways. For example,
> fetchmail will refuse to run with a world-readable .fetchmailrc file.
Yes, but nobody's arguing that these are license enforcement schemes or
that this is a license restriction. Nobody would complain if you removed
those restrictions. The question here is whether the GPL_ONLY stuff is a
copyright enforcement mechanism or license restriction. If we agree it's not
and anyone is free to circumvent or remove it, then there's nothing to
dispute.
> > It also restricts your ability to create and use derived works. The GPL
> > similarly does not permit such restrictions.
>
> That it does not, and such a restriction would violate the GPL, I'd
> agree to that.
Okay.
> > You only have that right (in the United States) if the GPL_ONLY stuff is
> > *not* a copyright enforcement scheme.
> How can it be that? It does not restrict copying nor distribution
> nor modification.
Copyright enforcement schemes can also restrict usage. Access cards for
satellite TV are purely usage restriction devices.
> People here are saying that it's more of a hint to people that they
> better think hard and ask a lawyer before implementing non-GPL'ed
> kernel modules.
I'd agree with that.
> I think you bringing the DMCA into this shows an interesting aspect
> of that law: who gets to say what is a copyright enforcement scheme
> and what is not?
The law has a somewhat incomprehensible definition of what consitutes such
a scheme. I don't think anybody really knows what things would be considered
copyright enforcement schemes and what would not.
Your argument that the GPL does not grant usage rights is troubling. If
it's correct, then I have no right to use the Linux kernel, since the
copyright holders never granted it to me!
DS
Alan Cox
> Next I'm going to add some new features to Linux and my code will check for
> a license certificate before it runs. I'll use the DMCA to protect the
> license check but I'll distribute the source code just like the GPL requires
> me to.
Tivo already do this.
Pascal Schmidt
> So are you arguing that I can distribute a derived work from the Linux
> kernel and attach a 'you may not use this unless you pay me $100' clause
> and it would be enforceable?
Well, the GPL does not allow you to impose retrictions on copying and
redistribution, so you cannot disallow others redistributing your work
without your usage clause attached, and it would be legal for them to
do that under the GPL.
Your restriction could only effect the part of the kernel you
actually modified, because that would be the only part you have
copyright on. How are you going to prove people used that part? They
have the right to modify the copy, unrestricted, so they could've
taken your piece of the code out before using the kernel.
> If you are right, you've discovered a serious fundamental flaw in the
> GPL. I can distribute code under the GPL and prohibit anyone from using
> derived works, hence effectively removing their freedom to modify.
No, I don't see how you have influence over derived works. Nothing in
the GPL allows you to bind redistributors to your usage clause, since
copying and redistribution is covered by the GPL.
> Then you have no right to usage. The preamble contradicts this, but I
> doubt it's binding.
Well, under German law, if I have the right to legally obtain something,
I automatically have the right to usage. Law only comes into play again if
I redistribute it or use it in public in some illegal way.
Under German law, you need a real contract in place for usage
restrictions to be effective or you need to make certain kinds of
usage technically impossible (because if you don't, courts will say
you did not even attempt to protect your interests). And no, MS-type
"open this bag and you're bound to our license" is not a legal contract
over here. Violation of the usage restriction would then fall under
contract law, not copyright law.
I don't see how GPL'ed code can have technical restrictions since I
can easily compile and change it and I don't have to sign a contract to
get it since the license grants unrestricted redistribution right.
This may all be different in the US, of course.
> This is only about works that you distribute or publish. We're talking
> about using modules.
Well, somebody must have distributed the module, and if that act was
illegal because of a GPL violation, I don't know whether you have any
right to usage anyway.
> Copyright enforcement schemes can also restrict usage. Access cards for
> satellite TV are purely usage restriction devices.
These come with a contract here in Germany, and once you have a contract,
you can of course, within some limits, put usage restrictions in it as
much as you like. You just have to make sure you only give the card to
someone who has indeed signed the contract.
--
Ciao,
Pascal
Timothy Miller
enough time reading the discussion about GPL and drivers that I feel
compelled to comment. I don't intend to comment further because I don't
want to contribute to a flamewar any more than this already will. But I
feel the need to defend those who contribute to Free Software against
those who don't.
The argument I have been reading has been centered around the idea of
working around the GPL to support binary-only driver and various other
things which are counter to the spirit of the GPL and Linux. But
someone who is trying to find a legal GPL loophole is not considering
the root of the situation and that the GPL is an effect, not a cause.
A point someone else made that I feel compelled to reiterate is that it
is the nature of the Linux development model and the attitude of the
developers which has made Linux what it is and has made you want to use it.
But I have another point. You are not dealing with a license here. The
license is there to satisfy lawyers and make clear the INTENT of the
authors. The keyword here is INTENT in that someone who has developed
something is telling you how they feel about the use of their work
which, under many circumstances, they could have chosen not to share
with you. What you are dealing with is real people who have put an
incredible amount of time and effort into developing Linux. Those
people, to whom you owe much respect for sharing their contributions,
have decided that their software should be used with certain
restrictions, that being the GPL. If you abuse Linux, it is not the GPL
that you are insulting, but the people who developed Linux.
The GPL_ONLY restriction for driver modules may seem unfair, but it is
far from it. There are both valid technical and philosophical reasons
for working that way. No one forces you to use Linux, and when you made
the choice to use it, you are entering into a community with a specific
philosophy. You know that philosophy in advance, so when you discover
that you have a restruction you don't like, you have no room to complain.
As someone said, if you want to write drivers for a UNIX which does not
have these restrictions, there are plenty of commercial UNIXes out there
that you have to choose from. The fact that they are perhaps less
popular is one reason why Linux developers do not want to imitate them.
So, the discussions about finding ways to make a non-GPL driver look
like a GPL driver and get away with it legally are all moot. The reason
you should not violate this is because the architects of Linux do not
want you to. If you choose to violate that, you are being unethical,
pure and simple. Or more to the point, you're being an asshole to a lot
of hard-working people who have chosen to freely share their work with
you. Since they are the authors and you are not, their feelings about
their softare are more important than yours. You may be able to screw
them over and get away with it -- people do that sort of thing all the
time -- but the fact that you may find a legal loophole doesn't make you
any less of an abject asshole.
In short: Be honorable.
David Schwartz
> But I have another point. You are not dealing with a license here. The
> license is there to satisfy lawyers and make clear the INTENT of the
> authors. The keyword here is INTENT in that someone who has developed
> something is telling you how they feel about the use of their work
> which, under many circumstances, they could have chosen not to share
> with you. What you are dealing with is real people who have put an
> incredible amount of time and effort into developing Linux. Those
> people, to whom you owe much respect for sharing their contributions,
> have decided that their software should be used with certain
> restrictions, that being the GPL. If you abuse Linux, it is not the GPL
> that you are insulting, but the people who developed Linux.
In other words, information does not want to be free. You shouldn't use
code the way you want to use it but the way the authors want you to use it.
After all, they didn't have to give it to you if they didn't want to.
However, Richard Stallman does not agree with this view. It's his view that
if the authors chose to give you the code, you can use it any way you want
to, regardless of how the authors feel about that type of usage. This is why
he created the GPL.
> So, the discussions about finding ways to make a non-GPL driver look
> like a GPL driver and get away with it legally are all moot. The reason
> you should not violate this is because the architects of Linux do not
> want you to.
If you really believe that the Linux authors wished to continue to control
how their code was used, you have to think that they were stupid to release
the code under the GPL. After all, the whole point of the GPL is to prohibit
such restrictions. The reason Linux is under the GPL is so that developers
*can't* put restrictions on how the package can be used. That's the "open"
in open source.
> If you choose to violate that, you are being unethical,
> pure and simple. Or more to the point, you're being an asshole to a lot
> of hard-working people who have chosen to freely share their work with
> you.
The person who tries to put other people's GPL'd works under his license
restrictions is the asshole. I have contributed code to the Linux kernel
under the GPL license (bonus points to anyone who can find my 25 lines of
code or so). It is nobody else's right to add code to my code and add usage
restrictions to it. The GPL expressly forbids this.
> Since they are the authors and you are not, their feelings about
> their softare are more important than yours.
I'm just baffled. You don't seem to understand at all why the Linux kernel
is organized under the GPL. It's precisely so that some developers can't
hijack the project and encumber the growing source base with usage and
distribution restrictions.
> You may be able to screw
> them over and get away with it -- people do that sort of thing all the
> time -- but the fact that you may find a legal loophole doesn't make you
> any less of an abject asshole.
The asshole is the person who thinks that they have the right to change the
express wishes of all the other contributors to the kernel who chose to
contribute to a project that operates under the GPL license. The GPL license
is about there being no restrictions on usage.
> In short: Be honorable.
I am. The hijackers are not.
DS
Pascal Schmidt
> However, Richard Stallman does not agree with this view. It's his
> view that if the authors chose to give you the code, you can use it any
> way you want to, regardless of how the authors feel about that type of
> usage. This is why he created the GPL.
Use in any way you want to is the BSD license, not the GPL. The GPL
does restrict what you're allowed to do in order to keep the source
free...
--
Ciao,
Pascal
David Schwartz
> On Wed, 10 Sep 2003 22:40:14 +0200, you wrote in linux.kernel:
> > However, Richard Stallman does not agree with this view. It's his
> > view that if the authors chose to give you the code, you can use it any
> > way you want to, regardless of how the authors feel about that type of
> > usage. This is why he created the GPL.
> Use in any way you want to is the BSD license, not the GPL.
Please show me one restriction on *use* in the GPL.
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does."
Licenses that place restrictions on usage are *not* open source licenses.
> The GPL
> does restrict what you're allowed to do in order to keep the source
> free...
Yes, it restricts your ability to distribute and your ability to create
derived works if and only if you distribute those derived works. It places
no restrictions whatsoever on use. And since it requires distributors to
place no restrictions not in the GPL, distributors cannot place *any*
restrictions on usage either.
DS
Pascal Schmidt
> Please show me one restriction on *use* in the GPL.
Well, you may not *use* GPL'd code to produce a derived work and
distribute it in binary form only. Use of the code, not use of
the product, sure.
--
Ciao,
Pascal
James Clark
There are a lot of zealots on both sides of the GPL debate - personally, my
undertanding is that the GPL forbids usage restrictions, thus once you
release code under the GPL you cannot control it. This seems especially
important in a project, such as Linux, that has been collaboratively
developmed by a whole community.
The original question was would a binary driver interface allow easier usage
by 'normal' users with any compatible kernel (rather than specific versions)
and perhaps simplify module development cycle?
Would the performance hit involved be worth the potential
compatibility/simplicity?
A lot of people have, assumed that this is a call to arms for binary-only
modules. This is not true although this type of change would make such things
more common.
James
David Schwartz
> On Wed, 10 Sep 2003, David Schwartz wrote:
> > Please show me one restriction on *use* in the GPL.
> Well, you may not *use* GPL'd code to produce a derived work and
> distribute it in binary form only.
That is a restriction on distribution, not use. You may use GPL'd code to
produce a derived work and you may use that derived work. The only
restrictions kick in when and if you distribute that derived work.
> Use of the code, not use of
> the product, sure.
The GPL puts no restrictions on use. The GPL_ONLY stuff does.
It's really this simple: The GPL says you can use the code for whatever you
want. It also says that if you want to distribute the GPL'd work or works
based on the GPL'd work, you may not impose any restrictions other than
those imposed by the GPL. It very specifically prohibits restrictions on
mere use or upon the mere creation of derived works. All of its restrictions
kick in on distribution.
The GPL_ONLY stuff is an attempt to restrict use. There is nothing
inherently wrong with attempts to restrict use. One could argue that the
root permission check on 'umount' is a restriction on use. Surely the GPL
doesn't mean you can't have any usage restrictions at all.
What it does mean is that such usage restrictions *cannot* be licensing
restrictions. In other words, it cannot be a license violation to remove
them or circumvent them. So long as nobody tries to claim the GPL_ONLY is a
license enforcement technique, there is no dispute.
However, some people seem to be arguing that the GPL_ONLY symbols are in
fact a license enforcement technique. If that's true, then when they
distribute their code, they are putting additional restrictions not in the
GPL on it. That is a GPL violation.
Other people who contributed to the Linux kernel relied upon the GPL
license to ensure that their code, and works derived from it, would be
available *without* use restrictions. Nobody has the right to turn around
and impose usage restrictions on the Linux kernel source code.
The GPL prohibits the imposition of any licensing requirements other than
those contained in the GPL itself, all of which kick in only upon
distribution. It's really that simple. Anyone who distributes the Linux
kernel with a licensing restriction that kicks in on mere use is violating
the GPL.
DS
David Schwartz
> On Wed, 10 Sep 2003, David Schwartz wrote:
> > Please show me one restriction on *use* in the GPL.
> Well, you may not *use* GPL'd code to produce a derived work and
> distribute it in binary form only. Use of the code, not use of
> the product, sure.
Sure, and you may not *use* GPL'd code to produce a derived work and bring
a firearm into a court of law. I asked for a restriction on *use*, not a
restriction on use and something else.
DS
Eric W. Biederman
> The GPL_ONLY stuff is an attempt to restrict use. There is nothing
> inherently wrong with attempts to restrict use. One could argue that the
> root permission check on 'umount' is a restriction on use. Surely the GPL
> doesn't mean you can't have any usage restrictions at all.
No the GPL_ONLY stuff is an attempt to document that there is no conceivable
way that using a given symbol does not create a derived work.
If you use an unmodified kernel it is only a one liner to ensure it does
not complain about your code. So this only shows up as a real
impediment when code that uses the symbol is distributed.
Beyond which copying code into the kernel is when this is checked so this is
a valid place to check things. There is a strong tying between using
programs and copying them into memory. And that copying is the
justification for most usage restrictions even in commercial software.
The code is also quite a small nit that really should not affect
anything.
Eric
Alan Cox
> The GPL puts no restrictions on use. The GPL_ONLY stuff does.
No it doesn't. It allows people to track whether you get support or not.
It prevents nothing.
David Schwartz
Combined responses.
> No the GPL_ONLY stuff is an attempt to document that there is no
> conceivable
> way that using a given symbol does not create a derived work.
and:
> > The GPL puts no restrictions on use. The GPL_ONLY stuff does.
> No it doesn't. It allows people to track whether you get support or not.
> It prevents nothing.
So long as it's not an attempt to use the GPL license as a way to restrict
use, there's no problem. There is no license restriction or enforcement
scheme here that one could possibly circumvent because the GPL_ONLY stuff is
not a license enforcement scheme. It cannot be a license enforcement scheme
because there are no license requirements that kick in upon any act other
than distribution.
The GPL_ONLY stuff does in fact restrict use. However, this is a
restriction anyone is free to remove or circumvent if it bothers them. This
isn't a dishonorable act because nobody intended this mechanism to restrict
use -- I hope.
DS
Mike Fedyk
> The GPL_ONLY stuff does in fact restrict use. However, this is a
> restriction anyone is free to remove or circumvent if it bothers them. This
> isn't a dishonorable act because nobody intended this mechanism to restrict
> use -- I hope.
If effect it does affect use because of lack of support. But personally I
agree with that...
Timothy Miller
David Schwartz wrote:
>>But I have another point. You are not dealing with a license here. The
>>license is there to satisfy lawyers and make clear the INTENT of the
>>authors. The keyword here is INTENT in that someone who has developed
>>something is telling you how they feel about the use of their work
>>which, under many circumstances, they could have chosen not to share
>>with you. What you are dealing with is real people who have put an
>>incredible amount of time and effort into developing Linux. Those
>>people, to whom you owe much respect for sharing their contributions,
>>have decided that their software should be used with certain
>>restrictions, that being the GPL. If you abuse Linux, it is not the GPL
>>that you are insulting, but the people who developed Linux.
>
>
> In other words, information does not want to be free. You shouldn't use
> code the way you want to use it but the way the authors want you to use it.
> After all, they didn't have to give it to you if they didn't want to.
EXACTLY. Fortunately in this case, the authors place few restrictions
on your usage. Indeed, the "restrictions" are more a matter of being
nice to the people who made the stuff you're using.
You're stuck thinking about "law" and "rules". I'm thinking instead
about "honor".
One of the (unresolved) discussions I had with RMS involved the role of
the author. He believes that the user is more important than the
author. I believe the author is more important, because had the author
not written what the user has, then the user would not have it!
Actually, he partially agrees with me but does not feel that the author
should be able to apply restrictions (IF the work is PUBLISHED).
> However, Richard Stallman does not agree with this view. It's his view that
> if the authors chose to give you the code, you can use it any way you want
> to, regardless of how the authors feel about that type of usage. This is why
> he created the GPL.
But it seems clear to me that the GPL places some very strong
restrictions on your usage. Those restrictions are that although your
specific usage of the code doesn't matter, anything (published) that you
derive from GPL work MUST also be published under GPL.
So my point is that when someone publishes something under GPL that you
find useful, give respect to the person who wrote it by obeying the
spirit of the license. But it is not the license that is important as
that the author chose to release his work under those terms. People,
not rules; honor, not law.
There are other licenses besides the GPL. When authors release under
those terms, you should respect those terms as well. The thing that
sets the GPL apart from, say, closed-source licensing is that the GPL is
based on a system of honor, while proprietary systems can (and often do)
become unfairly restrictive to the users.
>
>
>>So, the discussions about finding ways to make a non-GPL driver look
>>like a GPL driver and get away with it legally are all moot. The reason
>>you should not violate this is because the architects of Linux do not
>>want you to.
>
>
> If you really believe that the Linux authors wished to continue to control
> how their code was used, you have to think that they were stupid to release
> the code under the GPL. After all, the whole point of the GPL is to prohibit
> such restrictions. The reason Linux is under the GPL is so that developers
> *can't* put restrictions on how the package can be used. That's the "open"
> in open source.
The restrictions they are applying are the only ones in the GPL. It was
smart for them to use the GPL because it is compatible with their
wishes. Follow the GPL not because the GPL is a copyright license, but
because you are grateful for the efforts of those who published under GPL.
Furthermore, if someone publishes under GPL, and your insult them, they
may become less willing to release under GPL, thereby limiting your
ability to rip them off.
Also, just to be pedantic, because you mentioned RMS, "open source" and
"free software" are not the same thing.
>
>>If you choose to violate that, you are being unethical,
>>pure and simple. Or more to the point, you're being an asshole to a lot
>>of hard-working people who have chosen to freely share their work with
>>you.
>
>
> The person who tries to put other people's GPL'd works under his license
> restrictions is the asshole. I have contributed code to the Linux kernel
> under the GPL license (bonus points to anyone who can find my 25 lines of
> code or so). It is nobody else's right to add code to my code and add usage
> restrictions to it. The GPL expressly forbids this.
And I completely agree with all of this. I'm getting the feeling that
you and I don't actually disagree on any of this. :)
The point of divergence is with regard to modules and the symbol
restrictions for non-GPL drivers. Here is a gray area where the GPL may
not apply really. These gray areas are where ethics and honor must come
into play.
>
>>Since they are the authors and you are not, their feelings about
>>their softare are more important than yours.
>
>
> I'm just baffled. You don't seem to understand at all why the Linux kernel
> is organized under the GPL. It's precisely so that some developers can't
> hijack the project and encumber the growing source base with usage and
> distribution restrictions.
Which is precisely why those authors placed Linux under the GPL. If
they didn't like that, they would be working on proprietary OS's. I'm
saying that people should respect the authors by honoring the GPL.
>
>>You may be able to screw
>>them over and get away with it -- people do that sort of thing all the
>>time -- but the fact that you may find a legal loophole doesn't make you
>>any less of an abject asshole.
>
>
> The asshole is the person who thinks that they have the right to change the
> express wishes of all the other contributors to the kernel who chose to
> contribute to a project that operates under the GPL license. The GPL license
> is about there being no restrictions on usage.
Well, aside from the "it must remain free clause" (which I interpret as
an important restriction), I agree with you. That is to say, the
"contributor" who hijacks the work of other contributors is being
dishonorable, because he is not respecting the other contributors.
>
>>In short: Be honorable.
>
>
> I am. The hijackers are not.
Agreed.
Timothy Miller
David Schwartz wrote:
>>On Wed, 10 Sep 2003 22:40:14 +0200, you wrote in linux.kernel:
>
>
>>>However, Richard Stallman does not agree with this view. It's his
>>>view that if the authors chose to give you the code, you can use it any
>>>way you want to, regardless of how the authors feel about that type of
>>>usage. This is why he created the GPL.
>>
>
>>Use in any way you want to is the BSD license, not the GPL.
>
>
> Please show me one restriction on *use* in the GPL.
>
> "Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope. The act of
> running the Program is not restricted, and the output from the Program
> is covered only if its contents constitute a work based on the
> Program (independent of having been made by running the Program).
> Whether that is true depends on what the Program does."
>
> Licenses that place restrictions on usage are *not* open source licenses.
What about "usage" of source code?
GPL says you are not allowed to "use" GPL source in a non-free program
that you publish.
>
>>The GPL
>>does restrict what you're allowed to do in order to keep the source
>>free...
>
>
> Yes, it restricts your ability to distribute and your ability to create
> derived works if and only if you distribute those derived works. It places
> no restrictions whatsoever on use. And since it requires distributors to
> place no restrictions not in the GPL, distributors cannot place *any*
> restrictions on usage either.
I don't think anyone was talking about use of applications, but rather
use of source code.
Timothy Miller
David Schwartz wrote:
> However, some people seem to be arguing that the GPL_ONLY symbols are in
> fact a license enforcement technique. If that's true, then when they
> distribute their code, they are putting additional restrictions not in the
> GPL on it. That is a GPL violation.
Agreed. GPL_ONLY is not a license restriction. It is a technical issue.
Binary-only modules are inherently untrustworthy (no open code review)
and undebuggable. It is therefore of technical merit to restrict both
what they can access in the kernel (GPL_ONLY) and limit how much kernel
developers should have to tolerate when they're involved.
But beyond this, there are some social issues. If someone finds a way
to work around this mechanism, they are breaking things to everyone
else's detriment. For a commercial entity to violate the GPL_ONLY
barrier is an insult to kernel developers AND to their customers who
will have trouble getting problems solved.
So, if a company works around GPL_ONLY, are they violating the GPL
license? Probably not. Does that make it OKAY? Probably not.
This is like finding a way to give a user space program access to kernel
resources. There are barriers put in place for a REASON because people
make mistakes when they write software. If no one did, we wouldn't have
any need for memory protection, would we.
David Schwartz
> > Licenses that place restrictions on usage are *not* open
> > source licenses.
> What about "usage" of source code?
Same thing.
> GPL says you are not allowed to "use" GPL source in a non-free program
> that you publish.
This is a publication restriction, not a usage restriction. Your phrasing
above is like saying, "you can't put bullets into a gun that you use to
shoot a police officer". The restriction is on the shooting, not the
loading.
Again, quoting the GPL:
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
> I don't think anyone was talking about use of applications, but rather
> use of source code.
I'm not sure why you think this is an important distinction.
DS
Matt D. Robinson
|>David Schwartz wrote:
|>
|>> However, some people seem to be arguing that the GPL_ONLY symbols are in
|>> fact a license enforcement technique. If that's true, then when they
|>> distribute their code, they are putting additional restrictions not in the
|>> GPL on it. That is a GPL violation.
|>
|>Agreed. GPL_ONLY is not a license restriction. It is a technical issue.
|>
|>Binary-only modules are inherently untrustworthy (no open code review)
|>and undebuggable. It is therefore of technical merit to restrict both
|>what they can access in the kernel (GPL_ONLY) and limit how much kernel
|>developers should have to tolerate when they're involved.
|>
|>But beyond this, there are some social issues. If someone finds a way
|>to work around this mechanism, they are breaking things to everyone
|>else's detriment. For a commercial entity to violate the GPL_ONLY
|>barrier is an insult to kernel developers AND to their customers who
|>will have trouble getting problems solved.
I think you are all missing the point. This isn't a Linux kernel
problem. This is a customer and distributor problem. If Red Hat,
Mandrake, SuSE, etc., choose to remove these GPL_ONLY() barriers
and release the new "free" code under GPL, they're entitled. Heck,
they can even add in new ones in their own kernels.
I'm surprised you are even discussing this issue on this list.
If third party developers are restricted based on GPL_ONLY(),
they can either (A) release their product under other OSes or Linux
distributions without the GPL_ONLY() restrictions, (B) modify their
product to be more GPL-friendly, or (C) avoid Linux support entirely.
It ultimately means either more support for third party products with
one distribution over another, which may or may not be financially
beneficial to that distribution, or it means that some Linux
distributors continue to supress supporting new third party devices
that don't believe in the GPL. Either way, it's a distribution
decision based on open-source beliefs and how that balances with
financial benefit (both of which would matter to me as a stockholder).
This really has nothing to do with the Linux kernel code itself.
Very few customers that want third party device support will go to
vger to roll their own kernel -- they'll go to a Linux distributor,
get them to include device support and pay for it (or start with a
Linux distribution and roll their own).
So include GPL_ONLY(), don't include GPL_ONLY(), whatever. If you
don't like it, Mr. Customer, find a Linux distributor that will
fix the problem for you.
If you want to create a new driver model that supports third party
devices without regard to their GPL status, make a patch. Who
knows, maybe some distribution will actually start using it. But
don't even think about bugging this list to get it included by
default (too many GPL purists out there).
--Matt
Alan Cox
> So include GPL_ONLY(), don't include GPL_ONLY(), whatever. If you
> don't like it, Mr. Customer, find a Linux distributor that will
> fix the problem for you.
Linux vendors have already recieved, and decided to act on cease and
desist letters involving adding hooks (ie EXPORT_SYMBOL stuff) for non
free modules that were not in the base distro. I think that speaks for
part of the legal view.
David Schwartz
> On Gwe, 2003-09-12 at 22:47, Matt D. Robinson wrote:
> > So include GPL_ONLY(), don't include GPL_ONLY(), whatever. If you
> > don't like it, Mr. Customer, find a Linux distributor that will
> > fix the problem for you.
> Linux vendors have already recieved, and decided to act on cease and
> desist letters involving adding hooks (ie EXPORT_SYMBOL stuff) for non
> free modules that were not in the base distro. I think that speaks for
> part of the legal view.
Who is sending these letters? Who has no respect for the GPL and seeks to
add additional restrictions? IMO, these letters are almost as bad as the SCO
letters. Nobody has any business putting additional licensing restrictions
on code was placed under the GPL.
DS
jw schultz
>
> > On Gwe, 2003-09-12 at 22:47, Matt D. Robinson wrote:
>
> > > So include GPL_ONLY(), don't include GPL_ONLY(), whatever. If you
> > > don't like it, Mr. Customer, find a Linux distributor that will
> > > fix the problem for you.
>
> > Linux vendors have already recieved, and decided to act on cease and
> > desist letters involving adding hooks (ie EXPORT_SYMBOL stuff) for non
> > free modules that were not in the base distro. I think that speaks for
> > part of the legal view.
>
> Who is sending these letters? Who has no respect for the GPL and seeks to
> add additional restrictions? IMO, these letters are almost as bad as the SCO
> letters. Nobody has any business putting additional licensing restrictions
> on code was placed under the GPL.
I don't know who but i can say that Linus or anyone he
assigns can do so based not on GPL but on trademark. That is
to say that while it wouldn't be a violation of the
copyright license to distribute such modified code but it
would be within the rights of the trademark holder (Linus)
to refuse them the _privilege_ of calling the modified code
Linux. Not only would it be within his rights but it is
necessary for him to define and enforce restrictions on what
may be called Linux or he would lose that authority.
Just like you can make a copy of Red Hat's distribution but
without Red Hat Inc's explicit permission you cannot call it Red
Hat or Maroon Chapeau, etc. For that matter the Open group
could, in theory, deny SCO the privilege of of calling their
own products UNIX.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: j...@pegasys.ws
Remember Cernan and Schmitt
Nicolas Mailhot
[ sorry to interupt your flamewar but the amount of nonsence produced
here starts to irritate me ]
| Who is sending these letters? Who has no respect for the GPL and seeks
| to add additional restrictions?
This is no additional restriction.
Check your history. The linux kernel was always under the GPL, not the
LGPL ie distributing stuff that links with the kernel means this stuff
must be distributed under the gpl.
At some point Linus decreeted linking closed modules was ok with him
(note this was done without consulting anyone, so others contributors
could have objected - they did choose to release stuff under the gpl
after all - but this being Linus they let it pass)
At a later point however the scope of closed linking had grown so big
people started saying enough is enough and GPL-ONLY was born with
Linus's approval.
It is not a licensing change. It's an hint the associated kernel symbols
are not covered by Linus' previous informal exemption and full GPL rules
apply. To avoid rewriting history symbols that could be used in non-free
stuff previously are not GPL-ONLY. People that ignore the hint can and
will be sued (people that link to symbols not GPL-ONLY could be sued too
but everyone seems to have agreed to let it pass). Removing the software
GPL-ONLY checks or working around them has nothing to do with it - it
does not change the basic kernel license nor the stated intentions of
its authors to enforce it. Hiding a do-not-trespass sign does not give
you the right to do it (if you think so do a reality check).
So please stop making horrified noises the GPL is being enforced in a
GPL project. Don't you realise how ridiculous it is ?
--
Nicolas Mailhot
David Schwartz
> "David Schwartz" wrote :
> [ sorry to interupt your flamewar but the amount of nonsence produced
> here starts to irritate me ]
> | Who is sending these letters? Who has no respect for the GPL and seeks
> | to add additional restrictions?
> This is no additional restriction.
> Check your history. The linux kernel was always under the GPL, not the
> LGPL ie distributing stuff that links with the kernel means this stuff
> must be distributed under the gpl.
Yes, *distributing* stuff that links with the kernel means this stuff must
be distributed under the GPL. Note that this is a restriction that only
kicks in when you distribute something. It places no restrictions on how you
can use derived works you don't distribute.
> At some point Linus decreeted linking closed modules was ok with him
> (note this was done without consulting anyone, so others contributors
> could have objected - they did choose to release stuff under the gpl
> after all - but this being Linus they let it pass)
Right.
> At a later point however the scope of closed linking had grown so big
> people started saying enough is enough and GPL-ONLY was born with
> Linus's approval.
Okay.
> It is not a licensing change. It's an hint the associated kernel symbols
> are not covered by Linus' previous informal exemption and full GPL rules
> apply.
Fine, so long as it's not a license enforcement mechanism.
> To avoid rewriting history symbols that could be used in non-free
> stuff previously are not GPL-ONLY. People that ignore the hint can and
> will be sued (people that link to symbols not GPL-ONLY could be sued too
> but everyone seems to have agreed to let it pass).
Sued for what? Violating a restriction that isn't part of the license?
That's no more illegal than removing the security checks on 'mount'.
> Removing the software
> GPL-ONLY checks or working around them has nothing to do with it - it
> does not change the basic kernel license nor the stated intentions of
> its authors to enforce it. Hiding a do-not-trespass sign does not give
> you the right to do it (if you think so do a reality check).
Except that the GPL does not permit any usage restrictions.
> So please stop making horrified noises the GPL is being enforced in a
> GPL project. Don't you realise how ridiculous it is ?
All of the GPL's restrictions kick in upon distribution. The GPL_ONLY
restrictions affect use even in the absence of distribution. Thus, the
GPL_ONLY stuff *cannot* be a license enforcement because what it enforces is
*not* part of the license. Anyone who distributed Linux claiming that it had
such a license restriction would be in violation of the GPL's prohibition
against distribution with additional restrictions. Can you please reply to
that specific argument?
And this is not some whacko obsure legalistic argument. This is a
fundamental point. Many people who contributed to the Linux kernel
contributed *because* they believed in the GPL and felt assured that nobody,
not even Linus, could close the evolving works by putting usage restrictions
on it. You GPL a work because you want to keep not only the current code
open to unrestricted use but all future distributed derived works as well.
Nobody has the right to add new license restrictions beyond those present in
the GPL.
DS
Matt D. Robinson
|>> On Gwe, 2003-09-12 at 22:47, Matt D. Robinson wrote:
|>> > So include GPL_ONLY(), don't include GPL_ONLY(), whatever. If you
|>> > don't like it, Mr. Customer, find a Linux distributor that will
|>> > fix the problem for you.
|>
|>> Linux vendors have already recieved, and decided to act on cease and
|>> desist letters involving adding hooks (ie EXPORT_SYMBOL stuff) for non
|>> free modules that were not in the base distro. I think that speaks for
|>> part of the legal view.
|>
|> Who is sending these letters? Who has no respect for the GPL and seeks to
|>add additional restrictions? IMO, these letters are almost as bad as the SCO
|>letters. Nobody has any business putting additional licensing restrictions
|>on code was placed under the GPL.
|>
|> DS
FUD, Inc. If these really did exist, they would be more commonly
known and I'm certain would affect customer choice. IMHO, I think
this is the vendor's (and I specifically think of Red Hat) way of
excusing themselves from having to work with third party vendors
in order to cover themselves legally with groups like the FSF.
Whether that's true or not, or if there is some other developer
contingent at these distribution houses that is preventing the
EXPORT_SYMBOL{,GPL}() changes due to personal bias, I don't know.
And I doubt we'll ever know.
These letters are like WMD -- they exist, you know they do, but you
just can't find them. :)
--Matt
Geert Uytterhoeven
> David Schwartz wrote:
> about "honor".
Indeed. The GPL may not be perfect, but IMHO the GPL is the only way to make
sure everyone plays the game according to the rules. I.e. I give you something,
you can use it, but please play according to the rules of fair play.
BSD may look OK, but it doesn't protect against people who don't (want to) play
according to the rules.
> The point of divergence is with regard to modules and the symbol
> restrictions for non-GPL drivers. Here is a gray area where the GPL may
> not apply really. These gray areas are where ethics and honor must come
> into play.
I consider binary-only modules some kind of loophole to avoid playing according
to the rules of fair play.
Unfortunately it seems to be almost impossible to design a license that forces
you to play according to the rules of fair play, and doesn't have any
loopholes or grey areas.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Nicolas Mailhot
[...]
> > To avoid rewriting history symbols that could be used in non-free
> > stuff previously are not GPL-ONLY. People that ignore the hint can and
> > will be sued (people that link to symbols not GPL-ONLY could be sued too
> > but everyone seems to have agreed to let it pass).
>
> Sued for what? Violating a restriction that isn't part of the license?
> That's no more illegal than removing the security checks on 'mount'.
Sued for not infringing the software license, in this case the GPL. They
won't be sued for removing GPL_ONLY checks ; they won't even be sued for
using GPL_ONLY symbols. They will be sued for distributing a non-GPLed
derived work when the license forbids it.
A symbol is marked GPL-only :
1. when there is no bloody way it could be used in another work without
it being a derived work
2. when the author of the associated kernel code publicly stated he will
go after you if you do not respect the license.
All the software "workarounds" proposed are only ways to infringe
without getting a big red warning in the face. They do not change the
reality of the infraction per see.
> > Removing the software
> > GPL-ONLY checks or working around them has nothing to do with it - it
> > does not change the basic kernel license nor the stated intentions of
> > its authors to enforce it. Hiding a do-not-trespass sign does not give
> > you the right to do it (if you think so do a reality check).
>
> Except that the GPL does not permit any usage restrictions.
There is no usage restriction - you have the code, you can remove the
checks if you want to. Unlike a license enforcement restriction you
won't be sued just for this.
Now the next step is usually to link a big fat closed module to your
modified kernel. And there you *will* be sued if you distribute the
resulting work (which pisses of some unethical corporations because the
sole way to do it legally is to have the end-user perform the operation,
and the end-user does not want to bother with it. ie its closes them
some markets unless they open up their stuff. Guess what ? You won't
find any people on this list cry for them).
I even suspect if you submit a patch to have GPL-ONLY a kernel build
option it will be accepted (provided it taints the whole kernel
probably). Distributions of course will never ship binaries build
without it, and appliance manufacturers that use it will be submitted to
heavy review, but that's already the case.
--
Nicolas Mailhot
Alan Cox
> At some point Linus decreeted linking closed modules was ok with him
> (note this was done without consulting anyone, so others contributors
> could have objected - they did choose to release stuff under the gpl
> after all - but this being Linus they let it pass)
Other contributors objected at the time. Furthermore there is merging of
third party GPL code from bodies like the FSF who also object and didnt
submit their code themselves.
> will be sued (people that link to symbols not GPL-ONLY could be sued too
> but everyone seems to have agreed to let it pass). Removing the software
No. Sorry its neccessary to keep correcting people here but I have no
intention of allowing anyone creating a derivative work to claim
estoppel when they get their arses kicked some years on. Their sole
defence is that the work is not derivative. In some cases I can believe
that could be a valid claim.
As to _GPL. Its primarily a way of ensuring people who mix binary code
in with their kernel in unsupportable ways are made aware of it, and so
we can all use filter rules to discard their bugs.
Some vendors do support certain third party binary modules in some
specific enterprise configurations, others don't. In the community case
the general rule is we don't.
Alan
Andre Hedrick
On Thu, 11 Sep 2003, Pascal Schmidt wrote:
> On Wed, 10 Sep 2003, David Schwartz wrote:
>
> > Please show me one restriction on *use* in the GPL.
>
> Well, you may not *use* GPL'd code to produce a derived work and
> distribute it in binary form only. Use of the code, not use of
> the product, sure.
Prove an original work which uses the proper "unprotectable API" to
operate in the Linux kernel is a "derived work".
You can't and never will. It is an "original work".
"Original works" are exempt, what is not clear?
Oh I get it, because it happens to work in "Linux" it is not an original
work? What a lame cast of mental giants.
Andre
Alan Cox
> > On Gwe, 2003-09-12 at 22:47, Matt D. Robinson wrote:
> Who is sending these letters? Who has no respect for the GPL and seeks to
> add additional restrictions? IMO, these letters are almost as bad as the SCO
> letters. Nobody has any business putting additional licensing restrictions
> on code was placed under the GPL.
Nobody I've talked to (legal folks included) seems to think they are
additional restrictions, merely people enforcing their copyright rights
against folks working as a group to conspire to create a derivative work
prohibited by the GPL.
Alan Cox
> |>> Linux vendors have already recieved, and decided to act on cease and
> |>> desist letters involving adding hooks (ie EXPORT_SYMBOL stuff) for non
> |>> free modules that were not in the base distro. I think that speaks for
> |>> part of the legal view.
> FUD, Inc. If these really did exist, they would be more commonly
It has happened. If you want to call me a liar feel free. Its your right
in a free society. It doesn't change the facts however.
Adding hooks for a proprietary module is a dubious practice. Doing it as
part of a two way arrangement with a proprietary vendor producing a non
free module is extremely unwise indeed.
Andre Hedrick
On 11 Sep 2003, Eric W. Biederman wrote:
> "David Schwartz" <dav...@webmaster.com> writes:
>
> > The GPL_ONLY stuff is an attempt to restrict use. There is nothing
> > inherently wrong with attempts to restrict use. One could argue that the
> > root permission check on 'umount' is a restriction on use. Surely the GPL
> > doesn't mean you can't have any usage restrictions at all.
>
> No the GPL_ONLY stuff is an attempt to document that there is no conceivable
> way that using a given symbol does not create a derived work.
Bzzit ... GPL_ONLY stuff is an attempt to retrict usage by removing access
to the unprotectable API. And for anyone claiming there is not API to
protect, the kernel source is the manual to the API. The foolish intent
and design to hide the API has caused the kernel itself to become the
manual.
This is even obvious to people, like myself, who are not lawyers.
Andre
Alan Cox
> Unfortunately it seems to be almost impossible to design a license that forces
> you to play according to the rules of fair play, and doesn't have any
> loopholes or grey areas.
Fair play is awfully hard to define. Fair use likewise. Currently almost
all countries legal systems have a clear notion of "derived work", and
copyright (unlike patents) extends no further. That limits how far the
GPL can extend, but its the same line in the sand (well fuzzy patch in
the sand in truth) that stops a lot of other things you wouldnt like.
Which and what modules count as derivative works is a lawyer question
and not it seems a trivial one.
Patents do extend beyond just the derived work and since Linux contains
patented material with rights granted for GPL use as per the GPL(but not
for non GPL use) there is a murky area around modules and patents - one
example of the issues that raises being RTLinux.
Folks using binary modules may also find third party software licenses
invalid (eg the OpenMotif one)
Andre Hedrick
On Thu, 11 Sep 2003, Alan Cox wrote:
> On Iau, 2003-09-11 at 02:35, David Schwartz wrote:
> > The GPL puts no restrictions on use. The GPL_ONLY stuff does.
>
> No it doesn't. It allows people to track whether you get support or not.
> It prevents nothing.
Then allow the usage and functionality of the SYMBOLS and not "steal" them
from usage. If you say thay can be used without support.
PS it is "The Troll" again.
Just execute the reject of the License and have the means to reject
support. You are so full of it to say it is for rejecting support when
anyone knows it removes usage of the SYMBOL == API.
Cheers,
Andre
Andre Hedrick
On Thu, 11 Sep 2003, Mike Fedyk wrote:
> On Thu, Sep 11, 2003 at 11:39:33AM -0700, David Schwartz wrote:
> > The GPL_ONLY stuff does in fact restrict use. However, this is a
> > restriction anyone is free to remove or circumvent if it bothers them. This
> > isn't a dishonorable act because nobody intended this mechanism to restrict
> > use -- I hope.
>
> If effect it does affect use because of lack of support. But personally I
> agree with that...
I disagree that use == support. Whatever happen to RTFM ?
Wait I forgot TFM became GPL_ONLY so you can not read it freely anymore.
Try getting support from RedHat without a support contract, LOL.
Try getting support from XMission for anything without a support contract.
Cheers,
Andre
Andre Hedrick
Timothy,
Who is talking about using "GPL source code", that is a given NO NO!
Calling symbols in the header files used as the generic functionality of
the kernel is all one could use in "Driver Model". Beyond the simple
usage of header files, one is no longer in the land of API but usage of
raw GPL source.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 12 Sep 2003, Timothy Miller wrote:
Andre Hedrick
On Fri, 12 Sep 2003, Timothy Miller wrote:
>
>
> David Schwartz wrote:
>
> > However, some people seem to be arguing that the GPL_ONLY symbols are in
> > fact a license enforcement technique. If that's true, then when they
> > distribute their code, they are putting additional restrictions not in the
> > GPL on it. That is a GPL violation.
>
> Agreed. GPL_ONLY is not a license restriction. It is a technical issue.
Technical if and only if it did not remove the functionality of the
symbol when called.
Since it remove the ability to call and it work, creates a restriction of
usaged. Usage being, one calls the function and it works.
I have not decided yet to expose one of the grossest example of API thieft
yet, but will do so in time.
> Binary-only modules are inherently untrustworthy (no open code review)
> and undebuggable. It is therefore of technical merit to restrict both
> what they can access in the kernel (GPL_ONLY) and limit how much kernel
> developers should have to tolerate when they're involved.
Who cares, it reports a tainted and the community says, thank you have a
nice day.
> But beyond this, there are some social issues. If someone finds a way
> to work around this mechanism, they are breaking things to everyone
> else's detriment. For a commercial entity to violate the GPL_ONLY
> barrier is an insult to kernel developers AND to their customers who
> will have trouble getting problems solved.
So when is the last time a business sent it problems to LKML to be
solved? If I were a customer of such a company, I would be gone.
> So, if a company works around GPL_ONLY, are they violating the GPL
> license? Probably not. Does that make it OKAY? Probably not.
GPL_ONLY violate usage, thus it violate GPL.
Not a hard concept.
Also what if a company produces a "private gpl" product?
Open Source to customers but not to the world?
Nan, nobody would do that silly idea.
> This is like finding a way to give a user space program access to kernel
> resources. There are barriers put in place for a REASON because people
> make mistakes when they write software. If no one did, we wouldn't have
> any need for memory protection, would we.
Stop, the laughing hurts "memory protection" "vm" ...
Cheers,
Andre
Andre Hedrick
SYMBOL in question "dequeue_signal"
*************************************
pwd :: /usr/src/linux-2.4.18-27/kernel/signal.c
/*
* Dequeue a signal and return the element to the caller, which is
* expected to free it.
*
* All callers must be holding current->sigmask_lock.
*/
int
dequeue_signal(sigset_t *mask, siginfo_t *info)
{
int sig = 0;
#if DEBUG_SIG
printk("SIG dequeue (%s:%d): %d ", current->comm, current->pid,
signal_pending(current));
#endif
sig = next_signal(current, mask);
if (sig) {
if (current->notifier) {
if (sigismember(current->notifier_mask, sig)) {
if (!(current->notifier)(current->notifier_data)) {
current->sigpending = 0;
return 0;
}
}
}
if (!collect_signal(sig, ¤t->pending, info))
sig = 0;
/* XXX: Once POSIX.1b timers are in, if si_code == SI_TIMER,
we need to xchg out the timer overrun values. */
}
recalc_sigpending(current);
#if DEBUG_SIG
printk(" %d -> %d\n", signal_pending(current), sig);
#endif
return sig;
}
EXPORT_SYMBOL(dequeue_signal);
EXPORT_SYMBOL(flush_signals);
*************************************
pwd :: /usr/src/linux-2.4.20-18.9/kernel/signal.c
static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
siginfo_t *info)
{
int sig = 0;
sig = next_signal(pending, mask);
if (sig) {
if (current->notifier) {
if (sigismember(current->notifier_mask, sig)) {
if (!(current->notifier)(current->notifier_data)) {
current->sigpending = 0;
return 0;
}
}
}
if (!collect_signal(sig, pending, info))
sig = 0;
/* XXX: Once POSIX.1b timers are in, if si_code == SI_TIMER,
we need to xchg out the timer overrun values. */
}
recalc_sigpending();
return sig;
}
/*
* Dequeue a signal and return the element to the caller, which is
* expected to free it.
*
* All callers have to hold the siglock.
*/
int dequeue_signal(sigset_t *mask, siginfo_t *info)
{
int signr = __dequeue_signal(¤t->pending, mask, info);
if (!signr)
signr = __dequeue_signal(¤t->signal->shared_pending,
mask, info);
return signr;
}
EXPORT_SYMBOL(recalc_sigpending);
EXPORT_SYMBOL_GPL(dequeue_signal);
EXPORT_SYMBOL(flush_signals);
*************************************
Now it is totally clear this is an attempt to strip and remove
functionality of the API, period.
But this is to obvious to miss.
Regards,
Andre Hedrick
LAD Storage Consulting Group
-
Pascal Schmidt
> Prove an original work which uses the proper "unprotectable API" to
> operate in the Linux kernel is a "derived work".
I never claimed such a thing. Whether an API is unprotectable or not
is a question for the lawyers.
If people put GPL_ONLY symbol exports in their code, that's their call
to make, is it not? It's their code and they're free to say "well, this
is my code, and if you use this symbol, I consider your stuff to be a
derived work". Once again it's up to the lawyers to decide whether
this has legal value or not.
--
Ciao,
Pascal
David Schwartz
> If people put GPL_ONLY symbol exports in their code, that's their call
> to make, is it not? It's their code and they're free to say "well, this
> is my code, and if you use this symbol, I consider your stuff to be a
> derived work". Once again it's up to the lawyers to decide whether
> this has legal value or not.
If it has legal value, then it's an additional restriction.
DS
Andre Hedrick
David,
Agreed the total intent by the author is to impose a restriction.
Thus the author by default lost his/her right to use, period.
Ironic, how imposing a usage restriction will terminate ones own write to
use.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Pascal Schmidt
>> If people put GPL_ONLY symbol exports in their code, that's their call
>> to make, is it not? It's their code and they're free to say "well, this
>> is my code, and if you use this symbol, I consider your stuff to be a
>> derived work". Once again it's up to the lawyers to decide whether
>> this has legal value or not.
> If it has legal value, then it's an additional restriction.
Derived works are already restricted (when it comes to distributing them,
otherwise none of this is relevant since you can easily locally make
all EXPORT_SYMBOL_GPL be plain EXPORT_SYMBOL). It would be a restriction
on who gets to say what constitutes a derived work and what not - but
that is not governed by the GPL anyway but by the relevant local laws.
The GPL does not and cannot outrank the law. If the law were to say the
authors of a piece of code get to say what is a derived work and what
not, then so it is and nothing the GPL says can stand against it.
--
Ciao,
Pascal
Alan Cox
>
> > If people put GPL_ONLY symbol exports in their code, that's their call
> > to make, is it not? It's their code and they're free to say "well, this
> > is my code, and if you use this symbol, I consider your stuff to be a
> > derived work". Once again it's up to the lawyers to decide whether
> > this has legal value or not.
>
> If it has legal value, then it's an additional restriction.
If it has legal value in showing the work is derivative thats not an
additional restriction. Its merely showing the intent of the author. If
someone creates a work and its found to be derivative and they didnt
make it GPL compatible they get sued, thats also not an additional
restriction its what the GPL says anyway.
That is the whole point of EXPORT_SYMBOL_GPL, it doesn't enforce
anything and Linus was absolutely specific it should not do the
enforcing. Its a hint and a support filter.
David Schwartz
> On Sad, 2003-09-13 at 22:19, David Schwartz wrote:
> > > If people put GPL_ONLY symbol exports in their code, that's their call
> > > to make, is it not? It's their code and they're free to say
> > > "well, this
> > > is my code, and if you use this symbol, I consider your stuff to be a
> > > derived work". Once again it's up to the lawyers to decide whether
> > > this has legal value or not.
> > If it has legal value, then it's an additional restriction.
> If it has legal value in showing the work is derivative thats not an
> additional restriction.
If the work would not have been restricted without it and is restricted
with it and you can't remove it, it's an additional restriction. If not,
what would an additional restriction be?
> Its merely showing the intent of the author.
The intent of the author has no bearing on whether or not a work is
derived.
> If
> someone creates a work and its found to be derivative and they didnt
> make it GPL compatible they get sued, thats also not an additional
> restriction its what the GPL says anyway.
Show me where the GPL says you have to GPL derived works that you don't
distribute. That restriction is found nowhere in the GPL and if you
attempted to impose such a restriction, it would be an additional one.
> That is the whole point of EXPORT_SYMBOL_GPL, it doesn't enforce
> anything and Linus was absolutely specific it should not do the
> enforcing. Its a hint and a support filter.
If it doesn't enforce anything and isn't a license restriction, then it's
perfectly legal and kosher to remove it.
DS
Andre Hedrick
Alan,
Taking you at face value, as always in the past, how does one parse
between "usage"/"enforcement"?
Can a non-gpl object call, use, and it work "EXPORT_SYMBOL_GPL"?
If EXPORT_SYMBOL_GPL allows functionality, then it does not "enforce" any
license issues. If it is called and then allowed to quietly fail or not
function unless the caller's associated LICENSE is "GPL", then it does
enforce, restrict and prevents 'functional' usage.
If this is a "NEW SYMBOL" one may have an arguement to hold.
If it is an "OLD SYMBOL", or the old one is removed and replaced with an
random new one, yet the core functionality of the operations are the same,
the intent is to break or terminate usage.
If EXPORT_SYMBOL_GPL is to be a notifier to let end-user be aware that a
binary vendor may be operating in a grey region of "derived" work, fine.
Allow it to operate but make noise.
Pretend it is doing the NOVELL thing of exceeding license count, and make
noise.
It is all to simple to bypass, and if the TAINTING issues for detection
is truly only to ignore issues from non-gpl sourced drivers, then great.
I know you have killfiled me by now, but how goes business school for the
MBA? Does this mean you are going to quit Linux?
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick
more examples of SYMBOL rip offs.
2.6.0-test5
./kernel/exit.c
static inline void __exit_fs(struct task_struct *tsk)
{
struct fs_struct * fs = tsk->fs;
if (fs) {
task_lock(tsk);
tsk->fs = NULL;
task_unlock(tsk);
__put_fs_struct(fs);
}
}
void exit_fs(struct task_struct *tsk)
{
__exit_fs(tsk);
}
./kernel/fork.c
static inline struct fs_struct *__copy_fs_struct(struct fs_struct *old)
{
struct fs_struct *fs = kmem_cache_alloc(fs_cachep, GFP_KERNEL);
/* We don't need to lock fs - think why ;-) */
if (fs) {
atomic_set(&fs->count, 1);
fs->lock = RW_LOCK_UNLOCKED;
fs->umask = old->umask;
read_lock(&old->lock);
fs->rootmnt = mntget(old->rootmnt);
fs->root = dget(old->root);
fs->pwdmnt = mntget(old->pwdmnt);
fs->pwd = dget(old->pwd);
if (old->altroot) {
fs->altrootmnt = mntget(old->altrootmnt);
fs->altroot = dget(old->altroot);
} else {
fs->altrootmnt = NULL;
fs->altroot = NULL;
}
read_unlock(&old->lock);
}
return fs;
}
struct fs_struct *copy_fs_struct(struct fs_struct *old)
{
return __copy_fs_struct(old);
}
EXPORT_SYMBOL_GPL(exit_fs);
EXPORT_SYMBOL_GPL(copy_fs_struct);
This is what the issue is about!
Taking away the functionality of the API.
So much for choice anymore.
Erik Andersen
> Try getting support from XMission for anything without a support contract.
News flash, This just in! XMission is an ISP and Eric Biederman
does not work for them
http://www.xmission.com/
Eric Biederman, myself, and pretty much anybody around here that
wants a decent always-up internet connection run by folks with a
clue uses them. They do not sell "support contracts". As with
any company, they support their customers and nobody else. And
their support is excellent. Want to learn to install Linux?
They'll even show you how http://www.xmission.com/lif3/index.html
If you expect companies to support non-customers I have some fine
ocean-front property in New Mexico to sell you.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Andrew Pimlott
> If the work would not have been restricted without it and is restricted
> with it and you can't remove it, it's an additional restriction. If not,
> what would an additional restriction be?
You can remove it. But if you remove for with the obvious purpose
of abetting the distribution of non-GPL derived work, don't be
surprised to get smacked by courts who don't care for your technical
sophistry.
> > Its merely showing the intent of the author.
>
> The intent of the author has no bearing on whether or not a work is
> derived.
I've noticed it's become common to say this, but (NAL) I doubt it's
true. I would expect a court to respect the author's intent within
some narrow range that would otherwise be ambiguous. Intent and
community standards play a large role in law. If enough people wear
a path across private property, it can become an easement.
Andrew
Erik Andersen
>
>
> David Schwartz wrote:
>
> > However, some people seem to be arguing that the GPL_ONLY symbols
> > are in
> >fact a license enforcement technique. If that's true, then when they
> >distribute their code, they are putting additional restrictions not in the
> >GPL on it. That is a GPL violation.
>
> Agreed. GPL_ONLY is not a license restriction. It is a technical issue.
I'll go even farther, and say that one might call the GPL_ONLY
symbols an "effective technological measure" that "effectively
controls access to a work" and "effectively protects a right of a
copyright owner ... in the ordinary course of its operation....".
Bypassing GPL_ONLY symbols, as recently advocated by David
Schwartz and Andre Hedrick, could be considered circumvention of
an effective technological measure. Remember Dmitry Sklyarov,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Andre Hedrick
Please Erik,
Go have your "DADDY" write another legal letter for you and send it my
way. I will be happy to shove it down your pie hole.
There is a difference in blanket theift of the kernel API and any court
will point out that "fair usage" is proper.
PS how is your IRS media forensics gig going now that you do not have me
on your side to help you do the dirty work of sneaking around people's
hard drives. I was smart enough to never teach you what I knew you could
never learn.
Later!
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick
Erik:
One more thing you forgot!
Before you run around ranting about DMCA and CPRM and making suttle legal
threats. Everyone here knows who put it on the line to gain control of
technology to prevent Content Protection Recordable Media from covering
the storage industry wide. That is correct it was me. I was the one and
only person ever to stand up and have a position to help everyone here to
take control of technology. While all of my hard work was destroyed by
the brain-dead of the EFF by causing it to go underground.
So lets be real clear about your wild swings of DMCA, because the irony
will be back to haunt. Threaten to strike me down with DMCA, what a child
you have become.
So this is where it goes ... Mighty Linux kills usage for business with
lawsuits like the MPAA and RIAA.
GPL == DMCA, this is the brush you swing paint well dude.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Sat, 13 Sep 2003, Erik Andersen wrote:
Andre Hedrick
On Sat, 13 Sep 2003, Erik Andersen wrote:
> On Fri Sep 12, 2003 at 04:58:03PM -0400, Timothy Miller wrote:
> >
> >
> > David Schwartz wrote:
> >
> > > However, some people seem to be arguing that the GPL_ONLY symbols
> > > are in
> > >fact a license enforcement technique. If that's true, then when they
> > >distribute their code, they are putting additional restrictions not in the
> > >GPL on it. That is a GPL violation.
> >
> > Agreed. GPL_ONLY is not a license restriction. It is a technical issue.
>
> I'll go even farther, and say that one might call the GPL_ONLY
> symbols an "effective technological measure" that "effectively
> controls access to a work" and "effectively protects a right of a
> copyright owner ... in the ordinary course of its operation....".
> Bypassing GPL_ONLY symbols, as recently advocated by David
> Schwartz and Andre Hedrick, could be considered circumvention of
> an effective technological measure. Remember Dmitry Sklyarov,
>
> -Erik
Erik:
Dmitry Sklyarov was put in jail for DMCA.
Erik Anderson joins The Village People to sing "D M C A".
So "The Great 'Erik Anderson'" now threatens former opensource developer
with baiting tactics of GPL == DMCA. This is beautiful.
Richard, I know you will enjoy this one. People are thinking of
enforcing GPL via DMCA. Basically killing the idea that people have the
freedom of choice when it comes to software. Maybe Eben Moglen would like
to comment on this twisted idea of Mr. Erik Anderson.
I really don't care but this is to funny to pass up such a threat in a
public forum.
Cheer,
Andre Hedrick
LAD Storage Consulting Group
PS mental note, it takes two idiots to have a flame war, when am I going
quit being the second idiot, sigh.
Erik Andersen
>
> Please Erik,
>
> Go have your "DADDY" write another legal letter for you and send it my
> way. I will be happy to shove it down your pie hole.
Your intellect is truly dizzying. I am left stunned by your
carefully reasoned arguments.
> There is a difference in blanket theift of the kernel API and any court
> will point out that "fair usage" is proper.
"fair usage" != "derivitive works" as any court will point out.
Andre Hedrick
On Sat, 13 Sep 2003, Erik Andersen wrote:
> On Sat Sep 13, 2003 at 07:40:52PM -0700, Andre Hedrick wrote:
> >
> > Please Erik,
> >
> > Go have your "DADDY" write another legal letter for you and send it my
> > way. I will be happy to shove it down your pie hole.
>
> Your intellect is truly dizzying. I am left stunned by your
> carefully reasoned arguments.
>
> > There is a difference in blanket theift of the kernel API and any court
> > will point out that "fair usage" is proper.
>
> "fair usage" != "derivitive works" as any court will point out.
>
> -Erik
Wow ... Does "Original Work" have meaning?
Does an "Original Work" using only the standard kernel API headers to
interface mean it is a derived work? You better go find a new lawyer.
"fair usage" of .h files as the API is standard.
Using any .c or kernel C code is a NO NO.
Later.
Andre Hedrick
LAD Storage Consulting Group
Erik Andersen
> Wow ... Does "Original Work" have meaning?
>
> Does an "Original Work" using only the standard kernel API headers to
> interface mean it is a derived work? You better go find a new lawyer.
You seem to be somewhat confused as to who needs a lawyer. I'm
not the one asking this question. I am also not the one trying
to make a closed source binary only product that runs within the
context of the Linux kernel, and then complaining that the GPL
wackos are ruining my business... It seems to be that doing such
a thing would be a really stupid business model.
As I recall it is the One True(tm) iSCSI stack you are working
on, right?
> "fair usage" of .h files as the API is standard.
>
> Using any .c or kernel C code is a NO NO.
I invite you to read the COPYING file included in each and every
kernel tarball. There is exactly ONE exception granted in the
linux kernel copyright:
This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered
normal use of the kernel, and does *not* fall under the
heading of "derived work".
All the noise in the world about other exceptions is precisely
that, since the license granting use of the Linux kernel does
not contain any additional provisions.
Anything that can be identified as a "user program" that "use[s]
kernel services by normal system calls" is, by virtue of the above
license grant, doing so with permission and is therefore within
its rights. So you can make all the closed source user space
only One True(tm) iSCSI stacks you want.
Anything that is not a "user program" (and I think everyone can
agree a kernel module is not a "user program") is therefore a
derivitive work.
Anything that is linked into the kernel (and I think everyone can
agree a kernel module is linked into the kernel) and is therefore
interfacing with kernel internals, rather than using "kernel
services by normal system calls" is therefore a derivitive work.
Laugh at people, mock people, rant, rave, wantever you want.
When you are done making noise, please have your laywer explain
how a closed source binary only product that runs within the
context of the Linux kernel is not a derivitive work, per the
very definition given in the kernel COPYING file that grants you
your limited rights for copying, distribution and modification,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
walt
> Erik:
>
> One more thing you forgot!
>
> Before you run around ranting about DMCA and CPRM and making suttle legal
> threats. Everyone here knows who put it on the line to gain control of
> technology to prevent Content Protection Recordable Media from covering
Hi Andre,
I'm not a technical person but I've been following the linux-kernel list
for enough years to know who you are and approximately what you have
contributed to the open-source community. Let me start by saying THANK
YOU! I very much appreciate what you do for all of us.
I would like to help you in return, if I can.
I have tried my best for several years to understand your posts and I
simply cannot. I want to understand you because I know you know you
have a great deal to offer -- but I just don't know what the fuck you
are talking about most of the time, no matter how many times I read
your posts.
Please don't be insulted, I beg you. I don't mean to criticize in any
way, but I see that you need help with communication skills. Many of
your posts in this mailing list probably are ignored simply because
very few people understand what you are trying to say.
I'm a married man so I understand how frustrating it is to have every
word misinterpreted. But such frustration should not be necessary in
a technical forum like this one. Anyone who can talk to a disk should
be able to talk to this crowd, but I think you need a wrapper for the
PMLI (Programmer Mailing List Interface).
I can't help feeling that a lot of your frustration is caused by
miscommunciation rather than real issues.
I hate to see you so frustrated and upset when your coronaries are at
risk! Take your heart medication and hire a translator....please!
We are depending on you to be around for many more years.
Andre Hedrick
Pretty Boy,
It is coming and the intent is to return all the stolen symbols.
It is free for anyone to use and enjoy the usage of Linux once again.
So everyone get in line and SUE ME for GPL'ed drivers.
/*
* Original copyright notice:
*
* linux/kernel/freed_symbols.c
*
* Copyright (C) 2001-2003 Linux ATA Development
* Andre Hedrick <an...@linux-ide.org>
*
* GPL v2 and only version 2.
*/
/*
* kernel/signal.c:EXPORT_SYMBOL_GPL(dequeue_signal);
* returned to kernel API
*/
int freed_dequeue_signal(sigset_t *mask, siginfo_t *info)
{
return dequeue_signal(mask, info);
}
EXPORT_SYMBOL(freed_dequeue_signal);
/*
* was kernel/context.c
*
* kernel/workqueue.c:EXPORT_SYMBOL_GPL(create_workqueue);
* kernel/workqueue.c:EXPORT_SYMBOL_GPL(queue_work);
* kernel/workqueue.c:EXPORT_SYMBOL_GPL(queue_delayed_work);
* kernel/workqueue.c:EXPORT_SYMBOL_GPL(flush_workqueue);
* kernel/workqueue.c:EXPORT_SYMBOL_GPL(destroy_workqueue);
* returned to kernel API
*/
struct workqueue_struct *freed_create_workqueue(const char *name)
{
return create_workqueue(name);
}
int freed_queue_work(struct workqueue_struct *wq, struct work_struct *work)
{
return queue_work(wq, work);
}
int freed_queue_delayed_work(struct workqueue_struct *wq,
struct work_struct *work, unsigned long delay)
{
return queue_delayed_work(wq, work, delay);
}
void freed_flush_workqueue(struct workqueue_struct *wq)
{
flush_workqueue(wq);
}
void freed_destroy_workqueue(struct workqueue_struct *wq)
{
destroy_workqueue(wq);
}
EXPORT_SYMBOL(freed_create_workqueue);
EXPORT_SYMBOL(freed_queue_work);
EXPORT_SYMBOL(freed_queue_delayed_work);
EXPORT_SYMBOL(freed_flush_workqueue);
EXPORT_SYMBOL(freed_destroy_workqueue);
static int freed_symbols_ioctl (struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
switch (cmd) {
default:
return -EINVAL;
}
return 0;
}
static int freed_symbols_open (struct inode *inode, struct file *file)
{
return 0;
}
static int freed_symbols_release (struct inode *inode, struct file *file)
{
return 0;
}
static struct file_operations freed_symbols_fops = {
owner: THIS_MODULE,
ioctl: freed_symbols_ioctl,
open: freed_symbols_open,
release: freed_symbols_release,
};
static struct miscdevice freed_symbols_dev = { FREED_SYMBOLS_MINOR,
"freed_symbols",
&freed_symbols_fops };
static void __exit freed_symbols_exit (void)
{
printk(KERN_INFO "freed_symbols_module: unloaded.\n");
// remove_proc_entry("driver/freed_symbols", NULL);
misc_deregister(&freed_symbols);
}
int __init freed_symbols_init (void)
{
printk(KERN_INFO "freed_symbols_module: loaded.\n");
misc_register(&freed_symbols_dev);
// create_proc_read_entry("driver/freed_symbols", 0, 0, freed_symbols_read_proc, NULL);
return 0;
}
MODULE_LICENSE("GPL");
module_init(freed_symbols_init);
module_exit(freed_symbols_exit);
-------------------------------------------
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Erik Andersen
>
> Pretty Boy,
>
> It is coming and the intent is to return all the stolen symbols.
> It is free for anyone to use and enjoy the usage of Linux once again.
> So everyone get in line and SUE ME for GPL'ed drivers.
Do whatever you want. Its your life. Laugh at people, mock
people, rant, rave, violtate licenses, wantever you want.
When you are done making noise, please explain how a closed
source binary only product that runs within the context of the
Linux kernel is not a derivitive work, per the very definition
given in the kernel COPYING file that grants you your limited
rights for copying, distribution and modification,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Andre Hedrick
Erik,
Explain how a symbol in 2.4 which was EXPORT_SYMBOL is now
EXPORT_SYMBOL_GPL in 2.6 ?
When you can explain why the API for functionallity in 2.4 is ripped off
like an old lady's purse by a two-bit punk and made nojn-functional in 2.6
you may have a point.
But, you know what, I don't give a damn (DGD).
It is wrong and the original intent when it was discussed was for "NEW
SYMBOLS ONLY". But if distros can add in Symbols for code that does not
exist in the tree, why can't people change them?
But you have a nice day, and do you need a mail address for that letter
you want to send me? Please make it on heavy stock, you need some fiber
in your diet.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Erik Andersen
>
> Erik,
>
> Explain how a symbol in 2.4 which was EXPORT_SYMBOL is now
> EXPORT_SYMBOL_GPL in 2.6 ?
>
> When you can explain why the API for functionallity in 2.4 is ripped off
> like an old lady's purse by a two-bit punk and made nojn-functional in 2.6
> you may have a point.
It doesn't matter what the symbol is called. I personally agree
with you on this one point -- changing the symbols to use
EXPORT_SYMBOL_GPL type naming is deeply stupid.
I think it is stupid because by implication, it suggests that any
exported symbols lacking such tags are somehow NOT under the GPL.
Per the COPYING file included with each and every copy of the
kernel, Linux is licensed under the GPL. There are no provisions
in the linux kernel COPYING statement allowing non-GPL compatible
binary only closed source kernel modules.
You are therefore, entitled to abide by the precise terms and
conditions for copying, distribution and modification for the
Linux kernel. This entitles you to change symbol names to
whatever makes you feel happy.
But you are also _required_ to abide by the precise terms and
conditions for copying, distribution and modification for the
Linux kernel, which stipulates that unless your code is a "user
[program] that [uses] kernel services by normal system calls", it
is a derived work and therefore must abide by the terms of the
GPL.
Creating and loading such a symbol renaming module is certainly
something you are entitled to do. Using that module for
circumvention of an "effective technological measure" that
"effectively protects a right of a copyright owner ... in the
ordinary course of its operation...." could certainly open you to
legal action here in the USA. I do not hold copyright on any of
the symbols in question, but someone does, and if they do not take
kindly to your circumvention device....
But the DMCA issues are merely an aside to the fundamental
problem. A problem you have avoided in this thread with
gratuitous ad hominem attacks, with the "but Billy did it
first" defence, and similar nonsence.
When you are done making noise, please explain how a closed
source binary only product that runs within the context of the
Linux kernel is not a derivitive work, per the very definition
given in the kernel COPYING file that grants you your limited
rights for copying, distribution and modification.
Andre Hedrick
Erik,
When you can answer why binary only modules are allowed to load regardless
of symbol usage, I will answer your question. Since binary only modules
are allowed to load, this means they are intended to function. If they
are intended to function, they must use the API for standard operations.
Removing the abilty for standard functionality means one does not want
them to function? So if the kernel GPL-ONLY wonder blunders are thinking,
why let them load at all?
Clearly there is a "tainting" process?
If one can detect taint, one can reject loading.
If one reads ./include/linux/module.h
It clearly states any license is acceptable.
So when you can explain about "yes you can but not here", I will explain
the simple rules of how copyright and header files are to be used.
Now what does this have to do with a "freed_symbols" project?
Simple, it restores the symbols back to their original state before
everybody had a whining feast. When they are restored back to original
state then simple usage of the headers compliance to the "unprotectable
interface" is normalized. Go look up 1991 copyright rulings wrt SEGA.
It is all or nothing but both ways is not allowed, what do you think, we
all live in San Francisco?
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick
> On Sat Sep 13, 2003 at 10:32:38PM -0700, Andre Hedrick wrote:
> >
> > Erik,
> >
> > Explain how a symbol in 2.4 which was EXPORT_SYMBOL is now
> > EXPORT_SYMBOL_GPL in 2.6 ?
> >
> > When you can explain why the API for functionallity in 2.4 is ripped off
> > like an old lady's purse by a two-bit punk and made nojn-functional in 2.6
> > you may have a point.
>
> It doesn't matter what the symbol is called. I personally agree
> with you on this one point -- changing the symbols to use
> EXPORT_SYMBOL_GPL type naming is deeply stupid.
>
> I think it is stupid because by implication, it suggests that any
> exported symbols lacking such tags are somehow NOT under the GPL.
>
> Per the COPYING file included with each and every copy of the
> kernel, Linux is licensed under the GPL. There are no provisions
> in the linux kernel COPYING statement allowing non-GPL compatible
> binary only closed source kernel modules.
See above, remove the EXPORT_SYMBOL_GPL crap and then there is no need to
alter or change anything. This restores the original API.
> You are therefore, entitled to abide by the precise terms and
> conditions for copying, distribution and modification for the
> Linux kernel. This entitles you to change symbol names to
> whatever makes you feel happy.
>
> But you are also _required_ to abide by the precise terms and
> conditions for copying, distribution and modification for the
> Linux kernel, which stipulates that unless your code is a "user
> [program] that [uses] kernel services by normal system calls", it
> is a derived work and therefore must abide by the terms of the
> GPL.
Nice, but "derived work" is bogus and we all know it.
> Creating and loading such a symbol renaming module is certainly
> something you are entitled to do. Using that module for
> circumvention of an "effective technological measure" that
> "effectively protects a right of a copyright owner ... in the
> ordinary course of its operation...." could certainly open you to
> legal action here in the USA. I do not hold copyright on any of
> the symbols in question, but someone does, and if they do not take
> kindly to your circumvention device....
See above, which you agree is stupid, make EXPORT_SYMBOL_GPL go away and
nobody has to deal with API issues.
> But the DMCA issues are merely an aside to the fundamental
> problem. A problem you have avoided in this thread with
> gratuitous ad hominem attacks, with the "but Billy did it
> first" defence, and similar nonsence.
Nope, you made threats.
> When you are done making noise, please explain how a closed
> source binary only product that runs within the context of the
> Linux kernel is not a derivitive work, per the very definition
> given in the kernel COPYING file that grants you your limited
> rights for copying, distribution and modification.
See above again, nobody has to do anything if the API is restored to it
original format. Thus no changes, no modifications. All of your points
are void.
Cheers,
Andre
Erik Andersen
> > When you are done making noise, please explain how a closed
> > source binary only product that runs within the context of the
> > Linux kernel is not a derivitive work, per the very definition
> > given in the kernel COPYING file that grants you your limited
> > rights for copying, distribution and modification.
>
> See above again, nobody has to do anything if the API is restored to it
> original format. Thus no changes, no modifications. All of your points
> are void.
Truly a dizzying intellect! All my points are void and it is ok
to load binary only modules in the Linux kernel without releasing
source for the derivitive work. And the reason why it is ok to
thus violate the Linux kernel licence is because....
Oh, I guess you forgot the part where you explain why this is
legal. Sorry, but The Great Andre has Spoken isn't good enough.
Sorry, I'm not going to ignore the man behind the curtain.
When you are done making noise, please explain how a closed
source binary only product that runs within the context of the
Linux kernel is not a derivitive work and therefore not subject
to the terms of the GPL, per the definition given in the kernel
COPYING file that grants you your limited rights for copying,
distribution and modification.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Valdis.K...@vt.edu
> Nope, you made threats.
On Sat, 13 Sep 2003, Erik Andersen wrote:
> I'll go even farther, and say that one might call the GPL_ONLY
> symbols an "effective technological measure" that "effectively
> controls access to a work" and "effectively protects a right of a
to which you replied:
On Sat, 13 Sep 2003 19:40:52 -0700, Andre Hedrick said:
> Go have your "DADDY" write another legal letter for you and send it my
> way. I will be happy to shove it down your pie hole.
Erik postulates a "one MIGHT" legal argument, and gets threatened with bodily
harm? I think you've given up any moral high ground regarding threats.
You may want to just take a few days off - you're apparently not attached to
the same reality as the rest of us:
> If one reads ./include/linux/module.h
>
> It clearly states any license is acceptable.
Maybe if you apply the Bible Code to it, it's clearly stated, but all I see is
a reference that the MODULE_LICENSE macro will accept a parameter of
"Proprietary", and then goes on to say "it's there so the module in question
can be treated properly - just like a Jew in Warsaw in 1941 had to wear a star".
There. I said it. The esteemed Mr Godwin says we're now free to get on with our lives.
Pascal Schmidt
> If one reads ./include/linux/module.h
> It clearly states any license is acceptable.
The problem is that the kernel has many copyright holders for different
parts of the code, so what the author of module.h wrote can well be
his own opinion but not that of others. Also, if modules are derived
works under the terms of the GPL, the header file cannot change that
fact, no matter what is says exactly.
Once again, it's all up to the lawyers to decide.
--
Ciao,
Pascal