Notes on re-licensing

open source

Notes taken by me (Mara) in the process of re-licensing packages in the tidyverse, r-lib, and more.


Mara Averick

The Tidyverse


Sep 23, 2021

These are my (somewhat unhinged, and decidedly incomplete) notes taken while researching the re-licensing process. For a more succinct (and, hopefully, clearer) summary of what actually occurred, see Re-licensing packages: a retrospective on the tidyverse blog.


I am not a lawyer, and this is not legal advice. In fact, much of what follows has to do with perceived legal implications, as even lawyers can only speculate on several of the matters at hand, since actual judicial rulings on cases involving open-source licenses are sparse (the cost-benefit analysis rarely results in taking these things to court).

Furthermore, this isn’t advice as to what license(s) you should use for your R packages. Rather, it is an attempt to clarify the why of our recent, systematic re-licensing of several r-lib and tidyverse packages to use the MIT license.


The bottom line is that users are not free to use the software in any way that they might like; if users do not heed the requirements placed on the use of OSS, they might find themselves embroiled in an action claiming copyright infringement (Erp Montague 2011).


Derivative works

a work based upon one or more preexisting works (17 U.S.C. § 101 - Definitions; see also Darth Vader Scale of Derivative Works in (Lindberg 2008, 231) and shown later in these notes Figure 1).

Collective works

a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole (17 U.S.C. § 101 - Definitions).

Functional language

any idea, procedure, process, system, method of operation, concept, principle, or discovery (17 U.S.C. § 102(b)).

Copyright protection does not extend to functional language.

De minimis changes

changes that are so minimal that the changed work should be considered identical to the original work (Lindberg 2008, 97).

Contracts and Licenses

In Samuel Williston’s A Treatise on the Law of Contracts (first published between 1920 and 1922 in five volumes, Williston on Contracts is pretty much the definitive reference), a contract is defined thusly:

A contract is a promise, or a set of promises, for breach of which the law gives a remedy, or the performance of which the law in some way recognizes as a duty (Williston 1958, 1:1–2).

Basically, it’s an agreement enforceable by law (though, again, this is a gross oversimplification).

Intellectual property is shared through contracts and licenses.

Contracts and licenses are the means by which people let their intellectual property out in a controlled way (Lindberg 2008, 135).

Licenses are a type of contract (a subclass, if you will, with certain attributes):

When dealing with intellectual property, we make agreements about how that IP can be used. These agreements, called licenses in this context, are contracts (Lindberg 2008, 139).

A license is an agreement in which a licensee is given permission to use the property by the property holder:

A license can be thought of as permission to use someone else’s property. In a contract context, a license is an agreement in which one of the terms of the agreement is permission by the property holder to use the property (Lindberg 2008, 135).

IP holders can make money from their intellectual property in two ways: they can sell all the rights to the property (an assignment) or grant limited rights to the property (a license) (Lindberg 2008, 146).

How an IP contract becomes a license

A license is distinguished from common contracts in that it includes specific terms for one’s use of another person’s IP:

  1. Grant of the license
  2. Limitations on the scope of use
  3. The reservation of rights

Three effects of license on IP

  • It gives people permission to use someone else’s intellectual property.
  • It allows intellectual property holders to put bounds and conditions on the use of their intellectual property. The most common of these conditions is “pay money,” but other restrictions are also allowed. For example, many software licenses have restrictions on where and how the software is used and against reverse engineering.
  • It allows intellectual property holders to exercise their property rights if the bounds and conditions on the license are not met (Lindberg 2008, 135).

All use of IP is conditional on the scope of the granted permission (the license). If use is outside of that scope, it’s an infringement on IP rights.
In terms of legal implications, IP enforcement is almost always dealt with at the federal level:

Ordinary contracts are typically handled in state court, under state laws. Intellectual property enforcement, however, is almost exclusively dealt with at the federal level, under federal law. Because there are significant advantages for intellectual property holders in the federal courts, the ability to invoke federal intellectual property law can itself be an advantage (Lindberg 2008, 136).

Because The Free Software Foundation (FSF) maintains that the GPL is not a contract (and contract law is a lot to unpack), we will not go into great detail here.

Unenforceable contracts

From Black’s Legal Dictionary (9th edition, abridged):

