Re: [R-pkg-devel] Questions for writing a package

[Marc Schwartz]

> On Jun 11, 2015, at 7:02 AM, Dirk Eddelbuettel  wrote:
> 
> 
> On 11 June 2015 at 14:10, haixiao...@aliyun.com wrote:
> | I'm now developing a package, which needs to call other released software.
> | The software include executable files with configuration files for 
> Win/Linux/Mac. There is no need to install or compiling the software.
> | I know it is possible to call the software  executable files by invoking a 
> system command using the function 'system()', 
> | but how can I build up a package with these executable files? What 
> directory should I put the software files?  
> | Does anyone have experience or solutions? 
> 
> Please see
> 
>   
> http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dR-scripts-in-packages
> 
> as well as   help(system.file)   in R to locate such files.
> 
> As far as I know CRAN will probably reject a package containing binaries.


That is correct, as per:

  http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-structure


"A source package if possible should not contain binary executable files: they 
are not portable, and a security risk if they are of the appropriate 
architecture.  R CMD check will warn about them4 unless they are listed (one 
filepath per line) in a file BinaryFiles at the top level of the package. Note 
that CRAN will not accept submissions containing binary files even if they are 
listed.”


Note the last sentence.

Regards,

Marc Schwartz


> 
> Dirk

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

Re: [R-pkg-devel] Are import-export-only packages allowed on CRAN?

[Marc Schwartz]

> On Jul 6, 2015, at 5:47 AM, Dirk Eddelbuettel  wrote:
> 
> 
> Hi Richie,
> 
> On 5 July 2015 at 19:17, Richard Cotton wrote:
> | One piece of feedback that I received at useR was that the assertive
> | package is getting too big, and should be broken down into smaller
> | pieces.
> | 
> | I want to split the functionality into assertive.base,
> | assertive.types, and a few others, then have the assertive package as
> | a virtual package (suggestions for better terminology welcomed) that
> | just imports and reexports the contents of the underlying pieces.
> | 
> | That way end-users can can still type library(assertive) and have the
> | same behaviour as before, and package developers who worry about
> | having lightweight dependencies can just use the parts that they need.
> | 
> | Before I do the refactoring, I wanted to check that it is OK to have a
> | package without any of its own content (other than vignettes) on CRAN.
> | Is it OK?
> 
> That is a pure CRAN question; maybe someone from CRAN wants to chime in or
> else you need to ask directly.
> 
> Greg Warnes has/had such a meta package (which I look after in Debian as a
> still-existing-there whole and componentds), and Henrik does too.  What **I
> think** the practice is now discouraged somewhere in WRE or CRP.  But no
> direct reference, sorry,
> 
> Dirk


If you are referring to a package “bundle”, they were deprecated in R 2.10.0 
and put into defunct status in R 2.11.0. That is from the NEWS file:

  https://svn.r-project.org/R/trunk/doc/NEWS.2

There is no longer any reference to them in R-Exts.

Greg’s “gregmisc” bundle is no longer active on CRAN, in deference to using his 
component packages directly.


Regards,

Marc Schwartz

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

Re: [R-pkg-devel] UseR! Session: Navigating the jungle of R packages.

[Marc Schwartz]

Hi All,

A few points:

1. With respect to the CRAN Task Views, they are arguably buried a bit in the 
menus and that may contribute to low traffic. There is no direct link from the 
R Home page, albeit, there is a link on the main CRAN page, which is not 
prominent. I wonder if it might be reasonable for the main R web site 
maintainers to consider putting a link to the Task Views just below the CRAN 
link in the Download section or, perhaps better, in the Documentation section.

2. A group of us, led by Frank Harrell, who met during the DSC meeting out at 
Stanford last summer after the useR! meeting worked on modifying the online 
content for getting "Help with R" on the main R site home page. We added a 
brief section on the Task Views in the "R Help on the Internet" section to at 
least incrementally raise awareness:

  https://www.r-project.org/help.html

3. I see that Spencer's name is listed below and would presume that his 'sos' 
package would be featured in such a presentation? We also mention 'sos' on the 
above help page.

4. I would echo Jim's comments below regarding the use of Google, but I would 
add the use of http://www.rseek.org, which does have a tab for 'packages' on 
the results page when doing keyword searches. rseek.org is my first resource 
when searching for functionality in packages or posts to the lists.


Regards,

Marc Schwartz


