> On 12. Sep 2025, at 0.17, Ivan Krylov <[email protected] > The _safest_ (possibly overly strict) assumption is that your package > is a derived work of your GPL-2 dependencies even when they are not > direct but transitive (which is the position taken by GPL FAQ), which > necessitates licensing your code under GPL >= 2.
I tried to find a clear statement about the transitive case from the GPL FAQ without luck. By "transitive" did you mean distributing the code without the R packages the code depends on? Could you point out the part where the case was dealt with? I concluded it was not allowed, because the option was not separately mentioned, and because of the shared address space during the execution. Also the need for making the separate LGPL licenses affected my conclusion. > which necessitates licensing your code under GPL >= 2. This would be a very easy option for me: instead of licensing my code with GPL3 only, I would use the GPL >= 2 option. Without the need of possibly removing all the GPL2-licensed dependencies, or ask the authors of the dependencies to update their licenses. It would probably also mean that there is not conflict between the GPL-2 | GPL-3 lme4 and GPL2 minqa packages either in the first place. But having basis for this option would also be good, such as explained by the free software foundation. > You have already heard the view of the R community (in short namespaces > create APIs and R is interpreted, so use is not derivation) Simon, this is very interesting information and makes sense. If I understood correctly, no derivative work but an aggregate, the code entities are communicating through the well-documented APIs. Where was this community view actually stated, do you have any source for further information? If this aligns with the explanations of the free software foundation and thus GPL licenses, then I think there is no issues indeed. I am very likely to ask about the topic from a software lawyer for my particular case. But to form educated questions, I first need to get some basic understanding, and also hear how the community thinks about these issues. ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
