Implications of a Dependency on a GPLed Package
On 13-01-24 12:22 PM, Christian Sigg wrote:
I intend to submit a newly developed package to CRAN (to be licensed under the GPL), which prompted me to re-read the GPL FAQ. The following section caught my attention:
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no.
(...)
Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
(from http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL) My understanding of this section is the following: 1. If I develop and distribute an R package which depends on another package that is released under the GPL, I have to release my package in a GPL-compatible way. 2. Given that R itself is distributed as a set of base packages (released under the GPL), and a distinction between making use of the R "language" and making use of functionality provided by the base packages seem impossible, the above section could also imply that it is not possible at all to release R code under a license that is not GPL-compatible. Yet, there exist several packages on CRAN which seem to violate the GPL, according to the FSF interpretation quoted above. For example, the SDDA package prohibits commercial use of the package (a restriction that is incompatible with the GPL), but states an explicit dependency on the MASS package (which is not a "base" package and released under the GPL). Furthermore, several packages also prohibit commercial use, but list an explicit dependency on the methods package (e.g. gpclib, isa2, optmatch). As all of these packages are on CRAN, and at least one author is also a core R contributor (Duncan Murdoch for gpclib), I assume that the CRAN maintainers and/or the R Foundation do not consider these packages to violate the GPL, and therefore also do not agree with the FSF interpretation of the GPL quoted above (provided that they share my understanding of the quote). On the other hand, R is an official part of the FSF GNU project, so I would expect the R Foundation to agree with GNU policy in general. I have not found a statement by the CRAN maintainers and/or the R Foundation that addresses this issue (e.g. it is neither addressed in doc/COPYRIGHTS nor the R FAQ nor the CRAN repository policy). I have also searched the archives and there are at least three references to the above quoted section of the GPL FAQ on R-devel: https://stat.ethz.ch/pipermail/r-devel/2011-August/061907.html https://stat.ethz.ch/pipermail/r-devel/2009-April/053159.html https://stat.ethz.ch/pipermail/r-devel/2006-September/042715.html and one reference on R-help: https://stat.ethz.ch/pipermail/r-help/2008-November/179846.html While several list members provide their personal opinion on the matter, I could not find any statement that could be considered the agreed upon position of the CRAN maintainers and/or the R Foundation. The closest I could find are several replies by Duncan Murdoch where he writes that a package author is free in his choice of license if no actual copying of GPLed code takes place https://stat.ethz.ch/pipermail/r-devel/2006-September/042716.html https://stat.ethz.ch/pipermail/r-help/2010-June/240945.html and where he takes a critical stand against the quoted FSF interpretation of the GPL:
I don't think my point contradicts the FSF interpretation. I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program. However, I could be wrong. If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong. If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all. If a user needs my code to make yours useful, I don't see how any of that changes. The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
By your line of reasoning (which I don't agree with), if you write an R script, making use of features of R that are not present in other S dialects, then the only way to make it work would be to use R. So if you want to distribute it, you would need to GPL it. So lots of the R packages on CRAN that do not have GPL compatible licenses would be in violation of the GPL, and since CRAN is distributing them, CRAN is in violation of the GPL. That's nonsense.
(from https://stat.ethz.ch/pipermail/r-help/2008-November/179908.html) and an email by Prof. Leisch https://stat.ethz.ch/pipermail/r-devel/2009-April/053141.html where he mentions ongoing discussions in R Core and the R Foundation. However, these discussions might have only considered Revolution Analytic's ParallelR (the main topic of that thread), and I could not find a follow-up email where the result of that discussion was published. Did the CRAN maintainers and the R Foundation publish an agreed upon position on the FSF interpretation of the GPL quoted above, and I simply missed it? If yes, could it be added to the R FAQ and/or the CRAN repository policy, such that it is easier to find? If not, may I kindly ask them to explain their position?
No, CRAN and the R Foundation have not published that. I don't think either group will publish a position. You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change. The R Foundation does almost nothing, so it's a little more inscrutable.
Note that I am not asking for legal advice,
You should be. If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice. > nor am I advocating for a specific change of the current practices of the R project. Duncan Murdoch