From the legal point of view there are two types of work done by multiple authors:

  • Joint authorship - when the authors create inseparable work, and the contributions of the authors are interdependent.
  • Collective work - usually a compilation of works of multiple authors. Each part is separately copyrighted. As example it can be a newspaper or a magazine that consists of articles written by independent authors.

Each type of work provides different rights for the authors. In joint authorship each author shares copyright on the whole work with other authors. In collective work each author owns copyright only on his individual contributions.

How is it related to software?

Let's assume I'm the original author of some open source software project and someone (a contributor) sends me a pull request (a contribution). If I accept the contribution, what is the copyright status of the project now? Is the software project considered as joint authorship or collective work? Is it for whole software or just for the files that the contributor changed?

What are the rights of the original author? What are the rights of the contributor?

I know that it is possible to require the contributor to sign Contributor License Agreement (CLA) which may obligate the contributor to do copyright assignment of the contributions to the original author. But what is default when there is no CLA?

I tend to think that software with contributions is joint work since contributions are usually inseparable of the whole software (unless it is a plugin or a driver). On other hand I heard that contributors own copyright only to their contributions as it takes place in collective work.

  • It probably depends upon the legal system. Not the same in the USA and the European Union Dec 28, 2021 at 6:45

2 Answers 2


This is a broad question, as many different situations (e.g. addition to/modification of existing file vs. addition of a new file) and many different jurisdictions might influence the outcome. The following assumes that there is no Contributor License Agreement (CLA) in place.

You could view the situation of a project like this: There is a status A at a certain point in time t(A), with all of the copyright owners at the time. Then another person P comes at a later time t(B) and modifies the software of status A, creates a pull request and it becomes status B. Status B can be viewed as a derivative work of status A and the parts added/changed by P has his/her copyright in those changed/modified parts and needs to be added to the project’s list of contributors/copyright holders. With many pull requests to a project, this concept would be called ‘serial derivatives’ and each programmer would own his/her part(s) of the code.

The copyright ownership part of the project can —over time and with large projects— become difficult to track and maintain. Therefore many developers consider the situation more like a ‘joint authorship’, so everyone is part of everything. This has advantages and disadvantages, particularly in the areas of enforcement, and there it is important to look at the specific jurisdiction of the case (but as we know many OSS projects are with international contributions, so it is difficult to determine).

Both approaches are possible, and in the absence of a Contributors License Agreement there is no clear cut way to determine which one is right. If you are able and willing to read what lawyers have to say on this subject, then this article might be helpful for you.


Some info I got after reading the article (A Theory of Joint Authorship For Free and Open Source Software Projects by Pamela S. Chestek) provided in the answer of Martin_in_AUT.

First of all, the US copyright law doesn't divide works into two types: joint authorship and collective works. Instead it divides authorship into two types and divides works into five types.

There are only two types of authorship recognized in US copyright law, sole authorship and joint authorship. Copyright subsists in a "work" of authorship. Five types of works are mentioned in the Copyright Act, three expressly defined and two terms used but not defined.

Those types of works are:

  • Initial work.
  • Compilation.
  • Collective work - subset of compilation.
  • Derivative work.
  • Revision - derivative work with insignificant changes that are not enough to form new copyrighted work.

Each type of work can be sole authorship or joint authorship. So it possible to have collective work with joint authorship. But in this case the authorship is associated only with the selection, coordination and arrangement of the constituent works, not with the works themselves, they are separately authored. The same is with derivative work. It can be joint authorship, but the authorship is associated only with modifications to the original work, not with the entire derivative work.

Later the author of the article raises the question similar to the question of this topic.

Free and open source software is unlike almost any other kind of copyrightable work because there can be a monumental number of authors all contributing to the same body of code. The question becomes how to understand the authorship of a work when a number of different people have modified it over time.

Assume that there is a simple work of software, a single file, created by a sole author. The sole author elects to make the software available under an open source license in a public code repository like GitHub. Also assume that the original author plans to accept changes suggested by others but will not be asking for a formal contributor license agreement or an assignment of the contributor's copyright. Another person copies the original source code as allowed by the license, makes changes throughout the file as allowed by the license, and submits a pull request suggesting that the original author modify the initial work by making the same changes to it. The original author does. Assume that the change is significant enough that the contribution is copyrightable.

The author states that the answer to the question is that it is separately authored derivative work.

The traditional view is that each person who contributed copyrightable content to the file is the sole copyright owner of their contribution. Now recall the types of second generation works that copyright law recognizes—the revision, the derivative work, and the subset of a compilation, the collective work—and consider how this contribution affects the initial work. The file with the new changes is no longer the initial work because it has been modified. It may be a revision, although that would not create any new copyright. It is not a collective work because, under our hypothetical that this is a single file, the contributions are not "separate and independent works," they have been blended together and are inseparable from the initial work. The only possibility left is that it is a "derivative work" of the initial work—meaning there are now two works, the initial work and the newer derivative work.

Now consider the next contribution by another author. The result will be the same, an initial work, a subsequent derivative work created by making the first change, and now a second derivative work created by making the second change. Now consider how it looks when there are 13,500 authors and 8 to 9 changes made per hour.

Thus software with contributions is a chain of sequential/serial derivative works with each contribution usually being sole authorship.

Contributing to software project makes it neither joint authorship nor collective work. It makes a new derivative work where the contribution is copyrighted by the contributor and the original work is copyrighted by original author.

It is important to emphasize again that a contributor doesn't hold copyright to the entire derivative work but only to his/her changes to the original work.

Although the phrase "derivative work" means the combination of the pre-existing work and the modifications, the new author's rights do not extend to any of the pre-existing copyrighted work; the new author's copyright extends only to what is different from the pre-existing work and must itself have sufficient originality to be copyrightable.

After this the author lists the drawbacks of the traditional view. It takes large part of the article.

Alternatively open source software can be viewed as a single work with joint authorship.

For there to be joint authorship, the authorship contributed by the two or more participants is either "inseparable" or "interdependent." "Inseparable" means that the works cannot be separately identified, for example, the collaboration of two playwrights on one play. "Interdependent" means that, while the contributions may be separately identifiable, they are written pursuant to an express or implied agreement that the product will be regarded as an indivisible whole, such as the words and music of a song. Perhaps an example of the first in software is the single file with revisions by different authors, and an example of the second is a collection of files that creates one functioning software program.

Unfortunately, even after reading the article, I still do not understand what has to be done to make software joint authorship. Should it be declared in some kind of agreement or not. What the author says about this in her article is that authors should have an intent to combine their contributions into single whole.

For a work of joint authorship, all authors have to intend that their contributions be merged into a single whole.

In the case of free software, proof of the intent to create a joint work is not a problem; it is almost the sina qua non of the open source software project. The word "collaboration" is used so often to describe open source code development that it is almost a trope. The licenses themselves sometimes reflect a joint development ethos. For example, the Mozilla Public License version 2.0 defines "Contributor" as "each individual or legal entity that creates, contributes to the creation of, or owns Covered Software," suggesting that many authors are contributing to the same work. The terminology used in open source software, “contributing upstream,” “inbound” and “outbound,” suggests a common pool of code shared by all. Nevertheless, it is perceived as a legal status to be avoided.

Joint ownership theory has its advantages and disadvantages that are presented later on in the article and take another large part of the article.

Personally I think that one of the disadvantages is that all authors have the same amount of rights to the whole software even if contributions of some authors are insignificant.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.