You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Wes McKinney (JIRA)" <ji...@apache.org> on 2017/08/10 18:13:01 UTC
[jira] [Updated] (LEGAL-324) GPL or LGPL build or runtime
dependencies of optional / non-essential project components
[ https://issues.apache.org/jira/browse/LEGAL-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wes McKinney updated LEGAL-324:
-------------------------------
Description:
Apache Arrow provides a language-agnostic columnar in-memory data format and fast messaging framework (for RPC/IPC), among other things. One of the keys to this project's success is having implementations that work with many different programming languages and frameworks. Users may use one or more of the Arrow implementations, but in general
For example, we currently have code that involves
* C++
* Java
* C
* Ruby
* Python
* JavaScript
We are looking to add other languages to the mix, either as native implementations or as bindings to one of the other project components, like the C++ library.
As one concrete example, we would like to expand the community to include R developers and users. The R programming language has many tools to make developing bindings to C and C++ libraries easy and productive, but the R programming ecosystem is, by and large, a GPL-leaning ecosystem. This includes the main R interpreter runtime, as well as many of the build tools (like Rcpp, a framework for simplify writing R extensions that utilize C++ and possible link to other C++ libraries). In R, in particular, it is very uncommon to see complete software distributions released under the GPL or any other license. Users generally install the R platform and then install individual packages separately through R's package management system, CRAN.
So our question is: what should our position be on *optional* components of Apache Arrow which
* May have GPL (v2 or v3) or LGPL build dependencies
* May have GPL or LGPL runtime dependencies
These optional components will not preclude users from making use of the Apache Arrow format or primary reference implementations (Java and C++) in a fully Apache 2.0-compatible context, nor creating software distributions deriving from Arrow source distributions. The goal of having these optional components is to grow the Arrow community and simplify interoperability between languages and runtime ecosystems.
Thank you
was:
The Apache Arrow provides a language-agnostic columnar in-memory data format and fast messaging framework (for RPC/IPC), among other things. One of the keys to this project's success is having implementations that work with many different programming languages and frameworks. Users may use one or more of the Arrow implementations, but in general
For example, we currently have code that involves
* C++
* Java
* C
* Ruby
* Python
* JavaScript
We are looking to add other languages to the mix, either as native implementations or as bindings to one of the other project components, like the C++ library.
As one concrete example, we would like to expand the community to include R developers and users. The R programming language has many tools to make developing bindings to C and C++ libraries easy and productive, but the R programming ecosystem is, by and large, a GPL-leaning ecosystem. This includes the main R interpreter runtime, as well as many of the build tools (like Rcpp, a framework for simplify writing R extensions that utilize C++ and possible link to other C++ libraries). In R, in particular, it is very uncommon to see complete software distributions released under the GPL or any other license. Users generally install the R platform and then install individual packages separately through R's package management system, CRAN.
So our question is: what should our position be on *optional* components of Apache Arrow which
* May have GPL (v2 or v3) or LGPL build dependencies
* May have GPL or LGPL runtime dependencies
These optional components will not preclude users from making use of the Apache Arrow format or primary reference implementations (Java and C++) in a fully Apache 2.0-compatible context, nor creating software distributions deriving from Arrow source distributions. The goal of having these optional components is to grow the Arrow community and simplify interoperability between languages and runtime ecosystems.
Thank you
> GPL or LGPL build or runtime dependencies of optional / non-essential project components
> ----------------------------------------------------------------------------------------
>
> Key: LEGAL-324
> URL: https://issues.apache.org/jira/browse/LEGAL-324
> Project: Legal Discuss
> Issue Type: Question
> Reporter: Wes McKinney
>
> Apache Arrow provides a language-agnostic columnar in-memory data format and fast messaging framework (for RPC/IPC), among other things. One of the keys to this project's success is having implementations that work with many different programming languages and frameworks. Users may use one or more of the Arrow implementations, but in general
> For example, we currently have code that involves
> * C++
> * Java
> * C
> * Ruby
> * Python
> * JavaScript
> We are looking to add other languages to the mix, either as native implementations or as bindings to one of the other project components, like the C++ library.
> As one concrete example, we would like to expand the community to include R developers and users. The R programming language has many tools to make developing bindings to C and C++ libraries easy and productive, but the R programming ecosystem is, by and large, a GPL-leaning ecosystem. This includes the main R interpreter runtime, as well as many of the build tools (like Rcpp, a framework for simplify writing R extensions that utilize C++ and possible link to other C++ libraries). In R, in particular, it is very uncommon to see complete software distributions released under the GPL or any other license. Users generally install the R platform and then install individual packages separately through R's package management system, CRAN.
> So our question is: what should our position be on *optional* components of Apache Arrow which
> * May have GPL (v2 or v3) or LGPL build dependencies
> * May have GPL or LGPL runtime dependencies
> These optional components will not preclude users from making use of the Apache Arrow format or primary reference implementations (Java and C++) in a fully Apache 2.0-compatible context, nor creating software distributions deriving from Arrow source distributions. The goal of having these optional components is to grow the Arrow community and simplify interoperability between languages and runtime ecosystems.
> Thank you
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org