Re: [Rd] alternate licensing for package data?

[Martyn Plummer]

I think this is covered well by the CRAN repository policy:
http://cran.r-project.org/web/packages/policies.html 

The two key license requirements are that: 
1) CRAN must have a perpetual license to distribute the package
2) The package license should be listed here: 
https://svn.r-project.org/R/trunk/share/licenses/license.db
Packages with licenses not included in that list are generally not
accepted.

However, there are exceptions, and you can find some by searching for
"non-commercial site:cran.r-project.org" on Google. See also section
1.1.2 of the Writing R Extensions manual for an explanation.

Personally, I would not want to add the extra complexity to a package
that is otherwise GPL.

Martyn

On Tue, 2015-04-21 at 19:23 -0400, Ben Bolker wrote:
>   Does anyone have speculations about the implications of the GPL for
> data included in a package, or more generally for restricting use of data?
> 
>   The specific use case is that I have a package which is otherwise
> GPL (version unspecified at present).  There are various data sets
> included, but they are all essentially in the public domain.  I'm
> thinking about including another data set, but the original author of
> that data might like to impose some reasonable restrictions (e.g.
> please don't use in an academic publication without explicit
> permission ...)  Would such rules be expected to be compatible with
> CRAN rules?  Will having the package be "GPL except for file XXX, see
> LICENSE" mess things up horribly?
> 
>   I can of course make the data available for download and include a
> link, and/or make a special package that contains only these data, but
> it would seem to be more convenient for end users, and more
> future-proof, to put everything in one place.
> 
>   I know I will eventually need to take this up with CRAN, but I'm
> looking for reasonably informed opinions/suggestions ...
> 
>   cheers
> Ben Bolker
> 
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

---
This message and its attachments are strictly confidenti...{{dropped:8}}

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] alternate licensing for package data?

[Roger Bivand]

Martyn Plummer  iarc.fr> writes:

> 
> I think this is covered well by the CRAN repository policy:
> http://cran.r-project.org/web/packages/policies.html 
> 
> The two key license requirements are that: 
> 1) CRAN must have a perpetual license to distribute the package
> 2) The package license should be listed here: 
> https://svn.r-project.org/R/trunk/share/licenses/license.db
> Packages with licenses not included in that list are generally not
> accepted.
> 
...
> 
> Personally, I would not want to add the extra complexity to a package
> that is otherwise GPL.
> 
> Martyn
> 
> On Tue, 2015-04-21 at 19:23 -0400, Ben Bolker wrote:
> >   Does anyone have speculations about the implications of the GPL for
> > data included in a package, or more generally for restricting use of data?
> > 
...
While I agree with Martyn with respect to code, documentation, and
vignettes, the point Ben raises is relevant and not obvious. Data sets in
say GLP-licensed packages are on occasion challenged by Debian packagers
where it isn't obvious that GPL is appropriate. Some spatial packages are
not accepted for packaging as is because of included data, data that is
needed to run realistic examples. 

The problem could be picky packagers, but it is also reasonable that
well-known example data sets could be licensed differently.
share/licenses/license.db lists for example CC BY-SA 4.0 as both FOSS and
extensible but free_and_GPLv3_incompatible. One possibility I examined when
challenged was to place all such data files in a separate package, for
example under a CC license accepted by CRAN - I didn't complete the task,
but understand Ben's question as applying to the same question.

Roger

> > 
> >   cheers
> > Ben Bolker
> > 
> > 

>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] alternate licensing for package data?

[Brian G. Peterson]

