[R-pkg-devel] Possible open-source license incompatibilities within R packages
Ilmari Tamminen
||m@r|@t@mm|nen @end|ng |rom |c|oud@com
Mon Sep 15 09:55:09 CEST 2025
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
More information about the R-package-devel
mailing list