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

[Ben Bolker]

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.