From alsa-devel-owner@alsa.jcu.cz  Thu Jan 14 01:21:06 1999
Received: from sunu450.rz.ruhr-uni-bochum.de (sunu450.rz.ruhr-uni-bochum.de [134.147.222.33])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id BAA13368
	for <alsa-devel@alsa.jcu.cz>; Thu, 14 Jan 1999 01:20:59 +0100
Received: (qmail 29148 invoked from network); 14 Jan 1999 00:20:55 -0000
Received: from dialppp-3-130.rz.ruhr-uni-bochum.de (HELO localhost) (mail@134.147.3.130)
  by mailhost.rz.ruhr-uni-bochum.de with SMTP; 14 Jan 1999 00:20:55 -0000
Received: from brinkmds by localhost with local (Exim 2.05 #1 (Debian))
	id 100ZRV-0001XN-00; Thu, 14 Jan 1999 00:11:17 +0100
Message-ID: <19990114001115.A680@ruhr-uni-bochum.de>
Date: Thu, 14 Jan 1999 00:11:15 +0100
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: alsa-devel@alsa.jcu.cz, rutger@spin.m38c.nl
Subject: Re: as if to prove my point ...
References: <19990113222217.B2545@spin.m38c.nl> <Pine.LNX.3.96.990113223931.19441A-100000@entry.jcu.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.3.96.990113223931.19441A-100000@entry.jcu.cz>; from Jaroslav Kysela on Wed, Jan 13, 1999 at 10:41:12PM +0100
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, Jan 13, 1999 at 10:41:12PM +0100, Jaroslav Kysela wrote:
> On Wed, 13 Jan 1999 rutger@spin.m38c.nl wrote:
> 
> > [snip]
> > > 
> > > Jacob Crawley contacted me directly and we are looking for way howto
> > > support ALSA driver development for SB Live which should be acceptable
> > > by both sides. Looks that Creative can release some code under free
> > > license (it willn't be probably GNU GPL, but something like Netscape
> > > agreement for Mozilla). Main problem should be that Creative is thinking
> > > about release only some library for SB Live - this should cause unwanted
> > > trouble with different kernel versions :-((
> > > 
> > > 							Jaroslav
> > 
> > On news://news.3dfx.com/glide.linux something similar was going on: a
> > company wanted to create driver but didn't want to release source
> > code, and then the next thing was suggested which seems as a workable
> > solution:
> 
> Yes, this is really useable, I'm thinking about this solution (but in
> last sort)..

Note that you are not allowed to distribute a binary which sources are
partly GPL and contains such an object file. This would be a clear violation
of the GPL conditions, just for example requirement 3 (availability of
source code).

I don't see this as viable option for Linux development, but maybe I
misunderstood the original intentions.

Rutger wrote:
>  With these properties, you can make a SINGLE binary .o file
> that can:
>
>        a) Be `wrapped' with the appropriate kernel
>           functions and be used by FBcon
>        b) Be `wrapped' with KGI and used by GGI's kernel side.
>        c) Be linked into a shared library (ie MesaGL)
>        d) Be directly linked into a program (ie demos)

Either of these could only be done locally, nobody would be allowed to
distribute the resulting work as a whole, which makes it pretty useless for
Linux, if you ask me (as a member of the biggest Linux distribution, see my
signature).

Down this road lies madness. In Debian, we have to cope with hundreds of
licenses and copyrights, and I know that hardly anyone would touch such an
object file without source (not to speak of the security issues, including a
binary only object file in the kernel).

Marcus

-- 
"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

