Re: Binary only module overview

Re: Binary only module overview

[Petr Vandrovec]

On 24 Sep 01 at 12:24, Dave McCracken wrote:
> >> IIRC, vmware includes one or more kernel modules.
> >>
> >> Rasmus
> >>
> > Yes, but the modules are not binary-only.
> > The sourcecode is in the package, although it is not GPL.
> 
> I believe they only provide source for an interface layer that can be 
> compiled against a specific version of the kernel.  I think the core 
> drivers are binary only.

VMnet and VMppuser drivers are completely standalone and can work
without VMware. You can persuade VMmon module to load and execute
arbitrary code on kernel level - it just provides virtual machine
environment (switches CPU context), but as it even does not link to
anything else, I do not see any problem here. DRI drivers also allows
you to smash arbitrary piece of memory...

As for license on these modules - I was under impression that they are
under GPL, but I'll ask VMware for clarification.
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz

Re: Binary only module overview

[Dave McCracken]

--On Monday, September 24, 2001 19:52:13 +0000 Petr Vandrovec 
<VANDROVE@vc.cvut.cz> wrote:

>> > Yes, but the modules are not binary-only.
>> > The sourcecode is in the package, although it is not GPL.
>>
>> I believe they only provide source for an interface layer that can be
>> compiled against a specific version of the kernel.  I think the core
>> drivers are binary only.
>
> VMnet and VMppuser drivers are completely standalone and can work
> without VMware. You can persuade VMmon module to load and execute
> arbitrary code on kernel level - it just provides virtual machine
> environment (switches CPU context), but as it even does not link to
> anything else, I do not see any problem here. DRI drivers also allows
> you to smash arbitrary piece of memory...
>
> As for license on these modules - I was under impression that they are
> under GPL, but I'll ask VMware for clarification.

As a couple of people pointed out privately to me, I was mistaken.  VMware 
does include the complete source to its drivers.

A quick check of the file headers shows a VMware copyright with no mention 
of GPL.  Granted, that's not definitive, but it's a data point.

Dave McCracken

=====================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059

Re: Binary only module overview

[Eric W. Biederman]

Dave McCracken <dmccr@us.ibm.com> writes:

> --On Monday, September 24, 2001 19:52:13 +0000 Petr Vandrovec
> <VANDROVE@vc.cvut.cz> wrote:
> 
> >> > Yes, but the modules are not binary-only.
> >> > The sourcecode is in the package, although it is not GPL.
> >>
> >> I believe they only provide source for an interface layer that can be
> >> compiled against a specific version of the kernel.  I think the core
> >> drivers are binary only.
> >
> > VMnet and VMppuser drivers are completely standalone and can work
> > without VMware. You can persuade VMmon module to load and execute
> > arbitrary code on kernel level - it just provides virtual machine
> > environment (switches CPU context), but as it even does not link to
> > anything else, I do not see any problem here. DRI drivers also allows
> > you to smash arbitrary piece of memory...

Providing an interface to run arbitrary code in kernel space is definentily
against kernel policy.  As adding syscalls from modules have long been
officially off limits.  If the DRI code allows you to smash arbitrary pieces
of memory it probably needs a few checks.  DRI should be an interface
layer that makes it as safe as possible to directly access the video
card from user space.

> >
> > As for license on these modules - I was under impression that they are
> > under GPL, but I'll ask VMware for clarification.
> 
> As a couple of people pointed out privately to me, I was mistaken.  VMware does
> include the complete source to its drivers.

VMmon where it basically allows you to run arbitrary code at the kernel level
does appear to be complete source to me.  Complete source to an interface
layer yes, but not complete source.

> A quick check of the file headers shows a VMware copyright with no mention of
> GPL.  Granted, that's not definitive, but it's a data point.

Well whatever is loaded with VMmon counts as a binary only kernel module.

Eric

Re: Binary only module overview

[Giacomo Catenazzi]

Arjan van de Ven wrote:

> 
> Hardware drivers
> ----------------


draytek vigor *    : isdn cards (ftp.draytek.com)

	giacomo

RE: Binary only module overview

[KRAMER,STEVEN (HP-USA,ex1)]

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> 
> On Tue, Sep 25, 2001 at 04:09:02PM -0700, Crispin Cowan wrote:
> > 
> > Therefore, any additional constraints people may wish to 
> impose, such as 
> > Greg's comment in security.h, are invalid. When someone 
> receives a copy 
> > of the Linux kernel, the license is pure, vanilla GPL, with 
> no funny 
> > riders.*
> 
> My comment in security.h that I proposed [1] does not add any 
> additional
> constraints to the license that is currently on the file.  All it does
> is explicitly state the licensing terms of it, so that there 
> shall be no
> confusion regarding it's inclusion in programs.  If you think this is
> adding an additional restriction to the file, please explain.
> 
> thanks,
> 
> greg k-h

I disagree that your comment does not add any additional constraints.
One could argue that there is enough ambiguity in the GPL and Linus's
explanations regarding uses/derived from, to allow proprietary modules
in the current module framework.  Others can argue the other way. (Refer
back to Crispin's latest email.)  Your additional
comment fixes one of these points of view (call it a refinement rather than
a constraint if you will), so it does go further than the
original license did.  I think the comments we've seen proposed from Crispin
and jmjones (sorry if I attributed the sources incorrectly) are alright, in
that they discuss what is encouraged and discouraged, but do nothing to
refine the original GPL.  If such "style" language is not appropriate
for kernel code, I have no problem in leaving it out either.

You believe your comment does not place any new constraints on the license.
I do believe that it does (because the GPL leaves room for interpretation,
as Crispin has noted).  Would it not be safe, then, to just leave it out
entirely?  You still have the same licensing (that is, no new constraints),
and the few of us that believe otherwise are mollified.

--steve kramer

Re: Binary only module overview

[Chad Hanson]

Hi Greg,

PitBull LX for Linux source patches have been available at 
www.argusrevolution.com. After the tragic event of Sept 11, Argus has 
temporarily suspended the operation of this web site. I am sorry for the 
inconvenience this may have caused. The Argus PitBull LX for Linux 
patches for Linux will be available shortly at 
http://sourceforge.net/projects/pitbull-lx

Thanks for your understanding,

Chad Hanson

> On Tue, Sep 25, 2001 at 08:44:39AM -0700, Greg KH wrote:
> 
> 
>> On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> 
>> > 
>> > I'm composing a list of all existing binary only modules, 
> 
>> 
>> Argus System's PitBull for Linux modifies the kernel.  No source or
>> patches for these modifications can be found on the web, so I'm guessing
>> that it's closed source:
>> http://www.argus-systems.com/
> 
> 


-- 
Chad Hanson
VP and Chief Technologist, Govt Systems
Argus Systems Group, Inc.
mailto:hanson@argus-systems.com
http://www.argus-systems.com
Phone: (217) 355-6308
Fax:   (217) 355-1433

Re: Binary only module overview

[Crispin Cowan]

Arjan van de Ven <arjanv@redhat.com> wrote

I'm composing a list of all existing binary only modules, 
and I got to a list of 26 different modules
... 
Hewlet Packard	- High level security modules (LSM) 
SGI		- High level security modules (LSM) 
Wirex		- High level security modules (LSM)

NOTE: To my knowledge, the above mentioned modules either do not exist 
or have not been released. The LSM patch itself is entirely GPL'd.

The debate thread 
http://mail.wirex.com/pipermail/linux-security-module/2001-September/002017.html 
that Greg KH referred to is about whether LSM (security) modules should 
ever be permitted to be proprietary. Some feel that all LSM modules 
should be OSD-compliant Open Source software, while others feel that LSM 
should continue the existing Linux module policy of permitting 
proprietary modules only if they do not require changes to the Linux 
kernel (which would make them a derived work of the kernel).

This post cc'd and reply-to'd to the LSM mailing list.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[Alan Cox]

> ever be permitted to be proprietary. Some feel that all LSM modules 
> should be OSD-compliant Open Source software, while others feel that LSM 
> should continue the existing Linux module policy of permitting 
> proprietary modules only if they do not require changes to the Linux 
> kernel (which would make them a derived work of the kernel).

With the current lunatic US congress proposals on security, crypto and
building big brother into all PC's I'd say allowing non GPL security modules
is positively dangerous to the well being of non US citizens

Re: Binary only module overview

[Crispin Cowan]

Alan Cox wrote:

>>ever be permitted to be proprietary. Some feel that all LSM modules 
>>should be OSD-compliant Open Source software, while others feel that LSM 
>>should continue the existing Linux module policy of permitting 
>>proprietary modules only if they do not require changes to the Linux 
>>kernel (which would make them a derived work of the kernel).
>>
>With the current lunatic US congress proposals on security, crypto and
>building big brother into all PC's I'd say allowing non GPL security modules
>is positively dangerous to the well being of non US citizens
>
Alan made a very interesting point in this post back in June 
http://lwn.net/2001/0614/a/ac-modules.php3   that the Linux kernel is 
all fundamentally GPL licensed. Because the kernel is a composite work 
of many authors, and all that code was contributed under the GPL 2. It 
would require the unanimous consent of all the copyright holders to 
change the license.

That it is GPL licensed in turn has implications. One of them is that 
you are not allowed to impose additional constraints on distribution:

    * Clause 4: "You may not copy, modify, sublicense, or distribute the
      Program except as expressly provided under this License."
    * Clause 6: "... You may not impose any further restrictions on the
      recipients' exercise of the rights granted herein."

Therefore, any additional constraints people may wish to impose, such as 
Greg's comment in security.h, are invalid. When someone receives a copy 
of the Linux kernel, the license is pure, vanilla GPL, with no funny 
riders.*

The question of whether proprietary (non-GPL) modules are permitted is a 
matter of opinion. As Alan states in the June post above, Linus has 
given his opinion (that binary modules are ok, so long as it doesn't 
require kernel changes to run) but that is *only* Linus' opinion. Others 
may have different opinions, but they are all just opinions until the 
courts eventually rule on how the GPL is to be interpreted in this matter.

In light of all that, I propose that the LSM project take a strictly 
neutral stance on the question of binary modules. LSM imposes no new 
restrictions (which would be invalid anyway) and makes no judgment on 
whether binary modules are appropriate. As such, we would replace Greg's 
comment in security.h (and in all other LSM-specific files) with a 
comment that says "Copyright 2001 <authors>, Licensed under the GPL. See 
the Linux Kernels COPYING file for details."

How does that sound to folks?

Crispin

[*] The singular exception is the rider that Linus prepended to the 
Linux COPYING file, scoping what the GPL applies to. Presumably this 
rider was added before multiple authors got involved. If you wanna 
challenge Linus's exception and insist that all Linux applications are 
GPL'd, that's another thread :-)

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[jmjones]

