2

Consider the software project dwm by Suckless. The project is clearly licensed under the MIT/X Consortium License, which includes the clause

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The project is customarily augmented by source code patches. Suppose that someone wished to distribute either their modifications to, or their modified version of, dwm. 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. But since the patches are new material in themselves, it seems to me that the patches themselves could (pathologically) be given an incompatible license, which would forbid anyone from creating or distributing a fork of dwm which included those patches. I make no assumption about how substantial the patches are - they could be a minor change, or they might change the nature of the program completely.

I am curious about several different situations:

  1. 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?

  2. 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?

  3. 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?

These restrictions sound like a major obstacle to patching open source programs, and require agreement of all contributors to submit to the parent license. Are such agreements common in projects which accept contributions?

Clarifications

[1]: Alice could of course distribute a fork of dwm provided that it included a copy of the MIT/X License. I believe this would in practice cause the changes themselves to be subject to that same license, effectively nullifying her simultaneous restrictive license.

[2]: By "known", I mean any precise criterion which would indicate that a piece of software is intended for use as a modification to an existing program, and not as a new project in and of itself. For example, if the official host page of the patch said something to the effect of "This file consists of a patch to version 6.1 of dwm". Something which is a direct mention that the work is a modification, but not which makes any specific statements about the copyright of the work.

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

Improve this question
2
  • I have rolled the question back because you edited it to the point where none of the existing answers made sense, and that's not part of the compact. I'm glad that you've found the answers helpful in clarifying your views, and that you now have a somewhat different question to ask. The right way to do this is to accept an answer to this question, thus putting the question to bed, then ask a new question - linking to this one if you feel it's appropriate - that states what you want to know now. I hope you'll ask that new question, as it looks interesting - but it's still not this question.
    – MadHatter ♦
    Commented Sep 29, 2020 at 5:34
  • @MadHatter Thank you, no problem! I was trying to avoid what might be viewed as a duplicate question, but I agree that your solution is better.
    – preferred_anon
    Commented Sep 29, 2020 at 8:21

2 Answers 2

Reset to default
4

It is clear to me that any fork of dwm must also be licensed under an MIT/X-compatible license

That is not, in fact, clear. Firstly, if you read this question you'll see that there is quite a body of opinion that says it's perfectly acceptable to change the licence conditions on code if it was shared with you on terms that do not forbid that. The copyleft free licences require copies and derivatives to be distributed under the same licence (see eg GPLv3 ss 4 and 5c, GPLv2 ss 1 and 2b) but the non-copyleft free licences simply don't have similar language - they require only the distribution of specified text. Certainly, it's known that derivatives of BSD-licensed code are used in commercial products distributed under proprietary licences.

Secondly, you don't address the issue that it's very hard to write a patch for a piece of software without carefully examining said software, and copying the interfaces so that your patch can cleanly replace or supplement existing code. Those are very strong arguments that the patch is a derivative in copyright terms, whether or not it ships with the original software. What that implies for distribution depends on the original licence.

Those things said, let's examine your specific questions.

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

Assuming that dwm is licensed under a non-copyleft free license (such as MIT), Alice is completely free to distribute such a fork. It is, as I have said, a common-enough commercial practice.

Suppose Alice writes a patch [which she intended to be a patch of dwm] and does not explicitly license it at all.

As has been said here before, if code is distributed with no specific licence terms, and it's not required to be free by eg being a derivative of a third-party strong-copyleft work, you can make no assumptions about what you can do with it. The patch is proprietary, and thus unusable by the free software community.

Suppose Alice writes a patch, and explicitly licenses it under a license like the GPL... Are forked versions forbidden in practice, just like in situation 1

No, that would be fine. Such combinations are permitted provided the original licence is compatible with the GPL.

Improve this answer
9
  • You say "the non-copyleft licences simply don't have similar language - they require only the distribution of specified text". I don't understand the distinction between distributing the license text for MIT inside of the software, and licensing the software under the MIT license. If I have to include "Permission is hereby granted, free of charge, to any person... to deal in the Software without restriction" and so on, am i not providing it under an MIT license?
    – preferred_anon
    Commented Sep 28, 2020 at 7:36
  • It seems like the only way around that would be to have a file like: "THE FOLLOWING TEXT IS NULL AND VOID <MIT License body>". But if you could do that, then the clause seems meaningless to me - why would you insist on distribution of specified text if it doesn't mean anything?
    – preferred_anon
    Commented Sep 28, 2020 at 7:38
  • I understand you think the weakly-free licences are really copyleft, but they really aren't: see any number of commercial organisations that have turned such codebases into proprietary products. It is perfectly possible to write language into a free licence that says that copies and derivatives must be distributed under the terms of a particular licence, and the BSD/MIT/Apache folks have chosen not to do that. Licences mean what they say; it would be unwise to infer that the authors meant to but forgot, or that they thought it was implicitly there the whole time.
    – MadHatter ♦
    Commented Sep 28, 2020 at 7:52
  • Likewise, I understand that you're telling me they're not copyleft, but that doesn't answer my specific claim that it's logically inconsistent. But that's a side issue, I'll ask a separate question about it. It sounds like you're saying that patches would probably be regarded as derivative works, which the MIT license appears to impose no restrictions on. So, unless their is an explicit statement elsewhere, the presumption is that those derivative works are All Rights Reserved, is that correct?
    – preferred_anon
    Commented Sep 28, 2020 at 10:12
  • 1
    the presumption is that those derivative works are All Rights Reserved, is that correct? I and others believe so, yes. There is no logical inconsistency in my position on weakly-free licences; the problem is merely that you can't see a good reason to require reproduction of a block of text if it doesn't mean anything. The bad news is, contractual terms don't become void or altered just because they seem pointless to you. The terms mean what they say; no more, no less.
    – MadHatter ♦
    Commented Sep 28, 2020 at 10:17
1

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 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.

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.

Improve this answer
6
  • Thank you, unfortunately when I wrote the question I had a misunderstanding about the MIT/X license, and that obfuscates the core of the question (namely the status of code which is known to be a patch). If I understand you correctly, your claim is that patches are ARR unless some other explicit statement is made (either in the terms of use of a platform, or something else). This sounds like it would put distributers of forks which include those changes in a difficult situation, is that a fair understanding? I will update my question to correct my mistakes.
    – preferred_anon
    Commented Sep 28, 2020 at 17:59
  • I've updated the question - I apologise that it probably changes the nature of your answer. Your comment about Github may actually be an answer by itself (i.e. "Yes, an explicit agreement is required; no, it isn't a problem typically because platform ToS ensure contributions are licensed"). However, I will leave it open for a bit longer in case you have anything to add.
    – preferred_anon
    Commented Sep 28, 2020 at 18:15
  • "the GPL also does not require that the entire project is under the GPL license itself" sorry, Bart, but that's simply not true; see eg GPLv3 s5c: "You must license the entire work, as a whole, under this License".
    – MadHatter ♦
    Commented Sep 28, 2020 at 19:56
  • @preferred_anon, it is considered bad etiquette in the SE network to completely change a question around after answers have been provided to the original question. It is better to ask a new question in that case.
    – Bart van Ingen Schenau
    Commented Sep 29, 2020 at 6:36
  • @BartvanIngenSchenau Alright, I'll do that - I likewise didn't want to risk asking a duplicate question.
    – preferred_anon
    Commented Sep 29, 2020 at 8:19

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.