Description
As stated in the last weekly meeting, let's take the opportunity of the GitHub organization migration to review the license we use. Currently, we use the default from Data For Good which is MIT, a very permissive license.
The main issue I have with a very permissive license like MIT is that the distribution or modification of the library can be done without using the same license.
Example: a third party using a modified version of EcoLogits has no obligation to distribute and open source the modified version.
This as at least two consequences:
- The third party is not encouraged (forced) to contribute to the open-source project; thus modifications are not available for everyone to enjoy.
- The third party can use a degraded version of the library without having to specify it. For instance, impacts calculation could be altered and lead to wrong results, without the end users knowing that it is not running the original EcoLogits library. This reduces the transparency of the methodology and impact reporting when used in other projects.
Solution
A solution to this issue is to use a copyleft license that can force an individual or a company to redistribute the modifications that have been made, for instance. Here is a list of the well-known copyleft licenses that we could use, with their pros and cons.
LGPL 3.0
This license is mainly applied to libraries. You may copy, distribute and modify the software provided that modifications are described and licensed for free under LGPL. Derivatives works (including modifications or anything statically linked to the library) can only be redistributed under LGPL, but applications that use the library don't have to be.
Sources: tldrlegal.com, fossa.com
Well-known license that is especially designed for libraries. In theory, anyone can install and use the library in any project (including proprietary and commercial) without releasing the project under the same license. One caveat is that it is usually a red flag for some people / companies to have dependencies with GPL-like code because GPLv3 or AGPLv3 licenses force you to redistribute your code under a GPLv3 compatible license (even if you use one small function in an enormous stack).
Another implication of this license is the ability for the end-user to be able to replace the library by another one. Meaning, a company that uses EcoLogits in its dashboard should provide the user an option to use an equivalent library to EcoLogits in replacement for the computation of the impacts, for instance. This can be a burden and it is probably another reason why the LGPLv3 is not commonly liked.
MPL 2.0
MPL is a copyleft license that is easy to comply with. You must make the source code for any of your changes available under MPL, but you can combine the MPL software with proprietary code, as long as you keep the MPL code in separate files. Version 2.0 is, by default, compatible with LGPL and GPL version 2 or greater. You can distribute binaries under a proprietary license, as long as you make the source available under MPL.
Sources: tldrlegal.com, fossa.com
Less-known but actively used license created by Mozilla. The main difference I see with MPL 2.0 compared to LGPL 3.0 is that this license is completely permissive when you only use the library. This is true when the library is in its own separate file, which is always the case in Python if you "pip install" the library. I think the specification of the separate file is used for low-level programming languages. Otherwise, if you modify the library you are required to make it available with the same license
Other licenses
There are of course other licenses available that are copyleft or not. I have only listed the two I consider for this project. We should consider that it is possible to change the license again in the future if required. It is generally poorly regarded to change to a more restrictive license, but ok or encouraged to go for a more permissive license.
Other considerations
Another issue that I have mentioned it is the commercial exploitation of the library with no or low added value. This a very classical issue with open-source projects, and two solutions are possible:
- Use a very restrictive license that makes the software only usable in other open-source projects, that can be an issue if we want to address organizations that produce proprietary code (which we want).
- Use dual-licensing 1. Open-source license that is very restrictive and 2. A business license to sell to companies. This is not very doable as a non-profit (or not easily), plus it is usually viewed as not an open-source practice, but more as a bait to use paid software.
So, we will not try to address this issue here and with a license. We need to find other innovative ways to fund the project and encourage companies to do so.
Other resources
As you @LucBERTON @aqwvinh @adrienbanse @AndreaLeylavergne have contributed to the project (made a commit or created a file) you are concerned by this change and I would be glad to hear your opinion on this.