From alsa-devel-owner@alsa.jcu.cz  Fri Jan  8 20:56:42 1999
Received: from cyphyn.219.org (nwhn-sh19-port17.snet.net [204.60.209.17])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA17259
	for <alsa-devel@alsa.jcu.cz>; Fri, 8 Jan 1999 20:37:34 +0100
Received: from localhost (emng@localhost)
          by cyphyn.219.org (8.8.4/8.8.4) with ESMTP
	  id OAA00099 for <alsa-devel@alsa.jcu.cz>; Fri, 8 Jan 1999 14:42:29 -0500
Date: Fri, 8 Jan 1999 14:42:29 -0500 (EST)
From: Fred Floberg <emng@geocities.com>
To: alsa-devel@alsa.jcu.cz
Subject: Drivers from high-end card makers (was Re: serial midi)
In-Reply-To: <199901081901.OAA32718@cyphyn.219.org>
Message-ID: <Pine.LNX.4.05.9901081420370.9-100000@cyphyn.219.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list




On Fri, 8 Jan 1999 golinvaux@benjamin.net wrote:

> Suggestion :
> 
> as some companies insist on having a NDA signed OR wish to develop their own
> Linux drivers (we've been talking about Yamaha DSP Factory and CreamWare
> Pulsar before which BTW are great cards), would it be possible to segment
> the ALSA directories for various licenses... One could try to convince high
> end card makers that ALSA is better than OSS to support their card
> functionalities (and it IS the truth) and have them make the ALSA driver on
> their own...
> 
> Also, other licenses could lead us to code drivers but not being able to
> release the source code... It would be a pity not to release drivers
> anyway..
> 
This sounds very much like what is done in xanim: Certain proprietary video
codecs are supplied in rel-obj form only and are linked into the xanim app at
compile time. I'm pretty sure that xanim itself retains a GNU CopyLeft type
of copyright in spite of the fact that some of the video codecs are under an
NDA. I haven't been to the xanim webpage in a very long time (I don't even have
the URL handy) so I'm going from memory here...

One thing that may give trouble, technically speaking, is that a driver in
object code form may cause kernel symbol version errors if not used with the
same version of kernel that it was compiled on, no?

If Biff's Super Duper Screachboxes, Inc. writes a driver for 2.0.36 and users
want to upgrade their kernels to a newer version, they may have to wait for
Biff, Inc. to supply a driver compiled under that kernel version. And if Biff, 
Inc. no longer wishes to support ALSA they're stuck.

Or is it really safe to assume that an object module will keep running on future
kernels?

Fred



