This doesn’t really change the fundamental problem—most people think that all they have to do in order to be compliant with the GNU LGPL is release the (modified) source of the library under the GNU LGPL. The licence is (reasonably) clear that this is not the case, but this confusion is one of the reasons why it was renamed from the GNU Library GPL to the GNU Lesser GPL.
I personally recommend against using the GNU LGPL because of this confusion. If you want something that does what most people think the GNU LGPL does, use the MPL with a GNU GPL exception. (IMO, the MPL is a superior licence to anything in the GNU GPL family, but it is also not my licence of choice—that is the MIT-style licence.)
That's a problem with people, not with the LGPL. Would you sign a contract without reading it through? The same goes for software licenses. Suggesting an alternative license doesn't absolve people of the responsibility of reading the suggested text in the first place.
The language of most of common software licenses is straightforward; blindly using any license without being aware with their implications, especially in a commercial capacity, is... stupid.
Beyond that, we'll have to agree to disagree. If you're familiar with the four freedoms of the GNU free software definition [1], then licenses that are nonfree and non-copyleft do not ensure the four freedoms for users of the software. The (L)GPL has been carefully crafted to ensure those those freedoms. Although that might not matter to you personally, preserving those freedoms is important for many people.
That’s the Mozilla Public Licence. If I recall correctly, it is considered incompatible with the GNU GPL (although it probably shouldn’t be) without an explicit clause permitting combination of MPLed software with GNU GPLed software.
The MPL is a superb licence that is under-appreciated. It usually acts similar to the MIT licence in that it never taints your software that uses MPLed software. It has, at best, a “modular” taint. If you depend on an MPLed library, you can combine that library without revealing your source at all. If you modify that library, you only have to release your modified source. You can even modify it so that it goes from proprietary -> MPLed library -> proprietary, but you have to document the nature of what you’re doing in that call out from the MPL and you may need to release that (I haven’t dealt with the MPL in years, but I think that describes that particular case).
GNU activists were loud enough for years (despite having had the exact same debate at the beginning of the licensing project) that ultimately Mozilla caved and dual-licensed its projects just to shut them up. (It didn’t help with some folks in the Debian community because of the constraints on the trademarks, but some people will never be satisfied unless you’re receiving your web pages by email in emacs.)
Thank you. I asked because the expression "MPL with GPL exception" wasn't clear to me.
You may want to know that in the past few years, MPL 2.0 was released, which embeds a so-called "GPL compatibility" by default. In fact, it's a relicensing allowed by MPL 2.0 licensor.
MPL 2.0 still keeps an option for the licensor's software to never be relicensed, but they have to specifically use an "incompatibility" clause.
I personally recommend against using the GNU LGPL because of this confusion. If you want something that does what most people think the GNU LGPL does, use the MPL with a GNU GPL exception. (IMO, the MPL is a superior licence to anything in the GNU GPL family, but it is also not my licence of choice—that is the MIT-style licence.)