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

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

Re: is copyleft packaging bad for Debian?

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

Contents

  Re: is copyleft packaging bad for Debian? Gerardo Ballabio <gerardo.ballabio@gmail.com> - 2026-02-02 13:50 +0100
    Re: is copyleft packaging bad for Debian? Jonas Smedegaard <dr@jones.dk> - 2026-02-02 14:40 +0100
      Re: is copyleft packaging bad for Debian? Andrey Rakhmatullin <wrar@debian.org> - 2026-02-02 16:20 +0100
        Re: is copyleft packaging bad for Debian? Ansgar 🙀 <ansgar@debian.org> - 2026-02-02 17:10 +0100
          Re: is copyleft packaging bad for Debian? Jonas Smedegaard <dr@jones.dk> - 2026-02-02 20:10 +0100
            Is Packaging Copyrightable (was: is copyleft packaging bad for Debian?) Soren Stoutner <soren@debian.org> - 2026-02-02 20:20 +0100
              Re: Is Packaging Copyrightable (was: is copyleft packaging bad for Debian?) Jonas Smedegaard <dr@jones.dk> - 2026-02-03 15:10 +0100
                Re: Is Packaging Copyrightable (was: is copyleft packaging bad for Debian?) Soren Stoutner <soren@debian.org> - 2026-02-03 18:00 +0100
            Re: is copyleft packaging bad for Debian? Russ Allbery <rra@debian.org> - 2026-02-02 21:50 +0100
              Re: is copyleft packaging bad for Debian? Jonas Smedegaard <dr@jones.dk> - 2026-02-03 15:10 +0100
                Re: is copyleft packaging bad for Debian? Russ Allbery <rra@debian.org> - 2026-02-03 23:30 +0100
                  Re: is copyleft packaging bad for Debian? Soren Stoutner <soren@debian.org> - 2026-02-04 00:00 +0100
                  Re: is copyleft packaging bad for Debian? Jeremy Stanley <fungi@yuggoth.org> - 2026-02-04 00:20 +0100
                    Re: is copyleft packaging bad for Debian? Russ Allbery <rra@debian.org> - 2026-02-04 02:40 +0100
                      Re: is copyleft packaging bad for Debian? Jeremy Stanley <fungi@yuggoth.org> - 2026-02-04 19:00 +0100
      Re: is copyleft packaging bad for Debian? thomas@goirand.fr - 2026-02-02 20:20 +0100

#14131 — Re: is copyleft packaging bad for Debian?

If the packaging and the upstream source have different licenses, I
wonder what is the license on the resulting package -- both source and
binary?

For the source -- GPL permits "mere aggregation" of GPL and non-GPL
code in the same medium. But since the packaging is meant to work with
the upstream source, and is useless without it, I'm skeptic that they
could be considered "merely aggregated". So, there is at least some
ground for claiming that the GPL license of the packaging must extend
to the whole source package.

This argument seems even stronger for the binary. The binary is
generated from the upstream source and the packaging working together,
so it is most clearly not a "mere aggregation". I suppose that the
more "absorbing" license would prevail, that is, the binary must be
licensed under the GPL.

And what if the upstream license is incompatible with the GPL? In that
case it seems that the package would be *undistributable*.

That is, unless we adopt the view that packaging isn't copyrightable
-- but if it isn't, how does it make sense to stick a license on it?

Thus, I agree that the best course of action is likely to release the
packaging under the same license as the upstream source.

Gerardo

[toc] | [next] | [standalone]

#14132

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

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.

Kind regards,

 - Jonas

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

#14133

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

On Mon, Feb 02, 2026 at 02:24:40PM +0100, Jonas Smedegaard wrote:
>> 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.

But can you say that debian/rules and other packaging are also separate 
components which the binary package is not a derivative work of?

I understand that this is closer to debian-legal@ (or what I've heard of 
it) than to real world, but this whole discussion is not hugely important 
for the real world...

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

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


-- 
WBR, wRAR

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

#14135

Hi,

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.