On Wed, 2015-04-22 at 11:34 +, Roger Bivand wrote:
> Martyn Plummer  iarc.fr> writes:
> 
> > 
> > I think this is covered well by the CRAN repository policy:
> > http://cran.r-project.org/web/packages/policies.html 
> > 
> > The two key license requirements are that: 
> > 1) CRAN must have a perpetual license to distribute the package
> > 2) The package license should be listed here: 
> > https://svn.r-project.org/R/trunk/share/licenses/license.db
> > Packages with licenses not included in that list are generally not
> > accepted.
> > 
> ...
> > 
> > Personally, I would not want to add the extra complexity to a package
> > that is otherwise GPL.
> > 
> > Martyn
> > 
> > On Tue, 2015-04-21 at 19:23 -0400, Ben Bolker wrote:
> > >   Does anyone have speculations about the implications of the GPL for
> > > data included in a package, or more generally for restricting use of data?
> > > 
> ...
> While I agree with Martyn with respect to code, documentation, and
> vignettes, the point Ben raises is relevant and not obvious. Data sets in
> say GLP-licensed packages are on occasion challenged by Debian packagers
> where it isn't obvious that GPL is appropriate. Some spatial packages are
> not accepted for packaging as is because of included data, data that is
> needed to run realistic examples. 
> 
> The problem could be picky packagers, but it is also reasonable that
> well-known example data sets could be licensed differently.
> share/licenses/license.db lists for example CC BY-SA 4.0 as both FOSS and
> extensible but free_and_GPLv3_incompatible. One possibility I examined when
> challenged was to place all such data files in a separate package, for
> example under a CC license accepted by CRAN - I didn't complete the task,
> but understand Ben's question as applying to the same question.

It is also clearly possible to license data files differently than the
package.  GPL is copyleft for compiled code.  R data files are not
compiled/linked into the package, they are included in a tarball or zip
file.  As such, the copyleft provision of GPL doesn't necessarily apply
to non-compiled files in the package collection, and isn't necessarily
intended to apply (the Gnu licenses page suggests not using GPL for
data).

Whether CRAN or Debian packagers would accept a open but mixed code/data
license scheme is not for me to say, but I don't see any impediments
from the licenses themselves.


-- 
Brian G. Peterson
http://braverock.com/brian/
Ph: 773-459-4973
IM: bgpbraverock

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug 15899 - Omitted 'extern' on 'R_running_as_main_program' after refactor can cause linker errors for applications embedding R

[Martin Maechler]

> Jack Howarth 
> on Tue, 21 Apr 2015 10:52:52 -0400 writes:

> Is there any plans for addressing the regression...
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15899

> in the 3.2.1 release? In the fink project, I had to resort to creating a
> fixincludes subdirectory containg a local copy of the offending
> Rinterface.h header with the missing extern on the declaration of

I have addressed it now,  for the moment for R-devel only.
I will port the patch to "R 3.2 patched" (which should become R
3.2.1 eventualy) if there are no problems, issues with it.

Thank you for the reminder.

Martin Maechler

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] alternate licensing for package data?

[Dirk Eddelbuettel]

On 22 April 2015 at 11:34, Roger Bivand wrote:
| While I agree with Martyn with respect to code, documentation, and
| vignettes, the point Ben raises is relevant and not obvious. Data sets in
| say GLP-licensed packages are on occasion challenged by Debian packagers

Not generally the packagers (who get frustrated by this like everybody else)
but by the "ftp-masters" teams who look over what gets into the Archive. 

They are the license reviewers, and gate-keepers.

In several cases we (ie "packagers") had to write README.sources to document
origins of datasets.  That is generally a little silly as ... R itself
already enforces in the .Rd files. So for the packages where I had to do that
the README.sources effectively becomes a forward reference to the R docs.
But then again the ftp-masters review _thousands_ of packages and having to
help their workflow is a small burden.

In general, nitpicky licensing issue have been discussed (to mindnumbing
length) on the debian-legal list. Those interested in the issue may want to
peruse or search the archive:
http://news.gmane.org/gmane.linux.debian.devel.legal

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] shlib problems with Intel compiler

[Martyn Plummer]

On Tue, 2015-04-21 at 11:46 -0600, Andy Jacobson (NOAA Affiliate) wrote:
> Hi,
> 
> I'm encountering trouble compiling caTools_1.17.1.tar.gz and
> e1071_1.6-4.tar.gz on a Linux system using the Intel compiler suite.
> 14 other packages I generally use installed without any trouble.  I
> notice both of these trouble packages have a C++ component, so I
> wonder if that might be the issue.  Below, there's information on my
> platform, compiler, and some diagnostic output showing the errors.
> 
> Advice appreciated!
> 
> Thanks,
> 
> Andy

There are two things missing when R tries to create the shared object
file on this line:

icpc -L/usr/local/lib64 -o e1071.so Rsvm.o cmeans.o cshell.o floyd.o
svm.o

