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 <stato...@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 <bbol...@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 <profjcn...@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@r-project.org mailing list >>>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >>>>> >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ______________________________________________ >>>> 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 >>> >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> 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