> On Feb 10, 2017, at 4:26 PM, Jim Lemon  wrote:
> 
> This discussion started me thinking about searching for a function or
> package, as many questions on the R help list indicate the that poster
> couldn't find (or hasn't searched for) what they want. I don't think I
> have ever used task views. If I haven't got a clue where to look for
> something, I use Google. I can't recall an occasion when I didn't get
> an answer, even if it was that what I wanted didn't exist. Perhaps we
> should ask why Google is so good at answering uninformed questions, in
> particular about R. I'm not the only person on the help list who
> advises the clueless to try Google.
> 
> Jim
> 
> 
> On Sat, Feb 11, 2017 at 3:51 AM, Ben Bolker  wrote:
>>  I definitely read the task views and advise others to do so.  I
>> don't know how representative my little corner of the world is,
>> though.
>> 
>>  I have an embryonic task view on mixed models at
>> https://github.com/bbolker/mixedmodels-misc/blob/master/MixedModels.ctv
>> but the perfect is the enemy of the good ...
>> 
>> 
>> On Fri, Feb 10, 2017 at 9:56 AM, J C Nash  wrote:
>>> We'd be more than happy to have you contribute directly. The goal is not
>>> just an
>>> information session, but to get some movement to ways to make the package
>>> collection(s)
>>> easier to use effectively. Note to selves: "effectively" is important -- we
>>> could make
>>> things easy by only recommending a few packages.
>>> 
>>> Best, JN
>>> 
>>> 
>>> On 2017-02-10 09:29 AM, Michael Dewey wrote:
>>>> 
>>>> Dear all
>>>> 
>>>> That seems an interesting session. I am the maintainer of one of the CRAN
>>>> Task Views (MetaAnalysis) and will attend
>>>> unless I am successful in the draw for Wimbledon tickets.
>>>> 
>>>> Just in case I strike lucky one question I would have raised from the
>>>> floor if I were there would have been "Does anyone
>>>> read the Task Views?". Since I started mine I have received only a couple
>>>> of suggestions for additions including a very
>>>> abrupt one about a package which had been included for months but whose
>>>> author clearly did not read before writing. So I
>>>> would ask whether we need to focus much energy on the Task Views.
>>>> 
>>>> So, maybe see you there, maybe not.
>>>> 
>>>> 
>>>> On 16/01/2017 14:57, ProfJCNash wrote:
>>>>> 
>>>>> Navigating the Jungle of R Packages
>>>>> 
>>>>> The R ecosystem has many packages in various collections,
>>>>> especially CRAN, Bioconductor, and GitHub. While this
>>>>> richness of choice speaks to the popularity and
>>>>> importance of R, the large number of contributed packages
>>>>> makes it difficult for users to find appropriate tools for
>>>>> their work.
>>>>> 
>>>>> A session on this subject has been approved for UseR! in
>>>>> Brussels. The tentative structure is three short
>>>>> introductory pre

Re: [R-pkg-devel] Exited with status -1073741819.

[Marc Schwartz]

Rampal,

One additional thought here.

Since you reference RTools in your initial post, I presume that this is 
occurring on Windows, though not sure which version.

Have you tried to build the package using the WinBuilder site provided by Uwe?

If not, go here:

  https://win-builder.r-project.org

and request a build of the package using R-Devel.

See if any warnings/errors are picked up there. If not, then that would seem to 
reinforce the notion that there is something going on locally on your system.

Also, unless I missed it, you did not indicate which version of R-Devel you are 
running or where you obtained it. Did you get it from:

  https://cran.r-project.org/bin/windows/base/rdevel.html

?

Regards,

Marc


> On Nov 29, 2017, at 8:22 AM, Rampal S. Etienne  
> wrote:
> 
> Dear Marc, Martin, Dason,
> 
> I agree that the status number is not very informative, but neither is:
> "Package does not build". The point is that I have no clue what is going
> on, and was just hoping that someone might have seen the exit status
> number before.
> 
> I have done a clean install as suggested but still it won't work with
> R-devel, but it does with R-3.4.2.
> 
> I don't see how my setup is special in any way. It never caused me any
> problems until installing the latest R-devel. What are the changes in
> the latest R-devel that affect the building of packages?
> 
> Cheers, Rampal
> 
> 
> 
> On 29-11-2017 11:16, Martin Maechler wrote:
>>> Rampal S Etienne 
>>>on Wed, 29 Nov 2017 09:19:29 +0100 writes:
>>> Dear Dason,
>>> I don't get this error, but it crashes anyway. 
>> 
>> and you don't show what "crashes" means here.
>> (and yes, Dason is right: The RStudio status number in the
>> 'Subject' is not really useful)
>> 
>>> I've that if I use the
>>> stable version of R (3.4.2) I do NOT get the error anymore, so I assume
>>> there is something wrong with the current R-devel.
>> 
>>> Regards,
>>> Rampal Etienne
>> 
>> OTOH, the CRAN checks of your package run without any problem
>> with all 5 versions of R-devel there :
>> 
>>  https://cran.r-project.org/web/checks/check_results_SADISA.html
>> 
>> so it may rather be something specific to your setup ??
>> 
>> Martin Maechler
>> 
>> 
>>> On 29-11-2017 0:36, Dason Kurkiewicz wrote:
 Do you get the same error if you try to build on the command line
 outside of RStudio?
 
 On Nov 28, 2017 3:51 PM, "Rampal Etienne" >>> > wrote:
 
 Dear all,
 
 I updated RStudio, Rtools and R-devel, and then I tried to build a
 package in RStudio that I had been able to build before without
 any problems. But now I got the following error:
 
 Updating SADISA documentatiob
 Loading SADISA
 Exited with status -1073741819.
 
 That's all. What is this exit status? I can still build other
 packages, so it does not happen all the time. I can use "Load all"
 and all functions sseem to work fine.
 
 Any suggestions?
 
 Kind regards, Rampal Etienne

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

[R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Marc Schwartz]

Hi All,

I recently became aware of what appears to be some kind of incompatibility 
between the Perl distribution that is included in the RTools 4.4 distribution 
and my WriteXLS package on CRAN, running R 4.4.1. As far as I can tell, since 
the vast majority of the users of my package, which requires Perl, are running 
standard Perl installations, that is native OS, Strawberry Perl or Active State 
Perl, this appears to be something of a unique issue. 

It is not clear to me what the root cause of the problem is, and whether it is 
the RTools Perl binary itself and/or any of the other related components that 
are included in RTools, if this is specific to RTools, or may be an upstream 
issue from MSYS2. Thus, before I think about going down the rabbit hole, I am 
wondering if anyone has any intuitive guidance on this issue.

I was also a bit confused by this, as my aging memory recalled that the old 
Vanilla Perl had been removed from RTools many years ago circa R 2.x.y, so 
presume that there was motivation to reintroduce Perl in recent versions of 
RTools.

I have been able to largely replicate the problem on my MacBook Pro, running a 
Windows 11 VM under Parallels on macOS 14.5, and confirmed a workaround using a 
current Strawberry Perl installation for Windows on the same system. 

The initial report was from a user running Windows 10 on a native Intel based 
PC, with R 4.4.1 and RTools 4.4 installed, and they reported the following 
error:

> WriteXLS::WriteXLS(iris, "test.xlsx", verbose=T)
Creating Temporary Directory for CSV Files:  
C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS 

Creating CSV File: 1.csv
Creating SheetNames.txt

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LANG = "en"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
. No such file or 
directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
Creating Excel File: C:\Users\Kleinbub\Documents\test.xlsx

Reading: C:\Users\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv
The Perl script 'WriteXLSX.pl' failed to run successfully.
Cleaning Up Temporary Files and Directory


The basic workflow steps are that my R code wrapper function writes a CSV file 
containing the 'iris' dataframe into a temporary directory, my Perl script then 
reads in and parses that CSV file. and creates the Excel file using the 
relevant Perl packages included. The 'verbose = TRUE' setting outputs some 
additional diagnostic messages.

Note above that there are some warnings regarding locale settings from Perl, 
which I could not replicate on my Windows VM, albeit I can replicate the key 
error and failure of the Perl script as indicated.

If I run the same test code on my Windows 11 VM system, I get the following, 
including the initial testing function, which points to Perl in RTools:

> testPerl()
A system perl installation found in C:\rtools44\usr\bin\perl.exe

The perl modules included with WriteXLS are located in 
C:/Users/marcschwartz/AppData/Local/R/win-library/4.4/WriteXLS/Perl

All required Perl modules were found.

> WriteXLS(iris, "test.xlsx")
ERROR: cannot open 
C:\Users\MARCSC~1\AppData\Local\Temp\RtmpmKwGGX/WriteXLS/1.csv
. No such file or directory
The Perl script 'WriteXLSX.pl' failed to run successfully.


