Agreguesi i feed

Hari Rana: How far would hostile distributions go to hurt application developers?

Planet GNOME - Sht, 18/07/2026 - 2:00pd

Introduction

The Linux desktop has an upstream maintenance problem due to many reasons for it, such as the lack of paid work. No one is entitled to a volunteer’s free time apart from the volunteer themself. This is especially true to volunteers working on upstream projects, as they are at the mercy of downstream distributions, who have the final say.

As an upstream contributor, you have no choice but to meticulously plead for any reasonable request to be granted by difficult downstreams, treating them as if they are some kind of deity. Not doing so with the utmost respect can get you on their naughty list, which they can then use against you just because the license ‘allows’ it and they can get away with it; even shamelessly use the ‘you chose the wrong license’ card when they have nothing else to add.

We have seen several instances of downstreams misusing their power while simultaneously abusing upstreams’ generosity and free time to do whatever they want. This was especially true with XScreenSaver and Debian in the past, which Debian has since changed its policies to communicate better with upstreams, and more recently Bottles, OBS Studio, and Fedora. This article is specific to an even more recent incident we at GNOME Calendar have had with Linux Mint.

Technical Definitions

There are a few technical definitions that should be understood before reading the rest of the article:

Upstream: A group of individuals authoring software, for example GNOME Calendar.
Downstream: A group of individuals building, curating, and redistributing these software to end users, for example Linux Mint.

The distribution model works until it impacts upstream

Distribution model refers to an established model that the Linux desktop has been practicing for decades, where an end user is expected to report issues to downstream, and, if necessary, downstream relays said issue to upstream.

The adage that users report issues to downstream holds true up until these users start reporting them to upstream without reporting to downstream beforehand. In reality, many distributions advertise themselves as user-friendly. Users of these distributions are unaware of the distribution model, so, in good faith, they report issues to upstream without ever knowing that they should be contacting downstream.

Often, downstream issues have already been resolved in previous releases; however, since these issues are being reported to upstream, upstream has to regularly triage and close these invalid issues. This creates an additional burden for them because they end up spending their limited volunteer time managing these issues when it should have been downstream’s responsibility to ensure that the user is reporting to them first.

Contacting downstream is a burden in itself

Whenever the upstream project reaches out to the hostile downstream and asks for a change, the response is usually met with the downstream bluffing by pretending to look for a solution for a nonexistent request, such as adapting the issue tracker with the implication that upstream will have to write the template(s) themselves, and then regularly update when the message is misinterpreted, just so downstream can avoid doing any actual work. That is called moving the goalposts.

If upstream objects to these ‘suggestions’, this is usually done with a shift in tone, as these one-sided discussions occur in the span of weeks, if not months, if not years, which quickly drains upstream’s remaining energy. When it shifts to a harsh(er) tone, the hostile downstream takes the easy way out by making remarks on that tone and acting like they are the only one being dignified; when they can, they end the discussion just because they do not like the tone and can use that tone to justify their (lack of) decision, without taking any appropriate action to remedy the underlying request.

As a result, they continue to mislead users into reporting issues to upstream, but this time intentionally and out of spite simply because free software licenses do not disallow abusing people’s generosity and free time. However, you will see later that this has nothing to do with free software.

Linux Mint and GNOME Calendar

For years, we have been dealing with users reporting Linux Mint’s broken packaging of GNOME Calendar to us, that were either never present or addressed releases ago.

To name a few examples:

There were a couple of discussions regarding this in the past, in chat and without my involvement, but none of them ended up being productive. Eventually, we got fed up by it and I opened ticket #1 on Linux Mint’s “gnome-calendar” repository, asking them to remove all links pointing to upstream GNOME Calendar and rebranding the app:

Remove/replace links pointing to GNOME Calendar, and update branding

Being one of the core developers of GNOME Calendar, we do not support any of the versions provided and held back by Linux Mint. We would really appreciate if you could remove or replace every link, especially support links, targeting to GNOME Calendar, as well as rebranding the app icon.

Mind you, this is the first issue ever opened in the history of Linux Mint’s package repository (8 years ago)! Based on the links above, I think it is safe to say that the app was broken throughout these years despite the lack of tickets.

This ticket had no response for six months, in other words half a year, all the while we were still getting bug reports about their broken package.

We eventually got fed up (again!) and pinged the packager. The packager replied and asked which modifications we did not like, conveniently ignoring our actual request.

So, I stated that we do not have the time to look through the code just to pinpoint specific issues, so I loosely said “everything”; then followed up by stating that the only solution to this is to rebrand or drop the package.1 (Of course, it should not be our responsibility as an upstream to pinpoint issues to downstream’s mispackaging.)

Then, the packager responded with “I reviewed the changes. None of them are problematic.”, ignoring the essence of my comment once again, and followed with a whataboutism:

[…] [GNOME Calendar] 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?”

In other words: “what about Ubuntu LTS and Debian Stable?”, essentially roping Ubuntu and Debian into Linux Mint’s problem. As a bonus, they also twisted my words and changing the subject from “GNOME Calendar” to “GNOME apps”.

So, once again, I reminded that this is not what the issue is about, and Debian and Ubuntu LTS have nothing to do with this.

As a side note: no, never would we go after Debian or Ubuntu over this. If the distribution in question is doing its job properly by simply not bothering the people writing the software that they package, then why should we go after them? They are not the ones misleading users into opening in the wrong place, so there is no reason for us to be upset about. In this case, Linux Mint is leeching off of Debian, pushing their responsibility onto us, and roping Debian into their problems.

The packager then explained the following:

If we were to stop packaging GNOME Calendar, Mint users would end up with the exact same version 46 as now. You understand that? It wouldn’t magically upgrade their version of GNOME Calendar to 50+.

Very clear signs of strawman to make points against a proposal/demand that was never made, by arguing against ‘stop packaging GNOME Calendar’ rather than the original ‘rebrand GNOME Calendar’.1

Then:

Mint 22.x is built on top of Ubuntu 24.04 LTS. Packages come from both repositories. If there’s no gnome-calendar in Mint 22.x repositories, Mint 22.x users get it from the Ubuntu 24.04 repositories. The version in both repositories is 46. Removing gnome-calendar from our repositories would basically make our users switch to Ubuntu’s version, which is 46 as well.

Same goes for LMDE and Debian Stable, same principle, same bug fix, with version 48.

The only way to make it so Mint doesn’t have a frozen version of gnome-calendar would be to remove it from Debian. It would then disappear from future versions of Ubuntu and Mint which are based on it. If you got it removed from there we’d obviously oblige with your request not to re-add it and wouldn’t do so.

These are, again, unrelated problems to the essence of the request, as the request is about rebranding, not dropping the package altogether.

So, I again reminded them that this is not our responsibility as an upstream to fix their problems.

They then ‘suggested’ us to add code to check if the user is running an outdated version, and then ‘offered’ that they will patch their existing packages and potentially Debian’s and Ubuntu’s as well, essentially moving the goalposts once again. They’re expecting us to either phone home or somehow keep track of releases every six months.

If we were to phone home, we would need to cover more cases, such as bothering designers to find an appropriate way to display a warning to the user when they are not connected to the network or when the “gnome.org” domain is unreachable. This adds another dependency on the network for no reason.

This also adds more burden to translators: this is not a typical string where one needs to translate one word into another; the tone and vocabulary of a warning depends on the region, so translators need to adapt the vocabulary to ensure that the underlying meaning is not misinterpreted. In any case, I think it is fair to say that this is an absurd suggestion to a problem that has nothing to do with the upstream.

I lost my patience; I hostily replied that we as upstream do not care about how distributions operate, and, once again, reminded that all we want is for them to rebrand; a very simple request that was continuously red herred with bikeshedding, strawmen, whataboutisms, and moving goalposts.

When I posted that comment, I misinterpreted the message as I thought their ‘offer’ was them asking us to do their work, hence me stating that we do not care about how distributions operate.

The packager then replied: “If you don’t care, then neither do we.”; here, they are explicitly confirming that they do not care about Debian and the situation altogether. In a later comment, they stated: “probably requires GNOME Calendar to move away from free licenses” and locked the issue, which, once again, completely ignored the essence of this entire issue, but this time concluding with the ‘you chose the wrong license’ card.

Now, they were explicitly told what the problem was, have refused to act on it by continuing to shove their responsibilities onto us. The attitude went from doing something ‘just because they can’ to ‘that should show upstream for hurting my feelings!’, never mind the fact that we and Debian are the ones doing the hard work, which they are leeching off.

Note

If you read through the entire ticket, you may notice a part where the packager makes a comment regarding some serious accusations. This is a response to a banned user’s comment that is now deleted, who originally made these accusations.

Trademark and free software

As explained above, this actually has nothing to do with free software; rather, this is a question about trademarks: Linux Mint is allegedly2 (mis)using GNOME’s name by redistributing unsupported builds while pretending that they are supported by us, and is actively misleading users to avoid supporting them.

Offending distributions use the ‘you chose the wrong license’ card because it is simultaneously very difficult to correct them as a non-lawyer, while being looked positively throughout the free software community. However, they know very well that looking at the situation from the perspective of trademark usage rather than software licensing would make it significantly harder to defend themselves, so naturally they opt into using (the incorrect) free software licensing as a gotcha.

Tone is irrelevant

The issue itself was originally calm and straight to the point. Half a year passed by and there was no response. Then, the packager was pinged, they chimed in, and changed the subject immediately. The tone shifted, and they took the easy way out by locking the issue and misleadingly stating that this is an upstream problem for choosing the wrong license.

