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

[Avraham Adler]

On the other hand, MIT does not restrict what you do with your own
contributions, just the included code. GPL restricts rights on
redistributing your own work if a component is GPL as well.

Avi

On Thu, Jun 3, 2021 at 6:51 AM Berwin A Turlach
 wrote:
>
> G'day Jeff,
>
> On Wed, 02 Jun 2021 11:34:21 -0700
> Jeff Newmiller  wrote:
>
> Not that I want to get involved in old discussions :), but...
>
> > MIT is more permissive than GPL2,
>
> ... this statement depends on how one defines "permissive".
>
> MIT requires that you fulfil: "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software." (https://opensource.org/licenses/MIT)
>
> Whereas GPL 2 merely requires that you "[...] conspicuously and
> appropriately publish on each copy an appropriate copyright notice and
> disclaimer of warranty [...]".
>
> Thus, arguably, GPL 2 is more permissive.
>
> >  so there is a collision there.
>
> Well, luckily the FSF does not think that the MIT license is
> incompatible with the GPL license, though it finds the term "MIT
> license" misleading and discourages its use, see
> https://www.gnu.org/licenses/license-list.html
>
> Cheers,
>
> Berwin
>
> __
> 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] Question about preventing CRAN package archival

[Jeff Newmiller]

... but you went ahead and did it anyway.

MIT software can be absorbed by GPL2 software, but not vice versa since MIT 
allows the code to be further incorporated into and distributed as non-free 
software, a permission not granted by GPL2.

I am opposed to people snarfing GPL2 code up for their non-free software 
tarpits, and transferring GPL2 code to MIT without the GPL2 author explicitly 
re-releasing as MIT would allow that.

On June 2, 2021 11:51:01 PM PDT, Berwin A Turlach  
wrote:
>G'day Jeff,
>
>On Wed, 02 Jun 2021 11:34:21 -0700
>Jeff Newmiller  wrote:
>
>Not that I want to get involved in old discussions :), but...
>
>> MIT is more permissive than GPL2,
>
>... this statement depends on how one defines "permissive".
>
>MIT requires that you fulfil: "The above copyright notice and this
>permission notice shall be included in all copies or substantial
>portions of the Software." (https://opensource.org/licenses/MIT)
>
>Whereas GPL 2 merely requires that you "[...] conspicuously and
>appropriately publish on each copy an appropriate copyright notice and
>disclaimer of warranty [...]".
>
>Thus, arguably, GPL 2 is more permissive.
>
>>  so there is a collision there. 
>
>Well, luckily the FSF does not think that the MIT license is
>incompatible with the GPL license, though it finds the term "MIT
>license" misleading and discourages its use, see
>https://www.gnu.org/licenses/license-list.html
>
>Cheers,
>
>   Berwin

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

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

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

[Martin Maechler]

> Avraham Adler 
> on Wed, 2 Jun 2021 15:28:25 -0400 writes:

> Exactly. Is square is just brow=ncol, is positive definite can be
> implemented as a check that all eigenvalues > 0, which can be done with
> base, and is.symmetric can be simply brute forced in a loop comparing i,j
> with j,i.

> The fewer dependencies a package has, the more robust it is. It’s a fine
> balance between not reinventing the wheel and ceding too much stability to
> other packages.

> Thanks,
> Avi

Indeed.  Further,

-  isSymmetric()  has been part of base for a long time
   so the definition of an alternative in matrixcalc  had been @_*#^$%
   It's also supported by methods in the Matrix package
   e.g. for sparse matrices etc  so definitely something you
   "should" use instead.

-  is.square() is trivial and I think an explicit check such as
   { d <- dim(x);  d[1] == d[2] }
   is often more sensical, notably as in many of your functions
   you'd need either nrow(.) or ncol(.) of your matrix anyway.

- A remark on Positive Definiteness (or also, often what you really want,
   "Positive Semi-definitness", allowing 0 eigen values):
  The  Matrix  package has an (S4) class  "dpoMatrix"
  of dense positive-definite (actually 'positive semi-definite') matrices.
  In its validation method (yes, formal classes have validation!), we
  use a cheap test instead of an expensive test with eigenvalues
  (which is "too expensive": there are faster ones at least in theory,
   e.g., trying an  LDL' Cholesky decomposition and returning as soon as
   a non-positive / negative entry in D would appear).

  The really cheap "pre-test" you may want to use  before or instead
  of doing one of the more expensive ones is simply checking the diagonal:

   if(any(diag()) <  0) "not positive-semidefinite"
   if(any(diag()) <= 0) "not positive-definite"

Martin Maechler
(Maintainer of 'Matrix').


> On Wed, Jun 2, 2021 at 3:15 PM 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  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  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
>> > > > ,
>> > > > is.symmetric.matrix
>> > > > , and
>> > > > is.positive.definite
>> > > > ) and
>> > > there
>> > > > is

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

[Ben Staton]

Hi Everyone,

Thank you all for your input and thoughts on this topic. I've learned much
from this thread. I have arrived at a solution so we can now consider this
topic closed.

I ended up removing the dependency on 'matrixcalc' by (a) replacing
matrixcalc::is.square.matrix() with a basic check for nrow(x) == ncol(x),
(b) replacing matrixcalc::is.symmetric.matrix() with base::isSymmetric(),
and (c) replacing matrixcalc::is.positive.definite() with some basic custom
code that checks eigenvalues for >= 0 (thus checking for semi-positive
definiteness), as pointed out by Martin above. I have submitted the updated
version to CRAN and it is now available there.

Side note -- someone else ended up taking over as maintainer of the
orphaned 'matrixcalc' package and has had it successfully accepted to CRAN,
so it will continue to be available going forward. I'm still happy with the
solution that I used, as fewer dependencies the better -- a point also
raised earlier in this thread.

Thank you all,
Ben

On Thu, Jun 3, 2021 at 12:55 AM Martin Maechler 
wrote:

> > Avraham Adler
> > on Wed, 2 Jun 2021 15:28:25 -0400 writes:
>
> > Exactly. Is square is just brow=ncol, is positive definite can be
> > implemented as a check that all eigenvalues > 0, which can be done
> with
> > base, and is.symmetric can be simply brute forced in a loop
> comparing i,j
> > with j,i.
>
> > The fewer dependencies a package has, the more robust it is. It’s a
> fine
> > balance between not reinventing the wheel and ceding too much
> stability to
> > other packages.
>
> > Thanks,
> > Avi
>
> Indeed.  Further,
>
> -  isSymmetric()  has been part of base for a long time
>so the definition of an alternative in matrixcalc  had been @_*#^$%
>It's also supported by methods in the Matrix package
>e.g. for sparse matrices etc  so definitely something you
>"should" use instead.
>
> -  is.square() is trivial and I think an explicit check such as
>{ d <- dim(x);  d[1] == d[2] }
>is often more sensical, notably as in many of your functions
>you'd need either nrow(.) or ncol(.) of your matrix anyway.
>
> - A remark on Positive Definiteness (or also, often what you really want,
>"Positive Semi-definitness", allowing 0 eigen values):
>   The  Matrix  package has an (S4) class  "dpoMatrix"
>   of dense positive-definite (actually 'positive semi-definite') matrices.
>   In its validation method (yes, formal classes have validation!), we
>   use a cheap test instead of an expensive test with eigenvalues
>   (which is "too expensive": there are faster ones at least in theory,
>e.g., trying an  LDL' Cholesky decomposition and returning as soon as
>a non-positive / negative entry in D would appear).
>
>   The really cheap "pre-test" you may want to use  before or instead
>   of doing one of the more expensive ones is simply checking the diagonal:
>
>if(any(diag()) <  0) "not positive-semidefinite"
>if(any(diag()) <= 0) "not positive-definite"
>
> Martin Maechler
> (Maintainer of 'Matrix').
>
>
> > On Wed, Jun 2, 2021 at 3:15 PM John Harrold <
> john.m.harr...@gmail.com>
> > 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 
> 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 
> 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 Bo

[R-pkg-devel] [Error] data length differs from size of matrix

[Tiago Olivoto]

Dear all,
I have received an email from the CRAN team to fix a problem with my R
package metan > to safely retain it on CRAN.

The error is given at 
and seems to be related to data different from size of matrix.

The question is that and I cannot reproduce the error locally and thus not
able to fix anything. By googling the error I've seen similar issues with a
lot of other packages. Could be this be a temporary issue?

Thanks in advance!
Tiago

[[alternative HTML version deleted]]

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