search

krruzic / pulsectl

Easy to use Rust PulseAudio API
Other
8 stars 19 forks source link

Change license to LGPL / other? #6

Open jnqnfe opened 3 years ago

jnqnfe commented 3 years ago

I noticed that this library is GPL licensed. I just wanted to point out that LGPL is typically more appropriate for libraries...

While on the topic though, I'm not sure how much consideration you gave to your choice, so I'll just point out:

krruzic commented 3 years ago

Definitely not going to re-license as MIT or anything along those lines. I can switch it to LGPL but please explain further as to why.

jnqnfe commented 3 years ago

Definitely not going to re-license as MIT or anything along those lines. I can switch it to LGPL but please explain further as to why.

In addition to what I said above, the MIT OR Apache-2.0 licensing model is that used by the Rust developers themselves and is what they recommend for crates, but if you want to stick to GPL/LGPL, that's your choice, I just hope that you understand the limitations that imposes upon possible use of your crate.

The difference between GPL and LGPL is that a GPL shared-library (aka dynamically-linked library; .dll / .so) forces that GPL licensing onto any binaries that make use of it. Any non-GPL binary using it would be violating the license terms of it and the developers of that binary could thus be sued. LGPL does not carry such a restriction, allowing binaries using it to have whatever license they like. (To understand why GPL has such a restriction, you should understand that a big aspect of "copyleft" licenses like GPL is to encourage open sourcing code - you can only use my open source code/work/object if you open source yours - which is great in some respects, but can also be problematic, and hence the LGPL license was created to allow projects to remove this particular restriction if they wanted).

Currently, if either a binary or a shared-library were to include your rust-pulsectl crate, both would be forced to be GPL-3.0+ licensed, and in the shared-library case, that's very restrictive as just explained; more so than you might expect or typically want. If your crate was LGPL-3.0+ licensed, then while that would make no difference to binaries (they can freely choose to "upgrade" to the GPL version as more appropriate for binaries), it would make a big difference to shared-libraries that use it, since many shared-libraries choose LGPL licensing rather than GPL, and thus could not use your crate currently if they wanted to.

So switching to LGPL-3.0+ rather than GPL-3.0+ would remove a big restriction for shared-library use that you probably don't actually care about. Unless you really want to block non-GPL binaries for some reason from such possible use of your crate via a shared-library, then it's advisable to switch to LGPL.

As just one more point on that, some applications have very little code within their binary, instead putting most of it within a shared-library, even if they are the only users of that library. I know at least one very popular media player that does this; while the small binary is GPL-2.0+ licensed, it's library is LGPL-2.1+. If this application, or parts of it, were ever converted to Rust, there is no way currently that your crate could be used by it, even if they were willing to upgrade to v3.0 of the licenses, since compliant use of your crate would currently force them to have to re-license their entire library to GPL instead of LGPL which would definitely not be acceptable.

As for GPL-3.0+ vs GPL-2.0+ (and LGPL-3.0+ vs LGPL-2.1+), it's easy to assume that a newer version of something is greater, but the big difference between these versions is a difference relating to patents, which was a controversial change. A lot of GPL/LGPL licensed code developers chose not to "upgrade" to v3.0 when it was released in order to not force that upon people. Your crate using v3.0+ means that projects can only use it if they themselves are offered as v3.0 or v3.0+, which some projects may not be willing to accept. If you switched to v2.0+ (or v2.1+ for LGPL) then, just as with switching from GPL to LGPL, you again remove restrictions on possible use of your crate that you may not care about.

Note that using `MIT OR Apache-2.0' licensing does not mean that binaries or shared libraries using it must themselves pick one of these two options for their own use and distribution, if that was a concern of yours; they are free to use certain other licenses: wikipedia - license compatibility. Such licensing flexibility is the big reason for offering such licensing.

jnqnfe commented 3 years ago

A little more to say on MIT/Apache-2.0, since I'm not sure what your objection is to MIT or rational is for picking GPL/LGPL, and it's useful to me at least to explore the options to refresh my own understanding...

[Note that I'm not a lawyer, this is all just to the best of my understanding.]

Apache-2.0 contains patent protections such that contributors give users of the work a free patent license to any patent(s) of theirs that their contribution infringes upon, and has a retaliation clause such that it is lost to the user if the user tries to sue the authors/contributors of the work for patent infringement in that work. I believe GPL/LPGL v3.0 has this also, but not v2/v2.1, hence Apache-2.0 being considered compatible with the former but not the latter (see also here).

The big difference between Apache-2.0 and LGPL-3.0 is that LGPL-3.0 forces itself upon works that use it in order to force such projects to be open source, as mentioned before. If you want compatibility with closed-source projects, or think that the only impact of being LGPL will be less adoption of your crate rather than some worthwhile increase in the number of open-source projects, then Apache-2.0 might be a better choice, allowing projects using your crate a choice between at least Apache-2.0, LGPL-3.0+ and GPL-3.0+.

The MIT license contains much less text, but I believe that essentially is just because Apache-2.0 was written in a more expressive, lawyer-y way, and the only big difference is simply the lack of that patent protection (though some believe that it does cover this implicitly as discussed for example in the "relation to patents" section of the MIT wikipedia entry).

The Rust developers originally just used MIT, but added Apache-2.0 as a user choice in relation to giving users such patent protection (see here). They offered Apache-2.0 as a choice against MIT rather than a replacement since a switch to Apache-2.0 has much more limited compatibility with the licensing that users may want/need to use for their projects.