Hi dear fellow Debian developers,
When I package a project for inclusion into Debian, I commonly license
my packaging work using a copyleft license?.
I appreciate that upstream authors may have reasons to choose different >licensing, and am open to relicense non-packaging parts (e.g. patches). >Sometimes I proactively license patches potential for upstream adoption
same as upstream, but generally I don't - patches are often arguably
too small to be copyright-protected, or might contain contributions
from multiple authors - in short, it is simpler for me to ensure that
the packaging parts are all DFSG-free than that they are all compliant
with upstream choice of licensing, and I see no need for the packaging
part to be compliant with upstream choice of licensing.
My question here is: Am I doing a disservice to Debian? Do Debian
already have a Policy about this? If not, should we add one?
Hi dear fellow Debian developers,*shrug*
When I package a project for inclusion into Debian, I commonly license
my packaging work using a copyleft license?.
I appreciate that upstream authors may have reasons to choose different >licensing, and am open to relicense non-packaging parts (e.g. patches). >Sometimes I proactively license patches potential for upstream adoption
same as upstream, but generally I don't - patches are often arguably
too small to be copyright-protected, or might contain contributions
from multiple authors - in short, it is simpler for me to ensure that
the packaging parts are all DFSG-free than that they are all compliant
with upstream choice of licensing, and I see no need for the packaging
part to be compliant with upstream choice of licensing.
My question here is: Am I doing a disservice to Debian?
Do Debian already have a Policy about this?No, but AFAIK the project consensus is "a simple permissive license or the same license as the upstream; but also maybe the license doesn't matter because it's not copyrightable".
If not, should we add one?"You must license your packaging under these licenses" seems unusual to me
I appreciate that upstream authors may have reasons to choose different licensing, and am open to relicense non-packaging parts (e.g. patches). Sometimes I proactively license patches potential for upstream adoptionI think it is generally best for the debian/* licensing to match the upstream licensing. Unless there is some compelling reason why it should be different (so far, I have never come across an example of such a reason), I think it should be the default behavior for Debian packaging.
same as upstream, but generally I don't - patches are often arguably
too small to be copyright-protected, or might contain contributions
from multiple authors - in short, it is simpler for me to ensure that
the packaging parts are all DFSG-free than that they are all compliant
with upstream choice of licensing, and I see no need for the packaging
part to be compliant with upstream choice of licensing.
I agree with others that matching the package licensing is reasonable, although as we often see, bigger and larger
packages tend to have a mixture of licenses, in which case we typically choose the most free license for the package.
Occasionally, I run into problems with more advanced packages, and then find that Arch Linux of Gentoo have found a good
solution to it, and I use it. When I've already spent some hours to a packaging solution in Debian, I want it to be
available as widely as possible to others in the same manner with as little friction as possible. So, I think if I had
to default on something else that "same as packaging", I'd use something like CC0 or something that is equally
permissive.
On Fri, 30 Jan 2026 14:04, Jonas Smedegaard <dr@jones.dk> wrote:
My question here is: Am I doing a disservice to Debian? Do Debian
already have a Policy about this? If not, should we add one?
While I prefer strong copyleft licenses I *always* license my packaging
under the same license as upstream.
Jonathan Carter <jcc@debian.org> writes:Would you (the plural you - all those responding so far, and everyone
I agree with others that matching the package licensing is reasonable, although as we often see, bigger and larger
packages tend to have a mixture of licenses, in which case we typically choose the most free license for the package.
Occasionally, I run into problems with more advanced packages, and then find that Arch Linux of Gentoo have found a good
solution to it, and I use it. When I've already spent some hours to a packaging solution in Debian, I want it to be
available as widely as possible to others in the same manner with as little friction as possible. So, I think if I had
to default on something else that "same as packaging", I'd use something like CC0 or something that is equally
permissive.
I recently thought about this specific problem for reasons I can't now remember, and arrived at the conclusion that CC0 is probably the best
license one can choose for packaging.
For the most part the packaging is unlikely to be copyrightable anyway
so assigning a license that has restrictions only makes things harder
for the friendly folks who care about license compatibility and are
unwilling to unilaterally decide that copyright doesn't apply.
Potentially making things difficult for good free software citizens
without in any way affecting the not so friendly folks seems counterproductive to me.
Would you (the plural you - all those responding so far, and everyoneI would prefer to not spend time on this, life is too short and we are
reading this who has voting power in Debian) prefer that Debian
considered "too-strictly-free" packaging a release-critical bug and
reason for rejection in NEW queue screening?
Imagine a proposal was made to extend Debian Policy with a rule, that >packaging must be upstreamable - i.e. that packages licensed moreI wouldn't vote for one that requires NEW rejection. I may vote for it
strictly free than that of the contained project must be *rejected* at
the NEW queue screening, and packages already in the archive with such
"too strictly free" licensing should? be either corrected or dropped.
Would you vote for or against such a proposal?
When I package a project for inclusion into Debian, I commonly license
my packaging work using a copyleft license?.
What triggers me in asking this is that, as part of a recent NEW queue >processing, this pattern of mine was noticed and questioned.
Short summary, how about a new `Packaging:` field in machine-readable `debian/copyright` files?we
[My answer below was proof-read by MS Copilot]
Le Fri, Jan 30, 2026 at 02:04:44PM +0100, Jonas Smedegaard a ‚crit :
When I package a project for inclusion into Debian, I commonly license
my packaging work using a copyleft license?.
What triggers me in asking this is that, as part of a recent NEW queue >processing, this pattern of mine was noticed and questioned.
My experience is almost the opposite: when I generate a new package
using automated scripts, I don?t want to claim copyright on the
packaging. Unfortunately, this has been considered mandatory?the
previous team rejected packages without explicit license statements for
files under debian/.
To comply, many maintainers simply reuse the upstream license for
debian/*, which becomes messy when upstream later relicenses (common in
some ecosystems). And as Matthias noted, using a different license for packaging plus the machine?readable format adds overhead whenever
introduce new upstream patches.iting
It would help to have a default mechanism for maintainers who prefer to
waive as much copyright as possible without spending time hand?ed
debian/copyright.
Perhaps we could define a standard Comment or a new Packaging field inxplanation:
the machine?readable format pointing to a Debian?hosted e
that most packaging work is not copyrightable, that some files may carry upstream copyright, and that maintainers otherwise place their
contributions in the public domain (or equivalent).
I recently thought about this specific problem for reasons I can't now remember, and arrived at the conclusion that CC0 is probably the best
license one can choose for packaging.
Would you (the plural you - all those responding so far, and everyone
reading this who has voting power in Debian) prefer that Debian
considered "too-strictly-free" packaging a release-critical bug and
reason for rejection in NEW queue screening?
My question was not which licens each individual developer would choose
but whether Debian as a project should consider copyleft licensing bad.
I understand and appreciate that we do not agree on what licensing is
ideal.
Imagine a proposal was made to extend Debian Policy with a rule, that >packaging must be upstreamable - i.e. that packages licensed more
strictly free than that of the contained project must be *rejected* at
the NEW queue screening, and packages already in the archive with such
"too strictly free" licensing should? be either corrected or dropped.
When I package a project for inclusion into Debian, I commonly licenseI think all DFSG-compatible licenses should be OK for debian/*.
my packaging work using a copyleft license?.
(?)
My question here is: Am I doing a disservice to Debian? Do Debian
already have a Policy about this? If not, should we add one?
What triggers me in asking this is that, as part of a recent NEW queue processing, this pattern of mine was noticed and questioned. I don'tI guess it?s OK for the NEW processing team to ask if you did that
think that question is a relevant part of NEW queue processing, but
instead of letting that being a discussion between me and that one
helpful developer screening the package, or between me and the team,
I consider it more appropriately a discussion in Debian in general.
Imagine a proposal was made to extend Debian Policy with a rule, that packaging must be upstreamable - i.e. that packages licensed more
strictly free than that of the contained project must be *rejected* at
the NEW queue screening, and packages already in the archive with such
"too strictly free" licensing should? be either corrected or dropped.
Would you vote for or against such a proposal?
I appreciate that upstream authors may have reasons to choose different licensing, and am open to relicense non-packaging parts (e.g. patches).
Would you (the plural you - all those responding so far, and everyone
reading this who has voting power in Debian) prefer that Debian
considered "too-strictly-free" packaging a release-critical bug and
reason for rejection in NEW queue screening?
If the packaging and the upstream source have different licenses, ISome projects in Debian already without problems involve multiple
wonder what is the license on the resulting package -- both source and binary?
But can you say that debian/rules and other packaging are also separate components which the binary package is not a derivative work of?If the packaging and the upstream source have different licenses, I
wonder what is the license on the resulting package -- both source and
binary?
Some projects in Debian already without problems involve multiple
licenses, e.g. one license for code to be compiled together, maybe
another for components linkable with independently compiled code, and
maybe a third for some documentation.
I am not talking about is copyleft-licensing something which is patchedIt wasn't clear that you explicitly exclude debian/patches/ from the discussion and your questions. You even mentioned that "Sometimes I proactively license patches potential for upstream adoption
into upstream-licensed code and therefore causing Debian to
redistribute upstream works relicensed compared to their own licensing.
However, If you do claim that it is copyrightable by putting a licenseI agree with that, but there are plenty of examples of the contrary in well-established parts of Debian. Many Debian maintainers disagree with upstream maintainers on a wide variety of matters, including licensing (example: refusing to package GFDL documentation, even without Invariant sections, or refusal to contribute back improvements on anything
on it, I think using a different license than upstream is poor
form. Packaging someone's work is, hopefully, a respectful and
collaborative activity with upstream where they'll accomodate reasonable requests from the packager, and vice versa. Choosing a different
license than upstream seems like adding unnecessary friction to that relationship. (This assumes a free license for the upstream code, if
it's non-free, I'd say different expectations apply.)
It wasn't clear that you explicitly exclude debian/patches/ from the discussion and your questions. You even mentioned that "Sometimes I proactively license patches potential for upstream adoption
same as upstream, but generally I don't".
On Mon, 2026-02-02 at 19:27 +0500, Andrey Rakhmatullin wrote:
It wasn't clear that you explicitly exclude debian/patches/ from the discussion and your questions. You even mentioned that "Sometimes I proactively license patches potential for upstream adoption
same as upstream, but generally I don't".
Note that, for example, the GPL-2 contains this:
"For an executable work, complete source code means all the source code
for all modules it contains, plus any associated interface definition
files, plus the scripts used to control compilation and installation of
the executable."
The Debian packaging is (IMHO) "scripts used to control compilation and installation of the executable". Thus the GPL-2 requires these to be
included under GPL-2-compatible terms.
Quoting Gerardo Ballabio (2026-02-02 13:04:49)
If the packaging and the upstream source have different licenses, I
wonder what is the license on the resulting package -- both source and binary?
Some projects in Debian already without problems involve multiple
licenses, e.g. one license for code to be compiled together, maybe
another for components linkable with independently compiled code, and
maybe a third for some documentation.
I am not talking about is copyleft-licensing something which is patched
into upstream-licensed code and therefore causing Debian to
redistribute upstream works relicensed compared to their own licensing.
I am only talking about copyleft-licensing non-upstream-affecting
packaging parts.
I am also not talking about things not copyright-protectable: We all
claim copyright for packaging and license that copyright-claimed stuff,
so any discussion of whether those copyright claims are bogus and what problems such bogus claims might cause, is orthogonal to the choice of license.
My question is also not whether *you* should copyleft-license *your* contributions to Debian. I am only asking if you would prefer that copyleft-licensed contributions was unacceptable in Debian.
Related to that, I now (since yesterday) add the following section to
the debian/copyright file of packages that I maintain:
Files: debian/patches/*
Copyright: None
License: None
Comment:
Patches are generally assumed not copyright-protected by default.
Please list any patch with copyright claims separately.
In what you quote, I can see how "an executable work" can affect the licensing of directly related "scripts used to control [it]", but not
the other way around.
I.e. I can only read the quote as saying, that a strongly licensed work cannot be weakened by weaker licensed helper tools. I am unable to read
it as saying that stronger licensed helper tools affect the licensing
of what they help getting built.
Jonas Smedegaard <dr@jones.dk> writes:Ok, so my wording is bad. But I suspect that your understanding is off
Related to that, I now (since yesterday) add the following section to
the debian/copyright file of packages that I maintain:
Files: debian/patches/*
Copyright: None
License: None
Comment:
Patches are generally assumed not copyright-protected by default.
Please list any patch with copyright claims separately.
So far as I understand current coypright case law, the first sentence is factually incorrect as stated. I'm not sure that matters, since presumably
it should be read as a statement of your beliefs, and even if those
beliefs are not legally correct, they probably could be argued to
constitute some type of promissary estoppel against you ever making a copyright claim for the content of the patches. But it does leave things
in a somewhat ambiguous place.
I agree with that, but there are plenty of examples of the contrary in well-established parts of Debian. Many Debian maintainers disagree with upstream maintainers on a wide variety of matters [...]
I think this is generally unproductive and leads to poor relationship
between Debian and upstreams.
What I mean to say is, instead, "this section contains works that I
cannot meaningfully state copyright and licensing for as a whole but
also cannot meaningfully inherit from the superset of debian/* (and the superset of debian/* I cannot meaningfully omit because at least
copyright is unlikely to be same for packaging as for upstream work),
because each of the patches either a) is not copyrightable, or b) was cherry-picked upstream so potentially (but not necessarily) have same copyright and license as upstream project (i.e. not the nearest
superset section of debian/* in the machine-readable inheritance logic,
but topmost superset of *), or c) was created by the same authors as in
the superset section of debian/* so potentially (but not necessarily)
have same copyright and licensing as the packaging (which might be same
as upstream but maybe not), or d) was created by others than both
upstream and Debian packaging (e.g. contributed in a bugreport) so may
have any license and certainly differing copyright".
In summary, personally I would align licensing between packaging andRuss, thank you for the extensive analysis (of which, for space reasons, I have only quoted the final three paragraphs above). I agree with your conclusions and appreciate your humor in explaining the complexities of this subject.
upstream when choosing a license because I think it makes everything
simpler and more predictable, and when you are not getting legal
agreements from contributors, I think one is under some degree of moral obligation to not do anything surprising. But I don't think it's some
great sin if you don't do that, *provided* that you do not do things that cause surprising things to happen to the licensing of binaries produced by upstream.
And, in answer to your *actual* question, I think trying to explain all of these subtleties in debian/copyright is a lost cause and I am dubious you will gain all that much from trying. I think my best suggestion is to say that debian/patches/* is under the same license as the upstream code
because this will almost always be correct in practice. Certainly if
you're pulling those patches from upstream, that's a reasonable assumption
to make. If upstream code is under a bunch of different licenses and the patches are therefore under a bunch of different licenses, I would
probably do something annoying like list all the possible licenses as a conjunction (with "and") and then add a comment saying that each patch is under the same license as the file it is patching. (Or write separate
license clauses for every patch, but gah.)
For the rest of the packaging files, I think you can do whatever you're
doing now, but I would personally encourage you, at least a little, to consider aligning with upstream's licensing just on the grounds of
reducing community friction and avoiding unpleasantly surprising
contributors (and getting into extended and time-consuming discussions
like this one). I personally think those benefits outweigh whatever relatively minor benefits you would get from choosing a personally
preferable license for Debian packaging files where the precise licensing terms are unlikely to ever matter in practice. But this is just my
personal opinion and the advice is worth what you paid for it. :)
What nearly every free software project does in practice is make an assumption. That assumption goes roughly like this:[...]
You voluntarily submitted your work to my project and asked for it to
be included, so I am going to assume that this means you agree to the
standard conventions of free software and are okay with your work
being included under the free software license that the work is
already covered by. Asking you to confirm this explicitly is annoying
and requires another back-and-forth, so I'm just going to assume we're
all adults here and you wouldn't have sent me the patch if you didn't
want me to use it.
This is not legally rigorous, but it's also not *entirely* void of legal meaning either. There are a bunch of legal concepts sort of vaguely
floating around in this area that have names like "promissary estoppel"
that I am not even remotely qualified to analyze, but which roughly amount to a general informal principle that people are entitled to assume that
you are a reasonable person and you mean what you are clearly implying. If you try to sue someone for incorporating a patch that you sent them for incorporation, it's not an unreasonable assumption that a judge is going
to ask questions like "if you didn't want them to use your patch, why did you send it to them" and "if you didn't want your work covered under the same license as the software you submitted it to, why didn't you say so"
and arrive at reasonable conclusions.
The popularity of the legal workarounds you enumerated also vary
somewhat by license, owing in great part to the fact that not all
free/libre open source software licenses these days are purely copyright licenses: some also require patent grants, and for even longer we've had
some that mandated or restricted certain uses of associated trademarks
as well (thankfully not en vogue in recent years). So, depending on what additional sorts of intellectual property a license might cover, the project's legal counsel may push for stronger binding contracts to make
sure the intent is clear... especially since IP like patents and
trademarks tend to be jurisdiction-dependent and aren't covered by broad international convention the way copyright has been.
Tollef Fog Heen <tfheen@err.no> writes:
However, If you do claim that it is copyrightable by putting a license
on it, I think using a different license than upstream is poor
form. Packaging someone's work is, hopefully, a respectful and collaborative activity with upstream where they'll accomodate reasonable requests from the packager, and vice versa. Choosing a different
license than upstream seems like adding unnecessary friction to that relationship. (This assumes a free license for the upstream code, if
it's non-free, I'd say different expectations apply.)
I agree with that, but there are plenty of examples of the contrary in well-established parts of Debian. Many Debian maintainers disagree with upstream maintainers on a wide variety of matters, including licensing (example: refusing to package GFDL documentation, even without Invariant sections, or refusal to contribute back improvements on anything
licensed under the GFDL)
or cryptographic choice (example: Debian
patches GnuPG away from upstream wishes, introducing incompatibility).
I believe that kind of behaviour and attitude often is a consequence of
the strong package-ownership model in Debian, where a Debian package maintainer regard themselves as owner of a package to such an extent
that they are privileged enough to ignore requests from upstream or
other parts of Debian. I do not see the same extent of that behaviour
in communities without strong package ownership.
IMHO, if a Debian package maintainer has a strong enough idea of how
some upstream package should behave, that is incompatible with upstream,
they should fork the project, rather than adding patches in Debian to
their own liking. This is the FOSSy respectful way to act if you
disagree with project decisions, and this option needs to be feasible in
a health FOSS eco-system. Patching project X into something else and shipping it as project X is disrepectful.
It feels like problems with for example weak/team maintainership alwaysI agree with the above. There are pros and cons to both strong and weak maintainership models. Neither one guarantees that a packages will be well maintained, but there are good examples of packages being well maintained under both models.
get obviated in this kind of commentary. Such as, it shifting
disagreement from maintainer vs user to internal team strife *and*
team vs user, it substantially increasing communication and consensus overhead, both of which can very easily either cause "edit wars" or "paralysis by lack of consensus", or feelings of rudeness or unease
when one internal faction plows ahead regardless of consensus. It
might make maintainers have to work closer than desired with people
they'd rather keep at a distance with, besides the minimum required,
say via bug reports or whatever else. It makes having a coherent vision
of how the package is being maintained harder to understand from outside, both from upstream and within the project. It makes it harder to invest
in deep understanding of how the upstream code works. It makes it harder
to have a reliable and clear contact point of interest from outside and within the project. It makes it harder to have a long-standing
relationship with upstream and knowing/understanding each other's quirks, requirements, preferences or disagreements. It makes unmaintained packages more difficult to track, it makes inactive teams more difficult to deal
with and detect. It makes trying and experimenting with different packaging styles or techniques harder, because one has to justify diverting from
any team practices, for something that might well be a dead end. People
feel way less responsible for packages, as supposedly "someone else in
the team can take care of it". Etc.
. . .
A weak ownership team is not inherently a better way to maintain
packages, and I'd not like to see this reductionist maintainership view
keep being pushed across the project.
This is a really good point. I did not think about patent licenses, but indeed those are a completely different problem with different tradeoffs.And to be clear, this isn't a niche challenge. There are, for
For example, I suspect one of the most common failure modes, legally, of[...]
the standard community assumption about free software licensing is when someone submits a patch on employer time without getting explicit
permission from their employer to release the work as free software. Depending on local laws, work contracts, etc., that patch may be owned by their employer under work-for-hire laws and the person submitting it may have no legal right to agree to anything regarding it.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 119:52:50 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,568 |
| Posted today: | 26 |