13 Nov
2002
13 Nov
'02
1:26 p.m.
On Wed, 13 Nov 2002, Mark Knecht wrote:
Let me ask another question in this area. Could
someone explain the
implications of GPL/LGPL WRT proprietary applications that interface to Alsa
& Jack, along with their incumbent support programs like kaconnect and
qjackconnect?
Both ALSA (alsa-lib, ie. libasound) and JACK (libjack) are licensed under
LGPL and thus allow their use even from proprietary applications.
Btw; ecasound's control interface (EC) is licensed under LGPL (recently
changed), so it's possible to write closed-source apps that use
ecasound as the audio engine. Other parts of ecasound are
still under GPL, so if you want to improve or extend the audio
engine, you'll have to release your changes under GPL.
If Jack and Alsa were pushed in technical business
development circles as
a way for Company A to enter the Linux market and be able to work together
with other existing applications, do the GPL/LGPL licenses of Alsa & Jack
create issues for Company A's proprietary code base?
No. Glibc is also LGPL licensed, so if there were any problems with using
LGPL libraries from closed-sourced apps, this would affect _all_
applications that run on Linux.
I see the open nature of Linux as best exemplified
in the lower level
portions of the audio stack, and less so at the application level for the
reasons we've been discussing. As a person who is in business, but not in
this area, I have suspicions that these are the issues that are keeping
retail applications out of the Linux markets.
At least I wouldn't mind if some commercial entity used ecasound in their
product. I would get improvements and fixes to the engine code and they
could keep the interface to themselves. I'm fully content using the
user-interfaces that are already available for ecasound, so this would be
a win-win situation for me. Of course, a completely different thing is
whether anyone wants to use ecasound...:)
--
http://www.eca.cx
Audio software for Linux!