Using GPL-2-incompatible licenses such as the GPL-3-or-later thus makes
it hard to comply with the GPL-2 (though so does statically linking
GPL-3-or-later libraries like libstdc++, so maybe practically GPL-2 and
GPL-3 should be considered compatible in Debian even if FSF might
disagree). Unless the FSF fixes these problems (at least for -or-later)
by releasing a GPL-2-compatible GPL-4.

Ansgar

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

#14137

Hi Andrey and Ansgar,

Quoting Ansgar 🙀 (2026-02-02 16:55:28)
> 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".

The very next phrases sthat you mitted from above quote should clarify,
that I do not generally copyleft-license patches, but instead consider
patches generally uncertain to classify.

But you are right, it was unclear (and as demonstrated it was easy to
read out of context).

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.

The intent is to make explicit that patches are neither implied to be
licensed same as debian/* nor same as *.

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

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

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

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

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

On Monday, February 2, 2026 11:43:34 AM Mountain Standard Time Jonas 
Smedegaard wrote:
> 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.

As I just wrote in a separate email, I disagree strongly with the idea that 
Debian packaging is not copyrightable.  I do not think that any packages with 
the above debian/copyright entry should be allowed in Debian.

-- 
Soren Stoutner
soren@debian.org

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

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

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

Hi Soren,

Quoting Soren Stoutner (2026-02-02 20:04:57)
> On Monday, February 2, 2026 11:43:34 AM Mountain Standard Time Jonas 
> Smedegaard wrote:
> > 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.
> 
> As I just wrote in a separate email, I disagree strongly with the
> idea that Debian packaging is not copyrightable.  I do not think that
> any packages with the above debian/copyright entry should be allowed
> in Debian.

I read your previous email and I fully agree with you on that, but I
disagree with your conclusion (second sentence of your above).

For the record: I disagree strongly with the idea that Debian packaging
is *in general* is not copyrightable.

The reason I disagree with your conclusion has to do with a work
consisting of multiple parts, where some parts may be both easily
identifiable and also not in itself be copyrightable. Debian packaging
consist of such a subset, which has a third feature of being
potentially upstreamable: patches to upstream source.

(please see my response to Russ for more details on that reasoning)

Initially I talked about Debian packaging, but then I shifted to talk
more narrowly about the subset of "debian/patches*", and that is what
you quoted. Your position I fully agree with, but I am unsure if you
really mean that it holds true also for debian/patches as a subset on
its own - and I suspect that I would disagree with such a position.

Do you insist so very strongly that *patches* are not copyrightable?

 - Jonas

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

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

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

On Tuesday, February 3, 2026 6:16:46 AM Mountain Standard Time Jonas 
Smedegaard wrote:
> Hi Soren,
> 
> Quoting Soren Stoutner (2026-02-02 20:04:57)
> 
> > On Monday, February 2, 2026 11:43:34 AM Mountain Standard Time Jonas
> > 
> > Smedegaard wrote:
> > > 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.
> > 
> > As I just wrote in a separate email, I disagree strongly with the
> > idea that Debian packaging is not copyrightable.  I do not think that
> > any packages with the above debian/copyright entry should be allowed
> > in Debian.
> 
> I read your previous email and I fully agree with you on that, but I
> disagree with your conclusion (second sentence of your above).
> 
> For the record: I disagree strongly with the idea that Debian packaging
> is *in general* is not copyrightable.
> 
> The reason I disagree with your conclusion has to do with a work
> consisting of multiple parts, where some parts may be both easily
> identifiable and also not in itself be copyrightable. Debian packaging
> consist of such a subset, which has a third feature of being
> potentially upstreamable: patches to upstream source.
> 
> (please see my response to Russ for more details on that reasoning)
> 
> Initially I talked about Debian packaging, but then I shifted to talk
> more narrowly about the subset of "debian/patches*", and that is what
> you quoted. Your position I fully agree with, but I am unsure if you
> really mean that it holds true also for debian/patches as a subset on
> its own - and I suspect that I would disagree with such a position.
> 
> Do you insist so very strongly that *patches* are not copyrightable?

Not all patches are the same.  I agree that there are some that would not pass 
the copyrightable test.  But, in general, I strongly believe that *most* 
patches are copyrightable because they, generally, require some form of 
creative work.

-- 
Soren Stoutner
soren@debian.org

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

#14140

Jonas Smedegaard <dr@jones.dk> writes:

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

For work that you don't think is or should be protected by copyright at
all, I don't understand why you're uncomfortable with adding a simple
license to reassure those people who don't agree with you. For work where
I think making a coypright claim would just be silly, I use the Free
Software Foundation all-permissive license, just to remove any doubt or
ambiguity.

    Copying and distribution of this file, with or without modification,
    are permitted in any medium without royalty provided the copyright
    notice and this notice are preserved. This file is offered as-is,
    without any warranty.

This is a little bit annoying since it still requires preservation of a
copyright notice, but I didn't want to make up my own license.

You could use something like CC0 instead, of course, and that would
probably be more formally correct. I am stubbornly annoyed by using long
and complicated licenses like the CC0 to express very simple concepts,
even if I understand why lawyers feel like they have to write them, and
therefore am not inclined to use them myself if there's soemthing
reasonable that can be expressed in four lines but has still been looked
at by an actual lawyer.

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

I'm inclined to agree with this, but of course I'm not a lawyer and this
is not legal advice.

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

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

#14145

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

Hi Russ,

Quoting Russ Allbery (2026-02-02 20:36:26)
> Jonas Smedegaard <dr@jones.dk> writes:
> 
> > 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.

Ok, so my wording is bad. But I suspect that your understanding is off
too. I could use some help with that.

(thanks for your reflections on using weakest possible licensing for
some purposes, that just doesn't seem to help here...)

I do not mean to say "this section contains works of mine, that you
should not assume being copyrightable, because I refuse to acknowledge
authorship to avoid them needing licensing" - and I guess that's the
reading that makes you consider it flat out incorrect.

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

Even for packaging licensed same as upstream (i.e.  putting aside for a
moment the topic discussed in this thread), stating (implicitly or
explicitly) that debian/patches/* have same copyright and license as
the upstream project would still be wrong: At least copyright would
differ for most patches, and is likely to differ among the patches.

I tried to boil those 4 concerns into one short sentence. That failed,
as your reply demonstrates, but I don't think that your response covers
the concerns that I want to get across.

I can see how my original question about *choosing* a packaging license
and then shifting to talk about (copyright and) license of a subset of
packaging could lead to you reading that as being about *choosing* a
licensing for patches.

My concerns regarding debian/copyright coverage for patche is how to be
explicit about an ambiguity not introduced by my choice of packaging
license but merely more strongly exposed when upstream and packaging
licenses differ.

There are two ways that I can meaningfully state that the Eiffel Tower
is not for sale. Either I claim to know the owners and their opinions
in the matter, or I claim to be the (sole) owner and it is my opinion.

Similarly, license of assets in a Debian package can be described
either because the license is referenced or it is chosen.

The debian/copyright file lack that distinction: For some parts,
copyright and license represent a reference from elsewhere, but for
other parts they represent the source of truth on the matter.

I use an unofficial field "Reference" to indicate the difference:

Files: *
Copyright: them
License: TheseAreTheRules
Reference:
Comment:
 A Reference: field pointing elsewhere (or omitted) indicates that
 License and Copyright is referenced rather than introduced here.

Files: debian/*
Copyright: us
License: ThusThouShallDo
Reference: debian/copyright
Comment:
 A Reference: field pointing to $self indicates that License and
 Copyright originates here - i.e. look no further, as this is the
 source of those statements.
 If some project (as has happened at least once) copies the
 debian/copyright file e.g. as contrib/copyright, then it automatically
 stops being the source of truth but instead hints at where to look for
 potentially more up-to-date information.

Does that intent make sense now? Do you see how it arguably makes sense
even when *not* strongly copyleft-licensing the packaging?

I never *intended* to piss on the licensing choices made upstream, but
it occured to me, from the strong reactions to my descriptions of my
current practice, that it may be perceived that way. And that is the
reason I now want to (not change but) make explicit the "default" state
of debian/patches/* in debian/copyright: I want to clarify, that
patches are not simply "same as above", both because "abocve" is
ambiguous and because "same" is only rarely true (and different,
depending on the ambuguous "above").

 - Jonas

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

#14149

Jonas Smedegaard <dr@jones.dk> writes:

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

Ah, yes, I was misreading what you were trying to convey.

I think I understand the problem that you're trying to solve, and I think
it's yet another form of a standard free software problem, namely that
most of us do not use copyright assignments, contributor licensing
agreements, or developer certifications because we find them obnoxious,
but there are reasons why things all exist. I think you are trying to be
very precise about software licensing without using any of the tools that
lawyers have developed to allow you to be very precise about software
licenses, and one of those two things has to give.

Let me back up and try to explain this at a higher level. I'm going to say
a bunch of stuff here that you obviously already know, but it was helpful
for my thinking to lay it all out anyway, and that will let other folks
spot any flaws in my reasoning or places where they disagree. Also, I'll
say again that this is all based on my amateur understanding of copyright
law as a free software developer and I'm not a lawyer and probably am
wrong about some of the details.

I believe the following things are roughly true about copyright law under
Berne. There's a lot of per-country variation, so I'm more confident about
this being roughly true under US copyright law and less confident about EU
(or elsewhere) copyright law:

* Anything someone writes that involves non-trivial creative effort is
  copyrighted by default. This is a very complicated legal standard that
  is easy to oversimplify. Whenever I've seen a layman try to explain this
  standard in front of a lawyer, the lawyer starts making distressed
  facial expressions.

* The default rule for copyright is that unless you explicitly give your
  permission to use your copyrighted work, it can only be used in ways
  that fall under fair use or similar concepts, which is another very
  complicated legal standard that in the US involves a four-part weighing
  test and produces wildly different opinions about whether something is
  fair use even among lawyers.

* Therefore, if you produce a patch for some piece of software and you do
  not make any explicit statement about licensing of your copyright,
  whether that patch can be used by other people is legally ambiguous
  along multiple different axes and it's not uncommon for the correct if
  unsatisfying answer to the question "can I use this patch," if asked
  with legal rigor, to be "uh, hard to tell, the litigation would be
  really annoying."

* In 99.999% of these situations, the actual value of the patch is low
  enough, and the desires of the parties are sufficiently aligned, that
  absolutely no one is going to engage in litigation, and therefore the
  legal subtleties will never be tested and the *practical* answer to "can
  I use this patch" is "sure, who's going to stop you?"

This situation annoys the crap out of people like me, and I would suspect
also many other people who were drawn to programming because it lets you
say things precisely, who believe in following rules and hate this sort of
practical ambiguity and would prefer to correctly nail down the details
because otherwise this feels like an unsatisfied mental open loop. It also
creates some real legal risk in the 0.001% of cases where someone might
actually sue someone else.

Unfortunately, legally, the way to avoid this ambiguity is to get a
copyright license or other legal agreement from the author of the patch.
If the patch turns out to not be copyrightable or your use is fair use,
there's no harm in having a copyright license, and if both of those turn
out to not be true according to some legal system, you have a license and
you're covered. Getting that agreement is a pain in the ass. You generally
have to do one of the following:

1. Have the person put an explicit license on the patch. Depending on the
   license, this may require carrying around additional metadata with the
   patch that's annoying and doesn't help the software work any better and
   incurs ongoing overhead. There's also a bit of an open question about
   whether the person submitting the patch is legally entitled to license
   it that mostly people ignore but that may or may not be truly legally
   safe to ignore.

2. Have the person sign some sort of legal agreement with you about their
   patches. Most people hate this and, more practically, simply aren't
   going to do it, and also now you have to be the legal agreement police
   and double-check that everyone has signed and you have to worry about
   different jurisdictions and a bunch of other nonsense.

3. Have the person include some sort of statement that essentially
   formally agrees with the licensing of the patch without requiring a
   specific license statement. This is roughly what the Linux Developer
   Certificate of Origin is doing. This works legally (I assume, given
   that the Linux Foundation has good lawyers) and is somewhat
   lighter-weight than the other options, but some people object to it
   because it arguably shifts liability to the submitter, and also again
   people just won't do it unless you pester them.

The larger projects that face real legal threats and have corporations and
lawyers involved increasingly tend to do one of those three things. Nearly
every other free software project on earth, including, I suspect,
approximately 100% of Debian packaging, does none of these things.

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.

And, again, the simple reality is that in nearly every case the value of
the work is sufficiently low and the motives of everyone involved are
sufficiently aligned that no one is ever going to contemplate legal action
and therefore at some practical level it doesn't "really" matter. (The
problem, of course, is that this is true up until it's not, and there's
some risk of being unpleasantly surprised.)

I think what you're getting at is that, in practice, you are making this
reasonable assumption, just like nearly everyone else, but it's very
difficult to cast this reasonable assumption in the formal terms of the
debian/copyright file because it's not really a copyright license. It's an
assumption about the intentions of other parties, and in some cases you
may not even know who those parties are. They're just other participants
in an ecosystem with a certain set of shared default assumptions that
you're relying on.

I don't have a foolproof solution for you. I don't think there *is* a
foolproof solution other than CLAs or DCOs or some similar tool, which is
precisely why the projects with lawyers use those tools. If you want to be
formally correct, you have to have the formality, which includes all the
annoying and tedious overhead required to track the formality and pester
people to follow it.

What I can say is what I personally do, which I think is interestingly
different than what you are doing in ways that may produce a useful
discussion.

My position in all the projects I maintain, including Debian packaging, is
that I want to use the implicit community assumption and not require
formal statements because the last thing I need is to spend my scant and
precious free time doing tedious paperwork that's nearly always
meaningless. I therefore am going to lean into the community assumption,
but that means that I have an obligation to also align *my* behavior with
the rest of the community. If I plan on treating people's submissions in
the "expected" way, I also need to behave in the "expected" way myself.
Otherwise, my behavior is at the least unfair, and possibly undermines
whatever legal protection I get from assuming everyone involved is acting
in the normal way.

This means that I have an obligation to not do anything "surprising" that
would break this implicit social contract with submitters. In my
*personal* opinion, and other people can of course reach different
conclusions, that means the following:

1. My software should be clearly and straightforwardly licensed. Most
   people expect the whole software package to be under a single license,
   so do that where possible. If it's not possible for whatever reason,
   all the exceptions should be clearly labeled.

2. I should assume that any contribution someone gives me is intended to
   be covered by the same license as the file they're modifying is already
   under, and not under some other license that would be more convenient
   for me, unless I clarify this with them explicitly.

3. I should state the license of each file prominently at the top of the
   file where practical to increase the chances that someone can see that
   license, unless the default is really obvious (such as a package with a
   LICENSE file at the top level and no exceptions).

4. I have a moral obligation to not take advantage of my reliance on this
   implicit assumption to do something against the interests of the
   submitter. So, for example, if my whole package is GPLv3 except for one
   portion that is MIT-licensed and that I know is used in a non-free
   work, and someone submits a patch to a bunch of GPLv3 code but also
   non-trivial modifications to the MIT code, I feel some moral obligation
   to confirm with them that they're okay with that part being
   non-copyleft because that sort of split is surprising. The goal should
   be to never surprise the submitter with how I used their code.

5. I use standard licenses, not some weird niche license that a
   contributor may not be familiar with.

The practical effect of these personal rules for Debian packaging is that
I always release my Debian modifications to the upstream code (patches,
additional documentation, that sort of thing) under the same license as
the upstream package except for non-free upstreams, because to me that
follows the principle of least surprise. I then feel ethically comfortable
with relying on this implicit assumption of licensing of contributions,
because I am doing the "normal" thing that most free software contributors
expect: Everything related to a given piece of software is covered by the
same license, which is the obvious one declared at the top level or
prominently in the documentation.

For packaging files *that are not upstream modifications*, I think it's
actually hard to do something *that* surprising here. If the package is
GPLv3 and the packaging files are MIT, that follows a fairly typical
pattern of more generously licensing supporting files with (in most cases)
less creative work than the main software package. If the package is MIT
and the packaging files are GPLv3, well, you're allowed to relicense MIT
contributions under the GPLv3 so far as I can tell, so that's legally
allowed by the license even if you assume the contributor intended MIT
licensing. Either way, the chances that you're using someone's
contribution in a way that would make them unhappy is relatively low.

However! The chances that you will *mislabel* someone's contribution in a
way that makes them happy is higher! The labeling will probably have
no practical effect on how the contribution is *used*, but still, people
may well be unhappy having their MIT-licensed contributions labeled GPLv3
or vice versa.

Therefore, even in that case, I personally license the packaging under the
same terms as upstream because I am trying very hard to not be surprising.
Not surprising contributors is more important to me personally (by FAR)
than the precise details of licensing for work in situations, like Debian
packaging, where all of these licenses are going to be functionally
equivalent 99% of the time. That's just my personal opinion, of course,
and I can see lots of room for others to arrive at other conclusions.

In summary, personally I would align licensing between packaging and
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. :)

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

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

#14150

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

On Tuesday, February 3, 2026 12:11:57 PM Mountain Standard Time Russ Allbery 
wrote:
> In summary, personally I would align licensing between packaging and
> 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. :)

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

-- 
Soren Stoutner
soren@debian.org

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

#14151

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

On 2026-02-03 11:11:57 -0800 (-0800), Russ Allbery wrote:
[...]
> 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.
[...]

Also not a lawyer, but wanted to point out that the strength of this 
assumption does vary somewhat from license to license too. In 
particular, copyleft licenses sort of try to encode it insofar as if 
you're violating the patch author's implicit copyright by including 
their derivative work into the project, then they were likely also 
violating the project's copyright license by distributing that 
modification to you under infringing terms.

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

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

#14152

Jeremy Stanley <fungi@yuggoth.org> writes:

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

This is a really good point. I did not think about patent licenses, but
indeed those are a completely different problem with different tradeoffs.

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.

For most patches with only copyright interest, this still isn't a big
deal, since most employers are not going to care unless the work is quite
substantial and often will not care even then. In most cases the benefit
to the employer in getting their patch merged is much higher than any
inherent value in the patch, so interests are still aligned. Organizations
like the FSF try to handle this case explicitly in their legal agreements,
but most typical free software projects can (not legal advice!) still
ignore this and everything will usually be fine.

But an employer who doesn't care about the incidental copyright on a patch
often will still care A GREAT DEAL about patent licenses and will
absolutely not agree that some random employee can grant use of corporate
patents. This is one reason why it's common to see a corporate policy
prohibiting employees from contributing to free software covered by
licenses with patent grant clauses without explicit permission.

If there are any actual patent concerns and the license includes patent
grants, I personally would be very uncomfortable relying on social
convention rather than requiring some sort of legal agreement and
assurance that the submitter has a right to make that agreement.

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

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

#14155

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

On 2026-02-03 15:40:58 -0800 (-0800), Russ Allbery wrote:
[...]
> 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 
example, patent clauses in Apache Software License v2 and GNU Public 
License v3, extremely popular choices on both sides of the 
permissive vs copyleft aisles.

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

Right, this is precisely why (from what I understand) Apache 
Software Foundation counsel had them impose a CLA on participants in 
their projects, and subsequent non-ASF projects reusing their 
license followed suit. Inbound=outbound is a fairly comfortable 
assumption when it comes to copyright, but patent grants are an 
entirely different kettle of fish.
-- 
Jeremy Stanley

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

#14139

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

On Feb 2, 2026 14:32, Jonas Smedegaard <dr@jones.dk> wrote:
>
> 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.


*I* prefer to use the same license as upstream, I often advise to do the same, but I have no problem with you choosing GPL license for your packaging if you prefer, as long as you understand what you're doing (and I believe you do).


Cheers,


Thomas Goirand (zigo)

[toc] | [prev] | [standalone]

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

csiph-web