13 Nov
2002
13 Nov
'02
3:54 a.m.
<quote who="Mark Knecht">
I do not see how a company could afford to invest
in this area, short of
staying closed-source. Very difficult for them, so no wonder there are few
companies calling Linux developers.
Another difficulty with the GPL its somewhat sketchy legal basis. (OT for
LAD... Google if you want to know more).
I've noticed that Dual licencing GPL/Commercial seems to fit in with the
corporate mindset, however. (e.g. Mysql). Ardour/Libardour could go this
route if all the developers desired it.
---
Andrew W. Schmeder
13 Nov
13 Nov
12:09 p.m.
New subject: [linux-audio-dev] image problem
Another difficulty with the GPL its somewhat sketchy
legal basis. (OT for
LAD... Google if you want to know more).
the GPL is a contract freely entered into by the copyright owner and
the licensee. if the contract is held to be invalid, there is no
contract. at that point copyright law denies everyone except the
copyright holder any rights (except fair use) regarding the copyright
work.
i suppose you could call this sketchy. or not. ymmv.
I've noticed that Dual licencing GPL/Commercial
seems to fit in with the
corporate mindset, however. (e.g. Mysql). Ardour/Libardour could go this
route if all the developers desired it.
unlikely, but not impossible.
--p
12:51 p.m.
New subject: [linux-audio-dev] image problem
Hi,
To be clear, I was in no way suggesting that I thought Paul should change
his licensing terms in any way. I'm just interested in exploring the
underlying reasons why there are not more Linux applications available at
the retail level.
I personally think that this topic is interesting and enlightening. It is
(in some small way) about Linux Audio because we can discuss audio
applications. If people want this to go off line or can suggest a better
forum, please speak up.
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?
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?
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.
Thanks,
Mark
-----Original Message-----
From: linux-audio-dev-admin(a)music.columbia.edu
[mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Paul Davis
Sent: Wednesday, November 13, 2002 8:09 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] image problem
Another difficulty with the GPL its somewhat sketchy
legal basis. (OT for
LAD... Google if you want to know more).
the GPL is a contract freely entered into by the copyright owner and
the licensee. if the contract is held to be invalid, there is no
contract. at that point copyright law denies everyone except the
copyright holder any rights (except fair use) regarding the copyright
work.
i suppose you could call this sketchy. or not. ymmv.
I've noticed that Dual licencing GPL/Commercial
seems to fit in with the
corporate mindset, however. (e.g. Mysql). Ardour/Libardour could go this
route if all the developers desired it.
unlikely, but not impossible.
--p
1:24 p.m.
New subject: [linux-audio-dev] image problem
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?
alsa-lib is LGPL'ed, as is libjack. proprietary software can use these
libraries with no implications for their own code. if they choose to,
or need to, make changes in the LGPL'ed library code, those changes
must be made available under the LGPL.
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?
not unless they have lawyers who don't understand this stuff.
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.
a web page on the ardour site says:
"Your participation in the development and use of Ardour can help
bring to the audio world the same kinds of benefits that open source
development have accrued to the world of web servers. The most
widely use web server ("apache") contains code written by hundreds
if not thousands of people, and has been subject to continual
evolution and improvement. By contributing cash, comments, insight,
code, feedback or even just enthusiasm, you will help keep the
project moving forward towards a day when the best DAW is open for
everyone to study, improve and most of all, use and enjoy."
*that's* what "open" means to me. i don't care how good ProTools (or
Nuendo or Paris or ...) is - i could always find ways to make it
better if i had the source code. the same applies to almost ever other
proprietary audio software out there (1). but i can't get the source
code, so part of the promise of what we are doing here is to create
the necessary cultural artifacts necessary to move at least some
significant chunk of the audio software field towards this kind of
"open".
yes, it will be very hard to make (significant) money via traditional
retail channels with this sort of stuff. thats OK, i think.
--p
(1) there are a few exceptions. a recent one might be the Native Instruments'
FM7, which strikes me as just about perfect in every way.
1:26 p.m.
New subject: [linux-audio-dev] image problem
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!
7844
days inactive
7844
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
4 participants
participants (4)
-
Andrew W. Schmeder -
Kai Vehmanen -
Mark Knecht -
Paul Davis