With header this time On Thu, 10 Sep 2009 16:08 -0700, "Nicholas Lewin-Koh" <ni...@hailmail.net> wrote: > Hi, > I would also be in favor of a stronger stance on licenses. In > industry, where we can really get in big trouble for violating a > license, > we often maintain internal repositories, or need to be careful about > filtering > what is used from CRAN. I think that is should really be a requirement > the package > authors commit to stating what the restrictions are on their packages. > > Nicholas > > > 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 <nashjc at > 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 at r-project.org mailing list > | > https://stat.ethz.ch/mailman/listinfo/r-devel > | > > | > | ______________________________________________ > | R-devel at 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
