Guidance on R code licensing.

[MilesMcBain]

It's confession time. Deep breath

I have no idea what I am doing with open source licensing. My current practice is to use devtools::use_mit_license and hope for the best.

I realise I should educate myself but the topic is not all that accessible. Aside from Hadley's book I have not seen any other resource that makes recommendations about licensing choices in our specific context. The otherwise excellent rOpenSci Packaging Guide is mute on the subject, so I think there is scope for some discussion about this.

I am envisioning a simple guide that lays out the issues you need to consider if you are going to release R code in our software dev meets researcher world. Some I can think of now:

• Are there special considerations for research related code? e.g. OSS journal requirements, repository requirements.
• Are there commonly used dependencies (either R packages or c++ libs etc) that limit your license choices?
• Do suggests, imports, depends all create the same type of licensing interactions?
• Can publishing code or an algorithm in a journal affect the licenses you can choose?

So how is everyone else going with licenses? Safe choices? Gotchas?

[kbroman]

It's a great idea to add this topic to the ROpenSci packaging guide.

For material:

• I gave a lecture in my Tools for reproducible research course course that includes this: [slides | notes]

• There's also a section on software licenses in my R package primer.

[cboettig]

Great suggestion. I think there's a lot of scope to address some of the practical issues that arise with licensing that tend to be glossed over in the usual 'permissive vs copy-left' summary.

A few examples for discussion fodder from my own experience:

• Re Suggests/imports/depends: Great question on an issue I didn't see mentioned in the above guides. IANAL but fortunately I think this case is not so complicated: your license covers what you distribute. Since you're not usually distributing any part (source or binary) of these dependencies, you're not governed by their licenses.

• Note that this changes if you literally borrow code from them, or, say, include C++ code under another license. My understanding is that in that case, if said code is under GPL/copy-left license, then you need to follow suit; and if you want to use GPL, that code needs to be GPL-compatible. A case where this gets really subtle is when you distribute a bunch of material with all different licenses. The rmarkdown package from RStudio is a great example: it includes at least 7 different licenses from component parts which are included in the package (css and javascript stuff mostly), in addition to it's own license (GPL-3).

• On the copy-left side: GPLv3 vs GPLv2: It's easy to take the developer's view that v3 'patched some loopholes' of v2, so it must be better, right? Unfortunately, those changes (particularly regarding patent issues, rather than copyright issues) have made it incompatible with the IP policies of many Universities. In some cases, university faculty and sometimes graduate students are given more flexibility over IP than staff, but still, by choosing GPLv3 you may be preventing many academic developers from building derivatives on your software.

