Intellectual Property in Open Projects

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.

What is Intellectual Property in an Open Source Project?

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.

How to Model Risks to Open Source IP

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:

1. Improper use of the project’s logo or name (example: an initiative that is not associated with the project lists the project’s name and logo on their website);
2. Inappropriate relicensing of code (example: an initiative copies a code repository that is openly licensed from the project and applies a more restrictive license or removes required attribution);
3. Website content that is published separately from code and licensed differently, or is used in a manner that follows with license of the software, not the website copyright. For example, a user guide that is licensed more (or less) restrictively than the code.

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.

Learning from an Audit of IP for Conifer

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:

• Proper Licensing: Ensure any code is licensed and has the proper copyright notice. If software is not explicitly licensed, it may cause legal problems or make it difficult to involve collaborators, even though this source is available online, because the legality of re-use is unclear.
• Clear Communication on Management and Stewardship: If an individual maintains a code repository, the long-term management and governance may be unclear, even if the code is properly licensed. In open source software this is referred to as the Bus Factor. To ensure long term stability, it may make sense to move a repository from an individual to an organization. While this may not have any legal impact, it provides a signal to stakeholders and eases technical management.
• Strategic Contributions: Think strategically to identify parts of the open source project where involvement of contributors and stakeholders in development, governance, and long-term ownership would be beneficial. Is user feedback more valuable than bug fixes in the short term? If developing relationships with institutions is key for the project's future, can setting up regular communication (in-kind contributions, user groups, steering committee) help understand the needs of those stakeholder and build relationships? Mozilla's Open Canvas exercise can help identify what an open source project needs beyond code contributions to succeed. With key priorities identified, the project can set up to manage contributor and stakeholders involvement.
• Document Document Document: We advise that open source projects document what its key components are, who maintains these key components now, how frequently maintenance is required, and how technical decisions are made. Along with all the other docs, of course (check out Write the Docs)!

List Making Time!

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:

1. Make a list of digital assets (include: code repositories, web domains, documentation, and logos)
2. Determine who owns the copyright for each
3. Assess and describe how each asset is licensed (if at all)
4. Use scenarios to model how easily the project can respond to improper use
5. Identify gaps and/or inconsistencies in how the project would be able to respond to improper use today
6. Make changes to licensing, copyright, and/or governance to make it easier to respond to improper use
7. Document governance, maintenance, and stewardship commitments
8. Where questions remain, seek counsel from a lawyer experienced in open source IP