19 ms·

He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I hit t

He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I hit this with procps. (a package with ps, top, vmstat, free, kill...) It was horrifically demotivating, helping to end my involvement as the maintainer from roughly 1997 to 2007. (the other big issue was real life intruding, with me joining a start-up and having 5 kids) I had plans for command line option letters, carefully paying attention to compatibility with other UNIX-like systems, and then Red Hat would come along and patch their package to block my plans. They were changing the interface without even asking for a letter allocation. I was then sort of stuck. I could ignore them, but then my users would have all sorts of compatibility problems and Red Hat would likely keep patching in their own allocation. I could accept the allocation, letting Red Hat have control over my interface. Red Hat sometimes added major bugs. I'd get lots of complaints in my email. These would be a mystery until I figured out that the user had a buggy Red Hat change. Patches would often be hoarded by Linux distributions. I used to regularly download packages and open them up to look for new crazy patches. Sometimes I took the patches, sometimes I ignored the patches, and sometimes a wrote my own versions. What I could never do was reject patches. The upstream software maintainer has no ability to do that. The backlog of unresolved troubles of this sort kept growing, making me really miserable. Eventually I just gave up on trying to put out a new release. That was painful, since I'd written ps itself and being the maintainer had become part of my identity. Letting go was not easy. Maybe it had to happen at some point, since I now have more than twice as many kids, but I will be forever bitter about how Red Hat didn't give a damn about the maintainer relationship.

cyphar 7y ago
That sounds really awful, and it's really disheartening to see the (ex)maintainer of such a core piece of Linux distributions being treated that way. I work for a Linux distribution (SUSE) and I assure you that we don't all act this way. I've had to carry my fair share of downstream patches in openSUSE/SUSE packages, but I always make sure to submit the patches upstream in parallel. Quite a few people I know from Red Hat (and other distributions like Debian, Ubuntu, etc) do the same. It's possible that times have changed since then, or that it depends which package maintainers you are dealing with, but I hope it hasn't soured your opinion of all Linux distribution maintainers. One thing that is a constant problem is that users of distributions keep submitting bugs to upstream bug-trackers. If there was one thing I wish I could change about user behaviour, it would be this. Aside from the fact that the bug might be in a downstream patch (resulting in needless spam of upstream), package maintainers are also usually better bug reporters than users because they are more familiar with the project and probably are already upstream contributors.
- arendtio 7y ago
  > If there was one thing I wish I could change about user behaviour, it would be this. Speaking from a user perspective, I don't think that would be wise. If distributions would just stop feature patching, things would be a lot simpler. I mean, if a feature is good, everyone should have it, not just the users of one distribution. So please submit the patch upstream, discuss it and wait for the next release. That way, there is no real problem when users submit to upstream bug-trackers. The only exception is (time-critical) security patching. But those patches should be removed again as soon as upstream solves the issue. The scenario you are wishing for looks like an obvious solution to the issues you are having but will just make everything worse in the long run (slow and fragmented).
  - jiggunjer 7y ago
    Are there any distros with a strict upstream-only policy?
    - deleted 7y ago
      [deleted]
    - kashyapc 7y ago
      Fedora comes very close. But I'm biased, as a user of (and contributor to) it for about ten years. Don't take my word for it, read the related documentation[1]: "The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts." The linked[1] documentation also answers, with specific examples, the question of: "What are deviations from upstream?" [1] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro...
    - majewsky 7y ago
      https://www.archlinux.org/about/ https://www.archlinux.org/about/ > Arch [Linux] strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.
bscphil 7y ago
One of the things I really like about Arch Linux is their policy of not making unrequired changes to upstream software. The only changes usually made are those necessary to keep the software compatible with the other software on a rolling release system, and these changes are usually temporary.
- paco3346 7y ago
  I love this about Arch. It gives everything a very vanilla, organic feel and you never get caught off guard by some distro specific change.
- nvarsj 7y ago
  Ditto. Arch has the right attitude. I still have a bitter taste from a 0 day hack of one of my Debian servers, due to what I believed was a Debian only patch. I wish more distros followed the Arch approach. Redhat is particularly bad I think - I have had problems with the centos frankenkernel that I could never reproduce on other systems.
