From alsa-devel-owner@alsa.jcu.cz  Sun Feb 28 14:55:48 1999
Received: from neutrino.kek.jp (root@neutrino.kek.jp [130.87.218.139])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id OAA09908
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 14:54:00 +0100
Received: from lbscissors.kek.jp (root@lbscissors.kek.jp [130.87.218.173]) by neutrino.kek.jp (8.8.8+2.7Wbeta7/3.4W3) with ESMTP id WAA28411 for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 22:53:58 +0900
Received: from lbscissors.kek.jp (really [127.0.0.1]) by neutrino.kek.jp
	via in.smtpd with esmtp (ident sharkey using rfc1413)
	id <m10H6fN-000sLNC@lbscissors.kek.jp> (Debian Smail3.2.0.102)
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 22:53:57 +0900 (JST) 
Message-Id: <m10H6fN-000sLNC@lbscissors.kek.jp>
To: alsa-devel@alsa.jcu.cz
From: sharkey@ale.physics.sunysb.edu
Subject: Re: (SB Live) Free drivers or not? (fwd) 
In-reply-to: Your message of "Sun, 28 Feb 1999 11:02:29 +0100."
             <Pine.LNX.3.96.990228104206.11253B-100000@entry.jcu.cz> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Feb 1999 22:53:57 +0900
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

> ALSA would have to accept non-free code (modules) or to accept only GPL
> code (current status). The situation that Linus has given permission for
> non-free modules is for me new (but this allows probably existence of OSS
> commercial drivers). This also means that if we include ALSA driver to
> the official kernel, we won't possible to restrict to add a non-GPL code.
> I hate it.
> 
> If my assumptions are well, there is only one way for future - to accept
> non-free kernel modules for ALSA code, too. I hope that I'm wrong with my
> assumptions or I hope that there must be also another way.

If a company were to make a binary kernel module that depended on the ALSA
modules, I don't think you could legally prevent that.

What that company distributes is a .o file which (supposedly) contains no
GPL'd code itself.

In order to link, the symbol names need to match, but it's not clear to me if
the symbol names alone are protected by copyright.  If symbol names are
copy written, then the Wine project could be in trouble, but I don't think
that's the case.  A company could manage to produce a binary file without
actually linking in or compiling any GPL'd sources.  (including headers)

That .o can be inserted into a running kernel, as permitted by Linus.  If
ALSA is also installed in that kernel, it's not clear to me if that module
is is linked to ALSA or not.  It's enough of a grey area that attempting to
enforce it in court would be difficult.


But attempting to enforce this legally may not be the best course of action
anyway.  I think its more important to educate ALSA users about the limitations
of binary modules.  Linus has made his feelings about binary modules clear.
He does not forbid them, but he won't lift a finger to support them.  If he
wants to change the kernel in a way that breaks a binary module, he does
so without blinking.

If Jaroslav wishes to adopt a similar policy, I think this would be the most
reasonable solution.  Make it clear to all parties that, if Creative Balls*
were to release a binary driver for ALSA 0.3-pre4, that this module may not
work with 0.3-pre5.

If enough people understand that the binary drivers will be unstable,
frequently incompatible, and generally inferior, then Creative's release won't
matter, because no one will use it and there will truckloads of people
requesting the source.  If the community is unified enough, the source might
eventually be relicensed under the GPL.  That will happen when the perceived
financial loss due to the open source drivers will be less than the perceived
financial gain due to increased hardware sales.  It's hard to know where that
threshold is, because it depends highly on the mindset of the individuals
calling the shots.

Eric

* Creative Balls is a hypothetical, fictitious company.  Any resemblance to
  to any actual company is purely coincidental.


