[R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-02 Thread Ben Bolker 



  A collaborator is arguing that it's a good idea to license one small 
component of a package under the MIT license, while the rest of it 
remains GPL >=2.


  Suppose this is feasible.  How do I specify the license?  As far as I 
can tell from 
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing 
the DESCRIPTION file should have


License: file LICENSE
License_is_FOSS: yes
License_restricts_use: no

  But I can't figure out what should go in the LICENSE file. The one 
file that contains the MIT-licensed components contains the relevant 
license text in its body.


License: GPL (>=2) | MIT + file LICENSE

doesn't seem right, because these are not *alternative* licenses.  Would 
"GPL (>=2) + file LICENSE" be OK? We could explain the situation in 
LICENSE.note (WRE says "To include comments about the licensing rather 
than the body of a license, use a file named something like 
LICENSE.note. ")


  Could file LICENSE contain

The code in this package is licensed under GPL >=2 (see 
https://www.r-project.org/Licenses/GPL-2, 
https://www.r-project.org/Licenses/GPL-3, except for , which 
is under the MIT license (see ).


?

 Happy for advice or pointers to other packages that have successfully 
done something similar.


Looks like igraphdata may have heterogeneous licensing? 
https://cran.r-project.org/web/packages/igraphdata/index.html



Related: 
https://stackoverflow.com/questions/4314708/if-an-r-packages-licence-x-is-do-all-the-content-in-that-package-have-to-be-li


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

Re: [R-pkg-devel] Non-mainstream repository dependence for CRAN vignette building

2020-10-02 Thread Dirk Eddelbuettel 

On 1 October 2020 at 19:13, Max Turgeon wrote:
| Hi Nicholas,
| 
| I see two potential solutions, maybe other people will suggest different ones:
| 
|   1. You can make the evaluation of the whole vignette dependent on the data 
packages being available. Here's an example from one of my packages: 
https://github.com/sahirbhatnagar/casebase/blob/3403e0451ba5f0bf122924729ba85a904cf16082/vignettes/smoothHazard.Rmd#L22-L27

For reference that is also outlined in the Anderson + Eddelbuettel, 2017, R
Journal article on 'hosting data packages via drat' which shows how to use
(optional) data packages via Additional_repositories.

https://journal.r-project.org/archive/2017/RJ-2017-026/index.html

Dirk

|   2. You create the vignette on your machine and add it to the package as a 
"static vignette". Here's a blog post on how to do it (it's also been discussed 
on this list before, have a look at the archive): 
http://www.markvanderloo.eu/yaRb/2019/01/11/add-a-static-pdf-vignette-to-an-r-package/
| 
| Each approach has its pros and cons. In the first solution, a potential issue 
is that the complete vignettes may rarely be available on a user's machine, 
unless they install the data package first and build from source. In the second 
solution, there's more maintenance for you.
| 
| Best,
| 
| 
| Max Turgeon
| Assistant Professor
| Department of Statistics
| Department of Computer Science
| University of Manitoba
| maxturgeon.ca
| 
| 
| 
| From: R-package-devel  on behalf of 
Bennett Nicolas 
| Sent: Thursday, October 1, 2020 1:46 PM
| To: r-package-devel@r-project.org 
| Subject: [R-pkg-devel] Non-mainstream repository dependence for CRAN vignette 
building
| 
| 
| Caution: This message was sent from outside the University of Manitoba.
| 
| 
| Dear list
| 
| I�m in the process of submitting a package to CRAN that uses a non-mainstream 
repository for several data packages that are too large for CRAN (~50 MB in 
total) and therefore live in a drat repository hosted by gh. Data from these 
packages is used during vignette building and unsurprisingly, CRAN checks throw 
a �re-building of vignette� warning.
| 
| 1. Is such a warning acceptable or is vignette re-build required to run 
through?
| 2. Is it allowed to create a set-up that essentially runs 
`install.packages()` during CRAN checks to make the non-mainstream repo 
packages available?
| 3. Are there any go-to solutions for such a scenario? I tried knitr caching, 
but was unsuccessful, to get that to work. What I�m currently doing is masking 
the package function that loads data and supplying the required data with the 
package. But this unnecessarily inflates package size (and adds complexity), as 
the data is already conveniently and separately available as an R package.
| 
| Best,
| Nicolas
| __
| 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

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-02 Thread Hadley Wickham 
On Fri, Oct 2, 2020 at 1:51 PM Ben Bolker  wrote:

>
>A collaborator is arguing that it's a good idea to license one small
> component of a package under the MIT license, while the rest of it
> remains GPL >=2.
>
>Suppose this is feasible.  How do I specify the license?  As far as I
> can tell from
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing
> the DESCRIPTION file should have
>
> License: file LICENSE
> License_is_FOSS: yes
> License_restricts_use: no
>
>But I can't figure out what should go in the LICENSE file. The one
> file that contains the MIT-licensed components contains the relevant
> license text in its body.
>
> License: GPL (>=2) | MIT + file LICENSE
>
> doesn't seem right, because these are not *alternative* licenses.  Would
> "GPL (>=2) + file LICENSE" be OK? We could explain the situation in
> LICENSE.note (WRE says "To include comments about the licensing rather
> than the body of a license, use a file named something like
> LICENSE.note. ")
>
>Could file LICENSE contain
>
> The code in this package is licensed under GPL >=2 (see
> https://www.r-project.org/Licenses/GPL-2,
> https://www.r-project.org/Licenses/GPL-3, except for , which
> is under the MIT license (see ).
> ?
>

I have some recommendations at
https://r-pkgs.org/license.html#code-you-bundle, but in brief use License:
GPL (>= 2) and then explain in LICENSE.note which components have more
liberal licenses.

Hadley

-- 
http://hadley.nz

[[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] best practices for handling a mixed-licensed package

2020-10-02 Thread Jeff Newmiller 
Hadley offers what you _can_ do, but if you want clarity in the minds of 
_users_ I would beg you to split the code into two packages. People will likely 
either be afraid of the GPL bogey man and refrain from utilizing your MIT code 
as permitted or fail to honor the GPL terms correctly if both are in the same 
package.

On October 2, 2020 1:16:36 PM PDT, Hadley Wickham  wrote:
>On Fri, Oct 2, 2020 at 1:51 PM Ben Bolker  wrote:
>
>>
>>A collaborator is arguing that it's a good idea to license one
>small
>> component of a package under the MIT license, while the rest of it
>> remains GPL >=2.
>>
>>Suppose this is feasible.  How do I specify the license?  As far
>as I
>> can tell from
>>
>https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing
>> the DESCRIPTION file should have
>>
>> License: file LICENSE
>> License_is_FOSS: yes
>> License_restricts_use: no
>>
>>But I can't figure out what should go in the LICENSE file. The one
>> file that contains the MIT-licensed components contains the relevant
>> license text in its body.
>>
>> License: GPL (>=2) | MIT + file LICENSE
>>
>> doesn't seem right, because these are not *alternative* licenses. 
>Would
>> "GPL (>=2) + file LICENSE" be OK? We could explain the situation in
>> LICENSE.note (WRE says "To include comments about the licensing
>rather
>> than the body of a license, use a file named something like
>> LICENSE.note. ")
>>
>>Could file LICENSE contain
>>
>> The code in this package is licensed under GPL >=2 (see
>> https://www.r-project.org/Licenses/GPL-2,
>> https://www.r-project.org/Licenses/GPL-3, except for ,
>which
>> is under the MIT license (see ).
>> ?
>>
>
>I have some recommendations at
>https://r-pkgs.org/license.html#code-you-bundle, but in brief use
>License:
>GPL (>= 2) and then explain in LICENSE.note which components have more
>liberal licenses.
>
>Hadley

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] best practices for handling a mixed-licensed package

2020-10-02 Thread Dirk Eddelbuettel 


On 2 October 2020 at 14:44, Jeff Newmiller wrote:
| if you want clarity in the minds of _users_ I would beg you to split the code 
into two packages. People will likely either be afraid of the GPL bogey man and 
refrain from utilizing your MIT code as permitted or fail to honor the GPL 
terms correctly if both are in the same package.

Have you read R's own doc/COPYRIGHTS ?

   https://github.com/wch/r-source/blob/trunk/doc/COPYRIGHTS

In short the opposite of what you just suggest. 

Also, labels such as "more liberal" or "permissive" or "bogey man" are not
exactly unambiguous.  Different people can and do have different views here.
I would suggest using simpler terms such as "different". What matters is that
the licenses permit open source use while ensuring they are compatible which
is generally the case these days.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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