- kingosticks 7y ago
  So, maybe this is not quite the same thing, but wasn't it Arch (and only Arch?) that made python point to python3? And in doing so went against what the upstream Python project explicitly specified to do? I remember dealing with a few users who ran into this.
  - doubleunplussed 7y ago
    I believe they made this change before the official advice was contrary to it. Also, if you download and compile Python from python.org, isn't it also just 'python' that you get as your executable? If so arch is just following upstream, and the Python devs should follow their own advice. Arch doesn't seem to be patching this, though you can see in the PKGBUILD that arch explicitly creates 'python3' as a link to 'python' (with a comment lamenting that this isn't done by default) : https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/python https://git.archlinux.org/svntogit/packages.git/tree/trunk?h...
ddebernardy 7y ago
Similar story here. And it's not just distributions. There are web dev shops out there that edit OSS to add some functionality without even bothering to change the version or the user facing information. It makes for plenty of head scratchers when their customers report a bug in a piece of software you wrote.
stickfigure 7y ago
As the parent of a startup and one singular demanding child, I have to ask... 10?! Wow! Nevermind why, I want to know how do you get anything done? Do you have staff? Do you have personal time to yourself, or with your wife? How many soccer games do you attend in a given week? How many bedrooms does your house have? How many of your kids are turning out to be programmers? Forget maintaining software, I want to know how you maintain your existence. I don't think I could survive.
- krageon 7y ago
  I know... A lot of people who come from huge families, and from what their parents tell me, when you have more kids they are a bit easier to handle because they sort of take care of themselves. And of course you don't drive them to 10 football games every weekend, because you're not made of time :)
- pgeorgi 7y ago
  > I have to ask... 10?! > How many soccer games do you attend in a given week? One: souprock's kids + one friend vs. some other team.
- olau 7y ago
  I only have four small kids, but you're approaching this from the single kid direction. Once you have two, you stop caring as much about the first precious one - because you have two precious ones. So sometimes one has to wait. Repeat that a few times, and you'll arrive at your answer. With more kids, it becomes clear that there are things you simply cannot do, e.g. own a 11-bedroom house or drive each single kid to soccer. So the kids will have to do something else. Like playing with each other. That's just the way it is. There's virtually no free time, though. :)
  - cdaven 7y ago
    Ironically, we get a whole lot of free time when we invite the kids' friends over. They disappear somewhere and play for hours and hours.
- rjsw 7y ago
kashyapc 7y ago
[Disclosure: I'm a long-term Red Hatter.] Hmm. That's painful indeed. Sorry that you had such a dispiriting experience with the 'procps' package. For what it's worth, allow me to share my experience (I joined after 2008; so I can only speak about that period onwards) of being at Red Hat. One of the reasons that keep me at Red Hat is the iron-clad (with some sensible exceptions, e.g. security embargoes) principle of Upstream First. I see every day (and the community can verify -- the source out it there) maintainers upholding that value. And I've seen several times over the years maintainers, including yours truly, vigorously reject requests of 'downstream-only' patches or other deviations from upstream. When there are occasional exceptions, they need extraordinary justifications; either that, or those downstream patches are irrelevant in context of upstream. I've learnt enormously from observing inspiring maintainers at Red Hat (many are also upstream maintainers) on how to do the delicate Tango of balancing the upstream vs. downstream hats. So if it's any consolation, please know that for every aberration, there are thousands of other packages that cooperate peacefully with relevant upstreams.
- kashyapc 7y ago
  > the source out it there [Typo: "out it there --> "is out there"]
- loqd 7y ago
  Some of RedHat's dual upstream/downstream maintainers are possessively trying to take over the upstream projects while not doing very important changes. Others are great human beings. But on the whole, RedHat skepticism is healthy (this also applies to the NIH software that they push onto most Linux distributions).
  - Diederich 7y ago
    > NIH software that they push onto most Linux distributions This is likely off topic, but can you expand on that if you have a moment? Thanks.
    - inferiorhuman 7y ago
vertis 7y ago
Without trying to minimize this experience, I can't help but wonder if newer tools and techniques have mitigated some of this problem. For example GitHub pull requests make it much easier to collaborate on one version rather than an upstream, downstream relationship.
h91wka 7y ago
> He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I remember the frustration when I found that NixOS maintainers downright crippled certain build systems to force people to use Nix...
- gmfawcett 7y ago
  Who's forcing you to use Nix? Their goal was probably to get the thing building within the constraints of their own time, and the constraints of the Nix ecosystem. You can choose whether you want to invest the time to fix those build scripts and re-enable the other build systems, or not -- totally up to you. But it's uncharitable to suggest that the Nix maintainers have some kind of secret agenda.
  - h91wka 7y ago
    Yes, they do have an agenda, because how else you explain patches like this: https://github.com/NixOS/nixpkgs/blob/1137200d6b7fcf8fc401b54e8292f24f09bfc11d/pkgs/development/tools/build-managers/rebar3/hermetic-rebar3.patch#L56 https://github.com/NixOS/nixpkgs/blob/1137200d6b7fcf8fc401b5... Note that they didn't fork the project under some different name, they shipped it like this under the original name.
    - gmfawcett 7y ago
      Of course they have an agenda. Nix is one of the most opinionated Linux distros in existence. They have an absolute insistence on reproducible builds. What I said was that they didn't have a secret agenda. They are completely up front about reproducibility. Code that violates this principle needs to be fixed (or disabled, as in this Rebar example). If that doesn't meet your needs, then just move on. Nix isn't a distro that will please everyone.
      - h91wka 7y ago
        rebar3 itself supports reproducible builds via lock files. Applying patches like this instead of embracing the right way that the upstream designed for this exact purpose is just ignorance. I would be totally cool with any incompatible patches that distro makes for its needs, as long as the binary is renamed. But they shipped a broken binary and called it rebar3. Not "rebar3-nix", but "rebar3". People try using this binary for development and it doesn't work, they go to the upstream and the upstream spends time investigating someone else's hacks.
rurban 7y ago
I'm very happy with downstream patches. They come 90% from Redhat, rarely from Debian or Suse. The Redhat patches are usually 100x better than other contributors patches. Debian is usually the worst. When I maintained ~250 cygwin packages I acted as downstream also, and had to deal with upstream maintainers also. Usually a horror, maybe because I came from cygwin which was a crazy hack. Only postgresql said "such a nice port". For perl, gcc, python,... you were just a crazy one to be ignored.
- anarazel 7y ago
  > Only postgresql said "such a nice port". It is a crazy port ;). But the native windows port is much crazier :) /me wishes for a fountain of time to change postgres' threading model.
- lamby 7y ago
  > Debian is usually the worst. Can you elaborate?
debiandev 7y ago
I've been packaging for Debian for a decade and I ran into a lot of unfriendly upstreams that would refuse to make any change to allow packaging and I've never seen other Debian Developers treating upstream developers poorly.
LameRubberDucky 7y ago
Wow. Are you Albert mentioned in the man page? Seems like some unneeded snark after your entry. I think I would have left too. "Albert rewrote ps for full Unix98 and BSD support, along with some ugly hacks for obsolete and foreign syntax."
- souprock 7y ago
  I am, but I wrote that. Something like "ps -axu" will fail the UNIX/POSIX/SysV parsing, then restart in a pure BSD mode with the "-" ignored. Something like "ps -aux" will too, unless there is a user named "x". There is also a PS_PERSONALITY environment variable to force the parser to act in a particular way. It was needed to transition people over to a standards-compliant syntax. I couldn't support all the old syntax. Prior to 1997, something like "ps -ef" would parse as "ps ef" does today, which is not standards-compliant. People were unwilling to just switch over without the compatibility hacks. There were instances of things like "ps -aux" all over the place, including in people's private shell scripts. People couldn't resist typing it. I got pushback just for including the warning on stderr when somebody caused the parser to kick in to compatibility mode.
contingencies 7y ago
Haha! What are the odds? Maintainer of ps spawns too many subprocesses, runs up against parallelism... I think it's the Unix story in a nutshell.
aaron-santos 7y ago
More of a general question: is there any license or addendum clause which could have remedied this? Linux distribution creators love adhering to specific license requirements. Would a choice between distributing vanilla software vs not distributing have been more appealing?
- bonzini 7y ago
  That would make the program not free/open source (e g. CC-BY-ND is not considered free), so free-only distros such as Fedora would have simply not considered it.
