Clarification for acceptable licenses

[jhollist]

@noamross, @karthik, @sckott,

Got a question about licensing for rOpenSci packages.

There are two spots in the guidelines that mention licenses editor_template.md and issue_template.md.

In editor_template.md it states: License: The package has a CRAN or OSI accepted license.

In issue_template.md it states: has a CRAN and OSI accepted license.

Do licenses need to be acceptable by both or either? An example that directly impacts me is CC0 which is acceptable for CRAN and not for OSI (see here for more on this issue: https://github.com/openjournals/joss/issues/179).

If it is both CRAN and OSI then (most) federal employees will not be allowed to submit packages to rOpenSci. If it is either, then should have no problems.

[sckott]

Definitely CRAN accepted, but perhaps we could change to ideally OSI accepted ?

I know the USGS folks wanted to submit to ropensci, but couldn't transfer the repo outside of their github org. I don't know if that would be an issue for your agency?

I think we have talked about allowing ropensci repos to not actually live in one of our org accounts, maybe indicating with a badge - for cases where repo can not be transferred.

[jhollist]

I think having the "ideally OSI" language is fine.

In my discussion with JOSS about this the crux of it was that it is very explicitly a journal for Open Source Software and that OSI is involved. Allowing CC0 would have been inconsistent as it is not OSI approved. I actually have a call this PM with an EPA lawyer to discuss this...

As for transferring the repo, I hadn't thought about that. Might be an issue for us to, but no one in EPA has thought about that yet. Maybe a ask forgiveness, not permission thing for me.

[sckott]

Okay, makes sense that JOSS would want OSI approved.

From what I heard, sounds like gov. agencies really like CC0 as it's public domain - wonder if lawyer will be okay with MIT or something else that is also OSI approved

[jhollist]

CC0 has emerged as a standard in gov (18f, USGS, EPA ...) NASA is the interesting one as they officially have "software release authority" and thus use Apache 2.0 (I think). In any event, I think a lot of this will be hashed out in the next 6 months or so since the Federal Open Source Policy explicitly mentions forthcoming guidance on licensing. Until that happens thought, we (most feds) are stuck with CC0 (better than what we had before, btw).

[mbjones]

@sckott and @jhollist we had this discussion early on about ROpenSci packages living outside of the ropensci github tree a while ago, and we seemingly had approval to keep the dataone package over in 'DataONEorg/rdataone'. I think one of the problems with transferring packages is that transfers administrative control of the package repo, which best lives with the package maintainers who have to deal with it day to day. One of our packages (datapack) lives in the ropensci tree, and I'd have to say its been frustrating to not have ownership rights on the repo as the principal maintainer.

If you mainly want the transfer so that ropensci gets some form of credit for their services, then that might be accomplished by: 1) ensuring the ropensci banner/logo is in the package readme and is credited, and 2) forking the original repo into the ropensci tree and keep it synced with upstream. That way, it shows up in your tree, but is owned and maintained by the package maintainers in their tree. Would that work for some cases?

[jsta]

We did the reverse of your option 2 for dbhydroR. Transferred to ropensci but then created a fork of the transferred repo in the previous location.

[noamross]

@jhollist I'm doing a general refresh of packaging guidelines and submission documentation. Any updates or should we assume that CC0 will be required for many government packages for a while?

[jhollist]

@noamross Not much new to report. I have had some discussion with our attorneys and IM office and there seems to be a glimmer of a hope for OSI licenses. Haven't received a final word yet. I'll ping again this week.

[jhollist]

Bumping this. Any additional thoughts on CC0? I am contemplating submitting htpts://github.com/usepa/elevatr but have not received any movement on approval for additional licenses (in spite of multiple meetings/emails/etc/...).

I'd also need to think how the transferring ownership would work. I currently maintain all my repos on my account (so that I have admin control) and mirror them on the usepa org account. Not sure if I can transfer my repos completely away from usepa or not.

Anyway, these are two separate issues, I think. Most interested in knowing if CC0 allowed for rOpenSci or not.

Thanks!

[sckott]

i think we should allow CC0 - it may not be OSI accepted, but I think that's fine given that gov't has an important use case in that they have to put work into public domain

what do other @ropensci/editors think?

[maelle]

Sounds good, I have no strong opinion.

[kbenoit]

There are interesting and complex issues with the GPL license, namely that software that uses them - for instance anything that uses Rcpp which is GPL - must also be GPL. Not every package conforms to this, for instance dplyr is MIT even though it incorporates packages that are GPL (including Rcpp), but technically I think this violates the GPL.

I personally prefer MIT but as I understand it for my own packages, if they use GPL components then they must also be GPL.

[noamross]

@kbenoit My (limited) understanding is that software incorporating GPL must be GPL, but software linking to GPL software does not. Since dplyr does not contain the Rcpp code, but merely lists it as a dependency, it's in the clear. Similarly, I think a CC-0 package can link to a GPL one without problems.

I think we should narrow the carve-out a bit more: "OSI required, exemptions may be provided for packages produced by government agencies whose work must be CC-0 for legal reasons. Contact editors via a pre-submission inquiry if this may be needed. Note such packages may not be submitted to JOSS." Practically, this may not make much difference, but I think the gov't case is a special one and want to avoid growing

@jhollist, thanks for keeping up the good fight in this!

[mbjones]

Given that ROpenSci is allowing any OSI license, I think CC-0 should be just as acceptable, because through its grant into the public domain it grants more rights than all of the other OSI licenses. Whether the GPL viral provisions apply is an orthogonal issue -- if someone can use MIT or Apache for an ROpenSci package, they should be able to use CC-0 too. So @noamross, I don't understand why you'd want to restrict its use and make it so much harder to adopt.

[sckott]

i agree with @mbjones

[jhollist]

I agree mostly with @mbjones

Only reason I can see to limit it somewhat is the link with JOSS. JOSS does not accept CC-0 and we should, at a minimum, call this out like @noamross did above so that package authors who want to submit to JOSS steer clear of CC-0.

[karthik]

Thanks very much for this discussion. Since the onboarding repo is primarily meant as a tracker for package submissions and review, please continue this discussion over at Onboarding meta (https://github.com/ropensci/onboarding-meta) if you believe this is not already resolved here. In the interest of keeping this issue tracker clean, I am closing this repo. 🙏