In other words, you have two choices:

You kindly ask, and nothing happens apart from your own time and energy getting wasted for a considerable amount of time, with constant red herring or silence.
You start acting like a ‘dick’, and now they use this as an excuse to no longer communicate with you, all the while still refusing to address the underlying issue.

As an upstream, it is a lose-lose situation with hostile downstreams such as Linux Mint and Fedora. Once they start packaging your software, they immediately burn their bridges implicitly. In order to show that they are ‘good’, they only pretend to care about the problem, and keep proposing ‘solutions’ that 1. have nothing to do with the underlying problem, and 2. put on significantly more burden to upstream without putting an equal amount of effort themselves.

The reason there are so little undocumented cases is because many maintainers who deal with hostile downstreams are usually indie-developers that have very little resources and energy to deal with these problems, and have very little to no understanding with trademarks and legality.

They get burned out, stop developing and contributing to free software, and (rightfully) lose hope for the Linux desktop. They do not make any of it public or make a fuss about the situation because they do not feel comfortable to be in the middle of a conflict publicly. All they want is to just enjoy providing goods to the world, but are unfortunately bullied by repackaging fetishists whenever they raise a legitimate issue.

Conclusion

To summarize all this, hostile downstreams have already gone as far as to burn their bridges with upstreams. Any upstream is at a lose-lose position no matter how kind or unkind they are. If they are kind, they will be on the waiting list for as long as governments put patients on the waiting list for medical care. If they are ‘rude’, hostile downstreams will use this tone against them. If upstream sends out a cease and desist letter, the free software community will start seeing them as the Nintendo of free software and conflate volunteers who are fed up with hostile downstreams, with corporations that sue every sentient being that breathes.

While dropping the package was mentioned, the entire essence of the issue was about rebranding it ↩ ↩2
For some reason, “allegedly” is a common term used in legal contexts, even when there is all kinds of evidence pointing to something ↩

GIMP: Google Summer of Code Midpoint Progress

Planet GNOME - Sht, 18/07/2026 - 12:00pd

Since the release of GIMP 3.2.4, we’ve been hard at work behind the scenes. We’ve been making fixes that will be included in the upcoming 3.2.6 stable release and adding tons of new features for the first 3.4 development version.

In addition, we’ve been mentoring our four Google Summer of Code (GSoC) students as they’ve been working on their projects. Since we just completed their midpoint evaluation, we wanted to share their progress with you all!

In alphabetical order:

Akascape¶

Project Description

Akascape started off their early work for GSoC by creating a new Vibrance filter in GEGL. This filter combines the existing Hue-Chroma and Saturation filters to more selectively adjust the less saturated sections of an image without increasing others. It was released in GEGL 0.4.68, so you can use it right now in GIMP!

Their main focus has been on improving the user experience with the Keyboard Shortcuts dialog. They plan to both improve usability while also adding new features.

In-progress updates to Keyboard Shortcut UI, by Akascape

Akascape’s in-progress work already includes several big improvements such as a category list to quickly jump to relevant shortcuts, the ability to import and export shortcut “profiles”, and efforts to make the dialog more friendly for a future GTK4 port.

In addition, Akascape did some early work on adding more adjustment layers to our PSD import plug-in, building off in-progress work by several contributors. His work would allow for importing Vibrance, Black & White, Photo Filter, and Exposure PSD adjustment layers.

Blezecon¶

Project Description

Blezecon has taken on the task of building the online infrastructure for a GIMP Extensions platform. Originally planned as part of GIMP 3.0, the Extensions platform would allow users to download third-party themes, brushes, plug-ins, and more via a package manager directly in GIMP. The local infrastructure has been in place for several years - this GSoC project is about developing the online submission process.

Blezecon has been working in the Extension repository and making great progress. His initial work involved cleaning up and correcting issues with the initial YAML script.

He then created a comment-based approval system in the repo. This will allow community moderators to easily inspect and approve new extensions through the same interface they use for responding to issue reports and review merge requests. Blezecon next developed a scheduler script that will monitor pending extensions, and once they have received the required approvals, automatically merge them into the Extensions repository for user access.

While infrastructure work is often not as visible to end users, Blezecon’s GSoC project is an essential effort to getting the Extensions repository up and running for future releases of GIMP!

v4vansh¶

Project Description

v4vansh did some early bugfixes and improvements in GIMP beforehand. He fixed a problem where the thumbnail wouldn’t update after changing image modes, and he corrected missing information in our manual page generation.

Since the start of GSoC, he has been focused on improving text handling in GIMP. His current big project is grouping fonts by family in the text widgets. In addition to better organization (especially with the infamous Noto fonts which have hundres of variants), this patch significantly reduces lag on systems with large numbers of fonts, as v4vansh’s mentor Liam can attest. This feature is in final testing, and we hope it will be merged into the main codebase soon!

