License Review and Discussion

[Kylemaj]

Hey team,

I have shortlisted 4 potential licenses that I think would be a good fit for our project. Lets review and discuss.

MIT License https://choosealicense.com/licenses/mit/

Pros:

• Familiarity: everyone knows and trusts this license.
• Simplicity: short and to the point, avoiding endless pages of legal jargon.

Cons:

• Simplicity: does not cover any specific scenarios that we might be concerned with.
• Less control: allows others to make closed source versions of our software

GNU General Public License v3.0 https://choosealicense.com/licenses/gpl-3.0/

Pros:

• Openness: this license is designed to maximize access, any improvements made to the code will be available to everyone.
• Collaboration: this license fosters a collaborative environment in which everyone is working together, rather than focusing on personal interests.

Cons:

• Extra work: this license requires users to document any changes made to the source code and make source code available when distributing licensed material.

Apache License 2.0 https://choosealicense.com/licenses/apache-2.0/

Pros:

• More control: this license would give us the greatest degree of control over anything created using our code.

Cons:

• Restrictive: contributors may be discouraged to work with us knowing that we would control the copyright to their work.
• Trademark limitation: this license would not allow contributors to trademark their own work.

Hippocratic License v3.0 https://firstdonoharm.dev/

Pros:

• Ethical: this license has a strong moral foundation which ensures that our code will not be used maliciously.

Cons:

• Untested: this is a very new license and is therefore not as 'tried and true' as our previous options.

[Kylemaj]

I personally prefer the GNU General Public License.

My understanding of our project is that our primary motivators are:

• Exposure: adding to a body of work which we can use to build our reputations as data scientists.
• Outreach: get our work in front of as many people as possible both for our own exposure and to spread some laughs in the community.

I believe that the GNU GPL best aligns with these outcomes for the following reasons.

1. It is very encouraging of others to add to our project and share it, since they will not be giving us ownership of their work.
2. It ensures that we receive recognition as the projects founders, no matter what else gets built on top of it.
3. It ensures that anything built on top of our source code is also open source, which I believe will maximize viewership.

[nrao944]

I prefer the MIT license for several reasons

1) GPL is intentionally anti-commercial: Let's say we went with GNU General Public License for our project (called GNU for this bullet point). If Florencia or Tiffany created a a project GNU-X, with our project GNU and their code X, and want to distribute it, they not only have to make GNU available but also X available. This is because GNU-X is derivative work and therefore also licensed under GPL. The problem with this (as I would suspect) is, truly creative coders are likely to have a mind blowing idea that they want to monetize, which by making their code public, minimizes the odds since anyone can now use it/build upon it. Therefore, it creates a disincentive for monetizable innovation to occur from our package. While we may still get others interested in our package, the truly creative ideas (which are more likely than not monetizable) will not flourish.

2) MIT's neutral/supportive of commercial re-use: In contrast if we stuck to our MIT License, and someone used our project to build upon, they have to mention it builds on our project/license, but they don't have to explicitly state how much of our work it builds on, where it is used, how it is used etc. They can also choose not to make their source code available and go with licensing their product anyway they want (including GPL or any other commercial license). Thus, we are more likely to get more people willingly participating in the development/off-shooting of our product, since there is the likelihood of making profit unlike GNU where profit making is difficult (Linux is a classic proof for this!).

In summary, right now, we want to gain traction on our package and we do not have funds to market ours within the community. MIT ensures our license is non-intimidating and short. It also makes it easier for other users since they don't have to keep track of where all they have used our code. We are not in this to make money, but to bring a smile to people's faces, so the more we allow people to build on it, the more creativity flows, and the more smiles we garner.

[morganrosenberg50]

Thank you Kyle for such a comprehensive summary of the different reasonable options. I agree with your pros/cons for each option, however share a sentiment towards the MIT License over the GNU General Public License.

I would second Nagraj's priority given to ease of contribution for our community. In addition, I would circle back to the spirit of our package. Given that this package is meant to be used liberally, light-heartedly, and "not too seriously" (what a great Oscar Wilde quote from the presentation), I think a simple, easy to digest, and liberal license best upholds the spirit of what we are trying to achieve. While I'm less concerned about the anti-corporate nature of the GNU license, I am quite worried about the extra layer of work required to contribute and/ or share additions.

For the same reasons of simplicity and accessibility, I would rule out the Apache and Hippocratic; although I think the Hippocratic could be interesting to explore for future projects. While I don't think it's necessary for this one, as this package is sufficiently benign with regards to opportunities to use it maliciously, I do think there is value in leading by example, and generally supporing an ethics based approach to developing codes and managing communities.

[zjr-mds]

Great discussion about license choices! I like the idea of using GPL but after reading Nagraj and Morgan’s comments, I believe keeping the MIT license is a more suitable option for our package currently. Cheers!