0

This is a follow up question to an earlier question which included a misunderstanding about the nature of the MIT/X license, and has been clarified there.

Consider the software project dwm by Suckless. The project is clearly licensed under the MIT/X Consortium License. It is customarily augmented by source code patches.

Suppose Alice makes some changes to dwm. The changes could be conveniently distributed as either a patch file, or as a fork of the original repository. Suppose that Alice's changes make no alteration to the existing license of dwm. Her fork would include the same license statement that the original project did. Then I think that:

  • Alice's forks to dwm are clearly licensed as MIT/X.
  • Alice's patches, taken by themselves, have all rights reserved.

It follows that as long as no fork including Alice's patch has been published by Alice, that Bob (who forked dwm and included Alice's patch in good faith), might be violating Alice's copyright by distributing his version. This sounds like a problem for managing copyright among large projects - is it a problem in practice? Is there some inference made about the fact that Alice's changes were clearly intended to patch dwm, or must some explicit agreement be made?

A license with greater copyleft in the parent project (like the GPL) does ensure that Bob's fork is allowed. Section 5 of GPLv3 states (my emphasis):

    5. Conveying Modified Source Versions.
       You may convey a work based on the Program,
       **or the modifications to produce it from the Program**,
       in the form of source code under the terms of section 4,
       provided that you also meet all of these conditions:
       ...

Copied from previous question: Bart von Ingen Schenau wrote the following relevant detail:

There is only one situation where the default copyright "license" changes if it is known that the changes are intended to be a patch to another work. That is if the changes are offered in a pull-request to a repository that has the policy that the incoming license (the license of contributions) is the same as the outgoing license (the license under which the repository is offered). In that case, by making a pull request, Alice has agreed to license her changes under the repository's license, even when it is not explicitly stated among the changes.

They mention that GitHub is an example of a platform with such a ToS. I am interested in finding out if there are any more general considerations, in the absence of something like a ToS explicitly guaranteeing these rights.

Improve this question
5
  • 3
    It seems to me that this question, along with its answer, is well worth a look. Also this answer as well.
    – MadHatter ♦
    Sep 29 '20 at 8:52
  • 1
    What is Alice's intention or communication regarding this patch file? For example did she post it publicly on a message board somewhere and say something like "hey, feel free to use this patch file to fix bug 12345?" In other words, what is the basis of Bob's good faith that Alice wants him to include the patch file in the code?
    – Brandin
    Sep 29 '20 at 13:31
  • @Brandin To keep the conversation concrete, I'll stick with the specifics of this project. In this case, patches are submitted by the author to a mailing list, and then hosted on the project source page. The project page clearly states that the patches are intended for patching the main program, but there is no (known) explicit acknowledgement of copyright from Alice. The patches are primarily to enable additional features, rather than fix bugs, and are not always intended for eventual inclusion in the upstream project.
    – preferred_anon
    Sep 29 '20 at 16:06
  • @MadHatter Your links appear to suggest that (contrary to my statement) Alice's forks are not licensed under MIT/X. This suggests that there is no contradiction, and that no matter how Alice's changes are distributed, no copyright is ceded to anyone under any terms. This sounds like a real nightmare, because it implies that a license statement without full copyleft cannot be taken at face value. A user who desires to distribute it must in principle also scour the project history for all contributors and find explicit disclaimations of copyright.
    – preferred_anon
    Sep 29 '20 at 16:38
  • The difference, of course, is if there is an overarching contributor agreement. I guess sufficiently large OS projects generally have these, while smaller ones generally do not. Distributing under the GPL also appears to ensure the safety of distributors (whether via forks or via patch files).
    – preferred_anon
    Sep 29 '20 at 16:41
2

I think I can answer my own question at this point. The two relevant factors appear to be the scope of the parent license's copyleft, and whether some kind of contributor license agreement is in place.

No CLA, with a non-copyleft parent license

  • Alice's forks to dwm are clearly licensed as MIT/X.
  • Alice's patches, taken by themselves, have all rights reserved.

It is not true that Alice's forks are licensed under MIT/X. The license notice which is obtained from the parent project applies only to the code from that project. Alice's new code is not licensed under those changes, which implies that Bob's fork is always unauthorized, no matter how the changes are distributed. See the answers to this question for two opinions to that effect.

No CLA, with a strong copyleft license

As noted in the question, if we replace "MIT/X" with, for example, the GPL, then modified versions (or the parts of the program necessary to reproduce the modified version from the original) are necessarily licensed under the GPL also.

CLA

An explicit CLA may cede copyright to the project maintainer, or it may simply grant certain rights to the maintainer to use the contributor's code (wiki). If copyright is ceded, then that code is now a contribution of the project owner, no differently to any other part of the project.

If the project owner merely has a license to use the contribution in their project, then a forker seems to be on shakier ground, and the exact situation probably depends on the details of the CLA.

"Implicit" CLAs, and Community Expectations

There is generally a community expectation that "inbound=outbound": that contributions to Free projects are Free. As far as I can tell, this is mistaken. However, some platforms make this assumption into an explicit agreement in their Terms of Service. The linked question gives an example of GitHub, and again this varies from platform to platform.

Improve this answer
4
  • As Brandin pointed out, it depends on Alice's intent. But I agree that unless Alice clearly makes an expression to the contrary, you're right, which is why non-copyleft free projects would be well advised to get CLAs from contributors.
    – MadHatter ♦
    Sep 30 '20 at 10:11
  • Indeed, I was double checking your references as I posted and noticed a link to this answer which indicates a kind of "custom" which is not in law, but I guess would probably be respected by a court (but I don't know of any precendent). I plan to add more details.
    – preferred_anon
    Sep 30 '20 at 10:13
  • I think your guess is wrong. As the court showed in Great Minds v FedEx Office when they rejected CC's amicus brief, courts are generally uninterested in the internal traditions and consensus of groups like the free software community. They're solely interested, and rightly so, in law and legal precedent.
    – MadHatter ♦
    Sep 30 '20 at 10:56
  • @MadHatter Thanks for that clarification, and all your informative comments. I've updated the answer to give the fullest picture that I understand.
    – preferred_anon
    Sep 30 '20 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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