Re: How to make a non-GPL Org-mode exporter?

[Andreas Hilboll <lists@hilboll.de>]

On 27.07.2015 15:09, Greg Troxel wrote:
> 
> Rainer M Krug <Rainer@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.