Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #14113 > unrolled thread

is copyleft packaging bad for Debian?

Back to article view | Back to linux.debian.project

Contents

  is copyleft packaging bad for Debian? Jonas Smedegaard <dr@jones.dk> - 2026-01-30 15:50 +0100
    Re: is copyleft packaging bad for Debian? Matthias Geiger <werdahias@riseup.net> - 2026-01-30 17:40 +0100
      Re: is copyleft packaging bad for Debian? Martin <debacle@debian.org> - 2026-01-31 12:30 +0100
    Re: is copyleft packaging bad for Debian? Soren Stoutner <soren@debian.org> - 2026-01-30 17:40 +0100
    Re: is copyleft packaging bad for Debian? Andrey Rakhmatullin <wrar@debian.org> - 2026-01-30 17:40 +0100
    Re: is copyleft packaging bad for Debian? Arto Jantunen <viiru@debian.org> - 2026-01-31 10:40 +0100
      Re: is copyleft packaging bad for Debian? Jonas Smedegaard <dr@jones.dk> - 2026-01-31 12:30 +0100
        Re: is copyleft packaging bad for Debian? Andrey Rakhmatullin <wrar@debian.org> - 2026-01-31 12:50 +0100
        Re: is copyleft packaging bad for Debian? Matthias Geiger <werdahias@riseup.net> - 2026-01-31 17:30 +0100
        Re: is copyleft packaging bad for Debian? Mechtilde Stehmann <mechtilde@debian.org> - 2026-01-31 18:00 +0100
        Re: is copyleft packaging bad for Debian? Tollef Fog Heen <tfheen@err.no> - 2026-01-31 20:50 +0100
          Re: is copyleft packaging bad for Debian? Simon Josefsson <simon@josefsson.org> - 2026-02-02 16:20 +0100
            Re: is copyleft packaging bad for Debian? "Andrea Pappacoda" <andrea@pappacoda.it> - 2026-02-03 15:10 +0100
            Re: is copyleft packaging bad for Debian? Guillem Jover <guillem@debian.org> - 2026-02-04 10:50 +0100
              Re: is copyleft packaging bad for Debian? Soren Stoutner <soren@debian.org> - 2026-02-04 18:30 +0100
      Re: is copyleft packaging bad for Debian? "Andrea Pappacoda" <tachi@debian.org> - 2026-01-31 17:10 +0100
      Is Packaging Copyrightable (was: is copyleft packaging bad for Debian?) Soren Stoutner <soren@debian.org> - 2026-02-02 20:10 +0100
        Re: Is Packaging Copyrightable Martin <debacle@debian.org> - 2026-02-02 21:50 +0100
          as any other metadata + code expression  Question: Is Packaging Copyrightable Yaroslav Halchenko <yoh@debian.org> - 2026-02-03 00:30 +0100
        Re: Is Packaging Copyrightable Tollef Fog Heen <tfheen@err.no> - 2026-02-02 23:00 +0100
          Re: Is Packaging Copyrightable Soren Stoutner <soren@debian.org> - 2026-02-02 23:40 +0100
    Re: is copyleft packaging bad for Debian? Antoine Le Gonidec <vv221@debian.org> - 2026-01-31 17:40 +0100
    Re: is copyleft packaging bad for Debian? Russ Allbery <rra@debian.org> - 2026-01-31 20:00 +0100

Page 1 of 2  [1] 2  Next page →

#14113 — is copyleft packaging bad for Debian?

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#14114

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

[toc] | [prev] | [next] | [standalone]

#14120

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.

[toc] | [prev] | [next] | [standalone]

#14115

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#14116

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#14118

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

[toc] | [prev] | [next] | [standalone]

#14119

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#14122

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#14126

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

[toc] | [prev] | [next] | [standalone]

#14128

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#14130

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

[toc] | [prev] | [next] | [standalone]

#14134

[Multipart message — attachments visible in raw view] — view raw

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 think this is generally unproductive and leads to poor relationship
between Debian and upstreams.

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.

/Simon

[toc] | [prev] | [next] | [standalone]

#14146

Hi all,

On Mon Feb 2, 2026 at 2:35 PM CET, Simon Josefsson wrote:
> 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.

While sometimes this can be true, it is also true that upstream projects 
often live in a bubble. In Debian, we need to make sure everything fits 
coherently together; hence: patching. So I'd say this isn't as bad as it 
looks.

Bye :)

[toc] | [prev] | [next] | [standalone]

#14153

Hi!

On Mon, 2026-02-02 at 14:35:12 +0100, Simon Josefsson wrote:
> 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)

I'm assuming this refers to (or brings to mind) our past and recent
interaction about inetutils. Although I think this characterization is
inaccurate. inetutils upstream used to ship and maintain the original
BSD man pages, then around 2000, alternative texi/info documents started
to be written, culminating in 2009 when the original man pages got
completely removed, and replaced with the output of --help (which is
not very useful, TBH).

In Debian the info documents had never been packaged, because they just
didn't exist initially, and later the man pages were going to keep being
more convenient anyway (they have IMO a better reader UI, we get
automatic stuff like manpages.d.o per release, they can be shipped in the
same package as the tool w/o needing to pull in an inetutils-doc package
and an info reader). This was and has been mainly all a practical concern,
with the license annoyance being way secondary. And as long as we have the
forked man pages there's not much point in duplication with the info one
and needing to go through NEW with an added package.

Because Debian does not currently ship the info docs, when I patch
things I only do that for the local man pages. When submitting upstream
there's no matching and pre-existing info change, *and* because I don't
agree with the GFDL, as a contributor I don't feel compelled to license
changes I make in that license, so I don't do the changes. I'd assume
this is understandable to someone who has strong reactions to for
example Debian stances on licensing and distribution of non-free stuff.

> or cryptographic choice (example: Debian
> patches GnuPG away from upstream wishes, introducing incompatibility).

Well, I guess we'll have to agree to disagree here. GnuPG upstream
forked the specification in an incompatible way, causing ecosystem wide
interoperability problems. Because Debian is heavily invested in
OpenPGP, from upstream signing their artifacts, and from maintainers
signing Debian's artifacts, I think it's completely justified to take
a side in the OpenPGP schism. In addition interoperability problems are
suffered as well both by programs writers/maintainers that use OpenPGP
related tools, who have to deal with this fallout, as well as users who
will end up being unable to interop when communicating with counterparts
or when verifying artifacts from others or similar. I also don't think
the lock-in that GnuPG has managed to acquire on the ecosystem over the
years is healthy at all, more so given all the problems with its UI and
implementation, and I'm glad an invigorated and fresh OpenPGP ecosystem
with multiple implementations has been surfacing over the past years.

The GnuPG interop fallout management is not something that Debian is
doing alone, multiple major distributions are doing this as well, with
completely different maintainership styles.

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

Every time I see the "strong package ownership" complaint it always
feels a proxy for "I don't agree with something a maintainer did",
and "if this was maintained differently, then I'd have my way".

Both team and solo maintainership and strong and weak versions of each
have pros and cons. This constant daemonizing of the non-team/non-weak
maintainership parts of the project is a bit tiring.

It feels like problems with for example weak/team maintainership always
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.

And just to be clear, I am and have been part of teams with different
levels of "ownership", and I think that's fine. In Debian we have
great examples of teams that seem to run very smoothly, but I don't
think this is universally true, because we also have completely
dysfunctional teams, and then teams in-between.

It also matters whether the things to maintain are somewhat uniform or
not and the shape of upstream (both in software and people). We also
see people strongly disagreeing with decisions coming from maintainer
teams, where I fail to recall anyone calling for the dissolution of
team maintainership in general, because they cannot get their way.

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.

(BTW GnuPG is maintained by a team in Debian.)

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

Well I guess we'll have to agree to disagree here as well. IMO part of
the job in Debian is to have a coherent and interworking set of
software that operates together, taking into account how that affects
users. If this conflicts with upstream, then IMO whatever is best for
Debian I think trumps over upstream concerns, and barring that, the
software should IMO get removed from Debian. Also part of the point of
FOSS is to be able to modify the code to fit ones needs. I mean I get
software I develop/maintain modified in ways I think are either not
good/ideal or wrong, and I might recommend downstream to do otherwise,
but if they disagree, well they are free to do so as stated in the
license, I'm not sure why I'd get mad or feel disrespected.

Of course having a good relationship with upstream is ideal, and
agreeing on everything with upstreams is always going to be a smoother
experience, but I don't think that's always in the best interest of
Debian (or any other distribution) or its users for example.

Thanks,
Guillem

[toc] | [prev] | [next] | [standalone]

#14154

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, February 4, 2026 2:38:13 AM Mountain Standard Time Guillem Jover 
wrote:
> It feels like problems with for example weak/team maintainership always
> 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.

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

I prefer a strong maintainership model as long as the maintainer is doing a 
good job.  Personally, I prefer to have at least one co-maintainer where we 
communicate well, are both on the same page as to how to handle the package, 
and both have a relationship with upstream.  All of the complaints against a 
strong maintainership model have to do with the maintainer not doing a good 
job.  Usually that is through inactivity, but occasionally it is through 
active participation in negative ways.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#14125

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

