>>>>> 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 <nas...@uottawa.ca> >> 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 >> | > https://stat.ethz.ch/mailman/listinfo/r-devel >> | > >> | >> | ______________________________________________ >> | R-devel@r-project.org mailing list >> | https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > -- > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel