Ticket #154 (closed task: fixed)

Opened 7 years ago

Last modified 7 years ago

Revert the recently published Flag policy

Reported by: ixs Owned by:
Priority: major Keywords: meeting
Cc: spot, toshio Blocked By:


The new flag policy, discussed in January, was recently announced to fedora developers.

I do believe that accepting the proposal was a mistake and ask FESCO to please overturn the proposal as is.

The current policy is not mandated by Red Hat legal, therefore FESCO is free to overturn the earlier decision.

There certainly are reasons for mandating a flag policy, most connected to a flag being a political symbol, e.g. a Linux operating system being certified for sale in the P.R.C. might encounter problems if it chooses to show a Taiwan having a separate flag. While this is certainly reason enough for a commercial entitity to require it's shipped software to be modified to appease potential customers, it is the wrong policy for fedora:

  • Fedora maintainers are volunteers. We should not mandate policies burdening them with unnecessary work.
  • Removing flags from packages means locally patching fedora packages. Upstream authors have in the past reacted defensively to patches removing graphical symbols from their packages and rejected such patches. This would mean that fedora has to maintain it's patch for indefinite times if upstream is not cooperative. One of our main principles is to _not_ fork upstream versions, which is violated by this policy.

As can be seen on the newly improved fedora-devel list, many other maintainers share my opinion.

So, please reexamine said policy and throw it out. We already have upstream authors telling us that our packaging guidelines are useless, no need to bolster their arguments with really useless policies.



Change History

comment:1 Changed 7 years ago by jstanley

  • Cc spot added
  • Keywords meeting added

CC'ing spot since he proposed the original policy.

comment:4 Changed 7 years ago by dwmw2

As with various other types of material, we have to make a judgement on whether to remove/ban them, or whether they're OK to be included in Fedora.

We need to compare the disadvantages of including the problematic material with the disadvantages of removing it.

For stuff like profanity, the more colourful fortune files and 'dubious' imagery (including the random image screensaver stuff), the technical downside of removing them is fairly small. So even though I personally don't like pandering to political correctness, I accept that on balance it's saner to remove them.

The same kind of decision-making process applies to flags -- we have to balance the pain of shipping them against the pain of removing them.

I voted for the policy because I believe(d) that the "pain" of removing flags is fairly much negligible. Others disagree vehemently with that position. There is a common (or at least vocal) perception that removing flags is _more_ painful, and _more_ technically detrimental to Fedora, than we had originally believed -- thus potentially changing the balance enough to change our decision.

The other thing to consider is whether the policy would actually fix the 'problem' it sets out to fix. The policy as stated would not ban flags outright, but would allow them to be shipped with explicit FESCo approval. If we would then end up with Fedora being undistributable in the affected countries _anyway_, we haven't actually gained anything and might as well have abandoned the policy. So we should perhaps give some thought to what our policy would be w.r.t. granting exceptions.

Also, do we want to postpone this until after the forthcoming FESCo elections? If people really feel strongly and there are some anti-flag-policy candidates standing for the election, that could change the outcome. It's not as if there's any rush -- we're not holding F-11 up to implement the policy, after all.

comment:5 Changed 7 years ago by ixs

In order to facilate the decision on this topic, I re-read the rather heated discussion on fedora-devel-list and tried to summarize it.

NB: I did try to be as neutral and as far as I can see, there are really much more reasons against the policy to be found on the mailinglist then for the mailinglist. The proponents of a flag-ban are basically concentrating on four arguments. If I should have overlooked any argument mentioned on the ML in favor of banning flags, please accept my apology. On another note: I find the discussion culture on fedora-devel-list detestable. Straw man arguments are flying wild and ad-homminem attacks are following shortly after. But what really struck a chord were some of the retorts I read. Answering to complaints about additional work for maintainers by stating that, if a maintainer is not willing to do things properly, maybe he shouldn't be doing anything for Fedora" is not what I consider conductive to the aim of building or fostering a community.