[toc] | [prev] | [next] | [standalone]

#14136 — Is Packaging Copyrightable (was: is copyleft packaging bad for Debian?)

[Multipart message — attachments visible in raw view] — view raw

On Saturday, January 31, 2026 2:44:42 AM Mountain Standard Time Ilu wrote:
> Am 31.01.26 um 09:19 schrieb Arto Jantunen:
> > 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
> 
> ^^ This.
> 
> > 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.
> 
> Claiming copyright for something that is not copyright-able and then
> even putting restrictions on its use can be legally dangerous. Although
> it is a rare occurence, court cases have been lost in the past with
> expensive consequences for the person who tried to put restrictions on
> content that was - for whatever reason - part of the commons/public
> domain/not copyrightable.
> 
> > Potentially making things difficult for good free software citizens
> > without in any way affecting the not so friendly folks seems
> > counterproductive to me.

From time to time I hear people make the argument that Debian packaging is not 
copyrightable.  I personally disagree with that assessment.  Among all the 
other possible factors for considering that packaging *is* copyrightable, I 
think the effort argument is the easiest to understand.

When I consider the hours and hours and hours it often takes to get the 
contents of debian/* into good shape for proper packaging, I think it is 
impossible to argue that so little effort is required, or that Debian 
packaging is such an obvious task, or that the results are just a set of 
default values that don’t represent any actual labor.  That fact that Debian 
packaging done well requires so much effort, and that it takes so long for new 
packagers to become good at it, is a strong indication that it is 
copyrightable.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#14141 — Re: Is Packaging Copyrightable

On 2026-02-02 11:01, Soren Stoutner wrote:
> When I consider the hours and hours and hours it often takes to get the 
> contents of debian/* into good shape for proper packaging, I think it is 
> impossible to argue that so little effort is required, or that Debian 
> packaging is such an obvious task, or that the results are just a set of 
> default values that don’t represent any actual labor.  That fact that Debian 
> packaging done well requires so much effort, and that it takes so long for new 
> packagers to become good at it, is a strong indication that it is 
> copyrightable.

That. If Debian package were so trivial, that it can't even be
copyrighted, we can go out and party instead.

[toc] | [prev] | [next] | [standalone]

#14144 — as any other metadata + code expression Question: Is Packaging Copyrightable

> > When I consider the hours and hours and hours it often takes to get the 
> > contents of debian/* into good shape for proper packaging, I think it is 
> > impossible to argue that so little effort is required, or that Debian 
> > packaging is such an obvious task, or that the results are just a set of 
> > default values that don’t represent any actual labor.  That fact that Debian 
> > packaging done well requires so much effort, and that it takes so long for new 
> > packagers to become good at it, is a strong indication that it is 
> > copyrightable.

> That. If Debian package were so trivial, that it can't even be
> copyrighted, we can go out and party instead.

Packaging, which is a collection of metadata + code  is IMHO as
copyrightable  as any other metadata + code, which overall "might be
copyrightable" depending on how creative it is.  

E.g. if it is just some minor templated content: good luck trying to
claim copyright later on it, be it packaging or even the
underlying package content.

From my PoV: the point of us often stating a copyright + license (since
we AINL) is somewhat of adding a stake in the ground that in case the
content would evolve into sufficiently unique and would be
assessed to be copyrightable - here is the copyright and license to go
along.  It is not done when known ahead of time that copyright could not
even be assessed (e.g. works of .gov)

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik        

[toc] | [prev] | [next] | [standalone]

#14142 — Re: Is Packaging Copyrightable

]] Soren Stoutner

> From time to time I hear people make the argument that Debian
> packaging is not copyrightable.  I personally disagree with that
> assessment.  Among all the other possible factors for considering that
> packaging *is* copyrightable, I think the effort argument is the
> easiest to understand.

Depending on your jurisdiction, «Effort», is not, as I understand it,
relevant to whether something is copyrightable or not.  It's not
relevant in the US (per
https://en.wikipedia.org/wiki/Sweat_of_the_brow#United_States), in the
EU you get concept like database rights (which I don't think are
particularly relevant to Debian packaging).

> When I consider the hours and hours and hours it often takes to get
> the contents of debian/* into good shape for proper packaging, I think
> it is impossible to argue that so little effort is required, or that
> Debian packaging is such an obvious task, or that the results are just
> a set of default values that don’t represent any actual labor.  That
> fact that Debian packaging done well requires so much effort, and that
> it takes so long for new packagers to become good at it, is a strong
> indication that it is copyrightable.

Out of interest, do you think that the output of large language models
is copyrightable?

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.project

csiph-web