Note that I do not get the locale warnings, and this does not appear to be a 
permissions issue, but the Perl script still fails after indicating the 
inability to find the CSV file in the temporary directory.

With a Strawberry Perl installation in place, and explicitly pointing 
WriteXLS() to that Perl binary, I get a successful creation of the Excel file:

> WriteXLS(iris, "test.xlsx", perl = "C:\\Strawberry\\perl\\bin\\perl")
> 
> WriteXLS(iris, "test.xlsx", perl = "C:/Strawberry/perl/bin/perl")
>


Thus, I am confused as to the source of the incompatibility, and may be missing 
some nuances regarding the Perl binary and related components in RTools.

Any thoughts/pointers would be appreciated. 

Thank you,

Marc Schwartz

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

Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN Package

[Marc Schwartz]

Hi Ivan,

Thanks kindly for your expedient reply and pointer to the LF/CRLF issue. Not 
sure that I would have found that issue so quickly, so was hoping for some 
intuition here, as you have provided.

Thanks!

Regards,

Marc


-Original Message-
From: Ivan Krylov mailto:ikry...@disroot.org>>
Date: Friday, July 19, 2024 at 11:18 AM
To: Marc Schwartz mailto:marc_schwa...@me.com>>
Cc: mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] RTools 4.x Perl Incompatibility with WriteXLS CRAN 
Package


Dear Marc Schwartz,


В Fri, 19 Jul 2024 10:49:31 -0400
Marc Schwartz mailto:marc_schwa...@me.com>> пишет:


> . No such file or
> directory\Kleinbub\AppData\Local\Temp\RtmpuO4911/WriteXLS/1.csv


This looks like an extra carriage return has messed up the output.
By debugging WriteXLS and running the command line manually with perl
-d, I can confirm this:


main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:135):
135: my @FileNames = "";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:136):
136: open (DFHANDLE, $Encode, "$CSVPath/FileNames.txt") || die
"ERROR: cannot open $CSVPath/FileNames.txt. $!\n";
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:137):
137: @FileNames = ;
DB<3>
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:138):
138: close DFHANDLE;
DB<3> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM\cJ"
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:141):
141: chomp(@FileNames);
DB<4> n
main::(C:/Users/redacted/AppData/Local/R/win-library/4.5/WriteXLS/Perl/WriteXLS.pl:302):
302: foreach my $FileName (@FileNames) {
DB<4> x \@FileNames
0 ARRAY(0xa005e3c08)
0 "C:\\rtools44\\tmp\\Rtmpg9BxFb/WriteXLS/1.csv\cM"


Since the R code always uses a text-mode connection with WriteLines,
it always results in CR-LF line endings on Windows. The difference must
be in the default PerlIO layers applied by Strawberry Perl by default.
MSYS is based on Cygwin, which does its best to pretend to be an
Unix-like environment, so it's reasonable for an MSYS build of Perl to
default to LF line endings. But that means special-casing the MSYS
build of Perl:


DB<5> x $Encode
0 '<:encoding(utf8)'
DB<6> x $^O
0 'msys'


...and adding $Encode .= ":crlf" if $^O eq 'msys'; somewhere.


-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Internet security software?

[Marc Schwartz]

> On Feb 24, 2020, at 4:49 PM, Spencer Graves 
>  wrote:
> 
> Hello, All:
> 
> 
>   What antivirus / internet security software do you use and recommend?
> 
> 
>   I've used Bitdefender for years.  However, I've been encountering an 
> increasing number of problems with software I've used for years.  Some of my 
> problems disappear when I turn off parts of Bitdefender.  However, I've been 
> unable to use RStudio on my Windows 7 computer since early last November.  
> Also, when I turn off certain features of Bitdefender, "R CMD build sos" 
> (with sos cloned from "https://github.com/sbgraves237/sos";) completes in a 
> few minutes.  With Bitdefender configured normally, "R CMD build sos" stops 
> without warning on "* creating vignettes".  I've left it for days like that 
> without it moving beyond that point.  No error message but also no progress.
> 
> 
>   Rather than doing a web search for alternative internet security 
> software, I thought I'd ask you all:  If some of you have had similar 
> problems with other antivirus / internet security software, I think I'd be 
> more likely to hear it from you than from a web search.  Some of my problems 
> may not be due to Bitdefender, but I know that some are, and Bitdefender tech 
> support answers the phone but fails to fix these problems.
> 
> 
>   Thanks,
>   Spencer Graves


Spencer,

FWIW, I also use BitDefender on macOS, and have for a number of years, even 
though macOS has built-in features. I selected BitDefender because of minimal 
system overhead and high detection ratings.

I also use Malwarebytes for periodic scans as a second tier.

The key and really only issue that I have had with BitDefender is the Safe 
Files feature, which has a tendency to lock down folder trees, and which can be 
very nuanced in terms of the day to day operational impact. 

Under the premise of "The missing shall not be compromised due to security", a 
paradigm that I learned back in the 90s in an apropos setting, I long ago 
disabled the Safe Files feature in BitDefender, and have not had an issue since.

I am going to presume that the behavior on Windows is going to be similar. So 
if disabling the Safe Files feature, presuming that you have it enabled, is an 
option that you can consider, I would try that approach initially.

Regards,

Marc Schwartz

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

[R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi All,

Just thought that I would check to see if there are any known issues/delays for 
CRAN in creating R release and devel binaries for Windows for updated packages.

It has been four days since I submitted an update and the other binaries were 
created within a couple of days. The two Windows binaries are the only 
outstanding updates pending.

Thanks!

Marc Schwartz

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
wrote:
> 
> Hi,
> 
> I am developing a package and getting a NOTE from R CMD check about licenses 
> and ultimate dependencies on a restrictive license, which I can't figure out 
> how to fix.
> 
> My package imports flowCore, which has an Artistic-2.0 license.
> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
> Cancer Center that prohibits commercial use.
> 
> I tried using the same license as flowCore, but still get the NOTE. Does 
> anyone know which licenses can be used to be compatible with the Fred Hutch 
> license? Or can I just do what flowCore apparently does and ignore the NOTE?
> 
> Thanks,
>   Kevin


Hi Kevin,

I have not looked at BioC's licensing requirements, but presumably, they are ok 
with the non-commercial use restrictions placed on users of cytolib, thus also 
on flowCore.

If you want your package to be on CRAN, those restrictions on users are not 
allowed by CRAN's policy:

https://cran.r-project.org/web/packages/policies.html

"Such packages are not permitted to require (e.g., by specifying in ‘Depends’, 
‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package or external 
software which restricts users or usage."


Thus, you would seem to need to make a decision on hosting your package on 
CRAN, but without the need to import from flowCore/cytolib, or consider hosting 
your package on BioC, with the attendant restrictions on commercial use.

Regards,

Marc Schwartz

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
> 
> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
> wrote:
>> 
>> Hi,
>> 
>> I am developing a package and getting a NOTE from R CMD check about licenses 
>> and ultimate dependencies on a restrictive license, which I can't figure out 
>> how to fix.
>> 
>> My package imports flowCore, which has an Artistic-2.0 license.
>> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
>> Cancer Center that prohibits commercial use.
>> 
>> I tried using the same license as flowCore, but still get the NOTE. Does 
>> anyone know which licenses can be used to be compatible with the Fred Hutch 
>> license? Or can I just do what flowCore apparently does and ignore the NOTE?
>> 
>> Thanks,
>>  Kevin
> 
> 
> Hi Kevin,
> 
> I have not looked at BioC's licensing requirements, but presumably, they are 
> ok with the non-commercial use restrictions placed on users of cytolib, thus 
> also on flowCore.
> 
> If you want your package to be on CRAN, those restrictions on users are not 
> allowed by CRAN's policy:
> 
> https://cran.r-project.org/web/packages/policies.html
> 
> "Such packages are not permitted to require (e.g., by specifying in 
> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package 
> or external software which restricts users or usage."
> 
> 
> Thus, you would seem to need to make a decision on hosting your package on 
> CRAN, but without the need to import from flowCore/cytolib, or consider 
> hosting your package on BioC, with the attendant restrictions on commercial 
> use.
> 
> Regards,
> 
> Marc Schwartz


Well

Now that I look at:

  https://svn.r-project.org/R/trunk/share/licenses/license.db

there are a few licenses listed there that do place restrictions on commercial 
use.

These include some Creative Commons Non-Commercial use variants and the ACM 
license.

Is the license DB file out of date, or is there an apparent conflict with the 
CRAN policy that I quoted above?

Anyone with an ability to comment?

Regards,

Marc

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
>>> 
>>> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes  
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I am developing a package and getting a NOTE from R CMD check about 
>>>> licenses and ultimate dependencies on a restrictive license, which I can't 
>>>> figure out how to fix.
>>>> 
>>>> My package imports flowCore, which has an Artistic-2.0 license.
>>>> But flowCore imports cytolib, which has a license from the Fred Hutchinson 
>>>> Cancer Center that prohibits commercial use.
>>>> 
>>>> I tried using the same license as flowCore, but still get the NOTE. Does 
>>>> anyone know which licenses can be used to be compatible with the Fred 
>>>> Hutch license? Or can I just do what flowCore apparently does and ignore 
>>>> the NOTE?
>>>> 
>>>> Thanks,
>>>>  Kevin
>>> 
>>> 
>>> Hi Kevin,
>>> 
>>> I have not looked at BioC's licensing requirements, but presumably, they 
>>> are ok with the non-commercial use restrictions placed on users of cytolib, 
>>> thus also on flowCore.
>>> 
>>> If you want your package to be on CRAN, those restrictions on users are not 
>>> allowed by CRAN's policy:
>>> 
>>> https://cran.r-project.org/web/packages/policies.html
>>> 
>>> "Such packages are not permitted to require (e.g., by specifying in 
>>> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a 
>>> package or external software which restricts users or usage."
>>> 
>>> 
>>> Thus, you would seem to need to make a decision on hosting your package on 
>>> CRAN, but without the need to import from flowCore/cytolib, or consider 
>>> hosting your package on BioC, with the attendant restrictions on commercial 
>>> use.
>>> 
>>> Regards,
>>> 
>>> Marc Schwartz
>> Well
>> Now that I look at:
>>   https://svn.r-project.org/R/trunk/share/licenses/license.db
>> there are a few licenses listed there that do place restrictions on 
>> commercial use.
>> These include some Creative Commons Non-Commercial use variants and the ACM 
>> license.
>> Is the license DB file out of date, or is there an apparent conflict with 
>> the CRAN policy that I quoted above?
>> Anyone with an ability to comment?
> 
> Presumably CRAN would not accept the non-FOSS licenses that are listed in 
> license.db, but R could still do computations on them, as described in 
> ?library in the "Licenses" section.
> 
> Duncan Murdoch


Duncan,

That is a reasonable distinction.

However, upon searching CRAN with available.packages(), I came up with a list 
of packages that do include Non-Commercial restrictions, including CC BY-NC* 
and ACM licenses. There may be others that I missed visually scanning the 
output.

There also appear to be some conflicts/inconsistencies with the 
'License_restricts_use' field entry and the 'License' field in some cases, 
where, for example, most that have "CC BY-NC-SA 4.0" as the license, have "NA" 
as the entry for restricted use, rather than "yes".

I am not going to list them here, as I don't want to pick on any particular 
package, but this does seem to point to an inconsistency between packages that 
are hosted on CRAN and the articulated policy...

Regards,

Marc

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

On Oct 22, 2020, at 3:47 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  
>>> wrote:
>>> 
>>> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
>>>>> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
>>>>> 
>>>>> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes 
>>>>>  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I am developing a package and getting a NOTE from R CMD check about 
>>>>>> licenses and ultimate dependencies on a restrictive license, which I 
>>>>>> can't figure out how to fix.
>>>>>> 
>>>>>> My package imports flowCore, which has an Artistic-2.0 license.
>>>>>> But flowCore imports cytolib, which has a license from the Fred 
>>>>>> Hutchinson Cancer Center that prohibits commercial use.
>>>>>> 
>>>>>> I tried using the same license as flowCore, but still get the NOTE. Does 
>>>>>> anyone know which licenses can be used to be compatible with the Fred 
>>>>>> Hutch license? Or can I just do what flowCore apparently does and ignore 
>>>>>> the NOTE?
>>>>>> 
>>>>>> Thanks,
>>>>>>  Kevin
>>>>> 
>>>>> 
>>>>> Hi Kevin,
>>>>> 
>>>>> I have not looked at BioC's licensing requirements, but presumably, they 
>>>>> are ok with the non-commercial use restrictions placed on users of 
>>>>> cytolib, thus also on flowCore.
>>>>> 
>>>>> If you want your package to be on CRAN, those restrictions on users are 
>>>>> not allowed by CRAN's policy:
>>>>> 
>>>>> https://cran.r-project.org/web/packages/policies.html
>>>>> 
>>>>> "Such packages are not permitted to require (e.g., by specifying in 
>>>>> ‘Depends’, ‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a 
>>>>> package or external software which restricts users or usage."
>>>>> 
>>>>> 
>>>>> Thus, you would seem to need to make a decision on hosting your package 
>>>>> on CRAN, but without the need to import from flowCore/cytolib, or 
>>>>> consider hosting your package on BioC, with the attendant restrictions on 
>>>>> commercial use.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Marc Schwartz
>>>> Well
>>>> Now that I look at:
>>>>   https://svn.r-project.org/R/trunk/share/licenses/license.db
>>>> there are a few licenses listed there that do place restrictions on 
>>>> commercial use.
>>>> These include some Creative Commons Non-Commercial use variants and the 
>>>> ACM license.
>>>> Is the license DB file out of date, or is there an apparent conflict with 
>>>> the CRAN policy that I quoted above?
>>>> Anyone with an ability to comment?
>>> 
>>> Presumably CRAN would not accept the non-FOSS licenses that are listed in 
>>> license.db, but R could still do computations on them, as described in 
>>> ?library in the "Licenses" section.
>>> 
>>> Duncan Murdoch
>> Duncan,
>> That is a reasonable distinction.
>> However, upon searching CRAN with available.packages(), I came up with a 
>> list of packages that do include Non-Commercial restrictions, including CC 
>> BY-NC* and ACM licenses. There may be others that I missed visually scanning 
>> the output.
>> There also appear to be some conflicts/inconsistencies with the 
>> 'License_restricts_use' field entry and the 'License' field in some cases, 
>> where, for example, most that have "CC BY-NC-SA 4.0" as the license, have 
>> "NA" as the entry for restricted use, rather than "yes".
>> I am not going to list them here, as I don't want to pick on any particular 
>> package, but this does seem to point to an inconsistency between packages 
>> that are hosted on CRAN and the articulated policy...
> 
> Perhaps those packages were accepted before this became a policy, and now 
> that others depend on them, it would be too disruptive to remove them, and 
> users are warned via the 'License_restricts_use' field entry. Why does it 
> sometimes contain errors?  That I don't know, other than blaming it on 
> Murphy's Law.
> 
> Duncan Murdoch


Hi Duncan,

That seems a reasonable scenario.

Right now, the interpretation, without further clarification from CRAN, would 
be, it is ok for a package to be on CRAN with license based usage restrictions 
included (e.g. for non-commercial use), but a package on CRAN, irrespective of 
it's own license, cannot "interact" with other packages that do have 
restrictions...which seems inconsistent.

Back to the original question by Kevin, this would now seem to be even more 
confusing...

Kevin, you may need to send an e-mail to cran-submissi...@r-project.org 
<mailto:cran-submissi...@r-project.org> on the issue with your package, to get 
clarification on the current policy and recommendations for resolution. You 
might even want to include this thread (but don't cc: this list), so that they 
are aware, if not already, of the issues raised here.

If you do, please post back with an update.

Regards,

Marc


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi All,

Just a quick note to indicate that one of the two Windows binaries for the 
package appeared overnight (EDT). Not sure if this experience is representative 
for others, or just a temporary bump in the road.

Regards,

Marc


> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
> 
> Hi All,
> 
> Just thought that I would check to see if there are any known issues/delays 
> for CRAN in creating R release and devel binaries for Windows for updated 
> packages.
> 
> It has been four days since I submitted an update and the other binaries were 
> created within a couple of days. The two Windows binaries are the only 
> outstanding updates pending.
> 
> Thanks!
> 
> Marc Schwartz

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

Re: [R-pkg-devel] Delays in CRAN Windows Binaries?

[Marc Schwartz]

Hi Uwe,

Thanks for your reply.

I appreciate all of the efforts by the CRAN team here.

Regards,

Marc


> On Oct 23, 2020, at 8:47 AM, Uwe Ligges  
> wrote:
> 
> Windows binaries may be delayed these days, but they are generated in a bunch 
> R-flavour-wise. They typical delay after a source package publication should 
> be less then 72 hours ideally.
> 
> Best,
> Uwe
> 
> On 23.10.2020 14:05, Marc Schwartz wrote:
>> Hi All,
>> Just a quick note to indicate that one of the two Windows binaries for the 
>> package appeared overnight (EDT). Not sure if this experience is 
>> representative for others, or just a temporary bump in the road.
>> Regards,
>> Marc
>>> On Oct 21, 2020, at 2:08 PM, Marc Schwartz  wrote:
>>> 
>>> Hi All,
>>> 
>>> Just thought that I would check to see if there are any known issues/delays 
>>> for CRAN in creating R release and devel binaries for Windows for updated 
>>> packages.
>>> 
>>> It has been four days since I submitted an update and the other binaries 
>>> were created within a couple of days. The two Windows binaries are the only 
>>> outstanding updates pending.
>>> 
>>> Thanks!
>>> 
>>> Marc Schwartz
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

> On Oct 23, 2020, at 8:25 AM, Ege Rubak  wrote:
> 
> Hi all,
> 
> My two cents are below Marc's summary here:
> 
> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>> Right now, the interpretation, without further clarification from
>> CRAN, would be, it is ok for a package to be on CRAN with license
>> based usage restrictions included (e.g. for non-commercial use), but
>> a package on CRAN, irrespective of it's own license, cannot
>> "interact" with other packages that do have restrictions...which
>> seems inconsistent.
> 
> It depends a bit what is meant by "interact". Years ago `spatstat` used
> `gpclib` with a non-commercial license to do polygonal operations. The
> solution was to list `gpclib` in `Suggests` and require the user to
> make an active choice to use this piece of software with a warning
> about non-commercial use. I find this to be an OK solution in lack of
> completely free alternatives. These days `gpclib` is still on CRAN and
> only has reverse `Suggests` and `Enhances`, so that seems fairly
> consistent.
> 
> In the long run this was unsatisfatory and our specific problem was
> solved by Adrian Baddeley by making the `polyclip` package.
> 
> Kind regards,
> Ege


Hi Ege,

The use of "Suggests" may be the relevant difference here. My use of the word 
"interact" was focused on the text in the CRAN policy that I quoted in my 
initial reply:

"Such packages are not permitted to require (e.g., by specifying in ‘Depends’, 
‘Imports’ or ‘LinkingTo’ fields) directly or indirectly a package or external 
software which restricts users or usage."

As Duncan noted in his reply, there may be time based differences that are 
relevant here, if the CRAN policy had changed at some point, and there was, in 
effect, a grand-fathering of older packages that perhaps would not be accepted 
today under the current policy.

Regards,

Marc

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

Re: [R-pkg-devel] Licenses

[Marc Schwartz]

Hi Uwe,

Thanks for taking the time to reply.

Would you be willing to clarify/confirm the current situation regarding the 
hosting of non-FOSS packages on CRAN, such as those with ACM or Creative 
Commons license variants that have non-commercial use restrictions? 

These are presently included in the license.db file.

Are these on CRAN now because they are acceptable under the current policy, or 
are they on CRAN now, as Duncan posited, because they were acceptable under 
older policies and it would be disruptive to remove them now?

Thanks,

Marc


> On Oct 23, 2020, at 8:57 AM, Uwe Ligges  
> wrote:
> 
> I do not want to make many general comments about licenses in public, as this 
> is a very difficult matter and I am not a lawyer.
> 
> But let me cite from the CRAN policies:
> 
> "Packages with licenses not listed at 
> https://svn.r-project.org/R/trunk/share/licenses/license.db will generally 
> not be accepted. "
> 
> Further, I see in the discussions that you talked about depending on a 
> software with a non-FOSS license. The CRAN team's point of view, for short, 
> is:
> A package with a FOSS license cannot strictly depend on a package/software 
> that is non-FOSS. Obviously, the FOSS package cannot be used under its own 
> license conditions in that case.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> On 23.10.2020 14:25, Ege Rubak wrote:
>> Hi all,
>> My two cents are below Marc's summary here:
>> On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
>>> Right now, the interpretation, without further clarification from
>>> CRAN, would be, it is ok for a package to be on CRAN with license
>>> based usage restrictions included (e.g. for non-commercial use), but
>>> a package on CRAN, irrespective of it's own license, cannot
>>> "interact" with other packages that do have restrictions...which
>>> seems inconsistent.
>> It depends a bit what is meant by "interact". Years ago `spatstat` used
>> `gpclib` with a non-commercial license to do polygonal operations. The
>> solution was to list `gpclib` in `Suggests` and require the user to
>> make an active choice to use this piece of software with a warning
>> about non-commercial use. I find this to be an OK solution in lack of
>> completely free alternatives. These days `gpclib` is still on CRAN and
>> only has reverse `Suggests` and `Enhances`, so that seems fairly
>> consistent.
>> In the long run this was unsatisfatory and our specific problem was
>> solved by Adrian Baddeley by making the `polyclip` package.
>> Kind regards,
>> Ege
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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