On Tue, 25 Sep 2001, Crispin Cowan wrote:

> How does that sound to folks?

It sounds both wise and consistant with what I expected from LSM.
I can live with that.

> 
> Crispin
> 
...
> -- 
> Crispin Cowan, Ph.D.
> Chief Scientist, WireX Communications, Inc. http://wirex.com
> Security Hardened Linux Distribution:       http://immunix.org
> Available for purchase: http://wirex.com/Products/Immunix/purchase.html


Bravo,
J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjones@jmjones.com 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

Re: Binary only module overview

[Greg KH]

On Tue, Sep 25, 2001 at 04:09:02PM -0700, Crispin Cowan wrote:
> 
> Therefore, any additional constraints people may wish to impose, such as 
> Greg's comment in security.h, are invalid. When someone receives a copy 
> of the Linux kernel, the license is pure, vanilla GPL, with no funny 
> riders.*

My comment in security.h that I proposed [1] does not add any additional
constraints to the license that is currently on the file.  All it does
is explicitly state the licensing terms of it, so that there shall be no
confusion regarding it's inclusion in programs.  If you think this is
adding an additional restriction to the file, please explain.

If you were to include a GPL licensed user space header file in a closed
source program, of course you would be violating that license.  So why
do people think that since a file is in include/linux that the license
attached to that file is no longer valid?

Yes it is true that a variety of companies currently ship binary modules
for Linux.  And hopefully in the compilation of those modules they do
not include any GPL licensed header files.  I know some companies go to
great lengths to prevent this from happening.

thanks,

greg k-h

[1] Included here for those who did not see it on the
    linux-security-module mailing list:
	
	This file may not be included in any code not licensed
	under the list of accepted free software licenses as
	defined in module.h contained in this same directory.

Re: Binary only module overview

[Crispin Cowan]

Greg KH wrote:

>On Tue, Sep 25, 2001 at 04:09:02PM -0700, Crispin Cowan wrote:
>
>>Therefore, any additional constraints people may wish to impose, such as 
>>Greg's comment in security.h, are invalid. When someone receives a copy 
>>of the Linux kernel, the license is pure, vanilla GPL, with no funny 
>>riders.*
>>
>
>My comment in security.h that I proposed [1] does not add any additional
>constraints to the license that is currently on the file.  All it does
>is explicitly state the licensing terms of it, so that there shall be no
>confusion regarding it's inclusion in programs.  If you think this is
>adding an additional restriction to the file, please explain.
>
What your comment does is explicitly state your *interpretation* of the 
implications of the GPL. As is manifestly obvious, the GPL is subject to 
lots of interpretation, especially in the area of what is a "derived 
work." We are on the safest legal ground if we simply state that the 
file in question is GPL'd, and leave it at that.

>If you were to include a GPL licensed user space header file in a closed
>source program, of course you would be violating that license.
>
That is not clear to me. I have been unable to find a definitive 
reference that states that is the case.  If so, it is problematic, 
because then every user-land program that ever #include'd errno.h from 
glibc is GPL'd, because glibc #include's errno.h, among other GPL'd 
kernel header files. Are you sure you want to declare nearly all 
proprietary Linux applications to be in violation of the GPL?

We have a Schrodinger's Cat problem of whether the courts will 
eventually rule that modules are derivative works of the kernel. There 
are two cases here.  Either:

    * Binary modules are permitted by the kernel's GPL:  if this is the
      case, then Greg's comment is invalid, and misleading.
    * Binary modules are not permitted by the kernel's GPL: if this is
      the case, then Greg's comment is redundant, and just marking the
      file "GPL" is sufficient.

IMHO, in neither case is the special language appropriate. This file is 
GPL'd, and we should stop playing lawyer by trying to interpret what 
that means.

If you (Greg, Alan) are confident that your interpretation of the GPL is 
correct, then just marking the files as GPL should be sufficient. What 
purpose is served by saying anything else?

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[Alan Cox]

> If you (Greg, Alan) are confident that your interpretation of the GPL is 
> correct, then just marking the files as GPL should be sufficient. What 
> purpose is served by saying anything else?

It avoids confusion with some of Linus' more strange interpretations which
as a major copyright holder may otherwise be considered to the detriment
of other copyright holders

Re: Binary only module overview

[Greg KH]

On Wed, Sep 26, 2001 at 12:17:37PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> 
> >If you were to include a GPL licensed user space header file in a closed
> >source program, of course you would be violating that license.
> >
> That is not clear to me. I have been unable to find a definitive 
> reference that states that is the case.  If so, it is problematic, 
> because then every user-land program that ever #include'd errno.h from 
> glibc is GPL'd, because glibc #include's errno.h, among other GPL'd 
> kernel header files. Are you sure you want to declare nearly all 
> proprietary Linux applications to be in violation of the GPL?

That is an issue to take up with the glibc authors, not me.  If
something like this bothers you, then use a libc that does not include
kernel header files (which has been pointed out by the kernel authors
that they should not be doing.)  dietLibc [1] works for me quite well
and does not contain any kernel header files.

> If you (Greg, Alan) are confident that your interpretation of the GPL is 
> correct, then just marking the files as GPL should be sufficient. What 
> purpose is served by saying anything else?

As Alan stated, to reduce confusion as to the wishes of the copyright
holders of the file.  3 out of the 4 current holders agree to this
wording, and as the dissenting party, you are free to disagree and keep
that wording from the file (however a small note in it detailing this
disagreement might be a nice thing to do.)

thanks,

greg k-h

 [1] http://www.fefe.de/dietlibc/

Re: Binary only module overview

[Crispin Cowan]

Greg KH wrote:

>On Wed, Sep 26, 2001 at 12:17:37PM -0700, Crispin Cowan wrote:
>
>>Greg KH wrote:
>>
>>>If you were to include a GPL licensed user space header file in a closed
>>>source program, of course you would be violating that license.
>>>
>>That is not clear to me. [... #include glibc -> #include kernel]
>>
>That is an issue to take up with the glibc authors, not me.
>
Fair enough. I pointed it out to make clear that there are licensing 
problems and ambiguities if one strictly insists that #include 
some_gpl.h implies that the code is GPL'd. If that is the case, then 
there are MUCH bigger licensing problems than LSM, so don't take it up 
with me, either :-)

>>If you (Greg, Alan) are confident that your interpretation of the GPL is 
>>correct, then just marking the files as GPL should be sufficient. What 
>>purpose is served by saying anything else?
>>
>As Alan stated, to reduce confusion as to the wishes of the copyright
>holders of the file.
>
However, it is an outright contradiction to some wishes of some other 
copyright holders of the kernel (Linus' binary kernel opinion). Since 
revisions to the kernel's GPL are explicitly prohibited, it seems to me 
that this statement of one side of the controversy as if it were a fact 
increases confusion rather than decreases it.

>a small note in it detailing this disagreement might be a nice thing to do.
>
Fair enough.  How about this:

    "This file is GPL. See the Linux Kernel's COPYING file for details.
    There is controversy over whether this permits you to write a module
    that #includes this file without placing your module under the GPL.
    Consult your lawyer for advice."

I'm really trying to be constructive here.  There is a real licensing 
problem over whether binary modules are legitimate at all, and the issue 
is not special to LSM. I'm trying to get LSM out of the way so that the 
advocates of either side can fight it out without smushing LSM in the 
middle :-)

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[Alan Cox]

> I'm really trying to be constructive here.  There is a real licensing 
> problem over whether binary modules are legitimate at all, and the issue 
> is not special to LSM. I'm trying to get LSM out of the way so that the 
> advocates of either side can fight it out without smushing LSM in the 
> middle :-)

Yes - I agree. The question is "can you be using the LSM module" not
the headers - since LSM is GPL and your work relies on it 

Alan

Re: Binary only module overview

[Crispin Cowan]

Alan Cox wrote:

>>I'm really trying to be constructive here.  There is a real licensing 
>>problem over whether binary modules are legitimate at all, and the issue 
>>is not special to LSM. I'm trying to get LSM out of the way so that the 
>>advocates of either side can fight it out without smushing LSM in the 
>>middle :-)
>>
>Yes - I agree. The question is "can you be using the LSM module" not
>the headers - since LSM is GPL and your work relies on it 
>
I'm confused as to which question Alan is asking, so I'll answer several :-)

    * "What is the licensing on the LSM module?" Crispin's pedantic
      response: there is no "the" LSM module. LSM is a patch to enrich
      the existing Linux loadable kernel module interface to allow
      access control modules. These modules do exist:
          * There is a dummy module (useful as a template) which just
            does the superuser check ("UID==0" and access is granted)
            and it is GPL'd.
          * There is a module that embodies the guts of POSIX
            capabilities, and it is GPL'd.
          * There is a port of SELinux to LSM (produced by the SELinux
            team) and it is GPL'd.
    * "Can you use the LSM interface with a non-GPL module, if you
      eschew GPL'd .h files?" Crispin's opinion: I dunnow, but the
      answer is the same as the answer for current Linux loadble kernel
      modules. If loading a module is "linking", then all modules &
      device drivers must be GPL'd.
    * "Can a non-GPL LSM module #include a GPL'd .h?" Crispin's opinion:
      I dunnow, but the answer is the same as the answer for many
      current Linux applications.  I know, this is the question Alan did
      not ask :-)

Crispin is not a lawyer/judge, so his opinion doesn't matter anyway :-)

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[Valdis.Kletnieks]

On Thu, 27 Sep 2001 00:14:33 BST, Alan Cox said:
> > I'm really trying to be constructive here.  There is a real licensing 
> > problem over whether binary modules are legitimate at all, and the issue 
> > is not special to LSM. I'm trying to get LSM out of the way so that the 
> > advocates of either side can fight it out without smushing LSM in the 
> > middle :-)
> 
> Yes - I agree. The question is "can you be using the LSM module" not
> the headers - since LSM is GPL and your work relies on it 

Unfortunately, the commentary in /usr/src/linux/COPYING exempting programs
that use the syscall interface is clear as mud.

I can read it as saying "the syscall interface is hereby granted an exemption,
and other normal uses of the kernel are specifically NOT exempted".  In that
case, all authors of closed-source loadable modules are heretics and need to
be burnt at the stake. ;)

I can equally easily read it as "normal use of the kernel does not fall
under 'derivative work', and the syscall inferface is cited as one example
of normal use".  Given that Linus has been quoted elsewhere as saying that
closed-source modules are not *inherently* evil, this may be the intended reading.

I can equally easily read it as "Linus wrote it when the syscall interface WAS
the only interface, and never updated it for loadable modules...." ;)

Personally, I'd not be at all surprised to find out that none of my 3 readings
are anywhere close to the actual meaning as decided by a court of law....

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Re: Binary only module overview

[Greg KH]

On Wed, Sep 26, 2001 at 03:50:11PM -0700, Crispin Cowan wrote:
> >a small note in it detailing this disagreement might be a nice thing to do.
> >
> Fair enough.  How about this:
> 
>    "This file is GPL. See the Linux Kernel's COPYING file for details.
>    There is controversy over whether this permits you to write a module
>    that #includes this file without placing your module under the GPL.
>    Consult your lawyer for advice."

That's acceptable to me.  I'll go add that to the tree.

thanks,

greg k-h

Re: Binary only module overview

[Brian Hatch]

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



Crispin wrote:

> We have a Schrodinger's Cat problem of whether the courts will 
> eventually rule that modules are derivative works of the kernel. There 
> are two cases here.  Either:
> 
>     * Binary modules are permitted by the kernel's GPL:  if this is the
>       case, then Greg's comment is invalid, and misleading.
>     * Binary modules are not permitted by the kernel's GPL: if this is
>       the case, then Greg's comment is redundant, and just marking the
>       file "GPL" is sufficient.

This is the most concise explanation of the problem so far.

I don't like binary security modules, and I won't use them nor
write them, because that's my desicion to make.  Whether they
are legal or not is not.  It's all there in the GPL for well
paid lawyers to determine.  It doesn't seem that there's any
benefit to adding to the existing licensing terms -- it all
boils down to which of the two above cases is true.

> IMHO, in neither case is the special language appropriate. This file is 
> GPL'd, and we should stop playing lawyer by trying to interpret what 
> that means.
>
> If you (Greg, Alan) are confident that your interpretation of the GPL is 
> correct, then just marking the files as GPL should be sufficient. What 
> purpose is served by saying anything else?

Ding.

I wouldn't mind any 'We heartily suggest/prefer' wording, just let's
not get into anything legal or restrictive or the license could become
internally contradictory and make it more difficult to prosecute
GPL infractions.  (Where there are two different ideas in this
group about what constitutes an infraction...)

I always assumed that the LSM was to be treated no differently than
existing modules -- LKMs may be close source.  It was never said
otherwise anywhere when this project was formed.  Changing (ahem,
clarifying) it at this stage of the game is a bad thing.

Had I been able to contribute actual code to this project
(the days never are long enough, are they) I'd have more
of a direct say.  Taking an approach like 'oh, X of Y
developers say one thing, now that we asked' is not a fair
way to make desicions.  Though many on this list have not
contributed code, they have made comments and suggestions
which were used by the primary coders.  Perhaps we should
take a grand survey of everyone and see what they think,
since they all had some input, if not output, into the
code as it stands?  No, that's even worse.

The LSM code is GPLd.  That was a stated requirement from day one.
Nothing else was.  Leave the interpretation of binary module
acceptibility/nonacceptibility to the GPL and the lawyers, that's
not our job.





--
Brian Hatch                e ^ (i*pi) = -1
   Systems and
   Security Engineer
www.hackinglinuxexposed.com

Every message PGP signed

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

Re: Binary only module overview

[David Weinehall]

On Wed, Sep 26, 2001 at 12:17:37PM -0700, Crispin Cowan wrote:

[snip]

> That is not clear to me. I have been unable to find a definitive 
> reference that states that is the case.  If so, it is problematic, 
> because then every user-land program that ever #include'd errno.h from 
> glibc is GPL'd, because glibc #include's errno.h, among other GPL'd 
> kernel header files. Are you sure you want to declare nearly all 
> proprietary Linux applications to be in violation of the GPL?

AFAIK, the glibc (and most other libraries) are LGPL rather than GPL.

