Martyn Plummer <plummerm <at> iarc.fr> writes:> > I think this is covered well by the CRAN repository policy: > http://cran.r-project.org/web/packages/policies.html > > The two key license requirements are that: > 1) CRAN must have a perpetual license to distribute the package > 2) The package license should be listed here: > https://svn.r-project.org/R/trunk/share/licenses/license.db > Packages with licenses not included in that list are generally not > accepted. >...> > Personally, I would not want to add the extra complexity to a package > that is otherwise GPL. > > Martyn > > On Tue, 2015-04-21 at 19:23 -0400, Ben Bolker wrote: > > Does anyone have speculations about the implications of the GPL for > > data included in a package, or more generally for restricting use of data? > >... While I agree with Martyn with respect to code, documentation, and vignettes, the point Ben raises is relevant and not obvious. Data sets in say GLP-licensed packages are on occasion challenged by Debian packagers where it isn't obvious that GPL is appropriate. Some spatial packages are not accepted for packaging as is because of included data, data that is needed to run realistic examples. The problem could be picky packagers, but it is also reasonable that well-known example data sets could be licensed differently. share/licenses/license.db lists for example CC BY-SA 4.0 as both FOSS and extensible but free_and_GPLv3_incompatible. One possibility I examined when challenged was to place all such data files in a separate package, for example under a CC license accepted by CRAN - I didn't complete the task, but understand Ben's question as applying to the same question. Roger> > > > cheers > > Ben Bolker > > > >>
On Wed, 2015-04-22 at 11:34 +0000, Roger Bivand wrote:> Martyn Plummer <plummerm <at> iarc.fr> writes: > > > > > I think this is covered well by the CRAN repository policy: > > http://cran.r-project.org/web/packages/policies.html > > > > The two key license requirements are that: > > 1) CRAN must have a perpetual license to distribute the package > > 2) The package license should be listed here: > > https://svn.r-project.org/R/trunk/share/licenses/license.db > > Packages with licenses not included in that list are generally not > > accepted. > > > ... > > > > Personally, I would not want to add the extra complexity to a package > > that is otherwise GPL. > > > > Martyn > > > > On Tue, 2015-04-21 at 19:23 -0400, Ben Bolker wrote: > > > Does anyone have speculations about the implications of the GPL for > > > data included in a package, or more generally for restricting use of data? > > > > ... > While I agree with Martyn with respect to code, documentation, and > vignettes, the point Ben raises is relevant and not obvious. Data sets in > say GLP-licensed packages are on occasion challenged by Debian packagers > where it isn't obvious that GPL is appropriate. Some spatial packages are > not accepted for packaging as is because of included data, data that is > needed to run realistic examples. > > The problem could be picky packagers, but it is also reasonable that > well-known example data sets could be licensed differently. > share/licenses/license.db lists for example CC BY-SA 4.0 as both FOSS and > extensible but free_and_GPLv3_incompatible. One possibility I examined when > challenged was to place all such data files in a separate package, for > example under a CC license accepted by CRAN - I didn't complete the task, > but understand Ben's question as applying to the same question.It is also clearly possible to license data files differently than the package. GPL is copyleft for compiled code. R data files are not compiled/linked into the package, they are included in a tarball or zip file. As such, the copyleft provision of GPL doesn't necessarily apply to non-compiled files in the package collection, and isn't necessarily intended to apply (the Gnu licenses page suggests not using GPL for data). Whether CRAN or Debian packagers would accept a open but mixed code/data license scheme is not for me to say, but I don't see any impediments from the licenses themselves. -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock
On 22 April 2015 at 11:34, Roger Bivand wrote:
| While I agree with Martyn with respect to code, documentation, and
| vignettes, the point Ben raises is relevant and not obvious. Data sets in
| say GLP-licensed packages are on occasion challenged by Debian packagers
Not generally the packagers (who get frustrated by this like everybody else)
but by the "ftp-masters" teams who look over what gets into the
Archive.
They are the license reviewers, and gate-keepers.
In several cases we (ie "packagers") had to write README.sources to
document
origins of datasets. That is generally a little silly as ... R itself
already enforces in the .Rd files. So for the packages where I had to do that
the README.sources effectively becomes a forward reference to the R docs.
But then again the ftp-masters review _thousands_ of packages and having to
help their workflow is a small burden.
In general, nitpicky licensing issue have been discussed (to mindnumbing
length) on the debian-legal list. Those interested in the issue may want to
peruse or search the archive:
http://news.gmane.org/gmane.linux.debian.devel.legal
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Dirk Eddelbuettel <edd <at> debian.org> writes:> On 22 April 2015 at 11:34, Roger Bivand wrote: > | While I agree with Martyn with respect to code, documentation, and > | vignettes, the point Ben raises is relevant and not obvious. Data sets in > | say GLP-licensed packages are on occasion challenged by Debian packagers[GPL]> Not generally the packagers (who get frustrated by this like everybody else) > but by the "ftp-masters" teams who look over what gets into the Archive. > > They are the license reviewers, and gate-keepers. > > In several cases we (ie "packagers") had to write README.sources to document > origins of datasets. That is generally a little silly as ... R itself > already enforces in the .Rd files. So for the packages where I had to do that > the README.sources effectively becomes a forward reference to the R docs. > But then again the ftp-masters review _thousands_ of packages and having to > help their workflow is a small burden. > > In general, nitpicky licensing issue have been discussed (to mindnumbing > length) on the debian-legal list. Those interested in the issue may want to > peruse or search the archive: > http://news.gmane.org/gmane.linux.debian.devel.legal > > DirkThanks for the information, everyone! I think I'm just going to handle it the sloppy way, providing a .Rd file containing documentation and a URL for the data set. This is not particularly good for long-term maintenance, but it seems silly to try to get a separate package onto CRAN for a *single* (small) data set. For what it's worth, I've been informed by the CRAN maintainers that> 'license' is singular in the CRAN policies, something peoplesometimes overlook.> A package must have a single licence that applies to all of thepackage (even if alternative licences are offered for all or part), so "GPL except for file XXX" is not viable.