Early UI tests for OpenType fonts, by v4vansh

v4vansh has also begun experimenting with adding support for OpenType variable fonts. This would allow for much more sophisticated font and text work in GIMP. The initial work involves exploring both the functionality and the user interface to interact with it, and both will develop further as he continues to work with OpenType fonts.

Waris Maqbool¶

Project Description

Before GSoC began, Waris contributed some early work to GIMP. He updated our OpenEXR import code to load YUV images in color instead of in grayscale. The main focus of his project though has been with GEGL, our color processing engine.

His first project was implementing a GEGL version of the Sharpen filter. Sharpen is a simpler version of the Unsharpen Mask filter, a popular method of correcting blurry images. It was unfortunately removed from GIMP 3.0 due to it not being maintained and only working on 8 bit images. Waris has created a GEGL filter of Sharpen by doing comparisons with the 2.10 version. The recreated Sharpen filter will be non-destructive and will have an on-canvas preview, both improvements over the original.

Handwritten calculations to recreate the Sharpen Filter, by Waris Maqbool

You can see the in-progress merge request for comparison. We’re doing some final reviews for optimization, but we expect it to be ready for a future release of GEGL and GIMP.

Waris has also begun working on a new Inner Glow filter for our PSD support improvement project. While GEGL already has an inner glow feature, it was not designed to be compatible with how it looks in Photoshop. As part of his work, he is also creating a generic curve editing widget to use for editing the PSD Inner Glow’s settings.

We unfortunately had more great GSoC applicants than we were awarded available spaces. One student in particular continued contributing, so we’d like to highlight their work as well.

Harsh Verma¶

Harsh has been focusing on several different areas of GIMP. His initial proposal involved improving our unit testing suite. He is currently working to implement automated UI testing for GIMP. This is a challenging task, as interacting with the UI varies across platforms. He’s already developed several tests that work on Wayland, which you can see at his in-progress merge request.

He’s also improved our contributor infrastructure that integrating CI-Fairy into our pipeline. This feature checks to make sure contributor commits follow the proper format before merging, which makes our commit history easier to read and understand.

Harsh has also been working on more user-visible changes. He recently took on a user request to add more version information to our About dialog. This follows standard practice with other software, and makes it easier for users to find information that helps us troubleshoot problems. In addition, there’s a handy Copy feature to easily grab the information for sharing. The code and UI have gone through several revisions based on developer and designer feedback, and it will likely be merged soon!

About Dialog with additional version information, by Harsh Verma

We’ve very proud of our student’s contributions so far, both in code and in community! We’re looking forward to you all getting the chance to try out their work in future development releases of GIMP, which we hope to have more information to share soon.

HP Fined $14 Million For 'Cartelization' of Ink Cartridges, Toner, PCs

Slashdot - Pre, 17/07/2026 - 1:00pd

India's Competition Commission has fined HP India and its partners about 1.4 billion rupees ($14.4 million), alleging the company colluded with resellers to rig government PC bids and fix prices for ink cartridges, toner, and other printing supplies. "It said that HP was aiming to outcompete other OEMs and discourage resellers from selling 'counterfeit' ink and toner," adds Ars Technica. From the report: In an order, the CCI said that HP India worked with five resellers to coordinate their bid prices for government contracts to increase the chances of an HP partner winning the contracts. The company was fined 1.3 billion rupees (about $13.1 million). [...] HP was also fined 119.8 million rupees (about $1.2 million) for "indulging in cartelization in sale and supply of supplies products comprising of toner, cartridges, and other consumable used with print hardware products," CCI said in its announcement. The agency also fined 21 HP resellers 35.2 million rupees (about $365,335). In a separate order, the CCI said that WhatsApp records showed that HP and 16 of its Tier-2 reseller partners operated "in a collusive arrangement" and that the messages show the companies engaging in "bid rigging, including cover bidding, price fixation, and customer allocation during 2017-2020." HP India played a central role, the regulator said. Per the order, HP India said that high printing supply prices led some resellers to threaten to "shift to low-cost counterfeit products to compete on price." "HP India was commercially forced into a position where it had to support the collusive arrangement adopted by the Tier-2 resellers," the order reads. For its part, the order said that HP India "humbly objects to HP India's role being characterized as a 'kingpin' of the entire collusive arrangement." [...] The CCI also ordered HP India and its channel partners to "cease and desist from anti-competitive conduct" and to hold competition compliance training programs within 60 days.

Main menu

Kontribo me ...

Lundrimi

Bits from Debian

Planet GNOME

Kernel Linux

You are here

Faqet

Argumente të rinj në forum

Shkrimet e fundit në ditar

Projekte në shqip

Debian.org

LinuxSecurity.com