Mandatory disclaimer when talking about intellectual property: We are not lawyers, but we do help open projects assess IP risks to their work and that's what this post is about. This post is not legal advice. If you have a question for a lawyer, ask a lawyer.
While open source software is open by definition, this term applies only to the code of the project. The intellectual property (IP) of an open source project also includes other work produced to support the project, including the project’s name, logo, domain name, and website, which may be trademarked or copyrighted separate from the open source code. Project leads need to consider IP ownership of the open source code and other assets to avoid the worst case scenarios of infringement and inappropriate reuse. In 2020 we worked with Rhizome and Conifer, which is built on the open source project Webrecorder and we worked with these teams on an IP audit to help set up all parties for successful IP management. This work was supported by a grant to Rhizome from the Andrew W. Mellon Foundation. Here, informed by that work, we outline some simple steps that any open project can take to audit their IP to identify and remedy areas of unnecessary risk.
This first step to identifying any IP risks to a project is to make a list of assets (web domains, code repositories, logo, name), who owns the copyright for each, and how each asset is licensed (if at all). With this information, the project can consider the following scenarios:
Consider what other IP risks may exist for a specific project. Does the legal owner of the IP differ from the community perception of how the IP is held? It can be helpful to consult stakeholders and collaborators to gain additional perspectives on additional risks.
To model risks for each scenario, the next step is to write out the process that would be required to resolve the issue. Who would coordinate the response? Who would pay for any legal assistance? What companies or other third parties would need to cooperate to resolve the issue? Who owns the IP in question, and are they able to initiate a Digital Millennium Copyright Act (DMCA) takedown request, if necessary?
In many cases, IP handling for an open source project can be simplified when the IP is held by one entity that is aligned with the purposes of the project and able to defend the IP if necessary. Open source contributions from multiple sources can result in issues when IP is held by multiple individuals without a clear plan for defense. In an open source project, when IP is not explicitly assigned to a single party, the IP remains with the individual contributors. For most open source projects, the reality is that IP is held informally by many contributors, requiring coordination of multiple contributors for any action. If someone used the project’s open source code inappropriately -- for example relicensing with a more restrictive license -- without one entity holding the IP, the project would have difficulty enforcing their license. In this example, the dispersed ownership of IP poses a risk to the project because taking action on inappropriate code use requires all the individual contributors to coordinate. For a small project, this can result in stress for project staff and potentially extra legal costs.
Many open source projects have unique histories, stories of transition, and diverse groups of contributors - Webrecorder, Conifer, and Rhizome are no exception. Webrecorder had been developed at Rhizome and was transitioning to be an independent entity. Conifer, built with Webrecorder components, is the hosted service that Rhizome has committed to supporting with long term stewardship. In a transition moment like this, we looked to support good communication and clear expectations around IP. To start, we worked with Rhizome and Webrecorder to list the components of Conifer, describe their IP ownership, and licensing. This created an audit spreadsheet that enabled all parties involved to understand the scope of the project, who manages different parts of software, and how those pieces of software are licensed.
Key Take-aways for any open source project:
IP Audit Exercise for Open Projects
Determining IP risks to an open source project may seem daunting, however the first step is making a list. Listing digital assets and modeling scenario responses will help any project identify areas in need of attention or help from external legal counsel. For any open source project interested in improving their handling of IP, we recommend the following steps: