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?
Personally I think not. I think that Debian is about DFSG, not about
lowering politically to the lowest common denominator.
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't
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.
To clarify, I am not asking if copylef is more virtuous or a virus.
Also, I am not asking if it is simpler to go with the flow. I am
asking if it is bad for Debian to have licensing opinions, within the
scope of DFSG.
Kind regards,
- Jonas

? Nowadays I mostly use GPL-3+ but that varies slightly. I don't mind elaborating on when I choose which license specifically, but consider
such detalis unimportant for the topic of this email.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 30 Jan 2026 14:04, Jonas Smedegaard <dr@jones.dk> wrote:

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,

afaik we do not have a strict policy / clear wording on this.
While I prefer strong copyleft licenses I *always* license my packaging
under the same license as upstream. This follows the rationale that if I
had to send a patch upstream, it is under the same license as upstream.

Similarly, if an upstream commit is clearly licensed as e.g. GPL-3, and
if I would include that in debian/* while claiming debian/* is
MIT-licensed,
I would violate the GPL's terms.

best,

werdahias

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, Jan 30, 2026 at 02:04:44PM +0100, Jonas Smedegaard wrote:

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?

*shrug*
I haven't been in situations where this matters, but I may have seen discussions of those a couple of times.
It's certainly one of those things that may force people to spend more
time and brain power on such packaging in various situations though.

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
as a written policy, but maybe it's fine.

--
WBR, wRAR


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Friday, January 30, 2026 6:04:44?AM Mountain Standard Time Jonas Smedegaard wrote:

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.

I 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.
--
Soren Stoutner
soren@debian.org


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Jonathan Carter <jcc@debian.org> writes:

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.

--
Arto Jantunen

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-30 16:10, Matthias Geiger wrote:

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.

Same here. Both parts of the sentence.

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Quoting Arto Jantunen (2026-01-31 09:19:00)

Jonathan Carter <jcc@debian.org> writes:

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 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.
Would you vote for or against such a proposal?
- Jonas
? Maybe very slowly - similarly to how we are still carrying fonts that
have source available but not yet are built from source, for many
years.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, Jan 31, 2026 at 12:08:04PM +0100, Jonas Smedegaard wrote:

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?

I would prefer to not spend time on this, life is too short and we are
already spending too much time on licensing-related minutes.
Also "a release-critical bug" and "reason for rejection in NEW queue screening" don't necessarily go together.

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 wouldn't vote for one that requires NEW rejection. I may vote for it
being an RC bug but fixing those in existing packages where the original copyright holder may be unavailable or unwilling to relicense it may
usually be impossible (and also useless if it's not copyrightable?).

--
WBR, wRAR


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Short summary, how about a new `Packaging:` field in machine-readable `debian/copyright` files?

[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 we
introduce new upstream patches.

It would help to have a default mechanism for maintainers who prefer to
waive as much copyright as possible without spending time hand?editing debian/copyright.

Perhaps we could define a standard Comment or a new Packaging field in
the machine?readable format pointing to a Debian?hosted explanation:
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).

Have a nice day,

Charles

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Quoting Charles Plessy (2026-01-31 10:33:06)

Short summary, how about a new `Packaging:` field in machine-readable `debian/copyright` files?

[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

we

introduce new upstream patches.

It would help to have a default mechanism for maintainers who prefer to
waive as much copyright as possible without spending time hand?ed

iting

debian/copyright.

If I understand you correctly, you seek to permit most possible users
to do most possible with your contributions, including their chooing
to share their further development without such freedoms?

I see no problem with that preference of licensing: As Jonathan
mentions, then simply aim as relaxed as possible, e.g. license your contributions as CC0.

Perhaps we could define a standard Comment or a new Packaging field in
the machine?readable format pointing to a Debian?hosted e

xplanation:

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 see no need for special fields to express this. The expression, using existing lingo, is this:

Files: debian/*
Copyright: Jonas Smedegaard <dr@jones.dk>
License: CC0

Yes, you might argue that putting your name there is problematic, but
what is says is *who* stated that they want to waive most possible
rights.

The problem I raise - which so far I am alone in having concerns over,
it seems - is that I want to share my contributions with anyone that
values DFSG. I want to respect upstream eventually different choice by licensing anything that is extending on their work under their terms,
but I have no desire for embracing their terms for creative works not
built upon theirs.

- Jonas


? As you no doubt know already, but mentioning in case others less well
versed in this stumbled upon my post as well: Copyleft is essentially
about ensuring future commitment to protecting the four freedoms of Free software.

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi all,

On Sat Jan 31, 2026 at 9:19 AM CET, Arto Jantunen wrote:

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.

Just a small comment: CC0 is (was?) seen as problematic by some[1][2],
so a simpler license like the FSFAP[3][4], the ISC[5], or the 0BSD[6]
would probably be more appropriate for simple packaging files.

The ISC is endorsed by both the OSI and FSF, the FSFAP only by the FSF,
and the 0BSD is endorsed by the OSI while discouraged[7] by the FSF.

But, for the record, I think that licensing packaging work under the GPL
is fine, and probably does not matter that much anyway.

Bye!

[1]: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraprojec t.org/thread/RRYM3CLYJYW64VSQIXY6IF3TCDZGS6LM/
[2]: https://www.gnu.org/licenses/license-list.html.en#CC0
[3]: https://spdx.org/licenses/FSFAP.html
[4]: https://www.gnu.org/licenses/license-list.html.en#GNUAllPermissive
[5]: https://spdx.org/licenses/ISC.html
[6]: https://spdx.org/licenses/0BSD.html
[7]: https://www.gnu.org/licenses/license-list.html.en#Zero-BSD

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 31 Jan 2026 12:08, Jonas Smedegaard <dr@jones.dk> wrote:

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.

I would not be for such a strict proposal. Though I could get behind an addition to policy like this:
"""
It's recommended to license the packaging work (i.e. the debian folder)
under the same terms as upstream. This ensures that cherry-picked
upstream patches do not cause a license violation.

For instance, if a project has the following copyright stanza:


Files: *
Copyright: 2020 Alice Dev
License: GPL-3

...

you might license the packaging work itself like this:

Files: debian/*
Copyright: 2026 Daniela Debian
License: GPL-3

"""
Might need better wording; ESL speaker here.

Also, as (random) datapoint:
AFAIK, the rust team, the GNOME team, the KDE team and the vim team
already use said licensing. Not sure about the other teams. When I
started contributing I was told to use this style.

best,


werdahias

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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?.
(?)
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?

I think all DFSG-compatible licenses should be OK for debian/*.
Sticking with upstream license seems to be the recommended default,
but I see no reason to turn that into a policy point or a criteria
for rejection.
If that were to change, I think a new lintian check would be a good first step. Still I don?t think it needs to change. The current system with the license choice left to the appreciation of the people actually working on the packaging seems to be working well already.

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

I guess it?s OK for the NEW processing team to ask if you did that
as a conscious choice, or if you put a license "at random" on debian/*.
As long as it does not lead to a rejection on a basis outside of our policy, discussion is usually a good thing.


--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

.

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?

+1 for this

--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F



--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Jonas Smedegaard <dr@jones.dk> writes:

I appreciate that upstream authors may have reasons to choose different licensing, and am open to relicense non-packaging parts (e.g. patches).

I think the patches are the important part. In that specific case, if the upstream code is under a permissive non-copyleft license, I think it would
be highly surprising to our users if your patches were under a copyleft license, thus effectively changing the license of the binary package to a copyleft license.

Users are not going to expect that Debian is going to change the licensing
of some package, particularly a well-known package, from, say, MIT to
GPLv3. They are very, very likely to not check the debian/copyright file
if they know the upstream license via upstream, and will just assume the
Debian package is covered by the same terms under which upstream released
their code. I think that if we did something to violate that assumption,
it would be rather rude, even though it's often a legally permissible
thing for us to do.

If you're talking about just the Debian packaging files and you don't
believe that affects the license of the resulting binaries (particularly
for libraries and the like where they are often used as part of derived
works), I don't think it matters what license you use as long as it's DFSG-free. I've encountered Debian packages like that before, where
upstream is covered by a permissive non-copyleft license but the Debian packaging files (rules, etc.) are covered by the GPL. It's a little
surprising but I can't think of any concrete problem it creates.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

]] Jonas Smedegaard

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?

mu.

Like a few others in the thread, as a general rule, I don't consider the packaging as copyrightable. (There are obviously counterexamples to
this.)

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 don't think violating this expectation and social norm is grounds for rejection from NEW, but having the reviewer note it and give you some
friction for it seems appropriate to me.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--- PyGate Linux v1.5.8
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)