Why the GPL-2.0 license?

[ximon18]

Hi,

I learned about this project via a LinkedIn post to a Rust community there. Great to see a new entrant into the Rust crypto landscape, I look forward to seeing the project develop and hope it gains more contributors and can at some point undergo an external audit by a reputable party.

I'm interested to know why the GPL-2.0 license has been chosen.

I'm not looking to get into an unhealthy discussion about the PROs and CONs of different licenses, rather to understand the reasons for this choice as, while being "An OpenSSL inspired Rust based encryption library", it uses a different license to OpenSSL (Apache v2 licensed), and also to other Rust crypto crates such as RustLS (triple licensed under Apache License v2, MIT and ISC), and Ring (ISC style licensed, apparently due to being derived from BoringSSL). What factors drove the choice of the GPL-2.0 license for this library?

A quick comparison to these other crypto libraries in your README might also be a good addition as well to help guide readers in making a choice.

Best wishes with the project!

Thanks,

Ximon

[Azgrom]

Hey, thank you on bringing this issue! And pardon for responding so late... but let's go

Why GPL-2.0-only?

Basically, for two reasons:

1. Because I have not looked the details of the others licenses as well as the implications of combining them. While I already had researched the implications of the pros and cons of GPL2 and GPL3 in a past opportunity... ;
2. I have the impression that the GPL-2.0 license is designed to stimulate a project becoming thing with a life of its own. And what do I mean by that?! I am thinking about that phrase I once heard Linus Torvalds saying about the implication of GPL2.0: "Its free and public. You can do whatever you want. But if you do any improvement, bring it to the project";

I am completely open minded to publishing a new version combining and/or replacing the current license. I just want to eventually do it having a clear understanding that it will benefit this project's vision and its potential users.

In addition to this, if this project ever gain a significant popularity and gets bigger, I also consider eventually transferring it to the Rust community. So my motivation is absolutely to contribute to this project's vision.

A quick comparison to these other crypto libraries in your README might also be a good addition as well to help guide readers in making a choice.

To be sincere, I have already considered this. But I was afraid if bringing other projects names in the front-page would be impolite 🤔

That is a sound feedback, though. Thank you! I will think in someway of giving readers a sense of this project API user friendliness

[dcoles]

Just a drive-by reader who was similarly curious (I saw this project on crates.io). 😄

Probably the biggest implication of selecting the GPL-2.0 is that it is a "strong copyleft" license that requires all distributed derivative works (including binaries that link to the code) to be made available under the same license (i.e. the GPL). This would include all binaries or other libraries that use this crate.

Note: Linux is distributed under the GPL-2.0, but with a special exception to make it clear that making an ordinary Linux syscall is not considered to be a derivative work. If this wasn't the case, it might be argued that all distributed binaries would have to be licensed under the GPL.

There also exists a couple of "weak copyleft" licenses like the LGPL-3.0 and MPL-2.0 that require any modifications to the library (LGPL) or a file (MPL) to be under the same license, but allow for larger works (binaries and libraries that use this one) to be distributed under a different license.

The Apache-2.0 and MIT licenses are "permissive", with limited requirements on derivative works. Under this sort of license, you can make modification with no obligation to "give back".

As you can see, there's a pretty broad spectrum. Libraries under "permissive" licenses are more friendly for use in proprietary software; "strong copyleft" licenses are mainly to prevent the creation of proprietary software; and "weak copyleft" licenses are somewhere in the middle. Every license has their own special caveats (e.g. attribution, patent grants, ...), but they typically fall into one of those three categories.

One thing to also be mindful of is that changing a licence requires consent by the copyright holder of that piece of work. So keep this in mind if you're going to accept external contributions (copyright typically stays with the author unless explicitly granted to another party).

With that said, they're all fine licences and it really depends on where and how you wish this library to be used.

Best of luck with the project! 🎉