[Rd] Implications of a Dependency on a GPLed Package

Duncan Murdoch murdoch.duncan at gmail.com
Fri Jan 25 19:31:12 CET 2013


On 25/01/2013 1:16 PM, Christian Sigg wrote:
> Dear Duncan
>
> > 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.
>
> Let me again quote parts of the GPL FAQ:
>
> > 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.
>
> The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.

I still find that paragraph to be ambiguous, but I'm willing to believe 
that they are making claims with no legal basis for them.

Duncan Murdoch

>
> I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.
>
> The preceding entry of the GPL FAQ has this to say:
>
> > If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)
> >
> >     Yes, because the software as it is actually run includes the library.
>
> There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:
>
> > Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
> >
> >    (...)
> >
> >     If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
>
>
> I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.
>
>
> > 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).
>
> I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.
>
> > 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.
>
> I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.
>
> Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:
>
> > Just a short clarification (by no means intended to stop the thread):
> > as you can imagine we are discussing the matter internally in R Core
> > and the Foundation, but there are different views and we want to
> > consolidate before we make a public statement.  If all of us were of
> > the same opinion we would already have made one.
>
>
>
>
> >> 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.
>
> This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.
>
> Best regards,
> Christian



More information about the R-devel mailing list