Ilmari, there is a huge difference between opinions and law. Many of the statements your quoted are just opinions, they are not legally binding - in fact if you research the legal area you will find that they are often considered incompatible with the wording of the license (i.e., it has been argued that the courts are unlikely to take those views). However, none of these statements have been tested in court (AFAIK), so there is no definitive answer. The simple answer to your question is: consult your lawyer. It really makes no sense to speculate on your own unless you are very familiar with the law and legal system. You have already heard the view of the R community (in short namespaces create APIs and R is interpreted, so use is not derivation) for what it’s worth (it isn’t legally binding, either, but it explains what you see on CRAN), so you can take it or leave it, but you won’t get anything more definitive unless you seek legal advice (and even then you may not get a definitive answer, only an advice).
Cheers, Simon > On 9/09/2025, at 19:07, Ilmari Tamminen <[email protected]> wrote: > > Thank you for the input. > > I have seen the same interpretation earlier, and it feels logical and > intuitive to me as well. However, there is a lot of opposing opinions to it > in different contexts of programming. For example, see the below > question-answer, where the Free Software Foundation itself is also cited: > > https://opensource.stackexchange.com/questions/9085/can-i-distribute-non-gpl-code-that-uses-gpl-code-as-long-as-i-dont-distribute-m > > I think that the software aggregate is one central concept when considering > the question: whether an R code/package using other R packages can be > distributed without GPL "leaking" from one entity to another. Below is a link > to the Free Software Foundation's interpretations about the aggregates. What > do you think about these, how do they apply for the cases where GPL2+ or GPL3 > -licensed R code calls GPL2package::function()? Or the installation of GPL2+ > or GPL3 -licensed R package also installs a GPL2package? > > https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation > > Does the "shared address space" cover the typical case in R, where both my R > code and the R package it loaded can access the same variable in the working > memory? If so, then the Free Software Foundation seems to interpreter them as > a single program, not an aggregate. And if the LGPL licenses are not used > (allowing dynamic linking without the leakage, which is the default with R > packages to my understanding), then the GPL licenses start to leak across R > codes/packages. To my understanding. > > This might also be useful to look at: > > https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > > I am not familiar with Windows functions. But my gut feeling says that they > are considered as separate entity, if standard command-line communication or > similar is used (see the above link). The below lecture, from a real > open-source legal expert, is titled for corporates, but the principles are > the same. I link directly to the point where she discuss about the > differences between the GPL and LGPL licenses. Soon after that she discusses > how the operating system and its functionalities are considered as separate > entity from the other software (with certain conditions). > > https://youtu.be/gF4b1TA5Q5w?t=831 > >> On 8. Sep 2025, at 22.07, Duncan Murdoch <[email protected]> wrote: >> >> On 2025-09-08 10:55 a.m., Ilmari Tamminen wrote: >>> I would like to release my R code under GPL-3. The code depends on a >>> package (lme4) that itself uses "GPL >= 2", but which has upstream >>> dependencies (minqa, numDeriv, rbibutils) that are GPL-2 only. According >>> to what I've read (see below), GPL-2 and GPL-3 are incompatible. Are the >>> GPL-2 upstream licenses a problem for my GPL-3 R code? If so, are there >>> recommended ways of resolving this? >> >> My understanding is that the licenses of other packages are only relevant if >> you are incorporating their code into yours and would like to release the >> combined work. >> >> If your code uses some other package but you are not distributing the other >> package then their license doesn't affect your package. >> >> For example, many packages (including R itself) are written to use Windows >> functions, but since they don't distribute copies of those functions the >> fact that Windows isn't open source doesn't matter. >> >> Duncan Murdoch >> >>> This post is written from the perspective of an R-package user. I am not an >>> R-package developer nor a lawyer. I want to comply with the software >>> licenses with the best available understanding about the topic I have. >>> How did I found the issue: I built a container image from my code, then I >>> ran: >>> write.csv(installed.packages(fields = "License")[,c(1,10)], >>> "Licenses-of-R-packages.csv") >>> After inspecting the above list I found out that the lme4, central to my >>> code, imports the minqa package. The lme4 is licensed under the "GPL-2 | >>> GPL-3 [expanded from: GPL (≥ 2)]" according to CRAN, and the minqa package >>> under "GPL-2". Thus, there might be a license incompatibility. The GPL2 vs >>> GPL3 incompatibility is stated for example here: >>> https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility >>> Also if you select both the GPL2 and GPL3 licenses in the following license >>> tool, it says they are incompatible: >>> https://ufal.github.io/public-license-selector/ >>> Here is one of the graphs trying to simplify the license relations. Notice >>> that there is no downstream-compatibility arrow from the GPLv2 to the >>> GPLv2+. >>> https://dwheeler.com/essays/floss-license-slide.html >>> Here is another figure lacking the compatibility arrow. On the other hand, >>> there is no red arrow or cross either. The compatibility graph was obtained >>> from the: "Georgia M. Kapitsaki, Nikolaos D. Tselikas, Ioannis E. >>> Foukarakis: An insight into license tools for open source software systems. >>> Journal of Systems and Software 102: 72-87 (2015)". >>> https://gkapi.blogspot.com/2016/09/foss-license-compatibilities.html?m=1 >>> The main question is: are there incompatibilities between the upper stream >>> GPL2 and lower stream "GPL-2 | GPL-3 [expanded from: GPL (≥ 2)]" R packages >>> (minqa vs lme4)? If so, how could I deal with the situation as an R-package >>> user trying to publish my source code under the GPL3? Or could the issue be >>> solved by removing the minqa-based bobyqa optimiser from the lme4 package >>> (a solution not directly in my hands)? >>> Lme4 also suggests the GPL2 numDeriv, is this an issue as well? >>> Furthermore, it is notable how the R package installations also install the >>> undirect dependencies by default, even if my code works without them, >>> complicating the topic further. For example, if I rely on an R package >>> licensed to me with GPL3, after the installation my setup (computer or a >>> container image) can be full of other and possibly non-complying R >>> packages. One of them being the GPL2 licensed rbibutils, which becomes >>> installed with the lme4, but the CRAN page of the lme4 does not mention >>> this as a direct dependency. >>> Best regards >>> ______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