[snip]


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Binary only module overview

[Ignacio Vazquez-Abrams]

On Wed, 26 Sep 2001, David Weinehall wrote:

> On Wed, Sep 26, 2001 at 12:17:37PM -0700, Crispin Cowan wrote:
>
> > That is not clear to me. I have been unable to find a definitive
> > reference that states that is the case.  If so, it is problematic,
> > because then every user-land program that ever #include'd errno.h from
> > glibc is GPL'd, because glibc #include's errno.h, among other GPL'd
> > kernel header files. Are you sure you want to declare nearly all
> > proprietary Linux applications to be in violation of the GPL?
>
> AFAIK, the glibc (and most other libraries) are LGPL rather than GPL.

What about programs that include header files from /usr/include/linux,
/usr/include/asm, and/or /usr/include/scsi?

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Binary only module overview

[Alan Cox]

> What about programs that include header files from /usr/include/linux,
> /usr/include/asm, and/or /usr/include/scsi?

I believe you cannot copyright an interface just an implementation of it.
I suspect someone more familiar in law can give the required precise info
on that boundary

That is the security layer issue is one of "does it depend on the linux
kernel to work, is it deriving from the kernel and the GPL'd module for
security plugins" not about the precise structs and #defines.

Given the SSSCA we have to be very clear on this issue, and if its not clear
I might be best to kill the entire uncertainty by not including the LSM
patch in Linux until the US government returns to sanity

Re: Binary only module overview

[Ignacio Vazquez-Abrams]

On Wed, 26 Sep 2001, Alan Cox wrote:

> > What about programs that include header files from /usr/include/linux,
> > /usr/include/asm, and/or /usr/include/scsi?
>
> I believe you cannot copyright an interface just an implementation of it.
> I suspect someone more familiar in law can give the required precise info
> on that boundary
>
> That is the security layer issue is one of "does it depend on the linux
> kernel to work, is it deriving from the kernel and the GPL'd module for
> security plugins" not about the precise structs and #defines.

There are two things that work together cause problems, however:

1) The kernel header files are part of the Linux package, therefore unless a
specific license is applied to these files, they are covered by the license
applied to the entire package, i.e., GPL.

2) I agree that the structs and #define values contained within the header
files are not a problem; there is no transfer of code, only the information
about data formats and contents. OTOH, the #define macros, e.g., the ioctl()
stuff, may cause a problem due to the fact that cpp does in fact take the code
contained in these macros and inserts it into the program.

Therefore, it can be said that anything that uses the header macros must also
be under the GPL. Certainly this is a ridiculous idea, but it is one that
requires additional clarification.

The best solution is probably to make all header files in <linux-src>/include
LGPLed, and make the additional requirement in the Linux license that anything
in <linux-src>/include must also be LGPLed.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Binary only module overview

[Alan Cox]

> The best solution is probably to make all header files in <linux-src>/include
> LGPLed, and make the additional requirement in the Linux license that anything
> in <linux-src>/include must also be LGPLed.

If you want to chase down each author of each file and lobby them
indvidually go ahead.

Alan

Re: Binary only module overview

[Ignacio Vazquez-Abrams]

On Wed, 26 Sep 2001, Alan Cox wrote:

> > The best solution is probably to make all header files in <linux-src>/include
> > LGPLed, and make the additional requirement in the Linux license that anything
> > in <linux-src>/include must also be LGPLed.
>
> If you want to chase down each author of each file and lobby them
> indvidually go ahead.

Is there an official place where the responses from them should be collected
or should I just handle them and notify the list when I receive them and what
they are?

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Binary only module overview

[Greg KH]

On Wed, Sep 26, 2001 at 10:58:35PM +0100, Alan Cox wrote:
> 
> Given the SSSCA we have to be very clear on this issue, and if its not clear
> I might be best to kill the entire uncertainty by not including the LSM
> patch in Linux until the US government returns to sanity

Or place some kind of markings on the symbols/functions that the LSM
code exports stating that these symbols/functions can only be called
from GPL licensed code.

But to do that, it would require the cooperation of all of the LSM
authors :)

thanks,

greg k-h

Re: Binary only module overview

[Alan Cox]

> Or place some kind of markings on the symbols/functions that the LSM
> code exports stating that these symbols/functions can only be called
> from GPL licensed code.

GPL_EXPORT_SYM is coming, has been discussed and tentatively agreed upon
so that we can for example have libraries of GPL code that are GPL module
only usable, while still exporting clear interfaces for nonfree users when
appropriate (eg device drivers)

Turning existing in kernel exports GPL_ all of a sudden is not going to
happen.

Re: Binary only module overview

[Greg KH]

On Thu, Sep 27, 2001 at 01:09:27PM +0100, Alan Cox wrote:
> GPL_EXPORT_SYM is coming, has been discussed and tentatively agreed upon
> so that we can for example have libraries of GPL code that are GPL module
> only usable, while still exporting clear interfaces for nonfree users when
> appropriate (eg device drivers)

So in your opinion, would making the LSM public functions use
GPL_EXPORT_SYM (when it is available) increase the odds of the patch
being accepted into the kernel?

thanks,

greg k-h

Re: Binary only module overview

[Alan Cox]

> So in your opinion, would making the LSM public functions use
> GPL_EXPORT_SYM (when it is available) increase the odds of the patch
> being accepted into the kernel?

Not sure - thats a Linus question

Re: Binary only module overview

[jmjones]

It has been implied that I am not being "politically correct" on this
list.  Yeah, I know.  That's only one realm of the many ways to be
correct.  Read on...

--------

I have been reading everything I can access about GPL in the last few 
days, and, while I'm no snake[1], it seems to me that everything Greg's
additional "restriction" adds is probably already covered in the GPL.
It also seems to my somewhat-logical-but-not-legal-mind that Linus MAY
be stretching the GPL if he explicitly allows binary modules.

However, the way I understand copyright laws (admittedly "vague"): it is up
to the copyright holder to defend his product, not anybody else.  If Linus,
or anybody else, wants to say "okay, I won't file suit against people who 
abuse me in this manner ... XYZ", that's his/her right.  It's less
restrictive, and (it would seem) compatable to GPL, IMHO.  No government
agency is going to SWOOP in and challenge his right to "fail to prosecute."

The way this percolates down, in my mind, is that GPL is a pretty darn
good document.  If LSM just GPLs it's code, it can still decide (imho), in
the ultimate event, to pursue any violations of its licensing.  How the
courts may act on the "legacy" of the licensor above... is up to the
court. 

I think it's perfectly acceptable to implement any *legal-technical* means
to hide your interface that you choose (data isn't covered by GPL, can
somebody create a data-based key that stops GPL'd code from working? 
Um...  maaaaybeeee (^_^).  Is a module "code" or "data"?  maaaaaaaaaaaybe)
I also think, from my reading, that you are violating the GPL if you add
other "special restrictions." 

Suppose I add "You cannot copy or distribute this portion of the source to
anybody for any reason." to the license?  Would that be legal?  Strictly
NOT is my reading.  It's restrictive and, therefore, not "compatible." The
proposed few lines MAY someday be interpretted as such.  *BANG*, you're on
legal-quicksand.

Greg (et al), I have great respect for your opinion... but you just may be
breaking GPL by adding a "further restriction."  If you're not adding a
"further restriction", leave it out... it's already there.  If some court
somewhere finds that this is not part of the GPL restriction, you break from
GPL and ... well, then it's anybody's game.

Get out your pencil, draw the logic diagram... you're making a logical
mistake.

Um, and logic and law are not necessarily compatible. :)

Trust GPL,
J. Melvin Jones

P.S. -- I've got an interface for similar purposes spec'd and partly
written.  It is NOT efficient at doing what LSM does, but IS more flexible
and allows more things to be done (stipulation).  For certain purposes
(mine), it may actually be faster, but IN GENERAL, the special case I'm
addressing is NOT similar to LSM.  It might be better for my and some other
solutions.  Majority solutions?  Who knows?  Admittedly, I now see problems
with implementation that were cited before when some of my ideas were
"trampled."  I'm tackling them, not dismissing them.

No worries, I don't have even the REMOTEST desire to be included in the
Kernel... I just want something that works and enhances Linux Security.

