Ownership and Control in Open Source

Open source challenges basic notions of ownership and control. With many copyright works, an author seeks to control their work so that others have to pay to access it, and no one can edit it without the author’s approval. Open source reverses the control model so that anyone can access the work for free and everyone is welcome to modify their copy. That said, projects are managed; otherwise they would be chaotic or subject to internet trolls. This page seeks to clarify some of the issues that can arise regarding these notions of ownership and control.

We’ll explore the following questions:

1. Who “owns” a project? Does it matter?
2. Who controls the project?
3. What happens during conflicts?

Ownership

The copyright owner of a project has the right to publish an open source project. Meaning, you don’t have the right to take someone else’s code and publish it for them – much like I don’t have the right to take pictures from your phone and share them. Only the rights holder has those rights. Normally the author of a work is the copyright owner. However in many jurisdictions, an author can assign the copyrights via contract. In fact this is how most companies use code authored by their employees. They enter into a contractual agreement with the employee where the employee assigns the code copyrights and the company pays the employee a salary. Thus when an employee writes code for work, the company gets the copyrights allowing it to use the code and publish the code as open source. The details of the contract stipulate what code is included in the category “work for hire” and some jurisdictions add limitations on what can be assigned.

So who owns source code? Let’s define ownership in this context as being the copyright holder. (Later we’ll explore where this notion differs from control.) Initially the author of code is the copyright holder. For work-related code, the author assigns the code to the company. The direct implication: the company can use the code without fear the employee will sue the company. The indirect implication: the company can publish the code (even if the employee leaves the company or does not want the code published), and the company can block the code being published (even if the employee wants to publish it, or just take the code with them to their next job when they leave the company). The company, as copyright holder, has the upper hand in deciding the fate of the code.

This can pose an emotional conflict with employees who feel attached to their creative work. They feel that they own the code (they don’t feel as moved to refund paychecks that were given in consideration of the copyright assignment agreement). The resolution of rights ownership is often addressed by an impassive legal examination of the legal arrangements the employee made with the employer. Companies with an OSPO can leverage the OPSO to help clarify and resolve conflicts and questions, should they arise.

Typical conflict scenarios include:

1. The employee wishes to take unpublished code with her when she leaves to another company. This is usually an explicit violation of employment terms and the company’s information security policies. Moreover, the pre-publication SDRT review helps ensure code does not contain confidential or sensitive information (e.g. passwords). Employees should not copy company code to be used outside the context of work without explicit approval (e.g. a published project with an open source license). Many requests to publish code are issued by employees who are planning to leave the company and want to take the code they were working on to their next job. By asking for an open source license, they protect themselves (and their next company) from complications.
2. The employee wishes to publish code she worked on as an open source project on her personal GitHub account. Before publishing code, we’ll ask who is the copyright holder? If this is personal code (e.g. written by the employee while self-employed, or code not assigned to the company), the company cannot publish the code and generally has nothing to say about what employees do with their own property (assuming it does not violate any laws, corporate ethics considerations, etc.). If this is company code, and if the SDRT approves the publication, the employee can host a copy of the code on her personal GitHub account (actually once published by the SDRT, anyone can host a copy of the code on their personal account too.)
3. The employee wishes to publish code she worked on as an open source project on the company’s GitHub organization. The SDRT will ask who is the copyright holder? If it’s company code, and if the SDRT approves the publication, we would likely publish the code on the company’s GitHub account. But if this is personally-owned code, it is uncommon to host an employee’s personal project in the company account. Company accounts are not ideal for forks (they get stale quickly) and it’s unclear what should happen to the code when the employee leaves.
4. The company wishes to publish code, but one of the employee authors does not want the code published. In this case, the SDRT should explore why one of the authors does not want the code published. Before publishing code, the SDRT will encourage the team publishing the code to ensure that all the people involved in the project agree the code should be published. Sometimes a developer feels their code is not ready to be published, sometimes they want to be more involved in the process. Ultimately, one employee who is not the copyright holder might not block a publication. But we advise understanding the situation before acting with fiat. It’s always better to understand issues before code is publiished.
5. An employee wishes to take an existing open source project in a different direction than the project is going. Once a project is published under an open source license, anyone can fork the project. Provided an employee complies with the project license, they can do as they wish with the code (considering legal, ethical, and related issues etc.). Ideally employees would work together toward a shared outcome for a project. But if two groups of employees disagree on a project, it’s better they each write the code they want to see and not argue about it, certainly not in public. Arguments don’t make code better, but working code wins arguments.

Control

Control is closely related to ownership. We often confuse the two. Consider if someone gave you the right to use his car whenever you wished. You could park it in your driveway, drive it anytime, and use it as you please. It would feel like your car since you have the controls that ownership usually entails. However if you tried to sell the car, you’d have to deal with the fact that someone else owns the title to the car. This gets more complicated with intellectual property since source code is not inherently excludable, nor is your use of code rivalrous to someone else’s use. Control often feels like a close proxy to ownership. So who controls the open source project? How does control even work?

For company published open source projects, an employee controls the project often based on objectives that are in harmony with the company. We expect the lead maintainer to invite external participation and eventually get non-employees to become project maintainers too. This often results in one of three outcomes:

• The project runs its course as a company-managed project for as long as there is activity and interest in the project.
• The community takes a more active role in the project and we consider transferring the project to a software foundation so that the project is community-controlled.
• All employee maintainers leave the company and the company offers the project to the community or archives it.

Conflicts

This discussion about ownership and control may cause us to forget that open source challenges the models and allows us to think differently about projects. No code runs because of only one person. All source code projects are based on language fundamentals, libraries, and other code projects. Source code can be improved by contributions from others who are not the code authors. Rather than asserting ownership rights and exclusive control of code, successful projects convey that the future of a project rests in the hands of an emergent community who, together, shapes the growth of the code. When developers view code as a fixed asset, the code rarely becomes a communal project. When a developer starts an argument with “but this code is mine…” she shuts down the notion that others have contributed to it, and those others’ will.

It is a reality that open source projects have copyright holders and maintainers who control which pull requests are merged. But open source also invites the thinking that the project is not an owned fixed asset, but a growing potential. Our opportunity is not found in how we control it, but in how we encourage it to grow. Yet when there is conflict between participants in a project, we need a resolution that does not destroy the project or the relationships developed within the community. So we encourage people to fork the project and create the reality they wish to see. Arguments don’t make code better, but working code wins arguments.