Re: [Rd] Non-GPL packages for R
Comrades, When talk turns to the purity of the revolution, and purge of packages then the guillotine can't be far behind. We all remember Lenin berating the "renegade Kautsky" for his "pragmatism," and we know where that led... So let me put in a good word for pragmatism, and incidentally for saving one of my own packages, SparseM, and perhaps eventually my neck. Last week Kurt asked me to look into a SparseM licensing quirk based on an inquiry from the Fedora folks. SparseM is GPL except for one routine cholesky.f written at Oakridge Lab by E. Ng and B. Peyton. Our version of the code was redistributed in the package PCx which was copywrited by the U. of Chicago, who specified that commercial users should contact someone at Argonne National Lab. Since the beginning we have retained this language in the License file of SparseM, even though the code in question was not actually developed as a part of PCx. I contacted one of the original PCx developers who responded as follows: The routine you mention was distributed with PCx but not part of it as you see from the legalese and not covered by the PCx copyright. I tried to interest the authors of that code in legal issues in around 1997 but could not get them motivated (frankly I also can't get too interested). To which I heartily concurred. If someone who is worried about getting sued would like to dig into this can of worms, then fine. But life is too short for the rest of us. This is quite a murky business, we shouldn't create incentives to make it murkier by covering up relevant language on licensing. But surely we can also all agree that CRAN has been a fantastic success, and adding new constraints on its operation is ill-advised. Roger url:www.econ.uiuc.edu/~rogerRoger Koenker emailrkoen...@uiuc.eduDepartment of Economics vox: 217-333-4558University of Illinois fax: 217-244-6678Urbana, IL 61801 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- View this message in context: http://www.nabble.com/Non-GPL-packages-for-R-tp25387980p25406418.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
John, On Sep 11, 2009, at 9:07 , Prof. John C Nash wrote: The responses to my posting yesterday seem to indicate more consensus than I expected: 1) CRAN should be restricted to GPL-equivalent licensed packages I would definitely vote against that - I think this is not what the most people here agreed with (and the subject [non-GPL] and your wording [non-redistributable code] are two entirely different things). GPL is more restrictive than most open source licenses so with the above you'd throw out a lot of "real" open source packages (namely those with more permissive open source licenses). The point was open distribution as Peter pointed out so GPL-compatible licenses would be one possibility (although it also disallows some open source licenses). Cheers, Simon 2) r-forge could be left "buyer beware" using DESCRIPTION information 3) We may want a specific repository for restricted packages (RANC?) How to proceed? A short search on Rseek did not turn up a chain of command for CRAN. I'm prepared to help out with documentation etc. to move changes forward. They are not, in my opinion, likely to cause a lot of trouble for most users, and should simplify things over time. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran routine affected by unrelated R code
On Fri, Sep 11, 2009 at 5:00 PM, Duncan Murdoch wrote:
> On 9/11/2009 10:48 AM, Arne Henningsen wrote:
>>
>> Hi!
>>
>> When I run "R CMD check" on the current development version of my R
>> package "frontier" [1], there is no difference between the output of
>> the test scripts in the /tests/ folder and the saved output files
>> (.Rout.save). However, if I change an R file in the /R/ folder, some
>> calls to the Fortran code (called by ".Fortran()") return different
>> results, although the change of the R file is not related to this,
>> e.g. when I add the commands 'print("abc")' or 'newVariable <- 123' to
>> an R file that even does not call the Fortran code. However, adding
>> empty lines or comments does NOT change the values returned by the
>> Fortran code. Different modifications of the R files lead to different
>> results but the same modification always leads to the same results
>> (hence, the results are perfectly reproducible). Since the Fortran
>> code does a non-linear optimization, (slightly) different results
>> (e.g. depending on starting values) could be expected. However, the
>> values passed to the Fortran code are not affected by the
>> modifications that alter the values returned by the Fortran code and I
>> cannot sea any connection between the modification of the R files and
>> the values returned by the Fortran code. Could this phenomenon be
>> caused by an error in the Fortran code, by a bug in R, or is this a
>> usual behavior that an expert would expect in this situation? Any
>> hints are welcome!
>
> It is likely a bug in the Fortran or in R. Since you see it from very
> simple, well-tested R code like print() and <-, I would bet pretty heavily
> on it being in the Fortran.
>
> What it sounds like is that some part of the Fortran code depends on
> uninitialized values, or values outside the bounds of some array. The local
> variables take on values depending on what last used that portion of memory,
> so they are reproducible under identical scripts, but their value depends on
> more than the function arguments.
>
> I don't know Fortran well enough to know if there's an easy way to diagnose
> this. Does valgrind work for Fortran? In the old days, it used to be
> possible to fill the unused portion of the stack with FF bytes: these
> became NaN values in floating point, and -1 in integers, and would often
> trigger errors in functions that weren't ready for NaNs or negatives. I
> don't know how to do that on a modern system, though.
>
> Duncan Murdoch
Thanks for the hint, Duncan. Indeed it was an uninitialized value in
the Fortran code.
/Arne
--
Arne Henningsen
http://www.arne-henningsen.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
License filters will work for me. My offer stands to help on documentation,or to act as a "stooge" to test tools in this area. Thanks to those who responded. And for myself, "GPL compatible" was my intended expression. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
Dirk Eddelbuettel wrote: On 11 September 2009 at 17:25, Kurt Hornik wrote: | I thought I had already explained the last time the GPL-only suggestion | came up that this will not happen for CRAN. | | But again: we have invested considerable time into getting the license | specs standardized, and writing code to compute on these. Time | permitting, R 2.10.0 will feature code that allows specifying license | filters which can be customized according to individuals' needs. But I | see no point in physically representing one particular license profile. | | Btw, there are less non-free packages on CRAN than packages which claim | to be free but have non-free installation dependencies: some would argue | that the latter is impossible from a license perspective. I feel little | desire to start arguing about this, as being able to control package | installation by license filters will resolve matters anyway. Indeed, that would possibly solve some our (as in cran2deb) worries too. So a nig Thanks! for working on this, and of course for providing CRAN in the first place. I second that. People all over the world are more quantitative than they would otherwise be because the R project including CRAN (and R-Forge) make it economically feasible for them to access and use high quality software to better understand their world and communicate that improved understanding more effectively to others. Knowledge is power, and this increased knowledge gives more people more control over their lives. We are not laying brick but building a cathedral. Spencer Dirk -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
On 11 September 2009 at 17:25, Kurt Hornik wrote: | I thought I had already explained the last time the GPL-only suggestion | came up that this will not happen for CRAN. | | But again: we have invested considerable time into getting the license | specs standardized, and writing code to compute on these. Time | permitting, R 2.10.0 will feature code that allows specifying license | filters which can be customized according to individuals' needs. But I | see no point in physically representing one particular license profile. | | Btw, there are less non-free packages on CRAN than packages which claim | to be free but have non-free installation dependencies: some would argue | that the latter is impossible from a license perspective. I feel little | desire to start arguing about this, as being able to control package | installation by license filters will resolve matters anyway. Indeed, that would possibly solve some our (as in cran2deb) worries too. So a nig Thanks! for working on this, and of course for providing CRAN in the first place. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
On 11 September 2009 at 12:19, Gabor Grothendieck wrote: | One complication is that its possible that a package can use a non-free | component but can also be used without it. The fame package could | be used with fame or without fame for a long time but more recently the | non-fame portion was factored out into the tis package. The VhayuR | package is similar in that it can be used without Vhayu. In that case it | can use flat files instead of the Vhayu database. So in cases where a package used to not build with 'freely available' (and preferably available as Debian packages) tools but does so now we welcome hints so that we can update the blacklist. All it does, really, is to save a few cpu cycles when we have the expectation that 'R CMD INSTALL' is almost surely going to fail. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
At 08:07 11/09/2009, Romain Francois wrote: +1 Commit to freedom if you want the free services of CRAN, etc ... It seems to me very reasonable for people to be asked to distribute their software via some other route if they cannot join in the spirit of the enterprise. So add my vote in with Romain's. On 09/11/2009 12:13 AM, Dirk Eddelbuettel wrote: On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: |> Subject: Non-GPL packages for R |> |> Packages that are not licensed in a way that permits re-distribution on |> CRAN are frequently a source of comment and concern on R-help and other |> lists. A good example of this problem is the Rdonlp2 package that has caused |> a lot of annoyance for a number of optimization users in R. They are also an |> issue for efforts like Dirk Eddelbuettel's cran2deb. |> |> There are, however, a number of circumstances where non-GPL equivalent |> packages may be important to users. This can imply that users need to |> both install an R package and one or more dependencies that must be |> separately obtained and licensed. One such situation is where a new |> program is still under development and the license is not clear, as in |> the recent work we pursued with respect to Mike Powell's BOBYQA. We |> wanted to verify if this were useful before we considered distribution, |> and Powell had been offering copies of his code on request. Thus we |> could experiment, but not redistribute. Recently Powell's approval to |> redistribute has been obtained. |> |> We believe that it is important that non-redistributable codes be |> excluded from CRAN, but that they could be available on a repository |> such as r-forge. However, we would like to see a clearer indication of |> the license status on r-forge. One possibility is an inclusion of a |> statement and/or icon indicating such status e.g., green for GPL or |> equivalent, amber for uncertain, red for restricted. Another may be a |> division of directories, so that GPL-equivalent packages are kept |> separate from uncertain or restricted licensed ones. |> |> We welcome comments and suggestions on both the concept and the |> technicalities. |> |> John Nash& Ravi Varadhan -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/y8y0 : search the graph gallery from R |- http://tr.im/y8wY : new R package : ant `- http://tr.im/xMdt : update on the ant package __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Michael Dewey http://www.aghmed.fsnet.co.uk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
One complication is that its possible that a package can use a non-free component but can also be used without it. The fame package could be used with fame or without fame for a long time but more recently the non-fame portion was factored out into the tis package. The VhayuR package is similar in that it can be used without Vhayu. In that case it can use flat files instead of the Vhayu database. On Fri, Sep 11, 2009 at 11:44 AM, Dirk Eddelbuettel wrote: > > On 11 September 2009 at 16:37, Peter Dalgaard wrote: > | who have responded on the list do not necessarily speak for CRAN. In the > | final analysis, the maintainers must decide what is maintainable. > > Fully agreed. As 'maintainers' of cran2deb, Charles and I decided to 'shoot > first, ask questions later' as we clearly wanted to avoid creating any sort > of trouble for our generous CRAN hosts (currently just the Vienna master) are > effectively re-distributing our compilations (of its own content). > > So we pro-actively chose to excludes some packages. To put some meat on this > particular bone, the current set packages blacklistes for 'nonfree-ness' is: > > sqlite> select package, explanation from blacklist_packages where nonfree; > package explanation > > mclust non-commercial license > mclust02 non-commercial license > ConvCalendar no modification or distribution rights > SDDA non-commercial CSIRO license > conf.design non-commercial license > isa2 non-commercial creative commons license > optmatch non-commercial license > rankreg non-commercial license > realized non-commercial license > rngwell19937 non-commercial license > tnet non-commercial creative commons license > spatialkernel contains non-commercial gpc code > Bhat non-commercial license > PTAk non-commercial license > PredictiveRegression non-commercial license > RLadyBug contains some code under non-commercial > mapproj non-commercial license > mathgraph non-commercial license > sqlite> > > | (Even within the Free Software world there are current issues with, > | e.g., incompatibilities between GPL v.2 and v.3, and also with the > | Eclipse license. Don't get me started...) > > Yes. There is a potential problem with gcc 4.4 compilation of GPL-2 code. If > that comes to a boil we all (as in: GPL 2 users) are in a spot of bother. > > On 11 September 2009 at 07:48, Robert Gentleman wrote: > | It is also the case that things are not so simple, as dependencies > | can make a package unusable even if it is itself GPL-compatible. This > > Yes, in the case of cran2deb / CRAN there are just three blacklists because > of dependencies on nonfree CRAN content, most often it is dependencies on > other stuff incl BioC which we do not include (for mostly technical / > historical reasons; contact Charles or me offline if you'd like to work on > changing this) > > sqlite> select package,explanation from blacklist_packages where > unsatisfied_dependency; > package explanation > > ROracle requires Oracle to build and run > Rlsf requires LSF cluster/grid system librari > Rsge requires SGE cluster/grid system librari > CarbonEL requires OS X system > VhayuR requires Vhayu database system > gputools requires Nvidia CUDA compiler and GPU-en > klaR requires SVMlight which is non-free > wgaim requires asreml-R > svGUI requires Komodo from OpenKomodo.org whic > RScaLAPACK requires MPICH2 and Blacs and ScaLAPACK > caMassClass requires PROcess from BioConductor > Rcplex requires CPLEX libraries > ADaCGH BioC depends: tilingArray > DAAGbio BioC depends: limma > GFMaps BioC depends: affy > GOSim BioC depends: GO.db > Metabonomic BioC depends: PROcess > classGraph BioC depends: Rgraphviz > gcExplorer BioC depends: Rgraphviz > logilasso BioC depends: Rgraphviz > pcalg BioC depends: Rgraphviz > celsius BioC depends: BioBase > multtest BioC depends: BioBase > hopach BioC depends: BioBase > GExMap BioC depends: multtest,BioBase > LMGene BioC depends: multtest,BioBase > PCS BioC depends: multtest,BioBase > SubpathwayMiner BioC depends: KEGG.db > gene2pathway BioC depends: KEGG.db > PhViD BioC depends: LBE > SNPMaP BioC depends: affxparser > qdg
Re: [Rd] Non-GPL packages for R
On 11 September 2009 at 16:37, Peter Dalgaard wrote:
| who have responded on the list do not necessarily speak for CRAN. In the
| final analysis, the maintainers must decide what is maintainable.
Fully agreed. As 'maintainers' of cran2deb, Charles and I decided to 'shoot
first, ask questions later' as we clearly wanted to avoid creating any sort
of trouble for our generous CRAN hosts (currently just the Vienna master) are
effectively re-distributing our compilations (of its own content).
So we pro-actively chose to excludes some packages. To put some meat on this
particular bone, the current set packages blacklistes for 'nonfree-ness' is:
sqlite> select package, explanation from blacklist_packages where nonfree;
package explanation
mclustnon-commercial license
mclust02 non-commercial license
ConvCalendar no modification or distribution rights
SDDA non-commercial CSIRO license
conf.design non-commercial license
isa2 non-commercial creative commons license
optmatch non-commercial license
rankreg non-commercial license
realized non-commercial license
rngwell19937 non-commercial license
tnet non-commercial creative commons license
spatialkernel contains non-commercial gpc code
Bhat non-commercial license
PTAk non-commercial license
PredictiveRegression non-commercial license
RLadyBug contains some code under non-commercial
mapproj non-commercial license
mathgraph non-commercial license
sqlite>
| (Even within the Free Software world there are current issues with,
| e.g., incompatibilities between GPL v.2 and v.3, and also with the
| Eclipse license. Don't get me started...)
Yes. There is a potential problem with gcc 4.4 compilation of GPL-2 code. If
that comes to a boil we all (as in: GPL 2 users) are in a spot of bother.
On 11 September 2009 at 07:48, Robert Gentleman wrote:
|It is also the case that things are not so simple, as dependencies
| can make a package unusable even if it is itself GPL-compatible. This
Yes, in the case of cran2deb / CRAN there are just three blacklists because
of dependencies on nonfree CRAN content, most often it is dependencies on
other stuff incl BioC which we do not include (for mostly technical /
historical reasons; contact Charles or me offline if you'd like to work on
changing this)
sqlite> select package,explanation from blacklist_packages where
unsatisfied_dependency;
package explanation
ROracle requires Oracle to build and run
Rlsf requires LSF cluster/grid system librari
Rsge requires SGE cluster/grid system librari
CarbonEL requires OS X system
VhayuRrequires Vhayu database system
gputools requires Nvidia CUDA compiler and GPU-en
klaR requires SVMlight which is non-free
wgaim requires asreml-R
svGUI requires Komodo from OpenKomodo.org whic
RScaLAPACKrequires MPICH2 and Blacs and ScaLAPACK
caMassClass requires PROcess from BioConductor
Rcplexrequires CPLEX libraries
ADaCGHBioC depends: tilingArray
DAAGbio BioC depends: limma
GFMapsBioC depends: affy
GOSim BioC depends: GO.db
Metabonomic BioC depends: PROcess
classGraphBioC depends: Rgraphviz
gcExplorerBioC depends: Rgraphviz
logilasso BioC depends: Rgraphviz
pcalg BioC depends: Rgraphviz
celsius BioC depends: BioBase
multtest BioC depends: BioBase
hopachBioC depends: BioBase
GExMapBioC depends: multtest,BioBase
LMGeneBioC depends: multtest,BioBase
PCS BioC depends: multtest,BioBase
SubpathwayMiner BioC depends: KEGG.db
gene2pathway BioC depends: KEGG.db
PhViD BioC depends: LBE
SNPMaPBioC depends: affxparser
qdg BioC depends: pcalg,Rgraphviz
lsa Ohat depends: Rstem
mpm BioC depends: geneplotter
sisus BioC depends: annotate
metaMABioC depends: limma
clustTool non-free depends: mclust02
clustvarsel non-free depends: mclust02
SpectralGEM non-free depends: optmatch
bayesCGH BioC depends: snapCGH
crosshybDetector missing depends: marray
FEST needs MERLIN
Re: [Rd] Non-GPL packages for R
> Prof John C Nash writes: > The responses to my posting yesterday seem to indicate more consensus > than I expected: > 1) CRAN should be restricted to GPL-equivalent licensed packages > 2) r-forge could be left "buyer beware" using DESCRIPTION information > 3) We may want a specific repository for restricted packages (RANC?) > How to proceed? A short search on Rseek did not turn up a chain of > command for CRAN. I thought I had already explained the last time the GPL-only suggestion came up that this will not happen for CRAN. But again: we have invested considerable time into getting the license specs standardized, and writing code to compute on these. Time permitting, R 2.10.0 will feature code that allows specifying license filters which can be customized according to individuals' needs. But I see no point in physically representing one particular license profile. Btw, there are less non-free packages on CRAN than packages which claim to be free but have non-free installation dependencies: some would argue that the latter is impossible from a license perspective. I feel little desire to start arguing about this, as being able to control package installation by license filters will resolve matters anyway. -k > I'm prepared to help out with documentation etc. to move changes > forward. They are not, in my opinion, likely to cause a lot of trouble > for most users, and should simplify things over time. > JN > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran routine affected by unrelated R code
On 9/11/2009 10:48 AM, Arne Henningsen wrote:
Hi!
When I run "R CMD check" on the current development version of my R
package "frontier" [1], there is no difference between the output of
the test scripts in the /tests/ folder and the saved output files
(.Rout.save). However, if I change an R file in the /R/ folder, some
calls to the Fortran code (called by ".Fortran()") return different
results, although the change of the R file is not related to this,
e.g. when I add the commands 'print("abc")' or 'newVariable <- 123' to
an R file that even does not call the Fortran code. However, adding
empty lines or comments does NOT change the values returned by the
Fortran code. Different modifications of the R files lead to different
results but the same modification always leads to the same results
(hence, the results are perfectly reproducible). Since the Fortran
code does a non-linear optimization, (slightly) different results
(e.g. depending on starting values) could be expected. However, the
values passed to the Fortran code are not affected by the
modifications that alter the values returned by the Fortran code and I
cannot sea any connection between the modification of the R files and
the values returned by the Fortran code. Could this phenomenon be
caused by an error in the Fortran code, by a bug in R, or is this a
usual behavior that an expert would expect in this situation? Any
hints are welcome!
It is likely a bug in the Fortran or in R. Since you see it from very
simple, well-tested R code like print() and <-, I would bet pretty
heavily on it being in the Fortran.
What it sounds like is that some part of the Fortran code depends on
uninitialized values, or values outside the bounds of some array. The
local variables take on values depending on what last used that portion
of memory, so they are reproducible under identical scripts, but their
value depends on more than the function arguments.
I don't know Fortran well enough to know if there's an easy way to
diagnose this. Does valgrind work for Fortran? In the old days, it
used to be possible to fill the unused portion of the stack with FF
bytes: these became NaN values in floating point, and -1 in integers,
and would often trigger errors in functions that weren't ready for NaNs
or negatives. I don't know how to do that on a modern system, though.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
> spencerg writes: > I will offer my opinion as a user and contributer to R packages > via R-Forge and CRAN: >1. How difficult would it be to split CRAN into two parts, > depending on whether the package carried an acceptable license allowing > free distribution? The second might carry a name like RANC (R Archive > Network - Commercial), and the first would retain the CRAN name. You are suggesting we create and maintain an *empty* repository? All packages on CRAN should be freely redistributable by/within CRAN. If you find a package which is not, pls let us know---such packages must be removed from CRAN. I think you are mistaking the situation about "non-free" packages: these typically restrict usage for commercial purposes. -k >2. R-Forge allows public access to the source code, at least > for some packages. Moreover, users applying for R-Forge support must > specify the license they plan to use. Support may be denied for a > project that does not use one of the standard public distribution > licenses like GPL. > Spencer > Dirk Eddelbuettel wrote: >> On 10 September 2009 at 14:26, Gabor Grothendieck wrote: >> | The SystemRequirements: field of the DESCRIPTION file normally >> | lists external dependencies whether free or non-free. >> >> Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more >> parseable and contains pertinent information. A number of more 'challenging' >> packages basically pass the buck on with an entry >> >> License: file LICENSE >> >> which refers to a file in the sources one needs to read to decide. >> >> This is e.g. at the basis of Charles' and my decision about what we think we >> cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or >> otherwise nasty licenses. There are a couple of packages we exclude for this >> (or related reasons), and we have been meaning to summarise them with a >> simple html summary from the database table we use for cran2deb, but have not >> yet gotten around to it. >> >> Just like John and Ravi, I would actually be in favour of somewhat stricter >> enforcements. If someone decides not to take part in the gift economy that >> brought him or her R (and many other things, including at least 1880+ CRAN >> packages with sane licenses) then we may as well decide not to waste our time >> and resources on his project either and simply exclude it. >> >> So consider this as a qualified thumbs-up for John and Ravi's suggestion of a >> clearer line in the sand. >> >> Dirk >> >> [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian >> 'testing' binaries for amd64 and i386 that are continuously updated as new >> packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a >> reality for almost every value of foo out of the set of CRAN packages. >> >> >> | >> | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash >> wrote: >> | > Subject: Non-GPL packages for R >> | > >> | > Packages that are not licensed in a way that permits re-distribution on >> | > CRAN are frequently a source of comment and concern on R-help and other >> | > lists. A good example of this problem is the Rdonlp2 package that has >> caused >> | > a lot of annoyance for a number of optimization users in R. They are >> also an >> | > issue for efforts like Dirk Eddelbuettel's cran2deb. >> | > >> | > There are, however, a number of circumstances where non-GPL equivalent >> | > packages may be important to users. This can imply that users need to >> | > both install an R package and one or more dependencies that must be >> | > separately obtained and licensed. One such situation is where a new >> | > program is still under development and the license is not clear, as in >> | > the recent work we pursued with respect to Mike Powell's BOBYQA. We >> | > wanted to verify if this were useful before we considered distribution, >> | > and Powell had been offering copies of his code on request. Thus we >> | > could experiment, but not redistribute. Recently Powell's approval to >> | > redistribute has been obtained. >> | > >> | > We believe that it is important that non-redistributable codes be >> | > excluded from CRAN, but that they could be available on a repository >> | > such as r-forge. However, we would like to see a clearer indication of >> | > the license status on r-forge. One possibility is an inclusion of a >> | > statement and/or icon indicating such status e.g., green for GPL or >> | > equivalent, amber for uncertain, red for restricted. Another may be a >> | > division of directories, so that GPL-equivalent packages are kept >> | > separate from uncertain or restricted licensed ones. >> | > >> | > We welcome comments and suggestions on both the concept and the >> | > technicalities. >> | > >> | > John Nash & Ravi Varadhan >> | > >> | > __ >> | > R-devel@r-project.org mailing list >> | > h
Re: [Rd] Non-GPL packages for R
Hi, Peter Dalgaard wrote: Prof. John C Nash wrote: The responses to my posting yesterday seem to indicate more consensus than I expected: Umm, I had thought that it was well established that responders need not represent the population being surveyed. I doubt that there is consensus at the level you are suggesting (certainly I don't agree) and as Peter indicates below the issue is: what is maintainable with the resources we have, not what is the best solution given unlimited resources. Personally, I would like to see something that was a bit easier to deal with programmatically that indicated when a package was GPL (or Open source actually) compatible and when it is not. This could then be used to write a decent function to identify suspect packages so that users would know when they should be concerned. It is also the case that things are not so simple, as dependencies can make a package unusable even if it is itself GPL-compatible. This also makes the notion of some simple split into free and non-free (or what ever split you want) less trivial than is being suggested. Robert 1) CRAN should be restricted to GPL-equivalent licensed packages GPL-_compatible_ would be the word. However, this is not what has been done in the past. There are packages with "non-commercial use" licences, and the survival package was among them for quite a while. As far as I know, the CRAN policy has been to ensure only that redistribution is legal and that whatever license is used is visible to the user. People who have responded on the list do not necessarily speak for CRAN. In the final analysis, the maintainers must decide what is maintainable. The problem with Rdonlp2 seems to have been that the interface packages claimed to be LGPL2 without the main copyright holder's consent (and it seems that he cannot grant consent for reasons of TU-Darmstadt policies). It is hard to safeguard agaist that sort of thing. CRAN maintainers must assume that legalities have been cleared and accept the license in good faith. (Even within the Free Software world there are current issues with, e.g., incompatibilities between GPL v.2 and v.3, and also with the Eclipse license. Don't get me started...) 2) r-forge could be left "buyer beware" using DESCRIPTION information 3) We may want a specific repository for restricted packages (RANC?) How to proceed? A short search on Rseek did not turn up a chain of command for CRAN. I'm prepared to help out with documentation etc. to move changes forward. They are not, in my opinion, likely to cause a lot of trouble for most users, and should simplify things over time. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fortran routine affected by unrelated R code
Hi!
When I run "R CMD check" on the current development version of my R
package "frontier" [1], there is no difference between the output of
the test scripts in the /tests/ folder and the saved output files
(.Rout.save). However, if I change an R file in the /R/ folder, some
calls to the Fortran code (called by ".Fortran()") return different
results, although the change of the R file is not related to this,
e.g. when I add the commands 'print("abc")' or 'newVariable <- 123' to
an R file that even does not call the Fortran code. However, adding
empty lines or comments does NOT change the values returned by the
Fortran code. Different modifications of the R files lead to different
results but the same modification always leads to the same results
(hence, the results are perfectly reproducible). Since the Fortran
code does a non-linear optimization, (slightly) different results
(e.g. depending on starting values) could be expected. However, the
values passed to the Fortran code are not affected by the
modifications that alter the values returned by the Fortran code and I
cannot sea any connection between the modification of the R files and
the values returned by the Fortran code. Could this phenomenon be
caused by an error in the Fortran code, by a bug in R, or is this a
usual behavior that an expert would expect in this situation? Any
hints are welcome!
Arne
[1] http://r-forge.r-project.org/projects/frontier/
--
Arne Henningsen
http://www.arne-henningsen.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
Prof. John C Nash wrote: > The responses to my posting yesterday seem to indicate more consensus > than I expected: > 1) CRAN should be restricted to GPL-equivalent licensed packages GPL-_compatible_ would be the word. However, this is not what has been done in the past. There are packages with "non-commercial use" licences, and the survival package was among them for quite a while. As far as I know, the CRAN policy has been to ensure only that redistribution is legal and that whatever license is used is visible to the user. People who have responded on the list do not necessarily speak for CRAN. In the final analysis, the maintainers must decide what is maintainable. The problem with Rdonlp2 seems to have been that the interface packages claimed to be LGPL2 without the main copyright holder's consent (and it seems that he cannot grant consent for reasons of TU-Darmstadt policies). It is hard to safeguard agaist that sort of thing. CRAN maintainers must assume that legalities have been cleared and accept the license in good faith. (Even within the Free Software world there are current issues with, e.g., incompatibilities between GPL v.2 and v.3, and also with the Eclipse license. Don't get me started...) > 2) r-forge could be left "buyer beware" using DESCRIPTION information > 3) We may want a specific repository for restricted packages (RANC?) > > How to proceed? A short search on Rseek did not turn up a chain of > command for CRAN. > > I'm prepared to help out with documentation etc. to move changes > forward. They are not, in my opinion, likely to cause a lot of trouble > for most users, and should simplify things over time. > > JN > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
The responses to my posting yesterday seem to indicate more consensus than I expected: 1) CRAN should be restricted to GPL-equivalent licensed packages 2) r-forge could be left "buyer beware" using DESCRIPTION information 3) We may want a specific repository for restricted packages (RANC?) How to proceed? A short search on Rseek did not turn up a chain of command for CRAN. I'm prepared to help out with documentation etc. to move changes forward. They are not, in my opinion, likely to cause a lot of trouble for most users, and should simplify things over time. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Logic ("!", "&", ...) on complex
The documentation, help("!") e.g.,
contains
> Arguments:
> x, y: logical vectors, or objects which can be coerced to such or
> for which methods have been written.
and then later
> Numeric and complex vectors will be coerced to logical values,
> with zero being false and all non-zero values being true.
and that is consistent with what S-plus (3.4, 5.1, 8.0.2)
gives.
However, (nowadays at least) R internally checks and gives an
error for complex arguments,
even though as.logical(0 + 1i) works fine.
> z <- complex(i=1)
> !z
Error in !z : invalid argument type
> !as.logical(z)
[1] FALSE
I'm proposing to make R's behavior consistent with its
documentation and predecessor.
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
+1 Commit to freedom if you want the free services of CRAN, etc ... On 09/11/2009 12:13 AM, Dirk Eddelbuettel wrote: On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: |> Subject: Non-GPL packages for R |> |> Packages that are not licensed in a way that permits re-distribution on |> CRAN are frequently a source of comment and concern on R-help and other |> lists. A good example of this problem is the Rdonlp2 package that has caused |> a lot of annoyance for a number of optimization users in R. They are also an |> issue for efforts like Dirk Eddelbuettel's cran2deb. |> |> There are, however, a number of circumstances where non-GPL equivalent |> packages may be important to users. This can imply that users need to |> both install an R package and one or more dependencies that must be |> separately obtained and licensed. One such situation is where a new |> program is still under development and the license is not clear, as in |> the recent work we pursued with respect to Mike Powell's BOBYQA. We |> wanted to verify if this were useful before we considered distribution, |> and Powell had been offering copies of his code on request. Thus we |> could experiment, but not redistribute. Recently Powell's approval to |> redistribute has been obtained. |> |> We believe that it is important that non-redistributable codes be |> excluded from CRAN, but that they could be available on a repository |> such as r-forge. However, we would like to see a clearer indication of |> the license status on r-forge. One possibility is an inclusion of a |> statement and/or icon indicating such status e.g., green for GPL or |> equivalent, amber for uncertain, red for restricted. Another may be a |> division of directories, so that GPL-equivalent packages are kept |> separate from uncertain or restricted licensed ones. |> |> We welcome comments and suggestions on both the concept and the |> technicalities. |> |> John Nash& Ravi Varadhan -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/y8y0 : search the graph gallery from R |- http://tr.im/y8wY : new R package : ant `- http://tr.im/xMdt : update on the ant package __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
