-
Notifications
You must be signed in to change notification settings - Fork 616
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include WPIcal GPL license #7757
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that WPIcal is distributed under the terms of GPLv3, but the code itself is not licensed under GPLv3. Because of the GPL dependency, the combined work needs to be distributed under the terms of GPLv3, but that doesn't mean WPIcal's own code has to be GPLv3 as well.
Co-authored-by: Gold856 <[email protected]>
IANAL, but I don't believe that's true. For example section 5 of GPLv3 says:
|
As a whole would mean the binary in my eyes (And some other searches show that too). Its known that BSD/MIT licenses are usable from GPL programs. So the source code could all be BSD, its just the binary itself that needs to be GPL. |
I'm very curious about who says GPL only applies to the binaries and not the source, because that goes against the entire viral point of the GPL. The FSF FAQ says
I think this might be what people are confusing it with. The FSF FAQ says
So everything in WPIcal has to be licensed as GPL. We could additionally license the parts we wrote as BSD, but I don't think that actually buys anyone anything other then confusion. |
It gives us free implicit licensing back to BSD if/when we remove the GPL components. "You can, if you wish, release your module under a license which is more lax than the GPL but compatible with the GPL" That's basically what we'd be doing. Releasing the main code module under BSD, which is more lax but compatible with the GPL. It's not really that only the binary has to be released under GPL. It's that BSD source code is compatible with a GPL binary. You can include BSD licensed code in a GPL binary without issue. Theres no reason to actually make the source code GPL. Our BSD source code is still available, which satifies the license of the GPL. If it didn't, we couldn't include any wpiutil or glass code at all. |
The fact that we distribute the source code is irrelevant. The GPL isn't viral if someone else could modify WPIcal and not distribute the BSD licensed source, which they'd have the ability to do if parts of the source code are only BSD. That's specifically why the FAQ says you can have multiple licenses, but you have to make the source GPL.
It's my understanding that re-licensing can never be implicit, which is why I explicitly covered it. The only time it can be implicit is if all contributors grant the license rights, which some projects do, but we don't. Can you explain exactly what should be done for what you're proposing? It sounds like you're suggesting a one liner that includes the GPL in licenseFiles, but it feels like I've heard a few different things. |
Basically, what I'm proposing is shipping the mrcal binary with a copy of the GPL license rather than the BSD or LGPL license. Nothing else needs to change. If someone modifies the mrcal binary, they'd still have to ship the BSD source code. They'd have to ship all the source code used to compile the binary. Remember that shipping the source code means all the source code must be available, including all libraries. The license makes no difference between library and app code. If BSD code wasn't allowed, then it wouldn't be a compatible license, and bsd code in general couldn't be used in GPL apps, unless it was explicitly dual licensed. Which is definitely not the case. |
Co-authored-by: David Vo <[email protected]>
Closing in favor of wpilibsuite/thirdparty-ceres#10 |
Fixes #7694