That being said, I have been advised and believe that I will HAVE to GPL
the kernel-side patches, the code, and everything "south" of the API, and
gladly will so do.  I will also release (least-restrictively-as-possible)
any parts necessary to connect to my MPI (module programming interface.) 
Anything on the OUTSIDE of my interface belongs to whomever created it
IMHO.  Let the court decide how Linus' and anybody else's interest should
be protected, IF they sue... (and, I think I'm doing the RIGHT thing, so I
sleep at night and don't worry) ... so be it.  If they can build a better
mousetrap...  hey, KEWL!!!! 

Is this a political thing instead of a technical thing?  I think it may
be, at least for Greg (et al.)  Make Linux better and you can sleep at
night.  Don't let somebody make it worse: you are honorable.  But where
does LSM fit into that?  I'd like to see it make things better, AND open
to non-open solutions for making it better.  GPL gives you,
imh-nonlegal-opinion, the full right to band the Copyright holders
together to pursue "legal recoarse" to fight abuse.  REAL ABUSE, not just
some political ideal. 

If you can't sleep at night because somebody else can use your code for
purposes OTHER than you envisioned... you shouldn't be writing Open
Software.  Isn't that the real purpose... to let the next guy stand on
your shoulders?


--------

[1] SNAKE -- the best sort of thing to hire when your garden is full of 
    rats.  A "SNAKE" is a REPTILE, a term which is also euphemistically
used, by J. Melvin Jones, to describe Insurance Agents, CPA's, and any
other people who "bridge the gap between the logical, the ethical, and the
legal."  No disrespect intended, EVER.  Sometimes COLD BLOODEDNESS is a
very useful attribute for consultants to mammals.


|>------------------------------------------------------
||  J. MELVIN JONES            jmjones@jmjones.com 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

Re: Binary only module overview

[Rik van Riel]

On Fri, 28 Sep 2001 jmjones@jmjones.com wrote:

> However, the way I understand copyright laws (admittedly "vague"): it
> is up to the copyright holder to defend his product, not anybody else.
> If Linus, or anybody else, wants to say "okay, I won't file suit
> against people who abuse me in this manner ... XYZ", that's his/her
> right.

But could he decide that for the code of one of the other
few-hundred copyright holders in the kernel ?

Note that even if Linus says he thinks something is ok,
people would still need to respect the rights of all the
other copyright holders to the kernel.

Interesting thing is that Richard Stallman never seemed
willing to take this leap and trust the GPL, but instead
requires people to sign over their copyright to the FSF
before code is accepted into a GNU project ;))

cheers,

Rik
-- 
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Binary only module overview

[jmjones]

On Sat, 29 Sep 2001, Rik van Riel wrote:

> On Fri, 28 Sep 2001 jmjones@jmjones.com wrote:
> 
> > However, the way I understand copyright laws (admittedly "vague"): it
> > is up to the copyright holder to defend his product, not anybody else.
> > If Linus, or anybody else, wants to say "okay, I won't file suit
> > against people who abuse me in this manner ... XYZ", that's his/her
> > right.
> 
> But could he decide that for the code of one of the other
> few-hundred copyright holders in the kernel ?
> 
> Note that even if Linus says he thinks something is ok,
> people would still need to respect the rights of all the
> other copyright holders to the kernel.
> 
> Interesting thing is that Richard Stallman never seemed
> willing to take this leap and trust the GPL, but instead
> requires people to sign over their copyright to the FSF
> before code is accepted into a GNU project ;))


Geeeez, I'm no snake, but my belief would be NO, except that anyone who is
operating under the license of another can't usually exceed that license.
On the other hand, he couldn't grant "special license" anyway.

It's a pretty interesting legal issue, but GPL seems, to me, to cover all
the avenues AND pretty effectively prohibits "more restrictive" licensing.
I have NO idea if that's "legal", but, if it falls in court, there may be
many other parts of GPL that fall at the same time.  And, hey, if MORE
restrictive licenses are allowed... GPL is full of holes the size of
trucks.  GPL is excellent... I wouldn't TOUCH it unless I
expected to be laughed out of court.

In my experience, contracts restrict.  Anything not prohibitted is
allowed, except where EVERYTHING is prohibitted and a specific list of
things are allowed.  GPL seems to use that: to allow nothing but what is
mentioned, and even imposes conditions on that.  What little training in
contract law (Insurance and Securities Industries) I have says either are
possible. The wording of GPL is about as tight as any contract as I have
ever read.

In essence: GPL prohibits ALL rights except where granted.  Ergo,
prohibitting another right is superfluous and dangerous within the
construction of the document.

Adding ANYTHING, even a comma, seems dangerous.  Linus can release his
interest, but I don't know if he can release ANYBODY ELSE's interest.  

OPINION: STICK WITH GPL,
J. Melvin Jones

> 
> cheers,
> 
> Rik
> -- 
> IA64: a worthy successor to i860.
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> Send all your spam to aardvark@nl.linux.org (spam digging piggy)
> 

Re: Binary only module overview

[Alan Cox]

> If you can't sleep at night because somebody else can use your code for
> purposes OTHER than you envisioned... you shouldn't be writing Open
> Software.  Isn't that the real purpose... to let the next guy stand on
> your shoulders?

Thats the BSD license. The GPL is where you get to stand on each others
shoulders and goon style climb over any future walls together


Alan

Re: Binary only module overview

[Crispin Cowan]

David Weinehall wrote:

>On Wed, Sep 26, 2001 at 12:17:37PM -0700, Crispin Cowan wrote:
>
>>That is not clear to me. I have been unable to find a definitive 
>>reference that states that is the case.  If so, it is problematic, 
>>because then every user-land program that ever #include'd errno.h from 
>>glibc is GPL'd, because glibc #include's errno.h, among other GPL'd 
>>kernel header files. Are you sure you want to declare nearly all 
>>proprietary Linux applications to be in violation of the GPL?
>>
>AFAIK, the glibc (and most other libraries) are LGPL rather than GPL.
>
It appears that while glibc is LGPL, it in turn #include's stuff from 
the kernel.  It more or less has to; otherwise glibc has to guess the 
format of data structures the kernel is going to export.

Greg is partially correct that this is a licensing issue that the glibc 
maintainers need to resolve. However, I am not convinced that they can 
resolve it on their own. I see only the following possible resolutions:

    * we all decide (an opinion) that #include some_gpl.h does not GPL
      the code doing the including
    * glibc changes its license to GPL, which would make it unpopular
      among proprietary application developers
    * Linux maintainers decide to change the license on the relevant
      header files to LGPL

If one of the above does not happen, then I think I can derive "false" :-)

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

Re: Binary only module overview

[Alan Cox]

>     * Clause 6: "... You may not impose any further restrictions on the
>       recipients' exercise of the rights granted herein."
> 
> Therefore, any additional constraints people may wish to impose, such as 
> Greg's comment in security.h, are invalid. When someone receives a copy 
> of the Linux kernel, the license is pure, vanilla GPL, with no funny 
> riders.*

Greg's comment states what is already stated by the GPL. It might not suit
your personal desire, but thats tough. The matter is one of "linking" - in
a legal not a technical sense and of what is and is not a derivative
work. If your code is a derivative work of GPL code then the GPL is
totally clear on the matter.

Alan

Binary only module overview

[Arjan van de Ven]

Hi,

I'm composing a list of all existing binary only modules, 
and I got to a list of 26 different modules; I undoubtedly forgot a few, 
so I hereby request feedback from people who know about modules I
left out, so that I can complete the list. (I do not really care about
modules that once existed for 2.0 or earlier and no longer exist for all
intents and purposes)

Greetings,
  Arjan van de Ven


Hardware drivers
----------------
4-Front		- soundcard drivers
Adaptec		- Fiberchannel cards
Agilent		- Fiberchannel cards
aureal		- driver for soundcard
Conexant	- winmodem driver
Emulex		- Fiberchannel cards
Highpoint	- lowlevel IDE driver + software raid
IBM		- All hardware networkdrivers for S/390
Lucent		- driver for winmodem
Motorola	- driver for winmodem
M-Systems	- flash chips
NVidia		- 3D driver for their hardware 
Olicom		- tokenring networkcard
PCTel		- winmodem driver
Philips		- webcam driver
Promise		- lowlevel IDE driver + software raid
Sigma designs	- driver for soundcard

Highlevel drivers
-----------------
Cisco		- IPSEC
Hewlet Packard	- High level security modules (LSM)
Intel		- IPSEC 
Netraverse	- Win4lin
SGI		- XFS cluster extensions
		- High level security modules (LSM)