First, for people coming in late, some neutral background on the newly created Flag policy:

  • Flags are a political issue
  • Flags are *not* a legal issue.
  • There was an unofficial and unwritten no-flag policy inside Red Hat Engineering. This idea behind this rule was reportedly to prevent potential problems when certifying Red Hat (Enterprise) Linux for sale on the Chinese market.
  • There are reports however, that this rule was not uniformly enforced. FreeCiv had flags, Language chooser had not.
  • This rule was never officially mandated for Fedora. If Fedora packages did not include Flags it was the maintainers judgement.
  • There is a strong suggestion though in the Fedora wiki to not use Flags as a symbol for language, translations or UI design. This suggestion is part of the Translation Guidelines and does not apply to packaging.
  • To be clear: Fedora never had a no-flags policy. Judging by prior Fesco logs and discussion on the mailing list, some people are under the impression that the newly ratified policy was a relaxation of the prior rules. This impression is incorrect.
  • The current no-flags policy was written by Spot as the Fedora legal contact due to the request of a single Fedora contributor. This policy was not mandated by Red Hat legal.

Reasons mentioned during the discussion on fedora-devel-list for dropping flags from the distribution:

  • Flags are a political issue. Some countries could restrict distribution of Fedora due to Fedora containing potentially offensive flags to said country.
  • In order to make sure that Fedora is able to be used globally by everybody, this offensive content should be removed. As there's no wish to favor any side, all flags are to be dropped.
  • Being able to legally distribute Fedora in China is important because China is a populous country with many potential users and contributors.
  • Flags are usually a sign of bad user interface design. E.g. Language selection should never ever be done with a flag as it is often incorrect. A country such as Switzerland has four languages, but only one flag.

Reasons mentioned during the same discussion against dropping flags, respectively against introducing such a policy at all.

  • It's an upstream problem, not a Fedora problem. While bad UI design is certainly an issue and damnable we're not expected to correct the countless problems in Gnome. Why should we be forced to fix incorrect language selection screens? It is perfectly okay to work together with upstream to fix this, but it's not okay to carry a private patch in Fedora in case upstream is uncooperative.
  • Upstream is usually not willing to remove flags from their code as the flags have been a specifically requested feature as is the case with deluge.
  • Fedora focuses on not deviating from upstream in the software it includes in the repository. The examples which patches are acceptable not being upstreamed do not include anything remotely resembling the no-flags policy.
  • The policy requires contributors to spend extra work on satisfying an arbitrary policy which does not in any way improve the technical aspects of the package. It is actually reversed, future package updates are harder as fedora diverted from upstream code. This could have an negative impact on the availability of future security updates.
  • The extra effort without a technical improvement required from contributors may discourage them.
  • Fedora is the Red Hat Enterprise Linux Upstream. Therefore its priorities differ from Red Hat's priorities. Similarly, Fedora is not the Red Hat Engineering department. Red Hat Engineering has maintainers capable of removing docs, code, flags or any other data if deemed necessary. Any decision Red Hat Engineering makes, should not impact Fedora.
  • Quoting on the same note: We should not think like a business, as we aren't a business, and the company we're all thinking of doesn't make any money out of us.
  • While it is acceptable for most/all Fedora contributors that there are certain legal limits for Fedora due to the fact that Red Hat is bound by US law, implementing policy based on political and legal constraints from foreign countries is seen as a slippery slope. What will be the next policy implemented because of this? Where will it stop? Possible future problems (from the top of my head and tipped towards European legislation, as that's where I'm located):
    • Removal of cryptographic software from Fedora because there are limits on crypto in France and Russia
    • Removal of games from Fedora due to the need to have them approved and marked accordingly to their suitability and age range. Alternatively: Fedora can only be made available to people aged 18 or older in Germany and other EU countries.
    • Full translation of all accompanying documentation into the local language of all EU countries.
  • The purported benefits of being legally available in China are a straw man. The balance between the potential gain and the loss to fedora is not achieved.
  • The aim of Fedora being 100% legal/politically undisputed/ethnoculturally sound/loved and responsible for world peace in every jurisdiction/country/ ethnical group is never going to be achieved. This again looks too much like another straw man argument.
  • The goal is noble, but there are limits to what we should to to get there.
  • History sadly showed, appeasement does not work in the long term.
  • There's no guarantee that dropping flags will assure the legality of distributing/using fedora in China. Aiming to satisfying Chinese constraints is setting us up for disappointment/failure and will prove to be an exercise in futility.
  • In fact, there are currently no problems at all in obtaining and using Fedora in China. The whole reasoning is moot.
  • The current policy already has too many holes to be useful as there are enough programs which have justification for including flags.
  • The policy is unclear and illogical: A religious symbol, such as a cross is allowed. Putting a rectangle around it, thus making it a flag, is forbidden? As there are unclear definitions, who is going to clearly define unclear concepts which differ from location to location?
  • The idea of being neutral to any side by banning all flags is absurd. The truth is, you already caved in to repressive demands and now you're trying to hide the fact by exceeding the demands.
  • We're actually limiting _our_ _own_ freedom by catering to a repressive regime. This is especially sad, as our current logo sports the freedom moniker as the first of four F's.

