Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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, I agree, I was just not talking about licensing/legal issues, but only about the visible technical reasons and restrictions. So I dont think I am confused... thanks for follow up, Alan. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. )[EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+49721151516129 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 restrited in the number of symbols they can use, > this is to make it harder to derive work from the Linux Kernel with a ABI > interface. 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. If a work is derivative of another GPL work by any means then the GPL applies to it. If it is not then the GPL has no power over it because the GPL is a copyright based license. The law itself circumscribes the power of such licenses and their reach. And no doubt German law could be totally different. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 restrited in the number of symbols they can use, this is to make it harder to derive work from the Linux Kernel with a ABI interface. 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. If a work is derivative of another GPL work by any means then the GPL applies to it. If it is not then the GPL has no power over it because the GPL is a copyright based license. The law itself circumscribes the power of such licenses and their reach. And no doubt German law could be totally different. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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, I agree, I was just not talking about licensing/legal issues, but only about the visible technical reasons and restrictions. So I dont think I am confused... thanks for follow up, Alan. Gruss Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. )[EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+49721151516129 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 exported symbols are part of a GPL > product. The only question of relevance is whether the item is a derived > work in law or not. I dont understand that? Can you point out where I am confused? 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? Non GPL Modules are also restrited in the number of symbols they can use, this is to make it harder to derive work from the Linux Kernel with a ABI interface. Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 exported symbols are part of a GPL product. The only question of relevance is whether the item is a derived work in law or not. I dont understand that? Can you point out where I am confused? 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? Non GPL Modules are also restrited in the number of symbols they can use, this is to make it harder to derive work from the Linux Kernel with a ABI interface. Gruss Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 Windows XP/2000/2003/Longhorn and Free BSD. > > It uses no kernel headers or kernel files. > > So then, does it have _anything_ to do with linux kernel development? It > doesn't seem so. Is this "product" an attempt to raise some money, and > make your former "linux kernel buyout" offer, but now giving a higher > amount of money? > > Damnit, hope I am not feeding some troll out there... I think Jeff was making available changes he'd made to the Linux kernel, under the terms of the GPL, to allow this proprietary software to work (properly?). The patches contain nothing that would be of general use to anybody. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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-free binaries but also to indicate things like pre-empt, use of insmod -f etc that may be significant for debugging work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 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 exported symbols are part of a GPL product. The only question of relevance is whether the item is a derived work in law or not. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 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. [...] > 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 It is infringing the debuggability seriously outside the exclusive club of people with access to the secret source of these drivers. So "tainted" pretty much explains quite well the situation as seen from the kernel side. > "non-GPL" or "Vendor Supported" since > this is more accurate. Just a suggestion. "non-GPL" is clearly wrong. First the kernel source it self stays GPL independent for whatever legal people write into othre license agreements, second the license of your source *could be* (in theory) GPL if the authors wanted it and - in some cases - the source *is* actually GPL even if the authors doesn't want it. And "Vendor supported" must be (if you really want to be accurate) "At best it is vendor supported if the vendor exists at the moment and for whatever said vendor thinks support is. The contact address for said vendor is , , , , , . Please do not ask the free software community if you have any problem with the Linux kernel." So please put this in your proprietory module and print it whenever it makes sense since the necessary contact data is only known by you. The point is: There is no such concept as "vendor" as it would or could be seen in the commercial and/or legal world if you download the kernel source from kernel.org. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 more accurate. Just a suggestion. > > Thanks Jeff I believe the use of the word is quite correct. Taint is synonymous to contaminate. When you add a closed-source driver, the kernel is no longer pure GPL, it's been contaminated by a non-GPL part. There may be other connotations to the word in various regions in the english speaking world that give it much darker meanings, though, that I don't know about. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 running with preemptible kernel and hyperthreading enabled. Jeff, you are running a tainted kernel since you're loading proprietary modules. you'd better go back to your vendor for support. haha. cheers, lincoln. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 running with preemptible kernel and hyperthreading enabled. Jeff, you are running a tainted kernel since you're loading proprietary modules. you'd better go back to your vendor for support. haha. cheers, lincoln. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 more accurate. Just a suggestion. Thanks Jeff I believe the use of the word is quite correct. Taint is synonymous to contaminate. When you add a closed-source driver, the kernel is no longer pure GPL, it's been contaminated by a non-GPL part. There may be other connotations to the word in various regions in the english speaking world that give it much darker meanings, though, that I don't know about. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 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. [...] 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 It is infringing the debuggability seriously outside the exclusive club of people with access to the secret source of these drivers. So tainted pretty much explains quite well the situation as seen from the kernel side. non-GPL or Vendor Supported since this is more accurate. Just a suggestion. non-GPL is clearly wrong. First the kernel source it self stays GPL independent for whatever legal people write into othre license agreements, second the license of your source *could be* (in theory) GPL if the authors wanted it and - in some cases - the source *is* actually GPL even if the authors doesn't want it. And Vendor supported must be (if you really want to be accurate) At best it is vendor supported if the vendor exists at the moment and for whatever said vendor thinks support is. The contact address for said vendor is name, street, phnoe, mobile, email, homepage. Please do not ask the free software community if you have any problem with the Linux kernel. So please put this in your proprietory module and print it whenever it makes sense since the necessary contact data is only known by you. The point is: There is no such concept as vendor as it would or could be seen in the commercial and/or legal world if you download the kernel source from kernel.org. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 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 exported symbols are part of a GPL product. The only question of relevance is whether the item is a derived work in law or not. Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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-free binaries but also to indicate things like pre-empt, use of insmod -f etc that may be significant for debugging work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 Windows XP/2000/2003/Longhorn and Free BSD. It uses no kernel headers or kernel files. So then, does it have _anything_ to do with linux kernel development? It doesn't seem so. Is this product an attempt to raise some money, and make your former linux kernel buyout offer, but now giving a higher amount of money? Damnit, hope I am not feeding some troll out there... I think Jeff was making available changes he'd made to the Linux kernel, under the terms of the GPL, to allow this proprietary software to work (properly?). The patches contain nothing that would be of general use to anybody. -- Cheers, Alistair. 'No sense being pessimistic, it probably wouldn't work anyway.' Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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
> and lan
> throughput. This was running with preemptible kernel and hyperthreading
> enabled.
>
> The wheels come off in the kernel somewhere. I looked at later 2.6
> kernels and there's
> been some changes, but someone may get an ah ha from this fix, if there
> is an underlying
> problem in the kernel.
>
> Jeff
>
>
> static void dequeue_task(struct task_struct *p, prio_array_t *array)
> {
> -array->nr_active--;
> -list_del(>run_list);
> -if (list_empty(array->queue + p->prio))
> -__clear_bit(p->prio, array->bitmap);
> +if (!array)
> + printk("WARN: prio_array was NULL in dequeue task %08X"
> + "pid-%d\n", (unsigned)p, (int)p->pid);
> +
> +if (array)
> +{
> + array->nr_active--;
> + list_del(>run_list);
> + if (list_empty(array->queue + p->prio))
> + __clear_bit(p->prio, array->bitmap);
> +}
> }
>
>
> static void deactivate_task(struct task_struct *p, runqueue_t *rq)
> {
> -rq->nr_running--;
> -if (p->state == TASK_UNINTERRUPTIBLE)
> -rq->nr_uninterruptible++;
> -dequeue_task(p, p->array);
> -p->array = NULL;
> +if (!p->array)
> + printk("WARN: prio_array was NULL in deactivate task %08X"
> + "pid-%d\n", (unsigned)p, (int)p->pid);
> +
> +if (p->array)
> +{
> + rq->nr_running--;
> + if (p->state == TASK_UNINTERRUPTIBLE)
> + rq->nr_uninterruptible++;
> + dequeue_task(p, p->array);
> + p->array = NULL;
> +}
> }
>
I think a BUG_ON(!array) should be there to cache the call trace. I
think there are bugs on the call trace. The codes you add will only
resolve the problem in an exterior way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 with preemptible kernel and hyperthreading
enabled.
The wheels come off in the kernel somewhere. I looked at later 2.6
kernels and there's
been some changes, but someone may get an ah ha from this fix, if there
is an underlying
problem in the kernel.
Jeff
static void dequeue_task(struct task_struct *p, prio_array_t *array)
{
-array->nr_active--;
-list_del(>run_list);
-if (list_empty(array->queue + p->prio))
-__clear_bit(p->prio, array->bitmap);
+if (!array)
+ printk("WARN: prio_array was NULL in dequeue task %08X"
+ "pid-%d\n", (unsigned)p, (int)p->pid);
+
+if (array)
+{
+ array->nr_active--;
+ list_del(>run_list);
+ if (list_empty(array->queue + p->prio))
+ __clear_bit(p->prio, array->bitmap);
+}
}
static void deactivate_task(struct task_struct *p, runqueue_t *rq)
{
-rq->nr_running--;
-if (p->state == TASK_UNINTERRUPTIBLE)
-rq->nr_uninterruptible++;
-dequeue_task(p, p->array);
-p->array = NULL;
+if (!p->array)
+ printk("WARN: prio_array was NULL in deactivate task %08X"
+ "pid-%d\n", (unsigned)p, (int)p->pid);
+
+if (p->array)
+{
+ rq->nr_running--;
+ if (p->state == TASK_UNINTERRUPTIBLE)
+ rq->nr_uninterruptible++;
+ dequeue_task(p, p->array);
+ p->array = NULL;
+}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 symbols and that the kernel is tainted. Which basically means nobody sane can help you with corrupted kernel data structures. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ 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 more accurate. Just a suggestion. Thanks Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 modules. Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 tainted. Which basically means nobody sane can help you with corrupted kernel data structures. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. So, that means that DSFS runs on userspace? (We can't see the source so it'd be nice to know how DSFS works) Also, I'm curious about this piece of code on your patch: ftp://ftp.soleranetworks.com/pub/dsfs/datascout-only-2.6.9-06-28-05.patch - printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", - mod->name, license); +// printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", +//mod->name, license); I mean, nvidia people also use propietary code in the kernel (probably violating the GPL anyway) and don't do such things. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I disagree with the language and the characterization that our proprietary user application code is "tainted." Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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". > Also note that the GPL below is copyrighted by the Free Software > Foundation, but the instance of code that it refers to (the linux > kernel) is copyrighted by me and others who actually wrote it. So, that means that DSFS runs on userspace? (We can't see the source so it'd be nice to know how DSFS works) Also, I'm curious about this piece of code on your patch: ftp://ftp.soleranetworks.com/pub/dsfs/datascout-only-2.6.9-06-28-05.patch - printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", - mod->name, license); +// printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", +//mod->name, license); I mean, nvidia people also use propietary code in the kernel (probably violating the GPL anyway) and don't do such things. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 or kernel files. > So then, does it have _anything_ to do with linux kernel development? It doesn't seem so. Is this "product" an attempt to raise some money, and make your former "linux kernel buyout" offer, but now giving a higher amount of money? Damnit, hope I am not feeding some troll out there... -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.13) signature.asc Description: Digital signature
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
[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 to any person the "right to copy" in a license which states the software is FREE, you have in essense affected a copyright transfer to each and every person who receives the code. Bullshit. 17 USC 106(3) talks about transfer of ownership *of the item*, not of the copyright itself (see 17 USC 202, which clarifies this). So you can sell a book - but that isn't transferring the copyright of the book. There isn't any actual transfer without a document that actually *SAYS* "transfer of copyright" - see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm not surprised that you're confused on this as well). I have responded all I am going to on this topic. Further discussion will not be helpful. The patches are provided IAW the GPL. Our proprietary application is just like the thousands of others provided on Linux, and it does use or incorporate any GPL or Linux code. I will not respond to any further discussion on this thread. Thanks for the input. Please feel free to read Linus statements on kernel.org regarding the statements that applications that run on Linux and that use published interfaces are unaffected by the GPL. Thanks for your input. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 copy" in a license which states the software is FREE, you have > in essense > affected a copyright transfer to each and every person who receives the > code. Bullshit. 17 USC 106(3) talks about transfer of ownership *of the item*, not of the copyright itself (see 17 USC 202, which clarifies this). So you can sell a book - but that isn't transferring the copyright of the book. There isn't any actual transfer without a document that actually *SAYS* "transfer of copyright" - see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm not surprised that you're confused on this as well). pgpvxl2Vuin8d.pgp Description: PGP signature
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 not apply to it . except for section 2 which states that if parts are related (or at least not independent, for example when they are designed to exclusively work togethern), and one part is GPL, then both parts need to be, or you should not distribute the GPL part. This is not "your other code becomes gpl", it is "you can't distribute the GPL parts". The key word here is "designed to EXCLUSIVELY work together" as opposed to "INCLUSIVE". DSFS is not exclusive to Linux nor is it designed to run exclusively on Linux. 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 copy" in a license which states the software is FREE, you have in essense affected a copyright transfer to each and every person who receives the code. This is esspecially true since the GPL says that the software if "FREE". One could argue that the GPL requires reciprocal consdieration by requiring conversion of ownsership of protected IP into a GPL licensing scheme, but this violates several acts of Congress regarding anit-trust legislation. There is also the argument of the doctrine of esstoppel. This doctrine bascially says if you've been using it for some period of time, and no one brings a claim, then it's become yours. Linux and GPL has also become an "essential facility" of the US Internet. Under the Doctrine of essential facility anything that by it's nature has become such an integrated part of a class of activities affecting commerce, then the general public has a right to use it without claims of IP infingement or licensing restrictions. So, in short, the GPL language was and remains defective in this area. If someone takes and uses GPL code which is claimed to be FREE, and runs proprietary applications on Linux, particularly given Linus statements publically and those of others that Linux applications are not affected, then those appplications, provided they use published interfaces, and do not incorporate GPL code, are not subject to the GPL and it's terms. The modified portions of Linux, are however, subject to the GPL, and they have been disclosed as required. I do agree that the GPL has this language, but the balancing test in a Court of law would be whether or not the program was designed to be "exclusively work together" based upon the plain language of the license. This is not the case here. Folks may try to argue that the VFS interface in Linux is "exclusive", however, it ais a public interface, just like an ethernet adapter is a public interface. The real solution is to remove the "right to copy" language from the GPL, and substitute, "right to grant sub-licenses to distribute", then your arguments would be more solid in US District Court. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
> 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 . except for section 2 which states that if parts are related (or at least not independent, for example when they are designed to exclusively work togethern), and one part is GPL, then both parts need to be, or you should not distribute the GPL part. This is not "your other code becomes gpl", it is "you can't distribute the GPL parts". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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. 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 or kernel files. I have always taken the position that the GPL does not convert IP ownership. Since DSFS is hardware specific to our platforms, I do not believe it entails any issues with the GPL, and it uses published exports from the Linux kernel. The GPL also confers right to copy == copyright under US copyright laws. I don't believe that app vendors infringe the GPL on Linux. This is just another app, and I have disclosed and published all GPL code affected. 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 . Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 multiple gigabit capture and stream to disk capability These patches are being provided as required by the terms of the GNU Public License. Also included with this announcement are white papers which can be located at www.soleranetworks.com describing the appliance features and characteristics of the DSFS file system. The Core File System code is a separate proprietary module and is not released under the GPL and is shipped on the Solera Networks DS 1U, 2U, and 3U appliances. DS Appliances support gigabit ethernet and 10Ge Ethernet via the Intel e1000/ixgb adapter drivers. Current Capture rates sustained with a 2U appliance with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 2 interfaces = 120 MB/S stream to disk 445,000 pps @ 256 byte packets x 2 interfaces = 226 MB/S stream to disk 208,000 pps @ 576 byte packets x 2 interfaces = 240 MB/S stream to disk 119,000 pps @ 1024 byte packets x 2 interfaces = 245 MB/S stream to disk 82,000 pps @ 1500 byte packets x 2 interfaces = 247 MB/S stream to disk Current Capture rates sustained with a 1U appliance with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 1 interfaces = 60 MB/S stream to disk 445,000 pps @ 256 byte packets x 1 interfaces = 113 MB/S stream to disk 208,000 pps @ 576 byte packets x 1 interfaces = 119 MB/S stream to disk 119,000 pps @ 1024 byte packets x 1 interfaces = 122 MB/S stream to disk 82,000 pps @ 1500 byte packets x 1 interfaces = 123 MB/S stream to disk Current Capture rates sustained with a 3U appliance with dual disk controllers with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 3 interfaces = 180 MB/S stream to disk 445,000 pps @ 256 byte packets x 3 interfaces = 339 MB/S stream to disk 208,000 pps @ 576 byte packets x 3 interfaces = 360 MB/S stream to disk 119,000 pps @ 1024 byte packets x 3 interfaces = 365 MB/S stream to disk 82,000 pps @ 1500 byte packets x 3 interfaces = 370 MB/S stream to disk The DSFS file system supports over 300 open source applications with high peformance stream to disk network forensic storage capability and also supports SPAN, Optical Splitter, and Asymmetric Routed configurations. DSFS performs stream merging and also exposes the captured data as native LIBPCAP files and virtual network interfaces which allow seamless integration with Snort, tEthereal, and hundreds of open source Network Forsensic and Network Management tools on Linux and Windows.DSFS is the culmination of 2 years of intense development efforts by Solera Networks to create a powerful platform infrastructure for the development of high performance network forensic open source applications on the Linux Operating System. DSFS is fully SMP enabled and supports Hyperthreaded architectures as well as native SMP. Jeff V. Merkey Solera Networks www.soleranetworks.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 multiple gigabit capture and stream to disk capability These patches are being provided as required by the terms of the GNU Public License. Also included with this announcement are white papers which can be located at www.soleranetworks.com describing the appliance features and characteristics of the DSFS file system. The Core File System code is a separate proprietary module and is not released under the GPL and is shipped on the Solera Networks DS 1U, 2U, and 3U appliances. DS Appliances support gigabit ethernet and 10Ge Ethernet via the Intel e1000/ixgb adapter drivers. Current Capture rates sustained with a 2U appliance with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 2 interfaces = 120 MB/S stream to disk 445,000 pps @ 256 byte packets x 2 interfaces = 226 MB/S stream to disk 208,000 pps @ 576 byte packets x 2 interfaces = 240 MB/S stream to disk 119,000 pps @ 1024 byte packets x 2 interfaces = 245 MB/S stream to disk 82,000 pps @ 1500 byte packets x 2 interfaces = 247 MB/S stream to disk Current Capture rates sustained with a 1U appliance with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 1 interfaces = 60 MB/S stream to disk 445,000 pps @ 256 byte packets x 1 interfaces = 113 MB/S stream to disk 208,000 pps @ 576 byte packets x 1 interfaces = 119 MB/S stream to disk 119,000 pps @ 1024 byte packets x 1 interfaces = 122 MB/S stream to disk 82,000 pps @ 1500 byte packets x 1 interfaces = 123 MB/S stream to disk Current Capture rates sustained with a 3U appliance with dual disk controllers with DSFS on Linux 2.6.X and 2.4.X kernels are: 975,000 pps @ 72 byte packets x 3 interfaces = 180 MB/S stream to disk 445,000 pps @ 256 byte packets x 3 interfaces = 339 MB/S stream to disk 208,000 pps @ 576 byte packets x 3 interfaces = 360 MB/S stream to disk 119,000 pps @ 1024 byte packets x 3 interfaces = 365 MB/S stream to disk 82,000 pps @ 1500 byte packets x 3 interfaces = 370 MB/S stream to disk The DSFS file system supports over 300 open source applications with high peformance stream to disk network forensic storage capability and also supports SPAN, Optical Splitter, and Asymmetric Routed configurations. DSFS performs stream merging and also exposes the captured data as native LIBPCAP files and virtual network interfaces which allow seamless integration with Snort, tEthereal, and hundreds of open source Network Forsensic and Network Management tools on Linux and Windows.DSFS is the culmination of 2 years of intense development efforts by Solera Networks to create a powerful platform infrastructure for the development of high performance network forensic open source applications on the Linux Operating System. DSFS is fully SMP enabled and supports Hyperthreaded architectures as well as native SMP. Jeff V. Merkey Solera Networks www.soleranetworks.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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. 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 or kernel files. I have always taken the position that the GPL does not convert IP ownership. Since DSFS is hardware specific to our platforms, I do not believe it entails any issues with the GPL, and it uses published exports from the Linux kernel. The GPL also confers right to copy == copyright under US copyright laws. I don't believe that app vendors infringe the GPL on Linux. This is just another app, and I have disclosed and published all GPL code affected. 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 . Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 . except for section 2 which states that if parts are related (or at least not independent, for example when they are designed to exclusively work togethern), and one part is GPL, then both parts need to be, or you should not distribute the GPL part. This is not your other code becomes gpl, it is you can't distribute the GPL parts. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 not apply to it . except for section 2 which states that if parts are related (or at least not independent, for example when they are designed to exclusively work togethern), and one part is GPL, then both parts need to be, or you should not distribute the GPL part. This is not your other code becomes gpl, it is you can't distribute the GPL parts. The key word here is designed to EXCLUSIVELY work together as opposed to INCLUSIVE. DSFS is not exclusive to Linux nor is it designed to run exclusively on Linux. 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 copy in a license which states the software is FREE, you have in essense affected a copyright transfer to each and every person who receives the code. This is esspecially true since the GPL says that the software if FREE. One could argue that the GPL requires reciprocal consdieration by requiring conversion of ownsership of protected IP into a GPL licensing scheme, but this violates several acts of Congress regarding anit-trust legislation. There is also the argument of the doctrine of esstoppel. This doctrine bascially says if you've been using it for some period of time, and no one brings a claim, then it's become yours. Linux and GPL has also become an essential facility of the US Internet. Under the Doctrine of essential facility anything that by it's nature has become such an integrated part of a class of activities affecting commerce, then the general public has a right to use it without claims of IP infingement or licensing restrictions. So, in short, the GPL language was and remains defective in this area. If someone takes and uses GPL code which is claimed to be FREE, and runs proprietary applications on Linux, particularly given Linus statements publically and those of others that Linux applications are not affected, then those appplications, provided they use published interfaces, and do not incorporate GPL code, are not subject to the GPL and it's terms. The modified portions of Linux, are however, subject to the GPL, and they have been disclosed as required. I do agree that the GPL has this language, but the balancing test in a Court of law would be whether or not the program was designed to be exclusively work together based upon the plain language of the license. This is not the case here. Folks may try to argue that the VFS interface in Linux is exclusive, however, it ais a public interface, just like an ethernet adapter is a public interface. The real solution is to remove the right to copy language from the GPL, and substitute, right to grant sub-licenses to distribute, then your arguments would be more solid in US District Court. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 copy in a license which states the software is FREE, you have in essense affected a copyright transfer to each and every person who receives the code. Bullshit. 17 USC 106(3) talks about transfer of ownership *of the item*, not of the copyright itself (see 17 USC 202, which clarifies this). So you can sell a book - but that isn't transferring the copyright of the book. There isn't any actual transfer without a document that actually *SAYS* transfer of copyright - see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm not surprised that you're confused on this as well). pgpvxl2Vuin8d.pgp Description: PGP signature
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
[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 to any person the right to copy in a license which states the software is FREE, you have in essense affected a copyright transfer to each and every person who receives the code. Bullshit. 17 USC 106(3) talks about transfer of ownership *of the item*, not of the copyright itself (see 17 USC 202, which clarifies this). So you can sell a book - but that isn't transferring the copyright of the book. There isn't any actual transfer without a document that actually *SAYS* transfer of copyright - see 17 USC 204 (a) (Note that there's whole companies in Utah, with actual large legal teams, that seem unclear on the concept in 17 USC 204(a), so I'm not surprised that you're confused on this as well). I have responded all I am going to on this topic. Further discussion will not be helpful. The patches are provided IAW the GPL. Our proprietary application is just like the thousands of others provided on Linux, and it does use or incorporate any GPL or Linux code. I will not respond to any further discussion on this thread. Thanks for the input. Please feel free to read Linus statements on kernel.org regarding the statements that applications that run on Linux and that use published interfaces are unaffected by the GPL. Thanks for your input. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. Linus Torvalds - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 or kernel files. So then, does it have _anything_ to do with linux kernel development? It doesn't seem so. Is this product an attempt to raise some money, and make your former linux kernel buyout offer, but now giving a higher amount of money? Damnit, hope I am not feeding some troll out there... -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.13) signature.asc Description: Digital signature
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. So, that means that DSFS runs on userspace? (We can't see the source so it'd be nice to know how DSFS works) Also, I'm curious about this piece of code on your patch: ftp://ftp.soleranetworks.com/pub/dsfs/datascout-only-2.6.9-06-28-05.patch - printk(KERN_WARNING %s: module license '%s' taints kernel.\n, - mod-name, license); +// printk(KERN_WARNING %s: module license '%s' taints kernel.\n, +//mod-name, license); I mean, nvidia people also use propietary code in the kernel (probably violating the GPL anyway) and don't do such things. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. So, that means that DSFS runs on userspace? (We can't see the source so it'd be nice to know how DSFS works) Also, I'm curious about this piece of code on your patch: ftp://ftp.soleranetworks.com/pub/dsfs/datascout-only-2.6.9-06-28-05.patch - printk(KERN_WARNING %s: module license '%s' taints kernel.\n, - mod-name, license); +// printk(KERN_WARNING %s: module license '%s' taints kernel.\n, +//mod-name, license); I mean, nvidia people also use propietary code in the kernel (probably violating the GPL anyway) and don't do such things. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I disagree with the language and the characterization that our proprietary user application code is tainted. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 tainted. Which basically means nobody sane can help you with corrupted kernel data structures. Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 modules. Gruss Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 symbols and that the kernel is tainted. Which basically means nobody sane can help you with corrupted kernel data structures. Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ 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 more accurate. Just a suggestion. Thanks Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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 with preemptible kernel and hyperthreading
enabled.
The wheels come off in the kernel somewhere. I looked at later 2.6
kernels and there's
been some changes, but someone may get an ah ha from this fix, if there
is an underlying
problem in the kernel.
Jeff
static void dequeue_task(struct task_struct *p, prio_array_t *array)
{
-array-nr_active--;
-list_del(p-run_list);
-if (list_empty(array-queue + p-prio))
-__clear_bit(p-prio, array-bitmap);
+if (!array)
+ printk(WARN: prio_array was NULL in dequeue task %08X
+ pid-%d\n, (unsigned)p, (int)p-pid);
+
+if (array)
+{
+ array-nr_active--;
+ list_del(p-run_list);
+ if (list_empty(array-queue + p-prio))
+ __clear_bit(p-prio, array-bitmap);
+}
}
static void deactivate_task(struct task_struct *p, runqueue_t *rq)
{
-rq-nr_running--;
-if (p-state == TASK_UNINTERRUPTIBLE)
-rq-nr_uninterruptible++;
-dequeue_task(p, p-array);
-p-array = NULL;
+if (!p-array)
+ printk(WARN: prio_array was NULL in deactivate task %08X
+ pid-%d\n, (unsigned)p, (int)p-pid);
+
+if (p-array)
+{
+ rq-nr_running--;
+ if (p-state == TASK_UNINTERRUPTIBLE)
+ rq-nr_uninterruptible++;
+ dequeue_task(p, p-array);
+ p-array = NULL;
+}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches
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
and lan
throughput. This was running with preemptible kernel and hyperthreading
enabled.
The wheels come off in the kernel somewhere. I looked at later 2.6
kernels and there's
been some changes, but someone may get an ah ha from this fix, if there
is an underlying
problem in the kernel.
Jeff
static void dequeue_task(struct task_struct *p, prio_array_t *array)
{
-array-nr_active--;
-list_del(p-run_list);
-if (list_empty(array-queue + p-prio))
-__clear_bit(p-prio, array-bitmap);
+if (!array)
+ printk(WARN: prio_array was NULL in dequeue task %08X
+ pid-%d\n, (unsigned)p, (int)p-pid);
+
+if (array)
+{
+ array-nr_active--;
+ list_del(p-run_list);
+ if (list_empty(array-queue + p-prio))
+ __clear_bit(p-prio, array-bitmap);
+}
}
static void deactivate_task(struct task_struct *p, runqueue_t *rq)
{
-rq-nr_running--;
-if (p-state == TASK_UNINTERRUPTIBLE)
-rq-nr_uninterruptible++;
-dequeue_task(p, p-array);
-p-array = NULL;
+if (!p-array)
+ printk(WARN: prio_array was NULL in deactivate task %08X
+ pid-%d\n, (unsigned)p, (int)p-pid);
+
+if (p-array)
+{
+ rq-nr_running--;
+ if (p-state == TASK_UNINTERRUPTIBLE)
+ rq-nr_uninterruptible++;
+ dequeue_task(p, p-array);
+ p-array = NULL;
+}
}
I think a BUG_ON(!array) should be there to cache the call trace. I
think there are bugs on the call trace. The codes you add will only
resolve the problem in an exterior way.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
