Re: [linux-audio-dev] Re: proposed initial DTD for LADSPA-gui-xml .. licensing issues ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: proposed initial DTD for LADSPA-gui-xml .. licensing issues ...
From: David Olofson (david_AT_gardena.net)
Date: Mon Nov 27 2000 - 03:05:28 EET


On Sunday 26 November 2000 17:28, Benno Senoner wrote:
[...]
> If the virtual studio studio API will become reality someday, then
> it will be obvious that the code will be LGPL.

If there will be proprietary, closed source applications by then. Who
knows? If we get the modularity stuff right, we may kill them off,
simply because we provide the same or better performance for free
(and Free!). This won't happen in the next few years, though. (I hope
I'm wrong.)

> Of course we could say "the API specs are fully open , so
> Steinberg, Emagic,<place your commercial firm here> write your own
> implementation based on the specs"

<unforgiving>
Well, yeah, that's what we get all of the time. "Open" standards,
where we're not even allowed to use the header files... Why should we
be any better?
</unforgiving>

Seriously, how about LGPLed headers, but GPL for the rest? Prevents
people from stealing our code, while allowing them to use our
definitions for less risk of incompatibilities.

(Hey, what happens if plugins and stuff don't work properly with
Cubase/Linux!? Right, *Linux* gets a bad reputation. Hint: Seen
Netscape?)

> But this does not make sense, since this would lead to N different
> implementations (possibly closed source, with bugs and with
> incompatibilites among the different versions), plus it would not
> motivate commercial software manufacturers very much to get into
> the linux market. (one of the main hurdles to enter the linux
> market is that there are almost no standards in certain areas, plus
> if there are some, their implementation is possibly GPLed thus
> "unusable" by the commercial developer)

*Having* some standards in the first place helps a lot, and LGPLing
the definitions (but not our implementations) should basically solve
the problem. Looking at what you have to deal with to get real
performance from Windows, we're already *saving* time for them at
that point.

> It's not about 1-2 days worth of programming time, it's about
> keeping a single codebase where everyone can contribute without the
> interoperability mess.
> (unfortunately we are living in a real world
> where the implementations seldom follow the standard with 100%
> accuracy, see HTML browsers as an example :-) )

Not really fair; the HTML mess was created mainly by Netscape and
Microsoft fighting a very nasty war that the developers and users
still have to pay for...

However, you still have a point there; the implementations are where
the majority of the bugs get in...

> And it would not be a bad thing being able to pool the expertise of
> the leading pro-audio software manufacturers by letting them
> contribute to LGPLed audio development libraries.

Also a good point.

> It's your code so you can do what you want with it , but my take is
> to place as few barriers or ease as much as possible the migration
> from audio apps from the win/mac world to the linux platform,
> regardless if the apps are commercial or free.

Freeware and shareware apps spring to mind here; we don't really want
to make life harder for the authors of those. (Especially not thef
reeware guys - they're just slightly misguided as to what "free"
means. ;-)

> And commercial companies are certainly not going to sell a
> ladspa-gui library to the enduser. (and profit from it)
> At max if the lib is LGPL , they will use it, report eventual bugs,
> enhance it to suit their needs and contribute the code back to the
> community. (which is what the LGPL requires you to do).

Yep. Seen in that perspective, it even looks like we could *benefit*
from LGPLing our code. (Works for SDL and many other projects.)

> And even if the commercial company does not contribute back
> anything (to the codebase), by porting its commercial protucts to
> Linux, it will help to increase the linux-audio userbase which is
> IMHO very valuable, since it will in turn fuel develompent, etc
> etc.
> (I saw similar quotes from Linus where he talked about in what ways
> closed source apps running on linux can be beneficial to the whole
> linux wold )

Yes... OTOH, the audio users are a relatively small fraction of the
total computer user base. Then again, at least in the C64 and Amiga
demo and game programming scenes, one could see a very clear
connection between code and music. It seems to be somewhat relevant
to "normal" musicians as well, but I have no statistics on that...

(The problem with non-programming users is that they attract mainly
closed source software developers, while Free/Open Source developers
are generally more concerned about coding things they use themselves,
and less with the potential user base.)

> Paul, I'd like to know what the future linux-audio scenario would
> look like in your eyes ? (from the free-apps / commercial app
> standpoint)
>
> I'd like to live in a 100% opensource world too, but that is not
> going to happen anytime soon.

No. The question is if encouraging closed source applications of this
kind is going to *help*. I think it could, but I'm not sure.

> We have simply not the manpower (the knowledge would be less a
> problem :-) ), to reproduce all these sophisticated audio apps in
> existence, so we will live in a mixed opensource / commercial world
> for some more time.

I'm not so sure about that. There is certainly manpower enough for
*some* kind of code, but currently it seem that the audio community
is too small. However, we have the advantage of being able to share
code, which saves a great deal of time, even if we're not really
cooperating. And that's *without* an advanced plugin API, or a ReWire
style system. Things might change when we really get started.

> The only thing I'm concerned about, is that developers
> (regardless of their race, skin color, opensource or commercial
> nature), should encounter as few hurdles as possible when
> developing on the linux audio platform.

Yes, that's a good thought, as long as we don't "waste" too much time
serving people that are basically looking forward to make money on
the same things that we hack for free...

[...]
> PS: I was wondering who of the LAD-ers is more for keeping the
> audio development/infrastructure LGPL or who would opt for going
> GPL ? (I'm not talking about opensource apps because GPL is the way
> to go here, while the LGPL does not make sense in this case )

Despite my doubts about closed source software in a Free/Open audio
environment; at this point it has to be

        ++LGPL;

Apart from being compatible with closed source applications and
plugins, it's also slightly more compatible with other licenses than
(L)GPL.

//David

.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Nov 27 2000 - 05:53:49 EET