Sistina		- GFS and cluster extensions for LVM
Veritas		- Filesystem and Software RAID clusterextensions
Wirex		- High level security modules (LSM)

Re: Binary only module overview

[Rasmus Bøg Hansen]

On Mon, 24 Sep 2001, Arjan van de Ven wrote:

> I'm composing a list of all existing binary only modules, 
> and I got to a list of 26 different modules; I undoubtedly forgot a few, 
> so I hereby request feedback from people who know about modules I
> left out, so that I can complete the list. (I do not really care about
> modules that once existed for 2.0 or earlier and no longer exist for all
> intents and purposes)

IIRC, vmware includes one or more kernel modules.

Rasmus

-- 
-- [ Rasmus 'Møffe' Bøg Hansen ] ---------------------------------------
ATA100 is another testimony to the fact that pigs can be
made to fly given sufficient thrust (to borrow an RFC)
                                               -Alan Cox
--------------------------------- [ moffe at amagerkollegiet dot dk ] --

Re: Binary only module overview

[Ignacio Vazquez-Abrams]

On Mon, 24 Sep 2001, Rasmus Bøg Hansen wrote:

> On Mon, 24 Sep 2001, Arjan van de Ven wrote:
>
> > I'm composing a list of all existing binary only modules,
> > and I got to a list of 26 different modules; I undoubtedly forgot a few,
> > so I hereby request feedback from people who know about modules I
> > left out, so that I can complete the list. (I do not really care about
> > modules that once existed for 2.0 or earlier and no longer exist for all
> > intents and purposes)
>
> IIRC, vmware includes one or more kernel modules.

Yes, but they do provide source, so they lie in a grey area.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Binary only module overview

[Andreas Steinmetz]

> IIRC, vmware includes one or more kernel modules.

They come as tarballs, complete as source, in addition to some precompiled
versions.



Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH

Re: Binary only module overview

[Anders Peter Fugmann]

Rasmus Bøg Hansen wrote:

> On Mon, 24 Sep 2001, Arjan van de Ven wrote:
> 
> 
>>I'm composing a list of all existing binary only modules, 
>>and I got to a list of 26 different modules; I undoubtedly forgot a few, 
>>so I hereby request feedback from people who know about modules I
>>left out, so that I can complete the list. (I do not really care about
>>modules that once existed for 2.0 or earlier and no longer exist for all
>>intents and purposes)
>>
> 
> IIRC, vmware includes one or more kernel modules.
> 
> Rasmus
> 
> 
Yes, but the modules are not binary-only. 

The sourcecode is in the package, although it is not GPL.


Regards
Anders Fugman

Re: Binary only module overview

[Dave McCracken]

--On Monday, September 24, 2001 19:08:27 +0200 Anders Peter Fugmann 
<afu@fugmann.dhs.org> wrote:

>> IIRC, vmware includes one or more kernel modules.
>>
>> Rasmus
>>
> Yes, but the modules are not binary-only.
> The sourcecode is in the package, although it is not GPL.

I believe they only provide source for an interface layer that can be 
compiled against a specific version of the kernel.  I think the core 
drivers are binary only.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmc@austin.ibm.com                                      T/L   678-3059

Re: Binary only module overview

[Alan Cox]

> IIRC, vmware includes one or more kernel modules.

Their kernel modules are GPL, although they let other stuff do icky things

Re: Binary only module overview

[Alan Cox]

> IBM		- All hardware networkdrivers for S/390

> Philips		- webcam driver
Compression for - the driver itself is free, and is usable without

> Sigma designs	- driver for soundcard
Mpeg card

Intel btw also have a binary only winmodem driver (HaM)

Motorola SM56 winmodem

Re: Binary only module overview

[Kai Germaschewski]

On Mon, 24 Sep 2001, Arjan van de Ven wrote:

> Hardware drivers
> ----------------
AVM	- CAPI drivers for their passive ISDN cards
          (Fritz!Classic, Fritz!PCI, Fritz!PnP, Fritz!PCMCIA,
           Fritz!USB)
          For most of the hardware open source drivers exist as well,
          lacking some functionality, like e.g. softfax

--Kai

Re: Binary only module overview

[Rick Haines]

On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:

> Sigma designs	- driver for soundcard

That's their NetStream 2000 DVD (mpeg/ac3) decoder.
There are reverse engineered (GPL) drivers for the Hollywood Plus.

As a side note, there are currently 4 misc minor numbers allocated to
the em8300 drivers (according to Documentation/devices.txt).  That's
fine for one card but the driver support up to 4 cards so we'd need 16
devices in that case.  Currently we're using major number 121.  Does
anyone have suggestions for moving over to official device numbers?

-- 
Rick (rick@kuroyi.net)
http://dxr3.sourceforge.net

I think the slogan of the fansubbers puts
it best: "Cheaper than crack, and lots more fun."

Re: Binary only module overview

[Greg KH]

On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> Highlevel drivers
> -----------------
> Hewlet Packard	- High level security modules (LSM)
> SGI 		- High level security modules (LSM)
> Wirex		- High level security modules (LSM)

For those interested in the current LSM licensing issues, feel free to
join the discussion on the linux-security-module-list:
	http://mail.wirex.com/mailman/listinfo/linux-security-module

The thread can be read online starting at:
	http://mail.wirex.com/pipermail/linux-security-module/2001-September/thread.html#2017
with the title:
	GPL only usage of security.h

thanks,

greg k-h

Re: Binary only module overview

[Casey Schaufler]

Greg KH wrote:
> 
> On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> > Highlevel drivers
> ...
> > SGI           - High level security modules (LSM)

License terms and release scheme for this work
have not been finalized. 

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 888.220.0607

Re: Binary only module overview

[Alan Cox]

> > > SGI           - High level security modules (LSM)
> 
> License terms and release scheme for this work
> have not been finalized. 

But from your comments on the LSM list we can guess

Re: Binary only module overview

[Casey Schaufler]

Alan Cox wrote:
> 
> > > > SGI           - High level security modules (LSM)
> >
> > License terms and release scheme for this work
> > have not been finalized.
> 
> But from your comments on the LSM list we can guess

Sure you can guess. That's all you'll be doing though.
As a representitive of a corporate entity it is important
that I not make promises that I can't keep. I would like
to provide all facilities under GPL or more liberal terms.
We have to deal with potential legal encumberances, and
that's a fact of corporate life. I can say that I want
to use GPL, that I plan to use GPL (which is true) but
I am required to provide notice that I may not be able
for legal, copywrite, or corporate poliy reasons to
commit to doing so. This is one of the disadvantages of
being a wage slave.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 888.220.0607

Re: Binary only module overview

[Steve Lord]

> Hi,
> 
> I'm composing a list of all existing binary only modules, 
> and I got to a list of 26 different modules; I undoubtedly forgot a few, 
> so I hereby request feedback from people who know about modules I
> left out, so that I can complete the list. (I do not really care about
> modules that once existed for 2.0 or earlier and no longer exist for all
> intents and purposes)
> 
> Greetings,
>   Arjan van de Ven
> 
> 

> SGI		- XFS cluster extensions

This is not something which is available yet.

and you can add:

Tricord		- filesystem,

the only public info about this appears here:

http://www.tricord.com/appliance/aggregation?PID=Detail.html&CID=5ecf5843151b4891af7924eb65d548fe&DID=b18e43e06c44406ea73ceedc7f1448f4

they do not advertise the fact that their hardware runs Linux too much.

Steve

RE: Binary only module overview

[Michael Leun]

Hello,

On 24-Sep-2001 Arjan van de Ven wrote:

> I'm composing a list of all existing binary only modules, 

> Hardware drivers
> ----------------
Samsung         - wireless lan driver (prism2 chipset, binary core with source
                  for interface layer)
                  see www.magiclan.com

-- 
bye,


Michael Leun

Re: Binary only module overview

[Nerijus Baliunas]

On Mon, 24 Sep 2001 12:40:44 -0400 Arjan van de Ven <arjanv@redhat.com> wrote:

AvdV> Hi,
AvdV> 
AvdV> I'm composing a list of all existing binary only modules, 
AvdV> and I got to a list of 26 different modules; I undoubtedly forgot a few, 
AvdV> so I hereby request feedback from people who know about modules I
AvdV> left out, so that I can complete the list.

