Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, ? Kevin
[R-pkg-devel] Licenses
13 messages · Kevin Coombes, Marc Schwartz, Hugh Parsonage +3 more
On 22/10/2020 10:21 a.m., Kevin R. Coombes wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE?
flowCore is a Bioconductor package, not on CRAN. Are you intending to send yours there, or to CRAN? I suspect Bioconductor is happy with the Hutch's license. Duncan Murdoch
On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com> wrote: On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on commercial use. These include some Creative Commons Non-Commercial use variants and the ACM license. Is the license DB file out of date, or is there an apparent conflict with the CRAN policy that I quoted above? Anyone with an ability to comment? Regards, Marc
On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com> wrote: On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on commercial use. These include some Creative Commons Non-Commercial use variants and the ACM license. Is the license DB file out of date, or is there an apparent conflict with the CRAN policy that I quoted above? Anyone with an ability to comment?
Presumably CRAN would not accept the non-FOSS licenses that are listed in license.db, but R could still do computations on them, as described in ?library in the "Licenses" section. Duncan Murdoch
On Oct 22, 2020, at 12:12 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com> wrote: On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on commercial use. These include some Creative Commons Non-Commercial use variants and the ACM license. Is the license DB file out of date, or is there an apparent conflict with the CRAN policy that I quoted above? Anyone with an ability to comment?
Presumably CRAN would not accept the non-FOSS licenses that are listed in license.db, but R could still do computations on them, as described in ?library in the "Licenses" section. Duncan Murdoch
Duncan, That is a reasonable distinction. However, upon searching CRAN with available.packages(), I came up with a list of packages that do include Non-Commercial restrictions, including CC BY-NC* and ACM licenses. There may be others that I missed visually scanning the output. There also appear to be some conflicts/inconsistencies with the 'License_restricts_use' field entry and the 'License' field in some cases, where, for example, most that have "CC BY-NC-SA 4.0" as the license, have "NA" as the entry for restricted use, rather than "yes". I am not going to list them here, as I don't want to pick on any particular package, but this does seem to point to an inconsistency between packages that are hosted on CRAN and the articulated policy... Regards, Marc
It?s necessary but not sufficient to use a licence from license.db On Fri, 23 Oct 2020 at 3:12 am, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com>
wrote:
On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <
kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about
licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix.
My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred
Hutchinson Cancer Center that prohibits commercial use.
I tried using the same license as flowCore, but still get the NOTE.
Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE?
Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably,
they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore.
If you want your package to be on CRAN, those restrictions on users are
not allowed by CRAN's policy:
https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in
?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage."
Thus, you would seem to need to make a decision on hosting your package
on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use.
Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on
commercial use.
These include some Creative Commons Non-Commercial use variants and the
ACM license.
Is the license DB file out of date, or is there an apparent conflict
with the CRAN policy that I quoted above?
Anyone with an ability to comment?
Presumably CRAN would not accept the non-FOSS licenses that are listed in license.db, but R could still do computations on them, as described in ?library in the "Licenses" section. Duncan Murdoch
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
On Oct 22, 2020, at 12:12 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com> wrote: On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on commercial use. These include some Creative Commons Non-Commercial use variants and the ACM license. Is the license DB file out of date, or is there an apparent conflict with the CRAN policy that I quoted above? Anyone with an ability to comment?
Presumably CRAN would not accept the non-FOSS licenses that are listed in license.db, but R could still do computations on them, as described in ?library in the "Licenses" section. Duncan Murdoch
Duncan, That is a reasonable distinction. However, upon searching CRAN with available.packages(), I came up with a list of packages that do include Non-Commercial restrictions, including CC BY-NC* and ACM licenses. There may be others that I missed visually scanning the output. There also appear to be some conflicts/inconsistencies with the 'License_restricts_use' field entry and the 'License' field in some cases, where, for example, most that have "CC BY-NC-SA 4.0" as the license, have "NA" as the entry for restricted use, rather than "yes". I am not going to list them here, as I don't want to pick on any particular package, but this does seem to point to an inconsistency between packages that are hosted on CRAN and the articulated policy...
Perhaps those packages were accepted before this became a policy, and now that others depend on them, it would be too disruptive to remove them, and users are warned via the 'License_restricts_use' field entry. Why does it sometimes contain errors? That I don't know, other than blaming it on Murphy's Law. Duncan Murdoch
On Oct 22, 2020, at 3:47 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
On Oct 22, 2020, at 12:12 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz <marc_schwartz at me.com> wrote: On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <kevin.r.coombes at gmail.com> wrote:
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin
Hi Kevin, I have not looked at BioC's licensing requirements, but presumably, they are ok with the non-commercial use restrictions placed on users of cytolib, thus also on flowCore. If you want your package to be on CRAN, those restrictions on users are not allowed by CRAN's policy: https://cran.r-project.org/web/packages/policies.html "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." Thus, you would seem to need to make a decision on hosting your package on CRAN, but without the need to import from flowCore/cytolib, or consider hosting your package on BioC, with the attendant restrictions on commercial use. Regards, Marc Schwartz
Well.... Now that I look at: https://svn.r-project.org/R/trunk/share/licenses/license.db there are a few licenses listed there that do place restrictions on commercial use. These include some Creative Commons Non-Commercial use variants and the ACM license. Is the license DB file out of date, or is there an apparent conflict with the CRAN policy that I quoted above? Anyone with an ability to comment?
Presumably CRAN would not accept the non-FOSS licenses that are listed in license.db, but R could still do computations on them, as described in ?library in the "Licenses" section. Duncan Murdoch
Duncan, That is a reasonable distinction. However, upon searching CRAN with available.packages(), I came up with a list of packages that do include Non-Commercial restrictions, including CC BY-NC* and ACM licenses. There may be others that I missed visually scanning the output. There also appear to be some conflicts/inconsistencies with the 'License_restricts_use' field entry and the 'License' field in some cases, where, for example, most that have "CC BY-NC-SA 4.0" as the license, have "NA" as the entry for restricted use, rather than "yes". I am not going to list them here, as I don't want to pick on any particular package, but this does seem to point to an inconsistency between packages that are hosted on CRAN and the articulated policy...
Perhaps those packages were accepted before this became a policy, and now that others depend on them, it would be too disruptive to remove them, and users are warned via the 'License_restricts_use' field entry. Why does it sometimes contain errors? That I don't know, other than blaming it on Murphy's Law. Duncan Murdoch
Hi Duncan, That seems a reasonable scenario. Right now, the interpretation, without further clarification from CRAN, would be, it is ok for a package to be on CRAN with license based usage restrictions included (e.g. for non-commercial use), but a package on CRAN, irrespective of it's own license, cannot "interact" with other packages that do have restrictions...which seems inconsistent. Back to the original question by Kevin, this would now seem to be even more confusing... Kevin, you may need to send an e-mail to CRAN-submissions at R-project.org <mailto:CRAN-submissions at R-project.org> on the issue with your package, to get clarification on the current policy and recommendations for resolution. You might even want to include this thread (but don't cc: this list), so that they are aware, if not already, of the issues raised here. If you do, please post back with an update. Regards, Marc
Hi all, My two cents are below Marc's summary here:
On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
Right now, the interpretation, without further clarification from CRAN, would be, it is ok for a package to be on CRAN with license based usage restrictions included (e.g. for non-commercial use), but a package on CRAN, irrespective of it's own license, cannot "interact" with other packages that do have restrictions...which seems inconsistent.
It depends a bit what is meant by "interact". Years ago `spatstat` used `gpclib` with a non-commercial license to do polygonal operations. The solution was to list `gpclib` in `Suggests` and require the user to make an active choice to use this piece of software with a warning about non-commercial use. I find this to be an OK solution in lack of completely free alternatives. These days `gpclib` is still on CRAN and only has reverse `Suggests` and `Enhances`, so that seems fairly consistent. In the long run this was unsatisfatory and our specific problem was solved by Adrian Baddeley by making the `polyclip` package. Kind regards, Ege
I do not want to make many general comments about licenses in public, as this is a very difficult matter and I am not a lawyer. But let me cite from the CRAN policies: "Packages with licenses not listed at https://svn.r-project.org/R/trunk/share/licenses/license.db will generally not be accepted. " Further, I see in the discussions that you talked about depending on a software with a non-FOSS license. The CRAN team's point of view, for short, is: A package with a FOSS license cannot strictly depend on a package/software that is non-FOSS. Obviously, the FOSS package cannot be used under its own license conditions in that case. Best, Uwe Ligges
On 23.10.2020 14:25, Ege Rubak wrote:
Hi all, My two cents are below Marc's summary here: On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
Right now, the interpretation, without further clarification from CRAN, would be, it is ok for a package to be on CRAN with license based usage restrictions included (e.g. for non-commercial use), but a package on CRAN, irrespective of it's own license, cannot "interact" with other packages that do have restrictions...which seems inconsistent.
It depends a bit what is meant by "interact". Years ago `spatstat` used `gpclib` with a non-commercial license to do polygonal operations. The solution was to list `gpclib` in `Suggests` and require the user to make an active choice to use this piece of software with a warning about non-commercial use. I find this to be an OK solution in lack of completely free alternatives. These days `gpclib` is still on CRAN and only has reverse `Suggests` and `Enhances`, so that seems fairly consistent. In the long run this was unsatisfatory and our specific problem was solved by Adrian Baddeley by making the `polyclip` package. Kind regards, Ege
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
On Oct 23, 2020, at 8:25 AM, Ege Rubak <rubak at math.aau.dk> wrote: Hi all, My two cents are below Marc's summary here: On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
Right now, the interpretation, without further clarification from CRAN, would be, it is ok for a package to be on CRAN with license based usage restrictions included (e.g. for non-commercial use), but a package on CRAN, irrespective of it's own license, cannot "interact" with other packages that do have restrictions...which seems inconsistent.
It depends a bit what is meant by "interact". Years ago `spatstat` used `gpclib` with a non-commercial license to do polygonal operations. The solution was to list `gpclib` in `Suggests` and require the user to make an active choice to use this piece of software with a warning about non-commercial use. I find this to be an OK solution in lack of completely free alternatives. These days `gpclib` is still on CRAN and only has reverse `Suggests` and `Enhances`, so that seems fairly consistent. In the long run this was unsatisfatory and our specific problem was solved by Adrian Baddeley by making the `polyclip` package. Kind regards, Ege
Hi Ege, The use of "Suggests" may be the relevant difference here. My use of the word "interact" was focused on the text in the CRAN policy that I quoted in my initial reply: "Such packages are not permitted to require (e.g., by specifying in ?Depends?, ?Imports? or ?LinkingTo? fields) directly or indirectly a package or external software which restricts users or usage." As Duncan noted in his reply, there may be time based differences that are relevant here, if the CRAN policy had changed at some point, and there was, in effect, a grand-fathering of older packages that perhaps would not be accepted today under the current policy. Regards, Marc
Hi Uwe, Thanks for taking the time to reply. Would you be willing to clarify/confirm the current situation regarding the hosting of non-FOSS packages on CRAN, such as those with ACM or Creative Commons license variants that have non-commercial use restrictions? These are presently included in the license.db file. Are these on CRAN now because they are acceptable under the current policy, or are they on CRAN now, as Duncan posited, because they were acceptable under older policies and it would be disruptive to remove them now? Thanks, Marc
On Oct 23, 2020, at 8:57 AM, Uwe Ligges <ligges at statistik.tu-dortmund.de> wrote: I do not want to make many general comments about licenses in public, as this is a very difficult matter and I am not a lawyer. But let me cite from the CRAN policies: "Packages with licenses not listed at https://svn.r-project.org/R/trunk/share/licenses/license.db will generally not be accepted. " Further, I see in the discussions that you talked about depending on a software with a non-FOSS license. The CRAN team's point of view, for short, is: A package with a FOSS license cannot strictly depend on a package/software that is non-FOSS. Obviously, the FOSS package cannot be used under its own license conditions in that case. Best, Uwe Ligges On 23.10.2020 14:25, Ege Rubak wrote:
Hi all, My two cents are below Marc's summary here: On Thu, 2020-10-22 at 20:33 -0400, Marc Schwartz wrote:
Right now, the interpretation, without further clarification from CRAN, would be, it is ok for a package to be on CRAN with license based usage restrictions included (e.g. for non-commercial use), but a package on CRAN, irrespective of it's own license, cannot "interact" with other packages that do have restrictions...which seems inconsistent.
It depends a bit what is meant by "interact". Years ago `spatstat` used `gpclib` with a non-commercial license to do polygonal operations. The solution was to list `gpclib` in `Suggests` and require the user to make an active choice to use this piece of software with a warning about non-commercial use. I find this to be an OK solution in lack of completely free alternatives. These days `gpclib` is still on CRAN and only has reverse `Suggests` and `Enhances`, so that seems fairly consistent. In the long run this was unsatisfatory and our specific problem was solved by Adrian Baddeley by making the `polyclip` package. Kind regards, Ege
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel