[R-pkg-devel] Possible open-source license incompatibilities within R packages

[Ilmari Tamminen]

Sorry about my unclear communication. In the context of solving the assumed license conflicts in the lme4, I meant that you (Ben) could ask only one permission for the minqa, one permission for numderiv, and so on. The maintainers of those packages should know who contributed to the packages, and if there are multiple people, the maintainers could act behalf of those (for giving centralized permissions to you). However, this (and what follows) is only my best layman's understanding currently. It would indeed nice to have some earlier credible applications of the GPLv2 section 10. or relevant FSF FAQ. For example, to me the expression "parts" does not exclude "all parts". And would "all parts" even used in an usual case, if only a limited number of functions and their arguments are called from an R package. The packages are not usually even distributed along the code of interest (in this case the lme4), why saying "all parts were incorporated" does not sound valid. Even if the lme4 would call all the functions and their arguments from a package, the "incorporated parts" would still be limited to those superficial elements. And this could be agreed with the dependency maintainers: only the function calls are incorporated (the situation now resembling the namespace-API interpretation, but enhanced with the permissions). The spirit of the FSF in the section 10. is also notable. In the lme4 case, "the parts" are incorporated with the GPL-2 | GPL-3 software, promoting. sharing and reusing. But these are only my hopefull interpretations. As said, it was surprising to find the section 10. so late, nobody haven't talked about it. Coming searches should be focused on the application of the section 10. I will search more when I have time. If you feel that getting the lme4 dependency licenses updated is possible, then I think it would be the clearest option from these two. Regards Ilmari Tamminen Päivänä 20. syysk. 2025, klo 23.05, Ben Bolker <bbolker using gmail.com> kirjoitti: On 2025-09-19 1:40 p.m., Ilmari Tamminen wrote: Well, this turned out to be an odd case. It took quite long to notice the following in the end of the GPLv2: "10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally." The information I received from multiple sources was that the upstream licenses must be updated or the dependencies removed, if there is the GPLv2-only vs. GPLv3 conflict. Notably, the option based on the GPLv2 section 10. was not raised in this thread either. So, is an email "OK" enough for resolving the GPLv2-only vs. GPLv3 conflict? But not necessary only from the package maintainers though, but from all the relevant copyright holders. But the maintainer can ask the permissions and then probably act from behalf of the copyright holders for giving the centralised permission for the cross use. If this is indeed possible, maybe it would be wise to ask permissions (retroactively) for all the versions, to clear all possible conflicts and remove uncertainties from the future at once. It would also be wise to communicate the permissions along the distribution. I think the awareness about this less burdensome yet (I dare to say) unambiguous option should be distributed. I don't have the expertise to say is the namespace-API interpretation right or wrong. But this new approach is quite clearly defined in the GPLv2. However, I cannot give legal advice for all the possible circumstances. Everybody needs to do their own case-specific interpretations and take responsibility Any thoughts? It would be easy enough to request permissions from maintainers. > is an email "OK" enough for resolving the GPLv2-only vs. GPLv3 conflict? Maybe? > But the maintainer can ask the permissions and then probably act from behalf of the copyright holders for giving the centralised permission for the cross use. If this is indeed possible, maybe it would be wise to ask permissions (retroactively) for all the versions, to clear all possible conflicts and remove uncertainties from the future at once. It would also be wise to communicate the permissions along the distribution. I'm not quite sure what you want to have done here; if you're asking me (the lme4 maintainer) to ask all of the upstream maintainers and copyright holders (it's not clear to me who these are in the absence of an explicit 'cph'-tagged entity in the DESCRIPTION file or an explicit COPYRIGHTS file included in the package: maintainer? maintainer and all authors? maintainer, authors, and contributors?), that seems like more work than I want to do. Would I put these permissions in the LICENSE file, or ... ? I don't mind spending a bit of time asking upstream package maintainers to re-license their packages under 'GPL >= 2', but collating permissions actually seems like more work. I agree that it might be nice to have a clearer statement about these licensing issues, but the problem is that in the absence of a legal precedent (which doesn't exist AFAIK, and seems unlikely to exist in the future -- there would have to be an actual court case involving permissions of R packages, and then that would only apply to one particular jurisdiction etc. ...) it would still just be an opinion. Relevant opinions from Stack Exchange (still just opinions): https://opensource.stackexchange.com/questions/4414/if-my-r-package-uses-gpl-packages-does-mine-automatically-inherit-gpl https://opensource.stackexchange.com/search?q=R+package+GPL https://opensource.stackexchange.com/questions/14266/license-r-code-when-using-r-packages-with-different-license-types Br Ilmari Tamminen On 15. Sep 2025, at 10.55, Ilmari Tamminen <ilmari.tamminen using icloud.com> wrote: Many thanks for the input everybody! I am glad to get help with the complex topic. Am I reading this correctly that you imply that a relationship arising from package A calling library(B), or having a more Imports or Depends on it, would lead to same GPL "virality" as having actual object code from an external package? According to my layman's understanding yes. The primary argument being the shared address space mentioned in the GPL's FAQ, also noted by Ivan. For example, a function defined in my R script can access the same variable as a package::function(). It was mentioned under the #MereAggregation, but with the ambiguous "almost surely" (leaving some space for the API interpretation, I will come back to this later). I also think that the invention of the separate LGPL licenses allowing dynamic linking to dependencies without the license virality supports the above indirectly. Why would the LGPL licenses be needed if the GPL licenses would already allow the dynamic linking? To my understanding, the default use of R language relies on dynamic linking, as no comprehensive executables are compiled prior the execution of the source code. I do hope that the above interpretation would be wrong and the fight wouldn't exist. For example, so that the handling of the Henrik's afex package would have been incorrect. I do like the other interpretation where the R's namespace is considered as an API interface leading to software aggregates. However, notice the many opposing opinions against the non virality in the https://opensource.stackexchange.com/ , specially in the context of R. Although I haven't seen anyone raising the specific API interpretation, I think saw it first time in this discussion. They all might be wrong, but the situation is confusing. After the above, the most puzzling thing in my head currently reduces to the following. What is actually the difference between the dynamic linking and software aggregates? Any clarifying thoughts on this? The GPL2 license itself has the crucial permissible clause for the aggregates: "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." If the current discussion resembles some earlier debates (that I am not aware of), and the uncertainty is still floating, maybe it would be wise to find some decisive, unambiguous conclusion and state it somewhere officially and visibly. Pointing to the relevant arguments and sources, such as explaining the API interpretation and how it aligns with the GPL licenses and their FAQs. Possibly also deal the difference between the dynamic linking and software aggregates. Which one of the concepts actually covers the default application of the R language, or are they even counterparts? And why would the LGPL licenses be redundant in the context of the default use of R (or are they)? If these topics happen to be crucial for solving the seemingly long-lasting confusion. Br Ilmari -- Dr. Benjamin Bolker Professor, Mathematics & Statistics and Biology, McMaster University Director, School of Computational Science and Engineering > E-mail is sent at my convenience; I don't expect replies outside of working hours.