• Pl chevron_right

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

      news.movim.eu / PlanetGnome • 0:00 • 12 minutes

    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 allegedly 2 (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:

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

    1. While dropping the package was mentioned, the entire essence of the issue was about rebranding it ↩ ↩ 2

    2. For some reason, “allegedly” is a common term used in legal contexts, even when there is all kinds of evidence pointing to something ↩