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

Jeff Newmiller jdnewm|| @end|ng |rom dcn@d@v|@@c@@u@
Wed Jun 2 20:34:21 CEST 2021


MIT is more permissive than GPL2, so there is a collision there. But you may be able to work it out with the author?

On June 2, 2021 10:36:00 AM PDT, 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

-- 
Sent from my phone. Please excuse my brevity.



More information about the R-package-devel mailing list