[Openal-devel] Compilation error

[Chris]

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.
>
> http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

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 
problem. :P