Re: [Rd] Non-GPL packages for R
On Fri, Sep 11, 2009 at 1:48 PM, rudjer wrote:
>
> 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.
It is unfortunately common in the numerical analysis community,
especially those still using Fortran, to have a rather vague approach
to licensing. ("I'll send a copy of my code to anyone who asks for it
but put in some language that if someone is going to get fantastically
rich from it then they owe me money too") In the Open Source
community licensing is very important - it is what makes Open Source
software, including CRAN, possible. Most non-lawyers don't find the
study and discussion of licenses to be terribly fascinating but they
are the foundation of Open Source software. If the authors of Fortran
subroutines feel that it is too much of a bother to pay attention to
licenses (or to learn post-1950's programming languages) then
evolution will run its course and they will be left behind. It's
annoying in that so little software from the numerical analysis
community is covered by suitable licenses but that will change.
Tim Davis's C and C++-based sparse matrix code that is incorporated in
the Matrix package is licensed under the GPL or LGPL. Why mess around
with antiquated software and vague or non-existent licenses when there
are better alternatives? It is painful to need to recode old Fortran
routines in modern programming languages and under real licenses but
it is the only way we will ever bring numerical analysis into the
post-Beatles era.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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] 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] 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
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
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
Re: [Rd] Non-GPL packages for R
On 10/09/2009 6:57 PM, spencerg wrote: 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. To this I would say, try it. Don't ask volunteers to do some work that suits you; do it yourself. Duncan Murdoch 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 | > https://stat.ethz.ch/mailman/listinfo/r-devel | > | | __ | 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] Non-GPL packages for R
With header this time On Thu, 10 Sep 2009 16:08 -0700, "Nicholas Lewin-Koh" 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 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
Re: [Rd] Non-GPL packages for R
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. 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 | > 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
Re: [Rd] Non-GPL packages for R
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 | > https://stat.ethz.ch/mailman/listinfo/r-devel | > | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- 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
The SystemRequirements: field of the DESCRIPTION file normally lists external dependencies whether free or non-free. 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 > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Non-GPL packages for R
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