unenforceable contract. A valid contract that, because of some technical defect, cannot be fully enforced; a contract that has some legal consequences but that may not be enforced in an action for damages or specific performance in the face of certain defenses, such as the statute of frauds (Garner 2010, 374).


One of the features of contract law is that any ambiguity in the license is construed against the writer (Lindberg 2008, 148).

Intellectual Property (IP)

IP audits

An IP audit also may include the identification of rights that a company licenses to and from third parties. Information should be obtained directly from company personnel through in-person interviews and questionnaires, as well as from reviewing documents, such as relevant contracts, patent and trademark filings, and laboratory notebooks (Kohel 2020).

After the intellectual property is identified and relevant information is collected, a report is generated that sets out the following basic information:

  • the owner of each item of intellectual property;
  • the remaining life of each item of intellectual property;
  • a description of whether and how the intellectual property is being used, including any potential infringements and misuses by the company and third parties; and
  • the evaluation of any defects and recommended remedial action (Kohel 2020).

Trade secrets

Defend Trade Secrets Act (DTSA), codified at 18 U.S.C. §1831-1839

Uniform Trade Secrets Act with 1985 Amendments

Uniform Trade Secrets Act (UTSA) A model law drafted by the National Conference of Commissioners on Uniform State Laws that codifies the basic principles of common law trade secret protection. The UTSA (in modified or unmodified form) has been enacted by 49 states (the exception is New York), the District of Columbia, and the US Virgin Islands (Practical Law Glossary, 2020).

Uniform Trade Secrets Act, §.1.(4) (1985); 18 U.S.C. 41839(3)


Open Source

The term “open source” refers only to how code is distributed and consumed. It says nothing about how code is produced. “Open source” projects have nothing more in common with one another than “companies” do. All companies, by definition, produce something of value that is exchanged for money, but we don’t assume that every company has the same business model (Eghbal 2020).


MIT license

While the MIT license is credited with making the distribution of open source code frictionless, its “set it and forget it” approach has also been criticized for driving the wedge between open source code and its ideological origins (Eghbal 2020).


From Kyle E. Mitchell’s How to Speak Copyleft (2018):

To implement a copyleft rule, a drafter must make four independent design decisions:

  1. Trigger: When must licensees share other work?
  2. Reach: What other work must licensees share?
  3. Licensing: On what terms must licensees share that work?
  4. Distribution: How must licensees share source for that work?

Several licenses, such as the GPL variants, contain an obligation for reciprocity; you can use this, but only if whatever you make using this is also available under this same license. This is a gross oversimplification, and the scope of the reciprocal obligation varies across licenses (and is often vaguely worded in the license itself). As Lawrence Rosen describes in Open Source Licensing: Software Freedom and Intellectual Property Law (2004):

Licenses like the GPL contain vague provisions about derivative and collective works; some licensors prefer that ambiguity because it results in more software licensee contributions licensed under the GPL.

From the Free Software Foundation’s What is Copyleft? (2018):

To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code, or any program derived from it, but only if the distribution terms are unchanged.

Though this sounds simple enough, ambiguity tends to make corporate folks (or at least their lawyers) nervous. And, when it comes to code, there are added layers of complexity, many of which have yet to be ruled on in a court of law.

In the ongoing case of Oracle v. Google, both plaintiff and defendant have issued motions for “judgment as matter of law” (“JMOL”) both successfully and unsuccessfully for: fair use (denied), the “rangeCheck” computer routine (denied), and eight decompiled security files (granted–see Oracle Am., Inc. v. Google Inc., No. C 10-3561, 2012 U.S. Dist. (N.D. Cal. May 11, 2012) (“Order Granting JMOL on Decompiled Files”)).

Throughout the case parties have distinguished “declaring code” and “implementing code” (see Oracle America, Inc. v. Google Inc., 750 F. 3d 1339 - Court of Appeals, Federal Circuit 2014), and as oral arguments have been presented to the Supreme Court, the copyrightability of an Application Programming Interface (API) remains undecided (see Transcript of Oral Argument Google LLC v. Oracle America, Inc., U.S. (2020) (No. 18-956) (Argued October 7, 2020)).

