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.
Ye
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 a
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 conf
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 non
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
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, y
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
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 ru
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 combin
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 wi
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 s
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 on
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 ta
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 he
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
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 head
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 i
[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 con
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
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. Pleas
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 "uns
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 multi
25 matches
Mail list logo
