Re: [R-pkg-devel] Licenses

2020-10-23 Thread Marc Schwartz 
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  
> 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-23 Thread Marc Schwartz 


> On Oct 23, 2020, at 8:25 AM, 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


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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-23 Thread Uwe Ligges 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-23 Thread Ege Rubak 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Marc Schwartz 
On Oct 22, 2020, at 3:47 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  
>>> wrote:
>>> 
>>> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
> 
> On Oct 22, 2020, at 10:21 AM, 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?
>> 
>> 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-submissi...@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


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Marc Schwartz 


> On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  wrote:
> 
> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
>>> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
>>> 
>>> On Oct 22, 2020, at 10:21 AM, 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?
 
 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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Marc Schwartz 



> On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:
> 
> On Oct 22, 2020, at 10:21 AM, 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?
>> 
>> 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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Duncan Murdoch 

On 22/10/2020 12:56 p.m., Marc Schwartz wrote:



On Oct 22, 2020, at 12:12 PM, Duncan Murdoch  wrote:

On 22/10/2020 11:55 a.m., Marc Schwartz wrote:

On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:

On Oct 22, 2020, at 10:21 AM, 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?

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Marc Schwartz 
On Oct 22, 2020, at 10:21 AM, 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?
> 
> 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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Hugh Parsonage 
It’s necessary but not sufficient to use a licence from license.db

On Fri, 23 Oct 2020 at 3:12 am, Duncan Murdoch 
wrote:

> On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
> >
> >
> >> On Oct 22, 2020, at 11:19 AM, Marc Schwartz 
> wrote:
> >>
> >> On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes <
> kevin.r.coom...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Duncan Murdoch 

On 22/10/2020 11:55 a.m., Marc Schwartz wrote:




On Oct 22, 2020, at 11:19 AM, Marc Schwartz  wrote:

On Oct 22, 2020, at 10:21 AM, 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?

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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Licenses

2020-10-22 Thread Duncan Murdoch 

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Licenses

2020-10-22 Thread Kevin R. Coombes 

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-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel