R packages license

[isuruf]

license_file is not included in most of the R recipes. What should be done here? The packages don't have license files in them, so we might need to package it manually.

Opening this issue here since I saw PRs here with license_file not included.

cc @conda-forge/staged-recipes, @bgruening, @johanneskoester

[johanneskoester]

Not my call, but personally I think if even the authors don't bother, we don't need to either.

[bgruening]

I don't think we should repackage them. We could raise the issue upstream but for the meantime I would say licence is good enough.

[jakirkham]

Raising it upstream sounds like a good idea.

What does a developer of an R library need to do to ensure their license file shows up with their source code on CRAN? Just include it in the source code? Or is there something like Python's MANIFEST.in for R, which needs to list files like these to include?

[jdblischak]

What does a developer of an R library need to do to ensure their license file shows up with their source code on CRAN? Just include it in the source code? Or is there something like Python's MANIFEST.in for R, which needs to list files like these to include?

@jakirkham The convention is that CRAN packages do not includes the actual license file with them to avoid duplication. Instead, the license is specified in the file DESCRIPTION, and then the actual text of the standard license is distributed with R itself. For example, on Ubuntu the licenses are saved in /usr/share/R/share/licenses/:

$ ls /usr/share/R/share/licenses/
AGPL-3        BSD_2_clause  GPL-2  LGPL-2    LGPL-3      MIT
Artistic-2.0  BSD_3_clause  GPL-3  LGPL-2.1  license.db

From the manual Writing R Extensions:

Whereas you should feel free to include a license file in your source distribution, please do not arrange to install yet another copy of the GNU COPYING or COPYING.LIB files but refer to the copies on https://www.R-project.org/Licenses/ and included in the R distribution (in directory share/licenses).

For now, I am interpreting the discussion in this Issue to mean that we don't need to include a separate file with the license text for GPL'd CRAN packages when submitting future recipes. Please let me know if I am mistaken.

[scopatz]

Please let me know if I am mistaken.

Hello All, I think that you are mistaken. It is a requirement of GPL to distribute the license file along with the software. If we want to have these codes as packages, we have a legal obligation to provide the license as well. That is just the cost of doing business with those codes.

It seems that CRAN / R distribute their own copy of license and have a clear mechanism for directing people to that license for downstream packages. This is a tiny bit more efficient for the whole ecosystem. (Presumably packages that use non-standard licenses or licenses that aren't shipped with CRAN still have to provide the license file.) However, conda and conda-build have no such mechanism, to the best of my knowledge.

A conda package cannot guarantee that their license is present & there is no clear way to find a copy of the license if it does exist (R may ship with GPL, but how does r-mypackage know where that is). Thus, for the time being, every GPL package in conda has to provide the license file --- just in case some one is looking at that package and that package alone.

Also, on the flip side, it is just a single file and it isn't really that much data in the grand scheme of things.

Yes, it might be minorly annoying to include because the upstream distributor has chosen to do something special. But that doesn't prevent us from doing the legal thing :).

[bgruening]

@sccolbert you are completely right. But r-base is shipping with the license file as seen here: https://github.com/conda-forge/r-base-feedstock/blob/master/recipe/meta.yaml#L131

And this is also the way conda packaging works with such cases. If we need to put this into every package we should enhance our linting to make license_file mandatory if it is GPL licensed.

[jakirkham]

If r-base has some standard licenses that we should use, it should be straightforward to point license_file at the respective license for each package so that they get included in the final package.

[scopatz]

we should enhance our linting to make license_file mandatory if it is GPL licensed.

Yes, we should :)

[isuruf]

license_file: '{{ environ["PREFIX"] }}/lib/R/share/licenses/GPL-3' works

[jdblischak]

license_file: '{{ environ["PREFIX"] }}/lib/R/share/licenses/GPL-3' works

If we end up using this solution, two follow-up questions:

1. Should this be incorporated upstream into cran.py so that it is the default behavior of conda skeleton cran? There are lots of R packages uploaded to Anaconda Cloud, so it would be nice if most followed this convention.
2. Should we add support to link to the other non-GPL licenses that ship with R (e.g. BSD, MIT)?

[isuruf]

Should this be incorporated upstream into cran.py so that it is the default behavior of conda skeleton cran? There are lots of R packages uploaded to Anaconda Cloud, so it would be nice if most followed this convention.

cc @msarahan, @mingwandroid

Should we add support to link to the other non-GPL licenses that ship with R (e.g. BSD, MIT)?

BSD in binary form also requires the license be distributed. It's better to have it for all licenses shipped in r-base.

[ocefpaf]

This is a messy subject and I don't think what CRAN does by default is 100% OK. Most r packages that are GPL-3.0 do not ship the GPL-3.0 license text but do ship something like this. So, if we add that license file we are still missing the actual license text b/c r-folks expect that to be "bundled," while if we decide to use only a bundled GPL-3.0 text we are still missing the info in that file 😒

TL;DR we would need to do both to actually do the right thing.

[scopatz]

BSD in binary form also requires the license be distributed

Not strictly true (the license does not require that the warranty disclaimer be distributed - even though it is part of the license) but it is close enough :)

[jakirkham]

Sorry to ping this. Just trying to wrap this up.

It seems that @isuruf's suggestion has become standard. Is that correct? If so, did we document this somewhere? If not documented, should we add this to the webpage docs?

Also (assuming I understand the standard correctly) there is @jdblischak's suggestion to incorporate this in conda-build. Is there a conda-build issue/PR for this that we can track? If not, can we raise an issue for now? IIRC @bgruening has built tooling to generate R recipes. Should we/did we integrate a similar change into that tooling? Or perhaps raise an issue on the appropriate repo holding this tooling?

[mingwandroid]

IIRC @bgruening has built tooling to generate R recipes

Do you mean something other than conda skeleton cran?

[bgruening]

I wouldn't call it tooling, but some hacks ;) https://github.com/bgruening/conda_r_skeleton_helper it started all to add the maintainers automatically and then ended up in adding all the extra bit to make it conda-forge compliant.

[jdblischak]

It seems that @isuruf's suggestion has become standard. Is that correct?

Yes, we use that solution for GPL'd packages. They're the easiest because the GPL licenses shipped with r-base are complete, whereas many of the others are only templates.

If so, did we document this somewhere? If not documented, should we add this to the webpage docs?

No because it is not a mature solution. As @bgruening noted below, our current pipeline is a series of hacks after running conda skeleton cran. It can't even run on macOS, so it's hard to require submitters to use it.

Also (assuming I understand the standard correctly) there is @jdblischak's suggestion to incorporate this in conda-build. Is there a conda-build issue/PR for this that we can track?

This has been on my "if I had a free afternoon" to-do list for awhile. One reason that I have not been overly motivated is because conda-forge still uses conda-build 2, so even if we implemented this for conda-build 3, it wouldn't save conda-forge R maintainers any time until we make the migration.

If not, can we raise an issue for now?

That'd be great. It would be good to discuss the scope before trying to implement it.

[jdblischak]

I started working on this in https://github.com/conda/conda-build/pull/2831. Please let me know what you think.

It currently supports all the licenses shipped with R that are complete. I think it would also be straightfoward to include actual license files shipped with the packages, e.g. 'ACM | file LICENSE', but I haven't implemented that yet. The trickiest are licenses like BSD/MIT that would need to combine the template shipped with R plus the LICENSE shipped by the authors, and I'm not currently attempting to handle these cases in this first pass.

[CJ-Wright]

For the existing packages without a license file maybe we should have the autotick-bot inspect them and offer some PRs (or alongside the version PRs?)

[jdblischak]

For the existing packages without a license file maybe we should have the autotick-bot inspect them and offer some PRs (or alongside the version PRs?)

I'm not sure we'd want to spend the CI time to only add the license file; however, it would be great if the autotick-bot could add the license file when updating the version.

[CJ-Wright]

xref: https://github.com/regro/cf-scripts/issues/51

[jdblischak]

My PR https://github.com/conda/conda-build/pull/2831 was just merged to be included in the next release of conda-build. I realize this was a quick turn-around, so please do comment sooner rather than later if you have thoughts on how this could be improved.

[jdblischak]

My previous PR had to be reverted due to the recent changes in the installation path of R on Windows. I've resubmitted a new PR. Feedback welcome!

[jdblischak]

My PR https://github.com/conda/conda-build/pull/3284 was included in the 3.17.2 release of conda-build. This means that the default CRAN skeleton now automatically adds the following licenses to R recipes:

• AGPL-3
• Artistic-2.0
• GPL-2
• GPL-3
• LGPL-2
• LGPL-2.1
• LGPL-3

These were the easiest to package because they are complete licenses shipped with r-base.