[dev] Licensing question

[Gimmi]

Hi everybody,

I was wondering what is the license of the patches published on the
suckless.org website. A few of them include a license header pointing to
the LICENSE file in the project, so they are under the MIT/X license.
However, many of them do not have a proper license notice.

Is there some kind of implied licenses for the patches once they are
uploaded?

Thanks.

--
Gimmi

[Страхиња Радић]

Дана 26/02/28 02:28PM, Gimmi написа:

It only makes sense for the license of a patch to be the same as that
of the program it applies to. Otherwise, programs would be subject to
relicensing if the license of the patch is overriding (like GNU GPL
is).

[Gimmi]

Hello,

I know that it makes sense and I agree on the principle, but I am afraid
current copyright law does not agree with us.

If I were to publish a patch to a software, I can put the patch under
the license I want and I can choose the GPL: the problem of complying
with the requirements of both licenses is, legally speaking, on the
person that applies the patch.
Worse, if a patch does not specify a license, according to current
copyright law, you cannot redistribute it (I don't even know if you can
actually _use_ it).
Moreover, the MIT/X license allows sublicensing, so the license of the
final program _can_ be changed and one can argue that should the license
of the patch be more restrictive, it would override the MIT/X license.

IMO this should be cleared up for every patch, not only for a small
subset that included a comment at the beginning.

--
Gimmi

[Vincent Lefevre]

On 2026-03-01 12:38:30 +0000, Gimmi wrote:
> If I were to publish a patch to a software, I can put the patch under the
> license I want and I can choose the GPL: the problem of complying with the
> requirements of both licenses is, legally speaking, on the person that
> applies the patch.
> Worse, if a patch does not specify a license, according to current copyright
> law, you cannot redistribute it (I don't even know if you can actually _use_
> it).

A patch yields a modified version of the original work, whose license
may imply obligations on the license of such modified versions.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

[Gimmi]

Hello,

On 01/03/2026 14:06, Vincent Lefevre wrote:
> On 2026-03-01 12:38:30 +0000, Gimmi wrote:
>> If I were to publish a patch to a software, I can put the patch under the
>> license I want and I can choose the GPL: the problem of complying with the
>> requirements of both licenses is, legally speaking, on the person that
>> applies the patch.
>> Worse, if a patch does not specify a license, according to current copyright
>> law, you cannot redistribute it (I don't even know if you can actually _use_
>> it).
>
> A patch yields a modified version of the original work, whose license
> may imply obligations on the license of such modified versions.
>

I am *not* a lawyer, however, AFAIK this is true if the license of the
original work has restrictions.
The MIT/X license under which suckless tools are, gives you the freedom
to sublicense the results, hence to change the license of the patched
software.

So the question of "How is the patch licensed" is still relevant IMO.

--
Gimmi

[Storkman]

On Sun, Mar 01, 2026 at 12:38:30PM +0000, Gimmi wrote:
> Hello,
>
> On 01/03/2026 10:50, Страхиња Радић wrote:
> > Дана 26/02/28 02:28PM, Gimmi написа:
> >> Hi everybody,
> >>
> >> I was wondering what is the license of the patches published on the
> >> suckless.org website. A few of them include a license header pointing to the
> >> LICENSE file in the project, so they are under the MIT/X license. However,
> >> many of them do not have a proper license notice.

Well, what's the licencse of the wiki content in general?
Perhaps it should be specified.

--
Storkman

[Страхиња Радић]

Дана 26/03/01 02:28PM, Gimmi написа:

> I am *not* a lawyer, however, AFAIK this is true if the license of the
> original work has restrictions.
> The MIT/X license under which suckless tools are, gives you the freedom to
> sublicense the results, hence to change the license of the patched software.
>
> So the question of "How is the patch licensed" is still relevant IMO.

Yes, this (also IANAL). Far from it being forbidden to create a patch
under GNU GPL and publish it on one's own website, but keep in mind it
relicenses the entire modified work under GNU GPL. So the decision of
whether to include such a patch on the suckless.org wiki is entirely on
the "people in charge" here and their policies.

I know that the stance of folks usually using Expat ("MIT") license and
similar "lax" licenses is to "avoid politics" while "giving the maximal
amount of freedom", and they also tend to have a strong opinion on GNU
GPL being "political". (This "neutral" stance, IMHO, in itself
constitutes a political opinion, ironically; however, that is off-topic
in this particular thread.) Given that GNU GPL overrides "lax"
licenses, a feature which some even compare to "a virus", it would be
logical to assume such patches would be frowned upon here.

Anyway, this is all just my assumption about whether stronger-licensed
patches would be welcome on suckless.org. I might be wrong.

[Miles Rout]

> On 2 Mar 2026, at 4:48 AM, Страхиња Радић <s...@strahinja.org> wrote:
>
> Дана 26/03/01 02:28PM, Gimmi написа:

>> I am *not* a lawyer, however, AFAIK this is true if the license of the
>> original work has restrictions.
>> The MIT/X license under which suckless tools are, gives you the freedom to
>> sublicense the results, hence to change the license of the patched software.
>>
>> So the question of "How is the patch licensed" is still relevant IMO.
>
> Yes, this (also IANAL). Far from it being forbidden to create a patch
> under GNU GPL and publish it on one's own website, but keep in mind it
> relicenses the entire modified work under GNU GPL. So the decision of
> whether to include such a patch on the suckless.org wiki is entirely on
> the "people in charge" here and their policies.

This is my understanding of things. The whole topic is complicated by the fact different countries have different law and use different terminology, of course.

It is inaccurate to say "it relicenses the entire modified work under GNU GPL". A licence is something you distribute software under, not a static attribute of the software.

Presuming that the patch in question is a creative work sufficiently original to be subject to copyright, that patch can be distributed under whatever licence _or licences_ the author of it chooses.

I don't know if a patch counts as a derived work of the original software, but it probably does - patches often include snippets of the original source code. So the choice of licence for the patch might be constrained by the licence of the original work.

Here the original work does not constrain the choice of licence of derived works, so your patch can be whatever licence you like.

The result of applying the patch is a derivative of both the original work and the patch. So its licence may be constrained by both for third parties. Obviously if the original work is MIT and the patch is GPL then the patch author can still distribute the result of applying the patch under any licence.

But calling it "relicensing" is wrong. The modified version is just a work. It is a derived work of the original software, and of the patch, so how you may distribute it may be constrained, but as it is a work in its own right, when you distribute it under a particular licence you aren't "relicensing" it You are just licensing it.

Point is, each individual instance of a work is its own work, and each individual conveyance of a work from one person to another may be under a different licence. The licence is really a property of that conveyance not of, for example, a project. It is a property of a project only as a social convention: people tend not to license software under different licences every time they distribute it, although someone has probably done that as an artistic statement at least once.

And the other point is that nothing someone does with a patch has any effect on the original software or how it is licensed.

Usual disclaimer, etc. This email is not legal advice.

[NRK]

On Sat, Feb 28, 2026 at 02:28:18PM +0000, Gimmi wrote:
> Is there some kind of implied licenses for the patches once they are
> uploaded?

Some of the other replies already give answers which align with my
understanding of the copyright law as well, so I won't repeat those
points. However, I think this discussion as a whole is heading in a
unproductive theorycelery direction so I'll try and give some practical
perspective here.

In order to avoid ambiguity with copyright/license, larger open source
projects such as the linux kernel require you to sign off your commit
agreeing with it's "Developer's Certificate of Origin":

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1

