[Openal-devel] Compilation error
chris.kcat at gmail.com
Fri Jun 9 08:06:50 PDT 2006
On Friday 09 June 2006 07:17, you wrote:
> Am Freitag Juni 9 2006 16:05 schrieb Chris:
> > On Friday 09 June 2006 06:32, Prakash Punnoor wrote:
> > > Sorry, this is not allowed either. You provide means to load GPL libs
> > > and the hooks are just there for this specific task.
> > I don't see how loading an external library via dlopen can be a problem.
One could hardly call the gpl license itself an authoritive source on what
licenses in general are allowed to cover (in fact, licenses tend to cover
more than they are allowed to "just to be safe"). Just about anyone you talk
to with knowledge in the legal field will tell you it's an iffy restriction
(if not outright say, it can't do that). A license can't put restrictions on
a completely independant package.
I mean, if I write a DLL with 100% pure GPL code and replace a native Windows
DLL with it, does that put Windows under the GPL since "they make function
calls to each other and share data structures"? I highly doubt it.
> > See Wine as an example; they put in mechanisms to load copyrighted,
> > closed source, Windows DLLs.
> This is not the same. GPL "infects" other porgs using it, but using propr.
> stuff doesn't.
I'm pretty sure the Windows license says Windows DLLs can only be used on real
Windows systems (something Wine is not, but they can't enforce it because
their license can't cover independant programs). Also the fact that a DLL can
just as easilly have GPL code as an .so can, that argument isn't valid.
If you're that up-tight about it though, do this. Make a library filled with
stub functions that has the same exact API/ABI as the GPL lib, but put it
into the public domain, and package it with OpenAL SI. Then there you go.
OpenAL would interface, dynamicly, with free non-GPL code. However, if the
user wanted to install the GPL lib instead, then well... that's their
More information about the Openal-devel