The LGPL License

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.

Getting a Pull Request Accepted

I like to receive pull requests, but I like some more than others. Here are a few hints on how to make me love your totally awesome pull request and merge it instantly.

With a bit more than a year as an open source maintainer I’ve received a few pull requests. Some have been good, some have had room for improvements and some have required extensive work by myself to clean up before merging.

An Awesome Pull Request

To write an awesome pull request is not that hard, but requires a bit of planning and reading up on tools.

  1. Add an issue describing the feature before coding. It’s an opportunity to get feedback both on the suggested feature and on how to make it fit with the existing design/architecture.
  2. Learn git. As a minimum you need to know how to fork the main repository, create feature branches and how to rebase them on a refreshed master pulled from the main repository. Check out the contribution guidelines from Nancy for details.
  3. Limit each pull request to a single issue/feature. It’s much easier to review and discuss multiple small focused PRs than one large complex.
  4. So you have Resharper and found a bunch of unused usings and other things that should be cleaned up? You’re welcome to submit those non-functional changes in a separate pull request.
  5. Run any existing tests and make sure you didn’t break anything.
  6. Make sure your code meets the test coverage expected and coding standard in the project.
  7. Respect the architecture of the existing code. For example in AuthServices that supports both IIS and Owin hosting, it’s not acceptable to reference System.Web from most parts of the code.

A Gift to Who?

Finally I’d like to mention the view of pull requests as gifts. I totally agree with viewing pull requests as gifts. But not only a gift from the contributor (sending the PR) to the maintainer (receiving the PR), but also from the maintainer to the contributor.

I give you this code that I have written to improve your project.

The contributor

I will take care of your code by reviewing it, maintaining it and take responsibility for any bugs in it.

The maintainer accepting a pull request

This post was inspired by a similar post by Mark Seemann. It’s very good (although more lenghty than this), so I recommend reading it.

Software Development is a Job – Coding is a Passion

I'm Anders Abel, a systems architect and developer working for Kentor in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

Code for most posts is available on my GitHub account.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.