It's pretty short with only 4 points, so I suggest reading it, but the
tldr is that by signing off your commit you're explicitly stating that
the commit will follow the license of whatever file it modified (if you
wanted to submit under a different (but still compatible) license then
you'd need to create a new file with that license header).

Many other large projects follow a similar rule as well, e.g Gentoo
linux [0], GCC [1] and probably many others. (Note that this is
different than requiring contributor to transfer/assign the copyright to
upstream author, which is what GCC used to require before [1]).

So what about smaller projects that don't have such rule (i.e ~99% of
open-source)? Maybe there's some legal ground for someone to submit
change and then later randomly decide that it has a different license
than the original work. But practically, open-source development is
built upon trust so we expect contributors who spent their free time
submitting patches not to do that.

So unless a patch explicitly states that it has a different license, we
should expect that it follows the same license as the file that it's
modifying. And so unless you live in Germany (this is a joke), I don't
think you're ever going to go to jail for ricing your dwm setup.

[0]: https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
[1]: https://lwn.net/ml/gcc/CAGWvnyme6cQUGb+G4=tesNYqLYBSGnDYb9...@mail.gmail.com/

- NRK

[Gimmi]

Hello,

Suckless works differently: instead of submitting a change to be
incorporated in upstream, you publish a patch that _the user_
incorporates in their software. Practically speaking, this means that a
patch is not a commit in the repository of the software, but on the
wiki. At most we could assume it has the same license as the wiki pages;
however, I could not find the license of the wiki (maybe I didn't look
hard enough).
And this is by assuming an implicit release under the same license of
the repository, which, based also on the overall discussion, is not true
under current copyright law.

>
> So unless a patch explicitly states that it has a different license, we
> should expect that it follows the same license as the file that it's
> modifying. And so unless you live in Germany (this is a joke), I don't
> think you're ever going to go to jail for ricing your dwm setup.

Ricing your own? Probably not. Sharing it? The risk is greater IMO.

>
> [0]: https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
> [1]: https://lwn.net/ml/gcc/CAGWvnyme6cQUGb+G4=tesNYqLYBSGnDYb9...@mail.gmail.com/
>
> - NRK
>

--
Gimmi

[Страхиња Радић]

Дана 26/03/02 11:18AM, Miles Rout написа:
> [...] A licence is something you distribute software under, not a

> static attribute of the software.

It is definitely not a static attribute, but it is related to the
specific work, and it describes the legality of actions upon that work.
The original author may (non-retroactively) alter the license from that
point onward at any time, regardless of the terms.

> Presuming that the patch in question is a creative work sufficiently
> original to be subject to copyright, that patch can be distributed
> under whatever licence _or licences_ the author of it chooses.

> [...]

> Here the original work does not constrain the choice of licence of
> derived works, so your patch can be whatever licence you like.

Yes, of course. However, the author(s) of the original work might
choose to not publish/host/distribute the modified versions of their
work which are licensed under different, more restrictive, licenses
(that they didn't choose for the original in the first place) on their
own website, especially when those licenses state the entire modified
work must be relicensed under that license (GNU GPL does). Given the
terms of particular licenses involved, this doesn't affect the
unmodified, original versions, nor the ability of the author of the

modified version to publish it on his own website. Like you said:

> And the other point is that nothing someone does with a patch has
> any effect on the original software or how it is licensed.

That is also what I am saying.

> But calling it "relicensing" is wrong. The modified version is just a
> work. It is a derived work of the original software, and of the patch,
> so how you may distribute it may be constrained, but as it is a work in
> its own right, when you distribute it under a particular licence you
> aren't "relicensing" it You are just licensing it.

Wikipedia[1] defines "relicensing" as modifying the license of a work
when combining it with another work, if the licenses aren't
"compatible". (This seems to be meant in the "cohabitation" sense; this
isn't "compatibility" as defined by FSF. They define it as the ability
for a license to be changed to GNU GPL.) Since the GNU GPL requires the
entire work be licensed under GNU GPL, when publishing/distributing the
work created by applying the patch licensed under it, the license of
the part of the combined modified work which comes from the original
work must be changed (relicensed) to GNU GPL in order to comply with
its terms.

So, it *is* relicensing.


[1]: https://en.wikipedia.org/wiki/Software_relicensing