- wmf 7y ago
  Trademarks can control this while remaining open source. If you ship an official package it's Firefox™ but if you ship a hacked-up version it's Iceweasel. Of course everyone will tell you you're evil if you try to do this.
agumonkey 7y ago
Crazy how social relationship leaks back into the open source concept. Sorry you had to endure all this.. not fun.

cyphar 7y ago

That sounds really awful, and it's really disheartening to see the (ex)maintainer of such a core piece of Linux distributions being treated that way. I work for a Linux distribution (SUSE) and I assure you that we don't all act this way. I've had to carry my fair share of downstream patches in openSUSE/SUSE packages, but I always make sure to submit the patches upstream in parallel. Quite a few people I know from Red Hat (and other distributions like Debian, Ubuntu, etc) do the same. It's possible that times have changed since then, or that it depends which package maintainers you are dealing with, but I hope it hasn't soured your opinion of all Linux distribution maintainers. One thing that is a constant problem is that users of distributions keep submitting bugs to upstream bug-trackers. If there was one thing I wish I could change about user behaviour, it would be this. Aside from the fact that the bug might be in a downstream patch (resulting in needless spam of upstream), package maintainers are also usually better bug reporters than users because they are more familiar with the project and probably are already upstream contributors.

arendtio 7y ago
> If there was one thing I wish I could change about user behaviour, it would be this. Speaking from a user perspective, I don't think that would be wise. If distributions would just stop feature patching, things would be a lot simpler. I mean, if a feature is good, everyone should have it, not just the users of one distribution. So please submit the patch upstream, discuss it and wait for the next release. That way, there is no real problem when users submit to upstream bug-trackers. The only exception is (time-critical) security patching. But those patches should be removed again as soon as upstream solves the issue. The scenario you are wishing for looks like an obvious solution to the issues you are having but will just make everything worse in the long run (slow and fragmented).
- jiggunjer 7y ago
  Are there any distros with a strict upstream-only policy?
  - deleted 7y ago
    [deleted]
  - kashyapc 7y ago
    Fedora comes very close. But I'm biased, as a user of (and contributor to) it for about ten years. Don't take my word for it, read the related documentation[1]: "The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository. The following guidelines are a general set of best practices, and provide reasons why this is a good idea, tips for sending your patches upstream, and potential exceptions Fedora might make. The primary goal is to share the benefits of a common codebase for end users and developers while simultaneously reducing unnecessary maintenance efforts." The linked[1] documentation also answers, with specific examples, the question of: "What are deviations from upstream?" [1] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects https://fedoraproject.org/wiki/Staying_close_to_upstream_pro...
  - majewsky 7y ago
    https://www.archlinux.org/about/ https://www.archlinux.org/about/ > Arch [Linux] strives to keep its packages as close to the original upstream software as possible. Patches are applied only when necessary to ensure an application compiles and runs correctly with the other packages installed on an up-to-date Arch system.

bscphil 7y ago

One of the things I really like about Arch Linux is their policy of not making unrequired changes to upstream software. The only changes usually made are those necessary to keep the software compatible with the other software on a rolling release system, and these changes are usually temporary.

