On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
> Non GPL modules are required not to be derivative works (a term of law).
> The EXPORT_SYMBOL information is merely advisory to help seperate
> symbols. In many cases its purely historical as to whether a symbol is
> marked _GPL or not.
On Sad, 2005-09-03 at 23:26 +0200, Bernd Eckenfels wrote:
> Loading a non-GPL (tagged) module leads in tainting the kernel (which
> basically
> is a flag for developers to be alerted while debugging), is that right?
Correct, although some administrators find it useful too
> Non GPL Modules are
On Sad, 2005-09-03 at 23:26 +0200, Bernd Eckenfels wrote:
Loading a non-GPL (tagged) module leads in tainting the kernel (which
basically
is a flag for developers to be alerted while debugging), is that right?
Correct, although some administrators find it useful too
Non GPL Modules are also
On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
Non GPL modules are required not to be derivative works (a term of law).
The EXPORT_SYMBOL information is merely advisory to help seperate
symbols. In many cases its purely historical as to whether a symbol is
marked _GPL or not.
Yes,
In article <[EMAIL PROTECTED]> you wrote:
>> The Linux kernel allows binary drivers, you just have to live with a limited
>> number of exported symbols and that the kernel is tainted. Which basically
>> means nobody sane can help you with corrupted kernel data structures.
>
> You appear to be
In article [EMAIL PROTECTED] you wrote:
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is tainted. Which basically
means nobody sane can help you with corrupted kernel data structures.
You appear to be confused. The
On Wednesday 31 August 2005 22:49, Jose Luis Domingo Lopez wrote:
> On Wednesday, 31 August 2005, at 11:27:41 -0600,
>
> Jeff V. Merkey wrote:
> > I am very open to discussions of this. Please go ahead and argue the
> > merits of GPL vs. proprietary code. DSFS is platform
> > neutral and will also
On Iau, 2005-09-01 at 09:45 +0200, Vojtech Pavlik wrote:
> I believe the use of the word is quite correct.
Ditto. The term is used for all kinds of marking in software and in the
kernel case comes well after its use for things like perl unsafe
variables. It is also used for far more than just
On Iau, 2005-09-01 at 02:33 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I mean, nvidia people also use propietary code in the kernel (probably
> > violating the GPL anyway) and don't do such things.
>
> The Linux kernel allows binary drivers, you just have to
On Wed, 2005-08-31 at 18:56 -0600, jmerkey wrote:
> Bernd Eckenfels wrote:
> >In article <[EMAIL PROTECTED]> you wrote:
> >>I mean, nvidia people also use propietary code in the kernel (probably
> >>violating the GPL anyway) and don't do such things.
> >
> >The Linux kernel allows binary drivers,
On Wed, Aug 31, 2005 at 06:56:28PM -0600, jmerkey wrote:
> Bernd,
>
> Thanks for the accurate and reasonable response. I object to the use
> of the word "tainted". This implies the binary code is somehow
> infringing. I would suggest changing the word to "non-GPL" or "Vendor
> Supported"
jmerkey wrote:
It might be helpful for someone to look at these sections of code I
had to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range > 200MB/S combined disk
and lan
throughput. This was
jmerkey wrote:
It might be helpful for someone to look at these sections of code I
had to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range 200MB/S combined disk
and lan
throughput. This was
On Wed, Aug 31, 2005 at 06:56:28PM -0600, jmerkey wrote:
Bernd,
Thanks for the accurate and reasonable response. I object to the use
of the word tainted. This implies the binary code is somehow
infringing. I would suggest changing the word to non-GPL or Vendor
Supported since this is
On Wed, 2005-08-31 at 18:56 -0600, jmerkey wrote:
Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have
On Iau, 2005-09-01 at 02:33 +0200, Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a
On Iau, 2005-09-01 at 09:45 +0200, Vojtech Pavlik wrote:
I believe the use of the word is quite correct.
Ditto. The term is used for all kinds of marking in software and in the
kernel case comes well after its use for things like perl unsafe
variables. It is also used for far more than just
On Wednesday 31 August 2005 22:49, Jose Luis Domingo Lopez wrote:
On Wednesday, 31 August 2005, at 11:27:41 -0600,
Jeff V. Merkey wrote:
I am very open to discussions of this. Please go ahead and argue the
merits of GPL vs. proprietary code. DSFS is platform
neutral and will also run on
2005/9/1, jmerkey <[EMAIL PROTECTED]>:
> Bernd,
>
> It might be helpful for someone to look at these sections of code I had
> to patch in 2.6.9.
> I discovered a case where the kernel scheduler will pass NULL for the
> array argument
> when I started hitting the extreme upper range > 200MB/S
Bernd,
It might be helpful for someone to look at these sections of code I had
to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range > 200MB/S combined disk
and lan
throughput. This was running
Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported
In article <[EMAIL PROTECTED]> you wrote:
> I disagree with the language and the characterization that our
> proprietary user application code is "tainted."
The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary
In article <[EMAIL PROTECTED]> you wrote:
> I mean, nvidia people also use propietary code in the kernel (probably
> violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is
Diego Calleja wrote:
El Wed, 31 Aug 2005 14:27:47 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> escribió:
NOTE! 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
El Wed, 31 Aug 2005 14:27:47 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> escribió:
>
> NOTE! 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
On Wednesday, 31 August 2005, at 11:27:41 -0600,
Jeff V. Merkey wrote:
> I am very open to discussions of this. Please go ahead and argue the
> merits of GPL vs. proprietary code. DSFS is platform
> neutral and will also run on Windows XP/2000/2003/Longhorn and Free BSD.
> It uses no kernel
NOTE! 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".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the
[EMAIL PROTECTED] wrote:
On Wed, 31 Aug 2005 12:00:45 MDT, "Jeff V. Merkey" said:
There's also a more fundamental problem with the GPL language. The GPL stated
it
confers "RIGHT TO COPY". This is not the same as "RIGHT TO GRANT
LICENSES TO DISTRIBUTE." Under US copyright law, if you
On Wed, 31 Aug 2005 12:00:45 MDT, "Jeff V. Merkey" said:
> There's also a more fundamental problem with the GPL language. The GPL
> stated it
> confers "RIGHT TO COPY". This is not the same as "RIGHT TO GRANT
> LICENSES TO DISTRIBUTE." Under US copyright law, if you confer to any person
>
Arjan van de Ven wrote:
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does
> The GPL terms that require GPL conversion of any code that runs on Linux
> is not supported by US Law. Many would
> disagree, but that's OK. In short, it's just like any other proprietary
> app running on Linux. If it uses no Linux code (which
> it does not), then the GPL does not apply to it
Rik van Riel wrote:
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
I am very open to discussions of this.
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
> The Core File System code is a separate proprietary module and is not
> released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
--
All Rights Reversed
-
To unsubscribe from this list: send the line
The Solera Networks DS File System kernel patches have been posted at
ftp.soleranetworks.com
and can be downloaded via anonymous ftp access.
These patches are for the 2.4.29, and 2.6.9 kernels. These patches
includes all kernel changes
made to the Linux kernel and GPL code that allows
The Solera Networks DS File System kernel patches have been posted at
ftp.soleranetworks.com
and can be downloaded via anonymous ftp access.
These patches are for the 2.4.29, and 2.6.9 kernels. These patches
includes all kernel changes
made to the Linux kernel and GPL code that allows
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
--
All Rights Reversed
-
To unsubscribe from this list: send the line
Rik van Riel wrote:
On Wed, 31 Aug 2005, Jeff V. Merkey wrote:
The Core File System code is a separate proprietary module and is not
released under the GPL
Are you going to post an analysis on the legality of this
on merkeylaw.com ? ;)
I am very open to discussions of this.
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does not apply to it .
Arjan van de Ven wrote:
The GPL terms that require GPL conversion of any code that runs on Linux
is not supported by US Law. Many would
disagree, but that's OK. In short, it's just like any other proprietary
app running on Linux. If it uses no Linux code (which
it does not), then the GPL does
On Wed, 31 Aug 2005 12:00:45 MDT, Jeff V. Merkey said:
There's also a more fundamental problem with the GPL language. The GPL
stated it
confers RIGHT TO COPY. This is not the same as RIGHT TO GRANT
LICENSES TO DISTRIBUTE. Under US copyright law, if you confer to any person
the right to
[EMAIL PROTECTED] wrote:
On Wed, 31 Aug 2005 12:00:45 MDT, Jeff V. Merkey said:
There's also a more fundamental problem with the GPL language. The GPL stated
it
confers RIGHT TO COPY. This is not the same as RIGHT TO GRANT
LICENSES TO DISTRIBUTE. Under US copyright law, if you confer
NOTE! 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.
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the
On Wednesday, 31 August 2005, at 11:27:41 -0600,
Jeff V. Merkey wrote:
I am very open to discussions of this. Please go ahead and argue the
merits of GPL vs. proprietary code. DSFS is platform
neutral and will also run on Windows XP/2000/2003/Longhorn and Free BSD.
It uses no kernel headers
El Wed, 31 Aug 2005 14:27:47 -0600,
Jeff V. Merkey [EMAIL PROTECTED] escribió:
NOTE! 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.
Diego Calleja wrote:
El Wed, 31 Aug 2005 14:27:47 -0600,
Jeff V. Merkey [EMAIL PROTECTED] escribió:
NOTE! 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
In article [EMAIL PROTECTED] you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is
In article [EMAIL PROTECTED] you wrote:
I disagree with the language and the characterization that our
proprietary user application code is tainted.
The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary only
Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported
Bernd,
It might be helpful for someone to look at these sections of code I had
to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range 200MB/S combined disk
and lan
throughput. This was running
2005/9/1, jmerkey [EMAIL PROTECTED]:
Bernd,
It might be helpful for someone to look at these sections of code I had
to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range 200MB/S combined disk
50 matches
Mail list logo
