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 > On 15. Sep 2025, at 10.55, Ilmari Tamminen <ilmari.tammi...@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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