paco3346 7y ago
I love this about Arch. It gives everything a very vanilla, organic feel and you never get caught off guard by some distro specific change.
nvarsj 7y ago
Ditto. Arch has the right attitude. I still have a bitter taste from a 0 day hack of one of my Debian servers, due to what I believed was a Debian only patch. I wish more distros followed the Arch approach. Redhat is particularly bad I think - I have had problems with the centos frankenkernel that I could never reproduce on other systems.
kingosticks 7y ago
So, maybe this is not quite the same thing, but wasn't it Arch (and only Arch?) that made python point to python3? And in doing so went against what the upstream Python project explicitly specified to do? I remember dealing with a few users who ran into this.
- doubleunplussed 7y ago
  I believe they made this change before the official advice was contrary to it. Also, if you download and compile Python from python.org, isn't it also just 'python' that you get as your executable? If so arch is just following upstream, and the Python devs should follow their own advice. Arch doesn't seem to be patching this, though you can see in the PKGBUILD that arch explicitly creates 'python3' as a link to 'python' (with a comment lamenting that this isn't done by default) : https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/python https://git.archlinux.org/svntogit/packages.git/tree/trunk?h...

ddebernardy 7y ago

Similar story here. And it's not just distributions. There are web dev shops out there that edit OSS to add some functionality without even bothering to change the version or the user facing information. It makes for plenty of head scratchers when their customers report a bug in a piece of software you wrote.

stickfigure 7y ago

As the parent of a startup and one singular demanding child, I have to ask... 10?! Wow! Nevermind why, I want to know how do you get anything done? Do you have staff? Do you have personal time to yourself, or with your wife? How many soccer games do you attend in a given week? How many bedrooms does your house have? How many of your kids are turning out to be programmers? Forget maintaining software, I want to know how you maintain your existence. I don't think I could survive.

krageon 7y ago
I know... A lot of people who come from huge families, and from what their parents tell me, when you have more kids they are a bit easier to handle because they sort of take care of themselves. And of course you don't drive them to 10 football games every weekend, because you're not made of time :)
pgeorgi 7y ago
> I have to ask... 10?! > How many soccer games do you attend in a given week? One: souprock's kids + one friend vs. some other team.
olau 7y ago
I only have four small kids, but you're approaching this from the single kid direction. Once you have two, you stop caring as much about the first precious one - because you have two precious ones. So sometimes one has to wait. Repeat that a few times, and you'll arrive at your answer. With more kids, it becomes clear that there are things you simply cannot do, e.g. own a 11-bedroom house or drive each single kid to soccer. So the kids will have to do something else. Like playing with each other. That's just the way it is. There's virtually no free time, though. :)
- cdaven 7y ago
  Ironically, we get a whole lot of free time when we invite the kids' friends over. They disappear somewhere and play for hours and hours.
rjsw 7y ago

kashyapc 7y ago

[Disclosure: I'm a long-term Red Hatter.] Hmm. That's painful indeed. Sorry that you had such a dispiriting experience with the 'procps' package. For what it's worth, allow me to share my experience (I joined after 2008; so I can only speak about that period onwards) of being at Red Hat. One of the reasons that keep me at Red Hat is the iron-clad (with some sensible exceptions, e.g. security embargoes) principle of Upstream First. I see every day (and the community can verify -- the source out it there) maintainers upholding that value. And I've seen several times over the years maintainers, including yours truly, vigorously reject requests of 'downstream-only' patches or other deviations from upstream. When there are occasional exceptions, they need extraordinary justifications; either that, or those downstream patches are irrelevant in context of upstream. I've learnt enormously from observing inspiring maintainers at Red Hat (many are also upstream maintainers) on how to do the delicate Tango of balancing the upstream vs. downstream hats. So if it's any consolation, please know that for every aberration, there are thousands of other packages that cooperate peacefully with relevant upstreams.

kashyapc 7y ago
> the source out it there [Typo: "out it there --> "is out there"]
loqd 7y ago
Some of RedHat's dual upstream/downstream maintainers are possessively trying to take over the upstream projects while not doing very important changes. Others are great human beings. But on the whole, RedHat skepticism is healthy (this also applies to the NIH software that they push onto most Linux distributions).
- Diederich 7y ago
  > NIH software that they push onto most Linux distributions This is likely off topic, but can you expand on that if you have a moment? Thanks.
  - inferiorhuman 7y ago

vertis 7y ago

Without trying to minimize this experience, I can't help but wonder if newer tools and techniques have mitigated some of this problem. For example GitHub pull requests make it much easier to collaborate on one version rather than an upstream, downstream relationship.

h91wka 7y ago

> He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do. I remember the frustration when I found that NixOS maintainers downright crippled certain build systems to force people to use Nix...

gmfawcett 7y ago
Who's forcing you to use Nix? Their goal was probably to get the thing building within the constraints of their own time, and the constraints of the Nix ecosystem. You can choose whether you want to invest the time to fix those build scripts and re-enable the other build systems, or not -- totally up to you. But it's uncharitable to suggest that the Nix maintainers have some kind of secret agenda.
- h91wka 7y ago
  Yes, they do have an agenda, because how else you explain patches like this: https://github.com/NixOS/nixpkgs/blob/1137200d6b7fcf8fc401b54e8292f24f09bfc11d/pkgs/development/tools/build-managers/rebar3/hermetic-rebar3.patch#L56 https://github.com/NixOS/nixpkgs/blob/1137200d6b7fcf8fc401b5... Note that they didn't fork the project under some different name, they shipped it like this under the original name.
  - gmfawcett 7y ago
    Of course they have an agenda. Nix is one of the most opinionated Linux distros in existence. They have an absolute insistence on reproducible builds. What I said was that they didn't have a secret agenda. They are completely up front about reproducibility. Code that violates this principle needs to be fixed (or disabled, as in this Rebar example). If that doesn't meet your needs, then just move on. Nix isn't a distro that will please everyone.
    - h91wka 7y ago
      rebar3 itself supports reproducible builds via lock files. Applying patches like this instead of embracing the right way that the upstream designed for this exact purpose is just ignorance. I would be totally cool with any incompatible patches that distro makes for its needs, as long as the binary is renamed. But they shipped a broken binary and called it rebar3. Not "rebar3-nix", but "rebar3". People try using this binary for development and it doesn't work, they go to the upstream and the upstream spends time investigating someone else's hacks.

rurban 7y ago

I'm very happy with downstream patches. They come 90% from Redhat, rarely from Debian or Suse. The Redhat patches are usually 100x better than other contributors patches. Debian is usually the worst. When I maintained ~250 cygwin packages I acted as downstream also, and had to deal with upstream maintainers also. Usually a horror, maybe because I came from cygwin which was a crazy hack. Only postgresql said "such a nice port". For perl, gcc, python,... you were just a crazy one to be ignored.

anarazel 7y ago
> Only postgresql said "such a nice port". It is a crazy port ;). But the native windows port is much crazier :) /me wishes for a fountain of time to change postgres' threading model.
lamby 7y ago
> Debian is usually the worst. Can you elaborate?

