[linux-audio-dev] New form of GPL licence that protects Linux from proprietary world [was: New powermacs?]

Ivica Bukvic ico at fuse.net
Sat Jun 21 22:30:01 UTC 2003


> I really don't see this as a problem.

Do you mind saying why?

The way I see it is it could be possibly because it feels good for a
developer to see that the interest in their creation is increasing
beyond the confines of the original platform, which certainly is good
for the developer as an individual, but does not do as much for Linux
overall (I am putting a big * since in your case we are talking about a
lib, please see below). Sure, a contributor from another platform might
contribute a system-independent improvement, but then again they might
only (and perhaps more likely) provide platform-dependent improvement,
which might not transfer so well back into Linux version (obviously
assuming that it was originally developed for Linux).

OTOH, if let's say theoretically the user base eventually tips in other
OS's favor (meaning majority of users are on a different platform than
the one it was originally designed for), then the project might
eventually abandon original OS altogether. This is again, assuming that
the nature of the project demands some kind of system dependence.

----

*Obviously in your case, there is no need for system dependence since we
are talking about a library, but in the case of an app like Ardour, this
might be an issue. So, perhaps having libraries cross-platform
compatible would encourage new avenues of porting apps from other OS's
into Linux, but the same could not be said for the apps themselves (this
again being an over-generalization).

The reason I am bringing this up is because in the studio where I work
(part of an university), I had this short window of opportunity when
Macs were getting way behind Wintel machines (and Wintel machines were
not an option) to introduce Linux, which I did. However, with the
appearance of OS X shortly thereafter, the Linux adoption has come to
standstill, primarily because a majority of the software studio was
using was soon ported to OS X, and Linux lost its unique appeal. Hence,
we now have only one Linux box in the official studio, while I use
another completely unrelated lab with 5 Linux boxes to teach my "Linux &
Multimedia" class.

----

Also, in response to Tim Hockin who mentioned:

>I guess I don't see it as a problem.  Forcing people to use this or
that
>software is exactly what GPL is AGAINST.  Use whatever works for you.

I don't see how would that go against GPL. If anything, I see my
proposal as a GPL-offspring since it has a lot in common with the whole
issue of using closed-source drivers (i.e. nvidia's or ati's) which
taints the GPL nature of the kernel. By the same token, using the GPL'ed
software on top of proprietary framework to me seems also a kind of a
tainted approach to the whole issue. I know that this comparison is a
bit far-fetched, but not completely unrealistic.

Think of it this, very economically driven way:

For instance, Linux developers (among others) have poured a lot of time
and effort into developing gnu compilers and various other dev tools
(i.e. glade, kdevelop). Now, person X designs an app using those tools,
but uses it for OS other than Linux. End result, Linux OS does not gain
anything, while the other proprietary OS does. Does this seem like a
sane business? I know that GPL is not about that, and that its primary
goal is to provide freedom for all, but then again knowing that there
are forces out there who would rather see FSF, GNU, and Linux die, one
has to wonder whether we are prepared to survive the commercial
onslaught we are already tasting with the whole SCO fiasco.

Besides, this could provide avenues for profit that some of the audio
projects desperately need: like Trolltech with Qt, where they sell the
dev tools to Microsoft's platform, but give them under GPL to GNU/Linux.

OK, enough for now. Sorry all for the long ramble. Hope this will
instigate an interesting discussion. :-)

Ico




More information about the Linux-audio-dev mailing list