I think the main difference between BSD and LGPL is that someone who modifies an LGPL library has to publish his modifications. I think this is usually a good idea because it guarantees that someone who uses my library is forced to contribute his improvements.I usually write code in Python and most of the libraries that I use (numpy, scipy, matplotlib, scikit-learn) are released under BSD licenses. So I wonder why this is the case.Are there any strong arguments against LGPL?I understand that a company will not be able to take an LGPL library, make its own private fork and sell it. Would that really scare someone of from using the library? Would that be something which prevents people from contributing to that library?I want my software to be as open as possible but at the same time I would like to get improvements that people made, e.g. bugfixes for Python 3.6 or Ubuntu 18.04.
Why should I release my code under BSD license and why not under LGPL?
licensing;lgpl;bsd license
There are two big differences between the LGPL and the BSD license.First, if you distribute an LGPL-licensed library, you have to provide the source. (This is slightly different from what you said. I can take any LGPL library, make changes, and use it internally; as long as I don't distribute it, I don't need to make any changes I made public. And I only need to offer my version of the code to those I distribute to; I am not obligated to contact the original developer and offer the changes for upstreaming.)Second, if I distribute something that uses an LGPL-licensed library, I must make it possible for the users to substitute the library with something compatible (e.g. their own compilation of said library where they fixed a bug).This second point can be troublesome.It makes static linking difficult. If you want your application to be a standalone executable, you have to provide the parts that make it up, plus instructions on how to recombine, so that the users can create their own package. Or at least offer an alternative distribution that is not a standalone executable, but instead has the library in an external, replaceable form. This gets worse if your build process is more involved. For example, if I use whole-program optimization to get more performance by having the library and my code be optimized together, then I either have to distribute my parts in a form that is accessible to the optimizer (and thus generally far easier to reverse-engineer), or I can only offer a degraded experience for the replaceable version. (Does that even satisfy the requirements of the LGPL? IANAL, IDK.)Not all distribution formats are amenable to library replacement. C# libraries can be given a strong name, where they are cryptographically signed. An application that references a strong-named library will only load the library if the issuer of the signing certificate is the one it expects. This ensures that nobody can trick the application into loading untrusted code. But if the library is required to be replaceable by its license, I can't do that. If I sign using my own key, users can't replace it. If I sign using some publicly available key, what's the point? I believe iOS development has a similar issue.Not all distribution channels are amenable to library replacement. If I build some device (say, a smart washing machine) and use an LGPL library in its software, I need to give the user the ability to replace this library. What does this entail? I have to give him the ability to take a firmware image, replace the library inside, and then update the firmware on the device with this new image. Do I really want the tech support cases arising from that? What about liability if the washing machine then seriously misbehaves? What system does the machine even run on, and am I legally obligated to provide users with the tools they need to compile the library for this system? Am I allowed to do that, or does the license I got from the tool developer forbid this in the first place?Not all library formats are amenable to library replacement. In C++, it is very common that libraries consist in large parts or even completely of template code. This code is instantiated with your concrete types at compile time and integrated into the resulting object files. There is no properly separated library, and no way of using a replaced library except to recompile the entire program. This means that you actually have to provide any source code that uses the library to your users. At this point, there is little difference between the LGPL and the GPL. (In other words, an LGPL-licensed C++ mostly-header library is completely pointless.)And finally, the LGPL contains a small clause that restricts the licensing terms you can give your own application, namely that it must not forbid reverse engineering and debugging of your application to the extent necessary for the user to get his own replacement to work. An interesting edge case here would be software that uses copy protection including a debugger checker (a part of the software that tries to detect whether it's running under a debugger, and then kills the application, specifically meant to hinder efforts to bypass the copy protection). If the license doesn't forbid debugging, but the program contains technical countermeasures, does this violate the LGPL?As you can see, the LGPL offers quite a few pitfalls for commercial developers, which is why companies may often be very wary about using LGPL code in their products. The header code, C# strong name, and copy protection issues were the reasons we decided not to use any LGPL libraries at my previous job.