debiandev 7y ago

I've been packaging for Debian for a decade and I ran into a lot of unfriendly upstreams that would refuse to make any change to allow packaging and I've never seen other Debian Developers treating upstream developers poorly.

LameRubberDucky 7y ago

Wow. Are you Albert mentioned in the man page? Seems like some unneeded snark after your entry. I think I would have left too. "Albert rewrote ps for full Unix98 and BSD support, along with some ugly hacks for obsolete and foreign syntax."

souprock 7y ago
I am, but I wrote that. Something like "ps -axu" will fail the UNIX/POSIX/SysV parsing, then restart in a pure BSD mode with the "-" ignored. Something like "ps -aux" will too, unless there is a user named "x". There is also a PS_PERSONALITY environment variable to force the parser to act in a particular way. It was needed to transition people over to a standards-compliant syntax. I couldn't support all the old syntax. Prior to 1997, something like "ps -ef" would parse as "ps ef" does today, which is not standards-compliant. People were unwilling to just switch over without the compatibility hacks. There were instances of things like "ps -aux" all over the place, including in people's private shell scripts. People couldn't resist typing it. I got pushback just for including the warning on stderr when somebody caused the parser to kick in to compatibility mode.

contingencies 7y ago

Haha! What are the odds? Maintainer of ps spawns too many subprocesses, runs up against parallelism... I think it's the Unix story in a nutshell.

aaron-santos 7y ago

More of a general question: is there any license or addendum clause which could have remedied this? Linux distribution creators love adhering to specific license requirements. Would a choice between distributing vanilla software vs not distributing have been more appealing?

bonzini 7y ago
That would make the program not free/open source (e g. CC-BY-ND is not considered free), so free-only distros such as Fedora would have simply not considered it.
wmf 7y ago
Trademarks can control this while remaining open source. If you ship an official package it's Firefox™ but if you ship a hacked-up version it's Iceweasel. Of course everyone will tell you you're evil if you try to do this.

agumonkey 7y ago

Crazy how social relationship leaks back into the open source concept. Sorry you had to endure all this.. not fun.