[fpc-devel] LGPL vs BSD

[Jonas Maebe]

On 4 aug 2006, at 11:09, Graeme Geldenhuys wrote:

> The BSD license is starting to sound like a much easier license than
> the LGPL, as long as you are not interested in changes made to the
> library by others.

That's correct.

> I guess it is fair if you think of it as follows.  If a company
> invests a $1mil per year to improve a library for commercial use
> (think along the lines of Qt here), if it was LGPL'ed, they had to
> give all that work away which doesn't make financial sense.

It depends. It's quite possible that by releasing your code, other  
people will in turn improve on that and cut your future development  
costs a lot. That's why companies like IBM, Intel and Apple all work  
more and more on gcc nowadays. Apple already gave up it's own  
compiler (MrC) and I know that at least IBM has transferred engineers  
from its own xlc to gcc.

 From an economic point of view, open sourcing your stuff makes most  
sense for infrastructure frameworks and tools. After all, you can't  
really differentiate yourself with those things (or not enough at  
least), while it nevertheless costs a lot of money to get it all  
right. In those cases,  that $1mil per year is basically wasted money  
which could have been spent on more useful and differentiating stuff,  
rather than some precious investment which you want to keep to yourself.

And once your competitors start cooperating on an open source  
infrastructure which replicates your functionality, you're actually  
at a competitive disadvantage if you keep trying to reinvent the  
wheel on your own. After all, you are competing against the combined  
resources of your competitors. You may have some efficiency  
advantages because you are in full control of everything, but there  
is a limit to that.

Also, things which differentiate today, may be a commodity tomorrow.  
So over time it may be that the optimal strategy changes.

> But if it
> was BSD based, they could decide what they wanted to release back to
> the community in good faith (think Mac OS X here).

I think you are confused here. The BSD-licensed stuff in Mac OS X is  
mostly low-level stuff. Most of the proprietary stuff are high level  
applications (like the GUI/window manager and most end user apps),  
and several of them do link (dynamically) against LGPL libraries. You  
cannot call Mac OS X "BSD licensed", and the fact that it  
incorporates parts of the FreeBSD kernel and some libraries is not  
the reason that the upper layers can be closed.

Most of Apple's releases back to the community also make sense from a  
business point of view rather than merely "good faith". If their  
patches are incorporated upstream (i.e., in the open source project  
they use), then they don't have to maintain and merge those patches  
anymore when a new version comes out which they want to use.  
Additionally, all the open source stuff is tremendously helpful to  
developers, since if there is a bug it's much easier to figure out  
what's really going on.

>> I'm not sure I understand this. Technically, both are possible in
>> principle.
>
> I know both are possible, I just prefer to use it as part of the
> executable and not a separate shared library.  Makes for easier
> deployment and guarantees the application will run (no matter if I
> changed the API for a new version).

Usually such libraries would be installed in the same folder as the  
application, and not installed system-wide to avoid conflicts. It  
sort of defeats the dynamic library advantage of saving on memory  
usage (different apps won't use the same library, so no memory  
saving), but it does enable modular upgrading/patching.

Deployment may indeed be somewhat more complex on most OS'es with a  
separate dynamic library though.


Jonas