Win4Lin both patches kernel and uses binary modules (www.netraverse.com).
Check Point FireWall-1 uses binary module (www.checkpoint.com).

Regards,
Nerijus

Re: Binary only module overview

[Brian Strand]

Arjan van de Ven wrote:

>Hi,
>
>I'm composing a list of all existing binary only modules, 
>and I got to a list of 26 different modules; I undoubtedly forgot a few, 
>so I hereby request feedback from people who know about modules I
>left out, so that I can complete the list. (I do not really care about
>modules that once existed for 2.0 or earlier and no longer exist for all
>intents and purposes)
>
The Znyx driver appears to have a binary-only core (the file znb/rlk.O 
(note the capital letter 'O')).

Regards,
Brian Strand

Re: Binary only module overview

[Greg KH]

On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> 
> I'm composing a list of all existing binary only modules, 

Argus System's PitBull for Linux modifies the kernel.  No source or
patches for these modifications can be found on the web, so I'm guessing
that it's closed source:
	http://www.argus-systems.com/

greg k-h

Re: Binary only module overview

[Mark Zealey]

On Tue, Sep 25, 2001 at 08:44:39AM -0700, Greg KH wrote:

> On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> > 
> > I'm composing a list of all existing binary only modules, 
> 
> Argus System's PitBull for Linux modifies the kernel.  No source or
> patches for these modifications can be found on the web, so I'm guessing
> that it's closed source:
> 	http://www.argus-systems.com/

Umm, is it me or is that totally against the GPL? Have you bitched at them about
this?

-- 

Mark Zealey
mark@itsolve.co.uk

UL++++>$ G!>(GCM/GCS/GS/GM) dpu? s:-@ a16! C++++>$ P++++>+++++$ L+++>+++++$
!E---? W+++>$ N- !o? !w--- O? !M? !V? !PS !PE--@ PGP+? r++ !t---?@ !X---?
!R- b+ !tv b+ DI+ D+? G+++ e>+++++ !h++* r!-- y--

(www.geekcode.com)

Re: Binary only module overview

[Ignacio Vazquez-Abrams]

On Tue, 25 Sep 2001, Mark Zealey wrote:

> On Tue, Sep 25, 2001 at 08:44:39AM -0700, Greg KH wrote:
>
> > On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> > >
> > > I'm composing a list of all existing binary only modules,
> >
> > Argus System's PitBull for Linux modifies the kernel.  No source or
> > patches for these modifications can be found on the web, so I'm guessing
> > that it's closed source:
> > 	http://www.argus-systems.com/
>
> Umm, is it me or is that totally against the GPL? Have you bitched at them about
> this?

IIRC, the GPL only talks about _modifications_of_ GPLed code, not
_modifications_made_to_. Argus is treading a line, but it may not be doing
anything illegal.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Binary only module overview

[Greg KH]

On Tue, Sep 25, 2001 at 08:09:47PM +0100, Mark Zealey wrote:
> On Tue, Sep 25, 2001 at 08:44:39AM -0700, Greg KH wrote:
> 
> > On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> > > 
> > > I'm composing a list of all existing binary only modules, 
> > 
> > Argus System's PitBull for Linux modifies the kernel.  No source or
> > patches for these modifications can be found on the web, so I'm guessing
> > that it's closed source:
> > 	http://www.argus-systems.com/
> 
> Umm, is it me or is that totally against the GPL? Have you bitched at them about
> this?

I have only talked to one of their resellers, who could not find a link
to the code anywhere.  I have not asked them directly.  I will go do
that right now.

thanks,

greg k-h

Re: Binary only module overview

[Roberto Nibali]

Hi Greg,

> > > Argus System's PitBull for Linux modifies the kernel.  No source or
> > > patches for these modifications can be found on the web, so I'm guessing
> > > that it's closed source:
> > >     http://www.argus-systems.com/
> >
> > Umm, is it me or is that totally against the GPL? Have you bitched at them about
> > this?
> 
> I have only talked to one of their resellers, who could not find a link
> to the code anywhere.  I have not asked them directly.  I will go do
> that right now.

If you're dealing with argus, ask straight for developers or technical
people not resellers. The second problem is that they ceased making
their
Pitbull LX product available for download on the web for some reasons.
Since I work with argus-system products sometime I got the chance of
still
having a copy of this huge tarball and I made a diff or their actual
changes
to the 2.2.19 kernel for you. Unfortunately I had to put it onto a non-
argus related development site and I will leave it there for the next 12 
hours. Grab it, analyse it and convince yourself that they actually go
quite into the direction of the LSM framework approach. Actually I
talked
to one of the argus technical guys about a possible port to the LSM
frame-
work and he said that they are going to look into it. Of course the lkm
with the real security functionality is binary only. Decide yourself ...

http://www.linuxvirtualserver.org/~ratz/argus.diff

Best regards,
Roberto Nibali, ratz

Re: Binary only module overview

[Greg KH]

On Tue, Sep 25, 2001 at 11:09:43PM +0200, Roberto Nibali wrote:
> 
> If you're dealing with argus, ask straight for developers or technical
> people not resellers.

I did just directly email them.  Thanks for letting me know.

> The second problem is that they ceased making their
> Pitbull LX product available for download on the web for some reasons.
> Since I work with argus-system products sometime I got the chance of
> still having a copy of this huge tarball and I made a diff or their
> actual changes to the 2.2.19 kernel for you. Unfortunately I had to
> put it onto a non- argus related development site and I will leave it
> there for the next 12 hours. Grab it, analyse it and convince yourself
> that they actually go quite into the direction of the LSM framework
> approach. Actually I talked to one of the argus technical guys about a
> possible port to the LSM frame- work and he said that they are going
> to look into it. Of course the lkm with the real security
> functionality is binary only. Decide yourself ...

Thank you for putting this up.  It looks like they are placing hooks all
through the kernel, much like the LSM patch does.

And since they are patching the kernel to provide hooks for their
security module, they should also release that security module source
code to remain legal.

Thanks again.

greg k-h

Re: Binary only module overview

[Roberto Nibali]

Hi Greg,

> Thank you for putting this up.  It looks like they are placing hooks all
> through the kernel, much like the LSM patch does.

Yep, and I reckon that they could port their security module to the
LSM one within one week. I mentioned it to Peter Loscocco at OLS 2001 
at the LSM BOF.
 
> And since they are patching the kernel to provide hooks for their
> security module, they should also release that security module source
> code to remain legal.

I don't know about GPL and kernel related rights but I can hardly 
imagine a company that has a B1 certified product not to care well
about their other products to be on the right side of the law. I 
can talk to them on thursday about this at the comdex/orbit showcase.
The outcome of your legality statement might be crucial for their 
future business.

BTW, I recall the HP Linux which IMO also violates the GPL then, doesn't
it? http://www.hp.com/security/products/linux/opensource/
Or does this differ in them providing the source code even for the LKMs
as opposite to argus which has binary only LKMs?

> Thanks again.

No problem, regards,
Roberto Nibali, ratz

Re: Binary only module overview

[Greg KH]

On Wed, Sep 26, 2001 at 12:14:06AM +0200, Roberto Nibali wrote:
> 
> I don't know about GPL and kernel related rights but I can hardly 
> imagine a company that has a B1 certified product not to care well
> about their other products to be on the right side of the law. I 
> can talk to them on thursday about this at the comdex/orbit showcase.
> The outcome of your legality statement might be crucial for their 
> future business.

Yes, the LSM licensing issue seems to be critical to a lot of people :)
Presently I am waiting for a response from WireX as to what their stance
is.

> BTW, I recall the HP Linux which IMO also violates the GPL then, doesn't
> it? http://www.hp.com/security/products/linux/opensource/
> Or does this differ in them providing the source code even for the LKMs
> as opposite to argus which has binary only LKMs?

Exactly.  It looks like HP provides the source code for everything
(someone tell me if I'm wrong here) while Argus looks like they only
provide the kernel patches and a compiled loadable module binary, under
a unknown license (at this time.)

thanks,

greg k-h

Re: Binary only module overview

[Roberto Nibali]

> Yes, the LSM licensing issue seems to be critical to a lot of people :)

I read the current evolvement of the LSM framework and its ongoing
licensing discussions with great affection and joy :) This is what
happens if too many third party vendors get interested in yet another
possiblity of selling their product under Linux legally ...

> Presently I am waiting for a response from WireX as to what their stance
> is.

