[Rd] forking a CRAN project
There is a CRAN package licensed just as GPL, say, XX, I want to use in a book. But I've needed to modify the package to make it do what I need for expository purposes. The package author(s) are amenable to my modifications, but probably unlikely to incorporate them into the CRAN version any time soon. Am I allowed, under GPL, to create a new version of the package, say XX2, in a public repository such as R-Forge or github? I would, of course, maintain their authorship, though perhaps take over the maintainer role. For my purposes in the book, I don't necessarily need to release my version to CRAN; just a public repo a reader could download from. -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Constructor/extractor.
On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner r.tur...@auckland.ac.nz wrote: Questions: == (2) Even if there are no such functions, is there anything intrinsically *wrong* with having a function possessing this somewhat schizophrenic nature? Is it likely to cause confusion, induce syntactical mistakes, create errors, or produce wrong results? Any thoughts, comments, insights or suggestions gratefully received. I don't see why you can't conceptually think of w = owin(some_ppp_object) as an owin Constructor rather than an Accessor. Its constructing (and returning) an owin from an object, it just happens to be as simple as getting a component from that object. The raster package has the 'extent' function - you can create an extent with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or set the extent of a raster with extent(r1) - extent(r2), so I don't see any problem with: w1 = owin(poly=...) # construct polygon owin ppp1 = ppp(x,y,window=w1) ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object owin(ppp1) = owin(ppp2) # give ppp1 the owin of ppp2 That all reads pretty nicely. As long as owin(...) returns an observation window and owin-(...) assigns an observation window to an object that can validly have one, I don't think you can go wrong. I've probably already tried to do owin(ppp1)=... a few times... Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] forking a CRAN project
As usual: For legal advice, get a lawyer... However, yes, the GPL quite expressedly allows licencees to distribute modified versions, provided that the modified source code is made available and is redistributable under the GPL. It's common courtesy and possibly also required by law (the GPL itself doesn't say anything about it) to ensure that the original statements of authorship and copyright are retained. One thing to be slightly cautious about is to avoid inadvertent copyright transfer to your publisher of things that are also in the package. The back pages of ISwR (the book) has copies of the help pages for ISwR (the package), but Reproduced with permission so that Springer doesn't have the copyright for that part of the book. Not that they are likely to care, but better safe than sorry. -Peter D On 04 Mar 2014, at 16:50 , Michael Friendly frien...@yorku.ca wrote: There is a CRAN package licensed just as GPL, say, XX, I want to use in a book. But I've needed to modify the package to make it do what I need for expository purposes. The package author(s) are amenable to my modifications, but probably unlikely to incorporate them into the CRAN version any time soon. Am I allowed, under GPL, to create a new version of the package, say XX2, in a public repository such as R-Forge or github? I would, of course, maintain their authorship, though perhaps take over the maintainer role. For my purposes in the book, I don't necessarily need to release my version to CRAN; just a public repo a reader could download from. -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [PATCH] suggestions for R-lang manual
On Mon, Mar 3, 2014 at 7:48 AM, Martin Maechler maech...@stat.math.ethz.ch wrote: Scott Kostyshak skost...@princeton.edu on Thu, 27 Feb 2014 16:43:02 -0500 writes: On Thu, Nov 21, 2013 at 1:17 AM, Scott Kostyshak skost...@princeton.edu wrote: Attached is a patch with suggestions for the R-lang manual at r64277. Below are a few comments (some are implemented in the patch): In the section Objects, there is a table introduced by The following table describes the possible values returned by typeof. One of the results is any. Can any be returned by typeof() ? ANYSXP is a valid internal type on the C level, and src/main/util.c will make typeof(ob) return any if you can get your hands at an R level object of that type. I'd guess you can only get it currently by using .Call() and using your own C code, .. but at least that way it must be possible. Interesting to know. Regarding the Recycling rules section, -One exception is that when adding vectors to matrices, a warning is not -given if the lengths are incompatible. -@c Is that a bug? - was this a bug that was fixed? I did not investigate in details, but yes, I vaguely remember we had fixed that. So indeed, it's fine you omitted the para in your patch. I see the following behavior: myvec - 1:3 mymat - matrix(1:12, ncol=2) myvec - 1:5 myvec + mymat [,1] [,2] [1,]29 [2,]4 11 [3,]6 13 [4,]8 15 [5,] 10 12 [6,]7 14 Warning message: In myvec + mymat : longer object length is not a multiple of shorter object length Regarding -The arguments in the call to the generic are rematched with the -arguments for the method using the standard argument matching mechanism. -The first argument, i.e.@: the object, will have been evaluated. - this information is duplicated. See a few paragraphs up When the method is invoked it is called... Scott Thank you, Scott. Indeed, I've finally carefully looked at the patch, and applied it - for R-devel, to become R 3.1.0 in April. Thanks, Martin! Scott -- Scott Kostyshak Economics PhD Candidate Princeton University Martin -- Scott Kostyshak Economics PhD Candidate Princeton University The patch still applies cleanly (one offset) on r65090. Best, Scott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