Kyle E. Mitchell has several posts highlighting important bits, including Oracle v. Google Oral Argument, and Mix Many Metaphors in which he catalogs the many analogies used by Supreme Court justices and arguing lawyers alike (2020b, 2020a). Wikipedia also does a pretty bang-up job of summarising the now eight-year-long legal battle on their Google LLC v. Oracle America, Inc. (2020c).

Viruses and Freedoms

The first thing any lawyer learns about open source is that there are two kinds of open source licenses: “viral” and “nonviral.”

When lawyers use the term “viral,” they are referring to a license condition that requires the licensee to redistribute source code in outbound licenses only on the same terms as the inbound license (Meeker 2008, 11).

“Reciprocal” means two different things in law and FOSS:

For a more accurate term, I recommend “hereditary,” because the terms of the license initially applied to the software are “inherited” by all subsequent licensees of the same code, subsets of it, or variations of it (Meeker 2008, 13).


This key part of the second paragraph of the GPL is the most important provision of the license. Derivative works must be licensed under the GPL and be subject to all of its restrictions. Unlike works licensed under the MIT or the BSD License, works derivative of work licensed under the GPL (or the original work itself) may not be made proprietary or otherwise limited in their distribution. If a programmer is looking to create proprietary works, the entire universe of GPL-licensed software is closed off to her. Indeed, as described in Chapter 6, the inclusion of any GPL-licensed code in purportedly proprietary software could prevent the creator of that software from enforcing any of the rights otherwise available under copyright: any person could distribute, sell, or modify that software, in disregard of any rights that would otherwise be granted the creator under the copyright laws (Laurent 2004, 49) [emphasis added].

The Darth Vader Scale of Derivative Works


Note that The Darth Vader Scale of Derivative Works (Figure 1) is Lindberg’s interpretation of the FSF’s position on the applicability of the GPL.

To understand the FSF’s position on the applicability of the GPL, it is useful to view the interaction between programs on a scale from “mere aggregation” of differently licensed work to wholesale incorporation of code into a modified GPL-licensed binary. Figure 12-11 summarizes the FSF’s view of the situation; anything more than “mere aggregation” moves a user toward violating the GPL (Lindberg 2008, 231).

1 Figure 12-1 references the figure as it appears in Lindberg’s book (2008). Here, it is reproduced as Figure 1.

The Darth Vader Scale of Derivative Works: Young Anakin (circa Episode 1) is mere aggregation, older (but still young-ish) Anakin (Circa Episode 2) is plug-ins and dynamic linking, older still (circa Episode 3) is static linking, and full-blown Darth Vader is incorporation. Figure from Lindberg 2008.
Figure 1: The Darth Vader Scale of Derivative Works – Young Anakin (Episode 1) is mere aggregation, older (Episode 2) Anakin is plug-ins and dynamic linking, older still (Episode 3) is static linking, and full-blown Darth Vader is incorporation.


  • Open Source Licensing: Software Freedom and Intellectual Property Law by Lawrence Rosen (2004). Available from Rosen free online at
  • Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent (2004). Free online here, but not sure if this is a legitimate source.
  • Intellectual Property and Open Source: A Practical Guide to Protecting Code by Van Lindberg (2008).
  • The Open Source Alternative: Understanding Risks and Leveraging Opportunities by Heather J. Meeker (2008).
  • How Open Source Ate Software: Understand the Open Source Movement and So Much More by Gordon Haff (2018).
  • Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal (2020).


Harper & Row v. Nation Enterprises, 471 U.S. 539 (1985)

From: Justia Opinion Summary and Annotations

Primary Holding
A copyright holder has the statutory right to control the first public distribution of an authorized version of the protected material.

Chicago style citation for full opinion:

O’Connor, Sandra Day, and Supreme Court Of The United States. U.S. Reports: Harper & Row v. Nation Enterprises, 471 U.S. 539. 1984. Periodical.

Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992)

In this case, the Second Circuit adopted the “abstraction-filtration-comparison” three part test to analyze non-literal infringement claims in computer software. Utilizing this process, the Court found that in this instance, there was no copyrightable expression copied, so there is no copyright infringement.

Abstraction-Filtration-Comparison test (Wikipedia contributors 2020a)

The Abstraction-Filtration-Comparison test (AFC) is a method of identifying substantial similarity for the purposes of applying copyright law. In particular, the AFC test is used to determine whether non-literal elements of a computer program have been copied by comparing the protectable elements of two programs.