Firstly, the compiler flag "-shared" is missing. It tells the compiler
to build a shared object instead of an executable. Secondly the linker
flag "-lR" is missing, along with the "-L" flag that tells the linker
where to find the shared R library.

To find out what went wrong, you should share the configuration you used
when building R.

Martyn

> 
> 
> Intel compiler suite:  icc (ICC) 14.0.2 20140120
> 
> sessionInfo() reports:
> 
> R version 3.1.3 (2015-03-09)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> Running under: Red Hat Enterprise Linux Server release 6.5 (Santiago)
> 
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C  
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8   
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base 
> 
> loaded via a namespace (and not attached):
> [1] tools_3.1.3
> 
> 
> Abbreviated versions of the output from R CMD INSTALL:
> 
> For caTools:
> 
> * installing to library ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
> * installing *source* package ‘caTools’ ...
> ** package ‘caTools’ successfully unpacked and MD5 sums checked
> ** libs
> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include
> -fpic  -g -O3 -fp-model precise  -c Gif2R.cpp -o Gif2R.o
> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include
> -fpic  -g -O3 -fp-model precise  -c GifTools.cpp -o GifTools.o
> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
> runfunc.c -o runfunc.o
> icpc -L/usr/local/lib64 -o caTools.so Gif2R.o GifTools.o runfunc.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function 
> `_start':
> (.text+0x20): undefined reference to `main'
> Gif2R.o: In function `imwritegif':
> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:19: undefined 
> reference to `R_chk_calloc'
> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:23: undefined 
> reference to `R_chk_free'
> ... (many more R_* undefined references)
> 
> For e1071:
> 
> * installing to library ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
> * installing *source* package ‘e1071’ ...
> ** package ‘e1071’ successfully unpacked and MD5 sums checked
> checking for C++ compiler default output file name... a.out
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether icpc accepts -g... yes
> ** libs
> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c Rsvm.c 
> -o Rsvm.o
> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
> cmeans.c -o cmeans.o
> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
> cshell.c -o cshell.o
> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
> floyd.c -o floyd.o
> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include
> -fpic  -g -O3 -fp-model precise  -c svm.cpp -o svm.o
> icpc -L/usr/local/lib64 -o e1071.so Rsvm.o cmeans.o cshell.o floyd.o svm.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function 
> `_start':
> (.text+0x20): undefined reference to `main'
> Rsvm.o: In function `do_cross_validation':
> /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:91: undefined 
> reference to `GetRNGstate'
> /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:94: undefined 
> reference to `unif_rand'
> /tmp/Rtmp9h7iYE/R.INSTALL1d9615a42180e/e1071/src/Rsvm.c:106: undefined 
> reference to `PutRNGstate'
> ... (man

Re: [Rd] shlib problems with Intel compiler

[Andy Jacobson (NOAA Affiliate)]

Hi Martyn,

Thanks for your insight, that seems pretty direct.  Unfortunately, I did not 
compile this version of R (it's on a large supercomputer system and this 
version of R was installed by the admins).  Using "R CMD config", I see the 
following relevant settings:

DYLIB_LD = icc -std=gnu99
DYLIB_LDFLAGS = -shared -openmp
LDFLAGS = -L/opt/compilers/intel/cce/9.1.039/lib 
-L/opt/compilers/intel/fce/9.1.033/lib -L/usr/local/lib64
SHLIB_CXXLD = icpc
SHLIB_CXXLDFLAGS = 
SHLIB_LD = icc -std=gnu99
SHLIB_LDFLAGS = -shared

It looks like the SHLIB_CXXLDFLAGS is missing the "-shared -lR 
-L".  It's a mystery to me how R was built and configured such 
that it has incomplete/incorrect flags.

By trial and error I figured out how to use a .R/Makevars setting to add the 
required flags to SHLIB_CXXLDFLAGS.  (It sure would have been useful to have a 
reference about the syntax and variable names that the Makevars file can 
contain...is that documented somewhere?)

I wonder if the recommendation for "-lR" is correct.  None of the other 
packages are compiled with that flag, and everything seems to compile and load 
OK in R without using that.

Best Regards,

Andy

> On Apr 22, 2015, at 9:30 AM, Martyn Plummer  wrote:
> 
> On Tue, 2015-04-21 at 11:46 -0600, Andy Jacobson (NOAA Affiliate) wrote:
>> Hi,
>> 
>> I'm encountering trouble compiling caTools_1.17.1.tar.gz and
>> e1071_1.6-4.tar.gz on a Linux system using the Intel compiler suite.
>> 14 other packages I generally use installed without any trouble.  I
>> notice both of these trouble packages have a C++ component, so I
>> wonder if that might be the issue.  Below, there's information on my
>> platform, compiler, and some diagnostic output showing the errors.
>> 
>> Advice appreciated!
>> 
>> Thanks,
>> 
>> Andy
> 
> There are two things missing when R tries to create the shared object
> file on this line:
> 
> icpc -L/usr/local/lib64 -o e1071.so Rsvm.o cmeans.o cshell.o floyd.o
> svm.o
> 
> Firstly, the compiler flag "-shared" is missing. It tells the compiler
> to build a shared object instead of an executable. Secondly the linker
> flag "-lR" is missing, along with the "-L" flag that tells the linker
> where to find the shared R library.
> 
> To find out what went wrong, you should share the configuration you used
> when building R.
> 
> Martyn
> 
>> 
>> 
>> Intel compiler suite:  icc (ICC) 14.0.2 20140120
>> 
>> sessionInfo() reports:
>> 
>> R version 3.1.3 (2015-03-09)
>> Platform: x86_64-unknown-linux-gnu (64-bit)
>> Running under: Red Hat Enterprise Linux Server release 6.5 (Santiago)
>> 
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C  
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8   
>> [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
>> [9] LC_ADDRESS=C   LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   
>> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base 
>> 
>> loaded via a namespace (and not attached):
>> [1] tools_3.1.3
>> 
>> 
>> Abbreviated versions of the output from R CMD INSTALL:
>> 
>> For caTools:
>> 
>> * installing to library 
>> ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
>> * installing *source* package ‘caTools’ ...
>> ** package ‘caTools’ successfully unpacked and MD5 sums checked
>> ** libs
>> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include
>> -fpic  -g -O3 -fp-model precise  -c Gif2R.cpp -o Gif2R.o
>> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include
>> -fpic  -g -O3 -fp-model precise  -c GifTools.cpp -o GifTools.o
>> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
>> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
>> runfunc.c -o runfunc.o
>> icpc -L/usr/local/lib64 -o caTools.so Gif2R.o GifTools.o runfunc.o
>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function 
>> `_start':
>> (.text+0x20): undefined reference to `main'
>> Gif2R.o: In function `imwritegif':
>> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:19: undefined 
>> reference to `R_chk_calloc'
>> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:23: undefined 
>> reference to `R_chk_free'
>> ... (many more R_* undefined references)
>> 
>> For e1071:
>> 
>> * installing to library 
>> ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
>> * installing *source* package ‘e1071’ ...
>> ** package ‘e1071’ successfully unpacked and MD5 sums checked
>> checking for C++ compiler default output file name... a.out
>> checking whether the C++ compiler works... yes
>> checking whether we are cross compiling... no
>> checking for suffix of executables... 
>> checking for suffix of object files... o
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether icpc accepts -g... yes
>> ** libs
>> icc -s

Re: [Rd] shlib problems with Intel compiler

[Martyn Plummer]

I was assuming that R was configured with --enable-R-shlib but if that's not 
the case then you don't need it.

Martyn


> On 22 Apr 2015, at 18:40, Andy Jacobson (NOAA Affiliate) 
>  wrote:
> 
> Hi Martyn,
> 
> Thanks for your insight, that seems pretty direct.  Unfortunately, I did not 
> compile this version of R (it's on a large supercomputer system and this 
> version of R was installed by the admins).  Using "R CMD config", I see the 
> following relevant settings:
> 
> DYLIB_LD = icc -std=gnu99
> DYLIB_LDFLAGS = -shared -openmp
> LDFLAGS = -L/opt/compilers/intel/cce/9.1.039/lib 
> -L/opt/compilers/intel/fce/9.1.033/lib -L/usr/local/lib64
> SHLIB_CXXLD = icpc
> SHLIB_CXXLDFLAGS = 
> SHLIB_LD = icc -std=gnu99
> SHLIB_LDFLAGS = -shared
> 
> It looks like the SHLIB_CXXLDFLAGS is missing the "-shared -lR 
> -L".  It's a mystery to me how R was built and configured such 
> that it has incomplete/incorrect flags.
> 
> By trial and error I figured out how to use a .R/Makevars setting to add the 
> required flags to SHLIB_CXXLDFLAGS.  (It sure would have been useful to have 
> a reference about the syntax and variable names that the Makevars file can 
> contain...is that documented somewhere?)
> 
> I wonder if the recommendation for "-lR" is correct.  None of the other 
> packages are compiled with that flag, and everything seems to compile and 
> load OK in R without using that.
> 
> Best Regards,
> 
> Andy
> 
>> On Apr 22, 2015, at 9:30 AM, Martyn Plummer  wrote:
>> 
>> On Tue, 2015-04-21 at 11:46 -0600, Andy Jacobson (NOAA Affiliate) wrote:
>>> Hi,
>>> 
>>> I'm encountering trouble compiling caTools_1.17.1.tar.gz and
>>> e1071_1.6-4.tar.gz on a Linux system using the Intel compiler suite.
>>> 14 other packages I generally use installed without any trouble.  I
>>> notice both of these trouble packages have a C++ component, so I
>>> wonder if that might be the issue.  Below, there's information on my
>>> platform, compiler, and some diagnostic output showing the errors.
>>> 
>>> Advice appreciated!
>>> 
>>> Thanks,
>>> 
>>> Andy
>> 
>> There are two things missing when R tries to create the shared object
>> file on this line:
>> 
>> icpc -L/usr/local/lib64 -o e1071.so Rsvm.o cmeans.o cshell.o floyd.o
>> svm.o
>> 
>> Firstly, the compiler flag "-shared" is missing. It tells the compiler
>> to build a shared object instead of an executable. Secondly the linker
>> flag "-lR" is missing, along with the "-L" flag that tells the linker
>> where to find the shared R library.
>> 
>> To find out what went wrong, you should share the configuration you used
>> when building R.
>> 
>> Martyn
>> 
>>> 
>>> 
>>> Intel compiler suite:  icc (ICC) 14.0.2 20140120
>>> 
>>> sessionInfo() reports:
>>> 
>>> R version 3.1.3 (2015-03-09)
>>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>> Running under: Red Hat Enterprise Linux Server release 6.5 (Santiago)
>>> 
>>> locale:
>>> [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C  
>>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8   
>>> [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
>>> [9] LC_ADDRESS=C   LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   
>>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base 
>>> 
>>> loaded via a namespace (and not attached):
>>> [1] tools_3.1.3
>>> 
>>> 
>>> Abbreviated versions of the output from R CMD INSTALL:
>>> 
>>> For caTools:
>>> 
>>> * installing to library 
>>> ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
>>> * installing *source* package ‘caTools’ ...
>>> ** package ‘caTools’ successfully unpacked and MD5 sums checked
>>> ** libs
>>> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include   
>>>  -fpic  -g -O3 -fp-model precise  -c Gif2R.cpp -o Gif2R.o
>>> icpc -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  -I/usr/local/include   
>>>  -fpic  -g -O3 -fp-model precise  -c GifTools.cpp -o GifTools.o
>>> icc -std=gnu99 -I/apps/R/3.1.3-intel/lib64/R/include -DNDEBUG  
>>> -I/usr/local/include-fpic  -g -O3 -wd188 -ip -fp-model precise  -c 
>>> runfunc.c -o runfunc.o
>>> icpc -L/usr/local/lib64 -o caTools.so Gif2R.o GifTools.o runfunc.o
>>> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In 
>>> function `_start':
>>> (.text+0x20): undefined reference to `main'
>>> Gif2R.o: In function `imwritegif':
>>> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:19: undefined 
>>> reference to `R_chk_calloc'
>>> /tmp/RtmpEfnBsm/R.INSTALL17c3a7327d4fb/caTools/src/Gif2R.cpp:23: undefined 
>>> reference to `R_chk_free'
>>> ... (many more R_* undefined references)
>>> 
>>> For e1071:
>>> 
>>> * installing to library 
>>> ‘/scratch3/BMC/co2/lib/R-3.1/x86_64-unknown-linux-gnu’
>>> * installing *source* package ‘e1071’ ...
>>> ** package ‘e1071’ successfully unpacked and MD5 sums checked
>>> checking for C++

Re: [Rd] alternate licensing for package data?

[Ben Bolker]

Dirk Eddelbuettel  debian.org> writes:

> On 22 April 2015 at 11:34, Roger Bivand wrote:
> | While I agree with Martyn with respect to code, documentation, and
> | vignettes, the point Ben raises is relevant and not obvious. Data sets in
> | say GLP-licensed packages are on occasion challenged by Debian packagers

[GPL]
 
> Not generally the packagers (who get frustrated by this like everybody else)
> but by the "ftp-masters" teams who look over what gets into the Archive. 
> 
> They are the license reviewers, and gate-keepers.
> 
> In several cases we (ie "packagers") had to write README.sources to document
> origins of datasets.  That is generally a little silly as ... R itself
> already enforces in the .Rd files. So for the packages where I had to do that
> the README.sources effectively becomes a forward reference to the R docs.
> But then again the ftp-masters review _thousands_ of packages and having to
> help their workflow is a small burden.
> 
> In general, nitpicky licensing issue have been discussed (to mindnumbing
> length) on the debian-legal list. Those interested in the issue may want to
> peruse or search the archive:
> http://news.gmane.org/gmane.linux.debian.devel.legal
> 
> Dirk

Thanks for the information, everyone!  I think I'm just going to
handle it the sloppy way, providing a .Rd file containing
documentation and a URL for the data set.  This is not particularly
good for long-term maintenance, but it seems silly to try to get a
separate package onto CRAN for a *single* (small) data set.

  For what it's worth, I've been informed by the CRAN maintainers
that 

> 'license' is singular in the CRAN policies, something people
  sometimes overlook.
> A package must have a single licence that applies to all of the
  package (even if alternative licences are offered for all or part),
  so "GPL except for file XXX" is not viable.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] alternate licensing for package data?

[Avraham Adler]

To get around this last problem, perhaps you can take advantage of
CRAN's suggestion regarding large data files [1] where they say
"[w]here a large amount of data is required (even after compression),
consideration should be given to a separate data-only package which
can be updated only rarely (since older versions of packages are
archived in perpetuity)." This would allow you to have a different
license for the data package than for the main package. Whether CRAN
will except a file + LICENSE with "please only use academically" or a
CC-BY-NC, is a different question.

Avi

[1] 

On Wed, Apr 22, 2015 at 4:49 PM, Ben Bolker  wrote:
> Dirk Eddelbuettel  debian.org> writes:
>
>> On 22 April 2015 at 11:34, Roger Bivand wrote:
>> | While I agree with Martyn with respect to code, documentation, and
>> | vignettes, the point Ben raises is relevant and not obvious. Data sets in
>> | say GLP-licensed packages are on occasion challenged by Debian packagers
>
> [GPL]
>
>> Not generally the packagers (who get frustrated by this like everybody else)
>> but by the "ftp-masters" teams who look over what gets into the Archive.
>>
>> They are the license reviewers, and gate-keepers.
>>
>> In several cases we (ie "packagers") had to write README.sources to document
>> origins of datasets.  That is generally a little silly as ... R itself
>> already enforces in the .Rd files. So for the packages where I had to do that
>> the README.sources effectively becomes a forward reference to the R docs.
>> But then again the ftp-masters review _thousands_ of packages and having to
>> help their workflow is a small burden.
>>
>> In general, nitpicky licensing issue have been discussed (to mindnumbing
>> length) on the debian-legal list. Those interested in the issue may want to
>> peruse or search the archive:
>> http://news.gmane.org/gmane.linux.debian.devel.legal
>>
>> Dirk
>
> Thanks for the information, everyone!  I think I'm just going to
> handle it the sloppy way, providing a .Rd file containing
> documentation and a URL for the data set.  This is not particularly
> good for long-term maintenance, but it seems silly to try to get a
> separate package onto CRAN for a *single* (small) data set.
>
>   For what it's worth, I've been informed by the CRAN maintainers
> that
>
>> 'license' is singular in the CRAN policies, something people
>   sometimes overlook.
>> A package must have a single licence that applies to all of the
>   package (even if alternative licences are offered for all or part),
>   so "GPL except for file XXX" is not viable.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel