>> alsalib is released under the GPL. hence, any applications that to use
>> it must be under the GPL. since such an application would clearly be
>> utterly designed around the alsalib and alsa kernel API, you could not
>> use dynamic linking to circumvent this.
>
>As alsalib is released under the LGPL, apps that use it don't need to be
>under the GPL.
Oops. The source code is actually under mixed licenses. I looked at
alsa-lib/src/output.c, for example. Looking inside alsa-lib/src/*/*.c,
it seems to be all LGPL.
>The issue then becomes whether a closed source driver can be linked in with
>an LGPL library. The LGPL seems to split uses of a library into either
>"works that use the library" or "works that are derived from the library". I
>assume that a user space device driver would fall into the first category,
>as the driver does not include any library code. Therefore, according to
>section 5 of the LGPL, the LGPL does not have to be applied to the device
>driver.
yes, a user space device driver would be a work that used the
library. more precisely, it would be a library used by an LGPL'ed
library when an application used the LGPL'ed library.
>However, unless it can be argued that the closed source driver falls under
>the scope of the following exception in the GPL...
>
> However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on) of
> the operating system on which the executable runs, unless that
> component itself accompanies the executable.
I don't see a user-space device driver that uses alsa-lib being
anything that was intended to be a part of this set. The intent was to
cover standard libraries. Since your code would be a driver
>...it will not be possible to use a GPL licensed app with alsalib and the
>closed source driver.
If Jaroslav fixes the licenses to be consistently LGPL, I don't see
why you could not release your code as a closed source thing. An
application that uses your driver would make calls to alsa-lib, which
would dynamically load your code (as a shared object), and execute
it. Its OK for alsa-lib to do that, since its LGPL and does not
require that your code be LGPL or GPL. And its OK for the app, even if
its GPL'ed, since it doesn't use your library's API: if the user
provides a different ~/.asoundrc file, then their program won't use
your code at all, but will use the "regular ALSA drivers". Hence, the
application doesn't depend upon (arguably, doesn't even "use") the
functionality of your code, and so its GPL'edness isn't relevant.
The dynamic-loading of a backend shared object via a GPL'ed API is a
standard "workaround" for the GPL right now. v3.0 may change or
reinforce this - I'm not sure. But if someone writes code that doesn't
explicitly call any function in your driver (i.e. just regular ALSA
API stuff), then there is no way to argue that their work is connected
to yours in any way. It can easily be demonstrated that their program
runs with no loss of function without your code, other than the fact
that it will not work on certain pieces of audio h/w. My impression
has long been that this doesn't invoke GPL-style "connections" between
the works.
Also, keep in mind that even if this were not true, since its their
GPL'ed program that uses (or is a "derivative" of) your work, its up
to you to define the terms of use. If you allow people to run GPL'ed
apps that link (one way or another) to your code, thats your
choice. The GPL doesn't work backwards: you can't write a GPL program
that uses an non-GPL'ed library and demand that the library be
GPL'ed. Thats because of the direction of derivation; you clearly can
write a GPL'ed library that demands that its users be GPL'ed.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
