Skip to main content
used more precise language for the GPL requirements
Source Link

On the one hand, it is generally held that the MIT/X license does not forbid redistributing the code with additional conditions attached to it. And the GPL also does not require that the entire project isyou relicense all code to be under the GPL license itself, but rather that the conditions that apply to the.

The GPL code are also observed for the restrequires that

  • the result of combining GPL code and non-GPL code is distributed under the GPL, and
  • that the source-code distribution requirements from the GPL are also observed for the non-GPL code

oth of the codebase, but they don't have to be mandatedthose points are allowed by the license of that code. This makes the MIT/X license, which makes it compatible with the GPL license, with the result that you can combine works under both licenses in a single codebase.

On the one hand, it is generally held that the MIT/X license does not forbid redistributing the code with additional conditions attached to it. And the GPL also does not require that the entire project is under the GPL license itself, but rather that the conditions that apply to the GPL code are also observed for the rest of the codebase, but they don't have to be mandated by the license of that code. This makes the MIT/X license compatible with the GPL license, with the result that you can combine works under both licenses in a single codebase.

On the one hand, it is generally held that the MIT/X license does not forbid redistributing the code with additional conditions attached to it. And the GPL also does not require that you relicense all code to be under the GPL license.

The GPL requires that

  • the result of combining GPL code and non-GPL code is distributed under the GPL, and
  • that the source-code distribution requirements from the GPL are also observed for the non-GPL code

oth of those points are allowed by the MIT/X license, which makes it compatible with the GPL license, with the result that you can combine works under both licenses in a single codebase.

Source Link

Without the agreement of Suckless, it is clear to me that any fork of dwm must also be licensed under an MIT/X-compatible license.

As the MIT/X license also gives recipients the right to sublicense the work, it is almost trivial to meet that requirement.

The only licenses that would be incompatible are what I would call The One That Rules Them All licenses: licenses that require that all copies of the code are under the same license, The One License. To my knowledge, such a license does not currently exist and it would get very little traction if someone would create such a license.

Suppose Alice writes a patch of dwm, and explicitly licenses her changes under a restrictive copyright license. Alice could distribute her changes to whoever she likes, but could not distribute a fork of dwm which included those changes[1]. Bob (who is lawfully given Alice's changes) could apply them to dwm, but would not be able to distribute either those changes, or their version of dwm, to anyone else. Is this accurate?

No, that is not accurate.

The MIT license does not (claim to) apply to code that wasn't licensed with it. As long as Alice's license does not forbid combining the work of Alice with dwm, there is no problem having a fork that contains the result of applying Alice's changes to dwm. Different parts of that fork will be subject to different license terms and to be able for Bob to distribute that fork (or even just the changes from Alice), the license used by Alice will need to permit that.

Suppose Alice writes a patch, and does not explicitly license it at all. If we assume nothing at all about Alice's work, then the copyright is hers and hers alone, and we are in the same situation as 1. Suppose that it is "known"[2] that Alice's work is intended to be a patch of dwm. Does the default situation change in this case, or does it require an explicit agreement of Alice?

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.
Repositories hosted on GitHub are an example of repositories with that policy.

Suppose Alice writes a patch, and explicitly licenses it under a license like the GPL, which also includes a clause that requires modified versions to be under the same license[3]. Are forked versions forbidden in practice, just like in situation 1?

[3]: I am under the impression that code cannot simultaneously be licensed under MIT/X and GPL.

Your impression about the simultaneous licensing under MIT/X and GPL is incorrect.

On the one hand, it is generally held that the MIT/X license does not forbid redistributing the code with additional conditions attached to it. And the GPL also does not require that the entire project is under the GPL license itself, but rather that the conditions that apply to the GPL code are also observed for the rest of the codebase, but they don't have to be mandated by the license of that code. This makes the MIT/X license compatible with the GPL license, with the result that you can combine works under both licenses in a single codebase.

And if that isn't enough, the sublicense grant that the MIT/X license gives makes it possible to distribute dwm under the GPL license itself.