I have code written in R, an interpreted language. The R interpreter and most R libraries are under the GPL. What are the limits upon my code, if I want to distribute it while keeping it proprietary and non-GPL?


To paraphrase the quote from the FSF given in the answer by JNic:

  • The license of the interpreter itself is of no concern. The interpreter and the software executed by it are independent works as far as copyright is concerned and their licenses don't affect each other.
  • If you want to keep your application proprietary, you cannot use any GPL-licensed library and that would include the standard library of the implementation language and any transitive dependency.
  • Since some fancy late-added language elements may themselves be implemented in the interpreter by calls to older stdlib code, it sounds like FSF is drawing a line here between “interpreted code that, by name, causes the interpreter to invoke the GPL’d standard lib”, and “interpreted code that, obscurely through the language, causes the interpreter to invoke the GPL’d standard lib”.🤔 Sounds like a hack to me, although I can’t think of any other way to preserve the spirit of the GPL for interpreted code in such languages. – Keith Russell Feb 7 at 14:32

The Free Software Foundation has the answer to your question:

When the interpreter just interprets a language, the answer is no. 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.

However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a binding mechanism; libraries that are accessed in this way are linked dynamically with the Java programs that call them. These libraries are also linked with the interpreter. If the interpreter is linked statically with these libraries, or if it is designed to link dynamically with these specific libraries, then it too needs to be released in a GPL-compatible way.

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 GPLed 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.

  • I’d read that, and I’m still not sure what are the actual limits. If my interpreted code doesn’t cause invocation of any GPL libs by the interpreter, am I fine? Also, it sounds like FSF is saying something absurd here: interpreted code does not trigger the GPL when it causes the interpreter to run its own internal GPL code, but interpreted code does trigger the GPL when it causes to interpreter to run GPL code via the DLL mechanism. And another: interpreted code is “just data”, but if interpreted code causes an interpreter to invoke GPL interpreted code, it’s now one big program under the GPL. – Keith Russell Jan 8 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.