WARNING: binstalk is currently GPL

[NobodyXu]

I am the upstream maintainer of binstalk and the license seems to be a problem for this crate.
I can open an issue/PR in upstream to convert license of binstalk to MIT/Apache, but that requires everybody who contributed to cargo-binstalk to agree and that requires discussion among maintainers.

cc @passcod

[NobodyXu]

Or by appending to GPL the following texts:

Copyright (C) [years] [name of copyright holder]

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, see <https://www.gnu.org/licenses>.

Linking [name of your program] statically or dynamically with other modules is making a combined work based on [name of your program]. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

In addition, as a special exception, the copyright holders of [name of your program] give you permission to combine [name of your program] with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of [name of library] under the [name of library's license] (or modified versions of such code, with unchanged license). You may copy and distribute such a system following the terms of the GNU GPL for [name of your program] and the licenses of the other code concerned{, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code}.

Note that people who make modified versions of [name of your program] are not obligated to grant this special exception for their modified versions; it is their choice whether to do so. The GNU General Public License gives permission to release a modified version without this exception; this exception also makes it possible to release a modified version which carries forward this exception.

[oeb25]

Thanks for reaching out about this.

I'm a total license noob, so I don't quite know the steps to take. Would this require re-licensing binswap and, thus, any project that depends on it? Notably, we use it in checkr.

They currently have the same dual license, but correct me if I'm wrong; adding a third license would not be a solution?

Or by appending to GPL the following texts:

I don't know where this would be appended. In binswap or binstalk?

And I'm not opposed to changing the license, I just want to do the right thing.

[NobodyXu]

I am not a lawyer, so take what I said with a grain of salt.

According to my experience and internet, linking MIT/Apache crates with GPL crates is ok, but it will affect the license for the final executable created since they are linked together, you would have to list the crates binstalk used in the final executable and warn people that it uses GPL.

I don't know where this would be appended. In binswap or binstalk?

I was talking about changing license in binstalk as this might be a concern for some users.

[NobodyXu]

Honestly, I probably need to do more research on this, this is something I don't have much knowledge of.
cc @passcod is there any concern regarding use of our GPL binstalk crate in here?

[passcod]

(Edited multiple times as I got my thoughts in order)

---

Fundamentally, without changes to binstalk's licensing model, descendent crates such as yours must be distributed under the same terms or more permissive as the GPL. That is in the nature of the GPL, which is a strong copyleft viral license.

✅ MIT/Apache-2 are compatible with GPL (and more permissive), so it's fine really.

Specifically the only thing you (and any descendent crates) are required to do is to provide the source of your program alongside any binary (or more generically, non-source) distribution. A link to this repo does the trick.

(If you're a library, you may want to add a mention somewhere that you depend on GPL code so descendent binary crates know they need to do this, but it's also the responsibility of downstream users to do their due diligence.)

This prevents binstalk (and GPL projects in general) being used in fully-proprietary products, as they'd generally not want to provide their sources, and not want those sources to be licensed under GPL-compatible licenses. Source-available products are fine too, so long as their license are compatible; indeed many public projects don't really accept contributions, but can still use GPL code.

(Another aspect which isn't the case here, but which is often confused with the above, is that if you modify binstalk (like if you fork it, or patch it in some way), you must release those patches under the GPL.)

[oeb25]

I am not a lawyer and all that.

This is a great summary, thanks @passcod. 🙌

✅ MIT/Apache-2 are compatible with GPL (and more permissive), so it's fine really.

For completeness, here I think they mention they are compatible: Apache License, Version 2.0, Expat License.

provide the source of your program alongside any binary

We provide releases which contains a ZIP of the source file, so I would guess this is sufficient? cargo-binswap releases are the same, right?

[passcod]

We provide releases which contains a ZIP of the source, so I would guess this is sufficient?

It is.

cargo-binstall releases are the same, right?

Really we should have a link to the source in the --help listing! Stones in glass houses... In the .full. variants we include the readme itself, which does link to the repo.

[oeb25]

No worries 😉

Does linking to the repo of the binaries source code suffice? Is would it be rather be linking to individual GPL components?

[passcod]

To the repo of the code that's being distributed (so the binaries'), yes.