Baker v. Selden, 101 U.S. 99 (1879)

Widely cited as the source for the idea-expression dichotomy

The principal holding of Baker v. Selden is codified in §102(b) of the Copyright Act of 1976. Baker is still heavily cited today, with more than 130 decisions citing it from 1984–2004 (Wikipedia contributors 2020b).

Library of Congress record:
Bradley, Joseph P, and Supreme Court Of The United States. U.S. Reports: Baker v. Selden, 101 U.S. 99. 1879. Periodical.

17 U.S. Code § 102 - Subject matter of copyright: In general

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work (17 U.S.C §102(b)).

Mazer v. Stein, 347 U.S. 201 (1954)

Reed, Stanley Forman, and Supreme Court Of The United States. U.S. Reports: Mazer v. Stein, 347 U.S. 201. 1954. Periodical.

“Unlike a patent, a copyright gives no exclusive right to the art disclosed; protection is given only to the expression of the idea-not the idea itself” (at 217).

Andersen et al v. Monsoon Multimedia, Inc. 07-CV-8205 (S.D.N.Y. Sept. 19, 2007).2

In September of 2007, the Plaintiffs, Erik Andersen and Rob Landley sued the Defendant, Monsoon Multimedia, Inc., in what was the first U.S. lawsuit filed to enforce the General Public License version 2 (GPLv2) (Gatto 2007a).

The Plaintiffs filed claims of copyright infringement, pursuant to 17 U.S.C. § 501 and 28 U.S.C. §§1331 and 1338(a).

The case ultimately settled, leaving questions unanswered per the legal status of the GPL (Gatto 2007b). Though the Free Software Foundation is adamant that the GPL is not a contract, the status of the license (or contract) determines:

the legal basis for pursuing violators (copyright infringement vs. breach of contract) and the remedies (injunction vs. monetary damages) available (Gatto 2007a, 1).

2 The initial complaint has been made available via the Software Freedom Law Center, Inc. by Daniel B. Ravicher (attorney for the Plaintiffs) here.

Jacobsen v. Katzer 535 F.3d 1373 - Court of Appeals (Fed. Cir. 2008).

Landmark Federal Circuit opinion, holding that open source licenses are enforceable under state contract law and federal copyright law.

See: Azzi, R. Michael, CPR: How Jacobsen v. Katzer Resuscitated the Open Source Movement, 2010 U. Ill. L. Rev. 1,271–1,302 (2010).

The Jacobsen decision confirms previous speculation that a violation of an open source software license exposes a company to more than a breach of contract claim, but also to a claim of copyright infringement, and potentially, an injunction in addition to damages (Coch, Moss, and Roberts 2008).

Artifex Software, Inc. v. Hancom, Inc., Case No.16-cv-06982-JSC (N.D. Cal. Sep. 12, 2017)

allowed breach of contract claims for GPL violations in connection with the use of open source software. As the decision shows, reliance on arguments that the GPL is not a contract or that corresponding contract claims are preempted by copyright law may prove misplaced. Accordingly, businesses should carefully consider contract law implications when licensing and using GPL-governed code (Davis and Gilbert 2017).

Artifex shows that courts may be willing to allow dual theories of recovery–breach of contract and infringement–for GPL violations (Id).

CoKinetic Systems, Corp. v. Panasonic Avionics Corporation, No. 1:17-cv-01527, (S.D.N.Y. 2018)

This case did not reach a ruling. It was terminated on January 19, 2018 after CoKinetic submitted a letter to the court saying that an out-of-court settlement had been reached with Panasonic Avionics.

Summary facts of the case from Legal Issues And Compliance Pertaining To Open Source Software by Adhishree Jadhav for Global Patent Filing (2018):

  • CoKinetic Systems Corporation filed a suit against Panasonic Avionics in the New York Federal Court seeking damages of around $100 million.
  • The major claim of the petitioner was that the respondent has intentionally violated the GPLv2 open source licensing requirements, in addition to a lot of other actions aimed at monopolizing the market for in-flight entertainment software and media services.
  • Panasonic refused to distribute the source code (OSS) and thus prevented its competitors from being able to build the software for in-flight entertainment services.
  • By this unlawful act, CoKinetic alleges that the respondent has infringed the copyrights of a number of software developers that have contributed to Linux (the source code of which Panasonic refused to share).
  • CoKinetic notified the court in an 11 January letter that the dispute with Panasonic Avionics had been settled.

So, what’s the point of this? Well, chances are that if two large corporations ultimately couldn’t duke this out in court using Antitrust law (specifically The Clayton Antitrust Act, codified in 15 U.S.C. §§ 12-27), then it’s unlikely you’d succeed either.

According to the Thompson Reuters Practical Law Glossary definition:

The Clayton Act provides for civil penalties that are enforced by the Federal Trade Commission (FTC) and the Antitrust Division of the Department of Justice (DOJ). Private parties are also permitted to sue for damages, including punitive damages, and injunctive relief if they are injured by conduct prohibited by this Act.

The fact that antitrust law allows parties to sue for punitive damages as well as injunctive relief makes it one of the few approaches that could result in substantial financial compensation.

Back to top


Coch, Nicholas L., Kevin M. Moss, and Ashley B. Roberts. 2008. “Open Source Licensing: Caution and Considerations in Light of Jacobsen v. Katzer.” Kramer Levin Intellectual Property Alert.
Eghbal, Nadia. 2020. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press.
Erp Montague, Joanne van. 2011. “Copyright Issues with Open Source Software.” In, 18.
Free Software Foundation. 2018. “What Is Copyleft?” GNU Operating System.
Garner, Bryan A. 2010. Black’s Law Dictionary, Abridged. 9th edition. West.
Gatto, James G. 2007a. “First U.S. Lawsuit Filed to Enforce the General Public License.” Pillsbury Winthrop Shaw Pittman LLP Client Alert.
———. 2007b. GPL Enforcement Lawsuit Settles–Underscores the Importance of Open Source Compliance Measures.” Pillsbury Winthrop Shaw Pittman LLP Client Alert.
Haff, Gordon. 2018. How Open Source Ate Software: Understand the Open Source Movement and so Much More. 1st ed. USA: Apress.
Jadhav, Adhishree. 2018. “Legal Issues and Compliance Pertaining to Open Source Software.” Global Patent Filing.
Kohel, Matthew D. 2020. “Proactive Protection: Intellectual Property Audits.” Goodell DeVries.
Laurent, Andrew M. St. 2004. Understanding Open Source and Free Software Licensing. O’Reilly.
Lindberg, Van. 2008. Intellectual Property and Open Source: A Practical Guide to Protecting Code. First. O’Reilly.
Meeker, Heather J. 2008. The Open Source Alternative: Understanding Risks and Leveraging Opportunities. Wiley & Sons.
Mitchell, Kyle E. 2016. “The MIT License, Line by Line: 171 Words Every Programmer Should Understand.” /dev/lawyer.
———. 2018. “How to Speak Copyleft: The Missing Vocabulary of Copyleft Design.” /dev/lawyer.
———. 2020a. “Mix Many Metaphors: Analogies Galore in Oracle v. Google Oral Argument.” /dev/lawyer.
———. 2020b. “Oracle v. Google Oral Argument: Major League Copyright Lawyering at Bat.” /dev/lawyer.
Rosen, Lawrence. 2004. Open Source Licensing: Software Freedom and Intellectual Property Law. USA: Prentice Hall PTR.
Wikipedia contributors. 2020a. “Abstraction-Filtration-Comparison Test — Wikipedia, the Free Encyclopedia.”
———. 2020b. “Baker v. Selden — Wikipedia, the Free Encyclopedia.”
———. 2020c. “Google LLC v. Oracle America, Inc. — Wikipedia, the Free Encyclopedia.”,_Inc.&oldid=987579326.
Williston, Samuel. 1958. A Treatise on the Law of Contracts. Edited by Walter H. E. Jaeger. 3rd ed. Vol. 1. Baker, Voorhis.



BibTeX citation:
  author = {Averick, Mara and Averick, Mara},
  title = {Notes on Re-Licensing},
  date = {2021-09-23},
  url = {},
  langid = {en-US}
For attribution, please cite this work as:
Averick, Mara, and Mara Averick. 2021. “Notes on Re-Licensing.” September 23, 2021.