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 <[email protected]> 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.
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
