Hi! On Mon, 2026-02-02 at 14:35:12 +0100, Simon Josefsson wrote: > Tollef Fog Heen <[email protected]> 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
