Ossi Niiranen wrote:
The source code distribution of the package we reviewed does not seem to include the hdspm.h file you refer to below nor the UCM files. Does that mean the distribution is in some way "broken"?
No, I just used whatever alsa-lib I had lying around, about 1.0.24.
Ours did include also the sndop-mixer files which seem to be licensed under the GPL as well (although at least one of them does not necessarily warrant copyright protection as it is just a few lines).
I just searched for "GNU General"; this string isn't in these files. I'm happy to see that your research is more thorough. :-)
You made some generic comments in your email about why the GPL licensing is not an issue. If you have the time and the interest (there is obviously no obligation), I'd wish to take that a bit further into a file specific analysis (as we need certainty on a file level to be able to see there is no risk).
OK
For example, you say that aserver is "separate". Does that mean it is not shipped with the Alsa library? The impression I got from another response to my earlier post was that it is a legacy technology but still shipped with the library. If that's the case, I could not simply say that there are no GPL issues without further information on how this legacy tech is used.
The aserver executable is shipped _with_ the ALSA library, but it is not part of the library itself; applications that use the ALSA library do not use aserver directly.
The ALSA library offers an API that allows application to access sound devices. Furthermore, the library contains several plugins that implement the actual access to specific devices, as well as other plugins that modify the sound data (e.g., sample rate conversion) and redirect the result to another plugin.
In most cases, the plugin at the bottom of this stack is the "hw" plugin which interfaces with the ALSA drivers in the kernel.
There are the "shm" and "share" plugins that use sockets to talk with the aserver program, which runs as a separate process and also uses alsa-lib to access the actual sound device. The goal of this is to allow multiple programs to share this sound device.
Applications that link to the ALSA library use only the public API and typically do not know which plugin(s) are used to implement the device; the plugin configuration is read by alsa-lib from some machine-specific .conf files. (I wrote "typically" because it is possible for applications to create their own configuration from scratch.)
Nowadays, the plugins that use aserver are considered legacy because the dshare and dmix plugins allow the same sharing without having to run a separate server program.
In conclusion, applications that use alsa-lib are not "derived from" or "based on" the aserver program (in any interpretation of these clauses); this falls clearly under the "mere aggregation" clause of the GPL.
include/sound/asound.h include/sound/asoundef.h include/sound/asequencer.h
These files are copies of the respective kernel files and define the interface between the kernel and the hw plugins.
include/sound/asound_fm.h include/sound/emu10k1.h include/sound/hdsp.h include/sound/sb16_csp.h
These files are copies of the respective kernel files and define interfaces that applications can use to directly access certain hardware-dependent parts of these drivers.
The ALSA library uses only the system calls defined in these kernel headers, so it is not derived from the kernel.
m4/attributes.m4
Parts of this file are copied into the configure script when running Autoconf. This falls under the Autoconf exception.
alsa-lib/test/latency.c alsa-lib/test/oldapi.c alsa-lib/test/playmidi1.c
The test programs are neither used by nor shipped with the compiled alsa-lib.
*.alisp
As far as I can tell, these files are not actually used anywhere.
Regards, Clemens