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!
