[ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

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


>
>
>
>  
>

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Rik van Riel]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Arjan van de Ven]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

Valdis.Kletnieks@vt.edu 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jeff V. Merkey]

 
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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Jose Luis Domingo Lopez]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

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)


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[jmerkey]

Diego Calleja wrote:

>El Wed, 31 Aug 2005 14:27:47 -0600,
>"Jeff V. Merkey" <jmerkey@soleranetworks.com> 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 majordomo@vger.kernel.org
>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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Diego Calleja]

El Wed, 31 Aug 2005 14:27:47 -0600,
"Jeff V. Merkey" <jmerkey@soleranetworks.com> 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.

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <20050901012218.02c79560.diegocg@gmail.com> 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <43163430.7010107@utah-nac.org> 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[jmerkey]

Bernd Eckenfels wrote:

>In article <20050901012218.02c79560.diegocg@gmail.com> 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 majordomo@vger.kernel.org
>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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[jmerkey]

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;
+        }
 }
 

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Zhou Yingchao]

2005/9/1, jmerkey <jmerkey@utah-nac.org>:
> 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.

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Lincoln Dale]

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.

>

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Vojtech Pavlik]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Petrovitsch]

On Wed, 2005-08-31 at 18:56 -0600, jmerkey wrote:
> Bernd Eckenfels wrote:
> >In article <20050901012218.02c79560.diegocg@gmail.com> 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Alan Cox]

On Iau, 2005-09-01 at 02:33 +0200, Bernd Eckenfels wrote:
> In article <20050901012218.02c79560.diegocg@gmail.com> 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Alan Cox]

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.

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Alistair John Strachan]

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.

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <1125569702.15768.0.camel@localhost.localdomain> 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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Alan Cox]

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

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

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)     -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
 ( .. )    ecki@{inka.de,linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  eckes@IRCNet  v:+497211603874  f:+49721151516129
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!