• Good question re journal requirements. Some journals (PLOS) and funders (NSF SI2 calls) explicitly ask for a license recognized by the [OSI}(https://opensource.org). CC0, though a GPL-compatible license recognized by CRAN, is not on this list. (IP units at commercial ventures also can only use open source software if it uses one of these licenses -- I had a request once from a researcher at Boeing to re-release a package I had under CC0 using an OSI license. Note that like GPLv3, CC0 failed to pass OSI approval (after lengthy debate) due to possible patent issues.

[cboettig]

Oh, just for reference on the "what's actually okay with universities might not be what you expect from Here's the internal license guidelines currently in place at University of California (not that they post this anywhere convenient):

[karthik]

@MilesMcBain 💯 to this idea. I'll contribute a tool to uncover license incompatibilities for dependencies that I've been working on.

[MilesMcBain]

Thanks all, this is some really useful information. I've already started linking some of my colleagues to this thread.

So I hit another interesting case that hasn't been discussed. One of the organisations I work for has a statement they want you to publish on any OS repo that basically says "all contributors relinquish all rights to code and documentation contributed to this repository."

It sounds a bit draconian, but in reality it seems like most people contributing code assume this anyway. Is contributed code automatically covered under the repo license or is this statement required to make that so? Without such a statement does the contributor have to make this explicit?

The other problem I have with the statement is I want the option to list external contributors in the DESCRIPTION file and I am not yet certain if their policy precludes this.

[jcheng5]

So I hit another interesting case that hasn't been discussed. One of the organisations I work for has a statement they want you to publish on any OS repo that basically says "all contributors relinquish all rights to code and documentation contributed to this repository."

This is IMHO necessary, and RStudio requires it on all of our repos (we ask people to sign a CLA before we accept all but the most trivial pull requests). It gives the project owners the ability to relicense (e.g. moving from GPL-3 to MIT) without having to get each and every contributor to sign off. Check out how difficult it was for Bootstrap to move from Apache 2 to MIT, it took almost two years because two contributors of trivial patches dug in for ideological reasons. (If you google for "bootstrap relicense" it should be the top hit, I'm not linking because I don't want to reverse-link from that thread to this one.)

The other problem I have with the statement is I want the option to list external contributors in the DESCRIPTION file and I am not yet certain if their policy precludes this.

We do this with our packages (at least my team does), with DESCRIPTION listing all the copyright holders of bundled dependencies listed as role="ctb" and their license statements in a LICENSE.note file. See https://github.com/rstudio/crosstalk for an example.

[hadley]

@karthik note that the package license only has to be compatible with the licenses of code you bundle (i.e. distribute), not code that you depend on.

[karthik]

@hadley Thanks! good to know.

[jimhester]

your license covers what you distribute. Since you're not usually distributing any part (source or binary) of these dependencies, you're not governed by their licenses.

package license only has to be compatible with the licenses of code you bundle (i.e. distribute), not code that you depend on.

Note that while I think this is the correct way to interpret the GPL / copy-left licenses not all organisations / lawyers agree. In particular Oracle's lawyers are taking the stance if a package has any GPL package dependencies it needs to be GPL as well.

This was the main motivation of my recent proposed change to the covr license from MIT to GPL (r-lib/covr#256), because Oracle wants to contribute some code to the package but will only do so if the code is GPL licensed.

How is this handled in other communities like python or javascript? I think they are in similar situations to R in this case?

The covr case is also a real world example of the issue relicensing issues @jcheng5 mentioned, I still cannot change the license as I have not heard back from two contributors.

[MilesMcBain]

Thanks @jcheng5 and @jimhester for the examples that motivate the contributor agreements. This seems to be a real sleeper issue that is best addressed early. Maybe some infon on CLAs and how to use them on Github could be part of the guide. This integration looks useful: https://github.com/integrations/cla-assistant

[ateucher]

This is a great and i think much-needed project! As discussed in #61, I think some notes in the proposed guide about licensing data distributed in packages would be warranted.

[mooresm]

A couple of relevant notes:

"Code needs to include the GNU General Public Licence (GPL), versions GPL-2 or GPL-3, or a GPL-compatible license for publication in JSS." https://www.jstatsoft.org/pages/view/authors

" by linking your code against R (as well as Rcpp), the combination is bound by
the GPL as well." http://dirk.eddelbuettel.com/code/rcpp/Rcpp-FAQ.pdf

[katrinleinweber]

Dear @karthik, is the "tool to uncover license incompatibilities for dependencies" already published? If so, on your GH profile, or integrated into another package? Thanks for any hints :-)

[karthik]

Hi katrinleinweber, This project didn't get much traction. It was built into libraries.io but that project is also now in maintenance mode. If you want to build something like this, please go with the idea!

[luispuerto]

This is a great topic, I really would love to know more about it.

Let's see if I've understood it. You're free to set any license in you package, if you don't include other package's code or you link agains it —dynamically or statically.

However, to have a dependency of a package doesn't mean that they are linked —dynamically or statically— since they can just interact in the user space.

Is this linking only happening when you are using C++ in your package and you LinkingTo other package?

Is that correct?

[CR-Mercado]

This is possibly a derivative or not-related enough question on R code licensing. Please feel free to move if so, but this is the only open issue i can find that seems to be close.

I have recently learned about quite popular r packages that are MIT licensed, but then their dependencies are commercially licensed.

An easy example to pick on is rhandsontable.
https://cran.r-project.org/web/packages/rhandsontable/

MIT + a 2015-2018 copyright (as required for any MIT licensed packages in R)
https://cran.r-project.org/web/packages/rhandsontable/LICENSE

The github notes that the package is a wrapper for handsontable.js which itself has an MIT license- but only for non-commercial use.

Going deep into the copyright holder- https://handsontable.com/docs/7.4.2/tutorial-licensing.html
it becomes clear that rhandsontable is a wrapper for the non-commercial handsontable.js, but that any production level use requires commercial licensing. There are no warnings, product keys, tokens, or easily available details to realize that all commercial uses of this package are technically IP theft.

Is there formal tests (or packages) available that ensure R users aren't trusting that CRAN or other mechanism will help them avoid IP theft when using an r package?

[noamross]

@CR-Mercado I think this thread, being from the '17 conference and not generally monitored, may not be a great place for a general discussion of this important subject. Our forum might be a good place: https://discuss.ropensci.org/

On the specific topic of rhandsontable I think you may be mistaken. There's been some discussion of this in the issues of the repository: https://github.com/jrowen/rhandsontable/issues?utf8=%E2%9C%93&q=license . It appears that prior to v7, handsontable was fully open licensed, so rhandsontable uses the older version and did not upgrade to the version with the more restrictive license.

[hadley]

To answer (some of these) questions, I've expanded the license chapter for the WIP R Packages: https://r-pkgs.org/license.html. I don't want to get too "in the weeds" but hopefully this now provides a bit more concrete advice for common situations.

[RMHogervorst]

Thank you so much for responding to this old thread @hadley ! The chapter looks really good.

[cboettig]

Thanks @hadley, this is great. At risk of getting too much in the weeds or sounding too paternalistic, would it be worth mentioning in that section that package authors might want to consult with the policies of their employer on licenses as well?

While we in the open source community always focus on the difference between "permissive" and "copyleft", imho tech transfer offices etc can see these things very differently (for instance, many universities object to GPL-3 but are fine with GPL-2, which is partly why R itself is dual-licensed). I think as programmers many of us just assume we should go with v3 if we want copyleft. Likewise, some guidance about choosing between very minimalistic permissive license like MIT vs more recent and longer permissive licenses like Apache v2 would be super helpful. Your experience in particular spanning both academia and industry and as major producer of open source software is particularly valuable to the rest of us.

(and one nit pick on the text. you state use_cc0_license() is "basically the same as MIT". While personally I agree with this, it's worth noting that the lawyers who make up the Open Source Initiative ruled that CC0 did not qualify as an Open Source License (if I understood correctly, it was mostly due to a clause stating that it did not imply or revoke patent rights, https://lists.opensource.org/pipermail/license-review/2012-March/thread.html, an issue which I think distinguishes many of the longer modern permissive licenses from their minimalistic ancestors). I've seen journals and grants stipulate that projects must use OSI-recognized licenses to count as open source, so while this may be very much in the reeds, it's also one of the easiest ways readers may run into trouble.

[hadley]

I think I'll add a short section on how licensing intersects with employment; as @maelle pointed out, I also need to mention that it's usually your employer that holds the copyright. I really don't want to get into the weeds of licensing within academic institutions.

For the general R community, I don't really think there are major implications of which license you choose — practically, I really do think it is more about expressing how you want your code to be treated, and I think it's very unlikely that picking Apache over MIT makes any real difference.

(I'll clarify my comment about CC0; I want to imply it has the same intent as MIT, not that it's exactly the same. It doesn't surprise me that someone doesn't consider it to be open source, as it's specifically designed for non-code creative work.)