[R-pkg-devel] Question about preventing CRAN package archival

J C Nash pro|jcn@@h @end|ng |rom gm@||@com
Wed Jun 2 21:28:13 CEST 2021 

As noted by John Harrold and my previous posting, these are not monster codes.
I'd check what I needed and simply work out enough R to make my package work.
Most of these matrix functions are pretty much old-fashioned math translated
into R. I can't see that R will engage lawyers if the OP translates the variable
names to the ones he is using and more or less mimics the bits of code needed.

Cheers, JN


On 2021-06-02 3:15 p.m., John Harrold wrote:
> To add another option. In the past when this has happened to me I've found
> other packages that provide similar functionality.
> 
> I'm assuming that is.square just checks the number of columns == number of
> rows? And the others can probably be implemented pretty easily.
> 
> On Wed, Jun 2, 2021 at 10:41 AM Ben Staton <statonbe using gmail.com> wrote:
> 
>> My package uses the MIT license, so would that not meet the compatibility
>> requirements?
>>
>> I will attempt to reach out to the package author - thanks for your help!
>>
>> On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker <bbolker using gmail.com> wrote:
>>
>>>     That all sounds exactly right.
>>>    GPL >= 2 allows you to use the material without asking permission as
>>> long as your package is compatibly licensed (e.g. also GPL).
>>>    Under normal circumstances it would be polite to ask permission, but
>>> if the reason for doing this is that the maintainer is unreachable in
>>> the first place ...
>>>
>>>   If you want to try a little harder, it seems quite possible that you
>>> can reach the matrixcalc maintainer at the (personal) e-mail address
>>> shown in this page:
>>>
>>>
>> https://www.facebook.com/photo/?fbid=10208324530363130&set=ecnf.1000413042
>>>
>>>    (Possibly an identity confusion, but I rate that as unlikely based on
>>> other facebook snooping)
>>>
>>>    I don't think a short, polite e-mail request would be out of bounds,
>>> they can always ignore it or tell you to go away.
>>>
>>>    cheers
>>>     Ben Bolker
>>>
>>> On 6/2/21 1:15 PM, Ben Staton wrote:
>>>> Hello,
>>>>
>>>> Thank you for your detailed list of solutions.
>>>>
>>>> I was initially tempted to go with option 1 (move matrixcalc to
>> suggests
>>>> and check for its existence before using functions that rely on it),
>> but
>>> as
>>>> mentioned, this is not a long term fix.
>>>>
>>>> I unfortunately can't take on the responsibilities of option 2
>> (becoming
>>>> the package maintainer) -- there is much that this package does that I
>> do
>>>> not understand, and do not wish to feign authority!
>>>>
>>>> I plan to take option 3 (copy the needed functions into my package).
>>> There
>>>> are only three functions I need from matrixcalc, and all three are
>> fairly
>>>> simple (is.square.matrix
>>>> <https://rdrr.io/cran/matrixcalc/src/R/is.square.matrix.R>,
>>>> is.symmetric.matrix
>>>> <https://rdrr.io/cran/matrixcalc/src/R/is.symmetric.matrix.R>, and
>>>> is.positive.definite
>>>> <https://rdrr.io/cran/matrixcalc/src/R/is.positive.definite.R>) and
>>> there
>>>> is only one function in postpack that needs them. I plan to define them
>>>> within the postpack function. matrixcalc is licensed under GPL >= 2 and
>>>> based on my scan of the license text, this is allowed. Is that correct?
>>>>
>>>> Regarding option 4 (contacting the matrixcalc maintainer), the original
>>>> email from CRAN mentioned that they have attempted to contact the
>> package
>>>> author with no response.
>>>>
>>>> Thank you!
>>>>
>>>> On Wed, Jun 2, 2021 at 9:52 AM J C Nash <profjcnash using gmail.com> wrote:
>>>>
>>>>> I just downloaded the source matrixcalc package to see what it
>>> contained.
>>>>> The functions
>>>>> I looked at seem fairly straightforward and the OP could likely
>> develop
>>>>> equivalent features
>>>>> in his own code, possibly avoiding a function call. Avoiding the
>>> function
>>>>> call means NAMESPACE etc. are not involved, so fewer places for
>> getting
>>>>> into
>>>>> trouble, assuming the inline code works properly.
>>>>>
>>>>> JN
>>>>>
>>>>>
>>>>> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
>>>>>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I received an email notice from CRAN indicating that my R package
>>>>>>> ('postpack') will be archived soon if I do not take any action and I
>>>>> want
>>>>>>> to avoid that outcome. The issue is not caused by my package, but
>>>>> instead a
>>>>>>> package that my package depends on:
>>>>>>>
>>>>>>> "... package 'matrixcalc' is now scheduled for archival on
>> 2021-06-09,
>>>>>>> and archiving this will necessitate also archiving its strong
>> reverse
>>>>>>> dependencies."
>>>>>>>
>>>>>>> Evidently, xyz has been returning errors on new R builds prompting
>>> CRAN
>>>>> to
>>>>>>> list it as a package to be archived. My package, 'postpack' has
>>>>>>> 'matrixcalc' listed in the Imports field, which I assume is why I
>>>>> received
>>>>>>> this email.
>>>>>>>
>>>>>>> I want to keep 'postpack' active and don't want it to be archived. I
>>>>> still
>>>>>>> need package 'matrixcalc' for my package, but not for most
>> functions.
>>>>> Could
>>>>>>> I simply move package 'matrixcalc' to the Suggests list and submit
>> the
>>>>> new
>>>>>>> version to CRAN to remove the "Strong Reverse Dependency" issue that
>>>>>>> triggered this email to avoid CRAN from archiving my package?
>>>>>>
>>>>>> That's part of one solution, but not the best solution.
>>>>>>
>>>>>> If you move it to Suggests, you should make sure that your package
>>>>> checks for it before every use, and falls back to
>>>>>> some other calculation if it is not present.  Be aware that once it
>> is
>>>>> archived, almost none of your users will have it
>>>>>> available, so this is kind of like dropping the functions that it
>>>>> supports.
>>>>>>
>>>>>> Another solution which would be great for the community might be for
>>> you
>>>>> to offer to take over as maintainer of
>>>>>> matrixcalc.  Then you'd fix whatever problems it has, and you
>> wouldn't
>>>>> need to worry about it.  I haven't looked at the
>>>>>> issues so I don't know if this is feasible.
>>>>>>
>>>>>> A third choice would be for you to copy the functions you need from
>>>>> matrixcalc into your own package so you can drop the
>>>>>> dependency.  This is generally legal under the licenses that CRAN
>>>>> accepts, but you should check anyway.
>>>>>>
>>>>>> A fourth choice would be for you to contact the matrixcalc
>> maintainer,
>>>>> and help them to fix the issues so that
>>>>>> matrixcalc doesn't get archived.  They may or may not be willing to
>>> work
>>>>> with you.
>>>>>>
>>>>>> I'd say my third choice is the best choice in the short term, and 2nd
>>> or
>>>>> 4th would be good long term solutions.
>>>>>>
>>>>>> Duncan Murdoch
>>>>>>
>>>>>> ______________________________________________
>>>>>> R-package-devel using r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>>
>>>>
>>>>       [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>>
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
>

More information about the R-package-devel mailing list