[Rd] Implications of a Dependency on a GPLed Package

Marc Schwartz marc_schwartz at me.com
Fri Jan 25 21:55:08 CET 2013


On Jan 25, 2013, at 2:45 PM, Simon Urbanek <Simon.Urbanek at r-project.org> wrote:

> 
> On Jan 25, 2013, at 3:32 PM, Marc Schwartz wrote:
> 
>> 
>> On Jan 25, 2013, at 12:16 PM, Christian Sigg <christian at sigg-iten.ch> 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 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
>> 
>> 
>> 
>> Some additional points, if I may:
>> 
>> 1. The discussion that Christian points to which references Fritz' comments is now going on 4 years old. I have seen nothing, to my recollection, that represents a formal position being taken by the R Foundation on this issue.
> 
> I'm somewhat baffled that the one official statement that the R Foundation made specifically for this purpose is apparently being overlooked:
> 
> https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html
> 
> Cheers,
> Simon


Well, clearly my recollection is faulty. Thanks for that Simon. Now that you point that out, I do recall Robert's post, albeit, I think it got lost in the traffic on R-Devel, which contributes to the lack of recall.

Perhaps it would be reasonable to add something to the R FAQs which at least points to that post.

As noted, it implies that the position of the R Foundation is that non-GPL compatible packages are suitable for distribution via CRAN. Note that I am not disagreeing with that position, nor advocating any change.

Regards,

Marc


> 
>> Thus, I would not have any expectation that they will. If something has been decided, it appears to be a default position to not change anything vis-a-vis CRAN without sufficient motivation to do so, which would logically be legally based at some level.
>> 
>> 2. As Christian notes, R is a GNU project and is therefore a high profile project within the open source community. I take a certain level of comfort that none of the FSF, any other open source advocacy organization or RMS himself (who as we all know is not shy on these issues and who has spoken at a useR meeting), has elected to take a negative position on this issue, resulting in any change in the behavior of CRAN. In other words, there has been no cease and desist communication regarding the distribution of non-GPL compatible packages on CRAN or elsewhere for that matter. If there was, I have no doubt that we all would have heard about it and those packages would be off CRAN or other points of distribution by now. Given some of the "energy" contained in prior communications on this issue, I would envision that one or more of those previous participants would have taken it upon themselves to proactively communicate their concerns to the FSF. Just saying.
>> 
>> 3. There are for-profit commercial vendors of R distributions who have built proprietary components on top of R, who distribute R and other components, including add-on packages, under multiple licensing scenarios. I have absolutely no doubt that those vendors' corporate legal counsel have rendered formal legal opinions suitable to the respective companies and their boards of directors/investors/shareholders that a clear separation can be made between R as a GPL application and other components that do not need to be released under a GPL compatible license, given appropriate parameters.
>> 
>> So there appear to be two issues here:
>> 
>> 1. Should CRAN, as a distribution network for a GPL application, contain non-GPL compatible packages. As I noted, that appears to be a philosophical issue, with at least a de facto position being held by the R Foundation at this time.
>> 
>> 2. Can non-GPL compatible packages for R even be created (even if "pure R"), based upon the interpretation of the GPL that Christian has postulated? Any third party R program is certainly going to call at minimum, base R functions who's source code and/or compiled binaries are not contained in the user's package/code. Thus there is an implicit dependency on base R functionality other than the interpreter/parser itself. Given this, it seems to me that this possible interpretation of the GPL applies even in the scenario where I create an R package that does not depend upon someone else's CRAN package for functionality. The significant and long standing precedent in the marketplace would seem to indicate that the answer is Yes.
>> 
>> Regards,
>> 
>> Marc
>> 
>> 
>



More information about the R-devel mailing list