The different suggestion to resolve this issue raised on the ML are as follows:

  • Keep the current policy as is. This will potentially pose problems with the distributability in the China and will also be irritating to maintainers.
  • Forbid absolutely all flags, no exceptions. Does not guarantee legal distribution in china and is irritating to maintainers.
  • Implement various technical procedures to mark flag carrying packages to simplify removal of these packages for localized spins.
  • Revoke the current policy, resulting in fedora not caring about flags. This will potentially pose problems with the distributability in china.

My personal recommendation to Fesco would therefore be the following:

  1. Overturn the current no-flag policy. It is not fit for Fedora and does not even succeed in fulfilling it's promise. This will mean, that flag encumbered packages are perfectly okay for Fedora.
  2. If Fesco does in fact consider flags a problem Fedora should care about, do not mandate a new policy but instead encourage the formation of a Fedora SIG looking into ways to allow people living in repressive countries to easily generate spins fitting their constraints. Any potential changes to packages can then be advocated by the SIG as needed.

Personally though I'd like Fesco to _not_ enact any policy on Flags. The conclusive arguments to me supporting this are that it is basically an upstream problem which we should try to persuade upstream on working on and even more importantly, the fear that we're setting a precedent which will haunt us in the future.

comment:6 Changed 7 years ago by kkofler

Some arguments against dropping flags which came up (in fact, I posted them) and which you have missed:

  • There are over a dozen affected packages (and those are just the ones I know of, I strongly suspect there are more). Even the GNOME desktop spin which was claimed flag-free includes at least a UN flag. So the argument for dropping flags that "only 4 or 5 packages are affected" is moot.
  • Some upstreams (e.g. KDE) are not willing to remove flags because they consider doing so to be a political statement. (This is related to the "It's an upstream problem" and "The idea of being neutral to any side by banning all flags is absurd." arguments you already quoted.)

I haven't noticed any other arguments for dropping flags either (except the "only 4 or 5 packages are affected" one which is provably false).

comment:7 Changed 7 years ago by pwouters

Flags are not the only entity that describes a nation. The nation is the real problem, and it consists of more then just flags.

as maintainer of dnssec-conf, if Taiwan goes DNSSEC, can I not include their key?

There are other occurances of regions, countries and geographic maps that would surely be as bad as flags. Will those have to be removed too?

Let the censors to their own censoring. I do not wish to do it for them, as it does not promote my personal goal of giving people free software. Fedora is already free, it does not need to be free-er.

comment:8 Changed 7 years ago by toshio

If I might make a suggestion to make the meeting flow smoother, it might be a good idea to have a mini agenda for the flag discussion. Something like:

  • Preliminary vote: outright reject the flag policy and replace it with nothing. If this passes, everyone can go home but I doubt it will happen :-).
  • enumerate all the (possibly conflicting) goals of a flag policy
  • discuss solutions
  • 10 minutes from meeting end: if there's no obvious solution yet, call time on the discussion until next week so you can:
  • Assign people to write up the competing proposals for a new policy.
  • discuss whether the current policy should be enforced or suspended until FESCo comes up with a better policy.
  • Vote on whether the policy should be enforced or suspended until FESCo comes up with a better policy.

comment:9 Changed 7 years ago by jstanley

  • Status changed from new to closed
  • Resolution set to fixed

FESCo voted to retract the current policy and do research as to the impact and scope of any potential new policy.

Note: See TracTickets for help on using tickets.