TL;DR A component licensed under LGPL can be used by closed source, proprietary software, both internally used and distributed, for free, with no effects on the software using the component. LGPL is not “contagious” in the same way as GPL, so it only affects the component under LGPL. As long as you’re only using official distributions of the component, it is free to use and free to redistribute. The only requirement is that you include a notice in your “about” page or similar that the component is used.

I often get questions about the LGPL license used for Kentor.AuthServices. I also often find it confused with GPL, which is something you should never, ever even consider to use in any closed source software that you intend to distribute. So this post is an effort to explain and answer common questions about the LGPL. Unfortunately I have to add the disclaimer: I’m not a lawyer and the content of this post is only meant as an overview and introduction to the license. I might have got things wrong, so please read the real license yourself and involve appropriate legal counsel to be sure.

Intention of GPL and LGPL

The intention of the GPL (General Public License) is to promote free open source software. You can use the software under GPL, redistribute it and modify it. But the result is always bound to be under the GPL license too. You can also combine GPL software with other software – as long as the combined work is licensed and distributed under GPL. This means that the GPL is “contagious” – if you use a GPL component in a system, the entire system has to bee released under the GPL. The reasoning behind this is to promote open source. If a great library is only available under GPL it will force software that want to use the library to be free open source too.

The LGPL is a weaker form of the GPL that is not contagious over library boundaries. Originally LGPL was read out as Library General Public License. It has now been reinterpreted to be read out as the Lesser General Public License. I assume they mean lesser as in less strong in forcing software to be open source.

Applying LGPL to a library ensures that the library itself and any modified versions of it will remain open source. But it can be used by closed source software.

Kentor.AuthServices and LGPL

When I started the Kentor.AuthServices project my intention was for it to be free to use for anyone in any setup. But I was also a bit concerned about SAML2 being an enterprise technology where there were not any really good solutions on .NET. So I wanted to place restrictions so that a big player in the field would not be able to take the AuthServices project, add features to it and release it as a packaged product under their own brand. Anyone (including the big players) is welcome to use and participate in development of the project, but I want all development efforts to be channelled back to the community. This includes work that we are doing as assignments from our customers too. I want to be able to reuse investments done for one customer when working for the next – in the end it’s a win for everyone if the product gets better.

The LGPL license offered what I was looking for. The library can be used by both open and closed source software, but the library itself is protected from theft.

Internal Software

So what about using an LGPLed component such as AuthServices in some kind of internal software? Go ahead! LGPL and GPL only places restrictions on software that is distributed. As long as you’re not distributing the software (in binary or source form) you can use it and modify it.

Web Based Products

A special case of “internal software” is web based products. When the GPL was invented the web was not what it is today. If you wanted to offer someone to use a software back then you had to distribute the software by giving them something they could install on their own systems. The GPL ensured that anyone distributing the software also had to offer the source.

With web based products this reasoning doesn’t work. I can offer a service over the web, by using GPLed software. But I’m never distributing the software itself – it sits on my servers only. Which means I’m not bound to release the code of the produt, even if it is using GPLed components. To remedy this another license was born, the Affero General Public License which requires anyone using the software to offer services need to offer the source code to everyone that can access the services.

But as far as plain GPL and LGPL are concerned, a web based product is an internal application that doesn’t incur any requirement to distribute the source.

Distributed Products

With classically distributed products the case is different. If you do that, you have to offer the source code of any LGPLed components. If you are using GPLed components you have to offer the source code of that component and anything that links against it. And you have to include information in the “about” menu or readme file of the product. Even my Android phone includes the GPL license in the about menu. And it includes a notice on how to request the source code of the GPL and LGPL components used:

Sony Mobile offers to provide source code of software licensed under the GPL or LGPL or some other open source licenses allowing source code distribution to you on a CD-ROM for a charge covering the cost of performing such distribution, such as the cost of media, shipping and handling, upon written request to Sony Mobile Communications AB, Open Source Software Operations, Nya Vattentornet, SE-221 88 Lund, Sweden. This offer is valid for a period of three (3) years from the date of the distribution of this product by Sony Mobile.

LGPL Replacement Requirements

Finally, there is a replacement requirement for LGPLed libraries. It says that the user must be able to replace the LGPLed component with a modified version. For a .NET library it means that the user must be able to put a modified version of the library in the directory of the application and have the application use that. For example with AuthServices, it means that the user must be able to upgrade to a later, compatible release that contains security fixes, without the involvement of the vendor of the application. I think that’s good.

Requests to Change License of Kentor.AuthServices

Every now and then I get a request to change the license of AuthServices to something else. First of all it would be very hard to do that, as I would have to gain consent from all the developers that have contributed to the library. But even if I could you would first have to convince me. And so far, nobody that has requested a change of license have been able to explain why LGPL would be a problem. If you know any case where LGPL is a real stopper, please leave a comment to help me understand such a case.

Summary

My intention was to write a short post on this, but I’m already on 1321 words. So a summary might be appropriate on how LGPL affects users of a library such as AuthServices.

• If you’re not distributing the software – you’re free to use and modify the library without doing something special.
• If you distribute software using the library, you must offer to supply the source code of the library. If you’re just using the official builds, you don’t have to do anything special as the code is already available on GitHub.
• If you distribute a modified version of the library, you must offer to supply the source of that modified version.