Skip to content

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

21 messages · Duncan Murdoch, Ivan Krylov, Hadley Wickham +7 more

Original
Ilmari Tamminen
# 
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?

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
Duncan Murdoch
#
On 2025-09-08 10:55 a.m., Ilmari Tamminen wrote:
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
Ilmari Tamminen
# 
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
2 days later
Ivan Krylov
# 
On Mon, 8 Sep 2025 17:55:52 +0300
Ilmari Tamminen <ilmari.tamminen at icloud.com> wrote:

            

      
      
      
    

        
The _safest_ (possibly overly strict) assumption is that your package
is a derived work of your GPL-2 dependencies even when they are not
direct but transitive (which is the position taken by GPL FAQ), which
necessitates licensing your code under GPL >= 2.

This is not the only possibility. You could make various arguments that
would let you keep your code licensed under GPL-3.0-only (e.g. does your
GPL-3 code work even with the GPL-2 dependency uninstalled? do other
non-GPL2 libraries implement the same interface?), but whether they are
valid in your specific case, only a lawyer who specialises in software
can say.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

      
On Mon, Sep 8, 2025 at 2:08?PM Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        
This is my belief too, and I've written a bit about it at
https://r-pkgs.org/license.html#code-you-use

Hadley

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
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

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

          

      
      
      
    

        
I tried to find a clear statement about the transitive case from the GPL FAQ without luck. By "transitive" did you mean distributing the code without the R packages the code depends on? Could you point out the part where the case was dealt with? I concluded it was not allowed, because the option was not separately mentioned, and because of the shared address space during the execution. Also the need for making the separate LGPL licenses affected my conclusion.

            

      
      
      
    

        
This would be a very easy option for me: instead of licensing my code with GPL3 only, I would use the GPL >= 2 option. Without the need of possibly removing all the GPL2-licensed dependencies, or ask the authors of the dependencies to update their licenses. It would probably also mean that there is not conflict between the GPL-2 | GPL-3 lme4 and GPL2 minqa packages either in the first place. But having basis for this option would also be good, such as explained by the free software foundation.

            

      
      
      
    

        
Simon, this is very interesting information and makes sense. If I understood correctly, no derivative work but an aggregate, the code entities are communicating through the well-documented APIs. Where was this community view actually stated, do you have any source for further information? If this aligns with the explanations of the free software foundation and thus GPL licenses, then I think there is no issues indeed.

I am very likely to ask about the topic from a software lawyer for my particular case. But to form educated questions, I first need to get some basic understanding, and also hear how the community thinks about these issues.

  
  


  


      

    

    

      
      

        


  

        

      Charles Plessy
    

    

      
      #
    

  


  

      
Le Fri, Sep 12, 2025 at 10:42:56AM +0300, Ilmari Tamminen a ?crit :

            

      
      
      
    

        
Hi Ilmari,

there is an important point to consider in order to have the big picture
before asking for legal advice: on whom is the burden of license
compatibility.

I first wrote a long example, but here is a LLM summary that I am
very satisfied of:

GPL?2?only and GPL?3 are not license?compatible when combined into a
single derivative work, but this is rarely an issue for developers who
only distribute source code ? private use is unrestricted, and separate
works can be redistributed side?by?side.

The problem arises when redistributing binaries or other combined
artefacts: if any binary contains code from both, it cannot be legally
redistributed.

This risk extends to container images: while a generic image bundling
many unrelated packages is usually fine, an image built to run two
incompatible?licensed components together could be considered a single
work, triggering the same restrictions.

So I think that the big question is not only on how you comply to
license terms, some of which you can chose as you are the copyright
holder, but also how your choices empower the downstream community to
comply.

Best,

Charles

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Greg Hunt
    

    

      
      #
    

  


  

      
I don?t think we should be trusting LLM output for questions like these.
The GPL FAQ directly addresses the bindings between interpreted code
modules (text, not binary) and the need for distribution of code under the
GPL to either be under the same version code or a compatible license.

On Sat, 13 Sep 2025 at 11:53?am, Charles Plessy <

        
charles-listes+rd at plessy.org> wrote:

        

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Henrik Singmann
    

    

      
      #
    

  


  

      
Hi all,

Just adding my experience to this thread as a cautionary example against
the notion that it should be no problem to release a package under GPL-3 if
it only calls functions from packages released under GPL-2.

Up to 2017, my afex package (which depended on several GPL-2 packages) was
released under GPL-3. However, then an over-eager debian user reported this
as a violation of the GPL, see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800891
As a consequence, Debian suspended hosting the corresponding binary package
(r-cran-afex) until I changed my license to GPL (? 2).

I in principle agree with both Duncan and Hadley position, but if someone
more powerful (in this case the Debian package admin) has other opinions
there was not much I could do.

Best,
Henrik

Am Do., 11. Sept. 2025 um 23:32 Uhr schrieb Hadley Wickham <
h.wickham at gmail.com>:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

      
Thank you Henrik, I read the "bug" report. The precedent you described seems quite significant, and unfortunate of course, although dealt outside the courts. If no substantial counter arguments appear, such as a stance from the free software foundation or judicial decision that would falsify how your package was treated, I think I don't dare to use the lme4 package as such. Thus, I might need to make my own version and remove the GPL2 dependencies somehow. But there is the risk of breaking the code, as I am not a specialised lme4 developer. However, I have already tested that my mixed-model fittings do work after doing the following in a fresh R session:

library(lme4)
remove.packages(c("numDeriv", "minqa", "rbibutils"), c("/usr/local/lib/R/site-library"))

I understand the burden this would cause, but for me and maybe other lme4 users as well the easiest way would be to solve the assumed issues in more coordinated manner. By asking the dependency authors to update their licenses, or remove the dependencies from the official distribution of the lme4. But honestly I am still unsure is this an over reaction, or was the apex package treated incorrectly. Unfortunate uncertainties and delays for my project anyhow.

Best regards
Ilmari

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
I will go ahead and ask the upstream developers if they're willing to
change their licenses from GPL-2 to "GPL >= 2", but honestly I think
this is probably an overreaction. I suspect there are *many* packages
on CRAN that have the same kind of license incompatibility, especially
those relying on stable packages that are so old (pre-2007, e.g.
numDeriv) that they were released before GPL-3 existed (and the
package maintainers never saw the need to go back and change the
license).

On Sun, Sep 14, 2025 at 3:22?AM Ilmari Tamminen

        
<ilmari.tamminen at icloud.com> wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Hi Ilmari,

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?

The latter case (ie object code and linking) clearly is what the GPL has in
mind, where virality matters, and where it is commonly applied.  The
established consensus, as best as I can tell, always has been is that the
former (an R package calling another R package) is not, and the virality
argument you are making does not apply.  So I think you are fighting a
fighting that does not exist.

Cheers, Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Henrik Singmann
    

    

      
      #
    

  


  

      
Hi Dirk,

You might have missed the point I made in my email which shows that some
people from Debian (!) took exactly the position you believe does not exist
and removed the binary version of afex from the Debian repositories. I link
to the relevant Debian bug report again below which contains the following
claims:

            

      
      
      
    

        
GPL3+, however it has GPL2-only dependencies (r-cran-stringr, r-cran-coin,
r-crain-lsmeans), and it calls functions from these packages directly.

            

      
      
      
    

        
its dependencies constitute a single work, and not two separate programs,
as per the GPL faq: [...]
See here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800891

While I also believe that this is likely a misinterpretation of the GPL, I
was not in the mood to fight against this and simply changed my package's
license. So while we might all be in agreement here, clearly not everyone
sees it this way.

Best,
Henrik


Am So., 14. Sept. 2025 um 13:38 Uhr schrieb Dirk Eddelbuettel <
edd at debian.org>:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
Hi Henrik,

People have been wrong on the internet before, and they continue to do so.
Just because someone made a claim (which you and I considered false and
without underlying merit), and even when action resulted, does not create
"case law". That was simple a mistake being made. [1]

The underlying issue is that nobody has shown that a Depends (or these days
Imports) implies that the 'importing package' (here your `afex` package)
inherits anything from the 'imported package' (here Ben's `lme4`). CRAN has
over twenty-two thousand packages. There simply is no cross-pollination of
licensing on package being used in this standard way. [2] What matters is
that when a package gets onto CRAN is that its license is a suitable,
understood and accepted license that is part of the master list CRAN
keeps. All that is in the manuals.

I will now try to extract myself now from this thread. It really is a
flashback to earlier days in that it creates a lot of heat without much light.

Cheers, Dirk


[1] And having been part of Debian for thirty years I am with you that
sometimes it is easier to just make a change to a package or file and move
on. That by now means settles the underlying issue. There are simply too many
hotheads to debate.
[2] As said before, it is difference when a package builds, compiles, links,
with an external library. That is the example of virality that
matters. Different case though.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

      
Many thanks for the input everybody! I am glad to get help with the complex topic.

            

      
      
      
    

        
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

  
  


  


      

    

    
4 days later

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

      
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?

Br Ilmari Tamminen

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
On 2025-09-19 1:40 p.m., Ilmari Tamminen wrote:

            

      
      
      
    

        
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

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      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 at 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 at 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.

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

      
Hi, could the moderators remove my previous message. For some reason my email client screwed the response, as you can see:

https://stat.ethz.ch/pipermail/r-package-devel/2025q3/012000.html

I didn't find any address to moderators. Here is the previous message, hopefully better this time:


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 a 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

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Ilmari Tamminen
    

    

      
      #
    

  


  

      
Regarding the utilisation of the GPL2 section 10 for solving the GPL2-only vs. GPL3 conflicts, it is important to remember the GPL3 virality. If only the GPL licenses are being read then it looks like that the conflicts exist, and the two most certain solutions are:

1) Update the upstream licenses
2) Not use the GPL2 packages downstream

Then, however, the FSF's GPL FAQ takes the more liberal stance, allowing for example the command-line communication within software aggregates. It doesn't sound a valid independency, if one code entity cannot call another one and then fails executing its purpose because of it, but this kind of application without the GPL3 virality seem to be widely accepted despite the language in the GPL licenses. Furthermore, to my understanding the GPL licenses do not clearly take into account whether the dependencies are conveyed with the code of interest or not, making the situation even more blurry.

Thus, the situation is still unfortunately unclear. It seems that the language in the GPL licenses is the strictest, but the popular and widely accepted interpretations are more liberal way or another, divided into the two schools (the R community's way I would like to call as the namespace-API interpretation).

Regards
Ilmari Tamminen