How many developers would use LGPL library code in their own projects?

Question

I know many developers won't even touch LGPL but only use MIT or New BSD licensed libraries. But exactly HOW many?

I would use LGPL in my own projects, am I "alone" or "close to alone"...?

The platform I am most interested in knowing about it .Net developers...

As in; "How many percent of the world's .Net developers would use an LGPL licensed library"...?

Answer 1

I do, I see no reason not to.

Answer 2

I would use LGPL with no hesitation. For GPL, I would need to think long and hard.

I like the GPL. I'm glad that RMS put it together. However, the code that I write isn't necessarily my own and I have to put my employer's interests first.

Answer 3

I am no expert on legal/licensing issues. But my understanding of the LGPL is that proprietary, non-open-source software can link to a LGPL library. For OO languages, the special case of inheriting from classes defined in a LGPL library is also allowed.

So I would not hesitate to use a LGPL library.

From the LGPL paragraph 5:

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."

Answer 4

I would say you were nowhere close to alone.

The only reasons not to use LGPL libraries are:

• You've fallen for FUD
• You want to distribute modifications to the library itself, without distributing source code.

And consider this: since glibc is LGPL'd, almost every time someone compiles something with GCC, they're linking LGPL code.

Answer 5

I would use an LGPL library, if it doesn't clash with the licensing conditions and other requirements of the project I am working on. For example, as I understand it, the LGPL code has to be replaceable by the user if something changes, such as a new version being released. If there are versioning requirements that clash with this, I couldn't use the code.

Answer 6

We do use quite a few LGPL libraries, most notably SDL and friends. You can use a LGPL library for whatever purpose if you use its shared library version (ie DLL), not statically linking (ie LIB). This is because the user must be allowed to substitute the version you ship with his own.

More restrictive licenses (GPL) are more problematic - you can't use them commercially unless you agree to a set of terms you usually don't want to agree when developing commercial apps (except if you're open source too).

Less restrictive licenses (ZLIB, BSD, public domain) are a no-brainer. Use them!

Answer 7

LGPL is just fine for libraries. The problem is that it isn't very good for header files. In particular, if a LGPL header file contains macros or templates, and you include it, your program could be required to use an LGPL license (assuming you want to distribute it).

That's why I never use LGPL for my own Free Software projects. Instead, I will use GPL with linking exemptions. Click the link for an example.

The hierarchy of licenses I reccomend for free software developers is:

1. For stand-alone free-software programs - GPL
2. For libraries you want to be generally useful (not restrict your user's licenses) - GPL with linking exemptions.
3. For code you want someone else to take off your hands and further develop (under whatever license they choose) - Public Doman (this is harder to do than one might think).