12  Licensing

12.1 Introduction

The goal of this chapter is to give you the basic tools to manage licensing for your R package. Software licensing is a large and complicated field, made particularly complex because it lies at the intersection of programming and law. Fortunately, you don’t need to be an expert to do the right thing: respecting how an author wants their code to be treated as indicated by the license they’ve picked.

To understand the author’s wishes, it’s useful to understand the two major camps of open source licenses:

  • Permissive licenses are very easy going. Code with a permissive license can be freely copied, modified, and published, and the only restriction is that the license must be preserved. The MIT and Apache licenses are the most common modern permissive licenses; older permissive licenses include the various forms of the BSD license.

  • Copyleft licenses are stricter. The most common copyleft license is the GPL which allows you to freely copy and modify the code for personal use, but if you publish modified versions or bundle with other code, the modified version or complete bundle must also be licensed with the GPL.

To get a high-level view of the open source licensing space, and the details of individual licenses, I highly recommend https://choosealicense.com, which I’ve used in the links above.

When you look across all programming languages, permissive licenses are the most common. For example, a 2015 survey of GitHub repositories found that ~55% used a permissive license and ~20% used a copyleft license. The R community is a little different: as of 2020, my analysis (following Sean Kross’s blog post) found that ~70% of CRAN packages use a copyleft license and ~15% use a permissive license.

This chapter will start with licensing your own code, and then cover the most important details of receiving code from other people (e.g. in a PR) and bundling other people’s code into your package. Note that simply using a package or R itself doesn’t require that you comply with the license; this is why you can write proprietary R code and why R packages can have any license you choose.

For more details about licensing R packages, I recommend Licensing R by Colin Fay.

(If you run the code in this chapter, please make sure that you’re using usethis 2.0.0 or greater; writing this chapter prompted a number of changes in the package.)

12.2 Code you write

We’ll start by talking about code that you write, and how to license it to make clear how you want people to treat it. In brief:

  • If you want a permissive license so people can use your code with minimal restrictions, choose the MIT license with use_mit_license().

  • If you want a copyleft license so that all derivatives and bundles of your code are also open source, choose the GPLv3 license with use_gpl_license().

  • If your package primarily contains data, not code, and you want minimal restrictions, choose the CC0 license with use_cc0_license(). Or if you want to require attribution when your data is used, choose the CC BY license by calling use_ccby_license().

  • If you don’t want to make your code open source call use_proprietary_license(). Such packages can not be distributed by CRAN.

We’ll come back to more details and present a few other licenses in Section 12.3.2.

It’s important to use a license because if you don’t the default copyright laws apply which mean that no one is allowed to make a copy of your code without your express permission.

(It is possible to license a CRAN package with a non-open source license like the ACM license but we don’t recommend it.)

12.4 Code given to you

Many packages include code not written by the author. There are two main ways this happens: other people might choose to contribute to your package using a pull request or similar, or you might find some code and choose to bundle it. This section will discuss code that others give to you, and the next section will discuss code that you bundle.

When someone contributes code to your package using a pull request or similar, you can assume that the author is happy for their code to use your license. This is explicit in the GitHub terms of service, but is generally considered to be true regardless of how the code is contributed3.

Note, however, that the author retains copyright of their code, unless you use a “contributor license agreement” or CLA for short. The primary advantage of a CLA is that it makes the copyright of the code very simple, and hence makes it easy to relicense code if needed. This is most important for dual open-source/commercial projects because it easily allows for dual licensing where the code is made available to the world with copyleft license, and made available to paying customers with a different, more permissive, license.

It’s also important to acknowledge the contribution, and it’s good practice to be generous with thanks and attribution. In the tidyverse, we ask that all code contributors include a bullet in NEWS.md with their GitHub username, and we thank all contributors in release announcements. We only add core developers4 to the DESCRIPTION file; but some projects choose to add all contributors no matter how small.

12.5 Code you bundle

There are three common reasons that you might choose to bundle code written by someone else:

  • You’re including someone else’s CSS or JS library in order to create a useful and attractive web page or HTML widgets.

  • You’re providing an R wrapper for a simple C or C++ library. (For complex C/C++ libraries, you don’t usually bundle the code in your package, but instead link to a copy installed elsewhere on the system).

  • You’ve copied a small amount of R code from another package to avoid taking a dependency. Generally, taking a dependency on another package is the right thing to do because you don’t need to worry about licensing, and you’ll automatically get bug fixes. But sometimes you only need a very small amount of code from a big package, and copying and pasting it into your package is the right thing to do.

Note that R is rather different to languages like C where the most common way that code is bundled together is by compiling it into a single executable.

12.5.1 License compatibility

Before you bundle someone else’s code into your package, you need to first check that the bundled license is compatible with your license. When distributing code, you can add additional restrictions, but you can not remove restrictions, which means that license compatibility is not symmetric. For example, you can bundle MIT licensed code in a GPL licensed package, but you can not bundle GPL licensed code in an MIT licensed package.

There are five main cases to consider:

  • If your license and their license are the same: it’s OK to bundle.

  • If their license is MIT or BSD, it’s OK to bundle.

  • If their code has a copyleft license and your code has a permissive license, you can’t bundle their code. You’ll need to consider an alternative approach, either looking for code with a more permissive license, or putting the external code in a separate package.

  • If the code comes from Stack Overflow, it’s licensed5 with the Creative Common CC BY-SA license, which is only compatible with GPLv36 . This means that you need to take extra care when using Stack Overflow code in open source packages . Learn more at https://empirical-software.engineering/blog/so-snippets-in-gh-projects.

  • Otherwise, you’ll need to do a little research. Wikipedia has a useful diagram and Google is your friend. It’s important to note that different versions of the same license are not necessarily compatible, e.g. GPLv2 and GPLv3 are not compatible.

If your package isn’t open source, things are more complicated. Permissive licenses are still easy, and copyleft licenses generally don’t restrict use as long as you don’t distribute the package outside your company. But this is a complex issue and opinions differ, and should check with your legal department first.

12.5.2 How to include

Once you’ve determined that the licenses are compatible, you can bring the code in your package. When doing so, you need to preserve all existing license and copyright statements, and make it as easy as possible for future readers to understanding the licensing situation:

  • If you’re including a fragment of another project, generally best to put in its own file and ensure that file has copyright statements and license description at the top.

  • If you’re including multiple files, put in a directory, and put a LICENSE file in that directory.

You also need to include some standard metadata in Authors@R. You should use role = "cph" to declare that the author is a copyright holder, with a comment describing what they’re the author of.

If you’re submitting to CRAN and the bundled code has a different (but compatible) license, you also need to include a LICENSE.note file that describes the overall license of the package, and the specific licenses of each individual component. For example, the diffviewer package bundles six javascript libraries all of which use a permissive license. The DESCRIPTION lists all copyright holders, and the LICENSE.note describes their licenses. (Other packages use other techniques, but I think this is the simplest approach that will fly with CRAN.)

  1. At least in the US; you’ll need to double check with your local laws.↩︎

  2. Very simple contributions like typo fixes are generally not protected by copyright because they’re not creative works. But even a single sentence can be considered a creative work, so err on the side of safety, and if you have any doubts leave the contributor in.↩︎

  3. Some particularly risk averse organisations require contributors to provide a developer certificate of origin, but this is relatively rare in general, and I haven’t seen it in the R community.↩︎

  4. i.e. people responsible for on-going development. This is best made explicit in the ggplot2 governance document, GOVERNANCE.md.↩︎

  5. https://stackoverflow.com/help/licensing↩︎

  6. https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/↩︎