On 27.07.2015 15:09, Greg Troxel wrote: > > Rainer M Krug <rai...@krugs.de> writes: > >> These packages all depend on R itself. >> >> So isn't this the same as in emacs / elisp? Isn't an exporter / .el file >> the same as a package in R, something which enhances the original >> product using a provided interface (the functions) but does not change >> anything in the original program (R or emacs)? > > It's both the same and different. > > The legal question of whether R packages are derivative works of R is > similar to the question of elisp packages that use editing primitives > are derivative works of emacs.
https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL seems to give an answer: The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. [...] 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. So if I understand this correctly, an R module can be non-GPL if and only if it does not use any GPL'ed R modules. Cheers, Andreas.