Ok. I thought it had to be GPL anyway but then again I'm not too
familiar with the whole LSM "patch" yet. It seems as if there are
multiple licenses needed. [Well, that's what we have the MODULE_LICENSE
for then.]
 
> Exactly.  It looks like HP provides the source code for everything
> (someone tell me if I'm wrong here) while Argus looks like they only
> provide the kernel patches and a compiled loadable module binary, under
> a unknown license (at this time.)

I put their license on the page too. Enjoy the binary software license:
http://www.linuxvirtualserver.org/~ratz/argus-license.txt
 
Cheers,
Roberto Nibali, ratz

Re: Binary only module overview

[Greg KH]

On Tue, Sep 25, 2001 at 01:42:32PM -0700, Greg KH wrote:
> On Tue, Sep 25, 2001 at 08:09:47PM +0100, Mark Zealey wrote:
> > On Tue, Sep 25, 2001 at 08:44:39AM -0700, Greg KH wrote:
> > 
> > > On Mon, Sep 24, 2001 at 12:40:44PM -0400, Arjan van de Ven wrote:
> > > > 
> > > > I'm composing a list of all existing binary only modules, 
> > > 
> > > Argus System's PitBull for Linux modifies the kernel.  No source or
> > > patches for these modifications can be found on the web, so I'm guessing
> > > that it's closed source:
> > > 	http://www.argus-systems.com/
> > 
> > Umm, is it me or is that totally against the GPL? Have you bitched at them about
> > this?
> 
> I have only talked to one of their resellers, who could not find a link
> to the code anywhere.  I have not asked them directly.  I will go do
> that right now.

Argus has responded to me that their kernel patch is released under the
GPL (and will be placing it up on a sf.net site soon.)  However their
security kernel module that their patch uses is closed source.  So add
them to the closed source module list :)

As for the legality of modifying the kernel to provide hooks for your
closed source driver, I'm not going to argue that one, but I thought it
was forbidden.

thanks,

greg k-h

Re: Binary only module overview

[Alan Cox]

> As for the legality of modifying the kernel to provide hooks for your
> closed source driver, I'm not going to argue that one, but I thought it
> was forbidden.

Indeed.

Re: Binary only module overview

[Fabbione]

Arjan van de Ven wrote:
> 
> Hi,
> 

> Highlevel drivers
> -----------------

You can probably add mvfs ClearCase file system but I don't remember the
URL.

Cheers
Fabbione

-- 
Debian GNU/Linux Unstable Kernel 2.4.9
fabbione on irc.atdot.it #coredump #kchat | fabbione@fabbione.net

Re: Binary only module overview

[Edward S. Marshall]

On Tue, Sep 25, 2001 at 06:43:39PM +0200, Fabbione wrote:
> You can probably add mvfs ClearCase file system but I don't remember the
> URL.

http://www.rational.com/ is the corporate website, and the particular product
is at http://www.rational.com/products/clearcase/ .

The actual module is an implementation of the Rational (previously Atria)
ClearCase mvfs filesystem for Linux; it is composed of a source-available
translation layer, and a binary-only core.

One important note to mention: they only support Red Hat-supplied kernels;
there is a high chance of failure using it with a stock kernel, due to
changes in internal structures required by mvfs.

-- 
Edward S. Marshall <esm@logic.net>                        http://esm.logic.net/
-------------------------------------------------------------------------------
[                  Felix qui potuit rerum cognoscere causas.                  ]

Re: Binary only module overview

[Jes Sorensen]

>>>>> "Arjan" == Arjan van de Ven <arjanv@redhat.com> writes:

Arjan> Hi, I'm composing a list of all existing binary only modules,
Arjan> and I got to a list of 26 different modules; I undoubtedly
Arjan> forgot a few, so I hereby request feedback from people who know
Arjan> about modules I left out, so that I can complete the list. (I
Arjan> do not really care about modules that once existed for 2.0 or
Arjan> earlier and no longer exist for all intents and purposes)

Arjan> Greetings, Arjan van de Ven

Arjan> Hardware drivers ---------------- 

JNI - Fibre Channel cards: http://www.jni.com/Drivers/drivers2.cfm?OS=6

Can't seem to find any source there ;-(

Jes

Re: Binary only module overview

[Daniel Caujolle-Bert]

Hi,

Arjan van de Ven wrote:
> 
> Hi,
> 
> I'm composing a list of all existing binary only modules,
> and I got to a list of 26 different modules; I undoubtedly forgot a few,
> so I hereby request feedback from people who know about modules I
> left out, so that I can complete the list. (I do not really care about
> modules that once existed for 2.0 or earlier and no longer exist for all
> intents and purposes)
> 
> Greetings,
>   Arjan van de Ven
> 
> Hardware drivers
> ----------------
[...]
> PCTel           - winmodem driver

	This one is not really 100% binary only, it use
an modified version of serial.c kernel driver. Of course
it's freely available.

Cheers.
-- 
73's de Daniel, F1RMB.

              -=- Daniel Caujolle-Bert -=- segfault@club-internet.fr -=-
                        -=- f1rmb@f1rmb.ampr.org (AMPR NET) -=-

Re: Binary only module overview

[Arjan van de Ven]

Daniel Caujolle-Bert wrote:

> > Hardware drivers
> > ----------------
> [...]
> > PCTel           - winmodem driver
> 
>         This one is not really 100% binary only, it use
> an modified version of serial.c kernel driver. Of course
> it's freely available.

That I would call an obvious GPL violation... no discussion
about vague "interfaces", if you directly link serial.c 
(even modified) into a non-GPL .o file that's obvious....

Re: Binary only module overview

[Alan Cox]

> That I would call an obvious GPL violation... no discussion
> about vague "interfaces", if you directly link serial.c 
> (even modified) into a non-GPL .o file that's obvious....

I raised this one with Ted T'so (who wrote the serial.c they use) a long
time ago. Ted seemed happy for this to occur - and its kind of his code,
his business.

Re: Binary only module overview

[Nicholas Knight]

On Friday 28 September 2001 07:42 am, Alan Cox wrote:
> > That I would call an obvious GPL violation... no discussion
> > about vague "interfaces", if you directly link serial.c
> > (even modified) into a non-GPL .o file that's obvious....
>
> I raised this one with Ted T'so (who wrote the serial.c they use) a
> long time ago. Ted seemed happy for this to occur - and its kind of
> his code, his business.

Prehaps it'd be a good idea to (unofficialy) ask authors of drivers in 
the kernel that are thought to be GPL'd and not known to be under other 
licenses (BSD etc.), to (when possible) let the public know that 
they've granted some sort of license to a company/person to use that 
code in a binary-only module, so that people don't start accusing 
people of blatant GPL violations if they happen to notice. serial.c 
would be a perfect example of something that could be construed as a 
blatant violation and people might start yelling at the company and 
others about it, and it might make the company less willing to support 
Linux *at all*.

I'd prefer that there was no such thing as a binary-only module, but 
IMO binary-only is better than no support whatsoever. And if people 
start yelling at companies for using something they may have a 
legitimate license for, those companies may wonder what the point is in 
supporting Linux at all.

(This isn't directed at Arjan van de Ven, he just stated obvious facts, 
he didn't go off half-cocked at anybody :)

Re: Binary only module overview

[Albert D. Cahalan]

Nicholas Knight writes:

> I'd prefer that there was no such thing as a binary-only module, but 
> IMO binary-only is better than no support whatsoever.

If the module works in user-space Linux, problem solved.

Re: Binary only module overview

[Daniel Caujolle-Bert]

Alan Cox wrote:
> 
> > That I would call an obvious GPL violation... no discussion
> > about vague "interfaces", if you directly link serial.c
> > (even modified) into a non-GPL .o file that's obvious....
> 
> I raised this one with Ted T'so (who wrote the serial.c they use) a long
> time ago. Ted seemed happy for this to occur - and its kind of his code,
> his business.

	I don't understand you here, sorry, complicated sentence are
hard for me :<. Anyway, i am one of the one who hacked and old version
of this driver for 2.4.7+, of course i can understand it's a GPL
violation,
but like another guy wrote (sorry, i haven't his name liying around),
binary only module is *almost* better than no support.
	
Cheers.
-- 
73's de Daniel, F1RMB.

              -=- Daniel Caujolle-Bert -=- segfault@club-internet.fr -=-
                        -=- f1rmb@f1rmb.ampr.org (AMPR NET) -=-