[Openal-devel] Re-licensing OpenAL Soft

[Chris Robinson]

On Tuesday 13 April 2010 1:18:36 am Christopher Fitzgerald wrote:
> The LGPL allows for binary-only distribution if the library is dynamically
> linked, so in most cases I don't see the need to change OpenAL Soft's
> license.  In cases like OpenAL-Soft I find that dynamic linking provides
> benefits over static linking, anyway.

Right. Though it does also require allowing a user to swap out the lib for 
another ABI-compatible one. While that is also a nice feature, IMO, I could 
see why closed systems may not like that, since they don't allow the user to 
change files.

> > Although there isn't an issue with open source code in general, there are
> > enough concerns with the LGPL license itself that using it is an
> > impractical choice for these systems. Licenses like Apache[1], MIT[2],
> > and BSD[3], however, are fine.
> 
> Did they describe what their concerns were?

Not in detail, no. As you mentioned in your next email, though, I would think 
there are NDA problems if a new backend, or other such things, has to be 
written since the changes need to be made available which would expose the 
APIs.

There's also that the developer can't allow people to replace the lib with an 
ABI-compatible one since there's no write access to the file system (and you 
can't make a personal copy with a different lib in place, since it would trip 
copy-protection schemes).

> I certainly agree with the first point, and while I have reservations on the
> second, I can understand the desire for widening the platforms OpenAL Soft
> runs on.

It's very much a difficult thing for me, as it raises questions I can't 
readily answer, and questions what I really want out of this. The main point 
being, I want to keep with a stable, system-wide ABI with an implementation 
that's shared among all apps that use it and can be changed/updated on its own 
for improvements long after any given app using it stops updating, and not 
turn into something like FMOD where each app just uses the version it built 
with, which may or may not get minor updates before hitting EOL, and has next 
to no, or worse- conflicting, user configuration options.

Switching to an MIT or BSD-like license opens up the possibility of static 
linking with closed source apps, preventing such updates and user choice. I 
can't really answer how much of an issue that would be (ie, how many 
developers will or won't use an ABI-compatible dynamic lib when there's a 
choice), but I do know I've been asked several times for static linking.. 
which the LGPL does allow, but limits it to open source uses so it can still 
be updated.

I like the ideal of the LGPL, but its complexity makes it difficult/impossible 
to adjust for cases where it doesn't quite work. Switching to MIT/BSD would 
get rid of the complexity and allow it to work in those extra cases.