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 <murdoch.dun...@gmail.com> 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 >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
