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