Thanks Wes. I think the discussion is in line with my understanding of the 
release of optional component as well.

In Spark, which is often used as an example in various discussions, actually 
does not have GPL dependencies that are required to function at runtime. We 
have build and test dependencies (that's very hard to avoid) but they are not 
needed to install and run the package (besides R itself). We have some native C 
code in the source, but they are not required and not built (and not tested 
with, and to be honest, it has been more than 2 years, not likely to work at 

So going back to the context of Arrow, and optional component. If the goal is 
the have R source that are released with Arrow as source, and that an user will 
need to make a choice to manually extract the R pieces, build/install manually, 
my interpretation is that will be ok.

If the goal is to make such component a package released to CRAN however, then 
my take is this becomes a release by itself and what is required for the 
package to function becomes the area for discussion, as per my understanding.

From: Wes McKinney <>
Sent: Friday, August 11, 2017 7:29:29 AM
Cc: Felix Cheung
Subject: Re: R arrow dependency on Rcpp?

It seems that using Rcpp is fine because an R library for Arrow is an
optional component of the project, but will await more opinions on

+ Felix Cheung -- I wonder if you could comment further on your
concerns about licensing of R build dependencies, which were mentioned


On Thu, Aug 10, 2017 at 2:12 PM, Wes McKinney <> wrote:
> I started a discussion explaining the issue here:
> On Thu, Aug 3, 2017 at 5:50 PM, Wes McKinney <> wrote:
>> Thanks for weighing in on this, Hadley.
>> To your point
>>> You can distribute the package code according to its
>>> license, but whenever you bundle it with R (i.e. to actually use it)
>>> the GPL will apply to the whole conglomerate.
>> If someone wanted to create an all-GPLv2 software distribution
>> containing R and a bunch of libraries, then including the R Arrow
>> library would be problematic as Apache 2.0 is not compatible
>> ( I don't
>> think this is really a problem since R users generally just install
>> things from CRAN.
>> My understanding is that ASF legal has taken issue when an Apache
>> project _cannot be used at all_ without a hard GPL dependency (outside
>> certain exceptions, e.g. generated build files by GPL tools). This
>> makes it impossible to create a self-contained software distribution
>> of the project whose code and all dependencies are Apache 2.0
>> compatible. There was the recent BSD+Patents discussion on LEGAL where
>> projects were disallowed from using projects under that license as a
>> hard dependency.
>> I will open a LEGAL issue on the JIRA to discuss, but since the R
>> portion of Arrow is an _optional_ part of the project, I am hopeful
>> this will be deemed OK.
>> - Wes
>> On Thu, Aug 3, 2017 at 5:39 PM, Hadley Wickham <> wrote:
>>> On Thu, Aug 3, 2017 at 8:15 AM, Wes McKinney <> wrote:
>>>> I can open a ticket to get a definitive answer to these questions.
>>>> From and the
>>>> subsequent questions there, I view the R language and build tools like
>>>> Rcpp as part of the "R platform", which is, for the most part, all
>>>> GPL. SparkR depends on R, but only has testthat (MIT) as a dependency
>>>> beyond the R runtime. I think it is challenging to build high quality
>>>> software for the R platform relying only on the main R runtime and the
>>>> limited third party components which happens to be released under
>>>> non-CategoryX licenses.
>>> Some legal advice is probably needed, but do also see this statement
>>> from the R Foundation about package licenses:
>>> In general, the R community has taken the opinion that it is ok to
>>> license code that links to R with non-GPL (but GPL-compatible)
>>> licenses. You can distribute the package code according to its
>>> license, but whenever you bundle it with R (i.e. to actually use it)
>>> the GPL will apply to the whole conglomerate.
>>> So including an R arrow package would be fine according to the general
>>> standards of the R community. The Apache legal counsel may of course
>>> disagree.
>>> Hadley
>>> --

Reply via email to