-
Notifications
You must be signed in to change notification settings - Fork 37
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
License compatibility with GPLv3 packages (incompatibility intentional?) #110
Comments
Incompatible in what way? Do these packages want to copy code from ggtext? You can use R packages licensed GPL v2 and GPL v3 side-by-side, there is no incompatibility. The license is GPL v2 because ggtext contains code copied from ggplot2 and it was licensed GPL v2 at the time. |
Thank you for your quick answer!
Incompatible insofar that importing a GPLv2 (only) and a GPLv3 (only or "or later") package as libraries into the same R-package makes the whole non-distributable. You can use them side-by-side as long as there’s no intimate data communication, and when using them purely via devtools, I think effects of license incompatibility are avoided (because all installation happens locally), but for example I wouldn’t be comfortable distributing a docker image that provides the package with already includes downloaded dependencies. For compatibility details see https://www.gnu.org/licenses/gpl-faq.html#gpl-compat-matrix Using a library under GPLv2 (only) means that you have to put the combined project under GPLv2 (only or "or later"), but using a library under GPLv3 (only or "or later") means you have to put the combined project under GPLv3 (only or "or later"), which is not allowed if you also use code under GPLv2 (only).
Was the code in question relicensed to the MIT license when ggplot2 got relicensed? (I see the MIT-License used for ggplot2 nowadays) |
I would not interpret importing a package and using a function from it as code re-use in a sense that it would create license incompatibility. Unless the actual code is copied from ggtext into your package, then you are more simply using the output of ggtext in your package; output is generally not covered as part of the GPL. It is "at arms length" to use the term from the GNU FAQ. In the case of distributing packages as part of a Docker image, I would also interpret that as being clear that the image contains a mix of different softwares under different licenses, rather than constituting a single large piece of software. From the GNU FAQ:
That said, @clauswilke there are a small enough number of contributors that we could easily re-license under MIT if you were interested in pursuing that. |
Calling functions from another package is akin to linking to it, so it is the "intimate data communication" which causes them to be seen as a single program. To get the behavior that calling functions does not trigger copyleft, you’ll need the LGPL.
In this case, proprietary can be replaced with "incompatible license" — and sadly the GPL-2 and the GPL-3 are incompatible to each other (but GPL-2 or later — What usually suffices to communicate at arms length is to devise a generic web API that separates the two programs. But that’s overkill for calling R functions. Switching to |
@bwiernik I'm happy to relicense to MIT. I looked through the commits and it looks to me like the code is mostly all mine anyways. Two people made very minor contributions that didn't touch any of the actual code. We could ask them for their agreement just out of curtesy but if they can't be tracked down I don't see it as an issue. You should agree as the current maintainer. The older I get (I've been in this space for 30 years) the more I believe the GPL is a toxic license and should be avoided whenever possible. It's the only license that consistently leads to these kinds of discussions. And most of the time it's because of incompatibilities between different versions of the same license family. There's more important things in this world than arguing whether loading two distinct R packages into your script combines them in a way that creates a license conflict. (I still believe it doesn't, but that's neither here nor there.) |
@clauswilke thank you! I guess these discussions are a reason why creativecommons decided to always include the "or later" without giving an opt-out. |
I agree. I'll adjust the license. (Definitely agree about GPL) |
@ArneBab I don't like the "or later" option at all. It means that while I'm stuck with the licensing terms as they are (once I've accepted contributions from other developers), some third party can relicense my software as they see fit. I don't think that's acceptable. I've meant to write a detailed blog post about this whole topic. I really need to sit down and do this. |
@clauswilke if you decide to blog about that, please read up about the discussions during the GPLv3 drafting which changes can be considered similar in spirit: a new license can only be considered a later version if this is preserved. That’s a pretty strong limitation of the "or later" clause with GPL which prevents FSF from changing license terms in ways that deviate from the spirit of the license version you adopted. |
The DESCRIPTION file lists ggtext as GPLv2 only, so it would be incompatible with packages like assertthat, clipr, DT, forecast, profvis, and whisker.
Is this incompatibility intentional or could the license be upgraded to GPLv2 or later?
The dependencies use MIT-licenses, so they should not be blockers to enabling use together with GPLv3 and LGPLv3 projects.
# sorry for having no R-code, this is just a legal question.
The text was updated successfully, but these errors were encountered: