Why should I release my code under BSD license and why not under LGPL? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

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.

Answer 1

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.

Answer 2

The first thing to bear in mind is that, for the vast majority of open-source libraries, there is only ever one contributor to the code: the creator of that library.

If it's one of many similar solutions, and a 3rd party finds a limitation, they'll seriously consider switching to another library that doesn't have that limitation.

If it's popular and offers unique features, folk might request the author add missing features.

If it's popular and you are lucky, others might invest effort into making changes too.

From experience, both as someone who's made those changes and been lucky enough to have others care enough about my own work to want to contribute, if they make that change, they'll be keen to have it incorporated into the original code. The reason is simple: maintaining a separate fork is hard work as any changes to the original must be constantly merged, each time bringing the risk of a conflict that must be resolved.

The main reason why someone would take the alternative route of maintaining a separate, private, fork is for commercial reasons. Then, the licence comes into play. Can I legally keep that fork private? If yes, then great. If no, then can I wrap my commercial advantage around the library without changing it? Yes? Then great. If no, it's time to either take the risk and ignore the licence or find a different one/ write it myself. Again, "it's hard work" comes in to play with the last alternative: publishing their own version, highlighting the changes, to that library.

So, assuming the above all holds true for most people (and there isn't really any empirical evidence to confirm or deny it), then using the LPGL licence will not increase your chances of people helping maintain it. Further, commercial organisations are often nervous of LGPL. It's too close to other GPL licences and they may not want to employ a lawyer to check they are complying with the licence. So it's cheaper and easier just ban the use of LGPL libraries, reducing your potential user base.

The main reason folk use *GPL licences, is because they want to control what others do with their code, rather than to encourage contributions. So if encouraging contributions is your main concern, stick with the BSD licence and put effort into communicating the fact that you welcome contributions from others.